1. 助理教授：吳俊興 助教：楊文健 國立高雄大學 資訊工程學系
教育部行動寬頻尖端技術人才培育計畫-小細胞基站聯盟中心
示範課程:行動與無線區網整合
Week #05 WLAN Offload
助理教授：吳俊興
助教：楊文健
國立高雄大學 資訊工程學系

2. Outline Introduction of WLAN Offload Authentication
Initial attachment from Untrusted Non-3GPP Access
Initial attachment from Trusted Non-3GPP Access

3. Introduction
Increasing need for offloading solutions is caused by the explosion of Internet data traffic, especially the growing portion of traffic going through mobile networks
This has been enabled by smartphone devices possessing Wi-Fi capabilities together with large screens and different Internet applications, from browsers to video and audio streaming applications
In addition to smart phones, laptops with 3G access capabilities are also seen as a major source of mobile data traffic

4. Mobile Data Offloading
Mobile data offloading, is the use of complementary network technologies for delivering data originally targeted for cellular networks
Offloading reduces the amount of data being carried on the cellular bands, freeing bandwidth for other users
It is also used in situations where local cell reception may be poor, allowing the user to connect via wired services with better connectivity

5. The Main Complementary Network Technologies
The main complementary network technologies used for mobile data offloading are Wi-Fi, femtocell and Integrated Mobile Broadcast
Rules triggering the mobile offloading action can be set by either an end-user (mobile subscriber) or an operator
End users do data offloading for data service cost control and the availability of higher bandwidth
It is predicted that mobile data offloading will become a new industry segment due to the surge of mobile data traffic

6. Provide Mobile Network Access
WLAN access may be used by mobile operators to provide mobile network access
It allows an end-user to use their mobile device’s WLAN access interface and a “connection manager” client to route traffic back into the mobile network operator’s packet core network
© 2012 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Integration of Cellular and Wi-Fi Networks September 2013

7. WLAN Service
The mobile operator role involves both user plane routing and control plane functions including backend support for the Authentication, Authorization and Accounting (AAA) chain to provide access control and billing for WLAN service
In this case the end-user’s device is assigned an IP address by the mobile operator and any requirement for legal interception of user traffic would fall on the mobile operator
© 2012 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Integration of Cellular and Wi-Fi Networks September 2013

8. Primary Offload Technologies
Wi-Fi and femtocell technologies are the primary offload technologies used by the industry
In addition, WiMax and terrestrial networks (LAN) are also candidates for offloading of 3G mobile data
Femtocells use standard cellular radio technologies, thus any mobile device is capable of participating in the data offloading process, though some modification is needed to accommodate the different backhaul connection

9. Simplified WLAN Network Model
23.402
Figure 4.1: Simplified WLAN Network Model. The shaded area refers to WLAN 3GPP IP Access functionality

10. Non-3GPP accesses
Non-3GPP access includes access from for instance Wi-Fi, WiMAX, fixed and CDMA networks
The Mobility mechanisms supported between 3GPP and non- 3GPP accesses within an operator and its roaming partner's network would depend upon operator choice
The EPS supports the use of non-3GPP IP access networks to access the EPC
24.302

11. Trusted/Untrusted non-3GPP Access
Non-3GPP accesses can be split into two categories:
the "trusted" ones and the "untrusted"
The biggest difference between trusted access and untrusted access would be the requirement of authentication requirement
3GPP does not specify which non-3GPP technologies should be considered trusted or untrusted
This decision is made by the operator
24.302

12. Non-Roaming Architecture
23.402
Figure : Non-Roaming Architecture within EPS using S5, S2a, S2b

13. The S2a interface
Network Based Mobility uses S2a interface for Trusted access to EPC
This interface is based on the Proxy Mobile IPv6 (PMIPv6) protocol
The difference is that the PMIPv6 protocol does not require any changes on the user equipment. The wireless access gateway (WAG) in the trusted non-3GPP IP access network provides the mobile IP functions transparently for the client
© 2012 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Integration of Cellular and Wi-Fi Networks September 2013

