| OPSAWG | B. Pularikkal |
| Internet-Draft | Cisco Systems |
| Intended status: Informational | T. Pauly |
| Expires: November 19, 2016 | Apple Inc. |
| S. Touati | |
| Ericsson | |
| M. Grayson | |
| S. Gundavelli | |
| Cisco Systems | |
| May 18, 2016 |
Wi-Fi Calling Deployment Considerations
draft-pularikkal-opsawg-wifi-calling-00
Carrier Wi-Fi Calling is a solution that allows mobile operators to seamlessly offload mobile voice signaling and bearer traffic onto Wi-Fi access networks, which may or may not be managed by the mobile operators. Mobile data offload onto Wi-Fi access networks has already become very common, as Wi-Fi access has become more ubiquitous. However, the offload of mobile voice traffic onto Wi-Fi networks has become prevalent only in recent years. This was primarily driven by the native Wi-Fi Calling client support introduced by device vendors. The objective of this document is to provide a high level deployment reference to Mobile Operators and Wi-Fi Operators on Carrier Wi-Fi Calling.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 19, 2016.
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
There are several SP Managed and Over the Top Voice Solutions deployed today which can leverage Wi-Fi access networks. Some of these solutions rely on standalone applications installed on the Mobile Handset and other Mobile devices such as tablets. Also there are solutions, which leverage dedicated hardware built exclusively to support Voice over Wi-Fi.e.g,in enterprise type environments. The scope of this document is VoWiFi solutions, which are deployed by Mobile Network Operators also known as Wireless Carriers. VoWiFi from the context of Mobile Voice offload is often referred to as Carrier Wi-Fi Calling. The deployment of Carrier Wi-Fi Calling requires some kind of integration between the Wi-Fi Access network and Mobile Packet Core. Carrier Wi-Fi calling solutions deployed today predominantly uses an 'untrusted Wi-Fi'model that delivers simple IP connectivity to facilitate Mobile Packet Core integration. With this 'untrusted' approach, Mobile Operators are able to make use of the existing Wi-Fi deployment footprint regardless of whether it is owned by the MNOs or by their roaming partners or Wi-Fi Operators without any kind of partnership with the MNOs. This model has definitely allowed MNOs to accelerate the adoption of Wi-Fi calling. However, this comes with some caveats, as depending on the Wi-Fi network, there may be no visibility or control over it by the MNO, impacting its ability to carry voice calls without compromising end user experience.
It is in the interest of both MNOs as well as Wi-Fi Operators to improve the quality of experience for Wi-Fi Calling delivered over a Wi-Fi access network. MNOs have the incentive to make sure that the end user experience does not get compromised while the voice service is offloaded over Wi-Fi access. Wi-Fi operators have the business incentive to enter into roaming partnerships with the MNOs and support Wi-Fi calling with certain Service Level Agreements. In some deployments, it is possible for the MNOs to own some Wi-Fi hotspot deployments. In such cases, MNO will effectively be the Wi-Fi operator as well.
Objective of this document is to provide a Carrier Wi-Fi Calling deployment reference to Wi-Fi Operators and MNOs with primary focus on the Wi-Fi Access Network and the Wi-Fi to Packet Core integration aspects.
This section provides a very high level overview of the end-to-end Architecture for Carrier Wi-Fi Calling. It is outside the scope of this document to provide a detailed Architecture description, as all the functional entities and the protocol interfaces are well defined in the 3GPP and GSMA specifications [3GPPTS23.402,GSMAIR61,GSMAIR51]. Figure-01 below is used to describe the Architecture components at a high level.
+-----+ +-----+
| 3GPP+-----+ HSS |
| AAA | +-----+
+-----+
|
| +-----+
| | PCRF|
| +-----+
| |
+-------+ |
+---+ +-----+ Backhaul| TWAG /| +-----+
|UE +---+WLAN +----------+ ePDG +----+ PGW |
+---+ +-----+ | | +-----+
+-------+ |
|
+-----+
| IMS |
+-----+
Figure 1: High Level Architecture
The UE is the end user device such as a smartphone running native Wi-Fi Calling client. The UE is connected to a Wi-Fi access network, which is represented by the block WLAN in the diagram. Depending up on the trust model, TWAG or ePDG gateway is used to integrate the WLAN access network to the MNO packet core.More details around this untrusted and trusted approaches are covered in the next section. The P-GW acts as the common anchor for the subscriber sessions regardless of whether the UE is connected to Wi-Fi or LTE (not shown), allowing the preservation of the IP Session during a handover between LTE and Wi-Fi. IMS provides several functions related to SIP based call control signaling, namely SIP authentication, basic telephony services, supplementary services, interworking with other IMS systems, and offload into circuit switched voice networks. In addition to voice, the same IMS infrastructure may be leveraged for other multi-media functions such as video calling. The IMS framework consists of several functional entities and is omitted for the sake of simplicity here. PCRF performs classical Policy and Charging Rule functions in the Mobile Packet Core. For the Wi-Fi calling solution, it will trigger the establishment of the default and dedicated bearers on the S2a or S2b interfaces for SIP and RTP traffic between the PGW and the TWAG/ePDG.
This section covers deployment considerations for an end-to-end Wi-Fi calling Architecture that can influence the quality of experience, availability and monetization aspects of the solution offering.
There are three different Architecture options available for Wi-Fi to Packet Core integration for the deployment of Wi-Fi calling. Each of these models are described in the sub-sections below:
This model is built around the assumption that the Wi-Fi access network is 'unmanaged' or untrusted from the MNOs perspective. Since this model does not rely on any security or data privacy implementations on the Wi-Fi access network, it requires the establishment of an IPSec tunnel between the UE device and the Mobile Packet Core. The ePDG gateway acts as the IPSec tunnel termination point on the packet core side. The ePDG handles the user authentication as well as the establishment of an S2b packet data network connection towards the P-GW using the GTP based S2b interface. This Architecture model is illustrated in figure-2 below.
+--------------+ +----------+ +-------+
| +----------+ | IMS-APN | | | |
| | SWu | | Traffic | | | |
| | Client +------------------------------------+ |
| | | | Other APN | | | ePDG |
| | | | traffic | | | |
| | +------------------------------------+ |
| | | | | | +-------+
| +----------+ | | | | |
| | | | S2b| |S2b
| UE | | WLAN | | +---+
| | | Access | | |
| +----------+ | LBO | | +-------+ +-------+
| | Native | | Traffic | | |IMS APN| | Other |
| | | | | | | PGW | | APN |
| | Client +-------------------+ | | | | PGW |
| | | | | | | +-------+ +-------+
| +----------+ | | | | | |
+--------------+ +----------+ | |
| | |
| +-------+ +-------+
| | IMS | | App |
| | | | Server|
v +-------+ +-------+
Figure 2: Untrusted Wi-Fi to Packet Core Integration Model for Wi-Fi Calling
The Wi-Fi calling client implementation uses the ePDG client for IMS APN while the default PDN or Internet APN traffic is locally offloaded (Local Breakout LBO) into the Wi-Fi access network. The "untrusted Wi-Fi" architecture supports multiple APN over SWu, allowing the MNO to also route specific applications traffic associated with one or more APN through the Packet Core, in addition to the IMS APN, if required.
3GPP TS 23.402 also defines the concept of "trusted Wi-Fi" architecture, providing another method to integrate with the packet core. The trustworthiness of an access network itself is left to the MNO to decide, but it generally relies on some level of control by the MNO of the Wi-Fi access network either in a direct or indirect manner. One of the key characteristics of the "Trusted Wi-Fi" architecture as defined in 3GPP Release 11, is the client-less approach to support the packet core integration. This solution lacked the support for multiple APNs signaling for the UE when over the Wi-Fi access network, therefore all Wi-Fi offloaded traffic was assumed to be part of the default PDN or Internet APN. With this limitation, Wi-Fi calling cannot be supported as it require its own IMS APN. The hybrid architecture proposed here combines the 3GPP release 11 "trusted Wi-Fi" architecture, with the ePDG based untrusted Wi-Fi architecture. This hybrid model simultaneously supports IMS and other applications specific APNs using the untrusted Wi-Fi model, with the TWAG selectively offloading their traffic, while using the S2a interface for all other default PDN traffic toward the default PGW. This Architecture model is illustrated in figure 3 below
+------+ +---------+
| IMS | | Other |
| Core | |Services |
+------+ +---------+
| |
+------+ +-------+
+--------------+ +-----------+ |IMS | | Other |
| +----------+ | | | |P-GW | | P-GW |
| | SWu | | | +-------+ | +------+ +-------+
| | Client | | | |SIPTO | | | |
| | | | | ++NAT | | | +--------+
| +----------+ | | +-------+ | | |
| | | | +------+
| UE +------+ TWAG | S2b | ePDG |
| | | +--------+ |
| +----------+ | | | +------+
| | Native | | | |
| | Client | | | |
| | | | | | S2a +-------+
| +----------+ | | +--------+Default|
+--------------+ +-----------+ | PGW |
+-------+
|
|
+
XXXXXXXX
XX XX
X X
XInternetX
X X
XX XX
XXXXXXX
Figure 3: Hybrid Wi-Fi to Packet Core integration model for Wi-Fi calling
Enhancements introduced in 3GPP release 12 SaMOG specifications provides the ability to support multiple APN over Wi-Fi access making the support of Wi-Fi calling, and other applications specific APNs possible without the need for IPSec connectivity between the UE and the Packet core. This Architecture model is illustrated in figure 4 below
+-------+
| IMS |
| Core |
+-------------+ +-----------+ +-------+
| | | | |
| +--------+ | Flow mapped | | |
| |IMS APN | | to VMAC-01 | | +-------+
| | +-----------------+ | |IMS APN|
| |Client | | | +-------+ P-GW |
| +--------+ | | | +-------+
| | | |
| | |Release 12 |
| | | TWAG |
| | | | +-------+
| | | | |Default|
| | | +-------+ APN |
| +--------+ | Flow mapped | | | P-GW |
| |Default | | to VMAC-02 | | +-------+
| | APN +-----------------+ | |
| |Client | | | | |
| +--------+ | | | |
+-------------+ +-----------+ |
XXXXXX
XX XXX
XX XX
X X
X X
X Internet X
X X
X XX
X XX
XX XXXX
XXXXXX
Figure 4: Trusted Wi-Fi to Packet Core integration model for Wi-Fi calling
Each of the Wi-Fi to Packet Core Architecture models described in the previous sections comes with its own pros and cons. And selection of a specific architecture model depends on several factors. Some of these factors, which can help determine the appropriate model, are listed below:
*Wi-Fi Access Network Ownership: There are several ownership models available when it comes to Wi-Fi to packet core integration. Wi-Fi Access network may be deployed by the MNO to leverage as another RAT to complement 3G and LTE. Alternatively the Mobile Network Operator may deploy a Managed Wi-Fi network for the Enterprise and SMB customers. The MNO managed Wi-Fi footprint is only portion of the overall Wi-Fi deployment. Third parties such as broadband service providers today own a significant portion of the Wi-Fi access network. For third party owned Wi-Fi access, the Mobile Network Operator may or may not have a direct roaming partnership with the Wi-Fi operator. The ownership model influences the choice of packet core integration architecture.
*Backhaul Network Ownership: From the context of this discussion here, the backhaul refers to the connectivity between WLAN Access network and the Packet core. It consists of a combination of wired access network of the hotspot, Broadband access last mile, Wi-Fi operator core network, Internet etc. These connectivity aspects will be deciding factor for the choice of Wi-Fi packet integration model. For example, Wi-Fi access network may be owned and or operated by the MNO, but if the backhaul involved a third party connection or Internet where MNO does not have control over security and QoS, an untrusted packet core integration may be the viable solution.
*Mobile Offload Requirements: Choice of the Wi-Fi to packet core integration model is not only influenced by voice offload but data offload as well. The untrusted Wi-Fi and the hybrid architectures do support a flexible offload model, allowing the Mobile Network Operator to choose which traffic to backhaul to the Mobile Packet Core to provide charging and added value services, while also leveraging local breakout capabilities on the device. Using the untrusted, and when applicable, the hybrid models allow the Mobile Network Operator to leverage their deployed network architecture for Wi-Fi calling. This makes both the hybrid and the untrusted Wi-Fi architectures valid options to consider depending on the Wi-Fi network ownership requirements.
*Device Capabilities: This greatly influences the choice of Wi-Fi to packet core integration. For example, a trusted approach with multiple PDN support requires the capability on the device to comply with 3GPP release 12 SaMOG enhancements, while the untrusted or hybrid model can leverage existing implementations and do provide a similar level of functionality.
*Support of Non-SIM devices: The MNO can provide value-added services, including voice services on Non-SIM devices The Untrusted Wi-Fi architecture is compatible with Non-SIM devices and provide the same capabilities to these devices as for the SIM devices.
*Network Readiness: This is another influencing factor for the choice of the trust model, as there are dependencies on the Packet Core network elements as well as Wi-Fi access network for the implementation of these models.
Subscriber onboarding into a Wi-Fi access network is the process of getting connected to a WLAN access network and be able to offload mobile traffic successfully. In order to provide a seamless end user experience for Wi-Fi calling, the handset should be able to get connected to the WLAN with minimum or no user interaction. A seamless WLAN onboarding is critical for the smooth hand off of the voice call from LTE to Wi-Fi. There are several factors, which can influence the Wi-Fi onboarding experience. Proper choice of the available deployment options can ensure the subscriber onboarding experience is quite seamless.
Before the UE device can successfully get associated with a WLAN access network it needs to get authenticated with the WLAN network. There are several types of user authentication options in use such as Web Portal based authentication, EAP-TTLS, EAP-TLS, EAP-SIM, EAP-AKA etc. Choice of the authentication mechanism depends up on the deployment preferences of the Wi-Fi operator. Web portal based authentication relies on an Open SSID configuration. Once the portal has successfully authenticated the UE device, the traffic is carried over the WLAN air interface without any encryption. EAP authentication mechanisms relies on secured SSIDs mandate the 802.11i based air encryption of the subscriber data in the WLAN access network.
In order to support Wi-Fi calling, one of the EAP based mechanisms will be preferred over the web portal based authentication. In the case of Web based authentication, the user needs to manually enter the username and password credentials or in some cases sign up for a service via Operator portal. But with any of the EAP methods, once the credentials have been established on the UE device, then authentication happens automatically without user intervention and greatly improves the onboarding experience.
If the Wi-Fi operator decides to use a secured SSID for subscriber authentication, choice of the EAP method depends up on the business model. A Standalone Wi-Fi operator may need to rely on non-SIM based EAP authentication mechanisms such as EAP-TTLS or EAP-TLS for their home subscribers. A Wi-Fi operator who has a roaming partnership with an MNO could allow the uSIM credentials of the MNO subscriber to be used for the access. In this case, the Wi-Fi operator will act as a proxy and authenticate the customer credentials with the MNO HSS.
Identity management deals with establishing subscriber identity and associated credentials on the UE device for WLAN onboarding. Identity management and authentication goes hand in hand. Option leverages the same set of identity and credentials (unified identity) for WLAN onboarding and packet core connectivity will simplify the identity management for Wi-Fi calling. However this requires that the WLAN access network is either owned by the MNO or by their roaming partner. With unified identity, typically uSIM credentials will be leveraged for both WLAN onboarding as well as packet core connectivity for SIM devices, and an EAP method used for Non-SIM devices.
Ability for a handset to Seamlessly get connected to WLAN access network is one of the key factors which will influence the overall subscriber experience with Wi-Fi calling. Passpoint specifications defined by the Wi-Fi alliance under the Hotspot 2.0 program supports automatic discovery, selection and onboarding of Wi-Fi clients on to a compatible Wi-Fi access network. Figure-5 below is used to illustrate the hotspot 2.0 solution at a high level:
+----------------+
| Wi-Fi Operator |
| AAA Server / |
| AAA Proxy |
| |
+----------------+
|
|
|
+----------------+ XXXXX
+-----------+ | | XXX XXX
| | | +----------+ | XX XX
| | | | ANQP | | XX XXX
| UE | | | Server | | X XX
| | | | | | XX Roaming X
| +-------+ +------+ +----------+ +---------XXInterconnectXX
| | ANQP | | | | XX X
| | Client| | | | XX XX
| | | | | +----------+ | XX XXX
| +-------+ | | | AP/AC | | XX XX
+-----------+ | | | | XXX XXX
| +----------+ | X+X
+----------------+ |
| |
| |
| +------------+
XXXXX | MNO |
XX XXX | AAA Server |
X XX | |
XX XX +------------+
X External X |
XX Network XX |
X Access X |
XX XX +------------+
XX XX | HSS |
XX XXX | |
XXXX XXX +------------+
XXXX
Figure 5: Hotspot 2.0 with Service Provider Roaming
ANQP server is the component, which assists with the automatic discovery of WLAN network resources by the UE device. ANQP server is typically collocated on the Access Point (AP) or the Access Controller (AC). A Hotspot 2.0 compatible UE device will have a built in ANQP client. When a UE roams into the coverage area of a Hotspot 2.0 enabled network, it automatically learns about the network capability via Beacon or Probe Response. Then UE requests a set of network and service level information from the WLAN network. Based up on the info UE can decide which WLAN access is the most preferred and the type credentials it can use for getting connected.
MNOs can enter into roaming partnership, which will allow Wi-Fi calling clients to automatically get connected to the WLAN access. This also allows the devices to leverage uSIM credentials or EAP credentials for Non-SIM devices for getting authenticated with the WLAN network. The Wi-Fi operator AAA will function as a proxy in this case and completes the authentication by interfacing with the MNO AAA Server and HSS, for EAP_SIM/EAP_AKA in the MNO packet core.
The use of IPSec to establish a connection to the ePDG, require that the access network allow IPSec tunnel establishment. But some networks won't allow IPSec traffic either as a security policy or as a side-effect of only allowing "web traffic". In addition, many mainly corporate environments do deploy an HTTP proxy which will also prevent the establishment of an IPSec tunnel. Performing changes to these deployments may not always be possible or cost effective for the corporation or the public venues, especially in an "Untrusted Wi-Fi" model without the MNO involvement. In such situations, the mobile device can leverage the IPSec TCP encapsulation as described in draft-pauly-ipsecme-tcp-encaps-04 and in 3GPP TS 24302, which define the encapsulation of IPsec traffic in TCP. The Mobile device shall enable the TCP encapsulation only after failling to establish an IPSec connection to the ePDG. Figure 6 below shows the TCP encapsulation with the use for TLS to traverse a Proxy and reach the ePDG.
+------------+ +----------+ +-------+
| +--------+ | TCP with HTTP | | TCP with TLS | |
| | SWu +===================+==========+=================+ |
| | Client ------------------------------------IPSEC------- |
| | +===================+==========+=================+ ePDG |
| |Proxy | | then TLS | Proxy | | |
| |Config | | through proxy | Firewall | +-------+
| +--------+ | +----------+ |
| UE | |
+------------+ +-------+
| |
| IMS |
| PGW |
+-------+
Figure 6: Use of TCP encapsulation for IPSec
When an HTTP proxy is deployed, the UE should connect to the eDPG through the proxy and then establish a TLS connection toward the ePDG. TLS is not used for securing the link, but to traverse the HTTP Proxy, and is configured with NULL-Cipher. This model allows Wi-Fi calling to operate even in restrictive networks.
Quality of the Wi-Fi calling experience would be as good or as bad as Radio network itself. Three network performance KPIs which impact the quality of voice are latency, jitter and packet drops. A healthy network is critical to ensure that these KPIs will meet the thresholds allowed to meet the acceptable voice quality. This section primarily talks about various performance optimization mechanisms available on the Wi-Fi Radio network.
Radio Resource Management (RRM) aka Wi-Fi SON refers to the co-ordinated fine-tuning of the various RF network parameters among access points connected in a Wi-Fi network. It is very typical for Wi-Fi deployments from multiple operators to co-exist in the same hotspot. Scope RF fine tuning will be limited to the access points which are managed by the same operator in a specific hotspot. RRM fine-tuning will be typically performed by a centralized entity such as Access Controller. Some deployments which may not leverage AC such as Residential Gateways could leverage a cloud based RRM or SON Server. RRM controller continuously analyze the existing RF environment automatically adjust the power and channel configurations of access points to help mitigate issues such as co-channel interface and signal coverage. A proper implementation of RRM can greatly influence the RF performance and will have a positive impact on network KPIs that influence the Wi-Fi calling experience.
Roaming from the context of the discussion here refers to the hand of of a UE device from one Access Point to another Access Point in the same Extended Services Set (ESS) or mobility domain. Unlike cellular roaming between base stations, which is initiated by the network, in Wi-Fi the roaming is initiated by the UE device. A UE typically decides to disconnect from the current access point when some of the RF measurements such as RSSI, SNR etc. drops below certain threshold. There are other APs in the range with acceptable measurements the UE will start re-association process with one of the target APs. End user experience for a Wi-Fi call, which is active at the time of the hand off, will depend up on multiple factors. One critical factor is the time taken for the UE traffic to resume during the hand off. Also it is important that UE is able to make the optimum selection of the target AP from the list of available APs in the range. Discussed below are few IEEE 802.11 based mechanisms available to optimize the roaming.
IEEE 802.11r based fast BSS transition (FT) helps reduce the handoff time for a UE when it roams from one AP to another with in an ESS, which is enabled, with an EAP based authentication. Without FT, the UE will have to go through the full authentication process with the RADIUS server and device fresh set of encryption for 802.11i air encryption. When FT is enabled, the client will have an initial handshake with the target AP while still connected to the original AP. This handshake allows client and target APs to derive the encryption keys in advance to reduce the hand off time. Fast Transition can significantly improve the end user experience for the voice calls, which are active during a hand off.
IEEE 802.11k enhancements allow a UE device to request from the current AP to which it is connected for a recommended list of neighboring APs for roaming. Up on receiving the client request, the AP responds with a list of neighbors on the same WLAN with the Wi-Fi channel numbers. Neighbor list is created by the AP based up on the Radio Resource Measurements and includes the best potential roaming targets for the UE. Neighbor list allows UE to reduce the scanning time when it is time to roam into a new AP in the same WLAN and there by improves the roaming performance. It is recommended to enable 802.11k along with Fast BSS transmission for optimum roaming performance.
Typical WLAN deployments will have APs with overlapping coverage areas. This is done on purpose to seamless handoff and also to address capacity requirements. Load distribution of UEs in the same coverage area may be helpful to proactively manage the bandwidth requirements and there by improve the subscriber experience. In the most rudimentary form, some of the load balancing solutions relies on the brute force method of ignoring the association requests from a UE by the APs with high load. Another more sophisticated mechanism is to leverage 802.11v based network assisted roaming. 802.11v allows unsolicited BSS transmission management messages from AP towards the client with a list of preferred APs to make roaming decisions. If the AP is experiencing high load, or bad connectivity from the client it may send an unsolicited BSS transmission management frame with the recommended list of APs to roam into. Depending up on the client implementation, it may or may not honor this info while making oaming decisions.
This section covers the traffic prioritization mechanisms available in various segments of the overall traffic path of the Wi-Fi calling signaling and bearer sessions. Flexibility control of the QoS implementations will depend up on various factors such as ownership and management of the WLAN access network, Wi-Fi to packet core integration model etc.
Traffic prioritization in the WLAN for Carrier Wi-Fi calls can be achieved by implementing Wi-Fi Multimedia (WMM). WMM consists of a subset of IEEE 802.11e enhancements for Wi-Fi. WMM defines four Access Categories, AC1, AC2, AC3 and AC4. AC1 is mapped against voice, AC2 is mapped against video, AC3 is mapped against best effort traffic and AC3 is mapped against Background traffic. Each of these Access Categories is mapped against one or more 802.11e User Priority (UP) values. UP has range from 0 to 7. Higher UP values typically gets more expedited over the air treatment EDCA mechanism for channel access defined in 802.11e is modified to make sure that traffic in higher UP queues get higher priority treatment. WMM can only leveraged if the client can do the right classification and Access points also support it.
While QoS on the WLAN access network is critical, that by it may not be sufficient to maintain the subscriber quality of experience. It is important to enable QoS prioritization across all the network segments, which form part of the end-to-end voice path. Flexibility of the QoS implementation along the network segments will depend up on the trust models, which are discussed earlier. For example, if the transit path between WLAN network and Packet Core is include Internet, no QoS prioritization can be implemented over the Internet backhaul. How ever for deployment scenarios in which all network segments along the voice traffic path are managed either by the Mobile operator or their partners, then it makes much easier to implement end to end QoS. End to end QoS Classification for Wi-Fi calling is illustrated in figure 7 below.
Voice UP 6 Voice DSCP 46
Voice Sig. UP 4 Voice Sig. DSCP 24
+--------------+ +---------------+
| WMM or WMM+AC| | DiffSrv QoS |
| | | |
v v v v
+----+ +--------+ +--------+
| | | WLAN | | |
| | | | | |
| UE | | +----+ | | TWAG/ |
| +-----------+ | AP/| +---------+ ePDG | <------+
| | | | AC | | | | |
| | | +----+ | | | |
+----+ +--------+ +--------+ |
| Dedictated |
Voice QCI 1| and |
Sig. QCI 5 | Default |
| Bearers |
| |
+--------+ <------+
| |
| P+GW |
| | <------+
+--------+ |
| |
| DiffSrv |
| QoS |
| |
+--------+ |
| | |
| IMS | <------+
| |
+--------+
Figure 7: End-to-end QoS Reference Model
This QOS reference model assumes that, MNO or their roaming partners manage all the segments in the end-to-end path for voice signaling and voice bearer traffic. Model also assumes that transit path between WLAN and Packet core is private and secured and does not traverse Internet.
QoS reference model leverages WLAN access network leverages WMM that is described in the previous section, UP value of 6 is typically used for voice bearer traffic and UP value of 4 is used for voice signaling traffic. In order for voice to get the proper prioritization, WMM needs to be supported and enabled on both UE and the WLAN network.
In the transit IP network between WLAN and packet core, DSCP based QoS prioritization can be deployed if the connectivity is part of a managed transport. DSCP value of 46 is typically used for marking voice bearer and DSCP value of 24 is typically used for marking voice signaling. Proper traffic prioritization will depend up on whether DiffSrv QoS is enabled in the transit network.
Between P-GW and ePDG or TWAG, dedicated bearer with QCI value 1 will be established dynamically for voice calls. For signaling traffic a default bearer with QCI value of 5 will be used. These QCI values are mapped against specific QoS SLAs and allocation retention policies (ARP).
Wi-Fi calling client functionality requirements will have some level of dependency on the type of WLAN to packet core integration model. Bare minimum the clients should support IMS User Agent as defined in the 3GPP spec and be able to send and receive IMS signaling and bearer traffic over Wi-Fi access. In addition a SWu client with IPSec support will be required for ePDG based packet core integration. This section talks about some of the client side implementation considerations for Wi-Fi calling which will have an impact on the end user experience.
This section talks about the mechanisms available for selecting the right RAT technology to offload for IMS APN traffic. It is important to note that, once UE gets connected to a Wi-Fi network, NSWO traffic will always get offloaded to the Wi-Fi. This section focuses on handling of just IMS traffic. There are three different mechanisms available to assist with the selection of the RAT technology by the UE. Each of these are discussed below.
Local Carrier Policy Profile: In this case, the logic is defined in the local policy. Some MNOs may prefer cellular instead of Wi-Fi for voice service when both RAT technologies are available. Some other carriers may have Wi-Fi preferred approach for IMS APN when both RAT technologies are available. With Wi-Fi preferred approach, the WLAN access to which the UE connected may need to meet an acceptance criteria for some of the network performance KPIs such as RSSI and SNR before the voice gets offloaded into the Wi-Fi access network. If Passpoint enabled on a Wi-Fi access network, an intelligent UE logic could take into account network loading conditions learned from the ANQP server to decide whether to offload IMS traffic into the Wi-Fi network.
ANDSF Based Access Selection: ANDSF leverages a network-based infrastructure for MNO controlled access selection. Access selection policies can be applied on a per APN basis. ANDSF supports two types of access selection policies as described below
Inter-System Mobility Policies (ISMP) defines the network selection rules for a UE which can get connected to just one RAT network at a time.
Inter-System Routing Policies (ISRP) defines the traffic steering rules for a UE which can get connected simultaneously to multiple RAT technologies. In this case, traffic steering policies can be applied on a per APN basis or per IP flow basis.
Inter-RAT hand over refers to the handover of an active voice call without service disruption when the UE switches out from one RAT technology to another. Implementations must support handovers between Wi-Fi and LTE as well as Wi-Fi and 2G or 3G. In the case handovers between Wi-Fi and LTE, the IP address preservation is important. This is accomplished by making sure that the IMS subscriber session gets anchored on the same P-GW before and after the hand off. For hand off between Wi-Fi and 3G, Dual Radio Voice Call Continuity (DRVCC) mechanism is used.
This section talks about an additional performance management mechanism, which can be used to improve the overall Wi-Fi calling experience. Radio Network Performance management, and QoS considerations described earlier can significantly contribute to the overall QoE for Wi-Fi calling. A client driven congestion management mechanism can positively augment the overall experience. The idea is to dynamically change the bandwidth requirements for the call based up on the network congestion conditions. Network resource requirements (bandwidth, packets per second etc.) per call are directly proportional to the type of codec and the packetization rate. Sometimes it may be desirable to switch out to a lower audio codec to keep the drop, delay and jitter characteristics under acceptable levels during periods of network congestion. Explicit Congestion Notification for RTP over UDP defined in RFC 6679 can be used to inform network congestion to the end clients. But this requires the network elements to mark the ECN bits on the IP header of the packet when congestion conditions are encountered.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |