High Density Wi-Fi Deployments

Estimate Aggregate Application Throughput

Usually there is a primary application that is driving the need for connectivity. Understanding the throughput requirements for this application and any other activities on the network will provide will provide a per-user bandwidth goal. This required per-user bandwidth will be used to drive further design decisions. Throughput requirements for some popular applications is as given below:

Once the required bandwidth throughput per connection and application is known, this number can be used to determine the aggregate bandwidth required in the WLAN coverage area. It is recommended to have an aggregate throughput for different areas such as classrooms, lobby, auditorium, etc. as the requirements for these areas might be different.

As an example, we will design a high-density Wi-Fi network to support HD video streaming that requires 3 Mbps of throughput. Based on the capacity of the auditorium, there may be up to 600 users watching the HD video stream. The aggregate application throughput can be calculated using the below given formula:

(Application Throughput) x (Number of concurrent Users) = Aggregate Application Throughput

3 Mbps x 600 users = 1800 Mbps 

Estimate Device Throughput

While Meraki APs support the latest technologies and can support maximum data rates defined as per the standards, average device throughput available often dictated by the other factors such as client capabilities, simultaneous clients per AP, technologies to be supported, bandwidth, etc.

Client capabilities have a significant impact on throughput as a client supporting only legacy rates will have lower throughput as compared to a client supporting newer technologies. Additionally, bands supported by the client may also have some impact on the throughput. Meraki APs have band steering feature that can be enabled to steer dual band clients to 5 GHz.

In certain cases, having dedicated SSID for each band is also recommended to better manage client distribution across bands and also removes the possibility of any compatibility issues that may arise.

To assess client throughput requirements, survey client devices and determine their wireless capabilities. It is important to identify the supported wireless bands (2.4 GHz vs 5 GHz), supported wireless standards (802.11a/b/g/n/ac), and the number of spatial streams each device supports. Since it isn’t always possible to find the supported data rates of a client device through its documentation, the Client details page on Dashboard can be used as an easy way to determine capabilities.

Example Client details listing

Wi-Fi is based on CSMA/CA and is half-duplex. That means only one device can talk at a time while the other devices connected to the same AP wait to for their turn to access the channel. Hence, simultaneous client count also has an impact on AP throughput as the available spectrum is divided among all clients connected to the AP. While Meraki has client balancing feature to ensure clients are evenly distributed across AP in an area an expected client count per AP should be known for capacity planning.

Note: In order to ensure quality of experience it is recommended to have around 25 clients per radio or 50 clients per AP in high-density deployments.

Starting 802.11n, channel bonding is available to increase throughput available to clients but as a result of channel bonding the number of unique available channels for APs also reduces. Due to the reduced channel availability, co-channel interference can increase for bigger deployments as channel reuse is impacted causing a negative impact on overall throughput.

Client devices don’t always support the fastest data rates. Device vendors have different implementations of the 802.11ac standard. To increase battery life and reduce size, most smartphone and tablets are often designed with one (most common) or two (most new devices) Wi-Fi antennas inside. This design has led to slower speeds on mobile devices by limiting all of these devices to a lower stream than supported by the standard. In the chart below, you can see the maximum data rates for single stream (433 Mbps), two stream (866 Mbps), and three stream (1300 Mbps). No devices on the market today support 4 spatial streams or wider 160 MHz channels, but these are often advertised as optional "Wave 2" features of the 802.11ac standard.

The actual device throughput is what matters to the end user, and this differs from the data rates. Data rates represent the rate at which data packets will be carried over the medium. Packets contain a certain amount of overhead that is required to address and control the packets. The actual throughput is payload data without the overhead. Based on the advertised data rate, next estimate the wireless throughput capability of the client devices. A common estimate of a device's actual throughput is about half of the data rate as advertised by its manufacturer. As noted above, it is important to also reduce this value to the data rate for a 20 MHz channel width. Below are the most common data rates and the estimated device throughput (half of the advertised rate). Given the multiple factors affecting performance it is a good practice to reduce the throughput further by 30%

Estimate the Number of APs

It's important to document and review the requirements and assumptions and confirm they are reasonable. Changing one assumption will significantly impact the number of access points and the costs. If you assumed just 1.5 Mbps for HD video chat (as recommended by Microsoft Skype and Cisco Spark) you would need half the number of access points. If you assumed 5 Mbps was required for HD video streaming (as recommended by Netflix) you would need more access points. If you were designing to support 600 1 stream devices instead of 600 3 stream laptops, you would need roughly 3 times the number of access points. For this example, we now have the following requirements and assumptions:

• Video streaming requires 3 Mbps for HD quality video

• There will be 600 concurrent users streaming video to their laptop

• Every user has an Apple MacBook Pro or similar

• All laptops support 802.11ac and are capable of 3 spatial streams

• The network will be configured to use 20 MHz channels

• Each access point can provide up to 101 Mbps of wireless throughput

We can now calculate roughly how many APs are needed to satisfy the application capacity. Round to the nearest whole number.

 Number of Access Points based on throughput = (Aggregate Application Throughput) / (Device Throughput)

Number of Access Points based on throughput = 1800 Mbps/101Mbps = ~18 APs

In addition to the number of APs based on throughput, it is also important to calculate the number of APs based on clients count. To determine number of APs, first step is to estimate the clients per band. With newer technologies, more devices now support dual band operation and hence using proprietary implementation noted above devices can be steered to 5 GHz.

