The document discusses the integration of Wi-Fi access networks into the Evolved Packet Core (EPC) mobile network. It describes how Wi-Fi can be used to offload data traffic from licensed 3GPP networks using both trusted and untrusted Wi-Fi connections. For trusted connections, the Wi-Fi access network is directly integrated into the EPC using a Trusted WLAN Access Gateway. For untrusted connections, an IPsec tunnel is established between the user device and the Evolved Packet Data Gateway for authentication. The document also discusses various enhancements to support Wi-Fi calling and multiple concurrent connections over both cellular and Wi-Fi.

1. Integration of Wi-Fi access
networks into EPC
Franz Edler, WS 2015/16

2. Wi-Fi offloading
 Explosion of data consumption in mobile networks!
 3GPP access networks UMTS, LTE and LTE-A suffer from
limited availability of licensed spectrum.
 Wi-Fi is ideally positioned to extend the cellular coverage.
It uses unlicensed spectrum in ISM bands (2,4 GHz 5 GHz).
 First step (today) is manual selection of a Wi-Fi hotspot and
login.
2
© FH Technikum Wien

3. 3GPP Wi-Fi offload goals
 Goal of 3GPP standardisation is to create a converged
network solution with seamless coverage including Wi-Fi.
 Additional network elements will be added to handle
network selection, authentication, security, flow control and
handovers.
 Data streams shall even be able to use both connections
(cellular and Wi-Fi) at the same time depending on QoS
requirements.
3
© FH Technikum Wien

4. Wi-Fi networks: trusted or untrusted?
 The EPC architecture defines two access path for non-
3GPP access networks towards EPC: trusted / untrusted.
 Trusted non 3GPP access path:
– Security level (from operator perspective) is sufficiently safe.
– Example: carrier’s own installed Wi-Fi
– Authentication similar to 3GPP access - via USIM credentials
 Untrusted non 3GPP access path:
– No secure safety level
– Example: access using public hotspots
– IPsec tunnels are used
4
© FH Technikum Wien

5. Integration of Trusted Wi-Fi into EPC
 The trusted Wi-Fi access network is integrated into the
EPC by a trusted WLAN access gateway (TWAG).
 The TWAG simulates an S-GW.
 The S2a interface is based on PMIPv6 or GTPv2.
 Requirements on devices: Wi-Fi clients need only be Wi-Fi
certified. No additional functions are required.
 Secure connections based on smart-card credential.
5
© FH Technikum Wien
Trusted
Wi-Fi
access
network
Wi-Fi
client
TWAG P-GW
S2a
Internet

6. Limitations of trusted Wi-Fi access
 Because no additional device functionality is required the
client behaves as a simple Wi-Fi client:
– P-GW provides IP addresses to the TWAG.
– TWAG uses DHCP to provide than IP-address to the client.
 But licensed radio access networks support multiple IP-
addresses based on separate PDN connections associated
with dedicated APNs (access point names).
 Trusted Wi-Fi access (up to Rel. 11) only supports a single
IP-address which is associated with the default APN.
 This is appropriate for carrier Wi-Fi to offload Internet traffic
from licensed radio network, but not to selectively provide
access to IMS which is usually based on a 2nd APN.
6
© FH Technikum Wien

7. Integration of untrusted Wi-Fi into EPC
 Untrusted Wi-Fi access requires a new functionality in the device:
an IPsec client.
 New network element ePDG (evolved Packet Data Gateway)
– separates trusted and untrusted areas and
– authenticates the users
 The device uses an IPsec tunnel to connect to the ePDG.
7
© FH Technikum Wien
Untrusted
Wi-Fi
access
network
IPsec
client
ePDG P-GW
S2b
Internet
SWu

8. Trusted/Untrusted Wi-Fi: Comparison
8
© FH Technikum Wien
Internet Traffic
Default APN
Carrier Wi-Fi
Default client
Trusted Wi-Fi
IMS Traffic
APN Signalling
PDN Connectivity
Tunnel Client
Unmanaged Wi-Fi
IMS client
Untrusted Wi-Fi
Main differences:
Focus:
 Internet access
 Wi-Fi calling
APN awareness
Ownership
Device functionality

