ZEBRA Voice Deployment with Aruba WLAN Infrastructure User Guide

ZEBRA Voice Deployment with Aruba WLAN Infrastructure

Product Information

Specifications

• Manufacturer: Zebra Technologies Corporation
• Model: MN-004334-03EN Rev A
• Copyright Date: 2024/08/26
• Wireless Network Compatibility: Dual-band (2.4GHz, 5GHz)

Product Usage Instructions

Device Settings
To ensure optimal performance when deploying voice with Aruba WLAN Infrastructure, it is crucial to configure the device settings correctly. Follow the below steps:

1. Access the device settings menu on your Zebra mobile device.
2. Set the appropriate parameters for voice deployment as recommended in the manual.
3. Ensure that the Wi-Fi Quality of Service (QoS) tagging and mapping is configured according to the guidelines provided.

Default, Supported, and Recommended for Voice Device Settings
The manual provides detailed information on the default, supported, and recommended device settings for voice deployment. Make sure to review and apply these settings accordingly to optimize voice performance.

Device Wi-Fi Quality of Service (QoS) Tagging and Mapping
Properly configuring the Wi-Fi Quality of Service (QoS) tagging and mapping is essential for prioritizing voice traffic on the network. Refer to the manual for specific instructions on how to set up QoS for voice applications.

FAQ

• Q: Can devices supporting WiFi6 operate seamlessly in a WLAN of dual-band APs?
  A: Yes, devices listed in the WiFi6 column can operate and connect as a WiFi6 device in a WLAN of dual-band APs.

Copyright

2024/08/26
ZEBRA and the stylized Zebra head are trademarks of Zebra Technologies Corporation, registered in many jurisdictions worldwide. All other trademarks are the property of their respective owners. ©2024 Zebra Technologies Corporation and/or its affiliates. All rights reserved.
Information in this document is subject to change without notice. The software described in this document is furnished under a license agreement or nondisclosure agreement. The software may be used or copied only in accordance with the terms of those agreements.
For further information regarding legal and proprietary statements, please go to:
SOFTWARE: zebra.com/informationpolicy.
COPYRIGHTS: zebra.com/copyright.
PATENTS: ip.zebra.com.
WARRANTY: zebra.com/warranty.
END USER LICENSE AGREEMENT: zebra.com/eula.

Terms of Use

Proprietary Statement
This manual contains proprietary information of Zebra Technologies Corporation and its subsidiaries (“Zebra Technologies”). It is intended solely for the information and use of parties operating and maintaining the equipment described herein. Such proprietary information may not be used, reproduced, or disclosed to any other parties for any other purpose without the express, written permission of Zebra Technologies.

Product Improvements
Continuous improvement of products is a policy of Zebra Technologies. All specifications and designs are subject to change without notice.

Liability Disclaimer
Zebra Technologies takes steps to ensure that its published Engineering specifications and manuals are correct; however, errors do occur. Zebra Technologies reserves the right to correct any such errors and disclaims liability resulting there from.

Limitation of Liability
In no event shall Zebra Technologies or anyone else involved in the creation, production, or delivery of the accompanying product (including hardware and software) be liable for any damages whatsoever (including, without limitation, consequential damages including loss of business profits, business interruption, or loss of business information) arising out of the use of, the results of use of, or inability to use such product, even if Zebra Technologies has been advised of the possibility of such damages. Some jurisdictions do not allow the exclusion or limitation of incidental or consequential damages, so the above limitation or exclusion may not apply to you.

About This Guide

This guide is jointly authored by Zebra Technologies and Aruba Networks.
This guide provides recommendations for voice deployment using the following mobile computers, where the WLAN network employs access point hardware of up to dual-band (2.4GHz, 5GHz).
If the WLAN network employs access point hardware that supports and enables 6GHz (tri-band), refer to Best Practices for Wi-Fi 6E (Tri-Band) including Voice, with Aruba WLAN Infrastructure.

NOTE: Mobile devices listed in the WiFi6E column in the following table seamlessly operate and connect as a WiFi6 device in a WLAN of dual-band APs.
Table 1    Zebra Mobile Devices Supporting Aruba WLAN Voice Deployment

