Integration of Wi-Fi access

networks into EPC

Franz Edler, WS 2016
 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.
 Or in areas with bad cellular coverage (inside of buildings)
 Wi-Fi is ideally positioned to extend the cellular coverage.
It uses unlicensed spectrum in ISM bands (2,4 GHz 5 GHz).
 First step (offered already by UE vendors) is manual
selection of a Wi-Fi hotspot and login for access to the
Internet.

© FH Technikum Wien
2
 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 are needed 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.

© FH Technikum Wien
3
 Wi-Fi networks: trusted or untrusted?
 The EPC architecture distinguishes between 3GPP and
non-3GPP access technologies.
 Non-3GPP access networks are further distinguished:
trusted / untrusted.
 Trusted non-3GPP access networks:
– 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 networks:
– No secure safety level
– Example: access using public hotspots
– IPsec tunnels are used

© FH Technikum Wien
4
 Integration of Trusted Wi-Fi into EPC

Trusted
Wi-Fi Wi-Fi
TWAG P-GW Internet
client access S2a
network

 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 credentials.
© FH Technikum Wien
5
 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 3GPP 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.

© FH Technikum Wien
6
 Integration of untrusted Wi-Fi into EPC

Untrusted
IPsec Wi-Fi
ePDG P-GW Internet
client access S2b
network

SWu
 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.
 Untrusted Wi-Fi access is used for access to IMS services (Wi-Fi
calling).
© FH Technikum Wien
7
 Trusted/Untrusted Wi-Fi: Comparison

Trusted Wi-Fi Untrusted Wi-Fi

Main differences:
IMS Traffic
Focus:
Internet Traffic
 Internet access
APN Signalling
 Wi-Fi calling
PDN Connectivity
Default APN Tunnel Client
APN awareness
Carrier Wi-Fi Unmanaged Wi-Fi Ownership

Default client IMS client

Device functionality

© FH Technikum Wien
8
 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 is regarded as
