Hong Kong Wi-Fi Knowledge Hub · Compliance and interference analysis
WiFi-HKCommercial Wireless Network Engineering

ENGINEERING WORKBENCH / Evidence before changes

Engineer's Workbench
Support Every Decision with Evidence

Compare normal and abnormal behaviour and follow the packet path. Build repeatable testing, change and acceptance methods across radio, clients, wired networking and services.

Compare normal and abnormal behaviourCreate Measurement Records
A starting point for engineering judgement

A strong signal does not prove the service is working. First identify who is affected, where, when and in which application, then align client, AP, switch and service evidence on the same timeline.

NORMAL / ABNORMAL

Six Normal and Abnormal Comparisons

All numbers, trends, events and access-control results are synthetic teaching examples. They illustrate interpretation methods, rather than universal acceptance thresholds or completed projects.

SNR / RSSI

Signal and Noise

Normal ExampleRSSI −58 dBm · Noise floor −93 dBm · SNR 35 dB
Synthetic trend illustration for the normal exampleRelative shape · unitlessT0Illustrative time

Synthetic, unitless concept trend. The line does not correspond to the example values above, and the time axis does not specify sampling seconds. It cannot be used to calculate thresholds or interruption durations.

Record signal and background noise separately; the specified client can consistently complete its work.

Abnormal exampleRSSI −75 dBm · Noise Floor −88 dBm · SNR 13 dB
Synthetic trend illustration for the abnormal exampleRelative shape · unitlessT0Illustrative time

Synthetic, unitless concept trend. The line does not correspond to the example values above, and the time axis does not specify sampling seconds. It cannot be used to calculate thresholds or interruption durations.

Signal weakens behind a wall or at the end of a rack aisle, while retries or application latency increase.

What to Collect First
Record bidirectional results using the same location, band and client; compare RSSI, SNR, retries and application response time. What an AP hears from a client may differ from what the client hears from the AP.
Next assessment
Check location, materials, antenna orientation and client devices first. Increasing AP power may not improve a client's uplink capability.

CHANNEL / RETRIES

Full signal but slow speeds

Normal ExampleChannel utilisation 28% · Retries 4%
Synthetic trend illustration for the normal exampleRelative shape · unitlessT0Illustrative time

Synthetic, unitless concept trend. The line does not correspond to the example values above, and the time axis does not specify sampling seconds. It cannot be used to calculate thresholds or interruption durations.

At the load in this example, the channel still has available airtime and application latency does not keep rising with user numbers.

Abnormal exampleChannel Busy 86% · Retries 24%
Synthetic trend illustration for the abnormal exampleRelative shape · unitlessT0Illustrative time

Synthetic, unitless concept trend. The line does not correspond to the example values above, and the time axis does not specify sampling seconds. It cannot be used to calculate thresholds or interruption durations.

RSSI remains high, but the channel stays busy; low-rate clients or co-channel devices consume available airtime.

What to Collect First
Align timelines for busy time, Wi-Fi/non-Wi-Fi energy, management traffic, per-client airtime, MCS and retries.
Next assessment
Compare peak and off-peak conditions, channel reuse and bandwidth. Distinguish capacity issues from non-Wi-Fi interference before changing configuration.

BSSID / AUTH / GAP

Application interruption while moving

Normal ExampleBSSID changed · Example interruption 108 ms
Synthetic trend illustration for the normal exampleRelative shape · unitlessT0Illustrative time

Synthetic, unitless concept trend. The line does not correspond to the example values above, and the time axis does not specify sampling seconds. It cannot be used to calculate thresholds or interruption durations.

As the client changes APs along the route, the specified application continues within the latency budget of this demonstration.

Abnormal exampleBSSID Switch Delayed · Example Interruption 960 ms
Synthetic trend illustration for the abnormal exampleRelative shape · unitlessT0Illustrative time

Synthetic, unitless concept trend. The line does not correspond to the example values above, and the time axis does not specify sampling seconds. It cannot be used to calculate thresholds or interruption durations.