Device Type| Devices with dual-band radio (2.4GHz, 5GHz)

supporting WiFi5 (11ac)

| Devices with dual-band radio (2.4GHz, 5GHz) supporting WiFi6 (11ax)| Devices with tri- band radio (2.4GHz, 5GHz, 6GHz)

supporting WiFi6E (11ax with 6GHz)

---|---|---|---
Handhelds| 2×2 MU-MIMO with DBS : TC52, TC52x, TC72, TC57, TC57x, TC77, TC83, EC30, EC50, EC55, MC3300x, MC9300, PS20

1×1 MU-MIMO : *TC21,

TC26, MC27, *MC22,

*MC20, RZ-H271

| 2×2 MU-MIMO : TC52ax, MC3300ax| 2×2 MU-MIMO with DBS : TC53, TC53e, TC53e-RFID, TC73, TC58, TC58e, TC78, MC3400, MC9400, MC9450, PS30, *TC22,

*TC27

Handhelds for Healthcare| 2×2 MU-MIMO with DBS : TC52-HC, TC52x- HC

1×1 MU-MIMO : TC21- HC, TC26-HC

| 2×2 MU-MIMO : TC52ax-HC| 2×2 MU-MIMO with DBS : HC50, *HC20
Wearables| 2×2 MU-MIMO with DBS : WT6300| | 2×2 MU-MIMO with DBS : WT6400, WT5400
Tablets| 2×2 MU-MIMO with DBS : ET51, ET56, L10A| 2×2 MU-MIMO :

ET40, ET45
ET40-HC, ET45-HC.

| 2×2 MU-MIMO with DBS : ET60, ET65
Vehicle Mounted and Concierge| 2×2 MU-MIMO with DBS : VC8300, CC600, CC6000| |

Table 1   Zebra Mobile Devices Supporting Aruba WLAN Voice Deployment (Continued)

Device Type| Devices with dual-band radio (2.4GHz, 5GHz) supporting WiFi5 (11ac)| Devices with dual-band radio (2.4GHz, 5GHz) supporting WiFi6 (11ax)| Devices with tri- band radio (2.4GHz, 5GHz, 6GHz) supporting WiFi6E (11ax with 6GHz)
---|---|---|---
The terms MU-MIMO (Multi-User Multi-Input-Multi-Output) and DBS (Dual Band Simultaneous) are detailed in Device RF Capabilities.
Devices without “” support full Enterprise quality experience out of the box and include all device WiFi configurability options.
Devices with “” require a Zebra mDNA license for full Enterprise quality experience and configurability.

Notational Conventions
The following notational conventions make the content of this document easy to navigate.

• Bold text is used to highlight the following:
  • Dialog box, window, and screen names
  • Dropdown list and list box names
  • Checkbox and radio button names
  • Icons on a screen
  • Key names on a keypad
  • Button names on a screen
• Bullets (•) indicate:
  • Action items
  • List of alternatives
  • Lists of required steps that are not necessarily sequential.
• Sequential lists (for example, those that describe step-by-step procedures) appear as numbered lists.

Icon Conventions
The documentation set is designed to give the reader more visual clues. The following graphic icons are used throughout the documentation set. These icons and their associated meanings are described below.

NOTE : The text here indicates information that is supplemental for the user to know and that is not required to complete a task.The text here indicates information that is important for the user to know.

Related Documents For the latest version of this guide and all documentation sets for the respective devices, go to: zebra.com/support.
Refer to the Aruba’s RF and Roaming Optimization documentation for more details about Aruba infrastructure.

Device Settings

This chapter includes device settings for default, supported, and voice traffic recommendations.

Default, Supported, and Recommended for Voice Device Settings

Note the following:

