Home > Architectures and Best Practices > Cisco Meraki Best Practice Design > Best Practice Design - MR Wireless

Best Practice Design - MR Wireless

Table of contents
  1. High Density Wi-Fi Deployments
    1. Planning
      1. Capacity Planning
        1. Estimate Aggregate Application Throughput
        2. Estimate Device Throughput
        3. Estimate the Number of APs
    2. Site Survey and Design
      1. Mounting Access Points
      2. Directional Antennas
      3. Access Point Placement
    3. SSID Configuration
      1. Number of SSIDs 
      2. Enable Bridge Mode
      3. Layer 3 Roaming
    4. Radio Settings & Auto RF
      1. Band Selection
      2. Set Minimum Bitrate
      3. Auto Power Reduction
      4. Auto Channel selection
      5. Default Channel Width
      6. DFS Channels and Channel Reuse
      7. RX-SOP
      8. Client Balancing
      9. Roaming in High Density
      10. Enable Fast Roaming
    5. Traffic Shaping
      1. Set Bandwidth Limits 
      2. Define Traffic Shaping Rules
      3. Convert Multicast to Unicast
      4. Limit Broadcasts 
      5. Airtime Fairness 
  2. Wireless Layer 3 Roaming Best Practices
    1. Typical Campus Architecture 
    2. Distributed Layer 3 Roaming
    3. Broadcast Domain Mapping
    4. Broadcast Domain Discovery
    5. Roaming with Broadcast Domains
    6. VLAN Testing and Dynamic Configuration
    7. Tunneling
    8. Design Example
    9. Concentrator-Based Layer 3 Roaming
  3. Wireless VoIP QoS Best Practices
    1. Measuring Voice Quality 
      1. Voice Quality Before this Guide
      2. Voice Quality After this Guide
    2. Wireless Voice Best Practices
      1. Summary of 802.11 Standards
    3. Pre-Install Survey
    4. Network Configuration
      1. Add a Dedicated Voice SSID 
      2. Authentication Type
      3. WPA2 only for Encryption Mode
      4. 802.11r fast roaming
      5. Layer 2 and Layer 3 Roaming 
      6. Segregate Traffic on a Voice VLAN 
      7. Band Selection
      8. Minimum Bitrate
      9. Bandwidth Limits
      10. Traffic Shaping Rules
      11. PCP, DSCP, and WMM mapping
      12. Custom Traffic Shaping 
    5. Product Specific Recommendations
      1. Microsoft Lync / Skype for Business
      2. Cisco 7925G Phones
      3. Apple iPhones
      4. Vocera Badges
      5. WiFi Calling
    6. Service Provider WiFi 
      1. Hotspot 2.0
    7. Troubleshooting VoIP

High Density Wi-Fi Deployments

High-density Wi-Fi is a design strategy for large deployments to provide pervasive connectivity to clients when a high number of clients are expected to connect to Access Points within a small space. A location can be classified as high density if more than 30 clients are connecting to an AP. To better 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. Unless additional sensors or air monitors are added, access points without this dedicated radio have to use proprietary methods for opportunistic scans to better gauge the RF environment and may result in suboptimal performance.

 

Large campuses with multiple floors, distributed buildings, office spaces, and large event spaces are 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.

 

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 and the new 802.11ax standard currently being developed.

Planning

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 would be considered 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.

 

Understanding the requirements for the high density design is the first step and helps ensure 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. It is recommended to have the following details before moving onto the next steps in the design process:

  • Type of applications expected on the network

  • Supported technologies (802.11 a/b/g/n/ac)

  • Type of clients to be supported (Number of spatial streams, technologies, etc.)

  • Areas to be covered

  • Expected number of simultaneous devices in each area

  • Aesthetic requirements (if any)

  • Cabling constraints (if any)

  • Power constraints (It’s best to have PoE+ capable infrastructure to support high performance APs)

Capacity Planning

Once the above mentioned details are available, capacity planning can then be broken down into the following phases:

  • Estimate Aggregate Application Throughput

  • Estimate Device Throughput

  • Estimate Number of APs

Calculating the number of access points necessary to meet a site's bandwidth needs is the recommended way to start a design for any high density wireless network.

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:

Application

Throughput

Web Browsing

500 kbps (kilobits)

VoIP

16 - 320 kbps

Video conferencing

1.5 Mbps

Streaming - Audio

128 - 320 kbps

Streaming - Video

768 kbps

Streaming - Video HD

768 kbps - 8mbps

Streaming - 4K

8 mbps - 20mbps

Note: In all cases, it is highly advisable to test the target application and validate its actual bandwidth requirements. It is also important to validate applications on a representative sample of the devices that are to be supported in the WLAN. Additionally, not all browsers and operating systems enjoy the same efficiencies, and an application that runs fine in 100 kilobits per second (Kbps) on a Windows laptop with Microsoft Internet Explorer or Firefox, may require more bandwidth when being viewed on a smartphone or tablet with an embedded browser and operating system

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 

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 upper bound, which will be used in subsequent calculations.

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.

Note: A client supporting only 2.4 GHz might have lower throughput as compared to a dual band client since higher noise level is expected on the 2.4GHz as compared to 5 GHz and the client might negotiate lower data rate on 2.4GHz.

 

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.

Note: The option to have 2.4GHz only SSID is disabled by default. Please contact Meraki support to enable this feature.

 

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.png

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.

Note: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.

 

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.

 

Streams

20 MHz Channel Width

40 MHz Channel Width

80 MHz Channel Width

1 Stream

87 Mbps

200 Mbps

433 Mbps

2 Streams

173 Mbps

400Mbps

866 Mbps

3 Streams

289 Mbps

600 Mbps

1300 Mbps

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%

 

Protocol

Data rate (Mbps)

Estimated Throughput (1/2 advertised rate)

Throughput w/Overhead

802.11a or 802.11g

54 Mbps

27 Mbps

~19 Mbps

1 stream 802.11n

72 Mbps

36 Mbps

~25 Mbps

2 stream 802.11n

144 Mbps

72 Mbps

~50 Mbps

3 stream 802.11n

216 Mbps

108 Mbps

~76 Mbps

1 stream 802.11ac

87 Mbps

44 Mbps

~31 Mbps

2 stream 802.11ac

173 Mbps

87 Mbps

~61 Mbps

3 stream 802.11ac

289 Mbps

144 Mbps

~101 Mbps

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

Site Survey and Design

Performing an active wireless site survey is a critical component of successfully deploying a high-density wireless network and helps 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.

Note: It is recommended to have complete coverage for both bands.

Note: Read our guide on Conducting Site Surveys with MR Access Points for more help on conducting an RF site survey.

Mounting Access Points

The two main strategies for mounting Cisco Meraki access points are ceiling mounted and wall mounted. Each mounting solution has advantages.

 

ceiling_mounted_mr.png

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 have to be installed below 8 feet (~3 meters), indoor access points with integrated omni antennas or external dipole/can omni antennas are recommended.

  • If access points have to be installed between 8 - 25 feet (3 - 8 meters), indoor access points with external downtilt omni antennas are recommended.

 

wall_mounted.png

Wall mounted MRs, Cisco San Francisco

 

When ceiling heights are too high (25+ feet) or not feasible to mount access points (hard ceiling), 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. Designing a network with wall mounted omnidirectional APs should be done carefully and should be done only if using directional antennas is not an option. 

 

