SEA D6.1.1 NOM FF 20090630 Final

Information and Communication Technologies (ICT) Programme
Project No: FP7-ICT- 214063
SEA
Deliverable D6.1.1
Provisioning of RAT Testbed Components

Author(s): Imad Al Bekai (Nomor)
Status -Version: Final
Date: 30 June 2009
Distribution - Confidentiality: Public
Code: SEA_D6.1.1_NOM_20090630.doc
Abstract:
This deliverable gives a full description of the SEA testbed developed by Nomor. The document
specifies the architecture of the network as implemented in the testbed, the different nodes involved,
and the protocols and corresponding messages that are implemented and exchanged across the
different interfaces.
In addition, it also provides a detailed explanation on how to setup, start and operate the network
elements. It also explains the procedures that can be performed including initial attach, handover, or
detach.
Copyright by the SEA Consortium
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
Disclaimer
This document contains material, which is the copyright of certain SEA contractors, and may not be
reproduced or copied without permission. All SEA consortium partners have agreed to the full
publication of this document. The commercial use of any information contained in this document
may require a license from the proprietor of that information.
The SEA Consortium consists of the following companies:
No
Participant name
Participant
short name
Country
Country
ST Microelectronics
STM
Co-ordinator
Italy
Synelixis Solutions
Synelixis
Contractor
Greece
Thomson Grass Valley
Thomson
Contractor
France
Philips Consumer Electronics
Philips
Contractor
Netherlands
Vodafone Panafon AEET
Vodafone
Contractor
Greece
Nomor Research
Nomor
Contractor
Germany
Fraunhofer HHI
HHI
Contractor
Germany
Politecnico di Torino
Polito
Contractor
Italy
Universidad Politcnica de Madrid
UPM
Contractor
Spain
10
University of California, Los Angeles UCLA
Contractor
USA
The information in this document is provided as is and no guarantee or warranty is given that the
information is fit for any particular purpose. The user thereof uses the information at its sole risk and
liability.
SEA_D6.1.1_NOM_FF_20090630.doc
Page 2 of 102
This page has intentionally left bank
Page 3 of 102
Table of contents
1. Introduction .................................................................................................................................... 9
2. GPRS Tunneling Protocol - GTP................................................................................................ 13
2.1. General format of GTPv2-C header.......................................................................................... 13
2.2. GTP-U header........................................................................................................................... 14
2.3. GTP-C Messages....................................................................................................................... 15
2.3.1. Create Session Request.................................................................................................. 15
2.3.2. Create Session Response ............................................................................................... 17
2.3.3. Delete Session Request.................................................................................................. 18
2.3.4. Delete Session Response ............................................................................................... 19
2.3.5. Delete Bearer Request ................................................................................................... 20
2.3.6. Delete Bearer Response ................................................................................................. 21
2.3.7. Modify Bearer Request.................................................................................................. 21
2.3.8. Modify Bearer Response ............................................................................................... 23
2.3.9. Forward Relocation Request.......................................................................................... 24
2.3.10.
Forward Relocation Response.................................................................................... 26
2.3.11.
Forward Relocation Complete Notification ............................................................... 28
2.3.12.
Forward Relocation Complete Acknowledge ............................................................ 28
2.4. GTP-U Messages ...................................................................................................................... 29
3. Non Access Stratum Protocol - NAS........................................................................................... 30
3.1. EMM States ............................................................................................................................... 30
3.1.1. EMM States in the UE................................................................................................... 30
3.1.2. EMM states in the MME ............................................................................................... 31
3.2. EMM specific procedures.......................................................................................................... 32
3.2.1. Attach procedure............................................................................................................ 32
3.2.2. Detach procedure ........................................................................................................... 33
3.3. ESM states................................................................................................................................. 34
3.3.1. ESM states in the UE..................................................................................................... 34
3.3.2. ESM states in the MME................................................................................................. 35
3.4. Network initiated ESM procedures ........................................................................................... 36
3.4.1. Default EPS bearer context activation procedure .......................................................... 36
3.4.2. EPS bearer context deactivation procedure ................................................................... 37
3.5. UE requested ESM procedures ................................................................................................. 38
3.5.1. UE requested PDN connectivity procedure ................................................................... 38
3.6. NAS Messages - EMM............................................................................................................... 39
3.6.1. Attach Request............................................................................................................... 39
3.6.2. Attach Accept ................................................................................................................ 39
3.6.3. Attach Complete ............................................................................................................ 40
3.6.4. Attach Reject ................................................................................................................. 40
3.6.5. Detach Request .............................................................................................................. 40
3.6.6. Detach Accept................................................................................................................ 41
3.7. NAS Messages - ESM ................................................................................................................ 42
3.7.1. Activate default EPS bearer context request.................................................................. 42
3.7.2. Activate default EPS bearer context accept ................................................................... 42
3.7.3. Activate default EPS bearer context reject .................................................................... 42
3.7.4. Deactivate EPS bearer context request .......................................................................... 43
3.7.5. Deactivate EPS bearer context accept ........................................................................... 43
3.7.6. PDN connectivity request .............................................................................................. 43
3.7.7. PDN connectivity reject................................................................................................. 44
3.8. NAS Timers ............................................................................................................................... 44
Page 4 of 102
3.8.1.
3.8.2.
Timers of EPS mobility management ............................................................................ 44

Timers of EPS session management .............................................................................. 45
4. S1 Application Protocol - S1AP .................................................................................................. 46

4.1. S1AP Procedures ...................................................................................................................... 46
4.1.1. Bearer Management Procedures .................................................................................... 46
4.1.2. NAS Transport............................................................................................................... 47
4.1.3. Handover Signalling Procedures ................................................................................... 48
4.2. SAE Bearer Management Messages ......................................................................................... 49
4.2.1. SAE Bearer Setup Request ............................................................................................ 49
4.2.2. SAE Bearer Setup Response.......................................................................................... 50
4.2.3. SAE Bearer Release Command ..................................................................................... 50
4.2.4. SAE Bearer Release Response ...................................................................................... 50
4.3. NAS transport Messages ........................................................................................................... 51
4.3.1. Downlink NAS Transport.............................................................................................. 51
4.3.2. Uplink NAS Transport................................................................................................... 51
4.4. Handover Signalling Messages................................................................................................. 51
4.4.1. Handover Required........................................................................................................ 51
4.4.2. Handover Command ...................................................................................................... 51
4.4.3. Handover Request.......................................................................................................... 52
4.4.4. Handover Request Acknowledge .................................................................................. 52
4.4.5. Handover Notify ............................................................................................................ 52
5. Radio Access Network Application Protocol RANAP ........................................................... 53
5.1. RANAP Procedures and Messages ........................................................................................... 53
5.1.1. RAB Assignment ........................................................................................................... 53
5.1.2. Direct Transfer............................................................................................................... 53
5.1.3. Relocation Preparation................................................................................................... 54
5.1.4. Relocation Resource Allocation .................................................................................... 54
5.1.5. Relocation Complete ..................................................................................................... 55
6. Proxy Mobile IP - PMIP .............................................................................................................. 56
6.1. Introduction............................................................................................................................... 56
6.2. PMIPv6 Specifications .............................................................................................................. 56
6.3. PMIPv6 Use Case and Protocol Stacks .................................................................................... 58
6.4. Message Signalling ................................................................................................................... 59
6.4.1. Attach Procedure ........................................................................................................... 59
6.4.2. Detach Procedure........................................................................................................... 59
6.4.3. Resource Allocation Deactivation Procedure ................................................................ 59
6.5. PMIPv6 Messages Format ........................................................................................................ 60
6.5.1. Mobility Header............................................................................................................. 60
6.5.2. Proxy Binding Update (PBU) message ......................................................................... 60
6.5.3. Proxy Binding Acknowledgment (PBA) message......................................................... 61
6.5.4. Binding Revocation Indication (BRI) Message............................................................. 62
6.5.5. Binding Revocation Acknowledgment Message ........................................................... 63
7. Network Architecture and Functionality ................................................................................... 64
7.1. MME.......................................................................................................................................... 64
7.2. SGW .......................................................................................................................................... 64
7.3. PGW .......................................................................................................................................... 64
7.4. IP Address Allocation ............................................................................................................... 65
7.4.1. General........................................................................................................................... 65
7.4.2. IP Allocation.................................................................................................................. 65
7.4.3. Implementation .............................................................................................................. 65
7.5. Procedures ................................................................................................................................ 65
7.5.1. WiMAX Initial Attach................................................................................................... 65
7.5.2. LTE Initial Attach.......................................................................................................... 65
Page 5 of 102
7.5.3. HSPA Initial Attach....................................................................................................... 67
7.5.4. WiMAX Detach............................................................................................................. 68
7.5.5. LTE Detach (UE Initiated) ............................................................................................ 68
7.5.6. HSPA Detach................................................................................................................. 68
7.5.7. Handovers...................................................................................................................... 68
7.6. Data Storage ............................................................................................................................. 80
7.6.1. Serving GW ................................................................................................................... 80
7.6.2. PDN GW........................................................................................................................ 82
7.6.3. MME.............................................................................................................................. 83
7.6.4. SGSN ............................................................................................................................. 85
7.6.5. eNB and RNC ................................................................................................................ 85
7.6.6. UE.................................................................................................................................. 85
8. Testbed Installation and Configuration ..................................................................................... 86
8.1. Hardware Requirements ........................................................................................................... 86
8.2. Software Requirements.............................................................................................................. 87
8.3. Network Configuration.............................................................................................................. 87
8.4. Installation ................................................................................................................................ 88
8.4.1. RealNeS LTE................................................................................................................. 88
8.4.2. RealNeS HSPA.............................................................................................................. 88
8.4.3. RealNeS WiMAX.......................................................................................................... 88
8.4.4. MME, Serving Gateway and PDN Gateway ................................................................. 88
8.4.5. External Terminal .......................................................................................................... 89
8.4.6. Libraries......................................................................................................................... 89
9. Testbed Operation........................................................................................................................ 90
9.1. LTE............................................................................................................................................ 90
9.2. HSPA......................................................................................................................................... 90
9.3. WiMAX ...................................................................................................................................... 90
9.4. MME, S-GW and P-GW ............................................................................................................ 90
9.4.1. MME.............................................................................................................................. 91
9.4.2. Serving Gateway............................................................................................................ 91
9.4.3. PDN Gateway ................................................................................................................ 91
9.5. Common GUI ............................................................................................................................ 92
9.5.1. Connection and Operation ............................................................................................. 94
9.5.2. GUI Functionality.......................................................................................................... 94
9.5.3. GUI UE Movements ...................................................................................................... 96
9.5.4. Live User ....................................................................................................................... 97
9.5.5. Trouble Shoot ................................................................................................................ 97
9.6. External UE............................................................................................................................... 97
9.7. Message Logging ...................................................................................................................... 99
Page 6 of 102
Abbreviations
3GPP
3rd Generation Partnership Project
AMBR
Aggregate Maximum Bit Rate
APN
Access Point Name
EBI
EPS Bearer ID
EMM
EPS Mobility Management
eNB
evolved Node B
EPC
Evolved Packet Core
EPS
Evolved Packet System
ESM
EPS Session Management
GBR
Guaranteed Bit Rate
G-PDU
GTP-U non-signalling PDU
GTP
GPRS Tunnelling Protocol
GTP-PDU
GTP-C PDU or GTP-U PDU
GTPv2-C
GTP version 2, control plane
GTPv2-U
GTP version 2, user plane
HO
Handover
IE
Information Element
IMSI
International Mobile Subscriber Identity
IP
Internet Protocol
IPv6
Internet Protocol version 6
LMA
Local Mobility Anchor
MAG
Mobile Access Gateway
MBR
Maximum Bit Rate
MME
Mobility Management Entity
NAS
Non Access Stratum
PDN
Packet Data Network or Public Data Network
PDU
Protocol Data Unit
PMIPv6
Proxy Mobile IP version 6
P-GW or PGW
PDN Gateway
QoS
Quality of Service
RAT
Radio Access Type
S-GW or SGW
Serving Gateway
TEID
Tunnel Endpoint Identifier
Page 7 of 102
TEID-C
Tunnel Endpoint Identifier, control plane
TEID-U
Tunnel Endpoint Identifier, user plane
UDP
User Datagram Protocol
UE
User Equipment
Page 8 of 102
1. Introduction
This document provides a thorough description of the emulation platform developed by Nomor as
part of the SEA project.
Figure 1 represents the general network architecture. Note that at the current stage, the testbed
includes 3 radio access technologies; LTE, HSPA and WiMAX.
Data Connection
BSS
Signalling Connection
G
b
Um
Iu
S4
RNS
Serving
Gateway
SGSN
U
u
S12
UE
LTEUu
eNodeB
PDN
Gateway
S3
Serving
Gateway
MME
S1-MME
S5/S8a
S5/S8a
S11
S1-U
Trusted Non3GPP IP access

S2a
ePDG
S2b
Figure 1: Network Architecture
Figure 2 and Figure 3 below detail the whole protocol stack of the network for the C-Plane
and the U-Plane respectively.
Page 9 of 102
Figure 2: C-Plane Protocol Stack. GTP based S5/S8a
Page 10 of 102
Figure 3: U-Plane Protocol Stack. GTP based S5/S8a
Page 11 of 102
Chapters 2 to 6 shed light on the different protocols that are in action among the different network
nodes. For each protocol, only those messages that are implemented in the testbed are specified. For
each message, the structure of the message, the interface on which it is sent and the corresponding
procedure are discussed. In general, the contents of each message are listed in a table imported from
the corresponding specification. The message fields that were not used in implementation are greyed.
This gives a good idea on how close is the implementation to reality. Here it is worth mentioning that
implementation of the listed messages is bit-exact and fully compliant with this document.
The major protocols are listed as follows:
GTP protocol which is divided into GTP-C for control plane and GTP-U for user plane
NAS protocol
S1-AP protocol running over SCTP
PMIP protocol
RANAP protocol running over SCCP
Chapter 7 describes the network architecture, while chapter 8 explains the installation and
configuration of the different nodes.
Operating the testbed is discussed in chapter 9.
Page 12 of 102
2. GPRS Tunneling Protocol - GTP

GTPv2 is used in our platform. It has two flavours, a control plane protocol (GTPv2-C) fully
described in [1], and the user plane protocol (GTPv2-U) described in [5].
GTP is basically used between core network nodes, specifically on the following interfaces:
- S58 interface between the P-GW and S-GW (Control & Data).
- S11 interface between S-GW and MME (Control only).
- S1-U interface between S-GW and eNodeB (Data only).
- S4 interface between SGSN and S-GW.
- S12 interface between S-GW and RNC.
- S3 between SGSN and MME.
Figure 1 above shows the corresponding interfaces.
2.1. General format of GTPv2-C header

GTP uses a variable length header. Control Plane GTP header length shall be a multiple of 4 octets.
Figure 4 illustrates the format of the GTPv2-C Header.
Bits
Octets
7
Version
Spare Spare Spare
Message Type
Message Length (1st Octet)
Message Length (2nd Octet)
m to
k(m+3)
If T flag is set to 1, then TEID shall be placed into octets 58. Otherwise, TEID field is not present at all.
n to (n+1)
Sequence Number
(n+2) to
(n+3)
Spare
Figure 4: Format of GTPv2 Header
Where:
- if T = 0, TEID field is not present, k = 0, m = 0 and n = 5;
- if T = 1, TEID field is present, k = 1, m = 5 and n = 9.
Octet 1 bits shall be coded as follows:
- Bits 6-8 represent the Version field.
- Bit 5 represents the Piggybacking flag (P).
- Bit 4 represents the TEID flag (T).
- Bits 3-1 are spare, the sender shall set it to zero and the receiver shall ignore it.
Octet 2-8 of the GTPv2 header shall contain the following fields:
- Message Type field. This field shall indicate the type of GTP message.
- Length field. This field shall indicate the length of the message in octets excluding the
mandatory part of the GTP header (the first 4 octets). The TEID (if present), Sequence Number
and Extension Header(s) shall be included in the length count.
- Tunnel Endpoint Identifier (TEID) field. If present, this field shall unambiguously identify a
tunnel endpoint in the receiving GTP-U or GTP-C protocol entity.
Page 13 of 102
Apart from Echo Request and Echo Response messages the GTP-C message header shall contain
TEID and Sequence Number fields, followed by two spare octets. Typical GTP-C header is depicted
in Figure 5.
Bits
8
Version
T=1
Spare Spare Spare
Message Type
Message Length (1st Octet)
Message Length (2nd Octet)
Tunnel Endpoint Identifier (1st Octet)
Tunnel Endpoint Identifier (2nd Octet)
Tunnel Endpoint Identifier (3rd Octet)
Tunnel Endpoint Identifier (4th Octet)
Sequence Number (1st Octet)
Sequence Number (2nd Octet)
Spare
Spare
Figure 5: The format of EPC specific GTPv2 Control Plane message Header
2.2. GTP-U header

GTP-U header is specified in [5]. The GTP-U header is a variable length header whose minimum
length is 8 bytes. There are three flags that are used to signal the presence of additional optional
fields: the PN flag, the S flag and the E flag. The PN flag is used to signal the presence of N-PDU
Numbers.
The S flag is used to signal the presence of the GTP Sequence Number field.
The E flag is used to signal the presence of the Extension Header field, used to enable future
extensions of the GTP header without the need to use another version number.
Octets
7
Version
Bits
5
PT
4
(*)
Message Type
Length (1st Octet)
Length (2nd Octet)
Tunnel Endpoint Identifier (1st Octet)
Tunnel Endpoint Identifier (2nd Octet)
Tunnel Endpoint Identifier (3rd Octet)
Tunnel Endpoint Identifier (4th Octet)
Sequence Number (1st Octet)1) 4)
10
Sequence Number (2nd Octet)1) 4)
11
N-PDU Number2) 4)
1
PN
3) 4)
12
Next Extension Header Type
Figure 6: Outline of the GTP-U Header
Page 14 of 102
2.3. GTP-C Messages

Each GTPv2-C message is made up of the header, followed by one or more information elements
(IE). The messages used in our testbed are explained below. For each message, a table lists the
required IEs. The grey IEs are not implemented in our case. For information about each IE and its
format, refer to [1].
2.3.1. Create Session Request

The Create Session Request message shall be sent on the S11 interface by the MME to the SGW and
on the S5/S8 interface by the SGW to the PGW as part of the procedures:
- E-UTRAN Initial Attach (or HO from non 3GPP to 3GPP)
- UE requested PDN connectivity
The message shall also be sent on the S4 interface by the SGSN to the SGW as part of the
procedures:
- PDP Context activation
Table 1: Information Elements in a Create Session Request
Information
elements
IMSI
MSISDN
ME Identity (MEI)
User Location Info
(ULI)
Serving Network
RAT Type
Indication Flags
Condition / Comment
IE Type
M
IMSI
MSISDN
C For an E-UTRAN Initial Attach the IE shall be included
when used on the S11 interface, if provided in the
subscription data from the HSS and it shall be included
when used on the S5/S8 interfaces if provided by the
MME.
The IE shall be included for the case of a UE Requested
PDN Connectivity, it shall be included if the MME has it
stored for that UE.
C The MME shall include the ME Identity (MEI) IE, if it is
MEI
available.
C This IE shall be included for E-UTRAN access. It shall
ULI
include ECGI&TAI.
C This IE shall be included for an E-UTRAN initial attach and Serving Network
for a UE requested PDN connectivity.
M
RAT Type
Indication
C Applicable flags are:
S5/S8 Protocol Indicator: This flag shall be used

on the S11/S4 interfaces and set according to the
protocol chosen to be used on the S5/S8
interfaces.
Dual Address Bearer Flag: This flag shall be set

to 1 when the UE requests a PDN type IPv4v6
and all SGSNs which the UE may be handed over
to support dual addressing. This shall be
determined based on node pre-configuration by
the operator.
Handover Indication: This flag shall be set in an

E-UTRAN Initial Attach or in a UE Requested
PDN Connectivity, if the UE comes from non3GPP access.
Operation Indication: This flag shall be set for a

TAU/RAU.
Direct Tunnel Flag: This flag shall be used on the
S4 interface and set to 1 if Direct Tunnel is used.
Piggybacking Supported: This flag shall be set to 1 only if
the MME/SGSN/SGW supports the piggybacking feature
as described in Annex F of 3GPP TS 23.401.
Change Reporting support Indication: shall be used on
S4/S11, S5/S8 and set if the SGSN/MME supports location
Info Change Reporting.
Ins.
0
0
0
0
0
0
0
Page 15 of 102
Sender F-TEID for
Control Plane
PGW S5/S8 Address
for Control Plane or
PMIP
Access Point Name
(APN)
F-TEID
F-TEID
C This IE shall be sent on the S11 / S4 interfaces. The TEID
is set to "0" in the E-UTRAN initial attach and the UE
requested PDN connectivity procedures.
APN
C This IE shall be included for the TAU/RAU/Handover cases
when the S5/S8 Protocol Indicator is set to 1 (PMIP based
S5/S8). This IE shall also be included for an E-UTRAN
initial attach and a UE requested PDN connectivity.
Selection Mode
C This IE shall be included for an E-UTRAN initial attach and Selection Mode
a UE requested PDN connectivity. It shall indicate whether
a subscribed APN or a non subscribed APN chosen by the
MME was selected.
PDN Type
M This IE shall be set to IPv4, IPv6 or IPv4IPv6. This is
PDN Type
based on the subscription record retrieved from the HSS.
PAA
PDN Address
C This IE shall be included for an E-UTRAN initial attach and
Allocation (PAA)
a UE requested PDN connectivity.
The PDN type field in the PAA shall be set based on the
UE request.
For static IP address assignment, the MME shall set the
IPv4 address and/or IPv6 prefix length and IPv6 address if
available.
If static IP address assignment is not used, the the IPv4
address shall be set to 0.0.0.0, and the IPv6 Prefix Length
and IPv6 address shall all be set to zero.
APN Restriction
Maximum APN
M This IE denotes the most stringent restriction as required
Restriction
by any already active bearer context. If there are no
already active bearer contexts, this value is set to the least
restrictive type.
AMBR
Aggregate Maximum C This IE represents the APN-AMBR. It shall be included for
Bit Rate (APN-AMBR)
an E-UTRAN initial attach and a UE requested PDN
connectivity.
EBI
Linked EPS Bearer
C This IE shall be included on S4/S11 in RAU/TAU/HO
Identity
procedures with SGW change to identify the default bearer
of the PDN Connection
O This IE is not applicable to TAU/RAU/Handover.
PCO
Protocol
Configuration Options
(PCO)
Bearer Contexts to be M Several IEs with the same type and instance value shall be Bearer Context
created
included as necessary to represent a list of Bearers.
One bearer shall be included for an "eUTRAN Initial
Attach" or a "UE requested PDN Connectivity";
One or more bearers shall be included for a
Handover/TAU/RAU with an SGW change.
Bearer Context
Bearer Contexts to be C This IE shall be included on the S4/S11 interfaces for the
removed
TAU/RAU/Handover cases where any of the bearers
existing before the TAU/RAU/Handover procedure will be
deactived as consequence of the TAU/RAU/Handover
procedure.
For each of those bearers, an IE with the same type and
instance value, shall be included.
Trace Information
C This IE shall be included if an SGW and/or a PGW is
Trace Information
activated. See 3GPP TS 32.422 [18].
Recovery
C This IE shall be included if contacting the peer node for the
Recovery
first time.
FQ-CSID
MME-FQ-CSID
O This IE is optionally included by the MME on the S11
interface. It shall be forwarded by an SGW on the S5/S8
interfaces.
SGW-FQ-CSID
O This IE is optionally included by the SGW on the S5/S8
FQ-CSID
interfaces.
UE Time Zone
UE Time Zone
interface or by the SGSN on the S4 interface. This IE shall
be forwarded by the SGW on the S5/S8 interface.
Private Extension
O
Private Extension
0
1
0
0
0
0
0
1
0
VS
Page 16 of 102
Table 2: Bearer Context to be created within Create Session Request
Octet 1
Octets 2 and 3
Octet 4
Information
elements
EPS Bearer ID
UL TFT
DL TFT
S1-U eNodeB F-TEID
S4-U SGSN F-TEID
S5/8-U SGW F-TEID
S5/8-U PGW F-TEID
Bearer Level QoS