14. The S2a interface(Cont.)
It creates the tunnel, requests the IP address from the P-GW, and then assigns this address to the Wi-Fi connection
In this way, the user equipment is assigned an IP address that is part of the P-GW pool, but it does not see the address as virtual but as a physical address directly on the Wi-Fi interface
Allowing usage of Wi-Fi as a trusted non-3GPP access to EPC enables a connection to the EPC in deployments where the existing S2b and S2c solutions for untrusted non-3GPP access are not necessary
© 2012 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Integration of Cellular and Wi-Fi Networks September 2013

15. The S2b interface S2b interface for Un-Trusted access to EPC
This interface is based on the Proxy Mobile IPv6 (PMIPv6) protocol
This S2b interface is similar to the S5/S8 interface between a SGW and a P-GW
© 2012 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Integration of Cellular and Wi-Fi Networks September 2013

16. The S2b interface(Cont.)
To maintain trust, the UE has to establish a dedicated “Virtual Private Network (VPN) access”
This comprises of establishing an IPSec tunnel(s) to a secure gateway operated by a Mobile operator (called ePDG) that provides access to the EPC
These IPSec tunnels are set-up based on 3GPP requirements. IKE parameters are used to carry 3GPP information such as the APN
For each UE, there is one such IPSec tunnel per PDN connection, the UE wants to have over Non-Trusted Non- 3GPP Access to EPC
© 2012 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Integration of Cellular and Wi-Fi Networks September 2013

17. Non-Roaming Architecture
23.402
Figure : Non-Roaming Architecture within EPS using S5, S2c

18. The S2c interface Client/Host-Based Mobility uses S2c interface
S2c relies on DSMIPv6 mobility signaling
The access network needs to allocate Care-Of-Address to the UE, and the High Availability (HA) must be reachable from the access network for the UE
© 2012 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Integration of Cellular and Wi-Fi Networks September 2013

19. The S2c interface(Cont.)
The S2c interface is based on the Dual-Stack Mobile IP Version 6 (DSMIPv6) protocol and requires user equipment to support it
DSMIPv6 creates a tunneled connection between the user equipment and the P-GW, which is used to forward all traffic to and from the user equipment
The P-GW is responsible for assigning a virtual IP address to the tunnel during the setup process. This IP address is from the same IP pool that is used for LTE sessions
Because all traffic to and from the user equipment is sent through the tunnel, the P-GW has complete visibility of the user traffic
© 2012 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Integration of Cellular and Wi-Fi Networks September 2013

20. The S2c Interface Access to EPC
Access to EPC with Host Based Mobility:
in this scenario, the UE establishes DSMIPv6 connectivity to the EPC mobility anchor (i.e. the P-GW) transparently over Wi-Fi
Together with DSMIPv6 support in the UE, this requires the support of an IPsec Security Association between the UE and the P-GW in order to protect the Mobile IP signalling between the UE and the P-GW
© 2012 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Integration of Cellular and Wi-Fi Networks September 2013

21. Security Architecture
33.402
Figure 4.1-1: Security Architecture of Non-3GPP Access and 3GPP EPS

22. Authentication
Access authentication for non-3GPP access in EPS shall be based on EAP-AKA (RFC 4187 [7]) or on EAP-AKA' (RFC [23])
It follows from the preceding sentence in particular that access authentication for non-3GPP access in EPS using EAP-SIM is not allowed
The EAP server for EAP-AKA and EAP-AKA' shall be the 3GPP AAA server residing in the EPC
The UE and 3GPP AAA server shall implement both EAP- AKA and EAP-AKA'
33.402

23. 3GPP-Based Access Authentication
The non-3GPP access networks, which are trusted, can be pre-configured in the UE
Additionally, during 3GPP-based access authentication the UE may receive an indication whether the non-3GPP IP access is trusted or not
If such an indication is sent it shall be sent by the 3GPP AAA server as part of an EAP-AKA or EAP-AKA' request
If no such indication is received by the UE, and there is no pre-configured information in the UE, the UE shall consider the non-3GPP IP access as untrusted
33.402