pole_mounted.jpg

Pole mounted MR66 with Sector antennas, Cisco San Francisco

Directional Antennas

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), or if directional coverage is needed it is recommend to use directional antennas. When selecting a directional antenna, you should compare the horizontal/vertical beam-width and gain of the antenna.

 

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 its range.

 

Cisco Meraki offers 6 types of indoor-rated external antennas (available for MR42E and MR53E):

 

antennae1.png

 

Note: C/D/E/F series Meraki antennas are smart and are automatically detected when connected to the Meraki APs and don’t need additional configuration within dashboard.

 

Cisco Meraki offers 4 types of outdoor external antennas and supports 5 types of outdoor antennas. Cisco Meraki has certified the antennas for use with the Meraki MR84, MR74, MR72, MR66, and MR62 access points. AIR-ANT2514-P4M can only be used with MR84: 

 

antennae2.png

 

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.

Access Point Placement

Once the number of access points has been established, the physical placement of the AP’s can then take place. A site survey should be performed not only to ensure adequate signal coverage in all areas but to additionally assure proper spacing of APs onto the floorplan with minimal co-channel interference and proper cell overlap. It’s very important to consider the RF environment and construction materials used for AP placement.

 

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.

floorplan30.png

High density with 30 access points, Cisco San Francisco, 4th Floor

                   

 

floorplan60.png

Ultra High density with 60 access points, Cisco San Francisco, 3rd Floor

SSID Configuration

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.

Number of SSIDs 

The maximum recommended number of SSIDs is 3, and in a high-density environment, this recommendation becomes a requirement. If needed, the number of SSIDs can be increased to 5 but should be done only when necessary.  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.  

Enable Bridge Mode

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 transitions. When using Bridge mode, all APs in the intended area (usually a floor or set of APs in an RF Profile) 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 L3 roaming is recommended. Bridge mode will require a DHCP request when roaming 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. 

Layer 3 Roaming

Large wireless networks that need roaming across multiple VLANs may require layer 3 roaming to enable application and session persistence while a mobile client roams. 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.

Radio Settings & Auto RF

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.

 

Additionally, it is recommend to use RF profiles to better tune the wireless network to support the performance requirements. A separate RF profile should be created for each area that needs unique set of RF settings. The following details can be set in the RF Profiles:

Band Selection

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. If 2.4 GHz support is not needed, it is recommended to use “5 GHz band only”. Testing should be performed in all areas of the environment to ensure there are no coverage holes.

 

band_selection.png

Set Minimum Bitrate

Using RF Profiles, minimum bit rate can be set on a per band or a per SSID basis. For high-density networks, it is recommended to use minimum bit rates per band. If legacy 802.11b devices need to be supported on the wireless network, 11 Mbps is recommended as the minimum bitrate on 2.4 GHz. Adjusting the bitrates can reduce the overhead on the wireless network and improve roaming performance. Increasing this value requires proper coverage and RF planning. An administrator can improve the performance of clients on the 2.4 GHz and 5 GHz band by disabling lower bitrates. Management 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 and will increase the efficiency of the RF environment by sending broadcast frames at a higher bitrate.

Note: As per standards, 6 Mbps, 12 Mbps and 24 Mbps are the mandatory data rates. Cisco's San Francisco office uses 18 Mbps as the Minimum bitrate.

 

bitrate.png

 

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.

 

Note: For 2.4 GHz, Auto Power reduction algorithm allows TX power to go down only up to 5 dBm. For 5 GHz, Auto Power reduction algorithm allows TX power to go down only up to 8 dBm. If lower TX power is needed, APs can be statically set to lower power.

 

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.

 

auto_channel.png

 

Default Channel Width
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, it is recommended that access points be configured using 20-MHz (VHT20) channel widths for the following reasons:
  • 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
UNII-2/2e band has additional channels that can be used for WLAN but overlap with radar applications and are commonly referred as DFS channels. Cisco Meraki APs support 802.11h that provide two key features: Dynamic Frequency Selection (DFS) and Transmit Power Control (TPC). By using these features customers can use the additional DFS channels thereby bringing the total available 5 GHz channels to 19. Using 19 channels increases the channel reuse to ensure better CCI.
Note: Channel reuse is the process of using the same channel on APs within a geographic area that are separated by sufficient distance to cause minimal interference with each other.
 

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.

 

DFS1.png

 

 

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.

 

DFS2.png

 

RX-SOP
Using RX-SOP, the receive sensitivity of the AP can be controlled. The higher the RX-SOP level, the less sensitive the radio is and the smaller the receiver cell size will be. The reduction in cell size ensures that the clients are connected to the nearest access point using the highest possible data rates. In a high density environment, the smaller the cell size, the better. This should be used with caution however as you can create coverage area issues if this is set too high. It is best to test/validate a site with varying types of clients prior to implementing RX-SOP in production.
 
RX-SOP.png
 
 
The table below gives the recommended values for RX-SOP in high density deployments:

802.11 Band

High Threshold

Medium Threshold

Low Threshold

5 GHz

-76 dBm

-78 dBm

-80 dBm

2.4 GHz

-79 dBm

-82 dBm

-85 dBm

Note: RX-SOP is available only on Meraki 802.11 ac Wave 2 APs (MR30H/33/42/42E52/3/53E/74/84)

Client Balancing
Client balancing is recommended for high density applications as the feature tries to balance the number of users across APs. The feature is available starting MR25 firmware version and is enabled by default.
Roaming in High Density

 

client_roaming.png

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 Network access > 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.

Traffic Shaping

Set Bandwidth Limits 

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.

Note: this is not limiting the wireless data rate of the client but the actual bandwidth as the traffic is bridged to the wired infrastructure.

  1. Go to Wireless > Configure > Firewall & traffic shaping and choose the SSID from the SSID drop-down menu at the top of the screen.
  2. Set a 'Per-client bandwidth limit' to 5 Mbps with 'Speed Burst'. This will apply to all non-voice application traffic. This step in the guide is optional. 
  3. Set a 'Per-SSID bandwidth limit' to unlimited.

 

traffic_shaping_rules.png

 

SpeedBurst enables a bursts of four times the allotted bandwidth limit for five seconds.  

Define Traffic Shaping Rules

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. 

  1. Go to Wireless > Configure > Firewall & traffic shaping and choose the SSID from the SSID drop-down menu at the top of the screen.
  2. Click the drop down menu next to Shape traffic and choose Shape traffic on this SSID, then click Create a new rule.
  3. Click Add + and select 'All voice & video conferencing
  4. Set Per-client bandwidth limit to 'Ignore SSID per-client limit (unlimited)' and click Save changes.

 

traffic_shaping_definitions.png

Convert Multicast to Unicast

Cisco Meraki APs automatically perform a multicast-to-unicast packet conversion using the IGMP protocol. The unicast frames are then sent at the client negotiated data rates rather than the minimum mandatory data rates, 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 a high-definition video as part a classroom learning experience. 

Limit Broadcasts 
Cisco Meraki APs automatically limits duplicate broadcasts, protecting the network from broadcast storms. The MR access point will limit the number of broadcasts to prevent broadcasts from taking up air-time. This also improves the battery life on mobile devices by reducing the amount of traffic they must process.
Airtime Fairness 
Cisco Meraki APs have Airtaime fairness turned on by default and ensures that co-existing clients connected to a single AP have equal access to the airtime in the APs coverage area.

