Validation Survey, next to the Predictive Survey & Design, is the most popular type of the engagement we do in the WiFi consultancy world. We won’t exaggerate when we say we do it at least weekly and that validating / troubleshooting WiFi is a totally crucial skill.
Here is the video version of the Podcast – you can peek at our Ekahau Validation Survey template:
And here is what we have discussed:
Multiple names for the same thing
RF Assessment
Validation Survey
Troubleshooting Survey
It’s actually very similar to Post Deployment survey
Targeting brownfield sites
Capture ‘as-is’ state of WiFi
Data captured is used to produce an easy to read ‘summary’ followed by simple ‘recommendations’
Why do clients ask us to perform a Validation Survey
Documentation purposes
Having issues that are most likely related to RF (physical side of WiFi) and must be identified and rectified
Building business case for re-design
Often sold together with Configuration Assessment
Often leads to more business
Be honest and don’t exaggerate
How and what do we capture on-site
Go on site
Perform full, detailed, passive survey with a survey tool of your choice
Active vs passive – why Ekahau is not best for active
Best active survey test – check if WiFi works for what it was designed for
Voice & video – can you have a good quality call? If not – why?
Basic data – can you browse, scan barcodes etc.?
If you must do throughput test, do them locally (ePerf, WLANpi throughput test)
Ping is a poor test in WiFi due to the nature of how WiFi works – DCF aka ‘The Game’
Grab results of your fav WiFi Scanning tool
Capture what Ekahau can’t capture
Info from QBSS data like number of associated stations, AP reported channel utilisation
Amendments used
Authentication type used
SS info and more
On top of helping understanding RF better, quick WiFi scan can identify tons of common configuration issues without having to review the configuration
Be accurate
Click where you are
Don’t walk on water
Use good quality floor plans and measure with laser tool if required
What do we include in the Ekahau template – quick template demo
Ekahau captures tons of data and gives us access to tons of different heatmaps
Don’t include everything, include only what is relevant for your project
Here are the heatmaps and other info from Ekahau that we include in our Validation Survey documents:
Generic (band agnostic)
Requirements & Areas
Access Points
Survey Routes
Associates APs (make sure to use ‘measured’)
Capacity Health
Data Rates
Throughput (only if done local tests)
RTT (very infrequently)
Per band (same heatmaps for 2.4 and 5)
Coverage per AP
Primary Signal Strength
Secondary Signal Strength
Interference / noise
SNR
CCI
Network Health
Network Issues
Spectrum Utilization
Channel Width
What we don’t include
Capacity: Clients per AP – predicted, no value
Channel Coverage – can’t see a use case
Channel Interference – predicted, no value
Jitter – not best metric
Number of APs – use secondary coverage instead
Packet loss – exaggerated in Ekahau, not great metric
RTT – not best metric
Spectrum Channel Power – can’t see use case
Difference in Signal Strength – can be valuable to compare surveys, but never used it
What do we include in the Summary
A sentence or two about all heatmaps
DFS condition check
Types of APs / Antennas used, their suitability against env they’re in and requirements, mounting
Typical issues
Incorrect type of APs/Antennas used
Tendency to be scared of directional antennas
Dual band operation
Band select used
Some devices on terribly bad 2.4GHz
Coverage and SNR
Not sufficient coverage
High non-WiFi interference
Low SNR
Tons of rogue APs on site
Old overlays, hotspots, click shares
Excessive CCI
Not unusual to see 30+ in central London on 5GHz
Not enough APs
Capacity requirements not met
Sometimes a 100 or more associated stations
Insufficient secondary coverage
Poor WLAN config
No amendments used
Low data rates enabled
APs covering too much – 15m high omnis in WH?
High spectrum utilisation
More devices using WiFi than scoped
WiFi and non-WiFi interference
Too many SSIDs – seen 16 more than once
High packet loss
High airtime utilisation = tons of retransmissions = packet loss
Site heavily affected by DFS
Typical recommendations (just an example, can vary vastly)
Re-design of physical WiFi
Different APs, different antennas types, different mounting
Disable 2.4GHz
Set 5GHz statically to 20MHz
Channel width set to best is sometimes crazy
Use 40MHz until you can’t
Enable some amendments
802.11r
802.11k
Disable low data rates
12 or 24 mandatory is typically OK with all lower disabled and all higher supported
Limit min and max Tx power levels in RRM
5GHz should be ‘louder’ than 2.4GHz – at least 6dBm difference
We use cookies to ensure that we give you the best experience on our website. If you continue to use this site we will assume that you are happy with it!I'm cool!