3rd Generation Partnership Project;

Technical Specification Group Services and System Aspects;

3GPP System Architecture
Evolution:
V8.0.0
(2008-09)
Report on Technical Options and Conclusions
Technical Report
(Release 8)

3GPP TR 23.882

GLOBAL SYSTEM FOR

MOBILE COMMUNICATIONS

The present document has been developed within the 3rd Generation Partnership Project (3GPP TM) and may be further elaborated for the purposes of 3GPP.
The present document has not been subject to any approval process by the 3GPP Organizational Partners and shall not be implemented.
This Specification is provided for future development work within 3GPP only. The Organizational Partners accept no liability for any use of this
Specification.
Specifications and reports for implementation of the 3GPP TM system should be obtained via the 3GPP Organizational Partners' Publications Offices.

Release 8

Keywords
3GPP, Architecture, SAE

3GPP
Postal address
3GPP support office address
650 Route des Lucioles Sophia Antipolis
Valbonne FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16

Internet
http://www.3gpp.org

Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all
media.
2008, 3GPP Organizational Partners (ARIB, ATIS, CCSA, ETSI, TTA, TTC).
All rights reserved.

3GPP

3GPP TR 23.882 V8.0.0 (2008-09)

Release 8

3GPP TR 23.882 V8.0.0 (2008-09)

Contents
Foreword........................................................................................................................................................
Introduction....................................................................................................................................................
1

Scope....................................................................................................................................................

References............................................................................................................................................

Definitions, symbols and abbreviations................................................................................................

3.1
3.2

Definitions.........................................................................................................................................................
Abbreviations.....................................................................................................................................................

Architecture Baseline...........................................................................................................................

4.1
4.2
4.3
4.3.1

Architecture starting point.................................................................................................................................

Architecture for the evolved system non-roaming case.................................................................................
Architecture for the evolved system roaming cases........................................................................................
Scenario 1: Evolved packet core in the Visited network Evolved packet core in the Home network
......................................................................................................................................................................
Architectural principles.....................................................................................................................................

4.4

Requirements on the Architecture.........................................................................................................

Scenarios and Solutions........................................................................................................................

Key Architectural Issues.......................................................................................................................

7.1
7.1.1
7.1.2
7.1.3
7.1.4
7.1.5
7.2
7.2.1
7.2.2
7.2.2.1
7.2.2.1.1
7.2.2.1.2
7.2.2.1.3
7.3
7.3.1
7.3.2
7.4
7.5
7.5.1
7.5.2
7.5.2.1
7.5.2.1.1
7.5.2.1.2
7.5.2.1.3
7.5.2.1.4
7.5.2.1.5
7.5.2.1.6
7.5.2.2
7.5.2.2.1
7.5.2.2.2
7.5.2.2.3
7.5.2.2.4
7.6
7.6.1
7.6.2

Key Issue Policy control and Charging.............................................................................................................

Description of Key Issue Policy control and Charging................................................................................
Solution for key issue Policy control and Charging....................................................................................
Impact on the baseline CN Architecture......................................................................................................
Impact on the baseline RAN Architecture...................................................................................................
Impact on terminals used in the existing architecture..................................................................................
Key Issue- Roaming with Local Breakout........................................................................................................
Description of Key Issue Roaming with Local Breakout.........................................................................
Solution for key issue Roaming with Local Breakout..............................................................................
Analysis of Local Breakout of IMS bearer traffic.......................................................................................
Alternative solution 1 Visited P-CSCF..........................................................................................
Alternative solution 2 Dual IP addresses.......................................................................................
Alternative solution 3 MIPv6 Route Optimisation when host-based mobility is used..................
Tracking Area....................................................................................................................................................
Description of issue......................................................................................................................................
Agreements on Tracking Area Issues...........................................................................................................
Radio Access Network Core Network Functional Split.................................................................................
Key Issue Inter 3GPP Access System Mobility in Idle State............................................................................
Description of Key Issue Inter 3GPP Access System Mobility in Idle State...............................................
Solution for key issue Inter 3GPP Access System Mobility in Idle State....................................................
Alternative Solution A............................................................................................................................
General..............................................................................................................................................
Alternative Solution A1....................................................................................................................
Alternative Solution A2....................................................................................................................
Impact on the baseline CN Architecture...........................................................................................
Impact on the baseline RAN Architecture........................................................................................
Impact on terminals used in the existing architecture......................................................................
Alternative Solution B............................................................................................................................
Description........................................................................................................................................
Impact on the baseline CN Architecture...........................................................................................
Impact on the baseline RAN Architecture........................................................................................
Impact on terminals used in the existing architecture......................................................................
Key issue: Limiting signalling due to idle mode mobility between E-UTRA and UTRA/GSM......................
Requirement.................................................................................................................................................
Potential Solutions.......................................................................................................................................

3GPP

Release 8

7.6.3
7.7
7.7.1
7.7.2
7.7.2.1
7.7.2.2
7.7.2.3
7.7.2.4
7.7.3
7.7.4
7.7.5
7.7.6
7.7.6.1
7.8
7.8.1
7.8.2
7.8.2.1
7.8.2.2
7.8.2.2.1
7.8.2.2.2
7.8.2.2.3
7.8.2.2.4
7.8.2.3
7.8.2.3.1
7.8.2.3.2
7.8.2.3.3
7.8.2.3.4
7.8.2.4
7.8.2.4.1
7.8.2.4.2
7.8.2.4.3
7.8.2.4.4
7.8.2.5
7.8.2.5.1
7.8.2.5.2
7.8.2.5.3
7.8.2.5.4
7.8.2.6
7.8.3
7.8.3.1
7.8.3.2
7.8.3.2.1
7.8.3.2.2
7.8.3.2.3
7.8.3.2.4
7.8.3.3
7.9
7.9.1
7.9.2
7.9.3
7.9.4
7.9.5
7.10
7.10.1
7.10.2
7.10.2.1
7.10.2.2
7.10.2.3
7.10.3

3GPP TR 23.882 V8.0.0 (2008-09)

Selected Solution(s).....................................................................................................................................
Key Issue Intra LTE-Access-System Mobility in LTE_IDLE State..................................................................
Description of Key Issue Intra LTE-Access-System Mobility in LTE_IDLE State....................................
Solution for key issue Intra LTE-Access-System Mobility in Idle State.....................................................
General...................................................................................................................................................
Mobility in LTE_IDLE State..................................................................................................................
Intra LTE-Access-System change in idle state with user context transfer.............................................
Intra LTE-Access-System change in idle state with re-attach................................................................
Impact on the baseline CN Architecture......................................................................................................
Impact on the baseline RAN Architecture...................................................................................................
Impact on terminals used in the existing architecture..................................................................................
Alternative solution......................................................................................................................................
Solution for key issue Intra LTE-Access-System Mobility in Idle State...............................................
Key Issue: Inter access system handover..........................................................................................................
Principles and terminologies........................................................................................................................
Inter access system handover between 3GPP access systems (UTRAN/Evolved HSPA/GERAN and
SAE/LTE 3GPP access system)...................................................................................................................
Description.............................................................................................................................................
Alternative solution A............................................................................................................................
Description........................................................................................................................................
Impact on the baseline CN Architecture...........................................................................................
Impact on the baseline RAN Architecture........................................................................................
Impact on terminals used in the existing architecture......................................................................
Alternative solution B............................................................................................................................
Description........................................................................................................................................
Impact on the baseline CN Architecture...........................................................................................
Impact on the baseline RAN Architecture........................................................................................
Impact on terminals used in the existing architecture......................................................................
Alternative solution C............................................................................................................................
Description........................................................................................................................................
Impact on baseline CN Architecture.................................................................................................
Impact on baseline RAN Architecture..............................................................................................
Impact on terminals used in the existing architecture......................................................................
Alternative solution D............................................................................................................................
Description........................................................................................................................................
Impact on baseline CN Architecture.................................................................................................
Impact on baseline RAN Architecture..............................................................................................
Impact on terminals used in the existing architecture......................................................................
Comparison of Handover Flows............................................................................................................
Inter access system handover between 3GPP and non 3GPP access systems.............................................
Description of key issue Inter access system handover between 3GPP and non-3GPP access
systems...................................................................................................................................................
Solution of key issue Inter access system handover between 3GPP and non-3GPP access
systems...................................................................................................................................................
Relationship with SAE architecture..................................................................................................
Additional solution aspects...............................................................................................................
MIP version implications..................................................................................................................
Use of local mobility protocols........................................................................................................
Comparison of different mobility management schemes.......................................................................
Key Issue Default IP Access Service..............................................................................................................
Description of Key Issue Default IP Access Service................................................................................
Solution for Key Issue Default IP Access Service....................................................................................
Impact on the baseline CN Architecture......................................................................................................
Impact on the baseline RAN Architecture...................................................................................................
Impact on terminals used in the existing architecture..................................................................................
Key issue IP connectivity with multiple PDNs..............................................................................................
Description of Key Issue IP connectivity with multiple PDNs.................................................................
Solution for Key Issue IP connectivity with multiple PDNs.......................................................................
Working Assumptions............................................................................................................................
Solution alternatives...............................................................................................................................
Alternative solutions for the use cases...................................................................................................
Impact on the baseline CN Architecture......................................................................................................

3GPP

Release 8

3GPP TR 23.882 V8.0.0 (2008-09)

7.10.4
Impact on the baseline RAN Architecture...................................................................................................
7.10.5
Impact on terminals used in the existing architecture..................................................................................
7.11
Key Issue Functions in the evolved packet core.............................................................................................
7.11.1
Description of Key Issue Functions in the evolved packet core...............................................................
7.11.2
Solution for Key Issue grouping of the functions.....................................................................................
7.11.2.1
Allocation of evolved packet core functions to UPE, MME and Inter-AS Anchor...............................
7.11.2.2
Alternative 1...........................................................................................................................................
7.11.2.3
Alternative 2...........................................................................................................................................
7.11.2.4
Alternative .........................................................................................................................................
7.11.3
Impact on the baseline CN Architecture......................................................................................................
7.11.4
Impact on the baseline RAN Architecture...................................................................................................
7.11.5
Impact on terminals used in the existing architecture..................................................................................
7.12
Key Issue QoS concepts....................................................................................................................................
7.12.1
Terminology.................................................................................................................................................
7.12.2
Description of Key Issue QoS concepts.......................................................................................................
7.12.3
QoS Concept................................................................................................................................................
7.12.4
SAE Bearer Service Architecture.................................................................................................................
7.12.5
Granularity of QoS Control.........................................................................................................................
7.12.6
The QoS Profile of the SAE Bearer.............................................................................................................
7.12.7
Label Usage Principles.................................................................................................................................
7.12.8
Aggregate Maximum Bit Rate.....................................................................................................................
7.12.9
Resource Establishment and QoS Signalling...............................................................................................
7.12.10
Identified Open Issues..................................................................................................................................
7.12.11
Impact on the baseline CN Architecture......................................................................................................
7.12.12
Impact on the baseline RAN Architecture...................................................................................................
7.12.13
Impact on terminals used in the existing architecture..................................................................................
7.13
Key Issue Network Attachment.........................................................................................................................
7.13.1
Description of Network Attachment............................................................................................................
7.13.2
Solution for Key Issue Network Attachment...............................................................................................
7.13.3
Impact on the baseline CN Architecture......................................................................................................
7.13.4
Impact on the baseline RAN Architecture...................................................................................................
7.13.5
Impact on terminals used in the existing architecture..................................................................................
7.14
Key Issue Paging and C-plane establishment....................................................................................................
7.14.1
Description of Key Issue Paging and Evolved RAN C-plane establishment..............................................
7.14.2
Solution for Key Issue Paging and Evolved RAN C-plane establishment..................................................
7.14.3
Impact on the baseline CN Architecture......................................................................................................
7.14.4
Impact on the baseline RAN Architecture...................................................................................................
7.14.5
Impact on terminals used in the existing architecture..................................................................................
7.15
Key Issue: Intra LTE-Access-System inter MME/UPE handover in the active mode......................................
7.15.1
Description of Key Issue..............................................................................................................................
7.15.2
Solution for key issue...................................................................................................................................
7.15.2.1
Alternative 1...........................................................................................................................................
7.15.2.1.1
Description........................................................................................................................................
7.15.2.1.2
Impact on the baseline CN Architecture...........................................................................................
7.15.2.1.3
Impact on the baseline RAN Architecture........................................................................................
7.15.2.1.4
Impact on terminals used in the existing architecture......................................................................
7.15.2.2
Alternative 2...........................................................................................................................................
7.15.2.2.1
Description........................................................................................................................................
7.15.2.x
Alternative x...........................................................................................................................................
7.16
Key Issue Network Redundancy and Load Sharing.......................................................................................
7.16.1
Description of Key Issue Network Redundancy and Load-sharing..........................................................
7.16.2
General Solutions for key issue Network Redundancy and Load-sharing...............................................
7.16.3
S1-flex Concept............................................................................................................................................
7.16.3.1
Description of issue................................................................................................................................
7.16.3.2
Assumptions on S1-flex concept............................................................................................................
7.17
Key Issue Network Sharing...............................................................................................................................
7.17.1
Description of Network Sharing..................................................................................................................
7.17.2
Solution for Key Issue Network Sharing.....................................................................................................
7.17.2.1
General...................................................................................................................................................
7.17.2.2
S1-flex configuration..............................................................................................................................
7.17.2.3
Broadcast system information for an SAE/LTE network.......................................................................
7.17.2.4
Network selection in an SAE/LTE network...........................................................................................

3GPP

Release 8

7.17.2.5
7.17.2.6
7.17.3
7.17.4
7.17.5
7.18
7.18.1
7.18.2
7.18.2.1
7.18.2.2
7.18.3
7.18.4
7.18.5
7.19

3GPP TR 23.882 V8.0.0 (2008-09)

Assignment of Operator and MME/UPE node......................................................................................

Accounting in RAN................................................................................................................................
Impact on the baseline CN Architecture......................................................................................................
Impact on the baseline RAN Architecture...................................................................................................
Impact on terminals used in the existing architecture..................................................................................
Key Issue Intra-LTE-Access Mobility Support for Ues in LTE_ACTIVE........................................................
Description of Key Issue Intra-LTE-Access Mobility Support for Ues in LTE_ACTIVE..........................
Solution for key issue Intra-LTE-Access Mobility Support for Ues in LTE_ACTIVE...............................
C-plane handling....................................................................................................................................
User plane handling................................................................................................................................
Impact on the baseline CN Architecture......................................................................................................
Impact on the baseline RAN Architecture...................................................................................................
Impact on terminals used in the existing architecture..................................................................................
Key Issue Service continuity at domain and RAT change for TS 11, TS 12, and equivalent PS
service................................................................................................................................................................
7.19.1
Voice call continuity between IMS over SAE/LTE access and CS domain.................................................
7.19.1.1
Description of key issue Voice call continuity between IMS over SAE/LTE access and CS
domain....................................................................................................................................................
7.19.1.2
General aspects.......................................................................................................................................
7.19.1.3
Alternative solution A Combinational VCC........................................................................................
7.19.1.3.1
Description........................................................................................................................................
7.19.1.3.2
Impact on the baseline CN Architecture...........................................................................................
7.19.1.3.3
Impact on the baseline RAN Architecture........................................................................................
7.19.1.3.4
Impact on terminals used in the existing architecture......................................................................
7.19.1.4
Alternative solution B............................................................................................................................
7.19.1.4.1
Description........................................................................................................................................
7.19.1.4.2
Impact on the baseline CN Architecture...........................................................................................
7.19.1.4.3
Impact on the baseline RAN Architecture........................................................................................
7.19.1.4.4
Impact on terminals used in the existing architecture......................................................................
7.19.1.5
Alternative solution C CreDT.............................................................................................................
7.19.1.5.1
Description........................................................................................................................................
7.19.1.5.2
Impact on the baseline CN Architecture...........................................................................................
7.19.1.5.3
Impact on the baseline RAN Architecture........................................................................................
7.19.1.5.4
Impact on terminals used in the existing architecture......................................................................
7.19.1.6
Alternative solution D - Inter-MSC Handover solution...................................................................
7.19.1.6.1
Description........................................................................................................................................
7.19.1.6.2
Impact on the baseline CN Architecture...........................................................................................
7.19.1.6.3
Impact on the baseline RAN Architecture........................................................................................
7.19.1.6.4
Impact on terminals used in the existing architecture......................................................................
7.19.1.6a
Alternative D-1 Inter-MSC Handover with anchoring at the VCC Application...............................
7.19.1.6a.1
Description......................................................................................................................................
7.19.1.6a.2
LTE => 2G CS voice continuity with CS Proxy reference architecture.........................................
7.19.1.6a.2a
Optimized LTE => 2G CS voice continuity call flow....................................................................
7.19.1.6a.3
2G CS => LTE voice continuity call flow......................................................................................
7.19.1.6a.3a
Optimized 2G CS => E-UTRAN voice continuity call flow..........................................................
7.19.1.6b
Alternative D-2 LTE-VMSC Anchor Solution..................................................................................
7.19.1.6b.1
Description of LTE to UMTS/GERAN CS handover....................................................................
7.19.1.6b.2
Information flows...........................................................................................................................
7.19.1.6b.3
Subsequent handovers from 2G/3G back to IMS/LTE...................................................................
7.19.1.6b.4
Advantages of the solution.............................................................................................................
7.19.1.7
Alternative E IMS Anchored Voice Continuity.................................................................................
7.19.1.7.1
Alternative E with tunnelling option..............................................................................................
7.19.1.7.2
Alternative E without tunnelling option.........................................................................................
7.19.1.7.2.2
LTE VoIP to 2G/3G CS voice continuity.......................................................................................
7.19.1.7.3
2G/3G CS voice to LTE VoIP voice continuity..............................................................................
7.19.1.8
Alternative F Inter-MSC Handover with IMS Centralised Services.................................................
7.19.1.8.0
General Concept.............................................................................................................................
7.19.1.8.1
Alternative F-1................................................................................................................................
7.19.1.8.2
Alternative F-2................................................................................................................................
7.19.1.8.3
Impact on the baseline CN Architecture.........................................................................................
7.19.1.8.4
Impact on the baseline RAN Architecture......................................................................................
7.19.1.8.5
Impact on terminals used in the existing architecture....................................................................

3GPP

Release 8

3GPP TR 23.882 V8.0.0 (2008-09)

7.19.1.9
7.19.1.9.1
7.19.1.9.2
7.19.1.9.3
7.19.1.9.4
7.19.1.9.5
7.19.1.9.6
7.19.1.9.7
7.19.1.9.8
7.19.1.9.9
7.19.1.10

Alternative D/F.....................................................................................................................................
Description......................................................................................................................................
Call flows for Handovers of calls initiated in LTE.........................................................................
Service Model.................................................................................................................................
UE and S-IWF CS state synchronization.......................................................................................
VDN allocation for S-IWF.............................................................................................................
Interworking with non VCC capable IMS network........................................................................
Interworking with non VCC capable UE........................................................................................
ICS and Distributed Service model selection.................................................................................
Advantages of the solution.............................................................................................................
Partial Conclusions on Voice call continuity between IMS over SAE/LTE access and CS domain
..............................................................................................................................................................
7.19.1.11
Evaluation of the remaining options....................................................................................................
7.19.1.12
Conclusions on Voice call continuity between IMS over SAE/LTE access and CS domain over
GERAN/UTRAN access......................................................................................................................
7.19.2
Handover of MSC controlled voice calls between SAE/LTE access and CS access.................................
7.19.2.1
Description of key issue Handover of MSC controlled voice calls between SAE/LTE access and
CS access..............................................................................................................................................
7.19.2.2
Alternative solution A - Evolved CSI solution...............................................................................
7.19.2.2.1
Description......................................................................................................................................
7.19.2.2.2
Impact on the baseline CN Architecture.........................................................................................
7.19.2.2.3
Impact on the baseline RAN Architecture......................................................................................
7.19.2.2.4
Impact on terminals used in the existing architecture....................................................................
7.20
Key Issue SAE Identities..............................................................................................................................
7.20.1
Description of issue....................................................................................................................................
7.20.2
Agreements on SAE Identities...................................................................................................................
7.21
Key Issue Network Discovery and Selection...............................................................................................
7.21.1
Description of Key Issue Network Discovery and Selection.....................................................................
7.21.2
Solutions for Key Issue Network Discovery and Selection.......................................................................
7.22
Key Issue Voice service continuity between cdma2000 1xRTT Revision A and E-UTRA..........................
7.22.1
Description of key issue Voice Service Continuity between cdma2000 1xRTT Revision A and EUTRA.........................................................................................................................................................
7.22.2
Alternative solution A................................................................................................................................
7.22.2.1
Description...........................................................................................................................................
7.22.2.1.1
Call flow.........................................................................................................................................
7.22.2.2
Impact on the baseline CN architecture...............................................................................................
7.22.2.3
Impact on the baseline RAN architecture.............................................................................................
7.22.2.4
Impact on terminals used in the existing architecture..........................................................................

Consolidated architecture...................................................................................................................

Conclusions........................................................................................................................................

Annex A:

Open Issues........................................................................................................................

Annex B:

Summary of different high level architecture proposals.................................................

B.0
B.1
B.2

General.............................................................................................................................................................
Concept B1......................................................................................................................................................
Concept B2......................................................................................................................................................

Annex C:

Summary of different MM concepts................................................................................

Annex D:

More detailed descriptions of potential solutions for limiting signalling due to idle
mode mobility between E-UTRA and UTRA/GSM........................................................

D.1

Introduction........................................................................................................................................

D.2

Potential Solutions..............................................................................................................................

D.2.1
D.2.1.1
D.2.1.2
D.2.1.3
D.2.2
D.2.2.1

Do Nothing......................................................................................................................................................
Overview....................................................................................................................................................
Advantages.................................................................................................................................................
Drawbacks..................................................................................................................................................
Common Routeing Area and common SGSN.................................................................................................
Overview....................................................................................................................................................

3GPP

Release 8

D.2.2.2
D.2.2.3
D.2.3
D.2.3.1
D.2.3.2
D.2.3.3
D.2.4
D.2.4.1
D.2.4.2
D.2.4.3
D.2.4.4
D.2.4.4.1
D.2.4.4.2
D.2.4.5
D.2.4.6
D.2.4.7
D.2.5
D.2.5.1
D.2.5.2
D.2.5.3
D.2.6
D.2.6.1
D.2.6.2
D.2.6.3
D.2.6.4
D.2.7
D.2.7.1
D.2.7.2
D.2.7.3
D.2.7.4
D.2.8
D.2.8.1
D.2.8.2
D.2.8.3
D.2.8.4
D.2.9
D.2.9.1
D.2.9.2
D.2.9.3
D.2.9.4
D.2.9.5

D.3
D.3.1
D.3.2
D.3.3
D.3.4
D.3.5
D.3.6
D.3.7

D.4
D.4.1
D.4.2
D.4.3
D.4.4
D.4.5
D.4.6
D.4.7

3GPP TR 23.882 V8.0.0 (2008-09)

Advantages.................................................................................................................................................
Drawbacks..................................................................................................................................................
Common RAN / CN for E-UTRA / UTRA.....................................................................................................
Overview....................................................................................................................................................
Advantages.................................................................................................................................................
Drawbacks..................................................................................................................................................
Equivalent Routeing Areas and SGSN proxy..................................................................................................
Architectural overview...............................................................................................................................
Concept: Equivalent Routeing Areas.........................................................................................................
LERA Management....................................................................................................................................
Downlink data flow to an "inactive" UE...................................................................................................
Solution A.............................................................................................................................................
Solution B.............................................................................................................................................
Summary....................................................................................................................................................
Advantages.................................................................................................................................................
Drawbacks..................................................................................................................................................
UE remains camped on the last used RAT.......................................................................................................
Description.................................................................................................................................................
Advantages.................................................................................................................................................
Drawbacks..................................................................................................................................................
Packet Data Bearer Proxy................................................................................................................................
Architectural overview...............................................................................................................................
Information flow: registration and downlink data transfer........................................................................
Advantages.................................................................................................................................................
Drawbacks..................................................................................................................................................
Inter RAT Resource Allocation........................................................................................................................
Architectural overview...............................................................................................................................
Information flow: registration and uplink/downlink data transfer.............................................................
Advantages.................................................................................................................................................
Drawbacks..................................................................................................................................................
User-IP layer interconnection..........................................................................................................................
Architectural overview...............................................................................................................................
Information flow: registration and downlink data transfer........................................................................
Advantages.................................................................................................................................................
Drawbacks..................................................................................................................................................
Combined MME/SGSN...................................................................................................................................
Architectural overview...............................................................................................................................
Downlink data flow to an "inactive" UE...................................................................................................
Summary....................................................................................................................................................
Advantages.................................................................................................................................................
Drawbacks..................................................................................................................................................

Information Flows..............................................................................................................................
Attach to SAE and RAT change to 2G/3G......................................................................................................
Attach to UMTS and RAT change to LTE.......................................................................................................
Uplink Data Transfer.......................................................................................................................................
PMM-IDLE and URA-PCH state handling.....................................................................................................
Downlink Data Transfer..................................................................................................................................
SGSN (respectively MME) change.................................................................................................................
re-authentication when UE camped within ERA.............................................................................................

Potential mechanisms for context retrieval.........................................................................................

Fully synchronous mechanism........................................................................................................................
MME as master, SGSN as slave......................................................................................................................
Coordination between MME and SGSN.........................................................................................................
Retrieval context from the last access node.....................................................................................................
MME as master, SGSN as slave, plus CRN mechanism.................................................................................
Coordination between MME and SGSN, plus CRN mechanism....................................................................
Retrieval context from the last access node, plus CRN mechanism................................................................

3GPP

Release 8

Annex E:

3GPP TR 23.882 V8.0.0 (2008-09)

Mobility between pre-SAE/LTE 3GPP and non 3GPP access systems..........................

E.1

General...............................................................................................................................................

E.2

Description of mobility between pre-SAE/LTE 3GPP and non 3GPP access systems........................

E.3

Solutions for mobility between pre-SAE/LTE 3GPP and non 3GPP access systems..........................

E.3.1

E.4

Solution A........................................................................................................................................................

Impact on the baseline CN architecture..............................................................................................

E.4.1

Solution A........................................................................................................................................................

E.5

Impact on the baseline RAN architecture...........................................................................................

E.6

Impact on terminals used in the existing architecture.........................................................................

E.6.1

Solution A........................................................................................................................................................

Annex F:

Policy related network Scenarios.....................................................................................

F.1

Scenario 1: Inter-system mobility within the home domain................................................................

F.2

Scenario 2: Roaming with home forwarding/tunnelling of traffic.......................................................

F.3

Scenario 3: Static roaming agreement................................................................................................

F.4

Scenario 4: Roaming with route optimisation of traffic in the visited domain, AF in the home
domain................................................................................................................................................

F.5

Scenario 5: Roaming with local breakout of traffic in the visited domain, AF in the visited domain
............................................................................................................................................................

F.6

Scenario 6: Roaming with local breakout of some traffic in the visited domain,
forwarding/tunnelling other traffic to home network..........................................................................

Annex G:

Examples of Operator-Controlled Services....................................................................

G.1

Operator-Controlled Rx Services........................................................................................................

G.2

Operator-Controlled Gx-only Services...............................................................................................

Annex H:
H.1

Signalling charts for combined or separated MME and UPE........................................

Alternative B and C architecture scenarios and functional allocation.................................................

H.1.1
H.1.2

MME and UPE functional allocation..............................................................................................................

Reference point impact from MME/UPE split................................................................................................

H.2

Attach including default bearer handling............................................................................................

H.3

TA Update without MME or UPE change..........................................................................................

H.4

Inter eNB Handover in LTE_ACTIVE mode (intra MME and intra UPE).........................................

H.5

Inter 3GPP Handover between pre-SAE/LTE and SAE/LTE accesses in LTE_ACTIVE mode..........

H.6

Paging and Service Request................................................................................................................

H.7

PCRF triggered establishment of Dedicated Bearers..........................................................................

H.8

Inter MME and/or inter UPE change, including support for service continuity..................................

H.9

Authentication/Re-Authentication......................................................................................................

H.10 Comparison of Alternatives................................................................................................................

Annex I:

Open issues for the SAE architecture (Informative)................................

Annex J:

Change history...................................................................................................................

3GPP

Release 8

10

3GPP TR 23.882 V8.0.0 (2008-09)

Foreword
This Technical Report has been produced by the 3rd Generation Partnership Project (3GPP).
The contents of the present document are subject to continuing work within the TSG and may change following formal
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an
identifying change of release date and an increase in version number as follows:
Version x.y.z
where:
x the first digit:
1 presented to TSG for information;
2 presented to TSG for approval;
3 or greater indicates TSG approved document under change control.
Y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections,
updates, etc.
z the third digit is incremented when editorial only changes have been incorporated in the document.

Introduction
To ensure competitiveness of the 3GPP systems in a time frame of the next 10 years and beyond, a long-term evolution
of the 3GPP access technology needs to be considered.
In particular, to enhance the capability of the 3GPP system to cope with the rapid growth in IP data traffic, the packetswitched technology utilised within 3G mobile networks requires further enhancement. A continued evolution and
optimisation of the system concept is also necessary in order to maintain a competitive edge in terms of both
performance and cost. Important parts of such a long-term evolution include reduced latency, higher user data rates,
improved system capacity and coverage, and reduced overall cost for the operator.
Additionally, it is expected that IP based 3GPP services will be provided through various access technologies. A
mechanism to support seamless mobility between heterogeneous access networks, e.g. I-WLAN and 3GPP access
systems, is a useful feature for future network evolution.
In order to achieve this, an evolution or migration of the network architecture, as well as an evolution of the radio
interface, partly addressed already by individual WIDs, should be considered.
Architectural considerations will include end-to-end systems aspects, including core network aspects and the study of a
variety of IP connectivity access networks (e.g. fixed broadband access).

3GPP

Release 8

11

3GPP TR 23.882 V8.0.0 (2008-09)

Scope

The objective of this feasibility study is to develop a framework for an evolution or migration of the 3GPP system to a
higher-data-rate, lower-latency, packet-optimized system that supports, multiple RATs. The focus of this work will be
on the PS domain with the assumption that voice services are supported in this domain.
NOTE:

This feasibility study has led into work items specifying LTE/SAE and the contents of this study
should be considered out of date.

The main objectives are to address the following aspects:

1) Overall architecture impacts stemming from requirements coming out from TSG-RAN's Study Item on Radio
Evolution (see SP-040915). The architectural developments should take into account the targets for the evolution
of the radio-interface, e.g.:
i) whether there is a need for a modified network architecture and/or different functional split between network
nodes (compared to the current 3GPP architecture);
ii) how to provide a very low latency (including C-plane) for the overall network (including core network, radio
access network and radio access technology);
iii) how to provide the efficient support of the various types of services, especially from the PS domain (e.g.
Voice over IP, Presence).
2) Overall architecture impacts stemming from the work in SA1 on an All-IP Network (AIPN) (see TS 22.258 [4]),
e.g.:
i) support of a variety of different access systems (existing and future) and access selection based on
combinations of operator policies, user preferences and access network conditions;
ii) how to realize improvements in basic system performance e.g. communication delay, communication quality,
connection set-up time, etc.;
iii) how to maintain the negotiated QoS across the whole system; in particular to address inter-domain and internetwork interworking, and, QoS on the network link to the Base Station site.
NOTE:

Although used in the SA WG1 TS 22.258 [4], the All-IP Network (AIPN) term is not used in the network
architecture in this SAE TR as mapping between the term AIPN used in SA1 and the evolved architecture
is not deemed necessary to progress the SAE work. Instead, the requirements on AIPN in TS 22.258 [4]
are treated as overall system requirements. Even though the AIPN includes an evolved, IP based, core
network and evolved IMS domain, the scope of this SAE TR does not include the IMS domain aspects.

3) Overall architecture aspects of supporting mobility between heterogeneous access networks, including service
continuity. E.g.:
i) service continuity between I-WLAN and the 3GPP PS domain;
ii) how to support multiple radio access technologies and terminal mobility between different radio access
technologies;
iii) how to maintain and support the same capabilities of access control (authentication, authorization), privacy
and charging when moving between different radio access technologies.
Migration aspects should be taken into account for the above, i.e. how to migrate from the existing architecture.
In the course of conducting this feasibility study additional individual Work Items may be identified and prepared to
address certain aspects and to take care of the respective specification work. The timelines of those Work Items may or
may not concur with the timeline of this feasibility study.

3GPP

Release 8

12

3GPP TR 23.882 V8.0.0 (2008-09)

References

The following documents contain provisions which, through reference in this text, constitute provisions of the present
document.
References are either specific (identified by date of publication, edition number, version number, etc.) or
non-specific.
For a specific reference, subsequent revisions do not apply.
For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same
Release as the present document.
[1]

3GPP TR 41.001: "GSM Release specifications".

[2]

3GPP TR 21 912 (V3.1.0): "Example 2, using fixed text".

[3]

3GPP TS 23.002: "Network Architecture".

[4]

3GPP TS 22.258: "Service Requirements for the All-IP Network (AIPN); Stage 1".

[5]

IETF RFC 4004: "Diameter Mobile IPv4 Application", August 2005.

[6]

IETF RFC 4555: "IKEv2 Mobility and Multihoming Protocol (MOBIKE)".

[7]

3GPP TS 43.129: "Packed-switched handover for GERAN A/Gb mode; Stage 2".

[8]

IETF RFC 4068: "Fast Handovers for Mobile IPv6".

[9]

R. Koodli and C. E. Perkins: "Mobile IPv4 Fast Handovers", Internet Draft, draft-ietf-mip4fmipv4-02, October 2006. Available at http://www.ietf.org/internet-drafts/draft-ietf-mip4-fmipv402.txt.

[10]

IETF RFC 3344: "IP Mobility Support for IPv4".

[11]

IETF RFC 3775, "Mobility Support in IPv6".

[12]

H. Levkowetz: "The NETLMM Protocol", Internet Draft, draft-giaretta-netlmm-dt-protocol-02,

October 2006. Available at: http://www.ietf.org/internet-drafts/draft-giaretta-netlmm-dt-protocol02.txt.

[13]

Void.

[14]

Void.

[15]

Void.

[16]

3GPP TR 25.931: "UTRAN functions, examples on signalling procedures".

[17]

S. Gundavelli et. Al.: "Proxy Mobile IPv6", Internet Draft, draft-sgundave-mip6-proxymip6-00,

October 2006. Available at: http://tools.ietf.org/wg/mip6/draft-sgundave-mip6-proxymip6-00.txt.

[18]

3GPP TR 25.912: "3rd Generation Partnership Project; Technical Specification Group Radio
Access Network; Feasibility Study for Evolved UTRA and UTRAN".

[19]

3GPP TS 23.207: "End-to-end Quality of Service (QoS) concept and architecture".

[20]

3GPP TS 23.203: "Policy and Charging Control Architecture".

[21]

IETF RFC 2597: "Assured Forwarding PHB Group".

[22]

IETF RFC 3246: "An Expedited Forwarding PHB (Per-Hop Behavior)".

[23]

IETF RFC 3344: "IP Mobility Support for IPv4".

3GPP

Release 8

13

3GPP TR 23.882 V8.0.0 (2008-09)

[24]

IETF RFC 3775: "Mobility Support in IPv6".

[25]

Void.

[26]

K. Leung, G. Dommety, P. Yegani and K. Chowdhury: "Mobility Management using Proxy Mobile
IPv4", Internet Draft, draft-leung-mip4-proxy-mode-01, June 2006. http://www.ietf.org/internetdrafts/draft-leung-mip4-proxy-mode-01.txt.

[27]

H. Soliman: "Mobile IPv6 support for dual stack Hosts and Routers (DSMIPv6)", Internet Draft,
draft-ietf-mip6-nemo-v4traversal-03, October 2006. http://www.ietf.org/internet-drafts/draft-ietfmip6-nemo-v4traversal-03.txt.

[28]

3GPP TS 23.234: "3GPP System to Wireless Local Area Network (WLAN) Interworking; System
Description".

[29]

3GPP TS 23.206: "Voice Call Continuity between CS and IMS; Stage 2".

[30]

3GPP TR 23.806: "Voice call continuity between Circuit Switched (CS) and IP Multimedia
Subsystem (IMS) Study".

[31]

IETF RFC 4140: "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)".

[32]

G. Tsirtsis, H. Soliman, V. Park: "Dual Stack Mobile IPv4", Internet Draft, draft-ietf-mip4dsmipv4-00.txt, July 2006. http://www.ietf.org/internet-drafts/draft-ietf-mip4-dsmipv4-00.txt

[33]

K. Chowdhury, A. Singh: "Network Based Layer 3 Connectivity and Mobility Management for
IPv6", Internet Draft, draft-chowdhury-netmip6-01.txt, September 2006.
http://www.ietf.org/internet-drafts/draft-chowdhury-netmip6-01.txt.

[34]

3GPP TR 22.278: "Service requirements for evolution of the 3GPP system".

[35]

3GPP TR 22.279: "Combining Circuit Switched (CS) and IP Multimedia Subsystem (IMS)
services".

[36]

3GPP2 C.S0001-A Introduction to cdma2000 Standards for Spread Spectrum Systems - Release A.

[37]

3GPP2 C.S0002-A Physical Layer Standard for cdma2000 Spread Spectrum Systems - Release A

[38]

3GPP2 C.S0003-A Medium Access Control (MAC) Standard for cdma2000 Spread Spectrum
Systems Release A addendum 2.

[39]

3GPP2 C.S0004-A Signaling Link Access Control (LAC) Specification for cdma2000 Spread
Spectrum Systems Addendum 2.

[40]

3GPP2 C.S0005-A Upper Layer (Layer 3) Signaling Standard for cdma2000 Spread Spectrum
Systems Release A addendum 2.

[41]

3GPP2 C.S0006-A Analog Signaling Standard for cdma2000 Spread Spectrum Systems
Addendum 2.

[42]

3GPP2 A.S0007 A.S0009 Interoperability Specification (IOS) for High Rate Packet Data
(HRPD).

[43]

3GPP2 A.S0011 A.S0017 Interoperability Specification (IOS) for cdma2000 Access Network
Interfaces.

[44]

3GPP2 X.S0011 cdma2000 Wireless IP Network.

Definitions, symbols and abbreviations

3.1 Definitions
For the purposes of the present document, the following terms and definitions apply:

3GPP

Release 8

14

3GPP TR 23.882 V8.0.0 (2008-09)

Mobility Management Entity (MME): manages and stores UE context (for idle state: UE/user identities, UE mobility
state, user security parameters). It generates temporary identities and allocates them to UEs. It checks the authorization
whether the UE may camp on the TA or on the PLMN. It also authenticates the user.
MME Pool Area: An MME Pool Area is defined as an area within which a UE may be served without need to change
the serving MME. An MME Pool Area is served by one or more MMEs ("pool of MMEs") in parallel.
UPE Pool Area: A UPE Pool Area is defined as an area within which a UE may be served without need to change the
serving UPE. A UPE Pool Area is served by one or more UPEs ("pool of UPEs") in parallel.
User Plane Entity (UPE): terminates for idle state Ues the downlink data path and triggers/initiates paging when
downlink data arrive for the UE. It manages and stores UE contexts, e.g. parameters of the IP bearer service or network
internal routing information. It performs replication of the user traffic in case of interception.
It is FFS whether Charging Information for inter-operator accounting is in UPE or in another functional block.
Idle State: is LTE_IDLE for SAE/LTE or PMM_IDLE for 2G/3G or URA_PCH, which is FFS
IP Service continuity: IP service continuity is the capability of a system to hide the impact of mobility events to the
end user and the IP application(s), i.e. the service can continue without user intervention or special application support
to mask the effects of a mobility event.
Nomadic Terminal: Terminal that does not have full mobile capabilities but would normally be expected to roam
between different points of attachment of the network, both wireless and wired.
Backward Handover: the source RAN node initiates the handover, and resources are prepared in the target RAN
Nodes. Examples of this concept are reported in TR 25.931 [16].
Forward Handover: The UE changes to the target RAN node without any preparation in the network. Examples of this
concept are reported in TR 25.931 [16].
Trusted non-3GPP IP Access: A non-3GPP IP Access Network is defined as a trusted non-3GPP IP Access Network
if the 3GPP EPC system chooses to trust such non-3GPP IP access network. The 3GPP EPC system operator may
choose to trust the non-3GPP IP access network operated by the same or different operators, e.g. based on business
agreements.
Note that specific security mechanisms may be in place between the trusted non-3GPP IP Access Network and the
3GPP EPC to avoid security threats. It is assumed that an IPSec tunnel between the UE and the 3GPP EPC is not
required.
On the contrary, an untrusted non-3GPP IP access is an IP access network where 3GPP network requires use of IPSec
between the UE and the 3GPP network in order to provide adequate security mechanism acceptable to 3GPP network
operator. An example of such untrusted non-3GPP IP access is WLAN and it is made trusted in the Interworking WLAN
specifications developed within 3GPP.

3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
EPC
IASA

Evolved Packet Core network

Inter Access System Anchor

Architecture Baseline

4.1 Architecture starting point

This chapter describes the architecture baseline as the basis for further evolving the architecture. The full view of
Release 6 network architecture is the reference logical architecture with some additions from Release 7 work.
The Release 7 work that is included in the baseline architecture is:
-

PCRF and related reference points.

3GPP

Release 8

15

3GPP TR 23.882 V8.0.0 (2008-09)

Editors Note: It is FFS what other Release 7 work that may be added to the baseline architecture
NOTE:

For simplification reasons Gx+ and Rx+ is made explicit in the figure but it should be clear that in
Release 6 then the interfaces Gx/Rx and Go/Gq are applicable towards the CRF and PDF respectively.

More specifically the feasibility study shall focus on evolving the PS and I-WLAN architecture, functionalities and
figure 4.1-1. Refer to TS 23.002 [3] for further detailed description. The functional entities that are depicted in figure
4.1-1 are those that are potentially impacted as a result of this study, in relation to the reference points shown.
Editors Note: The interfaces and network entities related to CAMEL and LCS are currently not shown in
figure 4.1-1.

TE
R

MSC

GERAN

MT

HLR/AuC*
HSS*

EIR

SMS-GMSC
SMS-IWMSC

SMS-SC

Um
Gb, Iu

Rx+ (Rx/Gq)

Gr

Gf

Gs

Gd

Iu
TE

MT
R

Gn

Ga

Billing
System*

UE

GGSN
Ga

SGSN

BM-SC

Gi

Gn/Gp

Uu

Gx+ (Go/Gx)
Gmb

Gc

SGSN

UTRAN

AF

PCRF

Gi

PDN

Mb

Gy Mb

IMSMGW

MRFP

OCS*

Wi

CGF*

Gm

IMS
P-CSCF

CSCF

Mw

CDF
Wf Wf

Intranet/
Internet
Wa
WLAN
UE

Wa

WLAN Access
Network
Ww

3GPP AAA
Proxy

WAG
Wn

D/Gr
Wd

Wg

Dx

Cx

HLR/
AuC*

HSS*

SLF

Wx
Dw
3GPP AAA
Server
Wm

Wo Wy

PDG

Wp

Wz

Wu
Traffic and signaling
Signaling

CGF*

**

OCS*

Billing
System*

Note: * Elements duplicated for picture

layout purposes only, they belong to the
same logical entity in the architecture
baseline.
** is a reference point currently missing

Figure 4.1-1: Logical baseline architecture for 3GPP

4.2 Architecture for the evolved system non-roaming case

Figure 4.2-1 depicts the base line high level architecture for the evolved system.
Editor's note:
-

It is not the finalized architecture model for the evolved system. i.e. it does not contain all
functions/interfaces required, and some functions/interfaces may be added, deleted or modified in the
course of the key issue discussions.

In this TR, a trusted non-3GPP IP access is also referred to as the non-3GPP IP access, and an untrusted
non-3GPP IP accesses are accommodated by is also referred to as the WLAN 3GPP IP access.

3GPP

Release 8

16

3GPP TR 23.882 V8.0.0 (2008-09)

Figure 4.2-1: Logical high level architecture for the evolved system
The location of the functions belonging to MME/UPE is dependent on RAN CN function split table, i.e. it is FFS.
It is FFS whether there is an interface between UTRAN and evolved packet core.
The separation of MME/UPE into two separate entities is FFS.
Editor's Note: Additional Architecture diagram updates will be done following concrete resolutions on the other key
issues. The current figure above does not intend to draw any conclusion regarding the functional grouping
within the Evolved Packet Core. The number of interfaces and their termination points may change once
the grouping and other key issues are resolved.
3GPP Anchor
The 3GPP Anchor is a functional entity that anchors the user plane for mobility between the 2G/3G
access system and the LTE access system.
SAE Anchor
The SAE Anchor is a functional entity that anchors the user plane for mobility between 3GPP access
systems and non-3GPP access systems.
Whether the 3GPP Anchor functional entity is co-located with the MME/UPE or the SAE Anchor or both is FFS. I.e. it
is FFS whether to standardize open interfaces between the MME/UPE and the 3GPP Anchor and between the 3GPP
Anchor and the SAE Anchor.
NOTE 1: The Inter Access System Anchor (IASA) is indicated with a dotted box in Figure 4.2-1, because it is used
in several parts of this TR, including in figures, to represent both the 3GPP Anchor and the SAE Anchor.
NOTE 2: It is FFS how to map SAE architecture for the non-roaming case in Figure 4.2-1 to the roaming
architectures in clause 4.3
ePDG (evolved PDG)
It comprises the functionality of a PDG according to 3GPP TS 23.234 [28]; modifications/extensions compared to PDG
are FFS.

3GPP

Release 8

17

3GPP TR 23.882 V8.0.0 (2008-09)

Reference points
S1:

It provides access to Evolved RAN radio resources for the transport of user plane and control plane
traffic. The S1 reference point shall enable MME and UPE separation and also deployments of a
combined MME and UPE solution.

S2a:

It provides the user plane with related control and mobility support between trusted non 3GPP IP access
and the SAE Anchor.

S2b:

It provides the user plane with related control and mobility support between ePDG and the SAE Anchor.

S3:

It enables user and bearer information exchange for inter 3GPP access system mobility in idle and/or
active state. It is based on Gn reference point as defined between SGSNs.
User data forwarding for inter 3GPP access system mobility in active state (FFS).

S4:

It provides the user plane with related control and mobility support between GPRS Core and the 3GPP
Anchor and is based on Gn reference point as defined between SGSN and GGSN.

S5a:

It provides the user plane with related control and mobility support between MME/UPE and 3GPP
anchor.

It is FFS whether a standardized S5a exists or whether MME/UPE and 3GPP anchor are combined into one entity.
S5b:

It provides the user plane with related control and mobility support between 3GPP anchor and SAE
anchor. It is FFS whether a standardized S5b exists or whether 3GPP anchor and SAE anchor are
combined into one entity.

S6:

It enables transfer of subscription and authentication data for authenticating/authorizing user access to the
evolved system (AAA interface).

S7:

It provides transfer of (QoS) policy and charging rules from PCRF to Policy and Charging Enforcement
Point (PCEP).
The allocation of the PCEP is FFS.

Sgi:

It is the reference point between the Inter AS Anchor and the packet data network. Packet data network
may be an operator external public or private packet data network or an intra operator packet data
network, e.g. for provision of IMS services. This reference point corresponds to Gi and Wi functionalities
and supports any 3GPP and non-3GPP access systems.

Protocol assumption:
-

The interfaces between the SGSN in 2G/3G Core Network and the Evolved Packet Core (EPC) shall be based on
GTP protocol.

The interfaces between the SAE MME/UPE and the 2G/3G Core Network shall be based on GTP protocol.

4.3 Architecture for the evolved system roaming cases

Editor's note: It is not the finalized architecture model for the evolved system. I.e. it does not contain all
functions/interfaces required, and some functions/interfaces may be added, deleted or modified in the
course of the key issue discussions.
Editor's note: The protocol assumed in each interfaces in the roaming cases shall be inline with the protocol
assumption in the non-roaming case.

3GPP

Release 8

18

3GPP TR 23.882 V8.0.0 (2008-09)

4.3.1 Scenario 1: Evolved packet core in the Visited network Evolved

packet core in the Home network
In this clause it is considered the high level target roaming architecture in case both the visited and the home networks
are evolved Packet Core networks. Migration routes to this target roaming architecture are FFS. Two alternative
architectures are shown, depending on whether UE traffic has to be routed to the HPLMN or not. It is FFS whether the
two alternatives can be used in parallel by a UE, e.g. when only a part of the user's traffic has to be routed to the
HPLMN.
In case UE traffic is routed to the home network, the SAE architecture is depicted in figure 4.3-1.
Editor's note: The update in clause 4.2 at SA2#52 on showing the split of the IASA into two functional entities,
namely a 3GPP anchor and SAE anchor, requires the following figure to be updated. Whether the anchors
are going to be separated is FFS. In particular, although the Home IASA is illustrated in the HPLMN, it is
still an open issue whether the SAE anchor is located in the VPLMN. It is FFS how the above changes
impact the SAE roaming architecture depicted below.

Figure 4.3-1: SAE Roaming architecture Home routed traffic

For home routed user traffic the Inter AS Anchor is located in the HPLMN. Due to this reason, an interface between the
Visited 3GPP Anchor and Home EPC is needed. This interface is referred to as S8.
The vPCRF is located in the VPLMN, while hPCRF is in the HPLMN.
Usage of S6, S8 and S9 for providing visited network with static/dynamic policies is FFS.
The 3GPP anchor, which anchors user plane for mobility between the 2G/3G access system and the LTE access system,
is located in the VPLMN.
Note: It is FFS what is the functionality of the Home Inter AS anchor.
Note: It is FFS what is other functionalities of the 3GPP anchor in VPLMN besides user plane anchoring between
2G/3G access systems and LTE system.
It is FFS whether the Mobility anchor between 3GPP and non-3GPP access systems is provided by entities in the visited
network or by the Home Inter AS Anchor.
The IASA in the home network remains the entity that terminates the IP Access Service.
In case UE traffic is not routed to the HPLMN, the SAE architecture is depicted in the following figure 4.3-2.

3GPP

Release 8

19

3GPP TR 23.882 V8.0.0 (2008-09)

Editor's note: The update in clause 4.2 at SA2#52 that the split of the IASA into two functional entities, namely a
3GPP anchor and SAE anchor, requires the following figure to be updated. The decision to split the
anchors is FFS.

Figure 4.3-2: SAE Roaming architecture Local Breakout

Usage of S6 and S9 for providing visited network with static/dynamic policies is FFS.
In the case it is decided that PCRF in the visited network is used, one alternative solution is that the enforcement of the
Home PLMN policies (e.g.: QoS and charging policies) by the visited Inter AS Anchor is performed through the
interaction of Home and Visited PCRF. Possibly, the Visited PCRF may add/modify policies according to those defined
in the VPLMN. The related reference point between PCRFs is referred as S9.
Additional reference points for roaming scenarios (in addition to those described in clause 4.2)
S8:

indicates the roaming variant of S5 reference point when the Inter AS Anchor is located in the HPLMN.

S9:

indicates the roaming variant of the S7 reference point for the enforcement in the VPLMN of dynamic
control policies from the HPLMN.

NOTE:

S2 and S4 reference points could be interoperator when the GGSN/PDG and the Inter AS anchor belong
to different PLMNs.

4.4 Architectural principles

The following architectural principles are agreed. Note that roaming in this section refers only roaming between SAE
networks.
Editors note: The SAE architecture in section 4.2 and 4.3 need to be updated according to these principles.
-

S10 interface between MME/UPE and MME/UPE will be standardized for MME/UPE relocation, which is
functionally similar to S3 for inter 2G/3G LTE handover.

For the roaming case with the local breakout, the e-PDG shall be in the visited network.
For the roaming cases with home routed traffic, the e-PDG can be in the visited network when the visited
network owns the I-WLAN or has a business relationship with the I-WLAN operator. It can be in the home
network.

For the roaming case with home routed traffic, there is a user plane entity for LI and CDR generation for non3GPP access in the visited network.

3GPP

Release 8

20

3GPP TR 23.882 V8.0.0 (2008-09)

S6a between MME/UPE and HSS for authentication and authorization.

S6b between SAE PDN gateway and HSS for authorization

S6c between SAE MM anchor and HSS (as an AAA server) for mobility related authentication if needed.

For S6a, S6b and S6c, they can be collapsed into one as a result of the collocated functions.

It is desirable to specify the same protocols over S5(a/b) and S8.

For non-roaming case, there is no open interface between SAE MM anchor and SAE PDN gateway. (see the
possibly different definitions of SAE MM anchor and SAE PDN gateway in Annex I)

Requirements on the Architecture

Editors Note: This clause identifies the major requirements on the architecture that guide the architecture evolution.

High-level principles
1 3GPP and non 3GPP access systems shall be supported.
2 Shall provide scalable system architecture and solutions without compromising the system capacity, e.g. by
separating the control plane and the transport plane.
3 Interworking with release 6 3GPP systems (i.e. 3GPP-PS core, 3GPP-IP access and IMS) shall be supported
4 The C plane response time for the IP-CAN shall be such that (excluding DRX times) the mobile can move from
a fully idle state (this is an idle state where the mobile is GMM attached, has an IP address allocated and is IMS
registered) to one where it is sending and receiving user plane data in a significantly reduced time. The target
time is less than 200 ms;
5 The Evolved 3GPP System shall support SMS and equivalent functionality to that provided by the MSC's "SMS
message waiting flag". Note: this might be provided by the R'7 WID for "support of SMS and MMS over generic
3GPP IP access".
6 The Evolved 3GPP System shall support basic IP configuration for terminals that do not have IP connectivity.
7 The functional split will be defined to sufficient level of detail to avoid overlapping/duplicated functionality,
signalling and related delays.
8 The basic IP connectivity in the evolved architecture is established during the initial access phase of the UE to
the network.
9 For the set-up of IP connectivity with enhanced QoS, the number of signalling transactions shall be minimised.
10 Mobility Management functionality shall be responsible of mobility within the Evolved 3GPP System and
between the Evolved 3GPP System and different types of access systems.
11 The Evolved 3GPP Mobility Management solution shall be able to accommodate terminals with different
mobility requirements (e.g.: fixed, nomadic and mobile terminals);
12 The Evolved 3GPP Mobility Management shall allow the network operator to control the type of access system
being used by a subscriber.
13 Mobility procedures within the Evolved 3GPP System, between the Evolved 3GPP System and existing 3GPP
Access Systems and between Evolved/Existing 3GPP access systems and non 3GPP access system shall provide
seamless operations of both real-time (e.g. VoIP) and non real-time applications and services by, for example,
minimizing the packet loss and interruption time.
14 The Evolved 3GPP system should allow route optimization by selecting or re-selecting the MME, UPE, 3GPP
Anchor or SAE anchor so that the user plane traffic does not need to be tunneled outside the current network
area . This applies in all roaming scenarios (e.g.: when both users are in a visited network) and some intraPLMN scenarios (e.g. serving UPE/IASA of the UE has been changed due to UEs mobility). This is desirable in

3GPP

Release 8

21

3GPP TR 23.882 V8.0.0 (2008-09)

order to prevent additional delay and unnecessary waste of backbone bandwidth. The policy rules of the home
network should control whether or not local breakout is used.
15 In order to maximise users' access opportunities, the evolved architecture should allow a UE which is roaming to
a VPLMN to use a non-3GPP access network with which the VPLMN has a business agreement. For example, it
should be possible for a user to use a WLAN access network with whom only the visited operator has a direct
relationship (not the home operator).
16 The Evolved 3GPP System shall support Ipv4 and Ipv6 connectivity. Interworking between Ipv4 and Ipv6
terminals, servers and access systems shall be possible. Mobility between access systems supporting different IP
versions should be supported with minimum network/terminal impacts.
17 Subscriber security procedures in the Evolved 3GPP System shall assure (at least) the same security level as
current 3GPP CS/PS networks;
18 Access to Evolved 3GPP System shall be possible via existing Rel 99 USIM. Evolved 3GPP System shall also
permit access to inbound roamers from mobile networks with Rel 5 HSS;
19 The authentication framework should be independent from the specific access network technology;
20 The evolved 3GPP System shall ensure necessary support for the existing charging principles (e.g.: calling party
pays) both at application and bearer level.
21 Transport overhead needs optimization, especially for the last mile and radio interfaces.
22 Signalling overhead on the radio interface should be minimised.
23 Radio interface multicast capability shall be a built-in feature.
24 Evolved system shall support IP multicast service which provides point to multipoint user data transport.
25 The SAE/LTE system shall at least support handling of regional subscription / regional roaming / access
restriction (the terms are defined in 22.011). In case a regional subscription / regional roaming / access restriction
applies, the network may provide the UE with guidance to find another tracking area / network.
26 The SAE/LTE system shall be able to handle the situation where the home operator changes a user's subscription
such that it changes roaming restrictions.
27 Roaming etc restrictions shall not be more granular than Tracking Area (consideration for support of RAT
specific restrictions needs to be made). SA1 needs to clarify the requirements on RAT specific restrictions.
28 Handling of roaming etc. restrictions for UEs in LTE_IDLE and LTE_ACTIVE state shall be aligned.
29 LTE/SAE shall support the same level of User Identity Confidentiality as today's 3GPP system (e.g. Idle mode
signalling and attach/re-attach with temporary user identities)
30 The SAE/LTE system shall support network sharing functionality. Details need to be studied in RAN WGs and
SA2.
31 The SAE/LTE system shall support redundancy concepts / load sharing of network nodes, e.g. similar to today's
Iu-flex mechanisms. All nodes other than cell site node should be considered "distributed resources utilising load
sharing/redundancy mechanisms".
32 The SAE/LTE system shall provide effective means to limit signalling during inter-RAT cell-reselection in
LTE_IDLE state. For example, similar performance to that of the "Selective RA Update procedure" defined in
TS 23.060. Optimisation for movement to/from states such as URA-PCH and GPRS-Standby shall be studied.
33 It shall be possible to support service continuity between IMS over SAE/LTE access and the CS domain. It shall
be achieved with minimum impact on the CS domain.
34 It shall be possible to support IMS and its communication services over SAE/LTE access, including the support
of calls between IMS over SAE/LTE access and the CS domain.
35 It shall be possible for the operator to provide the UE with access network information pertaining to locally
supported 3GPP and non-3GPP access technologies. The access network information may also include operator

3GPP

Release 8

22

3GPP TR 23.882 V8.0.0 (2008-09)

preferences based on locally available 3GPP and non-3GPP access technologies, and the information may be
restricted to the access technologies or access networks the UE can use.
36 It shall be possible to perform Lawful Intercept for both roaming and non-roaming users for all access systems
the user are allowed to use.
37 The mobility management shall be able to provide location hiding capabilities without increasing system
complexity. The location hiding capabilities may be provided differently per operator (e.g. applied for all users,
only for the required users, not required at all). The mobility management shall also be able to enable location
privacy protection when to users who require this privacy service, and in this case local breakout and
route optimization support might be disabled.
38 The mobility management between 3GPP and non 3GPP access systems should have minimum impact on the
access technologies and it should be independent from transport technologies.
39 The mobility management shall support the anchoring of traffic for a UE within a SAE CN node to allow
charging and other service enabling functions to be performed. This does not preclude the possibility to change
the SAE CN nodes to allow route optimization.
40 It shall be possible to be compatible with the existing 3GPP roaming interfaces when SAE interworks with preSAE/LTE network.
41 The mobility management is provided without degrading the current 3G security level. This means both control
signalling and user data are securely transported. It is desirable that the mobility management entity for LTE
access is not directly addressable by the UE.
Editor's note: Initial list to be completed.

Scenarios and Solutions

Editors Note: This clause identifies potential scenarios based on drivers such as social and new emerging
technologies that have an impact on the existing reference architecture. The identified scenarios are used
to explore the architecture options and as a base for identifying the key architectural issues. The scenarios
may be based on the outcome from AIPN in SA1 and the TSG-RAN's Study Item on Radio Evolution
(see SP-040915). The scenarios should identify how migration and/or evolution from current systems
occur.

Key Architectural Issues

Editors Note: This clause identifies key issues e.g. related to mobility and QoS mechanisms, solutions for key Issues
and impact on the Architecture i.e.
7.1

Key Issue 1

7.1.1

Description of Key Issue 1

7.1.2

Solution for key issue 1

7.1.3

Impact on the baseline CN Architecture

7.1.4

Impact on the baseline RAN Architecture

7.1.5

Impact on terminals used in the existing architecture]

3GPP

Release 8

23

3GPP TR 23.882 V8.0.0 (2008-09)

7.1 Key Issue Policy control and Charging

7.1.1 Description of Key Issue Policy control and Charging
The PCC functionality comprises important functionality related to the configuration of certain filters and packet
processing rules. Typical use of such rules and filters include flow based charging, gating, QoS control, etc. Such rules
may implement multiple services of various types, including ones from 3rd party suppliers and hence are an important
part since it is related to a subscription and how services are authorized and charged for e.g. zero rating, price bundling,
premium price etc depending on the particular configuration of an operator. In a Rel-7 context PCC considers a number
of input parameters such as QoS parameters and for GPRS case TFTs and if a PDP context was activated by a secondary
PDP context activation procedure, etc. before finally implementing a rule. It is key for an operator to be able to use a
configuration of rules (policy and charging), which apply to Rel-7 architecture and terminals also in long term, i.e.,
smooth migration is important. The PCRFs interaction with future CN should be based on the existing PCC Rel-7
interfaces. It should be noted that some Rel-7 models (e.g. the QoS model) may be further evolved in the SAE work.
With the introduction of new 3GPP radio access technologies operators need to be in control of the use of each 3GPP
radio access technology. The policy should take subscriber identity and other circumstances into account. The use of a
different radio access technology may also lead to changes in other policies, e.g. different rating, etc.

7.1.2 Solution for key issue Policy control and Charging

-

It shall be possible to inform the PCRF what radio access technology a subscriber is utilizing since depending on
operator configuration it may influence what policy control and charging rule is being activated by a PCRF.

The PCC interfaces already defined in Rel-7 shall be used as a basis in an SAE context and may be evolved to
meet SAE requirements.

Editors Note: In a B1 context, cf. Annex B, the enforcement point of the mobility anchor that resides in the core
network shall be controlled by a PCRF. In a B2 context, it is FFS if the Inter AS-MM shall contain an
enforcement point that is controlled by a PCRF. Alternatively in a B2 context, it is FFS how the
interaction between the PCRF(s) and IP Gateways is performed in Inter Access System Handover.
-

The PCC functionality shall in an effective way be able to handle different QoS models cf. e.g. I-WLAN vis-vis WCDMA.

7.1.3 Impact on the baseline CN Architecture

The PCC functionality shall be evolved from the existing Rel-7 PCC interfaces.
It shall be possible to inform the baseline CN architecture what radio access technology (including an evolved RAN) is
being used by a subscriber.

7.1.4 Impact on the baseline RAN Architecture

In case the baseline RAN architecture support multiple RAN access technologies it may be needed to inform the PCRF
what radio access technology a subscriber is utilizing including an evolved RAN access technology.

7.1.5 Impact on terminals used in the existing architecture

Editors Note: It is FFS whether there is any particular terminal impact from the evolution of Policy control and
Charging architecture. However at the moment no particular terminal impact has been identified.

7.2 Key Issue- Roaming with Local Breakout

7.2.1 Description of Key Issue Roaming with Local Breakout
Roaming is when users receive service when they are in a VPLMN, i.e. in a network other than their HPLMN.

3GPP

Release 8

24

3GPP TR 23.882 V8.0.0 (2008-09)

Local breakout might optimize access to visited network services and might allow for user plane traffic route
optimization. Control plane traffic may also break out locally for emergency services or to obtain better signalling
performance and better user experience. In this clause it is clarified which interfaces are the roaming interfaces, and
how roaming and local breakout works in general for the evolved architecture.

7.2.2 Solution for key issue Roaming with Local Breakout

Roaming of subscribers (to different VPLMNs and to different types of VPLMN access) requires certain policies from
the home operator to be available in the Visited network. This information may be downloaded or it may be preconfigured and used during the subscriber access to the visited network. These policies may be static, dynamic or a
combination.
In order to provide high performance as well as real time services for roaming customers, efficient routing of user data
or media traffic is required. For some services, e.g. emergency services, Control plane traffic may also break out locally.
Features shall be provided to the home operator to negotiate with the visited operator:
-

if the traffic of the user is always transported to the home network over a roaming interface or broken out locally
for transport towards the destination;

and, if the default IP address (i.e. the IP address from PDN address space to access PDN) can be allocated by the
visited PLMN or not.

Furthermore, it should be possible to perform local breakout for some traffic of the user but not the other traffic. How to
accomplish this is FFS.
Such policies shall be based on the home operator's preference and have a granularity such that the gain justifies the
roaming infrastructure and complexity in operations for such a set up.
The IP Gateway (defined as GW in the context of current Policy and Charging Control work) in a VPLMN may connect
to multiple HPLMNs. The IP Gateways in the VPLMN serves to enforce the policies and charging as negotiated
between the visited and home operators. The result of the enforcements and the information of charging should be
provided to the home operator when required.
Using the policy enforcement function in the IP Gateway in the visited network, home operators can control routing of
traffic for roaming users. The IP Gateway in the HPLMN serves as a global mobility anchor point and at the same time
enforces the policies of, and the charging for the home operator. This IP Gateway can provide session continuity, even if
the VPLMN changes.
In order to support return traffic optimization for the roaming user, the roaming user should use an IP address belonging
to the VPLMN. On the other hand, in order to attain session continuity when roaming from HPLMN to VPLMN, the
user should keep using the IP address that is assigned by HPLMN. Mobility management protocol should be aware of
this so that it can support local breakout for roaming users.
The initial focus is put on local breakout of IMS bearer traffic, however since SAE must apply in general, the impacts
on local breakout from other services shall not be precluded.

7.2.2.1

Analysis of Local Breakout of IMS bearer traffic

Local breakout of IMS bearer traffic allows for route optimisation for IMS bearer traffic so that it does not need to be
tunnelled outside the current network area. This applies in all roaming scenarios and some intra-PLMN scenarios. This
is desirable in order to prevent additional delay and unnecessary waste of backbone bandwidth. The policy rules of the
home network should control whether or not local breakout is used. Depending on the solution the IMS control plane
traffic (i.e. SIP signalling) may be anchored in the home network or in the visited network.

3GPP

Release 8

7.2.2.1.1
7.2.2.1.1.1

25

3GPP TR 23.882 V8.0.0 (2008-09)

Alternative solution 1 Visited P-CSCF

Description

In this scenario the PDN SAE GW and the P-CSCF are located in the Visited network, as depicted in Figure X1.

Figure 7.2-1: Local Breakout with Visited P-CSCF

From SAE perspective it looks as if the accessed PDN is in the Visited network. Mw is the reference point crossing the
inter-PLMN boundary. In order to authorise a bearer, the vPCRF function may have to contact the hPCRF via S9.
This approach requires only one IP address for both SIP signalling and user plane traffic.
This configuration does not support inter-PLMN handovers because the latter imply a relocation of the PDN SAE GW
from one VPLMN to another.
This configuration also requires special arrangement for the roaming subscriber to access non-IMS services hosted in
the HPLMN, without exposing those services to all subscribers in the VPLMN.
7.2.2.1.1.2

Impact on the baseline CN Architecture

Impact on REL-7 PCC architecture is FFS.

7.2.2.1.1.3

Impact on the baseline RAN Architecture

No impact currently foreseen.

7.2.2.1.1.4

Impact on terminals used in the existing architecture

FFS.

7.2.2.1.2
7.2.2.1.2.1

Alternative solution 2 Dual IP addresses

Description

In this scenario, there are two PDN SAE GWs:

PDN SAE GW1 used for anchoring of SIP signalling and located in the Home network;

PDN SAE GW2 used for anchoring of bearer traffic and located in the Visited network.

3GPP

Release 8

26

3GPP TR 23.882 V8.0.0 (2008-09)

Figure 7.2-2: Local Breakout with Dual IP addresses

From SAE perspective this looks like concurrent access to Multiple PDNs (refer to the Key Issue in Section 7.10). Rel-7
IMS supports the usage of different IP addresses for the SIP signalling and for the bearer traffic. Note that when PCC
function is active, support of multiple IP addresses is not possible/does not work today. In addition, certain NAT
configurations do not work with multiple IP addresses on IMS.
S9 is used in order to provide PCC rules to the vPCRF function in the Visited network, which then distributes the PCC
information towards PDN SAE GW2 via S7.
Inter-PLMN handovers are supported by re-assigning a new PDN SAE GW2 in the target VPLMN (note that PDN SAE
GW1 is not re-assigned).
For intra-PLMN handovers involving Serving SAE GW change it may be possible to defer the re-assignment of a new
PDN SAE GW2 until the completion of any ongoing calls.
7.2.2.1.2.2

Impact on the baseline CN Architecture

Impact on REL-7 PCC architecture is FFS.

Applicability to the GTP-based S8a is FFS.
7.2.2.1.2.3

Impact on the baseline RAN Architecture

No impact currently foreseen.

7.2.2.1.2.4

Impact on terminals used in the existing architecture

How the IMS client in the terminal is instructed about the usage of two IP addresses is FFS.
In case of handover involving PDN SAE GW change (e.g. inter-PLMN handover), the IMS client may have to manage
the change of the IP address in the bearer plane (e.g. by sending SIP reINVITE to the remote party).

7.2.2.1.3

7.2.2.1.3.1

Alternative solution 3 MIPv6 Route Optimisation when host-based mobility is

used
Description

In this scenario there is only one PDN SAE GW located in the Home network. Inter-technology mobility is based on
Client MIP (e.g. DS MIPv6). The Care-of Address (CoA) is assigned by the Serving SAE GW, located in the Visited
network.

3GPP

Release 8

27

3GPP TR 23.882 V8.0.0 (2008-09)

Figure 7.2-3: Local Breakout with MIPv6 Route Optimisation

Before RO is activated, all traffic (both SIP signalling and bearer traffic) is backhauled to the Home network. When the
RO is activated, the bearer traffic can break out from the Serving GW and can be routed directly to the correspondent
node.
S9 is used in order to provide PCC rules to the vPCRF function in the Visited network, which then distributes the PCC
information towards Serving SAE GW via S7.
NOTE:

For MIP RO traffic the packet filtering in the Serving SAE GW should be beyond the IP-5 tuple.

The MIPv6 Return Routability procedure used for preparation of the optimised route may be an issue for real time
media in case of CoA change (e.g. due to inter-technology handover) with activated RO, because of the need to reestablish the optimised route on the new CoA. However, there are optimisations for the MIPv6 Return Routability
procedure available to reduce signalling and handover delay.
7.2.2.1.3.2

Impact on the baseline CN Architecture

This approach is not aligned with the current assumption about the usage of network-based mobility on S8b (cf. new
reference point Gi* in the figure).
Impact on REL-7 PCC architecture is FFS.
7.2.2.1.3.3

Impact on the baseline RAN Architecture

No impact currently foreseen.

7.2.2.1.3.4

Impact on terminals used in the existing architecture

7.3 Tracking Area

7.3.1 Description of issue
In GSM, mobiles are tracked in Location Areas and Routeing Areas. In UMTS, mobiles can be tracked in UTRAN
Registration Areas as well as Las and Ras. Within this Technical Report, Tracking Area is used as a generic name for
LA, RA and URA.
Within the LTE/SAE work, there has been debate about how many levels of Tracking Area there should be.

7.3.2 Agreements on Tracking Area Issues

It is agreed that:
-

There is only one common Tracking Area concept defined for RAN and CN in LTE/SAE.

The location of a UE in LTE_IDLE is known by the network on a Tracking Area granularity.

3GPP

Release 8

28

3GPP TR 23.882 V8.0.0 (2008-09)

A UE in LTE_IDLE is paged in all cells of the Tracking Area in which it is currently registered.

In order to avoid excessive Tracking Area update signalling within LTE, for terminals located on a Tracking Area
border, the following solutions should be considered (detailed solutions are FFS);
a) Allow one LTE cell to belong to multiple Tracking Areas, and allow the Tracking Areas to partially overlap
each other
b) Support the allocation of multiple Tracking Areas to the same terminal.

3GPP

Release 8

29

3GPP TR 23.882 V8.0.0 (2008-09)

7.4 Radio Access Network Core Network Functional Split

This clause describes the allocation of functions to either the RAN or the CN.
Table 1: RAN-CN functional split

3GPP

Release 8
Location:
High-level Function:
Radio resource management
Policy Decision
Admission/commitment of requested or
downgrade to available radio resources
Admission/commitment of network resources
Authorisation of QoS based on
subscription/service
Uplink packet Classification
Uplink packet re-classification based on operator
administered subscriber policies
Uplink packet re-classification based on
subscription independent serving operator
policies for the transport
Uplink QoS policy enforcement of negotiated QoS

30
EnodeB

3GPP TR 23.882 V8.0.0 (2008-09)

Above
EnodeB

X
X
X
X

Done by UE.
X
X

If needed and visible. E.g. Mapped from

radio bearer.

E.g. by scheduling. (does not include

packet marking, QoS Authorisation).
Does not include radio QoS (by
definition done in RAN).

Downlink QoS policy enforcement of negotiated

QoS
Attach, Subscriber & Key Management,
Authentication and Authorisation
Location management, Paging, Intra-radio access
mobility in LTE_IDLE
- Indicate cell information (PLMN-ID, tracking
area-ID, radio parameters) to UE for
cell/PLMN selection in LTE_IDLE
- Accept/deny UE's location (tracking area) in
LTE_IDLE

X
X

For CN signalling
For RAN signalling

Ciphering terminating in UE
- For user plane data
- For CN signalling
- For RAN signalling

In the case of MOCN shared network

configuration, each CN operator must
be able to configure its own roaming
agreements.
For paging inactive Ues and for
recovery

X
X

To decide on tracking areas allowed for

UE/user

As yet, not required to be provided by

the "access system".

X
-

X
FFS

Same as the location of the RAN

signalling termination.
X
X

If needed

IP Header compression between UE and network

Intra-radio access mobility in LTE_ACTIVE

- Determine allowed tracking areas and PLMNs
for handover in LTE_ACTIVE
- Guiding the measurement process within UE
for handovers in LTE_ACTIVE
- Decision for intra access system handover in
LTE_ACTIVE
- Path switch/mobility anchor for intra access
system handover in LTE_ACTIVE
- Support for lossless HO (E.g. Downlink

It is FFS if the PLMN-ID should be

subdivided.
X

Includes appropriate RAN capabilities

and RAN transport resources
Transport network resources outside
RAN

Downlink packet classification

Store UE's location (tracking area) in

LTE_IDLE
- Initiation (trigger) of Paging of LTE_iDLE Ues
within tracking area
- Local Storage of subscriber information about
allowed PLMNs and location restrictions within
PLMN
Radio channel coding
Integrity protection terminating in UE
- For user plane data

Comments

X
FFS

FFS

FFS

FFS

The requirements for RAN signalling

encryption need to be clarified.
It is agreed that, within the network, IP
Header Compression is performed in
between the User Plane Encryption
functionality and the Flow Based
Charging functionality.
Derived from subscription and provided
to RAN.
Same as the location of the RAN
signalling termination.
Same as the location of the RAN
signalling termination.

X
FFS

3GPP

FFS

If needed, check requirements with SA1

Release 8
Location:
High-level Function:
duplication, Packet forwarding or Anchor)
- Support for seamless HO (E.g. Downlink
duplication, packet forwarding or Anchor)
- Transfer of UE specific contexts for handover
of LTE_ACTIVE Ues
Radio protocols (HARQ, scheduling etc.)
Charging
IP Address Allocation
Roaming
Local breakout
Inter-Radio Access mobility, (3GPP <> 3GPP
RAT) in LTE_ACTIVE
- Determine tracking areas and PLMNs allowed
for handover in LTE_ACTIVE
- Guiding the measurement process within UE
for handovers in LTE_ACTIVE
- Decision for inter access system handover in
LTE_ACTIVE

Path switch/mobility anchor for inter access

system handover in LTE_ACTIVE
Transfer of UE specific contexts for handover
of LTE_ACTIVE Ues

Inter-Radio Access mobility, (3GPP <> non-3GPP

RAT) in LTE_ACTIVE
Inter-Radio Access mobility (3GPP <> 3GPP RAT)
in LTE_IDLE
- Indicate cell information (PLMN-ID, tracking
area-ID, radio parameters) to UE for
cell/PLMN selection in LTE_IDLE
- Accept/deny and store UE's location (tracking
area) in LTE_IDLE
- Initiation of Paging of LTE_IDLE Ues within
tracking area
- Local Storage of subscriber information about
allowed PLMNs and location restrictions within
PLMN
Inter-Radio Access mobility (3GPP <> non-3GPP
RAT) in LTE_IDLE
Access system selection
Load sharing among RATs

31

3GPP TR 23.882 V8.0.0 (2008-09)

EnodeB

Above
EnodeB

FFS

FFS

FFS

FFS

Comments
Sufficiently good for voice HO

X
X
X
X
X
X
FFS

FFS

FFS

FFS

Derived from subscription

Same as the location of the RAN
signalling termination.
Based on measurements and
potentially resource availability, blind
handover could also be possible.
Same as the location of the RAN
signalling termination.

X
FFS

FFS

GRPS core and LTE MME/UPE need to

exchange UE specific data for both CN
specific context and Radio specific
information.
FFS in SA2, includes e.g. I-WLAN
UTRAN, eUTRAN and GERAN

X
X
X
X

To decide on tracking areas allowed for

UE/user
FFS in SA2, includes e.g. I-WLAN

FFS

X
Solutions for load sharing among RATs
are FFS.

Lawful intercept
X
Positioning
X
X
Flow Control and buffering
FFS
FFS
If Needed
MBMS
X
X
NOTE 1: Packet Re-classification and QoS Enforcement at operator interconnect are done in CN if needed.
NOTE 2: transcoding has been considered and the conclusion is that it is handled on the Application level (IMS), and
hence not in RAN or CN.
NOTE 3: The function "reporting of unsent data volume" has been discussed. It has been agreed that there are no clear
requirements to have this function included in the RAN-CN functional split table at this point. It can be added to
the table and supported in the Evolved Architecture if sufficient reasons, e.g. significant charging impacts, are
presented later on.

3GPP

Release 8

32

3GPP TR 23.882 V8.0.0 (2008-09)

7.5 Key Issue Inter 3GPP Access System Mobility in Idle State
7.5.1 Description of Key Issue Inter 3GPP Access System Mobility in Idle
State
Idle State Inter 3GPP Access System Mobility functionality maintains the registration of a user/UE in the serving 3GPP
Access System so that mobile originated and mobile terminated packet transfer may be initiated. In Idle State the UE
reselects between SAE/LTE and other 3GPP access systems. Furthermore, Idle State Inter 3GPP Access System
Mobility updates within the network any user plane routing and any potential tunnelling information so that data path is
established between intersystem mobility anchor and the UPE of the 3GPP Access System the UE is registered with.
Idle State Inter 3GPP Access System Mobility maintains subscriber identity confidentiality, i.e. temporary user identities
are used where necessary.

7.5.2 Solution for key issue Inter 3GPP Access System Mobility in Idle State
Editor's note: Whether a UE can be registered in more than one 3GPP access system at one time and the possible
effects on SAE/LTE is FFS.

7.5.2.1
7.5.2.1.1

Alternative Solution A
General

The SAE/LTE 3GPP Access System has an MME (FFS whether in RAN or CN). The corresponding 2G/3G MME is the
SGSN. Furthermore, the SAE/LTE 3GPP Access System has a UPE. The corresponding 2G/3G UPE is the SGSN or
SGSN/GGSN. The UE registers with the MME and UPE of the selected 3GPP Access System. The MME of the 3GPP
Access System stores a UE contexts, e.g. permanent and temporary user identities, mobility state, tracking area. The
UPE of the 3GPP Access System stores a UE context, e.g. parameters of the basic IP bearer service, keeps network
internal routing information. The MME can store the UE context for long to allow for detach and reattach with
temporary identity (user identity confidentiality). The UE is only in one 3GPP access systems registered at one time and
not at multiple in parallel.
The SAE/LTE 3GPP Access System combines network attach and establishment of basic IP bearer capabilities (always
on), i.e. all parameters required for a best effort IP bearer service are allocated for the UE. In idle state all data transfer
resources between UE and network are released and only information for basic IP bearer is stored in the network. There
is a simple, preferably unique, mapping between 2G/3G and SAE IP bearer parameters
According to 2G/3G and LTE idle state definitions the UE (re-)selects cells and also access systems. The change of the
access system in idle state triggers a network registration by the UE. It is FFS whether this is triggered by different
tracking areas for different access systems or by other information.
User identity confidentiality requires the UE to register the access system change with the network using a temporary
identity. The temporary identity is resolved to a permanent identity by the old serving MME. This information transfer
between old and new serving MME transfers also other UE context information like security parameters and IP bearer
parameters to the new serving MME/UPE. The UE context transfer is preferred as it is typically faster than establishing
security association and IP bearer again in another access system.

7.5.2.1.2

Alternative Solution A1

In the information flow below MME and UPE are shown together in the first case, for simplicity reasons.
NOTE:

This does not preclude a separation. Two independent entities require an interface between both for
example for paging, then registration between each other and double context transfer.

In the second case, MME, UPE and Inter AS Anchor are shown together as another option.
The routing between UPE and intersystem mobility anchor is updated, which is the precondition for being able to page
the UE when downlink data arrive. For change from 2G/3G to SAE/LTE case, establishment of basic IP bearer
capabilities (always on) (i.e. all parameters required are allocated to the UE) is performed during the change procedure

3GPP

Release 8

33

3GPP TR 23.882 V8.0.0 (2008-09)

if no basic IP bearer exists before change. The home register (e.g. HSS) is updated with registration of the UE at another
MME/UPE. This scenario is shown in the figure 7.5-1.
This solution is also covering the case when the MME/UPE and the Intersystem Mobility Anchor is co-located (see step
10 of the signalling flow), see figure 7.5.1.a. In this case the routing between UPE and intersystem mobility anchor
updates do not require standardised mechanism.

Figure 7.5-1: 3GPP Inter Access System Change between SAE/LTE and 2G/3G

Figure 7.5-1.a: 3GPP Inter Access System Change between SAE/LTE and 2G/3G (MME/UPE/IASA
collocated)

3GPP

Release 8

34

UE

SAE
MME/UPE

3GPP TR 23.882 V8.0.0 (2008-09)

Intersystem
Mobility
Anchor

2G/3G
MME/UPE

HSS

1. Access System
Reselection
2. Network Registration
(old temporary identity)

3. Send Temporary Identity

4. Transfer UE Context
5. Authentication
6. Register MME
7. Delete old UE contexts
8. Confirm Registration

10. Confirm Registration

9. User Plane Route Update

Figure 7.5-2: Information flow for change in idle state from 2G/3G to SAE/LTE
1) The UE in idle state re-selects a different 3GPP access system.
2) The access system reselection triggers a network registration by the UE and sends its temporary identity and
potentially its old tracking area or another parameter identifying the old MME/UPE to the new MME/UPE.
3) The new MME/UPE derives an address of the UE's old MME/UPE from the parameters sent by the UE. The new
MME/UPE sends the UE parameters to the old MME/UPE.
4) The old MME/UPE sends a UE context to the new MME/UPE. The UE context includes a permanent user
identity and other information, e.g. security and IP bearer parameters.
5) The user/UE may be authenticated in the new MME/UPE.
6) The new MME/UPE derives from the permanent user identity an HSS address and registers itself as the
MME/UPE serving the user at the HSS.
7) The HSS deletes the UE context in the old MME/UPE.
8) The HSS confirms the registration of the new MME/UPE.
9) The new MME/UPE updates the route from the intersystem mobility anchor to itself. Mobile terminated packets
arrive at the new MME/UPE. In case the MME/UPE and the Intersystem Mobility Anchor is collocated this step
is not required.
10)The new MME/UPE confirms the UE's network registration and allocates a new temporary identity to the UE.
For change in Idle State from SAE/LTE to 2G/3G the same information flow is applicable with a changed order of
MME/UPE entities.
Editor's Note: The above solution does not cover inter-system mobility for Ues in URA-PCH. It is highly desirable
to support signalling optimisations for Ues in URA-PCH state as well. Solutions are FFS.

3GPP

Release 8

35

7.5.2.1.3

3GPP TR 23.882 V8.0.0 (2008-09)

Alternative Solution A2

In this solution, the SAE UPE contains the mobility anchor function for inter-3GPP access systems to handle mobility
between 2G/3G and SAE. The location of the mobility anchor function for 3GPP to non-3GPP access system does not
impact this solution, since this solution is for mobility between 3GPP access systems.
2G/3G
UE

2G/3G
network

HSS

MME

registration

2G/3G

RAN

registration

update

UPE
Context
Transfer

access

intersystem
mobility

system
change

route update

SAE
UE

LTE
network

anchor
+

MME

SAE
UPE

RAN

registration

Figure 7.5-3: 3GPP Inter Access System Change between SAE/LTE and 2G/3G for Solution A2.
When an SAE-capable UE in IDLE mode is attached in 2G/3G and then selects an LTE cell, the UE initiates a Tracking
Area Update. The 2G/3G MME treats this as an inter-SGSN routing area update as shown in the following figure.
It is assumed that a SAE-capable UE always uses an SAE UPE instead of a 2G/3G GGSN in order to meet the goal of
simplification.
UE

SAE
MME

UPE

2G/3G
MME/UPE

HSS

1. Access System
Reselection
2. Network Registration
(old temporary identity)

3. Send Temporary Identity

4. Transfer UE Context

5. Authentication
6. Register MME
7. Delete old UE contexts
8. Confirm Registration
9. IP Address Allocation
10. Confirm Registration

Figure 7.5-4: Information flow for change in idle state from 2G/3G to SAE/LTE
1) The UE in idle state re-selects a different 3GPP access system.
2) The access system reselection triggers a network registration by the UE and sends its temporary identity and
potentially its old tracking area or another parameter identifying the old MME/UPE to the new SAE MME.
3) The new SAE MME derives an address of the UE's old MME from the parameters sent by the UE. The new SAE
MME sends the UE parameters to the old MME.

3GPP

Release 8

36

3GPP TR 23.882 V8.0.0 (2008-09)

4) The old MME sends a UE context to the new SAE MME. The UE context includes a permanent user identity and
other information, e.g. security and IP bearer parameters.
5) The user/UE may be authenticated in the new SAE MME.
6) The new SAE MME derives from the permanent user identity an HSS address and registers itself as the MME
serving the user at the HSS.
7) The HSS deletes the UE context in the old MME/UPE.
8) The HSS confirms the registration of the new SAE MME.
9) The MME provides the UPE with information to configure the user plane. In case an IP Bearer is not already
established for the UE in 2G/3G network, the new SAE MME initiates an IP address allocation from the UPE.
The UE is now known in the UPE.
10)The new SAE MME confirms the UE's network registration and sends a new temporary identity to the UE.
Mobile terminated packets arrive at the UPE. If a new IP address has been allocated in step 9, it is provided to
the UE.
Editor's Note: The above solution does not cover inter-system mobility for Ues in URA-PCH. It is highly desirable
to support signalling optimisations for Ues in URA-PCH state as well. Solutions are FFS.

7.5.2.1.4

Impact on the baseline CN Architecture

The baseline CN architecture needs to be able to address SAE MME/UPEs and to perform context transfer with 2G/3G
MME/UPEs. In case of Gn procedures, the user plane between 2G/3G UPE and SAE UPE and the signalling plane
between 2G/3G MME and SAE MME can be accomplished based on GTP-U and GTP-C protocols respectively with
enhancements.

7.5.2.1.5

Impact on the baseline RAN Architecture

The baseline RAN architecture may support the UE in Idle State re-selection of the SAE/LTE 3GPP Access System.

7.5.2.1.6

Impact on terminals used in the existing architecture

Editor's Note: It is FFS whether there is any particular terminal impact.

7.5.2.2
7.5.2.2.1

Alternative Solution B
Description

Editor's note: Whether a UE can be registered in more than one 3GPP access system at one time and the possible
effects on SAE/LTE is FFS.
The proposed solution implements a loose interworking between SAE/LTE and 2G/3G, since the interconnection
between the two access systems is realized at user-IP layer (over Gi interface, for the legacy system) via Mobile IP
protocol. Terminating IP traffic is routed correctly to the UE that has moved from SAE/LTE to 2G/3G (and vice-versa)
via Mobile IP.
It is FFS whether MIP v4,MIPv6 or Proxy MIP is used.
The SAE/LTE network is seen as an external IP network for 2G/3G, and vice-versa: for this reason the inter 3GPP
access system mobility mechanisms apply also to mobility between 3GPP and non 3GPP access systems.
Intra-system mobility is handled in each access system according to its own network-based mechanisms (e.g. GTP for
2G/3G). Each Access System is regarded as an edge domain, i.e. a PLMN domain within which the UE acquires and
keeps the same IP address (IP edge) and where the UE's movements are handled using a local mobility management
protocol (e.g. NETLMM [12]). It is FFS how different 3GPP access systems can be managed within a single edge
domain. Since the UE keeps the same IP edge address, the network-based mobility protocol properly updates routing
information towards a local user plane anchor point (Local Mobility End Point, L-MEP) so that all packets destined to
IPedge address are correctly routed towards the moving UE.

3GPP

Release 8

37

3GPP TR 23.882 V8.0.0 (2008-09)

Any mobility event across the edge domains (i.e. 2G/3G GPRS network and SAE/LTE network) is handled by
anchoring the UE traffic to a fixed anchor (inter-domain anchor, or Global Mobility End Point, G-MEP). The G-MEP
can be located in the home or in the visited network depending on IP bearer service requirements (i.e. whether the
global IP address needs to be assigned by the visited or by the home network). In order to perform this, two different IP
addresses will be associated to the UE: the IP Edge address, belonging to the L-MEP subnet, and an IP address belonging
to the subnet of the G-MEP (IP Global). The IPGloba address is the address known at application level, used by the UE to
communicate with corresponding nodes, valid for all the session duration: since it doesn't change at access system
change (only IPEdge does), it guarantees session continuity. A global mobility protocol takes care of updating the route
from the G-MEP to the correct L-MEP, associating each new acquired IP Edge address to the IP Global address. When MIP is
used as global mobility protocol, G-MEP is the Home Agent, IP Edge is the Care-of-Address (CoA) and IP Global is the
Home Address.
For the SAE/LTE 3GPP Access System, L-MEP corresponds to the "user plane anchor" for Intra LTE mobility case, as
depicted in fig. 7.7-1, sec. 7.7.2. The L-MEP is located in the SAE packet core of the PLMN the UE is currently
attached to. An example of suitable network-based mobility protocol can be found in NETLMM [12]. The L-MEP could
be co-located with UPE, except when privacy requirements apply.
For the 2G/3G Access system, the L-MEP corresponds to the GGSN and the network-based mobility protocol is GTP.
The corresponding 2G/3G UPE is the GGSN.
The SAE/LTE 3GPP Access System has an MME (FFS whether in RAN or CN). The corresponding 2G/3G MME is the
SGSN.
The UE registers with the MME/UPE and the user plane anchor point of the selected 3GPP Access System, obtaining an
IPEdge. The MME/UPE of the 3GPP Access System stores a UE contexts, e.g. permanent user identities, mobility state,
tracking area. The UE (based on configuration options or on a specific request from the network) sends a MIP
Registration Request to the inter-domain anchor (Home Agent) to bind its current IP Edge address (CoA) to the IP Global
address (HA). The IPGlobal can be a static or a dynamic IP address.
The 2G/3G UPE of the 3GPP Access System stores a UE contexts, e.g. parameters of the basic IP bearer service, keeps
network internal routing information. The UE is only in one 3GPP access systems registered at one time and not at
multiple in parallel.
According to 2G/3G and LTE idle state definitions the UE (re-)selects cells and also access systems. The change of the
Access System in idle state triggers a network attach by the UE. It is FFS whether this is triggered by different tracking
areas for different access systems or by other information.
The SAE/LTE 3GPP Access System combines network attach and establishment of basic IP bearer capabilities (always
on), i.e. all parameters required for a best effort IP bearer service are allocated for the UE. In idle state all data transfer
resources between UE and network are released and only information for basic IP bearer is stored in the network. There
is a simple, preferably unique, mapping between 2G/3G and SAE IP bearer parameters
A global mobility protocol takes care of updating the inter-domain user plane anchor with the IP address acquired by the
UE in the new Access System. The routing between the new local user plane anchor and intersystem mobility anchor is
updated, which is the precondition for being able to page the UE when downlink data arrive. And, the home register
(e.g. HSS) is updated with registration of the UE at another MME/UPE. These functions are shown in the figure 7.5-5.
Inter 3GPP Access Mobility in LTE idle is performed with a re-attach based scheme (no context transfer).

3GPP

Release 8

38

3GPP TR 23.882 V8.0.0 (2008-09)

Figure 7.5-5: 3GPP Inter Access System Change between SAE/LTE and 2G/3G
The message sequence in figure 7.5-6 illustrates the high-level procedures for this solution alternative. In the
information flows below, MME and UPE/user plane anchor are shown together for simplicity reasons. This does not
preclude a separation.

Figure 7.5-6: Information flow for change in idle state from 2G/3G to SAE/LTE
1) The UE in idle state re-selects a different 3GPP Access System.
2) The Access System reselection triggers a network attach by the UE.
3) The UE is authenticated in the new MME/UPE. As a result of a successful authentication, the UE gets an IP
address belonging to the subnet of the user plane anchor (IP Edge). For routing optimization purposes the user
plane anchor can be co-located with the UPE.
4) The new MME/UPE registers itself as serving the UE in the HSS.
5) The UE contexts in the old MME/UPE (SGSN and GGSN) may be deleted by an explicit network request, or
after a timer expires.
6) The HSS confirms the registration of the new MME/UPE.
7) The new MME/UPE confirms the UE's network registration.

3GPP

Release 8

39

3GPP TR 23.882 V8.0.0 (2008-09)

8) The intersystem mobility anchor is updated with the IP Edge address. This step can be based on MIPv4,
RFC 3344 [10] or MIPv6, RFC 3775 [11]. In case MIPv6 is used, the UE sends a MIP Registration request to the
Intersystem mobility anchor (Home Agent), with IPEdge as a CoA. Terminating packets from the intersystem
mobility anchor will be tunneled towards the user plane anchor. The tunnel can terminate on the terminal (MIPv6
or MIPv4 with FA co-located mode) or on the user plane anchor (MIPv4 with FA located mode).
A similar flow applies for the change in idle state from SAE/LTE to 2G/3G.
In order to avoid Mobile IP impacts on the 2G/3G part of dual mode Ues and reduce air interface signalling, Proxy MIP
could be used for idle mobility management between EUTRAN and UTRAN/GSM.
When Proxy MIP is used into the architecture, the proxy MIP node should be included in SGSN/GGSN and User plane
anchor. In this case user plane route update could be initiated by Proxy MIP node. Inter 3GPP access Mobility
management in LTE idle is performed as Figure 7.5-7.

Figure 7.5-7: Information flow for change in idle state from 2G/3G to SAE/LTE
1) The UE in idle state re-selects a different 3GPP Access System.
2) The access System reselection triggers a network registration by UE with temporary identity and potentially its
old tracking area or another parameter identifying the old MME/UPE to the new SAE MME.
3) The new SAE MME derives an address of the UE's 2G/3G MME/UPE from the parameters sent by the UE. The
new SAE MME/UPE sends the UE parameters to the old MME/UPE.
4) The old MME/UPE sends a UE context to the new SAE MME. The UE context includes a permanent user
identity and other information, e.g. security and IP bearer parameters. The UE context may also include MIP
context, such as a HoA for the UE, UE-HA MSA.
5) If the new SAE MME/UPE couldnt get UE context from 2G/3G SGSN/GGSN, the new SAE MME/UPE
authenticates UE. If the new SAE MME/UPE has no valid MSA between UE and IASA, HSS should send MSAs
needed for mobile IP to SAE MME/UPE in this step.
6) The new MME/UPE registers itself as serving the UE in the HSS.
7) The UE contexts in the old MME/UPE (SGSN and GGSN) may be deleted by an explicit network request, or
after a timer expires.
8) The HSS confirms the registration of the new MME/UPE.

3GPP

Release 8

40

3GPP TR 23.882 V8.0.0 (2008-09)

9) If IASA has valid MSA between UE and IASA, mobile IP registration is done directly between new MME/UPE
and IASA, without the involvement of HSS; If IASA has no valid MSA between UE and IASA, IASA may need
to communicate with HSS for authentication and for retrieval of MSAs. The user plane between new MME/UPE
and IASA is established during the mobile IP registration procedure.
10)The new MME/UPE confirms the UE's network registration.

7.5.2.2.2

Impact on the baseline CN Architecture

Some impacts introduced by a Mobile IP solution for mobility across 3GPP and non-3GPP systems. These are listed
separately in this document.

7.5.2.2.3

Impact on the baseline RAN Architecture

The baseline RAN architecture may support the UE in idle state re-selection of the SAE/LTE 3GPP Access System.

7.5.2.2.4

Impact on terminals used in the existing architecture

The terminals used in the existing architecture may be impacted by the introduction of Mobile IP solution in 2G/3G
system.

7.6 Key issue: Limiting signalling due to idle mode mobility between
E-UTRA and UTRA/GSM
7.6.1 Requirement
Clause 5 of this TR contains the following requirement:
"The SAE/LTE system shall provide effective means to limit mobility related signalling during inter-RAT cell-reselection
in LTE_IDLE state. For example, with similar performance to that of the "Selective RA Update procedure" defined in
TS 23.060."
In this issue, the limiting signalling over the air interfaces is an important issue. The limiting signalling for updating the
tracking area (routing area, in case of UTRA/2G) and signalling for paging must be considered together, since the two
have a trade-off relationship.

7.6.2 Potential Solutions

The following solutions/concepts have been identified so far:
a) Separate Routeing Area/Do nothing
b) Common Routeing Area/Common SGSN
c) Common RNC
d) Equivalent Ras and SGSN proxy
e) UE remains camped on the last used RAT
f) Packet Data Bearer Proxy
g) Inter RAT Resource Allocation
h) User-IP layer interconnection
i) combined MME/SGSN
Other potential solutions might be identified in the future. Further information on the above solutions is included in
Annex D "More detailed descriptions of potential solutions for limiting signalling due to idle mode mobility between EUTRA and UTRA/GSM ".

3GPP

Release 8

41

3GPP TR 23.882 V8.0.0 (2008-09)

7.6.3 Selected Solution(s)

As they are currently described, potential solutions a, b and e do not provide sufficient limitation of mobility related
signalling during inter-RAT cell re-selection in idle state. Potential solutions a, b and e are hence ruled out.
Following TSG-RAN decisions on the nature of the LTE-RAN architecture, potential solution c is ruled out.
Owing to not considering the characteristic of UEs movement at the beginning and the push mode for context retrieval,
potential solution d is ruled out.
Potential solution f is ruled out since MME should have interface with HSS.
Owing to the working assumption on UTRA-LTE handover, potential solution h is ruled out.
Potential solution i, "combined MME/SGSN" does not meet all operational requirements. However the adopted solution
should not prevent the implementation of a combined MME/SGSN.
It is agreed that the selected solution should be developed using a standardised signalling interface between MME and
SGSN. Potential solutions d, f and g all contain information that should be considered when developing one unified
solution.
It is agreed that the selected solution should use potential mechanisms described in Annex D.4.4 or D.4.6 or D.4.7 for
context retrieval. It is FFS which one of the mechanisms is selected.
It is agreed that UE registers to both the SAE network and the UMTS network separately. After that, whether the MME
and the SGSN should be both registered to HSS is FFS. It is also agreed that the UE gets separate RAI and TAI for
2G/3G or LTE/SAE mobility management, allocated respectively by SGSN or MME/UPE.

7.7 Key Issue Intra LTE-Access-System Mobility in LTE_IDLE State

7.7.1 Description of Key Issue Intra LTE-Access-System Mobility in
LTE_IDLE State
Intra LTE-Access-System Mobility functionality for Ues in LTE_IDLE State maintains the registration of a user/UE and
keeps track of the location of the user/UE on Tracking Area base so that mobile originated and mobile terminated packet
transfer may be initiated. Furthermore, Intra LTE-Access-System Mobility functionality for Ues in LTE_IDLE State
updates within the network any user plane routing and any potential tunnelling information so that data path is
established between intersystem mobility anchor and the UPE.
Intra LTE-Access-System Mobility functionality in LTE_IDLE State maintains subscriber identity confidentiality, i.e.
temporary user identities are used where necessary.
In intra LTE-Access-System Mobility in LTE_IDLE State, UPE relocation is needed for certain scenarios.
In case of UPE relocation, it should be possible for IP applications to provide uninterrupted service to the end user.
Depending on the scenario, this may require support for IP service continuity.

7.7.2 Solution for key issue Intra LTE-Access-System Mobility in Idle State
7.7.2.1

General

The SAE/LTE Access System has an MME (Mobility Management Entity, it is FFS whether it resides in RAN or CN).
Furthermore, the SAE/LTE Access System has a UPE (User Plane Entity). The UE registers with the MME and the
UPE.
The MME stores a UE context data like permanent and temporary user identities, mobility state, tracking area etc. The
MME can store the UE context for long to allow for detach and reattach with temporary identity (user identity
confidentiality). The SAE/LTE system consists of distributed MMEs utilising load sharing/redundancy mechanisms
(e.g. similar to Iu-flex) enabling mobility of the UE within a certain geographical area without changing the MME. The
SAE/LTE system supports inter-MME mobility.

3GPP

Release 8

42

3GPP TR 23.882 V8.0.0 (2008-09)

The UPE stores UE context data like parameters of the default IP connectivity service and keeps network internal
routing information.
The SAE/LTE Access System combines network attach and establishment of default IP connectivity capabilities (always
on), i.e. all parameters required for an IP connectivity service with default QoS are allocated for the UE already at
attach. In idle state all data transfer resources between UE and network are released and only information for default IP
connectivity is stored in the network.
NOTE 1: Issues w.r.t. IP address re-assignment for inter-MME/UPE mobility need to be clarified.
User identity confidentiality requires the UE to register with the network using a temporary identity. The temporary
identity is resolved to a permanent identity by the old serving MME.
The routing between UPE and the user-plane anchor is updated, unless the two are co-located. It is the precondition for
being able to page the UE when downlink data arrive. And, the home register (e.g. HSS) is updated with registration of
the UE at another MME/UPE. These functions are shown in the figure 7.7-1.
NOTE 2: It is FFS whether inter MME mobility is done with a context transfer (relocation) or a re-attach based
scheme.
NOTE 3: The location of the user plane anchor for intra LTE-Access-System mobility is FFS.

Figure 7.7-1: Intra LTE-Access-System mobility in LTE_IDLE

7.7.2.2

Mobility in LTE_IDLE State

The information flow below depicts the mobility in LTE_IDLE State with Tracking Area Registration (when under
same MME).

Figure 7.7-2: Area Registration

3GPP

Release 8

43

3GPP TR 23.882 V8.0.0 (2008-09)

1) UE sends Tracking Area Registration when the previous Tracking Area is no longer valid or periodical Tracking
Area Update timer has expired. The Tracking Area Registration message contains UE's old temporary identity,
and old Tracking area Identity.
Editor's note: The exact list of information elements needed in this message is FFS.
2) MME responds with Confirm Registration. Confirm Registration contains new Tracking Area Identity, and may
also contain a new temporary identity for UE.

7.7.2.3

Intra LTE-Access-System change in idle state with user context transfer

The information flow below depicts inter-MME/UPE mobility with context transfer between MME/UPE entities. MME
and UPE entities on the old and the new side are shown together for simplicity reasons assuming a 1:1 relation between
MME and UPE entities. This does not preclude a separation, which would however require the definition of an interface
between both entities.

Figure 7.7-3: Information flow for Intra LTE-Access-System change in idle state with user context
transfer
1) The UE in idle state re-selects an LTE cell.
2) The cell re-selection triggers an area registration if the UE crossed an Tracking Area boundary. The UE sends its
temporary identity and its old tracking area identifying the old MME/UPE to the new MME/UPE.
3) The new MME/UPE derives an address of the UE's old MME/UPE from the parameters sent by the UE. The new
MME/UPE sends the UE parameters to the old MME/UPE.
4) The old MME/UPE sends the UE context to the new MME/UPE. The UE context includes a permanent user
identity and other information like security and IP connectivity parameters.
5) The UE may be authenticated in the new MME/UPE.
6) The new MME/UPE derives from the permanent user identity an HSS address and registers itself as the
MME/UPE serving the user at the HSS.
7) The HSS deletes the UE context in the old MME/UPE.
8) The HSS confirms the registration of the new MME/UPE.
9) The new MME/UPE confirms the UE's network registration and allocates a new temporary identity to the UE.
10)The new MME/UPE updates the route from the user plane mobility anchor to itself. Mobile terminated packets
arrive at the new MME/UPE.

3GPP

Release 8

7.7.2.4

44

3GPP TR 23.882 V8.0.0 (2008-09)

Intra LTE-Access-System change in idle state with re-attach

A MME/UPE may trigger a change of MME/UPE while the UE is in LTE-IDLE state using the Network initiated ReAttachment procedure described in clause 7.13.2.
While performing the Re-attachment procedure, the UE shall establish the same bearers as used before reattach and also
enough information may be provided to the network to make sure the same Inter-AS Anchor could be selected as the
one which was used before re-attach, if it is necessary for the service continuity.

7.7.3 Impact on the baseline CN Architecture

Editors Note: It is FFS whether there is any particular impact.

7.7.4 Impact on the baseline RAN Architecture

Editors Note: It is FFS whether there is any particular impact.

7.7.5 Impact on terminals used in the existing architecture

Editors Note: It is FFS whether there is any particular terminal impact.

7.7.6 Alternative solution

7.7.6.1

Solution for key issue Intra LTE-Access-System Mobility in Idle State

The SAE/LTE Access System has an MME (Mobility Management Entity, it is FFS whether it resides in RAN or CN).
Furthermore, the SAE/LTE Access System has a UPE (User Plane Entity). The UE registers with the MME and the
UPE.
The MME stores a UE context data like permanent and temporary user identities, mobility state, tracking area etc. The
MME can store the UE context for long to allow for detach and reattach with temporary identity (user identity
confidentiality). The SAE/LTE system consists of distributed MMEs utilising load sharing/redundancy mechanisms
(e.g. similar to Iu-flex) enabling mobility of the UE within a certain geographical area without changing the MME. The
SAE/LTE system supports inter-MME mobility.
The UPE stores UE context data like parameters of the default IP connectivity service and keeps network internal
routing information.
The SAE/LTE Access System combines network attach and establishment of default IP connectivity capabilities (always
on), i.e. all parameters required for an IP connectivity service with default QoS are allocated for the UE already at
attach. In idle state all data transfer resources between UE and network are released and only information for default IP
connectivity is stored in the network.
User identity confidentiality requires the UE to register with the network using a temporary identity. The temporary
identity is resolved to a permanent identity by the old serving MME.
A MME/UPE is the first IP hop router for the UE.
At power on, the UE attaches to a MME/UPE and gets an IP address belonging to the subnet of the user plane anchor
node. The user plane anchor node could be collocated with the serving MME/UPE. Otherwise, e.g, for location privacy
reasons, the user plane anchor node could be located in the PLMN core.
In order to avoid frequent IP address re-assignments, the UE shall keep the same IP address as long as possible. An
edge domain is defined as the area of a PLMN within which the UE can roam without any need to change the (local) IP
address. An edge domain could possibly be as large as the whole PLMN.
As long as the UE changes IP subnet or MME/UPE within the same edge domain, the routing between UPE and the
user-plane anchor is updated, unless the two are co-located. It is the precondition for being able to page the UE when
downlink data arrive. And, the home register (e.g. HSS) is updated with registration of the UE at another MME/UPE.
These functions are shown in the figure 7.7-4.

3GPP

Release 8

45

3GPP TR 23.882 V8.0.0 (2008-09)

If UE moves to an MME/UPE belonging to a new edge domain, the UE gets a new (local) IP address.
In order to allow IP reachability for a UE moving between different edge domains (e.g. in case the PLMN evolved core
is partitioned in more edge domains, or in case of movements across different PLMNs), the (local) IP address needs to
be registered towards a fixed anchor (inter-domain mobility anchor). This anchor can be located in the home or in the
visited network depending on IP bearer service requirements (i.e. whether the global IP address needs to be assigned by
the visited or by the home network).
The role of the inter-domain function is shown in the figure 7.7-5.
NOTE:

a home based inter-domain mobility anchor may be included in the data path in general for all roaming
Ues that need to obtain an IP address belonging to the HPLMN.

Figure 7.7-4: Intra LTE-Access-System mobility in LTE_IDLE (local mobility)

Figure 7.7-5: Intra LTE-Access-System mobility in LTE_IDLE (global mobility)

7.8 Key Issue: Inter access system handover

7.8.1 Principles and terminologies
There are two different cases for inter access system handover in SAE.
-

Handover between 3GPP access systems: Handover between UTRAN/GERAN and the SAE/LTE 3GPP Access
System.

3GPP

Release 8

46

3GPP TR 23.882 V8.0.0 (2008-09)

Handover between 3GPP and non 3GPP access systems: Handover between UTRAN/GERAN/SAE/LTE 3GPP
Access System and non 3GPP radio technology including WLAN 3GPP IP access.

NOTE 1: It is FFS whether the same mechanism can be applied to both cases or not.
NOTE 2: Solutions for mobility between access systems supporting different IP versions should be studied as part
of this key issue.
NOTE 3: The arguments and conclusions on mobility between access systems supporting different IP versions
presented under this key issue may be considered in the context of other mobility related key issues.

7.8.2 Inter access system handover between 3GPP access systems

(UTRAN/Evolved HSPA/GERAN and SAE/LTE 3GPP access system)
7.8.2.1

Description

Handover between 3GPP access systems maintains the UE's established IP packet bearer service(s) during mobility
between 2G/3G access and SAE/LTE 3GPP access system.
For mobility between 3GPP accesses (UTRAN/Evolved HSPA/GERAN and SAE/LTE), the mobility and anchoring is
performed below the User IP layer or in another term, below UMTS Gi level. This implies the usage of a common
2G/3G/LTE mobility anchor and mechanisms that control and perform mobility between the user plane tunnels (Gn-UP)
of existing 2G/3G accesses (GERAN and UTRAN) and the user plane tunnels of the Evolved Packet Core.
In addition, it is clarified that S3 is GTP based.
Editors note:
-The working assumption above does not imply any protocol/solution on S1 and S5 reference points (see
clause 4.2).
-The working assumption above does not imply any grouping of functions on other Key Issues.
It should be noted that this clause does not attempt to draw conclusions to the investigation of supporting different
anchoring mechanisms and mobility protocols between 3GPP and non-3GPP accesses.

7.8.2.2
7.8.2.2.1

Alternative solution A
Description

This alternative solution assumes a grouping of functions as shown in the figure below, i.e. the functions are grouped:
-

MME and UPE are combined into one functional entity, and

Inter AS anchor is one functional entity.

The description is also applicable to a functional grouping that combines SAE MME, SAE UPE and Inter AS Anchor
into one functional entity.
The SAE/LTE 3GPP Access System has an SAE MME (FFS whether in RAN or CN). The corresponding 2G/3G MME
is the SGSN. Furthermore, the SAE/LTE 3GPP access system has an SAE UPE. The corresponding 2G/3G UPE is the
SGSN.
The decision for initiating a handover is made by radio system entities of the source 3GPP access system.
Handover between 3GPP access systems is performed as a backward handover, i.e. the radio resources are prepared in
the target 3GPP access system before the UE is commanded by the source 3GPP access system to change to the target
3GPP access system.
The handover preparation is carried out over the reference point S3.
This reference point is also used to forward user data during handover to avoid data loss due to handover.

3GPP

Release 8

47

3GPP TR 23.882 V8.0.0 (2008-09)

During the handover phase or after the handover phase the user plane routing and any potential tunnelling between
serving 3GPP access system and inter system mobility anchor is updated to the target 3GPP access system. The UE
registers with the target 3GPP MME and the target 3GPP MME registers with the HSS.

Figure 7.8-1: Handover between 3GPP access systems for alternative solution A
In the information flow below SAE MME and SAE UPE are shown together for simplicity reasons. This does not
preclude a separation for SAE/LTE. The separation into two entities requires an interface between both for example for
paging, then registration between each other and doubles context transfer.

Figure 7.8-2: Information flow for handover from 2G/3G to SAE/LTE

1) The IP bearer service is established between UE and Inter AS Anchor via 2G/3G access system and 2G/3G
MME/UPE

3GPP

Release 8

48

3GPP TR 23.882 V8.0.0 (2008-09)

2) The serving 2G/3G access system decides to initiate a handover to Evolved RAN.
3) The serving 2G/3G access system indicates Handover Required and the handover target to its 2G/3G
MME/UPE.
3a) The 2G/3G MME/UPE selects a SAE MME/UPE serving the Evolved RAN nodes the UE is going to use
4) The 2G/3G MME/UPE sends a Handover Preparation Request to the target Evolved RAN via the selected SAE
MME/UPE.
5) The target Evolved RAN establishes bearer resources, including radio resources, for the UE.
6) The Evolved RAN confirms the Handover Preparation to the 2G/3G MME/UPE via the selected SAE
MME/UPE.
7) The 2G/3G MME/UPE commands the UE to change to the target Evolved RAN.
8) In case the source access system is 3G the 3G access system (RNC) may start to forward data to its 3G
MME/UPE. The 2G/3G MME/UPE forwards data to the Evolved RAN via the SAE MME/UPE. Depending on
the required QoS the 3G access system (RNC) sends duplicates of the forwarded data also via 3G radio to
minimise data loss.
8a) In case the source access system is 3G the 3G access system (RNC) sends a Forward SRNS Context message to
its 3G MME/UPE. It contains information for data transfer continuation by a new RNC for lossless relocation.
The usage of this information and mechanisms for inter 3GPP handover is FFS as it implies a stop of the data
transfer at source side, which is needed for a stable data transfer state.
9) The Radio Bearer is established between UE and target Evolved RAN.
10)The Evolved RAN informs the 2G/3G MME/UPE about handover completion.
11) The 2G/3G MME/UPE acknowledges the handover completion towards the SAE MME/UPE.
12)The SAE MME/UPE updates the route from the Inter AS Anchor to itself. Mobile terminated packets arrive at
the new MME/UPE.
13)The resource in the source system is released.
14)The IP bearer service is established between UE and Inter AS Anchor via Evolved RAN and SAE MME/UPE.
15)The UE may need to perform a registration with the new serving SAE MME/UPE. This triggers the SAE MME
to register with the HSS.
For handover from SAE/LTE to 2G/3G the same information flow is applicable with a changed order of MME/UPE and
RAN/access system entities. For this handover the Evolved NodeB or the SAE MME/UPE may need to duplicate and
forward data as the Evolved RAN has no user plane entity comparable to the RNC. It is FFS whether and which entity
performs duplication in this case.

7.8.2.2.2

Impact on the baseline CN Architecture

The baseline CN architecture needs to be able to address SAE MME/UPEs and to perform handover procedures with
SAE MME/UPEs. In case Gn procedures and RNC IDs are used to address the Evolved RAN the 3G MME/UPE
(SGSN) is not impacted.
Access restrictions, i.e. user specific restrictions for handover to Evolved RAN, may need an update for the SGSN to
know the relevant coding of such restrictions.

7.8.2.2.3

Impact on the baseline RAN Architecture

The baseline RAN architecture handles UE measurements from Evolved RAN and addresses Evolved RAN handover
targets.

7.8.2.2.4

Impact on terminals used in the existing architecture

Editors Note: It is FFS whether there is any particular terminal impact.

3GPP

Release 8

7.8.2.3
7.8.2.3.1

49

3GPP TR 23.882 V8.0.0 (2008-09)

Alternative solution B
Description

The SAE UPE contains the mobility anchor function for inter-3GPP access systems to handle mobility between 2G/3G
and SAE. The location of the mobility anchor function for 3GPP to non-3GPP access system does not impact this
solution, since this solution is for mobility between 3GPP access systems

2G/3G
UE

IP bearer
service

access
system
change

RAN
Context
Transfer /
Handover
Preparation

LTE

UE
IP bearer
service

2G/3G
MME
2G/3G
UPE

registration

HSS

update

intersystem
SAE
MME

route
update

mobility
anchor
+
SAE
UPE

RAN

Figure 7.8-3: 3GPP Inter Access System Change between LTE RAN and pre-SAE/LTE 2G/3G RAN for
Alternative B
Handover between 3G systems is performed as a backward handover i.e. the radio resources are prepared in the target
3GPP access system before the UE is ordered by the source 3GPP access system to change to the target 3GPP access
system.
For the case of a 2G to LTE system mobility when the 2G system has no support for PS Handover, the UE will first
perform cell re-selection before initiating a Tracking Update Procedure. This results in a "forward handover" instead of
the "backward handover" and is identical to inter-RAT Mobility in IDLE mode.
The decision for initiating a handover is made by radio system entities of the source 3GPP access system.
During the handover phase the user plane is established between the LTE Access and the SAE UPE.
The SAE MME may be collocated with the SAE UPE or with the 2G/3G MME/UPE (SGSN) in order to simplify the
number of interfaces and signalling transactions.

3GPP

Release 8

UE

50

2G/3G
Access

2. Handover
Initiation

LTE
Access
1. IP Bearer Service

3GPP TR 23.882 V8.0.0 (2008-09)

SAE UPE

2G/3G
MME /
UPE

SAE
MME

HSS

3. Handover Required

4. Handover Preparation Request

3a. SAE
selection

MME

5. LTE Access reserves UP resources

6. Handover Preparation Confirm
7. Handover Command
8. Means to minimise loss of data
9. UE Detection
10. Handover Complete
11. Handover Complete Ack
12. User Plane route update
13. Resource Release
14. IP Bearer Service

15. Location update procedure with HSS

Figure 7.8-4: Backward Handover from 2G/3G to SAE/LTE

1) The IP bearer service is established between the UE and the SAE UPE via 2G/3G access system and 2G/3G
MME/UPE (SGSN)
2) The pre-SAE/LTE 2G/3G Access decides to initiates a handover to LTE Access
3) The pre-SAE/LTE 2G/3G Access sends a Handover Required with the pre-SAE/LTE 2G/3G MME.
3a) The 2G/3G MME/UPE selects a SAE MME serving the Evolved RAN nodes the UE is going to use
4) The 2G/3G MME derives an address of the target SAE MME and sends a Handover Preparation Request,
including the UE context information. The SAE MME creates a UE context and sends a Handover Preparation
Request (PDP Session) to the LTE Access.
5) The LTE Access sets up user plane contexts for the SAE UE
6) The LTE Access sends a Handover Preparation Confirm to the SAE MME. The SAE MME sends a Handover
Preparation Confirm to the 2G/3G MME.
7) The 2G/3G MME sends a Handover Command to the UE via the 2G/3G Access.
8) Data loss may be minimised, e.g by bi-casting or data forwarding. Further details on the data forwarding path are
FFS as they depend on the location of header compression and ciphering.
9) The UE is detected at the LTE Access.
10)LTE Access sends a Handover Complete to the SAE MME. The SAE MME initiates the Handover Complete
Procedure with the 2G/3G MME.

3GPP

Release 8

51

3GPP TR 23.882 V8.0.0 (2008-09)

11) The 2G/3G MME acknowledges the handover completion towards the SAE MME.
12)The SAE UPE switches the user plane towards the new LTE Access. The SAE UPE will now forward all
downlink packets to the LTE Access.
13)The resource in the source system is released.
14)The IP Bearer service is now established between the UE and the SAE UPE via LTE Access and SAE UPE.
15)The UE updates its location using a Tracking Area Update Procedure with the SAE MME. The SAE MME will
initiate the Register MME procedure with the HSS.

7.8.2.3.2

Impact on the baseline CN Architecture

The baseline CN architecture needs to be able to address SAE MME/UPEs and to perform handover procedures with
2G/3G MME/UPEs. In case Gn procedures and RNC IDs are used to address the Evolved RAN the 2G/3G MME/UPE
(SGSN) is not impacted. In case of Gn procedures, the user plane between 2G/3G UPE and SAE UPE and the signalling
plane between 2G/3G MME and SAE MME can be accomplished based on GTP-U and GTP-C protocols respectively
with enhancements.
Access restrictions, i.e. user specific restrictions for handover to Evolved RAN, may need an update for the SGSN to
know the relevant coding of such restrictions.

7.8.2.3.3

Impact on the baseline RAN Architecture

The baseline RAN architecture handles UE measurements from Evolved RAN and addresses Evolved RAN handover
targets.

7.8.2.3.4

Impact on terminals used in the existing architecture

Editors Note: It is FFS whether there is any particular terminal impact.

7.8.2.4
7.8.2.4.1

Alternative solution C
Description

This solution is similar to Alternative solution A, but positions the solution for inter-access system handover between
3GPP access systems at user-IP layer, rather than below (i.e. tunnel switching below the user-IP layer). That is, the same
basic solution for mobility across 3GPP and non-3GPP access systems applies, with the addition of handover
enhancements as described below. These enhancements are meant to reduce the handover interruption times across
UTRAN/GERAN and SAE/LTE 3GPP access systems.
Similar to solution alternative A, the decision for initiating a handover is made by radio system entities of the source
3GPP access system.
Also, the handover between 3GPP access systems is performed as a backward handover, i.e. the radio resources are
prepared in the target 3GPP access system before the UE is commanded by the source 3GPP access system to change to
the target 3GPP access system.
The handover preparation is carried out over a reference point between target and source 3GPP access system, i.e.
between 2G/3G and SAE/LTE 3GPP access systems
It is FFS whether this reference point is also used to forward user data during handover or whether other mechanisms
are used to avoid data loss due to handover, e.g. bi-casting by the intersystem mobility anchor.
During the handover phase or after the handover phase the user plane routing and any potential tunnelling between
serving 3GPP access system and inter system mobility anchor is updated to the target 3GPP access system. The UE
registers with the target 3GPP access system and the target 3GPP access system (MME) registers with the HSS.
The message sequence chart in Figure 7.8-5 illustrates the high level procedures for this solution alternative. In the
information flows below, MME and UPE are shown together for simplicity reasons. This does not preclude a separation.

3GPP

Release 8

UE

52

Source
Radio Network

Source
MME/UPE

3GPP TR 23.882 V8.0.0 (2008-09)

Target
MME/UPE

Target
Radio Network

Inter-System
Mobility Anchor

HSS

1. Handover
Initiation
2. Handover Required
2.a source MME/UPE selects the target MME/UPE
3. Handover Preparation
Request

8. UE IP Address assigned by Target MME/UPE

7. Handover Preparation
Confirm

4. Handover Preparation
Request
5. Setup of necessary
resources
6. Handover Preparation
Confirm

9. Packet Forwarding Req (for lossless IS-HO)

10. User-plane forwarding
11. Handover Command
12. Handover Command
13. Setup of necessary radio resources
14. User-plane through forwarding tunnel
15. User Plane Route Reconfiguration Procedures
16. Handover Complete
17. Handover Complete
18. Resource Release
19. Handover Complete ACK
20. Location Update Procedures

Figure 7.8-5: High level procedures for inter-access system handover between UTRAN/GERAN and
SAE/LTE access systems when the inter-system mobility anchor is not a GTP tunnelling endpoint
Steps 18 correspond to the handover preparation phase, similar to that carried out for 2G/3G PS ISHO enhancements
defined in TS 43.129 [7]. If the direction of the handover is towards 2G/3G, step 3 also triggers GTP tunnel setup.
"Create PDP Context" messages are used for this purpose. Given that the UE IP address needs to be updated during the
inter-system handover procedure, the UE IP address assigned by the target MME/UPE can be passed to the UE in step
8. This measure allows faster inter-system transitions.
Step 9 can be used to set up temporary IP forwarding tunnel(s) between source UPE and target UPE. This allows faster
inter-system transitions and avoids packet loss.
Step 11 indicates the completion of the handover preparation phase. The source radio network can subsequently send a
Handover Command.
After the UE sets up the necessary radio resources with the target radio network in step 13, the UE can start sending and
receiving IP packets through the forwarding tunnel set up in step 10. If step 9 has not been carried out, then the UE
needs to wait till the procedures in step 15 are completed before sending and receiving IP packets.
Once the user plane route reconfiguration is completed in step 15, the UE can send and receive IP packets directly
through the target system. The forwarding tunnel that may have been set up in step 10 is no longer used and can be
thorn down at this stage, either through soft state timeout, or through other explicit signalling (FFS).
Steps 16-20 are maintenance procedures (i.e. release any resources in the source system and location update). If the
source access system is 2G/3G, this phase also includes tear-down of the GTP tunnel(s) between GGSN and source
SGSN. "Delete PDP Context" messages are used for this purpose.
The procedures in Figure 7.8-5 can be based on a combination of procedures already defined in 3GPP and IETF. More
specifically:

3GPP

Release 8

53

3GPP TR 23.882 V8.0.0 (2008-09)

Steps 8-10 and 14 can be based on procedures defined in RFC 4068 [8] (for Ipv6) and draft-ietf-mip4-fmipv4 [9]
(for Ipv4).
Step 15 can be based on RFC 3344 [10] (for Ipv4) and RFC 3775 [11] (for Ipv6).
The rest of the steps are similar to the procedures used in TS 43.129 [7].
Figure 7.8-6 shows an example of the mapping of Mobile IP functions and signalling flows in more detail, when Mobile
Ipv4 is operated in FA-located care-of address mode. It is FFS whether co-located care-of address with IP header
compression would be a more feasible solution compared to FA-located care-of address mode. A sequence chart for
Mobile Ipv6 would look similar, but in step 15 signalling would be directly between UE and HA, and there are no FA
functions in MME/UPE.

Source
Radio Network

UE

Source MME/UPE
(MIPv4 FA)

Target MME/UPE
(MIPv4 FA)

Target
Radio Network

Inter-System
Mobility Anchor
(MIPv4 HA)

HSS

1. Handover
Initiation
2. Handover Required
2.a source MME/UPE selects the target MME/UPE
3. Handover Preparation
Request

8. UE IP Address assigned by Target MME/UPE

9. Packet Forwarding Req (for lossless IS-HO)

7. Handover Preparation
Confirm

4. Handover Preparation
Request
5. Setup of necessary
resources
6. Handover Preparation
Confirm

10. User-plane forwarding

11. Handover Command
12. Handover Command
13. Setup of necessary radio resources
14. User-plane through forwarding tunnel
15a. MIPv4 Registration Request
15b. MIPv4 Registration Request
15c. MIPv4 Registration Response
15d. MIPv4 Registration Response
16. Handover Complete
17. Handover Complete
18. Resource Release
19. Handover Complete ACK
20. Location Update Procedures

Figure 7.8-6: Example procedures with Mobile IP in FA-located care-of address mode

7.8.2.4.2

Impact on baseline CN Architecture

The impacts on the baseline CN architecture are as follows:

-

same impacts introduced by a Mobile IP solution for mobility across 3GPP and non-3GPP systems. These are
listed separately in this document.

if packet loss mitigation is handled through packet forwarding, then the introduction of a layer-3 forwarding
interface between GGSN and the SAE MME/UPE is required. Other packet loss mitigation schemes may not
require this interface.

SGSN must be ready to create or delete PDP contexts during the relocation procedure when UE is moving across
UTRAN/GERAN and LTE/SAE Access systems.

For mobility from UTRAN/GERAN towards SAE/LTE, steps 8 and 9 in Figure 7.8-5 and 7.8.6 need to be
supported between UE and GGSN.

3GPP

Release 8

7.8.2.4.3

54

3GPP TR 23.882 V8.0.0 (2008-09)

Impact on baseline RAN Architecture

The baseline RAN architecture handles UE measurements from LTE access system and addresses LTE access system
handover targets.

7.8.2.4.4

Impact on terminals used in the existing architecture

The terminal needs to support Mobile IP protocol. And it is FFS whether the terminal should support both MIPv4 and
MIPv6.

7.8.2.5
7.8.2.5.1

Alternative solution D
Description

This solution is based on Alternative solution C. the main different point should be highlighted here are:
-

the UE won't need to support Mobile IP by using Proxy Mobile IP solution (e.g. draft-sgundave-mip6proxymip6-00 [17]);

the radio resource can be saved, because of hiding of the MIP signalling over radio interface.

The following figure describes this alternative solution. The source MME/UPE and target MME/UPE are 2G/3G
MME/UPE and SAE MME/UPE respectively, or vice versa.
NOTE:

The Proxy based Mobile IP mechanism is a kind of network layer mobility management mechanism. The
detail of this Proxy based mechanism is FFS,

3GPP

Release 8

55

3GPP TR 23.882 V8.0.0 (2008-09)

Figure 7.8-7: Inter MME/UPE Handover Message Flow

1. The IP bearer service is established between the UE and the inter AS Anchor via the source radio network and
the source MME/UPE.
2. The source radio network decides to initiate a handover to the target radio network.
3. The source radio network indicates the handover request and handover target to its source MME/UPE.
4. The source MME/UPE sends a Handover Preparation Request to the target MME/UPE, including the necessary
UE MM context (such as UE IP address, UE ID, and security parameters, etc).
5. The target MME/UPE forwards the Handover Preparation Request to the target radio network.
6. The target radio network sets up the user plane to the target MME/UPE for the UE. The detail process is FFS.
7. The target radio network confirms the Handover Preparation to the target MME/UPE.

3GPP

Release 8

56

3GPP TR 23.882 V8.0.0 (2008-09)

8. Upon receiver the PMIP registration response, the target MME/UPE will confirm the handover preparation with
the source MME/UPE.
9. The source MME/UPE sends the Handover Command to the source radio network. And the new Care-of Address
will be passed to the source radio network.
10. The source radio network forwards the Handover Command message to the UE to indicate it to switch to the
target radio network.
11. Data loss may be minimised, e.g. by bi-casting or data forwarding. If the bi-casting mechanism is assumed, the
procedure of updating routing information (e.g. the procedure is similar to step 14 and step 15 as below) would
be performed between step 7 and step 8.
12. The Radio Bearer is established between the UE and the target radio network. After that, the UE will receive the
packets via the target radio network.
13. The target radio network informs the target MME/UPE about the handover completion.
14. The target MME/UPE sends the Mobile IP Registration Request Message to the Inter AS Anchor instead of the
UE, which is called Proxy MIP Registration Request. The Care-of Address in the message can be the IP address
of the target MME/UPE or the one which the target MME/UPE gets via a DHCP server.
15. The Inter AS Anchor adds a new binding item for the UE and then sends back the Registration Response
Message to the target MME/UPE to confirm the registration.
16. The target MME/UPE forwards the Handover Completion to the source MME/UPE.
17. The user plane between the source MME/UPE and the source radio network will be released.
18. The source MME/UPE acknowledges the handover completion to the target MME/UPE.
19. Location update procedure will be done between the new MME/UPE and the HSS.

7.8.2.5.2

Impact on baseline CN Architecture

The impacts on the baseline CN architecture are the same as the alternative solution C. The additional impact is 2G/3G
MME/UPE and SAE MME/UPE should support the Proxy Mobile IP solution.

7.8.2.5.3

Impact on baseline RAN Architecture

The baseline RAN architecture handles UE measurements from LTE access system and addresses LTE access system
handover targets.

7.8.2.5.4

Impact on terminals used in the existing architecture

No impact is seen at this moment.

7.8.2.6

Comparison of Handover Flows

Editor's note: Following discussion at the SA 2 ad hoc on SAE in Paris, April 2006, this comparison has been
deleted.

7.8.3 Inter access system handover between 3GPP and non 3GPP access
systems
7.8.3.1

Description of key issue Inter access system handover between 3GPP and
non-3GPP access systems

The common denominator between 3GPP and non-3GPP access systems is that connectivity to packet services is
delivered through the IP layer.

3GPP

Release 8

57

3GPP TR 23.882 V8.0.0 (2008-09)

In this key issue, the term global mobility protocol is used to describe a mobility protocol that handovers between 3GPP
and non-3GPP access systems, and the term global mobility is used to describe mobility where the mobility anchor
point for handovers between 3GPP and non-3GPP access systems are involved. The term local mobility protocol is used
to describe a protocol that manages handovers within a non-3GPP access system. The local mobility protocol could be
Proxy MIP [17] or the mobility protocol specified within the IETF NETwork based Localized Mobility Management
(NETLMM) WG.
The solution presented in this clause is based on the use of Mobile IP (MIP) as a global mobility protocol providing
host-based IP mobility, which is in required whenever network-based mobility support is not provided. Depending on
operator requirements and/or deployment scenarios, network-based mobility protocols could be used as local or global
mobility protocols in combination with MIP, as described in clause 7.8.3.3.

7.8.3.2
7.8.3.2.1

Solution of key issue Inter access system handover between 3GPP and
non-3GPP access systems
Relationship with SAE architecture

Editors note: This clause identifies the dependencies of this key issue with the SAE architecture, and will be revised
when the functional grouping in the Evolved Packet Core is agreed.
The following illustrates the handovers that are within the scope of this key issue, and the related parts in the SAE
architecture. Mobility anchor points in the Evolved Packet Core include the following functions:
-

LTE anchor (corresponding to the anchor for LTE): The anchor point for intra-LTE mobility. This mobility
mechanism is addressed separately (mainly in the RAN WGs).

3GPP anchor (corresponding to GGSN in pre-SAE/LTE GPRS): The anchor point for handovers between 3GPP
access systems. This mobility mechanism is addressed in a separate key issue.

SAE Anchor (corresponding to HA in the case of MIP): Represents functions grouped around the anchor point
for handovers between 3GPP and non-3GPP access systems for the mobility protocols and mechanisms
described in this key issue. This anchor allocates IP address(es) for the UE as required by the used mobility
protocol (FFS).

The integration of the anchor points with each other and with other evolved packet core functions is FFS and is handled
in other key issues (clause 7.11, Functions in the evolved packet core, and clauses 4.2 and 4.3, Architecture for the
evolved system non-roaming and roaming cases). Thus, the final solution needs to be aligned with the above key
issues.
Non-3GPP inter access system mobility requires consideration of policy and charging control from the home operator,
as the controlled service may cross operator as well as access system boundaries. Supporting such functions using a
similar mechanism for different access types is described in a separate key issue (clause 7.1, Policy control and
Charging).

3GPP

Release 8

1.
2ab/c/d/e.
Note1:
Note2:
Note3:
Note4:
Note5:
Note6:

58

3GPP TR 23.882 V8.0.0 (2008-09)

3GPP handover. Mobility mechanism defined in different key issue.

Multi-access handover. Mobility using an IP layer mechanism.
Grouping of the anchor functions into logical entities UPE and IASA is FFS.
It is FFS whether the links between anchor functions imply reference points or not.
The non 3GPP IP Access may contain local mobility anchor function.
The relationship between PDG and the Evolved Packet Core is FFS.
It is FFS how the architecture is aligned with the roaming case.
The colours used in the figure do not imply any particular mobility protocol(s).

Figure 7.8-8: 3GPP and multi-access handover anchor functions.

Figure 7.8-8 shows the 3GPP and inter-access system handovers anchored in the 3GPP anchor function and SAE
Anchor, respectively.
The introduced overhead (signaling and user plane transport overhead) and performance penalties (delays etc., as
compared to when the mobility solution is not activated) should be minimized, especially for 3GPP accesses. By
providing a certain level of interaction between the SAE Anchor and the 3GPP Anchor within the Evolved Packet Core,
the Mobile IP based mobility signaling and tunneling only needs to be active when the terminal is using a non-3GPP
access technology. This interaction can be achieved by integrating the 3GPP anchor function and SAE Anchor into a
single entity, or with some other coordination between the 3GPP anchor and the SAE Anchor, so that the UE is at home
(in MIP terminology) while moving within 3GPP accesses.
Without any of these interactions, Mobile IP signaling and tunneling will be active also when using 3GPP access
technologies causing extra signaling as well as tunneling overhead to user data packets.
Beyond the immediate effects on performance, the integration or separation of the anchor points have implications, for
example, related to the complexity of the PCC support in the architecture, and the flexibility in the architecture options
available to operators, but that issue is not discussed in this clause.
The separation of the anchor points may also be considered as a means to make it easier to potentially introduce support
for enhancements such as hierarchical mobility concept.
Note that a serving access node for non-3GPP IP access (such as a PDG or a similar entity) may be located in the
evolved packet core but is not shown in the figure. Such an entity would be required in the network-based mobility
concept to update the route on behalf of the UE.
The following points shall also be considered in the selection process of the above alternatives:

3GPP

Release 8

59

3GPP TR 23.882 V8.0.0 (2008-09)

1. Whether the availability and maturity of the relevant IETF standards affects the solution preference.
2. Whether the selection should be aligned with solution selected in non-3GPP access technologies, e.g., the
mobility mechanism selected in the WiMAX forum.
3. Whether the solution provides satisfactory handover performance.

7.8.3.2.2

Additional solution aspects

Another aspect of the solution is the selection of address, network interface and IP access service used by the UE for the
connection. Destination and source address selection are functions of the TCP/IP stack and may be out of scope for SAE
(FFS). Network interface selection may utilize a virtual network interface to hide access changes from the rest of the
TCP/IP stack, and this may also be out of scope for SAE (FFS). The selection of IP access service is related to SAE
access bearers and connectivity to multiple PDNs, which are described in separate key issues. The solution should align
with PDN selection mechanism of 3GPP access systems.
Furthermore, the solution should allow the use of a SAE Anchor, which is the anchor for mobility between 3GPP and
non-3GPP access systems, as an anchor for mobility between two non-3GPP access systems. Although the specification
of such mechanisms is out of scope for 3GPP, the solution should not preclude performing this according to a
hierarchical mobility concept where the two non-3GPP access systems support local mobility protocols, given that both
non-3GPP access systems provide sufficient security for handover signalling and user data traffic.

7.8.3.2.3

MIP version implications

Independent of the above architectural aspects, Mobile Ipv6, Mobile Ipv4 or both can be used to execute mobility
toward non-3GPP accesses. The use of either MIPv4 or MIPv6 (or both) mostly depends on the expected use of IP
versions and is not strictly based on the merits of the individual Mobile IP protocol versions.
In the absence of mechanisms addressing the lack of native backwards compatibility of Mobile Ipv6 with Ipv4, the
support for already deployed Ipv4 services and networks results in the following alternatives:
-

A transition (dual stack UE, tunnelling from UE) mechanism is necessary if accessing Ipv6-only services from
an Ipv4-only access network. In order to avoid transition tunnels over the access network, it may be more
feasible to use MIPv4 with a transition mechanism on the service-side of the HA, such as protocol translation.

Mobility is not possible between Ipv4-only and Ipv6-only access networks.

For Ipv4-only services it is possible to use Mobile Ipv4 to avoid an additional transition mechanism on the
"service-end" of the HA.

Mobile Ipv4 has similar limitations associated with applicability in the presence of Ipv6, either in the UE connectivityside or the service-side of the HA. However it is worth to note that in the case of Mobile Ipv4 the first point mentioned
above is a reversal of the IP versions in services and access network, i.e. only relevant in the presence of an Ipv6-only
access network.
It is expected that most SAE-capable UEs will have a dual stack supporting both Ipv4 and Ipv6, and therefore using
both MIPv4 (for Ipv4 connections) and MIPv6 (for Ipv6 connections) is possible. This will however require additional
mobility signalling at handover. The cost to administer two mobility protocols in parallel may also be higher due to
additional configuration (e.g. in order to manage security associations) in the UE and HA. If local network
optimizations are used, they may need to be implemented for both MIPv4 and MIPv6.
Another possible approach is to adopt dual-stacked Mobile Ipv6 (DS-MIPv6) solution which is being drafted in IETF
(draft-ietf-mip6-nemo-v4traversal-01.txt). When this solution is available, it will allow connectivity and mobility across
any IP version, and access to services of any IP version, without additional transition (tunnelling) mechanisms. The
solution is not particularly well suited for Ipv4-only terminals, but adaptation of the solution could be studied further if
needed. It should be noted that the MIPv6 solution with Ipv4 extensions can be deployed in today's Ipv4 networks, and
does not require deployment of Ipv6 in existing networks.
In summary, the following implementation alternatives are possible to enable mobility for both Ipv4 and Ipv6 (the effect
of PDG on these alternatives is FFS):
1. MIPv4 and DS-MIPv6
Consequences: two protocols need to be supported in the mobility anchor and in the mobile node (UE).

3GPP

Release 8

60

3GPP TR 23.882 V8.0.0 (2008-09)

2. DS-MIPv6 only
Consequences: not compatible with MIPv4 only clients.
3. MIPv4 and MIPv6
Consequences: two protocols and architecture need to be supported in the mobility anchor. Not possible to serve
Ipv6 traffic over an Ipv4 access network (and vice versa). Mobility between Ipv4 and Ipv6 access networks is
not supported.

7.8.3.2.4

Use of local mobility protocols

A further possibility is the use of a hierarchical mobility concept including a global mobility protocol and a local
mobility protocol. The global mobility protocol handles mobility events across access systems by associating the global
IP address with the new local IP address at a fixed global mobility anchor, and forwarding UE traffic to the local IP
address allocated by an access system. UE handovers within the access system are managed using a local mobility
management protocol.
In Mobile IP, the UE obtains a care-of-address (CoA) and performs a MIP registration with the HA (SAE Anchor) to
bind its current CoA to the HoA. In the hierarchical mobility concept (network-based mobility), the local mobility
anchor sends a Route Update towards a global mobility anchor (SAE Anchor) triggered, for example, by IP Bearer
Establishment signalling between the UE and the local mobility anchor. The global IP address of the UE does not
change.
In summary, the following alternatives are possible:
1. MIP as a global mobility protocol, without an additional local mobility protocol, using only a common Home
Agent.
Consequences: UE needs to perform mobility signalling with every handover in the access-network. There is
overhead from Mobile IP tunnelling when the UE is not performing handovers between access systems.
2. MIP as a global mobility protocol and one of the local mobility protocols in the non-3GPP access system, using
both a common Home Agent as a global mobility anchor, and separate local mobility anchors for the accesssystem.
Consequences: There is less overhead and less signalling between the UE and the network when the local
mobility protocol is used. Note that unless the local mobility protocol is used as the LTE mobility mechanism,
there is no improvement for the UE when performing handovers between access systems, moreover not all non3GPP access networks support the particular local mobility protocol.
3. One of the network-based mobility protocols (as a global mobility protocol and any local mobility protocol
supported in the access system), using SAE Anchor as a global mobility anchor and separate local mobility
anchors for each access system. MIP is used for access systems that do not support the selected network-based
mobility protocol. Note that this means that the network-based mobility anchor for global mobility and the MIP
HA both are located in the SAE Anchor.
Consequences: There is less overhead and less signalling between the UE and the network when the UE is not
participating in network-based mobility signalling, which also reduces the need for security credentials shared
between the UE and the global mobility anchor. However, if MIP is used for access systems that do not support
the network-based mobility protocol, such security credentials are still needed in the UE. Network domain
security can be used to secure signalling over an untrusted network (e.g. between HPLMN and VPLMN). There
are potential security concerns (from the perspective of user plane confidentiality and network topology hiding)
if operator decides to allow handover to/from WLAN Direct IP Access.

7.8.3.3

Comparison of different mobility management schemes

The following alternatives are currently considered for mobility between 3GPP and Non-3GPP systems:
Host-based Mobility Management Solutions
1. MIPv4 with FA-CoA [23]
2. MIPv4 with Co-CoA [23]
3. MIPv6 [24]

3GPP

Release 8

61

3GPP TR 23.882 V8.0.0 (2008-09)

4. HMIPv6 [31]
5. DSMIPv6 [27]
6. DSMIPv4 [32]
Network-based Mobility Management Solutions
7. NETLMM [12]
8. PMIPv4 [26]
9. PMIPv6 [17, 33]
The main SAE requirements listed in clause 5 for the evolved 3GPP Mobility Management are applicable for mobility
between 3GPP and Non-3GPP systems as follows:
Requirement 1: The Evolved 3GPP Mobility Management solution shall be able to accommodate terminals with
different mobility requirements (e.g.: fixed, nomadic and mobile terminals).
Requirement 2: The Evolved 3GPP Mobility Management should allow optimized routing for user-to-user traffic
(including communication towards Internet and PSTN users, e.g.: via local break-out) and in all roaming scenarios (e.g.:
when both users are in a visited network).
Requirement 3: The Evolved 3GPP System shall support Ipv4 and Ipv6 connectivity. Interworking between Ipv4 and
Ipv6 terminals, servers and access systems shall be possible. Mobility between access systems supporting different IP
versions should be supported.
Additional SAE requirements listed (not specific to mobility management) in clause 5 that should be considered:
Requirement 4: Transport overhead needs optimization, especially for the last mile and radio interfaces.
Editors Note: The above list is not complete and further requirements can be added.
The advantages and disadvantages of different schemes are tabulated below:

Scheme
MIPv4 FA-CoA

Advantages

Mature
mobility
management
protocol (in IETF)

Need to
allocate only one
CoA for all UE

Disadvantages

Handover
interruption time
may not meet the
requirements for
some types of
flows, e. g., real
time flows.
Additional
signalling
overhead over
the air as UE
needs to perform
MIP binding
updates both
periodically as
well as for every
handover
All terminal
need to
necessarily
implement MIPv4
stack
Inefficient
routing (triangular
routing)
Core
network elements

3GPP

Requirements
Satisfied
Requirement 1
Requirement 4

Requirements Not
Satisfied Natively
Requirement 2
Requirement 3

Release 8

62

Scheme

MIPv4 Co-CoA

Advantages

Mature
mobility
management
protocol (in IETF)

Lesser
impact on core
network terminals
as FA
functionality need
not be
implemented

Need to
allocate one CoA
for each UE
leading to
limitation in
availability of IP
address

Disadvantages

MIPv6

Mature
mobility
management
protocol (in IETF)

Can support
route optimization

Supports
optimizations like
FMIP [9] and
HMIP

Less impact
on core network
terminals since
FA functionality
need not be
implemented

need to support
FA functionality
Handover
interruption time
may not meet the
requirements for
some types of
flows, e. g., real
time flows.
Additional
overhead in the
air due to tunnel
between HA and
UE
Additional
signalling
overhead over
the air as UE
needs to perform
MIP binding
updates both
periodically as
well as for every
handover
All terminals
that desire IASA
mobility need to
necessarily
implement MIPv4
stack
Inefficient
routing (triangular
routing)
Handover
interruption time
may not meet the
requirements for
some types of
flows, e. g., real
time flows.
Note:
Optimizations
such as FMIP [9]
and HMIP can be
used, to enable
fast handover
Additional
overhead in the
air due to tunnel
between HA and
UE or Home
Address Option
Additional
signalling
overhead over
the air as UE
needs to perform
MIP binding
updates both
periodically as
well as for every
handover
All terminals
that desire inter
access mobility

3GPP

3GPP TR 23.882 V8.0.0 (2008-09)

Requirements
Satisfied

Requirements Not
Satisfied Natively

Requirement 1

Requirement 2
Requirement 3
Requirement 4 Note:
This can be achieved
based on additional
mechanisms

Requirement 1
Requirement 2

Requirement 3
Requirement 4 Note:
This can be achieved
based on additional
mechanisms

Release 8

63

Scheme

NetLMM

Advantages

Proxy MIP

DS-MIPv6

Little
mobility signaling
over the air
interface for interaccess mobility
Since
mobility signaling
is handled locally
(only involving
network entities),
the HO
interruption time
is potentially
smaller
UE does not
need to
implement MIP
stack
Little
mobility signaling
over the air for
inter-access
mobility
Since
mobility signaling
is handled locally
(only involving
network entities),
the HO
interruption time
is potentially
smaller
UE does not
need to
implement MIP
stack

Supports
mobility of Ipv6
terminals in Ipv4
networks

Supports
both private and
public Ipv4 visited
access networks

3GPP TR 23.882 V8.0.0 (2008-09)

Disadvantages
need to
necessarily
implement MIPv6
stack

Impact on
core network
elements as they
need to
implement
NetLMM stack

Cannot
support Ipv4 only
core network in
initial release

Impact on
core network
elements as they
need to
implement proxy
mobility agent is
needed
Specification
status for Ipv6
unclear (solution
not accepted by
IETF NetLMM
WG)
Proxy agent
needs to run at
least as many
instances of MN
client as the
number of UEs.
Cannot
support Ipv4 only
terminal
Handover
interruption time
may not meet the
requirements for
some types of
flows, e. g., real
time flows

Requirements
Satisfied

Requirements Not
Satisfied Natively

Requirement 1
Requirement 2
Requirement 4

Requirement 3

Requirement 1
Requirement 2 (for
PMIPv6 alone)
Requirement 4

Requirement 3

Requirement 1
Requirement 2
Requirement 3 (for
Ipv6 capable
terminals)

Requirement 4 Note:
This can be achieved
based on additional
mechanisms

Editors Note: The above table is not complete and more requirements and mobility management options can be
added.

7.9 Key Issue Default IP Access Service

7.9.1 Description of Key Issue Default IP Access Service
The Default IP Access Service provides the basic "always-on" IP packet bearer service. It is expected to be used for user
data that do not require any service specific policies or charging rules. Such user data are, for example, satisfied by
default QoS and flat rate/bundled charging, as described in a separate Key Issue. The Default IP Access Service is

3GPP

Release 8

64

3GPP TR 23.882 V8.0.0 (2008-09)

described by a default context in the network, and possibly in the UE. User data requiring service specific policies or
charging are supported by additional IP access services.
The Default IP Access Service is established for a UE immediately after the subscriber has been authenticated and
authorized by the network. The Default IP Access Service provides the UE with Ipv6 and/or Ipv4 connectivity to
operator services, other Ues, private IP networks, or the Internet. The Default IP Access Service supports mobility of the
terminal.
The Default IP Access Service includes the establishment of the default SAE Bearer as part of the attach procedure.
Optionally, the establishment of one or more dedicated SAE Bearers may be triggered by the completion of the attach
procedure. The establishment of these additional bearers is determined by operator policy and may be based on
subscription information.
NOTE:

For example, a dedicated Non-GBR bearer ("signalling bearer") could be pre-established by the network
in addition to the default bearer to carry only the SIP signalling. In addition, another dedicated Non-GBR
bearer ("premium bearer") could be pre-established by the network to provide a "bit pipe" service with
"better than default QoS" but within limits of the user's subscribed QoS level. PCC rules associated with
such a "premium bearer" would allow multiple service data flows with the same QoS requirements to be
carried over it.

7.9.2 Solution for Key Issue Default IP Access Service

-

A Default IP Access Service in the serving (access) network is established within a single attach procedure that
includes authentication and authorization of the user. It shall be possible that any user specific information about
the Default IP Access Service, such as policies or configuration parameters, are received from the subscriber
databases in home network, such as HSS or/and Subscription Profile Repository.

It is FFS how the subscriber-specific policies or configuration parameters are transferred from the home network
to the serving (access) network.

The Default IP Access Service for roaming users in the serving (access) network can be modified by the home
operator.

The Default IP Access Service shall provide the UE with at least one Ipv6 address or one Ipv4 address allocated
or assigned by the network, together with necessary IP configuration parameters.

It is FFS how Default IP Access Service(s) provide Ipv6 and/or Ipv4 connectivity for a dual stack UE.

It is FFS whether the IP address is allocated or assigned statically or dynamically.

The Default IP Access Service(s) shall provide IP connectivity to the networks permitted under applicable
policies and roaming restrictions without excluding local breakout.

For roaming case, whether the default IP address can be allocated by VPLMN or HPLMN should be based on
the home operator' roaming policy and the roaming agreement between home operator and visited operator.

NOTE:

If the default IP address is allocated by HPLMN, this IP address should be the home address in the case of
MIP solution.

The Default IP Access Service shall allow for UE registration to the IMS, at least for services that do not require
better than default QoS and differentiated charging.

It is FFS how and when the IMS registration is performed and what kind of IMS services is provided to the UE
within the Default IP Access Service.

7.9.3 Impact on the baseline CN Architecture

FFS.

7.9.4 Impact on the baseline RAN Architecture

FFS.

3GPP

Release 8

65

3GPP TR 23.882 V8.0.0 (2008-09)

7.9.5 Impact on terminals used in the existing architecture

FFS.

7.10 Key issue IP connectivity with multiple PDNs

7.10.1 Description of Key Issue IP connectivity with multiple PDNs
According to 3GPP UMTS standards, the scenario where the UE has access (either concurrently or successively) to
several Packet Data Networks or Service Domains is possible, using one or more GGSNs as requested by the MS. Each
PDN/Service Domain is identified by an Access Point Name (APN) as defined in TS23.003. The SGSN resolves the
APN to an address that identifies a GGSN, and the GGSN can resolve the PDN/Service Domain. If that GGSN is
unavailable, the APN name resolution normally provides a second choice GGSN address.. In the following, the term IP
Gateway is used to describe the function with the capability of connecting with PDNs/Service Domains.
This key issue clarifies whether the UE will have a relation to a single or multiple IP Gateways in order to obtain
concurrent connectivity to several PDNs/Service Domains, and whether one or multiple IP addresses are provided by an
IP Gateway.
Public PDN
Public
PDN

GGSN
GGSN
GGSN
Gi

UE

3G/ 2G
RAN

as APN 1
by UE, HSS
and SGSN

SGSN
GGSN
GGSN

identified

Private PDN
Gi
Private
PDN

identified
as APN 2
by UE, HSS
and SGSN

Figure 7.10-1: Multi-APN support in pre-SAE/LTE access systems

It should be studied whether and how the SAE architecture can support the following non-exhaustive list of use cases,
or combination of use cases:
1. UE accesses a single PDN: This is not a use case involving multiple PDNs/Service Domains, but is included for
the purpose of comparisons with the solutions presented in other use cases.
Assumptions: It is anticipated that a UE will typically have connectivity to only a single PDN at a time. This
always-on IP connectivity is enabled by establishing a basic IP service during the Network Attachment
procedure.
2. UE accesses both Ipv4 and Ipv6 PDNs: A UE could access both Ipv4 and Ipv6 PDNs/Service Domains, e.g. if
Ipv4 and Ipv6 traffic is routed from the UE to Ipv4 and Ipv6 server clusters in different physical locations.
Assumptions: It is anticipated that support of concurrent Ipv4 and Ipv6 service usage is still needed because of
legacy Ipv4 support and new Ipv6 services.
3. Corporate PDN and IMS services in separate trust domains: Corporate employees may wish to use the
LTE/SAE access system available in corporate premises for access to corporate services, while using the UE for
IMS based telecommunications such as phone calls. The IMS traffic should comply with the requirements of the
operator trust domain in order to secure charging and LI while the corporate traffic should be securely and
efficiently routed.
Assumptions: It is anticipated that access to corporate services needs to be securely separated.
4. Corporate PDN and other services in separate trust domains: When working remotely away from the
corporate site, a corporate employee may access corporate services. This corporate traffic should remain securely
separated from other PDNs/Service Domains such as public Internet, or Device Management to the UE

3GPP

Release 8

66

3GPP TR 23.882 V8.0.0 (2008-09)

performed by the home operator.

Assumptions: It is anticipated that access to corporate services needs to be securely separated.
5. UE mobility between access systems: UE mobility between access systems such as LTE, 2G/3G or I-WLAN, or
between operators.
Assumptions: It is anticipated that mobility between 3GPP access systems and between 3GPP and non-3GPP
access systems needs to be efficiently supported. The detailed performance requirements are described in other
key issues.
6. Roaming cases: In some roaming cases, the UE could use the VPLMN for access to visited network services
such as public Internet or IMS emergency sessions (for pre-SAE/LTE access systems TR 23.867 requires a
globally dedicated APN), while operator services can also be provided in the HPLMN.
Assumptions: It is anticipated that the home network informs the current visited network of the UE about
whether access to local PDNs other than the PDNs connected to the home network, including visited services or
local breakout, is supported. The allowance of the access to the visited services and/or local breakout is based on
agreements between the visited and home operators, and the users subscription.
7. Separate private address spaces: Some of the PDNs/Service Domains may use private address spaces instead
of public addresses.
Assumptions: It is anticipated that the private address spaces of the multiple PDNs/Service concurrently
accessed by a UE may overlap with each other.
Based on the above use cases, concurrent access to several PDNs/Service Domains appears to be required in SAE.
Consistent behaviour for applications across different access technologies should also be considered.
The configuration describing the connectivity of a UE to a set of PDNs/Service Domains may be received from the
HSS/HLR, pre-configurations in the IP Gateway, by mediation of PCC mechanisms, or a combination of these
mechanisms.
The UE need not be aware of the default configuration that provides default PDN/Service Domain connectivity to the
UE, but the UE may request a configuration to be used instead of that default configuration for other connectivity than
the default PDN/Service Domain. The use of configuration other than the default configuration depends upon operator
configuration and the user's subscription.

7.10.2 Solution for Key Issue IP connectivity with multiple PDNs

7.10.2.1

Working Assumptions

When the UE operates using multiple PDNs there will be only one UPE in the evolved packet core per UE that
terminates user plane protocols for header compression and ciphering, and initiates paging.
Regarding the proposed solution alternatives, the following concerns should be considered due to the working
assumption above:
-

Under the assumption above the user plane data for UEs connected to multiple PDNs may for some PDNs be
routed via two user plane nodes in the evolved packet core network as opposed to one node in the single PDN
case.

Depending on migration, deployment scenarios and performance there may be a need to perform functions like
charging, policing etc. in the nodes terminating the Gi interface.

For proposed solutions relying on MIP4 (RFC 3344) and MIP6 (RFC 3775) on the S5/S8 reference points this
working assumption implies that the UPE shall support both Ipv4 and Ipv6. This is not needed if dual-stack
MIPv6 is used.

The UPE (terminating ciphering etc.) will be selected when the UE connects to the first PDN (i.e. at Attach). The
UPE may be optimised for that PDN (e.g. it may be combined with a IASA, and be a complex node that supports
Flow Based Charging, content control, etc, for services such as MMS/IMS). If a second PDN connection is
needed for access to, for example, a corporate customer using end-to-end encryption and high-volume traffic, the
same node has to be reused, while in a multiple UPE scenario, a different and less complex UPE and IASA could
be used for this second PDN connection.

3GPP

Release 8

67

3GPP TR 23.882 V8.0.0 (2008-09)

The use of a single UPE per UE may cause the UPE to be moved physically closer to the radio interface than
current GGSNs. The impact of this on operators is unclear. This should be considered as part of the migration
discussion.

The assumption and the detailed functional allocation between the different user plane nodes will be further elaborated
with the addition of more use cases for multiple PDNs.

7.10.2.2

Solution alternatives

This chapter is a work in progress. It is FFS how the solutions interwork with pre-SAE systems.
It is important that the solutions to use cases minimize the complexity of the mechanisms required for managing
multiple configurations and contexts in the UE and the network, which currently involves multiple APNs and PDP
addresses in the UE.
IP connectivity with multiple PDNs to each of the described use cases can be provided with one or more of the
following solution alternatives.
-

Single Ipv4 and Ipv6 access service supporting concurrent Ipv4 and Ipv6 addresses and service usage for dual
stack terminals. When used, this saves network resources and removes the need for UE to select the correct
access service depending on the IP version. The UE is aware of the IP version(s) supported by each access
service.

Single APN configuration: The term Single APN signifies access to one or more PDNs/Service Domains from
the UE point of view (and may include traffic separation rules) supporting all types of PDNs, i.e. Operator PDN,
Corporate or Private PDN and also Public Internet PDN. This allows the connectivity for a UE to be provided
using only one APN which has the same structure as APN in the IP Gateway. User data traffic separation into the
different PDNs can be performed in the network and be transparent to the UE.

Network based selection of the single APN configuration to be used for the UE in the IP Gateway based on
subscription information, or potentially by policy control means. Allowed access for the UE can be defined per
APN.

UE indication of IP version of access service to the IP Gateway when establishing a new SAE bearer service,
i.e. whether the IP access service is iPv4, Ipv6 or both.

UE indication of a specific additional APN to the IP Gateway, e.g. if needed for emergency session.

NAT between the IP Gateway and external PDN in case different address types and/or ranges are used. NAT
enables also access to multiple instances in parallel, e.g. access to multiple private PDNs at the same time.
Internet PDN uses public IP addresses, whereas operator and corporate/private PDNs may use private or public
addresses. NAT enables access to multiple private address spaces and may include interoperability between Ipv6
and Ipv4. Providing NAT functionality in the IP Gateway can also improve service access by providing to the UE
all services, including corporate services via e.g. L2TP tunnel, within the operator PDN IP address space.
Awareness of NAT in the UE and effects to network management need to be considered. Generally mandatory
usage of NAT and NAT like devices is discouraged due to various concerns, some of which are documented in
the TR 23.981.

Routing of IP packets in the UE between applications and IP connections in order to handle overlapping IP
address spaces, or service access over multiple network interfaces.

VPN client in UE with support for NAT traversal on top of LTE/SAE access to establish a secure tunnel to a
Corporate or Private PDN. The client can use split tunnelling by downloading specific network routes that allow
it to route only the Corporate or Private PDN traffic to the tunnel.

Network based VPN similar to specifications in TS 29.061 and TS 29.161.

Operator policies on QoS and flow based charging may be applied to differentiate between services. In the case
of split tunnelling in UE, this can be applied in conjunction with forced routing to specific next-hop routers to
differentiate between the non-tunneled and VPN tunnelled traffic.

IP access service via SAE anchor node(s) for 3GPP HO between 3GPP accesses when the SAE capable UE is
in pre-SAE/LTE 3GPP access system and SAE anchor(s) is available, and not towards pre-SAE/LTE GGSN.
This allows the UE to make handovers between 3GPP access systems.

3GPP

Release 8

68

3GPP TR 23.882 V8.0.0 (2008-09)

NOTE 1: This has dependencies with key issue 7.8.2

-

IP access service via SAE anchor node(s) for non-3GPP HO between 3GPP and non-3GPP access when the
SAE capable UE is in non-3GPP access systems and SAE anchor(s) is available. This allows the UE to make
handovers between 3GPP and non-3GPP access systems.

NOTE 2: This has dependencies with key issue 7.8.3

-

Dedicated IP Gateway may be used for each PDN/Service Domain by routing the user plane via the IP Gateway
for that PDN/Service Domain.

NOTE 3: User plane is always routed via an IP Gateway and UE needs to support at least one IP Address per PDN
-

Mobile IP tunnel: Mobile IP (MIP) tunnelling is used to reach the external PDN, where IASA containing a MIP
Home Agent (MIP HA) serves as a gateway to the PDN. There are as many IASAs (i.e. MIP Has) as there are
different external PDNs in parallel. The MIP Care-of Address (CoA) is assigned from the UPE address space.
The MIP Home Address (HoA) to access each particular external PDN is allocated from the PDN address space.
Both MIP4 and MIP6 may be supported simultaneously (requiring dual stack UPE), or alternatively, DS MIP6
may be used instead. In the non-roaming case, the reference point S5 between UPE and IASA is exhibited only
when the UPE has no direct access to a particular PDN. When using a non-3GPP IP access, the UE can access
multiple PDNs via multiple instances of the MIP based S2 reference point which has identical functionality as S5
and S8.

NOTE 4: This has dependencies with key issue 7.8.3

NOTE 5: User plane is always routed via a Home Agent and UE needs to support at least one Home Address per
PDN

Figure 7.10-2: Mobile IP tunnel solution in roaming case

-

Proxy MIP: SAE-capable UE can get access to multiple PDNs using different IP addresses (Home Address)
assigned by different IASAs. An IASA can be implemented as a Mobile IP Home Agent (HA) and the address
assignment can be performed using Proxy Mobile IP signalling, with MME/UPE acting as a Proxy MIP (P-MIP)
Client. The proposed solution works both with IPv4, Ipv6 and Dual stack Has. The P-MIP signalling can be used
to get a PDN IP address (Home Address) obtained at network attachment or based on explicit PDN IP address
request (e.g.: using DHCP negotiation) from the UE. Data from UE are sent directly to the UPE using the Home
Address as source address. Then UPE encapsulates packets towards the correct IASA.

NOTE 6: Access to multiple PDNs from a non-3GPP system with this solution requires P-MIP support in the non3GPP system

3GPP

Release 8

69

3GPP TR 23.882 V8.0.0 (2008-09)

NOTE 7: This has dependencies with key issue 7.8.3

NOTE 8: User plane is always routed via a Home Agent and UE needs to support at least one Home Address per
PDN

Figure 7.10-3: Proxy MIP solution

-

NAT Solution: It is not possible or very inefficient to support the corporate services by tunneling between UE
and corporate. The solution uses the single APN approach that supports all types of PDNs, i.e. Operator PDN,
Corporate or private PDN and also Public Internet PDN. NAT enables also interoperation between the different
PDNs in case different address types and or ranges, and in case of access to multiple private PDNs at the same
time. An APN defines the concurrent access possibilities to different PDNs. Allowed access is defined per APN
and controlled by subscription or policy control means. PDNs may use Ipv4 or Ipv6 addresses. Internet PDN
uses public IP addresses. User data traffic separation into the different PDNs is performed in the network only.

Figure 7.10-4: NAT Solution

7.10.2.3

Alternative solutions for the use cases

FFS.

3GPP

Release 8

70

3GPP TR 23.882 V8.0.0 (2008-09)

7.10.3 Impact on the baseline CN Architecture

Editors Note: It is FFS whether there is any particular impact.

7.10.4 Impact on the baseline RAN Architecture

Editors Note: It is FFS whether there is any particular impact.

7.10.5 Impact on terminals used in the existing architecture

Editors Note: It is FFS whether there is any particular terminal impact.

7.11 Key Issue Functions in the evolved packet core

7.11.1 Description of Key Issue Functions in the evolved packet core
The functions in the evolved packet core (as defined by Figure 4.2-1) are listed below. Depending on the deployment
scenario, some of these functions might be optional. Note that this is not the exhaustive list of the all functions required
in the evolved packet core and other functions identified later can be added.
-

IP access service enabling functions such as IP address allocation.

Packet routing and forwarding, including management and storage of user plane UE context describing IP bearer
service and internal routing information.

Policy and Charging Enforcement Function (PCEF) based on TS 23.203, including termination of Gx+ interface
according to the PCC architecture and termination of the Gy = Ro interface with the on-line charging server.

Collection of Charging Information for online or offline charging systems, including support for bearer and flow
based charging for IP services, and for session based services.

Mobility Anchor for mobility between different 3GPP based accesses (SAE/LTE and pre-SAE/LTE).

Mobility Anchor for mobility between 3GPP accesses and non 3GPP accesses.

Management and storage of UE control plane context, including generation of a temporary identity and mapping
it to a permanent identity (e.g. IMSI).

Mobility management, including determination of tracking areas and allowed PLMNs for handovers, and
registration and tracking of LTE_IDLE state Ues.

Authentication, authorization and key management, including HSS/AAA interaction.

Lawful interception of user plane traffic.

Lawful interception of signaling traffic.

Gateway functionality to external networks, including support for Network Address Translation (NAT) and
Firewall.

Content control, etc.

Multicasting traffic to multiple Ues.

The following functions are above eNodeB, and therefore in the evolved packet core if the RAN has no other entities
than eNodeB. If there are other RAN entities than eNodeB, their inclusion is FFS:
-

Ciphering termination for user plane traffic.

Ciphering/integrity termination for NAS signaling.

IP Header compression.

3GPP

Release 8

71

3GPP TR 23.882 V8.0.0 (2008-09)

Inclusion of the following functions is FFS:

-

Termination of LTE_IDLE state UE traffic on the downlink data path and paging requests.

To have a concrete architecture of the evolved packet core, the grouping of the functions into functional entities in the
evolved packet core needs to be studied.

7.11.2 Solution for Key Issue grouping of the functions

7.11.2.1

Allocation of evolved packet core functions to UPE, MME and Inter-AS

Anchor

The below non-exhaustive lists present the allocation of evolved packet core functions to logical entities, for the
purposes of comparing the grouping alternatives. This does not preclude solution alternatives that co-locate one or more
of the logical entities. Depending on the deployment and roaming scenarios, some of these functions might be optional.
The UPE consists of the following functions:
-

Packet routing and forwarding: For intra-UPE handovers without MME change, the control for eNB to UPE
tunnel movement occurs directly between the eNB and UPE without passing through the MME;

Depending on solution: allocation of a local IP address from the UPE address space for use by mobility
mechanisms;

FFS: Policy and Charging Enforcement Function (PCEF) based on TS 23.203 for roaming scenarios;

Depending on solution: Policy and Charging Enforcement Function (PCEF) based on TS 23.203 for route
optimisation scenarios;

Depending on solution: Collection of Charging Information for online or offline charging systems for roaming
with home routed traffic. The UPE generates CDRs and delivers CDRs to charging systems without passing
MME;

Depending on solution: Collection of Charging Information for online or offline charging systems when route
optimisation is applied. The UPE generates CDRs and delivers CDRs to charging systems without passing
MME;

Ciphering termination for user plane traffic;

IP Header compression;

Depending on solution: Lawful interception of user plane traffic. LI data are delivered without passing MME; LI
control on UPE is independent from MME;

Inter-eNodeB Mobility Anchor for user plane;

Depending on solution: inter-3GPP access system Mobility Anchor;

Trigger/initiation of paging when downlink data arrive for the UE in LTE_IDLE state.

FFS: Routing path establishment/change with IASA

The MME consists of the following functions. In some architecture solution alternatives, these functions may be colocated with the UPE:
-

Management and storage of UE control plane context;

Mobility management;

Authentication, authorization (PLMN, TA) and key management;

Lawful interception of signaling;

The MME terminates and handles UE NAS signaling; NAS signaling is not relayed via UPE; NAS signaling
means direct signaling between UE and entities above eNB;

3GPP

Release 8

72

3GPP TR 23.882 V8.0.0 (2008-09)

Ciphering/integrity termination for UE NAS signaling;

Management and allocation of temporary user identities;

Depending on solution: control plane function for inter-3GPP access system mobility.

The Inter-AS Anchor consists of the following functions. In some architecture solution alternatives, these functions may
be co-located with the UPE:
-

Packet routing and forwarding;

Depending on solution: Authentication, authorization and key management, for mobility management signaling
or for PDN access control;

Policy and Charging Enforcement Function (PCEF) based on TS 23.203;

Collection of Charging Information for online or offline charging systems;

Generation of CDRs and delivery to charging systems;

Mobility Anchor for mobility between 3GPP accesses and non 3GPP accesses;

Gateway functionality to PDN including IP address allocation from PDN address space;

Depending on solution: inter-3GPP access system Mobility Anchor;

Lawful interception of user plane traffic.

7.11.2.2

Alternative 1

7.11.2.3

Alternative 2

7.11.2.4

Alternative

7.11.3 Impact on the baseline CN Architecture

The baseline CN architecture is modified to reflect the functional grouping in the evolved core network.

7.11.4 Impact on the baseline RAN Architecture

The baseline RAN architecture is modified to be based on the functional split between RAN and CN.

7.11.5 Impact on terminals used in the existing architecture

FFS.

7.12 Key Issue QoS concepts

7.12.1 Terminology
The term Application Function (AF) is defined in TS 23.207 [19]. The terms Policy and Charging Rules Function
(PCRF) and Policy and Charging Enforcement Function (PCEF) are defined in TS 23.203 [20].

3GPP

Release 8

73

3GPP TR 23.882 V8.0.0 (2008-09)

A dedicated SAE bearer is associated with uplink packet filters in the UE and downlink packet filters in the PCEF
where the filters only match certain packets. A default SAE bearer is associated with match all uplink and downlink
packet filters in the UE and the PCEF, respectively.
An SAE bearer is referred to as a GBR SAE bearer if dedicated network resources related to a Guaranteed Bit Rate
(GBR) value that is associated with the SAE bearer are permanently allocated (e.g. by an admission control function in
the eNB) at SAE bearer establishment/modification. Otherwise, an SAE bearer is referred to as a Non-GBR SAE bearer.
A dedicated SAE bearer can either be a GBR or a Non-GBR SAE bearer. A default SAE bearer shall be a Non-GBR
SAE bearer.
An operator controlled Rx service is a service for which the PCEF receives from the PCRF service specific
uplink/downlink packet filters and service specific QoS parameters where the QoS parameters have been derived from
information that the PCRF received over the Rx interface from an AF.
An operator controlled Gx only service is a service for which the PCEF receives from the PCRF service specific
uplink/downlink packet filters and service specific QoS parameters without any interaction across an Rx interface.
NOTE:

A single PCEF may realize any combination of operator controlled Rx and Gx only services on the same
or different SAE bearers.

NOTE:

An operator controlled Gx only service may be realized based on a default SAE bearer or a dedicated
Non-GBR SAE bearer. An operator controlled Gx only service realized based on a dedicated GBR SAE
bearer is FFS.

7.12.2 Description of Key Issue QoS concepts

The key issue on QoS concepts encompasses the following aspects:
-

Means for providing enhanced QoS for services that require QoS or policies beyond what the default IP access
bearer provides;

An SAE/LTE QoS profile that is simple compared to the current UMTS QoS profile (i.e. UMTS bearer service
attributes). Possible simplification through QoS control based on service classes shall be studied.
At the same time complex mapping mechanisms between SAE/LTE QoS profile and the UMTS QoS profile are
to be avoided. Multiple mappings between UMTS and SAE/LTE QoS profiles should not result in QoS changes.

Signalling of QoS profiles and signalling for Resource Establishment or Resource Reservation, including the
direction of such signalling procedures (i.e. Network initiated / UE initiated);
It should also be studied whether/how the current UMTS signalling model can be simplified by deriving IP
bearer level and RAN level QoS and policy configuration from QoS-related signalling that is performed on
application-level (e.g. IMS). This includes study of the use of per-packet QoS-related information (e.g. DSCP
markings).

7.12.3 QoS Concept

The MME/UPE/Inter AS Anchor (Access Gateway aGW for short in this clause) will receive a PCC rule including
QoS request from the PCRF each time a new service is requested by the UE. If the requested QoS can not be provided
by the default IP bearer/connectivity service additional SAE bearer services are required, details about establishment are
FFS.
The aGW receives from the PCRF the details about the end-to-end services that need to be transferred, i.e. filters
describing the IP flows and related QoS description (at least bit rate information and a "traffic class" representing the
delay/priority requirement). The aGW may generate an aggregate for each traffic class consisting of all the end-to-endservices that are mapped to the same traffic class and their combined QoS description (at least bitrate). The eNodeB
receives the aggregate QoS descriptions for each SAE bearer service. Whenever an end-to-end service is going to be
started/terminated/modified, the aGW receives the relevant information, updates the aggregated QoS description and
forwards it to the eNodeB.
Both, UE as well as aGW perform the mapping of the end-to-end-service IP flows to SAE bearer service(s).

3GPP

Release 8

74

3GPP TR 23.882 V8.0.0 (2008-09)

In order to be able to differentiate between packets belonging to different SAE bearer services the eNodeB and the aGW
needs to be aware of the aggregate QoS description of an SAE bearer. The eNodeB uses it for scheduling (DL) and
policing (UL) and the aGW for policing (DL+UL).
For downlink, the nodeB treats the IP packets according to the aggregate QoS description of the SAE bearer service.
For the uplink, the eNodeB polices each IP packet against the aggregate QoS description of the SAE bearer service.
NOTE:

Potential conflicts between text in this section and the text in Section 7.12.8 may need to be resolved at a
later stage.

7.12.4 SAE Bearer Service Architecture

SAE System
UE

eNodeB

Peer entity
(e.g. UE,
server)

AGW

End-to-End Service

SAE Bearer Service

SAE Radio
Bearer Service

Physical Radio
Bearer Service

external Bearer
Service

SAE Access
Bearer Service

Physical
Bearer Service

Figure 7.12-1: SAE Bearer Service Architecture

It is FFS whether one or multiple AGWs serve a UE.
The SAE bearer service layered architecture is depicted in Figure 7.12-1. The definition of a bearer service as given in
TS 23.107 is still applicable:
-

A bearer service includes all aspects to enable the provision of a contracted QoS. These aspects are among others
the control signalling, user plane transport and QoS management functionality.

The SAE Bearer Service provides:

-

QoS wise aggregation of IP end-to-end-service flows;

IP header compression (and provision of related information to UE);

UP encryption (and provision of related information to UE);

if prioritised treatment of end-to-end-service signalling packets is required an additional SAE bearer service can
be added to the default IP service;

provision of mapping/multiplexing information to the UE;

provision of accepted QoS information to the UE.

The SAE Radio Bearer Service provides:

-

transport of the SAE Bearer Service data units between eNodeB and UE according to the required QoS;

linking of the SAE Bearer Service to the respective SAE Bearer Service.

3GPP

Release 8

75

3GPP TR 23.882 V8.0.0 (2008-09)

The SAE Access Bearer Service provides:

-

transport of the SAE Bearer Service data units between aGW and eNodeB according to the required QoS;

provision of aggregate QoS description of the SAE Bearer Service towards the eNodeB;

linking of the SAE Access Bearer Service to the respective SAE Bearer Service.

7.12.5 Granularity of QoS Control

Figure 7.12-2: Two Unicast SAE Bearers Each Consisting of one SAE Radio Bearer and one SAE
Access Bearer
A Service Data Flow (SDF) is an aggregate set of packet flows (see TS 23.203). An UpLink Packet Filter (ULPF) in the
UE binds an SDF to an SAE Bearer in the uplink direction, and a DownLink Packet Filter (DLPF) in the PCEF binds an
SDF to an SAE Bearer in the downlink direction.
Each unicast SAE Bearer is associated with one UE and one label (see clause 7.12.6).
There is a one-to-one mapping between an SAE Radio Bearer and an SAE Access Bearer.
An SAE Bearer (i.e., the corresponding SAE Radio Bearer and SAE Access Bearer) is the level of granularity for QoS
control in an SAE/LTE access system. That is, SDFs mapped to the same SAE Bearer receive the same treatment (e.g,,
scheduling principle). Providing different QoS to two SDFs thus requires that a separate SAE Bearer is established for
each SDF.

7.12.6 The QoS Profile of the SAE Bearer

The SAE QoS profile comprises only the following QoS parameters:
-

Label

GBR (Guaranteed Bit Rate UL + DL)

MBR (Maximum Bit Rate UL + DL)

ARP (Allocation and Retention Priority)

An SAE QoS profile is associated with an SAE Bearer. The four parameters of the SAE QoS profile are only signaled
from the MME/UPE to the eNB across S1 in the control plane at SAE bearer establishment / modification.
In the following we use the terms GBR bearer and Non-GBR bearer as defined in clause 7.12.1.
A Label is a scalar. The Label identifies Label Characteristics used to derive a traffic handling behavior in the eNB.
It is understood that operators require consistent traffic handling for specific services; in particular in a multi-vendor
scenario and in a roaming scenario. For that reason a number of traffic handling behaviors need to be standardized
(similar to the way that the so-called Per-Hop Behaviors are standardized for DiffServ, e.g. see IETF RFC 2597 [21]
and IETF RFC 3246 [22]).

3GPP

Release 8

76

NOTE:

3GPP TR 23.882 V8.0.0 (2008-09)

A specification of Label Characteristics provides sufficient information that allows together with the
other above mentioned signaled QoS parameters GBR and MBR the realization of a particular SAE
Radio Bearer in an eNB. For example, such information may include a reference SAE Radio Bearer
configuration (e.g. la 34.108, e.g., including RLC mode); scheduling policy; queue management policy;
packet discard timers, etc., etc.

Furthermore, it is understood that the mapping table (Standardized Label Label Characteristics) shall be specified in
3GPP specifications.
The GBR applies only to GBR bearers.
The MBR applies to GBR bearers where MBR may be greater than or equal to GBR. The signaling of MBR for NonGBR bearers is FFS. See Section 7.12.8 on "Aggregate Maximum Bit Rate".
GBR and MBR denote bit rates of traffic per SAE bearer while AMBR (see Section 7.12.8) denotes a bit rate of traffic
per group of SAE bearers. Each of those three QoS parameters has an uplink and a downlink component.
The MME/UPE shall modify the values of the GBR, MBR, and AMBR parameters for the purpose of signaling on S1 to
denote bit rates provided to/from "below" the PDCP layer. In this case the GBR, MBR and AMBR refer to a bit stream
that is composed of application level data, transport protocol and network protocol headers (e.g. TCP, RTP, UDP,
IP-based headers with or without IP-based header compression), and PDCP headers.
NOTE:

A more precise definition of GBR and MBR, e.g. whether those parameters only denote a bit rate or
additionally also a token bucket size, is left FFS.

The ARP applies to both GBR and Non-GBR bearers. The primary purpose of ARP is to decide whether a bearer
establishment / modification request can be accepted or needs to be rejected in case of resource limitations (typically
available radio capacity in case of GBR bearers). In addition, the ARP can be used (e.g. by the RAN) to decide which
bearer(s) to drop during exceptional resource limitations. Once successfully established, a bearers ARP shall not have
any impact on the traffic handling (e.g. scheduling and rate control) of the traffic carried by the bearer. Such traffic
handling should be solely determined by the other QoS parameters of the SAE QoS profile: Label, GBR, MBR.
NOTE:

The ARP should be understood as "Priority of Allocation and Retention"; not as "Allocation, Retention,
and Priority". A more precise definition of ARP, e.g. the encoding of 'retention', is left FFS.

7.12.7 Label Usage Principles

-

Need two levels of mappings: (1) SDF QCI (S7), and (2) Label Label Characteristics:
-

The value of QCI signaled on S7 is identical to the value of Label signaled on S1

(1) FFS (need agreed roaming architecture first): Service Data Flows (SDFs as defined in PCC) will be
mapped to a Label in the HPLMN or VPLMN for SDFs managed by the HPLMN. That mapping is done in
the VPLMN for SDFs managed the VPLMN (e.g. in case of local breakout)
-

(2) Need to standardize mapping table Standardized Label Label Characteristics

Use RFC4594 as an example for (1) and/or (2)

Label Characteristics = < SAE Bearer type (GBR or Non-GBR), delay budget (left over in eNB per packet
(UL+DL)); loss tolerance (of traffic per SAE bearer); other(FFS) >:

NOTE:

FFS: Need to standardize mapping table "well-known services" standardized Label(s)

Admission control can be performed at establishment / modification of a Non-GBR SAE bearer even
though a Non-GBR SAE bearer is not associated with a GBR value (see Section 7.12.6).

FFS: define integer values for 'delay budget' and 'loss tolerance' or only "soft values" (e.g. low medium, high)

FFS: Need for additional elements defining Label Characteristics ("other(FFS)")

The mapping standardized Label 'X' Label Characteristics will be used by the operator owning the node (e.g.
eNB) to configure node-specific parameters (e.g. scheduling weights, admission thresholds, queue management
thresholds, RLC configuration, packet delay budget, etc.) associated with an SAE Bearer that itself is associated
with Label 'X';

3GPP

Release 8

77

Standardized Label values need to be assigned by 3GPP;

Non-standardized Label values are outside the scope of this TR.

3GPP TR 23.882 V8.0.0 (2008-09)

7.12.8 Aggregate Maximum Bit Rate

Multiple SAE Bearers can share the same Aggregate Maximum Bit Rate (AMBR). That is, each of those SAE Bearers
could potentially utilize the entire AMBR, e.g. when the other SAE Bearers do not carry any traffic. The AMBR is the
'subscription MBR' stored in HSS. The AMBR is signaled from the MME/UPE to the eNB across S1 in the control
plane when the UE connects to the network.
NOTE:

It is FFS whether the AMBR will be signalled to the UE (in Access-Stratum and/or Non-Access Stratum).

NOTE:

It is FFS whether the AMBR can be modified from the MME/UPE.

This section outlines the options for the scope of AMBR that will be considered.
-

Option 1
AMBR applies to all Non-GBR SAE Bearers of a UE. GBR SAE Bearers are outside the scope of AMBR. In this
case, Non-GBR SAE Bearers do not have a separate 'per SAE Bearer MBR'.

FFS: Option 2
AMBR can apply to only some Non-GBR SAE Bearers of a UE. Independent Non-GBR SAE Bearers can be
established with an independent per SAE Bearer MBR (signaled as part of the SAE bearer's QoS profile). GBR
SAE Bearers are outside the scope of AMBR.

NOTE:

For option 2 it is left FFS whether multiple groups of Non-GBR SAE bearers each with an independent
AMBR can be defined.

FFS: Option 3
AMBR applies to all SAE Bearers (GBR and Non-GBR).

FFS: Option 4
AMBR can apply to only some SAE Bearers (GBR and Non-GBR). Independent SAE Bearers (GBR and NonGBR) can be established with an independent MBR (signaled as part of the SAE bearer's QoS profile).

7.12.9 Resource Establishment and QoS Signalling

Resource Establishment and QoS Signalling handle the provisioning of QoS/policy information to the network entities
that control radio/network resources. Radio/network resources are controlled applying information about the users'
subscription, the UE's and the radio/network capabilities, the availability of radio/network resources, certain operator
policies, and what services are being used.
It is assumed that resources can always be granted even though the requested QoS may not, i.e. the QoS can be
downgraded by the network/radio. It is FFS to which extent a negotiation/re-negotiation of requested network resources
shall be possible.
Resource Establishment and QoS Signalling assume a preceding signalling of QoS requirements. This could be either
by application signalling (e.g. IMS) or by IP bearer signalling. It is FFS if this will lead to the establishment of
additional IP bearers (comparable to UMTS PS bearers).The application signalling takes place on the already
established resources of the default IP access bearer. An application function performs the negotiation with the UE on
media components and their characteristics and provides the relevant information to the PCRF.
For operator-controlled services (e.g. IMS) SAE/LTE supports Network-Initiated SAE Bearer establishment and
Network-Initiated SAE Bearer modification, i.e., the network controls the SAE Bearer signalling and is thus responsible
for requesting the appropriate bearer QoS parameters.
NOTE:

The provisioning of enhanced QoS for non-operator-controlled services is FFS

NOTE:

Support in SAE/LTE for UE-Initiated SAE Bearer establishment and UE-Initiated SAE Bearer
modification is FFS

The Resource Establishment is triggered by a resource request from the PCRF which translates the media information
into the necessary Policy/QoS information or by IP bearer signalling which contains the Policy/QoS information. In the

3GPP

Release 8

78

3GPP TR 23.882 V8.0.0 (2008-09)

latter case it is assumed that the network performs a QoS authorization beforehand which adds the Policy information to
the bearer signalling. It is FFS whether triggering of the Resource Establishment by the PCRF should be also supported
for non-IMS services.
The Resource Establishment function contains both, the functions that are needed to setup network and radio resources
and the respective signalling towards the UE to bind the radio resources to the application layer and provide it with the
authorised QoS.
The MME/UPE checks whether the granted resources correspond to the limits defined in the subscription profile of the
user and initiates a resource assignment towards the radio part of the network.
The responsible LTE-RAN function checks the availability of resources and sets up the required resources and finally
informs the UE on the radio resources configuration for the service and which resources are linked to which IP or
session flows.
NOTE:

Allocation of LTE-RAN functions to logical entities is FFS in RAN WGs.

LTE-RAN
functions

UE

MME/UPE

1. Service negotiation on existing signalling relation + default IP bearer service established

2. Request Resources
(Policy/QoS Info)
3. Subscription Check,
Admission Control, QoS
Control, ...
4. Radio Resource Assignment
(QoS Info)
5. Admission Control for
radio resources, UE/network
capabilities, Configure
Scheduler etc.
6. Communicate granted Radio Resource to UE
(linking info, radio resource info, QoS info)

7. Assignment Ack
8. Report Resources
(QoS Info)

Figure 7.12-3: Information flow for Resource Establishment in the Radio Network
1) The UE has a signalling relation established with the network which performs on the default IP access bearer.
2) The MME/UPE is triggered by a resource request which contains Policy/QoS Information corresponding to the
requested service.
3) The MME/UPE checks the UE's subscription, performs admission control according to the received QoS
information and available resources and applies the received policy information.
NOTE:

The location of the policy enforcement point is FFS, it might be located in the (inter-access-) mobility
anchor).

4) MME/UPE initiates the Resource Establishment towards the responsible LTE-RAN functions.
5) The responsible LTE-RAN functions perform admission control. Translation of the received QoS information
into radio QoS information is expected to be necessary. The allocation of radio resources and the appropriate
configuration of the scheduler are performed according to the translated QoS information.
6) The UE is provided with information about the radio configuration necessary for the service and related
information to link radio resources with IP or session flows.
7) The MME/UPE is informed about the successful outcome of the resource establishment.

3GPP

Release 8

79

3GPP TR 23.882 V8.0.0 (2008-09)

8) The MME/UPE reports the outcome of the resource establishment together with the negotiated QoS.

7.12.10 Identified Open Issues

-

FFS: UE-initiated bearer establishment procedure needed for SAE/LTE?

FFS: Tunnel protocol on S1?

FFS: Differentiated packet discarding of packets of the same bearer?

FFS: Can SDFs from different PDNs be multiplexed onto the same SAE Bearer?

FFS: Allow QoS negotiation between eNB and MME/UPE at bearer establishment / modification?

FFS: For operator-controlled services: SAE/LTE supports only Network-Initiated Bearers (establishment +
modification)?

7.12.11 Impact on the baseline CN Architecture

Editors Note: It is FFS whether there is any particular impact.

7.12.12 Impact on the baseline RAN Architecture

Editors Note: It is FFS whether there is any particular impact.

7.12.13 Impact on terminals used in the existing architecture

Editors Note: It is FFS whether there is any particular terminal impact.

7.13 Key Issue Network Attachment

7.13.1 Description of Network Attachment
A UE/user needs to register with the network to receive services that require registration. This registration is described
as Network Attachment. The always-on IP connectivity for UE/users of the SAE system is enabled by establishing a
basic IP bearer during Network Attachment.
The network keeps UE/user registration information. The UE/user registration information, e.g. the mapping between
temporary and permanent user identities and the last registered tracking area, is kept by the network for an
(implementation) specific time after the UE/user detached before being deleted to allow for Network Attachment with
user identity confidentiality.

7.13.2 Solution for Key Issue Network Attachment

The following information flow shows the network attachment of a UE. (The dashed entity is involved optionally.)
MME and UPE are shown as combined; though they may be separate (in this case an additional interface must be
realized).
The steps shown in the information flow describe individual functional steps. This does not preclude any combining of
multiple functional steps into one message or separating one step into a message sequence. The sequence of the steps
shown in the information flow may change depending on the solutions for related key issues.

3GPP

Release 8

80

3GPP TR 23.882 V8.0.0 (2008-09)

Figure 7.13-1: Network Attachment information flow

1) The UE discovers the SAE/LTE access system(s) and performs access system and network selection. If network
sharing is present, a shared network may be selected. Further details of this process are FFS.
2) The UE sends an attach request to the MME/UPE, including its old registration information, e.g. temporary
identity. If the UE has no old registration information it includes its permanent identity.
In case of network sharing is applied the attach request includes information for selecting network or
MME/UPE.
The Evolved RAN selects the MME/UPE.
The attach request may include information on Default IP Access Bearer (e.g. user preferred IP address and
APN).
3) If old registration information was sent by the UE the MME/UPE tries to retrieve user information from the old
MME/UPE by sending the old registration information.
4) The old MME/UPE sends user information, e.g. the permanent user identity, to the MME/UPE.
5) The user/UE is authenticated in the new MME/UPE.
6) The MME/UPE registers itself as serving the UE in the HSS.
7) The user/UE information in the old MME/UPE is deleted or the user/UE is marked as not present.

3GPP

Release 8

81

3GPP TR 23.882 V8.0.0 (2008-09)

8) The HSS confirms the registration of the new MME/UPE. Subscription data authorising the Default IP Access
Bearer are transferred. Information for policy and charging control of the Default IP Access Bearer is sent to the
MME/UPE.
9) An Inters AS Anchor is selected. The selection mechanism is FFS. The IP address configuration is determined by
user preferences received from the UE, by subscription data, or by HPLMN or VPLMN policies.
10)The Inter AS Anchor configures the IP layer with the determined user IP address. The user plane is established
and the default policy and charging rules are applied. The user plane establishment is initiated by the UE or by
the MME/UPE, which is FFS.
11) The MME/UPE provides the Evolved RAN with QoS configurations for the Default IP Access Bearer, e.g. the
upper limits for transmission data rates. It is FFS whether this provision of QoS configuration requires an
additional trigger, e.g. the need to transfer uplink or downlink user data.
12)The MME/UPE accepts the UE's network attachment and allocates a temporary identity to the UE. Also the
determined user IP address is transferred.
13)Roaming restrictions are checked and if violated the network attachment is rejected.
14)The UE acknowledges the success of the network attachment.
It shall be possible for a MME/UPE to trigger the UE to reattach (for reasons like load redistribution, attachment to a
topologically more optimal MME/UPE due to current user location etc.). In this case, the following procedure would
apply:

Figure 7.13-2: Network initiated Re-Attachment information flow

3GPP

Release 8

82

3GPP TR 23.882 V8.0.0 (2008-09)

1) The Old MME/UPE requests the UE to re-attach.

2) The UE discovers the SAE/LTE access system(s) and perform access system and network selection. However,
this could be skipped in the case of Re-attachment required to move the UE to a topologically more optimal
MME/UPE.
3) The UE sends an attach request to the MME/UPE, including its old registration information, e.g. temporary
identity. If the UE has no old registration information it includes its permanent identity.
In case of network sharing is applied the attach request includes information for selecting network or
MME/UPE.
The Evolved RAN selects the MME/UPE.
The attach request may include information on Default IP Access Bearer (e.g. user preferred IP address and
APN).
4) If old registration information was sent by the UE the MME/UPE tries to retrieve user information from the old
MME/UPE by sending the old registration information.
5) The old MME/UPE sends user information, e.g. the permanent user identity, to the MME/UPE.
6) The user/UE is authenticated in the new MME/UPE.
7) The MME/UPE registers itself as serving the UE in the HSS.
8) The user/UE information in the old MME/UPE is deleted or the user/UE is marked as not present.
9) The HSS confirms the registration of the new MME/UPE. Subscription data authorising the Default IP Access
Bearer are transferred. Information for policy and charging control of the Default IP Access Bearer is sent to the
MME/UPE.
10)An Inters AS Anchor is selected. The selection mechanism is FFS.
11) The Inter AS Anchor configures the IP layer with the determined user IP address. The user plane is established
and the default policy and charging rules are applied. The user plane establishment is initiated by the UE or by
the MME/UPE, which is FFS.
12)The MME/UPE provides the Evolved RAN with QoS configurations for the Default IP Access Bearer, e.g. the
upper limits for transmission data rates. It is FFS whether this provision of QoS configuration requires an
additional trigger, e.g. the need to transfer uplink or downlink user data.
13)The MME/UPE accepts the UE's network attachment and allocates a temporary identity to the UE. Also the
determined user IP address is transferred.
Roaming restrictions are checked and if violated the network attachment is rejected.
14)The UE acknowledges the success of the network attachment.
NOTE:

It is FFS whether the re-attach procedure includes IP address re-allocation and Inter AS Anchor reselection or whether the UE does not change IP address and Inter AS Anchor during re-attach procedure.

7.13.3 Impact on the baseline CN Architecture

Editors Note: It is FFS whether there is any particular impact.

7.13.4 Impact on the baseline RAN Architecture

Editors Note: It is FFS whether there is any particular impact.

7.13.5 Impact on terminals used in the existing architecture

Editors Note: It is FFS whether there is any particular terminal impact.

3GPP

Release 8

83

3GPP TR 23.882 V8.0.0 (2008-09)

7.14 Key Issue Paging and C-plane establishment

7.14.1 Description of Key Issue Paging and Evolved RAN C-plane
establishment
The key issue Paging and C-plane establishment handles both, the mobile terminating and the mobile originating case
of C-plane establishment comprising:
-

in case of mobile terminating case: termination of incoming data packets for Ues in LTE_IDLE, triggering the
paging and distribution of paging over all cells of the Tracking Area the UE is registered.

for the mobile terminating and the originating case: establishment of a C-plane connection between UE and the
network, including the establishment of radio resources for the default (signalling) IP connectivity service and
possibly for other preserved services for which context data are already available in the MME/UPE and the UE.

NOTE:

There is some relation with "Key Issue Inter 3GPP Access System Mobility in Idle State".

7.14.2 Solution for Key Issue Paging and Evolved RAN C-plane
establishment
NOTE:

It is agreed that paging is initiated from the UPE (rather than from the eNodeB), provided that the
network signalling caused by Ues moving between LTE ACTIVE and LTE IDLE states is very limited.
E.g. by ensuring that Ues in LTE ACTIVE state have the same power saving capabilities as those in LTE
IDLE state.

A downlink data packet is terminated at the MME/UPE and paging is done within the cells contained in the Tracking
Area the respective user is registered.
The UE requests default radio resources to be able to contact the MME/UPE either in response to the paging request in
the mobile terminating case or for the mobile originating case. The UPE correlates the incoming data packet with either
the default IP connectivity service or other preserved service contexts.
The network provides the UE information to the radio functions of the evolved RAN to perform its services on the radio
resources (e.g., necessary information to allow the UE and network to communicate via scheduling control channels).
In the information flow below MME and UPE are shown together for simplicity reasons. This does not preclude a
separation, which would however require the definition of an interface between both entities. In a similar manner all
radio functions have been grouped into a single functional entity "radio functions".
NOTE:

Allocation of radio functions to logical entities is FFS in RAN WGs.

3GPP

Release 8

84

3GPP TR 23.882 V8.0.0 (2008-09)

Figure 7.14-1: Information flow for paging and C-plane establishment

1) Both, the UE in LTE_IDLE and the MME/UPE the UE is registered hold at least one preserved service context
(i.e. for the default IP connectivity service).
2) The UPE receives a downlink data packet for the UE and discovers that no connection with UE exists radio
resources are yet established.
3) The MME/UPE checks the state of the UE and retrieves the Tracking Area it is registered.
4) The MME/UPE triggers paging and requests the responsible radio functions to page the UE in all cells of the
Tracking Area the UE is registered.
5) The UE contacts the network using a Radio Resource Connection Request message containing NAS equivalent
information for "Service Request". The Radio functions send the Radio Resource Connection Request message
to the MME/UPE that is serving the UE.
NOTE 1: It might be possible to start to exchange AS equivalent information for the Security Mode Command
function already at this point in time, however, this is FFS.
6a) The MME/UPE correlates the UE request with the Paging procedure.
6b)If the network accepts the Service Request, it is possible to start data transmission on default resources.

3GPP

Release 8

85

3GPP TR 23.882 V8.0.0 (2008-09)

7) If the network decides to grant requested resources, it issues a Radio Resource Setup containing NAS equivalent
information for "Service Accept" and possibly (network initiated) "Activate PDP Context request" and AS
equivalent information for "Security Mode Command" and possibly RAB Assignment request / RB Setup.
8) The UE acknowledges the Radio Resource Setup. This might include the signalling of NAS equivalent
information for "Activate PDP Context Accept". It also includes AS equivalent information for "Security Mode
Complete" and possibly "RAB Assignment Response"/"RB Setup Complete".
NOTE 2: Radio function related details for steps 7) and 8) are further detailed in the key issue "Resource
Establishment and QoS Signalling" in TR 25.912.
NOTE 3: Whether it is possible to perform steps 5), 7) and 8) in 2 steps is FFS.

7.14.3 Impact on the baseline CN Architecture

Editors Note: It is FFS whether there is any particular impact.

7.14.4 Impact on the baseline RAN Architecture

Editors Note: It is FFS whether there is any particular impact.

7.14.5 Impact on terminals used in the existing architecture

Editors Note: It is FFS whether there is any particular terminal impact.

7.15 Key Issue: Intra LTE-Access-System inter MME/UPE

handover in the active mode
7.15.1 Description of Key Issue
This key issue is about whether it is advantageous to perform an inter-MME/UPE handover in case of an intra-LTE
handover, and studies different solutions that can solve this problem.
NOTE:

This key issue partially overlaps with key issue Intra LTE-Access-System handover. It is intended to
merge the two key issues once the key issue Intra LTE-Access-System handover is described in this TR.

NOTE:

Depending on the key issue of UP/CP separation, this key issue can be divided into inter-UPE handover
and inter-MME handover.

7.15.2 Solution for key issue

7.15.2.1

Alternative 1

7.15.2.1.1

Description

This solution proposes to perform inter-MME/UPE handover in LTE_ACTIVE mode when:

-

a UE moves a significant distance from its current MME/UPE, and when

the active communications are not delay-sensitive.

Whether inter-MME/UPE handoffs for active Ues with delay-sensitive communications are desirable remains FFS.
Proposed Solution:
Inter-MME/UPE handoffs can be achieved through a common 'user plane anchor' as illustrated in Figure 7.15-1.

3GPP

Release 8

86

3GPP TR 23.882 V8.0.0 (2008-09)

Figure 7.15-1: Intra LTE-Access-System inter-UPE/MME handover

Possible approaches to handle inter-MME/UPE mobility in this solution can be Mobile IP, NETLMM, etc.
This solution proposes different handoff procedures depending on the type of communications active on the UE at the
time of crossing a MME/UPE service area.
Procedure for Ues with non-delay sensitive communications (see Figure 7.15.2):
-

When the UE crosses a MME/UPE service area boundary, an inter-MME/UPE handover is performed. A new
MME/UPE is selected in the new service area in the same way as in LTE_IDLE mode mobility. This type of
mobility management is sufficient for terminals without delay sensitive communication requirements. Figure
7.15.2 illustrates how MME/UPE is re-selected for Ues with non delay-sensitive communication.

Figure 7.15.2: MME/UPE selection for Active UE with non delay-sensitive traffic
Procedure for Ues with delay sensitive communications (see Figure 7.15-3):
-

When the UE crosses a MME/UPE service area boundary, the original MME/UPE is maintained and the handoff
is performed to a LTE-RAN entity in the new service area. This is enabled by the S1-flex concept. Only when
the UE goes into LTE_IDLE state, the UE re-registers with a MME/UPE in the new service area. As part of this
process, a new MME/UPE is selected in the new service area. This type of mobility management is suitable for

3GPP

Release 8

87

3GPP TR 23.882 V8.0.0 (2008-09)

delay-sensitive communication (e.g., VoIP), since any perceivable disruption due to MME/UPE re-selection is
avoided. Figure 7.15-3 illustrates how MME/UPE is re-selected for Ues with delay-sensitive communication.

Figure 7.15-3: MME/UPE selection for an Active UE with delay-sensitive traffic

Since this alternative solution does not intend to change the signalling sequence for intra-LTE-Access-System interMME/UPE handover in LTE_ACTIVE mode, detailed signalling sequences are not provided.
NOTE:

7.15.2.1.2

This approach does not preclude that several MME/UPEs serve the same service area as discussed in the
key issue on redundancy and load sharing.

Impact on the baseline CN Architecture

Editors Note: It is FFS whether there is any particular impact.

7.15.2.1.3

Impact on the baseline RAN Architecture

Editors Note: It is FFS whether there is any particular impact.

7.15.2.1.4

Impact on terminals used in the existing architecture

Editors Note: It is FFS whether there is any particular terminal impact.

3GPP

Release 8

7.15.2.2
7.15.2.2.1

88

3GPP TR 23.882 V8.0.0 (2008-09)

Alternative 2
Description

Figure 7.15-4: intra-LTE handover with change of MME/UPE

The procedure is illustrated in the following flow charts:

3GPP

Release 8

89
eNB 1

UE

3GPP TR 23.882 V8.0.0 (2008-09)

MME/UPE
1

S1

eNB 2

Sx

S1

S5/S8

MME/UPE
2

IASA

1. IP bearer service
2. Handover Initiation
UE in ACTIVE mode

3. Handover Required (UE eNB context, eNB2 id)

4. Handover Required (UE eNB context,

eNB2 id, UE MM/SM Context)

5. Handover Request with eNB2 (UE eNB context)

Bearer path established between eNB2 and UPE2
6. Handover Response
7. Means to minimize loss of
data
8. Handover Command
9. Radio Bearer Establishment, UE detected by eNB2
10. Handover Complete Detect

13. Handover Complete (resource release)

11. Route Update/Bearer

Request
12. Handover Complete (Resource release)

14. IP bearer service via MME/UPE2

Figure 7.15-5 : intra-LTE MME/UPE Relocation in Active mode

Editor's note: transfer of PCC information is FFS
1) The IP bearer service is established between the UE and the IASA via the MME/UPE1
2) The eNB1 decides to initiates a handover to eNB2
3) The eNB1 sends a Handover Required to the MME/UPE1.
4) The MME/UPE1 selects a MME/UPE2 serving the eNB2 the UE is going to use and sends it a Handover
Preparation Request, including the UE context information.
5) The MME/UPE2 creates a UE context and sends a Handover Preparation Request to the eNB2. The eNB2 sends
a Handover Preparation Confirm to the MME/UPE2. The bearer plane is established between eNB2 and
MME/UPE2
6) The MME/UPE2 sends a Handover Preparation Confirm to the MME/UPE1.
7) Mean to minimize lost of data i.e. MME/UPE1 starts bi-casting to eNB1 and MME/UPE2 or data forwarding to
MME/UPE2.
8) The MME/UPE1 sends a Handover Command to the UE.

3GPP

Release 8

90

3GPP TR 23.882 V8.0.0 (2008-09)

9) The UE is detected at the eNB2.

10)eNB2 sends a Handover Complete to the MME/UPE2.
11) The MME/UPE2 does a route update with the IASA.
12)The MME/UPE2 informs MME/UPE1 of the Handover Complete and the possibility to release resources in
previous access. MME/UPE1 now sends all downlink packets only to the MME/UPE2.
13)The resource in the source system is released.
14)The IP Bearer service is now established between the UE and the IASA via MME/UPE2.
NOTE:

7.15.2.x

Step 11 above shows a proposal in case of PMIP/GTP solutions and it would be a route update directly
between the UE and IASA in case of MIP use.

Alternative x

7.16 Key Issue Network Redundancy and Load Sharing

7.16.1 Description of Key Issue Network Redundancy and Load-sharing
Redundancy is an important factor contributing to the overall reliability of the network, and load sharing can be used by
the operators to improve resource efficiency. Both redundancy and load-sharing may be achieved by two or more
entities performing the same functions, where the appropriate entity is chosen as needed. This Key Issue outlines
network redundancy and load sharing solutions over various network nodes and interfaces.

7.16.2 General Solutions for key issue Network Redundancy and Loadsharing
In the following text, client entity denotes an entity that uses the services of a serving entity that employs redundancy or
load-sharing mechanisms.
In one potential solution, the client entity attempts to query each serving entity in a fixed sequence until a serving entity
responds, i.e. as long as the candidate serving entities fail to or refuse to respond to the query. It is a simple solution but
not a flexible one. In order to achieve load sharing, the list of serving entities used by the client entity should be
carefully configured. This solution is suitable for redundancy scenario, or roughly load-sharing among a few entities. In
case of serving entity failure, it may take some time for the client entity to find an appropriate substitute serving entity.
In another potential solution, the sequence of serving entities used by the client entity is adjustable. The priority of each
serving entity in the list can be reconfigured, e.g. based on history information and current conditions. Redundancy can
be achieved more intelligently. Load sharing can be achieved if load information can be acquired or deduced. Compared
to the first solution, this solution is suitable for more precise load-sharing among a limited set of entities. In case of
serving entity failure, the time required to find a substitute serving entity is not reduced compared to the first solution.
In a third potential solution, a 'request and respond' mechanism is used. The client entity sends out a request, and the
serving entity that responds faster than the other serving entities are chosen, or the serving entity that responds with the
highest service priority is chosen. This solution can be used to attain redundancy and load sharing among many entities,
while achieving a more precise load-sharing compared to the first two solutions. The mechanism makes use of more
messages in order to reduce the search time and improve the precision of load sharing. Multicast/Broadcast may be used
to reduce the number of messages if needed.
Other possible solutions are FFS. For example, the anycast feature of Ipv6 may be considered.
It is FFS which solution would be used in each different situation.
It is FFS whether redundancy or load-sharing of serving network entities are needed when the client entity is a UE.

3GPP

Release 8

91

3GPP TR 23.882 V8.0.0 (2008-09)

7.16.3 S1-flex Concept

7.16.3.1

Description of issue

Support for Network Redundancy and Load Sharing of MME / UPEs in SAE / LTE is achieved by making the S1
interface a multi-to-multi interface, where one node in E-UTRAN can be connected to multiple MME / UPEs for
different terminals.
This clause is outlining the solutions for this key issue.

7.16.3.2

Assumptions on S1-flex concept

The following assumptions are taken regarding the S1-flex configuration:

1. There is a multi-to-multi relationship between the E-UTRAN and MME / UPEs in SAE / LTE, meaning one
node in eUTRAN can communicate with different MME / UPEs and vice versa.
2. One terminal can only be assigned to one MME at a time.
3. The MME / UPE will be assigned to the terminal during attach to the network, and it is FFS whether the MME /
UPE will be unchanged until the terminal leaves the serving area of that MME / UPE.

7.17 Key Issue Network Sharing

7.17.1 Description of Network Sharing
The key issue Network Sharing presents a way to apply functionality corresponding to Rel-6 MOCN Network Sharing
also to the LTE / SAE / LTE architecture.
The Rel-6 Network Sharing architecture describes two architectures for network sharing, the Gateway Core Network
(GWCN) configuration and the Multi-Operator Core Network (MOCN) configuration. In MOCN configurations only
the radio access network is shared, whereas in GWCN configurations also the SGSN and the MSC are shared. Similar
solution as MOCN sharing can in SAE / LTE architecture be supported where the MME / UPE belongs to each operator
and the e-UTRAN is shared among the operators.
The support of Network Sharing is based on support for multi-to-multi relationship between nodes in E-UTRAN and
MME/UPEs (S1-flex).

7.17.2 Solution for Key Issue Network Sharing

7.17.2.1

General

Figure 7.17.2 illustrated the case when 2 operators are sharing the base station sites (Node B) but having their own
MME / UPEs.

3GPP

Release 8

92

3GPP TR 23.882 V8.0.0 (2008-09)

Figure 7.17.2: Network Sharing in SAE/LTE based on S1-flex configuration

NOTE:

7.17.2.2

This figure and this key issue uses NB for simplification reasons but does not make any detailed
assumption on the Evolved RAN architecture. Any RAN details are FFS.

S1-flex configuration

The SAE/LTE network sharing function uses multi-to-multi connections between nodes of E-UTRAN and MME/UPE's,
"S1-flex".

7.17.2.3

Broadcast system information for an SAE/LTE network

Broadcast system information concerning available Operators is included in each cell in the LTE RAN. In an LTE RAN
which is shared by multiple Operators the broadcast system information contains multiple PLMN-ids (one PLMN-id for
each sharing Operator). An LTE UE decodes this information and takes the information concerning available Operators
into account in network and cell (re-)selection procedures.

7.17.2.4

Network selection in an SAE/LTE network

Network sharing is an inherent part of the SAE/LTE architecture, both on the UE and network side. All Ues equipped
with the new LTE radio supports network sharing from the beginning, i.e. any network sharing related information is an
inherent part of the SAE/LTE protocols and is supported by Ues. (With Rel-6 Netshare terminology, all Ues are
"supporting Ues").
An LTE UE decodes the broadcast system information to determine available Operators in the network. All Operators
indicated in the broadcast system information, regardless if there are multiple or a single Operator indicated, are treated
equally when the PLMN selection procedure is performed.

7.17.2.5

Assignment of Operator and MME/UPE node

When an LTE UE performs an initial access to a network, it informs the E-UTRAN of the identity of the Operator it has
chosen. The E-UTRAN routes the initial access to an MME/UPE of the chosen Operator.
After initial access to a shared network the UE does normally not change to another available Operator as long as the
selected Operator is available to serve the UE's location.
When the network signals tracking area identities to Ues, e.g. in location updating accept messages, these identities
shall contain the chosen Operator identity. The UE stores appropriate information on the SIM, to enable reattach to the
same Operator and MME/UPE again after power-off.
A UE shows the name of the Operator corresponding to the PLMN-id it has registered with.

3GPP

Release 8

7.17.2.6

93

3GPP TR 23.882 V8.0.0 (2008-09)

Accounting in RAN

When an LTE RAN is configured for multiple Operators, the RAN should provide an accounting function which can
determine the resource usage of respective Operator.

7.17.3 Impact on the baseline CN Architecture

Editors Note: It is FFS whether there is any particular impact.

7.17.4 Impact on the baseline RAN Architecture

Editors Note: It is FFS whether there is any particular impact.

7.17.5 Impact on terminals used in the existing architecture

Editors Note: It is FFS whether there is any particular terminal impact.

7.18 Key Issue Intra-LTE-Access Mobility Support for Ues in

LTE_ACTIVE
7.18.1 Description of Key Issue Intra-LTE-Access Mobility Support for Ues in
LTE_ACTIVE
The key issue Intra-Access Mobility Handling of Ues in LTE_ACTIVE handles all necessary steps already known from
state of the art relocation/handover procedures, like processes that precedes the final HO decision on the source
network, preparation of resources on the target network side, pushing the UE to the new radio resources and finally
releasing resources on the (old) source network side. It contains mechanisms to transfer context data between evolved
nodes, and to update node relations on C- and U-plane.

7.18.2 Solution for key issue Intra-LTE-Access Mobility Support for Ues in
LTE_ACTIVE
LTE_ACTIVE state mobility is still controlled by the LTE-RAN functions currently serving the UE (source LTE-RAN
functions) which trigger the HO process after it has made a definite decision to serve the user by neighbour ("target")
LTE-RAN functions.
Means need to be provided to protect against data loss during the handover process.
After the LTERAN functions on the target side have received the final confirmation from the UE on the completion of
the HO process, the release of resources on the (old) source side is triggered.

7.18.2.1
NOTE:

C-plane handling
The MME/UPE is shown as being co-located in one functional entity for simplicity reasons; however this
is FFS.

3GPP

Release 8

94

3GPP TR 23.882 V8.0.0 (2008-09)

Figure 7.18-1: Information flow for Intra-LTE-Access Mobility Support

1) The UE context within the Source RRC contains information regarding roaming restrictions which where
provided either at connection establishment or at the last TA update.
2) The responsible "source LTE-RAN functions" configure the UE measurement procedures according to the area
restriction information.
3) Based on measurement results, probably assisted by additional RRM specific information the source side decides
to handover the UE to a cell controlled by the "Target LTE RAN functions"
4) The target side is requested to prepare the HO on the target side.
5) Resources at the target side are reserved / prepared.
6) The preparation phase has ended successfully.
A) from step 7) until 10) means to avoid data loss during HO are provided and detailed in TR 25.912 [18]
7) The "Source LTE-RAN" functions command the UE to the target side.
8) The UE starts to gain synchronisation on the target side.
9) Once the UE has successfully accessed the cell, the UE sends an indication to the "target LTE-RAN functions" to
indicate that the handover is completed.
10)The HO Complete message is sent to indicate the MME/UPE that the UE is located at the target cell. This
indication should be used to perform the user plane switch.
11) The release of resources on the source side is triggered directly by the target side.
NOTE:

t is ffs whether the release of the resources on the source side is done with MME/UPE involvement or by
the "target LTE-RAN functions" directly.

3GPP

Release 8

95

3GPP TR 23.882 V8.0.0 (2008-09)

12)If the new cell is member of a new Tracking Area, the UE needs to register with the MME/UPE which in turn
updates the area restriction information on the target side.

7.18.2.2

User plane handling

Editor's note: This is for further study, but see document R3-060401 for the current status.

7.18.3 Impact on the baseline CN Architecture

Editors Note: It is FFS whether there is any particular impact

7.18.4 Impact on the baseline RAN Architecture

Editors Note: It is FFS whether there is any particular impact

7.18.5 Impact on terminals used in the existing architecture

Editors Note: It is FFS whether there is any particular terminal impact.

7.19 Key Issue Service continuity at domain and RAT change for
TS 11, TS 12, and equivalent PS service
The intent of this clause is to study solutions for service continuity at domain and RAT change for TS 11, TS
12, and equivalent PS service (see 3GPP TS 22.278 [34] for detailed requirements). The initial focus is
put on voice call continuity, however the study on continuity of other services (e.g. video) shall not be
precluded.

7.19.1 Voice call continuity between IMS over SAE/LTE access and CS
domain
7.19.1.1

Description of key issue Voice call continuity between IMS over SAE/LTE
access and CS domain

The intent of this clause is to study alternative solutions for Voice call continuity between IMS over
SAE/LTE access and CS domain. The solutions studied here shall allow coexistence with VCC (as specified
in 3GPP TS 23.206 [29]). Solutions compatible with VCC Rel 7 shall be studied .
It is expected that some of the alternative solutions may be applied in pre-SAE/LTE context i.e. for Voice call
continuity between IMS over 2G/3G PS access and CS domain. Any such applicability to pre-SAE/LTE
context should be highlighted when incorporated in here.
In the following desirable characteristics for proposed solutions are listed:
-

The solution shall not require UE and/or RAT capability to simultaneously signal on two different RATs.

Impact on service quality, e.g. QoS, interruption times should be minimized

RAT/domain selection/change should be under network control.

RAT/domain selection/change may be restricted to some access systems and some subscribers, depending on
operators' policies.

It shall be possible for operators to restrict and disable the handover of voice calls across different access
domains even if voice call services are available separately from those domains.

Editor's Note: the triggering for domain change, either UE initiated or network initiated, is FFS.

3GPP

Release 8

96

3GPP TR 23.882 V8.0.0 (2008-09)

In roaming cases, the Visited PLMN should control the RAT/domain selection/change while taking into account
any related HPLMN policies

Inter-domain handover in the VPLMN should be performed without significant amount of signalling to the
HPLMN.

Impact on legacy RAT is highly undesirable

Impact on legacy CS CN is undesirable

7.19.1.2

General aspects

It is understood that the service continuity aspects described in this clause are linked to radio aspects peculiar
to single radio devices e.g. handovers across 3GPP radio technologies.
Different solutions may be suited depending on the scenarios (e.g. which combination of domain transfer and
radio handover), on the deployment assumptions (e.g. PS Handover and VoIP optimisations supported in the
2G domain or not) and on the intended use cases (e.g. LTE used as an overlay in areas where both 2G and 3G
are present, or as a replacement for either of them)
The following table summarises the number of scenarios potentially to be considered for the continuity
between IMS and CS
Table 7.19.1,2-1 Continuity scenarios from IMS towards CS
Scenario

Source or
Target
cell
(PS)

LTE

Target
or
Source
cell
(CS)
3G

LTE

3G

3G: VoIP optimisations not supported

LTE

2G

LTE

2G

LTE

2G

2G: VoIP optimisations supported; PS Handover

supported
2G: VoIP optimisations not supported; PS Handover
supported
2G: VoIP optimisations not supported; PS Handover not
supported

3G

3G

3G

2G

3G

2G

3G

2G

10

2G

2G

NOTE:
NOTE:

Assumptions on deployment

Solutions

3G: VoIP optimisations supported

2G: VoIP optimisations supported; PS Handover

supported
2G: VoIP optimisations not supported; PS Handover
supported
2G: VoIP optimisations not supported; PS Handover not
supported

Scenarios 6,7,8,9 assume VoIP optimisations are supported in 3G

Scenarios 10 assumes VoIP optimisations are supported in 2G

Editors Note: The Solutions column is FFS

7.19.1.3
7.19.1.3.1

Alternative solution A Combinational VCC

Description

Combinational VCC (C-VCC) is a combination of radio handover (HO) and VCC domain transfer (DT; as defined in
3GPP TS 23.206 [29]).
The continuity between IMS/LTE and 3G CS is enabled by going through 3G PS as an intermediate step i.e.
-

LTE =(PS HO)=> via 3G PS =(DT)=> 3G CS, and

3GPP

Release 8

97

3GPP TR 23.882 V8.0.0 (2008-09)

3G CS =(DT)=> via 3G PS =(PS HO)=> LTE.

A pre-requisite for C-VCC operation in this scenario is that the 3G cell supports both CS voice bearers and PS voice
bearers.
The continuity between IMS/LTE and 2G CS is enabled by going through 2G PS as an intermediate step i.e.
-

LTE =(PS HO)=> via 2G PS =(DT)=> 2G CS, and

2G CS =(DT)=> via 2G PS =(PS HO)=> LTE.

A pre-requisite for C-VCC operation in this scenario is that the 2G cell supports both CS voice bearers and PS voice
bearers. In addition, the terminal and the 2G RAN must support the PS handover procedure and the DTM capability.
The GPRS access of the 2G cell is used like a changing room where the voice call/session can quickly change its
nature (from CS to IMS or vice versa), but without keeping the VoIP session in GPRS longer than necessary to perform
this transformation.
The solution is applicable in pre-SAE/LTE context, including transitions to/from 3G PS-only cells. It requires support
for PS Handover and DTM on the 2G side.

7.19.1.3.2

Impact on the baseline CN Architecture

7.19.1.3.3

Impact on the baseline RAN Architecture

7.19.1.3.4

Impact on terminals used in the existing architecture

7.19.1.4
7.19.1.4.1

Alternative solution B
Description

This solution enables the continuity between IMS/LTE and 3G CS by going through 3G PS as an intermediate step (i.e.
the same as in clause 7.19.1.3). There is no provision for support of continuity between IMS/LTE and 2G CS directly
without going through 3G as an intermediate step. This would be achieved as follows:
-

LTE =(PS HO)=> via 3G PS =(DT)=> via 3G CS =(CS HO)=> 2G CS, and

2G CS =(CS HO)=> via 3G CS =(DT)=> via 3G PS =(PS HO)=> LTE.

Such a simplification is based on the assumption that LTE will be deployed in islands of high user density first and 3G
coverage in these areas is well developed and in any case 3G with VoIP capability exists as a backup for LTE. It is
assumed that wherever there is 3G coverage, GSM coverage is also available.
The following picture illustrates graphically the concept.

3GPP

Release 8

98

3GPP TR 23.882 V8.0.0 (2008-09)

GSM coverage
Patchy UMTS coverage
VCC within UIMTS

UMTS coverage with VoIP

support

LTE coverage
PS HO LTE-UMTS

LTE coverage

CS HO GSM-UMTS

Figure 7.19.1.4.1-1: Underlying assumptions for Alternative solution B

In regions of the network where 3G VoIP coverage can be patchy and backed up by GSM, then the network must force
the voice call to be supported using 3G CS. Methods to command the UE to perform VCC domain transfer could be
various. For instance, the 3G NodeBs in areas of patchy 3G coverage may be configured to transmit on the broadcast
channel information that triggers the UE to move voice calls from 3G PS to 3G CS. Also, in areas of non-patchy 3G
coverage, the 3G network could transmit information on the broadcast channel that permits the UE to stay on 3G PS for
voice calls support.
When a user starts a call on 2G CS or 3G CS, or the call is handled by CS domain at some point, the transition to 3G
VoIP and then LTE should be driven by policy. The UE could decide the transition to 3G PS when the network provides
positive information that VoIP is supported on 3G PS. The transition to LTE would then be governed by network
controlled HO policies between 3G PS and LTE.
The solution is applicable in pre-SAE/LTE context provided that the 3G cells in the border areas support access to both
CS and PS domain.

7.19.1.4.2

Impact on the baseline CN Architecture

7.19.1.4.3

Impact on the baseline RAN Architecture

7.19.1.4.4

Impact on terminals used in the existing architecture

7.19.1.5
7.19.1.5.1

Alternative solution C CreDT

Description

Call Re-establishment on Domain Transfer (CreDT) is a "break-before-make" solution in which the remote party is
"parked" while the UE is in the source radio, and is then "un-parked" once the UE moves to the target radio. The VCC
application on the network side anchors the bearer path of the remote party during the execution of CreDT. The user is

3GPP

Release 8

99

3GPP TR 23.882 V8.0.0 (2008-09)

notified via appropriate MMI of the ongoing CreDT procedure, whereas comfort tone or recorded announcement is
provided to the remote party during CreDT.
The CreDT procedure initiation can be signalled explicitly by the UE (refer to Annex E in 3GPP TR 23.806 [30] for
detailed call flows) or implicitly deduced by the VCC application upon radio link failure (the latter is referred to here as
"Implicit CreDT").
The solution is applicable in pre-SAE/LTE context, including transitions to/from 3G PS-only cells. It does not require
support of PS Handover or DTM on the 2G side.

7.19.1.5.2

Impact on the baseline CN Architecture

7.19.1.5.3

Impact on the baseline RAN Architecture

7.19.1.5.4

Impact on terminals used in the existing architecture

7.19.1.6
7.19.1.6.1

Alternative solution D - Inter-MSC Handover solution

Description

This alternative solution is based on the inter-MSC Handover procedure. The SAE/LTE Evolved Packet Core (EPC)
emulates an "anchor MSC" functionality and exhibits the E interface towards the neighbouring MSCs. The solution
works for voice calls which have been initiated in IMS/LTE and allows for subsequent transitions from 2G CS domain
back to IMS/LTE.
While in IMS/LTE mode, the CSCFs detect the potential candidate sessions for VCC transition to the CS domain and
propagate this information via the PCRF and the EPC to the evolved RAN. This information allows the evolved RAN to
identify the Ues for which to initiate measurements that may eventually trigger the inter-MSC HO procedure. At the end
of the inter-MSC procedure, the P-CSCF may have to register with the IMS on UE's behalf in case the UE has no DTM
capability. It is FFS how call control signalling is handled after handover (e.g. relay of call control signalling in
BSSMAP messages).
Similar logic may be used for subsequent transitions from 2G CS to IMS/LTE, but it requires further investigation.
The services remain anchored in the IMS after the initial and subsequent transitions to/from the CS domain.
This solution may also be applicable for continuity between 3G PS and 2G CS, but it requires further investigation.

7.19.1.6.2

Impact on the baseline CN Architecture

7.19.1.6.3

Impact on the baseline RAN Architecture

7.19.1.6.4

Impact on terminals used in the existing architecture

3GPP

Release 8

7.19.1.6a
7.19.1.6a.1

100

3GPP TR 23.882 V8.0.0 (2008-09)

Alternative D-1 Inter-MSC Handover with anchoring at the VCC Application

Description

This alternative proposes a solution utilizing the inter-MSC handover mechanism and the VCC Rel-7 Voice Call
Continuity Application to enable the handover call between CS domain and LTE/SAE access. Re-use and enhancement
of Release 7 VCC, where applicable, will be considered. To realize this solution, the following principles apply:
1. All services are centralised in IMS
2. Session is anchored in the VCC Application
3. SIP session runs in the UE when using LTE access
4. When using PS access, SIP session runs in the UE with CS Proxy presenting it to IMS

7.19.1.6a.2

LTE => 2G CS voice continuity with CS Proxy reference architecture

The following figure shows the concept of CS proxy to be use for LTE to 2G CS voice call handover.

Figure 7.19.1.6a-1: LTE to 2G CS HO with CS Proxy

3GPP

Release 8

101

3GPP TR 23.882 V8.0.0 (2008-09)

Figure 7.19.1.6a-2:LTE => 2G CS voice continuity call flow

1. There is an ongoing IMS Voice session establish in the IMS where the session is anchored in the VCC
Application. In step 1a, the target measurement report is sent to Source eNB. The VCC Application is informed
by the S-CSCF about the used CK/IK (cipher and integrity key) in the 3rd party register. Note, for handovers to
2G RAN, the AKA keys shall be converted to SIM compatible keys according to the procedures specified in TS
33.102 [xx].
2. Source eNB processes the measurement report and determines a handover is needed. In step 2a the Source eNB
sends the Handover Required Message to MME containing the required information such as source to target
information.
3. The MME determines the target MSC based on the information received in the Handover Required message.
(How the MME learns the CS Proxy information that will be needed in the handover, e.g. CS Proxy DN, CS
Proxy IP address, is not specified here. The information could be provisioned or the MME could use some CS
Proxy local discovery mechanism).
4. The MME sends the Handover Request message to the UE with information such as source to target information,
the target MSC, and the CS Proxy Information.
5. The UE generates and sends SIP REFER message with target information to VCC Application. The SIP REFER
is sent within the currently active voice call dialogue.
6. The VCC Application returns SIP 202 Accept and begins the domain transfer to the CS domain.
7. The VCC Application initiates MAP Prepared Handover Message to the CS Proxy. In step 7b the CS Proxy
forwards the MAP Prepared Handover Message to the target MSC.
8. Standard GSM Handover Request and Acknowledge messages flow between target MSC and target BSS

3GPP

Release 8

102

3GPP TR 23.882 V8.0.0 (2008-09)

9. Target MSC returns Handover Number in the Prepare Handover Response message to allow establishment of a
circuit connection between the target MSC and MGW. In step 9b, the CS Proxy forwards the MAP Prepare
Handover Response message to the VCC Application.
10. Step 10 Step 20 is the establishment of the circuit connection from the UE through the MSC to the MGW
Upon receiving message in step 13, the UE plays a tone to the subscriber to give an indication of radio
technology change.
11. Upon completion of establishing circuit connection, the LTE resource is released.
12. VCC Application sends re-INVITE to MGCF to switch the media path from the UE to the target MSC.
Editor's Note: Optimization with MWG in the visited network is FFS.
Editor's Note: Optimization of number of message is FFS.

7.19.1.6a.2a

Optimized LTE => 2G CS voice continuity call flow

Figure 7.19.1.6a-2a below presents an optimized signalling flow for LTE to 2G CS domain call transfer, which exhibits
several optimizations as compared to the signalling flow in the previous sub-clause. For example, in the optimized
flows a Handover Required message is sent by CS Proxy to the VCC Application, instead of sending a SIP REFER
from the UE to the VCC Application to indicate that handover to CS domain is required. Also, in the optimized flows,
the UE receives the Handover Command within an Access Stratum message (see step 12c) via the eNB. So, the
Handover Command is not encapsulated within a SIP NOTIFY message as is done in the previous sub-clause. More
improvements are further discussed below.

Figure 7.19.1.6a-2a: LTE => 2G CS voice continuity call flow

1. The UE is attached to the EPC and has an ongoing IMS Voice session establish in the IMS where the session is
anchored in the VCC Application. The VCC Application is informed by the S-CSCF about the MSISDN, tel
URI and other PUIs in the UEs implicit registration set as a result of a 3rd party registration procedure. During

3GPP

Release 8

103

3GPP TR 23.882 V8.0.0 (2008-09)

the session setup the P-CSCF triggers the dedicated bearer establishment during which policy rules are
transferred from the PCRF to the PDN GW and the source eNB. Such policy rules allow eNB to determine if the
originating session is a candidate for VCC transfer to the 2G CS domain. VCC-only CS security context
key(s) are generated in both the UE and MME from the existing PS domain security context key(s).
2. When the eNB receives the candidate for VCC indication from the policy rules, the eNB can include candidate
2G CS cells into the neighbour cell lists which it sends to the UE.
3. Based on the received measurement reports and the policy rules received in step 1, the source eNB decides to
initiate a handover to the 2G CS domain. For this purpose it sends a Handover Required message to the MME.
The message informs the MME about the target 2G cell ID and indicates that this is a handover to the 2G CS
domain.
4. The MME uses the information provided by the eNB to select the target MSC based on configuration data stored
in the MME. It also determines both the MSISDN and home IMS VCC Application DN associated with the UE
through subscriber data it received for the UE during Network Attachment. Either provisioning or local
discovery mechanisms can be used to allow the MME to acquire the IP address of the CS Proxy.
5. The MME passes the information obtained in step 4 to the CS Proxy. The CS Proxy, in turn, has the interface that
is used to format and forward the required handover information to the UEs VCC Application via a 2G CS
Handover Required message. When the VCC Application receives the 2G CS Handover Required message, it
takes on the role of an anchor MSC-server in the basic handover procedure requiring a circuit connection
between MSC-A and MSC-B (see TS 23.009).
6. The VCC Application uses the MSISDN to help correlate the 2G CS Handover Required message with the
IMS Voice session it is anchoring for the UE. The VCC Application sends a MAP Prepare Handover request
message to the target CS Proxy. In step 6b the CS Proxy forwards the MAP Prepared Handover Message to the
target MSC.
7. Standard Handover Request and Acknowledge messages flow between target MSC and target BSS.
8. Target MSC returns Handover Number in the Prepare Handover Response message to allow establishment of a
circuit connection between the target MSC and MGW. In step 8b, the CS Proxy forwards the MAP Prepare
Handover Response message to the VCC Application.
9. The VCC Application initiates a new call (with a SIP INVITE) towards the 2G CS domain by using the
Handover Number provided by the target MSC. This call is required in order to establish a user plane between
the IMS MGCF/MGW and the UE through the 2G CS domain.
10. The circuit connection between the target MSC and the IMS MGCF/MGW is established with the exchange of
the ISUP IAM and ACM signalling messages.
11. The MGCF responds to the VCC Application with a SIP Progress message.
12. A Handover Command is sent from the VCC Application to the CS Proxy which includes the HO_CMD
received in step 9. The Handover Command is forwarded to the MME and on to the source eNodeB in step 12b.
The message is sent to the UE in step 12c instructing the UE to move from the PS domain to the 2G CS domain
by retuning to the target radio network and using the correct Cipher Key(s).
13. The UE accesses the target cell using normal 2G access signalling. The target BSS detects the presence of the
UE and sends a HO Detect message to the target MSC.
14. In response to the HO Detect message, the MSC sends a MAP Process Access Signalling request message to the
CS Proxy including the HO Detect message received from the BSS. The CS Proxy forwards this message to the
VCC Application.
15. When the UE is successfully communicating with the target BSS a Handover Complete message will be sent by
the UE to the target BSS. The target BSS will then send a Handover Complete message to the target MSC.
16. In response to the HO Complete command, the MSC sends a MAP Send End Signal request message to the CS
Proxy including the HO Complete message received from the BSS. The CS Proxy forwards this message to the
VCC Application.
17. When the HO Detect/Complete is received, the MSC sends an ISUP Answer message to the IMS MGCF/MGW
to complete the bearer path between the MSC and the MGW.

3GPP

Release 8

104

3GPP TR 23.882 V8.0.0 (2008-09)

18. The MGCF sends a SIP 200 OK message to the VCC Application. This establishes a new access leg between the
VCC Application and the 2G CS domain with the appropriate user plane resources in place between the IMS
MGW and the MSC MGW.
19. The VCC Application sends a SIP re-INVITE message to the MGCF/MGW serving the CS/PSTN remote party.
The MGCF instructs the MGW to update a termination toward the access leg of the 2G CS domain established in
step 19, and to release the termination for the access leg of the SAE/LTE domain.
20. The MGCF sends a SIP 200 OK message to the VCC Application signifying the completion of the session
modification procedure.
21. The VCC Application initiates the release of the source access leg in the SAE/LTE domain by sending a suitable
message to the MME.

7.19.1.6a.3

2G CS => LTE voice continuity call flow

Figure 7.19.1.6a-3: Overview CS to LTE Handover Call Flow

Figure 7.19.1.6a-3 provides an overview of the CS to LTE handover procedure. The procedure is broken into 2 phases.
The first phase is a normal handover as seen from the perspective of the source MSC. This results in a media path that
includes an IP to MSC to IP loop that can be eliminated in the second phase. The key for eliminating the loop is that the
VCC Application has anchored the signaling on the original call (labeled Call 1a and Call 1b in the figure) and the
handover call (labeled Call 2a and Call 2b in the figure). The VCC Application recognizes that both calls are associated
with the same UE and that the second call is a handover call. Knowing that, the VCC Application links the UE to the
original call port directly, connecting the Call 1a leg to the Call 2b leg and eliminating the Call 1b to Call 2a legs.

3GPP

Release 8

105

3GPP TR 23.882 V8.0.0 (2008-09)

Figure 7.19.1.6a-4: Basic CS to LTE Handover Call Flow

The initial state is that the UE is in a PSTN call while in the CS domain. The VCC Application is anchoring the call
using the procedures specified in 3GPP TS 23.206 [29].
1. The UE performs normal GSM measurement reporting as specified in [GSM TS], including eNB measurements.
2. The BSS determines that a handover is required and sends a Handover Required message to the Source MSC.
3. Based on information in the Handover Required message, the Source MSC determines that the CS Proxy is the
target MSC and sends a MAP Prepare Handover Required message to the CS Proxy. The CS Proxy uses the
IMSI to do a lookup in the HSS to determine which VCC Application is supporting the UE.
4. The CS Proxy sends the Prepare Handover Required message to the VCC Application
5. The VCC Application creates a Handover Number (HO#) and a Reference Number (Ref#) that will be used to
direct the handover calls to the VCC Application. In IMS terms, these are PSIs that refer to the VCC Application
Server. The Prepare Handover Response is sent from the VCC Application via the CS Proxy to the Source MSC.
6. Using normal GSM handover procedures, the Source MSC sends an ISUP IAM to the HO#. The IAM is routed
to an MGCF in the VCC Application domain.
7. The MGCF creates a SIP INVITE that gets routed to the VCC Application
8. The VCC Application sends back a SIP progress response
9. The MGCF converts this to an ISUP ACM that gets sent to the Source MSC
10. When the Source MSC gets the ACM, it sends a Handover Command that gets forwarded to the UE.
11. The UE uses this as a signal to commence handover to LTE and comes up on the LTE network following the
procedures defined in [TS23.401].

3GPP

Release 8

106

3GPP TR 23.882 V8.0.0 (2008-09)

12. After coming up on the LTE network, the UE sends a SIP INVITE to the Ref# received in the handover
command. The INVITE gets routed to the VCC Application.
13. The VCC Application completes the call setup in the IMS domain and sends 200 OK responses to both the UE
and the MGCF to link the UE to the appropriate port on the MGW.
14. The MGCF sends an ISUP ANM to the Source MSC indicating call setup is complete.
15. The Source MSC releases the 2G radio resources, but remains in the call path as the 2G anchor point.

EMBED PowerPoint.Slide.8

Figure 7.19.1.6a-5: Bearer and Signaling Path Optimization for CS to LTE Handover Call Flow
Since the VCC Application anchored the original call to the UE in the CS domain, it is now in the path for both call legs
to the Source MSC. Bearer and signaling path optimization can occur that removes the Source MSC from the call and
just leaves the VCC Application anchor function. The VCC Application is acting as a B2B UA for the original CS
domain call and again for the handover call from the CS domain. The VCC Application now merges the two B2B UA
appearances into 1 B2B UA and removes the Source MSC from the calls.
16. The VCC Application sends a SIP re-INVITE for the initial call from the MGCF. This time it includes the UEs
SDP as the target and not a loop back port in the MGW.
17. The MGCF sends messages to the MGW to disconnect the path to the CIC that went to the MSC and connect the
CIC from the PSTN to the UEs SDP. When the MGCF completes configuring the MGW, it replies with the
MGW information in the 200 OK response to the VCC Application
18. The VCC Application sends a SIP BYE to the MGCF for the call to the CS domain.
19. The MGCF converts this to an ISUP release that gets forwarded to the MSC.

3GPP

Release 8

107

3GPP TR 23.882 V8.0.0 (2008-09)

20. In parallel with 18, the VCC Application sends a SIP BYE to the MGCF for the call from the Source MSC for
the handover.
21. The MGCF converts this to an ISUP release that gets forwarded to the MSC.
22. The VCC Application sends a re-INVITE to the UE that points the UE to the MGW port for the initial PSTN call
instead of the MGW port for the handover call, using the information received in the 200 OK from the MGCF.
Normal SIP call signaling then proceeds to transfer the call legs and the Source MSC uses normal procedures to release
all of the 2G resources. The result is a call between the UE and the PSTN solely via IMS.
Similar logic applies if the other end of the original call was an IMS UE and not a PSTN destination.

7.19.1.6a.3a

Optimized 2G CS => E-UTRAN voice continuity call flow

Figure 7.19.1.6a-5a below presents an optimized signalling flow for 2G CS domain to E-UTRAN call transfer, which
exhibits several optimizations as compared to the signalling flow in the previous sub-clause. These optimizations are
further discussed below.
NOTE:

The figure below assumes that the UE remains attached to EPC while using the 2G CS domain and that it
can re-use the IP address that was received during EPC attachment.

Figure 7.19.1.6a-5a: 2G CS => LTE voice continuity call flow

The initial state is that the UE is in a PSTN call while in the CS domain. The VCC Application Server is anchoring the
call using the procedures specified in TS 23.206. The 2G network has all configured neighbouring cell information
such as E-UTRAN cells, UTRAN cells and 2G BS cells.
1.

Neighbour cell measurements are performed by the UE and forwarded to the BSS. The BSS includes candidate
eNodeB cells into the neighbour cell lists which it sends to the UE.

3GPP

Release 8

108

3GPP TR 23.882 V8.0.0 (2008-09)

2.

Based on the received measurement reports and associated policy rules, the BSS decides to initiate a handover to
the E-UTRAN domain. For this purpose it sends a Handover Required message to the MSC. The message
informs the MSC about the target eNodeB cell ID.

3.

The source MSC uses the information provided by the BSS along with configuration data stored in the MSC to
determine the CS proxy that should serve as the target MSC for the MAP Prepare Handover Request message.

4a. The MSC treats the handover as an "Inter-MSC" procedure so it sends a MAP Prepare Handover request message
to the target CS Proxy. The MAP Prepare Handover message shall carry the target eNodeB cell ID along with the
IMSI and MSISDN of the UE.
4b. The CS Proxy uses the IMSI to do a lookup in the HSS to determine which VCC Application is supporting the UE.
The CS Proxy is configured to allow it to determine the target MME associated with the target eNodeB cell ID
received in the MAP Prepare Handover request message.
5.

The CS Proxy sends the MAP Prepare Handover request message to the VCC Application. When the VCC
Application receives the MAP Prepare Handover request message, it takes on the role of a target MSC-server in the
"basic handover procedure requiring a circuit connection between MSC-A and MSC-B" (see TS 23.009).

6.

The VCC Application uses the MSISDN to help correlate the MAP Prepare Handover request message with the
IMS voice session it is anchoring for the UE. Since this is a handover to the E-UTRAN domain, the VCC
Application sends a Handover Preparation Request message to the target CS Proxy that corresponds to the inter
access system handover messaging between UTRAN/GERAN and EPS/E-UTRAN being defined in this TR
23.882.

7.

The CS forwards the HO Request message to the target MME, which sends the message to the target eNodeB. The
eNodeB ciphering and integrity protection keys are sent from the MME to the target eNodeB.

8.

The target eNodeB establishes bearer resources, including radio resources, for the UE. It then returns a HO Request
Ack message to the MME confirming the handover preparation. The HO Request Ack message is then forwarded to
the CS Proxy.

9.

The CS Proxy sends a Handover Preparation Request Confirm message to the VCC Application.

10. The VCC sends a MAP Prepare Handover response message to the Source MSC using the CS Proxy to forward this
message.
11. The Source MSC sends a HO Command message to the BSS which forwards it to the UE. This command requests
the UE to move from the 2G CS domain to the E-UTRAN domain by retuning to the target radio network.
12. The radio bearer is established between the UE and the target eNodeB.
13. The eNodeB informs the MME about handover completion.
14. The MME forwards the Handover Complete message to the CS Proxy, which sends the message to the VCC
Application.
15. When Handover Complete is received, the VCC Application sends a SIP INVITE message to the UE to begin reestablishing an access leg over the SAE/LTE domain.
16. The UE responds to the SIP INVITE message with a SIP 200 OK.
17. The VCC Application returns a SIP ACK message to complete the setup of the SIP session on the target access leg
in the EPS/E-UTRAN domain.
18. The VCC Application sends a SIP re-INVITE message to the MGCF/MGW serving the CS/PSTN remote party.
The MGCF instructs the MGW to update a termination toward the access leg of the SAE/LTE domain established
in step 17, and to release the termination for the access leg of the 2G CS domain.
19. The MGCF sends a SIP 200 OK message to the VCC Application. This establishes a new access leg between the
VCC Application and the SAE/LTE domain with the appropriate user plane resources in place between the IMS
MGW and the UE.
20. The VCC Application sends a MAP Send End Signal response message to the MSC using the CS Proxy to forward
this message. This releases the MAP resources in the MSC.

3GPP

Release 8

109

3GPP TR 23.882 V8.0.0 (2008-09)

21. When the MAP Send End Signal response is received, the MSC will send a CLR Command message to the BSS to
release the old radio resources in the BSS.
22. The VCC Application sends a SIP BYE message to the IMS MGCF/MGW terminating the 2G CS domain
connection to the MSC.
23. The IMS MGCF sends an ISUP Release message to release the circuit connection to the MSC.

7.19.1.6b
7.19.1.6b.1

Alternative D-2 LTE-VMSC Anchor Solution

Description of LTE to UMTS/GERAN CS handover

This alternative is based on Alternative D where the Evolved Packet Core (EPC) emulates an "anchor MSC"
functionality and exhibits the E interface towards the neighbouring MSCs.
A new CS-Proxy entity is introduced as a VMSC interfaced to MME on one side and to CS core on the other side. It
corresponds to the MSC entity that serves the LTE user and acts as a Anchor MSC function, forwarding the handover
required by the LTE towards the CS target network. This new CS-Proxy entity has some specific behaviour compared to
a legacy MSC in order that existing MSCs do not need to be modified.
In the same way as in UMTS, the UE performs and reports measurements of neighbour cells to the eNB , which is able
to decide a handover to a CS target cell. When the HO decision is taken, the eNB sends a Handover Request towards the
CS-Proxy, which initiates a standard inter-MSC Hand-Over procedure.
It also requests the UE to initiate a VCC Domain Transfer to CS by initiating a Setup towards the VDN (VCC Domain
Transfer Number) the UE knows, as specified in 3GPP TS 23.206. The Setup message (new message) is tunnelled
through the LTE network to the CS-Proxy. Unlike alternative F, the SIP session is not relocated from the UE to the
network.
The CS-Proxy waits for completion of the handover preparation phase, i.e. network resources reserved towards the
target network, and for the Setup (VDN) message sent by the UE. The CS-Proxy (acting as a VMSC and a MGCF)
routes the call signalling towards the user's VCC AS in the home network.
Upon receiving Re-Invite message, the UE-B replies with 200 OK, disconnects its user plane from the previous path
and connects it to the new path to the MGW associated with the CS-Proxy.
As the path with UE-B is established, the CS-Proxy can now request the UE-A to perform Handover Execution phase
i.e. to switch its radio to the target cell. CS-Proxy connects UE-B path to MSC-B.
The target NodeB/BTS detects the UE-A and sends Handover Detect to the RNC that will relay it to MSC-B. MSC-B
connects the UE-A path to the UE-B path. At this point, user plane is end-to-end connected. The UE-A sends Handover
Complete message to the RNC/BSC that relays it to the MSC-B. MSC-B relays it to the CS-Proxy in order to release
serving network resources in SAE network and eNB.
A possible alternative, called VDN-plus, to avoid forcing the UE to participate in the Domain Transfer, is to have the
VDN in the HSS subscriber profile. The VDN is provided at Attach to the MME, which passes it to the CS-Proxy at
first relocation message. Alternatively, VDN may be communicated to the MME via the PCRF, PGW and SGW, or
VDN may be derived from the MSISDN by the CS-Proxy or retrieved via CAMEL.
MME and CS-Proxy are functions located in the VPLMN and can be collocated. In a roaming scenario, the user plane
path is optimized i.e. it does not need to go through the HPLMN.

7.19.1.6b.2

Information flows

Handover from LTE to UMTS/GERAN CS is depicted in the following flow charts. The flow charts represent UMTS
entities and messages, but it also applies to GERAN entities and messages.

3GPP

Release 8

UE A

110

eNB

MME

CS-Proxy

3GPP TR 23.882 V8.0.0 (2008-09)

NodeB

MGW

RNC

MSC-B

CSCF

VCC AS

1: Measurement Report
2: Relocation Required
3: Fwd Relocation Required

4: MAP Prepare HO Request

5: Reloc Request
RAN Resources
reservation
6: Reloc Request Ack
7: MAP Prepare HO Response
8a: IAM
8b: ACM
8c: Connect
User Plane

Figure 7.19.1.6b-1: Handover from LTE to UMTS/GERAN CS (1 st part)

UE A

eNB

MME

CS-Proxy

NodeB

MGW

RNC

MSC-B

CSCF

VCC AS

UE B

Note that step a may occur any time after step 3 and steps
a, b and c run asynchronously with steps 4,5,6, 7 and 8.
a: CS HO Request
b: Setup (VDN)
c: Setup (VDN)
d: Reserve resources

e: INVITE (DTF PSI)

f: INVITE (DTF PSI)

g: RE-INVITE
h: 200OK

i: 200OK

Flow
broken

9: Connect User
Plane
10: Reloc command
11: Reloc command
12: HO command
UE switches its radio
Radio Synchronization under NodeB

13: Reloc Detect

13: Reloc Detect
Connect
user plane

14: HO complete

Flow
resumed

14: Reloc Complete

15: MAP proc access sig req (HO Detect)
16: MAP send end sig req (HO Complete)
Release Resources in SAE-LTE

Figure 7.19.1.6b-2: Handover from LTE to UMTS/GERAN CS (2nd part)

1. UE-A performs measurements and sends measurement reports to the eNB.

3GPP

Release 8

111

3GPP TR 23.882 V8.0.0 (2008-09)

2. eNB determines that a handover to UMTS or GERAN CS domain should be performed. It sends a
Relocation/Handover Required message to the MME indicating the target cell and that it is a handover to CS
domain.
3. The MME selects a CS-Proxy in the same PLMN and forwards the Relocation/Handover Required to that CSProxy node. In the "VDN-plus" alternative, the MME gets the VDN from the HSS and forwards this information
to the CS-Proxy in the Relocation/Handover Required message.
4. As the CS-Proxy node is in the same PLMN, it is configured with necessary tables enabling to determine MSC-B
and forward the handover request via MAP Prepare HO Request to MSC-B.
5. MSC-B sends Relocation/Handover Request to the target RNC.
6. The target UTRAN reserves the RAN resources and replies with Relocation/Handover Request Ack to MSC-B.
7. MSC-B sends MAP Prepare HO Response back to CS-Proxy. Necessary CS domain resources are then
established between CS-Proxy and MSC-B.
8. CS-Proxy establishes the path between MGW and MSC-B using ISUP IAM and ACM. In the "VDN-plus"
alternative, the steps a) to c) do not exist.
a. In parallel with steps 2 to 8, as soon as the eNB determined that a handover to UMTS or GERAN CS domain
should be performed, it sends a new "CS Handover Request" to the UE-A requesting the UE-A to initiate a
domain transfer.
b. UE-A sends the Setup (VDN) message to MME.
c. MME relays the Setup (VDN) message to CS-Proxy.
d. The CS-Proxy reserves resources at its MGW.
e. When CS-Proxy has received both Setup (VDN) from UE-A and MAP Prepare HO Response (or alternative
"VDN-plus", only MAP Prepare HO Response), the Domain Transfer is processed as described in clause
6.4.2.1 of TS 23.206 "Domain Transfer: IMS to CS". The DTF (PSI) DN is resolved using the VDN at the
CS-Proxy. The CS-Proxy routes the call by sending an INVITE (PSI) towards the user's VCC via the CSCF.
f. The UE-A CSCF forwards the requests to the VCC AS.
g. The VCC AS sends a RE-INVITE towards UE-B through its CSCF, that includes the user plane MGW
address.
h. UE-B replies with a 200 OK towards the CSCF, and connects its user plane to the indicated MGW user plane
address.
i. The VCC AS forwards the reply to the CS-Proxy.
9. The CS-Proxy requests the MGW to connect the user plane.
10. As the path with UE-B is established up to the MSC-B, the CS-Proxy can start the handover execution phase by
sending Relocation/Handover Command to the MME.
11. MME sends Relocation/Handover Command to eNB.
12. eNB sends Handover Command to UE-A.
13. UE-A already knows that the handover is directed to CS domain via the message CS HO Request send in step a),
therefore it knows it has to switch from VoIMS to VoCS. UE-A switches its radio to UMTS/GERAN target cell.
It may be detected by the NodeB/BTS. The NodeB/BTS sends Handover Detect to the RNC/BSC. The
RNC/BSC relays Handover Detect to MSC-B. MSC-B connects the UE-A path to the UE-B path. At this point,
user plane is end-to-end connected.
14. UE-A sends Handover Complete message to the RNC/BSC that relays it to the MSC-B.
15. MSC-B indicates Handover Detect via MAP PROC ACCESS SIG REQ (HO Detect) to CS-Proxy in order to
release serving network resources in SAE network and eNB. CS-Proxy releases all resources in eNB via MME.

3GPP

Release 8

112

3GPP TR 23.882 V8.0.0 (2008-09)

16. MSC-B indicates the Handover Complete via MAP SEND END SIG REQ (HO Complete) to CS-Proxy in order
to release serving network resources in SAE network and eNB. CS-Proxy releases all resources in eNB via
MME.
The following figure depicts the "VDN-plus" approach.

0. A VoIP Call is established using LTE and IMS; in IMS the call is anchored at the VCC-AS. At this point
a. The MME is aware of the VoIP bearer, such it can apply SR-VCC handling later at HO time.
b. Possibly, the VDN is communicated to the MME via the PCRF, PGW and SGW. Alternatively, the VDN can
be derived from the MSISDN by the CS-PROXY or retrieved via CAMEL, or downloaded from the HSS
during the Attach procedure.
1. The UE reports measurements to the eNB.
2. The eNB recognizes the need for a handover like for any other intra 3GPP handover. It reports the need for
handover to the MME, together with the information about the target RAN.
3. The MME communicates the need for handover to the CS-Proxy.
4. The CS-PROXY sends a Handover Preparation request to an MSC that serves the target RAN to setup the CS
radio bearers and CS call resources. This message contains information about the target RAN, IMSI, CS security
context key as derived from PS domain security context key. This is existing inter MSC handover functionality.
The MSC allocates the requested resources and confirms with a Handover Preparation Ack message to the CSPROXY.
5. The CS-PROXY, upon response of the handover request, establishes a CS call to the VDN (including bearer
reservation at CS-MGW).
NOTE:

No CS registration is needed because MME/CS-PROXY is a trusted entity.

6. The call to the VDN is established via the MGCF to the VCC-AS in the IMS. The existing Rel-7 VCC
mechanisms are applied, i.e. a re-INVITE is sent towards the B-party.
7. The MGCF confirms the CS call setup to the CS-PROXY.
8. The CS-PROXY confirms the handover preparation to the MME by sending a Handover Request Ack message.
The message includes a CS bearer description like used for CS handovers.
9. The information received with the Handover Request Ack is passed transparently from the MME to the eNB like
for any other intra 3GPP handover.
10. The eNB sends a handover command to the UE including the CS bearer description.

3GPP

Release 8

113

3GPP TR 23.882 V8.0.0 (2008-09)

11. The UE recognises the CS bearer description and switches from LTE radio to 2G/3G radio. It sends a handover
access message to the SRVCC enabled MSC. It switches voice media from the IP bearer to the established CS
bearer.
12. Handover Complete signalling between MME and CS-PROXY releases resources in MME.
NOTE:

No CS registration needed during call, only after the call.

7.19.1.6b.3

Subsequent handovers from 2G/3G back to IMS/LTE

Handover from UMTS/GERAN CS to LTE is depicted in the following flow charts. The flow charts represent UMTS
entities and messages, but it also applies to GERAN entities and messages.
UE A

eNB

MME

CS-Proxy

MGW

NodeB

RNC

MSC-B

CSCF

VCC AS

UE B

1: Measurement reports
Decision for
handover
2: Relocation Required
3: MAP-Prep-Sub-Handover req. (back to anchor point)
4: Fwd Prepare Reloc Request
5: Relocation Request
6: Relocation Request Ack
7: Fwd Prepare Reloc Request Ack
8: MAP-Prep-Sub-Handover resp
9: Relocation Command

Flow
broken

10: Reloc command

UE switches its radio
Radio Synchronization
under eNB
11: Reloc Detect
11: Reloc Detect
13: HO complete
13: Reloc Complete
12: MAP proc access sig req (HO Detect)
14: MAP send end sig req (HO Complete)

Flow
resumed

Release Resources in 2G-3G

Figure 7.19.1.6b-3: Subsequent handovers from 2G/3G back to IMS/LTE

1. UE-A performs measurements and sends measurement reports to the NodeB.
2. NodeB and RNC determine that a handover to IMS/LTE should be performed. It sends a Relocation/Handover
Required message to the MSC-B indicating the target cell.
3. As it is a inter-MSC handover, MSC-B sends MAP-Prep-Sub-Handover Request back to the anchor MSC per TS
23.009. There is no need for circuit connection.
4. CS-Proxy selects an MME that serves the eNB and sends Forward Prepare Relocation Request to that MME.
5. MME sends S1_Relocation_Request to the eNB.
6. eNB reserve appropriate resources and replies MME with S1_Relocation_Request_Ack.
7. MME sends Forward Prepare Relocation Response to CS-Proxy.
8. CS-Proxy sends MAP-Prep-Sub-Handover Response to MSC-B.
9. MSC-B sends RANAP Relocation Command to the source RNC.
10. The source RNC sends RRC Relocation Command to the UE.
11. The UE switches its radio to the E-UTRAN cell. Radio synchronization is detected by the eNB that sends
Relocation Detect to the MME, which forwards it to the CS-Proxy.

3GPP

Release 8

114

3GPP TR 23.882 V8.0.0 (2008-09)

12. CS-Proxy sends MAP proc access sig req (HO Detect) to MSC-B. MSC-B may connect the user plane.
13. CS-Proxy sends MAP send end sig req (HO Complete) to MSC-B. MSC-B connects the user plane if not done
yet at previous step.

7.19.1.6b.4

Advantages of the solution

There are several significant advantages to the above described solution:

-

There is no impact to the existing Core Network nodes as existing HO procedures are used and changes in
existing MSC behaviour is separated out in a new functional entity which can be a shared resource strategically
located in the network;

There is no impact to the existing RAN nodes as existing HO procedures are used (UMTS, GERAN);

There is no impact to IMS network;

There is no impact to VCC Application as standard VCC procedures are used;

The user plane interruption is minimized: it corresponds to the addition of the processing and transmission of the
200 OK between UE-B and CS-Proxy via CSCF and Relocation Command messages, estimated between 5 and
10 ms, to the inevitable handover execution time that is defined as the interruption time on Layer 1 and estimated
between 50 and 100 ms.

The handover preparation phase is minimized as the steps a, b and c are in parallel with the legacy handover
preparation phase (from Relocation/Handover Required to MAP Prepare HO Response). Moreover, the steps a)
to g) are very short compared to the legacy handover preparation phase; this means the handover preparation
phase is similar to the R99 legacy one;

The CS-Proxy and the related MGW can be distributed, so it is a scalable solution;

The CS-Proxy being in the VPLMN, the routing tables are the same as a legacy MSC; Furthermore, in a roaming
scenario, the user plane path is optimized i.e. it does not need to go through the HPLMN.

This is a VCC procedure triggered from the network;

Advantages of the VDN-Plus proposal

-

Does not require pre-established CS signalling and call setup like in alternative alt E and D2.

HO preparation is done in the network prior to HO command is sent to the UE (e.g., like how it is done today in
3GPP network).

Short handover preparation time as the UE is not involved

Fully re-use IMS based VCC implementation in the network.

No RNC emulation.

No CS registration is needed.

There are no changes for the existing inter MSC handover procedure and therefore no MSC changes are required

Compatible with IMS Centralized Service

7.19.1.7
7.19.1.7.1
7.19.1.7.1.1

Alternative E IMS Anchored Voice Continuity

Alternative E with tunnelling option
Description

This solution aims to use IMS and VCC Rel-7 framework for controlling the voice call continuity between CS domain
and LTE/SAE access. Re-use and enhancement of Release 7 VCC, where applicable, will also be considered.

3GPP

Release 8

115

3GPP TR 23.882 V8.0.0 (2008-09)

In order to utilize the IMS and VCC Rel-7 architecture, the following high level architecture introduces a gateway
called " Interworking Function (IWF)". The role of the IWF is:
-

To proxy S3 interface between MME and SGSN,

To be a signalling tunnelling end point towards the LTE/SAE MME for receiving/sending encapsulated
GSM/UMTS CS signalling messages to/from the UE and

To emulate a UTRAN RNS (Iu-CS interface) towards the 2G/3G MSC or GERAN BSS (A interface) towards
2G-only MSC. No modifications to the existing MSCs are required. As most A-capable MSCs are Iu-cs capable,
it is FFS whether A interface needs to be supported. Iu-cs/SIGTRAN is supported; it is FFS whether Iu-cs/ATM
transport option needs to be supported.

Figure 7.19.1.7-1: High Level SR-VCC Architecture

Per VCC Rel-7, for all VCC-capable UE's, the call is always anchored at the VCC AS / DTF.
The Role of the IWF is to enable a single radio UE to communicate in parallel both with the source system and target
system. Instead of using separate radios as in Rel-7 VCC, the signalling communication with the target system is carried
over the source system radio access.
Voice IWF is connected to MME with the S3' reference point. S3' is a version of the S3 reference point that is enhanced
to convey CS signalling messages between MME and IWF.
7.19.1.7.1.2

LTE VoIP to 2G/3G CS voice continuity

7.19.1.7.1.2.1

Overview

A SR-VCC signalling flow is presented with its two phases: "SR-VCC pre-registration phase" and "SR-VCC domain
transfer phase". These flows represent the "basic" alternative E in which there should be no need for any Rel-8 specific
user plane handling (such as MRF or CS bearers over EPS) to meet the SR-VCC break duration requirements.
NOTE:

If it is later desired that some Rel-8 specific user plane handling is to be performed, the presented basic
Alt-E signalling flow can be easily optimized for such scenarios.

7.19.1.7.1.2.2

SR-VCC pre-registration phase

The SR-VCC pre-registration phase corresponds to the LA Update procedure between the UE and the target MSC
tunnelled through MME and IWF. At handover decision, the initiation of the CM Service Request by the UE is triggered
by a message from E-UTRAN.

3GPP

Release 8

116

SR-VCC enhancements
UE

3GPP TR 23.882 V8.0.0 (2008-09)

CS DOMAIN

eNB

MME

SRVCC NAS / RRC&S1

container

IWF

S3 SR-VCC
container

HOME IMS DOMAIN

MSC

MGCF

CSCF

DTF

Iu-cs DTAP

24.008 LA Update procedure

Figure 7.19.1.7-3: SR-VCC Location Update Phase

SR-VCC pre-registration phase is started by the SRVCC UE, when two criteria are met:
-

UE is within LTE SR-VCCan area subject to SR-VCC (as indicated to UE by E-UTRAN. This is FFS)

UE is engaged in IMS VoIP session

When these criteria are met, SR-VCC UE performs a Location Update with the CS domain (as specified in TS 24.008).
If during the VoIP session, the UE enters a LTE cell for which there is no neighbour cells with the registered LA, the UE
shall perform a Location Update with the new LA. Periodic LA Update as per 24.008 are handled by the UE as per
24.008. It is expected that the change of LA and the LA Periodic timer expiry during a VoIP session are not frequent.
7.19.1.7.1.2.3

SR-VCC domain transfer phase

This phase describes the actual SR-VCC Domain Transfer taking place if an inter RAT handover towards 2G/3G occurs
during ongoing IMS VoIP session and when a SR-VCC is already prepared for the UE.
"SR-VCC extensions"
UE

eNB

MME

CS DOMAIN
IWF

MSC

HOME IMS DOMAIN

MGCF

CSCF

DTF

SR-VCC Domain TransferPhase (if happens within SR-VCC area during VoIP session)
1.HO to 2G/3G needed
1a.HO to CS Request
1b.CM_Service Request

Security Mode Command

1c.CC_SETUP VDN

2.HO REQUIRED

3.FW REL REQ

4. Setup (VDN)
8. IAM
5.RAB ASSIGN REQ

9. Invite

6.RAB ASSIGN COMP.

10. Invite

7.RELOC REQ

Proceed S3 reloc to SGSN (if any)

BREAK
without MRF

15. HO CMD

14. HO CMD

13. FW REL RESP

11. Access Leg Update

12. RELOC CMD

ANM

16. UE accesses the 2G/3G system over the target CS access

Source Leg
Release

17. CONNECT

Figure 7.19.1.7-4. SR-VCC Domain Transfer Phase.

1. Based on general inter system handover criteria, eNodeB decides when to trigger an Inter RAT HO preparation
towards a 2G/3G system.
1a. The eNodeB sends a RRC "HO to CS Request" message to the UE.

3GPP

Release 8

117

3GPP TR 23.882 V8.0.0 (2008-09)

1b. UE sends CM_Service Request to CS domain. MSC triggers Security Mode Command to IWF. IWF executes
the Security mode command towards the UE. The MSC may be configured on a per Iu-cs basis to inhibit UE
authentication when the CKSN/KSI sent by the UE is correct.
1c. After receiving a local indication of the Security Context being in place, the SR-VCC UE shall send a CS Call
Setup (VDN) towards the CS domain.
The 24.008 signalling over EPS system in encapsulated in special NAS message "SRVCC NAS / RRC&S1 container".
In addition of the encapsulated CS message the UE originated SRVCC NAS / RRC&S1 containers should include a flag
describing the content of the encapsulated CS message (CC_SETUP, CC_DISCONNECT, MM_LOCUP REQUEST or
OTHER SIGNALING).
MME forwards these SRVCC NAS / RRC&S1 containers to/from IWF over the S3' reference point.
2. To start inter RAT handover, eNodeB sends HO REQUIRED to MME.
3. MME generates S3 FWD RELOCATION REQUEST and sends it towards the SGSN, via the IWF which is in
MME-SGSN S3 signalling path.
4. IWF receives the FWD RELOCATION REQUEST from MME via S3'. IWF checks whether a CS Call Setup is
stored locally for the UE at IWF.
If no state for the UE exists within the IWF (i.e. no CS Call Setup is available at IWF for the UE), the IWF waits
for the CS Call Setup (VDN) for a short time. If the CS Call Setup (VDN) is not received before timer expiry
then no Domain Transfer is required for this S3 inter RAT Relocation. In this case the IWF acts as transparent S3
signalling proxy between the MME and SGSN for subsequent Inter RAT Relocation signalling. (This case is not
shown in figure)
If a CS Call Setup is available at the IWF for the UE before the above timer expires, the IWF forwards the
locally stored CS Call Setup to the MSC in Iu-CS Initial UE Message. IWF uses the registered Location Area
Identity in the Initial UE message.
IWF intercepts the received S3 FWD RELOCATION REQUEST message and reconstructs the message to
reflect the forking of the VoIP bearer towards the CS domain.
5. When MSC receives CS Call Setup, MSC triggers RAB Assignment for the CS call towards the IWF.
6. IWF responds with RAB ASSIGNMENT COMPLETE.
NOTE:

As the Iu-CS user plane is established towards the MGW by UTRAN and as there is no coordination
between the MGW and MSC at this phase, it should be possible for the IWF to skip the Iu-CS user plane
establishment towards MGW and proceed with step 6 without setting up a Iu-CS user plane.

7. Immediately after RAB ASSIGNMENT COMPLETE IWF proceeds with the Inter RAT Relocation. IWF sends
Iu_CS RELOCATION REQUIRED to MSC for the established CS RABs. MSC proceeds with the relocation
towards the target 2G/3G system. Note that in case the inter RAT HO target is a 2G radio system, the MSC
performs an 3G to 2G inter RAT HO for the CS call. In case when the target access system is not controlled by
the current MSC, an inter MSC handover is performed by the MSC.
IWF also forwards the reconstructed S3 FWD RELOCATION REQUEST to SGSN, if any other PS services
were active.
8. Preferably triggered by the step 4 the MSC proceeds with the CS call as specified for Release 7 VCC. MSC
sends IAM towards the MGCF.
9.-10. MGCF invites the DTF to the CS call.
11. DTF proceeds with the domain transfer and sets up the access leg for the CS call. MGCF completes the access
leg setup by sending ANM to MSC. During this Domain Transfer process the original VoIP media path gets
disconnected.
NOTE:

At this step it could be possible to insert a MRF into the media path. If MRF is inserted the original VoIP
media path would not be disconnected. Whether a MRF would be beneficial at all is FFS.

3GPP

Release 8

118

3GPP TR 23.882 V8.0.0 (2008-09)

12. In parallel with the Call handling at CS core, IWF receives Iu-CS RELOCATION COMMAND from MSC when
the relocation preparation at target CS system has completed. IWF also receives S3 FWD RELOCATION
RESPONSE from target SGSN if a parallel PS relocation was triggered.
NOTE:

In order to further optimize the voice call break time, the IWF may in some deployments artificially delay
the step 13 to give more time for the CS call to proceed.

13. After completion of the relocation preparation at target CS ( and PS) system(s), IWF reconstructs the S3 FWD
RELOCATION RESPONSE to correspond to the originally received PS-only relocation triggered by the MME.
IWF forwards the reconstructed FWD RELOCATION RESPONSE to the MME.
14. MME sends S1-AP HANDOVER COMMAND to eNodeB.
15. eNodeB sends an inter RAT HO Command to UE. This inter RAT HO command allocated the target system
resources for the CS call and for the possibly existing PS sessions. The target system radio resource information
is transparent to E-UTRAN.
16. UE performs inter RAT HO by tuning away from LTE and by accessing the target 2G/3G radio system. Target
2G/3G access system indicates to the MSC the detection of the UE at target System.
17. MSC forwards the CS Call CONNECT (as specified in TS 24.008) to UE.
To minimize the break time in the voice path:
-

the forwarding of the CS call setup by the IWF (step 4) should be triggered by the Inter RAT Relocation
procedure (step 3).

the step 13 may be artificially delayed by the IWF ( to allow the call proceed further before the Inter RAT HO)

It is FFS, whether alternatively, the VCC application may be enhanced to introduce a MGW to the media path to
maintain both voice media to the VoIP leg towards E-UTRAN and the CS leg towards MSC until the radio handover is
confirmed. During this period, the MGW may use bi-casting, conferencing or other means to assure voice continuity.
It is FFS, if as an another alternative to remove the break time, a CS voice path could be extended through the EUTRAN, i.e., to actually establish a EPS bearer to carry the CS voice between the IWF and UE, so that LTE VoIP bearer
can be switched to the CS voice bearer over EPS, in this case, there is no voice break after VCC domain transfer
procedure completed. In this case IWF supports Rx interface towards PCRF for the CS voice bearer establishment,
When the IWF receives the CS RAB assignment request from the MSC, the IWF interacts with PCRF to trigger a
dedicated bearer establishment for the CS voice, after that, the Iu-CS interface U-Plane connection between the MSC
and IWF is completed.
In case of MME relocation while keeping the same IWF, the old MME provides the new MME with the address of the
IWF. In case of MME relocation, it is also possible to relocate the IWF in order to keep collocation as long as it is
connected to the same MSC.

7.19.1.7.2
7.19.1.7.2.1

Alternative E without tunnelling option

Description

This solution aims to use IMS and VCC Rel-7 framework for controlling the voice call continuity between CS domain
and LTE/SAE access. Re-use and enhancement of Release 7 VCC, where applicable, will also be considered.
In order to utilize the IMS and VCC Rel-7 architecture, the following high level architecture introduces a gateway
called " Interworking Function (IWF)". The role of the IWF is:
-

To proxy S3 interface between MME and SGSN,

To allow the UE to be attached to the CS domain via the Gs interface towards the GSM/UMTS MSC and

To emulate a UE and a UTRAN RNS (Iu-CS interface) towards the 2G/3G MSC or GERAN BSS (A interface)
towards 2G-only MSC for call setup/release and handover. As most A-capable MSCs are Iu-cs capable, it is FFS
whether A interface needs to be supported. Iu-cs/SIGTRAN is supported; it is FFS whether Iu-cs/ATM transport
option needs to be supported.
Some modifications to the existing MSCs are required but without impacting the interfaces -see below.

3GPP

Release 8

119

3GPP TR 23.882 V8.0.0 (2008-09)

Figure 7.19.1.7-5: High Level SR-VCC Architecture

Per VCC Rel-7, for all VCC-capable UE's, the call is always anchored at the VCC AS / DTF.
The Role of the IWF is to enable a single radio UE to communicate in parallel both with the source system and target
system. Instead of using separate radios as in Rel-7 VCC, the signalling communication with the target system is carried
over the source system radio access.
Voice IWF is connected to MME with the S3' reference point. S3' is a version of the S3 reference point that is enhanced
to convey CS signalling messages between MME and IWF.

7.19.1.7.2.2

LTE VoIP to 2G/3G CS voice continuity

7.19.1.7.2.2.1

Overview

A SR-VCC signalling flow is presented with its two phases: "SR-VCC pre-registration phase" and "SR-VCC domain
transfer phase. This flow represents the "basic" alternative E in which there should be no need for any Rel-8 specific
user plane handling (such as MRF or CS bearers over EPS) to meet the SR-VCC break duration requirements.
NOTE:

If it is later desired that some Rel-8 specific user plane handling is to be performed, the presented basic
Alt-E signalling flow can be easily optimized for such scenarios.

7.19.1.7.2.2.2

SR-VCC preparation phase

SR-VCC enhancements
UE

eNB
EPS Attach

CS DOMAIN
MME/IWF

MSC

HOME IMS DOMAIN

MGCF

CSCF

DTF

LA Update via Gs

Figure 7.19.1.7-6: SR-VCC Location Update Phase

SR-VCC pre-registration phase is performed when the UE attaches to EPS and each time it changes TA. This allows the
IWF to select an appropriate MSC and therefore to minimize the inter-MSC handover cases. Enhancements are FFS.
The IWF is provisioned with a pre-configured LA.
The IWF initiates a Gs Location Update procedure with the pre-configured LA towards the MSC as specified in TS
29.108.

3GPP

Release 8

120

7.19.1.7.2.2.3

3GPP TR 23.882 V8.0.0 (2008-09)

SR-VCC domain transfer phase

This phase describes the actual SR-VCC Domain Transfer taking place if an inter RAT handover towards 2G/3G occurs
during ongoing IMS VoIP session and when a SR-VCC is already prepared for the UE.
SR-VCC enhancements
UE

eNB

CS DOMAIN
MME/IWF

MSC

RAN

HOME IMS DOMAIN

MGCF

CSCF

DTF

1-HO
trigger
2-Handover Required
3-CM Service Request (CK, IK)
4a-ID Req (IMSI)
4b-ID Resp(IMSI)
5-CM Service Accept
6a-Setup (VDN)

12-IAM

6b-Call Proceeding

12-Invite

12-Invite

7a-RAB Assignt Rq
7b-RAB Assignt Resp
8-Reloc Required

11-Reloc Command

16-Inter-RAT
HO Command

15-HO Command

9-Reloc
Request
(CK, IK)
10-Reloc
Request Ack
13-Access Leg Update
200 OK
ANM

14-Connect

200 OK

16-UE accesses the 2G/2G CS target cell

Figure 7.19.1.7-7: SR-VCC Domain Transfer Phase.

1. Based on general inter system handover criteria, eNodeB decides when to trigger an Inter RAT HO preparation
towards a 2G/3G system.
2. To start inter RAT handover, eNodeB sends HO REQUIRED to MME/IWF.
3. MME initiates CM Service Request to the MSC. VLR-TMSI is used if known. Otherwise, IMSI is used.
Location Area is preconfigured to the MME/IWF with one LA per MSC.
The MSC is configured on a per Iu-cs basis to inhibit common 24.008 procedures (Authentication, Security,
TMSI reallocation, IMEI request), useless RANAP procedures (Location report, Common ID, Trace) and
optionally global RANAP procedures (Reset, Reset Resource, Overload, Error Indication).
In order to handle security, there are two possibilities:
-

Sec-1 [additional Iu parameter]: CM Service Request message is enhanced with Ciphering Info (CK, IK), which
is further included in the Relocation Request towards target RAN in step 9 (shown in figure 7.19.7-7).

Sec-2 [additional parameter in S3 and RRC]: (not shown in figure 7.19.7-7) no changes to Iu but after CM
Service Request (no KSI), the MSC/VLR retrieves the authentication vectors from the HLR as for a normal call
and sends Authentication Request (RAND) to the IWF. The IWF stores RAND and the MSC always considers
the IWF has responded correctly to the Authentication Request. RAND is sent to the UE via HO Command
messages (RAND parameter to be added to S3 and RRC).

4a-b. The MSC may request IMSI from MME/IWF if VLR-TMSI is unknown.

3GPP

Release 8

121

3GPP TR 23.882 V8.0.0 (2008-09)

5. VMSC indicates to MME/IWF that call is in progress by sending Call Proceeding

6. MME/IWF sends setup (VDN) to MSC. The VDN is known by MME.
7a. When MSC receives Setup (VDN), MSC triggers RAB Assignment for the CS call towards the MME/IWF.
7b. MME/IWF responds with RAB ASSIGNMENT COMPLETE.
NOTE:

As the Iu-CS user plane is established towards the MGW by UTRAN and as there is no coordination
between the MGW and MSC at this phase, it should be possible for the MME/IWF to skip the Iu-CS user
plane establishment towards MGW and proceed with step 6 without setting up a Iu-CS user plane.

8. Immediately after RAB ASSIGNMENT COMPLETE MME/IWF proceeds with the Inter RAT Relocation.
MME/IWF sends Iu_CS RELOCATION REQUIRED to MSC for the established CS RABs. MSC proceeds with
the relocation towards the target 2G/3G system. Note that in case the inter RAT HO target is a 2G radio system,
the MSC performs an 3G to 2G inter RAT HO for the CS call. In case when the target access system is not
controlled by the current MSC, an inter MSC handover is performed by the MSC.
MME/IWF also forwards the reconstructed S3 FWD RELOCATION REQUEST to SGSN, if any other PS
services were active.
9. MSC sends Relocation Request to the target RAN.
10. Target RAN responds MSC with Relocation Request Ack after having reserved the RAN resources.
11. MME/IWF receives Iu-CS RELOCATION COMMAND from the MSC when the relocation preparation at target
CS system is completed. MME/IWF also receives S3 FWD RELOCATION RESPONSE from target SGSN if a
parallel PS relocation was triggered.
12. Preferably triggered by the step 4 the MSC proceeds with the CS call as specified for Release 7 VCC. MSC
sends IAM towards the MGCF and MGCF invites the DTF to the CS call.
13. DTF proceeds with the domain transfer and sets up the access leg for the CS call. MGCF completes the access
leg setup by sending ANM to MSC. During this Domain Transfer process the original VoIP media path gets
disconnected.
NOTE:

At this step it could be possible to insert a MRF into the media path. If MRF is inserted the original VoIP
media path would not be disconnected. Whether a MRF would be beneficial at all is FFS.

14. The MSC sends DTAP(CONNECT) to the IWF.

15. After completion of the relocation preparation at target CS ( and PS) system(s), and after having received
CONNECT message from the MSC, the MME/IWF sends S1-AP HANDOVER COMMAND to eNodeB. This
synchronization minimizes the flow break duration.
16. eNodeB sends an inter RAT HO Command to UE. This inter RAT HO command allocated the target system
resources for the CS call and for the possibly existing PS sessions. The target system radio resource information
is transparent to E-UTRAN.
17. UE performs inter RAT HO by tuning away from LTE and by accessing the target 2G/3G radio system. Target
2G/3G access system indicates to the MSC the detection of the UE at target System.
It is FFS, whether alternatively, the VCC application may be enhanced to introduce a MGW to the media path to
maintain both voice media to the VoIP leg towards E-UTRAN and the CS leg towards MSC until the radio handover is
confirmed. During this period, the MGW may use bi-casting, conferencing or other means to assure voice continuity.
It is FFS, if as an another alternative to remove the break time, a CS voice path could be extended through the EUTRAN, i.e., to actually establish a EPS bearer to carry the CS voice between the MME/IWF and UE, so that LTE VoIP
bearer can be switched to the CS voice bearer over EPS, in this case, there is no voice break after VCC domain transfer
procedure completed. In this case MME/IWF supports Rx interface towards PCRF for the CS voice bearer
establishment, When the MME/IWF receives the CS RAB assignment request from the MSC, the MME/IWF interacts
with PCRF to trigger a dedicated bearer establishment for the CS voice, after that, the Iu-CS interface U-Plane
connection between the MSC and MME/IWF is completed.
In case of MME relocation while keeping the same IWF, the old MME provides the new MME with the address of the
IWF. After the relocation of MME, the IWF will communicate with the MME via an S3 interface.

3GPP

Release 8

122

3GPP TR 23.882 V8.0.0 (2008-09)

In case of MME relocation, it is also possible to relocate the IWF in order to keep collocation as long as it is connected
to the same MSC.

7.19.1.7.3

2G/3G CS voice to LTE VoIP voice continuity

This procedure works for the case of subsequent handover i.e when the voice call was initiated in LTE as well as for
the case where the voice call was initiated in 2G/3G.
2G/3G CS to LTE VoIP voice continuity can be achieved in many different ways which completely reuse the Release 7
VCC framework. These mechanisms reuse the Release 7 VCC procedures but use different mechanisms (if any)
between the underlying source (CS) and target (LTE/PS) access systems to minimize the break time resulting from the
single radio operation.
If simultaneous PS connectivity during the CS call is not possible following steps should be followed:
-

When CS to LTE handover is desired, UE may abandon the CS system without any preceding resource
reservation at LTE system. UE abandons the source system either by network controlled handover terminated to
the IWF or by UE controlled inter RAT Tracking Area Update (TAU) (no IWF involved)

Editor's note: In the case of TAU, the mechanism by which it is ensured that the release of the CS call does not result
into the release of the VCC session is FFS.
-

UE tunes it's single radio to the LTE radio and re-establishes IP connectivity via e_UTRAN.

UE registers to IMS (if not already registered)

UE Invites (SIP Invite via LTE) the VCC Application Server to the ongoing voice call. The EPC voice bearer is
setup from the network via PCRF.
These steps enable domain transfer from CS to PS in all cases but may cause a larger break in the voice
communication. Especially if the UE can be assumed to be already IMS registered the solution should be able to
meet the service requirements defined for SR-VCC.

If simultaneous CS and PS connectivity during the CS is possible, UE may register to IMS during the CS call via the
source system.
Following signalling flow illustrates the CS->LTE SR-VCC procedure:

3GPP

Release 8

123

3GPP TR 23.882 V8.0.0 (2008-09)

Figure 7.19.1.7.3-1. 2G/3G CS to LTE VoIP inter RAT Handover

In case of Network triggered inter system handover:
A1.

E.g. based on the measurements and additional information, the source system decides to initiate the
handover.

A2.

The source BSS/RAN sends HO Required message to MSC.

A3.

The source MSC sends a HO Request message to the IWF. The IWF plays the role of Target BSS/RAN
for the MSC. This message contains the target cell.

A5.

For the possibly existing PS services to be handed over to LTE, the BSS/RAN may initiate ina parallel
inter RAT PS handover / Relocation towards the Target MME via the SGSN IWF as described for inter
RAT handover in TS 23.401.
In this PS handover/ Relocation the IWF is in the S3 signalling path between the source SGSN and the
target MME. As the IWF terminates the CS relocation (from source CS system) locally, only the
Handover/Relocation from the source PS system is relayed to the target MME. IWF also coordinates
towards the source system - the parallel execution of the CS and PS Handover/Relocation.

A7.

The IWF sends a HO Response to the MSC emulating the target BSS/RAN. This message contains,
within the transparent container, an indication to the UE that the CS call is subject to SR-VCC and the UE
should initiate SIP invite to VCC-AS immediately after entering to the target system to resume the speech
call. LTE reserves no resources for the CS handover.

3GPP

Release 8

124

3GPP TR 23.882 V8.0.0 (2008-09)

A8.

The MSC sends HO Command to the source BSS/RAN.

A9.

The source BSS/RAN sends a HO Command message to the UE to begin HO procedure to the target
system.

In case of UE triggered inter system handover (Tracking Area Update):

B1.

UE decides to switch from CS system to LTE

Then, for both cases:

10.

UE tunes to LTE radio system and establishes RRC connection as specified in TS 36.300.

A11.

In case some LTE resources were already allocated to the UE in step A9, the UE completes the inter RAT
HO with RRC HO Complete. The eNodeB sends HO Complete to MME.

B11.

In case no LTE resources are allocated to the UE, UE triggers Tracking Area Update (TAU) procedure
towards the LTE system as specified in TS 23.401. UE sets the Active Flag on. Default IP connectivity
gets (re-)established.

12.

If UE is not already registered to IMS, UE executes IMS registration. Existing IMS registration helps
reducing the voice communication break time in the procedure.

13.

UE sends SIP Invite to VCC-AS, inviting the VCC-AS into a VoIP call with the UE. UE indicates the
correct call to the VCC-AS by including the VDI. Upon reception of the SIP Invite the VCC-AS invites
the other end (e.g. a peer UE or a MGW) to the new SIP call via the new VoIP leg.

14.

VSS-AS responds with 200 OK.

15.

IMS may trigger Dedicated EPS bearer establishment via PCRF for the VoIP media. Before Dedicated
bearer establishment VoIP media may use the already established Default bearer.

16.

VCC-AS triggers resource release in the source system by sending SIP BYE towards the source
MSC/MGCF/MGW. The resources at the source system are locally cleared.

7.19.1.8

Alternative F Inter-MSC Handover with IMS Centralised Services

7.19.1.8.0

General Concept

This section proposes to complement Alternative D with concepts being defined as part of IMS Centralised Services
(TR 23.982). Specifically, it is proposed to use the ICCC (IMS CS Control Channel) logical channel to convey service
control messages after HO to the CS domain.
Additionally, it defines a stand-alone interworking function referred to as PS-CS Handover Control Function (PCHCF)
which presents PS HO and CS HO behaviour towards the SAE/LTE Evolved Packet Core and the CS core, respectively.
There are two different solutions following with this concept, one called alternative F-1, which is described in the
section 7.19.1.8.1, and another one is called alternative F-2, which is described in the 7.19.1.8.2.

7.19.1.8.1
7.19.1.8.1.1

Alternative F-1
Description

Depicted in Figure 7.19.1.8.1.1-1 is a SR VCC architecture, including the architecture for handovers of non-voice
sessions.

3GPP

Release 8

125

3GPP TR 23.882 V8.0.0 (2008-09)

Figure 7.19.1.8.1.1-1: SR VCC architecture Alternative F-1

PCHCF contains MME function and anchor MSC server function. It also contains an adaptation function for the service
control signalling between CS domain and IMS. This function converts the service control signalling information
received from the UE over CS access signalling and uses this information for initiation and control of SIP sessions via a
SIP User Agent function towards the ICCF function in the IMS.
The PCHCF presents an Mw-like interface to the home IMS in a manner similar to the I6 reference point between the
enhanced MSC and the CSCF as defined in TR 23.892 enhanced MSC approach for non ICS UE.
NOTE:

The relationship with ICS in general and the enhanced MSC approach in particular needs to be revisited
as SR VCC and ICS studies are evolving in parallel.

The following principles are used in defining the architecture for enablement of IMS-CS service continuity with support
for IMS Centralised Services:
1. All services are centralised in IMS;
2. SIP session runs in the UE when using LTE access;
3. When using CS access, SIP session runs in the UE with PCHCF presenting it to IMS [SIP templates embedded
in CS signalling for transport b/w UE and PCHCF]; SDP is generated by PCHCF;
4. For Handovers to CS:
a. PCHCF performs a SIP REGISTER with a new IMPI. A new SIP session is created to initiate VCC Domain
Transfer;
b. Downlink bi-cast is employed at a MRF associated with the DTF to prepare downlink bearer toward the
target GERAN/UTRAN prior to instructing the UE to retune to the target radio. The first uplink packet from
the UE after the radio switch results in switching at the MRF of the uplink bearer from the UE;
c. In case of HO to 2G: the voice session is relocated using a new CS-PS handover procedure which are a
combination of PS-PS and Inter-MSC Handover procedures; any non-voice sessions including the SIP
signalling bearer are suspended in the LTE access and are resumed upon subsequent handback to LTE. In
case the voice call is terminated while in 2G CS, the non-voice sessions are resumed from the 2G access and
are relocated to the 2G SGSN;
d. In case of HO to 3G: the voice session is relocated using a new CS-PS handover procedure which are a
combination of PS-PS and Inter-MSC Handover procedures; any non-voice sessions including the SIP
signalling bearer are relocated to the 3G SGSN using the standard PS-PS HO procedure.

3GPP

Release 8

126

3GPP TR 23.882 V8.0.0 (2008-09)

5. For Handback to LTE:

a. In case of handback from 2G: the original SIP signalling bearer (as well as any other non-voice session) is
resumed; UE sends a SIP INVITE from LTE access and NW-initiated bearer is used to establish the VoIP
bearer;
b. In case of handback from 3G: the voice session is relocated using a new PS-CS handover procedure which
are a combination of Subsequent Inter-MSC Handover and PS-PS Handover procedures; any non-voice
sessions including the SIP signalling bearer are relocated to the MME/SGW using the standard PS-PS HO
procedure.
7.19.1.8.1.2

Call flows for Handovers of calls initiated in LTE

7.19.1.8.1.2.1

LTE => 2G CS handover

Depicted in Figure 7.19.1.8.1.2.1-1 is a call flow for LTE => 2G CS handover of a call initiated in LTE. It is assumed
that the 2G network has no support for DTM, 2G PS handover or VoIP optimisations.

Figure 7.19.1.8.1.2.1-2: IMS/LTE to 2G Handover (voice bearers only)

1. Target measurements and handover trigger detection at the source eNB and the UE for initiation of handover to
CS.
2. Relocation Required message sent by the source eNB to source MME containing required information such as
source to target information.
3. Standard PS-PS handover procedure at the source MME for initiation of Forward Relocation Request toward
PCHCF.
4. PS handover request interworked with CS inter-MSC handover request to the target MSC at PCHCF. The
PCHCF initiates a Prepare Handover Request toward target MSC for the voice session only. It is assumed that

3GPP

Release 8

127

3GPP TR 23.882 V8.0.0 (2008-09)

the CS Security context (e.g. Cipher Key, CKSN, and if handing over to UMTS CS, also the Integrity Key) is
available at the PCHCF. Mechanisms for the discovery/retrieval of the CS security context at the PCHCF may
include the following:
A) generation of extra key at PS domain authentication
Currently, when the ME passes an Authentication Challenge into the UICC, several security keys are
generated (which match the ones contained in the authentication vectors sent from the HSS to the MME).
This could be extended so that other keys can be generated by the UICC one of these could be a VCConly CS domain key. The UE uses this key after handover and it would match the one sent from the HSS
to the MME (and onto the relay MSC which in turn sends it to the GERAN) for this purpose.
This approach appears promising, but, this requires a new UICC. However the generation of LTE keys
probably also requires a new UICC and backwards compatibility mechanisms to use old UICCs are
likely to be specified. see (B) below.
B) hash function in UE.
This is a complement to (A) above, wherein the ME uses a hash function on the PS domain key(s)
generated by the USIM to generate a VCC-only CS domain key.
The MME implements the same hash function on the authentication vector received from the HSS to
generate the VCC-only CS domain key. The MME sends this VCC-only CS domain key via PCHCF
onto the relay MSC which in turn sends it to the GERAN.
5. Target GERAN preparation via the target MSC.
6. Handover Number returned in Prepare Handover Response by the target MSC for establishment of circuit
connection between the target MSC and the MGW associated with the PCHCF.
7. Establishment of circuit connection between the target MSC and the MGW associated with the PCHCF initiated
by the PCHCF using ISUP IAM and ACM. Completion of this step leads to the following subsequent steps:
a. The SIP User Agent function associated with the PCHCF performs a SIP REGISTER with a new IMPI/IMPU
pair using Early IMS procedures for trusted node
b. Subsequently PCHCF initiates an enhanced VCC Domain Transfer procedure to perform bearer preparation.
This establishes a downlink bi-cast from the MRF associated with the DTF toward the bearer termination at
the MGW associated with the PCHCF. The first uplink packet from the MGW associated with the PCHCF
results in switch of the uplink media at the MRF.
8. Forward Relocation Response generated toward source MME with the required information such as target to
source BSS information as indication of network bearer preparation and to instruct the UE to retune. The
Forward Relocation Response message indicates to the MME that only the voice bearer is being relocated. The
MME knows that at the end of the CS-PS handover the non-voice bearers should be preserved.
9. Relocation Required Ack toward the source eNB to instruct the UE to retune to the target radio.
10. Relocation Command sent by the source eNB for the UE to retune to the target radio.
11. Handover Detection at the target GERAN.
12. Handover Complete sent by the target GERAN to the MSC. Completion of this step leads to the following
subsequent steps:
a. SES Handover Complete sent to the PCHCF.
b. ISUP Answer message sent to the PCHCF to complete the bearer path between the MSC and the MGW
associated with the PCHCF.

3GPP

Release 8

7.19.1.8.1.2.2

128

3GPP TR 23.882 V8.0.0 (2008-09)

Subsequent 2G CS => LTE handover

Depicted in Figure 7.19.1.8.1.2.2-1 is a call flow for subsequent 2G CS => LTE handover of a call initiated in LTE. It is
assumed that the 2G network has no support for DTM, 2G PS handover or VoIP optimisations.

Figure 7.19.1.8.1.2.2-1: Handback from 2G to IMS/LTE (voice bearers only)

At the beginning of the call flow the UE is IMS registered over a suspended PS bearer (the latter was suspended during
the LTE => CS handover).
1. Target measurements and handover trigger detection at the source GERAN and the UE for initiation of handover
to LTE.
2, Handover Required message sent by the source GERAN to source MSC containing required information such as
source to target information.
3. Standard inter-MSC CS-CS handover procedure between the MSC and the PCHCF with exchange of Prepare
Subsequent HO Request/ Response messages. The PCHCF signal successful Subsequent CS handover without
allocating any LTE resources.
4. Handover Require Ack sent by source MSC to source GERAN
5. Handover Command sent by the source GERAN for the UE to retune to the target radio.
6. UE re-tunes to LTE radio and performs a TAU procedure (if required)
7. UE performs a Service Request (or similar) in order to resume the suspended SIP signalling bearer and any other
suspended non-voice bearers
8. Subsequently UE initiates the enhanced VCC domain transfer procedure. Note that the SIP INVITE goes only as
far as the DTF.
9. The IMS triggers a network-initiated bearer for the voice bearer (IMS access leg)

3GPP

Release 8

129

3GPP TR 23.882 V8.0.0 (2008-09)

10. Relocation Required Ack toward the source eNB to instruct the UE to retune to the target radio.
11. SIP ack
12. The resource release in the CS domain and the PCHCF is triggered from the DTF.
7.19.1.8.1.2.3

LTE => 3G CS handover

Depicted in Figure 7.19.1.8.1.2.3-1 is a call flow for LTE => 3G CS handover of a call initiated in LTE. Both voice and
non-voice bearers are relocated.

Figure 7.19.1.8.1.2.3-1: IMS/LTE to 3G Handover (both voice and non-voice bearers)

1. Target measurements and handover trigger detection at the source eNB and the UE for initiation of handover to
CS.
2. Relocation Required message sent by the source eNB to source MME containing required information such as
source to target information.
3. Standard PS-PS handover procedure at the source MME for initiation of Forward Relocation Request toward
PCHCF.
4. The PCHCF splits the voice bearers from all other PS bearers and initiates a Prepare Handover Request toward
target MSC. It is assumed that the CS Security context is available at the PCHCF; possible mechanisms for the
discovery/retrieval of the CS security context at the PCHCF are described in the previous subclauses. The
relocation of remaining PS bearers is initiated towards the target SGSN with a Forward Relocation Request
message.
5. Target UTRAN preparation via the target MSC (CS relocation) and the target SGSN (PS relocation).
6. Successful CS relocation indicated by target MSC with a Handover Number returned in Prepare Handover
Response. Successful PS relocation indicated by target SGSN with a Forward Relocation Response.

3GPP

Release 8

130

3GPP TR 23.882 V8.0.0 (2008-09)

7. Establishment of circuit connection between the target MSC and the MGW associated with the PCHCF initiated
by the PCHCF using ISUP IAM and ACM. Completion of this step leads to the following subsequent steps:
a. The SIP User Agent function associated with the PCHCF performs a SIP REGISTER with a new IMPI/IMPU
pair using Early IMS procedures for trusted node
b. Subsequently PCHCF initiates the enhanced VCC Domain Transfer procedure.
8. Forward Relocation Response generated toward source MME with the required information such as target to
source BSS information as indication of network bearer preparation and to instruct the UE to retune.
9. Relocation Required Ack toward the source eNB to instruct the UE to retune to the target radio.
10. Relocation Command sent by the source eNB for the UE to retune to the target radio.
11. Handover Detection at the target UTRAN.
12. Relocation Complete sent by the target UTRAN to the MSC and to the SGSN
13. Target SGSN updates the bearer with SGW or PGW
7.19.1.8.1.2.4

Subsequent 3G CS => LTE handover

Depicted in Figure 7.19.1.8.1.2.4-1 is a call flow for subsequent 3G CS => LTE handover of a call initiated in LTE.
Both voice and non-voice bearers are relocated.

Figure 7.19.1.8.1.2.4-1: Handback from 3G to IMS/LTE (both voice and non-voice bearers)
1. Target measurements and handover trigger detection at the source UTRAN and the UE for initiation of handover
to LTE.
2. Relocation Required message sent by the source UTRAN to source MSC and source SGSN containing required
information such as source to target information.

3GPP

Release 8

131

3GPP TR 23.882 V8.0.0 (2008-09)

3. Source MSC sends a Prepare Subsequent HO Request to PCHCF. Source SGSN sends a Forward Relocation
Request. / Response messages.
4. The PCHCF sends a Forward Relocation Request to the target MME including information about the non-voice
bearers only.
5. Target MME sends a Relocation Request to target eNB.
6. Target eNB replies with Relocation Request Ack.
7. Target MME sends a Forward Relocation Response to the PCHCF.
8. The PCHCF signals successful Subsequent CS handover to the source MSC without allocating any LTE
resources. The PCHCF also signals a Forward Relocation Response to the source SGSN.
9. Relocation Required Ack sent by source MSC and SGSN to source UTRAN.
10. Relocation Command sent by the source UTRAN for the UE to retune to the target radio.
11. UE re-tunes to LTE radio
12. to 15. Relocation Detect, Relocation Complete
16. At the end of the relocation procedure the UE performs a TAU (if required)
17. Subsequently UE initiates the enhanced VCC domain transfer procedure over the relocated SIP signalling bearer.
Note that the SIP INVITE goes only as far as the DTF.
18. The IMS triggers a network-initiated bearer for the voice bearer (IMS access leg)
19. Relocation Required Ack toward the source eNB to instruct the UE to retune to the target radio.
7.19.1.8.1.3

Advantages of the solution

There are several significant advantages to the above described solution:

1. There is no impact to the existing Core Network nodes;
2. There is no impact to the existing GERAN and UTRAN nodes as existing HO procedures are used;
3. There is no impact to the IMS network;
4. The solution is compatible with IMS Centralised Services;
5. Changes to the REL-7 VCC Application are minimised and are limited to the use of associated MRF;
6. The handover preparation phase should be comparable to the handover preparation phase in 2G/3G networks;
7. The handover interruption is expected to meet the 300 ms target in all cases except for the 2G => LTE case due
to lack of physical layer information exchange between the source and target RANs. However, even in this case
the service interruption time is expected to be ~750 ms;
8. The PCHCF is a control plane functionality and can be scaled separately from the user plane functionality in the
MGW;
9. The overall SR VCC procedure is triggered from the network.

7.19.1.8.2
7.19.1.8.2.1

Alternative F-2
Description

PCHCF contains eNodeB/RNC/BSC function and anchor MSC server function.

The alternative F-2 works for the voice calls which have been initiated in the IMS/LTE to be transferred tot he 2G/3G
CS and allows for subsequent transition from 2G/3G CS back to the IMS/LTE. It is FFS how the Alternative F-2 can be
used for calls initiated in the CS domain.

3GPP

Release 8

132

3GPP TR 23.882 V8.0.0 (2008-09)

Comprising with the alternative F-1, the difference of the alternative F-2 is that, the SAE GW acts as the media plane
anchor point that all bearers of the UE will be transferred from the eNodeB to the eNodeB/RNC/BSC associated with
the PCHCF by performing a inter eNodeB handover. So that the execution of handover doesnt not depend on the VCC
procedure, because there is no need of sending re-invited to the remote UE to update the IP address the since the SAE
GW is still kept in the call path.
Editors note: it is FFS how to handle the non-voice related bearer in the SAE GW when the voice handover is
occurred.
7.19.1.8.2.2

SAE/LTE => CS handovers

The signalling/ bearer architecture for the LTE-2G/3G CS Handover is illustrated in figure 7.19.1.8,2-1 below.

7.19.1.8.2-1: Signalling/Bearer Architecture for the LTE-2G/3G CS Handover Voice bearer anchored
at SAE-GW
NOTE1: after handover, the signalling control plane between the UE and the ICCF via SAE GW (SIP signalling
bearer) will be transferred to a ICCC signalling between the UE and the ICCF via the target MSC, how
the ICCC signalling can be routed to the ICCF located in the home IMS network will follow the decision
taken by the ICS work item.
For the sake of brevity, "the eNodeB/BSC/RNC function associated with the PCHCF" is abbreviated as "PCHCFeNodeB/BSC/RNC", and "the MSC-S function associated with the PCHCF" is abbreviated as "PCHCF-MSC-S",
Based on the Figure 7.19.1.8.2-1, the more detail about the process is depicted as follows:
1. Based on the measurement report, the standard PS-PS Handover procedure will be triggered and the PCHCFeNodeB/BSC/RNC receives the standard PS-PS Handover message (i.e. Handover Request), and the PCHCFeNodeB/BSC/RNC maintains the bearer information such as all PDP contexts and the related radio parameters.
2. The PCHCF-MSC-S mimics a standard inter-MSC Handover to establish the CS bearer as shown in light blue
real line between the UE and MSC.
3. The data forwarding process is triggered and the source eNodeB forwards the downlink data to the PCHCFeNodeB/BSC/RNC.

3GPP

Release 8

133

3GPP TR 23.882 V8.0.0 (2008-09)

4. The PCHCF decodes the downlink VoIP packets to get the voice media information such as IP 5 tuple and the
voice codec, which will be used by the PCHCF-MSC-S to establish the bearer as shown in light blue real line
between the MGW and the MSC using ISUP IAM/ACM.
5. The PCHCF-eNodeB/BSC/RNC triggers the process of redirecting the bearers from the source eNodeB to itself
by sending Update Bearer Context towards SAE GW via its serving MME. Upon completion of this process, the
new voice bearer as show in light blue real line between the UE and the MGW and in deep blue real line between
the PCHCF-eNodeB/BSC/RNC and remote UE via SAE GW has been established or reserved successfully.
6. When UE has accessed in the CS domain, the SIP session control messages are transported over ICCC, which
defined in the current ICS work item.
7.19.1.8.2.3

Subsequent handovers from CS => SAE/LTE

The signalling/ bearer architecture for the subsequent 2G/3G CS to SAE/LTE Handover is illustrated in figure
7.19.1.8.2-2 below.

Figure 7.19.1.8.2-2: Signalling/Bearer Architecture for the Subsequent HO Voice bearer anchored at
SAE-GW
NOTE1: after the subsequent handover, the signalling control plane of the ICCC signalling between the UE and the
ICCF via the target MSC will be transferred to a SIP signalling bearer between the UE and the SAE GW,
how the original ICCC signalling can be routed to the ICCF located in the home IMS network will follow
the decision taken by the ICS work item.
During the subsequent handover back from CS to LTE procedure, PCHCF only needs to get the target LTE Cell ID from
the subsequent handover message as the related bearer information about inter-eNodeB handover has been stored and
maintained by the PCHCF-eNodeB/BSC/RNC.
When the subsequent CS to LTE handover is occurred, the related neighbour LTE cells are configured in BSS/RNS,
which, from the BSS/RNS point of view, are regarded as pseudo-CS cells and served by the PCHCF-MSC-S. So, if the
BSS/RNS receives the measurement report sent by the UE and decides to trigger the standard inter-MSC handover
towards LTE cell, and the standard CS-CS handover message will be sent to the target PCHCF-MSC-S with the target
LTE Cell ID to inform the PCHCF the occurrence of subsequent handover.

3GPP

Release 8

134

3GPP TR 23.882 V8.0.0 (2008-09)

After that, the PCHCF-eNodeB/BSC/RNC finds out the target LTE Cell ID from the subsequent handover message, and
generates the related Relocation Required message using the bearer information maintained in PCHCFeNodeB/BSC/RNC, and then mimics an inter-eNodeB handover to the real target eNodeB by sending the Relocation
Required. The following steps are similar to the standard inter-eNodeB handover.

7.19.1.8.3

Impact on the baseline CN Architecture

This solution requires new core network functionality (PCHCF). The alternative with optimised bearer preparation
requires an enhancement to REL-7 DTF allowing for insertion of MRF in the bearer path of IMS sessions anchored at
the DTF.

7.19.1.8.4

Impact on the baseline RAN Architecture

This solution does not require any of the following GERAN features: DTM, EGPRS (EDGE), PS handover, DTM
enhancements or VoIP optimisations.

7.19.1.8.5

Impact on terminals used in the existing architecture

7.19.1.9

Alternative D/F

7.19.1.9.1

Description

This alternative combines the concepts and principles from Alt F1 (clause 7.19.1.8.1) and Alt D2-VDN+ (clause
7.19.1.6b) proposals as they share same mobility trigger and functions for the "HO" to/from 2G/3G. The differences are
in the service capabilities (e.g., network ICS (F1) vs. non network ICS (D2-VDN+)). This combined proposal is
referred to as Alt D/F.
Depicted in Figure 7.19.1.9.1-1 is a SR VCC Alt D/F architecture, including the architecture for handovers of non-voice
sessions.

NOTE1:
NOTE2:
NOTE3:
NOTE4:
NOTE5:

HO interface with MSC consists of MAP-E and speech circuit related interface such as ISUP, BICC, or SIPI.
this reference point is Mg (for support of Rel-7 VCC and Rel-8 ICS/MMSC) or Mw (for support of Rel-8
ICS/MMSC) For details of ICS, see 3GPP TS 23.292 and for MMSC, see 3GPP TR 23.893.
whether SGSN is connected to the MSC/S-IWF or the MME via S3 is FFS. This depends on the location of
the PS bearer splitting functionality (voice bearer vs non-voice bearers) as clarified further below. Once
this decision is made there will be only one S3 instance in the figure.
in some deployment scenarios the MSC/S-IWF may not exhibit any Iu-CS or A interface
whether UE needs to be registered with MSC/S-IWF via Gs is FFS

Editors note: IWF interworking with SMS is FFS!

Figure 7.19.1.9.1-1: SR VCC architecture Alternative D/F

3GPP

Release 8

135

3GPP TR 23.882 V8.0.0 (2008-09)

The following principles are used in defining this Alt D/F architecture:
1. S-IWF can perform MSC-MSC handover or RNC/BSC handover, depending on the absence or presence of IuCS/A interfaces on the S-IWF.
2. The CS access leg setup upon EUTRAN=>CS handover is triggered by the radio handover signalling.
3. A function that identifies the voice PS bearer upon EUTRAN=>CS handover and separates it from the rest of PS
bearers. This function is referred to as "PS bearer splitting function" and is located either in the MSC/IMSC/IWF
or in the MME (FFS).
For convenience, in the remainder of this clause the MSC/S-IWF function will be shortly referred to as S-IWF (SRVCC
IWF). Note that the S-IWF may also be implemented with an MSC Server (i.e. control plane functionality), the user
plane functionality being provided on a MGW.

7.19.1.9.2

Call flows for Handovers of calls initiated in LTE

Editor's note: The following call flows are focusing on the voice component. General handling of split function
with MMSC for others PS components is FFS.
The call flows in this clause assume that the PS bearer splitting function (voice vs non-voice bearers) is located in the SIWF. The case where the PS bearer splitting function is located in the MME is covered by appropriate indications in the
text.
If the S-IWF exhibits an Iu-CS or A interface, the steps covered by yellow boxes are not executed and the S-IWF and
MSC functions are merged.

7.19.1.9.2.1

LTE => 2G CS handover;

Depicted in Figure 7.19.1.9.2.1-1 is a call flow for LTE => 2G CS handover of a call initiated in LTE. This depicts the
usage of Mg interface at the IWF. It is assumed that the 2G network has no support for DTM, 2G PS handover or VoIP
optimisations.

3GPP

Release 8

136

e U

1 :

e a s u r e m

T R A

r e g is t e r s

e n t

r e

i t h

C S

d o m

S - I W

a i n

v ia

v M

S G

S C

f o r

2 :

E R A

S G

S C

I C

c a t io n

e q

a r d

e l o c

r e p a r e

( o r

f r o m

E )

s p l i t s

t h e

I P

7 .

I A

/ A

e q u e s t / A

a i n i n g
S P

E N

a l l

i s

o t h e r

f o r w

P S

a r d e d

b e a r e r s

v M

S C

t h i s

i s

t h e

s i m

t h a t

n o n - v o i c e

i l a r

9 :

F l o w

c o m

i t c h e s

r a d i o
S y n

b r o k e n

e l o c

s w

e r

1 1 .H

w
F

n l i n k
i s

b i - c a s t

i t h

t h e

F F S

t o

3 G

R e lo

> 2 G

e q

I A

( V

s h o u l d
P S

b e a r e r s
H

F / I M

( V

S S - A

S )

a r d

e l o c

e s p

c k

a n d

it s

c h r o n i z a t io

u n d

a r e

8 .F o r w

1 0 :

p l i e s

p r e s e r v e

o f

b e a r e r s ; o n l y
t o

7 a .
i m

u s e

c k

e s p

M
b e a r e r

T h i s

e q

S U

e q

5 .

r e m

u i r e d

6 .P r e p a r e

t h i s

F / D T F

( F F S )

4 .P

b e a r e r

e lo

3 .F o r w

S N

p o r t s

D e c is i o

S - I W

3GPP TR 23.882 V8.0.0 (2008-09)

E R

e t e c t i o n

1 2 .

1 2 a .S E

( H

o m

o m

p l e t e

F l o w

p l e t e )

r e s u m
1 2 b .

1 3 .U

p d a t e L o c

S W

e d

E R

H
H

S S /
L R

Figure 7.19.1.9.2.1-1: IMS/LTE to 2G Handover with Mg interface at the IWF (voice bearers)
Before the initiation of the HO the UE may register with the CS domain via Gs (FFS).
1. Target measurements and handover trigger detection at the source eNB and the UE for initiation of handover to
CS.
2. Relocation Required message sent by the source eNB to source MME containing required information such as
source to target information.
3. Standard PS-PS handover procedure at the source MME for initiation of Forward Relocation Request toward SIWF.
NOTE:

If the PS bearer splitting functions is located in the MME, the MME includes only the voice bearer in the
Forward Relocation Request.

4. PS handover request interworked with CS inter-MSC handover request to the target MSC at S-IWF. The S-IWF
initiates a Prepare Handover Request toward target MSC for the voice session only. It is assumed that the CS
Security context key can be derived from the LTEs PS domain key context (e.g. similar for security key
mapping for PS-PS HO to 2G/3G SGSN)
5. Target GERAN preparation via the target MSC.
6. Handover Number returned in Prepare Handover Response by the target MSC for establishment of circuit
connection between the target MSC and the MGW associated with the S-IWF.
7. Establishment of circuit connection between the target MSC and the MGW associated with the S-IWF initiated
by the S-IWF using ISUP IAM and ACM. Completion of this step leads to the following subsequent steps:
7a. The S-IWF, upon response of the handover request, establishes a CS call to the VDN (including bearer
reservation at CS-MGW). VDN and MSISDN are received from the HSS via MME as part of the subscription
profile download to MME during LTE attach procedure.

3GPP

Release 8

137

NOTE:

3GPP TR 23.882 V8.0.0 (2008-09)

Use of a downlink bi-cast from the MRF associated with the DTF is FFS.

8. Forward Relocation Response generated toward source MME with the required information such as target to
source BSS information as indication of network bearer preparation and to instruct the UE to retune. The
Forward Relocation Response message indicates to the MME that only the voice bearer is being relocated. The
MME knows that at the end of the CS-PS handover the non-voice bearers should be preserved.
9. Relocation Required Ack toward the source eNB to instruct the UE to retune to the target radio.
10. Relocation Command sent by the source eNB for the UE to retune to the target radio.
11. Handover Detection at the target GERAN.
12. Handover Complete sent by the target GERAN to the MSC. Completion of this step leads to the following
subsequent steps:
a) SES Handover Complete sent to the S-IWF.
b) ISUP Answer message sent to the S-IWF to complete the bearer path between the MSC and the MGW
associated with the S-IWF.
13: S-IWF performs an MAP Update Location to the HSS/HLR if needed. This allows S-IWF to receive GSM SS
information and also allows HSS/HLR to route the mobile terminating call properly. This step is not needed if
the UE was already registered with the S-IWF via Gs (FFS).
NOTE:

This Update_location is not initiated by UE.

Depicted in Figure 7.19.1.9.2.1-2 is a call flow for LTE => 2G CS handover of a call initiated in LTE when Mw
interface is used at the IWF. It is assumed that the 2G network has no support for DTM, 2G PS handover or VoIP
optimisations.

e U

1 :

a s u r e m

T R A

r e g i s t e

n t

r s

i t h

d o m

S - I W

a i n

v i a

v M

S C

f o r

R e

lo c a t i o n

R e q

a r d

e lo c

r e p a r e

( o r

f r o m

b e a r e r
a in in g

E )

s p l it s

a l l o t h e r
is
P

f o r w
S

t h e

P S

a r d e d

b e a r e r s

V o I P

b e a r e r s ;
t o

v M

7 .

r e p a r e

I A M

/ A

S P

h is

E N
i m

is

t h e

s i m

t h a t

F l o w

R e

lo c

s w

i t c h e s

r a d i o
S y n c h r o

b r o k e n

c o m

u n d e r

1 1 . H

u s e

o f

M
D

o w

n l in k

b i - c a s t

it h

t h e

o n l y

7 a .

E G

I S T

i s

F F S

E R

I N

V I T

t o

3 G

R e

lo c

> 2 G

b e a r e r s
H

R e q

a r d

e lo c

e s p

A c k

a n d

i t s

n i z a t i o
G

s h o u l d

8 . F o r w

a r e

n o n - v o ic e

i la r

9 :
1 0 :

T F

E D

p l ie s

p r e s e r v e
t h i s

I C C F / D

C S C F

e s p

7 b .

e q
5 .

S U

S G

e q

6 . P

r e m

( F F S )

4 . P

t h i s

e q u e s t / A c k

E R A

u i r e d

3 . F o r w

H O

2 :

b e a r e r

S N

r e p o r t s

e c i s i o n

S - I W

S G

E R

A N

e t e c t io n

1 2 .
1 2 a . S E S

( H

o m

o m

p le t e

F l o w

p le t e )

r e s u m
1 2 b .

A N

S W

E R

Figure 7.19.1.9.2.1-2: IMS/LTE to 2G Handover with Mw (voice bearers only)

3GPP

e d

Release 8

138

3GPP TR 23.882 V8.0.0 (2008-09)

Step 1-7. Same as in Figure 7.19.1.9.2.1-1.

7a. The S-IWF obtains the ICS subscription information for this user (e.g. over S3). Since here the user is ICS user,
it begins to perform the ICS procedures. The SIP User Agent function associated with the S-IWF performs a SIP
REGISTER with a new IMPI/IMPU pair using procedures similar to Early IMS procedures for trusted node.
7b. Subsequently S-IWF initiates an enhanced VCC Domain Transfer procedure to perform bearer preparation.
Step 8-12. Same as in Figure 7.19.1.9.2.1-1.
7.19.1.9.2.2

Subsequent 2G CS => LTE handover

Depicted in Figure 7.19.1.9.2.2-1 is a call flow for subsequent 2G CS => LTE handover of a call initiated in LTE. It is
assumed that the 2G network has no support for DTM, 2G PS handover or VoIP optimisations. LTE neighbouring cells
have to be configured in GERAN for the purpose of measurements. This flow applies to both when Mg or Mw interface
is used at the S-IWF.

U
S U

S P

i s
E

a n

I M

r e

D E
o

n g o

g i s t e

r e

b e

a r e

i n g

2 G

o v e
r

a n d

S - I W

v M

S G

S C

S N

S G

a s u r e

n t

r e

r e

p
e

a r e
q

2 :

S u b

/ R e

R e

u i r e

c i s i o

f o

5 :

r o k e n

i t c h

r a d

u n d

/ D

S - I W

F
w

s w

I C

s p

4 :

S C

r t s

a s

3 :

S y n c h

c a l l

1 :

F l o w

r o
e

i o

c o

6 .

u i r e

s i g n a ls
i t h

u t

s u c c e
a l lo

s s f u

c a t i n g

S u b

L T E

s e
r e

q
s o

u e

n t

u r c e

C
s

S
f o

H
r

O
C

r e
S

s p

R A

n s e

c k

a n d

i t s

n i z a t i o
r

A U

r o

c e

u r e

( i f

n e

7 .

S i g n a l l i n g

a r e

s u m

8 :

I N

I T E

( V D

I )

F l o w
9 .

r e

a t i o

N W

- i n i t i a t e

P S

s p

c h

R A B

i a

- C

S C

a n d

R F

n o

s h

1 0 :

1 1 .

R e

l e

s e

R e

s o

u r c e

i n

o w

2 0

0 O

S - I W

r e s u m

e d

a f t e

R e

l e

a s e

f r o

V C

A S

Figure 7.19.1.9.2.2-1: Handback from 2G to IMS/LTE (voice bearers only)

At the beginning of the call flow the UE is IMS registered over a suspended PS bearer (the latter was suspended during
the LTE => CS handover).
1. Target measurements and handover trigger detection at the source GERAN and the UE for initiation of handover
to LTE.
2. Handover Required message sent by the source GERAN to source MSC containing required information such as
source to target information.
3. Standard inter-MSC CS-CS handover procedure between the MSC and the S-IWF with exchange of Prepare
Subsequent HO Request/ Response messages. The S-IWF signal successful Subsequent CS handover without
allocating any LTE resources.

3GPP

Release 8

139

3GPP TR 23.882 V8.0.0 (2008-09)

4. Handover Require Ack sent by source MSC to source GERAN

5. Handover Command sent by the source GERAN for the UE to retune to the target radio.
UE re-tunes to LTE radio and performs a TAU procedure (if required)
6. to 7.UE performs a Service Request (or similar) in order to resume the suspended SIP signalling bearer and any
other suspended non-voice bearers
8. Subsequently UE initiates the enhanced VCC domain transfer procedure. Note that the SIP INVITE goes only as
far as the DTF.
9. The IMS triggers a network-initiated bearer for the voice bearer (IMS access leg)
Relocation Required Ack toward the source eNB to instruct the UE to retune to the target radio.
10. SIP ack
11. The resource release in the CS domain and the S-IWF is triggered from the DTF.
7.19.1.9.2.3

LTE => 3G CS handover

Depicted in Figure 7.19.1.9.2.3-1 is a call flow for LTE => 3G CS handover of a call initiated in LTE. Both voice and
non-voice bearers are relocated. This depicts the usage of Mg interface.

Figure 7.19.1.9.2.3-1: IMS/LTE to 3G Handover with Mg interface (both voice and non-voice bearers)
Before the initiation of the HO the UE may register with the CS domain via Gs (FFS).
1. Target measurements and handover trigger detection at the source eNB and the UE for initiation of handover to
CS.
2. Relocation Required message sent by the source eNB to source MME containing required information such as
source to target information.
3. Standard PS-PS handover procedure at the source MME for initiation of Forward Relocation Request toward SIWF.

3GPP

Release 8

140

3GPP TR 23.882 V8.0.0 (2008-09)

4. The S-IWF splits the VoIP component from all other PS bearers and initiates a Prepare Handover Request toward
target MSC. It is assumed that the CS Security context is available at the S-IWF; possible mechanisms for the
discovery/retrieval of the CS security context at the S-IWF are described in the previous subclauses. The
relocation of remaining PS bearers is initiated towards the target SGSN with a Forward Relocation Request
message.
NOTE:

In case the PS bearer splitting functions is located in the MME, the Forward Relocation Request message
for non-speech bearers is sent from the MME towards the target SGSN (step 4b).

5. Target UTRAN preparation via the target MSC (CS relocation) and the target SGSN (PS relocation).
6. Successful CS relocation indicated by target MSC with a Handover Number returned in Prepare Handover
Response. Successful PS relocation indicated by target SGSN with a Forward Relocation Response.
NOTE:

in case the PS bearer splitting functions is located in the MME, the Forward Relocation Response
message from the target SGSN (step 6b) is sent towards the MME.

7. Establishment of circuit connection between the target MSC and the MGW associated with the S-IWF initiated
by the S-IWF using ISUP IAM and ACM. Completion of this step leads to the following subsequent steps:
7a. The S-IWF, upon response of the handover request, establishes a CS call to the VDN (including bearer
reservation at CS-MGW). VDN and MSISDN are received from the HSS via MME as part of the subscription
profile download to MME during LTE attach procedure.
8. Forward Relocation Response generated toward source MME with the required information such as target to
source BSS information as indication of network bearer preparation and to instruct the UE to retune.
9. Relocation Required Ack toward the source eNB to instruct the UE to retune to the target radio.
10. Relocation Command sent by the source eNB for the UE to retune to the target radio.
11. Handover Detection at the target UTRAN.
12. Relocation Complete sent by the target UTRAN to the MSC and to the SGSN
13. Target SGSN updates the bearer with S-GW or P-GW
13c. S-IWF performs an Update Location to the HSS/HLR if needed. This allows S-IWF to receive GSM SS
information and also allows HSS/HLR to route the mobile terminating call properly. This step is not needed if
the UE was already registered with the S-IWF via Gs (FFS).
Depicted in Figure 7.19.1.9.2.3-2 is a call flow for LTE => 3G CS handover of a call initiated in LTE. Both voice and
non-voice bearers are relocated. This depicts the usage of Mw interface.

3GPP

Release 8

141

s u

r e

r e

c i s

i s t e

r e

r t s

i o

f o

i t

S - I W

i n

v i a

( F

v M

3GPP TR 23.882 V8.0.0 (2008-09)

S G

S C

S N

b e a r e

( o

f r o

lo

t i o

i r

. F

a r d

l o

b e

a r e r

a l l

t h e

i s

a i n i n g

f o

a . P

r e

b . F

p a r e

s p l i t s

t h e

b e

r w

a r d

l o

a r d s

I P

I S

p a i r

r w

b e

i n

u s i n

a r d e

a r e r s

a r e r s ;

a . R

t o

v M

a r e

r e l o

p e

i t h

a r l y

r f o

n e

r m

I M

u b s e

I M

p r o

c e

n o

i n i t i a t e

d e

a n

n h

n c e

lo

q u e

9
1

l o

r o

lo

s w

i t

c h

i o

r a
S y

n
n

c
d

h
e

r o

. H

c o

i z a

i o

S C

I C

l o

a . R

e l o

;
a . P

r e

p a r e

s p

c a t e d

b . F

r w

a r d

l o

b .

e l o

c k

w
R

n l i n
F

i s

k
F

b i - c
F

a s t

i t h

t h e

u s e

s p

I P

I / I M

u r e

P
s

f o

I A

/ A

r
a .

I S

I T

n t l y

. F

r w

a r d

l o

b .

I N

e s p

c k

i t s

e l o

7
t r u s t e

n l y

- I W

e q

I P

S G

6
t o

e q

6
r e

r w

6
t h i s

S )

- I W

t e

c t i o

. S

( H

e l o

p l e

t e

e l o

p l e t e )

a t e

b e

p l e

t e

r e

l o

s u

w
m

a r e r

Figure 7.19.1.9.2.3-2: IMS/LTE to 3G Handover with Mw interface (both voice and non-voice bearers)
Steps 1-7. Same as in Figure 7.19.1.9.2.3-1.
7a. The SIP User Agent function associated with the S-IWF performs a SIP REGISTER with a new IMPI/IMPU pair
using Early IMS procedures for trusted node
7b. Subsequently S-IWF initiates the enhanced VCC Domain Transfer procedure.
Steps 8-13.
7.19.1.9.2.4

Same as in Figure 7.19.1.9.2.3-1.

Subsequent 3G CS => LTE handover

Depicted in Figure 7.19.1.9.2.4-1 is a call flow for subsequent 3G CS => LTE handover of a call initiated in LTE. Both
voice and non-voice bearers are relocated. This flow applies to both Mg and Mw interface. LTE neighbouring cells have
to be configured in UTRAN for the purpose of measurements.

3GPP

Release 8

142

I M

r e

i s t e

s u

r e

r e

p o

- I W

3GPP TR 23.882 V8.0.0 (2008-09)

lo

lo

c a

c i s i o

t i o

f o

q u

i r e

3
4
R

lo

lo

lo

r d

r e

S u

lo

c a

t i o

q u

i r e

i n

r w

lo

P r e

i t i a

t e

lo

c o

l o

s w

w
S y n

r o

i t c h

r a

c
u

h
n

d i o

r o
d e

n
r

lt a
c h

r o

r e

i z e

lo

r e

c a

lo

t i o

c a

t i o

o
n

s i g

S
n

a
a

l l i n

s .

i t h

F
u

s i g

l l o

S u

lo

ls

c a
R

s u
t i n
A

c e

B s

s s f u

r e

r e

r e

r e

s o

r c e

lo

c a

t e

lo

c a

t i o

r e

f o

t o

u
B

e
.

s t
O

ly

s p
a

s p

lo

lo

c k

c k

lo

c a

t i o

P r o

c e

d u

r e

i t s

i z a

t i o

s y n

P S

S R

s i m
F

s p

w
:

I C

c k
7

S - I W
A

S - I W

d
R

r t s

lo

t e

c o

c t
1

le

lo

t e

c t

t e

lo

l e

t e

lo

p l e

t e

r e

t i o

o f

- i n

r o

i t i a

c e

t e

d u

r e

P S

d a

( i f

s p

r e

t e

q u

c h

B e

i r e

lo

r e

P r o

c e

l e

t e

r e

v i a

- C

S C

le

s e

P C

s o

I N

s h

r c e

i n

I T

( V

I )

r e

S - I W

f t e

le

s e

f r o

l o

s u

w
m

Figure 7.19.1.9.2.4-1: Handback from 3G to IMS/LTE (both voice and non-voice bearers)
1. Target measurements and handover trigger detection at the source UTRAN and the UE for initiation of handover
to LTE.
2. Relocation Required message sent by the source UTRAN to source MSC and source SGSN containing required
information such as source to target information.
3. Source MSC sends a Prepare Subsequent HO Request to S-IWF. Source SGSN sends a Forward Relocation
Request messages to S-IWF.
NOTE:

in case the PS bearer splitting functions is located in the MME, the Forward Relocation Request message
from the source SGSN (step 3b) is sent towards the MME.

4. The S-IWF sends a Forward Relocation Request to the target MME including information about the non-voice
bearers only.
5. Target MME sends a Relocation Request to target eNB.
6. Target eNB replies with Relocation Request Ack.
7. Target MME sends a Forward Relocation Response to the S-IWF.
8. The S-IWF signals successful Subsequent CS handover to the source MSC without allocating any LTE
resources. The S-IWF also signals a Forward Relocation Response to the source SGSN.
NOTE:

in case the PS bearer splitting functions is located in the MME, the Forward Relocation Response to the
source SGSN (step 8b) is sent from the MME.

9. Relocation Required Ack sent by source MSC and SGSN to source UTRAN.
10. Relocation Command sent by the source UTRAN for the UE to retune to the target radio.

3GPP

Release 8

143

3GPP TR 23.882 V8.0.0 (2008-09)

11. UE re-tunes to LTE radio

12. to 15. Relocation Detect, Relocation Complete
16. At the end of the relocation procedure the UE performs a TAU (if required)
17. Subsequently UE initiates the enhanced VCC domain transfer procedure over the relocated SIP signalling bearer.
Note that the SIP INVITE goes only as far as the DTF.
18. The IMS triggers a network-initiated bearer for the voice bearer (IMS access leg)
19. Relocation Required Ack toward the source eNB to instruct the UE to retune to the target radio.

7.19.1.9.3

Service Model

The specific of the individual service models are provided below.

7.19.1.9.3.1

IMS Centralized Services (ICS) model

The ICS can be supported with either Mw or an Mg interface from the S-IWF towards IMS. For the support of Mw
interface, the S-IWF provides functions similar to the MSC Server enhanced for ICS defined in TS 23.292; the Mg
interface is provided by an MGCF located in the serving or home network.
7.19.1.9.3.2

VCC Rel-7 model

The S-IWF utilizes the concept of R7 VCC architecture. Prior to HO procedure, S-IWF initiates a CS call to VCC AS
with VDN on behalf of the user. If UE is not registered with S-IWF via Gs (FFS), when HO is completed, S-IWF
initiates a MAP Update Location. This allows execution of GSM Supplementary Service (SS) by the S-IWF as it has the
GSM subscriber data from the HSS, and also update the location information in the HSS so that CS mobile terminating
call routing can be done.

7.19.1.9.4
7.19.1.9.4.1

UE and S-IWF CS state synchronization

UE state synchronisation

TS 24.008 (chapter 5) describes call control states for the MS (UE) and for the Network side. During the SRVCC
process, the UE receives the HO Command with the target circuit-switched bearer radio information. The UE CS call
control state can be moved to U10 (Active state) during processing of the HO Relocation Command message.
On the network side, the S-IWF initiated the DT with a CS call setup to VDN. When this call is answered by the
IMS/VCC-AS, the S-IWF moves the call control states to N10 (Active state).
At this point, both the circuit-switched call control state in UE and in S-IWF is synchronized to Active state (U10 and
N10). Both S-IWF/UE continue their call state transition from this point, as defined in TS 24.008.

7.19.1.9.5

VDN allocation for S-IWF

In order to follow the R7 VCC DT procedure, the S-IWF needs MSISDN and VDN of that user in order to generate the
DT request. Both the MSISDN and VDN may be stored in the HSS as part of the subscription profile for E-UTRAN
access and is downloaded to the MME during initial attach process as described in TS 23.401.
MME passes both MSISDN and VDN if available to S-IWF via S3.
NOTE:

7.19.1.9.6

The absent of VDN is used to indicate to the S-IWF that the home IMS does not support VCC procedure
for this subscriber.

Interworking with non VCC capable IMS network

If the home IMS does not support VCC procedure, the S-IWF shall not perform DT and shall become an S3 relay
function.
S-IWF is made aware of whether home IMS support VCC for this subscriber or not by the VDN indication from S3'.

3GPP

Release 8

7.19.1.9.7

144

3GPP TR 23.882 V8.0.0 (2008-09)

Interworking with non VCC capable UE

It is proposed the SRVCC capability is indicated as part of the UE Network Capability. This information is sent to the
MME during attach procedure. This information is then passed to S-IWF via S3.
S-IWF will act as S3 relay function when UE is not capable to do SRVCC.

7.19.1.9.8
NOTE:

ICS and Distributed Service model selection

It is TBD whether both options are needed in this architecture in R8. This section only applies if both
options are needed to be specified.

If the serving network supports both ICS and Distributed Service model, then if the ICS subscription indication is
received from the home network, then ICS is used, otherwise, Distributed Services model is used.

7.19.1.9.9

Advantages of the solution

There are several significant advantages to the above described solution:

-

There is no impact to the existing GERAN and UTRAN nodes apart from configuration of LTE neighbouring
cells;

There is no impact to the IMS network;

The solution is compatible with IMS Centralised Services and MMSC;

The handover preparation phase should be comparable to the handover preparation phase in 2G/3G networks;

The handover interruption is expected to meet the 300 ms target in all cases except for the 2G => LTE case due
to lack of physical layer information exchange between the source and target RANs. However, even in this case
the service interruption time is expected to be ~750 ms;

The overall SR VCC procedure is triggered from the network.

In case of LTE=>CS handover the setup of the CS access leg in the target access is performed after the HO
preparation, which allows for graceful handling of cases where the target system has not enough resources.

7.19.1.10

Partial Conclusions on Voice call continuity between IMS over SAE/LTE

access and CS domain

During the course of this study, a number of alternative architectural solutions that enable Voice Call Continuity
between IMS over SAE/LTE and CS domain have been proposed and documented in this report. The study has revealed
the complexity of the subject and has shown that all of the solutions have their advantages and disadvantages.
Given that:
-

most of the deployed GERAN networks do not support the following GERAN features: DTM, PS HO or VoIPrelated enhancements, and

GERAN WG is working on solutions for GERAN networks that support GERAN features like: DTM, PS HO or
VoIP-related enhancements,

the future SA2 work will work on solutions that do not rely on any of these as a pre-requisite for SR VCC operation.
Alternatives that do not rely on any of the GERAN features listed above include the following:
-

The alternatives building on the inter-MSC HO principle (D and F), and

Alternative E (as currently described for the IMS => CS direction only).

NOTE:

Alternative C too does not rely on the GERAN features listed above, however it is not considered a viable
solution due to the significant service break that it incurs.

NOTE:

Alternative A/B may still be allowed if the target network supports DTM, PS HO or VoIP-related
enhancements.

3GPP

Release 8

145

3GPP TR 23.882 V8.0.0 (2008-09)

It is noted that the Stage 1 requirement is for bi-directional voice call continuity with interruption time not higher than
300 ms. As proposed, Alternative E does not address bi-directionality without relying on some of the GERAN features
listed above. It is FFS if alternative E could be enhanced with bi-directionality that does not require any of the GERAN
features listed above and if such solution would meet the Stage 1 requirements.

7.19.1.11

Evaluation of the remaining options

The following table describes the impact and characteristics of the remaining SR VCC options.

E
UE impacts

SR-VCC specific triggering of

CS signalling procedures
Routing of CS signalling over
UE LTE stack (instead of the
regular CS radio), when used
for SR-VCC
Extended timer for CS Call
Setup, when used for SR-VCC
(Call setup starts in LTE and
completes over CS radio)
Modifications of CC state
machine because of null RAB
Assignment

D/F
UE will have to be moved
to the CS speech/active
mode in the CS side
without going thru the
traditional 24.008 state
machine setup with the
MSC
UE not CS registered
while in a CS call or using
SMS
Impacts on 24.007/24.008
MM, SMS and CC are
FFS

BSS/UTRAN
impacts
eUTRAN
impacts

EPC impacts

No impact from SRVCC

Proposed/selected target cell

be compatible with the UE
capabilities(same as D/F)

Explicit or implicit indication

from eUTRAN to UE when UE
enters/leaves into/from LTE
border area ("SR-VCC Area").
"SR VCC area" needs to be
configured and maintained if
explicit indication is used.

MME-IWF encapsulation of CS
signalling for UEs in "SR VCC
area" (extensions of S3
functionality)
MME relay function between
NAS signalling and IWF
MME maintains per-UE
connection on S3' during the
SR VCC Preparation

No impact from SRVCC

Proposed/selected target
cell be compatible with the
UE capabilities(same as
E)

MME routes any 2G/3G

target to IWF, therefore no
MME impact

3GPP

Comments

UE does not establish user

plane prior handover from
LTE to CS
Need to configure LTE
neighbouring cells for the
purpose of measurements
for CS LTE

Release 8

146
E

IWF complexity

Interfaces:

S3

S3': S3 plus encapsulation

feature (extension of S3
functionality)

Iu-CS or A (control plane only)

Impacts on IMS
Impact on VCC
Application /
Service
Continuity Rel 8

Functions:

Encapsulation / decapsulation
of CS signalling to / from UE
via MME

S3 proxying between MME and

SGSN

Coordination between S3 and

Iu-CS procedures

IWF holds a context for a SRVCC UE when the SR-VCC UE

is engaged in a VoIP session
with in the LTE SR-VCC area
Note: UP is not initialized
No impact to R7 IMS.

Deployment
impacts (not
covered in
other rows)

Enhancement needed if
bicasting is used

D/F
Interfaces:

S3

S3': S3 plus additional

parameters (e.g.
MSISDN, VDN) between
MME and IWF

MAP E, D, C, LI (FFS),
Charging, ,Mc, ISUP

Mw (if ICS is to be
supported in option F)
Functions

MSC Server functions and

interfaces (MAP (HO
control part only),
subscriber profile
handling, Charging,
Lawful Interception, MGW
management)

SIP user agent with Early

IMS security. Note: a SIP
user agent with Early IMS
security (Mw reference
point) is needed if ICS are
to be supported in option
F by the serving PLMN

S3 proxying between
MME and SGSN

Coordination between S3
and MAP-E procedures

IWF maintains per-UE

context and UP
connection after the SR
VCC handover until end of
call.
No impact to R7 IMS.

Enhancement is needed
if bi-casting is used.

Usage of MSISDN as
VDN is FFS for D-2
VDN+

IWF must be placed in the S3

signalling path between MMEs
and SGSNs
An IWF is to be configured as
the target BSS/RNS for all LTE
cells in existing 2G/3G MSCs
Additional signalling load on
MSCs and HSS even in case
SR VCC domain transfer does
not occur

3GPP TR 23.882 V8.0.0 (2008-09)

3GPP

IWF is perceived as an
MSC/MSS/MGW and will
need to have MAP and
ISUP to interwork with
target MSC.
For the MME/SGSN it
looks like an SGSN.
The IWF is configured as
the target SGSN for
handovers to 2G/3G.
Additional inter-MSC
trunks (if IWF not
integrated in all MSCs).

Comments

Release 8

147
E

3GPP TR 23.882 V8.0.0 (2008-09)

D/F
Once the UE accessed
2G/3G all 24.008
signalling is between UE
and IWF and services are
available as supported by
IWF and IMS.

All ICS modes of

operation are supported
by Alt D+F. I1-cs is not
supported in eUTRAN.
Support of I1-ps requires
PS-PS handover
executed together with SR
VCC. Otherwise fallback
to I1-cs as described in
3GPP TR 23.892.

An LA is required
during/after SR-VCC if a
new CS controlled service
is added to the call which
has been handed over to
CS (e.g. adding CSData/fax to a voice only
session after its handed
over to CS). Note that
handling of a call with
some of its services
controlled in CS is a
general ICS issue which
requires further study; not
specific to SR-VCC.

Handling of an
Emergency call which is
placed when a call is
active which has been
handed over from LTE is
FFS. Note that this is
general ICS issue which
has been identified for
further study (refer to S2075294- Emergency Call
issue with ICS for details )
Editors note: It is FFS whether
and when to insert subscriber
data in the IWF.

Comments

Impacts on
availability of
user services

Same as Rel-7 VCC. Alt-E is

only a signalling extension to
Rel-7 VCC for seamless
Domain Transfer for Single
Radio devices
All ICS modes of operation are
supported; including I1-cs, I1ps and IMSC. Support of I1-ps
requires PS-PS handover
executed together with SR
VCC. Otherwise fallback to I1cs as described in 3GPP TR
23.892.

Impacts on
other network
features

Nothing specific due to SRVCC

From a high-level point of view the remaining options D/F and E can be differentiated regarding their impacts as
follows (issues were there are no differences are omitted):
Option D / F
-

Based on MSC-MSC handover principle

IWF has to act as an anchor MSC server and has to provide required interfaces and functions; in addition, IWF
has SGSN functionality

Additional MGW and Inter-MSC Trunk resources

No impacts on EPC; impacts on E-UTRAN.

UE is not attached to CS prior handover from LTE to CS

Option E
-

Based on RNC/BSC handover principle

3GPP

Release 8

148

3GPP TR 23.882 V8.0.0 (2008-09)

IWF has to act as RNC or BSC and has to provide required interfaces and functions; in addition, IWF has SGSN
functionality

Impacts on E-UTRAN and EPC for tunnelling of CS signalling. Requires explicit or implicit indication from EUTRAN to UE when UE enters/leaves into/from LTE border area ("SR-VCC Area")

UE attaches to CS prior handover from LTE to CS

Both options have impacts on UE, deployment, and VCC Application; the later only if bicasting is used.
Regarding the expected HO performance of options D/F and E, it was concluded that there are no significant differences
in performance assuming UE in Alt E has performed the SRVCC preparation phase in advance of the actual HO
triggering by eNb. Both options provide similar level of performance in terms of radio Handover efficiency in
maintaining the service continuity and QoS between the source and the target accesses.
Regarding commonalties and differences of the option E with Voice Service Continuity between cdma2000 1xRTT
Revision A and E-UTRA, it was concluded that there are similar principles for triggers and encapsulation, but also
differences in the details.
Editor's note: A more detailed analysis regarding commonalities and differences of the option E with Voice Service
Continuity between cdma2000 1xRTT Revision A and E-UTRA is FFS.
Editor's note: A more detailed analysis regarding usage of ICS UE in option E and option D/F is FSS.

7.19.1.12

Conclusions on Voice call continuity between IMS over SAE/LTE access and
CS domain over GERAN/UTRAN access

It is concluded that the Stage 2 specification work should focus on the Alternative D/F in the variant with Mg reference
point described in clause 7.19.1.9 with the following clarification:
-

The "PS bearer splitting function" described in 7.19.1.9 is located at the MME.

7.19.2 Handover of MSC controlled voice calls between SAE/LTE access and
CS access
Editor's Note: In order to avoid duplication of the work the "Handover of MSC controlled voice calls between
SAE/LTE access and CS access" will not be developed further in this TR and will be investigated within
the 3GPP TR 23.879: "Study on CS Domain Services over evolved PS access".

7.19.2.1

Description of key issue Handover of MSC controlled voice calls between

SAE/LTE access and CS access

The intent of this clause is to study alternative solutions for Handover of MSC controlled voice calls between SAE/LTE
access and CS access. The solutions studied here shall be compatible with CSI (as specified in 3GPP TS 23.279 [35]).
The basic assumption in this clause is that the control of voice telephony calls is centralized in CS CN domain, for CS
access as well as for LTE/SAE access. Proposed solutions are mostly applicable for operators with a majority of
traditional CS voice service customers, and do not solve issues related to voice telephony services offered in IMS. Nonvoice telephony services are controlled by the IMS, and are interworked with MSC controlled voice service with CSI.
The intent of such solutions is to simplify the problem of service continuity of voice services between CS and LTE/SAE
access by having the same call control entity for all access domains, thus removing issues related to change of call
control entity when changing access domains.
In the following desirable characteristics for proposed solutions are listed:
-

The solution shall not require UE and/or RAT capability to simultaneously signal on two different RATs.

Impact on service quality, e.g. QoS, interruption times should be minimized

RAT/access domain selection/change should be under network control.

In roaming cases, the Visited PLMN should control the RAT/access domain selection/change while taking into
account any related HPLMN policies

3GPP

Release 8

149

3GPP TR 23.882 V8.0.0 (2008-09)

Inter-access domain handover in the VPLMN should be performed without significant amount of signalling to
the HPLMN.

Impact on legacy RAT is highly undesirable

Impact on legacy CS CN is undesirable

7.19.2.2
7.19.2.2.1

Alternative solution A - Evolved CSI solution

Description

The basic principle of this solution is to keep Call and SS Control for voice telephony in the CS Domain. So, for a PS
only radio access like LTE an evolved MSC-Server, does 24.008 signalling via IP transport (tunnelled via LTE/SAE
access) towards the UE.
After the UE has established IP connectivity over LTE/SAE, the UE registers with the eMSC similar to legacy location
update procedure, and is then "pseudo-CS" attached.
MO and MT call setup signalling procedure occurs according to TS 23.018, and is transported over IP. The CS channel
assignment is replaced by an SAE network initiated bearer setup. It is assumed that SAE bearer control and PCC
mechanisms can be reused without additions.
Mobility
As preparation for a possibly needed PS-CS voice call continuity procedure the eMSC registers itself at the MME as
'Handover-serving Node' for an ongoing voice bearer, at bearer setup.
In case a handover between LTE and legacy 3GPP radio accesses is needed the MME triggers the respective eMSC
(including the information about the target cell ID). The eMSC then initiates standard legacy handover procedure (in
case the target cell belongs to the eMSC's area) or standard legacy inter-MSC Handover procedure (in case the target
cell belongs to another MSC area).
Handover is possible for PS to CS direction. Further study is needed for the CS to PS direction (issues to resolve
include PS attachment and establishment of default IP connectivity along with the HO procedure).
Voice & IMS-session in parallel
Interworking of voice telephony calls with parallel IMS multimedia sessions is done in the terminal. Interworking in the
network is needed if the remote end is doing voice over IMS (see CSI Interworking).

3GPP

Release 8

150

3GPP TR 23.882 V8.0.0 (2008-09)

Figure 7.19.1.7.1: Evolved CSI approach

7.19.2.2.2

Impact on the baseline CN Architecture

7.19.2.2.3

Impact on the baseline RAN Architecture

7.19.2.2.4

Impact on terminals used in the existing architecture

7.20 Key Issue SAE Identities

7.20.1 Description of issue
The UE and the network entities in an SAE network need different identities for addressing, mobility, connectivity,
confidentiality and other reasons.
In GSM and UMTS networks the identities are to a large extent the same. Using the same identities specifically also for
LTE accesses would be beneficial from e.g. a UE mobility and identification point of view. In addition new identities
are needed for new network entities.

7.20.2 Agreements on SAE Identities

The following table defines the identities that the UE and the network need in a SAE network.

3GPP

Release 8

151

3GPP TR 23.882 V8.0.0 (2008-09)

NOTE:

Identities identifying connections or tunnel end-points have not been addressed except for some specific
cases which may have impact on the network architecture.

NOTE:

Additional Non-3GPP identities are FFS

NOTE:

The exact mapping between node identities and Transport Network Layer (TNL) addresses (e.g. IP
addresses) is FFS.

Name

IMSI

Allocated
by which
SAE/LTE
entity
N/A

IMEI

Purpose

UE and Network Identities

Scope
Used by

Permanent Identity
of the Subscriber

Globally
unique

N/A

Permanent Identity
of the end user
equipment

Globally
unique

S-TMSI

MME

Temporary user
identity

Unique
within a
tracking
area or
within
MME
pool
area(s)

UE, Evolved
Packet Core, NAS
layer

MS-ISDN

N/A

Globally
unique

UE, Evolved
Packet Core, HSS,
O+M

IP address

IASA

Permanent
subscriber Identity
primarily used by
CS and SMS
services and by
O+M systems.
Permanent or
temporary
Identifier used to
identify the
UE/user within the
PDN

Unique
within
PDN

UE, Evolved
Packet Core, PDN,
operator
services/IMS

3GPP

UE, Evolved
Packet Core and
NAS layer (and
possibly RRC
during initial
attach and to
determine paging
occasion).
UE, Evolved
Packet Core and
NAS layer.

Comment

For security reasons the IMSI

should not be used/stored in
the LTE RAN (rare exceptions
might be possible)

For security reasons the IMEI

should not be used/stored in
the LTE RAN (rare exceptions
might be possible)
The S-TMSI is similar to P-TMSI
used today in GSM/UMTS. It
needs not to share TMSI space
with CS domain as in
GSM/UMTS.
Either part of the S-TMSI is
used to identify the MME within
a pool of MMEs or a separate
MME-ID (similar to the 3G NRI)
is used (FFS).
Solutions are needed to
support network sharing.
Uniqueness of S-TMSI within
areas depends on tracking area
concept, which is FFS.
Format influences re-use of
resolution of temporary
addresses be 2G/3G SGSNs.
The need to store S-TMSI on
legacy UICC is FFS.
Used to identify a subscriber
within a charging record. Its
usage is FFS; another identifier
might be used in SAE. Usage of
MS-ISDN for VCC in Evolved
Packet Core is FFS.
The UE needs a routeable
address when connected to a
PDN. The IP address may be a
IPv4 or a IPv6 address, and may
be a private or public IP
address.
There are also other IP address
allocation options, e.g. by autoconfiguration.

Release 8

Name

Tracking
Area
Identity

152

Allocated
by which
SAE/LTE
entity
N/A

Purpose

3GPP TR 23.882 V8.0.0 (2008-09)

UE and Network Identities

Scope
Used by

Permanent Identity
used to identify
tracking areas.

Unique
within a
PLMN

Evolved Packet
Core, UE. The
tracking area
identity is also
broadcasted
transparently in
the LTE RAN.

MME
Identity

N/A

Permanent Identity
used to identify
MME

Unique
within a
PLMN

Evolved Packet
Core, LTE RAN, UE
(indirectly via STMSI and Tracking
Area Identity
(FFS))

Cell Identity

N/A

Permanent Identity
used to identify
the Cell

FFS:
Unique
within a
PLMN

Evolved Packet
Core, LTE RAN

eNode B
Identity

N/A

Permanent Identity
used to identify
the eNode B

Unique
within a
PLMN

Evolved Packet
Core, LTE RAN

3GPP

Comment

May share some similarities

with the existing Routing Area
Identity.
Solutions are needed to
support network sharing.
Format influences re-use of
resolution of temporary
addresses be 2G/3G SGSNs.
The need to store TAI on legacy
UICC is FFS
FFS whether a separate MME
Identity is needed. As today, the
old Tracking Area Identity +
(parts of) the S-TMSI can
identify the MME (FFS).
In the LTE RAN the eNode B can
(as in the RNC today) use (part
of) the S-TMSI identify the MME
(FFS)
An MME is associated with one
or more TNL, e.g. IP, addresses.
Needed to be known in the CN
for some UEs in active mode
when location-based charging
is used. [For paging, the MME
needs to know which S1
interfaces to send the page
message to. Hence the MME
probably needs to be able to
map Tracking Area to Cell
IDs/eNodeB IDs. Note that the
cells within an eNodeB may
need to be in different tracking
areas.]
It is FFS if the Cell Identity is
associated with a TNL address.
FFS whether Cell Identity has to
be unique within LTE RAN or
globally unique or whether both
are needed.
FFS whether a specific eNodeB
identity is needed or whether
(TNL) addresses are sufficient.
Used to derive (TNL) addresses
for S1 addressing.
The eNode B Identity is
associated with one or more
TNL, e.g. IP, addresses.

Release 8

Name

eNode B
Specific S1
UE Context
Identity

153

Allocated
by which
SAE/LTE
entity
eNode B

Purpose

3GPP TR 23.882 V8.0.0 (2008-09)

UE and Network Identities

Scope
Used by

Temporary identity
used to identify an
S1 UE context
within eNodeB.

FFS:
Unique
within a
eNode B
[and x2
interface
handove
r target
eNodeB
s?]

Evolved Packet
Core, LTE RAN

Comment

It is used to identify the MME

and/or UPE UE context(s) in the
eNode B that relate to signaling
relations(s) over S1.
Whether MME, UPE or both UE
context identities are needed
depends on function separation
between MME and UPE. NAS
signaling, for example, might be
exchanged over S1 by using
UE/user identity without a need
for an additional UE Context
Identity.
The S1 addressing principle is
still FFS.
Uniqueness within a (TNL)
eNodeB address might be
sufficient.
It is used for signaling over S1
to identify the UE context in the
MME. Its need is FFS.
The S1 addressing principle is
still FFS.
Uniqueness within a (TNL) MME
address might be sufficient.
It is used for signaling over S1
to identify the UE context in the
UPE. Its need is FFS.
The S1 addressing principle is
still FFS.
Uniqueness within a (TNL) UPE
address might be sufficient.
FFS if needed or if the UPE TNL
address, e.g. IP address, is
enough.

MME
Specific S1
UE Context
Identity

MME

Temporary identity
used to identify an
S1 UE context
within MME.

FFS:
Unique
within a
MME

Evolved Packet
Core, LTE RAN

UPE
Specific S1
UE Context
Identity

UPE

Temporary identity
used to identify an
S1 UE context
within UPE.

FFS:
Unique
within a
UPE

Evolved Packet
Core, LTE RAN

UPE
identity

N/A

Unique
within a
PLMN

Evolved Packet
Core, LTE RAN

PDN
Identity

N/A

Globally
unique

UE, Evolved
Packet Core

Depending on Multiple PDNs

solution. It may be an APN.

PCRF Id

N/A

FFS if needed or if the PCRF

TNL address is enough.

N/A

Evolved Packet
Core

RAT ID

N/A

Unique
within a
PLMN
Unique
within a
PLMN
Globally
unique

Evolved Packet
Core

HSS Id

Permanent Identity
used to identify
the UPE from the
LTE RAN
Permanent Identity
used to identify
one or multiple
specific PDN(s)
Permanent Identity
used to identify
the PCRF
Permanent Identity
used to identify
the HSS
Radio Access
Technology
Identity used to
identify the type of
radio access
technology

FFS if needed or if the HSS is

identified by (part of) user
Identities.
FFS if needed or is used by the
PCC of SAE.

7.21

Evolved Packet
Core

Key Issue Network Discovery and Selection

7.21.1 Description of Key Issue Network Discovery and Selection

In legacy 3GPP accesses well established principles for Network Discovery and Selection (NW-DS) are applied, both in
idle and active mode (e.g. 3GPP TSs 22.011, 22.102, 23.122, 43.129 and 23.060). It is expected that these can be

3GPP

Release 8

154

3GPP TR 23.882 V8.0.0 (2008-09)

extended for LTE access in SAE quite naturally. Regarding non-3GPP access, full alignment and exchange of
configuration data between 3GPP and non-3GPP domains are unlikely.
Also, the presumably more localized nature of non-3GPP access NWs (e.g. WLANs) will lead to an increase in
discovery procedures and in an increased number of decision points for NW selections. It is necessary to optimize NWDS procedures for frequent mobility events.
Access NW discovery of non-3GPP RATs, e.g. WLAN, depends largely on passive scanning or active probing of radio
channels (potentially in parallel to active transmission), which is costly in terms of power consumption and processing.
It is desirable that the concept for NW-DS in SAE supports effective means for minimizing processing.
For seamless handovers to/from/between non-3GPP access(es) within SAE, according to stated requirements, the
latency of NW-DS procedures is crucial. But the time criticality is different in different handover situations. Looking at
the currently defined NW-DS principles for I-WLAN in [28] it becomes clear that they cannot be extended for time
critical handovers and for other RATs, due to complexity and latency:
-

per available WLAN access NW a scan/probe has to be performed

if a WLAN AN is connected to more than one 3GPP NW this is only detected after L2 association and trying
authentication

It is therefore necessary to develop or adopt new, more efficient mechanisms, for both idle and active mode (where this
differentiation is applicable).
Editors note: a problem statement potentially related to this key issue is found in draft-ietf-eap-netsel-problem-05.
Editors note: it is necessary to cross-check with the work being done in SA1 under WID I-WLAN NSP and WID
Non-3GPP access NSP.

7.21.2 Solutions for Key Issue Network Discovery and Selection

These may include:
-

solutions based on concepts developed in other fora (e.g. IEEE 802.11u, IEEE 802.21, IETF)

solutions based on concepts defined by 3GPP (e.g. provision of specific databases)

Further mechanisms are FFS. When selecting solutions, the amount of signalling, size of stored and transferred data,
especially over the radio interface, and terminal power consumption shall be taken into account.

7.22 Key Issue Voice service continuity between cdma2000

1xRTT Revision A and E-UTRA
7.22.1 Description of key issue Voice Service Continuity between cdma2000
1xRTT Revision A and E-UTRA
The intent of this clause is to study alternative solutions for Service continuity between IMS over EPS/E-UTRA access
and CS domain over cdma2000 1xRTT Revision A access ([36], [37], [38], [39], [40], [41], [43], [44]) as per the Stage 1
requirements in 3GPP TS 22.278 [34]. The initial focus is put on voice call continuity, however the study on continuity
of other services shall not be precluded.
NOTE:

The CS component of cdma2000 1xRTT Revision A is not expected to be connected to the EPC.

In the following desirable characteristics for proposed solutions are listed:

3GPP

Release 8

155

3GPP TR 23.882 V8.0.0 (2008-09)

The solution should support bi-directional service continuity between cdma2000 1xRTT Revision
A and E-UTRA. If bi-directional support is not practical, then service continuity from E-UTRA to
cdma2000 1xRTT Revision A shall have the higher priority.

The solution shall allow coexistence and be compatible with REL-7 VCC (as specified in 3GPP TS
23.206 [29]).
-

The solution shall allow coexistence with REL-8 VCC and ICS.

In order to permit UEs with a single radio configuration the solutions shall not require UE and/or RAT capability
to simultaneously signal on two different RATs.

The solution should aim for commonality in the solution for support of single radio and dual radio terminals.

The solution should be transparent to E-UTRA only terminal or network.

The solution should not have any impact on deployed cdma2000 1xRTT Rev A and cdma2000 HRPD Rev 0 and
Rev A terminals.

The solution should minimize the coupling between the E-UTRAN and the 3GPP2 access. In particular, the
solution should allow the cdma2000 1xRTT Rev A specification to evolve without necessitating a modification
to the E-UTRA(N) specifications.

Impact on service quality, e.g. QoS, interruption times should be minimized

RAT/domain selection/change should be under network control.

RAT/domain selection/change may be restricted to some access systems and some subscribers, depending on
operators policies.

It shall be possible for operators to restrict and disable the handover of voice calls across different access
domains even if voice call services are available separately from those domains.

Editor's Note: The triggering for domain change, either UE initiated or network initiated, is FFS.
-

In roaming cases, the Visited PLMN should control the RAT/domain selection/change while taking into account
any related HPLMN policies

Inter-domain handover in the VPLMN should be performed without significant amount of signalling to the
HPLMN.

Impact on legacy cdma2000 RAT is highly undesirable

Impact on legacy cdma2000 CS CN is undesirable

7.22.2 Alternative solution A

7.22.2.1

Description

The solution for E-UTRA/EPS 1xRTT voice service continuity described in this section is similar to the existing
3GPP2 solution for HRPD1xRTT voice service continuity specified in [X.P0042].

3GPP

Release 8

156

3GPP TR 23.882 V8.0.0 (2008-09)

Figure 7.22.2.1-1: Proposed architecture for E-UTRA/EPS to 1xRTT voice service continuity
In this solution it is proposed to terminate the S102 interface (defined in [X.P0042]) between the MME and the
Interworking Solution function (IWS), defined in [A.S0008-C v1.0]. This interface is labelled in EPS as S102.
The role of the IWS is:
-

To be a signalling tunnelling end point towards the E-UTRAN/EPS MME for receiving/sending encapsulated
1xRTT CS signalling messages to/from the UE, and

To emulate an 1xRTT BSS towards the 1xRTT MSC (reference point A1). No modifications to the existing
MSCs are expected.

The role of the MME is:

-

To be a signalling tunnelling end point towards the IWS (in [A.S0008-C v1.0]) for sending/receiving
encapsulated 1xRTT CS signalling messages to/from the UE, which are encapsulated in EPS NAS messages
(UE-MME)

For VCC-capable UEs the call is always anchored at the VCC AS in the IMS. The IWS enables a single radio UE to
communicate in parallel both with the source system and the target system. From VCC perspective this mechanism
allows for "make-before-break" operation similar to dual radio VCC i.e. it allows for transport of signalling for
establishment of the target CS access leg while the terminal is connected to the source PS access network.

3GPP

Release 8

157

3GPP TR 23.882 V8.0.0 (2008-09)

Figure 7.22.2.1-2: Transport of 1xRTT CS signalling messages for preparation of the CS access leg in
the target system
The S102 reference point is used to convey 1xRTT CS signalling messages between MME and IWS. These 1xRTT CS
signalling messages are actually exchanged between the UE and the MSC, and S102 is only one link in the overall UEMSC tunnelling path. On the remaining portion of the tunnelling path, the 1xRTT signalling messages are encapsulated
in EUTRAN/EPS tunnelling messages (UE-MME) or carried as part of A1 signalling (IWS-MSC).
It is expected that the existing A21 protocol (specified in [A.S0008-C v1.0]) can be re-used on S102.

7.22.2.1.1

Call flow

Figure 7.22.2.1.1-1 illustrates a high-level call flow for the LTE-to-1x voice service continuity procedure.

3GPP

Release 8

158

3GPP TR 23.882 V8.0.0 (2008-09)

Figure 7.22.2.1.1-1: LTE VoIP-to-1x CS voice service continuity

1. Ongoing VoIP session over the IMS access leg established over EPS/EUTRAN access.
2. Based on some trigger (e.g., measurement reports), the EUTRAN makes a determination to initiate an intertechnology handover to cdma2000 1xRTT Rev A.
3. The EUTRAN signals the UE to perform an inter-technology handover.
4. The UE performs signalling for establishment of the CS access leg. The 1xRTT CS signalling exchanged
between the UE and the MSC is tunnelled inside EUTRAN/EPS tunnelling to the MME and then further
tunnelled inside S102 messages to the IWS.
Editors Note:The A21 signalling as defined in 3GPP2 provides indications as to the type of messages being
signalled. In particular, indications that a particular message represents a traffic channel assignment
message is provided. This can be used by the EPS system to release resources, if desired.
5. Once the UE receives the traffic channel information from the cdma2000 1xRTT Rev A system, the UE retunes
to the 1xRTT radio access network and performs traffic channel acquisition with the 1xRTT BSS.
Editors note: It is FFS how eNodeB determines that the UE left the eNodeB due to 1xRTT handoff or due to bad
radio coverage (e.g. dead spot).
6. The UE sends a 1xRTT handoff completion message to the 1xRTT BSS.
7. The 1xRTT BSS sends an assignment complete message to the 1xRTT MSC.
8. Ongoing voice call over the CS access leg established over 1xRTT access
9. The EUTRAN/EPS context may by released based on the normal EUTRAN/EPS procedure.

3GPP

Release 8

7.22.2.2

159

3GPP TR 23.882 V8.0.0 (2008-09)

Impact on the baseline CN architecture

The solution requires a new interface between MME towards the IWS function in the 1xRTT network referred to as
S102. It is expected that the existing 3GPP2 defined A21 interface shall be used for the preparation and execution of the
handoff procedures between LTE and cdma2000 1xRTT CS. The working assumption is that no modifications will be
required to the currently defined specification for the A21 interface.

7.22.2.3

Impact on the baseline RAN architecture

E-UTRA(N) should support measurements of cdma2000 channels from the EUTRAN, similar to that which is already
defined for UTRAN. It should also support the ability to trigger a handover to the cdma2000 system, similar to that
which is already defined for UTRAN.
Other aspects are FFS.

7.22.2.4

Impact on terminals used in the existing architecture

UE should support measurements of cdma2000 channels from the EUTRAN, similar to that which is already defined
for UTRAN. UE should support a tunnelling protocol for tunnelling 1xRTT CS signalling messages inside EPS NAS
signalling.
Other aspects are FFS.

Consolidated architecture

Conclusions
Editors Note: Both interim and final conclusions can be documented.

3GPP

Release 8

160

3GPP TR 23.882 V8.0.0 (2008-09)

Annex A:
Open Issues
-

How to achieve mobility within the Evolved Access System?

Is the evolved access system envisioned to work on new and/or existing frequency band?

Is connecting the Evolved RAN to the pre-SAE/LTE PS core needed?

How to add support for non-3GPP access systems?

WLAN 3GPP IP access system might need some new functionality for Inter-system Mobility with the Evolved
Access System

Clarify which interfaces are the roaming interfaces, and how roaming works in general

Inter-access-system mobility

Possible difference between PCC functionality, mainly stemming from the difference in how Inter-AS mobility is
provided

How do UEs discover Access Systems and corresponding radio cells ? Autonomous per Access System and the
UEs scans/monitors any supported Access System to discover Systems and cells. Or, do Access Systems
advertise other Access Systems to support UEs in discovering alternative Access Systems ? How is such
advertising performed (e.g. system broadcast, requested by UE, ) ? How do these procedures impact battery
lifetime ?

In case Access Systems advertise other Access Systems: will any Access System provide seamless coverage
(avoiding loss of network/network search), or is a hierarchy of Access Systems needed to provide seamless
coverage for continuous advertisement ?

Is user access control/authentication per access system or more centralized for multiple access systems ?

How are Access Systems, PLMNs and operators discovered and selected ? Can a UE access/attach multiple
PLMN/operator in parallel ? If yes, how many ? Or, has a UE to select the same PLMN/operator for each Access
System in case the UE accesses/attaches multiple Access systems in parallel?

How many identities and temporary identities has a UE/subscriber? For every Access System another identity?
In case of multiple identities: is user context transfer and identity translation required at a change of the Access
System to avoid re-authentication?

In case a UE accesses/attaches multiple Access Systems in parallel: how does reservation of guaranteed
resources work? Are multiple reservations in parallel required (same resource on every Access System) to allow
for fast change between Access Systems ? Or, does a mobility/handover mechanism reserve resources during the
mobility/handover process ?

Shall inter Access System mechanisms and signalling for load sharing and mobility be generic for all Access
Systems or peer-to-peer between Access Systems ?

Will any Access Systems have an idle or paging mode ? And, shall the wake-up work over multiple Access
Systems (e.g. paging in multiple Access Systems in parallel) ?

Are User or UE access and service rights specific per Access Systems or common for all or multiple Access
Systems ?

How many network nodes are between UE and top level mobility anchor ? And is there only one set traffic plane
functions for user data (policing and charging) ? Or, may the traffic plane functions change during an ongoing
service because of an Access System change?

Are there layers of multiple Access Systems in same physical location required ? And how dynamic do Ues
change between different Access Systems in the same location in idle and in connected mode? What signalling
traffic is acceptable during such mobility (e.g. signalling via HPLMN) and how does it influence system
performance and QoS (e.g. packet loss / service interruption during change of Access System)?

3GPP

Release 8

161

3GPP TR 23.882 V8.0.0 (2008-09)

May functions be transferred to application/services level (e.g. mobility supported by IMS services) ? If yes, to
which extent is this feasible for application/services ?

Does every Access System provide its own security mechanisms (encryption, integrity) ? Is a parameter mapping
between different security mechanisms possible? Or, can security associations be established in parallel to
ongoing services ?

How is data compression provided for the different access systems ? And how re-synchronizes compression
when the access system changes ?

3GPP

Release 8

162

3GPP TR 23.882 V8.0.0 (2008-09)

Annex B:
Summary of different high level architecture
proposals
Editor's note: Now that a common high level architecture proposal has been added to clause 4.2, further
contributions to this annex are NOT expected.

B.0 General
Current company inputs have been summarized into the following 2 separate high level architecture figures. These
figures represent the spectrum of company inputs. The key differences between the two figures are:
a) Inter-access-system mobility is achieved differently;
b) Possible difference between PCC functionality, mainly stemming from the difference in how Inter-AS mobility is
provided.
Key issues for further consideration and contributions have been added to the list of open issues in Annex A.

B.1 Concept B1
NOTE:

For simplicity and readability, in figures B1.b to B1.e, many of the details of WLAN roaming such as
AAA infrastructure for WLAN are omitted and some details may be FFS.

GERAN

Gb

SGSN

Iu

R1, R2, R3 are working names for

reference points

UTRAN
R3

Gn

Gx+ denotes evolved/extended Gx

PCRF1

Gx+

Evolved RAN

R1

Evolved
Packet Core

Gi

AAA interface

HSS

Gi

R2

Internet
Wi

Op.
IP
Serv.
(IMS,
PSS,
etc)

PCRF1 denotes evolved Policy and

Charging Rules Function

Wi

WLAN
3GPP IP Access
* Colour coding: Red indicates new functional element / interface

Figure-B.1a: Non-roaming case

3GPP

Release 8

163

GERAN

3GPP TR 23.882 V8.0.0 (2008-09)

Gb
Iu

SGSN

Gn+ denotes enhanced SGSN Evolved Packet Core interface

UTRAN
R3

Other notes from Fig-B.1a " nonroaming case " still apply.

Gn+

Gr
Evolved RAN

R1

HSS

Evolved
Packet Core

PDF/CRF

Gi (RADIUS)

Gx/Go
R2

VPLMN

Gp

Wi

Internet

GGSN

Gi

Op.
IP
Serv.
(IMS,
PSS,
etc)

Gi

WLAN
3GPP IP Access

HPLMN

* Color coding:red indicates new functional element / interface

Wi

Figure-B.1b: Roaming case: Evolved VPLMN, legacy HPLMN

3GPP

Release 8

164

3GPP TR 23.882 V8.0.0 (2008-09)

Other notes from Fig-B.1a " nonroaming case " still apply.

GERAN

Gr

Gb

HSS

SGSN

Iu

PCRF1

AAA interface

Gx+

UTRAN

VPLMN

Gp
Wp
Wi

Internet

Evolved Gi
Packet
Core

Op.
IP
Serv.
(IMS,
PSS,
etc)

Gi

WLAN
3GPP IP Access

HPLMN

* Color coding: red indicates new functional element / interface

Wi

Figure-B.1c: Roaming case: Legacy VPLMN, evolved HPLMN

3GPP

Release 8

165

GERAN

3GPP TR 23.882 V8.0.0 (2008-09)

Gb
Iu

SGSN

Gn+ denotes enhanced SGSN Evolved Packet Core interface

UTRAN
R3

Gr+ and Gp+ denote evolutions of

Gr and Gp

Gn+

Other notes from Fig-B.1a " nonroaming case " still apply.
Evolved RAN

R1

Evolved
Packet Core

Gr+

PCRF1

HSS
AAA interface

R2

VPLMN

Gp+

Wi

Evolved Gi
Packet
Core

Internet

Op.
IP
Serv.
(IMS,
PSS,
etc)

Gi

WLAN
3GPP IP Access
Wi
* Color coding:

Gx+

HPLMN

red indicates new functional element / interface

Figure-B.1d: Roaming case: Evolved VPLMN, evolved HPLMN "GGSN" in HPLMN

3GPP

Release 8

166

GERAN

3GPP TR 23.882 V8.0.0 (2008-09)

Gb

SGSN

Iu

UTRAN

Gn+ denotes enhanced SGSN Evolved Packet Core interface

Gn+
R3

Proxy
PCRF1
Gx-roam+

Other notes from Fig-B.1a " nonroaming case " still apply.

Gx+

Evolved RAN

R1

Home
PCRF1

Evolved
Packet Core
Gr+
R2

VPLMN

HSS

Gi
Wi

Op.
IP
Serv.
(IMS,
PSS,
etc)

Internet

WLAN
3GPP IP Access

HPLMN

* Color coding: red indicates new functional element / interface

Figure-B.1e: Roaming case Future VPLMN, future HPLMN "GGSN" in VPLMN

NOTE:

The exact details of the PCC architecture to handle the "GGSN" in the VPLMN are FFS.

3GPP

Release 8

167

GERAN

3GPP TR 23.882 V8.0.0 (2008-09)

Gb
Iu

N3MM manages the mobility with

non-3GPP systems.

SGSN

UTRAN

Op. Gi+ denotesGi with added mobility

IP
support.
Serv.
(IMS,
PSS, When using UTRAN or Evolved
RAN, the N3MM is not used.
etc)

PCRF1
R3

Gn/Gp

Gi

Dependent on the nature of the

non-3GPP system, either the
device, or, the network of the non3GPP system provides some
mobility support (denoted N3FA).

Gx+

Evolved RAN

R1

Evolved
Packet Core

N3MM

AAA interface

HSS

R2

Gi

Gi +

Internet

Non 3GPP
IP System

Wi

WLAN
3GPP IP Access

Device

* Color coding: red indicates new functional element / interface

N3FA

N3FA

Figure-B.1f: Non-3GPP system support

B.2 Concept B2

Figure-B.2
Inte rne t

Gb

Gi

GPRS Core
PCRF2*

GERAN

Iu

Gx+

UTRAN
Rh

Gi+

HSS

R x+

AAA inte rfa ce

Op.
IP
Se rv.
(IMS,
PS S,
e tc)

Inte r-AS
MM

Gi

Evolve d
Pa cke t Core

Gi

Inte rne t

Gx+
R x+

Wi

Wi+

PCRF2*

Gx+

WLAN
3GP P IP Ac c e ss

Figure B.2

3GPP

Ra

Evolve d RAN

Release 8

168

3GPP TR 23.882 V8.0.0 (2008-09)

Key and notes to figure B.2:

-

Color coding: red indicates new functional element / interface

Inter-AS MM: Inter-Access-System Mobility Management

*PCRF2 elements are drawn twice only for figure topology reasons

PCRF2: Evolved Policy and Charging Rules Function

NOTE-i: It is FFS how PCRF2 connects to other elements.

NOTE-ii: It is necessary to contact the same PCRF2 for a user when he moves between different access systems.
How this is achieved is FFS.
-

Gi+ : Gi with added Inter-AS mobility support

Wi+ : Wi with added Inter-AS mobility support

Rh: provides functionality to prepare handovers such that interruption time is reduced. It is intended that this
interface should be generic enough to cope with other "combinations of RATs" for which handover preparation is
needed.

3GPP

Release 8

169

3GPP TR 23.882 V8.0.0 (2008-09)

Annex C:
Summary of different MM concepts
So far 3 LTE-MM states are identified:
LTE_Detached:
-

The location of the UE is not known by the network (e.g. UE switched off);

LTE_Idle:
-

State in which the UE has a low power consumption and can thus be kept for many days;

Fast state transition to LTE_Active shall be supported (<=100ms excluding DTX);

Mobility: cell reselection by the UE and traffic area change registration to the network;

LTE_Active
-

UE is able to perform Uplink/Downlink transport with very limited access delay;

Mobility: network directs the UE to serving cells;

It is FFS whether additional LTE-MM states will be required.

3GPP

Release 8

170

3GPP TR 23.882 V8.0.0 (2008-09)

Table C.1
Mobility
State

LTE_
Detached
LTE_
Idle

LTE_
Active

Context in
E-UTRAN
(including
security
parameters
)

E-UTRAN Uplane
resources
established:
Radio
Resources

E-UTRAN Uplane
resources
established:
Transport
Network
Layer
Resources

Paging
within
Tracking
Area

Tracking
Area
Update

No

No

No

No

(please
indicate
size of
Tracking
Area, e.g.
RA,
NodeB)
No

Yes/No
(note 1)

No

Yes/No (note
1)

Handled
by
RAN/CN
(note 1)

Yes

Yes
(shared)

Yes

No
paging

Intra-access
mobility

Interaccess
mob ->
UTRAN/
GERAN

Handling
of
roaming
restrictio
ns

No

No

No

Cell group
level
UE
triggered

UE (re-)selects
cells
autonomously

UE
(re-)select
s cells
autonomo
usly

Within
RAN
(assisted
by CN) or
CN

Cell/Node
B Level
No
Tracking
area
update

E-UTRAN
directs Ues to
serving cells,
(note 2)

E-UTRAN
directs
Ues to
serving
cells,
(note 2)

Within
RAN
(assisted
by CN) or
CN

Battery
saving
scheme

inherently
power
saving
inherently
power
saving
e.g. use
of DRX
cycle
There is a
power
saving
substate
within the
Active
Mode.
This is the
dormant
substate
(e.g.
using
DRX
cycles).

NOTE 1: 4 options were expressed with respect to LTE_Idle state:

Context in E-UTRAN
(including security
parameters)
No
Yes

E-UTRAN U-plane resources

established:
Transport Network Layer
Resources
No
Yes

Yes

No

No

Tunneling endpoints in CN
remain

Paging within
Tracking Area

Comment

Handled by CN
Handled by
E-UTRAN
Handled by
E-UTRAN

Only CN is aware of UE in LTE_Idle state

Resources to Node-B remain established; Node-B will
handle paging
Node above Node-B in E-UTRAN handles UE in
LTE_Idle state, but no reservation of U-plane
resources
UE and CN have the necessary shared security
parameters to enable user data transfer before
security parameters are sent from CN to RAN

Handled by CN

NOTE 2: Some companies think UE based selection may be required in the Dormant Substate of the Active state.

3GPP

Release 8

171

3GPP TR 23.882 V8.0.0 (2008-09)

Annex D:
More detailed descriptions of potential solutions
for limiting signalling due to idle mode mobility
between E-UTRA and UTRA/GSM
D.1

Introduction

This annex provides more information on some potential solutions that could be used to meet this requirement. Further
analysis of these solutions (and other potential solutions) is needed before a decision is made.

D.2

Potential Solutions

D.2.1 Do Nothing
D.2.1.1 Overview
This does not meet the requirement to minimize the signalling due to idle mode mobility between E-UTRA and
UTRA/GSM, but, is a feasible solution for single-mode E-UTRA terminals, or, if the E-UTRA coverage does not
overlap other coverage areas, or, if the proportion of "dual" mode terminals is low. In this solution the terminal context
in the network is only located in the network the terminal is currently camping on. As in all other solutions it is possible
to utilize various hysteresis based cell selection criteria (thresholds, timer based etc.) in order to minimize the risk that
the terminal toggles between different systems.

D.2.1.2 Advantages
1. No additional functionality needs to be added to the network architecture.
2. Possible to utilize any camped state in each access (e.g. URA_PCH).

D.2.1.3 Drawbacks
1. The camped terminal needs to signal the network at every inter-access cell change leading to unnecessary
signalling load.
2. There is also a higher risk that the terminal will miss a page message from the network since the number of interaccess tracking area updates might be higher in this solution.

D.2.2 Common Routeing Area and common SGSN

D.2.2.1 Overview
Placing the GSM and UMTS cells into the same LA and RA is the basic part of the UMTS/GSM solution. However this
does mean that both the MSC and SGSN are shared between 2G and 3G. The SGSN has to support both the Gb and Iups interfaces and their different RAN/CN functional splits.
From a standardisation point of view, it would be relatively easy to extend this concept to cover E-UTRA, UTRA and
GSM. However, from an implementation point of view, this requires the development core network nodes that support
all of the Gb, the Iu-ps AND the E-UTRA RAN-CN interface.

3GPP

Release 8

172

3GPP TR 23.882 V8.0.0 (2008-09)

In addition, the "signalling free movement between 2G and 3G" only applies in the "idle" state (GPRS-Standby to PMM
idle) and means that the URA-PCH state does not get utilised to its full benefits.

D.2.2.2 Advantages
1. Tracking areas that overlap multiple RATs are supported which reduces signalling, assuming the EUTRA/UTRA/GSM cells belong to the same CN node area

D.2.2.3 Drawbacks
1. Required combined PS nodes (or CS nodes) for different accesses (2G/3G, SAE / LTE)
2. Slower transition from camped to active state when the terminal is in UTRAN since it is not possible to utilize
camped state containing RAN context in UTRAN (e.g. URA_PCH) and at the same time perform signalling free
inter-RAT cell changes.

D.2.3 Common RAN / CN for E-UTRA / UTRA

D.2.3.1 Overview
With "basic GSM" and "EDGE", and with GSM in different frequency bands (900, 1800, etc), a common BSC can be
used with all the cells in the same LA/RA.
A similar technique could be used for connecting E-UTRA and UTRA cells to the same RAN / CN. The terminal would
operate using a common upper layer protocol stack for both E-UTRA and UTRA. Only the lower layers would be
different depending on which technology the terminal is connected to. In this solution UTRA cells (at least HsxPA
capable ones) are supported in the SAE / LTE architecture either using combined E-UTRA / UTRA nodes or using new
or modified interfaces between UTRA and E-UTRA nodes. This does constrain the E-UTRA architecture since it needs
to support UTRA cells, but it would permit the URA-PCH/long live Iu-ps connections to be maintained.

D.2.3.2 Advantages
1. Tracking areas that overlap E-UTRAN and UTRAN are supported, which reduces signalling
2. It is possible to utilize a concept similar to URA_PCH where tracking areas can overlap each other, which avoids
hard tracking area borders.

D.2.3.3 Drawbacks
1. Tracking areas do not overlap E-UTRAN and GERAN.
2. Require that UTRA cells are integrated in the SAE / LTE network either using combined UTRA / E-UTRA nodes
or using new or modified interfaces between UTRA and E-UTRA nodes.

D.2.4 Equivalent Routeing Areas and SGSN proxy

D.2.4.1 Architectural overview
The description of this mechanism is based on the architectural picture indicated below.
NOTE 1: These techniques may also be applicable to other architectural concepts (e.g. there could be an E-UTRA
RNC in between the AP box and the UP/CP-GW boxes).
NOTE 2: The use of some "GPRS terminology" does NOT imply that these interfaces/functions are reused by
LTE/SAE, rather, the terms are just used to aid comprehension of the concept.

3GPP

Release 8

173

3GPP TR 23.882 V8.0.0 (2008-09)

NOTE 3: Equivalent routing areas will probably not be possible to support networks using only CS speech services
in one access (e.g. GSM) and only PS speech services in another access (e.g. SAE / LTE), since CS
paging will only be supported in one of the two accesses (FFS).
UP-GW

GTP-U+

A
P

Gi

Iu

A
P

GTP-U
GTP-U+

UE

CP-GW

AAA

Gn+
& Gr-

UP-GW
N
b

Gr

Gi

GTP-U
Iub

RNC

Iu

SGSN

Figure D.1: architecture overview

In this architecture, the "2G/3G packet core" connects to the "evolved packet core" as follows:
-

the user plane from the 2G/3G SGSN connects to the User Plane GateWay via the GTP-U part of Gn.

the control plane part of the Gn interface connects the 2G/3G SGSN to the Control Plane GateWay via a
somewhat modified GTP-C part of Gn.

for E-UTRA capable Ues, the SGSN does not send MAP signalling to the HLR/HSS. Instead these functions are
proxied across "Gr minus" to the CP-GW. The CP-GW has a Gr reference point between it and the HSS/AAA.

Between the E-UTRA Access Point and the core network:

-

the interfaces need not be based on GTP/Iu, however, the same functional split might apply.

The GateWay:
-

is split into separate Control Plane and User Plane units, and

should support the concept that more than one "APN" may need to be supported (e.g. for Ipv4 and Ipv6, and/or
for Corporate access and Public Operator MMS/IMS service), with each APN potentially being on different User
Plane GateWays.

D.2.4.2 Concept: Equivalent Routeing Areas

The concept is summarised as follows:
a) the E-UTRA Access Points and UTRA/GSM cells are in separate Routeing (Tracking) Areas.
b) Upon Attach and RA update, the UE is "accepted" into multiple, Equivalent Routeing Areas. Typically, one is for
E-UTRA and one is for UTRA/GSM. The UE may be allocated different P-TMSIs in the different Tracking
Areas.
c) When the mobile moves between (E-UTRA) LTE-IDLE and an "inactive" UTRA state, the UE does no
signalling to the network (as long as the new cell is within one of the set of Equivalent Routeing Areas). The
"inactive" UTRA states are RRC-IDLE and URA-PCH. The nature of CELL-PCH and CELL-FACH are FFS.
d) Movement to E-UTRA from UTRA by mobiles in URA-PCH does NOT cause the Iu-PS connection to be
released. This permits fast reconnection of the UE's data flow if the mobile later returns to UTRA.
e) While in E-UTRA, the UE keeps the periodic URA update timer running. If this expires while not in UTRA
coverage, the UTRA will release the Iu connection, so when the UE next returns to UTRA coverage, it enters
PMM-IDLE state.
f) If the new cell is in a Routeing Area that is not within the List of Equivalent Ras (LERA) stored in the UE, then
the normal RAU procedure is performed.

3GPP

Release 8

174

3GPP TR 23.882 V8.0.0 (2008-09)

g) When the mobile changes RAT while in an "active" state, UE-network signalling takes place to ensure that user
data is correctly routed. The "active" states include LTE-active, UTRA-Cell-DCH and GPRS-Ready.
h) For E-UTRA UEs, GMM and SM contexts in the SGSN and the CP-GW are synchronised by the SGSN
proxying GMM and SM signalling to the CP-GW, and, by using a 'context reference number' (CRN). Whenever
the UE modifies its SM or GMM state via E-UTRA, the CRN is updated. When the UE accesses via UTRA or
2G, the UE sends the CRN to the SGSN. If the SGSN detects a CRN mismatch, the SGSN pulls the SM and
GMM context from the CP-GW. Changes in the security context that are made on E-UTRA may be pushed
towards the SGSN(s) in advance of the UE leaving E-UTRA.
i) The Periodic RA Update Timer is replaced with a Periodic SMU Timer, running between the UE and the CPGW.
j) If needed, Mobile Terminating activities based on MSISDN/IMSI (e.g. Location Services, SMS) are routed to
the CP-GW.
k) The Access Point informs the UP-GW(s) from which it has sent/received data if the UE leaves the LTE-Active
state.
l) When the mobile is in LTE-idle and a downlink IP packet arrives at the User Plane Gateway (UP-GW) entity of
the GW, then the UP-GW entity contacts the Control Plane Gateway (CP-GW), and the CP-GW initiates the
Paging procedure in all of that UE's Equivalent RAIs. (Extra details are given below).

D.2.4.3 LERA Management

The CP-GW could manage LERA and update the LERA to the UE in the corresponding set of Equivalent Ras. For
paging process, CP-GW could send paging to the APs and SGSN according to the LERA it stores. SGSN does not have
to store the LERA, nor has to take part into the LERA management, since the normal routing area update process will
be performed.
After registration with HSS via CP-GW is finished in RA update process or in network attachment, the CP-GW may
include the LERA in the confirm message to the UE.
Figure D.2 shows how the LERA is allocated for UE when UE initiates a routing area update request or attach request
via 2G/3G SGSN.

Figure D.2: Information flow for LERA management

1. UE sends RA Update Request or Attach Request to 2G/3G SGSN.
2. Other steps in RA update or Attachment processes, such as security functions.

3GPP

Release 8

175

3GPP TR 23.882 V8.0.0 (2008-09)

3. if UE is in a legacy network, SGSN sends the registration request to the CP-GW. The registration request
includes the legacy RAI, CP-GW then forwards the request to HSS.
4. HSS sends registration confirm message to CP-GW.
5. If UE is in a legacy network, CP-GW sends the registration confirm message including LERA to SGSN
according the legacy RAI, and SGSN will forwards the message to UE.

D.2.4.4 Downlink data flow to an "inactive" UE

D.2.4.4.1

Solution A

When downlink packets are received at the UP-GW and the UE is in LTE-Active state, a (virtual) connection between
the UP-GW and the AP may already exist for the UE. If such a connection exists, the UP-GW sends the packets directly
to the AP.
After the expiry of the LTE-Active State Timer in the AP, the AP and UP-GW release the connection between them for
that UE. No user plane transmission path for the UE exists for future packets received in the downlink.
When a downlink packet arrives the procedure described below is applied:
The UE may be in LTE-Active state as a result of signalling between UE and the core network and/or data
transmission through a different UP-GW. In this case, a 'disconnected' UP-GW also acts as described below
when a downlink packet arrives.

RNC

SGSN

5. PAGING
UE

6
PAGING

UPGW

AP

AP

3
4

PAGING

AP

CP-GW

Figure D.3: Transfer from Idle to Active states for Ues caused by downlink Traffic whilst in EUTRA
coverage
0 The User Plane Gateway has two flags associated with the "PDP context". One indicates whether the UE is in
"LTE-active or not". The other indicates whether the last "GTP-U tunnel" to be used was "on E-UTRA or on
UTRA/2G".
1 A downlink packet is received in a UP-GW function and the "LTE-active or not" flag indicates "not".
2 If the "last used tunnel" flag in the UP-GW indicates that the UE was last in the coverage of the SGSN, then the
UP-GW sends the downlink packet to the UTRA/2G SGSN.
A When received by a 2G-SGSN:
I

If the MS is in the Ready state then the SGSN sends the packet to the BSS.

II If the MS is in the Standby state, then the SGSN initiates paging for the MS, AND immediately returns a
copy of the Packet to the UP-GW with an indication that parallel "paging in a wider area" is required. Once
the 2G paging process has been completed, the SGSN returns an indication to the UP-GW of whether the MS
was reachable or not (in 2G coverage).

3GPP

Release 8

176

3GPP TR 23.882 V8.0.0 (2008-09)

B When received by a 3G-SGSN:

I

If an Iu connection for this UE exists, the SGSN forwards this packet to the RNC on the Iu connection. If the
UE is in URA_PCH or CELL_PCH, the RNC immediately returns a copy of the packet to the UP-GW, via
the SGSN, with an indication that parallel "paging in a wider area" is required, AND, in parallel initiates
paging in the URA/CELL. Once the UTRA paging process has been completed, the RNC sends the UP-GW
an indication of whether the MS was reachable or not.
If the UE is in Cell_DCH, the packet is delivered to the mobile.

II If an Iu connection for this UE does not exist, the SGSN immediately returns a copy of the packet to the UPGW with an indication that parallel "paging in a wider area" is required, AND, the SGSN initiates paging for
this UE in UTRA. Once the paging process has been completed, an indication of whether the UE was
reachable or not is sent to the UP-GW.
3 When receiving a downlink packet from the Gi interface when the "last used tunnel" flag in the UP-GW
indicates that the UE was last in EUTRA coverage (and the "LTE-Active or not" flag is set to "not"), then, the
UP-GW will contact the CP-GW requesting paging to be initiated for this UE.
Also, if the UP-GW receives a copy of a packet from an RNC/3G SGSN/2G SGSN with a request for "paging in
a wider area" the UP-GW will contact the CP-GW requesting paging to be initiated for this UE in other areas.
4 The CP-GW sends a Paging message to all the Aps and SGSN which are part of Ras that have been allocated to
the UE (and which are not yet paging the mobile), including the parameters needed to page the UE (c.f. IMSI in
2G/3G).
5 The UE is paged on each of the E-UTRA, UTRA and 2G Cells that are contained within the list of Equivalent
RAIs allocated to the UE.
6 When the UE receives the Paging message it responds with the Service Request/Cell Update message (or EUTRA equivalent). In EUTRA this message contains enough information for the AP to gather the context for the
UE (either directly from the last registered AP or from the CP-GW). In UTRA/2G, the SGSN indicates to the
CP-GW that the mobile has responded to paging.
7 The AP (or SGSN) then creates the connection to the UP-GW (via the CP-GW in the case of an SGSN). When
the connection is created to the UP-GW the IP packet buffered for the UE is sent on the connection to the AP (or
SGSN).
8 The AP informs the CP-GW that it controls the UE, and the CP-GW passes the QoS information to the AP for
this flow.
9 The CP-GW informs the UP-GW that the Paging procedure to locate the UE was successfully completed.

3GPP

Release 8

D.2.4.4.2
UE

177

3GPP TR 23.882 V8.0.0 (2008-09)

Solution B
RNC/B
SC

E-UTRAN

2G/3G
SGSN

CP-GW

UP-GW

1 Downlink data

2 Paging

3 CP-GW checks MM
state
4Paging
4Paging
5 Paging response
5 Paging response
6Paging response
7User plane Connection established
7User plane Connection established
8) Downlink data

Figure D.4: Transfer from Idle to Active states for UE caused by downlink traffic arriving while UE is
in LTE IDLE
0 The User Plane Gateway has a flag associated with the "PDP context", which indicates whether the UE is in
"LTE-active or not".
1 A downlink packet is received in a UP-GW function and the "LTE-active or not" flag indicates "not" or a copy of
a packet from RNC with a request for " paging in a wider area" is received in a UP-GW function.
2 UP-GW sends paging request to CP-GW, the paging request should indicate if "paging in a wider area" is
requested.
3 CP-GW checks UE MM states, if UE is in PMM-CONNECTED State/GPRS-READY State, then go to step 6, if
UE is in PMM-IDLE State/GPRS-STANDBY State or LTE-IDLE State, or the paging request from UP-GW
indicates "paging in a wider area" then go to step 4.
4 The CP-GW sends a Paging message to all the Aps and SGSN which are part of Ras that have been allocated to
the UE (and which are not yet paging the mobile), including the parameters needed to page the UE (c.f. IMSI in
2G/3G).
The UE is paged on each of the E-UTRA, UTRA and 2G Cells that are contained within the list of Equivalent
RAIs allocated to the UE.
5 When the UE receives the Paging message it responds with the Service Request/Cell Update message (or EUTRA equivalent). In E-UTRA this message contains enough information for the AP to gather the context for the
UE (either directly from the last registered AP or from the CP-GW). In UTRA/2G, the SGSN indicates to the
CP-GW that the mobile has responded to paging.

3GPP

Release 8

178

3GPP TR 23.882 V8.0.0 (2008-09)

6 CP-GW sends paging response to UP-GW, which indicates if UE is now in coverage of UTRA/GERA. When
UP-GW receives paging response, which indicates that UE is now in coverage of UTRA/GERA, then the UPGW sends the downlink packet to the 2G/3G SGSN.
If the UE is in URA_PCH or CELL_PCH, the RNC immediately returns a copy of the packet to the UP-GW, via
the SGSN, with an indication that parallel "paging in a wider area" is required, AND, in parallel initiates paging
in the URA/CELL. Once the UTRA paging process has been completed, the RNC sends the UP-GW an
indication of whether the UE was reachable or not.
If the UE is in Cell_DCH, the packet is delivered to the mobile.
7 User plane connection will be established between UP-GW and UE (User plane connection could be controlled
by the CP-GW). The AP informs the CP-GW that it controls the UE, and the CP-GW passes the QoS information
to the AP for this flow.
8 When the connection is created to the UP-GW the IP packet buffered for the UE is sent on the connection to the
AP (or SGSN).

D.2.4.5 Summary
It is believed that, the description given above in Annex D, clause D.2.4 shows that this mechanism can limit "inactive
mode signalling" while maintaining the E-UTRA core network separate from the 2G/UTRA core network.
Upgrades to existing equipment are necessary, but these upgrades appear to be limited to software.

There are two main differences between Solution A and B

1) In Solution B, UP-GW wont send downlink data to SGSN unless it knows there is Iu connection by
information from CP-GW, so that UP-GW could handle the downlink data more efficiently.
2) UE shall always activate PDP context when it register with SGSN for Solution A, but for Solution B, its not
necessary to activate PDP context in the coverage of SGSN if there is neither uplink nor downlink data for the UE.
This may benefit the UE when the UE first registers in SAE network, then moves to the coverage of SGSN, in
which case, UE doesnt activate PDP context again to SGSN if there is neither uplink nor downlink data for UE.

D.2.4.6 Advantages
Editor's Note: This list is suitable for both Solution A and Solution B for Equivalent Routing area concept..
1. Allows overlapping tracking areas between E-UTRA / UTRA and GSM regardless which tracking area concept
is used in each technology, which reduces signalling.
2. It is possible to assign multiple tracking areas to the terminal, which avoids hard tracking area borders also
within each access.

D.2.4.7 Drawbacks
Editor's Note: this list is suitable for both Solution A and Solution B for Equivalent Routing area concept.
1. Requires updates to existing GERAN / UTRAN networks to support the equivalent tracking area concept.

D.2.5 UE remains camped on the last used RAT

D.2.5.1 Description
In this solution, the network knows the technology in which the mobile can be reached, and the paging is performed in
that particular technology alone. This will require that the mobile make a location area/tracking area update whenever it
makes an idle mode handover from one technology to another. Initial coverage of E-UMTS will be spotty compared to
UMTS. Therefore, if the network needs to know the current technology in which the mobile can be reached, there will
be a high tracking area update signalling load on the network due to idle mode handovers. It would be best if we can
avoid this kind of signalling load by reducing idle mode handovers.

3GPP

Release 8

179

3GPP TR 23.882 V8.0.0 (2008-09)

The main idea of this option is that the mobile continues to remain camped in the technology in which it last did a
tracking area update, unless it enters a region where there is no coverage of that particular technology. For example, if a
mobile did its last location area update in UMTS technology, it continues to remain in UMTS technology and makes its
location area updates as per UMTS location areas for as long as there is UMTS coverage. Even if it enters E-UMTS
coverage areas, if there is still UMTS coverage, it continues to remain in the UMTS technology. When the mobile needs
to be paged, it is paged in the UMTS technology, and if there is E-UMTS coverage in that area as well, and if operator
and mobile policies are such that E-UMTS is the preferred technology, then an active mode handover is carried out to
the E-UMTS technology.
A minor modification of the above idea would be to have the mobile camped on the last used RAT for a certain period
of time before switching over to the preferred RAT when under common coverage. This builds in a certain amount of
hysterisis to reduce signalling load and at the same time reduce the occurrence of active mode handover.
The main advantage that this technique offers is that the location area/tracking area signalling load is reduced, while
still allowing the network to know the exact technology in which the mobile can be reached. This benefit is obtained by
postponing any inter-technology handovers in idle mode until it is actually required, i.e. when it loses coverage in the
technology in which it made its last tracking area update, or when it needs to move to active mode and the alternate
technology is the preferred technology for active data transfers.

D.2.5.2 Advantages
1. Paging in a single technology alone is required at all times.
2. No additional functionality needs to be added to the network architecture.
3. Reduced signalling load compared to the scheme where a tracking area update is sent when a new preferred
technology is available.

D.2.5.3 Drawbacks
1. Imposes a restriction on the mobile to not perform idle mode handovers when coverage of the previous
technology exists.
2. Requires an inter-technology handoff at the time of call setup, if the mobile is in the coverage area of a preferred
technology, while still in idle mode in a different technology.
3. If UMTS coverage is more extensive than E-UTRA coverage, then the mobile will frequently be initiating access
from UMTS. These accesses are unlikely to achieve the E-UTRA performance requirements for the transition
time for moving from Idle to active mode data transfer.

D.2.6 Packet Data Bearer Proxy

D.2.6.1 Architectural overview
The description of this mechanism is based on the picture shown below.

3GPP

Release 8

180

3GPP TR 23.882 V8.0.0 (2008-09)

Figure D.5: architecture overview

In this mechanism the UPE is in the data path of the packet data bearer provided by the 2G/3G SGSN. The UE registers
with SGSN and receives TMSI and RA from SGSN. And the UE establishes a packet data bearer, which has the UPE in
the data path. A subsequent registration with the MME maintains the TMSI and RA from SGSN and allocates in
addition TMSI and RA from MME to UE. The UE remains registered at SGSN and the SGSN at HSS. After this
registration with MME the UE may change between 2G/3G access and Evolved RAN without any registration
signalling.
Uplink data the UE may send to the 2G/3G SGSN or to the MME/UPE. Both are in the data path of the UE's packet
bearer service. Downlink data are duplicated by the MME/UPE and duplicates are forwarded to the 2G/3G SGSN so
that both SGSN and MME/UPE start paging. Data are sent by that entity, which receives the paging response from the
UE.

3GPP

Release 8

181

3GPP TR 23.882 V8.0.0 (2008-09)

D.2.6.2 Information flow: registration and downlink data transfer

UE

SGSN

1. Registration Request

MME/UPE

Inter AS MM

HSS

2. Register SGSN
2. Registration Confirm

3. Registration Accept
4. Activate PDP Context Request
4. Activate PDP Context Response
5. UE changes
access system
6. Registration Request
7. Identity Request
7. Response
8. Registration Accept

11. Paging

9. Data

10. Data

12. Paging
13a. Paging Response
14a. Data
13b. Paging Response
14b. Data

Figure D.6: message flow

0) In case the UE performs its first registration with MME/UPE this is performed as without any optimisation for
limiting idle state signalling. The mechanism starts when the UE registers with the 2G/3G SGSN, e.g. because of
selecting 2G/3G access.
1) The UE registers with the 2G/3G SGSN.
2) The 2G/3G SGSN registers at HSS and retrieves subscriber data, e.g. authentication data.
3) In case of successful authentication/authorisation the SGSN accepts the UE registration.
4) The UE request the establishment of the default IP bearer service if not already established. The packet bearer
service is established by the SGSN towards the MME/UPE. The MME/UPE establishes the packet bearer service
towards the inter AS MM. As a result of the IP bearer service establishment the MME/UPE is in the data path of
the packet bearer service provided by the SGSN.
5) The UE changes to the Evolved RAN.
6) The UE sends a registration request to the MME/UPE and sends old TMSI and old RA.
7) The MME/UPE requests subscriber data from SGSN. The SGSN address is derived from old TMSI/RA. The UE
is identified by old TMSI/RA.

3GPP

Release 8

182

3GPP TR 23.882 V8.0.0 (2008-09)

8) The MME/UPE confirms the registration and allocates new TMSI/RA to the UE. And the MME/UPE sends the
old TMSI/RA to the UE for the 2G/3G SGSN. The 2G/3G SGSN remains registered at HSS. The UE may
change between 2G/3G and LTE access without network registration.
9) Downlink data arrive at MME/UPE.
10)The MME/UPE stores data and forwards duplicates to the SGSN.
11) The SGSN pages the UE in the 2G/3G RA.
12)The MME/UPE pages the UE in the RA of the Evolved RAN.
13a)

In case the UE responds to the SGSN the SGSN sends data to the UE in step 14a).

13b)

In case the UE responds to the MME/UPE the MME/UPE sends data to the UE in step 14b).

In case URA_PCH shall be included in idle state handling an inactivity timer in MME/UPE may be used to decide
whether paging is performed on last used RAT or on all RATs. Alternatively, a message from UTRAN to MME/UPE
may indicate the transfer to URA_PCH, which causes paging in all RATs instead of URA-only.

D.2.6.3 Advantages
1. Allows Ues to be registered in Tracking Areas of E-UTRAN, UTRAN and GERAN, which reduces signalling
for idle state Ues.
2. Can be applied without modifying 2G or 3G SGSNs.
3. Can handle URA_PCH as idle state allowing for fast transitions from camped to active state when the UE is on
UTRAN.
4. Allows to limit updates by Ues at TA borders by overlapping Tas or by confirming multiple TA at least for
SAE/LTE (for 2G/3G see drawbacks).
5. Does not require Gr (MAP) at the SAE entities.

D.2.6.4 Drawbacks
1. Some potential limitations as subscriber control and registration with HSS remains on SGSN and control on SAE
entities is via bearer service control. The specific limitations are FFS.
2. Some modification of the SGSN (multiple TA in update confirmation) needed to further improve the amount of
idle state signalling reduction.
3. Some modification of the SGSN and RNC (signalling of transition to URA_PCH to SAE entity) needed to
further improve the amount of idle state signalling reduction if URA_PCH is handled as an idle state.
4. The LTE MME/UPE is on the signalling and data path for 2G/3G access, which is no drawback when
MME/UPE and Inter AS MM are combined into one network entity.

D.2.7 Inter RAT Resource Allocation

D.2.7.1 Architectural overview
The description of this mechanism is based on the picture shown below.

3GPP

Release 8

183

3GPP TR 23.882 V8.0.0 (2008-09)

Figure D.7: architecture overview

The UE registers with the MME/UPE and receives a TMSI, an RA of the Evolved RAN and an RA from 2G/3G access.
The MME/UPE registers with the HSS. After this registration with MME/UPE the UE may change between 2G/3G
access and Evolved RAN without any registration signalling.
When downlink data arrive at MME/UPE the MME/UPE starts paging in the RA of the Evolved RAN and the
MME/UPE requests the SGSN to page the UE within the 2G/3G RA. When the UE responds to the MME/UPE data are
sent by the MME/UPE to the UE. When the UE responds to the SGSN a data path is established between MME/UPE
and SGSN and data are sent by the SGSN to the UE.
For uplink data transfer the UE request MME/UPE or SGSN, respectively to establish data transfer resources. When the
UE camps on Evolved RAN this is straightforward like without this mechanism of reducing idle state signalling. When
the UE camps on 2G/3G access the SGSN establishes in addition a data path to the MME/UPE and forwards data
received from the UE to the MME/UPE. The SGSN derives the serving MME/UPE from information sent by the UE
(e.g. the RA of the Evolved RAN) or the SGSN could receive such information from the MME/UPE already during the
UE's registration.

3GPP

Release 8

184

3GPP TR 23.882 V8.0.0 (2008-09)

D.2.7.2 Information flow: registration and uplink/downlink data transfer

UE

SGSN

MME/UPE

Inter AS MM

HSS

1. Registration Request
2. Register MME
2. Registration Confirm
3. Registration Accept
4. Service Request
5. Path Establishment
6. RAB Setup
7. User Data
8. User Data

9. Paging
9. Request Paging

9. Paging
10a. Paging Response

11a. Path Establishment

12a. User Data

10b. Paging Response
11b. User Data

Figure D.8: message flow

0) In case the UE performs its first registration with 2G/3G this is performed as without any optimisation for
limiting idle state signalling. The mechanism starts when the UE registers with the MME/UPE, e.g. because of
selecting LTE access. Alternatively, the SGSN may confirm 2G/3G TMSI/Ras and Evolved RAN TMSI/Ras to
the UE. This allows the UE to change between 2G/3G and LTE in idle state without any update signalling. This
alternative requires SGSN modifications.
1) The UE request registration at the MME/UPE.
2) The MME/UPE registers at HSS and retrieves subscriber data, e.g. authentication data.
3) In case of successful authentication/authorisation the MME/UPE accepts the UE registration and sends TMSi
and Ras from Evolved RAN and from 2G/3G access to UE. In case this is the network attach the UE is provided
with the IP configuration. This step may include communication between MME/UPE and SGSN to derive
2G/3G RA and TMSI and to establish a UE context in the SGSN.
4) The UE camps on 2G/3G access and needs to transfer uplink data. It performs the Service Request Procedure in
case it camps on 3G access.
5) The SGSN establishes a data path with the MME/UPE that serves the UE. The data path may be established by
existing or by enhanced Gn procedures. The address of the MME/UPE may be stored by the SGSN in an UE
context, which is established in step 3. The UE may be authenticated by the SGSN.
6) The SGSN initiates the RAB establishment.
7) The UE sends uplink user data to the SGSN, which the SGSN forwards to MME/UPE.

3GPP

Release 8

185

3GPP TR 23.882 V8.0.0 (2008-09)

8) Downlink data arrives at MME/UPE.

9) The MME/UPE pages the UE in the RA of the Evolved RAN and the MME/UPE request the SGSN to page the
UE in the 2G/3G RA.
10a) In case the UE responds to the SGSN the SGSN establishes a data path with the MME/UPE in step 11a) and
the MME/UPE sends user data to the UE via SGSN in step 12a). The data path may be established by existing or
by enhanced Gn procedures.
10b)

In case the UE responds to the MME/UPE the MME/UPE sends user data to the UE in step 121).

In case URA_PCH shall be included in idle state handling an inactivity timer in MME/UPE may be used to decide
whether paging is performed on last used RAT or on all RATs. Alternatively, a message from UTRAN to MME/UPE
may indicate the transfer to URA_PCH, which causes paging in all RATs instead of URA-only.

D.2.7.3 Advantages
1. Allows Ues to be registered in Tracking Areas of E-UTRAN, UTRAN and GERAN, which reduces signalling
for idle state Ues.
2. Can handle URA_PCH as idle state allowing for fast transitions from camped to active state when the UE is on
UTRAN.
3. Allows to limit updates by Ues at TA borders by overlapping Tas or by confirming multiple Tas for every RAT to
the UE.
4. Does not require Gr (MAP) at the SAE entities.

D.2.7.4 Drawbacks
1. Some modification of the SGSN needed (multiple TA in update confirmation, interaction with MME/UPE).
2. Some modification of the SGSN and RNC (signalling of transition to URA_PCH to SAE entity) needed if
URA_PCH is handled as an idle state.
3. The LTE MME/UPE is on the signalling and data path for 2G/3G access, which is no drawback when
MME/UPE and the anchor between 3GPP access systems are combined into one network entity.

D.2.8 User-IP layer interconnection

D.2.8.1 Architectural overview
The description of this mechanism is based on the figure as shown below.

Iu

SGSN

UTRAN

Gn/Gp

S3

Evolved RAN

S1

HSS

Gr

Gb

GERAN

MME/
UPE

S4

S5

Figure D.9: architecture overview

3GPP

GGSN

Inter-AS
MM

Gi

Release 8

186

3GPP TR 23.882 V8.0.0 (2008-09)

In this mechanism the Inter-AS MM is the mobility anchor using IP based mobility mechanism (e.g. Mobile IP and any
enhancement of it) and is located within the data path of the packet data bearers provided by both 2G/3G and LTE
system.
The UE subsequently registers with both 2G/3G PS domain and MME/UPE, and receives two TMSIs and Ras.
Accordingly, two different local IP addresses IPLocal are allocated to the UE for each access system (i.e. 2G/3G PS
domain and SAE/LTE network). The global IP address IPGlobal shall be allocated as well by the Inter-AS MM (e.g. HA
when MIP is used as mobility protocol). IPlocal allocated by the 2G/3G PS domain shall be reported to the inter-AS MM
and used as the default query address (i.e.Care-of-Address for MIP) of the UE. The UE may remain registered at SGSN
and the SGSN at HSS. After this registration with both 2G/3G and LTE system, the UE may change between 2G/3G
access and Evolved RAN without any more registration signalling.
Uplink data the UE may send out directly via 2G/3G PS domain or MME/UPE. Downlink data shall be delivered by the
inter-AS MM to the GGSN. Then the 2G/3G PS domain can send paging request to MME/UPE so that both SGSN and
MME/UPE can start paging. The paging response from the UE shall cause the query address IPLocal binding updating to
this entity, which receives this paging response and shall send out data later.

D.2.8.2 Information flow: registration and downlink data transfer

UE

SGSN
1. Attach request

GGSN

MME/UPE

Inter-AS MM

2. Registration
3. Attach Accept
4.Activate PDP Context
5.IPLocal Binding
6. UE changes
access system

7. Registration Request
8. Send Temporary Identity
9. Transfer UE Context

10. Registration Accept

11. Registration Confirm
12. Data
14. Paging

13. Paging request

14. Paging

15a. Paging Response

17a. Data

16a. Stop Paging Indication

15b. Paging Response

16b. Paging response
17b. Data Forwarding
18b. Data
19b. IPLocal Binding Updating
20b. Data

Figure D.10: message flow when UE selects 2G/3G access at first

3GPP

HSS

Release 8

187

3GPP TR 23.882 V8.0.0 (2008-09)

0) The mechanism starts when the UE registers with the 2G/3G SGSN, e.g. because of selecting 2G/3G access.
1) The UE attaches to the 2G/3G PS domain.
2) The 2G/3G SGSN registers at HSS and retrieves subscriber data, e.g. authentication data.
3) In case of successful authentication/authorisation, SGSN accepts the UE attachment.
4) The UE request the establishment of the default IP bearer service within the 2G/3G PS domain if not already
established. The local IP address IPLocal allocated by GGSN and the global IP address IPGlobal allocated by inter-AS
MM shall be distributed to the UE as well.
5) IPLocal allocated by GGSN shall be binding to the inter-AS MM. It is FFS whether this IP Local Binding operation
shall be carried out by the GGSN or the UE itself.
6) The UE changes to the Evolved RAN.
7) The UE sends a registration request to the MME/UPE and sends old TMSI and old RA assigned by the SGSN to
identify itself.
8) The MME/UPE sends the UE parameters to SGSN.
9) The SGSN sends a UE context to MME/UPE. The UE context includes a permanent user identity and other
information, e.g. security and QoS information.
10)The MME/UPE confirms the registration and allocates new set of TMSI/RA/IP Local to the UE. The old set of
TMSI/RA/IPLocal shall be kept by the UE as well. The SGSN remains registered at HSS. Then the UE may
change between 2G/3G and LTE access without further network registration.
11) The UE may acknowledge the success of the network registration.
12)The incoming downlink data is forwarded by inter-AS MM to GGSN, and then SGSN.
13)SGSN sends the paging request to MME/UPE.
14)Both SGSN and MME/UPE start paging the UE in their own RA/TA.
15a)

In case the UE responds to the SGSN, SGSN sends data to the UE in step 17a).

16a)

SGSN may send one indication to MME/UPE to stop paging (FFS).

15b) In case the UE responds to the MME/UPE, MME/UPE shall send out one paging response indication to
SGSN in step 16b).
17b)

SGSN shall forward the received data to MME/UPE using 2G/3G existing mechanism.

18b)

MME/UPE delivers the data to UE.

19b)

Another IPlocal binding updating procedure shall be carried out by the UE or MME/UPE(FFS.) .

20b)

Subsequently the data shall be forwarded by inter-AS MM to MME/UPE, and then UE.

It should be noted that it is the similar procedure for the case when UE selects and registers SAE/LTE system at first.
It also should be noted that although "data forwarding by SGSN" is adopted in the above figured D.10, it is FFS
whether other mechanisms can be used instead to deal with the data received before paging response is acknowledged.

D.2.8.3 Advantages
1. Allows Ues to be registered in Tracking Areas of E-UTRAN, UTRAN and GERAN, which reduces signalling
for idle state Ues.
2. Does not require Gr (MAP) at the SAE entities.
3. Similar user-IP layer mobility management mechanism (e.g. MIP), which is also used for between 3GPP and
non-3GPP access system mobility management.

3GPP

Release 8

188

3GPP TR 23.882 V8.0.0 (2008-09)

D.2.8.4 Drawbacks
1. Some modification of SGSN needed to support initiate paging request to MME/UPE.
2. Some potential limitations as subscriber control and registration with HSS remains on SGSN and control on SAE
entities is via bearer service control. The specific limitations are FFS.
3. Some modification of the SGSN (multiple TA in update confirmation, new message to provide all subscription
information to MME/UPE) needed to further improve the amount of idle state signalling reduction.
4. Some modification of the SGSN and RNC (signalling of transition to URA_PCH to SAE entity) needed to
further improve the amount of idle state signalling reduction if URA_PCH is handled as an idle state.

D.2.9 Combined MME/SGSN

D.2.9.1 Architectural overview
This mechanism is based on the architecture where MME is separated from UPE and where MME is co-localised with
2G/3G SGSN to reduce over the air signalling between 2G/3G and SAE MME, avoiding unnecessary Mobility and
messages for Paging coordination. This will also result in a reduction in signalling with the HSS.
This proposal is based on the concept of Equivalent RA and is also valid when SAE UPE is separated from the Anchor.

3GPP

Release 8

189

3GPP TR 23.882 V8.0.0 (2008-09)

Figure D.11: Architecture overview

In this mechanism the UPE is in the data path of the packet data bearer provided by the 2G/3G SGSN.
If the UE is under 2G/3G coverage, the UE registers with SGSN and receives TMSI and RA and an Equivalent RA from
SGSN. If the UE was under SAE coverage and registered with the MME, it would have received the same TMSI and
TA and list of Equivalent RA from the MME. After the UE has completed it's registration with the HSS via
MME/SGSN during either the RA update procedure or network attachment, the MME/SGSN includes the List of
Equivalent RA (LERA) in the confirm message to the UE.
When the UE registers with the Combined SGSN/MME the HSS is updated and a default packet bearer is established
between the Combined SGSN/MME and the UPE/Anchor. The UE remains registered at the combined SGSN/MME
until it changes Pool Area.
After registering in one Domain, the UE may move between 2G/3G access and Evolved RAN in IDLE mode without
any signalling due to presence of same Equivalent RA under the two Domains.
If the UE was last in 2G/3G SGSN coverage and a downlink data arrives in UPE, DL PDU are duplicated and
duplicates are forwarded to the Combined SGSN/MME. If the UE was last in SAE coverage and a downlink data
arrives in UPE, paging request is sent to MME.
If the UE is in IDLE mode the Combined SGSN/MME initiates paging procedure: MME sends paging to the eNodeB
according to the TA of last known Equivalent RA, SGSN sends paging to RA of Equivalent RA. If the SGSN receives
the Paging response, data is sent by that entity. If the paging response is received by the MME, the MME establishes UP
between Access node and UPE and data is forwarded to Access node.
The paging response might be a Routing or Tracking area (if the UE had changed access technology) and if so this
proposal avoids new signalling to the HLR which minimizes the time required to buffer the downlink packet which
triggered the paging.

D.2.9.2 Downlink data flow to an "inactive" UE

When downlink packets are received at the UPE and the UE is in LTE-Active state, a (virtual) connection between the
UPE and the eNodeB may already exist for the UE. If such a connection exists, the UPE sends the packets directly to
the eNodeB.
After the expiry of the LTE-Active State Timer in the eNodeB, the eNodeB will inform the MME which will then
remove the bearer connection between them eNodeB and UPE. . No user plane transmission path between the eNodeB
and UPE exists for the UE.

3GPP

Release 8

190

3GPP TR 23.882 V8.0.0 (2008-09)

When a downlink packet arrives the procedure described below applies:

UE

SGSN/MME

1. Registration Request

UPE/Inter AS
MM

HSS

2. Register
2. Registration Confirm

3. Registration Accept
4. Activate PDP Context Request
4. Activate PDP Context Response

5. UE in IDLE mode
changes access system
with no signalling
6. Data
9. Parallel Paging
procedures under
2G/3G and SAE

7. Data
8. Paging

10a. Paging Response

10b. Paging Response
11a. Data
11b. Data

1. A LTE-capable UE performs a registration with the SGSN if under 2G/3G coverage or with the MME if under
SAE coverage.
2. The SGSN/MME registers at HSS and retrieves subscriber data.
3. In case of successful authentication/authorisation, the SGSN/MME accepts the UE Registration.
4. If the UE is under 2G/3G coverage, it activates a default PDP Context, the SGSN interface with UPE to establish
the bearer plane. If the UE is under SAE coverage, default bearer is defined with UPE. The UPE knows in which
combined SGSN/MME node the UE camps.
5. The UE moves to IDLE mode. SAE Default bearer is released if present. The UE moves between access types
(from 2G/3G to SAE or from SAE to 2G/3G) without exchanging new signalling with the Network.
6. Downlink data arrives at UPE
7. If a tunnel exists with the SGSN, the UPE stores downlink packets and forwards duplicates to the SGSN. If there
is no Iu connection for the UE, SGSN initiates paging in last known RA of the UE, else it forwards DL PDU to
the appropriate RNC. MME pages the UE in the last known TA of the UE.
8. If there is no tunnel with the SGSN, the UPE stores downlink packets and initiates a paging request with the
combined SGSN/MME. The combined MME/SGSN initiates 3G paging in last known RA and in last known TA
(Equivalent RA).
9. Paging takes place in the two Domains (2G/3G and SAE) in parallel. The UE is paged on each of the E-UTRA,
UTRA and 2G Cells that are contained within the list of Equivalent RAIs allocated to the UE. If an Iu connection
for this UE exists in the SGSN, the SGSN forwards the packets to the RNC to allow it to page the mobile and
handle URA_PCH or CELL_PCH states.
10. a) and b): When the UE receives the Paging message it responds with the Service Request/Cell Update message
(or E-UTRA equivalent) in the respective domain.

3GPP

Release 8

191

3GPP TR 23.882 V8.0.0 (2008-09)

11. In case the UE responds to the SGSN, the SGSN sends data to the UE in step 11a and MME paging can be
stopped. In case the UE responds to the MME, the bearer plane between eNodeB and UPE is established and the
UPE forwards the IP packet buffered for the UE to the eNodeB in step 11b and SGSN paging can be stopped. If
the UE changed access technology, the response will probably be either a Routing/Tracking Area Update but
there is no need for the combined MME/SGSN to update the HLR, thus saving some signalling. In case the UE
was in URA-PCH state, UE response to paging is not visible from the MME, MME paging shall be stopped
based on a timer.

D.2.9.3 Summary
It is believed that, the description given above in Annex D, clause D.2.x shows that this mechanism can limit "inactive
mode signalling".
Upgrades to existing equipment are avoided through combination of MME with 2G/3G SGSN.

D.2.9.4 Advantages
1. No signalling for coordination is needed between SGSN and MME.
2. UE is paged by the SGSN and also in Equivalent RA by the MME allowing reaching UE which have change
access technology in URA-PCH state.
3. Reduces user plane latency (paging in all access technologies occurs in parallel).
4. Reduction in session setup time when transitioning from IDLE to ACTIVE as there is less interaction with the
HLR.
5. Limits IDLE mode signalling due identical Equivalent RA configuration.
6. Allows overlapping tracking areas between E-UTRA / UTRA and GSM regardless which tracking area concept
is used in each technology, which reduces signalling.
7. It is possible to assign multiple tracking areas to the terminal, which avoids hard tracking area borders also
within each access.
8. A unique interface with the HLR is needed.
9. There is no new registration with the HLR during inter-access mobility.

D.2.9.5 Drawbacks
Editor's Note: This list was prepared with respect to "Solution A" in clause D.2.4.4.1.
1. Requires addition of MME features with SGSN

3GPP

Release 8

D.3

192

3GPP TR 23.882 V8.0.0 (2008-09)

Information Flows

Note: all flows do not make any assumption on the collocation of entities, so some cases where IASA is distinct
from MME/UPE are shown as well as some cases where it is collocated with it.

D.3.1 Attach to SAE and RAT change to 2G/3G

UE

SGSN

MME/UPE

HSS

1. Attach Request (IMSI, APN)

3. Authentication Request (RAND)
4. Authentication Response (SRES)

2. Register MME
2. Registration Confirm

6. Attach Accept (S-TMSI, S-RA, IP config)

RAT change
7. RA Update (S-TMSI, S-RA)
8. SGSN Context Request (S-TMSI, S-RA)
8. SGSN Context Response (IMSI, S-TMSI, S-RA, keys in MM ctxt)
9. Authentication

2. Register SGSN
2. Registration Confirm
10. SGSN Context Acknowledge
PDP Request
11. Update PDP Request
11. Update PDP Response

12. RA Update Accept (S-TMSI, S-RA, TMSI, RA)

13. RA Update Complete

Note: any assumption on the collocation of entities cannot be derived from this figure. Implementations collocating
IASA and MME/UPE are not excluded.
When the UE performs Attach or RA Update with the MME/UPE, it receives an S-TMSI and an TA of the Evolved
RAN. When the UE performs Attach or RA Update with the SGSN it receives a TMSI and a RA of the 2G/3G RAN.
The UE memorizes these two pairs of identifiers.
After registration once with SGSN and once with MME/UPE, the UE may change between 2G/3G access and Evolved
RAN without any RA Update signalling as long as it does not change the TA or RA and does not need to send/receive
UL/DL data.
When the UE moves between SGSN and MME in the allocated RA and TA, there is no UE signalling with the Network,
thus no signalling with the HLR.
The MM and PDP Contexts including security parameters are always kept up-to-date on latest access (SGSN or
MME/UPE) and transferred on demand to the current access as described above. This keeps security consistent data for
all situations, e.g. also handover between 2G/3G and LTE. It is FFS whether during such contexts transfer procedure,

3GPP

Release 8

193

3GPP TR 23.882 V8.0.0 (2008-09)

the current access node shall deliver some Keep-context-indicator to make the previous access node keep the saved
contexts instead of removing them. It is FFS whether such MM and PDP contexts include security contexts.
Optimisations e.g. using a Context reference Number are FFS. It is FFS whether periodic updates are considered as
latest access.
To save some Authentication vectors and ensure the UE uses same authentication vectors for MME and SGSN as both
handles same PS bearers, authentication vector can be exchanged between MME and SGSN (vectors used in the old
MME can be known in the new SGSN and vice-versa). It is FFS whether the UE should use same authentication vectors
for MME and SGSN.
It is FFS whether MME and SGSN are registered in parallel at the HSS, or whether only one entity MME or SGSN is
registered at a time at the HSS.
It is FFS whether and how periodic updates are used. It is FFS whether and how the network detects that a UE is nonreachable (e.g. to stop paging for downlink data) or when UE contexts can be deleted from MME or SGSN after long
period of inactivity.

3GPP

Release 8

194

3GPP TR 23.882 V8.0.0 (2008-09)

D.3.2 Attach to UMTS and RAT change to LTE

UE

SGSN

MME/UPE

HSS

1. Attach Request (IMSI)

3. Authentication
2. Register SGSN
4. Attach Accept (TMSI, RA)

2. Registration Confirm

5. Activate PDP Context

RAT change
6. RA Update (TMSI, RA)
7. SGSN Context Request (TMSI, RA)
7. SGSN Context Response (IMSI, keys in MM context)
8. Authentication
9. SGSN Context Acknowledge

10. Register MME

11. RA Update Accept (S-TMSI,
S-RA, TMSI, RA)

10. Registration Confirm

12. RA Update Complete

RAT change with change of RA
13. RA Update Request (S-TMSI, S-RA, TMSI, RA)
14. SGSN Context Request (S-TMSI, S-RA)
14. SGSN Context Response (IMSI, keys in MM context)
2. Register SGSN
15. RA Update Accept (S-TMSI, S-RA, TMSI, RA)

2. Registration Confirm

Note: any assumption on the collocation of entities cannot be derived from this figure. Implementations collocating
IASA and MME/UPE are not excluded.
Note: It is FFS in step 6) how to derive the address of the MME/UPE that was allocated in step 56). It is FFS whether
providing S-TMSI and S-TA to UE in step 5) can be used.
When the UE performs Attach or RA Update with the MME/UPE, it receives an S-TMSI and an TA of the Evolved
RAN. When the UE performs Attach or RA Update with the SGSN it receives a TMSI and a RA of the 2G/3G RAN.
The UE memorizes these two pairs of identifiers.
After registration once with SGSN and once with MME/UPE, the UE may change between 2G/3G access and Evolved
RAN without any RA Update signalling as long as it does not change the TA or RA and does not need to send/receive
UL/DL data.

3GPP

Release 8

195

3GPP TR 23.882 V8.0.0 (2008-09)

When the UE moves between SGSN and MME in the allocated RA and TA, there is no UE signalling with the Network,
thus no signalling with the HLR.
The MM and PDP Contexts including security parameters are always kept up-to-date on latest access (SGSN or
MME/UPE) and transferred on demand to the current access as described above. This keeps security consistent data for
all situations, e.g. also handover between 2G/3G and LTE. It is FFS whether during such contexts transfer procedure,
the current access node shall deliver some Keep-context-indicator to make the previous access node keep the saved
contexts instead of removing them. It is FFS whether such MM and PDP contexts include security context depending on
SA3 decision. Whether the serving SGSN/MME should store all the up-to-date contexts both for SGSN and MME/UPE
is FFS. In case of some special contexts only for one access system, those specific context may be only stored in one
access system. It is FFS whether periodic updates are considered as latest access.
It is FFS whether CRN (Context Reference Number), which inflects whether the context is up-to-date in the access
node) mechanism should be used to save signalling between SGSN and MME. The SGSN should send SGSN Context
Request to MME only if the CRN sent by the UE mismatches with the one stored in SGSN.
To save some Authentication vectors and ensure the UE may uses same authentication vectors for MME and SGSN as
both handles same PS bearers, authentication vector can be exchanged between MME and SGSN (vectors used in the
old MME can be known in the new SGSN and vice-versa).
Editor's Note: is re-use of vectors meant here? It is FFS if the UE should use same authentication vectors for MME
and SGSN.
It is FFS whether MME and SGSN are registered in parallel at the HSS, or whether only one entity HSSMME or SGSN
is registered at a time at the HSS.
It is FFS whether SGSN should send registration at the HSS after the step 14 due to no change of the SGSN.
It is FFS whether and how periodic updates are used. It is FFS whether and how the network detects that a UE is nonreachable (e.g. to stop paging for downlink data) or when UE contexts can be deleted from MME or SGSN after long
period of inactivity.

3GPP

Release 8

196

3GPP TR 23.882 V8.0.0 (2008-09)

D.3.3 Uplink Data Transfer

UE

RNC

eNodeB

SGSN

MME/UPE

Uplink data on 3G
1. RA Update Request
2. SGSN Context Request (IMSI)
4. Security Mode Command (keys)

3. SGSN Context Response (contexts and keys)

5. Update PDP

6. RA Update Accept
6bis. Service Request
7. RAB Establishment

8. Uplink User Data

Uplink data on LTE

1. Service Request
2. SGSN Context Request (IMSI)
3. SGSN Context Response (contexts and keys)
2. Service Accept
3. RAB Establishment
4. Uplink User Data

Note: any assumption on the collocation of entities cannot be derived from this figure. Implementations separating
IASA and MME/UPE are not excluded.
The information flow assumes that the UE has registered to both SAE network and UMTS network for signalling free.
Note: For the uplink data on 3G, retrieving the latest context from the old MME/UPE may increase the call setup
latency. Optimisation is FFS for example to move the step 2 3 4 5 after step 6bis then remove the RA procedure. Or,
steps 2,3,5 may be optional as only needed when latest access was on LTE or CRN is mismatched if CRN mechanisms
are applied.
The uplink data transfer on 3G may be optimised by starting immediately with a Service Request instead of RAU
Request, which is FFS.
Note: for the uplink data on LTE case, it is FFS whether the MME/UPE retrieves UE contexts (step 2&3) in all cases
or only when uplink data transfer is initiated on another RAT than the UE used as the latest LTE access
before or CRN is mismatched if CRN mechanisms are applied.
For uplink data transfer, when the UE camps on Evolved RAN, the Service Request triggers the MME to derive up-todate PDP context and security information from the old SGSN by means of the SGSN Context Request procedure. For
uplink data transfer, when the UE camps on 2G/3G the RAU Request triggers the SGSN to derive up-to-date PDP
context and security information from the old MME/UPE by means of the SGSN Context Request procedure. The UE

3GPP

Release 8

197

3GPP TR 23.882 V8.0.0 (2008-09)

can then initiate another NAS signalling as needed such as the Service Request re-activate PDP Sessions. This
establishes in addition a data path to the MME/UPE and forwards data received from the UE to the MME/UPE.

D.3.4 PMM-IDLE and URA-PCH state handling

UE

RNC

eNodeB

SGSN

MME/UPE
2G/3G connected

UE moves to PMM-IDLE in SGSN

1a. Iu Release
2a. UE Idle
2G/3G dis-connected

2G/3G connected
UE moves to URA-PCH in RNC
1b. URA PCH entered
2b. UE Idle
2G/3G dis-connected

Note: any assumption on the collocation of entities cannot be derived from this figure. Implementations separating
IASA and MME/UPE are not excluded.
Note: in steps 2, it is FFS whether existing SM messages can be used instead of new messages.
Note: step 1b, 2b are dependent on whether URA_PCH state should be supported for signalling free(see RP-050893
and report of RAN plenary #30). The signalling load impacts of this mechanism are FFS. The interaction
of this approach with 2G Ready to Standby state transitions is FFS.
Note: how subsequent transitions from URA-PCH to other RRC connected substates (and from GPRS standby to
GPRS ready) are FFS.
Whether synchronous mode or asynchronous mode is used is FFS. The above figure is synchronous mode.
To reach UE, UPE would keep two flags to indicate the UE is active or idle in E-UTRA and UTRA: one flag is EUTRA active or not and another is UTRA active or not. If both of them are idle, the UE would be paged in the
both RATs. If one of them is active, the data would be sent to the RAN.
The information E-UTRA active or not is easy to get by whether the tunnel between the UPE and the ENB exists or
not. But the information UTRA active or not is not so easy to get. To page the UE correctly, there are several
mechanisms that can be used. The choice of mechanism is FFS. Two possible mechanisms are ways to achieve it:
a) synchronous mode:
Whenever the UE turns to PMM_IDLE state, the SGSN informs MME/UPE; and whenever the UE moves in URA_PCH
state, the SRNC informs MME/UPE (via SGSN), so that the UPE gets UTRA active or not as idle synchronously.
When downlink data arrive at the UPE, the MME/UPE starts paging in E-UTRA and the MME/UPE requests the SGSN
to page the UE if the UEs UTRA active or not and E-UTRA active or not both are idle. In case the UE
responses in UTRA, the UPE set UTRA active or not as active.
b) asynchronous mode:

3GPP

Release 8

198

3GPP TR 23.882 V8.0.0 (2008-09)

Although the UE moves in PMM_IDLE or URA_PCH state, the MME/UPE may not know about it and the UTRA
active or not is still active. When downlink data arrive at the UPE, the UPE send data to the SGSN. In case the UE
is in PMM_IDLE state, the SGSN pages the UE in UTRA and return copy data to the UPE to indicate it to page the UE
in E-UTRA. In case the UE is in URA_PCH state, the SGSN send data to SRNC, and the SRNC return copy data to the
UPE (via SGSN) to indicate it to page the UE in E-UTRA. If the UE responses paging in E-UTRA, UTRA active or
not will be set idle.

D.3.5 Downlink Data Transfer

RNC

UE

eNodeB

SGSN

MME/UPE

If UE is 2G/3G connected

1. User Data

If UE is LTE connected

1. User Data

If UE 2G/3G and LTE dis-connected

2. Paging

2. Paging Request

1. Paging Request(SM info)

2. Paging

2. Paging Request

UE in PMM-IDLE on 3G
3a. Paging Response
4a. Paging Response

5a. RAB Setup

UE states moves to
2G/3G connected

6a. User Data

UE in URA-PCH on 3G
3a. Paging Response
4a. paging Response

UE states moves to
2G/3G connected
6a. User Data

UE on LTE

3b. Paging Response

LTE connected
4b. RAB Setup
5b. User Data
6b. Paging Cancel

NOTE:

Any assumption on the collocation of entities cannot be derived from this figure. Implementations
separating IASA and MME/UPE are not excluded.

3GPP

Release 8

199

3GPP TR 23.882 V8.0.0 (2008-09)

NOTE:

In step a, it is FFS whether the existing SM message can be used in stead of a new message.

NOTE:

Step 4a is dependent on whether exists only if it is agreed that URA_PCH state should be supported for
signalling free (see RP-050893 and report of RAN plenary #30). The interaction of this approach with 2G
Ready to Standby state transitions is FFS.

This proposal implies RNC-MME/UPE signalling each time the UE changes to URA-PCH state. This could be avoided
if the UPE duplicates and sends duplicated data to the SGSN when UE is in PMM-CONNECTED state. The RNC
receiving DL data while the UE is in URA-PCH should then signal the UE state to MME/UPE (via SGSN) so that UPE
stops sending data and starts parallel paging with MME.
When downlink data arrive at MME/UPE, the MME/UPE starts paging in the TA of the Evolved RAN and the
MME/UPE requests the SGSN to page the UE. The SGSN paging is triggered by a MME/UPE message. (It is FFS
whether further enhancement is needed to allow the UPE to provide the SGSN with up-to-date PDP context and security
information at that stage). When the UE responds to the MME/UPE, data are sent by the MME/UPE to the UE. When
the UE responds to the SGSN, the SGSN's response establishes the data path(s) between MME/UPE and SGSN and
data are sent by the MME/UPE via the SGSN to the UE.

D.3.6 SGSN (respectively MME) change

If the UE arrives under a new SGSN (respectively MME), the new SGSN gets MM and SM information from MME
(respectively SGSN), like for an inter-SGSN RAU procedure. In order to allow the new SGSN (respectively MME) to
identify the old node the UE was previously attached to, the UE provides a pair of access type identifiers: 2G/3G
identifiers (old TMSI and old S-TMSI), and SAE ones (old RAI and old Tai), with an indication of the latest one. The
new SGSN (respectively MME) retrieves MM/SM context information from the latest node the UE was attached to. It
is FFS whether CRN mechanisms are used. In this case the new SGSN retrieves MM/SM context information from the
old SGSN and may retrieve contexts from MME in case of the CRN mismatch.
The new SGSN (respectively MME) registers to the HLR.
Registration with the HSS allows subscription changes to be sent to the current active node (SGSN or MME). ). It is
FFS how for the new active node to retrieve the changed subscription when the UE changes the RAT.
To save process time, it is FFS whether Cancel Location sent by the HLR should not remove MM/SM information so
that MME keeps UE context information when UE is under SGSN coverage for further usage.

D.3.7 re-authentication when UE camped within ERA

UE

SGSN

MME/UPE

2 Paging request

3 Paging

1 re-authentication decision

3 Pagi ng

1 re-authentication decision
3 Paging

2 Paging request
3 Pagi ng

4 re-authentication procedure
5 security information exchange

4 re-authentication procedure
5 security information exchange

3GPP

HSS

Release 8

200

3GPP TR 23.882 V8.0.0 (2008-09)

It is FFS whether and when the network triggers a standalone re-authentication or whether re-authentication is
combined with other procedures, e.g. with periodic updates.
When MME (respectively SGSN) initiates re-authentication procedure, MME/UPE (respectively SGSN) starts paging
the UE in the TA (respectively RA) of the Evolved RAN (respectively UTRA) and the MME/UPE (respectively SGSN)
requests the SGSN (respectively MME/UPE) to page the UE. The SGSN (respectively MME/UPE) paging is triggered
by a MME/UPE (respectively SGSN) message. The access node which response the paging response shall carry out the
mutual re-authentication procedure with the UE, and exchange security information with the other node to synchronize
on the usage of Authentication vectors.
For the UE initiates re-authentication procedure, the current access node shall carry out the mutual authentication with
the UE, and exchange security information with the other node to synchronize on the usage of Authentication vectors.

D.4

Potential mechanisms for context retrieval

This clause introduces several alternative mechanisms for context retrieval, to be used as part of alternative potential
solutions described in clause D.2.

D.4.1 Fully synchronous mechanism

Fully synchronous mechanism means whenever MME/SGSN changes relative contexts (MM/SM information), the
MME/SGSN pushes them to the other registered node of the UE (e.g. SGSN/MME). So before the UE accesses the
network, both RATs nodes have the latest information. Theres no need for the access node to retrieve the contexts
during the UE's access procedure.

D.4.2 MME as master, SGSN as slave

The MME always has the latest information, which means that the SGSN would push the contexts to the MME when
the SGSN updates the contexts as an access node, but the MME wont push contexts to the SGSN when the MME
updates the contexts. And when the UE accesses LTE, the MME dont retrieve contexts from the SGSN, while the
SGSN retrieves contexts from the MME if the UE arrives under 2G/3G.

D.4.3 Coordination between MME and SGSN

MME has up-to-date contexts when UE is under LTE coverage; SGSN has up-to-date contexts when the UE is under
2G/3G coverage. The MME retrieves contexts from the SGSN when the UE arrives under LTE coverage and the SGSN
retrieves contexts from the MME when the UE arrives under 2G/3G coverage. There is no pushing contexts procedure
compared with the above two approaches.

D.4.4 Retrieval context from the last access node

When the UE arrives under a new node, the new node retrieves information from previous node since the last access
node always has the latest contexts. The approach also doesnt need to push contexts. Compared with mechanism
described in D.4.3 (the coordination approach), there is no need to retrieve contexts from other node in case the access
node is the same as the node immediately prior to the last access node. The approach needs the UE indicate the last
access information at access procedure.

D.4.5 MME as master, SGSN as slave, plus CRN mechanism

Whenever the SGSN changes UE contexts, the CRN is updated in the SGSN and synchronized to the MME and the UE.
When the UE accesses 2G/3G, the UE sends the CRN to the SGSN. Only if the SGSN detects the CRN mismatch, the
SGSN will pull the contexts from the MME. As a result, there is no need for the SGSN to pull contexts from the MME
if the SGSN already has the up-to-date contexts (for example, the MME did not update the contexts or the UE continue
to access the SGSN)

3GPP

Release 8

201

3GPP TR 23.882 V8.0.0 (2008-09)

D.4.6 Coordination between MME and SGSN, plus CRN

mechanism
If the contexts are changed, the SGSN updates the CRN and synchronizes it to the UE. If the UE then accesses to the
MME, it will send the CRN to the MME. In case the MME detects the CRN mismatch the one stored in it for the UE, it
will pull contexts from the SGSN and update its CRN as the CRN the UE sent. In case the CRN kept in the MME
matches the CRN the UE sent, the MME doesnt need to pull contexts from the SGSN. If the UE move from SAE
network to 2G/3G network the procedure is vice versa.

D.4.7 Retrieval context from the last access node, plus CRN
mechanism
The CRN mechanism is used like in the approach D.4.6. When the UE accesses the 2G/3G network, the UE indicates
the CRN to the SGSN. In case the SGSN detects the CRN mismatched, the SGSN will pull UE contexts from the MME.
When the UE move from 2G/3G network to SAE network, the context procedure is vice versa. Because the CRN must
match if the access node is the last access node, theres no need to bring last access information. So, the approach could
be converged into approach D.4.6.

3GPP

Release 8

202

3GPP TR 23.882 V8.0.0 (2008-09)

Annex E:
Mobility between pre-SAE/LTE 3GPP and non
3GPP access systems
E.1

General

The intent of this Annex is to study architectural solutions for session continuity and seamless mobility for 3GPPWLAN Interworking in parallel to the study of the evolved system. The goal is to develop a feasible architectural
solution for session continuity and seamless mobility for 3GPP-WLAN Interworking, which allows evolution towards
the SAE architecture for mobility between access systems using 3GPP and non-3GPP radio.

E.2

Description of mobility between pre-SAE/LTE 3GPP

and non 3GPP access systems

The term Access System is used here to designate one of the following:
-

The GPRS IP access (including both the PS core network and the RAN),

The WLAN 3GPP IP Access, or

The WLAN Direct IP Access.

Currently there is no standard means for ensuring session continuity or seamless mobility between these two systems.
Whenever the UE moves between the two, any established session will fail and will have to be tunnelled. The purpose
of this clause is to study mobility solutions.

E.3

Solutions for mobility between pre-SAE/LTE 3GPP

and non 3GPP access systems

E.3.1 Solution A
This clause assumes that Mobile IP is used as mobility protocol for GPRS-WLAN mobility, whereas MOBIKE [6] is
used for Ue-PDG Ipsec tunnel relocation within the WLAN 3GPP IP Access. It is assumed that the same solution
applies for both session continuity (a.k.a. Scenario 4) and seamless mobility (a.k.a. Scenario 5), depending on the
mobile's capability for simultaneous connections.
Note that in the subsequent text we use the traditional MIP terminology i.e. Mobile Node (MN), Foreign Agent (FA)
and Home Agent (HA).
It is assumed that Home AAA in HPLMN is in charge of user authentication and authorization.
Figure E.1 is a simplified figure describing how the Diameter application for Mobile Ipv4, RFC 4004 [5], works in
conjunction with the Mobile Ipv4 protocol. Depicted is the case where Mobile Ipv4 is used with Foreign Agent Care-of
Address (FA-CoA). This requires a FA functionality within the Gateway (PDG or GGSN). The names associated with
some interfaces (e.g. Wm+, Wd+, Gi-aaa, Rha-aaa, Gi+, Wi+) are clarified later in the text.

3GPP

Release 8

203

3GPP TR 23.882 V8.0.0 (2008-09)

Figure E.1: Use of MIPv4 FA care-of address mode with Diameter application
The following are the subsequent steps described in Figure E.1 (for more details the reader may refer to RFC 4004 [5]):
1) The MN establishes a connection with the GW (i.e. GGSN or PDG);
2) The MIP Foreign Agent (MIP FA) function in the GW sends a FA advertisement;
3) The MN sends a MIPv4 Registration Request (RRQ);
4) The GW interrogates the user's Home AAA server in order to authenticate and authorise the user. In the roaming
case, the GW uses the Proxy AAA to contact the user's Home AAA server. The Home AAA server assigns a
Home Agent (HA) and provides the address of the assigned HA to the GW.
5) The FA forwards the MIPv4 RRQ to the MIP HA.
6) The HA fetches a pre-shared key for MN-HA authentication. This step is required only at session establishment.
Specifically, it is not required for MN-HA authentication when the UE subsequently connects to other Fas.
7-8)

The HA accepts the mobile registration by replying with a MIPv4 Registration Response (RRP).

Figure E.2 is a simplified figure describing how the Diameter application for Mobile Ipv4, RFC 4004 [5], works in
conjunction with the Mobile Ipv4 protocol when no FA present (co-located care-of address mode). The names
associated with some interfaces (e.g. Rha-aaa) are clarified later in the text.

3GPP

Release 8

204

3GPP TR 23.882 V8.0.0 (2008-09)

Figure E.2: Use of MIPv4 collocated care-of address mode with Diameter application when no FA is
present
The following are the subsequent steps described in Figure E.2 (for more details the reader may refer to RFC 4004 [5]):
1) The MN establishes a connection with a GW (e.g. GGSN or PDG) or is otherwise assigned an IP address from
an access network.
2) The MN sends a MIPv4 Registration Request (RRQ) to its HA transparently through the GW. The HA IP address
may be discovered e.g. using DNS resolution of a HA FQDN, or through an agent advertisement, if the Home
Agent is in the same link as the MN.
3) The HA contacts the AAA server to fetch authentication and keying information for the MN. This step is
required at session establishment. Specifically, it is not required for MN-HA authentication when the UE makes
subsequent registrations while the lifetime of the MN-HA keys is not due to expire.
4) The HA accepts the mobile registration by replying with a MIPv4 Registration Response (RRP).
Depicted in Figure E.3 is a simplified view on how a Diameter application may work in conjunction with MIPv6. The
main difference wrt Ipv4 is the absence of Foreign Agent in the GW.

Figure E.3: Use of MIPv6 with Diameter application

The following are the subsequent steps described in Figure E.3:
1) The MN establishes a connection with the GW and begins authentication;

3GPP

Release 8

205

3GPP TR 23.882 V8.0.0 (2008-09)

2) The GW interrogates the user's Home AAA server in order to authenticate and authorise the user. In the roaming
case, the GW uses the Proxy AAA to contact the user's Home AAA server. In addition, the Home AAA server
provides "MIPv6 bootstrap" information i.e. information allowing the Mobile IP client in the UE to configure
itself for MIPv6 service and identify the assigned HA;
3) The GW completes the user authentication;
4) The MN carries out a DHCPv6 procedure for MIPv6 bootstrap;
5-6)

The MN sends a Binding Update (BU) to the MIPv6 HA (this is the equivalent of the MIPv4 RRQ);

7) The HA authenticates the user and fetches keying material for subsequent Binding Updates;
8-9)

The HA accepts the mobile registration by replying with a Binding Acknowledgement (BA).

The next two figures provide examples on how the MIPv4 and MIPv6 concepts described above can be mapped to
scenarios for GPRS-WLAN mobility. The red pipes stand for Ipsec tunnels, whereas the blue pipes represent Mobile IP
tunnels.
Depicted in Figure E.4 is the application of Mobile Ipv4 as a solution for GPRS-WLAN mobility. A FA functionality is
incorporated in both the GGSN and the PDG, meaning that in this case MIPv4 is used with Foreign Agent Care-ofAddress (FA-CoA). The Foreign Agent is not necessary for co-located mode operation of Mobile IP (see Figure E.5).
The "Home AAA" functions which are required for the Diameter MIPv4 application are assumed to be provided by the
3GPP AAA server.
The MIPv4 tunnelling is used only on the Gi+ and Wi+ interfaces i.e. between the HA and the FA located in the GGSN
and the PDG, respectively.

Figure E.4: Use of MIPv4 with FA-CoA for GPRS-WLAN mobility

NOTE 1: In case the HA functionality is collocated with the GGSN, the terminal can be considered to be at home in
Mobile IP sense when using the GPRS IP access. The FA functionality in the GGSN becomes redundant
in this case.
NOTE 2: In case the GGSN and the PDG are attached to the same IP subnet, the use of MIP is FFS.
NOTE 3: Whether the FA functionality has to be collocated with the GGSN/PDG or whether it can exist as a standalone element is FFS.

3GPP

Release 8

206

3GPP TR 23.882 V8.0.0 (2008-09)

The same architecture applies to both Scenario 4 and Scenario 5, the only difference being that in Scenario 5 the UE is
assumed to maintain simultaneous connections across the source and target Access System during the transition period.
Depicted in Figure E.5 is the application of Mobile Ipv6 as a solution for inter-system mobility. The same figure also
applies to the use of MIPv4 with collocated Care-of-Addresses (co-CoA).

Figure E.5: Use of MIPv6 or MIPv4 with co-CoA for GPRS-WLAN mobility
In either case there is no notion of Foreign Agent in the GGSN or the PDG. MIP tunnelling is used from the HA all the
way down to the UE. In case of MIPv6, the MIPv6 "route optimisation" mechanism is used to avoid tunnelling over the
radio.
Regarding inter-WLAN mobility, relying on Mobile IP alone may not be sufficient for achieving Scenario 5-like
seamless mobility. A possible issue here is the time required for setting up a new Ipsec tunnel when changing the point
of WLAN attachment, because, contrary to the inter-system handover, the UE may not be able to initiate a new Ipsec
tunnel setup before breaking the previous one. The IETF MOBIKE group is currently working on mechanisms for
speeding up this kind of Ipsec tunnel relocation. Figure E.6 clearly shows that Mobile IP does not intervene during the
relocation of the Ipsec tunnel. MOBIKE would be used instead.

3GPP

Release 8

207

3GPP TR 23.882 V8.0.0 (2008-09)

Figure E.6: MOBIKE use for inter-WLAN mobility

E.4

Impact on the baseline CN architecture

E.4.1 Solution A
Depicted in Figure E.7 is the baseline architecture taken from 23.882, from which all IMS specific elements have been
removed for simplicity. In addition, a Mobile IP Home Agent (MIP HA) has been added to the figure, as well as a
couple of reference points. Listed below are all new or modified reference points, with a description of their role:
-

Gi+/Wi+: this is the Mobile IP signalling and bearer plane between the Gateway (i.e. GGSN or PDG) and the
MIP HA;

Wj; this is the Mobile IP signalling and bearer plane (tunnel) between the UE and the MIP HA, which is used in
case of MIPv4 co-located care-of address and MIPv6;

Gi-aaa: this is the AAA part of the Gi interface, which traditionally connects the GGSN to a AAA server which
itself is not part of the 3GPP system architecture. Here it is assumed that the Gi-aaa interface connects to the
3GPP AAA server. It is used by the Diameter Mobile IP application, RFC 4004 [5], for dynamic assignment of a
MIP HA, as well as during setup of security associations (MN-HA, MN-FA, FA-HA);

Wm+/Wd+: this is respectively an enhancement to the existing Wm and Wd reference points. The additional
functionality is similar to the Gi-aaa functionality described above;

Rha-aaa: this is the reference point between the MIP HA and the 3GPP AAA server. Similar to the previous, it is
used for dynamic assignment of a MIP HA and during setup of security associations.

The impact on the PCRF is left FFS.

The applicability to WLAN Direct IP Access is FFS.

3GPP

Release 8

208

3GPP TR 23.882 V8.0.0 (2008-09)

Figure E.7: Impact of Mobile IP on the baseline architecture

E.5

Impact on the baseline RAN architecture

None.

E.6

Impact on terminals used in the existing architecture

E.6.1 Solution A
In order to support GPRS-WLAN mobility with session continuity (i.e. Scenario 4), the terminal must have a Mobile IP
client and a MOBIKE client. In order to support seamless mobility (i.e. Scenario 5), the terminal must in addition be
capable of simultaneous connections.
Other impacts on the terminal are FFS.

3GPP

Release 8

209

3GPP TR 23.882 V8.0.0 (2008-09)

Annex F:
Policy related network Scenarios
F.1

Scenario 1: Inter-system mobility within the home

domain

As the user changes between two access systems, its serving MME/UPE may change. All user plane traffic will pass the
anchor node(s) in addition to the serving MME/UPE. Depending on the grouping of functions (which is FFS), the
anchor nodes may be interpreted as MME/UPE, Inter-AS Anchor, or both.
For a single user, one PCRF node controls the anchor node(s), over an enhanced Gx interface (Gx+). This means that
when a user moves between 3GPP cellular accesses and non-3GPP access such as I-WLAN, the PCRF will remain
unchanged. Policy enforcement (PEP) and charging functions (TPF) are in the anchor node(s).
It is FFS whether policy enforcement functions are needed in the serving MME/UPE.
NOTE:

F.2

The single PEP assumption for this scenario may prevent the use of route optimisation for traffic
generated in the non-3GPP access system. Whether this is an issue for the non-roaming case is FFS.

Scenario 2: Roaming with home

forwarding/tunnelling of traffic

In this scenario a user moves to an access operated by a different operator than its home operator, i.e. the user is
roaming. The access type used in the visited domain may or may not be different from the access type used in the home
domain. Traffic is forwarded/tunnelled home from the MME/UPE in the visited domain to the anchor node(s) in the
home domain. Policy enforcement (PEP) and charging functions (TPF) are in the anchor node(s).
Since the serving MME/UPE is in the visited domain, QoS support is needed in the MME/UPE. The visited network
operator may prefer not to allow another business entity, i.e. the home operator, to have direct control over its
MME/UPE and set QoS and charging filters, since this would make it very difficult for the visited operator to take
responsibility for the management of its own MME/UPE.
It is FFS whether a PCRF node is needed in the visited domain in order to transfer dynamic AF session information to
policy enforcement functions (PEP) in the serving MME/UPE, when there already are both PEP and TPF in the home
domain anchor node(s).
If such a roaming interface is defined and used for the transfer of dynamic AF session information (or some translation
thereof) to the MME/UPE, it should not make the AF mobility-aware, i.e., the AF should not need to be aware that the
user is roaming. This would add complexity into the AF, which is clearly not desired. In addition, the interface should
also allow the home network to be involved in e.g. admission control decisions together with the transfer of the AF
session information (or some translation thereof).
If it will be decided that the existence of both PEP and TPF in the home domain anchor node(s) is not enough to support
the QoS in the visited domain, it is FFS how to translate the dynamic AF session information so that a roaming
agreement between the visited and the home domains can be applied to the QoS policies of the AF session in a
consistent fashion.
The inter-system mobility in the visited domain may imply a PEP relocation. How policy control works in conjunction
with PEP relocation is FFS.

3GPP

Release 8

F.3

210

3GPP TR 23.882 V8.0.0 (2008-09)

Scenario 3: Static roaming agreement

This is a simplified scenario with limited capabilities. It does not provide any PCC features, i.e. it does not use a PCRF
to install dynamic policy or charging rules. Such a simplified scenario might be used for e.g., plain best-effort internet
access. Basic policy and charging functionality, (e.g., measurement of the total amount of bytes transferred) could be
pre-provisioned or provided over a AAA interface between the home and the visited domains.

F.4

Scenario 4: Roaming with route optimisation of traffic

in the visited domain, AF in the home domain

This scenario is similar to scenario 2, with the difference that traffic is not forwarded/tunnelled to the home domain;
instead it is routed optimally between the visited domain and the peer node. The application function, however, is still in
the home domain; or alternatively it is outside the home domain (e.g. at a third-party) but is connected to the PCRF in
the home domain.
The traffic passes through the visited network and not the home network, but it should be under the control of the home
operator. Bi-directional route optimization is needed in most cases.
Due to the fact that no anchor node is involved in handling of the user plane traffic in the home network, policy
enforcement has to be implemented in the visited domain. It is FFS whether PCRF nodes need to be involved in the
home and visited domains in order to transfer dynamic AF session information for policy enforcement in the
MME/UPE. It is FFS whether the roaming agreement required between the home and the visited domains is feasible. In
particular, it is FFS how the roaming agreements for charging can be made simpler, e.g. if charging is based on session
signalling, and media is zero-charged.
The use of route optimisation may require updates to the PEP configuration (e.g. if the bearer route can switch between
optimised and non-optimised mode during the lifetime of a session). How this is achieved is FFS.

F.5

Scenario 5: Roaming with local breakout of traffic in

the visited domain, AF in the visited domain

In this scenario, the AF is in the visited domain, or at a third party but connected directly to the visited PCRF. Bidirectional route optimization is expected in this scenario. In this case policy control takes place fully in the visited
network, without direct signalling from the home network. The way policy rules are provided by the PCRF in the
visited domain has to be settled in the roaming agreement with the home domain. It is FFS whether an increasing
reliance on the roaming agreement to provide control in the visited domain is feasible, and what modifications would be
needed to the roaming agreements.
In particular, it is FFS how charging is handled in the visited network.
It is FFS whether the home network AF takes part in the service provisioning.

F.6

Scenario 6: Roaming with local breakout of some

traffic in the visited domain, forwarding/tunnelling
other traffic to home network

This scenario is a combination of scenario 2 and scenario 4/5. For some services, e.g. voice services and streaming
services, local breakout for user plane traffic has advantages in performance and bandwidth saving. However, for other
services, it is reasonable that the home operator would like to have more control and forwarding/tunnelling is expected.

3GPP

Release 8

211

3GPP TR 23.882 V8.0.0 (2008-09)

Annex G:
Examples of Operator-Controlled Services
G.1

Operator-Controlled Rx Services

An operator has a specific charging rate for user-user VoIP traffic over the IMS. A PCC rule is established for this
service data flow. The filter information to identify the specific service data flow for the user-user traffic is provided by
the P-CSCF.
An operator is implementing UICC based authentication mechanisms for HTTP based services utilizing the GAA
Framework as defined in TR 33.919 [11] by e.g. using the Authentication Proxy. The Authentication Proxy may appear
as an AF and provide information to the PCRF for the purpose of selecting an appropriate PCC Rule.

G.2

Operator-Controlled Gx-only Services

A network server provides an FTP service. The FTP server supports both the active (separate ports for control and data)
and passive modes of operation. A PCC rule is configured for the service data flows associated with the FTP server for
the user. The PCC rule uses a filter specification for the uplink that identifies packets sent to port 20 or 21 of the IP
address of the server, and the origination information is wildcarded. In the downlink direction, the filter specification
identifies packets sent from port 20 or 21 of the IP address of the server.
A network server provides a "web" service. A PCC rule is configured for the service data flows associated with the
HTTP server for the user. The PCC rule uses a filter specification for the uplink that identifies packets sent to port 80 of
the IP address of the server, and the origination information is wildcarded. In the downlink direction, the filter
specification identifies packets sent from port 80 of the IP address of the server.
The same server also provides a WAP service. The server has multiple IP addresses, and the IP address of the WAP
server is different from the IP address of the web server. The PCC rule uses the same filter specification as for the web
server, except the IP address is different.
An operator offers a zero rating for network provided DNS service. A PCC rule is established setting all DNS traffic
to/from the operators DNS servers as offline charged. The data flow filter identifies the DNS port number, and the
source/destination address within the subnet range allocated to the operators network nodes.
For the IMS signalling traffic, a PCC rule may be configured, which includes a charging key for zero rating and the
authorised QoS parameters. The data flow filter identifies the P-CSCF source/destination address within the subnet
range allocated to the IMS nodes.

3GPP

Release 8

212

3GPP TR 23.882 V8.0.0 (2008-09)

Annex H: Signalling charts for combined or separated MME

and UPE
This Annex presents information flows of SAE procedures that demonstrate on a high level the differences between
alternative function allocation to MME and UPE and whether the MME and UPE are grouped or separated with an open
interface.
Editors note: These information flows are work-in-progress and details and principles need to be clarified for each
alternative for performing the final comparison and decision.
The information flows presented here only serve as illustrations of the principal differences between the proposed
alternatives to support the comparison and selection of specific functional grouping and allocation of functions to
functional entities. The information flows need to provide sufficient level of details to enable identification of main
differences and thereby identifying the questions that need to be answered. It is not intended to develop the final
information flows in this annex.
These draft information flows are shown for the following alternatives:
A. Combined MME/UPE.
B. Separate MME and UPE with control signalling mostly via the MME, and session and context management in
MME.
C. Separate MME and UPE with control signalling via the MME or the UPE, and session and context
management only in UPE.
For alternative A, the flows are adopted from the related key issue solution descriptions of this document where the
MME/UPE is shown as a combined entity. Therefore they may lack details and may not be completely according to the
views of the companies supporting alternative A.
For alternative B and C is also the functional allocation shown.
The following non-exhaustive list of procedures are described, and other procedures can be added later on:
1.

Attach including default bearer handling

2.

TA Update without MME or UPE change

Note: Procedure has not been proposed for alternative A.

3.

Inter eNB Handover in LTE_ACTIVE mode (intra MME and intra UPE)
Note: Various other procedures have been proposed where the MME and/or UPE are also relocated, but they
are not shown here in order to simplify the discussions.

4.

Inter 3GPP Handover between pre-SAE/LTE and SAE/LTE accesses in LTE_ACTIVE mode
Note: Procedures have not been proposed for alternatives B and C. Several procedures have been proposed for
alternative A.

5.

Paging and Service Request

6.

Establishment of Dedicated Bearers

Note: Only the main preferred signalling chart is shown for each alternative, although further procedures may
also be supported.

7.

Inter MME and/or inter UPE change, including support for service continuity
Note: This procedure addresses an architecture requirement.

8.

Authentication/ Re-Authentication

Lawful interception procedures may also be different for the different alternatives, due to the need to coordinate
between the MME and the UPE in alternatives B and C. The details are FFS and are in the scope of the SA3 LI.

3GPP

Release 8

213

3GPP TR 23.882 V8.0.0 (2008-09)

Note: The flows in this annex are mainly to show the differences between alternatives and can be optimized further.
Editors note: it is FFS in the following flows if IASA and UPE are collocated or not.
Editors note: Handovers are assumed to be Backward Handovers.
Editors note: Data Forwarding as means to minimize loss of data is indicative only. Other approaches may be used
following agreed assumption in the future.

H.1

Alternative B and C architecture scenarios and

functional allocation

The functional allocation and reference point impact is shown below for the roaming and non-roaming scenarios,
focusing on the MME/UPE split according to alternative B and alternative C.

H.1.1 MME and UPE functional allocation

Table H.1: Allocation of Evolved Packet Core functions to MME and UPE
Alternative B
Grouping:

MME

UPE

Alternative C
MME

UPE

EPC Function:
IP access service enabling functions
Packet routing and forwarding
Gateway functionality to external PDNs
PCEF
Collection of Charging Information
Inter-eNodeB Anchor for user plane
Anchor for inter-3GPP AS mobility
Anchor for 3GPP and non-3GPP mobility
IDLE UE DL data termination
Paging initiation (send page message to eNode Bs)
IP Header compression
Ciphering termination for user plane traffic
SAE Bearer Management
Lawful interception of user plane traffic
Ciphering/integrity termination for signaling
Lawful interception of signaling traffic
CP function for inter-3GPP AS mobility
UE CP context management/storage
UE UP context management/storage
Temporary user ID management/storage
Mobility management
Authentication, authorization, etc.

X
X

X
X

X
X

X
X
X

X
X
X
X
X

X
X
X
X
X

X
X
X

X
X
X
X

NOTE 1: X indicates allocation, and does not mean that the function is always used in the entity.

H.1.2 Reference point impact from MME/UPE split

One new interface, S11, have been identified due to the MME/UPE split. S10 between MMEs is also identified, but is
regarded as needed regardless of MME/UPE split.
S11: A new interface as a consequence of the MME-UPE split. Any MME-UPE split would require this interface.

3GPP

Release 8

H.2

214

3GPP TR 23.882 V8.0.0 (2008-09)

Attach including default bearer handling

S6

S1

UE

X?

eNB

HSS

MME/UPE

IASA
S5/S8

1. Attach Request (APN)

2. Authentication
3. Update Location
4. Insert Subscriber Data

FFS whether radio bearer

setup during attach or when
needed for data transfer

5. Insert Subscriber Data Ack

6. Update Location Ack
7. Route Update/Bearer Request
9. Route Update response/Bearer Response

11. RRC (radio resource

info, QoS info)

10. Radio Bearer Request (QoS, RRC keys)

12. Attach Accept (IP configuration)

13. Attach Complete

Figure H.2.1: Alternative A

3GPP

8. PCRF Interaction

Release 8

215

UE

S6

MME

S1a
X?

3GPP TR 23.882 V8.0.0 (2008-09)

HSS

S10

eNB
S1b

UPE

S5/S8

IASA

1. Attach Request (APN)

2. Authentication
3. Update Location
4. Insert Subscriber Data

FFS whether radio bearer

setup during attach or when
needed for data transfer

5. Insert Subscriber Data Ack

6. Update Location Ack
7. Create Bearer Request (APN, UP Keys)
8. Route Update/Bearer Request
9. PCRF Interaction
10. Bearer Response(IP configuration) 10. Route Update response/Bearer Response

12. RRC (radio resource

info, QoS info)

11. Radio Bearer Request (QoS, RRC keys)

13. Radio Bearer Response

15. Attach Accept (IP configuration)

14. Bearer Ack

16. Attach Complete

NOTE:

Step 1 Attach request can involve indication of old temporary ID with context request and response from
old MME. Subscriber data transactions with HSS can be combined with location update messages in steps
3 and 6. The default bearer can be set up in IASA directly by the MME in steps 8 and 10 with update of
UPE tunnel endpoint also provided by the MME. The NAS ciphering algorithm can be negotiated during
Authentication procedure, the UP ciphering algorithm can be negotiated during bearer establishment
procedure. The details of the UP ciphering algorithm negotiation are FFS.

Figure H.2.2: Alternative B

3GPP

Release 8

216

UE

S6

MME

S1a
X?

3GPP TR 23.882 V8.0.0 (2008-09)

HSS

S10

eNB
S1b

S5/S8

UPE

IASA

1. Attach Request (APN)

2. Authentication
3. Update Location
4. Insert Subscriber Data
5. Insert Subscriber Data Ack

FFS whether radio bearer

setup during attach or when
needed for data transfer

6. Update Location Ack

7. Attach Request (APN, UPE + RRC keys)
8. Bearer Request

12. RRC (radio resource

info, QoS info)

11. Radio Bearer Request (QoS, RRC keys)

10. Bearer Response

9. PCRF Interaction

13. Radio Bearer Confirm

14. Attach Accept (IP configuration)

15. Attach Accept (IP configuration)

16. Attach Complete

NOTE:

The NAS ciphering algorithm can be negotiated during Authentication procedure, the UP ciphering
algorithm can be negotiated during bearer establishment procedure. The details of the UP ciphering
algorithm negotiation are FFS.

Figure H.2.3: Alternative C

H.3

TA Update without MME or UPE change

TBD
Figure H.3.1: Alternative A
eNB

UPE
S10

UE

S1b

X?

MME

1. TAU Request
2. TAU Accept
3. TAU Complete (if TMSI changed)

Only NAS level encryption and/or

integrity protection between UE and
MME; no need to signal RRC keys
and no delay from such signaling

Figure H.3.2: Alternative B

3GPP

S6

HSS

Release 8

217

3GPP TR 23.882 V8.0.0 (2008-09)

eNB

UPE
S10

UE

S1b

X?

S6

MME

HSS

1. TAU Request
2. Authentication
3. Update UPE Request
4. Update UPE Response
5. TAU Accept
6. TAU Complete (if TMSI changed)

When is UPE updated ?

a) when key changes
b) when RA changes (for CDRs)
c) with every RAU (= keep alive
between MME and UPE)

Only NAS level encryption and/or

integrity protection between UE and
MME; no need to signal RRC keys
and no delay from such signaling

Figure H.3.3: Alternative C

H.4

Inter eNB Handover in LTE_ACTIVE mode (intra

MME and intra UPE)
eNB 1
X2

UE

X?

S1

eNB 2
1. IP bearer service
2. Handover Initiation
3. Handover Required (contexts including RRC keys)
4. LTE Bearer Establishment
5. Handover Command
6. Data Forwarding

7. Radio Bearer Establishment

8. User Plane Route Update Request

10. Handover Complete

9. User Plane Route Update Response

11. Handover Complete Acknowledge

12. IP bearer service
13. TAU in case RA changed

Figure H.4.1: Alternative A

3GPP

MME/UPE
UPE

Release 8

218

3GPP TR 23.882 V8.0.0 (2008-09)

eNB 1
S1b

X2

UE

X?

eNB 2

MME

UPE

1. IP bearer service
2. Handover Initiation
3. Handover Required (UE RAN context including RRC keys)
4. LTE Bearer Establishment
5. Handover Command (C-RNTI)
6. Data Forwarding
7. Handover Confirm
10. Handover Complete

8. Relocation Indicatio n

11. Handover Complete Acknowledge

9. Relocatio n Ack

8. User Plane Route Update Request

9. User Plane Route Update Response

12. IP bearer service

13. TAU in case RA changed

NOTE:

User plane route update in steps 8 and 9 can be done by updating the user plane route directly between
the eNB2 and UPE instead of via the MME, with notifications sent to the MME and acknowledgement sent
to eNB2 by the MME.

Figure H.4.2: Alternative B

eNB 1

MME
X2

UE

X?

S1b

eNB 2
1. IP bearer service
2. Handover Initiation
3. Handover Required (contexts including RRC keys)
4. LTE Bearer Establishment
5. Handover Command
6. Data Forwarding

7. Radio Bearer Establishment

8. User Plane Route Update Request

10. Handover Complete

9. User Plane Route Update Response

11. Handover Complete Acknowledge

12. IP bearer service
13. TAU in case RA changed

Figure H.4.3: Alternative C

3GPP

UPE

Release 8

H.5
+

219

Inter 3GPP Handover between pre-SAE/LTE and

SAE/LTE accesses in LTE_ACTIVE mode
UTRAN

Uu

UE

3GPP TR 23.882 V8.0.0 (2008-09)

SGSN

Iu

X?

S3
S1

eNB

S4

MME/UPE

S6
S5

IASA

1. IP bearer service
2. Handover Initiation
3. Relocation Required
4. Forward Relocation Request
4. Prepare HO Request
5. New E-NB
reserves resources
6. Prepare HO Response

9. RRC MSG

7. Forward Relocation Response

8. Relocation Command
10. Data Forwarding (minimize loss)

Encrypt

11. Forward SRNS context

12. Forward SRNS context

13. Forward SRNS context ACK
14. New E-NB
Detects UE
15. Radio Bearer Establishment

19. Iu release command

17. Forward Relocation Complete

context
18. Forward Relocation Complete ACK

20. Iu release complete

TA Update procedure

Figure H.5.1: Alternative A

3GPP

21. User Plane Route Update

HSS

Release 8

UE

220

Source BSS

Target eNB

3GPP TR 23.882 V8.0.0 (2008-09)

MME

SGSN

UPE/SAE
GW

1. Handover
Initiation
2. PS Handover Required
3. Forward Relocation Request
4. Handover Preparation Request
5. Handover Preparation Confirm
6. Update Context Request
6. Update Context Response
7. Forward Relocation Response
8. Relay PDUs to target eNB
8. Relay PDUs to target eNB
9. PS Handover Required Acknowledge
10. PS Handover Command

11. UE Detection
12. Handover Complete
13. Forward Relocation Complete
13. Forward Relocation Complete Acknowledge
14. Update Bearer Context Request
14. Update Bearer Context Response
15. Resource Release procedure

16. Tracking Area Update procedure

Figure H.5.2: Information flow for handover from 2G to SAE/LTE

3GPP

HSS

Release 8

UE

221

Source RNC

Target eNB

3GPP TR 23.882 V8.0.0 (2008-09)

MME

SGSN

UPE/SAE
GW

1. Handover
Initiation
2. Relocation Required
3. Forward Relocation Request
4. Handover Preparation Request
5. Handover Preparation Confirm
6. Update Context Request
6. Update Context Response
7. Forward Relocation Response
8. Relocation Command
9. Relay PDUs to target eNB
9. Relay PDUs to target eNB
10. Handover from UTRAN Command

11. UE Detection
12. Handover Complete
13. Forward Relocation Complete
13. Forward Relocation Complete Acknowledge
14. Update Bearer Context Request
14. Update Bearer Context Response
15. Resource Release procedure

16. Tracking Area Update procedure

Figure H.5.3: Information flow for handover from 3G to SAE/LTE

3GPP

HSS

Release 8

UE

222

Source eNB

Target BSS

3GPP TR 23.882 V8.0.0 (2008-09)

SGSN

MME

UPE/SAE
GW

1. Handover
Initiation
2. Handover Required
3. Forward Relocation Request
4. PS Handover Request
5. PS Handover Request Acknowledge
6. Forward Relocation Response
7. Update Context Request
7. Update Context Response
8. PDUs to source eNB
8. Relay PDUs to Target BSS
9. Handover Required Acknowledge
10. Handover Command

11. UE Detection
12. PS Handover Complete
13. Forward Relocation Complete
13. Forward Relocation Complete Acknowledge
14. Update PDP Context Request
14. Update PDP Context Response
15. S1 Release procedure

16. Routeing Area Update procedure

Figure H.5.4: Information flow for handover from SAE/LTE to 2G

3GPP

HSS

Release 8

UE

223

Source eNB

Target RNC

3GPP TR 23.882 V8.0.0 (2008-09)

SGSN

MME

UPE/SAE
GW

HSS

1. Handover
Initiation
2. Handover Required
3. Forward Relocation Request
4. Relocation Request
5. Relocation Request Acknowledge
6. Forward Relocation Response
7. Update Context Request
7. Update Context Response
8. PDUs to source eNB
8. Relay PDUs to target RNC
9. Handover Required Acknowledge
10. Handover Command

11. UE Detection
12. Handover Complete
13. Forward Relocation Complete
13. Forward Relocation Complete Acknowledge
14. Update PDP Context Request
14. Update PDP Context Response
15. S1 Release procedure

16. Routeing Area Update procedure

Figure H.5.5: Information flow for handover from SAE/LTE to 3G

NOTE:

Data forwarding mechanism is involved in the above 4 diagrams for lossless handover. However, it's FFS
that Lossless handover use bi-casting or data forwarding.
Alternative B
TBD
Figure H.5.6: Alternative C

3GPP

Release 8

H.6

224

3GPP TR 23.882 V8.0.0 (2008-09)

Paging and Service Request

Xu

UE

S1

eNB

MME/UPE

1. Downlink Data

2. Paging Request

3. Paging
4. Paging Response

5. Radio Bearer Request ([list of] QoS, RRC keys)

6. RRC Establishment

7. Radio Bearer Confirm

8. Data
A. Service Request
B. Radio Bearer Request ([list of] QoS, RRC keys)

C. RRC Establishment

D. Radio Bearer Confirm

E. Uplink Data

Figure H.6.1: Alternative A

UE

eNB

MME

SAE GW/
UPE

HSS

1.RRC Connection Establishment

2.Service Request
3.Authentication
4.Security Mode Command
4.RRC Security Mode Command
4.RRC Security Mode Complete
4.Security Mode Complete
5.UE Context Setup Request
6.RB Setup Procedure
7.UE Context Setup Complete
8.Update Bearer Context Indication
8.Update Bearer Context Ack

9.Uplink Data

Figure H.6.2-1: Alternative B, service request

3GPP

S5

Release 8

225

3GPP TR 23.882 V8.0.0 (2008-09)

Figure H.6.2-2: Alternative B, paging

MME
S1a

UE

Xu

eNB

S10

S1b

UPE
2. Paging Request

3. Paging

S5
1. Downlink Data

4. Paging Response

6. RRC Establishment

5. Radio Bearer Request ([list of] QoS, RRC keys)

7. Radio Bearer Confirm
8. Data Forwarding
A. Service Request

C. RRC Establishment

B. Radio Bearer Request ([list of] QoS, RRC keys)

D. Radio Bearer Confirm
E. Uplink Data

Figure H.6.3: Alternative C

H.7

PCRF triggered establishment of Dedicated Bearers

Editors note: The flows may be changed once the implied aspects on QoS signaling are agreed within the scope of
the discussion on how QoS and bearers are set up.

3GPP

Release 8

226

3GPP TR 23.882 V8.0.0 (2008-09)

UE

AF
Rx
X?

eNB

S1

MME/UPE

S5

IASA

Gx

PCRF

2. Request Resources (Policy/QoS Info)

3. Admission Control, QoS Control
4. Radio Resource Assignment (QoS Info)

5. Report Resources
(QoS Info)

6. Admission Control for radio

resources, UE/network capabilities,
Configure Scheduler etc.
7. RRC (linking info, radio
resource info, QoS info)
8. Assignment Ack

9. Report Resources
(QoS Info)

Figure H.7.1: Alternative A

1. SDP session parameters

UE

AF

11. SDP answer

eNB

MME

Rx

UPE

IASA

Gx

PCRF

2. Request Resources(Policy, QoS info)

3. SAE bearer setup
5. SAE Access
Bearer Req

6. SAE Radio Bearer

Setup

4. SAE bearer setup ACK

7. SAE Access
Bearer Resp (eNB
tunnel EP)
8. Bearer setup conf
9. Request resource Ack
10. Push PCC rules
Policy and charging rules
enforcement

NOTE:

The resource request from PCRF in step 2 can be replaced by a push authorization message to the IASA
followed by SAE bearer setup requested from MME by the UPE, with similar acknowledgements via the
IASA in step 9, but these do not affect these differences do not affect the discussion on MME and UPE.

Figure H.7.2.1: Alternative B, using PCRF-MME interface

3GPP

Release 8

227

3GPP TR 23.882 V8.0.0 (2008-09)

Figure H.7.2.2: Alternative B, without PCRF-MME interface

MM ctxt

MME
1. Service negotiation

UE
X?

eNB

SM ctxt

S1u

UPE

SM ctxt

S5/S8

IASA

AF
Rx
Gx

PCRF

2. Request Resources (Policy/QoS Info)

3. Admission Control, QoS Control
4. Request Resources (Policy/QoS Info)
5. Admission Control, QoS Control
6. Radio Resource Assignment (QoS Info)
7. Admission Control for radio
resources, UE/network capabilities,
Configure Scheduler etc.
8. RRC (linking info, radio
resource info, QoS info)

9. Assignment Ack

10. Report Resources

(QoS Info)

Figure H.7.3: Alternative C

3GPP

11. Report Resources

(QoS Info)

Release 8

H.8

228

3GPP TR 23.882 V8.0.0 (2008-09)

Inter MME and/or inter UPE change, including

support for service continuity
TBD
Figure H.8.1: Alternative A

Flows are described here when MME and UPE are separated:
eNB 1
S1a

UE

S1b

UPE1

MME1

S5/S8

Sxb
Sxb

S1b

eNB 2

S1a

UPE 2

IASA

MME2

1. IP bearer service

2. Handover Initiation
UE in ACTIVE mode

3. Handover Required (UE eNB

context, eNB2 id)

4. Handover Required (eNB2 id, UE

MM/SM Context)
4.1. Handover Required (eNB2 addr, UE SM cxt)

5. Handover Request with eNB2 (UE eNB context)

Bearer path established between eNB2 and UPE2
6. Handover Response

7. Means to minimize
loss of data
8. Handover Command
9. Radio Bearer Establishment, UE detected by eNB2
10. Handover Complete Detect

11.Route Update/Bearer
Request

12. Handover Complete (Resource release)

13. Handover Complete (resource release)
14. IP bearer service via UPE2

Figure H.8.2: intra-LTE MME/UPE Relocation in Active mode when MME and UPE are separated
Editor's note: transfer of PCC information is FFS
1) The IP bearer service is established between the UE and the IASA via the UPE1
2) The eNB1 decides to initiates a handover to eNB2

3GPP

Release 8

229

3GPP TR 23.882 V8.0.0 (2008-09)

3) The eNB1 sends a Handover Required to the MME1.

4) The MME1 selects a MME2 serving the eNB2 the UE is going to use and sends it a Handover Preparation
Request, including the UE context information.
5) The MME2 creates a UE context and sends Handover Preparation Request to UPE2. MME1 sends a Handover
Preparation Request to the eNB2. The eNB2 sends a Handover Preparation Confirm to the MME2. The bearer
plane is established between eNB2 and UPE2.
6) The MME2 sends a Handover Preparation Confirm to the MME1. MME1 informs UPE1 of the relocation to
UPE2.
7) Means to minimize lost of data i.e. UPE1 starts bi-casting to eNB1 and UPE2 or data forwarding to UPE2.
8) The MME1 sends a Handover Command to the UE.
9) The UE is detected at the eNB2.
10)eNB2 sends a Handover Complete to the MME2. MME2 informs UPE2.
11) The UPE2 does a route update with the IASA.
12)UPE2 informs MME2 of the Handover Complete and the possibility to release resources in previous access.
MME2 informs MME1 which triggers UPE1 to sends all downlink packets only to the UPE2.
13)The resource in the source system is released.
14)The IP Bearer service is now established between the UE and the IASA via UPE2.
TBD
Figure H.8.3: Alternative C

H.9

Authentication/Re-Authentication

If MME/UPE split, it is the MMEs role to negotiate and synchronize the keys for AS, NAS and UP with UE by
authentication procedure. And, the MME shall deliver the keys for UP security to the related UPE during the IP bearer
establishment or after the MME and the UE renew the keys for UP security by another authentication procedure. In
short, after the MME challenges the UE by performing an authentication, the MME shall deliver the renewed key for
UP security to the related UPEs.

H.10

Comparison of Alternatives

The table identifies the main differences between the two MME separation approaches and compares them with
combined MME/UPE. Also a comparison with the SGSN is included as the MME is sometimes compared with the
control part of an SGSN.

3GPP

Release 8

230

3GPP

3GPP TR 23.882 V8.0.0 (2008-09)

Release 8

231
SGSN

Dynamic
characteristics
Idle state RAU

MME/UPE

3GPP TR 23.882 V8.0.0 (2008-09)

MME/UPE Split B)

any RAU

any RAU

any
RNC/BSC
change
Depends on
SGSN split

any NB change

Dedicated (QoS)
Bearer Setup
latency

Depends on
SGSN split

1) Request from IASA

2) RAB Setup

paging

1) downlink
packet
2) Paging
request to
RAN
none

1) downlink packet
2) Paging request to
NBs

Inter NB
handover without
MME and UPE
change

n.a.

Handover
signalling 2G/3G
to LTE

via Gn

1) NB change
2) NB update to
MME/UPE
3) MME/UPE response
to NB
via S3
1) RNC request to
SGSN
2) SGSN request to
MME/UPE
3) MME/UPE request
RAN resources and
bearer NB-UPE
4) MME responds to
SGSN
5) SGSN sends
handover command

Handover
signalling for
MME and UPE
change

n.a.

1) NB request to
MME/UPE
2) MME/UPE request to
new MME
3) new MME requests
NB resources and
bearer NB-UPE
4) new MME/UPE
responds to old
MME7upe
5) old MME sends
handover command

1) NB request to MME
2) MME request to new
MME
3) new MME requests NB
resources
4) New MME request UPE
resources
5) new MME initiates
bearer NB-UPE
6) new MME responds to
old MME
7) old MME sends
handover command

Inter MME
Handover without
UPE change

n.a.

via S10

1) NB request to MME
2) MME request to new
MME (new MME accepts
old UPE)
3) new MME responds to
old MME

Active state NB
change
Idle to active
latency

MME UPE
signalling
procedures

any RAU to MME

nothing to UPE
any NB change to MME
any NB change to UPE

1) Service Request
2) RAB Setup

none

3GPP

1) Service Request
2) RAB Setup
3) Indication to UPE
1) Request from IASA
2) Request to MME
3) RAB Setup
4) Indication to UPE
1) downlink packet
2) Request to MME
3) Paging request to NBs

MME/UPE Split C)
any RAU to MME
any RAU to UPE
Only RAU to MME, no
other NB changes to MME
any NB change to UPE
1) Service Request
2) Request to UPE
3) RAB Setup
1) Request from IASA
2) RAB Setup
1) downlink packet
2) Request to MME
3) Paging request to NBs

-Initial attach
-state transition
-paging
-load balancing
-keep alive
-inter UPE handover
-handover 2G/3G
-dedicated bearer setup
-NB change
There is the need to
update the UPE and to
update the MME. The
procedure is FFS.

-Initial attach
-state transition
-paging
-load balancing
-keep alive
-RAU
-inter UPE handover
-handover 2G/3G

via S3 at MME
1) RNC request to SGSN
2) SGSN request to MME
3) MME requests NB
resources
4) MME requests UPE
resources
5) MME initiates bearer
NB-UPE
6) MME responds to SGSN
7) SGSN sends handover
command

via S3 at MME
1) RNC request to SGSN
2) SGSN request to MME
3) MME requests UPE to
establish NB resources
and bearer NB-UPE
4) UPE request NB
resources and bearer NBUPE
5) MME responds to
SGSN
6) SGSN sends handover
command RAN resources
1) NB request to UPE
2) UPE request to old
MME
3) old MME request to new
MME
4) New MME request new
UPE resources
5) new UPE request NB
resources and bearer NBUPE
6) new MME responds to
old MME
7) old MME responds to
UPE
8) old UPE sends
handover command
1) NB update request to
UPE
2) UPE update response
to new NB
3) UE sends TA Request
4) new MME confirms new

1) NB change
2) NB update to UPE
3) UPE response to NB

Release 8

Static
characteristics
UE context

232

3GPP TR 23.882 V8.0.0 (2008-09)

4) old MME sends
handover command
5) UE sends TA Request
(FFS)
6) new MME confirms new
TA (FFS)

TA

Most in MME, some in

UPE
In UPE
Within MME pool(s)
Within UPE pool(s)

yes

yes

yes
Within
SGSN
pool(s)
New UE
attach
New UE
attach

yes
Within MME/UPE
pool(s)

Most in MME, some in

UPE
in MME and in UPE
Within MME pool(s)
Within UPE pool(s)

New UE attach

New UE attach

New UE attach

New UE attach
[recovery for UE
triggered by downlink
packets]

E.g. new UE attach

recovery for UE triggered
by downlink packet FFS

New UE attach
[recovery for UE triggered
by downlink packets]

Other functions
CDR generation

yes

yes

UPE
(not in UPE but in IASA
when collocated with UPE)

Legal Intercept

yes

yes

MME and UPE

(not in UPE but in IASA
when collocated with UPE)
Generation by MME if
needed.
MME and UPE
(not in UPE but in IASA
when collocated with UPE)

S1 MME

Iu
connection

S1 UPE

GTP-U

Common connection
with NB for NAS and
UP control
e.g. GTP-U

Bearer context
Load balancing
MME recovery
UPE recovery

3GPP

Common connection with

NB for NAS and UP control

UPE
(not in UPE but in IASA
when collocated with UPE)
FFS whether the UPE
receives all events for LI or
whether additional MMEUPE communication
needed.
Common connection with
NB for NAS

e.g. GTP-U, GTP-C (FFS)

e.g. GTP-C and GTP-U

Release 8

233

3GPP TR 23.882 V8.0.0 (2008-09)

Annex I:
Open issues for the SAE architecture (Informative)
The followings capture the differences of major alternatives for the SAE architecture, which are in line with the
working assumptions agreed. Note that roaming in this annex refers only roaming between SAE networks.
-

Separate the functionalities of 3GPP anchor and SAE anchor.

-

Alternative X
-

3GPP anchor: Function that anchors the user plane for mobility between 3GPP access systems, and
includes GTP interface to SGSN in the GPRS Core. It handles pre-LTE access bearers, by terminating
the bearers or by associating them with the user data traffic.
(Note that the LTE access bearer termination and/or association with the user data traffic is a UPE
function, which is collocated with 3GPP anchor.)

SAE MM anchor: Function that anchors the user plane for mobility between 3GPP access systems and
non-3GPP access systems. It also handles the mobility for UPE/3GPP anchor relocation.

SAE PDN gateway: Function for IP connectivity with PDNs/Service Domains (IP address allocation for
user data traffic, PCEF and LI for user plane traffic, interfacing with the PCC and charging systems).

Alternative Y
-

3GPP anchor: Function that anchors the user plane for mobility between 3GPP access systems, and
includes GTP interface to SGSN in the GPRS Core.

SAE MM anchor: Function that anchors the user plane for mobility between 3GPP access systems and
non-3GPP access systems

SAE PDN gateway: Function for IP connectivity with PDNs/Service Domains (IP address allocation for
user data traffic, PCEF and LI for user plane traffic, interfacing with the PCC and charging systems). It
also handles 3GPP access bearers, by terminating the bearers or by associating them with the user data
traffic.

3GPP anchor location

-

Alternative A
-

collocated with UPE:

SAE PDN gateway/SAE MM anchor can be collocated also by implementation.

Alternative B
-

For roaming case with home routed traffic: 3GPP anchor and UPE are collocated in VPLMN, SAE PDN
gateway is (SAE MM anchor if needed) in HPLMN.

For non-roaming case all in one.

Alternative C
-

3GPP Anchor and UPE are collocated (when a 3GPP Anchor is needed); also collocated with SAE PDN
Gateway/SAE MM Anchor in non-roaming case

SAE MM anchor location for the roaming case with home routed traffic
-

Alternative 1
-

There is an SAE MM anchor in VPLMN

Alternative 2

3GPP

Release 8

234

An SAE MM anchor is only in HPLMN

3GPP

3GPP TR 23.882 V8.0.0 (2008-09)

HSS

Release 8

235

3GPP TR 23.882 V8.0.0 (2008-09)

Annex J:
Change history
Change history
Date
2006-03

TSG #
SP-31

TSG Doc.
CR
SP-060152 -

2008-08

SP-41

SP-080549 -

2008-09

SP-41

Rev Cat
Subject/Comment
Editorial update by MCC for presentation to TSG SA for
Information
MCC Update to version 2.0.0 for approval. This TR will not
be maintained.
MCC Update of approved TR for publication

3GPP

Old
New
0.11.0 1.0.0
1.16.0 2.0.0
2.0.0

8.0.0