24. Access Authentication Mechanisms
EAP-SIM, EAP-AKA and EAP-AKA’ are Wi-Fi access authentication mechanisms that make use of (U)SIM credentials
EAP-SIM is the EAP based mechanism defined for authentication based on SIM credentials
EAP-AKA is an improvement on EAP-SIM and is based on USIM symmetric keys allowing for mutual authentication, integrity protection and replay protection
EAP-AKA’ is a minor revision to EAP-AKA method with a new key derivation function.
33.402

25. Access Authentication Mechanisms(Cont.)
It should be noted that while all three of these mechanisms make use of (U)SIM credentials, based on existing 3GPP specifications only the EAP-AKA and EAP-AKA’ methods can provide access to the EPC via non-3GPP accesses
It is therefore recommended that both EAP-AKA and EAP- AKA’ be supported for authentication purposes in an integrated network environment
All of these methods require support of IEEE 802.1x
33.402

26. Initial attachment from Untrusted Non-3GPP Access
23.402
Figure 7.3-1: Initial attachment from Untrusted Non-3GPP IP Access with DSMIPv6

27. Attachment-Step 1
The Figure illustrates the attachment as defined by 3GPP
The Access authenticate between UE and the 3GPP EPC
After the authentication, UE is configured with Local IP Address from the access network domain
This address is used for sending all IKEv2, RFC 5996 [9] messages and as the source address on the outer header of the IPsec tunnel between the UE and the ePDG
© 2012 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.

28. Attachment-Step 2~4
The IKEv2 tunnel establishment procedure is started by the UE
The ePDG IP address to which the UE needs to form IPsec tunnel is discovered via DNS
The ePDG sends the final IKEv2 message with the assigned IP address in IKEv2 Configuration payloads
IPsec Tunnel between the UE and ePDG is now setup
© 2012 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.

29. Attachment-Step 5
A security association is established between UE and PDN GW to secure the DS-MIPv6 messages between UE and PDN GW
During this step an IPv6 home network prefix is assigned by the PDN GW to the UE as defined in RFC 5026 [40]
After the IPv6 home network prefix is assigned, UE constructs a home address from it via auto-configuration.
© 2012 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.

30. Attachment-Step 6
The UE sends the Binding Update (IP Addresses (HoA, CoA)) message to the PDN GW
The UE may request an IPv4 Home Address in this step
The UE shall inform the PDN GW that the whole home prefix shall be moved
© 2012 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.

31. Attachment-Step 7
The PDN GW executes a IP‑CAN Session Establishment Procedure with the PCRF
The message from the PDG GW includes at least the HoA and the CoA
The message may also include a permanent UE identity and an APN string
The PCRF decides on the PCC rules and Event Triggers and provisions them to the PDN GW
© 2012 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.

32. Attachment-Finally Step
The PDN GW processes the binding update and creates a binding cache entry for the UE. The PDN GW allocates an IPv4 home address for the UE if requested by the UE in step 5
The PDN GW then sends a Binding Ack to the UE, including the IPv4 home address allocated for the UE
The IP Connectivity is now setup
© 2012 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.

33. Authentication and Key Agreement for Untrusted Access
For untrusted access, UE and the ePDG shall perform mutual authentication during the IPsec tunnel establishment between the UE and the ePDG (SWu reference point)
In addition, before the IPsec tunnel establishment between the UE and the ePDG can be performed, the UE needs to obtain IP connectivity across the access network, which may require an access authentication, which is independent of the EAP-AKA authentication run in conjunction with the IPsec tunnel establishment
33.402
6.4 Authentication and key agreement for untrusted access
This procedure is specified in clause 8 of the present document.

34. Tunnel full authentication and authorization
33.402
Figure : Tunnel full authentication and authorization

35. Tunnel full authentication and authorization(Cont.)
33.402
Figure : Tunnel full authentication and authorization