Charging
Characteristics
Charging ID
Bearer Context IE Type = 93 (decimal)

Length = n
Spare and Instance fields
Condition / Comment
M
O
O
C This IE shall be included on the S11 interface for an
eUTRAN handover/TAU.
C This IE shall be included on the S4 interface if the S4-U
interface is used.
C This IE shall be included on the S5/S8 interface for an
"eUTRAN Initial Attach" or a "UE Requested PDN
Connectivity".
C This IE shall be included on the S4 and S11 interfaces for
the TAU/RAU/Handover cases when the GTP-based
S5/S8 is used.
M
C This IE shall be included according to 3GPP TS 32.251 [8]
C This IE shall be included on the S11/S4 interfaces for the
TAU/RAU/Handover cases.
O Applicable flags are:
PPC (Prohibit Payload Compression)
Bearer Flags
IE Type
Ins.
EBI
Bearer TFT
Bearer TFT
F-TEID
0
0
1
0
F-TEID
F-TEID
F-TEID
Bearer QoS
Charging
Characteristics
Charging ID
0
0
0
Bearer Flags
2.3.2. Create Session Response

The Create Session Response message shall be sent on the S11 interface by the SGW to the MME
and on the S5/S8 interface by the PGW to the SGW as part of the procedures:
E-UTRAN Initial Attach
UE requested PDN connectivity
The message shall also be sent on S4 interface by the SGW to SGSN as part of the PDP Context
activation. If handling of default bearer fails, then cause at the message level shall be a failure cause.
Table 3: Information Elements in a Create Session Response

Information
elements
Cause
BCM
Change Reporting
Action
Sender F-TEID for
Control Plane
PGW S5/S8 Address

for Control Plane or
PMIP
PDN Address
Allocation (PAA)
APN Restriction
Condition / Comment
IE Type
Ins.
M
Cause
C This IE shall be included if this message is part of the
Bearer Control
procedure PDP Context Activation using the S4 interface.
Mode
Change Reporting
C This IE shall be sent on the S4 interface if the MS Info
Action
Change Reporting mechanism is to be used for this
subscriber in the SGSN.
F-TEID
C This IE shall be sent on the S11/S4 interfaces. For the
S5/S8 interfaces it is not needed because its content would
be identical to the IE PGW S5/S8 Address for Control
Plane or PMIP.
C This IE shall include the TEID in the GTP based S5/S8
F-TEID
case and the GRE key in the PMIP based S5/S8 case.
0
0
C This IE shall be included for the E-UTRAN initial attach and

PAA
the UE requested PDN connectivity.
M This IE denotes the restriction on the combination of types APN Restriction
of APN for the APN associated with this EPS bearer
Context.
Page 17 of 102
Aggregate Maximum C This IE represents the APN-AMBR. It shall be included if
AMBR
Bit Rate (APN-AMBR)
the received APN-AMBR has been modified by the PCRF.
EBI
Linked EPS Bearer
C This IE shall be sent on S4 or S11 when the UE moves
Identity
from a Gn/Gp SGSN to the S4 SGSN or MME to identify
the default bearer the PGW selects for the PDN
Connection.
O This IE is not applicable for TAU/RAU/Handover.
PCO
Protocol
(PCO)
Bearer Context
Bearer Contexts
M EPS bearers corresponding to Bearer Contexts sent in
created
request message. Several IEs with the same type and
instance value may be included as necessary to represent
a list of Bearers.
One bearer shall be included for "eUTRAN Initial Attach" or
"UE Requested PDN Connectivity".
One or more created bearers shall be included for a
Handover/TAU with an SGW change.
Bearer Context
Bearer Contexts
C EPS bearers corresponding to Bearer Contexts to be
marked for removal
removed that were sent in the Create Session Request
message.
For each of those bearers an IE with the same type and
instance value shall be included.
Recovery
C This IE shall be included if contacting the peer for the first
Recovery
time
FQ-CSID
PGW-FQ-CSID
O This IE is optionally included by the PGW on the S5/S8
interfaces. It shall be forwarded by the SGW on the S11
interface.
SGW-FQ-CSID
O This IE is optionally included by the SGW on the S11
FQ-CSID
interface.
Private Extension
O
Private Extension
0
0
0
0
1
VS
Table 4: Bearer Context Created within Create Session Response

Octets 1
Octets 2 and 3
Octets 4
Information
elements
EPS Bearer ID
Cause
UL TFT
DL TFT
S1-U SGW F-TEID
S4-U SGW F-TEID
S5/8-U PGW F-TEID
S12 SGW F-TEID
Bearer Level QoS
Charging Id
Bearer Flags

Length = n
Condition / Comment
M
M This IE shall indicate if the bearer handling was successful,
and if not, it gives information on the reason.
O
O
interface is used.
interface is used.
C This IE shall be included for an "eUTRAN Initial Attach" or
a "UE Requested PDN Connectivity".
C This IE shall be included on the S4 interface if the S12
interface is used.
C This IE shall be included if the received QoS parameters
have been modified.
C This IE shall be included for an E-UTRAN initial attach and
a UE requested PDN connectivity.
O Applicable flags are:
PPC (Prohibit Payload Compression)
IE Type
Ins.
EBI
Cause
0
0
Bearer TFT
Bearer TFT
F-TEID
0
1
0
F-TEID
F-TEID
F-TEID
Bearer QoS
Charging Id
Bearer Flags
2.3.3. Delete Session Request

A Delete Session Request message shall be sent on the S11 interface by the MME to the SGW and on
the S5/S8 interface by the SGW to the PGW as part of the procedures:
Page 18 of 102
EUTRAN Initial Attach (if an old bearer exists)
UE, HSS or MME Initiated Detach
UE or MME Requested PDN Disconnection
It shall also be sent on the S4 interface by the SGSN to the SGW, and on the S5/S8 interface by the
SGW to the PGW as part of
MS, HLR or SGSN initiated detach procedure
Combined GPRS/IMSI Attach
MS and SGSN Initiated Default Bearer Deactivation Procedure using S4
If there are any procedure collisions, the Delete Session Request shall have precedence over any
other Tunnel Management message.
Table 5: Information Elements in a Delete Session Request
Information
P
Condition / Comment
elements
Linked EPS Bearer ID M This IE shall be included to indicate the default bearer
(LBI)
associated with the PDN being disconnected
Indication Flags
C Applicable flags:
Operation Indication: shall be sent on S4/S11
interface if the SGW needs to forward the Delete
Session Request message to PGW.
Scope Indication: if request corresponds to S1
based handover procedure with SGW relocation
or X2 based handover with SGW relocation, then
this bit is set
C If the UE includes the PCO IE, then the MME shall copy
Protocol
the content of this IE transparently from the PCO IE
included by the UE.
(PCO)
Originating Node
C This IE shall be included if the ISR associated GTP entity
sends this message to SGW in Detach procedure to
denote the type of the node originating the message
Private Extension
O None
IE Type
Ins.
EBI
Indication
PCO
Node Type
Private Extension
VS
2.3.4. Delete Session Response

A Delete Session Response message shall be sent on the S11 interface by the SGW to the MME and
on the S5/S8 interface by the PGW to the SGW as part of the following procedures:
- EUTRAN Initial Attach
- UE, HSS or MME Initiated Detach
- UE or MME Requested PDN Disconnection
It shall also be sent on the S4 interface by the SGW to the SGSN and on the S5/S8 interface by the
PGW to the SGW as part of the procedures:
- MS, HLR or SGSN initiated detach procedure
- Combined GPRS/IMSI Attach
- MS and SGSN Initiated Default Bearer Deactivation Procedure using S4
The sending entity shall include Cause IE in the Delete Session Response message. The IE indicates
if the peer has deleted the bearer, or not.
Possible Cause values are "Request accepted" or Request rejected".
Page 19 of 102
Table 6: Information Elements in a Delete Session Response
Information
elements
Cause
Recovery
Condition / Comment
M
C This IE shall be included If contacting the peer for the first
time
C The MME shall copy the content of this IE transparently
Protocol
from the PCO IE included by the UE if the PGW wishes to
provide the UE with application specific parameters
(PCO)
Private Extension
O
IE Type
Ins.
Cause
Recovery
0
0
PCO
Private Extension
VS
2.3.5. Delete Bearer Request

A Delete Bearer Request message shall be sent as part of PGW initiated bearer deactivation
procedures. This Request is sent by the PGW to the SGW and shall be forwarded to the MME or
SGSN.
Possible Cause values are:
- "RAT changed from 3GPP to Non-3GPP".
Table 7: Information Elements in a Delete Bearer Request
Information
P
Condition / Comment
IE Type
Ins.
elements
EBI
0
Linked EPS Bearer ID C If the request corresponds to the bearer deactivation
(LBI)
procedure in case all bearers belonging to a PDN
connection shall be released, then this IE shall be included
to indicate the default bearer associated with the PDN
being disconnected.
This IE shall be included only when the Bearer Contexts is
not present in the message.
EBI
1
EPS Bearer IDs
C This IE shall be used for bearers different from the default
one. In this case at least one bearer shall be included.
Several IEs with this type and instance values shall be
Used for dedicated bearers. When used, at least one
dedicated bearer shall be present
PTI
0
Procedure
C If the request corresponds to UE requested bearer
Transaction Id (PTI)
resource modification procedure for an E-UTRAN, this IE
shall be included.
AMBR
0
C This IE shall be included when the PGW initiates a delete
APN Aggregate
procedure in case of policy updates due to the deletion of
Maximum Bit Rate
non GBR flows
(APN-AMBR)
PCO
0
C The MME shall copy the content of this IE transparently
Protocol
from the PCO IE included by the UE if the PGW wishes to
provide the UE with application specific parameters
(PCO)
FQ-CSID
0
PGW-FQ-CSID
O This IE is optionally included by the PGW on the S5/S8
interface. It shall be forwarded by the SGW on the S11
interface.
SGW-FQ-CSID
O This IE is optionally included by the SGW on the S11
FQ-CSID
1
interface.
Cause
0
Cause
C This IE shall be included if the message is caused by
handover without optimization occurs from 3GPP to non3GPP. In this case the cause value shall be set to RAT
changed from 3GPP to Non-3GPP"
Private Extension
O
Private Extension VS
If handovers without optimization occur from 3GPP to non-3GPP, the PDN GW sends Delete Bearer
Request message to the Serving GW involved to delete all bearers with the PDN address. The
Serving GW sends Delete Bearer Request message to the MME or SGSN involved to delete all
bearers with the PDN address.
Page 20 of 102
2.3.6. Delete Bearer Response

The Delete Bearer Response shall be sent as a response of Delete Bearer Request.
Possible Cause values are:
- "Request accepted".
-
"Request rejected".
Table 8: Information Elements in Delete Bearer Response
Information
P
Condition / Comment
IE Type
Ins.
elements
Cause
M
Cause
0
EBI
0
Linked EPS Bearer ID C If the response corresponds to the bearer deactivation
(LBI)
procedure in case all the bearers associated with the
default bearer of a PDN connection shall be released, this
IE shall be included to indicate the default bearer
associated with the PDN being disconnected.
Bearer Context
0
Bearer Contexts
C It shall be used for bearers different from default one. In
this case at least one bearer shall be included.
Used for dedicated bearers. When used, at least one
dedicated bearer shall be present.
Recovery
Recovery
0
time
MME-FQ-CSID
O This IE is optionally included by MME the on S11 interface.
FQ-CSID
0
It shall be forwarded by the SGW on S5/S8 interface.
SGW-FQ-CSID
O This IE is optionally included by the SGW on the S5/S8
FQ-CSID
1
interface.
Private Extension
O
The Delete Bearer Response is sent from MME or SGSN to PGW (through SGW) as a response of
Delete Bearer Request.
2.3.7. Modify Bearer Request

The Modify Bearer Request message shall only be sent on the S11 interface by the MME to the SGW
and on the S5/S8 interfaces (only during a HO) by the SGW to the PGW as part of the procedures:
- S1-based Handover
- UTRAN Iu mode to E-UTRAN Inter RAT handover
- E-UTRAN Initial Attach
It shall also only be sent on the S4 interface by the SGSN to the SGW and on the S5/S8 interfaces by
the SGW to the PGW as part of the procedures:
- E-UTRAN to UTRAN Iu mode Inter RAT handover
- PDP Context Activation Procedure
Page 21 of 102
Table 9: Information Elements in a Modify Bearer Request
Information
elements
ME Identity (MEI)
Condition / Comment
IE Type
C This IE shall be sent on the S5/S8 interfaces for the Gn/Gp

MEI
SGSN to MME TAU.
User Location Info
O This IE may be included if the ULI has changed since the
ULI
(ULI)
last update
Serving Network
Serving Network
C This IE shall be sent for a TAU with an associated MME
change.
It is sent for a RAU with an MME interaction.
RAT Type
RAT Type
C This IE shall be sent on the S11 interface for a TAU with an
MME change, UE triggered Service Request or an I-RAT
Handover.
This IE shall be sent on the S5/S8 interface for achange of
RAT type.
This IE shall be sent on the S4 interface for aRAU with
MME interaction, a RAU with an SGSN change, a UE
Initiated Service Request or an I-RAT Handover.
Indication
Indication Flags
C Applicable flags are:
ISRAI: This flag shall be set when used on the

S11 interface for a TAU without an MME change
and for an IRAT handover. This flag shall be used
on the S4 interface for a RAU with an MME
interaction
Handover Indication: This flag shall be set for an

E-UTRAN Initial Attach or for a UE Requested
PDN Connectivity change, if the UE comes from a
non-3GPP access.
Direct Tunnel Flag: This flag shall be used on the

S4 interface and set to 1 if Direct Tunnel is used.
Change Reporting support Indication: shall be

used on S4/S11, S5/S8 and set if the SGSN/MME
supports location Info Change Reporting.
F-TEID
Sender F-TEID for
C This IE shall be sent on the S11 and S4 interfaces for a
Control Plane
TAU/RAU/Handover without any SGW change.
This IE shall be sent on the S5 and S8 interfaces for a
TAU/RAU/Handover with a SGW change.
AMBR
Aggregate Maximum C The APN-AMBR shall be sent for a 3G SGSN to MME
Bit Rate (APN-AMBR)
combined hard handover or an SRNS relocation
procedure.
C This IE shall be sent on the S11 interface for a UE
Delay Value
Delay Downlink
triggered Service Request.
Packet Notification
Request
Bearer Contexts to be M Several IEs with the same type and instance value shall be Bearer Context
modified
included as necessary to represent a list of Bearers to be
modified
Bearer Context
Bearer Contexts to be C This IE shall be included on the S4 and S11 interfaces for
removed
the TAU/RAU/Handover and Service Request procedures
where any of the bearers existing before the
TAU/RAU/Handover procedure and Service Request
procedures will be deactivated as consequence of the
TAU/RAU/Handover procedure and Service Request
procedures.
For each of those bearers, an IE with the same type and
instance value, shall be included.
Recovery
Recovery
time
UE Time Zone
UE Time Zone
interface or by the SGSN on the S4 interface. This IE shall
be forwarded by the SGW on the S5/S8 interface.
MME-FQ-CSID
O Optionally included by MME on S11. Shall be forwarded by
FQ-CSID
SGW on S5/S8.
SGW-FQ-CSID
O Optionally included by SGW on S5/S8.
FQ-CSID
Private Extension
O
Private Extension
Ins.
0
0
0
0
0
0
1
VS
Page 22 of 102
Table 10: Bearer Context to be modified within Modify Bearer Request
Octets 1
Octets 2 and 3
Octets 4
Information
elements
EPS Bearer ID
S1 eNodeB F-TEID
S5/8-U SGW F-TEID

S12 RNC F-TEID
S4-U SGSN F-TEID
Bearer Level QoS
Charging
Characteristics

Length = n
Condition / Comment
M
C This IE shall be sent on the S11 interface if the S1-U is
being used:
for an eUTRAN initial attach
a UE triggered Service Request
in all handover cases.

C This IE shall be sent on the S5/S8 interfaces for a
Handover or a TAU/RAU with a SGW change.
C This IE shall be included if the message is sent on the S4
interface if the S12 interface is being used.
interface, if S4-U is being used.
interafce for a TAU without any SGW change.
C This IE shall be included according to 3GPP TS 32.251 [8]
IE Type
Ins.
EBI
F-TEID
0
0
F-TEID
F-TEID
F-TEID
Bearer QoS
Charging
Characteristics
2.3.8. Modify Bearer Response

The Modify Bearer Response message shall be sent on the S11 interface by the SGW to the MME
and on the S5/S8 interfaces (only during HO) by the PGW to the SGW as part of the procedures:
- S1-based Handover
- UTRAN Iu mode to E-UTRAN Inter RAT handover
- E-UTRAN Initial Attach
It shall also be sent on the S4 interface by the SGW to the SGSN and on the S5/S8 interfaces (during
a HO) by the PGW to the SGW as part of the procedures:
- E-UTRAN to UTRAN Iu mode Inter RAT handover
- PDP Context Activation Procedure
If handling of default bearer fails, then Cause at the message level shall be a failure cause.
Page 23 of 102
Table 11: Information Elements in a Modify Bearer Response
Information
elements
Cause
MSISDN
Condition / Comment
IE Type
Ins.
M
Cause
0
C This IE shall be included by the PGW if it is stored in its UE
MSISDN
0
context
EBI
0
Linked EPS Bearer
C This IE shall be sent on S5/S8 when the UE moves from a
Identity
Gn/Gp SGSN to the S4 SGSN or MME to identify the
default bearer the PGW selects for the PDN Connection.
C This IE shall be used for an Inter RAT handover from the
PCO
0
Protocol
UTRAN or GERAN to the E-UTRAN.
(PCO)
Bearer Context
0
Bearer Contexts
M EPS bearers corresponding to Bearer Contexts to be
modified
modified that were sent in Modify Bearer Request
message. Several IEs with the same type and instance
value shall be included as necessary to represent a list of
the Bearers which are modified.
Bearer Context
1
Bearer Contexts
C EPS bearers corresponding to Bearer Contexts to be
marked for removal
removed sent in the Modify Bearer Request message.
Shall be included if request message contained Bearer
Contexts to be removed.
For each of those bearers an IE with the same type and
instance value shall be included.
Change Reporting
C This IE shall be included with the appropriate Action field If Change Reporting 0
Action
Action
the location Change Reporting mechanism is to be started
or stopped for this subscriber in the SGSN/MME.
PGW-FQ-CSID
O Optionally included by PGW on S5/S8. Shall be forwarded
FQ-CSID
0
by SGW on S11.
SGW-FQ-CSID
O Optionally included by SGW on S11.
FQ-CSID
1
Recovery
Recovery
0
time.
Private Extension
O
Table 12: Bearer Context modified within Modify Bearer Response

Octets 1
Octets 2 and 3
Octets 4
Information
elements
EPS Bearer ID
Cause

Length = n
Condition / Comment
IE Type
Ins.
M
EBI
0
M This IE shall indicate if the bearer handling was successful,
Cause
0
and if not, gives information on the reason.
S1 SGW F-TEID
C This IE shall be used on the S11 interface, if the S1
F-TEID
0
interface is used. See NOTE 1
S12 SGW F-TEID
C This IE shall be included on the S4 interface if the S12
F-TEID
1
interface is being used. See NOTE 1
S4-U SGW F-TEID
C This IE shall be present if used on the S4 interface if the
F-TEID
2
S4-U interface is being used. See NOTE 1
NOTE 1: The SGW shall not change its F-TEID for a given interface during the Handover and Service Request
procedure.
2.3.9. Forward Relocation Request

A Forward Relocation Request message shall be sent from the source MME to the target SGSN or
from the source SGSN to the target MME over S3 interface as part of Inter RAT handover.
Table 13 specifies the presence requirements and conditions of the IEs in the message.
Page 24 of 102
Table 13: Information Elements in a Forward Relocation Request
Information
elements
IE Type
Ins.
IMSI
F-TEID
0
0
PDN Connection
F-TEID
SGW S11/S4 IP
Address and TEID for
Control Plane
SGW node name
C This IE shall be included if the source MME or SGSN has
FQDN
the source SGW FQDN.
MME/SGSN UE MM M None
MM Context
Context
Indication
Indication
C This IE shall be included if either one of the DFI flag and
ISRSI flag is set.
DFI flag is set if direct forwarding is supported. DFI flag
shall not be set if the message is used for SRNS relocation
procedure.
ISRSI flag is set if the source MME/SGSN is capable to
establish ISR for the UE or if the ISR is activated, the
source MME/SGSN then indicate the target SGSN/MME to
maintain ISR for the UE in the inter RAT handover
procedures.
F-Container
C This IE shall be included if the message is used for
E-UTRAN
UTRAN/GERAN to E-UTRAN inter RAT handover
Transparent
procedure, intra RAT handover procedure and 3G SGSN
Container
to MME combined hard handover and SRNS relocation
procedure.
F-Container
UTRAN Transparent C This IE shall be included if the message is used for PS
Container
handover to UTRAN Iu mode procedures, SRNS relocation
procedure and E-TURAN to UTRAN inter RAT handover
procedure.
Target
Target Identification
C This IE shall be included if the message is used for SRNS
Identification
relocation procedure and handover to UTRAN/E-UTRAN
procedures.
HRPD access node
C This IE shall be included only if the HRPD pre registration
IP-Address
S101 IP address
was performed at the source MME
1xIWS S102 IP
C This IE shall be included only if the 1xRTT CS fallback pre
IP-Address
address
registration was performed at the source MME
RAN Cause
C This IE is the information from the source eNodeB, the
F-Cause
source MME shall include this IE in the message.
RANAP Cause
C This IE is the information from the source RNC, the source
F-Cause
SGSN shall include this IE in the message.
F-Container
BSS Container
C This IE shall be included if the message is used for PS
handover to GERAN A/Gb mode and E-UTRAN to GERAN
A/Gb mode inter RAT handover procedure.
Source
Source Identification
Identification
handover to GERAN A/Gb mode and E-UTRAN to GERAN
A/Gb mode inter RAT handover procedure.
BSSGP Cause
C This IE is the information from source BSS, the source
F-Cause
SGSN shall include this IE in the message.
Selected PLMN
Selected PLMN ID
O The Selected PLMN ID IE indicates the core network
ID
operator selected for the UE in a shared network. The old
SGSN shall include this IE if the selected PLMN identity is
available.
Recovery
C If contacting the peer for the first time
Recovery
Trace Information
C This IE shall be included when session trace is active for
Trace Information
this IMSI/IMEI.
Private Extension
O
Private Extension
IMSI
Sender's F-TEID for
Control Plane
MME/SGSN UE EPS
PDN Connections
Condition / Comment
M
M This IE specifies the address and the tunnel for control
plane message which is chosen by the source
MME/SGSN.
M Several IEs with this type and instance values shall be
included as necessary to represent a list of PDN
Connections
M
0
0
0
0
0
0
1
0
2
0
0
0
VS
The PDN Connection grouped IE shall be coded as depicted in Table 14.