Note: A common design strategy is to do a 30/70 split between 2.4 GHz and 5 GHz     

For this example, we now have the following requirements and assumptions:

• There will be 600 concurrent users streaming video to their laptop

• Concurrent 2.4 GHz clients = 600 * 0.3 = 180

• Concurrent 5 GHz clients = 600 * 0.7 = 420

We can now calculate roughly how many APs are needed to satisfy the client count. Round to the nearest whole number.

Number of Access Points based on client count = (Concurrent 5 GHz clients) / 25

Number of Access Points based on client count = 420 / 25 = ~17 APs

Now the Number of APs required can be calculated by using the higher of the two AP counts.

Number of Access Points = Max (Number of Access Points based on throughput, Number of Access Points based on client count)

Number of Access Points = Max (18,17) = 18 APs

Auto Power Reduction

Every second the access point's radios samples the signal-to-noise (SNR) of neighboring access points. The SNR readings are compiled into neighbor reports which are sent to the Meraki Cloud for processing. The Cloud aggregates neighbor reports from each AP. Using the aggregated data, the Cloud can determine each AP's direct neighbors and how by much each AP should adjust its radio transmit power so coverage cells are optimized. For determining the changes in TX power the cloud tries to ensure that there are at least 3 heard by each  in the area. The calculations are done every 20 minutes and once complete, the Cloud instructs each AP to decrease or increase the transmit power.TX power can be reduced by 1-3 dB per iteration and is increased in 1 dB iterations.

AutoRF tries to reduce the TX power uniformly for all APs within a network but in complex high density network it is necessary to limit the range and the values for the AP to use. To better support complex environments, minimum and maximum TX power settings can be configured in RF profiles.

Auto Channel selection

Adding additional access points on the same channel with overlapping coverage does not increase capacity. To prevent access points nearby from sharing the same channel, Cisco Meraki access points automatically adjusts the channels of the radios to avoid RF interference (Both 802.11 and non-802.11) and develop a channel plan for the Wireless Network. Channels can be selectively assigned to be used with each RF profile. By using channels selectively, network administrators can control the co-channel interference more effectively.

Default Channel Width

• In moving towards 40-Mhz or 80-Mhz channels, you are effectively halving (if selecting 40-MHz) or quartering (80-MHz) the number of non-overlapping 5GHz channels by doubling or quadrupling the channel width due to channel bonding. This, in turn, increases the distance at which access points must be placed if co-channel interference (CCI) and adjacent channel interference (ACI) are to be kept to a minimum.

• While using 40-MHz or 80-Mhz channels might seem like an attractive way to increase overall throughput, one of the consequences is reduced spectral efficiency due to legacy (20-MHz only) clients not being able to take advantage of the wider channel width resulting in the idle spectrum on wider channels. Depending on the RF environment, even clients capable of 40 and 80 MHz may only use the 20 MHz base channel and is often observed in highly contentious RF environments.  

• Due to the mix of clients usually seen in high-density deployments (such as laptops, mobile phones, and tablets etc.) the capabilities of clients in such environments also vary (some will support 20-Mhz, some will support 40-MHz and some will support 80-Mhz channels). Due to this, it is better to have each client communicating at the lowest common channel width, giving each client equal access to the network. It is better to have 4 clients communication at 20-MHz with 4 access points, rather than 4 clients of mixed capability communicating with 1 access points at 80-MHz resulting in idle.

DFS Channels and Channel Reuse

For an example deployment with DFS channels enabled and channel reuse is not required, the below grid shows 12 access points with no channel reuse. As there are 19 channels in the US, when you reach 20 access points in the same space, the APs will need to reuse a channel.

For a deployment example where DFS is disabled and channel reuse is required, the below diagram shows 4 channels being reused in the same space. When channel reuse cannot be avoided, the best practice is to separate the access points on the same channel as much as possible.

RX-SOP

Client Balancing

Roaming in High Density

Client roaming between access points

Enable Fast Roaming

Cisco Meraki MR access points support a wide array of fast roaming technologies.  For a high-density network, roaming will occur more often, and fast roaming is important to reduce the latency of applications while roaming between access points. All of these features are enabled by default, except for 802.11r. 

• 802.11r (Fast BSS Transition) - 802.11r allows encryption keys to be stored on all of the APs in a network. This way, a client doesn't need to perform the full re-authentication process to a RADIUS server every time it roams to a new access point within the network. This feature can be enabled from the Configure > Access control page under Security > 802.11r. If this option does not appear, a firmware update may be required. 
• Opportunistic Key Caching (OKC) - 802.11r and OKC accomplish the same goal of reducing roaming time for clients, the key difference being that 802.11r is standard while OKC is proprietary. Client support for both of these protocols will vary but generally, most mobile phones will offer support for both 802.11r and OKC. 
• 802.11i (PMKID caching) - PMK Caching, defined by IEEE 802.11i, is used to increase roaming performance with 802.1X by eliminating the RADIUS exchange that occurs. From a high-level perspective, this occurs by the client sending a PMKID to the AP which has that PMKID stored. If it’s a match the AP knows that the client has previously been through 802.1X authentication and may skip that exchange.  
• 802.11k (Neighbor BSS) -802.11k reduces the time required to roam by allowing the client to more quickly determine which AP it should roam to next and how. The AP the client is currently connected to will provide it with information regarding neighboring APs and their channels.