Professional Documents
Culture Documents
03 - LTE-EPS Mobility & Session Management PDF
03 - LTE-EPS Mobility & Session Management PDF
Legal notice
The Cell
Smallest entity regarding mobility
When the UE is connected to the network, the MME will know
the UE´s position on cell level
Cells are identified by the Cell Identification (CI) and by the
Physical Cell Identification (PCI)
Example:
•Let's say that we are going to deploy a LTE network in a city and that city needs 1000
cells.
•Each of the 1000 cells will have their own cell ID, but, since there is only 504 physical
cell IDs, we will need to repeat the physical cell IDs twice.
•The key is that that the two cell that share a physical cell ID cannot be geographically
close to each other or they will interfere will each other.
Tracking Areas
Tracking Area Identity (TAI) vs. Tracking Area Code (TAC)
TAI= MCC + MNC + TAC
Tracking Area
eNB 1 2
TAI1
TAI1
TAI1 MME
TAI1
TAI1
TAI2
TAI2 eNB
TA List: TAI2
TAI2
TA1 TAI2
TAI2
TA2 TAI2
TAI2 Cell Identity
TAI3 3
TAI3 S-eNB
TAI3
TAI3 MME
TAI3
TAI3
TAI3
For public use – IPR applies
9 © Nokia Siemens Networks LTE/EPS Mobility & Session Management / Jose Maria Anarte / v2.0 / Document Number
•Another difference between TAU and the LAU/RAU of UMTS is that the mobile can have
a list of several valid tracking areas and an update only has to be made if the new cell is
in a tracking area that is not part of that list.
•This solution will avoid unnecessary tracking area updates at the tracking areas border
when the UE is ping-ponging between cells belonging to different TAs.
Tracking Areas: Use of S1-flex Interface
TAI1 1 2 3
TAI1
TAI1 MME
TAI1
TAI1 MME
TAI2 eNB Pooling:
TAI2
TAI2 several
TAI2
TAI2 MME
TAI2 handle the
TAI2
TAI2 same
eNB
TAI2 tracking
TAI2 1 2 3
area
TAI2
TAI3 S-MME
TAI3
TAI3
TAI3
S-eNB
• IMSI
– International Mobile Subscriber Identity
• GUTI
– Global Unique Temporary Identity
• C-RNTI
– Cell Radio Network Temporary Identity
• S1-AP UE ID
– S1 Application Protocol User Equipment Identity
IMSI:
• International Mobile Subscriber Identity.
• Used in LTE to uniquely identify a subscriber world-wide
• Its structure is kept in form of MCC+MNC+MSIN:
MCC: mobile country code
MNC: mobile network code
MSIN: mobile subscriber identification number
• A subscriber can use the same IMSI for 2G, 3G and LTE access
• MME uses the IMSI to locate the HSS holding the subscribers permanent
registration data for tracking area updates and attaches
IMSI
•USIM card can be used to access 2G networks (besides 3G and LTE Networks)
•SIM card (original 2G SIM card) can not be used to access LTE Networks
UE Identification: GUTI
GUTI:
• Globally Unique Temporary Identity
• It is dynamically allocated by the serving MME
• Its main purpose is to avoid usage of IMSI on air
• Internally the allocating MME can translate GUTI into IMSI and vice versa
• The GUTI consists of 2 components: GUMMEI and M-TMSI
GUTI
GUMMEI M-TMSI
Further Reading:
The GUMMEI in turn consists of the following:
− PLMN Id: MCC, MNC
− MME Identifier (MMEI): MME Group Id (MMEGI) and MME Code (MMEC)
The MMEC provides a unique identity to an MME within the MME pool, while the MMEGI
is used to distinguish between different MME pools.
More details about these identifiers can be found in TS 23.003.
GUTI reallocation is further described in TS 23.401 and TS 24.301.
Further Reading: S-TMSI
S-TMSI:
•The SAE TMSI (S-TMSI) is a shortened form of the GUTI
•It is used to identify the UE over the radio path and is included in the RRC
connection request and paging messages
•The S-TMSI contains the MMEC and M-TMSI components of the GUTI
• Note, however, that the S-TMSI does not include the MMEGI — that is, the MME
pool component
S-TMSI
GUMMEI
GUTI
For public use – IPR applies
15 © Nokia Siemens Networks LTE/EPS Mobility & Session Management / Jose Maria Anarte / v2.0 / Document Number
Because MME pool areas can overlap, care must be taken to ensure that MMEs serving
the overlapping areas are
not allocated the same MMECs
UE Identifications: C-RNTI
C-RNTI:
• Cell Radio Network Temporary Identity
• C-RNTI is allocated by the eNB serving a UE when it is in active mode
(RRC_CONNECTED)
• This is a temporary identity for the user only valid within the serving cell of
the UE
• It is release as soon as the UE moves to idle state (RRC_IDLE)
• It is exclusively used for radio management procedures.
S1-AP UE ID:
• S1 Application Protocol User Equipment Identity.
• Two additional temporary identifiers allocated by eNB and MME:
- eNB S1-AP UE ID
- MME S1-AP IE ID
eNB
TAI1 1 2 3
IMSI TAI1
TAI1 MME
MCC MNC MSIN TAI1
TAI1
TAI2 eNB
TAI2
TAI2
TAI2
TAI2
Cell Identity TAI2
TAI2 MME Identity
TAI2
TAI2 S-eNB
TAI2 1 2 3
C-RNTI TAI2
TAI3 S-MME
TAI3
TAI3 eNB S1-AP UE-ID | MME S1-AP UE-ID
TAI3
GUTI
GUMMEI M-TMSI
IMSI International Mobile Subscriber Identity TAI Tracking Area Identity (MCC+MNC+TAC)
GUTI Globally Unique Temporary Identity S-MME Serving MME
C-RNTI Cell Radio Network Temporary Identity S-eNB Serving E-Node B
For public use – IPR applies
18 © Nokia Siemens Networks LTE/EPS Mobility & Session Management / Jose Maria Anarte / v2.0 / Document Number
Module Contents
3G LTE
Mobility management
Connection management
These are:
1.- EPS* Mobility Management (EMM) states
2.- EPS* Connection Management (ECM) states
Attach
Detach
EMM-DEREGISTERED:
•In this state the MME holds no valid location information about the UE
•MME may keep some UE context when the UE moves to this state (e.g. to
avoid the need for Authentication and Key Agreement (AKA) during every
attach procedure)
•Successful Attach and Tracking Area Update (TAU) procedures lead to
transition to EMM-REGISTERED
EMM-REGISTERED:
•In this state the MME holds location information for the UE at least to the
accuracy of a tracking area
•In this state the UE performs TAU procedures, responds to paging
messages and performs the service request procedure if there is uplink data
to be sent.
UE E-UTRAN MME
RRC connection
establishment
RRC
RRC idle
connected
RRC connection
release
S1 connection establishment
ECM
ECM idle
connected
S1 connection release
UE
eNB
MME
RRC Connection S1 Connection
ECM Connected
ECM-IDLE:
•In this state there is no NAS signalling connection between the UE and the
network and there is no context for the UE held in the E-UTRAN.
•The location of the UE is known to within the accuracy of a tracking area
•Mobility is managed by tracking area updates.
ECM-CONNECTED:
•In this state there is a signalling connection between the UE and the MME
which is provided in the form of a Radio Resource Control (RRC) connection
between the UE and the E-UTRAN and an S1 connection for the UE
between the E-UTRAN and the MME.
•The location of the UE is known to within the accuracy of a cell.
•Mobility is managed by handovers.
RRC-IDLE:
• No signalling connection between the UE and the E-UTRAN.
• I.e.: PLMN Selection.
• UE Receives system information and listens for Paging.
• Mobility based on Cell Re-selection performed by UE.
• No RRC context stored in the eNB (No C-RNTI).
• RACH procedure used on RRC connection establishment.
RRC-CONNECTED:
• UE has an E-UTRAN RRC connection.
• UE has context in E-UTRAN (C-RNTI allocated).
• E-UTRAN knows the cell which the UE belongs to.
• Network can transmit and/or receive data to/from UE.
• Mobility based on handovers
• UE reports neighbour cell measurements.
For public use – IPR applies
28 © Nokia Siemens Networks LTE/EPS Mobility & Session Management / Jose Maria Anarte / v2.0 / Document Number
EMM & ECM States Transitions
Power On
Release due to
Registration (Attach) Inactivity
• Allocate C-RNTI, GUTI • Release RRC connection
• Allocate IP address • Release C-RNTI
• Authentication • Configure DRX for paging
• Establish security context
New Traffic
Deregistration (Detach) TAU
Change PLMN
•Establish RRC Connection
• Release C-RNTI, GUTI •Allocate C-RNTI
• Release IP address
Timeout of Periodic TA
Update
• Release GUTI
• Release IP address
For public use – IPR applies
29 © Nokia Siemens Networks LTE/EPS Mobility & Session Management / Jose Maria Anarte / v2.0 / Document Number
EMM & ECM States Summary
•For further information about the EPS Bearer, please refer to 3GPP TS 23.401, v9.2.0,
section 4.7.2
LTE/EPS Bearer: Identity & Architecture
•An EPS bearer identity uniquely identifies an EPS bearer for one UE. The EPS Bearer
Identity is allocated by the MME.
•LTE/EPS Bearer spans the complete network, from UE over EUTRAN and EPC up to the
connector of the external PDN.
•The SAE bearer is associated with a quality of service (QoS) usually expressed by a label or
QoS Class Identifier (QCI)
End-to-End Service
•There is a one to one mapping between EPS Radio Bearer (RB) and EPS Bearer, and
the mapping between EPS RB Identity and EPS Bearer Identity is made by E-UTRAN.
•The E-RAB ID value used at S1 and X2 interfaces to identify an E-RAB is the same as
the EPS Bearer ID value used to identify the associated EPS Bearer.
LTE/EPS Bearer Sections
S5/S8 Bearer
•Between the P-GW to S-GW.
•This is usually a GTP or MIP (Mobile IP) tunnel between the two network
elements.
S1 Bearer
•Between eNB and S-GW.
•The S1 Bearer is implemented using the 2G/3G GTP (GPRS Tunneling
Protocol) protocol which builds a GTP tunnel between eNB and S-GW.
•The setup of this S1Bearer is managed by the MME. S-GW and eNB do not
directly exchange signaling to create it.
Radio Bearer
•Between UE and eNB.
•The eNB connects a radio bearer internally with the associated S1 Bearer
on S1-U interface.
•The mapping of radio bearers to physical resources on the air interface is
the major task of the eNB scheduler.
For public use – IPR applies
34 © Nokia Siemens Networks LTE/EPS Mobility & Session Management / Jose Maria Anarte / v2.0 / Document Number
•An E-RAB (E-UTRAN Radio Access Bearer) refers to the concatenation of an S1 bearer
and the corresponding radio bearer, as defined in TS 36.300
EPS Bearers Establishment can be triggered by….
MME:This happens typically
PDN Gateway: The external data
during the attach procedure of an
network can request the setup of an
UE. Depending on the information
EPS bearer by issuing this request via
coming from HSS, the MME will
PCRF to the PDN gateway. This
set up an initial bearer, also
request will include the quality of service
known as the Default EPS
granted to the new bearer. Those are
bearer. This EPS bearer provides
referred as Dedicated EPS bearers.
the initial connectivity of the UE
with its external data network or
MME
IMS platform. Gx/S7
PCRF
S1-MME Rx
UE eNB S11
S1-U S5 SGi
cell PDN
Serving
Gateway PDN
Gateway
•Each UE that is attached to the LTE network has at least one bearer
available, that is called the default bearer.
•Its goal is to provide continuous IP connectivity towards the EPC (“always-
on” concept)
•From the QoS point of view, the default bearer is normally a quite basic
bearer
•If an specific service requires more stringent QoS attributes, then a
dedicated bearer should be established.
MME
S1-MME
UE eNB S11 PDN
S5 Gateway
S1-U Sgi
cell PDN
Serving
Gateway
•A default Evolved Packet System (EPS) bearer is the bearer that is established during
the attach process.
•It will give the UE an IP address and packet data resources so that the UE can do limited
packet services.
•One of the best examples of a service that would be good for the default EPS bearer is
an IMS registration.
•The characteristics of the default EPS bearer will be defined by the subscription and
established by the Mobility Management Entity (MME) upon receiving the attach message
based on the subscriber profile in the Home Subscriber Server (HSS).
•Default bearers are created on a per PDN basis. So if a UE is connecting to two PDNs it
will need to establish two default bearers.
SAE Bearer QoS Awareness
•One of the major requirements for EUTRAN and EPC to fulfill is that every SAE
bearer must be QoS aware.
•All data transmitted within a SAE bearer will get the same QoS handling (scheduling,
prioritization, discarding probability, etc.).
•Different applications (for example take a packet video streaming service and a ftp
download) have different QoS setting and cannot share the same SAE bearer.
•Other applications with similar traffic characteristics will be able to be placed inside
the same SAE bearer provided that the bandwidth of the bearer is scaled accordingly .
•Due to this fact, the standard will allow a UE to have several SAE bearers, each one
with a different QoS setting.
•Schedulers in eNB, SAE GW and PDN GW must respect the QoS of each individual
SAE bearer.
•Limits coming from a user’s subscription must be taken into account when a new SAE
bearer is set up or one is modified. This is one task of the MME.
•Basic Guideline: The LTE/EPS Bearer and QoS management has to be improved in
comparison to the way it is done in existing 3GPP system.
•The main reason is that it has not been easy for operators to implement QoS attributes in
GSM/WCDMA networks, as they were somehow disconnected from the application layer.
This problem was even getting worse by the fact that the UE was responsible for setting
the QoS attributes for a Bearer.
•It was therefore agreed that only a reduced set of QoS parameters and standardized
attributes would be specified for the EPS bearer.
EPS Bearer QoS Attributes
GBR/N-GBR
MBR
EPS Bearer QoS Parameters
(To be defined per Bearer)
UL/DL-TFT
QCI
ARP
For every EPS bearer the following QoS parameters are available:
• Dedicated or default EPS bearer
• Guaranteed Bit Rate (GBR) or Non-Guaranteed Bit Rate (N-GBR)
• Maximum Bit Rate (MBR)
• Traffic Flow Control (UL/DL-TFT):
• Integer number indicating QoS category: Label or QoS Class identifier (QCI)
• Allocation/Retention Priority (ARP)
For all bearers together for one user, following QoS parameter is available:
• Aggregate Maximum Bit Rate (AMBR)
SAE Bearer QoS Attributes (1/3)
Dedicated or Default bearer:
•The default bearer is allocated during attach of a UE to the system.
•Dedicated bearers on the other hand are created on demand by the external PDN
network.
•Only dedicated bearers can be of Guaranteed Bit rate (GBR) type.
GBR identifies the bit rate that will be ensured to the bearer.
SAE Bearer QoS Attributes (2/3)
ARP Parameter
Notes from the Specs (3GPP TS 23.401, v9.2.0, section 4.7.3) regarding the ARP
parameter:
The ARP should be understood as "Priority of Allocation and Retention"; not as
"Allocation, Retention, and Priority".
Video telephony is one use case where it may be beneficial to use EPS bearers with
different ARP values for the same UE. In this use case an operator could map voice to
one bearer with a higher ARP, and video to another bearer with a lower ARP. In a
congestion situation (e.g. cell edge) the eNB can then drop the "video bearer" without
affecting the "voice bearer". This would improve service continuity.
UE-AMBR
Notes from the Specs (3GPP TS 23.401, v9.2.0, section 4.7.3) regarding the UE-AMBR
parameter:
The UE-AMBR limits the aggregate bit rate that can be expected to be provided across
all Non-GBR bearers of a UE (e.g. excess traffic may get discarded by a rate shaping
function).
Each of those Non-GBR bearers could potentially utilize the entire UE-AMBR, e.g.
when the other Non-GBR bearers do not carry any traffic.
GBR bearers are outside the scope of UE AMBR.
The E-UTRAN enforces the UE-AMBR in uplink and downlink.
3G vs. SAE Bearers QoS Attributes Comparison
3G LTE/EPS
QCI (QoS Class
Residual BER
Identifier)
SDU error rate ARP
Delivery of
erroneous SDUs
Max bit rate Per bearer
Guaranteed bit
Max SDU size
rate
Delivery order UL/DL TFT
Transfer delay
Aggregate max
Traffic class bit rate Per terminal
Traffic handling
priority
• A single scalar parameter (QoS Class Identifier=QCI) is
ARP a pointer to a set of QoS parameters.
• QCI is also called Label in LTE.
Max bit rate • Simplified approach compared to 2G/3G where each
Guaranteed bit parameter is indicated separately.
rate
For public use – IPR applies
42 © Nokia Siemens Networks LTE/EPS Mobility & Session Management / Jose Maria Anarte / v2.0 / Document Number
QoS Class Identifier (QCI) Table in 3GPP
Priori
QCI Guarantee Delay budget Loss rate Application
ty
Nine pre-configured classes have been specified in 2 categories of Bearers: GBR and N-
GBR.
In addition, Operators can create their own QoS class identifiers (QCI)
Priority: used to define the priority for the Packet Scheduler function in the eNB
Delay Budget: helps the packet scheduler to ensure that users are scheduled sufficiently
often to guarantee the delay requirements of the Bearer.
Loss Rate tolerance is primarily intended for setting the RLC protocol settings (e.g.
number of RLC retransmissions). The label will most likely also include a priority
parameter, which the packet scheduler can use for differentiation.
SAE Bearer Usage Example
PDN
Gateway
IMAP server
(IP:A, UDP Port:a)
SIP UA
SIP server
VoIP (IP:B, UDP Port:b)
Codec
PDN
•The figure shows a UE with three applications running: e-mail, SIP user agent and VoIP
call. The voice over IP call was initiated via the SIP user agent. In this example we have
three applications running, although for the user the SIP UA and the VoIP call belong
together and form one service component.
•First let us analyze how many different QoS requirements we have. If we don’t want to
make a too fine split, we can say, that SIP signaling and e-mail is not so time sensitive.
So both could share a single SAE bearer with NGBR behavior and this could be the
default EPS bearer created when the user attached to the system.
•On other hand the VoIP call is obviously time critical, as speech codecs do not tolerate a
high delay or delay jitter. Thus for the speech call we would have to setup a SAE bearer
providing a minimum bit rate equal to the minimum useful bit rate the codec requires.
•So we end up with two SAE bearers, the default one for the e-mail application and the
SIP user agent. The second SAE bearer is a dedicated one and is used for the transfer of
the VoIP speech packets (usually IP/UDP/RTP datagrams).
•For the dedicated bearer we have to specify a DL and UL TFT to support the system in
its decision which IP datagrams will be transferred via which SAE bearer. In the simplest
from the TFT specify the IP addresses of the UE and the opposite VoIP client and their
allocated UDP port numbers for the VoIP call.
SAE bearer – GTP option shown on S5/S8
IP: A Serving PDN IP: B
eNB
Gateway Gateway Sgi
S1-U S5
PDN
Applic.
Applic.
IP
IP
Radio
Radio GTP-U T-PDU GTP-U T-PDU
Protocols
Protocols
IP Package IP Package IP Package IP Package
IP Source:A IP Source:A TEID-SG1 IP Source:A TEID-PG IP Source:A
IP Dest.:B IP Dest.:B IP Dest.:B IP Dest.:B
Radio Protocols
TEID-SG1 TEID-PG
TEID-eNB TEID-SG2
•SAE bearers consist of three segments: radio bearer, S1-U bearer and S5/S8 bearer.
•For the S5/S8 bearer between SAE GW and PDN GW there are two options mentioned. The first one is based
on the 2G/3G protocol GTP which is also used on S1-U. The second option for S5/S8 is based on Mobile IPv6
(MIPv6). As the latter is not completed yet, we discuss here only the GTP based S5/S8 interface.
•On the radio interface the SAE bearer is uniquely associated with one radio bearer RB. The radio bearer is
by the radio scheduler dynamically mapped to the available physical layer resources, this means, that a RB
does not allocate resources in a fixed manner for a long time. This provides the required flexibility for resource
re-assignments which WCDMA introduced with HSDPA.
•Between eNB and SAE GW the SAE bearer is tied to a single GTP-U tunnel. A GTP-U tunnel is identified by a
TEID (Tunnel Endpoint IDentifier) allocated by both endpoints - in this case one from eNB TEID-eNB and
one from SAE GW TEID-SG1. It is a task of the MME to exchange both TEIDs between eNB and SAE GW
during setup of the tunnel. Packets in the downlink will be sent in GTP-U frames (T-PDU) and will carry the
TEID-eNB in its header. The eNB must connect its TEID-eNB internally with the radio bearer. This also works
for uplink, where all data from the associated radio bearer will have to be sent on S1-U with the TEID-SG1 in
the GTP-U header.
•If the S5/S8 interface is based on GTP option, then we will also here find a GTP-U tunnel for the SAE bearer.
Again exactly one tunnel will be provided for the SAE bearer. The setup of the tunnel requires two new TEID -
one from SAE GW TEID-SG2 (usually different from TEID-SG1) and one from the PDN GW TEID-PG. The
communication principle is the same as on S1-U interface. But this time SAE GW and PDN GW handle the
exchange of their TEIDs for themselves. Therefore they use the control part of the GTP protocol which
provides messages to setup such tunnels. [NOTE: Which changes in GTP are required for this is currently
under investigation.]
•The SAE gateway is responsible to link the S1 GTP-U tunnel and the S5/S8 GTP-U tunnel with each other to
allow efficient forwarding of data between PDN GW and eNB. The PDN GW on the other hand must link its
tunnel to the external network and to the IP address of the UE inside this network. The DL TFT packet filters
support the PDN GW in the task to select the right GPT-U tunnel of a UE for an incoming IP datagram. The UL
TFT on the other hand is used at the UE side for the same task.
•It is important to note, how and when these tunnels and bearer segments are available. When a new SAE
bearer is setup usually a radio bearer, a S1 GTP-U tunnel and a S5/S8 GTP-U tunnel is created. The latter will
only be released, when the SAE bearer is released. Radio bearer and S1 GTP-U tunnel on the other hand will
be released when the UE enters an idle state. This state can be triggered due to inactivity. When this happens
the radio bearer is removed and the eNB will also clear the TEIDs from its memory for the UE (to be true, the
eNB will delete everything). The SAE GW therefore also must delete the TEID-eNB, but will usually keep its
own TEID-SG1. If there should be data to be sent later on, the UE must send a SERVICE REQUEST to the
MME to demand the re-establishment of the S1 GTP-U tunnel and the radio bearer. In short words, the S5/S8
tunnel is rather permanent, whereas radio bearer and S1 tunnel are dynamic with respect to the life time of a
SAE bearer.
Module Contents
• Attach
• S1 Release
• Detach
• Service Request
• Tracking Area Update (TAU)
• Dedicated Bearer Activation
• Handover
EMM_Deregistered
RRC_Connected
Attach Request
IMSI/old GUTI,old TAI,old GUMMEI, old ECGI
Authentication Response
Update Location (ME & MME Capabilities, IMEI, Update Type)
The attach procedure in LTE/EPS is quite similar to the GPRS attach in 2G/3G. It brings
the UE from EMM_DEREGISTERED state to EMM_REGISTERED. In addition to that
the procedure also establishes the default SAE bearer for the UE and thus allocates
the required IP addresses for the subscriber in the external packet data network.
1.- The UE connects to the serving cell and the associated eNB. The UE sends the
ATTACH REQUEST message (NAS) including IMSI/ old GUTI, old TAI, old GUMMEI
and old ECGI. The eNB selects an available MME and forwards the message to it.
2.-The first task of the MME is to identify and authenticate the subscriber. Thus it contacts
the HSS (in case IMSI is used for identification) or the old MME (in case the UE is
identified via old GUTI) with IDENTIFICATION REQUEST (GTP-C). The response
should contain the IMSI (when contacting old MME) and some authentication vectors
for the subscriber. (Flowchart shows direct contact with HSS).
3.-Using the authentication vectors from the old MME/HSS the new MME can start an
authentication procedure (NAS). The authentication mechanism is the same as in 3G.
4.-After a successful authentication the new MME can begin to update the HSS and
download the subscription data from there. This is achieved via Diameter procedures
UPDATE LOCATION and INSERT SUBSCRIBER DATA. During this process the
HSS will also force the old MME to clear the stored data about the subscriber using
the Diameter operation CANCEL LOCATION.
Attach (2/2) Reference to specs.: TS 23.401 section 5.3.2
5.-Based on the subscription data the new MME must decide whether a default bearer
has to be created or not. The default access point name (default APN) assists the
MME in selection of an appropriate SAE GW. To this serving gateway the CREATE
DEFAULT BEARER REQUEST message (GTP-C) is sent to. The SAE GW will now
create the S5/S8 tunnel. This is done with the same message, but sent to the PDN
GW.
6.-When the EPC resources for the default bearer are prepared, the new MME can give
the ATTACH ACCEPT message to eNB. The S1-AP message which will contain it is
the Initial Context Setup request and it will also hold the tunnel endpoint identifier
allocated by the Serving GW for S1-U interface. The eNB creates the radio bearer for
the default SAE bearer and returns ATTACH COMPLETE to the MME. The S1-AP
message this one is in will hold the TEID allocated by the eNB for S1-U interface. Via
an UPDATE BEARER procedure the MME will give this parameter to the Serving GW.
7.-Now the default SAE bearer is complete and the UE is in state EMM_REGISTERED
and ECM_CONNECTED.
S1 Release Reference to specs.: TS 23.401 section 5.3.5
ECM_Connected
S1 Release Request
Update Bearer Request
cause
release of eNB S1U resources
Update Bearer Response
S1 Release Command
RRC Connection Release
cause
RRC Connection Release Ack
S1 Release Complete
1.-The eNB can send the message S1 RELEASE REQUEST (S1-AP) to the MME to
request the release of all EUTRAN resources for a UE. The message can for instance
be triggered by detection of a too long inactivity period.
2.-When the MME gets a trigger to release the UE from EUTRAN, it will release the S1
tunnels allocated for the SAE bearers of the UE. This is done by sending an UPDATE
BEARER REQUEST message (GTP-C) to the Serving GW. In the message the
indication of the release of the S1 resources is contained.
3.-In parallel to the previous step the MME will send the S1-AP message S1 RELEASE
COMMAND to the eNB. It will trigger the release of the UE on the air interface with
message RRC CONNECTION RELEASE (RRC). This will bring the UE to RRC_IDLE
state and with that also to ECM_IDLE state. The UE acknowledges with RRC
CONNECTION RELEASE ACK.
Detach Reference to specs.: TS 23.401 section 5.3.8
Serving PDN
MME Gateway Gateway HSS
(SGW)
EMM-Registered
RRC_Connected
NAS Detach Request
Delete Bearer Request
switch off flag Delete Bearer Request
ECM_Connected
Delete Bearer Response
Delete Bearer Response
NAS: Detach Accepted IP Session
PCRF
Termination
EMM-Deregistered
RRC_Idle + ECM Idle
Note: Detach procedure initiated by UE.
For public use – IPR applies
51 © Nokia Siemens Networks LTE/EPS Mobility & Session Management / Jose Maria Anarte / v2.0 / Document Number
Serving PDN
MME Gateway Gateway HSS
(SGW)
EMM-Registered
RRC_Connected
NAS Detach Request
Delete Bearer Request
switch off flag Delete Bearer Request
ECM_Connected
Delete Bearer Response
Delete Bearer Response
NAS: Detach Accepted IP Session
PCRF
Termination
EMM-Deregistered
RRC_Idle + ECM Idle
Serving PDN
MME Gateway Gateway
(SGW)
RRC_Idle+ ECM_Idle
NAS Service Request Note: Service Request procedure
GUTI/S-TMSI, TAI, service type initiated by UE.
RRC_Connected
NAS Service Request
ECM_Connected
Authentication Request
authentication challenge
Authentication Response
Authentication response
Initial Context Setup Req.
1.-The UE sends the NAS message SERVICE REQUEST towards the MME encapsulated in an
RRC message to the eNodeB. If there are multiple MME connected to the eNB it is the task of
the eNB to select the right MME (the one the UE is registered with) from S-TMSI/GUTI and TAI.
The service type parameter indicates the above mentioned reason for the service request.
2.The eNodeB forwards NAS message to MME. NAS message is encapsulated in an S1-AP: Initial
UE Message (NAS message, TAI+ECGI of the serving cell, S-TMSI, CSG ID, CSG access
Mode).
3.NAS authentication procedures may be performed.
4.The MME sends S1-AP Initial Context Setup Request (Serving GW address, S1-TEID(s) (UL),
EPS Bearer QoS(s), Security Context, MME Signalling Connection Id, Handover Restriction
List,…) message to the eNodeB. This step activates the radio and S1 bearers for all the active
EPS Bearers. The eNodeB stores the Security Context, MME Signalling Connection Id, EPS
Bearer QoS(s) and S1-TEID(s) in the UE RAN context.
5.The eNodeB performs the radio bearer establishment procedure. The user plane security is
established at this step.When the user plane radio bearers are setup the Service Request is
completed and EPS bearer state is synchronized between the UE and the network
6.The uplink data from the UE can now be forwarded by eNodeB to the Serving GW. The eNodeB
sends the uplink data to the Serving GW address and TEID provided in the step 4. The Serving
GW forwards the uplink data to the PDN GW.
7.The eNodeB sends an S1-AP message Initial Context Setup Complete (eNodeB address, List of
accepted EPS bearers, List of rejected EPS bearers, S1 TEID(s) (DL)) to the MME.
8.The MME sends a Modify Bearer Request message (eNodeB address, S1 TEID(s) (DL) for the
accepted EPS bearers, Delay Downlink Packet Notification Request, RAT Type) to the Serving
GW. The Serving GW is now able to transmit downlink data towards the UE.
12.The Serving GW sends a Modify Bearer Response to the MME.
Service Request Reference to specs.: TS 23.401 section 5.3.4
Serving PDN
MME Gateway Gateway
(SGW)
RRC_Idle+ ECM_Idle
1.When the Serving GW receives a downlink data packet for a UE known as not user
plane connected (i.e. the S-GW context data indicates no downlink user plane TEID),
it buffers the downlink data packet and identifies which MME is serving that UE.
2.The Serving GW sends a Downlink Data Notification message to the MME for which it
has control plane connectivity for the given UE. The MME respond to the S-GW with
a Downlink Data Notification Ack message.
If the Serving GW receives additional downlink data packets for this UE, the Serving GW
buffers these downlink data packets and the Serving GW does not send a new
Downlink Data Notification.
3.The MME sends a Paging message (NAS ID for paging, TAI(s), UE identity based DRX
index, Paging DRX length, list of CSG IDs for paging) to each eNodeB belonging to
the tracking area(s) in which the UE is.
4.If eNodeBs receive paging messages from the MME, the UE is paged by the eNodeBs.
Steps 3-4 are omitted if the MME already has a signalling connection over S1-MME
towards the UE.
5.When UE is in the ECM-IDLE state, upon reception of paging indication in E-UTRAN
access, the UE initiates the UE triggered Service Request procedure
Tracking Area Update (TAU)
•Tracking area (TA) is similar to Location/Routing area in 2G/3G .
•TAI (Tracking Area Identity) = MCC (Mobile Country Code) + MNC (Mobile
Network Code) + TAC (Tracking Area Code).
•When UE is in ECM-Idle, MME knows UE location with Tracking Area
accuracy.
MME
Tracking area 2
Tracking area 1
RRC_Idle + ECM_Idle
TAU Request
Context Request
ECM_Connected
(Old GUTI/IMSI, complete TAU Request Message)
Context Response
Authentication Request (IMSI, IMEI,MSISDN, unused EPS Authentication vectors, KASME, etc…)
Authentication Response
MME determines if Serving
GW Change is needed
Context Acknowledge
Serving GW change Indication
Note: TAU with Serving GW Create Bearer Request
Update Bearer Request
change (IMSI, bearer contexts, RAT type)
(IP/TEID for new SGW-S5, RAT type)
Create Bearer Response Update Bearer Response
1.-The UE sends TRACKING AREA UPDATE REQUEST with its current GUTI or IMSI,
old TAI and EPS Bearer Status information to the eNB. This one has to forward the
message to a MME. If the old MME cannot be selected, then a new MME must be
chosen by the eNB.
2.-The new MME must first of all get the identity (IMSI) of the subscriber and authenticate
him/her. Therefore the new MME contacts the old one via GTP-C CONTEXT
REQUEST. The CONTEXT RESPONSE contains IMSI, authentication vectors, but
also all information about the currently active SAE bearers of this user.
3.-With one of the authentication vectors the new MME can start authentication.
4.-After a successful authentication the new MME analyzes if a Serving GW change is
needed
5.- New MME informs the old one that it is ready to take control over the UE (Context
Acknowledge message). The old MME will now start a timer and wait for the
cancellation of the subscriber record.
6.-In parallel to the previous step the new MME sends GTP-C CREATE BEARER
REQUEST to the Serving GW it has selected. The message will trigger the setup of
new S1 tunnels and trigger an update towards PDN GW. This will change the traffic
path from PDN GW to new Serving GW to new eNB.
TAU (2/2) Reference to specs.: TS 23.401 section 5.3.3
eNB new old new old
MME MME Serving Serving PDN HSS
MME MME Gateway Gateway Gateway
(SGW) (SGW)
Update Location
(new MME identity, IMSI, update type, …)
Cancel Location
7.-Also simultaneously with the previous steps the MME will update the HSS. During this
the HSS will cancel the subscriber record in the old MME. The old MME will of course
also delete the old tunnels in the old Serving GW.
8.-At the end the UE gets a NAS message TRACKING AREA UPDATE ACCEPT. In it a
new GUTI and new tracking area (or tracking area list) will be contained. The UE has
to acknowledge with TRACKING AREA UPDATE COMPLETE.
“Multi Tracking Area Registration” Concept
Paging Paging
RRC_Connected + ECM_Connected
For public use – IPR applies
60 © Nokia Siemens Networks LTE/EPS Mobility & Session Management / Jose Maria Anarte / v2.0 / Document Number
1.-The external data network triggers the request for a new IP connectivity bearer (SAE
bearer) via the PCRF connected to the PDN gateway that owns the default SAE
bearer of this user. This is sent in form of a Policy and Charging Control (PCC)
decision (QoS policy) from PCRF to PDN GW.
2.-The PDN GW first of all uses GTP-C CREATE DEDICATED BEARER REQUEST to
setup the tunnel between PDN GW and Serving GW.
3.-The Serving GW allocates the resources for the S5/S8 tunnel and forwards an
associated request to the MME for the S1 tunnel.
4.-If the UE is currently ECM_IDLE it must be paged. Thus the MME sends PAGING
messages of S1-AP protocol to all eNB that own cell’s of the UE’s current tracking
area (or tracking areas). If the UE receives such a paging it will respond with the
SERVICE REQUEST procedure. in the following the default SAE bearer will be re-
established.
Dedicated Bearer Activation (2/2)
Reference to specs.: TS 23.401 section 5.4.1
Serving PDN
MME Gateway Gateway PCRF
(SGW)
5.-The UE NAS layer builds a Session Management Response including EPS Bearer
Identity. The UE then sends a Direct Transfer (Session Management Response)
message to the MME.
6.- Upon reception of the Bearer Setup Response message and the Session
Management Response message in step 5, the MME acknowledges the bearer
activation to the Serving GW by sending a Create Bearer Response (EPS Bearer
Identity, S1-TEID) message.
7.-The Serving GW acknowledges the bearer activation to the PDN GW by sending a
Create Bearer Response (EPS Bearer Identity, S5/S8-TEID) message.
8.-If the dedicated bearer activation procedure was triggered by a PCC Decision
Provision message from the PCRF, the PDN GW indicates to the PCRF whether the
requested PCC decision (QoS policy) could be enforced or not, allowing the
completion of the PCRF-Initiated Session Modification procedure.
LTE/EPS Handover
• When the UE is in ECM_Connected state, mobility
handling takes place via network controlled handovers
with UE assistance.
• UE assistance here simply means that the UE sends
measurements and reports to the eNB to assist in the
handover decision.
• Currently it is planned that neighbour cells are based on
the UE’s cell detection capabilities rather than on a
network supplied neighbour cell list.
Source Target
eNB eNB
DATA FORWARDING
Downlink
–source eNB forwards all downlink RLC SDUs that have not been acknowledged by the
UE to the target eNB
–target eNB re-transmits and prioritize all downlink RLC SDUs forwarded by the source
eNB as soon as it obtains them
–reordering and duplication avoidance in the UE
•Uplink
–source eNB forwards all successfully received uplink RLC SDUs to the EPC
–UE re-transmits the uplink RLC SDUs that have not been successfully received by the
source eNB
–Reordering and duplication avoidance in EPC
Inter eNB Handover with X2 interface (1/2)
Reference to specs.: TS 23.401 section 5.5.1
ECM_Connected
7.-UE performs the final synchronization to target eNB and accesses the cell via RACH
procedure
(DL pre-synchronization is obtained during cell identification and measurements)
8.-Target eNB gives the uplink allocation and timing advance information
9.-Once synchronization between UE and the new cell is achieved, the UE confirms the
handover with RRC message HANDOVER CONFIRM. This will trigger a HANDOVER
COMPLETE message of S1-AP to be sent to the MME. It simply informs the MME that
now a new eNB is responsible for the UE. Thus this message will contain the IP
addresses and TEIDs of the target eNB for the S1 tunnels.Additionally it contains the
TAI and the target cell ECGI.
10.-The MME’s task is to send this information via GTP-C UPDATE BEARER REQUEST
to the Serving GW. This will switch the traffic path now completely from Serving GW
to target eNB.
11.-Serving Gateway switches the downlink data path to the target side.
12.-Serving Gateway sends an UPDATE BEARER RESPONSE message to MME.
13.-MME confirms the Handover Execution with the HANDOVER COMPLETE ACK
message.
14.-By sending RELEASE RESOURCE the target eNB informs success of handover to
source eNB and triggers the release of resources.
15.-Upon reception of the RELEASE RESOURCE message, the source eNB can release
radio and C-plane related resources associated to the UE context.
Module Contents
For further information, please refer to 3GPP TS 33.401 and TS 33.102 (SAE Security
Architecture)
EPS Authentication Procedure
MME HSS
NAS: attach Request
User Id, UE Capabilities, etc. Authentication Data Request
Signaling protection
•For core network (NAS) signaling, integrity
and confidentiality protection terminate in
MME.
•For radio network (RRC) signaling, integrity
and confidentiality protection terminate in
eNodeB.