idnits 2.17.1 draft-pularikkal-opsawg-wifi-calling-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 3 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 1009: '...based on the MTU SHOULD be re-calculat...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 3, 2017) is 2488 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'IR51' is defined on line 1051, but no explicit reference was found in the text == Unused Reference: 'IR92' is defined on line 1054, but no explicit reference was found in the text == Unused Reference: 'RFC4066' is defined on line 1056, but no explicit reference was found in the text == Unused Reference: 'RFC4187' is defined on line 1061, but no explicit reference was found in the text == Unused Reference: 'RFC4555' is defined on line 1066, but no explicit reference was found in the text == Unused Reference: 'RFC4881' is defined on line 1070, but no explicit reference was found in the text == Unused Reference: 'RFC5213' is defined on line 1074, but no explicit reference was found in the text == Unused Reference: 'RFC5568' is defined on line 1079, but no explicit reference was found in the text == Unused Reference: 'RFC5944' is defined on line 1083, but no explicit reference was found in the text == Unused Reference: 'RFC6275' is defined on line 1087, but no explicit reference was found in the text == Unused Reference: 'RFC7296' is defined on line 1091, but no explicit reference was found in the text == Unused Reference: 'TS22228' is defined on line 1096, but no explicit reference was found in the text == Unused Reference: 'TS23402' is defined on line 1099, but no explicit reference was found in the text == Unused Reference: 'TS23852' is defined on line 1103, but no explicit reference was found in the text == Unused Reference: 'TS29273' is defined on line 1108, but no explicit reference was found in the text Summary: 4 errors (**), 0 flaws (~~), 16 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Operations and Management Area Working Group B. Pularikkal 3 Internet-Draft Cisco Systems 4 Intended status: Informational T. Pauly 5 Expires: January 4, 2018 Apple Inc. 6 M. Grayson 7 S. Gundavelli 8 Cisco Systems 9 S. Touati 10 Ericsson 11 July 3, 2017 13 Carrier Wi-Fi Calling Deployment Considerations 14 draft-pularikkal-opsawg-wifi-calling-03 16 Abstract 18 Carrier Wi-Fi Calling is a solution that allows mobile operators to 19 seamlessly offload mobile voice signaling and bearer traffic onto Wi- 20 Fi access networks, which may or may not be managed by the mobile 21 operators. Mobile data offload onto Wi-Fi access networks has 22 already become very common, as Wi-Fi access has become more 23 ubiquitous. However, the offload of mobile voice traffic onto Wi-Fi 24 networks has become prevalent only in recent years. This was 25 primarily driven by the native Wi-Fi Calling client support 26 introduced by device vendors. The objective of this document is to 27 provide a high level deployment reference to Mobile Operators and Wi- 28 Fi Operators on Carrier Wi-Fi Calling. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on January 4, 2018. 47 Copyright Notice 49 Copyright (c) 2017 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3. Architecture Overview . . . . . . . . . . . . . . . . . . . . 6 67 4. Wi-Fi Calling Deployment Considerations . . . . . . . . . . . 8 68 4.1. Wi-Fi to Packet Core Integration . . . . . . . . . . . . 8 69 4.1.1. Untrusted Model . . . . . . . . . . . . . . . . . . . 8 70 4.1.1.1. IPSec Tunnel Negotation . . . . . . . . . . . . . 9 71 4.1.2. Hybrid Model . . . . . . . . . . . . . . . . . . . . 10 72 4.1.3. Trusted Model . . . . . . . . . . . . . . . . . . . . 11 73 4.1.4. Model Selection Criteria . . . . . . . . . . . . . . 13 74 5. Subscriber Onboarding into Wi-Fi Access Network . . . . . . . 14 75 5.1. Authentication and Identity Management . . . . . . . . . 14 76 5.2. Hotspot 2.0 for Seamless Onboarding . . . . . . . . . . . 15 77 5.2.1. Hotspot 2.0 Inter-Operator Roaming for Wi-Fi Calling 17 78 6. Wi-Fi calling deployment in restrictive networks . . . . . . 17 79 7. RF Network Performance Optimization . . . . . . . . . . . . . 18 80 7.1. Radio Resource Management . . . . . . . . . . . . . . . . 18 81 7.2. Wi-Fi Roaming Optimization . . . . . . . . . . . . . . . 19 82 7.2.1. Fast BSS Transition . . . . . . . . . . . . . . . . . 19 83 7.2.2. 802.11k based Neighbor Reports . . . . . . . . . . . 19 84 7.2.3. 802.11v based Assisted Roaming and Load Balancing . . 20 85 8. QoS Deployment Considerations for Wi-Fi Calling . . . . . . . 20 86 8.1. Wi-Fi Access Network QoS . . . . . . . . . . . . . . . . 20 87 8.2. End to End QoS . . . . . . . . . . . . . . . . . . . . . 21 88 9. Wi-Fi Calling Client Considerations . . . . . . . . . . . . . 23 89 9.1. Access Selection Criteria . . . . . . . . . . . . . . . . 23 90 9.2. Inter-RAT Handover . . . . . . . . . . . . . . . . . . . 24 91 9.3. MTU Considerations . . . . . . . . . . . . . . . . . . . 24 92 9.4. Congestion Management . . . . . . . . . . . . . . . . . . 24 93 9.5. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 25 94 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 95 11. Informative References . . . . . . . . . . . . . . . . . . . 25 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 98 1. Introduction 100 There are several SP Managed and Over the Top Voice Solutions 101 deployed today which can leverage Wi-Fi access networks. Some of 102 these solutions rely on standalone applications installed on the 103 Mobile Handset and other Mobile devices such as tablets. Also there 104 are solutions, which leverage dedicated hardware built exclusively to 105 support Voice over Wi-Fi.e.g,in enterprise type environments. The 106 scope of this document is VoWiFi solutions, which are deployed by 107 Mobile Network Operators also known as Wireless Carriers. VoWiFi 108 from the context of Mobile Voice offload is often referred to as 109 Carrier Wi-Fi Calling. The deployment of Carrier Wi-Fi Calling 110 requires some kind of integration between the Wi-Fi Access network 111 and Mobile Packet Core. Carrier Wi-Fi calling solutions deployed 112 today predominantly uses an 'untrusted Wi-Fi'model that delivers 113 simple IP connectivity to facilitate Mobile Packet Core integration. 114 With this 'untrusted' approach, Mobile Operators are able to make use 115 of the existing Wi-Fi deployment footprint regardless of whether it 116 is owned by the MNOs or by their roaming partners or Wi-Fi Operators 117 without any kind of partnership with the MNOs. This model has 118 definitely allowed MNOs to accelerate the adoption of Wi-Fi calling. 119 However, this comes with some caveats, as depending on the Wi-Fi 120 network, there may be no visibility or control over it by the MNO, 121 impacting its ability to carry voice calls without compromising end 122 user experience. 124 It is in the interest of both MNOs as well as Wi-Fi Operators to 125 improve the quality of experience for Wi-Fi Calling delivered over a 126 Wi-Fi access network. MNOs have the incentive to make sure that the 127 end user experience does not get compromised while the voice service 128 is offloaded over Wi-Fi access. Wi-Fi operators have the business 129 incentive to enter into roaming partnerships with the MNOs and 130 support Wi-Fi calling with certain Service Level Agreements. In some 131 deployments, it is possible for the MNOs to own some Wi-Fi hotspot 132 deployments. In such cases, MNO will effectively be the Wi-Fi 133 operator as well. 135 Objective of this document is to provide a Carrier Wi-Fi Calling 136 deployment reference to Wi-Fi Operators and MNOs with primary focus 137 on the Wi-Fi Access Network and the Wi-Fi to Packet Core integration 138 aspects. 140 2. Terminology 142 Service Provider (SP) 144 Refers to a provider of telecommunications services such as 145 Broadband Operator or Mobile Operator. An SP may provide several 146 telecommunications services. 148 APP 150 Refers to computer program typically designed to run on Mobile 151 devices such as smartphones and tablets. 153 Wireless Fidelity (Wi-Fi) 155 Technology that allows devices to wirelessly connect using 2.4 GHz 156 and 5.0 GHz unlicensed radio bands. Wi-Fi is defined as part of 157 IEEE 802.11 standards 159 Voice over Wi-Fi (VoWiFi) 161 Any solution, which supports voice services over Wi-Fi. 163 Mobile Network Operator (MNO) 165 A wireless communications service provider who owns and operates 166 licensed wireless access network and the backend infrastructure to 167 offer mobile voice, data and multimedia services. 169 3rd Generation Partnership Project (3GPP) 171 3GPP unites seven telecommunications standards development 172 organizations known as Organizational Partners and provides their 173 members with a stable environment to produce the reports and 174 specifications that define 3GPP technologies 176 Groups Special Mobile Association (GSMA) 178 GSMA represents the interests of mobile operators worldwide, 179 uniting nearly 800 operators with more than 250 companies in the 180 broader mobile ecosystem, including handset and device makers, 181 software companies, equipment providers and internet companies, as 182 well as organizations in adjacent industry sectors. 184 User Equipment (UE) 186 Term represents any device used directly by an end user to 187 communicate. 189 Wireless Local Area Network (WLAN) 191 Refers to IEEE 802.11 based Wi-Fi access networks and represents 192 an extended service set consisting of multiple access points. 194 Long Term Evolution (LTE) 196 Is the fourth generation 3GPP standard set for wireless 197 communication of mobile devices in end-to-end IP environment. 199 Evolved Packet Core (EPC) 201 Represents the Core Network in the 3GPP LTE system Architecture. 203 Packet Data Network (PDN) 205 PDN represents a network in the packet core a Mobile UE device 206 wants to communicate with. PDN generally is mapped to a set of 207 related services. 209 Access Point Name (APN) 211 APN represents a set of services available to a specific PDN. 212 Typically UE devices will be configured to access multiple APNs 213 corresponding various services in the packet core. 215 Trusted WLAN Access Gateway (TWAG) 217 Performs the gateway function between a trusted WLAN access 218 network and packet core. It acts as the default gateway and DHCP 219 Server for UE devices connected to the WLAN access network for 220 trusted Wi-Fi to packet core integration model. 222 Evolved Packet Data Gateway (ePDG) 224 ePDG performs the gateway function between WLAN access network and 225 Mobile Packet core in an untrusted model. Main function of ePDG 226 is to secure the data transmission with a UE connected to the EPC. 228 PDN Gateway (P-GW) 230 P-GW is the subscriber session anchor in EPC. It enforces policy 231 and also has a role in IP persistence in roaming scenarios. Based 232 up on the policy, P-GW steers traffic towards various PDN networks 233 corresponding to various APNs. 235 IP Multi-Media Subsystem (IMS) 236 An Architectural framework for delivering IP multimedia services. 237 And is defined in 3GPP 239 Policy and Charging Rule Function (PCRF) 241 A system in EPC, which detects service data flows, applies 242 policies and QoS to subscriber flows to and supports flow based 243 charging 245 Session Initiation Protocol (SIP) 247 SIP is an application layer control protocol that can establish, 248 modify and terminate multimedia sessions or calls. 250 Real-time Transport Protocol (RTP) 252 RTP is a transport protocol, which provides end-to-end delivery 253 services for data with real-time characteristics such as 254 interactive audio and video. 256 Proxy Mobile IPv6 (PMIPv6) 258 PMIPv6 is a network based mobility management protocol 259 standardized by IETF and adopted in 3GPP. 261 GPRS Tunneling Protocol (GTP) 263 Group of IP based communications protocols used in 3GPP 264 architectures. 266 S2a Interface 268 Is the interface between TWAG and P-GW and can be either GTP or 269 PMIPv6 based 271 S2b Interface 273 Interface between ePDG and P-GW and can be either GTP or PMIPv6 275 3. Architecture Overview 277 This section provides a very high level overview of the end-to-end 278 Architecture for Carrier Wi-Fi Calling. It is outside the scope of 279 this document to provide a detailed Architecture description, as all 280 the functional entities and the protocol interfaces are well defined 281 in the 3GPP and GSMA specifications [3GPPTS23.402,GSMAIR61,GSMAIR51]. 282 Figure-01 below is used to describe the Architecture components at a 283 high level. 285 +-----+ +-----+ 286 | 3GPP+-----+ HSS | 287 | AAA | +-----+ 288 +-----+ 289 | 290 | +-----+ 291 | | PCRF| 292 | +-----+ 293 | | 294 +-------+ | 295 +---+ +-----+ Backhaul| TWAG /| +-----+ 296 |UE +---+WLAN +----------+ ePDG +----+ PGW | 297 +---+ +-----+ | | +-----+ 298 +-------+ | 299 | 300 +-----+ 301 | IMS | 302 +-----+ 304 Figure 1: High Level Architecture 306 The UE is the end user device such as a smartphone running native Wi- 307 Fi Calling client. The UE is connected to a Wi-Fi access network, 308 which is represented by the block WLAN in the diagram. Depending up 309 on the trust model, TWAG or ePDG gateway is used to integrate the 310 WLAN access network to the MNO packet core.More details around this 311 untrusted and trusted approaches are covered in the next section. 312 The P-GW acts as the common anchor for the subscriber sessions 313 regardless of whether the UE is connected to Wi-Fi or LTE (not 314 shown), allowing the preservation of the IP Session during a handover 315 between LTE and Wi-Fi. IMS provides several functions related to SIP 316 based call control signaling, namely SIP authentication, basic 317 telephony services, supplementary services, interworking with other 318 IMS systems, and offload into circuit switched voice networks. In 319 addition to voice, the same IMS infrastructure may be leveraged for 320 other multi-media functions such as video calling. The IMS framework 321 consists of several functional entities and is omitted for the sake 322 of simplicity here. PCRF performs classical Policy and Charging Rule 323 functions in the Mobile Packet Core. For the Wi-Fi calling solution, 324 it will trigger the establishment of the default and dedicated 325 bearers on the S2a or S2b interfaces for SIP and RTP traffic between 326 the PGW and the TWAG/ePDG. 328 4. Wi-Fi Calling Deployment Considerations 330 This section covers deployment considerations for an end-to-end Wi-Fi 331 calling Architecture that can influence the quality of experience, 332 availability and monetization aspects of the solution offering. 334 4.1. Wi-Fi to Packet Core Integration 336 There are three different Architecture options available for Wi-Fi to 337 Packet Core integration for the deployment of Wi-Fi calling. Each of 338 these models are described in the sub-sections below: 340 4.1.1. Untrusted Model 342 This model is built around the assumption that the Wi-Fi access 343 network is 'unmanaged' or untrusted from the MNOs perspective. Since 344 this model does not rely on any security or data privacy 345 implementations on the Wi-Fi access network, it requires the 346 establishment of an IPSec tunnel between the UE device and the Mobile 347 Packet Core. The ePDG gateway acts as the IPSec tunnel termination 348 point on the packet core side. The ePDG handles the user 349 authentication as well as the establishment of an S2b packet data 350 network connection towards the P-GW using the GTP based S2b 351 interface. This Architecture model is illustrated in figure-2 below. 353 +--------------+ +----------+ +-------+ 354 | +----------+ | IMS-APN | | | | 355 | | SWu | | Traffic | | | | 356 | | Client +------------------------------------+ | 357 | | | | Other APN | | | ePDG | 358 | | | | traffic | | | | 359 | | +------------------------------------+ | 360 | | | | | | +-------+ 361 | +----------+ | | | | | 362 | | | | S2b| |S2b 363 | UE | | WLAN | | +---+ 364 | | | Access | | | 365 | +----------+ | LBO | | +-------+ +-------+ 366 | | Native | | Traffic | | |IMS APN| | Other | 367 | | | | | | | PGW | | APN | 368 | | Client +-------------------+ | | | | PGW | 369 | | | | | | | +-------+ +-------+ 370 | +----------+ | | | | | | 371 +--------------+ +----------+ | | 372 | | | 373 | +-------+ +-------+ 374 | | IMS | | App | 375 | | | | Server| 376 v +-------+ +-------+ 378 Figure 2: Untrusted Wi-Fi to Packet Core Integration Model for Wi-Fi 379 Calling 381 The Wi-Fi calling client implementation uses the ePDG client for IMS 382 APN while the default PDN or Internet APN traffic is locally 383 offloaded (Local Breakout LBO) into the Wi-Fi access network. The 384 "untrusted Wi-Fi" architecture supports multiple APN over SWu, 385 allowing the MNO to also route specific applications traffic 386 associated with one or more APN through the Packet Core, in addition 387 to the IMS APN, if required. 389 4.1.1.1. IPSec Tunnel Negotation 391 The IPSec tunnel from the UE to the ePDG is negotiated using IKEv2. 392 The parameters for tunnel negotation in Wi-Fi Calling are as follows: 394 o The Initiator Identifier (IDi) will be in ID_RFC822_ADDR (email 395 address) form, and be based on the UE's IMSI@Realm. 397 o The Responder Identifier (IDr) will be in ID_FQDN form, and be the 398 APN name that the tunnel should access through the ePDG. 400 o EAP should be used for mutual authentication. When on a device 401 with a SIM card, EAP-AKA should be used. On other devices, EAP- 402 TLS is preferred. EAP-Only authentication (in which the server 403 certificate is not sent in an CERT payload) may be used to reduce 404 packet size, but only with mutually authenticating EAP types such 405 as EAP-AKA or EAP-TLS. 407 o Strong encryption and authentication algorithms should be used, 408 such as ENCR_AES_CBC, PRF_HMAC_SHA2_256, AUTH_HMAC_SHA2_256_128, 409 and Diffie-Hellman Group 14. 411 o The Configuration Request should specify an IPv4 or IPv6 addresses 412 used for handover. The UE may also request ePDG-specific 413 attributes such as P_CSCF_IP4_ADDRESS and P_CSCF_IP6_ADDRESS. 415 4.1.2. Hybrid Model 417 3GPP TS 23.402 also defines the concept of "trusted Wi-Fi" 418 architecture, providing another method to integrate with the packet 419 core. The trustworthiness of an access network itself is left to the 420 MNO to decide, but it generally relies on some level of control by 421 the MNO of the Wi-Fi access network either in a direct or indirect 422 manner. One of the key characteristics of the "Trusted Wi-Fi" 423 architecture as defined in 3GPP Release 11, is the client-less 424 approach to support the packet core integration. This solution 425 lacked the support for multiple APNs signaling for the UE when over 426 the Wi-Fi access network, therefore all Wi-Fi offloaded traffic was 427 assumed to be part of the default PDN or Internet APN. With this 428 limitation, Wi-Fi calling cannot be supported as it require its own 429 IMS APN. The hybrid architecture proposed here combines the 3GPP 430 release 11 "trusted Wi-Fi" architecture, with the ePDG based 431 untrusted Wi-Fi architecture. This hybrid model simultaneously 432 supports IMS and other applications specific APNs using the untrusted 433 Wi-Fi model, with the TWAG selectively offloading their traffic, 434 while using the S2a interface for all other default PDN traffic 435 toward the default PGW. This Architecture model is illustrated in 436 figure 3 below 437 +------+ +---------+ 438 | IMS | | Other | 439 | Core | |Services | 440 +------+ +---------+ 441 | | 442 +------+ +-------+ 443 +--------------+ +-----------+ |IMS | | Other | 444 | +----------+ | | | |P-GW | | P-GW | 445 | | SWu | | | +-------+ | +------+ +-------+ 446 | | Client | | | |SIPTO | | | | 447 | | | | | ++NAT | | | +--------+ 448 | +----------+ | | +-------+ | | | 449 | | | | +------+ 450 | UE +------+ TWAG | S2b | ePDG | 451 | | | +--------+ | 452 | +----------+ | | | +------+ 453 | | Native | | | | 454 | | Client | | | | 455 | | | | | | S2a +-------+ 456 | +----------+ | | +--------+Default| 457 +--------------+ +-----------+ | PGW | 458 +-------+ 459 | 460 | 461 + 462 XXXXXXXX 463 XX XX 464 X X 465 XInternetX 466 X X 467 XX XX 468 XXXXXXX 470 Figure 3: Hybrid Wi-Fi to Packet Core integration model for Wi-Fi 471 calling 473 4.1.3. Trusted Model 475 Enhancements introduced in 3GPP release 12 SaMOG specifications 476 provides the ability to support multiple APN over Wi-Fi access making 477 the support of Wi-Fi calling, and other applications specific APNs 478 possible without the need for IPSec connectivity between the UE and 479 the Packet core. This Architecture model is illustrated in figure 4 480 below 481 +-------+ 482 | IMS | 483 | Core | 484 +-------------+ +-----------+ +-------+ 485 | | | | | 486 | +--------+ | Flow mapped | | | 487 | |IMS APN | | to VMAC-01 | | +-------+ 488 | | +-----------------+ | |IMS APN| 489 | |Client | | | +-------+ P-GW | 490 | +--------+ | | | +-------+ 491 | | | | 492 | | |Release 12 | 493 | | | TWAG | 494 | | | | +-------+ 495 | | | | |Default| 496 | | | +-------+ APN | 497 | +--------+ | Flow mapped | | | P-GW | 498 | |Default | | to VMAC-02 | | +-------+ 499 | | APN +-----------------+ | | 500 | |Client | | | | | 501 | +--------+ | | | | 502 +-------------+ +-----------+ | 503 XXXXXX 504 XX XXX 505 XX XX 506 X X 507 X X 508 X Internet X 509 X X 510 X XX 511 X XX 512 XX XXXX 513 XXXXXX 515 Figure 4: Trusted Wi-Fi to Packet Core integration model for Wi-Fi 516 calling 518 4.1.4. Model Selection Criteria 520 Each of the Wi-Fi to Packet Core Architecture models described in the 521 previous sections comes with its own pros and cons. And selection of 522 a specific architecture model depends on several factors. Some of 523 these factors, which can help determine the appropriate model, are 524 listed below: 526 *Wi-Fi Access Network Ownership: There are several ownership models 527 available when it comes to Wi-Fi to packet core integration. Wi-Fi 528 Access network may be deployed by the MNO to leverage as another RAT 529 to complement 3G and LTE. Alternatively the Mobile Network Operator 530 may deploy a Managed Wi-Fi network for the Enterprise and SMB 531 customers. The MNO managed Wi-Fi footprint is only portion of the 532 overall Wi-Fi deployment. Third parties such as broadband service 533 providers today own a significant portion of the Wi-Fi access 534 network. For third party owned Wi-Fi access, the Mobile Network 535 Operator may or may not have a direct roaming partnership with the 536 Wi-Fi operator. The ownership model influences the choice of packet 537 core integration architecture. 539 *Backhaul Network Ownership: From the context of this discussion 540 here, the backhaul refers to the connectivity between WLAN Access 541 network and the Packet core. It consists of a combination of wired 542 access network of the hotspot, Broadband access last mile, Wi-Fi 543 operator core network, Internet etc. These connectivity aspects will 544 be deciding factor for the choice of Wi-Fi packet integration model. 545 For example, Wi-Fi access network may be owned and or operated by the 546 MNO, but if the backhaul involved a third party connection or 547 Internet where MNO does not have control over security and QoS, an 548 untrusted packet core integration may be the viable solution. 550 *Mobile Offload Requirements: Choice of the Wi-Fi to packet core 551 integration model is not only influenced by voice offload but data 552 offload as well. The untrusted Wi-Fi and the hybrid architectures do 553 support a flexible offload model, allowing the Mobile Network 554 Operator to choose which traffic to backhaul to the Mobile Packet 555 Core to provide charging and added value services, while also 556 leveraging local breakout capabilities on the device. Using the 557 untrusted, and when applicable, the hybrid models allow the Mobile 558 Network Operator to leverage their deployed network architecture for 559 Wi-Fi calling. This makes both the hybrid and the untrusted Wi-Fi 560 architectures valid options to consider depending on the Wi-Fi 561 network ownership requirements. 563 *Device Capabilities: This greatly influences the choice of Wi-Fi to 564 packet core integration. For example, a trusted approach with 565 multiple PDN support requires the capability on the device to comply 566 with 3GPP release 12 SaMOG enhancements, while the untrusted or 567 hybrid model can leverage existing implementations and do provide a 568 similar level of functionality. 570 *Support of Non-SIM devices: The MNO can provide value-added 571 services, including voice services on Non-SIM devices The Untrusted 572 Wi-Fi architecture is compatible with Non-SIM devices and provide the 573 same capabilities to these devices as for the SIM devices. 575 *Network Readiness: This is another influencing factor for the choice 576 of the trust model, as there are dependencies on the Packet Core 577 network elements as well as Wi-Fi access network for the 578 implementation of these models. 580 5. Subscriber Onboarding into Wi-Fi Access Network 582 Subscriber onboarding into a Wi-Fi access network is the process of 583 getting connected to a WLAN access network and be able to offload 584 mobile traffic successfully. In order to provide a seamless end user 585 experience for Wi-Fi calling, the handset should be able to get 586 connected to the WLAN with minimum or no user interaction. A 587 seamless WLAN onboarding is critical for the smooth hand off of the 588 voice call from LTE to Wi-Fi. There are several factors, which can 589 influence the Wi-Fi onboarding experience. Proper choice of the 590 available deployment options can ensure the subscriber onboarding 591 experience is quite seamless. 593 5.1. Authentication and Identity Management 595 Before the UE device can successfully get associated with a WLAN 596 access network it needs to get authenticated with the WLAN network. 597 There are several types of user authentication options in use such as 598 Web Portal based authentication, EAP-TTLS, EAP-TLS, EAP-SIM, EAP-AKA 599 etc. Choice of the authentication mechanism depends up on the 600 deployment preferences of the Wi-Fi operator. Web portal based 601 authentication relies on an Open SSID configuration. Once the portal 602 has successfully authenticated the UE device, the traffic is carried 603 over the WLAN air interface without any encryption. EAP 604 authentication mechanisms relies on secured SSIDs mandate the 802.11i 605 based air encryption of the subscriber data in the WLAN access 606 network. 608 In order to support Wi-Fi calling, one of the EAP based mechanisms 609 will be preferred over the web portal based authentication. In the 610 case of Web based authentication, the user needs to manually enter 611 the username and password credentials or in some cases sign up for a 612 service via Operator portal. But with any of the EAP methods, once 613 the credentials have been established on the UE device, then 614 authentication happens automatically without user intervention and 615 greatly improves the onboarding experience. 617 If the Wi-Fi operator decides to use a secured SSID for subscriber 618 authentication, choice of the EAP method depends up on the business 619 model. A Standalone Wi-Fi operator may need to rely on non-SIM based 620 EAP authentication mechanisms such as EAP-TTLS or EAP-TLS for their 621 home subscribers. A Wi-Fi operator who has a roaming partnership 622 with an MNO could allow the uSIM credentials of the MNO subscriber to 623 be used for the access. In this case, the Wi-Fi operator will act as 624 a proxy and authenticate the customer credentials with the MNO HSS. 626 Identity management deals with establishing subscriber identity and 627 associated credentials on the UE device for WLAN onboarding. 628 Identity management and authentication goes hand in hand. Option 629 leverages the same set of identity and credentials (unified identity) 630 for WLAN onboarding and packet core connectivity will simplify the 631 identity management for Wi-Fi calling. However this requires that 632 the WLAN access network is either owned by the MNO or by their 633 roaming partner. With unified identity, typically uSIM credentials 634 will be leveraged for both WLAN onboarding as well as packet core 635 connectivity for SIM devices, and an EAP method used for Non-SIM 636 devices. 638 5.2. Hotspot 2.0 for Seamless Onboarding 640 Ability for a handset to Seamlessly get connected to WLAN access 641 network is one of the key factors which will influence the overall 642 subscriber experience with Wi-Fi calling. Passpoint specifications 643 defined by the Wi-Fi alliance under the Hotspot 2.0 program supports 644 automatic discovery, selection and onboarding of Wi-Fi clients on to 645 a compatible Wi-Fi access network. Figure-5 below is used to 646 illustrate the hotspot 2.0 solution at a high level: 648 +----------------+ 649 | Wi-Fi Operator | 650 | AAA Server / | 651 | AAA Proxy | 652 | | 653 +----------------+ 654 | 655 | 656 | 657 +----------------+ XXXXX 658 +-----------+ | | XXX XXX 659 | | | +----------+ | XX XX 660 | | | | ANQP | | XX XXX 661 | UE | | | Server | | X XX 662 | | | | | | XX Roaming X 663 | +-------+ +------+ +----------+ +---------XXInterconnectXX 664 | | ANQP | | | | XX X 665 | | Client| | | | XX XX 666 | | | | | +----------+ | XX XXX 667 | +-------+ | | | AP/AC | | XX XX 668 +-----------+ | | | | XXX XXX 669 | +----------+ | X+X 670 +----------------+ | 671 | | 672 | | 673 | +------------+ 674 XXXXX | MNO | 675 XX XXX | AAA Server | 676 X XX | | 677 XX XX +------------+ 678 X External X | 679 XX Network XX | 680 X Access X | 681 XX XX +------------+ 682 XX XX | HSS | 683 XX XXX | | 684 XXXX XXX +------------+ 685 XXXX 687 Figure 5: Hotspot 2.0 with Service Provider Roaming 689 ANQP server is the component, which assists with the automatic 690 discovery of WLAN network resources by the UE device. ANQP server is 691 typically collocated on the Access Point (AP) or the Access 692 Controller (AC). A Hotspot 2.0 compatible UE device will have a 693 built in ANQP client. When a UE roams into the coverage area of a 694 Hotspot 2.0 enabled network, it automatically learns about the 695 network capability via Beacon or Probe Response. Then UE requests a 696 set of network and service level information from the WLAN network. 697 Based up on the info UE can decide which WLAN access is the most 698 preferred and the type credentials it can use for getting connected. 700 5.2.1. Hotspot 2.0 Inter-Operator Roaming for Wi-Fi Calling 702 MNOs can enter into roaming partnership, which will allow Wi-Fi 703 calling clients to automatically get connected to the WLAN access. 704 This also allows the devices to leverage uSIM credentials or EAP 705 credentials for Non-SIM devices for getting authenticated with the 706 WLAN network. The Wi-Fi operator AAA will function as a proxy in 707 this case and completes the authentication by interfacing with the 708 MNO AAA Server and HSS, for EAP_SIM/EAP_AKA in the MNO packet core. 710 6. Wi-Fi calling deployment in restrictive networks 712 The use of IPSec to establish a connection to the ePDG, require that 713 the access network allow IPSec tunnel establishment. But some 714 networks won't allow IPSec traffic either as a security policy or as 715 a side-effect of only allowing "web traffic". In addition, many 716 mainly corporate environments do deploy an HTTP proxy which will also 717 prevent the establishment of an IPSec tunnel. Performing changes to 718 these deployments may not always be possible or cost effective for 719 the corporation or the public venues, especially in an "Untrusted Wi- 720 Fi" model without the MNO involvement. In such situations, the 721 mobile device can leverage the IPSec TCP encapsulation as described 722 in draft-pauly-ipsecme-tcp-encaps-04 and in 3GPP TS 24302, which 723 define the encapsulation of IPsec traffic in TCP. The Mobile device 724 shall enable the TCP encapsulation only after failling to establish 725 an IPSec connection to the ePDG. Figure 6 below shows the TCP 726 encapsulation with the use for TLS to traverse a Proxy and reach the 727 ePDG. 729 +------------+ +----------+ +-------+ 730 | +--------+ | TCP with HTTP | | TCP with TLS | | 731 | | SWu +===================+==========+=================+ | 732 | | Client ------------------------------------IPSEC------- | 733 | | +===================+==========+=================+ ePDG | 734 | |Proxy | | then TLS | Proxy | | | 735 | |Config | | through proxy | Firewall | +-------+ 736 | +--------+ | +----------+ | 737 | UE | | 738 +------------+ +-------+ 739 | | 740 | IMS | 741 | PGW | 742 +-------+ 744 Figure 6: Use of TCP encapsulation for IPSec 746 When an HTTP proxy is deployed, the UE should connect to the eDPG 747 through the proxy and then establish a TLS connection toward the 748 ePDG. TLS is not used for securing the link, but to traverse the 749 HTTP Proxy, and is configured with NULL-Cipher. This model allows 750 Wi-Fi calling to operate even in restrictive networks. 752 7. RF Network Performance Optimization 754 Quality of the Wi-Fi calling experience would be as good or as bad as 755 Radio network itself. Three network performance KPIs which impact 756 the quality of voice are latency, jitter and packet drops. A healthy 757 network is critical to ensure that these KPIs will meet the 758 thresholds allowed to meet the acceptable voice quality. This 759 section primarily talks about various performance optimization 760 mechanisms available on the Wi-Fi Radio network. 762 7.1. Radio Resource Management 764 Radio Resource Management (RRM) aka Wi-Fi SON refers to the co- 765 ordinated fine-tuning of the various RF network parameters among 766 access points connected in a Wi-Fi network. It is very typical for 767 Wi-Fi deployments from multiple operators to co-exist in the same 768 hotspot. Scope RF fine tuning will be limited to the access points 769 which are managed by the same operator in a specific hotspot. RRM 770 fine-tuning will be typically performed by a centralized entity such 771 as Access Controller. Some deployments which may not leverage AC 772 such as Residential Gateways could leverage a cloud based RRM or SON 773 Server. RRM controller continuously analyze the existing RF 774 environment automatically adjust the power and channel configurations 775 of access points to help mitigate issues such as co-channel interface 776 and signal coverage. A proper implementation of RRM can greatly 777 influence the RF performance and will have a positive impact on 778 network KPIs that influence the Wi-Fi calling experience. 780 7.2. Wi-Fi Roaming Optimization 782 Roaming from the context of the discussion here refers to the hand of 783 of a UE device from one Access Point to another Access Point in the 784 same Extended Services Set (ESS) or mobility domain. Unlike cellular 785 roaming between base stations, which is initiated by the network, in 786 Wi-Fi the roaming is initiated by the UE device. A UE typically 787 decides to disconnect from the current access point when some of the 788 RF measurements such as RSSI, SNR etc. drops below certain threshold. 789 There are other APs in the range with acceptable measurements the UE 790 will start re-association process with one of the target APs. End 791 user experience for a Wi-Fi call, which is active at the time of the 792 hand off, will depend up on multiple factors. One critical factor is 793 the time taken for the UE traffic to resume during the hand off. 794 Also it is important that UE is able to make the optimum selection of 795 the target AP from the list of available APs in the range. Discussed 796 below are few IEEE 802.11 based mechanisms available to optimize the 797 roaming. 799 7.2.1. Fast BSS Transition 801 IEEE 802.11r based fast BSS transition (FT) helps reduce the handoff 802 time for a UE when it roams from one AP to another with in an ESS, 803 which is enabled, with an EAP based authentication. Without FT, the 804 UE will have to go through the full authentication process with the 805 RADIUS server and device fresh set of encryption for 802.11i air 806 encryption. When FT is enabled, the client will have an initial 807 handshake with the target AP while still connected to the original 808 AP. This handshake allows client and target APs to derive the 809 encryption keys in advance to reduce the hand off time. Fast 810 Transition can significantly improve the end user experience for the 811 voice calls, which are active during a hand off. 813 7.2.2. 802.11k based Neighbor Reports 815 IEEE 802.11k enhancements allow a UE device to request from the 816 current AP to which it is connected for a recommended list of 817 neighboring APs for roaming. Up on receiving the client request, the 818 AP responds with a list of neighbors on the same WLAN with the Wi-Fi 819 channel numbers. Neighbor list is created by the AP based up on the 820 Radio Resource Measurements and includes the best potential roaming 821 targets for the UE. Neighbor list allows UE to reduce the scanning 822 time when it is time to roam into a new AP in the same WLAN and there 823 by improves the roaming performance. It is recommended to enable 824 802.11k along with Fast BSS transmission for optimum roaming 825 performance. 827 7.2.3. 802.11v based Assisted Roaming and Load Balancing 829 Typical WLAN deployments will have APs with overlapping coverage 830 areas. This is done on purpose to seamless handoff and also to 831 address capacity requirements. Load distribution of UEs in the same 832 coverage area may be helpful to proactively manage the bandwidth 833 requirements and there by improve the subscriber experience. In the 834 most rudimentary form, some of the load balancing solutions relies on 835 the brute force method of ignoring the association requests from a UE 836 by the APs with high load. Another more sophisticated mechanism is 837 to leverage 802.11v based network assisted roaming. 802.11v allows 838 unsolicited BSS transmission management messages from AP towards the 839 client with a list of preferred APs to make roaming decisions. If 840 the AP is experiencing high load, or bad connectivity from the client 841 it may send an unsolicited BSS transmission management frame with the 842 recommended list of APs to roam into. Depending up on the client 843 implementation, it may or may not honor this info while making oaming 844 decisions. 846 8. QoS Deployment Considerations for Wi-Fi Calling 848 This section covers the traffic prioritization mechanisms available 849 in various segments of the overall traffic path of the Wi-Fi calling 850 signaling and bearer sessions. Flexibility control of the QoS 851 implementations will depend up on various factors such as ownership 852 and management of the WLAN access network, Wi-Fi to packet core 853 integration model etc. 855 8.1. Wi-Fi Access Network QoS 857 Traffic prioritization in the WLAN for Carrier Wi-Fi calls can be 858 achieved by implementing Wi-Fi Multimedia (WMM). WMM consists of a 859 subset of IEEE 802.11e enhancements for Wi-Fi. WMM defines four 860 Access Categories, AC1, AC2, AC3 and AC4. AC1 is mapped against 861 voice, AC2 is mapped against video, AC3 is mapped against best effort 862 traffic and AC3 is mapped against Background traffic. Each of these 863 Access Categories is mapped against one or more 802.11e User Priority 864 (UP) values. UP has range from 0 to 7. Higher UP values typically 865 gets more expedited over the air treatment EDCA mechanism for channel 866 access defined in 802.11e is modified to make sure that traffic in 867 higher UP queues get higher priority treatment. WMM can only 868 leveraged if the client can do the right classification and Access 869 points also support it. 871 8.2. End to End QoS 873 While QoS on the WLAN access network is critical, that by it may not 874 be sufficient to maintain the subscriber quality of experience. It 875 is important to enable QoS prioritization across all the network 876 segments, which form part of the end-to-end voice path. Flexibility 877 of the QoS implementation along the network segments will depend up 878 on the trust models, which are discussed earlier. For example, if 879 the transit path between WLAN network and Packet Core is include 880 Internet, no QoS prioritization can be implemented over the Internet 881 backhaul. How ever for deployment scenarios in which all network 882 segments along the voice traffic path are managed either by the 883 Mobile operator or their partners, then it makes much easier to 884 implement end to end QoS. End to end QoS Classification for Wi-Fi 885 calling is illustrated in figure 7 below. 887 Voice UP 6 Voice DSCP 46 888 Voice Sig. UP 4 Voice Sig. DSCP 24 890 +--------------+ +---------------+ 891 | WMM or WMM+AC| | DiffSrv QoS | 892 | | | | 893 v v v v 895 +----+ +--------+ +--------+ 896 | | | WLAN | | | 897 | | | | | | 898 | UE | | +----+ | | TWAG/ | 899 | +-----------+ | AP/| +---------+ ePDG | <------+ 900 | | | | AC | | | | | 901 | | | +----+ | | | | 902 +----+ +--------+ +--------+ | 903 | Dedictated | 904 Voice QCI 1| and | 905 Sig. QCI 5 | Default | 906 | Bearers | 907 | | 908 +--------+ <------+ 909 | | 910 | P+GW | 911 | | <------+ 912 +--------+ | 913 | | 914 | DiffSrv | 915 | QoS | 916 | | 917 +--------+ | 918 | | | 919 | IMS | <------+ 920 | | 921 +--------+ 923 Figure 7: End-to-end QoS Reference Model 925 This QOS reference model assumes that, MNO or their roaming partners 926 manage all the segments in the end-to-end path for voice signaling 927 and voice bearer traffic. Model also assumes that transit path 928 between WLAN and Packet core is private and secured and does not 929 traverse Internet. 931 QoS reference model leverages WLAN access network leverages WMM that 932 is described in the previous section, UP value of 6 is typically used 933 for voice bearer traffic and UP value of 4 is used for voice 934 signaling traffic. In order for voice to get the proper 935 prioritization, WMM needs to be supported and enabled on both UE and 936 the WLAN network. 938 In the transit IP network between WLAN and packet core, DSCP based 939 QoS prioritization can be deployed if the connectivity is part of a 940 managed transport. DSCP value of 46 is typically used for marking 941 voice bearer and DSCP value of 24 is typically used for marking voice 942 signaling. Proper traffic prioritization will depend up on whether 943 DiffSrv QoS is enabled in the transit network. 945 Between P-GW and ePDG or TWAG, dedicated bearer with QCI value 1 will 946 be established dynamically for voice calls. For signaling traffic a 947 default bearer with QCI value of 5 will be used. These QCI values 948 are mapped against specific QoS SLAs and allocation retention 949 policies (ARP). 951 9. Wi-Fi Calling Client Considerations 953 Wi-Fi Calling client device functionality requirements depend on the 954 on the models used for WLAN to packet core integration. At a minimum 955 the clients should support IMS User Agent as defined in the 3GPP spec 956 and be able to send and receive both IMS signaling and bearer traffic 957 over a Wi-Fi access point. In addition, an SWu client that supports 958 IPSec will can use ePDG-based packet core integration. This section 959 talks about some of the client side implementation considerations for 960 Wi-Fi calling. 962 9.1. Access Selection Criteria 964 The client device must select which RAT (cellular or Wi-Fi) it will 965 use for communication to the cellular network. Commonly deployed 966 access selection criteria is described below: 968 Device Local Policy Profile: In this case, the logic is defined by 969 locally configured policy. Local policy may allow the end user to 970 set prereferences. It is also possible for carriers to push these 971 profiles to the device. Some MNOs may prefer cellular instead of Wi- 972 Fi for voice service when both RAT technologies are available. Some 973 other carriers may have Wi-Fi preferred approach for IMS APN when 974 both RAT technologies are available. If Passpoint is enabled on the 975 Wi-Fi access network, the client may take into account network 976 loading conditions learned from the ANQP server to decide whether to 977 offload IMS traffic into the Wi-Fi network. 979 9.2. Inter-RAT Handover 981 Inter-RAT handover refers to the handover of an active voice call 982 without service disruption when the UE switches out from one RAT 983 technology to another. Implementations must support handovers 984 between Wi-Fi and LTE. 986 Handover between LTE and Wi-Fi is acheived by maintaining IP or IPv6 987 addresses between the LTE interface and the IPSec tunnel over Wi-Fi. 988 If the IPSec tunnel is negotiated while a call is already in 989 progress, the IKEv2 Configuration Request should specify the local 990 address of the LTE interface in order to get assigned the same 991 address on the IPSec tunnel. Similarly, handover from an IPSec 992 tunnel over Wi-Fi to LTE requires the LTE interface to be brought up 993 with the same address as the tunnel. Maintaining the address allows 994 the client to not interrupt TCP or UDP connections that are using the 995 local address for communication. In a system that uses POSIX 996 sockets, for example, the handover must be done in such a way that 997 the sockets do not need to be closed and re-opened. 999 9.3. MTU Considerations 1001 When handing over between LTE and IPSec tunnels over Wi-Fi, the 1002 client device should be aware of the Maximum Transmission Unit (MTU) 1003 of each interface. It is possible that the effective MTU for the 1004 IPSec tunnel (which can be calculated as the MTU of the Wi-Fi 1005 interface minus the overhead for ESP encryption) is notably smaller 1006 than the effective MTU of the LTE interface. For UDP flows, they 1007 should avoid sending large datagrams that could get fragmented when 1008 handing over between RATs. For TCP flows, the Maximum Segment Size 1009 based on the MTU SHOULD be re-calculated upon handover. 1011 9.4. Congestion Management 1013 Radio Network Performance management and QoS considerations described 1014 earlier can significantly contribute to the overall QoE for Wi-Fi 1015 calling. A client driven congestion management mechanism can 1016 positively augment the overall experience. The idea is to 1017 dynamically change the bandwidth requirements for the call based up 1018 on the network congestion conditions. Network resource requirements 1019 (bandwidth, packets per second etc.) per call are directly 1020 proportional to the type of codec and the packetization rate. 1021 Sometimes it may be desirable to switch out to a lower audio codec to 1022 keep the drop, delay and jitter characteristics under acceptable 1023 levels during periods of network congestion. Explicit Congestion 1024 Notification for RTP over UDP defined in RFC 6679 can be used to 1025 inform network congestion to the end clients. But this requires the 1026 network elements to mark the ECN bits on the IP header of the packet 1027 when congestion conditions are encountered. 1029 9.5. NAT Traversal 1031 Since NATs are very commonly deployed primarily due to the shortage 1032 of IPv4 address space, a client side implementation should support 1033 NAT traversal for Wi-Fi calling. IPSec implementation on the client 1034 side should support the detection of NAT gateways as defined in RFC 1035 7296 specification. If a NAT gateway is detected, client should send 1036 all subsequent IPSec traffic from port 4500. If NAT is detected ESP 1037 packets must be UDP encapsulation using port 4500. If NAT devices 1038 are not detected, SWu may use pure ESP encapsulation without UDP. It 1039 is important to understand the implications on firewall rules with 1040 and without NAT so that the Wi-Fi calling does not get blocked by the 1041 firewall. Many deployments may allow ESP with UDP encapsulation by 1042 default but may block ESP only tunnels. 1044 10. Acknowledgements 1046 Authors would like to acknowledge the inputs and advice provided by 1047 Eduardo Abrantes and Ajoy Singh. 1049 11. Informative References 1051 [IR51] "IMS Profile for Voice, Video and SMS over untrusted Wi-Fi 1052 access Version 5.0", 2017. 1054 [IR92] "IMS Profile for Voice and SMS Version 10.0", 2016. 1056 [RFC4066] Liebsch, M., Ed., Singh, A., Ed., Chaskar, H., Funato, D., 1057 and E. Shim, "Candidate Access Router Discovery (CARD)", 1058 RFC 4066, DOI 10.17487/RFC4066, July 2005, 1059 . 1061 [RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication 1062 Protocol Method for 3rd Generation Authentication and Key 1063 Agreement (EAP-AKA)", RFC 4187, DOI 10.17487/RFC4187, 1064 January 2006, . 1066 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 1067 (MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006, 1068 . 1070 [RFC4881] El Malki, K., Ed., "Low-Latency Handoffs in Mobile IPv4", 1071 RFC 4881, DOI 10.17487/RFC4881, June 2007, 1072 . 1074 [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., 1075 Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", 1076 RFC 5213, DOI 10.17487/RFC5213, August 2008, 1077 . 1079 [RFC5568] Koodli, R., Ed., "Mobile IPv6 Fast Handovers", RFC 5568, 1080 DOI 10.17487/RFC5568, July 2009, 1081 . 1083 [RFC5944] Perkins, C., Ed., "IP Mobility Support for IPv4, Revised", 1084 RFC 5944, DOI 10.17487/RFC5944, November 2010, 1085 . 1087 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 1088 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 1089 2011, . 1091 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 1092 Kivinen, "Internet Key Exchange Protocol Version 2 1093 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 1094 2014, . 1096 [TS22228] "Service requirements for the Internet Protocol (IP) 1097 multimedia core network subsystem (IMS); Stage 1", 2010. 1099 [TS23402] "3rd Generation Partnership Project; Technical 1100 Specification Group Services and System Aspects; 1101 Architecture Enhancements for non-3GPP Accesses.", 2009. 1103 [TS23852] "Study on S2a Mobility based on GPRS Tunneling Protocol 1104 (GTP) and Wireless Local Area Network (WLAN) access to the 1105 Enhanced Packet Core (EPC) network (SaMOG); Stage 2", 1106 2011. 1108 [TS29273] "Evolved Packet System (EPS); 3GPP EPS AAA interfaces", 1109 2011. 1111 Authors' Addresses 1113 Byju Pularikkal 1114 Cisco Systems 1115 170 West Tasman Drive 1116 San Jose 1117 United States 1119 Email: byjupg@cisco.com 1120 Tommy Pauly 1121 Apple Inc. 1122 1 Infinite Loop 1123 Cupertino, California 95014 1124 US 1126 Email: tpauly@apple.com 1128 Mark Grayson 1129 Cisco Systems 1130 10 New Square Park 1131 Feltham 1132 United Kingdom 1134 Email: mgrayson@cisco.com 1136 Sri Gundavelli 1137 Cisco Systems 1138 170 West Tasman Drive 1139 San Jose 1140 United States 1142 Email: sgundave@cisco.com 1144 Samy Touati 1145 Ericsson 1146 300 Holger Way 1147 San Jose, California 95134 1148 US 1150 Email: samy.touati@ericsson.com