Hey!

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:

https://youtu.be/hkcTUcxDUD8

 

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
    • Typical Tx levels for 5GHz – around 14-17dBm

Cheers and tons of love,

Your Ninjas.