9. Trusted/Untrusted Wi-Fi: Device perspective
 How can a device decide about trusted/untrusted access?
– Based on preconfigured policy
– Based on dynamic policy: requires ANDSF*
– Based on signalling during authentication (EAP-AKA)
 For Wi-Fi calling the access network must be regarded as
untrusted – as of today
(enhancements of trusted access defined in Rel. 12)
 ANDSF: Access Network Discovery and Selection Function
– Based on an operator owned policy server which tells the device how it should
connect considering geographic area, time and congestion situation.
 EAP-AKA: Extensible Authentication Protocol - Authentication and Key Agreement
9
© FH Technikum Wien

10. Support of Non-IMS traffic in
untrusted Wi-Fi
 3GPP defines Non-Seamless WLAN Offload (NSWO)
 Non-seamless means: IP address is not kept when moving
 NSWO allows a device in untrusted Wi-Fi
– to send Internet traffic directly to the Wi-Fi access network
– and to simultaneously use a tunnel to ePDG for voice calls.
 IMS traffic goes to the tunnel
 Non-IMS traffic goes directly to the Wi-Fi network
10
© FH Technikum Wien

11. Architecture for NSWO and IMS traffic
11
© FH Technikum Wien
Trusted/Untrust
ed policy
NSOW policy
IPsec
client
Native
Wi-Fi client
WLAN
access
ePDG
IPsec tunnel
IEEE 802.11
NSWO-traffic
SWu IMS-
APN
P-GW
Internet

12. Wi-Fi calling in a trusted Wi-Fi access
 Due to the limitations of trusted Wi-Fi access (no APN
awareness) Wi-Fi call can be supported as shown on next
slide.
 The architectural drawback is:
– Traffic to IMS-APN must pass two P-GWs:
- the P-GW of the default APN
- the P-GW for IMS traffic
12
© FH Technikum Wien

13. Wi-Fi calling in a trusted Wi-Fi access
13
© FH Technikum Wien
Trusted/
Untrusted
policy
IPsec
client
Native
Wi-Fi
client
TWAG
ePDG
IPsec tunnel
IEEE 802.11
SWu
Default
APN
P-GW
Internet
traffic
Internet
IMS-
APN
P-GW

14. Optimized architecture with SIPTO
 The double transition of IMS-traffic to P-GWs can be
avoided with “Selective IP Traffic Offload” (SIPTO).
 This feature – if supported by TWAG – allows to directly
route IMS traffic to the IMS-APN without traversing the
Internet P-GW (default APN).
 This is done with packet filter and packet inspection.
 Note: the TWAG also includes NAT functions.
14
© FH Technikum Wien

15. Optimized architecture with SIPTO
15
© FH Technikum Wien
Trusted/
Untrusted
policy
IPsec
client
Native
Wi-Fi
client
SIPTO
enabled
TWAG
ePDG
IPsec tunnel
IEEE 802.11
SWu
Default
APN
P-GW
Internet
traffic
Internet
IMS-
APN
P-GW

16. Enhancements for trusted Wi-Fi access
 Up to 3GPP Release 11:
– Trusted Wi-Fi access does not support APN signalling and
multiple PDN connections as provided in cellular access.
– Therefore device policies are required to split IMS traffic from
non-IMS traffic.
 3GPP Release 12 addresses this deficiency with new
network and client functionalities:
– Multiple PDN connections will be supported by TWAG and
the devices based on virtual interfaces and MAC addresses.
– NSWO will also be supported in parallel.
– Clients must support dynamic indication of trust to determine
which mode to activate: - tunnel to ePDG or
- virtual MAC connection to TWAG
16
© FH Technikum Wien

17. Multi-PDN capability in trusted WLAN
17
© FH Technikum Wien
Release
12 device
Virtual
interface
Release 12
TWAG
Trusted WiFi
IEEE 802.11
Default
APN
P-GW
IMS-
APN
P-GW
Virtual
interface
Virtual
MAC #1
Virtual
MAC #2
S2a
S2a
Internet
IMS
network

18. Setup of an encrypted
connection
18
© FH Technikum Wien

