I do a lot of work in the retail industry, where thin profits dictate if, when, and how much budget can be allocated to new technology initiatives and upgrades. I’m commonly told to “be creative” in developing a WiFi design that is repeatable, scalable, and most importantly, fiscally feasible.
Given these guiding principles, I set out to develop a WiFi design guide that ensures the budget is used strategically (when and where it is absolutely necessary), and can be implemented at scale (throughout the entire store chain). In the paragraphs below, I share my process when customizing a WiFi design guide for my retail customers.
Step 1 – Identify the devices and/or applications that are driving the design, and understand their capabilities.
Client devices vary significantly, using differing radio chipsets, antennas, and power delivery systems, as well as implementing differing WiFi capabilities. It can be a challenge obtaining all of the information that is needed in this process. After all, a device’s spec sheet only tells you what the device vendor wants you to know. To get all of the client information that I need, I gather a packet capture of when the device connects to the WLAN (specifically the association request). This allows me to see the specific capabilities that the client itself says it supports, which can include the following:
- PHY Type
- Supported Data Rates
- Transmit Power Capability
- Supported Channels
- RSN Information (encryption and authentication)
- Power Save Capability
- Quality of Service (QoS) Support
Step 2 – Learn and understand the limitations of the device(s), and the unique environmental conditions where they’ll be deployed.
Now that I know what the device is capable of, it’s time to discover where its performance will begin to break down. This is crucial since I’m designing to avoid break-downs. I do this in the following manner:
- Identify the environmental conditions of where the device will be deployed. For me, this usually falls into the following zones:
- sales floor with line-of-sight (LOS) to the AP
- sales floor with shelving and product between client device and AP (no LOS)
- stock rooms
- office areas
- outdoor areas (i.e. curbside pickup, parking lot, etc.)
- Configure the APs’ Tx power levels and supported data rates as they would be in production.
- In each of the zones listed above, identify the RSSI and/or SNR just before performance (Tx and Rx) begins to suffer.
- Gather data points from both the client device and the AP – this will help identify potential for one-way communication, as the device may be able to receive from the AP, but the AP may not be able to receive from the device (or vice-versa)
- Note the distance from the AP
- Repeat (going away from the AP in different directions) until you can consistently reproduce the data points (signal and distance)
- Repeat this process from different AP locations
- data points should be similar for each AP tested within the same zone; if not, creating a new zone may be required
- Calculate the square feet per AP coverage for each zone.
- I usually do this using Ekahau, by drawing a coverage area around the AP, based on the noted distances above
Step 3 – “Bucketize” the design requirements and determine the number of APs required.
Now that I understand the real-world limitations of the client devices that will be used, as well as the expected coverage that each AP should provide, I can now “bucketize” the expected coverage for each zone, and then determine how many APs may be required for each, resulting in something similar to the table below.
|Zone||Zone Sq Ft||Sq Ft / AP||# of APs|
|sales floor w/ LOS||50000||3000||17|
|sales floor w/o LOS||50000||2000||25|
Knowing how many APs are needed in each zone, it’s time to load up Ekahau and determine AP placement. This is also a key validation step to ensure that the predictive coverage is in line with the data that I’ve previously collected.
Step 4 – Monitor and remediate.
Since the vast majority of store locations will have their WiFi design implemented without someone actually surveying the store, it is critical to have a remediation plan. Because of the design approach, remediation will be reactionary, and determined after initial deployment, based on a period of monitoring the infrastructure and client performance. After which, I’ll know the specific store(s) that are struggling, and I can then send resources there to perform a validation survey, and then formulate a remediation plan.
From a WiFi engineering standpoint, designing in this manner has drawbacks, since it is always preferred to go onsite at each and every location and gather survey data. But, for many customers, that’s just not an option, and creativity is required. In these cases, this process has proved effective in focusing limited resources to exactly where they are needed, and has saved my customers millions of dollars along the way. It also provides them with a design plan that is relatively quick to implement and scalable across an entire chain of stores.
Comments are closed