Page 25 of 102
Table 14: MME/SGSN UE EPS PDN Connections within Forward Relocation Request
Octet 1
Octets 2 and 3
Octet 4
Information
elements
APN
IPv4 Address
IPv6 Address
PDN Connection IE Type = 109 (decimal)

Length = n
Condition / Comment
M
C This IE shall not be included if no IPv4 Address is
assigned.
C This IE shall not be included if no IPv6 Address is
assigned.
C This IE shall only be included for GTP based S5/S8
PGW S5/S8 IP
Control Plane
PGW node name
C This IE shall be included if the source MME or SGSN has
the PGW FQDN.
Bearer Contexts
C Several IEs with this type and instance values may be
Aggregate Maximum C This IE shall be included if the dynamic APN-AMBR is
Bit Rate (APN-AMBR)
available on the source MME/SGSN for this PDN
connection.
IE Type
Instance
APN
IP Address
0
0
IP Address
F-TEID
FQDN
Bearer
Context
AMBR
0
0
The Bearer Context grouped IE shall be coded as depicted in Table 15.

Table 15: Bearer Context within MME/SGSN UE EPS PDN Connections within Forward
Relocation Request
Octet 1
Octets 2 and 3
Octet 4
Information
elements
EPS Bearer ID
UL TFT
DL TFT
Bearer Context IE Type = 93

Length = n
Condition / Comment
Instance
M
EBI
C This IE shall be present if an Uplink TFT is defined for this Bearer TFT
bearer.
C This IE shall be present if a Downlink TFT is defined for
Bearer TFT
this bearer.
M
F-TEID
SGW S1/S4/S12 IP
user plane
C This IE shall be present for GTP based S5/S8
PGW S5/S8 IP
user plane
Bearer Level QoS
M
Charging
characteristics
Container
O Packet Flow ID, Radio Priority, SAPI, PS Handover XID

Parameters may be included
2.3.10.
IE Type
0
0
1
0
F-TEID
Bearer
Level QoS
Charging
characterist
ics
F-Container
0
0
Forward Relocation Response
A Forward Relocation Response message shall be sent as a response to Forward Relocation Request
during Inter RAT handover procedures. Table 16 specifies the presence requirements and conditions
of the IEs in the message.
Cause IE indicates if the relocation has been accepted, or not. The relocation has not been accepted
by the target MME/SGSN if the Cause IE value differs from "Request accepted". Possible Cause
values are:
"Request accepted".
Page 26 of 102
"System failure".
No resources available".
Table 16: Information Elements in a Forward Relocation Response
Information
elements
Cause
Sender's F-TEID for
Control Plane
Condition / Comment
IE Type
M
Cause
F-TEID
C If the Cause IE contains the value "Request accepted", the
target MME/SGSN shall include this IE in Forward
Relocation Response message.
Indication
Indication
C This IE shall be included if the target MME/SGSN has
selected a new SGW. This IE shall not be included if the
message is used for SRNS relocation procedure.
SGWCI flag is set to indicate Serving GW change.
Bearer Context
List of Set-up Bearers C The list of set-up Bearers IE contains the EPS bearer
Identifiers of the Bearers that were successfully allocated
in the target system during a handover procedure. This IE
shall be included if the Cause IE contains the value
"Request accepted".
Bearer Context
List of Set-up RABs
C The list of set-up RABs IE contains the RAB Identifiers of
the RABs that were successfully allocated in the target
system. This IE shall be included if the Cause IE contains
the value "Request accepted".
Bearer Context
List of Set-up PFCs
O The list of set-up PFCs IE contains the Packet Flow
Identifies of the PFCs that were successfully allocated in
the target system during a PS handover to/from GERAN or
inter RAT handover to/from GERAN. If the Cause IE
contains the value "Request accepted", this IE is included.
F-Cause
eNodeB Cause
C If the Cause IE contains the value "Request accepted", this
IE is mandatory if cause value is contained in S1-AP
message.
F-Cause
RANAP Cause
C If the Cause IE contains the value "Request accepted", this
IE is mandatory if cause value is contained in RANAP
message.
F-Container
O This IE contains the radio-related and core network
E-UTRAN
information for handover to E-UTRAN. If the Cause IE
Transparent
Container
F-Container
UTRAN Transparent O This IE contains the radio-related and core network
Container
information for handover to UTRAN. If the Cause IE
F-Container
BSS Container
O This IE contains the radio-related and core network
information for handover to GERAN. If the Cause IE
F-Cause
BSSGP Cause
O For handover to GERAN, if a cause value is received from
the Target BSC, the BSSGP Cause IE shall be included
and shall be sent to the cause value received from the
target BSC.
Private Extension
O None
Private Extension
Ins.
0
0
VS
Bearer Context IE in this message is specified in Table 17, the source system shall use this IE for data
forwarding in handover.
Page 27 of 102
Table 17: Bearer Context
Octet 1
Octets 2 and 3
Octet 4
Information
elements
EPS Bearer ID
NSAPI
Packet Flow ID
eNodeB F-TEID for

DL data forwarding
eNodeB F-TEID for

UL data forwarding
SGW F-TEID for data

forwarding
RNC F-TEID for data
forwarding
SGSN F-TEID for
data forwarding
2.3.11.

Length = n
Condition / Comment
C This IE shall be included if the message is used for S1Based handover procedure.
C This IE shall be included if the message is used for SRNS
relocation procedure and Inter RAT handover to/from Iu
mode procedures.
handover and Inter RAT handover to/from A/Gb mode
procedures.
C This IE shall be included for the message sent from the
target MME, if the DL Transport Layer Address and DL
GTP TEID are included in the "SAE Bearers Admitted List"
of the S1AP: HANDOVER REQUEST ACKNOWLEDGE
and direct forwarding or indirect forwarding without SGW
change is applied.
C This IE shall be included for the message sent from the
target MME, if the UL Transport Layer Address and UL
GTP TEID are included in the "SAE Bearers Admitted List"
of the S1AP: HANDOVER REQUEST ACKNOWLEDGE
and direct forwarding or indirect forwarding without SGW
change is applied.
C This SGW F-TEID shall be included for indirect data
forwarding.
C This RNC F-TEID shall be included in the message sent
from SGSN, if the target system decides using RNC FTEID for data forwarding.
C This SGSN F-TEID shall be included in the message sent
from SGSN, if the target system decides using SGSN FTEID for data forwarding.
IE Type
Ins.
EBI
NSAPI
Packet Flow ID
F-TEID
F-TEID
F-TEID
F-TEID
F-TEID
Forward Relocation Complete Notification
A Forward Relocation Complete Notification message shall be sent to the source MME/SGSN to
indicate the handover has been successfully finished.
Table 18: Information Elements in a Forward Relocation Complete Notification
Information
elements
Indication
Private Extension
O None
2.3.12.
Condition / Comment
This IE shall be included if the message is used for inter
RAT handover, and the UE has ISR capability. Available
flags:
ISRAI flag is set to indicate to the source MME/SGSN
whether it shall maintain the UE's context and whether it
shall activate ISR.
IE Type
Ins.
Indication
Private Extension
VS
Forward Relocation Complete Acknowledge
A Forward Relocation Complete Acknowledge message shall be sent as a response to Forward

Relocation Complete Notification.
Page 28 of 102
Table 19: Information Elements in a Forward Relocation Complete Acknowledge
Information
elements
Cause
Recovery
Private Extension
P
M None
O None
O None
Condition / Comment
IE Type
Ins.
Cause
Recovery
Private Extension
0
0
VS
2.4. GTP-U Messages

In the current version of the testbed, only the G-PDU message is implemented. It consists of a GTP-U
header (as described above), followed by the full IP data packet.
Page 29 of 102
3. Non Access Stratum Protocol - NAS

This chapter provides a description of the NAS protocol messages which are implemented and used
in the current version of our platform. For more detailed information about NAS, please refer to [6].
NAS messages are basically exchanged between UE and MME. The messages can be organized in
two main groups:
- EPS Mobility Management (EMM) Messages.
- EPS Session Management (ESM) Messages.
3.1. EMM States

The EMM protocol of the UE and the network is described by means of two different state machines:
3.1.1. EMM States in the UE

In the following, the possible EMM states of an EMM entity in the UE are described. Only the main
states of an EMM entity are considered.
EMM-DEREGISTERED
In the state EMM-DEREGISTERED, no EMM context has been established and the UE location is
unknown to an MME and hence it is unreachable by an MME. In order to establish an EMM context,
the UE shall start the attach procedure.
EMM-REGISTERED-INITIATED
A UE enters the state EMM-REGISTERED-INITIATED after it has started the attach procedure and
is waiting for a response from the MME.
EMM-REGISTERED
In the state EMM-REGISTERED an EMM context has been established in the UE. The UE may
initiate sending and receiving user data and signalling information.
EMM-DEREGISTERED-INITIATED
A UE enters the state EMM-DEREGISTERED-INITIATED after it has requested release of the
EMM context by starting the detach procedure and is waiting for a response from the MME.
Page 30 of 102
EMM Deregitered
Initiated
Detach Accept
Detach Request
EMM
EMM
Deregistered
Attach Reject
Registered
Attach Request
EMM Regitered
Attach Accept
Initiated
Figure 7: EMM main states in the UE
3.1.2. EMM states in the MME
EMM-DEREGISTERED
In the state EMM-DEREGISTERED, the MME has no EMM context or the EMM Context is marked
as detached. The UE is detached. The MME may answer to an attach procedure initiated by the UE.
EMM-REGISTERED
In the state EMM-REGISTERED, an EMM context has been established in the MME.
EMM-DEREGISTERED-INITIATED
The MME enters the state EMM-DEREGISTERED-INITIATED after it has started a detach
procedure and is waiting for a response from the UE.
EMM Deregitered
Initiated
Detach Accept
Network-Initiated
Detach Request
UE Initiated Detach
EMM
EMM
Deregistered
Registered
ATTACH procedure
Figure 8: EMM main states in the MME
Page 31 of 102
3.2. EMM specific procedures

In our simulation, only 2 EMM specific procedures are implemented:
Attach: Initiated by the UE and used to attach the IMSI in the network for EPS services and
to establish an EMM context and a default bearer.
Detach: Initiated by the UE or the network and used to detach the IMSI in the network for
EPS services and to release an EMM context and all bearers.
3.2.1. Attach procedure

The attach procedure is used to attach for packet services in EPS. With a successful attach procedure,
a context is established for the UE in the MME, and a default bearer is established between the UE
and the PDN GW, thus enabling always-on IP connectivity to the UE.
During the attach procedure, the UE may also obtain the home agent IPv4 and IPv6 addresses.
3.2.1.1 Attach procedure for EPS services
This procedure is used to attach for EPS services only. If the UE wants to keep the connection(s) to
the PDN GW to which it has connected via non-3GPP access, the UE shall indicate "handover EPS
attach" in the EPS attach type IE. Otherwise, the UE shall indicate "initial EPS attach".
Attach procedure initiation

In state EMM-DEREGISTERED, the UE initiates the attach procedure by sending an ATTACH
REQUEST message to the MME, starting timer T3410 timer and entering state EMMREGISTERED-INITIATED.
If timer T3402 is currently running, the UE shall stop timer T3402. If timer T3411 is currently
running, the UE shall stop timer T3411.
The UE shall include the IMSI in the ATTACH REQUEST message. The UE shall send the
ATTACH REQUEST message together with a PDN CONNECTIVITY REQUEST message to
request PDN connectivity to the default PDN.
Attach accepted by the network

If the attach request is accepted by the network, the MME shall send an ATTACH ACCEPT message
to the UE and start timer T3450. The MME shall send the ATTACH ACCEPT message together with
the ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST message to activate the default
bearer.
Upon receiving the ATTACH ACCEPT message, the UE shall stop timer T3410, reset the attach
attempt counter, enter state EMM-REGISTERED.
The UE, when receiving the ATTACH ACCEPT message combined with the ACTIVATE
DEFAULT EPS BEARER CONTEXT REQUEST message, shall send an ATTACH COMPLETE
message combined with an ACTIVATE DEFAULT EPS BEARER CONTEXT ACCEPT message to
the network.
Upon receiving an ATTACH COMPLETE message, the MME shall stop timer T3450.
Attach not accepted by the network

If the attach request cannot be accepted by the network, the MME shall send an ATTACH REJECT
message to the UE including an appropriate reject cause value.
If the attach procedure fails due to a default EPS bearer setup failure, the MME shall combine the
ATTACH REJECT message with a PDN CONNECTIVITY REJECT message. In this case the reject
cause value in the ATTACH REJECT message shall be set to "ESM failure".
Page 32 of 102
Upon receiving the ATTACH REJECT message, the UE shall stop timer T3410 and enter EMMDEREGISTERED state.
Abnormal cases in the UE

The following abnormal cases can be identified:
1. T3410 timeout:
The UE shall abort the attach procedure and proceed as follows:
The attach attempt counter shall be incremented. If the attach attempt counter is less than 5, Timer
T3411 is started and the state is changed to EMM-DEREGISTERED. When timer T3411 expires the
attach procedure shall be restarted.
If the attach attempt counter is equal to 5, the UE starts timer T3402. The state is changed to EMMDEREGISTERED.
2. Transmission failure of ATTACH REQUEST message indication from lower layers:
The UE shall restart the attach procedure.
Abnormal cases on the network side

1. T3450 time-out: On the first expiry of the timer, the network shall retransmit the ATTACH
ACCEPT message and shall reset and restart timer T3450. This retransmission is repeated
four times, i.e. on the fifth expiry of timer T3450, the attach procedure shall be aborted.
3.2.2. Detach procedure

The detach procedure is used by the UE to detach for EPS services and/or to disconnect from the last
PDN it is connected to.
If the detach procedure is performed, the EPS bearer context(s) for this particular UE are deactivated
locally without peer-to-peer signalling between the UE and the MME.
3.2.2.1
UE initiated detach procedure
UE initiated detach procedure initiation

The detach procedure is initiated by the UE by sending a DETACH REQUEST message. The Detach
type IE included in the message indicates whether detach is due to a "switch off" or not. The Detach
type IE also indicates whether the detach is for EPS services only, for non-EPS services only, or for
both.
If the detach is not due to switch off and the UE is in the state EMM-REGISTERED, timer T3421
shall be started in the UE after the DETACH REQUEST message has been sent. The UE shall enter
the state EMM-DEREGISTERED-INITIATED.
If the UE is to be switched off, the UE shall try for a period of 5 seconds to send the DETACH
REQUEST message. During this period, the UE may be switched off as soon as the DETACH
REQUEST message has been sent.
UE initiated detach procedure completion for EPS services only

When the DETACH REQUEST message is received by the network, the network shall send a
DETACH ACCEPT message to the UE, if the Detach type IE does not indicate "switch off".
Otherwise, the procedure is completed when the network receives the DETACH REQUEST message.
Page 33 of 102
The network and the UE shall deactivate the EPS bearer context(s) for this UE locally without peerto-peer signalling between the UE and the MME.
The UE, when receiving the DETACH ACCEPT message, shall stop timer T3421. The UE is marked
as inactive in the network for EPS services. State EMM-DEREGISTERED is entered in the UE and
the network.

1. T3421 timeout:
On the first four expiries of the timer, the UE shall retransmit the DETACH REQUEST message and
shall reset and restart timer T3421. On the fifth expiry of timer T3421, the detach procedure shall be
aborted and the UE shall change to state EMM-DEREGISTERED.
3.3. ESM states

Here the possible states of EPS bearer contexts in the UE and on the network side are described. Each
EPS bearer context is associated with an individual state.
3.3.1. ESM states in the UE
BEARER CONTEXT INACTIVE

No EPS bearer context exists.
BEARER CONTEXT ACTIVE

The EPS bearer context is active in the UE.
Figure 9: The ESM states for EPS bearer context
PROCEDURE TRANSACTION INACTIVE

No procedure transaction exists.
PROCEDURE TRANSACTION PENDING

The UE has initiated a procedure transaction towards the network.
Page 34 of 102
Figure 10: The procedure transaction states in the UE
3.3.2. ESM states in the MME

BEARER CONTEXT INACTIVE
No EPS bearer context exists.
BEARER CONTEXT ACTIVE PENDING

The network has initiated an EPS bearer context activation towards the UE.
BEARER CONTEXT ACTIVE

The EPS bearer context is active in the network.
BEARER CONTEXT INACTIVE PENDING

The network has initiated an EPS bearer context deactivation towards the UE.
Figure 11: The ESM states for EPS bearer context handling in the network
Page 35 of 102
3.4. Network initiated ESM procedures

3.4.1. Default EPS bearer context activation procedure
The purpose of the default bearer context activation procedure is to establish a default EPS bearer
context between the UE and the EPC. The default EPS bearer context activation procedure is initiated
by the network as a response to the PDN CONNECTIVITY REQUEST message from the UE. The
default bearer context activation procedure can be part of the attach procedure, and if the attach
procedure fails, the UE shall consider that the default bearer activation has implicitly failed.
Default EPS bearer context activation initiated by the network

The MME shall initiate the default bearer context activation procedure by sending an ACTIVATE
DEFAULT EPS BEARER CONTEXT REQUEST message and enter the state BEARER CONTEXT
ACTIVE PENDING.
When the default bearer is activated as part of the attach procedure, the MME shall send the
ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST message together with ATTACH
ACCEPT and shall not start the timer T3485.
When the default bearer is activated as the response to a stand-alone PDN CONNECTIVITY
REQUEST message apart from the attach procedure, the MME shall send the ACTIVATE
DEFAULT EPS BEARER CONTEXT REQUEST message alone, and start the timer T3485.
The MME shall assign and include an EPS bearer identity in the ACTIVATE DEFAULT EPS
BEARER CONTEXT REQUEST message.
Default EPS bearer context activation accepted by the UE

Upon receipt of the ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST message, the UE
shall send an ACTIVATE DEFAULT EPS BEARER CONTEXT ACCEPT message and enter the
state BEARER CONTEXT ACTIVE.
When the default bearer is activated as part of the attach procedure, the UE shall send the
ACTIVATE DEFAULT EPS BEARER CONTEXT ACCEPT message together with ATTACH
COMPLETE message.
When the default bearer is activated as the response to the stand-alone PDN CONNECTIVITY
REQUEST message, the UE shall send the ACTIVATE DEFAULT EPS BEARER CONTEXT
ACCEPT message alone.
Upon receipt of the ACTIVATE DEFAULT EPS BEARER CONTEXT ACCEPT message, the
MME shall enter the state BEARER CONTEXT ACTIVE and stop the timer T3485, if the timer is
running.
Default EPS bearer context activation not accepted by the UE

The UE shall send an ACTIVATE DEFAULT EPS BEARER CONTEXT REJECT message and
enter the state BEARER CONTEXT INACTIVE.
Upon receipt of the ACTIVATE DEFAULT EPS BEARER CONTEXT REJECT message, the MME
shall enter the state BEARER CONTEXT INACTIVE and stop the timer T3485, if the timer is
running.

1. Default EPS bearer context activation request for an already activated default EPS bearer
context:
Page 36 of 102
If the UE receives an ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST message
with an EPS bearer identity identical to the EPS bearer identity of an already activated default
EPS bearer context, the UE shall locally deactivate the existing default EPS bearer context and all
the associated dedicated EPS bearer contexts, if any, and proceed with the requested default EPS
bearer context activation.
Abnormal cases on the network side

1. Expiry of timer T3485:
On the first expiry of the timer T3485, the MME shall resend the ACTIVATE DEFAULT EPS
BEARER CONTEXT REQUEST and shall reset and restart timer T3485. This retransmission is
repeated four times, i.e. on the fifth expiry of timer T3485, the MME shall release possibly allocated
resources for this activation and shall abort the procedure.
3.4.2. EPS bearer context deactivation procedure

The purpose of the EPS bearer context deactivation procedure is to deactivate an EPS bearer context
or disconnect from a PDN by deactivating all EPS bearer contexts to the PDN. The EPS bearer
context deactivation procedure is initiated by the network, and it may be triggered by the UE by
means of the UE requested bearer resource release procedure or UE requested PDN disconnect
procedure.
EPS bearer context deactivation initiated by the network

If a NAS signalling connection exists when the MME initiates the EPS bearer context deactivation,
the MME shall initiate the EPS bearer context deactivation procedure by sending a DEACTIVATE
EPS BEARER CONTEXT REQUEST message to the UE, start the timer T3495, and enter the state
BEARER CONTEXT INACTIVE PENDING.
When the MME wants to deactivate all EPS bearer contexts to a PDN and thus disconnect the UE
from the PDN, the MME shall include the EPS bearer identity of the default bearer associated to the
PDN in the DEACTIVATE EPS BEARER CONTEXT REQUEST message.
If no NAS signalling connection exists when the MME initiates the EPS bearer context deactivation,
the ESM entity in the MME shall locally deactivate the EPS bearer context towards the UE without
any peer-to-peer ESM signalling between the MME and the UE.
EPS bearer context deactivation accepted by the UE

Upon receipt of the DEACTIVATE EPS BEARER CONTEXT REQUEST message, the UE shall
delete the EPS bearer context identified by the EPS bearer identity. After deactivating the identified
EPS bearer context, the UE shall respond to the MME with the DEACTIVATE EPS BEARER
CONTEXT ACCEPT.
If the EPS bearer identity indicated in the DEACTIVATE EPS BEARER CONTEXT REQUEST
does not point to an existing EPS bearer context, the UE shall respond with a DEACTIVATE EPS
BEARER CONTEXT ACCEPT with the EPS bearer identity set to the received EPS bearer identity.
If the EPS bearer identity indicated in the DEACTIVATE EPS BEARER CONTEXT REQUEST is
that of the default bearer to a PDN, the UE shall delete all EPS bearer contexts associated to the
PDN. After deactivating all EPS bearer contexts, the UE shall respond to the MME with the
DEACTIVATE EPS BEARER CONTEXT ACCEPT.
Upon receipt of the DEACTIVATE EPS BEARER CONTEXT ACCEPT message, the MME shall
enter the state BEARER CONTEXT INACTIVE and stop the timer T3495.
Page 37 of 102
Abnormal cases on the Network side

1. Expiry of timer T3495:
On the first expiry of the timer T3495, the MME shall resend the DEACTIVATE EPS BEARER
CONTEXT REQUEST and shall reset and restart timer T3495. This retransmission is repeated four
times, i.e. on the fifth expiry of timer T3495, the MME shall abort the procedure and deactivate the
EPS bearer context locally without any peer-to-peer ESM signalling between the MME and the UE.
3.5. UE requested ESM procedures

3.5.1. UE requested PDN connectivity procedure
The purpose of the UE requested PDN connectivity procedure is for a UE to request the setup of a
default EPS bearer to a PDN. If accepted by the network, this procedure initiates the establishment of
a default EPS bearer context. The procedure is used to establish the first default bearer by inclusion
into the initial attach message.
UE requested PDN connectivity procedure initiation

