Integration of trusted and untrusted WiFi into EPC - overview

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