36. The First Message
The UE sends the user identity (in the IDi payload) and the APN information (in the IDr payload) in this first message of the IKE_AUTH phase, and begins negotiation of child security associations
The UE shall send the configuration payload (CFG_REQUEST) within the IKE_AUTH request message to obtain an IPv4 and/or IPV6 home IP Address and/or a Home Agent Address
33.402
6.4 Authentication and key agreement for untrusted access
This procedure is specified in clause 8 of the present document.

37. Authentication and Authorization Request message
The ePDG sends the Authentication and Authorization Request message to the 3GPP AAA Server, containing the user identity and APN
The 3GPP AAA server shall identify based on the realm part of the NAI that combined authentication and authorization is being performed for tunnel establishment with an ePDG which allows only EAP-AKA
33.402
6.4 Authentication and key agreement for untrusted access
This procedure is specified in clause 8 of the present document.

38. Authentication Successful
The 3GPP AAA Server initiates the authentication challenge
The user identity is not requested again
When all checks are successful, the 3GPP AAA Server sends the final Authentication and Authorization Answer (with a result code indicating success) including the relevant service authorization information, an EAP success and the key material to the ePDG
33.402
6.4 Authentication and key agreement for untrusted access
This procedure is specified in clause 8 of the present document.

39. UE is Authenticated
The ePDG checks the correctness of the AUTH received from the UE
At this point the UE is authenticated
In case S2b is used, PMIP signalling between ePDG and PDN GW can now start
33.402
6.4 Authentication and key agreement for untrusted access
This procedure is specified in clause 8 of the present document.

40. Initial attachment from Trusted Non-3GPP Access
23.402
Figure 6.3-1: Initial attachment from Trusted Non-3GPP IP Access with DSMIPv6

41. Attachment The Figure illustrates the attachment as defined by 3GPP
Phase A represents attachment to the Wi-Fi network
In phase B, the DSMIPv6 tunnel is opened to the P-GW
In phase C, the session is signaled as the active one and also illustrated is the establishment of policies for the session using the PCRF
© 2012 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.

42. Non-3GPP Access Authentication Step 1~10
33.402
6.2 Authentication and key agreement for trusted access
Figure 6.2-1: Non-3GPP Access Authentication

43. Non-3GPP Access Authentication Step 11~18
33.402
Figure 6.2-1: Non-3GPP Access Authentication

44. Non-3GPP Access Authentication Step 19~25
33.402
Figure 6.2-1: Non-3GPP Access Authentication

45. Non-3GPP Access Authentication
EAP-AKA' as defined in RFC 5448 [23] shall be used for mutual authentication and key agreement
A connection is established between the UE and the trusted non-3GPP access network, using a procedure specific to the non-3GPP access network
An AAA interface (STa) with a 3GPP AAA server to support UE authentication as well as to retrieve user Authorization data
Diameter referral can also be applied to find the AAA server
33402
Figure 6.2-1: Non-3GPP Access Authentication

46. Non-3GPP Access Authentication(Cont.)
The HSS shall check if there is a 3GPP AAA Server already registered to serve for this subscriber
In case the HSS detects that another 3GPP AAA Server has already registered for this subscriber, it shall provide the current 3GPP AAA Server with the previously registered 3GPP AAA Server address
The authentication signalling is then routed to the previously registered 3GPP AAA Server with Diameter-specific mechanisms
e.g., the current 3GPP AAA Server transfers the previously registered 3GPP AAA Server address to the 3GPP AAA proxy or the AAA entity in the trusted non-3GPP access network, or the current 3GPP AAA Server acts as a AAA proxy and forwards the authentication message to the previously registered 3GPP AAA Server
33402
Figure 6.2-1: Non-3GPP Access Authentication

47. Authentication Failed
The authentication process may fail at any moment, for example because of unsuccessful checking of MACs or no response from the UE after a network request
In that case, the EAP AKA' process will be terminated as specified in RFC 5448 [23] and an indication shall be sent to HSS.
33402

48. References