untrusted – as of today
(enhancements for trusted access are 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

© FH Technikum Wien
9
 Support of Internet traffic in untrusted Wi-Fi
 Non-IMS oriented traffic (towards Internet)
– is handled autonomously by the UE, and
– in case of mobility: 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 IPsec tunnel
– ePDG keeps the “inner” IP-address provided from P-GW.
 Non-IMS traffic
– goes directly to the Wi-Fi network
– IP-address is provided by Wi-Fi network and lost outside of WiFi
© FH Technikum Wien
10
 Architecture for Internet and IMS traffic
in untrusted WiFi

IPsec IMS-traffic
client IPsec tunnel IMS-
ePDG
APN
P-GW
Trusted/Untrust IEEE 802.11
ed policy WLAN
access
NSOW policy

Native Internet-traffic Internet

Wi-Fi client

© FH Technikum Wien
11
 Wi-Fi calling in a trusted Wi-Fi access
network with TWAG
 Trusted Wi-Fi access has no APN awareness (as of today).
 Only one IP-address is provided by the TWAG.
 To support both Wi-Fi calling and Internet the ePDG can be
used again.
 This leads to a non optimal architecture (see next slide).
 The architectural drawback is:
– Traffic to IMS-APN must pass two P-GWs:
- the P-GW of the default APN (traffic towards Internet)
- the P-GW for IMS traffic

© FH Technikum Wien
12
 Wi-Fi calling in a trusted Wi-Fi access

IPsec IMS traffic

client IPsec tunnel ePDG IMS-
APN
IEEE 802.11 P-GW
Trusted/
Default
Untrusted TWAG
APN
policy
P-GW
Native Internet
Wi-Fi Internet
traffic
client

© FH Technikum Wien
13
 Optimized architecture with SIPTO
 The double transition P-GWs for IMS-traffic 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 means an APN awareness of the TWAG.
 This is done with packet filter and packet inspection.

© FH Technikum Wien
14
 Optimized architecture with SIPTO
IMS-
IPsec tunnel APN
IPsec
client SWu ePDG
P-GW

IEEE 802.11
Trusted/ SIPTO
Untrusted enabled
policy TWAG

Default
Native Internet APN
Wi-Fi Internet
traffic
client P-GW

© FH Technikum Wien
15
 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.
 From 3GPP Release 12 onwards:
– Multiple PDN connections are supported by TWAG and the
UEs based on virtual interfaces and MAC addresses.
– Clients must support dynamic indication of trust to determine
which mode to activate:
- tunnel to ePDG or
- virtual MAC connection to TWAG

© FH Technikum Wien
16
 Multi-PDN capability in trusted WLAN
IMS-
Virtual Virtual S2a APN
IMS
interface MAC #1 network
P-GW

Trusted WiFi
Release Release 12
12 device TWAG
IEEE 802.11

Default
Virtual Virtual S2a APN
interface MAC #2 Internet
P-GW

© FH Technikum Wien
17
 Further Wi-Fi related topics

• Multi-Access PDN Connectivity

(MAPCON)

• IP Flow Mobility (IFOM)

• Mobility between hotspots (MOBIKE)

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

© FH Technikum Wien
19
 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.

© FH Technikum Wien
20
 IP Flow Mobility (IFOM)

© FH Technikum Wien
21
 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.

© FH Technikum Wien
22
 Mobility between hotspots (MOBIKE)
 A WLAN area may consist of 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 when changing the
access point.
 Tear down and recreate the IPsec SA requires the whole
IKE procedure again and leads to a remarkable service
interruption.
 The MOBIKE protocol extends IKEv2 with possibilities to
dynamically update the IP address of the IKE SAs and
IPsec SAs.

© FH Technikum Wien
23
 Backup slides
showing some details of attachment
in non-3GPP networks.

• Attachment in trusted non-3GPP network

• Attachment in untrusted non-3GPP network

© FH Technikum Wien
24
Trusted access:
authentication &
authorization

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

© FH Technikum Wien
26
 3GPP
UE
Untrusted Wi-Fi ePDG
AAA-Serv
HSS / HLR

1. IKE_SA_INIT
• Setup of IPsec connection
[Headers, Sec. associations, D-H values, Nonces]

(Diffie-Hellman exchange) 2. IKE_AUTH Request

[Header, User ID, Configuration Pyload, Sec. associations, Traffic selectors, APN info]
3. Authentication & Authorization Req [EAP-
• Identification and retrieval Payload(EAP-Resp/Identity), User ID, APN info]

of authentication data 4. AVs retrieval if needed

(i.e. if not available in the AAA)

5. A&A-Answer [EAP-Request/AKA-Challenge]
6. IKE_AUTH Response
[Header, ePDG ID, Certificate, AUTH, EAP-Request/AKA-Challenge]
• Calculate and send 6.a UE runs AKA
response algorithms, verifies AUTN,
generates RES and MSK
7. IKE_AUTH Request
[Header, EAP-Request/AKA-Challenge]
8. A&A-Request [EAP-Response/AKA-Challenge]
• Verify result 8a. 3GPP AAA Server verifies
If AT_RES = XRES

• Optional step Conditional Messages

8b. A&AA-Answer [EAP-Req/AKA-Notification]
(dynamic selection of
8c. IKE_AUTH Response [Header, EAP-Req/AKA-Notification]
mobility mode) 8d. IKE_AUTH Request [Header, EAP-Resp/AKA-Notification]
8e. A&A-Request [EAP-Resp/AKA-Notification]

8A. Profile Retrieval and

• Retrieval of user-profile Registration
9. AA-Answer [EAP-Success, key material, IMSI]

10. AUTH payload is computed

using the keying material (MSK)
11. IKE_AUTH Response
[Header, EAP-Success]
12. IKE_AUTH Request [AUTH]
(3GPP TS 33.402 § 8.2) 13. Check AUTH correctness

14. Calculate AUTH

15. IKE_AUTH Response

[Header, AUTH, Configuration Payload, Sec. Associations, Traffic Selectors]
© FH Technikum Wien
27