Wireless Layer 3 Roaming Best Practices

Large WLAN networks (for example, those found on large campuses) may require IP session roaming at layer 3 to enable application and session persistence while a mobile client roams across multiple VLANs. For example, when a user on a VoIP call roams between APs on different VLANs without layer 3 roaming, the user's session will be interrupted as the external server must re-establish communication with the client's new IP address. During this time, a VoIP call will noticeably drop for several seconds, providing a degraded user experience. In smaller networks, it may be possible to configure a flat network by placing all APs on the same VLAN.

 

However, on large networks filled with thousands of devices, configuring a flat architecture with a single native VLAN may be an undesirable network topology from a best practices perspective; it may also be challenging to configure legacy setups to conform to this architecture. A turnkey solution designed to enable seamless roaming across VLANs is therefore highly desirable when configuring a complex campus topology. Using Meraki's secure auto-tunneling technology, layer 3 roaming can be enabled using a mobility concentrator, allowing for bridging across multiple VLANs in a seamless and scalable fashion.

Typical Campus Architecture 

Large campuses are often designed with a multi-VLAN architecture to segment broadcast traffic. Typically, network best practices dictate a one-to-one mapping of an IP subnet to a VLAN, e.g., client devices joining VLAN 10 will be assigned an IP address out of the subnet range 10.0.10.0/24. In this design, clients in different VLANs will receive IP addresses in different subnets via a DHCP server. Multi-VLAN architectures can vary to include multiple subnets within a building (e.g., one for each floor/area), or multiple subnets across a large site (e.g., one for each building/region in a large campus or enterprise environment).

 

As seen in the diagram below, the typical campus architecture has the core L3 switch connected to multiple L3 distribution switches (one per site), with each distribution switch then branching off to L2 access switches configured on different VLANs. In this fashion, each site is assigned a different VLAN to segregate traffic from different sites. Without an L3 roaming service, a client connected to an L2 access switch at Site A will not be able to seamlessly roam to a L2 access switch connected to Site B. Upon associating with an AP on Site B, the client would obtain a new IP address from the DHCP service running on the Site B scope. In addition, a particular route configuration or router NAT may also prevent clients from roaming, even if they do retain their original IP address.

 

 

With layer 3 roaming, a client device must have a consistent IP address and subnet scope as it roams across multiple APs on different VLANs/subnets. Meraki's auto-tunnelling technology achieves this by creating a persistent tunnel between the L3 enabled APs and depending on the architecture, a mobility concentrator. The two layer 3 roaming architectures are discussed in detail below.  

Distributed Layer 3 Roaming

Distributed layer 3 roaming maintains layer 3 connections for end devices as they roam across layer 3 boundaries without a 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 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 defined by the anchor AP.

 

Distributed layer 3 roaming is very scalable because the access points are establishing connections with each other without the need for a concentrator. The target access point will look up in the shared user database and contact the anchor access point. This communication does not traverse the Meraki Cloud and is a proprietary protocol for secure access point to access point communication. UDP port 9358 is used for this communication between the APs.

 

 

As you can see in the above diagram, Anchor AP is the AP where the client gets connected the first time. An AP to which the client is associated is called a hosting AP, it does not connect with the broadcast domain of the client. Hosting AP will create a tunnel with the Anchor AP to maintain the IP address of the client.

In case the hosting AP has direct access to the broadcast domain of the client, then the hosting AP will become the Anchor AP for that client.

A client's anchor AP will timeout after the client has left the network for 30 seconds.

Broadcast Domain Mapping

Each Meraki Access point sends layer 2 broadcast probes over the Ethernet uplink to discover broadcast domain boundaries on each VLAN that a client could be associated with when connected. This is done for multiple reasons. One reason is because there can be instances where AP1 is connected to an access port (no VLAN tag) and AP2 is connected to a trunk port where the same VLAN is used, but the VLAN ID is present and tagged on the uplink. These broadcast frames are of type 0x0a89 sent every 150 seconds.

 



There could also be situations where the same VLAN ID is used in different buildings (representing different broadcast domains), so it’s important to ensure exactly which APs and VLAN IDs can be found on which broadcast domains. Apart from tunnel load balancing and resiliency, the broadcast domain mapping and discovery process also allows for anchor APs and hosting APs to have a real-time view into which VLANs are shared between the two APs. This allows for efficient decision making when it comes to layer 2 vs layer 3 roaming for a client, as described in the “VLAN Testing and Dynamic Configuration” section below.  This is important so that anchor APs for clients can be dynamically switched for load balancing reasons, or in failover situations where the original anchor AP is no longer available. 
Meraki APs will send out probes to discover the following broadcast domains:

  • The AP’s native VLAN
  • Any VLAN that is configured for the SSID on the AP
  • Any VLAN that is dynamically learned via a client policy 
  • Any VLAN that an AP has recently received a broadcast probe on from another Meraki AP in Dashboard network

The power of the broadcast domain mapping is that this will discover broadcast domains agnostic of VLAN IDs configured on an AP. As a result of this methodology, each AP on a broadcast domain will eventually gather exactly the AP/VLAN ID pairs that currently constitute the domain. Whenever a client connects to another SSID the Anchor AP for that client is updated.

Broadcast Domain Discovery

The following steps establish the AP/VLAN ID (VID) pair that correspond to a broadcast domain:

  1. APs periodically broadcast a BCD announcement packet that contains the AP’s VLAN ID for that broadcast domain, giving a {sender AP,VID} pair on each broadcast domain the AP interacts with.
  2. Create equivalence classes based on AP/VID pairs recently observed in BCD announcement packets on the same broadcast domain.

Additional notes:

  • Each AP on a broadcast domain will eventually gather exactly the AP/VID pairs that currently constitute the domain.
  • In principle, any AP/VID pair can be used to refer to a broadcast domain. Given AP1/VID1, as long as you know the full list of pairs for that broadcast domain, you can tell whether some other AP2/VID2 refers to the same domain or not.

 

An AP could theoretically broadcast BCD announcement packets to all 4095 potentially attached VLANs, however it will limit itself to the VLANs outlined above.

Roaming with Broadcast Domains

The Meraki MRs leverage a distributed client database to allow for efficient storage of clients seen in the network and to easily scale for large networks where thousands of clients may be connecting. The client distributed database is accessed by APs in real-time to determine if a connecting client has been seen previously elsewhere in the network. This requires that the APs in the Meraki network have layer 3 IP connectivity with one another, communicating over UDP port 9358. Leveraging the Meraki Dashboard, the APs are able to dynamically learn about the other APs in the network (including those located on different management VLANs) to know whom they should communicate with to look up clients in the distributed client database. 
 

