With the introduction of Apple’s iOS 8, Voice over Wi-Fi (VoWi-Fi) has received a lot of attention. Previously, VoWi-Fi was an over-the-top (OTT) application that users downloaded from an app store so they could make calls over the Internet. But here’s the problem with that OTT offering: At least one of the calling parties had to load the OTT application onto a device and create an OTT identity (typically an email address and password). Then that user had to rely on the OTT application’s dialer, rather than the phone itself.
With iOS 8, users no longer have to create separate identities or even know that they are initiating or receiving voice calls over Wi-Fi. As long as the user’s phone and cellular provider support VoWi-Fi calling, then the user can simply enable Wi-Fi. Then the user’s device will typically select a Wi-Fi network automatically and authenticate itself.
With Wi-Fi Certified Passpoint networks, this authentication becomes transparent. The user can place and receive voice calls over the Wi-Fi network using the phone’s own dialer.
Initial VoWi-Fi deployments have been targeted at residential users, providing additional coverage inside homes that are poorly served by the macro cellular network. However, as VoWi-Fi deployments accelerate, and its use gains in popularity, calls will be made over nonresidential systems, including community Wi-Fi, hotspots, hot zones, large venues, enterprise Wi-Fi networks, and city Wi-Fi networks. Network performance will become critical in these scenarios, which includes delivering a consistent user experience regardless of the load, user location, and environment.
This design guide outlines best practices when designing and implementing next-generation carrier-class Wi-Fi networks for mobile operators, cable operators, and managed service providers.
Best Practices for a High-Definition Voice Experience
A single VoWi-Fi call does not place a heavy data load on the network (iOS 8 VoWi-Fi calling, for example, typically requires around 160 Kbps [bidirectional G.711]). However, other factors such as connection quality, VoWi-Fi capacity, interference, and access point–to–access point mobility have a dramatic affect on voice quality.
The optimum cell size is based on the cell-edge data rate and receive-signal strength indication (RSSI), which for iOS 8 devices needs to be >-82dBm. This will achieve a certain packet-error-rate (PER), which we measure using the retry rate. Because a high voice mean opinion score (MOS) needs a PER <1 percent and typical Wi-Fi cells are built to a 10 percent PER, we need to reduce our link budget by ~5dB, as per Figure 1, which reduces, for example, a 10K sq. ft. cell by 33 percent to 6.7K sq. ft.
Figure 1. VoWi-Fi Performance
In Wi-Fi, overhead and collisions of small periodic VoWi-Fi packets (for example, G.711) significantly reduce the MAC efficiency (see Figure 1), while cochannel interference (CCI) limits channel utilization. Because the distribution of users is unknown a priori, we must consider the minimum capacity (number of concurrent calls at cell edge). Because we share VoWi-Fi with data, we assume at most 25 percent of the channel utilization is allocated to voice and also that voice activity detection (VAD) reduces required throughput by 50 percent. The resulting call capacity is shown in Figure 2.
Figure 2. VoIP Call Capacity
For typical cells (5000 sq. ft), the planning capacity is 16 calls (because we favor the 5GHz band). For different conditions (for example, higher channel utilization, lower CCI, and so on), this access point planner can be used:
Band and Rate Selection
VoWi-Fi devices can connect over a Wi-Fi network on either the 2.4GHz or 5GHz band and use either newer 802.11n/11ac rates or older 802.11 b/a/g rates. Because the 2.4Ghz band tends to be congested (interference and so on), the Wi-Fi network should be configured to encourage the device to use 5GHz either using a policy (for example, disable 2.4GHz radios, deploy SSID over 5GHz only) or using BandSelect.
In general, throughput and roaming are improved when the minimum cell data rate accepted by the network matches the planned cell edge RSSI. For iOS devices in the 5GHz band, the roaming process begins (scanning for alternate access points) at –70dBm RSSI, and handoff is attempted (reassociated) when an access point is found that is 8dBm better. Thus, –62dBm should be our target RSSI at the cell edge. This needs to be consistently set across:
● Target cell-edge RSSI: lowest RSSI for cell-size planning (see above)
● Minimum data rate for association (that is, 802.11a/n/ac->network->rates)
● RSSI low-check threshold: lowest RSSI for association
● Minimum data rate for assisted/optimized roaming (that is, optimized roaming->data rate threshold)
● Coverage hole detection and mitigation (CHDM) RSSI: lowest RSSI for roaming in (reassociation)
For example, to achieve a –62dBm cell-edge (optimal VoWi-Fi roaming), the RSSI low-check threshold should be –62dBm + 5dBm (shadowing) = –67dBm, the CHDM RSSI should be –62dBm (it includes 6dB shadowing), and both minimum data rates (assumed 5GHz/40MHz, iPhone 6) should be 150Mb/s (or closest supported rate).
As noted previously, VoWi-Fi capacity is relatively independent of data rate and bandwidth. Thus, consideration should be given primarily to improving link quality. If data throughput is not a consideration, the smallest bandwidth (20MHz) should be selected for channels because it yields the lowest CCI. Otherwise, channel bandwidth consideration should be based on client density (see “Density Considerations”).
Planners should also consider that interference from Wi-Fi (that is, cochannel) and non-Wi-Fi sources will degrade the VoWi-Fi quality. To mitigate, we should use radio resource management (RRM) with CHDM to choose channels and transmit power (TXP) that minimize CCI and CleanAir to identify, classify, and mitigate the effects of non-Wi-Fi interference. For improved VoWi-Fi quality, event-driven RRM (ED-RRM) should be considered to improve response to unexpected interference: that is, minimize cell-outage time or time to repair (TTR).
In higher client density scenarios (for example, sports stadium with 50+ clients per cell), the access point density is typically higher than in other venues, and CCI must be considered. Intuitively, the use of higher bandwidth enabled by 802.11ac (that is, 80MHz) should yield the highest throughput, but a detailed study indicates that in these dense client scenarios, the use of 40MHz is optimal. In addition, the WLC can be configured with the Cisco® WLAN Express feature and selecting the high client density option as outlined in the Cisco Wireless Controller Configuration Guide.
A wireless LAN controller (WLC) can provide transparent fast roaming between access points (<50ms) using 802.11r capabilities of the mobile device (for example, iOS 8) and access point. However, mobile devices often try and hang on or “stick” to a Wi-Fi access point connection even if there is a better Wi-Fi access point available, leading to reduced throughput and cell capacity (as above). To encourage fast timely roaming, we employ the following techniques:
● 802.11r: Enable fast transition as L2 security option on per SSID basis (for iOS7+ and newer Android OS)
● 802.11k: Enable neighbor lists (non-dual-band) and assisted roaming (non-11k devices)
● 802.11v: Enable BSS transition with disassociation imminent (to encourage roaming)
With these options plus the recommended band and rate selection, 2.4GHz roaming is highly discouraged. For more details about iOS device roaming, see this Apple blog.
Quality of Service
Any deployment requiring quality of service (QoS) must enable wireless multimedia (WMM) in order to provide differentiated access categories (ACs), including voice (AC_VO) specifically. The iOS 8 VoWi-Fi application uses WMM but only marks upstream packets for voice (AC_VO). The downstream packets are typically unmarked and treated as best-effort (AC_BE), which leads to inconsistent treatment. With controller-based Wi-Fi (local mode), this can be addressed using application visibility and control (AVC) to mark these downstream VoWi-Fi packets appropriately. This also includes matching QoS on the wired LAN (for example, CAPWAP) and provides granular metrics such as serving operator, bandwidth (packet/bytes), and peak/average bit rates needed for adequate QoS, planning, and billing. (See Figure 3.)
Figure 3. VoWi-Fi QOS
For architectures without AVC for VoWi-Fi (for example, FlexConnect), it is common to use a QoS profile (that is, Platinum) to remark packets to the AC-VO. However, this causes all packets’ ingress to that WLAN to be upgraded and could cause a significant reduction in cell capacity; thus, this is not recommended.
Note that admission control is not supported by iOS, and so network dimensioning (as above) is critical.
Achieving a high-definition voice experience (HDVX) is highly desirable from a service provider perspective to provide a consistent voice and data experience while using their mobile devices, irrespective of the access networks providing that experience. The best practices identified in this design guide prescribe a methodology to select and deploy a Wi-Fi access network for carrier-grade performance and customer satisfaction. Cisco has a complete set of HDVX features that provide the best user experience on VoWi-Fi as well as future multimedia and interactive applications.
For More Information
To learn more about the Cisco Universal Wi-Fi Solution featuring HDVX, go to cisco.com/go/spwifi.