• Pairwise master key identifier (PMKID) is disabled on the device by default. If your infrastructure configuration is configured for PMKID, enable PMKID and disable the opportunistic key caching (OKC) configuration.
• The Subnet Roam feature allows you to change the network IP of the WLAN interface when the network is configured for a different subnet on the same extended service set identification (ESSID).
• In execution of default fast transition (FT) (also known as FT Over-the-Air), in case that other non-FT Fast Roaming Methods might be available on the same SSID, see Fast Roam Methods in Table 5 and relevant notes in General WLAN Recommendations.
• Use mobile device management (MDM) agents to change settings. Use the user interface (UI) to change parameter subsets.
• For voice applications, and for any highly-dependent client-server communication apps, it is not recommended to use the Android battery optimization feature (also known as Doze Mode) in device management tools. Battery optimization interrupts communication between dependent endpoints and servers.
• Media access control (MAC) randomization:
• From Android Oreo onwards, Zebra devices support the MAC randomization feature, which is enabled by default. Disable or enable this via MDM or via Android privacy setting Use Device MAC:
  • When enabled in Android 10 versions and earlier, the randomized MAC value is used only for Wi-Fi scanning of new networks prior to association with the intended network (prior to new connection), however, it is not used as the associated device MAC address. The associated MAC address is always the physical MAC address.
  • When enabled in Android 11 onwards, the randomized MAC value is also used for association with the intended network. The randomized value is specific for each network name (SSID). It remains the same when the device roams from one AP of the connected network to different AP(s) of the same network, and/or when it has to fully re-connect to the specific network after being out of coverage.
• The MAC randomization feature does not affect voice performance and it is not necessary to disable this feature for general troubleshooting purposes. However, in some specific situations, disabling it may be helpful during the troubleshooting data collection.

NOTE: Device models in Table 1 prefixed with “*” are assumed to be provisioned with Zebra’s mDNA software license in the voice deployment. Table 2 does not apply to these devices if they do not have that license.
The following table lists the default, supported configuration, and recommended voice settings.
The default value is recommended in the Recommended for Voice column, which is also the default value populated in recent Product Releases. Observe the notes in the Default Configuration columns. If a prior release is applicable in the deployment and the Recommended for Voice setting is the default, then it is recommended to reconfigure the respective item in the older release to match the noted value in the newer release.

Table 2 Default, Supported, and Recommended Voice Device Settings

Feature| Default Configuration| Supported Configuration| Recommended for Voice
---|---|---|---
State11d| Country selection set to Auto|

• Country selection set to Auto
• Country selection set to Manual

| Default
ChannelMask_2.4 GHz| All channels enabled, subject to local regulatory rules.| Any individual channel can be enabled or disabled, subject to local regulatory rules.| Device Mask matches the exact set of network side operating channels configuration.
| | | It is recommended to configure both the device and the network to a reduced set of channels 1, 6, and 11, if WLAN SSID is enabled on 2.4 GHz.
ChannelMask_5.0 GHz|

• Up to Android Oreo Build Number 01.13.20, all non- dynamic frequency selection
• (DFS) channels are enabled.
• From Android Oreo Build Number 01.18.02 onwards, Android 9 and, Android 10, all channels are enabled, including DFS.

| Any individual channel can be enabled or disabled, subject to local regulatory rules.| Device Mask matches the exact set of network side operating channels configuration. It is recommended to configure both the device and the network to a reduced set of only non-DFS channels.
For example, in North America, configure the network channels to 36, 40, 44, 48, 149, 153,157, 161, 165.
| All the above are subject to local regulatory rules.| |
Band Selection| Auto (both 2.4 GHz and 5 GHz bands enabled)|

• Auto (both bands enabled)
• 2.4 GHz
• 5 GHz

| 5 GHz

Table 2 Default, Supported, and Recommended Voice Device Settings (Continued)

Feature| Default Configuration| Supported Configuration| Recommended for Voice
---|---|---|---
Band Preference| Enabled| •     Enable for 5 GHz

•     Enable for 2.4 GHz

•     Disable

| Enable for 5 GHz, if WLAN SSID is on both bands.
Open Network Notification|

• Enabled in Android 10 onwards
• The default is disabled in Android 10 versions and earlier.

| •     Enable

•     Disable

| Default
Advanced Logging| Disabled| •     Enable

•     Disable

| Default
User Type| Non-Restricted| •     Enable

•     Disable

| Default
FT| Enabled| •     Enable

•     Disable

| Default
OKC| Enabled| •     Enable

•     Disable

| Default
PMKID| Disabled| •     Enable

•     Disable

