Вы находитесь на странице: 1из 69

LTE/EPS Mobility & Session Management

TM51153EN04GLA2 1
LTE/EPS Mobility & Session Management

TM51153EN04GLA2 2
LTE/EPS Mobility & Session Management

TM51153EN04GLA2 3
LTE/EPS Mobility & Session Management

TM51153EN04GLA2 4
LTE/EPS Mobility & Session Management

TM51153EN04GLA2 5
LTE/EPS Mobility & Session Management

TM51153EN04GLA2 6
LTE/EPS Mobility & Session Management

why a TAU is necessary in the connected state?


The answer to that question can be found in the message sequence charts for handovers.
For example: during an X2 handover, which is directly negotiated between two base stations,
the Mobility Management Entity (MME) in core network is only informed of the handover
after it has taken place. Also, there's no direct communication between the MME and the
mobile device during the handover procedure. That means that in case the new cell is in a
new tracking area, the mobile has to update its tracking area list as that information was not
contained in the handover messaging.
From a logical point of view that also makes sense. Tracking areas are administered by the
core network (by the Non Access Stratum) while handovers are performed by the access
network. Also, the signaling does not interrupt the user data transfer so there are no side
effects of performing this procedure in connected mode and while transferring data.

TM51153EN04GLA2 7
LTE/EPS Mobility & Session Management

• 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.

TM51153EN04GLA2 8
LTE/EPS Mobility & Session Management

TM51153EN04GLA2 9
LTE/EPS Mobility & Session Management

TM51153EN04GLA2 10
LTE/EPS Mobility & Session Management

•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

TM51153EN04GLA2 11
LTE/EPS Mobility & Session Management

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.

TM51153EN04GLA2 12
LTE/EPS Mobility & Session Management

Because MME pool areas can overlap, care must be taken to ensure that MMEs serving the
overlapping areas are not allocated the same MMECs.

TM51153EN04GLA2 13
LTE/EPS Mobility & Session Management

TM51153EN04GLA2 14
LTE/EPS Mobility & Session Management

TM51153EN04GLA2 15
LTE/EPS Mobility & Session Management

TM51153EN04GLA2 16
LTE/EPS Mobility & Session Management

TM51153EN04GLA2 17
LTE/EPS Mobility & Session Management

TM51153EN04GLA2 18
LTE/EPS Mobility & Session Management

TM51153EN04GLA2 19
LTE/EPS Mobility & Session Management

More about LTE Mobility and Connection States on 3GPP TS23.401

TM51153EN04GLA2 20
LTE/EPS Mobility & Session Management

TM51153EN04GLA2 21
LTE/EPS Mobility & Session Management

TM51153EN04GLA2 22
LTE/EPS Mobility & Session Management

TM51153EN04GLA2 23
LTE/EPS Mobility & Session Management

TM51153EN04GLA2 24
LTE/EPS Mobility & Session Management

TM51153EN04GLA2 25
LTE/EPS Mobility & Session Management

TM51153EN04GLA2 26
LTE/EPS Mobility & Session Management

TM51153EN04GLA2 27
LTE/EPS Mobility & Session Management

TM51153EN04GLA2 28
LTE/EPS Mobility & Session Management

TM51153EN04GLA2 29
LTE/EPS Mobility & Session Management

• For further information about the EPS Bearer, please refer to 3GPP TS 23.401, v9.2.0,
section 4.7.2

TM51153EN04GLA2 30
LTE/EPS Mobility & Session Management

• 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.

TM51153EN04GLA2 31
LTE/EPS Mobility & Session Management

• 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

TM51153EN04GLA2 32
LTE/EPS Mobility & Session Management

• Default bearer is established during the attach phase.


• Dedicated bearers are established based on the services running between the UE and
the PDN/IMS.
• A comparison can be made between the dedicated bearer in EPS and the secondary
PDP context in UMTS.
• TS 29.274 defines the create bearer request message. This request is used to establish
dedicated bearers but not default bearer.
• Reading from the specs, it may lead to a confusion the following sentence: “the
dedicated bearers are network initiated”. Because LTE/EPS is all on IP and if you are
receiving a call then network may initiate dedicated bearer to forward that call to you.
This doesn't mean that UE cannot ask for dedicated bearers. UE can ask for dedicated
bearers by sending out bearer modification command but UE cannot send create bearer
request. Bearer modification command will make PDN trigger a dedicated bearer.