The client may remain attached after moving away from the original AP, or reauthentication, DHCP or a subnet change may cause a longer interruption.

In this example, interruption means the longest interval between two successful packets in a continuous test stream. Record the sending interval and wired baseline, and distinguish this gap from BSSID transition time, authentication duration and individual packet latency.

What to Collect First
Synchronise client, AP, RADIUS and application times; record BSSID, band, RSSI, reauthentication and packet loss. Clients usually decide when to roam.
Next assessment
Check coverage overlap, power, minimum data rates, encryption and 802.11k/v/r support. Validate with the actual scanner or voice device.

ASSOC / DHCP / DNS

Connected to Wi-Fi but Unable to Use Services

Normal ExampleDHCP/HTTPS example: Wi-Fi access → IP → DNS → TLS → application
  1. 01
    Wi-Fi accessAssociation and security/identity authentication completed
    Complete
  2. 02
    IP leaseCorrect subnet and gateway obtained
    Complete
  3. 03
    DNS resolutionDesignated test name resolved successfully
    Complete
  4. 04
    TCP／TLSHTTPS connection established
    Complete
  5. 05
    Application responseDesignated service responded successfully
    Complete

This sequence illustrates a DHCP and HTTPS scenario. Networks may use different services or authentication sequences, and the events are not equally spaced time measurements.

Each layer has a corresponding success event, and the device obtains the correct subnet and a usable service path.

Abnormal exampleDHCP/HTTPS example: Wi-Fi access established; no lease obtained
  1. 01
    Wi-Fi accessAssociation and security/identity authentication completed
    Complete
  2. 02
    IP leaseDHCP request sent; no reply observed
    Incomplete
  3. 03
    DNS resolutionTest not performed
    Not tested
  4. 04
    TCP／TLSTest not performed
    Not tested
  5. 05
    Application responseIncomplete
    Not tested

This sequence illustrates a DHCP and HTTPS scenario. Networks may use different services or authentication sequences, and the events are not equally spaced time measurements.

Signal is not the main issue; the client may lack a lease or have an incorrect VLAN, gateway or DNS configuration.

What to Collect First
Check association, 802.1X/PSK, VLAN, DHCP, ARP/ND, DNS, TCP/TLS and application responses layer by layer.
Next assessment
Compare packets on the AP's wired side and the relevant network segments. Check whether requests arrive and responses return, rather than mistaking service-layer failures for RF problems.

VLAN / ACL / IDENTITY

Guest access works with correct internal permissions

Normal ExamplePermitted Services Reachable; Prohibited Internal Resources Unreachable
Example access-control matrix
Source and destinationExpectedObserved
Guest → Internet HTTPS serviceAllowConnection succeededMatches the policy
Guest → internal management HTTPS serviceDenyConnection deniedMatches the policy
Staff → designated internal HTTPS serviceAllowConnection succeededMatches the policy

Identities, services and outcomes are synthetic examples. Validate actual access against the agreed policy, checking source subnets, ports and rule matches for each test.

Verify rules using source identity, destination service and tests in both directions, rather than checking only SSID names.

Abnormal exampleGuests can reach internal resources, or necessary casting/DNS is incorrectly blocked
Example access-control matrix
Source and destinationExpectedObserved
Guest → Internet HTTPS serviceAllowConnection succeededMatches the policy
Guest → internal management HTTPS serviceDenyConnection succeededDoes not match the policy
Staff → designated internal HTTPS serviceAllowConnection deniedDoes not match the policy

Identities, services and outcomes are synthetic examples. Validate actual access against the agreed policy, checking source subnets, ports and rule matches for each test.

Insufficient segmentation can permit unauthorised access; excessive segmentation can prevent required business tasks.

What to Collect First
Build a matrix of identity × source subnet × destination resource × port, then check ACLs, firewalls, client isolation and necessary service discovery.
Next assessment
Define the intended allowed and denied access first, then test both directions and retain rule matches, logs and exceptions.