The following process describes how client roaming operates with distributed layer 3 roaming

  1. Anchor APs have a full set of AP/VLAN ID pairs for each attached broadcast domain as described above.

  2. On client association, the hosting AP retrieves the client data from the distributed store.

    • If the hosting AP does not find an entry in the store:

      • The hosting AP then becomes the anchor AP for the client. It stores the client in the distributed database, adding a candidate anchor AP set. The candidate anchor set consists of the AP’s own AP/VLAN ID pair plus two randomly chosen pairs from the same anchor broadcast domain.

    • If the hosting AP does find an entry in the store:

      • It checks to see if the client’s VLAN is available locally, from the previous broadcast domain discovery process outlined above. If the associated VLAN ID is available, the hosting AP will become the anchor AP and the VLAN for that client will dynamically be provisioned for the client. See the section “VLAN Testing and Dynamic Configuration” below.

      • Otherwise, the hosting AP sets up an anchor AP for the client (picking a random pair from the candidate anchor set).

  3. As long as the hosting AP continues to host the client, it periodically receives updates to the candidate anchor set from the anchor AP. The anchor AP replaces any AP/VLAN ID pair in the candidate anchor set that disappears with another randomly chosen AP/VLAN ID pair for that broadcast domain. The hosting AP updates the distributed store’s client entry with changes to the candidate

VLAN Testing and Dynamic Configuration

The anchor access point runs a test to the target access point to determine if there is a shared layer 2 broadcast domain for every client serving VLAN. If there is a VLAN match on both access points, the target access point will configure the device for the VLAN without establishing a tunnel to the anchor. This test will dynamically configure the VLAN for the roaming device despite the VLAN that is configured for the target access point and the clients served by it. If the VLAN is not found on the target AP either because it is pruned on the upstream switchport or the Access Point is in a completely separated layer 3 network, the Tunneling method described below will be used.

Local VLAN testing and dynamic configuration is one method used to prevent all clients from tunneling to a single anchor AP. To prevent excess tunneling the layer 3 roaming algorithm determines that it is able to place the user on the same VLAN that the client was using on the anchor AP. The client in this case does a layer 2 roam as it would in bridge mode.

Tunneling

If necessary, the target access point will establish a tunnel to the anchor access point. Tunnels are established using Meraki-proprietary access point to access point communication. To load balance multiple tunnels amongst multiple APs, the tunneling selector will choose a random AP that has access to the original broadcast domain the client is roaming from. If the target AP detects a connectivity failure to the currently selected anchor AP, as a failover mechanism the target AP will choose a new anchor AP. Hosting AP will ping Anchor AP every second to ensure that the Anchor AP has not failed. This ping is integrated as a part of the L3 communication on UDP port 9358.
 
All APs must be able to communicate with each other via IP.  This is required both for client data tunneling and for the distributed database. If a target access point is unable to communicate with the anchor access point the layer 3 roam will time out and the end device will be required to DHCP on the new VLAN. Data packets are not encrypted between two Anchor APs on the wired side but control and management frames are encrypted.

Fast roaming protocols such as OKC and 802.11r are not currently supported with distributed layer 3 roaming. The best roaming performance will be using Layer 2 roaming with 802.11r.

Design Example

Let’s walk through an example of the distributed layer 3 roaming architecture from start to finish. In this example network, we’ll use the following configuration:

  1. 5x MRs on management VLAN 10 tagged with ‘Group A’

  2. 5x MRs on management VLAN 20 tagged with ‘Group B’

  3. SSID: Corporate

  4. Client IP Assignment: layer 3 roaming

  5. VLAN ID:

    • Group A: VLAN 15

    • Group B: VLAN 25

We will assume that the total of 10 APs are online and connected to Dashboard, and have IP connectivity with one another.

 

Client A associates with a ‘Group A’ AP on management VLAN 10, and receives an IP address in VLAN 15 as expected. This AP becomes the anchor AP & hosting AP for the client. The APs in the Meraki network have built out the broadcast domain mapping pairs (AP/VLAN ID) and are exchanging periodic updates. Client A roams to a ‘Group B’ AP on management VLAN 20, client VLAN 25. The ‘Group B’ AP is now considered the hosting AP and reads the distributed client database to see if the client has connected previously. It finds an entry for the client and checks locally to see if the client’s broadcast domain is available on the switchport. The broadcast domain is not available, and the hosting AP will now pick an anchor AP out of the candidate anchor set (supplied from the distributed client database check) which will be any AP that has advertised itself to the distributed client database as having access to client VLAN 15. Once the anchor AP is selected, along with two candidate anchors for resiliency, the tunnel is established and the hosting AP updates the distributed client database with this information.

 

The hosting AP will periodically refresh the anchor AP and distributed database. The anchor AP’s entry for a client has an expiration time of 30 seconds. If the client disconnects from the network for 45 seconds, as an example, it may connect back to a new anchor AP on the same broadcast domain associated with the client. The distributed database expiration timer for a client is the DHCP lease time. This effectively determines how long a client’s broadcast domain binding is remembered in the distributed database. If a client disconnects from the network, and then reconnects before the DHCP lease time has expired, then the client will still be bound to its original broadcast domain.

 

In another scenario, let’s imagine a large enterprise campus with 10 floors. Following common enterprise campus design, the customer has segmented one VLAN per floor for the users. To accommodate for client mobility and seamless roaming throughout the campus building, the customer wishes to leverage distributed layer 3 roaming. Using AP tags, the configuration will specify a VLAN ID assignment for a given SSID based on the tag. In this case, the following configuration will be used:

  • SSID: Corporate

  • Client IP Assignment: layer 3 Roaming

  • VLAN ID:

    • Floor 1 - VLAN 11

    • Floor 2 - VLAN 12

    • Floor 3 - VLAN 13

    • Floor 4 - VLAN 14

    • Floor 5 - VLAN 15

    • Floor 6 - VLAN 16

    • Floor 7 - VLAN 17

    • Floor 8 - VLAN 18

    • Floor 9 - VLAN 19

    • Floor 10 - VLAN 20

The switchports which the MRs will be connecting to will be configured as trunk ports. Switches on floors 1-5 will allow VLANs 11,12,13,14,15. Switches on floors 6-10 will allow VLANs 16,17,18,19,20. With this configuration, a user who associates on floor 1 will receive an IP address on VLAN 11. As they roam throughout the building, changing floors, the roams will be layer 2 only with no tunneling required.

Only when the client roams to the upper half of the building (or vise versa) will a tunnel be formed to keep the client in its original broadcast domain. Keep in mind that even if the client originally received IP addressing on VLAN 11, since AP’s on Floor 5 have access to that broadcast domain (discovered via the Broadcast Domain Mapping & Discovery mechanism), then that client will maintain it’s VLAN 11 IP addressing information and will simply use the AP on floor 5 as it’s new anchor.

This type of design allows for maximum flexibility by allowing for traditional layer 2 roams for users who spend the majority of their time in a specific section of the building, and allowing for continued seamless roaming for the most mobile clients.

Repeaters don’t have their own IP address, so they cannot be anchor APs. When a client connects to a repeater, the repeater becomes the client’s hosting AP, and the repeater assigns its gateway as the client’s anchor AP.

Concentrator-Based Layer 3 Roaming

Any client that is connected to a layer 3 roaming enabled SSID is automatically bridged to the Meraki Mobility Concentrator. The Mobility Concentrator acts as a focal point to which all client traffic will be tunneled and anchored when the client moves between VLANs. In this fashion, any communication data directed towards a client by third party clients or servers will appear to originate at this central anchor. Any Meraki MX can act as a Concentrator, please refer to the MX sizing guides to determine the appropriate MX appliance for the expected users and traffic. 

 

 

