Wanneer is een post-deployment wifi survey noodzakelijk?

Een post-deployment wifi survey (ook wel validatiesurvey) is een meting op locatie waarmee je controleert of het uitgerolde draadloze netwerk voldoet aan het ontwerp en de afgesproken KPI’s. Denk aan dekking, capaciteit, roaming, latency en interferentie. Het doel is simpel: bevestigen wat werkt, en gericht verbeteren wat niet voldoet. Zoals een toonaangevende leverancier het kernachtig samenvat: "A validation survey verifies that the deployed network meets the design requirements" [2].
In de praktijk combineer je metingen van signaalsterkte, signaal-ruisverhouding en doorvoersnelheid met een beoordeling van clientervaring (zoals voice of realtime apps). Je legt bevindingen vast op plattegronden en rapporteert concrete correcties (zoals kanaalwijzigingen of het verplaatsen van access points).

Plan een validatiesurvey direct na oplevering, zodat je kunt aantonen dat het netwerk aan de doelen voldoet (acceptatie) en je baseline vastlegt. Daarnaast is een survey noodzakelijk bij belangrijke wijzigingen, zoals een verbouwing, nieuwe plafonds of stellingen, andere AP-modellen/firmware, of wanneer het gebruik verandert (bijv. meer videovergaderen, scanners, of IoT). Ook bij klachten over haperende voice, roaminggaten of hoge latency helpt een survey de oorzaak objectief te isoleren [1].
Kort gezegd: bij elke verandering die dekking, demping of capaciteit beïnvloedt, of wanneer je nieuwe bedrijfskritische eisen stelt (SLA’s, telefonie, locatiebepaling), is een validatiesurvey de snelste weg naar risicobeheersing.

Veel organisaties hanteren voor kantoor- en voice-omgevingen doelen zoals: minimale RSSI van -67 dBm, SNR ≥ 25 dB, packet loss < 1%, jitter < 30 ms, en round-trip latency < 150 ms. Cisco adviseert bij spraak expliciet deze bandbreedte van waarden voor betrouwbare prestaties [1]. Voor roaming controleer je overlap (minimaal twee AP’s ≥ -67 dBm waar nodig) en support voor 802.11k/v/r om het roamen te versnellen [1][3].
Kijk bovendien naar kanaalgebruik en interferentie: kanaalbezetting bij piek bij voorkeur < 50–60% en beperkt co-channel interference, vooral op 2,4 GHz. Waar mogelijk geef je 5 en 6 GHz voorrang voor capaciteit en minder storingen. Dit zijn geen willekeurige getallen, maar beproefde ontwerpcriteria die in validatiemetingen bevestigd moeten worden [1][2].

Een praktische aanpak: 1) Doelen en use-cases bevestigen (voice, scanners, telemetrie). 2) Surveyplan maken (looproutes, drukke tijdstippen, meethoogte). 3) Actieve en passieve metingen uitvoeren met professionele tooling (bijv. spectrum- en throughputtests). 4) Resultaten op kaart interpreteren en vergelijken met KPI’s. 5) Adviezen prioriteren op risico en impact. Zoals Ekahau samenvat: "measure, validate, and optimize" als iteratief proces [2].
Gebruik recente plattegronden en loop tijdens drukke periodes om realistische belasting te meten. Test ook roaming op kritieke paden (vergaderruimtes, gangen, lifthallen, magazijnpaden) en verifieer 802.11k/v/r en QoS-markering end-to-end [1][3].

Veel verbeteringen kun je in software oplossen: RF-profielen aanscherpen, kanalen en zendvermogens herverdelen, band steering en minimum data rates instellen, of 2,4 GHz beperken waar dit loont. Waar nodig verplaats of kantel je AP’s, voeg je capaciteit toe (extra AP’s op 5/6 GHz), of verwijder je storingsbronnen. Documenteer de wijzigingen en voer daarna een gerichte resurvey uit om te bevestigen dat KPI’s nu wél gehaald worden [2].
Voor zakelijke spraak stel je QoS in (WMM/DSCP), verifieer je dat latency/jitter binnen de norm blijft en dat de overlap voor naadloos roamen klopt. Dit sluit aan op Cisco’s aanbeveling om na implementatie te valideren en te tunen op basis van gemeten prestaties [1].

Veelgemaakte fouten zijn: alleen op RSSI sturen (en SNR, interferentie en capaciteit negeren), meten op rustige momenten, verouderde plattegronden gebruiken, of geen actieve tests doen. Ook wordt roaming vaak niet op werkelijke looproutes getest, waardoor problemen later pas opvallen. Vermijd verder handmatige kanaalkeuzes zonder spectrumcheck; automatische RF-optimalisatie kan helpen, maar valideer altijd met metingen [1][2].
Best practices: definieer acceptatiecriteria vooraf, meet tijdens piekbelasting, test kritieke applicaties (voice, VDI, scanners), verifieer 802.11k/v/r en QoS, en leg een duidelijke baseline vast voor beheer. Of zoals Cisco stelt: "validate and document post-installation performance" als sluitstuk van elk ontwerp [1].