04 - TM51154EN04GLA2 - LTE Air Interface Overview

LTE/EPS Mobility & Session Management
TM51153EN04GLA2 1
TM51153EN04GLA2 2
TM51153EN04GLA2 4
TM51153EN04GLA2 5
TM51153EN04GLA2 6
TM51153EN04GLA2 7
- The CellId is a System Level parameter

- The PhyCellID is a Physical level parameter
- UE gets the PhyCellID from the Primary and Secondary Synchronization Signals (PSS and SSS)
PSS: provides the PhyCellID sector: 0..2
SSS: provides the PhyCellID group: 0…167
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.
TM51153EN04GLA2 8
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 9
• 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 10
TM51153EN04GLA2 11
TM51153EN04GLA2 12
TM51153EN04GLA2 13
•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 14
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 15
TM51153EN04GLA2 17
TM51153EN04GLA2 18
TM51153EN04GLA2 19
TM51153EN04GLA2 20
TM51153EN04GLA2 21
TM51153EN04GLA2 22
More about LTE Mobility and Connection States on 3GPP TS23.401
TM51153EN04GLA2 23
TM51153EN04GLA2 24
TM51153EN04GLA2 25
TM51153EN04GLA2 26
TM51153EN04GLA2 27
TM51153EN04GLA2 28
TM51153EN04GLA2 29
TM51153EN04GLA2 30
TM51153EN04GLA2 31
TM51153EN04GLA2 32
• For further information about the EPS Bearer, please refer to 3GPP TS 23.401,
v9.2.0, section 4.7.2
TM51153EN04GLA2 33
• 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 34
• 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 35
• 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 36
• 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 37
• 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 38
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 39
GBR identifies the bit rate that will be ensured to the bearer.
TM51153EN04GLA2 40
TM51153EN04GLA2 41
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 42
TM51153EN04GLA2 43
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 44
• 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 45
• 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 46
TM51153EN04GLA2 47
TM51153EN04GLA2 48
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.
TM51153EN04GLA2 49
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.
TM51153EN04GLA2 50
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.
TM51153EN04GLA2 51
The transition to EMM_DEREGISTERED state is achieved by the NAS detach

procedure.
The Detach procedure allows:

− the UE to inform the network that it does not want to access the EPS any
longer
− the network to inform the UE that it does not have access to the EPS
any longer
The UE is detached either explicitly or implicitly:

− Explicit detach: The network or the UE explicitly requests detach and
signal with each other
− Implicit detach: The network detaches the UE, without notifying the UE.
This is typically the case when the network presumes that it is not able
to communicate with the UE, e.g. due to radio conditions.
The procedure consists of the DETACH REQUEST / DETACH ACCEPT procedure

between UE and MME and the DELETE BEARER procedure between MME and
Serving GW and PDN GW. Furthermore at the end the S1 RELEASE procedure
between MME and eNB deletes all radio resources.
TM51153EN04GLA2 52
The transition to EMM_DEREGISTERED state is achieved by the NAS detach

procedure.
The Detach procedure allows:

− the UE to inform the network that it does not want to access the EPS any
longer
− the network to inform the UE that it does not have access to the EPS
any longer
The UE is detached either explicitly or implicitly:

− Explicit detach: The network or the UE explicitly requests detach and
signal with each other
− Implicit detach: The network detaches the UE, without notifying the UE.
This is typically the case when the network presumes that it is not able
to communicate with the UE, e.g. due to radio conditions.
The procedure consists of the DETACH REQUEST / DETACH ACCEPT procedure

between UE and MME and the DELETE BEARER procedure between MME and
Serving GW and PDN GW. Furthermore at the end the S1 RELEASE procedure
between MME and eNB deletes all radio resources.
TM51153EN04GLA2 53
• 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 54
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 55
A Tracking Area Update takes place if:

− UE detects it has entered a new Tracking Area that is not in the list of TAIs that
the UE registered with the network;
− the periodic Tracking Area update timer has expired;
TM51153EN04GLA2 56
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.
TM51153EN04GLA2 57
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.
TM51153EN04GLA2 58
TM51153EN04GLA2 59
TM51153EN04GLA2 60
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 61
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 62
TM51153EN04GLA2 63
TM51153EN04GLA2 64
TM51153EN04GLA2 65
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 66
1. The source eNB configures the UE measurement procedures with

