Survey For Your WiFi Clients

When designing WiFi networks, a crucial part of the design process is the wireless survey. This may be a traditional ‘AP on a stick’ survey or may be an off-site, ‘desktop’, predictive survey. In amongst the variety of variables that need to be considered, including coverage and capacity, there is one crucial item that is easy to forget: how does the designed wireless network look from the point of view WiFi clients that will actually use the network?


Best practice for wireless surveying usually dictates that prior to completing a survey for a new WiFi deployment design, a pre-survey questionnaire will be supplied to your customer. This document will ask about the environment that the network is to be deployed into. It will include information such as physical building characteristics, cabling and switch infrastructure, health and safety considerations, access arrangements etc.  

In addition, the pre-survey questionnaire will also request information from the customer about the requirements of the new network to be installed. This will generally include information such as coverage requirements, capacity requirements, service requirements (e.g. voice, data, RTLS) and information about the types of wireless client to be used on the new WiFi network.

When considering the network requirements, many WiFi manufacturers are able to provide some very good guidelines around the design parameters to be used for a network. A classic approach is to design a voice-grade network which uses cell edges around -67dBm and a consistent SNR (Signal to Noise Ratio) of 25dB. There are also considerations around level of cell overlap, but these are a little less well defined and subject to debate about how to actually define/measure them. For ease of demonstration, we’ll go with a very simple -67dBm/25dB approach in our examples.

Performing the Survey

Now that we have a set of defined design criteria, we can press ahead with performing our design survey. In this case, I've chosen an example which shows data from a limited area of a building that was actually a partially complete test survey. The example itself does not stand up to close scrutiny in terms of best practice design, but serves to emphasize the point I am raising in this article.

The graphic below shows how part of the building has been surveyed by walking throughout the rooms in the coverage area. The survey has been performed with Ekahau’s Site Survey package.The walk-paths can be seen (green lines) , together with the placement of the access points (green dots). In addition, the overlaid heatmap shows the coverage of our -67dBm cell edge boundary, with the colouration showing the RF signal level variations. Areas with white-space are outside of our -67dBm threshold and outside of our design criteria (i.e. they are out of spec and need to be fixed). We can see a couple of areas of white-space in the middle of the graphic where we maybe need to place another AP to fill the coverage holes.

If we also take a look at our second design criteria, SNR, the graphic below shows the SNR over the same area, down to our threshold of 25dBm. Again, we've got some white-space in the middle of the graphic and really do need to think about placing an AP in that area to get this design back in-spec.

Once we’ve inserted another AP, we’ve almost certainly fixed our issue and we can put this design to bed - or can we? Although we may have measured the signal levels and SNR thresholds (using a professional surveying tool) and have them within specification, is this network really going to meet the requirements defined by the customer?

It’s All About the Clients

When designing a WiFi network, you have to consider how the network is going to look from the point of view of your WiFi clients - all of your clients. Clients come in a very wide variety of shapes, sizes and capabilities. Some may have good quality RF hardware and decent gain antennas, ensuring that they will have few issues in a reasonably well designed network. They should easily hear our deployed APs and achieve SNR levels that ensure low error rates and good throughput.

However, other clients may have miniscule, poorly designed antennas, with low-cost, low quality RF circuitry. Their antennas may often be in a housing partially made of metal (great for RF eh…?). They may have limited power available due to the power demands of a smartphone handset on a very limited battery. The explosion of mobile devices such as tablets and smartphone means that the majority of clients on a network may suffer these limitations . With the proliferation of these ‘less able’ clients, it is often best to be pessimistic about client capabilities when designing a wireless network and design for your ‘worst’ clients.

If we return to our original survey, we need to take a step back and think about the survey we performed. What were we measuring? Were signal levels and SNR actually measured with a smartphone or tablet? The answer is: no. We were actually measuring (in all likelihood) using a laptop with a USB wireless dongle that has very good RF capabilities. Will this survey 'client' see the network in the same way as a less capable tablet or smartphone? (The answer is no, by the way…)

An Alternative Point of View

In order to understand if this network is going to meet the design criteria laid down, we need to look at the survey data gathered from the point of view of the clients that will be using the network. As mentioned previously, we have to assume the worst, and design for our less able clients.

Fortunately, Ekahau SS provides a very nice feature that allows us to look at our survey data as it might look if it had been gathered by a different type of client. Remember, we have gathered this data using a laptop with a reasonable-gain antenna with good quality RF circuitry. What might this data look like if it has been gathered with a tablet device (perhaps an iPad?).

Ekahau SS considers the original, unfiltered data gathered by the USB dongle antenna to be “raw” measurements. If we take a look under the ‘Options’ button of the ESS display pane, we see a drop-down selection box labelled “Adapter”. By default, the adapter setting is “Raw Measurements” - this means we are seeing the RF data in the same way as the wireless NIC that gathered that data (see graphic below).

If we modify the adapter setting to something other than “Raw Measurements”, we can see how the RF survey data may look through the eyes of another type of wireless client. A whole variety of clients types are available including smartphones, Cisco phones, tablets and many others. For our example, we’ll take a look at our data through the eyes of a tablet device:

Back to the Drawing Board

The graphic below shows how our RF signal coverage may look from the point of view of a tablet device. Note that we still have the same cell edge limit of -67dBm - the only thing that has changed is the client viewing this data:

Unfortunately, we now see huge holes in our coverage. We simply cannot meet the design criteria for our agreed cell edges for tablet devices in this network. We would certainly have to look at adding in more access points, repositioning APs and perhaps winding up our AP transmit powers.Whichever way you look at it, we need to head back to the drawing board on this one if we want to provide ubiquitous coverage at the agreed design signal levels for all device types.

We’ve looked solely at RF signal levels in this example, but there are other considerations that also need to be considered.These include factors such as client transmit power, client sensitivity and the varying CCI view of each client type. The key takeaway from this is that client capabilities need to factored in to design considerations - a survey using raw measurements is generally an invalid approach on today’s “support everything” networks.

One final note is to use the adapter simulation setting within ESS with caution, It should only be used as a guide to how coverage may look. There is no substitute to verifying the data with an actual client device where possible.


In summary, we’ve taken a look at how we need to define design criteria for the type of wireless network that will meet customer requirements. We looked at a simplified voice-grade survey using cell edges of -67dBm and SNR of 25dB.

Although we may be able to measure the design criteria using a professional survey tool, we need to be mindful of how the measurements are collected. Survey data gathered with a high-spec wireless NIC is generally going to see RF signals at higher levels than a lower spec mobile device.

When considering how effective our design will be in meeting the design criteria, we have to consider how the gathered RF data will look from the point of view of a actual clients that will use the network. Only then can we be sure of whether we can meet the design criteria and the customers’ requirements.


As mentioned in the article, here are couple of sample vendor design guides to have a look at (there are plenty of others out there too):

Popular posts from this blog

The 5GHz “Problem” For Wi-Fi Networks: DFS

Microsoft NPS as a RADIUS Server for WiFi Networks: Self Signed Certificate

Microsoft NPS as a RADIUS Server for WiFi Networks: Dynamic VLAN Assignment