wifi-integration into epc

Integration of Wi-Fi access

networks into EPCFranz Edler, WS 2015/16

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

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


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


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


Trusted

Wi-Fi

access

network

Wi-Fi

clientTWAG P-GW

S2aInternet

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


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


Untrusted

Wi-Fi

access

network

IPsec

clientePDG P-GW

S2bInternet

SWu

Trusted/Untrusted Wi-Fi: Comparison

8


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

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


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


Architecture for NSWO and IMS traffic

11


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

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


Wi-Fi calling in a trusted Wi-Fi access

13


Trusted/

Untrusted

policy

IPsec

client

Native

Wi-Fi

client

TWAG

ePDG

IPsec tunnel

IEEE 802.11

SWu

Default

APN

P-GW

Internet

trafficInternet

IMS-

APN

P-GW

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


Optimized architecture with SIPTO

15


Trusted/

Untrusted

policy

IPsec

client

Native

Wi-Fi

client

SIPTO

enabled

TWAG

ePDG

IPsec tunnel

IEEE 802.11

SWu

Default

APN

P-GW

Internet

trafficInternet

IMS-

APN

P-GW

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


Multi-PDN capability in trusted WLAN

17


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

S2aInternet

IMS

network

Setup of an encrypted

connection

18


Further related topics

• Multi-Access PDN Connectivity (MAPCON)

• IP Flow Mobility (IFOM)

• Mobility between hotspots (MOBIKE)

19


Multi-Access PDN Connectivity (MAPCON)

20


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


IP Flow Mobility (IFOM)

22


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


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


25


Conditional Messages

UE ePDG3GPP

AAA-ServHSS / 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)

Backup slides

showing some details of attachment

in non-3GPP networks.

• Attachment in trusted non-3GPP network

• Attachment in untrusted non-3GPP network

26


27


Trusted access:

authentication &

authorization

28


Untrusted access:

authentication &

authorization,

tunnel setup

wifi-integration into epc

Technology