Professional Documents
Culture Documents
SEA D6.1.1 NOM FF 20090630 Final
SEA D6.1.1 NOM FF 20090630 Final
SEA D6.1.1 NOM FF 20090630 Final
SEA
Deliverable D6.1.1
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.
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
Contractor
France
Philips
Contractor
Netherlands
Vodafone
Contractor
Greece
Nomor Research
Nomor
Contractor
Germany
Fraunhofer HHI
HHI
Contractor
Germany
Politecnico di Torino
Polito
Contractor
Italy
UPM
Contractor
Spain
10
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
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
SEA_D6.1.1_NOM_FF_20090630.doc
Page 3 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
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
SEA_D6.1.1_NOM_FF_20090630.doc
Page 4 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
3.8.1.
3.8.2.
Page 5 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
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
SEA_D6.1.1_NOM_FF_20090630.doc
Page 6 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
Abbreviations
3GPP
AMBR
APN
EBI
EPS Bearer ID
EMM
eNB
evolved Node B
EPC
EPS
ESM
GBR
G-PDU
GTP
GTP-PDU
GTPv2-C
GTPv2-U
HO
Handover
IE
Information Element
IMSI
IP
Internet Protocol
IPv6
LMA
MAG
MBR
MME
NAS
PDN
PDU
PMIPv6
P-GW or PGW
PDN Gateway
QoS
Quality of Service
RAT
S-GW or SGW
Serving Gateway
TEID
SEA_D6.1.1_NOM_FF_20090630.doc
Page 7 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
TEID-C
TEID-U
UDP
UE
User Equipment
SEA_D6.1.1_NOM_FF_20090630.doc
Page 8 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
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
ePDG
S2b
Figure 2 and Figure 3 below detail the whole protocol stack of the network for the C-Plane
SEA_D6.1.1_NOM_FF_20090630.doc
Page 9 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
SEA_D6.1.1_NOM_FF_20090630.doc
Page 10 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
SEA_D6.1.1_NOM_FF_20090630.doc
Page 11 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
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
PMIP protocol
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.
SEA_D6.1.1_NOM_FF_20090630.doc
Page 12 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
7
Version
Message Type
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
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.
SEA_D6.1.1_NOM_FF_20090630.doc
Page 13 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
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
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
Octets
7
Version
Bits
5
PT
4
(*)
Message Type
10
11
N-PDU Number2) 4)
1
PN
3) 4)
12
SEA_D6.1.1_NOM_FF_20090630.doc
Page 14 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
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:
SEA_D6.1.1_NOM_FF_20090630.doc
Ins.
0
0
0
0
0
0
0
Page 15 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
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
O This IE is optionally included by the MME on the S11
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
SEA_D6.1.1_NOM_FF_20090630.doc
0
1
0
0
0
0
0
1
0
VS
Page 16 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
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
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:
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
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.
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
SEA_D6.1.1_NOM_FF_20090630.doc
Page 17 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
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
Configuration Options
(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
M
M This IE shall indicate if the bearer handling was successful,
and if not, it gives information on the reason.
O
O
C This IE shall be included on the S11 interface if the S1-U
interface is used.
C This IE shall be included on the S4 interface if the S4-U
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:
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
Page 18 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
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
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
Configuration Options
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
SEA_D6.1.1_NOM_FF_20090630.doc
Page 19 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
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
Configuration Options
provide the UE with application specific parameters
(PCO)
Private Extension
O
IE Type
Ins.
Cause
Recovery
0
0
PCO
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.
SEA_D6.1.1_NOM_FF_20090630.doc
Page 20 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
"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.
Several IEs with this type and instance values shall be
included as necessary to represent a list of Bearers.
Used for dedicated bearers. When used, at least one
dedicated bearer shall be present.
Recovery
C This IE shall be included if contacting the peer for the first
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
Private Extension VS
The Delete Bearer Response is sent from MME or SGSN to PGW (through SGW) as a response of
Delete Bearer Request.
SEA_D6.1.1_NOM_FF_20090630.doc
Page 21 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
Table 9: Information Elements in a Modify Bearer Request
Information
elements
ME Identity (MEI)
Condition / Comment
IE Type
SEA_D6.1.1_NOM_FF_20090630.doc
Ins.
0
0
0
0
0
0
1
VS
Page 22 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
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
M
C This IE shall be sent on the S11 interface if the S1-U is
being used:
IE Type
Ins.
EBI
F-TEID
0
0
F-TEID
F-TEID
F-TEID
Bearer QoS
Charging
Characteristics
SEA_D6.1.1_NOM_FF_20090630.doc
Page 23 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
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.
Configuration Options
(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
C This IE shall be included if contacting the peer for the first
Recovery
0
time.
Private Extension
O
Private Extension VS
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.
SEA_D6.1.1_NOM_FF_20090630.doc
Page 24 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
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
C This IE shall be included if the message is used for PS
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
Page 25 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
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
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
Address and TEID for
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
included as necessary to represent a list of Bearers.
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
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
Address and TEID for
user plane
C This IE shall be present for GTP based S5/S8
PGW S5/S8 IP
Address and TEID for
user plane
Bearer Level QoS
M
Charging
characteristics
Container
2.3.10.
IE Type
0
0
1
0
F-TEID
Bearer
Level QoS
Charging
characterist
ics
F-Container
0
0
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".
SEA_D6.1.1_NOM_FF_20090630.doc
Page 26 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
"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".
Several IEs with this type and instance values shall be
included as necessary to represent a list of Bearers.
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".
Several IEs with this type and instance values shall be
included as necessary to represent a list of Bearers.
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
contains the value "Request accepted", this IE is included.
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
contains the value "Request accepted", this IE is included.
F-Container
BSS Container
O This IE contains the radio-related and core network
information for handover to GERAN. If the Cause IE
contains the value "Request accepted", this IE is included.
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.
SEA_D6.1.1_NOM_FF_20090630.doc
Page 27 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
Table 17: Bearer Context
Octet 1
Octets 2 and 3
Octet 4
Information
elements
EPS Bearer ID
NSAPI
Packet Flow ID
2.3.11.
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.
C This IE shall be included if the message is used for PS
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
A Forward Relocation Complete Notification message shall be sent to the source MME/SGSN to
indicate the handover has been successfully finished.
Table 18 specifies the presence requirements and conditions of the IEs in the message.
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
SEA_D6.1.1_NOM_FF_20090630.doc
Page 28 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
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
SEA_D6.1.1_NOM_FF_20090630.doc
Page 29 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
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.
SEA_D6.1.1_NOM_FF_20090630.doc
Page 30 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
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
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
SEA_D6.1.1_NOM_FF_20090630.doc
Page 31 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
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.
Page 32 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
Upon receiving the ATTACH REJECT message, the UE shall stop timer T3410 and enter EMMDEREGISTERED state.
SEA_D6.1.1_NOM_FF_20090630.doc
Page 33 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
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.
SEA_D6.1.1_NOM_FF_20090630.doc
Page 34 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
Figure 11: The ESM states for EPS bearer context handling in the network
SEA_D6.1.1_NOM_FF_20090630.doc
Page 35 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
Page 36 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
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.
SEA_D6.1.1_NOM_FF_20090630.doc
Page 37 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
SEA_D6.1.1_NOM_FF_20090630.doc
Page 38 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
Upon receipt of the PDN CONNECTIVITY REJECT message, the UE shall stop timer T3482 and
enter the state PROCEDURE TRANSACTION INACTIVE.
: 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
Protocol discriminator
Security header type
Message type
EPS mobile identity
MS network capability
EPS attach type
NAS key set identifier
Tracking area identity
FFS
ESM message container
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
: network to UE
SEA_D6.1.1_NOM_FF_20090630.doc
Page 39 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
Table 21: ATTACH ACCEPT message content
IEI
FFS
FFS
FFS
FFS
FFS
FFS
Information Element
Protocol discriminator
Security header type
Attach accept message identity
EPS attach result
Spare half octet
T3412 value
TAI list
GUTI
LAI
MS identity
T3402 value
Equivalent PLMNs
ESM message container
Type/Reference
Protocol discriminator
Security header type
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
ESM message container
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
: UE to network
Table 22: ATTACH COMPLETE message content
IEI
Information Element
Protocol discriminator
Security header type
Attach complete message identity
FFS ESM message container
Type/Reference
Protocol discriminator
Security header type
Message type
ESM message container
Presence
M
M
M
O
Format
V
V
V
TLV-E
Length
1/2
1/2
1
3-n
: network to UE
Table 23: ATTACH REJECT message content
IEI
Information Element
Protocol discriminator
Security header type
Attach reject message identity
EMM cause
FFS ESM message container
Type/Reference
Protocol discriminator
Security header type
Message type
EMM cause
ESM message container
Presence
M
M
M
M
O
Format Length
V
1/2
V
1/2
V
1
V
1
TLV-E
3-n
: UE to network
SEA_D6.1.1_NOM_FF_20090630.doc
Page 40 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
Table 24: DETACH REQUEST message content
IEI
Information Element
Protocol discriminator
Security header type
Detach request message identity
Detach type
Spare half octet
GUTI
Type/Reference
Protocol discriminator
Security header type
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
: network to UE
Table 25: DETACH REQUEST message content
IEI
Information Element
Protocol discriminator
Security header type
Detach request message identity
Detach type
Spare half octet
EMM cause
FFS
Type/Reference
Protocol discriminator
Security header type
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
: network to UE
Table 26: DETACH ACCEPT message content
IEI
Information Element
Protocol discriminator
Security header type
Detach accept message identity
Type/Reference
Protocol discriminator
Security header type
Message type
Presence
M
M
M
Format
V
V
V
Length
1/2
1/2
1
: UE to network
Table 27: DETACH ACCEPT message content
IEI
Information Element
Protocol discriminator
Security header type
Detach accept message identity
SEA_D6.1.1_NOM_FF_20090630.doc
Type/Reference
Protocol discriminator
Security header type
Message type
Presence
M
M
M
Format
V
V
V
Length
1/2
1/2
1
Page 41 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
: 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
Protocol discriminator
EPS bearer identity
Procedure transaction identifier
Activate default EPS bearer
context request message identity
SDF QoS
Type/Reference
Protocol discriminator
EPS bearer identity
Procedure transaction identifier
Message type
Presence Format
M
V
M
V
M
V
M
V
Length
1/2
1
1
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
Protocol configuration options
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
: UE to network
Table 29: ACTIVATE DEFAULT EPS BEARER CONTEXT ACCEPT message content
IEI
Information Element
Protocol discriminator
EPS bearer identity
Procedure transaction identifier
Activate default EPS bearer context
accept message identity
FFS Protocol configuration options
Type/Reference
Presence
Protocol discriminator
M
EPS bearer identity
M
Procedure transaction identifier
M
Message type
M
Protocol configuration options
Format
V
V
V
V
Length
1/2
1/2
1
1
TLV
3-253
: UE to network
SEA_D6.1.1_NOM_FF_20090630.doc
Page 42 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
Table 30: ACTIVATE DEFAULT EPS BEARER CONTEXT REJECT message content
IEI
Information Element
Protocol discriminator
EPS bearer identity
Procedure transaction identifier
Activate default EPS bearer context
reject message identity
ESM cause
FFS Protocol configuration options
Type/Reference
Presence
Protocol discriminator
M
EPS bearer identity
M
Procedure transaction identifier
M
Message type
M
ESM cause
Protocol configuration options
M
O
Format
V
V
V
V
Length
1/2
1/2
1
1
V
TLV
1
3-253
: network to UE
Table 31: DEACTIVATE EPS BEARER CONTEXT REQUEST message content
IEI
FFS
Information Element
Protocol discriminator
EPS bearer identity
Procedure transaction identifier
Deactivate EPS bearer context
request message identity
ESM cause
Protocol configuration options
Type/Reference
Protocol discriminator
EPS bearer identity
Procedure transaction identifier
Message type
ESM cause
Protocol configuration options
Presence
M
M
M
M
Format
V
V
V
V
Length
1/2
1/2
1
1
M
O
V
TLV
1
3-253
: UE to network
Table 32: DEACTIVATE EPS BEARER CONTEXT ACCEPT message content
IEI
FFS
Information Element
Protocol discriminator
EPS bearer identity
Procedure transaction identifier
Deactivate EPS bearer context
accept message identity
Protocol configuration options
Type/Reference
Protocol discriminator
EPS bearer identity
Procedure transaction identifier
Message type
Protocol configuration options
Presence
M
M
M
M
Format
V
V
V
V
Length
1/2
1/2
1
1
TLV
3-253
: UE to network
SEA_D6.1.1_NOM_FF_20090630.doc
Page 43 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
Table 33: PDN CONNECTIVITY REQUEST message content
IEI
Information Element
Protocol discriminator
EPS bearer identity
Procedure transaction identifier
PDN connectivity request
message identity
Request type
PDN type
FFS Access point name
FFS Ciphered PCO transfer flag
FFS Protocol configuration options
Type/Reference
Protocol discriminator
EPS bearer identity
Procedure transaction identifier
Message type
Request type
PDN type
Access point name
FFS
Protocol configuration options
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
: network to UE
Table 34: PDN CONNECTIVITY REJECT message content
IEI
FFS
Information Element
Protocol discriminator
EPS bearer identity
Procedure transaction identifier
PDN connectivity reject message
identity
ESM cause
Protocol configuration options
Type/Reference
Presence
Protocol discriminator
M
EPS bearer identity
M
Procedure transaction identifier
M
Message type
M
ESM cause
Protocol configuration options
M
O
Format
V
V
V
V
Length
1/2
1/2
1
1
V
TLV
1
3-253
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
SEA_D6.1.1_NOM_FF_20090630.doc
Page 44 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
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.
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
NOTE 1: Typically, the procedures are aborted on the fifth expiry of the relevant timer. Exceptions are
described in the corresponding procedure description.
TIMER
VALUE
T3485 FFS
STATE
BEARER
CONTEXT
ACTIVE
PENDING
CAUSE OF START
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
NOTE 1: Typically, the procedures are aborted on the fifth expiry of the relevant timer. Exceptions are
described in the corresponding procedure description.
T3495 FFS
BEARER
CONTEXT
INACTIVE
PENDING
SEA_D6.1.1_NOM_FF_20090630.doc
Page 45 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
SEA_D6.1.1_NOM_FF_20090630.doc
Page 46 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
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.
SEA_D6.1.1_NOM_FF_20090630.doc
Page 47 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
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.
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.
SEA_D6.1.1_NOM_FF_20090630.doc
Page 48 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
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.
source
eNB
MME
HANDOVER REQUIRED
HANDOVER COMMAND
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.
SEA_D6.1.1_NOM_FF_20090630.doc
Page 49 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
target
eNB
MME
HANDOVER REQUEST
HANDOVER REQUEST ACKNOWLEDGE
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
SEA_D6.1.1_NOM_FF_20090630.doc
Page 50 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
SEA_D6.1.1_NOM_FF_20090630.doc
Page 51 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
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
Page 52 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
IE/Group Name
Presence
Message Type
MME UE S1AP ID
eNB UE S1AP ID
M
M
Handover Type
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
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
IE/Group Name
Message Type
MME UE S1AP ID
eNB UE S1AP ID
SEA_D6.1.1_NOM_FF_20090630.doc
Presence
M
M
M
Page 53 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
Overall RAB management. This function is responsible for setting up, modifying and
releasing RABs.
Note that on the SGSN and RNC, RANAP runs over SCCP. In our implementation, SCCP is
transparent.
CN
RNC
RAB ASSIGNMENT
REQUEST
RAB ASSIGNMENT
RESPONSE
.
.
.
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.
SEA_D6.1.1_NOM_FF_20090630.doc
Page 54 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
5.1.2.1 CN Originated Direct Transfer
CN
RNC
DIRECT TRANSFER
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
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.
Source RNC
CN
RELOCATION REQUIRED
RELOCATION COMMAND
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.
SEA_D6.1.1_NOM_FF_20090630.doc
Page 55 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
Target RNC
CN
RELOCATION REQUEST
RELOCATION REQUEST
ACKNOWLEDGE
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.
Target RNC
CN
RELOCATION COMPLETE
The target RNC shall initiate the Relocation Complete procedure by sending a RELOCATION
COMPLETE message to the CN.
SEA_D6.1.1_NOM_FF_20090630.doc
Page 56 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
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.
SEA_D6.1.1_NOM_FF_20090630.doc
Page 57 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
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.
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.
SEA_D6.1.1_NOM_FF_20090630.doc
Page 58 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
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].
SEA_D6.1.1_NOM_FF_20090630.doc
Page 59 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
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.
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.
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.
SEA_D6.1.1_NOM_FF_20090630.doc
Page 60 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
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.
SEA_D6.1.1_NOM_FF_20090630.doc
Page 61 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
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.
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]:
SEA_D6.1.1_NOM_FF_20090630.doc
Page 62 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
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.
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.
SEA_D6.1.1_NOM_FF_20090630.doc
Page 63 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
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.
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
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.
SEA_D6.1.1_NOM_FF_20090630.doc
Page 64 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
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.
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:
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).
SEA_D6.1.1_NOM_FF_20090630.doc
Page 65 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
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.
SEA_D6.1.1_NOM_FF_20090630.doc
Page 66 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
UE
eNodeB
new MME
Serving GW
PDN GW
1. Attach Request
2. Attach
Request
7. Delete Session Request
SEA_D6.1.1_NOM_FF_20090630.doc
Page 67 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
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.
SEA_D6.1.1_NOM_FF_20090630.doc
Page 68 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
UE
MME
Serving GW
PDN GW
1. Detach Request
2. Delete Session Request
3. Delete Bearer Request
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.7. Handovers
The HO procedures covered are discussed below:
Handover from 3GPP Access to Trusted Non-3GPP IP Access (LTE to WiMAX and HSPA
to WiMAX).
SEA_D6.1.1_NOM_FF_20090630.doc
Page 69 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
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
Figure 36: Handover from Trusted Non-3GPP IP Access to E-UTRAN with PMIP on S2a and
GTP on S5/S8 interfaces
SEA_D6.1.1_NOM_FF_20090630.doc
Page 70 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
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.
SEA_D6.1.1_NOM_FF_20090630.doc
Page 71 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
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
8. Create Default Bearer Request
9. Create Bearer Request
11. Create Bearer Response
12. Create Default Bearer
Response (IP Addr)
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).
SEA_D6.1.1_NOM_FF_20090630.doc
Page 72 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
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).
UE
PDN
GW
SEA_D6.1.1_NOM_FF_20090630.doc
Page 73 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
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.
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
Figure 39: Handover from 3GPP Access to Trusted Non-3GPP IP Access with PMIPv6 on S2a
and GTP on S5 interface
SEA_D6.1.1_NOM_FF_20090630.doc
Page 74 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
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)
UE
Source
eNodeB
Target
Target SGSN Serving GW Serving GW
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).
SEA_D6.1.1_NOM_FF_20090630.doc
Page 75 of 102
PDN GW
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
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.
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.
SEA_D6.1.1_NOM_FF_20090630.doc
Page 76 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
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
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.
SEA_D6.1.1_NOM_FF_20090630.doc
Page 77 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
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.
Source RNC
Target eNodeB
Source SGSN
Target MME
SGW
PGW
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).
SEA_D6.1.1_NOM_FF_20090630.doc
Page 78 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
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.
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.
SEA_D6.1.1_NOM_FF_20090630.doc
Page 79 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
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
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.
SEA_D6.1.1_NOM_FF_20090630.doc
Page 80 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
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.
MSISDN
Description
IMSI (International Mobile Subscriber Identity) is the
subscriber permanent identity.
Selected CN operator id
Trace type
Trigger id
OMC identity
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
SEA_D6.1.1_NOM_FF_20090630.doc
create_session_req
received from MME
Page 81 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
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.
APN Restriction
SEA_D6.1.1_NOM_FF_20090630.doc
Page 82 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
Field
RNC TEID for S12
Description
RNC Tunnel Endpoint Identifier for the S12 interface.
Charging Characteristics
7.6.2. PDN GW
The PDN GW maintains the following EPS bearer context information for UEs. The table below
shows the context fields for one UE.
Table 51: PGW context
Field
Description
IMSI
create_session_req
received from SGW
MSISDN
Selected CN operator id
RAT type
Trace reference
Trace type
Trigger id
OMC identity
create_session_req
received from SGW
create_session_req
received from SGW
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)
SEA_D6.1.1_NOM_FF_20090630.doc
Page 83 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
CGI/SAI/RAI change
report required
BCM
7.6.3. MME
The MME maintains MM context and EPS bearer context information for UEs. The table below
shows the context fields for one UE.
Table 52: MME MM and EPS bearer Contexts
Field
Description
IMSI
MSISDN
MM State
GUTI
ME Identity
Tracking Area List
Cell Global Identity
Cell Identity Age
Authentication Vector
UE Radio Access
Capability
UE Network Capability
SEA_D6.1.1_NOM_FF_20090630.doc
Page 84 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
Field
NAS Keys and COUNT
Selected CN operator id
Recovery
Access Restriction
ODB for PS parameters
MME IP address for S11
MME TEID for S11
S-GW IP address 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.
Subscribed Charging
Characteristics
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.
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)
sending control plane signalling.
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
An EPS bearer identity uniquely identifies an EPS
bearer for one UE accessing via E-UTRAN
create_session_res received
from SGW
SEA_D6.1.1_NOM_FF_20090630.doc
Page 85 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
7.6.4. SGSN
A data structure similar to that of the MME is maintained at the SGSN.
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
IMSI (International Mobile Subscriber Identity) is the
subscribers permanent identity.
MSISDN
EMM State
SEA_D6.1.1_NOM_FF_20090630.doc
Page 86 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
RealNeS LTE
Switch
Switch
External
RealNeS HSPA
Terminal
- MME
- SGW
- PGW
Switch
sgi
RealNeS WiMAX
SEA_D6.1.1_NOM_FF_20090630.doc
Page 87 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
libnetfilter_queue-0.0.16
libnet
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
SEA_D6.1.1_NOM_FF_20090630.doc
Page 88 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
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.
Page 89 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
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.6. Libraries
The following libraries should also be installed on the machine hosting the GWs/MME:
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.
SEA_D6.1.1_NOM_FF_20090630.doc
Page 90 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
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
dialog window will open. All the available scenarios are listed on this window. Select a scenario and
click OK. The HSPA emulator will start operating.
A shortcut to start the dialog window will be also available on the Desktop after the installation.
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
dialog window will open. All the available scenarios are listed on this window. Select a scenario and
click OK. The WiMAX emulator will start operating.
A shortcut to start the dialog window will be also available on the Desktop after the installation.
SEA_D6.1.1_NOM_FF_20090630.doc
Page 91 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
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.
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 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.
SEA_D6.1.1_NOM_FF_20090630.doc
Page 92 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
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.
SEA_D6.1.1_NOM_FF_20090630.doc
Page 93 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
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
SEA_D6.1.1_NOM_FF_20090630.doc
status
priority
color
x_origin
y_origin
Page 94 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
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.
SEA_D6.1.1_NOM_FF_20090630.doc
Page 95 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
SEA_D6.1.1_NOM_FF_20090630.doc
Page 96 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
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.
SEA_D6.1.1_NOM_FF_20090630.doc
Page 97 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
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.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.
SEA_D6.1.1_NOM_FF_20090630.doc
Page 98 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
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
SEA_D6.1.1_NOM_FF_20090630.doc
Page 99 of 102
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
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.
SEA_D6.1.1_NOM_FF_20090630.doc
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
SEA_D6.1.1_NOM_FF_20090630.doc
FP7-ICT-214063 - SEA
D6.1.1: Provisioning of RAT Testbed Components
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.
SEA_D6.1.1_NOM_FF_20090630.doc