| Default
Power Save| NDP (Null data power save)
Note : Devices with WiFi6E are set with a Power Save default of 6E/TWT (6E Target Wake Time). When deployed in a non-6E WLAN, they dynamically auto- default to NDP.|

• NDP
• Power save polling (PS- POLL)
• Wi-Fi multimedia power save (WMM-PS)

| Default
11k| Enabled|

• Enable
• Disable

| Default
Feature| Default Configuration| Supported Configuration| Recommended for Voice
---|---|---|---
11v| TC52ax: Enabled from build 11.16.05 with U120 onwards All other models: Enabled from build 11.20.18 onwards|

• Enable
• Disable

| Use the default for each build version.
Subnet Roam| Disabled|

• Enable
• Disable

| Default
11w| After Android 10: Enable / Optional

Before Android 10: Disable

|

• Enable / Mandatory
• Enable / Optional
• Disable

| Default
Channel Width| 2.4 GHz – 20 MHz

5 GHz – 20 MHz, 40

MHz and 80 MHz

| Not configurable| Default
11n| Enabled|

• Enable
• Disable
• Note: Disabling this also disables 11ac.

| Default
11ac| Enabled|

• Enable
• Disable

| Default

Device Wi-Fi Quality of Service (QoS) Tagging and Mapping

This section describes device QoS tagging and mapping of packets from the device to the AP (such as outgoing packets in the uplink direction).
The tagging and mapping of traffic in the downlink direction from the AP to the device is determined by the AP or controller vendor implementation or configuration, which is not in the scope of this document.

For the uplink direction, an application on the device sets Differentiated Service Code Point (DSCP) or Type of Service (ToS) values for its sourced packets, based on the application’s specifications. Prior to the transmission of each packet over Wi-Fi, the DSCP or ToS values determine the device’s further 802.11 Tagging ID assigned to the packet, and the mapping of the packet to 802.11 Access Category.

The 802.11 tagging and mapping columns are provided for reference and are not configurable. The IP DSCP or ToS values may or may not be configurable, depending on the app.

NOTE : Table 3 describes the tagging and mapping values for outgoing packets when no other dynamic protocols affect them by standard specifications. For example, if the WLAN infrastructure mandates the Call Admission Control (CAC) protocol for certain traffic types (such as voice and/or signaling), tagging and mapping obey the dynamic states of the CAC specifications. This means that there could be CAC configuration or sub- periods in which the tagging and mapping apply different values than mentioned in the table, even though the DSCP value is the same.

Table 3 Device Wi-Fi QoS Tagging and Mapping for Outgoing Traffic

IP DSCP

Class Name

| IP DSCP

Value

| ToS Hexa| Tagging of 802.11 TID (Traffic ID) and UP (802.1d UserPriority)| Mapping to 802.11 Access Category (same as Wi-Fi WMM AC spec)
---|---|---|---|---
none| 0| 0| 0| AC_BE
cs1| 8| 20| 1| AC_BK
af11| 10| 28| 1| AC_BK
af12| 12| 30| 1| AC_BK
af13| 14| 38| 1| AC_BK
cs2| 16| 40| 2| AC_BK
af21| 18| 48| 2| AC_BK
af22| 20| 50| 2| AC_BK
af23| 22| 58| 2| AC_BK
cs3| 24| 60| 4| AC_VI
af31| 26| 68| 4| AC_VI
af32| 28| 70| 3| AC_BE
af33| 30| 78| 3| AC_BE
cs4| 32| 80| 4| AC_VI
af41| 34| 88| 5| AC_VI
af42| 36| 90| 4| AC_VI
af43| 38| 98| 4| AC_VI
cs5| 40| A0| 5| AC_VI
va| 44| B0| 5| AC_VI
ef| 46| B8| 6| AC_VO
cs6| 48| C0| 6| AC_VO
cs7| 56| E0| 6| AC_VO

Network Settings and Device RF Characteristics

This section describes device settings for the recommended environment and device RF characteristics.

Recommended Environment