The diagram below shows the traffic flow for a particular flow within a campus environment using the layer 3 roaming with concentrator. 

 

L3_roam_Diagram2.png

Wireless VoIP QoS Best Practices

This article is a guide to optimize Quality of Service (QoS) for wireless Voice over IP applications on Meraki MR wireless access points. Voice over IP (VoIP) has replaced telephones in enterprise networking with IP-based phones. While the majority of desk phones using VoIP require ethernet, there are many voice applications and wireless VoIP phones that operate over WiFi.

The Meraki MR series of WiFi access points have been tested by Cisco Meraki to provide the highest quality VoIP experience when using Cisco Jabber, Microsoft Lync, Microsoft Skype for Business, Broadsoft, Cisco 7900 Series phones, SpectraLINK phones, Ascom phones, Cisco phones, and Apple iPhones. This guide will provide recommendations for optimizing voice quality followed by product specific recommendations. 

Measuring Voice Quality 

By following this guide, you can significantly improve quality of service for the wireless voice applications and reduce or eliminate dropped calls, choppy speech, fuzzy speech, buzzing, echoing, long pauses, one-way audio, and issues while roaming between access points. 

To develop this guide, we performed testing using Microsoft Lync's Pre-Call Diagnostics Tool. The endpoints used during testing were Macbook Pros running Office 365's Cloud-hosted Skype for Business Online, also known as Lync Online. All tests were performed while connected to an MR32 access point inside Meraki's headquarters in San Francisco, a  high density corporate WiFi network. This tool measures 3 key metrics for voice quality: 

  • Network MOS - The Network Mean Opinion Score (MOS) is the network’s impact on the listening quality of the VoIP conversation. The score ranges from 1 to 5, with 1 being the poorest quality and 5 being the highest quality.
  • Packet Loss Rate - The packet loss rate is the percent of packets that are lost during transmission.
  • Interarrival Jitter - Interarrival jitter measures the variation in arrival times of packets being received in milliseconds (ms).

By combining this guide with best practices for configuring your client device configuration, application servers, WAN links, and wired network, you can measure and improve quality voice end-to-end. For more information on configuring your wired network to support Voice, please visit the article on Configuring MS Access Switch for Standard VoIP deployment article.

Voice Quality Before this Guide

With the default settings on the MR, we see the baseline for quality. Voice calls with Lync on this network would be acceptable to some users, but not acceptable to others. The results of the Lync testing show that the Network Mean Opinion Score (MOS) drops below 3.5. Values values dropping below 3.5 are termed unacceptable by many users. The packet loss jumps to 8 percent during a period of network congestion simulated by running a speed test. Jitter fluctuates from 12 milliseconds to over 36 milliseconds. Cisco recommends a target of 10 ms of jitter and no more than 50 ms of jitter. Jitter is handled using buffering in voice/video applications, adding a small delay. The human ear normally accepts up to about 140 milliseconds of delay without noticing it.

Voice Quality After this Guide

After making the changes exactly as described in this guide, we see a significant improvement in voice quality. The MOS score approaches 3.9, the packet loss is near zero, and the jitter is consistently below 6 milliseconds and always below 12 milliseconds. As the call starts, traffic shaping kicks in automatically with prioritization and QoS tagging. A speed test was performed with no impact to the voice traffic - packet loss increased to 0.5% during the congestion.

Wireless Voice Best Practices

A Cisco Meraki wireless network has the intelligence built-in with deep packet inspection to identify voice and video applications and prioritize the traffic using queuing and tagging to inform the rest of the network how to handle your voice traffic. Below is a summary of the best practices to provide the best voice quality over wireless.

  1. Perform a pre-install RF survey for overlapping 5 GHz voice-quality coverage with -67 dB signal strength in all areas.
  2. If possible, create a new SSID dedicated to your voice over IP devices.
    1. Set Authentication type to 'Pre-shared key with WPA2'
    2. Set WPA encryption mode to 'WPA2 only'
    3. Enable '5 GHz band only'
    4. Set Minimum bitrate to '12 Mbps' or higher. 
  3. Enable Bridge mode. If you cannot provide a VLAN across the entire floor, use Layer 3 roaming.
  4. Enable 'VLAN tagging' and assign a VLAN dedicated to wireless voice. If you cannot dedicate an SSID to voice, assign a VLAN dedicated to wireless.
  5. Set a 'Per-client bandwidth limit' to 5 Mbps with 'Speed Burst' to limit all non-voice traffic
  6. Set a 'Per-SSID bandwidth limit' to unlimited.
  7. Enable 'Traffic shaping' on the SSID to prioritize all voice traffic
    1. Create a traffic shaping rule for 'All voice & video conferencing
    2. Add 'Custom expressions' for the IP and ports used by your servers hosting Microsoft Lync / Skype for Business, Jabber, or Spark
    3. Set the Per-client bandwidth limit to 'Ignore SSID per-client limit (unlimited)' from the drop down.
    4. Set PCP to '6
    5. Set DSCP to '46 (EF - Expedited Forwarding, Voice)'
  8. Verify the Voice VLAN is tagged correctly
  9. Verify your uplinks and Switches have Quality of Service defined with the maximum PCP and DSCP values
  10. Verify DSCP trust is enabled on switch ports to APs and uplinks
  11. Verify your Windows Group Policy to ensure your devices are tagging application traffic with DSCP (not on by default)
  12. Verify your voice server configuration to ensure Microsoft Lync / Skype and Call Manager have DSCP enabled (not on by default)
Summary of 802.11 Standards

All Meraki MR series access points support the most recent 802.11 standards implemented to assist devices to roam between access points and ensure voice calls maintain a quality user experience. 

  • 802.11r: Fast BSS transition to permit fast and secure hand-offs from one access point to the other in a seamless manner
  • 802.11i: Enabling client devices authenticated via 802.1x to authenticate with decreased latency whilst roaming
  • 802.11k: assisted roaming allows clients to request neighbor reports for intelligent roaming across access points.
  • 802.11e: Wireless Multimedia Extensions (WMM) traffic prioritization ensures wireless VoIP phones receive higher priority.
  • WMM Power Save: maximizes power conservation and battery life on devices without sacrificing Quality of Service.
  • 802.11u: Hotspot 2.0 also known as Passpoint is a service provider feature that assists with carrier offload.

Pre-Install Survey

The design and layout of access points is critical to the quality of voice over WiFi. Configuration changes cannot overcome a flawed AP deployment. In a network designed for Voice, the wireless access points are grouped closer together and have more overlapping coverage, because voice clients should roam between access points before dropping a call. Designing with smaller cells and lower power settings on the access point are key elements to ensure the overlapping coverage from neighboring APs/cells. Set a clear requirement based on the device type when performing a survey. 

Pre-site surveys are useful for identifying and characterizing certain challenging areas and potential sources for interference, such as existing WiFi networks, rogues, and non-802.11 interference from sources such as microwave ovens and many cordless telephones. Post-site surveys should be performed at least 48 hours after installation to allow the network to settle on channel and power settings.

  • Prefer 5 GHz coverage for voice applications due to the lower noise floor compared to 2.4 GHz
  • Verify an AP can be seen from the phone at -67 dBm or better in all areas to be covered 
  • Verify that the AP sees the phone at -67 dBm or better in all areas as well
  • Signal to Noise Ratio  should always 25 dB or more in all areas to provide coverage for Voice applications
  • Channel utilization should be under 50%

 