In order to request connectivity, the UE shall send a PDN CONNECTIVITY REQUEST message to
the MME, start timer T3482 and enter the state PROCEDURE TRANSACTION PENDING. This
message shall include the requested APN, if available. In the PDN type information element the UE
shall indicate the IP version capability of the IP stack associated with the UE.
The UE shall set the request type to "initial attach" when the UE is establishing connectivity to a
PDN for the first time, i.e. when it is an initial attach to that PDN.
The UE shall set the request type to "handover" when the connectivity to a PDN is established upon
handover from a non-3GPP access network and the UE was connected to that PDN before the
handover to the 3GPP access network.
UE requested PDN connectivity procedure accepted by the

network
Upon receipt of the PDN CONNECTIVITY REQUEST message, the MME checks whether
connectivity with the requested PDN can be established. If no requested APN is included in the PDN
CONNECTIVITY REQUEST message, the MME shall use the default APN as requested APN.
If connectivity with the requested PDN is accepted by the network, the MME shall initiate the default
EPS bearer context activation procedure.
If connectivity with the requested PDN is accepted, but with a restriction of IP version (i.e. both an
IPv4 address and an IPv6 prefix is requested, but only one particular IP version, or only single IP
version bearers are supported/allowed by the network), cause "PDN type IPv4 only supported" or
"PDN type IPv6 only allowed" or cause "single address bearers only allowed", respectively, shall be
included in the ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST message.
Upon receipt of the message ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST, the UE
shall stop timer T3482 and enter the state PROCEDURE TRANSACTION INACTIVE.
UE requested PDN connectivity procedure not accepted by the

network
If connectivity with the requested PDN cannot be accepted by the network, the MME shall send a
PDN CONNECTIVITY REJECT message to the UE.
Page 38 of 102
Upon receipt of the PDN CONNECTIVITY REJECT message, the UE shall stop timer T3482 and
enter the state PROCEDURE TRANSACTION INACTIVE.

1. T3482 expired:
On the first expiry of the timer T3482, the UE shall resend the PDN CONNECTIVITY REQUEST
and shall reset and restart timer T3482. This retransmission is repeated four times, i.e. on the fifth
expiry of timer T3482, the UE shall abort the procedure and enter the state PROCEDURE
TRANSACTION INACTIVE;
3.6. NAS Messages - EMM

The header of a standard L3 message [7] is composed of two octets, and structured in three main
parts, the protocol discriminator (1/2 octet), a message type octet, and a half octet used in some cases
as a Transaction Identifier, in some other cases as a sub-protocol discriminator, and called skip
indicator otherwise.
Bits 1 to 4 of the first octet of a standard L3 message contain the protocol discriminator.
The other half (bits 5 to 8) of the first octet of every EPS Mobility Management (EMM) message
contains the Security header type IE, or the EPS bearer identity in case of an EPS Session
Management (ESM) message.
The IEs present in the different messages are also explained in [6].
3.6.1. Attach Request

This message is sent by the UE to the network in order to perform an attach procedure.
Message type: ATTACH REQUEST
Direction
: UE to network
Table 20: ATTACH REQUEST message content
IEI
FFS
FFS
FFS
Information Element
Protocol discriminator
Security header type
Attach request message identity
IMSI
MS network capability
EPS attach type
NAS key set identifier
Last visited registered TAI
DRX parameter
ESM message container
Type/Reference
Message type
EPS mobile identity
MS network capability
EPS attach type
NAS key set identifier
Tracking area identity
FFS
Presence
M
M
M
M
M
M
M
O
O
O
Format
V
V
V
LV
LV
V
V
TV
FFS
TLV-E
Length
1/2
1/2
1
2-12
3-9
1/2
1/2
6
FFS
3-n
3.6.2. Attach Accept

This message is sent by the network to the UE to indicate that the corresponding attach request has
been accepted.
Message type: ATTACH ACCEPT
Direction
: network to UE
Page 39 of 102
Table 21: ATTACH ACCEPT message content
IEI
FFS
FFS
FFS
FFS
FFS
FFS
Information Element
Attach accept message identity
EPS attach result
Spare half octet
T3412 value
TAI list
GUTI
LAI
MS identity
T3402 value
Equivalent PLMNs
Type/Reference
Message type
EPS attach result
Spare half octet
GPRS timer
Tracking area identity list
EPS mobile identity
Location area identification
Mobile identity
GPRS timer
PLMN List
Presence
M
M
M
M
M
M
M
O
O
O
O
O
O
Format
V
V
V
V
V
V
LV
TLV
TV
TLV
TV
TLV
TLV-E
Length
1/2
1/2
1
1/2
1/2
1
7-97
13
6
7-10
2
5-47
3-n
3.6.3. Attach Complete

This message is sent by the UE to the network in response to an ATTACH ACCEPT message.
Message type: ATTACH COMPLETE
Direction
: UE to network
Table 22: ATTACH COMPLETE message content
IEI
Information Element
Attach complete message identity
FFS ESM message container
Type/Reference
Message type
Presence
M
M
M
O
Format
V
V
V
TLV-E
Length
1/2
1/2
1
3-n
3.6.4. Attach Reject

This message is sent by the network to the UE to indicate that the corresponding attach request has
been rejected.
Message type: ATTACH REJECT
Direction
: network to UE
Table 23: ATTACH REJECT message content
IEI
Information Element
Attach reject message identity
EMM cause
FFS ESM message container
Type/Reference
Message type
EMM cause
Presence
M
M
M
M
O
Format Length
V
1/2
V
1/2
V
1
V
1
TLV-E
3-n
3.6.5. Detach Request

3.6.5.1 Detach Request (UE originating detach)
This message is sent by the UE to request the release of an EMM context.
Message type: DETACH REQUEST
Direction
: UE to network
Page 40 of 102
Table 24: DETACH REQUEST message content
IEI
Information Element
Detach request message identity
Detach type
Spare half octet
GUTI
Type/Reference
Message type
Detach type
Spare half octet
EPS mobile identity
Presence
M
M
M
M
M
M
Format
V
V
V
V
V
LV
Length
1/2
1/2
1
1/2
1/2
12
3.6.5.2 Detach Request (UE terminated detach)

This message is sent by the network to request the release of an EMM context.
Message type: DETACH REQUEST
Direction
: network to UE
Table 25: DETACH REQUEST message content
IEI
Information Element
Detach request message identity
Detach type
Spare half octet
EMM cause
FFS
Type/Reference
Message type
Detach type
Spare half octet
EMM cause
Presence
M
M
M
M
M
O
Format
V
V
V
V
V
TV
Length
1/2
1/2
1
1/2
1/2
2
3.6.6. Detach Accept

3.6.6.1 Detach Accept (UE originating detach)
This message is sent by the network to indicate that the detach procedure has been completed.
Message type: DETACH ACCEPT
Direction
: network to UE
Table 26: DETACH ACCEPT message content
IEI
Information Element
Detach accept message identity
Type/Reference
Message type
Presence
M
M
M
Format
V
V
V
Length
1/2
1/2
1
3.6.6.2 Detach Accept (UE terminated detach)

This message is sent by the UE to indicate that the detach procedure has been completed.
Message type: DETACH ACCEPT
Direction
: UE to network
Table 27: DETACH ACCEPT message content
IEI
Information Element
Detach accept message identity
Type/Reference
Message type
Presence
M
M
M
Format
V
V
V
Length
1/2
1/2
1
Page 41 of 102
3.7. NAS Messages - ESM

3.7.1. Activate default EPS bearer context request
This message is sent by the network to the UE to request activation of a default EPS bearer context.
Message type: ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST
Direction
: network to UE
Table 28: ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST message content
IEI
FFS
FFS
FFS
FFS
FFS
FFS
FFS
FFS
FFS
Information Element
EPS bearer identity
Procedure transaction identifier
Activate default EPS bearer
context request message identity
SDF QoS
Type/Reference
EPS bearer identity
Message type
Presence Format
M
V
M
V
M
V
M
V
Length
1/2
1
1
SDF quality of service
FFS
FFS
PDN address
Access point name
Uplink TFT
Negotiated QoS
Negotiated LLC SAPI
Radio priority
Packet flow Identifier
Protocol configuration options
ESM cause
PDN address
Access point name
Traffic flow template
Quality of service
LLC service access point identifier
Radio priority
Packet flow Identifier
ESM cause
O
O
O
O
O
O
O
O
O
TLV
TLV
TLV
TLV
TV
TV
TLV
TLV
TV
7-23
3-102
3-257
14-18
2
1
3
3-253
2
3.7.2. Activate default EPS bearer context accept

This message is sent by the UE to the network to acknowledge activation of a default EPS bearer
context.
Message type: ACTIVATE DEFAULT EPS BEARER CONTEXT ACCEPT
Direction
: UE to network
Table 29: ACTIVATE DEFAULT EPS BEARER CONTEXT ACCEPT message content
IEI
Information Element
EPS bearer identity
Activate default EPS bearer context
accept message identity
FFS Protocol configuration options
Type/Reference
Presence
M
EPS bearer identity
M
M
Message type
M
Format
V
V
V
V
Length
1/2
1/2
1
1
TLV
3-253
3.7.3. Activate default EPS bearer context reject

This message is sent by UE to the network to reject activation of a default EPS bearer context.
Message type: ACTIVATE DEFAULT EPS BEARER CONTEXT REJECT
Direction
: UE to network
Page 42 of 102
Table 30: ACTIVATE DEFAULT EPS BEARER CONTEXT REJECT message content
IEI
Information Element
EPS bearer identity
Activate default EPS bearer context
reject message identity
ESM cause
Type/Reference
Presence
M
EPS bearer identity
M
M
Message type
M
ESM cause
M
O
Format
V
V
V
V
Length
1/2
1/2
1
1
V
TLV
1
3-253
3.7.4. Deactivate EPS bearer context request

This message is sent by the network to request deactivation of an active EPS bearer context.
Message type: DEACTIVATE EPS BEARER CONTEXT REQUEST
Direction
: network to UE
Table 31: DEACTIVATE EPS BEARER CONTEXT REQUEST message content
IEI
FFS
Information Element
EPS bearer identity
Deactivate EPS bearer context
request message identity
ESM cause
Type/Reference
EPS bearer identity
Message type
ESM cause
Presence
M
M
M
M
Format
V
V
V
V
Length
1/2
1/2
1
1
M
O
V
TLV
1
3-253
3.7.5. Deactivate EPS bearer context accept

This message is sent by the UE to acknowledge deactivation of the EPS bearer context requested in
the corresponding Deactivate EPS bearer context request message.
Message type: DEACTIVATE EPS BEARER CONTEXT ACCEPT
Direction
: UE to network
Table 32: DEACTIVATE EPS BEARER CONTEXT ACCEPT message content
IEI
FFS
Information Element
EPS bearer identity
Deactivate EPS bearer context
accept message identity
Type/Reference
EPS bearer identity
Message type
Presence
M
M
M
M
Format
V
V
V
V
Length
1/2
1/2
1
1
TLV
3-253
3.7.6. PDN connectivity request

This message is sent by the UE to the network to initiate establishment of a PDN connection.
Message type: PDN CONNECTIVITY REQUEST
Direction
: UE to network
Page 43 of 102
Table 33: PDN CONNECTIVITY REQUEST message content
IEI
Information Element
EPS bearer identity
PDN connectivity request
message identity
Request type
PDN type
FFS Access point name
FFS Ciphered PCO transfer flag
Type/Reference
EPS bearer identity
Message type
Request type
PDN type
Access point name
FFS
Presence
M
M
M
M
Format
V
V
V
V
Length
1/2
1/2
1
1
M
M
O
O
O
V
V
TLV
FFS
TLV
1/2
1/2
3-102
FFS
3-253
3.7.7. PDN connectivity reject

This message is sent by the network to the UE to reject establishment of a PDN connection.
Message type: PDN CONNECTIVITY REJECT
Direction
: network to UE
Table 34: PDN CONNECTIVITY REJECT message content
IEI
FFS
Information Element
EPS bearer identity
PDN connectivity reject message
identity
ESM cause
Type/Reference
Presence
M
EPS bearer identity
M
M
Message type
M
ESM cause
M
O
Format
V
V
V
V
Length
1/2
1/2
1
1
V
TLV
1
3-253
3.8. NAS Timers

The implemented and used NAS timers for UE and network sides are listed in the following tables.
For more details please refer to [6]:
3.8.1. Timers of EPS mobility management

Table 35: EPS mobility management timers UE side
TIMER TIMER
NUM.
VALUE
T3402 Default 12
min.
NOTE 1
T3410 15s
T3411 10s
STATE
CAUSE OF START
NORMAL STOP
ON
EXPIRY
At attach failure and the attempt ATTACH REQUEST Initiation of the
EMMattach
sent
DEREGISTERED counter is equal to 5.
procedure
EMMREGISTERED
ATTACH REQUEST sent
ATTACH ACCEPT Start T3411 or
EMMT3402
received
REGISTEREDATTACH REJECT
INITIATED
received
At attach failure due to T3410
ATTACH REQUEST Retransmission
EMMsent
of the ATTACH
DEREGISTERED timeout
DETACH REQUEST sent

DETACH ACCEPT Retransmission
EMMreceived
of DETACH
DEREGISTEREDREQUEST
INITIATED
NOTE 1: The default value of this timer is used if the network does not indicate another value in an EMM
signalling procedure.
NOTE 2: The value of this timer is provided by the network operator during the attach and tracking area
update procedures.
T3421 15s
Page 44 of 102
Table 36: EPS mobility management timers network side
TIMER
NUM.
TIMER
VALUE
STATE
CAUSE OF START
NORMAL STOP
ON THE
1st, 2nd, 3rd,
4th EXPIRY
(NOTE 1)
DETACH REQUEST sent
DETACH ACCEPT Retransmission
T3422 6s
EMMreceived
of DETACH
DEREGISTEREDREQUEST
INITIATED
Retransmission
T3450 6s
EMM-COMMON- ATTACH ACCEPT sent
ATTACH
of the same
PROC-INIT
COMPLETE
message type,
received
i.e. ATTACH
ACCEPT
NOTE 1: Typically, the procedures are aborted on the fifth expiry of the relevant timer. Exceptions are
described in the corresponding procedure description.
NOTE 2: The value of this timer is network dependent.
3.8.2. Timers of EPS session management

Table 37: EPS session management timers UE side
TIMER
NUM.
TIMER
VALUE
STATE
CAUSE OF START
NORMAL STOP
ON THE
1st, 2nd, 3rd,
4th EXPIRY
(NOTE 1)
DEACTIVATE EPS Retransmission
T3492 6s
PROCEDURE PDN DISCONNECT REQUEST
of PDN
BEARER
TRANSACTION sent
DISCONNECT
CONTEXT
PENDING
REQUEST received REQUEST
or PDN
DISCONNECT
REJECT received
Table 38: EPS session management timers network side

TIMER
NUM.
TIMER
VALUE
T3485 FFS
STATE
BEARER
CONTEXT
ACTIVE
PENDING
CAUSE OF START
ACTIVATE DEFAULT EPS

BEARER CONTEXT REQUEST
sent
NORMAL STOP
ACTIVATE
DEFAULT EPS
BEARER
CONTEXT ACCEPT
received
or ACTIVATE
DEFAULT EPS
BEARER
CONTEXT REJECT
received
DEACTIVATE EPS
BEARER
CONTEXT ACCEPT
received
ON THE
1st, 2nd, 3rd,
4th EXPIRY
(NOTE 1)
Retransmission
of the same
message
Retransmission
of
DEACTIVATE
EPS BEARER
CONTEXT
REQUEST
T3495 FFS
BEARER
CONTEXT
INACTIVE
PENDING
DEACTIVATE EPS BEARER

CONTEXT REQUEST sent
Page 45 of 102
Page 46 of 102
4. S1 Application Protocol - S1AP

This chapter describes the E-UTRAN radio network layer signalling protocol for the S1 interface.
The S1 Application Protocol (S1AP) provides the signalling service between E-UTRAN and the
evolved packet core (EPC). For more details on S1AP Protocol refer to [11].
In our implementation, the following S1AP functions have been implemented:
SAE Bearer management function: This is responsible for setting up and releasing SAE bearers,
which are triggered by the MME. The release of SAE bearers may also be triggered by eNB.
NAS Signalling transport function between the UE and the MME.
Handover Signalling procedures for inter-RAT HO.
Note that on the MME and eNB, S1AP runs over SCTP. In our implementation, SCTP is
transparent.
4.1. S1AP Procedures

4.1.1. Bearer Management Procedures
4.1.1.1 SAE Bearer Setup
The purpose of the SAE Bearer Setup procedure is to assign resources on Uu and S1 for a SAE
bearer and to setup corresponding SAE Radio Bearer for a given UE. The MME initiates the
procedure by sending a SAE BEARER SETUP REQUEST message to eNB. The SAE BEARER
SETUP REQUEST message shall contain the information required by the eNB to build the SAE
bearer configuration.
Figure 12: SAE Bearer Setup procedure
Upon reception of the SAE BEARER SETUP REQUEST message, eNB shall check if resources are
available for the requested configuration. For each SAE bearer request that is accepted, the eNB shall
establish an SAE Radio Bearer and allocate the required resources on Uu. The eNB shall report to the
MME, in the SAE BEARER SETUP RESPONSE message, the result for the requested SAE bearer.
Page 47 of 102
4.1.1.2 SAE Bearer Release
The purpose of the SAE Bearer Release procedure is to enable the release of already established SAE
Bearers for a given UE. The MME initiates the procedure by sending a SAE BEARER RELEASE
COMMAND message. The SAE BEARER RELEASE COMMAND message shall contain the
information required by the eNB to release a SAE bearer.
Figure 13: SAE Bearer Release procedure
Upon reception of the SAE BEARER RELEASE COMMAND message the eNB shall execute the
release of the requested SAE Bearer. For each SAE bearer to be released the eNB shall release the
corresponding SAE Radio Bearer and release the allocated resources on Uu. The eNB shall report to
the MME, in the SAE BEARER RELEASE RESPONSE message, the result for the SAE bearer to be
released.
4.1.2. NAS Transport

The purpose of the NAS Transport procedure is to carry UE-MME signalling over the S1 Interface.
The NAS messages are not interpreted by eNB. The NAS messages are transported in an IE of the
DOWNLINK NAS TRANSPORT or UPLINK NAS TRANSPORT messages:
4.1.2.1 Downlink NAS Transport
If a NAS message shall be sent from the MME to the UE, the MME shall send a DOWNLINK NAS
TRANSPORT message to the eNB including the NAS message as a NAS-PDU IE. The NAS-PDU IE
contains the MME-UE message that is transferred without interpretation in the eNB.
Figure 14: Downlink NAS Transport procedure
Page 48 of 102
4.1.2.2 Uplink NAS Transport
When the eNB has received from the radio interface a NAS message to be forwarded to the MME,
the eNB shall send the UPLINK NAS TRANSPORT message to the MME including the NAS
message as a NAS-PDU IE. The NAS-PDU IE contains the UE-MME message that is transferred
without interpretation in the eNB.
Figure 15: Uplink NAS Transport procedure
4.1.3. Handover Signalling Procedures

4.1.3.1 Handover Preparation
The purpose of the Handover Preparation procedure is to request the preparation of resources at the
target side via the EPC. There is only one Handover Preparation procedure ongoing at the same time
for a certain UE.
source
eNB
MME
HANDOVER REQUIRED
HANDOVER COMMAND
Figure 16: Handover preparation
The source eNB initiates the handover preparation by sending the HANDOVER REQUIRED
message to the serving MME. When the preparation, including the reservation of resources at the
target side is ready, the MME responds with the HANDOVER COMMAND message to the source
eNB.
4.1.3.2 Handover Resource Allocation
The purpose of the Handover Resource Allocation procedure is to reserve resources at the target eNB
for the handover of a UE.
Page 49 of 102
target
eNB
MME
HANDOVER REQUEST
HANDOVER REQUEST ACKNOWLEDGE
Figure 17: Handover resource allocation
The MME initiates the procedure by sending the HANDOVER REQUEST message to the target
eNB. After all necessary resources for the admitted E-RABs have been allocated the target eNB
generates the HANDOVER REQUEST ACKNOWLEDGE message.
4.1.3.3 Handover Notification
The purpose of the Handover Notification procedure is to indicate to the MME that the UE has
arrived to the target cell and the S1 handover has been successfully completed.
target
eNB
MME
HANDOVER NOTIFY
Figure 18: Handover notification
4.2. SAE Bearer Management Messages

4.2.1. SAE Bearer Setup Request
This message is sent by the MME and is used to request the eNB to assign resources on Uu and S1
for a SAE bearer.
Table 39: SAE Bearer Setup Request
Page 50 of 102
4.2.2. SAE Bearer Setup Response

This message is sent by the eNB and is used to report the outcome of the request from the SAE
BEARER SETUP REQUEST message.
Table 40: SAE Bearer Setup Response
4.2.3. SAE Bearer Release Command

This message is sent by the MME and is used to request the eNB to release allocated resources on Uu
and S1 for a SAE bearer.
Table 41: SAE Bearer Release Command
4.2.4. SAE Bearer Release Response

This message is sent by the eNB and is used to report the outcome of the request from the SAE
BEARER RELEASE COMMAND message.
Table 42: SAE Bearer Release Response
Page 51 of 102
4.3. NAS transport Messages

4.3.1. Downlink NAS Transport
This message is sent by the MME and is used for carrying NAS information over the S1 interface.
Table 43: Downlink NAS Message
4.3.2. Uplink NAS Transport

This message is sent by the eNB and is used for carrying NAS information over the S1 interface.
Table 44: Uplink NAS Message
4.4. Handover Signalling Messages

4.4.1. Handover Required
This message is sent by the source eNB to the MME to request the preparation of resources at the
target.
Table 45: HO Required
IE/Group Name
Message Type
MME UE S1AP ID
eNB UE S1AP ID
Handover Type
Cause
Target ID
Direct Forwarding Path
Availability
Presence
M
M
M
M
M
M
O
4.4.2. Handover Command

This message is sent by the MME to inform the source eNB that resources for the handover have
been prepared at the target side.
Table 46: HO Command
Page 52 of 102
IE/Group Name
Presence
Message Type
MME UE S1AP ID
eNB UE S1AP ID
M
M
Handover Type
4.4.3. Handover Request

This message is sent by the MME to the target eNB to request the preparation of resources.
Table 47: HO Request
IE/Group Name
Message Type
MME UE S1AP ID
Handover Type
Cause
UE Aggregate Maximum Bit Rate
Bearer ID
Transport Layer Address
GTP TEID
Bearer Level QoS Parameters
Presence
M
M
M
M
M
M
M
M
M
4.4.4. Handover Request Acknowledge

This message is sent by the target eNB to inform the MME about the prepared resources at the target.
Table 48: HO Request Acknowledge
IE/Group Name
Message Type
MME UE S1AP ID
eNB UE S1AP ID
E-RAB ID
Transport Layer Address
GTP-TEID
DL Transport Layer Address
DL GTP-TEID
UL Transport Layer Address
UL GTP-TEID
Presence
M
M
M
M
M
M
O
O
O
O
4.4.5. Handover Notify