• Perform a Voice Grade Site Survey to ensure the requirements in Table 4 are met.
• Signal to Noise Ratio (SNR), measured in dB, is the delta between the noise in dBm and the coverage RSSI in dBm. The minimum SNR value is shown in Table 4. Ideally, the raw noise floor should be -90 dBm or lower.
• In floor level, Same-Channel Separation refers to two or more APs with the same channel are in RF sight of a scanning device in a given location. Table 4 specifies the minimum received signal strength indicator (RSSI) delta between these APs.

Table 4 Network Recommendations

• No adjacent channels (overlapping)
• Overlapping APs must be on different channels 5 GHz: 36, 40, 44, 48, 149, 153, 157, 161, 165
• If you are using DFS channels, broadcast the SSID in beacons.
• Unlicensed National Information Infrastructure-2 (U-NII-2) (DFS channels 52 to 140) and U-NII-3 (channels 149 to 165) are subject to local regulatory rules.

Device RF Capabilities
The device RF capabilities described in this section (Dual Band Simultaneous (DBS), WiFi6/OFDMA, MU-MIMO, 2×2 vs 1×1 antenna) apply to the supported devices in the Table 1.

DBS Advantages in 2×2 MU-MIMO Devices
2×2 devices with DBS use several functionalities which allow one antenna to be on a specific band (5 GHz or 2.4 GHz), while the other antenna can be on another band at the same air time.

Important DBS Performance Considerations
Stable network connectivity and streaming traffic during roaming are important to time-sensitive applications such as voice. The availability of DBS on the devices results in better performance concerning the following parameters:

• DBS devices do not spend much time on off-channel scanning compared to non-DBS devices. Packet loss typically happens when devices are performing off-channel scanning. Therefore, the ongoing traffic between the DBS devices and the APs has lower packet loss. This reduces the jitter and delays of the traffic.

  • The off-channel scanning time depends on the distributions or layouts of deployments and the WLAN configurations such as 11k. On average, DBS devices spend about half the time non-DBS do on off-channel scanning.

• DBS devices complete scanning cycles in a shorter time than the non-DBS to search for the best
  AP. DBS devices scan and connect to the next stronger AP before the current AP connection deteriorates and impacts the traffic or disconnects during roaming. By doing this quicker than non-DBS, the connectivity is less likely to be interrupted, and the data transmission traffic keeps going in an expected stable quality without packet retries. In addition to that, when DBS devices move from a poor network coverage area which is not covered at all or spotty to a better one, the devices can connect to the new network quicker than the non-DBS.

  • The switching speed from one AP to another by DBS devices depends on the distributions or layouts of deployments and the WLAN configuration such as 11k. On average, DBS devices are 50%faster than non-DBS.

Relevant Use Cases and Environments
The WLAN deployment eco-system and the quality requirements of applications impose different dynamic characteristics that probably impact the connectivity and the quality. The use cases and environments relevant to the capabilities of DBS are as follows:

• When the deployment includes time-sensitive applications using Wi-Fi, such as voice and video calls, which need to maintain active registration and connectivity parameters with the backend servers.
• When users are using time-sensitive applications, such as voice calls, moving across a building for a continuous duration while roaming.
• When users are using applications that need to have good connection quality while moving within a building that does not have continuous Wi-Fi network coverage. The building layout, obstruction, and other use cases may impact the Wi-Fi network coverage.
• When the infrastructure channel plan has many channels (such as more than 15 channels).

The higher the level of those characteristics is, the more critical DBS is.

Devices with Wi-Fi 6 Advantages

Devices that support Wi-Fi 6 (802.11ax) can use the unique capabilities when connected to WLAN or APs infrastructure that also supports Wi-Fi 6 or 802.11ax. Orthogonal frequency-division multiple access (OFDMA) is a Wi-Fi 6 feature that increases the efficiency of handling the application traffic and is useful for time-sensitive applications such as voice.

OFDMA allows the APs to subdivide the serving channel into sub-channels and to allocate smaller frequencies to each, such that the AP can handle the simultaneous data transmission on the channel to multiple connected devices (OFDMA downlink transmissions), and simultaneous data reception on the channel from multiple connected devices (OFDMA uplink transmissions).

The efficiency of the OFDMA allows the ecosystem to support a much larger capacity of time-sensitive applications that are used by multiple devices simultaneously on the channel, while keeping the traffic performance intact and maintaining the stable performance with negligible jitter, latency, and packet loss for all the connected devices. Without OFDMA, a lower number of connected devices can receive good quality service from the given APs.

