[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00 01 02 03

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

Abstract

   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.

Status of This Memo

   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.






Pularikkal, et al.      Expires November 19, 2016               [Page 1]


Internet-Draft   Wi-Fi Calling Deployment Considerations        May 2016


Copyright Notice

   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Architecture Overview . . . . . . . . . . . . . . . . . . . .   6
   4.  Wi-Fi Calling Deployment Considerations . . . . . . . . . . .   8
     4.1.  Wi-Fi to Packet Core Integration  . . . . . . . . . . . .   8
       4.1.1.  Untrusted Model . . . . . . . . . . . . . . . . . . .   8
       4.1.2.  Hybrid Model  . . . . . . . . . . . . . . . . . . . .   9
       4.1.3.  Trusted Model . . . . . . . . . . . . . . . . . . . .  11
       4.1.4.  Model Selection Criteria  . . . . . . . . . . . . . .  13
   5.  Subscriber Onboarding into Wi-Fi Access Network . . . . . . .  14
     5.1.  Authentication and Identity Management  . . . . . . . . .  14
     5.2.  Hotspot 2.0 for Seamless Onboarding . . . . . . . . . . .  15
       5.2.1.  Hotspot 2.0 Inter-Operator Roaming for Wi-Fi Calling   17
   6.  Wi-Fi calling deployment in restrictive networks  . . . . . .  17
   7.  RF Network Performance Optimization . . . . . . . . . . . . .  18
     7.1.  Radio Resource Management . . . . . . . . . . . . . . . .  18
     7.2.  Wi-Fi Roaming Optimization  . . . . . . . . . . . . . . .  19
       7.2.1.  Fast BSS Transition . . . . . . . . . . . . . . . . .  19
       7.2.2.  802.11k based Neighbor Reports  . . . . . . . . . . .  19
       7.2.3.  802.11v based Assisted Roaming and Load Balancing . .  20
   8.  QoS Deployment Considerations for Wi-Fi Calling . . . . . . .  20
     8.1.  Wi-Fi Access Network QoS  . . . . . . . . . . . . . . . .  20
     8.2.  End to End QoS  . . . . . . . . . . . . . . . . . . . . .  21
   9.  Wi-Fi Calling Client Considerations . . . . . . . . . . . . .  23
     9.1.  Access Selection Criteria . . . . . . . . . . . . . . . .  23
     9.2.  Inter-RAT Handover  . . . . . . . . . . . . . . . . . . .  24
     9.3.  Congestion Management . . . . . . . . . . . . . . . . . .  24
   10. Informative References  . . . . . . . . . . . . . . . . . . .  25
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  25





Pularikkal, et al.      Expires November 19, 2016               [Page 2]


Internet-Draft   Wi-Fi Calling Deployment Considerations        May 2016


1.  Introduction

   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.

2.  Terminology

   Service Provider (SP)






Pularikkal, et al.      Expires November 19, 2016               [Page 3]


Internet-Draft   Wi-Fi Calling Deployment Considerations        May 2016


      Refers to a provider of telecommunications services such as
      Broadband Operator or Mobile Operator.  An SP may provide several
      telecommunications services.

   APP

      Refers to computer program typically designed to run on Mobile
      devices such as smartphones and tablets.

   Wireless Fidelity (Wi-Fi)

      Technology that allows devices to wirelessly connect using 2.4 GHz
      and 5.0 GHz unlicensed radio bands.  Wi-Fi is defined as part of
      IEEE 802.11 standards

   Voice over Wi-Fi (VoWiFi)

      Any solution, which supports voice services over Wi-Fi.

   Mobile Network Operator (MNO)

      A wireless communications service provider who owns and operates
      licensed wireless access network and the backend infrastructure to
      offer mobile voice, data and multimedia services.

   3rd Generation Partnership Project (3GPP)

      3GPP unites seven telecommunications standards development
      organizations known as Organizational Partners and provides their
      members with a stable environment to produce the reports and
      specifications that define 3GPP technologies

   Groups Special Mobile Association (GSMA)

      GSMA represents the interests of mobile operators worldwide,
      uniting nearly 800 operators with more than 250 companies in the
      broader mobile ecosystem, including handset and device makers,
      software companies, equipment providers and internet companies, as
      well as organizations in adjacent industry sectors.

   User Equipment (UE)

      Term represents any device used directly by an end user to
      communicate.

   Wireless Local Area Network (WLAN)





Pularikkal, et al.      Expires November 19, 2016               [Page 4]


Internet-Draft   Wi-Fi Calling Deployment Considerations        May 2016


      Refers to IEEE 802.11 based Wi-Fi access networks and represents
      an extended service set consisting of multiple access points.

   Long Term Evolution (LTE)

      Is the fourth generation 3GPP standard set for wireless
      communication of mobile devices in end-to-end IP environment.

   Evolved Packet Core (EPC)

      Represents the Core Network in the 3GPP LTE system Architecture.

   Packet Data Network (PDN)

      PDN represents a network in the packet core a Mobile UE device
      wants to communicate with.  PDN generally is mapped to a set of
      related services.

   Access Point Name (APN)

      APN represents a set of services available to a specific PDN.
      Typically UE devices will be configured to access multiple APNs
      corresponding various services in the packet core.

   Trusted WLAN Access Gateway (TWAG)

      Performs the gateway function between a trusted WLAN access
      network and packet core.  It acts as the default gateway and DHCP
      Server for UE devices connected to the WLAN access network for
      trusted Wi-Fi to packet core integration model.

   Evolved Packet Data Gateway (ePDG)

      ePDG performs the gateway function between WLAN access network and
      Mobile Packet core in an untrusted model.  Main function of ePDG
      is to secure the data transmission with a UE connected to the EPC.

   PDN Gateway (P-GW)

      P-GW is the subscriber session anchor in EPC.  It enforces policy
      and also has a role in IP persistence in roaming scenarios.  Based
      up on the policy, P-GW steers traffic towards various PDN networks
      corresponding to various APNs.

   IP Multi-Media Subsystem (IMS)

      An Architectural framework for delivering IP multimedia services.
      And is defined in 3GPP



Pularikkal, et al.      Expires November 19, 2016               [Page 5]


Internet-Draft   Wi-Fi Calling Deployment Considerations        May 2016


   Policy and Charging Rule Function (PCRF)

      A system in EPC, which detects service data flows, applies
      policies and QoS to subscriber flows to and supports flow based
      charging

   Session Initiation Protocol (SIP)

      SIP is an application layer control protocol that can establish,
      modify and terminate multimedia sessions or calls.

   Real-time Transport Protocol (RTP)

      RTP is a transport protocol, which provides end-to-end delivery
      services for data with real-time characteristics such as
      interactive audio and video.

   Proxy Mobile IPv6 (PMIPv6)

      PMIPv6 is a network based mobility management protocol
      standardized by IETF and adopted in 3GPP.

   GPRS Tunneling Protocol (GTP)

      Group of IP based communications protocols used in 3GPP
      architectures.

   S2a Interface

      Is the interface between TWAG and P-GW and can be either GTP or
      PMIPv6 based

   S2b Interface

      Interface between ePDG and P-GW and can be either GTP or PMIPv6

3.  Architecture Overview

   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.






Pularikkal, et al.      Expires November 19, 2016               [Page 6]


Internet-Draft   Wi-Fi Calling Deployment Considerations        May 2016


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




Pularikkal, et al.      Expires November 19, 2016               [Page 7]


Internet-Draft   Wi-Fi Calling Deployment Considerations        May 2016


4.  Wi-Fi Calling Deployment Considerations

   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.

4.1.  Wi-Fi to Packet Core Integration

   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:

4.1.1.  Untrusted Model

   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.



























Pularikkal, et al.      Expires November 19, 2016               [Page 8]


Internet-Draft   Wi-Fi Calling Deployment Considerations        May 2016


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

4.1.2.  Hybrid Model

   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"



Pularikkal, et al.      Expires November 19, 2016               [Page 9]


Internet-Draft   Wi-Fi Calling Deployment Considerations        May 2016


   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





































Pularikkal, et al.      Expires November 19, 2016              [Page 10]


Internet-Draft   Wi-Fi Calling Deployment Considerations        May 2016


                                                  +------+   +---------+
                                                  | 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

4.1.3.  Trusted Model

   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





Pularikkal, et al.      Expires November 19, 2016              [Page 11]


Internet-Draft   Wi-Fi Calling Deployment Considerations        May 2016


                                                             +-------+
                                                             |  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







Pularikkal, et al.      Expires November 19, 2016              [Page 12]


Internet-Draft   Wi-Fi Calling Deployment Considerations        May 2016


4.1.4.  Model Selection Criteria

   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



Pularikkal, et al.      Expires November 19, 2016              [Page 13]


Internet-Draft   Wi-Fi Calling Deployment Considerations        May 2016


   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.

5.  Subscriber Onboarding into Wi-Fi Access Network

   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.

5.1.  Authentication and Identity Management

   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



Pularikkal, et al.      Expires November 19, 2016              [Page 14]


Internet-Draft   Wi-Fi Calling Deployment Considerations        May 2016


   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.

5.2.  Hotspot 2.0 for Seamless Onboarding

   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:


















Pularikkal, et al.      Expires November 19, 2016              [Page 15]


Internet-Draft   Wi-Fi Calling Deployment Considerations        May 2016


                              +----------------+
                              | 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



Pularikkal, et al.      Expires November 19, 2016              [Page 16]


Internet-Draft   Wi-Fi Calling Deployment Considerations        May 2016


   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.

5.2.1.  Hotspot 2.0 Inter-Operator Roaming for Wi-Fi Calling

   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.

6.  Wi-Fi calling deployment in restrictive networks

   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.














Pularikkal, et al.      Expires November 19, 2016              [Page 17]


Internet-Draft   Wi-Fi Calling Deployment Considerations        May 2016


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

7.  RF Network Performance Optimization

   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.

7.1.  Radio Resource Management

   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



Pularikkal, et al.      Expires November 19, 2016              [Page 18]


Internet-Draft   Wi-Fi Calling Deployment Considerations        May 2016


   influence the RF performance and will have a positive impact on
   network KPIs that influence the Wi-Fi calling experience.

7.2.  Wi-Fi Roaming Optimization

   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.

7.2.1.  Fast BSS Transition

   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.

7.2.2.  802.11k based Neighbor Reports

   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




Pularikkal, et al.      Expires November 19, 2016              [Page 19]


Internet-Draft   Wi-Fi Calling Deployment Considerations        May 2016


   802.11k along with Fast BSS transmission for optimum roaming
   performance.

7.2.3.  802.11v based Assisted Roaming and Load Balancing

   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.

8.  QoS Deployment Considerations for Wi-Fi Calling

   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.

8.1.  Wi-Fi Access Network QoS

   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.





Pularikkal, et al.      Expires November 19, 2016              [Page 20]


Internet-Draft   Wi-Fi Calling Deployment Considerations        May 2016


8.2.  End to End QoS

   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.




































Pularikkal, et al.      Expires November 19, 2016              [Page 21]


Internet-Draft   Wi-Fi Calling Deployment Considerations        May 2016


                    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.




Pularikkal, et al.      Expires November 19, 2016              [Page 22]


Internet-Draft   Wi-Fi Calling Deployment Considerations        May 2016


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

9.  Wi-Fi Calling Client Considerations

   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.

9.1.  Access Selection Criteria

   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



Pularikkal, et al.      Expires November 19, 2016              [Page 23]


Internet-Draft   Wi-Fi Calling Deployment Considerations        May 2016


   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.

9.2.  Inter-RAT Handover

   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.

9.3.  Congestion Management

   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



Pularikkal, et al.      Expires November 19, 2016              [Page 24]


Internet-Draft   Wi-Fi Calling Deployment Considerations        May 2016


   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.

10.  Informative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

Authors' Addresses

   Byju Pularikkal
   Cisco Systems
   170 West Tasman Drive
   San Jose
   United States

   Email: byjupg@cisco.com


   Tommy Pauly
   Apple Inc.
   1 Infinite Loop
   Cupertino, California  95014
   US

   Email: tpauly@apple.com


   Samy Touati
   Ericsson
   300 Holger Way
   San Jose, California  95134
   US

   Email: samy.touati@ericsson.com


   Mark Grayson
   Cisco Systems
   10 New Square Park
   Feltham
   United Kingdom

   Email: mgrayson@cisco.com



Pularikkal, et al.      Expires November 19, 2016              [Page 25]


Internet-Draft   Wi-Fi Calling Deployment Considerations        May 2016


   Sri Gundavelli
   Cisco Systems
   170 West Tasman Drive
   San Jose
   United States

   Email: sgundave@cisco.com












































Pularikkal, et al.      Expires November 19, 2016              [Page 26]


Html markup produced by rfcmarkup 1.124, available from https://tools.ietf.org/tools/rfcmarkup/