TM51153EN04GLA2 33
LTE/EPS Mobility & Session Management

• 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.

TM51153EN04GLA2 34
LTE/EPS Mobility & Session Management

Benefits
This feature offers the possibility to use different applications with
varying bearer QoS requirements, including congestion situations.
Voice, real time gaming and also video applications have stringent
application specific QoS requirements, supported with different QCIs
and dedicated bearers. On the other hand, there are applications which
can be satisfied with less demanding QCI requirements or QoS
requirements, such as file transfer. The user, as well as the operator,
benefits when resource use is optimal in the network, as this ensures
both availability as well as cost efficiency.
Dedicated bearer
Dedicated bearer is supported to provide QoS differentiation for applications having
Different QoS requirements, and to ensure optimal resource use in operator’s network.
Dedicated bearers roughly corresponds to 2G/3G secondary PDP contexts.
Once the UE has initiated a default bearer with a particular APN, a dedicated bearer may
be established with the same APN and IP addresses but with different QoS parameters
to meet specific application needs, such as IMS voice, IMS signalling, video streaming,
and file transfer.

TM51153EN04GLA2 35
LTE/EPS Mobility & Session Management

• 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.

TM51153EN04GLA2 36
LTE/EPS Mobility & Session Management

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)

TM51153EN04GLA2 37
LTE/EPS Mobility & Session Management

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)

The QoS attributes associated with the QCI parameter are:

• 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.

TM51153EN04GLA2 38
LTE/EPS Mobility & Session Management

GBR identifies the bit rate that will be ensured to the bearer.

TM51153EN04GLA2 39
LTE/EPS Mobility & Session Management

TM51153EN04GLA2 40
LTE/EPS Mobility & Session Management

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.

TM51153EN04GLA2 41
LTE/EPS Mobility & Session Management

• 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.

TM51153EN04GLA2 42
LTE/EPS Mobility & Session Management

• 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.

TM51153EN04GLA2 43
LTE/EPS Mobility & Session Management

TM51153EN04GLA2 44
LTE/EPS Mobility & Session Management

TM51153EN04GLA2 45
LTE/EPS Mobility & Session Management

TM51153EN04GLA2 46
LTE/EPS Mobility & Session Management

TM51153EN04GLA2 47
LTE/EPS Mobility & Session Management

TM51153EN04GLA2 48
LTE/EPS Mobility & Session Management

TM51153EN04GLA2 49
LTE/EPS Mobility & Session Management

TM51153EN04GLA2 50
LTE/EPS Mobility & Session Management

• From time to time a UE must switch from ECM_Idle to ECM_connected


• The reasons for this might be UL data is available, UL signaling is pending (e.g. tracking area update, detach) or a
paging from the network was received.

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 signaling 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 signaling 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.
9. The Serving GW sends a Modify Bearer Response to the MME.

TM51153EN04GLA2 51
LTE/EPS Mobility & Session Management

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 signaling 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.

TM51153EN04GLA2 52
LTE/EPS Mobility & Session Management

TM51153EN04GLA2 53
LTE/EPS Mobility & Session Management

TM51153EN04GLA2 54
LTE/EPS Mobility & Session Management

TM51153EN04GLA2 55
LTE/EPS Mobility & Session Management

TM51153EN04GLA2 56
LTE/EPS Mobility & Session Management

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.

TM51153EN04GLA2 57
LTE/EPS Mobility & Session Management

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.

TM51153EN04GLA2 58
LTE/EPS Mobility & Session Management

TM51153EN04GLA2 59
LTE/EPS Mobility & Session Management

TM51153EN04GLA2 60
LTE/EPS Mobility & Session Management

TM51153EN04GLA2 61
LTE/EPS Mobility & Session Management

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

TM51153EN04GLA2 62
LTE/EPS Mobility & Session Management

TM51153EN04GLA2 63
LTE/EPS Mobility & Session Management

For further information, please refer to 3GPP TS 33.401 and TS 33.102 (SAE Security
Architecture)

TM51153EN04GLA2 64
LTE/EPS Mobility & Session Management

TM51153EN04GLA2 65
LTE/EPS Mobility & Session Management

TM51153EN04GLA2 66
LTE/EPS Mobility & Session Management

TM51153EN04GLA2 67
LTE/EPS Mobility & Session Management

TM51153EN04GLA2 68
LTE/EPS Mobility & Session Management

TM51153EN04GLA2 69