Wi-Fi Roaming, Channel and Transmit-Power Tuning Workshop

1. Define the roaming use case

Voice handsets, scanners and moving laptops have different tolerance for roaming interruption. Record the actual client models and application sensitivity.

2. Capture the RF baseline

Record AP locations, channels, channel widths, transmit powers, utilisation, noise and client distribution before changing anything.

3. Avoid maximum-power design

If APs transmit much louder than clients can answer, clients may hear distant APs but fail on the return path. Excessive cell overlap can also encourage sticky clients.

4. Plan channel reuse

Co-channel contention is shared airtime, not simply interference. Use enough channel separation and reuse for the environment and regulatory domain.

5. Tune 2.4 GHz deliberately

2.4 GHz has limited non-overlapping channel options in common deployments and often carries legacy/IoT devices. Do not let it dictate AP placement intended for 5/6 GHz capacity.

6. Test real roaming

Walk the actual route with representative clients while generating application traffic. Record transition points, packet loss, latency and any authentication delays.

7. Use controller features carefully

Band steering, minimum data rates, load balancing and fast-roaming features can help but can also expose client compatibility problems. Change one control at a time.

8. Post-change survey

Repeat measurements after tuning. The goal is not prettier heatmaps but reliable client experience in the target areas.

9. Document the tuned state

Record channels, widths, power levels, exceptions and test results so future automatic or manual changes can be compared to a known baseline.

Worked field scenario

Warehouse scanners stay attached to a distant AP while moving down an aisle. Raising AP power can make the imbalance worse. Measure the scanner radio behaviour, overlap, retries and transition points, then tune cells and roaming-related controls with that client in hand.

Procurement questions before ordering

The ordering stage is where many field problems are created. Capture the following before selecting the exact product:

• Client device types and application requirements
• Floor/site plan and AP mounting constraints
• Regulatory domain and supported bands
• PoE and wired uplink capability
• Pre-install or validation survey plan

Where a manufacturer compatibility list, rail matrix, supported-optics table or battery cartridge reference exists, record the exact source used for the decision. That gives the later installer evidence rather than a verbal assumption.

Fault-finding decision path

Separate RF from IP. Confirm the client can see and join the intended SSID, then examine RSSI/SNR, channel utilisation, retries and roaming behaviour before moving to DHCP, DNS, gateway and application tests. Compare a failing client with a known-good client at the same location.

Keep a simple change log while troubleshooting: observation, action, result. If a change does not alter the symptom, put the system back unless there is a documented reason to retain it. This prevents troubleshooting from becoming an uncontrolled configuration drift.

Common mistakes that create repeat faults

Do not fix coverage complaints by setting every AP to maximum power. Do not choose AP count from an advertised square-metre number alone. Do not change channels, widths, power and minimum rates simultaneously because you will not know which change helped or hurt.

A technically successful installation can still be a poor operational result if the next technician cannot identify what was installed, why it was selected, or how it was tested. Serviceability is part of infrastructure quality.

Acceptance and handover evidence

Keep the final AP map, channel/width/power state, switch port and PoE mapping, post-install survey evidence and representative client tests. Record deliberate exceptions so the next administrator does not undo them thinking they are mistakes.

Use filenames, labels and port/bay identifiers that match the physical installation. Handover evidence should let someone who was not present at the installation verify the final state and repeat the important tests later.