This message is sent by the target eNB to inform the MME that the S1 handover has been completed.
Table 49: HO Notify
IE/Group Name
Message Type
MME UE S1AP ID
eNB UE S1AP ID
Presence
M
M
M
Page 53 of 102
5. Radio Access Network Application Protocol

RANAP
This chapter describes the radio network layer signalling protocol called Radio Access Network
Application Protocol (RANAP) for the Iu interface [23].
RANAP provides the signalling service between UTRAN and the core-network. At the moment, the
following RANAP protocol functions are implemented:
Overall RAB management. This function is responsible for setting up, modifying and
releasing RABs.
Transport of NAS information between UE and core-network (CN).
Inter-RAT handover related procedures.
Note that on the SGSN and RNC, RANAP runs over SCCP. In our implementation, SCCP is
transparent.
5.1. RANAP Procedures and Messages

5.1.1. RAB Assignment
The purpose of the RAB Assignment procedure is to establish new RABs and/or to enable
modifications and/or releases of already established RABs for a given UE. The procedure uses
connection oriented signalling.
CN
RNC
RAB ASSIGNMENT
REQUEST
RAB ASSIGNMENT
RESPONSE
.
.
.
* it can be several responses
Figure 19: RAB Assignment procedure
The CN initiates the procedure by sending a RAB ASSIGNMENT REQUEST message. In our
implementation, the CN may request the UTRAN to establish or release RABs.
The RNC then replies with a RAB ASSIGNMENT RESPONSE message.
5.1.2. Direct Transfer

The purpose of the Direct Transfer procedure is to carry UE CN signalling messages over the Iu
Interface. The UE - CN signalling messages are not interpreted by the UTRAN, and are transported
as a parameter in the DIRECT TRANSFER messages. The procedure uses connection oriented
signalling.
Page 54 of 102
5.1.2.1 CN Originated Direct Transfer
CN
RNC
DIRECT TRANSFER
Figure 20: Direct Transfer, CN originated
If a UE - CN signalling message has to be sent from the CN to the UE, the CN shall send a DIRECT
TRANSFER message to the RNC including the UE - CN signalling message as a NAS-PDU IE.
5.1.2.2 UTRAN Originated Direct Transfer
CN
RNC
DIRECT TRANSFER
Figure 21: Direct Transfer, RNC originated
If a UE - CN signalling message has to be sent from the RNC to the CN without interpretation, the
RNC shall send a DIRECT TRANSFER message to the CN including the UE - CN signalling
message as a NAS-PDU IE.
5.1.3. Relocation Preparation

The relocation procedure shall be co-ordinated over all Iu signalling connections existing for the UE
in order to allow Relocation co-ordination in the target RNC.
Source RNC
CN
RELOCATION REQUIRED
RELOCATION COMMAND
Figure 22: Relocation Preparation procedure
The source RNC initiates the procedure by sending a RELOCATION REQUIRED message. When
the preparation including resource allocation in the target system is ready, the CN shall send a
RELOCATION COMMAND message to the source RNC.
5.1.4. Relocation Resource Allocation

The purpose of the Relocation Resource Allocation procedure is to allocate resources from a target
RNC. The procedure shall be co-ordinated over all Iu signalling connections existing for the UE. The
procedure uses connection oriented signalling.
Page 55 of 102
Target RNC
CN
RELOCATION REQUEST
RELOCATION REQUEST
ACKNOWLEDGE
Figure 23: Relocation Resource Allocation procedure
The CN initiates the procedure by generating a RELOCATION REQUEST message. Upon reception
of the RELOCATION REQUEST message, the target RNC shall initiate allocation of requested
resources.
After all necessary resources for accepted RABs including the initialised Iu user plane, are
successfully allocated, the target RNC shall send a RELOCATION REQUEST ACKNOWLEDGE
message to the CN.
5.1.5. Relocation Complete

The purpose of the Relocation Complete procedure is to indicate to the CN the completion by the
target RNC of the relocation procedure. The procedure shall be co-ordinated over all Iu signalling
connections existing for the UE. The procedure uses connection-oriented signalling.
Target RNC
CN
RELOCATION COMPLETE
Figure 24: Relocation Complete procedure
The target RNC shall initiate the Relocation Complete procedure by sending a RELOCATION
COMPLETE message to the CN.
Page 56 of 102
6. Proxy Mobile IP - PMIP

This chapter deals with a network-based mobility management protocol referred to as Proxy Mobile
IPv6 or PMIPv6.
Network-based mobility management enables IP mobility for a host without requiring its
participation in any mobility related signalling. The Network is responsible for managing IP mobility
on behalf of the host. The mobility entities in the network are responsible for tracking the movements
of the host and initiating the required mobility signalling on its behalf.
The use case examined is the S2a link between non-3GPP Access (WiMAX) and PDN Gateway.
6.1. Introduction
IP mobility for IPv6 hosts is specified in [14]. Mobile IPv6 requires client functionality in the IPv6
stack of a mobile node. Exchange of signalling messages between the mobile node and home agent
enables the creation and maintenance of a binding between the mobile node's home address and the
home agent. Mobility as specified in [14] requires the IP host to send IP mobility management
signalling messages to the home agent.
Network-based mobility is another approach to solving the IP mobility challenge. It is possible to
support mobility for IPv6 nodes without host involvement by extending Mobile IPv6 signalling
messages between a network node and a home agent. This approach to supporting mobility does not
require the mobile node to be involved in the exchange of signalling messages between itself and the
home agent. A proxy mobility agent in the network performs the signalling with the home agent and
does the mobility management on behalf of the mobile node attached to the network. Because of the
use and extension of Mobile IP signalling and home agent functionality, this protocol is referred to as
Proxy Mobile IPv6 (PMIPv6).
The advantages of developing a network based mobility protocol based on Mobile IPv6 are:
Reuse of home agent functionality and of the messages/format used in mobility signalling.
Mobile IPv6 is a mature protocol with several implementations that have undergone
interoperability testing.
A common home agent would serve as the mobility agent for all types of IPv6 nodes.
6.2. PMIPv6 Specifications

Network-based mobility management enables the same functionality as Mobile IP, without any
modifications to the host's TCP/IP Protocol stack. With PMIP the host can change its point-ofattachment to the Internet without changing its IP address.
The core functional entities are the Local Mobility Anchor (LMA) and the Mobile Access Gateway
(MAG).
The local mobility anchor is responsible for maintaining the mobile node's reachability state and is
the topological anchor point for the mobile node's home network prefix(es).
The mobile access gateway is the entity that performs the mobility management on behalf of a mobile
node and it resides on the access link where the mobile node is anchored. The mobile access gateway
is responsible for detecting the mobile node's movements to and from the access link and for
initiating binding registrations to the mobile node's local mobility anchor. There can be multiple local
Page 57 of 102
mobility anchors in a Proxy Mobile IPv6 domain each serving a different group of mobile nodes. The
architecture of a Proxy Mobile IPv6 domain is shown in the following figure.
Figure 25: PMIPv6 Domain
Once a mobile node enters a Proxy Mobile IPv6 domain and attaches to an access link, the mobile
access gateway on that access link, after identifying the mobile node and acquiring its identity, will
determine if the mobile node is authorized for the network-based mobility management service.
If the network determines that the network-based mobility management service needs to be offered to
that mobile node, the network will ensure that the mobile node using any of the address configuration
mechanisms permitted by the network will be able to obtain the address configuration on the
connected interface and move anywhere in that Proxy Mobile IPv6 domain. The obtained address
configuration includes the address(es) from its home network prefix(es), the default-router address on
the link and other related configuration parameters.
The mobile node may be an IPv4-only node, IPv6-only node or a dual IPv4/IPv6 node. Based on
what is enabled in the network for that mobile node, the mobile node will be able to obtain an IPv4,
IPv6 or dual IPv4/IPv6 addresses and move anywhere in that Proxy Mobile IPv6 domain.
If the mobile node connects to the Proxy Mobile IPv6 domain through multiple interfaces and over
multiple access networks, the network will allocate a unique set of home network prefixes for each of
the connected interfaces. The mobile node will be able to configure address(es) on those interfaces
from the respective home network prefix(es). However, if the mobile node performs a handoff by
moving its address configuration from one interface to the other and if the local mobility anchor
receives a handoff hint from the serving mobile access gateway about the same, the local mobility
anchor will assign the same home network prefix(es) that it previously assigned prior to the handoff.
The mobile node will also be able to perform a handoff by changing its point of attachment from one
mobile access gateway to a different mobile access gateway using the same interface and will be able
to retain the address configuration on the attached interface.
The generic message flow for PMIPv6 is illustrated below.
Page 58 of 102
Figure 26: Generic Message Flow
6.3. PMIPv6 Use Case and Protocol Stacks

The PMIPv6 protocol shall be supported in the S2a link between the Mobile Access Gateway (MAG)
and the Local Mobility Anchor (LMA). In this use case, bindings are established between a trusted
non-3GPP IP access (WiMAX) and the PDN GW. The figures below illustrate the control plane for
Mobility Management (MM) and the user plane.
Figure 27: Protocol Stacks
According to terms defined in PMIPv6, the functional entities terminating both the control and user
planes are denoted MAG in the non-3GPP IP access and LMA in the Gateway. LMA includes also
the function of the Home Agent as described in [14].
Page 59 of 102
The MM control plane stack is PMIPv6 over IPv6/IPv4. The user plane carries remote IPv4/v6
packets over either an IPv4 or an IPv6 transport network. The tunnelling layer implements
encapsulation applicable for PMIPv6.
6.4. Message Signalling

In the S2a link implementation, PMIPv6 [18] is used to setup a PMIPv6 tunnel between the trusted
non-3GPP IP access (WiMAX) and the PDN GW. It is assumed that MAG exists in the trusted non3GPP IP access.
6.4.1. Attach Procedure

The Attach procedure can be summarized in the following steps:
The Mobile Station sends a Registration Request Message which arrives at the ASN Gateway
(WiMAX).
The MAG function of Trusted Non-3GPP IP Access sends a Proxy Binding Update (MNNAI, Lifetime) message to PDN GW as described in Section 6.2.1 of [19]. The MN-NAI
identifies the UE. The Lifetime field must be set to a nonzero value in the case of a
registration and a zero value in the case of a de-registration.
The PDN GW processes the proxy binding update message and creates a binding cache entry
for the UE. The PDN GW then sends a Proxy Binding Acknowledgement (MN-NAI,
Lifetime, IP address) message to the MAG function as described in Section 6.2.1 of [19]. The
Lifetime indicates the duration of the binding. The message includes the IP address assigned
by the PGW to the UE.
The PMIPv6 tunnel is set up between the Trusted Non-3GPP IP Access and the PDN GW.
Now IP connectivity between the MS and the PDN GW is set for uplink and downlink
directions.
6.4.2. Detach Procedure

The detach procedure can be summarized in the following steps:
The Mobile Station sends a Deregistration Request Message [3] to the ASN GW (WiMAX).
The Mobile Access Gateway (MAG) in the Trusted Non-3GPP Access sends a Proxy
Binding Update message to the PDN GW with lifetime value set to zero, indicating deregistration, and deletes the cache entry of the specific UE as described in Section 6.4.1 of
[19].
The PDN GW deletes the existing entry implied in the Proxy Binding Update message from
its Binding Cache and sends a Proxy Binding Acknowledgement message to the MAG as
described in Section 6.4.1 of [19].
Resource release procedure is performed and the tunnel is destroyed in case there is no
remaining binding.
6.4.3. Resource Allocation Deactivation Procedure

This procedure is initiated by the PDN GW in order to deactivate the allocated resources in case the
MS has performed a handover to a 3GPP Access Network. All the resource allocations associated
with the PDN address are released in this procedure. The message flow as described in [3] is as
follows:
The PDN GW sends a Binding Revocation Indication message to the trusted non-3GPP IP
access (WiMAX) as defined in [20].
The resources are released in trusted non-3GPP IP access.
Page 60 of 102
The trusted non-3GPP IP access (WiMAX) returns a Binding Revocation Acknowledgement

message to the PDN GW.
6.5. PMIPv6 Messages Format

6.5.1. Mobility Header
The Mobility Header is identified by a Next Header value of 135 in the immediately preceding
IPv6 header and has the following format as described in [14]:
Figure 28: Mobility Header
The 'Payload Proto' field is an 8-bit selector, which identifies the type of header immediately
following the Mobility Header. This field is intended to be used by a future extension.
Implementations conforming to this specification should set the payload protocol type to
IPPROTO_NONE (59 decimal).
The 'Header Len' field is an 8-bit unsigned integer, representing the length of the Mobility Header
in units of 8 octets, excluding the first 8 octets. The length of the Mobility Header must be a
multiple of 8 octets.
The 'MH Type' field is an 8-bit selector, which identifies the particular mobility message in
question. This field has value 5 for a Proxy Binding Update message and value 6 for a Proxy
Binding Acknowledgment message.
The 'Reserved' field is an 8-bit field reserved for future use. The value must be initialized to zero
by the sender and must be ignored by the receiver.
The 'Checksum' field is a 16-bit unsigned integer. This field contains the checksum of the
Mobility Header.
The 'Message Data' is a variable length field containing the data specific to the indicated Mobility
Header type.
6.5.2. Proxy Binding Update (PBU) message

This message is used to request a new binding between the MAG and the LMA or to refresh an
existing binding. The message format is shown below as described in Section 8.1 of [18]:
Page 61 of 102
Figure 29: PBU
The 'Sequence #' field is a 16-bit number to match the corresponding PBU's with PBA's of a
Mobile node.
The bits A, H, L, P must be set to value 1 and K, M, R must be set to value 0.
The 'Reserved' field is bits that are reserved for future purposes and are set to 0.
The 'Lifetime' field is used to specify the time that the Mobile Node needs the binding for (nonzero for registration or reregistration and zero for de-registration).
The Mobility options are the following:
Mobile Node Identifier: this is the Network Access Identifier of the Mobile Node.
Home Network Prefix(es): this is the IP address granted to the UE.
Handoff Indicator: defines the reason of the Handoff. The field HI has value 1 for an
attachment over a new interface, value 4 for deregistration and value 5 for re-registration.
Access Technology Indicator: defined during the attachment procedure. The value 5 indicates
use of the WiMAX.
The format of the mobility options is the following as described in Section 6.2.1 of [14]:
Figure 30: Mobility Options Format
6.5.3. Proxy Binding Acknowledgment (PBA) message

This message is used to respond to a request from the MAG to the LMA. The format is the
following as described in Section 8.2 of [18]:
Page 62 of 102
Figure 31: PBA message Format
The 'Status' field must be zero in case the Proxy Binding Update was accepted by the LMA. In
case it is less than 128, it is still accepted. In case the value is one, it is accepted but prefix
discovery is necessary. If the Proxy Binding Update was rejected by the LMA, then the Status
field value is greater than or equal to 128.
The Mobility Options, the Sequence # and the K, R, P bits must be copied from the PBU message.
In the Home Prefix Address Option the IP address granted is filled in.
The 'Lifetime' field is filled with the granted lifetime, in time units of 4 seconds, for which this
node should retain the entry for this mobile node in its Binding Cache List. The value of this field
is undefined if the Status field indicates that the Binding Update was rejected.
6.5.4. Binding Revocation Indication (BRI) Message

The Binding Revocation Indication (BRI) message is used by the LMA to notify the MAG that the
mobility service of a specified MN binding or bindings have been revoked in order for the MAG to
take the proper action and release the associated resources. The format is the following as described
in Section 10.1 of [20]:
Figure 32: BRI message Format
The Sequence field is a two byte sequence number. The mobility agent sets this sequence number
to the next available number after the last used sequence number. The sending mobility node uses
this sequence number to match the BRA to the outstanding BRI message.
The Proxy Binding (P) bit is set by the sending mobility node to indicate that the revoked binding
is a proxy MIPv6 binding entry.
Page 63 of 102
The Acknowledge (A) bit is set by the sending mobility node to request the peer mobility node to
acknowledge receiving the BRI message via a BRA message.
The Global Per-Peer Bindings (G) bit is set by the sending mobility node to request the receiving
peer mobility node to terminate all mobility sessions created between the two mobility entities.
The Reserved field is reserved for future use. The value must be initialized to 0 by the sender and
must be ignored by the receiver.
A mobility option of type MN-ID [17] is used to identify a specific binding that its registration is
being revoked.
6.5.5. Binding Revocation Acknowledgment Message

The receiver of the BRI message will send the Binding Revocation Acknowledge (BRA) in response
to a Binding Revocation Indication message. The format is the following as described in Section 10.2
of [20]:
Figure 33: BRA message Format
The Sequence field is a two byte sequence number. When the MAG sends a BRA message, it
must copy the sequence number from the sequence number field of the corresponding BRI
message.
The Status field is one byte which indicates the result of processing the corresponding BRI
message by the receiving mobility entity:
0 for success
1 for failure unspecified
2 for MN binding does not exist
The Proxy Binding (P) bit is set if the same P bit is set in the corresponding BRI message.
The Global Per-Peer Bindings (G) bit is set if the same G bit is set in the corresponding BRI
message
The Reserved field is reserved for future use. The value must be initialized to 0 by the sender and
must be ignored by the receiver.
A mobility option of type MN-ID [17] is used to identify a specific binding that its registration is
being revoked.
Page 64 of 102
7. Network Architecture and Functionality

This chapter provides a description of the network nodes as implemented in the testbed and the
different procedures that can be performed including initial attach, detach and handover procedures.
In addition to a streaming server and a user node, the system is made up of several entities as follows:
RealNeS LTE Emulator
RealNeS WiMAX Emulator
RealNeS HSPA Emulator including the SGSN
MME node
SGW node
PGW node
7.1. MME
The standard functions of MME are described in [2]. In our implementation only a part of this
functionality is needed as follows:
NAS signalling required to perform an initial attach, detach, or a handover (HO). Details
on implemented NAS procedures/messages can be found in chapter 3.
Selection of the PGW and SGW: In our emulation, the PGW and SGW selection
functions are simple since we only have one PGW and one SGW.
Bearer management functions including S1-AP procedures as described in Chapter 4.
7.2. SGW
The standard functions of the Serving GW are described in [2]. In our implementation, only a part of
this functionality is needed as follows:
GTP-C procedures executed when performing initial attach, detach, or a handover. Details on
implemented GTP messages can be found in Chapter 2. Description of the procedures will
follow in this chapter.
Routing data traffic (G-PDUs) between PGW and 3GPP Access (eNodeB or RNC in our
testbed).
7.3. PGW
The standard functions of the PDN GW are described in [2]. In our implementation, only a part of
this functionality is needed as follows:
UE IP address allocation as described in the following section.
A Local Mobility Anchor, LMA (refer to Chapter 6). The LMA function is to accept and
route packets to a trusted Mobile Access Gateway (MAG), like the ASN GW in WiMAX.
User plane anchor for mobility between 3GPP access (LTE, HSPA) and non-3GPP access
(WiMAX).
Page 65 of 102
7.4. IP Address Allocation

7.4.1. General
A UE shall perform the address allocation procedures for at least one IP address (either IPv4 or IPv6)
after the default bearer activation if no IPv4 address is allocated during the default bearer activation
[2].
Both EPS network elements and UE shall support the following mechanisms:
IPv4 address allocation via default bearer activation, if IPv4 is supported.
IPv6 prefix allocation via IPv6 Stateless Address auto-configuration according to [21], if
IPv6 is supported;
The following clauses describe how the above listed IP address allocation mechanisms work when
GTP based S5/S8 is used.
In order to support DHCP based IP address configuration, the PDN GW shall act as the DHCP server
for HPLMN assigned dynamic and static and VPLMN assigned dynamic IP addressing. When DHCP
is used for external PDN assigned addressing and parameter configuration, the PDN GW shall act as
the DHCP server towards the UE and it shall act as the DHCP client towards the external DHCP
server. The Serving GW does not have any DHCP functionality. It forwards all packets to and from
the UE including DHCP packets as normal.
7.4.2. IP Allocation
When the PLMN allocates the IP address, it is the PGW's responsibility to allocate and release the IP
address. The PDN GW may use an internal address pool in this case. The PDN GW allocates an IPv4
address upon default bearer activation and it releases the IPv4 address upon default bearer deactivation for a given UE.
When the IP address is allocated from the external PDN, it is the PGW's responsibility to obtain the
IP address from the external PDN, allocate and release the IP address.
7.4.3. Implementation
In our testbed, the IPv4 address is provided to the UE as part of the default bearer activation [2]. The
PGW is responsible for allocating the address (static allocation).
7.5. Procedures
7.5.1. WiMAX Initial Attach
This procedure is described in Chapter 6.
7.5.2. LTE Initial Attach

The messages involved in this procedure are shown in the figure below:
Page 66 of 102
UE
eNodeB
new MME
Serving GW
PDN GW
1. Attach Request
2. Attach
Request
7. Delete Session Request
7. Delete Session Response
13. Create Default Bearer Request

16. Create Default Bearer Response
17. Create Default Bearer Response
18. Attach Accept
19. RRC Connection Reconfiguration
20. RRC Connection Reconfiguration Complete
21. Attach Complete
First Uplink Data
22. Update Bearer Request
23. Update Bearer Response
First Downlink Data
Figure 34: Attach procedure
Page 67 of 102
1,2.
7.
13.
14.
16.
17.
18.
19.
20.
21.
22.
23.
The UE initiates the Attach procedure by the transmission of a NAS Attach Request (IMSI)
message to MME. The message is carried by RRC from UE to eNodeB and then by S1-AP
from eNodeB to MME. Attach Type indicates Initial Attach. For detailed description of the
NAS message refer to Chapter 3.
If there are active bearer contexts in the MME for this particular UE (i.e. the UE re-attaches to
the same MME without having properly detached before), the new MME deletes these bearer
contexts by sending GTP Delete Session Request (TEIDs) messages to the GWs involved. The
GWs acknowledge with Delete Session Response (TEIDs) message.
MME sends a GTP Create Default Bearer Request (IMSI, MME TEID for control plane, PDN
GW address, PDN Address, APN, RAT type, Default Bearer QoS, PDN Type, EPS Bearer
Identity) message to the selected Serving GW.
The Serving GW creates a new entry in its EPS Bearer table and sends a Create Default Bearer
Request (IMSI, APN, Serving GW Address for the user plane, Serving GW TEID of the user
plane, Serving GW TEID of the control plane, RAT type, Default Bearer QoS, PDN Type,
PDN Address, EPS Bearer Identity) message to the PDN GW indicated by the PDN GW
address received in the previous step.
The P-GW creates a new entry in its EPS bearer context table. The new entry allows the P-GW
to route user plane PDUs between the S-GW and the packet data network.The PDN GW
returns a Create Default Bearer Response (PDN GW Address for the user plane, PDN GW
TEID of the user plane, PDN GW TEID of the control plane, PDN Type, PDN Address, EPS
Bearer Identity, Cause) message to the Serving GW. The PDN GW allocates a PDN Address
which is the IP address assigned for the UE for the given PDN.
The Serving GW returns a Create Default Bearer Response (PDN Type, PDN Address, Serving
GW address for User Plane, Serving GW TEID for User Plane, Serving GW TEID for control
plane, EPS Bearer Identity, PDN GW addresses and TEIDs (GTP-based S5/S8) at the PDN
GW(s) for uplink traffic, Cause) message to the MME.
The MME sends an Attach Accept (APN, PDN Address, EPS Bearer Identity) message to the
eNodeB. This message is contained in an S1_MME control message Initial Context Setup
Request. This S1 control message also includes the EPS Bearer QoS, EPS Bearer Identity, as
well as the TEID at the Serving GW used for user plane and the address of the Serving GW for
user plane.
The eNodeB sends the RRC Connection Reconfiguration message including the EPS Radio
Bearer Identity to the UE, and the Attach Accept message will be sent along to the UE.
The UE sends the RRC Connection Reconfiguration Complete message to the eNodeB. This
message includes the Attach Complete (EPS Bearer Identity) message.
The eNodeB forwards the Attach Complete message to the new MME in an S1 control
message. This S1 control message includes the TEID of the eNodeB and the address of the
eNodeB used for downlink traffic on the S1-U reference point.
After the Attach Accept message and once the UE has obtained a PDN Address, the UE can
then send uplink packets towards the eNodeB which will then be tunnelled to the Serving GW
and PDN GW.
The MME sends an Update Bearer Request (eNodeB address, eNodeB TEID) message to the
Serving GW.
The Serving GW acknowledges by sending Update Bearer Response (EPS Bearer Identity)
message to the MME. The Serving GW can then send downlink packets.
For detailed information about the exchanged GTPv2 and NAS messages exchanged above please
refer to Chapters 2 and 3 respectively.
7.5.3. HSPA Initial Attach