For more guidelines on site surveys read our article on Performing a Wireless Site Survey. For more detailed guidelines on designing RF specifically for Cisco Voice over WiFi please read Cisco's Voice over WLAN Guide.

Network Configuration

Making the changes described in this section will provide a significant improvement in voice quality and user satisfaction by following the best practices for configuring your SSIDs, IP assignment, Radio Settings, and traffic shaping rules.

Add a Dedicated Voice SSID 

Voice optimization typically requires a different configuration including access control and traffic shaping to address device specific recommendations. You should create a separate Voice SSID for devices dedicated to voice applications. While this is not a requirement, we recommend to create a separate network to follow this guide. In networks with VoIP handsets from two different manufacturers, it is common to create two voice SSIDs. 

If you plan to deploy more than 4 SSIDs please read our guide on the Consequences of Multiple SSIDs.​

Authentication Type

Voice over WiFi devices are often mobile and moving between access points while passing voice traffic. The quality of the voice call is impacted by roaming between access points. Roaming is impacted by the authentication type. The authentication type depends on the device and it's supported auth types. It's best to choose the auth type that is the fastest and supported by the device. If your devices do not support fast roaming, Pre-shared key with WPA2 is recommended. ​WPA2-Enterprise without fast roaming can introduce delay during roaming due to its requirement for full re-authentication. When fast roaming is utilized with WPA2-Enterprise, roaming times can be reduced from 400-500 ms to less than 100 ms, and the transition time from one access point to another will not be audible to the user. The following list of auth types is in order of fastest to slowest.

  1. Open (no encryption)
  2. Pre-shared key with WPA2 and Fast roaming
  3. WPA2-Enterprise with Fast roaming
  4. ​Pre-shared key with WPA2 
  5. ​WPA2-Enterprise 
WPA2 only for Encryption Mode

Voice devices can benefit from having a single type of encryption used. ​By default, SSIDs on Cisco Meraki access points that are configured as WPA2 will utilize a combination of both WPA1 TKIP and WPA2 AES encryption. WPA2 (AES) is recommended and required in order to utilize caching or fast roaming. The WPA encryption setting is SSID specific, and can be found on the Wireless > Configure > Access control page.

  • If all Voice devices support WPA2, the 'WPA2 only' option is recommended for Voice over IP devices. 
  • If the device does not support AES, it is also possible to force TKIP only. Please contact Cisco Meraki support to configure this option.

For step-by-step instructions on changing the WPA encryption mode, see our document on Setting a WPA Encryption Mode.

802.11r fast roaming

Enabling 802.11r is recommended to improve voice quality while roaming. The 802.11r standard was designed to improve VoIP and voice applications on mobile devices connected to Wi-Fi, in addition to or instead of cellular networks. When mobile devices roam from one area to another, they disassociate from one access point and reassociate to the next access point. Enabling 802.11r benefits VoIP devices by reducing the roaming time spent changing between access points. Some client devices are not compatible with Fast BSS Transition (802.11r). You may wish to check your devices for compatibility.

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.  For more details on 802.11r, refer to our guide on Fast Roaming Technologies

It has been determined that configuring an SSID with WPA2-PSK and 802.11r fast roaming poses a security risk due to a vulnerability.  The vulnerability allows potential attackers the ability to obtain the PSK for the SSID when a client fast roams to another AP.  While 802.11r does improve VOIP quality as the time for the necessary re-association process to the next AP is reduced, it is not recommended to use 802.11r fast roaming at this time with an SSID using WPA2-PSK. 

You can read more on the 802.11r  with WPA2-PSK vulnerability on this blog post.

Layer 2 and Layer 3 Roaming 

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, particularly for seamless roaming, and is the simplest option to put wireless clients on the LAN. To configure the client IP assignment modes please refer to our document on SSID Modes for Client IP Assignment.

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. Using Bridge mode will require a DHCP request when performing a Layer 3 roam between two subnets. For example, when a user on a VoIP call roams between APs on different VLANs without layer 3 roaming, the user's session will be interrupted as the external server must re-establish communication with the client's new IP address. During this time, a VoIP call will noticeably drop for several seconds, providing a degraded user experience. 

Large wireless networks with multiple VLANS per floor may require IP session roaming at layer 3 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/subnetsIf Layer 3 roaming is required on your network, please refer to our article on Layer 3 Roaming

Note: It is strongly recommended to consult with a Cisco Meraki SE or Cisco Partner when considering layer 3 roaming options.

NAT mode is not recommended for Voice over IP: With NAT mode enabled, your 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 hen roaming between APs. 

Segregate Traffic on a Voice VLAN 

Voice traffic tends to come in large amounts of two-way UDP communication. Since there is no overhead on UDP traffic ensuring delivery, voice traffic is extremely susceptible to bandwidth limitations, clogged links, or even just non-voice traffic on the same line. Separating out your voice traffic allows it to function independently of other network traffic, and allows for more granular control over different types of traffic.

If a voice VLAN is specified on a Meraki MS switch, the port will accept tagged traffic on the voice VLAN. In addition, the port will send out LLDP and CDP advertisements recommending devices use that VLAN for voice traffic.  The VLAN tagged on the wireless access point should match the Voice VLAN on your wired network.  For more information, please visit the article on Configuring MS Access Switch for Standard VoIP deployment.

Screenshot 2015-11-13 03.59.38.png

Band Selection

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. A wireless network will provide the best quality of service for wireless voice when designed correctly to support 5 Ghz coverage for voice. 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 your environment. If you do not have proper 5 GHz coverage after a post-install site survey, you can manually increase the power on the 5 GHz radio  in Radio Settings > Channel Planning. 

If you do not have a dedicated Voice SSID, enable 'Dual-band with band steering' to enable your voice 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. However,  to improve voice quality, please follow our guide on configuring wireless band preference on client devices.

If you have devices that only support a 2.4 GHz network such as 802.11bgn devices, please contact Meraki Support to enable a 2.4 GHz only network.

Minimum Bitrate

For Voice networks, 12 Mbps is recommended as the minimum bitrate. Increasing this value requires proper coverage in the RF planning. An administrator can improve the performance of clients on the 2.4 GHz and 5Ghz band by disabling lower bitrates. Adjusting the bitrates can reduce the overhead on the wireless network and also in some cases improve roaming performance. 

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.

Keep in Mind that selecting bitrates 12Mbps and above will prevent 802.11b clients from joining.

As you increase the minimum bitrate, clients need a higher signal to noise ratio to join and use the AP. 

The highest recommended setting is 24Mbps unless specifically advised by a Cisco partner. Most environments and designs do not provide a great enough signal to noise ratio for the client to reliably decode all frames sent at a higher rate.

Bandwidth Limits

Consider placing a per-client bandwidth limit on the rest of your network traffic. Prioritizing voice 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.

  1. Go to Wireless > Configure > Firewall & traffic shaping and choose your SSID from the SSID drop down menu at the top of the screen.
  2. Set a 'Per-client bandwidth limit' to 5 Mbps with 'Speed Burst'. This will apply to all non-voice application traffic. This step in the guide is optional. 
  3. Set a 'Per-SSID bandwidth limit' to unlimited.

