buu-minh ta charlie perkins improved lte mobility mgmt
TRANSCRIPT
Constraints & Goals
eNodeB and MME shouldn’t be changed
Use existing LTE authentication procedures
Use existing policy interface via HA
Smooth and quick handovers
Identify Mobile IP features needed to support inferred LTE design goals
Present at IETF, publish
Constraints Goals
Issues
S-GW What is its purpose? Only intermediary on the GTP tunnel
Handovers between other networks? Length of procedures…
How many roundtrips to establish the connection?
Initially planned response
Observation: Past projects have exhibited excellent performance using Mobile IP.
[S-GW + P-GW] = P-GW/S-GW HA-D pMME (proxy MME) HA-C Keep existing PCEF/PCRF/PCC Keep existing MME authentication
Why is S-GW separate from P-GW?
It’s not all that easy to figure out Some purported justifications:
Aggregation of mobility events Distribution of statistics gathering Hiding aspects of radio technology Enabling multi-homed eNodeBs
By now, the P-GW and S-GW seem tightly bound
A fully routed EPC seems likely to work “better”
eNodeB
UE
S-GW
P-GW
MME
Architecture (1)Internal HA
eNodeB
UE
S-GW
P-GW
MME
HA-DS-GW/P-GW
HA-CpMME
GTP
GTP
GTP
Modifying Mobile IPv6
Split HA into HA-D (== P-GW) + HA-C (== MME)
Enable HA to tunnel via GTP HA-C HA-D via GTP-C Enable alternate security association
(algorithm, data) Enable Binding Authorization for HA Enable alternative CoA
Problem: UE has no unique ID for eNodeB
Moving to a network using MobileIP Initial Attach
..\Initial Attach.vsd Initial Attach with external HA
..\Initial Attach - HA external.vsd
New NAS Attach Request message (UEpMME, pre-existing HA)
Attach Request’Attach
Request[NAS
protected]
Ciphered Options
[NAS protected]
Identifier
HA address
Derived Key
Ciphered
derived key
1. Attach Request: current message sent by UE to MME (protected using EPS security association). Encapsulated into a NAS container IE.
2. Ciphered Options: avoid one round trip to the UE.3. Identifier: NAI.4. HA address: so the pMME can send the BU. 5. Derived Key: to establish a security association between
pMME and HA.6. Ciphered derived key: so the HA can know the derived key,
and verify it has been establish by the UE.
New NAS Attach Request message (UEpMME, non-existing HA)
Attach Request’
Attach Request[NAS protected] Identifier
Ciphered Options
[NAS protected]
1. Attach Request: current message sent by UE to MME (protected using EPS security association). Encapsulated into a NAS container IE.
2. Identifier: NAI.3. Ciphered Options: avoid one round trip to the UE.
Binding Update (pMMEP-GW)External HA
Binding Update
Header Identifier Home Address
Care-of Address
Binding Authorization Data
Create Session Request
Ciphered Derived
Key
1. Care-of Address: external address of the P-GW.2. Binding Authorization Data: signature on everything that
precedes, using the derived key.3. Create Session Request: extracted by the P-GW.4. Ciphered Key: same as in the Attach Request.
Binding Update (pMMEP-GW)Internal HA
Binding Update
Header Identifier TEID
1. TEID: eNodeB GTP Tunnel Enpoint.
Pre-Authentication with LTE network Context:
UE is within reach of LTE network, but has not initiated attach and handover.
Goals: Pre-authentication with pMME and MME to
establish security association. “Pro-active handover” to make the
handover quicker.
Pre-Authentication with LTE network How can we do it?
Pre-Authentication Request containing Attach Request to pMME.
pMME fakes the attach of the UE to a “virtual” eNodeB by forwarding the Attach Request to the MME.
Current Authentication and Identification procedures. Pre-create the session within the P-GW
When the UE initiates the attach: Continues the procedure (session already created, P-
GW TEID available): Attach Accept Basically, just need the eNodeB TEID to establish the
tunnel.
Additional steps
Consider client-triggered PMIP approach. Map signaling to multi-stage HA into
HMIP approach. Insert preregistration sequences from
SFF designs, attempt the application of FMIP context transfer.
Is it better?
With so many modifications, one wonders whether it is worth it to use Mobile IPv6
But – compared to existing procedures, it is still much simpler – less signaling, fewer steps
Most of the complexity is due to constraint to avoid modifications to eNodeB/MME/GTP etc.
Have an almost complete spreadsheet