HSPA initial attach from the core-network point of view is the same as that of LTE. The
same GTP procedure is executed. More details on this and the radio bearer establishment
is found in [22].
Page 68 of 102
7.5.4. WiMAX Detach

This procedure is described in Chapter 6.
7.5.5. LTE Detach (UE Initiated)
The Detach procedure when initiated by the UE is illustrated in the figure below.
eNodeB
UE
MME
Serving GW
PDN GW
1. Detach Request
2. Delete Session Request
3. Delete Bearer Request
4. Delete Bearer Response

5. Delete Session Response
11. Detach Accept
12. Signalling Connection Release
Figure 35: UE-Initiated Detach Procedure
1.
The UE sends NAS message Detach Request (IMSI, Switch Off) to the MME. Switch Off
indicates whether detach is due to a switch off situation or not.
The active EPS Bearers in the Serving GW regarding this particular UE are deactivated by the
MME sending Delete Session Request (TEID) to the Serving GW.
The Serving GW sends Delete Bearer Request (TEID) to the PDN GW.
The PDN GW acknowledges with Delete Bearer Response (TEID).
The Serving GW acknowledges with Delete Session Response (TEID).
If Switch Off indicates that detach is not due to a switch off situation, the MME sends a NAS
Detach Accept to the UE.
The MME releases the S1-MME signalling connection for the UE by sending S1 Release
Command to the eNodeB with Cause set as Detach.
2.
3.
4.
5.
11.
12.
7.5.6. HSPA Detach

HSPA detach procedure from the core-network point of view is the same as the LTE detach. A GTP
Delete Session Request message is sent by the SGSN over the S4 interface to the SGW which
forwards it to the PGW.
7.5.7. Handovers
The HO procedures covered are discussed below:
Handover from Trusted Non-3GPP IP Access to E-UTRAN Access (WiMAX to LTE).
Handover from Trusted Non-3GPP IP Access to UTRAN Access (WiMAX to HSPA).
Handover from 3GPP Access to Trusted Non-3GPP IP Access (LTE to WiMAX and HSPA
to WiMAX).
Page 69 of 102
7.5.7.1 Handover from WiMAX to LTE
The messages involved are shown in the figure below. It is assumed that while the UE is served by
the trusted non-3GPP IP access (WiMAX), a PMIPv6 tunnel is established between the non-3GPP
access network and the PDN GW in the EPC.
UE
Trusted
Non3GPP IP
Access/
ePDG
E-UTRAN
MME
Serving
GW
PDN
GW
1. PMIPv6 Tunnel
2. UE
discovers
3GPP access
system and
initiates HO
3. Attach
7. Create Bearer Request

9. Create Bearer Response
10. Create Default Bearer
Response (IP Addr)
11. Radio and Access Bearer Establishment
12. Modify Bearer Request

14. Modify Bearer Response

16. Radio and Access Bearer
16. PMIPv6/GTP Tunnel
17. UE Requested PDN Connectivity

18. Non-3GPP EPS Bearer Release
Figure 36: Handover from Trusted Non-3GPP IP Access to E-UTRAN with PMIP on S2a and
GTP on S5/S8 interfaces
Page 70 of 102
The steps involved in the handover are listed below.
1
The UE uses a trusted non-3GPP access system (WiMAX) and is being served by PDN GW.
2
The UE discovers the E-UTRAN access and determines to transfer its current sessions (i.e.
handover) from the currently used non-3GPP access system to E-UTRAN.
3
The UE sends an Attach Request to the MME with Attach Type indicating "Handover" Attach.
The message from the UE is routed by E-UTRAN to the MME as specified in TS 23.401 (EUTRAN) [2].
6
The MME selects a serving GW as described in TS 23.401 [2] and sends a Create Default
Bearer Request (including IMSI, PDN-GW address, Handover Indication) message to the
selected Serving GW. Since the Attach Type is "Handover" Attach, Handover Indication
information is included.
7
The Serving GW sends a Create Default Bearer Request (Handover Indication) message to the
PDN-GW. Since the MME includes Handover Indication information in Create Default Bearer
Request message, the Serving GW includes this information in Create Default Bearer Request
message.
Since Handover Indication is included, the PDN GW should not switch the tunnel from non3GPP IP access to 3GPP access system at this point.
9
The PDN GW responds with a Create Default Bearer Response message to the Serving GW.
The Create Default Bearer Response contains the IP address that was assigned to the UE while
it was connected to the non-3GPP IP access.
10
The Serving GW returns a Create Default Bearer Response message to the MME as specified
in TS 23.401 [2]. This message also includes the IP address of the UE. This message also
serves as an indication to the MME that the S5 bearer setup and update has been successful. At
this step the GTP tunnel(s) over S5 are established.
11
Radio and Access bearers are established at this step in the 3GPP access (chapter 6).
12
The MME sends an Update Bearer Request (eNodeB address, eNodeB TEID, Handover
Indication) message to the Serving GW.
13
Since the Handover Indication is included in step 12, the Serving GW sends a Modify Bearer
Request message to the PDN GW to prompt the PDN GW to tunnel packets from non 3GPP IP
access to 3GPP access system and immediately start routing packets to the Serving GW for the
default and any dedicated EPS bearers established.
14
The PDN GW acknowledges by sending Modify Bearer Response to the Serving GW.
15 The Serving GW acknowledges by sending Modify Bearer Response (EPS Bearer Identity)
message to the MME.
16
The UE sends and receives data at this point via the E-UTRAN system.
17
For connectivity to multiple PDNs, the UE establishes connectivity to each PDN that the UE
was connected to before the handover, besides the Default PDN, by executing the UE
requested PDN connectivity procedure specified in TS 23.401 [2].
18
The PDN GW shall initiate resource allocation deactivation procedure in the trusted non-3GPP
IP access as described below (PDN GW initiated Resource allocation Deactivation with S2a
PMIP).
7.5.7.2 Handover from WiMAX to HSPA
The messages involved are shown in the figure below. It is assumed that while the UE is served by
the trusted non-3GPP IP access (WiMAX), a PMIPv6 tunnel is established between the non-3GPP
access network and the PDN GW in the EPC.
Page 71 of 102
UE
Trusted
Non3GPP IP
Access/
ePDG
UTRAN
SGSN
Serving
GW
PDN
GW
1. PMIPv6 Tunnel
2. UE
discovers
3GPP access
system and
initiates HO
3. Attach
6. Attach accept
7. Activate PDP Context Request
11. Create Bearer Response
12. Create Default Bearer
Response (IP Addr)
13. Completion of PDP Context Establishment

14b. Modify Bearer Request
15b. Modify Bearer Response

16. Radio and Access Bearer
16. PMIPv6/GTP Tunnel
17. Non-3GPP EPS Bearer Release
Figure 37: Handover from Trusted Non-3GPP IP Access to UTRAN with PMIP on S2a and GTP
on S5/S8 interfaces
1.
The UE uses a trusted/untrusted non-3GPP access system and is being served by PDN GW (as
PMIPv6 LMA).
Page 72 of 102
2.
3.
6.
7.
8.
9.
11.
12.
13.
14. 14b.
15b. 15
16.
17.
The UE discovers the 3GPP Access system (UTRAN) and determines to transfer its current
sessions (i.e. handover) from the currently used non-3GPP access system to the discovered
3GPP Access system.
The UE sends an Attach Request to the SGSN. The message from the UE is routed by 3GPP
Access to the SGSN as specified in clause 6.5 of [22].
The SGSN sends the Attach Accept request to the UE to indicate the completion of the attach
procedure as defined in [22].
The UE initiate at this stage this establishment of the primary PDP context as defined in
clause 9.2.2 of [22].
The SGSN selects a Serving GW as described in [22] and sends Create Default Bearer Request
(Handover indication, and other parameters) message to the selected Serving GW.
The Serving GW sends a Create Default Bearer Request message to the PDN-GW. The PDN
GW should not switch the tunnel from non-3GPP IP access to 3GPP access system at this
point.
The PDN GW responds with a Create Default Bearer Response message to the Serving GW.
The Create Default Bearer Response contains the IP address or the prefix that was assigned to
the UE while it was connected to the non-3GPP IP access.
The Serving GW returns a Create Default Bearer Response message to the SGSN. This
message also includes the IP address of the UE. This message also serves as an indication to
the SGSN that the S5 bearer setup and update has been successful.
The rest of the PDP context establishment as specified in [22] is completed here.
The SGSN sends an Update Bearer Request (RNC address, RNC TEID, Handover Indication)
message to the Serving GW. Since the Handover Indication is included, the Serving GW sends
a Modify Bearer Request message to the PDN GW to prompt the PDN GW to tunnel packets
from non 3GPP IP access to 3GPP access system and immediately start routing packets to the
Serving GW for the default and any dedicated EPS bearers established.
The PDN GW acknowledges by sending Modify Bearer Response to the Serving GW. The
Serving GW acknowledges by sending Modify Bearer Response (EPS Bearer Identity)
message to the SGSN.
The UE sends and receives data at this point via the 3GPP access system.
The PDN GW shall initiate resource allocation deactivation procedure in the trusted/untrusted
non-3GPP IP access as described below (PDN GW initiated Resource allocation Deactivation
with S2a PMIP).
7.5.7.3 PDN GW initiated Resource Allocation Deactivation with S2a PMIP

All the resource allocations associated with the PDN address are released in this procedure.
UE
Trusted Non3GPP IP Access
PDN
GW
1. Binding Revocation Request

Trusted Non-3GPP IP Access initiated release procedures
2. Release the Old context
5. Binding Revocation Ack
Figure 38: PDN GW Initiated Binding Revocation with S2a PMIP
Page 73 of 102
1.
2.
5.
The PDN GW sends a Binding Revocation Indication message to the trusted non-3GPP IP
access (Chapter 6).
The resources may be released in trusted non-3GPP IP access, according to an access specific,
trusted non-3GPP IP access initiated, release mechanism.
The trusted non-3GPP IP access returns a Binding Revocation Acknowledgement message to
the PDN GW.
7.5.7.4 Handover from LTE to WiMAX or HSPA to WiMAX

The steps involved in the handover from 3GPP Access connected to the EPC to trusted non-3GPP IP
access are depicted below. It is assumed that while the UE is served by the 3GPP Access, a GTP
tunnel is established between the S-GW and the PDN GW in the evolved packet core.
UE
Trusted
Non3GPP IP
Access
3GPP
Access
MME
Serving
GW
PDN GW
1. GTP tunnel
2. UE discovers
Trusted Non-3GPP
Access and initiates
HO
4. L3 Attach Trigger
6. Proxy Binding Update

9. Proxy Binding Ack (IP Addr)
10. L3 Attach Completion

11. PMIPv6 tunnel
12. UE-initiated Connectivity to Additional PDN

13. 3GPP EPS Bearer Release
Figure 39: Handover from 3GPP Access to Trusted Non-3GPP IP Access with PMIPv6 on S2a
and GTP on S5 interface
Page 74 of 102
1
2
The UE is connected in the 3GPP Access and has a GTP tunnel on the S5 interface.
The UE discovers the trusted non-3GPP IP access system and determines to transfer its current
sessions (i.e. handover) from the currently used 3GPP Access to the discovered trusted non3GPP IP access system.
The L3 attach procedure is triggered.
The entity in the trusted non-3GPP IP Access acting as a MAG (ASN-GW in WiMAX), sends
a Proxy Binding Update message to the PDN GW in order to establish the new registration.
The PDN GW responds with a PMIP Binding Acknowledgement message to the Trusted Non3GPP IP Access. The message contains the IP address allocated for the UE.
L3 attach procedure is completed at this point. The IP address(es) assigned to the UE by the
PDN-GW is conveyed to the UE.
The PMIPv6 tunnel is set up between the Trusted Non-3GPP IP Access and the PDN GW. The
UE can send/receive IP packets at this point.
For connectivity to multiple PDNs, the UE establishes connectivity to all the PDNs that the UE
was connected to before the handover besides the Default PDN.
The PDN GW shall initiate resource allocation deactivation procedure in 3GPP access as
defined in [3].
4
6
9
10
11
12
13)
7.5.7.5 Handover from LTE to HSPA

Here handovers are carried using a direct tunnel and direct forwarding as well. No SGW change is
assumed.
The handover is divided into two phases: a preparation phase and an execution phase [2].
7.5.7.5.1 Preparation phase
UE
Source
eNodeB
Target RNC Source MME
Target
Target SGSN Serving GW Serving GW
Uplink and DownlinkUser Plane PDUs

1. Handover Initiation
2. Handover Required
3. Forward Relocation Request
5. Relocation Request
5a. Relocation Request Acknowledge
7. Forward Relocation Response
Figure 40: E-UTRAN to UTRAN Iu mode Inter RAT HO, preparation phase
1.
The source eNodeB decides to initiate an Inter-RAT handover to the target access network,
UTRAN Iu mode. At this point both uplink and downlink user data is transmitted via the
following: Bearer(s) between UE and source eNodeB, GTP tunnel(s) between source eNodeB,
Serving GW and PDN GW.
2.
The source eNodeB sends a Handover Required (S1AP Cause, Target RNC Identifier, Source
eNodeB Identifier, Source to Target Transparent Container) message to the source MME to
request the CN to establish resources in the target RNC, target SGSN and the Serving GW.
The bearers that will be subject to data forwarding (if any) are identified by the target SGSN in
a later step (see step 7 below).
Page 75 of 102
PDN GW
3.
The source MME determines from the 'Target RNC Identifier' IE that the type of handover is
IRAT Handover to UTRAN Iu mode. The Source MME initiates the Handover resource
allocation procedure by sending a Forward Relocation Request (IMSI, Target Identification,
MM Context, PDN Connections, MME Tunnel Endpoint Identifier for Control Plane, MME
Address for Control plane, RAN Cause,) message to the target SGSN. This message includes
all PDN Connections active in the source system and for each PDN Connection includes the
associated APN, the address and the uplink Tunnel endpoint parameters of the Serving GW for
control plane, and a list of EPS Bearer Contexts. RAN Cause indicates the S1AP Cause as
received from source eNodeB.
5.
The target SGSN requests the target RNC to establish the radio network resources (RABs) by
sending the message Relocation Request (UE Identifier, Cause, RAB to be setup list).
5a.
The target RNC allocates the resources and returns the applicable parameters to the target
SGSN in the message Relocation Request Acknowledge (RABs setup list).
Upon sending the Relocation Request Acknowledge message the target RNC shall be prepared
to receive downlink GTP PDUs from the Serving GW. Each RAB to be setup is defined by a
Transport Layer Address, which is the target RNC Address for user data, and the Iu Transport
Association, which corresponds to the downlink Tunnel Endpoint Identifier for user data.
7.
The target SGSN sends the message Forward Relocation Response (Cause, SGSN Tunnel
Endpoint Identifier for Control Plane, SGSN Address for Control Plane, Cause, RAB Setup
Information, Additional RAB Setup Information, Address(es) and TEID(s) for User Traffic
Data Forwarding) to the source MME.
The IE 'Address(es) and TEID(s) for User Traffic Data Forwarding' defines the destination
tunnelling endpoint for data forwarding in target system, and it is set as follows:
If 'Direct Forwarding' apply, then the IE 'Address(es) and TEID(s) for User Traffic Data
Forwarding' contains the address and DL GTP-U tunnel endpoint parameters to the Target
RNC received in step 5a.
7.5.7.5.2 Execution phase

The source eNodeB continues to receive downlink and uplink user plane PDUs.
1.
The source MME completes the preparation phase towards source eNodeB by sending the
message Handover Command (Bearers Subject to Data Forwarding List). The "Bearers Subject
to Data forwarding list" IE may be included in the message and it shall be a list of 'Address(es)
and TEID(s) for user traffic data forwarding' received from target side in the preparation phase
(Step 7 of the preparation phase) when 'Direct Forwarding' applies.
The source eNodeB initiates data forwarding for bearers specified in the "Bearers Subject to
Data Forwarding List". The data forwarding may go directly to target RNC.
2.
The source eNodeB will give a command to the UE to handover to the target access network
via the message HO from E-UTRAN Command.
4.
The UE moves to the target UTRAN Iu (3G) system and executes the handover according to
the parameters provided in the message delivered in step 2.
When the new source RNC-ID is successfully exchanged with the UE, the target RNC shall
send the Relocation Complete message to the target SGSN. The purpose of the Relocation
Complete procedure is to indicate by the target RNC the completion of the relocation from the
source E-UTRAN to the RNC. After the reception of the Relocation Complete message the
target SGSN shall be prepared to receive data from the target RNC. Each uplink N-PDU
received by the target SGSN is forwarded directly to the Serving GW.
5.
Page 76 of 102
6.
Then the target SGSN knows that the UE has arrived to the target side and target SGSN
informs the source MME by sending the Forward Relocation Complete message.
A timer in source MME is started to supervise when resources in Source eNodeB shall be
released. When the timer expires, the source MME releases all bearer resources of the UE.
The MME replies with the Forward Relocation Complete Acknowledge message.
Source
eNodeB
UE
Target RNC
Source MME
Target
Serving GW PDN GW
Target SGSN
Uplink and Downlink User Plane PDUs

1. Handover Command
2. HO from- E-UTRAN Command
4. UTRAN Iu Access Procedures
4a. Handover to UTRAN Complete
Sending of
uplink data
possible
Downlink User Plane PDUs

If Direct Forwarding applies
5. Relocation Complete
6. Forward Relocation Complete
6a. Forward Relocation Complete Acknowledge
8a. Update Bearer Response
11b. Release Resources
Figure 41: E-UTRAN to UTRAN Iu mode Inter RAT HO, execution phase
7.
The target SGSN will now complete the Handover procedure by informing the Serving GW
that the target SGSN is now responsible for all the EPS Bearer Contexts the UE has
established. This is performed in the message Update Bearer Request (SGSN Tunnel Endpoint
Identifier for Control Plane, SGSN Address for Control Plane, RNC Address(es) and TEID(s)
for User Traffic for the accepted EPS bearers (in case Direct Tunnel is used), PDN GW
addresses and TEIDs (for GTP-based S5/S8)).
8.
The Serving GW may inform the PDN GW the change of for example for the RAT type that
e.g. can be used for charging, by sending the message Update Bearer Request. The PDN GW
must acknowledge the request with the message Update Bearer Response.
Page 77 of 102
9.
The Serving GW acknowledges the user plane switch to the target SGSN via the message
Update Bearer Response (Cause, Serving GW Tunnel Endpoint Identifier for Control Plane,
Serving GW Address for Control Plane, Protocol Configuration Options, PDN GW addresses
and TEIDs (for GTP-based S5/S8)).
At this stage the user plane path is established for all EPS Bearer contexts between the UE,
target RNC, Serving GW and PDN GW.
If the Serving GW does not change, the Serving GW shall send one or more "end marker"
packets on the old path immediately after switching the path.
11.
When the timer started at step 6 expires, the source MME sends a Release Resources message
to the Source eNodeB. The Source eNodeB releases its resources related to the UE.
7.5.7.6 Handover from HSPA to LTE

Here handovers are carried using direct forwarding. No SGW change is assumed.
The handover is divided into two phases: a preparation phase and an execution phase [2].
7.5.7.6.1 Preparation phase

UE
Source RNC
Target eNodeB
Source SGSN
Target MME
SGW
PGW

1. Handover Initiation
2. Relocation Required
3. Forward Relocation Request
5. Handover Request
5a. Handover Request Acknowledge
7. Forward Relocation Response

8a. Create Bearer Response
Figure 42: UTRAN Iu mode to E-UTRAN Inter RAT HO, preparation phase
1.
The source RNC decides to initiate an Inter-RAT handover to the E-UTRAN. At this point
both uplink and downlink user data is transmitted via the following: Bearers between UE and
source RNC, GTP tunnel(s) between source RNC, Serving GW and PDN GW.
2.
The source RNC sends a Relocation Required (Cause, Target eNodeB Identifier, Source RNC
Identifier) message to the source SGSN to request the CN to establish resources in the target
eNodeB, Target MME and the Serving GW. The bearers that will be subject to data forwarding
(if any) are identified by the target MME in a later step (see step 7 below).
Page 78 of 102
3.
The source SGSN determines from the 'Target eNodeB Identifier' IE that the type of handover
is IRAT Handover to E-UTRAN. The Source SGSN initiates the Handover resource allocation
procedure by sending Forward Relocation Request (IMSI, Target Identification, MM Context,
PDN Connections, SGSN Tunnel Endpoint Identifier for Control Plane, SGSN Address for
Control plane, RAN Cause) message to the target MME.
This message includes all PDN Connections active in the source system and for each PDN
Connection includes the associated APN, the address and the uplink tunnel endpoint
parameters of the Serving GW for control plane, and a list of EPS Bearer Contexts.
5.
5a.
7.
The target MME requests the target eNodeB to establish the bearer(s) by sending the message
Handover Request (UE Identifier, S1AP Cause, EPS Bearers to be setup list). S1AP Cause
indicates the RAN Cause as received from source SGSN.
For each EPS bearer requested to be established, 'EPS Bearers To Be Setup' IE shall contain
information such as ID, bearer parameters, Transport Layer Address, "Data forwarding not
possible" indication, and S1 Transport Association.
The target eNodeB allocates the requested resources and returns the applicable parameters to
the target MME in the message Handover Request Acknowledge (Target to Source EPS
Bearers setup list).
Upon sending the Handover Request Acknowledge message the target eNodeB shall be
prepared to receive downlink GTP PDUs from the Serving GW for the accepted EPS bearers.
The target MME sends the message Forward Relocation Response (Cause, List of Set Up
RABs, MME Tunnel Endpoint Identifier for Control Plane, Cause, MME Address for control
plane, Address(es) and TEID(s) for Data Forwarding) to the source SGSN.
The IE 'Address(es) and TEID(s) for User Traffic Data Forwarding' defines the destination
tunnelling endpoint for data forwarding in target system, and it is set as follows:
If 'Direct Forwarding' applies, then the IEs 'Address(es) and TEID(s) for Data Forwarding'
contains the forwarding DL GTP-U tunnel endpoint parameters to the eNodeB received in
step 5a.
7.5.7.6.2 Execution phase