Screen Shot 2018-08-12 at 7.27.56 PM.png

SpeedBurst enables a bursts of four times the allotted bandwidth limit for five seconds. 

Traffic Shaping Rules

Use traffic shaping to offer voice traffic the necessary bandwidth. It is important to ensure that your voice traffic has enough bandwidth to operate. As such, traffic shaping rules can be implemented to allow voice traffic to use additional bandwidth, or limit other types of traffic to help prioritize voice traffic.

  1. Go to Wireless > Configure > Firewall & traffic shaping and choose your SSID from the SSID drop down menu at the top of the screen.
  2. Click the drop down menu next to Shape traffic and choose Shape traffic on this SSID, then click Create a new rule.
  3. Click Add + and select 'All VoIP & video conferencing
  4. Set Per-client bandwidth limit to 'Ignore SSID per-client limit (unlimited)' and click Save changes.​

Screen Shot 2018-08-12 at 7.26.04 PM.png

 

PCP, DSCP, and WMM mapping

Many devices support Quality of Service (QoS) tags to maintain traffic priority across the network. Meraki MR access points support WMM to improve the performance of real-time data such as voice and video.  WMM improves the reliability of applications in progress by preventing oversubscription of bandwidth. WMM accomplished this by enhancing the prioritization of traffic using the access categories: voice, video, best effort, and background data. WMM has mapped values which can be found in this article. To configure correct mapping for PCP and DSCP values, the following steps should be followed:

  1. Go to Wireless > Configure > Firewall & traffic shaping and choose your SSID from the SSID drop down menu at the top of the screen.
  2. Under the traffic shaping rules, make sure Shape Traffic for this SSID is selected and that  there's a rule for All voice & video conferencing.
  3. Set PCP to '6' or the setting recommended by your device/application vendor (Note that PCP values can only be changed if the SSID has VLAN tagging enabled. This ensures there's a field to which the CoS value can be written).
  4. Set DSCP to 46 (EF - Expedited Forwarding, Voice) or the setting recommended by your device/application vendor.

Note: The DSCP tag, 46 (EF - Expedited Forwarding, Voice) maps to WMM Access Category AC-VO for Voice, Layer 2 CoS 6)

 

If no DSCP values are configured, the default DSCP to WMM mapping will be used. The access point does the mapping between the LAN's Layer 2 priority and the radio's WMM class. Below is table showing the mapping between common traffic types and their respective markings:

RFC 4594-Based Model

802.3 DSCP 802.3 DSCP [Decimal]

IEEE 802.11 Model [802.11e WMM-AC]

Voice + DSCP-Admit

EF + 44

46

Voice AC (AC_VO)

Broadcast Video

CS5 24 Video AC (AC_VI)

Multimedia Conferencing

AF4n 34, 36, 38 Video AC  (AC_VI)
Realtime Interactive CS4 32 Video AC (AC_VI)
Multimedia Streaming AF3n 26, 28, 30 Video AC  (AC_VI)
Signaling CS3 40 Video AC  (AC_VI)
Transactional Data AF2n 18, 20, 22 Best Effort AC (AC_BE)
OAM CS2 16 Best Effort AC (AC_BE)
Bulk Data AF1n 10, 12, 14 Background AC (AC_BK)
Scavenger CS1 8 Background AC  (AC_BK)
Best Effort DF 0 Best Effort AC  (AC_BE)

* n as used in place for the drop indication of assured forwarding matches values 1-3.  

 

For QoS prioritization to work end to end, ensure that upstream networking equipment supports QoS prioritization as well. The PCP and DSCP tags applied on the wireless access point should match the wired network configuration to ensure end-to-end QoS. For more information, please visit the article on Configuring MS Access Switch for Standard VoIP deployment article.

Custom Traffic Shaping 

If your voice traffic does not match the built-in application signatures or is not listed, you can create your own signature for traffic shaping.

  1. Add the IP and ports used by your servers hosting Microsoft Lync / Skype for Business, Jabber, Spark, or other voice application.
    1. In the Definition field click Add + and Custom expressions 
    2. In the text field, enter the IP address of each of your voice servers for example 172.16.1.123 or a range of server IPs 172.16.1.0/24
    3. Also, add your servers as source addresses by using the CIDR notation localnet:172.16.1.123/32 for an individual server, or localnet:172.16.1.0/24 for a range of IPs.
    4. Click the Add + button again when finished.
  2. If you have a dedicated voice SSID and dedicated voice VLAN add the local subnet of the client devices.
    1. In the Definition field click Add + and Custom expressions 
    2. In the text field, enter localnet:192.168.0.1/16 indicating the source subnet of your client devices in CIDRnotation.
    3. Click the Add + button again when finished.
  3. Set Per-client bandwidth limit to 'Ignore SSID per-client limit (unlimited)' and click Save changes.​

Product Specific Recommendations

Cisco Meraki works closely with device manufacturers, for example Apple, to provide them with their own access points for interoperability testing. Meraki performs our own testing across the entire spectrum of devices and our customer support team handles and reports bugs quickly. This section will provide recommendations based on real-world deployments by Meraki customers combined with the best practices developed by Meraki and the vendors mentioned below.

Microsoft Lync / Skype for Business

This section will provide guidance on how to implement QoS for Microsoft Lync and Skype for Business. Microsoft Lync is a widely deployed enterprise collaboration application which connects users across many types of devices. This poses additional challenges because a separate SSID dedicated to the Lync application may not be practical. When you install Microsoft Lync Server / Skype for Business, Quality of Service (QoS) will not be enabled for any devices used in your organization that use an operating system other than Windows. For more guidance on deploying Lync over Wi-Fi, please read Microsoft's deployment guide, Delivering Lync 2013 Real-Time Communications over Wi-Fi.

 

Meraki's deep packet inspection can intelligently identify Lync calls made on your wireless network and apply traffic shaping policies to prioritize the Lync traffic - using the SIP Voice protocol. In addition to the Meraki built-in signatures for Skype and SIP, you should also identify each Lync server by IP and any custom ports used by your Lync clients or servers. Follow these steps to configure your traffic shaping rules for Lync / Skype.

  1. Go to Wireless > Configure > Firewall & traffic shaping and choose your SSID from the SSID drop down menu at the top of the screen.
  2. Click the drop down menu next to Shape traffic and choose Shape traffic on this SSID, then click Create a new rule.
  3. Consider setting a 'Per-client bandwidth limit' to 5 Mbps with 'Speed Burst'. This will apply to all non-voice application traffic
  4. Set Per-client bandwidth limit to unlimited
  5. Create a traffic shaping rule for All voice & video conferencing > 'Skype' and 'SIP (Voice)'
  6. Set the Per-client bandwidth limit to 'Ignore SSID per-client limit (unlimited)' from the drop down.
  7. Set PCP to '6'. The 802.1p parameter is no longer supported in Lync Server 2013. The parameter is still valid for backward compatibility with Microsoft Lync Server 2010; however, it has no effect on devices used with Lync Server 2013.
  8. Set DSCP to '46 (EF - Expedited Forwarding, Voice)
  9. Add 'Custom expressions' for the IP and ports used by your servers hosting Microsoft Lync / Skype for Business
    1. For Cloud-hosted Lync / Skype, add the domain names from the table below
    2. Add the Port numbers from the table below or your own list of assigned port numbers
    3. Add the IP address of each of your on-premise Lync servers
  10. You can test that DSCP markings are applied using the Meraki packet capture tool. 

 