2×2 MU-MIMO and 1×1 MU-MIMO Devices Antenna Configuration
Table 1 shows that most devices covered in this guide are 2×2 MU-MIMO and some are 1×1 MU-MIMO. Most APs of the WLAN infrastructure in enterprise deployments support 2×2 MU-MIMO. The key aspects of the 2×2 or 1×1 devices in Table 1 fitting into a 2×2 WLAN environment are different, especially when stable network connectivity is required and time-sensitive applications such as voice are used.

Air Medium and Time Sharing
In the WLAN infrastructure that supports Wi-Fi 5 (802.11ac) or earlier and regardless of the Wi-Fi generation of the wireless devices, the AP and devices must wait for the air medium to be free before each and

next data transmission can occur. If the AP and the device are both 2×2, the transmission speed can be at the maximum rate of the 2×2 communication capability between them. Meaning, the airtime for each transmission between the AP and the device is shorter and the medium is free in a shorter time for the next potential transmission. However, if the device is 1×1, the maximum rate of communication between the AP and the device is determined by the 1×1 modulation scheme which has a lower speed. This leads to longer airtime for each transmission and longer wait time for each and next potential transmission.

When the Wi-Fi 6-enabled devices are connected to a WLAN infrastructure that also supports Wi- Fi 6 (802.11ax), there is no contention in airtime. The OFDMA technology in Wi-Fi 6 mitigates the airtime contention challenge to some degree by allowing simultaneous data transmission to multiple devices. However, the maximum rate is still determined by the maximum modulation scheme of 2×2 or 1×1. Even though a 1×1 is capable of carrying the traffic of time- sensitive application in terms of speed and pace, the main aspects that need attention are the nearby congregation and potential amount of the 1×1 links between the APs and devices in the network ecosystem.

This may dynamically impact the air medium, and then may impact the traffic utilization and capacity, potentially leading to latency to or from one or more of the applications. For example, when many devices are likely to be connected to the same strong AP and each of these devices are sending and receiving time-senstitive application data at the same time, the 2×2 devices are less likely to be suffering air medium contention, whereas the data streaming speed for the 1×1 devices might be impacted.

In another example, in the networks which must serve high-throughput applications next to the ongoing operating voice, regardless of the number of users, utilization of the high-throughput applications has lesser impact on the voice in the network ecosystem of 2×2 links as compared to the 1×1.

No formula can be used to compute the exact capacity and performance of the 1×1. When 1×1 devices are considered for time-sensitive application deployments, running pre-tests in the deployed WLAN of the respective use- cases or in the heaviest RF conditions and capacity is important to evaluate the performance.

Multipath and Interference

Multipath, caused by RF signals reflected from the surfaces of physical obstructions, and external RF signals are two factors that potentially distort the original transmission of any 802.11 wireless network. In such conditions, a 1×1 device may struggle to decode a large amount of distorted signals, which results
in the network having to retransmit the signals. A high retransmission rate in the ecosystem causes latency, packet loss, and medium congestion, which can then become a self-inflicting factor that impacts the air medium and capacity. However, the 2×2 devices are capable of taking advantage of the elevated gains of the multipath signals and using the maximum ratio combined (MRC) method to decode the distorted signals. Therefore, retransmission is not required.

No network environment is free of multipath, and no formula can predict the exact level of multipath impacting the 1×1 which may lead to retry and poor data transmission quality. It is recommended that users run pre-tests on the 1×1 models to evaluate the RF signal performance. In addition, users can use some RF spectrum survey tools and sniffers to detect the noise level and RF interference in the environment.

Coverage and Range
For the WLAN deployments that take place in uneven network coverage areas due to low RSSI, weak spots where individual AP range does not overlap, and/or the devices are at a farther distance outside the network perimeter or in transitions between two separate areas or buildings, the following aspects need to be fulfilled:

• The devices need to hear APs beacons at a larger distance to maintain the connectivity.
• The devices need to hear the AP downlink of time-sensitive packets at that same distance.
• The AP needs to hear the device uplink of time-sensitive packets at that same distance.