MEASUREMENT CONTROL
2. UE is triggered to send MEASUREMENT REPORT to the source eNB. It can be
event triggered or periodic.
3. Source eNB makes handover decision based on UE report + load and service
information.
4. When the source (current serving) eNB decides to start a handover of an UE to a
neighbor cell in a new (target) eNB it will contact this target eNB. This is done via
the X2-AP message HANDOVER REQUEST. The message will contain the
target cell for the UE, the current serving MME and SAE GW. It is task of the
target eNB to allocate virtual capacity in the target cell via its admission control
function.
5. If this is done the target eNB returns part of the handover message for the UE
within the X2-AP message HANDOVER REQUEST ACKNOWLEDGE. In this
message also a data forwarding tunnel (TEID from target eNB) is indicated. It
allows the source eNB to forward still buffered or still arriving downlink packets to
the target eNB.
6. The source eNB can now give the HANDOVER COMMAND (RRC) to the UE.
The command contains the configuration for the UE in the new cell and possibly
already an UL/DL resource allocation. The UE will detach from the old cell and
synchronize itself to the new cell. In the mean time the source eNB can start
downlink packet forwarding via X2 interface.
TM51153EN04GLA2 67
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.
TM51153EN04GLA2 68
TM51153EN04GLA2 69
For further information, please refer to 3GPP TS 33.401 and TS 33.102 (SAE
Security Architecture)
TM51153EN04GLA2 70
TM51153EN04GLA2 71
TM51153EN04GLA2 72
• The generation of keys is triggered by Authentication and Key Agreement (AKA)

procedures.
• In LTE the MME acts as the Access Security Management Entity (ASME). This
is the access network entity that receives top level keys from the HSS.
• UMTS AKA is capable of agreeing two keys, CK and IK, on the USIM and in the
AuC. For LTE these keys never leave the HSS. Instead they are used to derive
KASME, which is transferred from the HSS to the MME as part of the
Authentication Vector.
• The keys used for UP, NAS and AS protection shall be dependent on the
algorithm with which they are used.
• The keys used for UP, NAS and RRC (AS) protection shall be dependent on the
algorithm with which they are used.
TM51153EN04GLA2 73
TM51153EN04GLA2 74
TM51153EN04GLA2 75
KEY GENERATION PROCEDURE
1. When a UE initially attaches to the network the MME will authenticate the
subscriber using UMTS4 AKA . This triggers generation of security keys by the
UE and HSS. At this point the UE and HSS know the PLMN ID which is used in
the generation of KASME.
2. The UE and HSS generate CK and IK from K and the RAND value used in
UMTS-AKA.
3. The UE and HSS derive KASME from CK, IK and PLMN-ID.
4. The HSS transfers KASME to the MME as part of the Authentication Vector used
in EPS AKA.
5. Once the UE has successfully been authenticated the MME and UE generate the
keys for NAS signaling security - KNAS int and KNAS enc
6. The MME and UE generate the KeNB key from KASME and the eNB-ID.
7. The MME transfers KeNB to the eNB across the S1-MME. This key is
transferred as part of the Initial Context Setup Request message to the eNB.
8. The eNB and UE generate the keys used for protection of RRC signaling (KeNB
RRC-int and KeNB RRC-enc) and U-plane traffic (KeNB UP-enc), using KeNB.
TM51153EN04GLA2 76
TM51153EN04GLA2 77

04 - TM51154EN04GLA2 - LTE Air Interface Overview

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

04 - TM51154EN04GLA2 - LTE Air Interface Overview

Caricato da

Copyright:

Formati disponibili

LTE/EPS Mobility & Session Management

- The CellId is a System Level parameter

why a TAU is necessary in the connected state?

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

• An E-RAB (E-UTRAN Radio Access Bearer) refers to the concatenation of an S1

• Default bearer is established during the attach phase.

Nine pre-configured classes have been specified in 2 categories of Bearers: GBR

The QoS attributes associated with the QCI parameter are:

The transition to EMM_DEREGISTERED state is achieved by the NAS detach

The Detach procedure allows:

The UE is detached either explicitly or implicitly:

The procedure consists of the DETACH REQUEST / DETACH ACCEPT procedure

The transition to EMM_DEREGISTERED state is achieved by the NAS detach

The Detach procedure allows:

The UE is detached either explicitly or implicitly:

The procedure consists of the DETACH REQUEST / DETACH ACCEPT procedure

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

A Tracking Area Update takes place if:

5. The UE NAS layer builds a Session Management Response including EPS

1. The source eNB configures the UE measurement procedures with

• The generation of keys is triggered by Authentication and Key Agreement (AKA)

KEY GENERATION PROCEDURE

Potrebbero piacerti anche