Lync Online / Skype for Business Online servers Lync & Skype port numbers On Premise Lync / Skype for Business Servers
  • lync.com
  • skype.com
  • outlook.com
  • onmicrosoft.com
  • cloudapp.net
  • sharepoint.com
  • officedn.microsoft.com
  • microsoftonline.com
  • microsoftonline-p.com
  • verisign.com
  • ​444
  • 5060-5064
  • 5070-5072
  • 5086-5087
  • 8058-8061
  • 49152-57500
  • 172.16.1.123 (Destination IP) 
  • 172.16.1.0/24 (Destination IP range) 
  • localnet:172.16.1.123/32 (Source IP)
  • localnet:172.16.1.0/24 (Source IP range) 

The ports provided in the above table are the standard ports provided by Microsoft. Enabling QoS Configuration of the client device to modify the port ranges and assign the DSCP value 46. Microsoft's best practices include configuring the port ranges on both your servers and client devices. For details on enabling QoS, refer to Microsoft's article Managing Quality of Service (QoS) in Lync Server 2013

Cisco 7925G Phones

Cisco 7925G, 7925G-EX, and 7926G VoIP phones require specific settings to inter-operate with Meraki MR access points configured with WPA2-PSK association requirements. For more in-depth information on integrating Cisco 792xG with MR Access Points, see the Cisco Unified Wireless IP Phone 792xG + Cisco Meraki Wireless LAN Deployment Guide

  1. Cisco recommends to set band selection to 5 GHz only.
  2. Do not utilize the Dual band operation with Band Steering option. If the 2.4 GHz band needs to be used due to increased distance, select Dual band operation (2.4 GHz and 5 GHz) should be selected. 
  3. Set the Minimum bitrate to 11 Mbps or higher. 
  4. By default, Cisco Meraki access points currently tag voice frames marked with DSCP EF (46) as WMM UP 6 and call control frames marked with DSCP CS3 (24) as WMM UP 4.

 

Cisco Meraki access points will trust DSCP tags by default. Administrators should ensure that upstream QoS is in place and that the QoS markings outlined below are in place for the 7925 phones. To rewrite QoS tags for certain traffic types or source/destination, then create a traffic shaping rule as outlined in Custom Traffic Shaping above.

 

Below is the QoS and port information for voice and call control traffic used by the Cisco Unified Wireless IP Phone 7925G, 7925G-EX, and 7926G. For a full list of ports and protocols used by Cisco phones refer to the Cisco Unified Communications Manager TCP and UDP Port Usage Guide.

Traffic Type DSCP   PCP (802.1p) WMM Port Range
Voice (RTP, STRP) EF (46) 5 6 UDP 16384 - 32767
Call Control (SCCP, SCCPS) CS3 (24) 3 4 TCP 2000, TCP 2443

Cisco Unified Communications Manager only uses the port range 24576-32767 although other devices use the full range 16384 - 32767.

Apple iPhones

Apple and Cisco have created partnership to better support iOS business users by optimizing Cisco and Meraki networks for iOS devices and apps. For more information on this partnership, please see Apple's website. Meraki's group policies can be easily configured to optimize Apple devices on a Meraki network. First create a group policy you would like to apply to Apple devices.

  1. Browse to Network-wide > Configure > Group Policies, scroll down and click Add Group
  2. Under traffic shaping, create a new rule, and add All VoIP & video conferencing
    1. Set the Per-client bandwidth limit to Ignore network per-client limit
    2. Set PCP to 6 (highest priority) and DSCP to 46 (EF - Expedited Forwarding, Voice). 
  3. Create a second rule, and add All Video & music
    1. Set the Per-client bandwidth limit to Ignore network per-client limit
    2. Set PCP to and DSCP to 34 (AF41- Multimedia Conferencing, Low Drop).

Screen Shot 2018-08-12 at 8.04.29 PM.png

 

To apply your new Apple device group policy, browse to WirelessAccess Control and enable Assign group policies by device type. Click Add group policy for a device type for each Apple device type (iPhone, iPad, iPod, and Mac OS X) and assign the Apple device group policy you created. Click save and your optimization is complete.

Vocera Badges

Vocera badges communicate to a Vocera server, and the server contains a mapping of AP MAC addresses to building areas. The server then sends an alert to security personnel for following up to that advertised location. Location accuracy requires a higher density of access points. In a high density deployment, you may need to reduce the transmit power of each AP manually to as low as 5 dB on all supported radios. Vocera provides additional documentation on deploying WLAN best practices to support Vocera badges. For more information download their document on Vocera WLAN Requirements and Best Practice

Some models of Vocera badges do not support 5 GHz or WPA2 AES encryption and require WPA1 TKIP.  Please contact Cisco Meraki support to configure a WPA1 TKIP on your network. 

WiFi Calling

Mobile network operators (MNOs) now allow their customers to place phone calls over Wi-Fi to save roaming costs and leverage WiFi coverage in buildings with poor cellular coverage. WiFi calling is expected to be supported by majority of mobile devices and MSPs by the end of 2015. Apple maintains a list of carriers that have wifi calling ready and devices that support it. 

An Enterprise WiFi infrastructure handles more than just carrier voice traffic, and this limited spectrum is shared by other applications and services like Video streaming & Web Conferencing. The requirements for voice in terms of latency and jitter warrants a network with proper end-to-end QoS design & Voice optimizations that would optimize delivery of WiFi calling packets in the presence of other applications.

Service Provider WiFi 

Service providers are using WiFi to offload data from cellular networks to meet the ever-increasing demands of mobile device users. Two technologies enabling WiFi to meet this demand are WiFi calling and Hotspot 2.0.

Hotspot 2.0

Hotspot 2.0 also known as Passpoint is a service provider feature that assists with carrier offloading. Part of the 802.11u amendment to the 802.11 standard additional information is included in Hotspot 2.0 configured SSIDs that Hotspot 2.0 client devices can analyze use to determine if it is able to join the network automatically. 

Managed Service Providers (MSPs) can now take enable of Hotspot 2.0 options on the Cisco Meraki MR access points. Meraki allows MSPs to customize the Hotspot 2.0 SSID advertisements to allow their subscribers to easy roam between networks.  Hotspot 2.0 options are only available to qualified Managed Service Providers. Please contact Cisco Meraki Support to check eligibility.

Troubleshooting VoIP

We have created a detailed article focused on troubleshooting VoIP on Meraki. Please visit the article: VoIP on Cisco Meraki: F.A.Q. and Troubleshooting Tips

Last modified

Tags

Classifications

This page has no classifications.

Explore the Product

Click to Learn More

Article ID

ID: 7125

Explore Meraki

You can find out more about Cisco Meraki on our main site, including information on products, contacting sales and finding a vendor.

Explore Meraki

Contact Support

Most questions can be answered by reviewing our documentation, but if you need more help, Cisco Meraki Support is ready to work with you.

Open a Case

Ask the Community

In the Meraki Community, you can keep track of the latest announcements, find answers provided by fellow Meraki users and ask questions of your own.

Visit the Community