There are several mechanisms that give a 2×2 device more advantages than a 1×1 device to accomplish the three aspects above.

• When a 2×2 device hears the AP beacons or AP-downlink from a far distance that have weak signals, the ability to use the maximum ratio combined (MRC) from the two spatial streams improves the chances to decode the signal as valid and distinguish it from the local noise. A 1×1 device is unlikely to be able to decode weak signals.
• • The 2-antenna design and placement in the 2×2 device help MRC receive signals and reduce the chances that the dynamic positioning of the device (such as the device orientation and the way that the users hold the device) in the 3-dimensional space might impact the ability to hear weak signals.
• A 2×2 uses the cyclic delay diversity (CDD) mechanism to achieve full diversity by turning spatial diversity into frequency diversity when transmitting data to an AP as in any 2×2 MU-MIMO transmission. Using CDD increases the chances for the AP to hear the 2 spatial streams of the device that is from a far distance.

When the coverage expectations are known, the potential challenges may be surveyed and corrected by using WLAN coverage survey tools.

It is important to consider that time-sensitive applications in 1×1 devices require a close to ideal WLAN coverage to operate, where the deployed AP power or channels are overlapped and no error in other network criteria. In such deployments, it is recommended to re-survey and re-check the coverage more frequently, especially when the infrastructure-related configuration parameters have changes.

Infrastructure and Vendor Model Recommendations

This section includes recommendations for Aruba infrastructure settings, including WLAN practices for enabling voice as well as more specific recommendations to manage voice traffic and maintain expected voice quality.

This section does not include a full list of Aruba configurations, but only those required verification to accomplish successful interoperability between Zebra devices and the Aruba WLAN network.

The listed items may or may not be default settings of the given Aruba controller version. Verification is advised.
See Related Documents for more detailed information on recommended network settings.

General WLAN Recommendations
This section lists recommendations to optimize WLAN to support voice deployment.

• For best results, use Wi-Fi Certified (voice enterprise certification from Wi-Fi Alliance) AP models.

• If SSID for voice is enabled on 2.4G band, do not enable the 11b-legacy data rates on that band unless specifically required by some restricted coverage planning or older legacy devices must be supported.

• The device chooses to roam or connect to an AP depending on the infrastructure settings in effect and the underlying dynamics of the RF ecosystem. Generally, the device scans for other available APs at certain trigger points (for example, if the connected AP is weaker than -65 dBm) and connects to a stronger AP if available.

• 802.11r: Zebra strongly recommends that the WLAN network supports 11r FT as a fast-roaming method to achieve the best WLAN and device performance and user experience.

• 11r is recommended above other fast-roaming methods.

  • When the 11r is enabled on the network, either with pre-shared-key (PSK) security (such as FT-
    PSK) or with an authentication server (such as FT-802.1x), the Zebra device automatically facilitates 11r, even if other parallel non-11r methods co-exist on the same SSID network. No configuration is needed.

• Disable unused Fast Roam Methods from the SSID if possible. However, if older devices on the same SSID support a different method, that two or more methods may remain enabled if they can coexist. The device automatically prioritizes its selection per the Fast Roaming Method in Table 4.

• It is a general best practice to limit the amount of SSID per AP to only those required. There is no specific recommendation on the number of SSIDs per AP as this depends on multiple RF environmental factors which are specific to each deployment. A high number of SSIDs impacts channel utilization which comprises not only users and application traffic, but also beacons traffic of all SSIDs on the channel, even those not in use.

  • Call Admission Control (CAC):
  • The network’s CAC feature is designed to facilitate VoIP deployments, but uses algorithmic complexities to determine whether to accept or reject new calls based on network resources in runtime.
  • Do not enable (set to mandatory) CAC on the controller without testing and validating the stability of admissions (calls) in the environment under stress and plurality conditions.
  • Be aware of devices that do not support CAC which are using the same SSID as Zebra devices support CAC. This scenario requires testing to determine how the network CAC impacts the entire eco-system.

• If WPA3 is required for the deployment, refer to the Zebra WPA3 Integrator Guide for guidance on device models that support WPA3 and configuration guidance.

