High density Wi-Fi is a design strategy for large deployments to provide pervasive connectivity with 10 or more access points in the same space and more than 40 devices connected to any access point. To support high density wireless, Cisco Meraki access points are built with a dedicated radio for RF spectrum monitoring allowing the MR to handle the high density environments, without additional sensors or air monitors.
Large campuses with multiple floors, distributed buildings, office space, and large event spaces are now considered high density due to the number of access points and devices connecting. More extreme examples of high density environments include sports stadiums, university auditoriums, casinos, event centers, and theaters. Cisco Meraki's MR access points are used in high density environments like Friedrichstadt-Palast, the world's largest theater, and Stanford University, one of the world's largest college campuses.
As Wi-Fi continues to become ubiquitous, there is an increasing number of devices consuming an increasing amount of bandwidth. The increased need for pervasive connectivity can put additional strain on wireless deployments. Adapting to these changing needs will not always require more access points to support greater client density. As the needs for wireless connectivity have changed over time, the IEEE 802.11 wireless LAN standards have changed to adapt to greater density, from the earliest 802.11a and 802.11b standards in 1999 to the most recent 802.11ac standard, introduced in 2013.
Planning ahead for the required capacity of a Wi-Fi network is one of the first steps to a successful design. This planning helps reduce the need for further site surveys after installation and for the need to deploy additional access points over time.
In the recent past, the process to design a Wi-Fi network centered around a physical site survey to determine the fewest number of access points that would provide sufficient coverage. By evaluating survey results against a predefined minimum acceptable signal strength, the design could be evaluated as a success. While this methodology works well to design for coverage, it does not take into account requirements based on the number of clients, their capabilities, and their applications' bandwidth needs.
Calculating the number of access points necessary to meet a site's bandwidth needs is the recommended way to start a design for any wireless network with density.
Capacity planning should begin with the bandwidth requirements: how many devices will be connecting, what types of devices are they, and how much throughput is required by the applications on each device? Using this estimate, you can determine the number of access points needed to support the required capacity. The best locations for access point installation can be determined with the aid of a map of the area.
When planning for capacity it is necessary to determine the mission critical applications end clients are utilizing, especially during peak access hours. In the event of wireless medium congestion, you will want to make sure mission critical applications are given a higher priority over less important types of traffic. These mission critical applications typically include VoIP and video conferencing, video streaming, and dedicated enterprise applications, depending on the business requirements. However, each of these applications have different bandwidth requirements.
VoIP requires lower overall bandwidth (64 - 88 kbps) than that of video conferencing (512 kbps - 16 Mbps). However, wireless VoIP will typically need to take priority over video to assure that voice call quality is not degraded. VoIP requires very low latency as even a few delayed or dropped packets can lead to choppy audio easily detected by the human ear. By contrast, streaming video may be more tolerant if video content can be buffered. Streaming video may be less sensitive to network disruption than VoIP and video conferencing traffic, but it can consume an almost unlimited bandwidth. For more details on the best practices for VoIP over wireless, please read the Wireless Voice Deployment Guide.
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. By multiplying the application throughput by the number of expected concurrent users we get the total application bandwidth needed.
(Application Throughput) x (Number of Users) = Aggregate Application Throughput
3 Mbps x 600 users = 1800 Mbps
Note that 1.8 Gbps exceeds the bandwidth offerings of almost all internet service providers. The total application bandwidth we are estimating is a theoretical demand upperbound, which will be used in subsequent calculations.
The throughput an access point can provide is influenced by the client devices connecting to it. To calculate the required number of access points for a particular area, it will also be necessary to know the actual throughput required by client devices.
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
The 802.11ac standard has enabled faster higher capacity networks using wider channels and multiple streams with MIMO (multiple-input multiple-out). Wider 40 MHz channels double the capacity of the 20 MHz channels, and 80 MHz channels provide double the capacity of 40 MHz channels. With MIMO, transmitting two separate spatial streams on two antennas allows double the amount of data sent at the same time; sending three separate spatial streams on antennas triples the amount of data compared to a single stream. Devices must have multiple antennas to send multiple streams.
While Cisco Meraki access points support the fastest data rates of 802.11ac, client devices do always not 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 only a single Wi-Fi antenna inside. This design has led to slower speeds on mobile devices by limiting all of these devices to a single stream. In the chart below, you can see some common devices including the iPhone (433 Mbps), MacBook (866 Mbps), and MacBook Pro (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.
Bitrates by channel width (MHz) and number of streams
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. It is important to also reduce this value to the data rate for a 20 MHz channel width. In a high density environment, a channel width of 20 MHz is a common recommendation to reduce the number of access points using the same channel. Below are the most common data rates and the estimated device throughput (half of the advertised rate).
|Protocol||Advertised Rate (from chart above)||Estimated Throughput (½ advertised rate)|
|1 stream 802.11a or 802.11g (Legacy devices)||54 Mbps||27 Mbps|
|1 stream 802.11n or 802.11ac (iPhone, iPad)||87 Mbps||44 Mbps|
|2 stream 802.11n or 802.11ac (MacBook)||173 Mbps||87 Mbps|
|3 stream 802.11n or 802.11ac (iMac)||289 Mbps||144 Mbps|
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 iPhones instead of 600 high-end laptops, you would need 3 times the number of access points. For this example we now have the following requirements and assumptions:
We can now calculate roughly how many APs are needed to satisfy the application capacity. Round to the nearest whole number.
(Aggregate Application Throughput) / (Device Throughput) ≈ Number of Access Points
3 Mbps x 600 users / 144 Mbps = 12.5 ≈ 13 APs
Performing an active wireless site survey is a critical component of successfully deploying a high density wireless network. A site walk-through prior to the survey should give you a good idea on the layout of the floor plan, physical obstructions that could impact the RF propagation and potential access point and antenna placement options. The walkthrough should help provide visibility into any limitations that might exist in terms of ceiling heights and mounting restrictions due to aesthetics of the given place. The site walk-through should be followed up with an active site survey in order to evaluate the RF propagation in the actual physical environment. The active site survey also gives you the ability to actively transmit data and get data rate coverage in addition to the range.
In addition to verifying the RF propagation in the actual environment, it is also recommended to have a spectrum analysis done as part of the site survey in order to locate any potential sources of RF interference and take steps to remediate them. Site surveys and spectrum analysis are typically performed using professional grade toolkits such as Ekahau Site Survey or Fluke Networks Airmagnet. Ensure a minimum of 25 dB SNR throughout the desired coverage area. Remember to survey for adequate coverage on 5GHz channels, not just 2.4 GHz, to ensure there are no coverage holes or gaps. Depending on how big the space is and the number of access points deployed, there may be a need to selectively turn off some of the 2.4GHz radios on some of the access points to avoid excessive co-channel interference between all the access points.
Read our guide on Conducting Site Surveys with MR Access Points for more help on conducting an RF site survey.
The two main strategies for mounting Cisco Meraki access points are ceiling mounted and wall mounted. Each mounting solution has advantages.
Ceiling mounted MR, Cisco San Francisco
Ceiling mounted access points are placed on a ceiling tile, T-bar, roof, or conduit extending down from the roof. This brings advantages such as a clear line-of-sight to the user devices below and flexibility in where to place the access point. Access points can be easily placed with even spacing in a grid and at the intersection of hallways. The disadvantage is the ceiling height and the height of the access point could negatively impact the coverage and capacity. If access points can be installed below 26 feet (8 meters), indoor access points with integrated omni antennas are recommended.
Wall mounted MRs, Cisco San Francisco
When ceiling heights are too high or not feasible to mount access points, a wall mounted design is recommended. The access points are mounted on drywall, concrete or even metal on the exterior and interior walls of the environment. Access points are typically deployed 10-15 feet (3-5 meters) above the floor facing away from the wall. Remember to install with the LED facing down to remain visible while standing on the floor.
Pole mounted MR66 with Sector antennas, Cisco San Francisco
If there is no mounting solution to install the access point below 26 feet (8 meters), or where ceilings are replaced by the stars and the sky (outdoors), high density best practices recommend using directional antennas. When selecting a directional antenna, you should compare the vertical beam-width and gain of the antenna. Cisco Meraki offers 3 types of external antennas. When using directional antennas on a ceiling mounted access point, direct the antenna pointing straight down. When using directional antennas on a wall mounted access point, tilt the antenna at an angle to the ground. Further tilting a wall mounted antenna to pointing straight down will limit it's range. Cisco Meraki has certified the following antennas for use with the Meraki MR84, MR72, MR66, and MR62 access points:
Using 3rd party antennas with gain higher than 11 dBi on 2.4 GHz or 13 dBi on 5 GHz may violate regulations in some countries. Meraki certifies only Meraki antennas.
Once the number of access points has been established, the physical placement of the AP’s can then take place. As site survey should be performed not only to ensure adequate signal coverage in all areas, but to additionally assure spacing 25 APs onto the floorplan with minimal co-channel interference. It's very important that access points are as evenly spaced as possible.
Review the designs below from the Cisco Meraki San Francisco office. The 4th Floor was constructed to support Cisco's sales team, customer briefings, and a cafe. In contrast, the 3rd floor was constructed to support Cisco's 24x7 technical support, our small IT department, and Cisco's Collaboration group with applications such as Telepresence and Cisco Spark HD video chat. The density of the 3rd floor is double that of the 4th floor.
High density with 30 access points, Cisco San Francisco, 4th Floor
Ultra High density with 60 access points, Cisco San Francisco, 3rd Floor
Making the changes described in this section will provide a significant improvement in overall throughput by following the best practices for configuring SSIDs, IP assignment, Radio Settings, and traffic shaping rules.
The maximum recommended number of SSIDs is 5, and in a high density environment this recommendation becomes a requirement. Using more than 5 SSIDs creates substantial airtime overhead from management frames: consuming 20% or more of the bandwidth available and limiting the maximum throughput to less than 80% of the planned capacity. Create a separate SSID for each type of authentication required (Splash, PSK, EAP) and consolidate any SSIDs that use the same type authentication.
Adding several SSIDs has a negative impact on capacity and performance. See the article Multi-SSID Deployment Considerations for more detail.
A high density wireless network will work best the SSID is configured for 5 GHz band only. The 2.4 GHz band has only 3 channels that do not overlap, while the 5 GHz band has up to 19 individual channels in the US. This can be configured under Access Control > Wireless options > Band selection > '5 GHz band only'. After configuration, testing should be performed in all areas of the environment.
If the client devices require 2.4 GHz, enable 'Dual-band with band steering' to enable client devices to use both 2.4 GHz channels and 5 GHz. Devices will be steered to use the 5 GHz band. For more details refer to the Band Steering Overview article. With a dual-band network, client devices will be steered by the network.
For high density networks that can accommodate legacy 802.11b devices, 11 Mbps is recommended as the minimum bitrate. Adjusting the bitrates can reduce the overhead on the wireless network and improve roaming performance. Increasing this value requires proper coverage in the RF planning. An administrator can improve the performance of clients on the 2.4 GHz and 5 GHz band by disabling lower bitrates. This feature is configured under the Configure tab on the Access Control page on a per SSID basis. Management and Data frames will be sent out at the lowest selected rate. Clients must use either the lowest selected rate or a faster one. Selecting a Minimum bitrate of 12Mbps or greater will prevent 802.11b clients from joining.
Cisco's San Francisco office uses 18 Mbps as the Minimum bitrate.
Cisco Meraki access points feature a third radio dedicated to continuously and automatically monitoring the surrounding RF environment to maximize Wi-Fi performance even in the highest density deployment. By measuring channel utilization, signal strength, throughput, signals from non-Meraki APs, and non-WiFi interference, Cisco Meraki APs automatically optimize the radio transmit power and selected operating channels of individual APs to maximize system-wide capacity.
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. Once calculations are complete, the Cloud instructs each AP to decrease or increase the transmit power.
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. To ensure Auto Channel is enabled on a access point, navigate to Wireless > Configure > Radio settings in Dashboard and select a particular AP. The radio configuration for the Access Point will be displayed on the right hand side of the page. The Auto Channel algorithm will be used on radios that have "Auto" selected for their channel.
Cisco Meraki provides the ability to configure the MR series access points using either 20-MHz (VHT20), 40-MHz (VHT40) or 80-MHz (VHT80) channels on the 5GHz band. When deploying within a high density environment, Cisco recommends that access points be configured using 20-MHz (VHT20) channel widths for the following reasons:
The ability to manually set the Radio Channel and Transmit Power gives you more granular control over the wireless coverage in the environment. In order to minimise contention due to CCI and reduce cell sizing, the transmit power for each AP should be less than or equal to the transmit power or EIRP of the client devices. For tablets and smartphones, a starting value of 14 dBm for 5 GHz, and 11 dBm for 2.4 GHz is commonly recommended. A post deployment site survey is recommended to test these values.
Note: The 2.4GHz radio on an MR access point can have its power set to "off." This will prevent this particular unit from serving clients with its 2.4GHz radio.
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.
A wireless client will decide to roam to a new access point (AP) when it detects a better signal from that AP than the one it is currently associated with. This behavior is normal, particularly when devices are moving around within an environment, such as laptops, tablets, and mobile phones.
Client roaming between access points
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.
This feature can be enabled from the Configure > Access control page under Network access > 802.11r. If this option does not appear, a firmware update may be required.
Note: 802.11r is intended for use on SSIDs that use enterprise authentication methods.
Bridge mode is recommended to improve roaming for voice over IP clients with seamless Layer 2 roaming. In bridge mode, the Meraki APs act as bridges, allowing wireless clients to obtain their IP addresses from an upstream DHCP server. Bridge mode works well in most circumstances, provides seamless roaming with the fastest transistions. When using Bridge mode, all APs on the same floor or area should support the same VLAN to allow devices to roam seamlessly between access points.
For seamless roaming in bridge mode, the wired network should be designed to provide a single wireless VLAN across a floor plan. If the network requires a user to roam between different subnets, using Bridge mode will require a DHCP request when roaminh between two subnets or VLANs. During this time, real-time video and voice calls will noticeably drop or pause, providing a degraded user experience.
NAT mode is not recommended for Voice over IP: With NAT mode enabled, devices will request a new DHCP IP address on each roam. Moving between APs in NAT mode will cause the connection to break when moving AP to AP. Applications requiring continuous traffic streams such as VoIP, VPN or media streams will be disrupted during roaming between APs.
Large wireless networks with multiple VLANS per floor may require layer 3 roaming to enable application and session persistence while a mobile client roams across multiple VLANs. With layer 3 roaming enabled, a client device will have a consistent IP address and subnet scope as it roams across multiple APs on different VLANs/subnets.
Cisco Meraki's Layer 3 roaming is a distributed, scalable way for Access Points to establish connections with each other without the need for a controller or concentrator. The first access point that a device connects to will become the anchor Access Point. The anchor access point informs all of the other Cisco Meraki access points within the network that it is the anchor for a particular client. Every subsequent roam to another access point will place the device/user on the VLAN that defined by the anchor AP. This is ideal for high density environments that require Layer 3 roaming, and there is no throughput limitation on the network.
The MR continues to support Layer 3 roaming to a concentrator requires an MX security appliance or VM concentrator to act as the mobility concentrator. Clients are tunneled to a specified VLAN at the concentrator, and all data traffic on that VLAN is now routed from the MR to the MX. The concentrator creates a choke-point, and in a high density environment, the number of clients may be limited by the throughput of the MX concentrator.
If Layer 3 roaming is required on the network, please refer to our article on Layer 3 Roaming.
Consider placing a per-client bandwidth limit on all network traffic. Prioritizing applications such as voice and video will have a greater impact if all other applications are limited. For more details refer to the article Configuring Bandwidth Limitations and Enabling Speed Burst on Wireless Networks. 5 Mbps is a good recommendation for per-client bandwidth limit in high density environment. You can override this limit for specific devices and applications.
SpeedBurst enables a bursts of four times the allotted bandwidth limit for five seconds.
Use traffic shaping to offer application traffic the necessary bandwidth. It is important to ensure that the application has enough bandwidth as estimated in the capacity planning section. Traffic shaping rules can be implemented to allow real-time voice and video traffic to use additional bandwidth, and the rules can be used to block or throttle applications such as P2P, social networks.
Cisco Meraki APs automatically perform a multicast-to-unicast packet conversion using the IGMP protocol, ensuring high quality video transmission to large numbers of clients. This can be especially valuables in instances such as classrooms, where multiple students may be watching high-definition video as part a classroom learning experience.
Virtual Local Area Networks (VLANs) allow a single physical Ethernet network to appear to be multiple logical networks. There are a couple of reasons to use VLANs, including:
Cisco Meraki APs use tag-based VLANs to identify traffic. When the switch/router sees VLAN-tagged traffic from a MR access point, it can apply different policies to that traffic, including access control (e.g., send traffic straight to the firewall for Internet-only access) or QoS (e.g., prioritize traffic on the VOIP SSID).
In a high-density environment, determining a suitable subnet size and allocating sufficient dynamic IP addresses is key to providing a positive user experience. To calculate the approximate number of IP addresses needed, multiple the number of users by 3 devices per user. We can expect at least 2 devices per user (laptop and mobile device), and need to allow for future growth.
(Number of Users) x (3 Devices per User) = Number of IP Addresses
Select a network class that is larger than the total number of wireless IP addresses. Class A networks are the largest and most common for a large organization. If you use a Class C network you will be limited to just 254 IP addresses. A common problem with a Class C network is running out of IP addresses to assign. In most cases a Class A or Class B should be used for the wireless network.
|Class||Bits||Addresses||Networks||Subnet Mask||Address Range|
|A||/8||16,777,214||10.0.0.0||255.0.0.0||10.0.0.0 - 10.255.255.255|
|B||/16||65,534||172.16.0.0 - 172.31.0.0||255.240.0.0||172.16.0.0 - 172.31.255.255|
|C||/24||254||192.168.0.0||255.255.0.0||192.168.0.0 - 192.168.255.255|
Example: Cisco has around 75,000 employees and requires 225,000 IP addresses for all wireless networks across all sites. Cisco needs more than 65,534 address, and requires a Class A network. Cisco's San Francisco office has 1,100 employees and requires 3,300 IP addresses for the wireless VLAN in the San Francisco office.
Within the Class A or Class B network, define subnets for each Wireless VLAN. Cisco recommends to create a wireless VLAN(s) separate from the wired VLAN(s). To segregate wireless users into different access categories, organizations typically divide the subnet for wireless into several VLANs. When dividing into smaller subnets, follow the same estimate of the IPs required. A typical VLAN configuration might break up a physical LAN by department (e.g., Engineering, HR, Marketing) or by user class (Employee, Guest).
VLANs can be assigned by SSID, by AP Tag, by user, or by device type.
Example: Cisco's San Francisco office uses 4 wireless VLANs: Cisco Corporate, Meraki Corporate, Meraki Engineering, and Guest
Select a subnet size for each wireless VLAN that is larger than the estimate of the number of wireless IP addresses expected on the VLAN. The wireless VLAN should be no larger than a Class B network or /16 and no smaller than a Class C network or /24. Cisco's San Francisco office is estimated at 3,300 IPs, and requires at least a /20 subnet with 4094 IPs for it's wireless VLANs.
|Network Bits||Subnet Mask||Number of Subnets||Addresses|
|/16 (Class B)||255.255.0.0||0||65534|
|/24 (Class C)||255.255.255.0||256 (254)||254|
Example: Cisco San Francisco's wireless network uses a /22 network for the 4th floor, and a /22 network for the 3rd floor. Roaming between floors is not a concern.
DHCP servers should be configured with shorter lease times in high-density environments. This is to ensure that IP addresses are not unnecessarily used up outside the time frame of the event. A good rule of thumb is to set the lease time at twice the duration of the typical event or shift.
DHCP servers should be located on site, and SSID’s should be set to bridged mode to ensure assignments are carried out as quickly as possible. The transaction time for the DHCP discover-offer-request-ack sequence should be 2 milliseconds or less to maintain a fast connection time.
To assign VLANs, first enable VLAN tagging on the SSID under Wireless > Access Control > Addressing and traffic > VLAN tagging. VLAN tagging can be assigned automatically by SSID, AP tag, RADIUS override, Group Policy, Policy by device type, or using Systems Manager.
VLAN by AP Tag - Using Tags to Broadcast SSIDs from Specific APs
RADIUS override - Tagging Client VLANs with RADIUS Attributes
Group Policy - Using RADIUS Attributes to Apply Group Policies
Device Type - Applying Policies by Device Type
Systems Manager - Applying Group Policies to Systems Manager (MDM) Devices using Tags
Example: Cisco's corporate wireless network uses AP tags to assign VLANs to the 3rd Floor and 4th Floor.