The source RNC continues to receive downlink and uplink user plane PDUs.
1.
The source SGSN completes the preparation phase towards source RNC by sending the
message Relocation Command (RABs Subject to Data Forwarding List). The "RABs Subject
to Data forwarding list" IE may be included in the message and it shall be a list of 'Address(es)
and TEID(s) for user traffic data forwarding' received from target side in step 7 of the
preparation phase when 'Direct Forwarding' applies.
2.
The source RNC will send a command to the UE to handover to the target eNodeB via the
message HO from UTRAN Command.
The source RNC may initiate data forwarding for the indicated RABs/EPS Bearer contexts
specified in the "RABs Subject to Data Forwarding List". The data forwarding may go directly
to target eNodeB.
Upon the reception of the HO from UTRAN Command message containing the Relocation
Command message, the UE shall associate its RAB IDs to the respective bearers ID and shall
suspend the uplink transmission of the user plane data.
4.
The UE moves to the E-UTRAN and performs access procedures toward target eNodeB.
5.
When the UE has got access to target eNodeB it sends the message HO to E-UTRAN
Complete.
Page 79 of 102
6.
When the UE has successfully accessed the target eNodeB, the target eNodeB informs the
target MME by sending the message Handover Notify.
7.
Then the target MME knows that the UE has arrived to the target side and target MME informs
the source SGSN by sending the Forward Relocation Complete message.
UE
Source
RNC
Target
eNodeB
Source SGSN
Target
Serving GW
Target MME
PDN
GW

1. Relocation Command
2. HO from UTRAN Command
4. E-UTRAN Access Procedures

5. HO to E-UTRAN Complete
Downlink Payload User Plane PDUs
Sending of
uplink data
possible
If Direct Forwarding applies

6. Handover Notify
7. Forward Relocation Complete
7a. Forward Relocation Complete Acknowledge
9a. Update Bearer Response
12b. Iu Release Procedure
Figure 43: UTRAN Iu mode to E-UTRAN Inter RAT HO, execution phase
The source SGSN shall also acknowledge that information. A timer in source SGSN is started
to supervise when resources in the in Source RNC shall be released.
8.
The target MME will now complete the Inter-RAT Handover procedure by informing the
Serving GW that the target MME is now responsible for all the bearers the UE have
established. This is performed in the message Update Bearer Request (Cause, MME Tunnel
Endpoint Identifier for Control Plane, EPS Bearer ID, MME Address for Control Plane, PDN
GW addresses and TEIDs (for GTP-based S5/S8)).
9.
The Serving GW may inform the PDN GW the change of for example the RAT type that e.g.
can be used for charging, by sending the message Update Bearer Request.
Page 80 of 102
The PDN GW must acknowledge the request with the message Update Bearer Response.
10.
The Serving GW acknowledges the user plane switch to the target MME via the message
Update Bearer Response (Cause, Serving GW Tunnel Endpoint Identifier for Control Plane,
Serving GW Address for Control Plane, Protocol Configuration Options, and PDN GW
addresses and TEIDs (for GTP-based S5/S8)).
At this stage the user plane path is established for all bearers between the UE, target eNodeB,
Serving GW and PDN GW. If the Serving GW does not change, the Serving GW shall send
one or more "end marker" packets on the old path immediately after switching the path in order
to assist the reordering function in the target eNodeB.
12.
When the timer started in step 7 expires the source SGSN will clean-up all its resources
towards source RNC by performing the Iu Release procedures. When there is no longer any
need for the RNC to forward data, the source RNC responds with an Iu Release Complete
message.
7.6. Data Storage

7.6.1. Serving GW
The Serving GW maintains the following EPS bearer context information for UEs. The table below
shows the context fields for one UE.
Table 50: SGW EPS bearer context
Field
IMSI
MSISDN
Description
IMSI (International Mobile Subscriber Identity) is the
subscriber permanent identity.
MME TEID for S11
The basic MSISDN of the UE. The presence is

dictated by its storage in the HSS.
Selected core network operator identity (to support
network sharing as defined in TS 23.251 [24]).
MME Tunnel Endpoint Identifier for the S11 interface
MME IP address for S11
MME IP address the S11 interface.
SGW TEID for S11/S4

(control plane)
SGW Tunnel Endpoint Identifier for the S11 Interface

and the S4 Interface (control plane).
SGW IP address for S11/S4

(control plane)
SGW IP address for the S11 interface and the S4

Interface (control plane).
SGSN IP address for S4

(control plane)
SGSN TEID for S4 (control
plane)
Trace reference
SGSN IP address for the S4 interface (Used by the

S-GW).
SGSN Tunnel Endpoint Identifier for the S4 interface.
Selected CN operator id
Trace type
Trigger id
OMC identity
Get value from:

create_session_req
received from MME
create_session_req
received from MME
create_session_req
received from MME
generate locally when
create_session_res
received from PGW
get locally from
configuration when
create_session_res
received from PGW
create_session_req
received from MME
create_session_req
received from MME
Identifies a record or a collection of records for a

particular trace.
Indicates the type of trace
Identifies the entity that initiated the trace
Identifies the OMC that shall receive the trace
record(s).
For each PDN Connection:

NOTE:
The following entries are repeated for each PDN.
APN in Use
The APN currently used. This APN shall be
composed of the APN Network Identifier and the
APN Operator Identifier.
create_session_req
received from MME
Page 81 of 102
Field
P-GW Address in Use
(control plane)
P-GW TEID for S5/S8
(control plane)
S-GW IP address for S5/S8
(control plane)
Description
The IP address of the P-GW currently used for
sending control plane signalling.
P-GW Tunnel Endpoint Identifier for the S5/S8
interface for the control plane.
S-GW IP address for the S5/S8 for the control plane
signalling.
S-GW TEID for S5/S8

(control plane)
S-GW Tunnel Endpoint Identifier for the S5/S8

control plane interface.
Get value from:

create_session_req
received from MME
create_session_res
received from PGW
get locally from
configuration when
create_session_req
received from MME
create_session_req
received from MME
APN Restriction
Denotes the restriction on the combination of types of

APN for the APN associated with this EPS bearer
Context.
For each EPS Bearer within the PDN Connection:
NOTE: The following entries defining the EPS Bearer specific parameters are included within the set of
parameters defining the PDN Connection.
EPS Bearer Id
An EPS bearer identity uniquely identifies an EPS
create_session_req
bearer for one UE accessing via E-UTRAN
received from MME
UL TFT
Uplink Traffic Flow Template
DL TFT
Downlink Traffic Flow Template
P-GW Address in Use (user
The IP address of the P-GW currently used for
create_session_res
plane)
sending user plane traffic.
received from PGW
P-GW TEID for S5/S8 (user
create_session_res
plane)
interface for the user plane.
received from PGW
S-GW IP address for S5/S8
S-GW IP address for user plane data received from
get locally from
(user plane)
PDN GW.
configuration when
create_session_req
received from MME
S-GW TEID for S5/S8 (user
S-GW Tunnel Endpoint Identifier for the GTP Based
plane)
S5/S8 interface for user plane.
create_session_req
received from MME
S-GW IP address for S1-u
S-GW IP address for the S1-u interface (Used by the
get locally from
eNodeB)
configuration when
create_session_req
received from MME
S-GW TEID for S1-u
S-GW Tunnel Endpoint Identifier for the S1-u
interface.
create_session_req
received from MME
eNodeB IP address for S1-u eNodeB IP address for the S1-u interface (Used by
Modify_bearer_req
the S-GW).
received from MME
eNodeB TEID for S1-u
eNodeB Tunnel Endpoint Identifier for the S1-u
Modify_bearer_req
interface.
received from MME
S-GW IP address for S12
S-GW IP address for the S12 interface (Used by the
get locally from
RNC)
configuration when
create_session_req
received from MME
S-GW TEID for S12
S-GW Tunnel Endpoint Identifier for the S12
get locally from
interface.
configuration when
create_session_req
received from MME
RNC IP address for S12
RNC IP address for the S12 interface (Used by the
Modify_bearer_req
S-GW).
received from MME
Page 82 of 102
Field
RNC TEID for S12
Description
RNC Tunnel Endpoint Identifier for the S12 interface.

(user plane)
S-GW TEID for S4 (user
plane)
SGSN IP address for S4
(user plane)
SGSN TEID for S4 (user
plane)
EPS Bearer QoS Profile
Charging Id
S-GW IP address for the S4 interface (Used by the

SGSN)
S-GW Tunnel Endpoint Identifier for the S4 interface.
Charging Characteristics
Get value from:

Modify_bearer_req
received from MME
SGSN IP address for the S4 interface (Used by the

S-GW).
SGSN Tunnel Endpoint Identifier for the S4 interface.
ARP, GBR, MBR, QCI.
Charging identifier, identifies charging records
generated by S-GW and PDN GW.
Normal, prepaid, flat rate and/or hot billing
7.6.2. PDN GW
The PDN GW maintains the following EPS bearer context information for UEs. The table below
Table 51: PGW context
Field
Description
Get value from:
IMSI

subscriber permanent identity.
create_session_req
received from SGW
MSISDN

Selected core network operator identity (to support
network sharing as defined in TS 23.251 [24]).
Current RAT
RAT type
Trace reference
Trace type
Trigger id
OMC identity
create_session_req
received from SGW
Identifies a record or a collection of records for a

particular trace.
Indicates the type of trace
Identifies the entity that initiated the trace
Identifies the OMC that shall receive the trace
record(s).
For each APN in use:

NOTE:
The following entries are repeated for each APN.
APN in use
The APN currently used. The APN shall be
APN-AMBR
The APN-AMBR for this APN.
create_session_req
received from SGW
For each PDN Connection within the APN:

NOTE:
The following entries are repeated for each PDN connection within the APN.
IP Address(es)
IPv4 address and/or IPv6 address
PDN type
S-GW Address in Use
(control plane)
S-GW TEID for S5/S8
(control plane)
P-GW IP address for
S5/S8 (control plane)
IPv4, IPv6, or IPv4v6

The IP address of the S-GW currently used for
interface for the control plane.
P-GW IP address for the S5/S8 for the control plane
signalling.
P-GW TEID for S5/S8

(control plane)

control plane interface.
SGSN support for

CGI/SAI/RAI change
reporting
Indicated that the SGSN serving the UE supports

procedures for reporting CGI/SAI/RAI changes
(according to 23.060 [7] clause 15.1.1a).
get locally from database

when create_session_req
received from SGW
create_session_req
received from SGW
create_session_req
received from SGW
get locally from
configuration when
create_session_req
received from SGW
create_session_req
received from SGW
Page 83 of 102
CGI/SAI/RAI change
report required
BCM
Denotes whether the SGSN is requested to send

changes in CGI/SAI or RAI for this bearer
The negotiated Bearer Control Mode for
GERAN/UTRAN.
For each EPS Bearer within the PDN Connection:
NOTE:
The following entries defining the EPS Bearer specific parameters are included within the
set of parameters defining the PDN Connection.
EPS Bearer Id
create_session_req
received from SGW
UL TFT
Uplink Traffic Flow Template
DL TFT
Downlink Traffic Flow Template
S-GW Address in Use
The IP address of the S-GW currently used for
create_session_req
(user plane)
sending user plane traffic.
received from SGW
S-GW TEID for S5/S8
create_session_req
(user plane)
interface for the user plane.
received from SGW
P-GW IP address for
P-GW IP address for user plane data received from
get locally from
S5/S8 (user plane)
PDN GW.
configuration when
create_session_req
received from SGW
P-GW TEID for S5/S8
P-GW Tunnel Endpoint Identifier for the GTP Based
(user plane)
S5/S8 interface for user plane.
create_session_req
received from SGW
EPS Bearer QoS Profile
ARP, GBR, MBR, QCI.
Charging Id
generated by S-GW and PDN GW.
Charging Characteristics
Normal, prepaid, flat rate and/or hot billing
7.6.3. MME
The MME maintains MM context and EPS bearer context information for UEs. The table below
Table 52: MME MM and EPS bearer Contexts
Field
Description
IMSI
IMSI (International Mobile Subscriber Identity) is

the subscribers permanent identity.
MSISDN

Mobility management state ECM-IDLE, ECMCONNECTED, EMM-DEREGISTERED.
Globally Unique Temporary Identity.
Mobile Equipment Identity (e.g. IMEI/IMEISV)
Software Version Number
Current Tracking area list
Last known cell
Time elapsed since the last Cell Global Identity
was acquired
Temporary authentication and key agreement
data that enables an MME to engage in AKA with
a particular user. An EPS Authentication Vector
consists of four elements:
a) network challenge RAND,
b) an expected response XRES,
c) Key KASME,
d) a network authentication token AUTN.
UE radio access capabilities.
MM State
GUTI
ME Identity
Tracking Area List
Cell Global Identity
Cell Identity Age
Authentication Vector
UE Radio Access
Capability
UE Network Capability
Selected NAS Algorithm

Selected AS Algorithm
KSIASME
KASME
Get value from:

get from Attach Req received
from UE
not really used
UE network capabilities including security

algorithms and key derivation functions supported
by the UE
Selected NAS security algorithm
Selected AS security algorithms.
Key Set Identifier for the main key KASME
Main key for E-UTRAN key hierarchy based on
CK, IK and Serving network identity
Page 84 of 102
Field
NAS Keys and COUNT
Recovery
Access Restriction
ODB for PS parameters
MME IP address for S11
MME TEID for S11
S-GW TEID for S11
eNodeB Address in Use
eNB UE S1AP ID
MME UE S1AP ID
APN Restriction
Description
KNASint, K_NASenc, and NAS COUNT parameter.
Selected core network operator identity (to
support network sharing as defined in
TS 23.251 [24]).
Indicates if the HSS is performing database
recovery.
The access restriction subscription information.
Indicates that the status of the operator
determined barring for packet oriented services.
MME IP address for the S11 interface (used by SGW)
MME Tunnel Endpoint Identifier for S11 interface.
S-GW IP address for the S11 interface (used by
MME)
S-GW Tunnel Endpoint Identifier for the S11
interface.
The IP address of the eNodeB currently used.
Unique identity of the UE over the S1 interface
within eNodeB.
Unique identity of the UE over the S1 interface
within MME.
Get value from:
get locally from config when

Attach Req received from UE
generate randomly when
Attach Req received from UE
SGW Selection Function in
MME
from create_session_res
received from SGW
S1-AP procedure with eNB
Denotes the restriction on the combination of

types of APN for the APN associated with this
EPS bearer Context.
e.g. Normal, prepaid, flat rate and/or hot billing.
Subscribed Charging
Characteristics
For each active PDN connection:
APN in Use
The APN currently used. This APN shall be
APN Subscribed
The subscribed APN received from the HSS.
IP Address(es)
IPv4 and/or IPv6 address(es)
Specifies whether the UE is allowed to use the
APN in the domain of the HPLMN only, or
additionally the APN in the domain of the VPLMN.
PDN GW Address in Use
The IP address of the PDN GW currently used for
(control plane)
Location Change Report
Need to communicate Cell or TAI to the PDN GW
Required
with this EPS bearer Context.
EPS subscribed QoS
The bearer level QoS parameter values for that
profile
APN's default bearer (QCI and ARP) and that
APN's AMBR (see clause 4.7.3).
PDN GW GRE Key for
PDN GW assigned GRE Key for the S5/S8
uplink traffic (user plane)
interface for the user plane for uplink traffic. (For
PMIP-based S5/S8 only)
For each EPS Bearer within the PDN connection:
EPS Bearer ID
currently just a string set by

MME
create_session_res received
from SGW
VPLMN Address Allowed
IP address for S1-u

TEID for S1u
EPS bearer QoS
parameters
EPS Bearer Charging
Characteristics
Charging Id
DL TFT
UL TFT
IP address of the S-GW for the S1-u interfaces.

Tunnel Endpoint Identifier of the S-GW for the S1u interface.
QCI and ARP
optionally: GBR and MBR in case of GBR bearer
PGW Selection function in

MME
unique id generated locally in

MME when Attach Req
received from UE
S1-AP proc with eNB
S1-AP proc with eNB
e.g. Normal, prepaid, flat-rate and/or hot billing.

generated by SGW and PDN GW.
Downlink Traffic Flow Template. (For PMIP-based
S5/S8 only)
Uplink Traffic Flow Template. (For PMIP-based
S5/S8 only)
Page 85 of 102
7.6.4. SGSN
A data structure similar to that of the MME is maintained at the SGSN.
7.6.5. eNB and RNC

The eNodeB also maintains simple UE context structures, containing the SGW IP and TEID
for S1-u interface and the IP and TEID of the eNodeB for the same interface, in addition to
some information that helps map the data packets to corresponding bearers.
Similarly, the RNC has UE contexts containing the SGW IP and TEID for S12 interface and
the IP and TEID of the RNC for the same interface.
7.6.6. UE
The UE maintains the following context information shown in the table below. A GERAN or
UTRAN capable UE maintains in addition the context information as described in a similar UE
context table in TS 23.060 [22].
Table 53: UE context
Field
IMSI
Description
subscribers permanent identity.
The basic MSISDN of the UE.

Mobility management state EMM-REGISTERED,
EMM-DEREGISTERED.
GUTI
Globally Unique Temporary Identity.
ME Identity
Mobile Equipment Identity (e.g. IMEI/IMEISV)
Software Version Number.
Tracking Area List
Current Tracking area list.
last visited TAI
A TAI which is contained in the TA list the UE
registered to the network and which identifies the
tracking area last visited by the UE.
Selected NAS Algorithm
Selected NAS security algorithm.
Selected AS Algorithm
Selected AS security algorithms.
KSIASME
Key Set Identifier for the main key KASME.
Main key for E-UTRAN key hierarchy based on CK, IK
KASME
and Serving network identity.
NAS Keys and COUNT
KNASint, KNASenc, and NAS COUNT parameter.
Temporary Identity used
This parameter is used internally by the UE to
in Next update (TIN)
memorise which temporary ID it has to indicate in the
next RAU/TAU (P-TMSI, GUTI or RAT-related TMSI,
the latter means P-TMSI in RAU and GUTI in TAU).
For each active PDN connection:
APN in Use
The APN currently used. This APN shall be composed
of the APN Network Identifier and the APN Operator
Identifier.
IP Address(es)
IPv4 and/or IPv6 address(es).
For each EPS Bearer within the PDN connection
EPS Bearer ID
bearer for one UE accessing via E-UTRAN.
EPS bearer QoS
GBR and MBR in case of GBR bearer.
parameters
UL TFT
Uplink Traffic Flow Template.
Get value from:
MSISDN
EMM State
Page 86 of 102
8. Testbed Installation and Configuration

This chapter provides a description of the testbed, the software and hardware requirements, and the
installation procedure for the different nodes in the network.
In the current setup, the nodes are arranged as follows:
RealNeS LTE runs on one machine.
RealNeS WiMAX runs on one machine.
RealNeS HSPA runs on one machine.
The MME, SGW and PGW run on the same machine.
An external UE runs on one machine.
Figure 44 describes the network from a hardware point of view.
RealNeS LTE
Switch
Switch
External
RealNeS HSPA
Terminal
- MME
- SGW
- PGW
Switch
sgi
RealNeS WiMAX
Figure 44: Network Hardware with dynamic IP assignment for UE
8.1. Hardware Requirements

To insure Real-time operation for the LTE, HSPA and WiMAX emulators, it is recommended that
the host computers have the following minimum requirements:
z Dual core processor with 1.66 GHz each.
z 1 GB of memory (RAM)
The computers hosting LTE, HSPA and WiMAX should have 3 network interfaces each, while the
machine hosting the GWs/MME should have 2. The computer used as the external UE should have
also 2 interfaces.
Three LAN switches are needed. Two connect the external UE to LTE, HSPA and WiMAX
machines. The third connects the GWs/MME machine to LTE and WiMAX.
Thirteen LAN cables are needed. Nine cables are used to connect the switches to LTE, HSPA and
WiMAX computers.
Two cables connect two switches to the external UE. Another connects the third switch to the
gateway computer. One is used for the SGi to connect the gateway to some external LAN.
Page 87 of 102
8.2. Software Requirements

The computers hosting LTE, HSPA, WiMAX and the GWs/MME should have a standard Suse 10.2
or 10.3 installations.
The LTE, HSPA and WiMAX machines require ns-2.29.3 installed in /opt. The WiMAX machine
also needs mysqlclient package to be installed.
The 3 machines also should have %wheel ALL=(ALL) NOPASSWD:ALL enabled
(uncommented) in /etc/sudoers. In addition, the user account from which LTE, HSPA and WiMAX
are run should be a member of the goup wheel.
The GWs/MME machine requires, in addition to mysql (server/client), the following libraries:
z libnfnetlink-0.0.39
z
libnetfilter_queue-0.0.16
libnet
Please check section 8.4, for more installation details.
8.3. Network Configuration

For the platform to work, the following configurations should be used. Please pay special attention
for the network interface names (whether eth0 or eth1).
Figure 45 summarizes the network address configurations.
eth2 192.168.0.125
neatbox LTE
Eth1: Used
for Control
msg
eth0
192.168.3.11
eth1 192.168.1.11
192.168.0.123
eth1
eth2 192.168.0.122
- MME
External
neatbox HSPA
Terminal
eth0
Switch
eth1 192.168.1.12
eth0
Switch
eth0
192.168.3.12
192.168.3.13
eth1
- SGW
SGi
- PGW
P
d
eth2 192.168.0.124
neatbox WiMAX
eth0
eth1 192.168.1.10
192.168.3.10
Figure 45: Network address configurations (dynamic IP)
Page 88 of 102
The SGi interface can be connected to local LAN and can be configured with DHCP or simply with
static IP address.
On the External Terminal, in addition to specifying the IP address, the DNS server must also be
specified inorder to be able to use URLs with a browser.
8.4. Installation
8.4.1. RealNeS LTE
The RealNeS LTE needs to be installed by using the corresponding DVD provided. Insert the DVD
into the DVD-ROM. Open a Console Window and change to the DVD directory. Type and execute
the command sh ./install_lte.sh vx.y.z where the vx.y.z field is indicated on the DVD.
8.4.2. RealNeS HSPA

The RealNeS HSPA needs to be installed by using the corresponding DVD provided. Insert the DVD
into the DVD-ROM. Open a Console Window and change to the DVD directory. Type and execute
the command ./install_hspa.sh vx.y.z where the vx.y.z field is indicated on the DVD.
8.4.3. RealNeS WiMAX

The RealNeS WiMAX needs to be installed by using the corresponding DVD provided. Insert the
DVD into the DVD-ROM. Open a Console Window and change to the DVD directory. Type and
execute the command ./install_wimax.sh vx.y.z where the vx.y.z field is indicated on the DVD.
8.4.4. MME, Serving Gateway and PDN Gateway