TRY THE RELATIONSHIP

Same Signal, Different Noise

SNR = RSSI − noise floor. Adjust the example values to see why reception quality differs from signal bars. This calculator does not read your network.

−58 dBm−93 dBm
35 dB−58 − (−93) = 35

This demonstrates the calculation without a pass/fail judgement. Compare readings from the same receiving perspective, band, channel width and sampling window. Do not subtract another AP’s noise reading from a client’s RSSI.

A REPRODUCIBLE RECORD

Measurements must be repeatable

Engineering measurement and acceptance fields
RecordsWhy it is needed
Time, time zone and sampling windowSynchronise AP, RADIUS, switch and application clocks. Record sampling intervals and sample counts.
Location, stock and loadMake empty/full warehouse, peak/off-peak, movement direction and simultaneous connection counts comparable.
Client and RF ConditionsModel, driver, band, channel, channel width, BSSID, power and antenna conditions.
Bidirectional and multilayer metricsUplink/downlink, RSSI/SNR, airtime, retries, packet loss, p50/p95 latency and actual task success rate.
Counter definitions and perspectiveRecord whether counters come from an AP, client or scanning radio, which data or management frames they include, their denominator and firmware version. Retry rate is not application packet-loss rate.
Wired baseline and methodLocal server, WAN, test tool/version, packet size and test duration.
Changes and RollbackChange one set of assumptions at a time, retaining before-and-after configurations, maintenance windows, exceptions and rollback conditions.

Four often-missed checks

  • Check EIRP together with antenna gain and cable loss, and confirm regional variants, indoor/outdoor use and OFCA requirements.
  • PoE specifications and negotiated power can differ. Check requested and granted power, per-port and total budgets, firmware and low power modes for the specific model. Insufficient power may reduce functionality or prevent normal operation; APs do not all behave alike when power is limited.
  • Wide channels and additional APs are not automatic answers to capacity; compare channel reuse, client capabilities and airtime.
  • For MLO, 802.11r or WPA3, check clients, APs, firmware and deployment methods. Support in a specification does not mean a feature is active on every connection.

Packets and logs may contain identity, location or business information. Agree the collection scope, redaction, access rights and retention period before engineering handover.

Make changes into verifiable experiments

  1. Define the symptoms and affected scope.Is one client, one area, the whole SSID or the service itself affected?
  2. Establish a control.Under the same device, location and load conditions, compare wired/wireless, local/WAN and peak/off-peak performance.
  3. State a hypothesis that can be disproved.State clearly which metrics should change together if the proposed cause is correct.
  4. Back up first, then schedule the change.Set rollback methods and stop conditions, and retain a timeline of changes.
  5. Validate with the agreed applications.Test AP transitions, reconnection, permissions, busy-period loads and sustained operation, rather than running one speed test.

This workflow was prepared by WiFi-HK's engineering editors. Formal projects should follow equipment documentation, operational constraints and the agreed SLA.

Common questions about interpreting engineering data

Are There Universal Passing Values for Every Site?

No. First define applications, clients, coverage areas, peak loads and test methods, then agree thresholds. SNR, retries and latency are only part of the picture; instrument sampling, aggregation and direction also affect results.

Why look at p95 rather than just the average?

An average can hide brief spikes. The p95 value means approximately 95% of sample values are at or below it. Interpret it alongside the maximum, packet loss, sample count and time window; one percentile alone cannot guarantee service.

Are these normal and abnormal examples actual customer records?

No. These synthetic data illustrate troubleshooting methods; they are not customer cases, official acceptance thresholds or commitments about engineering performance.

Official References and Updates

Technical sources checked: 11 October 2026. Cases and graphics are synthetic examples created for this website; brand documentation does not indicate a partnership or certification.

Connect measurements to real work

Bring the problem times, locations, client details and redacted records to discuss the next survey and acceptance scope.

Contact WiFi-HK
Ready to improve your Wi-Fi?
First, outline your site requirementsContact WiFi-HK