19. Further related topics
• Multi-Access PDN Connectivity (MAPCON)
• IP Flow Mobility (IFOM)
• Mobility between hotspots (MOBIKE)
19
© FH Technikum Wien

20. Multi-Access PDN Connectivity (MAPCON)
20
© FH Technikum Wien

21. Multi-Access PDN Connectivity (MAPCON)
 MAPCON allows management of multiple PDN
connections with a UE that has multiple IP addresses.
 It supports simultaneous connections via 3GPP access
and non 3GPP access networks.
 MAPCON uses common network based mobility
procedures.
Application example:
 Download of large files using FTP via Wi-Fi and
simultaneous voice & video calls via 3GPP network.
21
© FH Technikum Wien

22. IP Flow Mobility (IFOM)
22
© FH Technikum Wien

23. IP Flow Mobility (IFOM)
 IFOM allows simultaneous connection via 3GPP and non-
3GPP networks to the same PDN.
 It maintains the connection while managing the mobility
data in flow units.
 Mobile data is distributed in flow units for each network.
Application example:
 Download of large files using FTP via Wi-Fi and
simultaneous voice & video calls via 3GPP network.
23
© FH Technikum Wien

24. Mobility between hotspots (MOBIKE)
 A WLAN area may comprise several access points.
 The security associations (SA) of IPsec are setup when the
IKE SA is established.
 It is not possible to keep the IPsec SA when the user
moves and receives a new IP address (e.g. in a WLAN
consisting of several access points).
 Tear down and recreate the IPsec SA requires the whole
IKE procedure again and leads to a service interruption.
 The MOBIKE protocol extends IKEv2 with possibilities to
dynamically update the IP address of the IKE SAs and
IPsec SAs.
24
© FH Technikum Wien

25. 25
© FH Technikum Wien
Conditional Messages
UE ePDG
3GPP
AAA-Serv
HSS / HLR
1. IKE_SA_INIT
4. AVs retrieval if needed
(i.e. if not available in the AAA)
14. Calculate AUTH
8a. 3GPP AAA Server verifies
If AT_RES = XRES
[Headers, Sec. associations, D-H values, Nonces]
2. IKE_AUTH Request
[Header, User ID, Configuration Pyload, Sec. associations, Traffic selectors, APN info]
3. Authentication & Authorization Req [EAP-
Payload(EAP-Resp/Identity), User ID, APN info]
5. A&A-Answer [EAP-Request/AKA-Challenge]
6. IKE_AUTH Response
[Header, ePDG ID, Certificate, AUTH, EAP-Request/AKA-Challenge]
7. IKE_AUTH Request
[Header, EAP-Request/AKA-Challenge]
8. A&A-Request [EAP-Response/AKA-Challenge]
9. AA-Answer [EAP-Success, key material, IMSI]
11. IKE_AUTH Response
[Header, EAP-Success]
12. IKE_AUTH Request [AUTH]
13. Check AUTH correctness
15. IKE_AUTH Response
[Header, AUTH, Configuration Payload, Sec. Associations, Traffic Selectors]
6.a UE runs AKA
algorithms, verifies AUTN,
generates RES and MSK
8b. A&AA-Answer [EAP-Req/AKA-Notification]
8c. IKE_AUTH Response [Header, EAP-Req/AKA-Notification]
8d. IKE_AUTH Request [Header, EAP-Resp/AKA-Notification]
8e. A&A-Request [EAP-Resp/AKA-Notification]
10. AUTH payload is computed
using the keying material (MSK)
8A. Profile Retrieval and
Registration
Untrusted Wi-Fi
• Setup of IPsec connection
(Diffie-Hellman exchange)
• Identification and retrieval
of authentication data
• Calculate and send
response
• Verify result
• Optional step
(dynamic selection of
mobility mode)
• Retrieval of user-profile
(3GPP TS 33.403 § 8.2)

26. Backup slides
showing some details of attachment
in non-3GPP networks.
• Attachment in trusted non-3GPP network
• Attachment in untrusted non-3GPP network
26
© FH Technikum Wien

27. 27
© FH Technikum Wien
Trusted access:
authentication &
authorization

28. 28
© FH Technikum Wien
Untrusted access:
authentication &
authorization,
tunnel setup