In order to install the MME, Serving Gateway and PDN Gateway, you need the corresponding DVD
provided. Insert the DVD into the DVD-ROM. Open a Console Window and change to the DVD
directory.
Type and execute the following commands:
./install_mme.sh vx.y.z where the vx.y.z field is indicated on the DVD.
./install_s_gw.sh vx.y.z where the vx.y.z field is indicated on the DVD.
./install_p_gw.sh vx.y.z where the vx.y.z field is indicated on the DVD.
Copy the script start_gw_mme_vx.y.z.sh to the home directory (same directory where the MME,
P-GW and S-GW were installed), and replace the x, y and z fields in the script name with the current
version number. This script is used to run the 3 nodes together. Note that if the name of the script is
not correct, it will not work.
Copy the file Control_GUI.jar and place it in the home directory. This is the binary for the
common gui that controls the live user in all 3 systems.
The file log_mod is the binary for the logging utility and should be copied to the home directory as
well.
Enable IPforwarding from linux settings.
Also the file cache.sql needs to be copied. With mysql server running on the GWs/MME machine,
import the database file cache.sql. The following steps are needed:
First run: mysql uroot
Then create an empty database cache with: create database cache; command
If the database already exists, delete it with: drop database cache; command
Now from another console, change to directory where you copied the cache.sql file and import the
database with: mysql uroot cache < cache.sql
Page 89 of 102
From mysql, run: use cache
And then run: grant select on useCases to root@192.168.3.10;
The IP address 192.168.3.10 is the one corresponding to the WiMAX machine.
8.4.5. External Terminal

To install the external terminal insert the DVD into the DVD-ROM, then open a Console Window
and change to the DVD directory.
Type and execute the following commands:
./install_ue.sh vx.y.z where the vx.y.z field is indicated on the DVD.
Before running the application, two files should be created inside the folder where the binary files
are. On the terminal, go to the corresponding directory and type while root:
mkfifo pipein then mkfifo pipeout.
8.4.6. Libraries
The following libraries should also be installed on the machine hosting the GWs/MME:
mysql (client and server) package
libnet library
libnfnetlink-0.0.39 library
libnetfilter_queue-0.0.16 library
Please make sure that the library in step 3 is always installed before installing the library in step 4.
The machine running WiMAX needs ns-2.29.3 installed in /opt and mysqlclient package, while the
machines running LTE and HSPA only need ns-2.29.3 installed in /opt.
Page 90 of 102
9. Testbed Operation
The general rule when operating the testbed is to first start the 3 emulators LTE, HSPA and WiMAX
and wait till they are running, then run the MME, SGW and PGW as well as the common GUI and
finally start the UE.
9.1. LTE
In order to run the LTE emulator, a licence is required. After having installed the LTE emulator, copy
the file license.nmr (provided by Nomor) to the lte_vx.y.z/license folder found inside the home
folder. This has to be done only once prior to the first use of the software.
To start the emulator, open a new console window, change to lte_vx.y.z and type ./dialog . A
dialog window will open. All the available scenarios are listed on this window. Select a scenario and
click OK. The LTE emulator will start operating.
A shortcut to start the dialog window will be also available on the Desktop after the installation.
9.2. HSPA
In order to run the HSPA emulator, a licence is required. After having installed the HSPA emulator,
copy the file license.nmr (provided by Nomor) to the hspa_vx.y.z/license folder found inside the
home folder. This has to be done only once prior to the first use of the software.
To start the emulator, open a new console window, change to hspa_vx.y.z and type ./dialog . A
click OK. The HSPA emulator will start operating.
9.3. WiMAX
In order to run the WiMAX emulator, a licence is required. After having installed the WiMAX
emulator, copy the file license.nmr (provided by Nomor) to the wimax_vx.y.z/license folder found
inside the installation folder. This has to be done only once prior to the first use of the software.
To start the emulator, open a new console window, change to wimax_vx.y.z and type ./start. A
click OK. The WiMAX emulator will start operating.
9.4. MME, S-GW and P-GW

The MME, S-GW and P-GW are located on the same machine. Those can be run together using the
script start_gw_mme.sh. Depending on the machine setup, the paths specified in the script might
need to be updated.
The advantage of the script is that it checks whether the machine has a dual core processor. If so, it
executes the P-GW on one core, the S-GW and the MME on the other. The script runs each node in a
separate console, so to kill the nodes just close the windows opened.
If the nodes need to be restarted, it is enough to rerun the script even without killing the existing
nodes. The following describes how to run each node separately plus some additional directions for
the P-GW.
Page 91 of 102
9.4.1. MME
Open a new console window and change to the folder where the mme file was copied. Type and
execute ./mme and the MME module will start operating.
9.4.2. Serving Gateway

Open a new console window and change to the folder where the s_gateway file was copied. Type and
execute ./s_gateway and the Serving Gateway module will start operating.
9.4.3. PDN Gateway

Open a new console window. Change to the folder where the p_gateway file was copied. Type and
execute as root ./p_gateway. The PDN Gateway module will start operating.
After the PDN Gateway has started operation, the console window shall be used to modify the use
cases for each network.
Four use cases when the UE is not able to attach to trusted non-3GPP Access (WiMAX) are
supported besides the normal one when the UE is able to attach. The use cases are inserted on a
database. The model for the database can be seen below.
Table 54: Part of the useCases table in Cache database
Column 0 Column 1
Column 2
Column 3
Column 4
ID
Network_Name IP Address
Status
Priority
LTE
192.168.3.11
WiMAX_1
192.168.3.10
HSPA
192.168.3.12
The first column of the table is the ID of the entry in the database. The second column includes the
name of the network. The third column includes the IP address assigned to the network. The fourth
column describes the use cases. The range for the fourth column is from 0 to 4 and the corresponding
use cases are:
If it is equal to 0 then the attach request is accepted.
If it is equal to 1 then an authorization failure occurs and attach is rejected with

PROXY_REG_NOT_ENABLE status field in the response message.
If it is equal to 2, attach is accepted but an unacceptable IP address is assigned to the UE,

therefore the UE detaches once it receives the accept response.
If it is equal to 3 then an IP address cannot be assigned by the LMA to the UE because of

operator policies, so the attach request is rejected with 130 status field in the response message.
If it is equal to 4 then the S2a link is congested and the attachment cannot take place. In case the
MAG is informed about congestion, it should reject the attachment from the UE immediately.
In order to modify the status field for an entry in the database, type the name of the network and the
new status number. For example in order to change the use case for WiMAX_1 to the third negative
use case, type in the console window of the PGW WiMAX_1 3 and press ENTER. The status field
in the database will be updated and the corresponding use case will be used.
Page 92 of 102
9.5. Common GUI

Each of the 3 emulators LTE, HSPA and WiMAX has its own GUI and information regarding,
among others, the mobile positions that are displayed in a cell visualization window.
The cell visualization window shows a cell (hexagon shape) with the base station at the left corner
and the mobiles positioned in or out of the cell. A snapshot of LTE emulator GUI is shown below
where on the lower left hand side a cell appears along with the mobiles connected to a base station.
Nine mobiles and one red mobile exist in the figure below. The red mobile in every emulator has
some particular importance which will be discussed shortly. Similar to LTE, the other two emulators
have their own GUIs.
Figure 46: Cell Visualization Window
In the SEA project, however, we are also interested in studying handovers, as the live user moves
geographically from one position to another. As the user changes position, the strength of the signals
received from different systems is supposed to vary and thus handovers are expected to occur as the
user will prefer better reception conditions.
In the testbed, therefore, it would be useful to view the cells of the 3 systems in the same GUI, and
for this purpose the Common GUI is implemented. The Common GUI shows all connected systems
together, and it allows us to configure the relative positions of the systems (cells) to each other. The
GUI also enables us to control the position of its live user (mobile icon with the dot in the middle).
This user corresponds to the users with red icons in the separate GUIs of the 3 systems, and it
corresponds to the external UE in the testbed.
This common GUI, which runs on the same machine as the MME and the gateways, combines the
cell visualization from the 3 systems in a common frame, and preserves the relative positions of the
users of each system, including the live user, relative to the base station of that system. The only
difference regarding the live user is that all 3 red icons in the individual GUIs of the systems are
represented by one single icon in the common GUI (icon with the dot in middle), and only this
user/icon can be controlled and moved in the common GUI.
From a connection point of view, each emulator in the system acts as a server, and the GUI as a
client. Complete system diagram is shown below.
Page 93 of 102
Figure 47: System Diagram for common GUI
The above shown system diagram can be divided into two parts, left and right. Left part contains all
the emulators or the servers whereas the right part has the GUI. Currently the system supports three
emulators (and all the three emulators must be running at the same time).
In the block diagram of the emulators, there are three sections; the first section shows a GUI view of
the emulator, the second section shows particular information that each emulator shares with the
GUI, and the third box shows the TCP/IP server which will connect the emulator with external
environment.
Similarly on the right hand side there is a box showing the common GUI, which also has three parts.
The first part is the GUI layout; the second part is the cache database located at the gateway
machine. Most of the information required by the common GUI is stored in this database, such as the
IP addresses of the emulators, the color selection for each technology and starting coordinates of the
cells. (Note that according to the current version, the GUI only supports three colors, which are
shown in the above diagram). The third part shows the TCP/IP client, which connects the GUI to the
emulators. The table below shows how the useCases database table, also used by the GUI, looks
like:
Table 55: useCases table in the cache database
id
network_name
ip_address
status
priority
color
x_origin
y_origin
Page 94 of 102
1
LTE
192.168.3.11
GREEN
80
160
WiMAX_1
192.168.3.10
BLUE
150
160
HSPA
192.168.3.12
MAGENTA
200
160
WiMAX_2
192.168.6.11
NULL
WiMAX_3
192.168.7.11
NULL
WiMAX_4
192.168.8.11
NULL
WiMAX_5
192.168.9.11
NULL
When the GUI is started, it tries to connect to the systems using the specified IP addresses. Since in
the current testbed, 3 systems exist, we use dummy IP addresses for the other systems. The x_origin
and y_origin are the coordinate for the cell center of each system in the common GUI.
9.5.1. Connection and Operation

The connection between the GUI and all the emulators is TCP/IP. The IP addresses of the emulators
are fetched from the database at the Gateway.
After all the emulators are running, start the GUI by executing the following command from a shell
script java jar Control_GUI.jar
where Control_GUI.jar is the name of the GUI executable copied from the DVD. Now the connection
will be established automatically and the GUI will appear on the screen.
9.5.2. GUI Functionality

After the connection has been established, the GUI will appear. In case the original frame size of GUI
is small, you can always resize the frame to make larger. The frame can be adjusted to any size, but it
is recommended that it has a square shape.
The GUI displays all the mobiles from the emulators. The UE with the red icon in all 3 emulators is
the Live UE (external UE) and in the common GUI it is represented by the icon with the red dot in
the monitor. So in order to trigger handovers (when the automatic mode is chosen for external UE as
described in section 9.6), it is enough to move the live user on the common GUI.
This live user can be controlled from common GUI or from the emulators, and it will have a relative
position. In other words if the position of the live user is changed from the common GUI then the
positions of all three red users in all the 3 emulators will change accordingly. Also as an example, if
the position of the red user is changed from LTE then both of the red users in HSPA and WiMAX
will be updated along with live user in the common GUI. Note that mobiles other than this can only
be changed by the emulators and not by the common GUI.
From the three figures below it can be seen that all the red mobiles in the emulators are in relative
positions with the live user and the circles in the common GUI.
Page 95 of 102
Figure 48: LTE Moblies
Figure 49: HSPA Mobiles
Figure 50: WiMAX Mobiles
Page 96 of 102
Figure 51: Common GUI Mobiles
The above figure shows three circles, Green for LTE cell, Blue for WiMAX cell and Magenta for
HSPA cell. The base-station for each system is located at the left edge of each circle. On the right
side of the LTE cell, there is a green mobile icon with a red dot, this is the live user. Again, the color
for each system is specified in the database table and the color of the live user (with the dot in the
middle) varies according to the system to which it is not connected to.
The position of the live user is relative to all the emulators. For example in Figure 48 of LTE GUI,
the red mobile is on the right sector of the cell, relatively close to the base station. As can be seen
from Figure 51, the live user is outside of the HSPA and WiMAX cells; hence no red user is seen
inside the cell of WiMAX in Figure 50 and that of HSPA in Figure 49.
On the lower left corner of Figure 51, there is a table which indicates the coordinates (X & Y) for the
center of each cell of the corresponding systems. Those can be modified to position the cells of the
different systems as required relative to each other.
The table also indicates the radius of each cell (circle). The radius is read from the emulator;
therefore it cannot be changed from the table.
The table also has a colored legend, which makes it easy to find which emulator has which color.
9.5.3. GUI UE Movements

Although the common GUI displays all of the mobiles of all the emulators, only the movement of the
live user can be controlled.
The position of other mobiles cannot be changed from the common GUI. If you try to move any of
the other mobiles then they will jump back to their former position, also the live user will turn black
Page 97 of 102
indicating that this movement is not allowed. The other mobiles can only be moved from the GUI of
their respective emulator.
The live user can be moved in two different ways:
you can drag drop the icon of the live user, i.e. left click on the icon, hold the mouse and drag
the icon to the new position.
The second method is quite useful for SEA demonstrations as it allows the live user to move
by itself to a desired location. This is very useful to demonstrate handovers as the user, for
example, moves away from one system closer to another one!
To do this, left click on the live user icon and then left click on any other point on the GUI where you
want the user to move to. The live user will start then moving slowly towards the new destination.
When it arrives, the GUI will automatically update along with all the emulators.
While dragging the live user you will notice two things, initial position and the current position. The
initial position of the live user is indicated by a red mobile and current position is indicated by a
black mobile. When dragging is complete and the red mobile position in all the emulators is updated,
then the live user will again turn back to its color depending on which system it is connected.
Note all the movements of the live user on the Gateway GUI are updated simultaneously in all the
connected emulators at run time.
9.5.4. Live User

As mentioned earlier, the live user in the common GUI corresponds to the red users of the emulators.
In addition to this the live user also indicates to which emulator it is currently connected. If the live
user is connected to LTE its color would be the color of the corresponding LTE with red dot in the
middle.
From the above figure it can be seen that live user is green in color with a red dot (since it is
connected to LTE). Similarly if the live user is connected to HSPA then its color would be magenta
with a red dot. Note that by changing the connectivity the position of the live user does not change.
The common GUI receives information from the PGW and SGW to know to which system the live
user is connected.
9.5.5. Trouble Shoot

Always make sure correct IP addresses of the emulators are specified in the gateway database, and
the GUI always requires that all the emulators are running before it is started.
9.6. External UE
To run the UE application, you can simply use the icon created on Desktop. As you click it, you will
be asked to enter the root password of your machine.
Alternatively, you can also run from command line. As root, execute ./ext_ue 1 0. Note that to
switch to root, do NOT use sudo su, rather use su and enter root password when asked.
The program will initialize and shortly afterwards the GUI, as shown below, will start.
Page 98 of 102
LTE Signal
Level
Threshold in
Threshold out
Sensitivity
WiMAX Signal
Level
Threshold in
Threshold out
Sensitivity
HSPA Signal
Level
Threshold in
Threshold out
Sensitivity
Automatic
Handover
Manual
Handover
ON/OFF Button
Apply Selection
Figure 52: External UE GUI
To start the application, press the ON/OFF Button.

After pressing the ON/OFF Button, the GUI starts to show the signal level of the Systems. The
Green bar shows the signal level for the system that the UE is currently connected to. Threshold IN
and Threshold OUT specify the signal levels considered in the handover decision in the Automatic
mode. Threshold IN is the level above which the signal is good and hence encourages the UE to HO
to the system while Threshold out is the level below which a handover should take place. The values
are expressed in percentage of the maximum signal.
The sensitivity also controls the handover. A high value makes the mobile unit more sensitive to
instantaneous signal variations which might lead to fast handovers. A low value places more
emphasis on the average of the past values, so fast signal variations will slowly affect the HO
decision.
Page 99 of 102
The Automatic HO enables the automatic handover decision. The access technology can also be
chosen manually by choosing an option from the dropdown menu. If Automatic HO is chosen the
selection from the dropdown menu is not effective.
In all the cases, it is necessary to press the Set button for the changes to take place, i.e., if some
parameters are changed or if the automatic handover is chosen, such changes will only take place if
the Set is pressed.
When the terminal is turned off, the terminal will be detached from the currently attached system. If it
is turned on again, it will only reconnect if the Automatic field is set, otherwise it will wait for a
manual handover command.
9.7. Message Logging

The logging utilities allows to show the control messages exchanged among the network nodes (UE,
LTE, HSPA, WiMAX, MME, S-GW and P-GW) during procedures like initial attach, detach and
handovers between the different RATs. Messages belong to different protocols like NAS, GTP,
PMIP, S1-AP, RANAP
To plot the exchanged messages, the utility make use of the Quick Sequence Diagram Editor
(QSDE), http://sdedit.sourceforge.net/index.html.
The QSDE server uses special syntax to plot the messages and needs a TCP connection to receive
such messages. Since our platform has multiple nodes that would log messages, we use a central
module, log_module, that is responsible for collecting messages from different nodes over UDP
sockets and building & sending the correct messages to the QSDE server.
In our setup, the QSDE server and the log_module both run on the GW machine. The log_module
has a text file to configure the IP addresses and TCP port for the QSDE server and IP address and the
UDP port on which it listens. The other nodes also have the IP address and UDP port specified in
their ip_config files in order to send the messages to the log_module.
To run the logging utility, first the QSDE server must be started. This is done by running the
following command:
java jar sdedit-3.0.5.jar
Where sdedit-3.0.5.jar is the QSDE application file downloaded from the link above. Note that the
machine hosting this needs java to be installed.
After running the application if the server doesnt start automatically, go to Extras in the tool menu
and start it from Start/stop RT server. It uses a default port of 60001.
Next run the log_mod application with the command ./log_mod. If things are ok, this will directly
setup the nodes in the system like UE, WiMAX, HSPA_RNC, SGSN, LTE_eNB, MME, SGW, and
PGW.
Then during the emulation, different exchanged messages will be plotted between the corresponding
nodes.
The figure below demonstrates how such messages will look like:
Page 100 of 102
Page 101 of 102
References
[1] TS 29.274 V8.1.1, Evolved GPRS Tunnelling Protocol for EPS (GTPv2), 3GPP Evolved
Packet System
[2] TS 23.401 V8.4.1, General Packet Radio Service (GPRS) enhancements for Evolved
Universal Terrestrial Radio Access Network (E-UTRAN) access
[3] TS 23.402 V8.4.1 Architecture enhancements for non-3GPP accesses
[4] TS 29.060 V8.4.0 General Packet Radio Service (GPRS); GPRS Tunnelling Protocol (GTP)
across the Gn and Gp interface
[5] TS 29.281 V8.1.0, General Packet Radio System (GPRS) Tunnelling Protocol User Plane
(GTPv1-U)
[6] TS 24.301 V1.0.0, Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS)
[7] TS 24.007 V7.0.0, Mobile radio interface signalling layer 3; General aspects
[8] TS 24.008 V8.2.0 Mobile radio interface Layer 3 specification; Core network protocols
[9] TS 36.401 E-UTRAN Architecture Description
[10] TS 36.410 S1 General Aspects and Principles
[11] TS 36.413 V8.3.0 S1 Application Protocol (S1AP)
[12] TS 36.300 V8.4.0 Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved
Universal Terrestrial Radio Access Network (E-UTRAN)
[13] Conta, A. and S. Deering, Generic Packet Tunneling in IPv6 Specification', RFC-2473,
Internet Engineering Task Force, December 1998.
[14] Johnson D., Perkins C., Arkko J., Mobility Support in IPv6, RFC 3775, Internet Engineering
Task Force, June 2004.
[15] Devarapalli V., Wakikawa R., Petrescu A., and P. Thubert, Network Mobility (NEMO) Basic
Support Protocol, RFC 3963, Internet Engineering Task Force, January 2005.
[16] Aboba B., Beadles M., Arkko J., and P. Eronen, The Network Access Identifier, RFC 4282,
Internet Engineering Task Force, December 2005.
[17] Patel A., Leung K., Khalil M., Akhtar H., and K. Chowdhury, Mobile Node Identifier Option
for Mobile IPv6, RFC 4283, Internet Engineering Task Force, November 2005.
[18] Gundavelli S., Leung K., Devarapalli V., Chowdhury K., Patil B., Proxy Mobile IPv6, RFC
5213, Internet Engineering Task Force, August 2008.
[19] IEEE Computer Society, IEEE Microwave Theory and Techniques Society, 802.16, IEEE
Standard for Local and Metropolitan Area Networks, Part 16: Air Interface for Fixed
Broadband Wireless Access Systems, October 2004.
[20] A. Muhanna, M. Khalil, S. Gundavelli, K. Chowdhury, P. Yegani, Binding Revocation for
IPv6 Mobility, Internet Engineering Task Force, November 2007.
[21] S. Thomson, T. Narten, T. Jinmei, IPv6 Stateless Address Autoconfiguration, RFC 4862,
September 2007.
[22] TS 23.060 V8.4.0 General Packet Radio Service (GPRS); Service Description.
[23] TS 25.413 V8.3.0 UTRAN Iu interface Radio Access Network Application Part (RANAP)
signalling.
Page 102 of 102

SEA D6.1.1 NOM FF 20090630 Final

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

SEA D6.1.1 NOM FF 20090630 Final

Enviado por

Direitos autorais:

Formatos disponíveis

Information and Communication Technologies (ICT) Programme

Project No: FP7-ICT- 214063

Provisioning of RAT Testbed Components

Copyright by the SEA Consortium

Thomson Grass Valley

Philips Consumer Electronics

Vodafone Panafon AEET

Universidad Politcnica de Madrid

University of California, Los Angeles UCLA

This page has intentionally left bank

Timers of EPS mobility management ............................................................................ 44

4. S1 Application Protocol - S1AP .................................................................................................. 46

3rd Generation Partnership Project

Aggregate Maximum Bit Rate

Access Point Name

EPS Mobility Management

Evolved Packet Core

Evolved Packet System

EPS Session Management

Guaranteed Bit Rate

GTP-U non-signalling PDU

GPRS Tunnelling Protocol

GTP-C PDU or GTP-U PDU

GTP version 2, control plane

GTP version 2, user plane

International Mobile Subscriber Identity

Internet Protocol version 6

Local Mobility Anchor

Mobile Access Gateway

Maximum Bit Rate

Mobility Management Entity

Non Access Stratum

Packet Data Network or Public Data Network

Protocol Data Unit

Proxy Mobile IP version 6

Radio Access Type

Tunnel Endpoint Identifier

Tunnel Endpoint Identifier, control plane

Tunnel Endpoint Identifier, user plane

User Datagram Protocol

Trusted Non3GPP IP access

Figure 1: Network Architecture

and the U-Plane respectively.

Figure 2: C-Plane Protocol Stack. GTP based S5/S8a

Figure 3: U-Plane Protocol Stack. GTP based S5/S8a

S1-AP protocol running over SCTP

RANAP protocol running over SCCP

2. GPRS Tunneling Protocol - GTP

2.1. General format of GTPv2-C header

Spare Spare Spare

Message Length (1st Octet)

Message Length (2nd Octet)

Figure 4: Format of GTPv2 Header

Spare Spare Spare

2.2. GTP-U header

Length (1st Octet)

Length (2nd Octet)

Tunnel Endpoint Identifier (1st Octet)

Tunnel Endpoint Identifier (2nd Octet)

Tunnel Endpoint Identifier (3rd Octet)

Tunnel Endpoint Identifier (4th Octet)

Sequence Number (1st Octet)1) 4)

Sequence Number (2nd Octet)1) 4)