WLAN Infrastructure Recommendations for Voice Support

Table 5 WLAN Infrastructure Recommendations for Voice Support

FT-PSK.
Note: Device automatically selects FT-PSK. PSK is necessary to support legacy /non-11r devices on same SSID.
Operational Data Rates| 2.4 GHz:

• G: 12, 18, 24, 36, 48, 54 (disable all lower rates, including 11b- legacy)
• N: MCS 0 -15

5 GHz:

• A:12, 18, 24, 36, 48, 54 (disable all lower rates)
• AN: MCS 0 – 15
• AC: MCS 0 – 7, 8
• AX: MCS 0 – 7, 8, 9, 10, 11

Note: Adjust rate settings according to environmental characteristics.

Fast Roam Methods

(See General WLAN Recommendations)

| If supported by infrastructure:

• FT (802.11R)
• OKC or PMK Cache

Note: Device priority order from the top.

Note: Local environmental/RF situations (such as high interference level, collisions, obstructions) may yield local high retries ratio, delays, and packet-drops. The AMPDU feature can degrade voice performance in addition to the challenging RF. In such cases, it is recommended to disable the AMPDU.

Aruba Infrastructure Recommendations for Voice Quality

This section lists specific Aruba infrastructure recommendations to manage voice traffic and maintain expected voice quality.
NOTE: If the deployment has services which require service-discovery, set broadcast filtering to ARP only. Consult with Aruba if there are address- resolution issues with the respective discovery protocol.

Table 6  Aruba Infrastructure Recommendations for Voice Quality

Set delivery traffic indication message (DTIM) interval to 1. Note: A value of 2 is also acceptable for certain deployments depending on the voice application (and other voice related aspects such as Push-to-Talk), as well as on the potentially mixed types of devices sharing the same SSID, the battery life of each type, and the Power Save configuration of each client product.| ✓|
Create a dedicated user role on Aruba for voice devices, according to application deployment needs. Create a session access control list (ACL) and place the voice protocols in the prioritized high queue.| ✓|
Broadcast Filtering set to All or address resolution protocol (ARP).| ✓|
Disable Dot1x Termination.| ✓|
Set Probe Retry to its default Enable.| | ✓
Set Max Tx Failure to its default Disable (max-tx-fail=0).| ✓|
Recommendation| Required| Recommended But Not Required
---|---|---
Enable 802.11d/h.| ✓|
Enable Mcast-rate-opt (needed for multicast to go at highest rate).| | ✓
Beacon-rate set with a rate that is also basic-rate.| | ✓
Set Local Probe Request Threshold to its default of 0 (disable).| ✓|
Disable Band Steering.| ✓|
Enable voice Aware Scan and ensure voice traffic of the given ACL definition (of the deployed App) is detected on the controller.| ✓|
Disable 80 MHz support.| | ✓

Additional Configurations for Voice Multicast Applications
Zebra PTT Express Deployment
The following lists recommendations of additional Aruba infrastructure settings to support PTT Express:

• dynamic-multicast-optimization
  Converts Multicast to Unicast with a higher data rate

• dmo-channel-utilization-threshold 90
  Falls back to Multicast traffic from Unicast if the channel utilization reaches 90%

Zebra Recommended WLC, AP Models, and Firmware Versions

NOTE: Model versioning recommendations in this section are based on satisfactory interop
test plan results. Zebra recommends that when using other software versions not listed below, consult the WLC/AP in the Release Notes to verify that a particular version is stable and preferred by the vendor.

• Aruba Controllers 73xx, 72xx, 70xx:
  • Software versions: 8.7.1.x, 8.8.0.1, 8.10.0.x, 8.11.x
• Campus-AP Models: 303H, 303 Series, 30x, 31x, 32x, 33x, 34x, 51x, 53x, 55x, 57x
• IAP 300 series, 31x, 32x, 33x, 34x, 51x, 53x, 55x, 57x:
  • Software versions: 6.5.4.8, 8.7.1.x, 8.8.0.1, 8.9.x, 8.10.x, 8.11.x

www.zebra.com

Read User Manual Online (PDF format)

Read User Manual Online (PDF format)  >>

Download This Manual (PDF format)

Download this manual  >>