Академический Документы
Профессиональный Документы
Культура Документы
1 EPS Architecture
Objectives
Whilst UMTS is based upon WCDMA technology, the 3GPP developed new specifications
for the LTE air interface based upon OFDMA (Orthogonal Frequency Division Multiple
Access) in the downlink and SC-FDMA (Single Carrier - Frequency Division Multiple Access)
in the uplink. This new air interface is termed the E-UTRA (Evolved - Universal Terrestrial
Radio Access).
l ESM (EPS Session Management) - is a Control Plane activity which manages the
activation, modification and deactivation of EPS bearer contexts. These can either be
default EPS bearer contexts or dedicated EPS bearer contexts.
User IP Adaptation
Radio Resource
Plane Function
Radio Resource
RRC, PDCP, RLC, MAC &
PHY Layer Protocols
In terms of the Physical Layer, the capabilities of the UE may be defined in terms of the
frequencies and data rates supported. Devices may also be capable of supporting adaptive
modulation including QPSK (Quadrature Phase Shift Keying), 16QAM (16 Quadrature
Amplitude Modulation) and 64QAM (Quadrature Amplitude Modulation).
In terms of the radio spectrum, the UE is able to support several scalable channels including;
1.4MHz, 3MHz, 5MHz, 10MHz, 15MHz and 20MHz whilst operating in FDD (Frequency
Division Duplex) and/or TDD (Time Division Duplex). Furthermore, the UE may also
support advanced antenna features such as MIMO (Multiple Input Multiple Output).
UE Identities
An LTE capable UE will be allocated / utilize a number of identities during operation within
the network. These include:
l IMSI (International Mobile Subscriber Identity) - this complies with the standard 3GPP
format and is comprised of the MCC (Mobile Country Code), MNC (Mobile Network
Code) and the MSIN (Mobile Subscriber Identity Number). This uniquely identifies a
subscriber from within the family of 3GPP technologies - GSM, GPRS, UMTS etc.
l IMEI (International Mobile Equipment Identity) - is used to uniquely identify the ME. It
can be further subdivided into a TAC (Type Approval Code), FAC (Final Assembly Code)
and SNR (Serial Number).
l GUTI (Globally Unique Temporary Identity) - is allocated to the UE by the MME
(Mobility Management Entity) and identifies a device to a specific MME. The identity is
comprised of a GUMMEI (Globally Unique MME Identity) and an M-TMSI (MME -
Temporary Mobile Subscriber Identity).
l S-TMSI (Serving - Temporary Mobile Subscriber Identity) - is used to protect a
subscribers IMSI during NAS (Non Access Stratum) signaling between the UE and
MME as well as identifying the MME from within a MME pool. The S-TMSI is
comprised of the MMEC (MME Code) and the M-TMSI.
l IP Address - the UE requires a routable IP address from the PDN (Packet Data Network)
from which it is receiving higher layer services. This may either be an IPv4 or IPv6
address.
Security in LTE is not solely limited to encryption and integrity protection of information passing across
the air interface but instead, NAS encryption and integrity protection between the UE and MME also
takes place. In addition, IPSec may also be used to protect user data within both the E-UTRAN and
EPC.
eNB Identities
In addition to the UE identities already discussed, there are a number of specific identities
associated with the eNB. These include:
l TAI (Tracking Area Identity) - is a logical group of neighboring cells defined by the
service provider in which UEs in LTE Idle mode are able to move within without
needing to update the network. As such, it is similar to a RAI (Routing Area Identity)
used in 2G and 3G packet switched networks.
l ECGI (E-UTRAN Cell Global Identifier) - is comprised of the MCC, MNC and ECI
(Evolved Cell Identity), the later being coded by each service provider.
Femto Cells
In order to improve both network coverage and capacity, the 3GPP have developed a new type
of base station to operate within the home or small business environment. Termed the HeNB
(Home Evolved Node B), this network element forms part of the E-UTRAN and in so doing
supports the standard E-UTRAN interfaces. However, it must be stated that HeNBs do not
support the X2 interface.
The architecture may include an HeNB-GW (Home Evolved Node B - Gateway) which
resides between the HeNB in the E-UTRAN and the MME / S-GW in the EPC in order to
scale and support large numbers of base station deployments.
l S-GW and PDN-GW Selection - upon receipt of a request from the UE to allocate a
bearer resource, the MME will select the most appropriate S-GW and PDN-GW. This
selection criterion is based on the location of the UE in addition to current load
conditions within the network.
l Tracking Area List Management and Paging - whilst in the LTE Idle state, the UE is
tracked by the MME to the granularity of a Tracking Area. Whilst UEs remain within the
Tracking Areas provided to them in the form of a Tracking Area List, there is no
requirement for them to notify the MME. The MME is also responsible for initiating the
paging procedure.
l Inter MME Mobility - if a handover involves changing the point of attachment within the
EPC, it may be necessary to involve an inter MME handover. In this situation, the
serving MME will select a target MME with which to conduct this process.
l Authentication - this involves interworking with the subscribers HSS (Home Subscriber
Server) in order to obtain AAA (Access Authorization and Accounting) information with
which to authenticate the subscriber. Like that of other 3GPP system, authentication is
based on AKA (Authentication and Key Agreement).
Uu Interface
The Uu Interface supports both a Control Plane and a User plane and spans the link between
the UE and the eNB / HeNB. The principle Control Plane protocol is RRC (Radio Resource
Control) while the User Plane is designed to carry IP datagrams.
X2 Interface
The X2 interface interconnects two eNBs and in so doing supports both a Control Plane and
User Plane. The principle Control Plane protocol is X2AP (X2 Application Protocol).
S1 Interface
The S1 interface can be subdivided into the S1-MME interface supporting Control Plane
signaling between the eNB and the MME and the S1-U Interface supporting User Plane traffic
between the eNB and the S-GW. The principle Control Plane protocol is S1AP (S1
Application Protocol).
packet switched mobility and uses the GTPv2-C and GTP-U protocols respectively. The
SGSN connects to the MME via the S3 Interface and the S-GW via the S4 Interface.
l EIR (Equipment Identity Register) - this database enables service providers to validate a
particular IMEI (International Mobile Equipment Identity) against stored lists. It
connects to the MME via the S13 Interface and uses the Diameter protocol for message
transfer.
2 EPS Protocols
Objectives
Control Plane
Figure 2-1 illustrates the concept of NAS and AS signaling, i.e. the Control Plane. It is worth
noting that the NAS signaling is effectively transparent to the E-UTRAN. Access Stratum
signaling provides a mechanism to deliver NAS signaling, as well as the lower layer signaling
required to setup, maintain and manage the connections. The X2 interfaces are also part of
this methodology and as such it also is part of Access Stratum signaling.
User Plane
The User Plane focuses on the delivery of IP datagrams to and from the EPC, namely the
S-GW and PDN-GW. Figure 2-2 illustrates this concept.
In the case of the User Plane the higher layer NAS is an IP datagram. This effectively is
delivered between the UE and the PDN-GW, with the eNB and S-GW acting as lower layer
relaying devices.
EMM Procedures
The key EMM procedures include:
l Attach - this is used by the UE to attach to an EPC (Evolved Packet Core) for packet
services in the EPS (Evolved Packet System). Note that it can be also used to attach to
non-EPS services.
l Detach - this is used by the UE to detach from EPS services. In addition, it can also be
used for other procedures such as disconnecting from non-EPS services.
l Tracking Area Updating - this procedure is always initiated by the UE and is used for the
various purposes. The most common include normal and periodic tracking area updating.
l Service Request - this is used by the UE to get connected and establish the radio and S1
bearers when uplink user data or signaling is to be sent.
l Extended Service Request - this is used by the UE to initiate a Circuit Switched fallback
call or respond to a mobile terminated Circuit Switched fallback request from the
network.
l GUTI Reallocation - this is used to allocate a GUTI (Globally Unique Temporary
Identifier) and optionally to provide a new TAI (Tracking Area Identity) list to a
particular UE.
l Authentication - this is used for AKA (Authentication and Key Agreement) between the
user and the network.
l Identification - this is used by the network to request a particular UE to provide specific
identification parameters, e.g. the IMSI (International Mobile Subscriber Identity) or the
IMEI (International Mobile Equipment Identity).
l Security Mode Control - this is used to take an EPS security context into use, and
initialize and start NAS signaling security between the UE and the MME with the
corresponding NAS keys and security algorithms.
l EMM Status - this is sent by the UE or by the network at any time to report certain error
conditions.
l EMM Information - this allows the network to provide information to the UE.
l Transport of NAS messages - this is to carry SMS (Short Message Service) messages in
an encapsulated form between the MME and the UE.
l Paging - this is used by the network to request the establishment of a NAS signaling
connection to the UE. Is also includes the Circuit Switched Service Notification
EMM Procedures
The key ESM procedures include:
l Default EPS Bearer Context Activation - this is used to establish a default EPS bearer
context between the UE and the EPC.
l Dedicated EPS Bearer Context Activation - this is to establish an EPS bearer context
with specific QoS (Quality of Service) and TFT (Traffic Flow Template) between the UE
and the EPC. The dedicated EPS bearer context activation procedure is initiated by the
network, but may be requested by the UE by means of the UE requested bearer resource
allocation procedure.
l EPS Bearer Context Modification - this is used to modify an EPS bearer context with a
specific QoS and TFT.
l EPS Bearer Context Deactivation - this is used to deactivate an EPS bearer context or
disconnect from a PDN by deactivating all EPS bearer contexts to the PDN.
l UE Requested PDN Connectivity - this is used by the UE to request the setup of a
default EPS bearer to a PDN.
l UE Requested PDN Disconnect - this is used by the UE to request disconnection from
one PDN. The UE can initiate this procedure to disconnect from any PDN as long as it is
connected to at least one other PDN.
l UE Requested Bearer Resource Allocation - this is used by the UE to request an
allocation of bearer resources for a traffic flow aggregate.
l UE Requested Bearer Resource Modification - this is used by the UE to request a
modification or release of bearer resources for a traffic flow aggregate or modification of
a traffic flow aggregate by replacing a packet filter.
l ESM Information Request - this is used by the network to retrieve ESM information, i.e.
protocol configuration options, APN (Access Point Name), or both from the UE during
the attach procedure.
l ESM Status - this is used to report at any time certain error conditions detected upon
receipt of ESM protocol data.
In the Control Plane, PDCP facilitates encryption and integrity checking of signaling
messages, i.e. RRC and NAS. The User Plane is slightly different since only encryption is
performed. In addition, the User Plane IP datagrams can also be subjected to IP header
compression techniques in order to improve the systems performance and efficiency. Finally,
PDCP also facilitates sequencing and duplication detection.
l TM (Transparent Mode) - this is utilized for some of the air interface channels, e.g.
broadcast and paging. It provides a connectionless service for signaling.
l UM (Unacknowledged Mode) - this is like Transparent Mode, in that it is a
connectionless service; however it has the additional features of sequencing,
segmentation and concatenation.
l AM (Acknowledged Mode) - this offers an ARQ (Automatic Repeat Request) service.
As such, retransmissions can be used.
These modes, as well as the other RLC features are illustrated in Figure 2-6. In addition to
ARQ, RLC offers segmentation, re-assembly and concatenation of information.
2.2.8 X2 Interface
As previously mentioned, the X2 interface interconnects two eNBs and in so doing supports
both a Control Plane and User Plane. The principle Control Plane protocol is X2AP (X2
Application Protocol). This resides on SCTP (Stream Control Transmission Protocol) where
as the User Plane IP is transferred using the services of GTP-U (GPRS Tunneling Protocol -
User) and UDP (User Datagram Protocol).
Figure 2-9 illustrates the X2 User Plane and Control Plane protocols.
SCTP is also found on the S1-MME Interface which links the eNB to the MME.
GTP-U is also found on the S1-U Interface which links the eNB to the S-GW and may also be used on
the S5 Interface linking the S-GW to the PDN-GW.
2.2.12 S1 Interface
The S1 interface can be subdivided into the S1-MME interface supporting Control Plane
signaling between the eNB and the MME and the S1-U Interface supporting User Plane traffic
between the eNB and the S-GW.
l NAS Signaling Transport - this is used for the transport of NAS related signaling over
the S1-MME Interface.
l UE Context Modification and Release - this allows for the modification and release of
the established UE Context in the eNB and MME respectively.
l Location Reporting - this enables the MME to be made aware of the UEs current
location within the network.
GTPv2-C is also found on the S5/S8 Interface between the S-GW and PDN-GW and the S10 Interface
between MMEs. Furthermore, it can also be found on the S3 and S4 interfaces when interconnecting
with an SGSN (Serving GPRS Support Node).
Logical channels are classified as either Control Logical Channels, which carry control data
such as RRC signaling, or traffic Logical Channels which carry User Plane data.
l CCCH (Common Control Channel) - this is used to establish a RRC (Radio Resource
Control) connection, also known as a SRB (Signaling Radio Bearer). The SRB is
discussed further in Section . The SRB is also used for
re-establishment procedures. SRB 0 maps to the CCCH.
l DCCH (Dedicated Control Channel) - this provides a bidirectional channel for signaling.
Logically there are two DCCH activated:
SRB 1 - this is used for RRC messages, as well as RRC messages carrying high
priority NAS signaling.
SRB 2 - this is used for RRC carrying low priority NAS signaling. Prior to its
establishment low priority signaling is sent on SRB1.
The DTCH is a bidirectional channel that can operate in either RLC AM or UM mode. This is
configured by RRC and is based on the QoS (Quality of Service) of the E-RAB (E-UTRAN -
Radio Access Bearer).
l BCH (Broadcast Channel) - this is a fixed format channel which occurs once per frame
and carries the MIB (Master Information Block). Note that the majority of System
Information messages are carries on the DL-SCH (Downlink - Shared Channel).
l PCH (Paging Channel) - this channel is used to carry the PCCH, i.e. paging messages. It
also utilizes DRX (Discontinuous Reception) to improve UE battery life.
l DL-SCH (Downlink - Shared Channel) - this is the main downlink channel for data and
signaling. It supports dynamic scheduling, as well as dynamic link adaptation. In
addition, it supports HARQ (Hybrid Automatic Repeat Request) operation to improve
performance. As previously mentioned it also facilitates the sending of System
Information messages.
l RACH (Random Access Channel) - this channel carries limited information and is used
in conjunction with Physical Channels and preambles to provide contention resolution
procedures.
l UL-SCH (Uplink Shared Channel) - this is similar to the DL-SCH, this channel supports
dynamic scheduling (eNB controlled) and dynamic link adaptation by varying the
modulation and coding. In addition, it also supports HARQ (Hybrid Automatic Repeat
Request) operation to improve performance.
l PRACH (Physical Random Access Channel) - this channel carries the Random Access
Preamble. The location of the PRACH is defined by higher layer signaling, i.e. RRC
signaling.
l PUCCH (Physical Uplink Control Channel) - this channel carries uplink control and
feedback. It can also carry scheduling requests to the eNB.
l PUSCH (Physical Uplink Shared Channel) - this is the main uplink channel and is used
to carry the UL-SCH (Uplink Shared Channel) Transport Channel. It carries both
signaling and user data, in addition to uplink control. It is worth noting that the UE is not
allowed to transmit the PUCCH and PUSCH at the same time.
In order to facilitate the multiplexing from Logical Channels to Transport Channels, the MAC
Layer typically adds a LCID (Logical Channel Identifier).
Objectives
The main functions associated with QoS in a packet switch (router) are the:
l Packet Classifier - this function analyses packets and based on a set of filters classifies
the packet. As such, it receives the correct packet forwarding treatment and scheduling.
l Packet Scheduler - this schedules packets based on priority. In so doing various methods
are used to ensure low latency data, e.g. voice, is optimally scheduled.
transport between the S-GW / PDN-GW and eNB according to the EPS QoS profile
associated with each EPS Bearer.
It is possible for the UE to establish more than one default EPS bearer, however this is via a different
APN (Access Point Name).
UE
eNB S-GW PDN-GW
SRB 1
SRB 2 RRC (High Priority)
E-UTRA Configuration
In order to achieve the QoS for the E-RAB the eNB configures the lower layer protocols,
namely PDCP, RLC, MAC and the Physical Layers.
There are various parameters that could be configured/modified to influence the performance
of the E-UTRA and thus aid the eNB QoS scheduling requirements. These include:
l PDCP Compression.
l RLC AM or UM.
l RLC AM Polling Configuration.
l Uplink MAC Priority.
l Uplink MAC Prioritized Bit Rate.
l Uplink MAC Bucket Size Duration.
l HARQ Configuration and re-transmissions.
l BSR (Buffer Status Report) Configuration.
l SPS (Semi Persistent Scheduling) Configuration.
l Physical Channel and Power Configuration.
Objectives
The Transport Network Layer Control Plane and User Plane both use the service of IP;
however a reliable robust delivery protocol in the form of SCTP (Stream Control
Transmission Protocol) exists within the Control Plane. In contrast, the User Plane utilizes
GTP-U and the services of the UDP (User Datagram Protocol). Note that an eNB may have
one or multiple IP addresses at the Transport Network Layer for both the Control and User
Planes.
The X2AP consists of various EP (Elementary Procedures). Table 4-1illustrates the mapping
between the functions provided by the X2 interface and the actual Elementary Procedure(s)
that are used to support this functionality.
The X2AP also supports various Class 2 procedures, i.e. EPs without a response message.
The role of the X2 interface may be divided into two main groups. These are:
l X2AP Basic Mobility Procedures - these relate to procedures used to handle the UE
mobility within E-UTRAN.
l X2AP Global Procedures - these relate to procedures that are not related to a specific
UE.
Presence
The presence of Information Elements within a message depends on a number of factors
including the scenario in which the message has been invoked. Consequently, Information
Elements may be:
l M (Mandatory) - these IE are always included in the message.
l O (Optional) - these IE may or may not be included in the message.
l C (Conditional) - these IE are included in the message only if the condition is satisfied.
Range
The Range indicates the number of copies of repetitive Information Elements that are allowed
in the message. E.g. there may be three cells configured and each has its associated
parameters.
Criticality
In each protocol message, there is criticality information set for individual and/or groups of IE
that comprise it. This criticality information instructs the receiver how to act when receiving
an IE that is in error or not comprehended. This criticality information may be applied as
follows:
l Null - no criticality information is applied explicitly.
Handover Request
The Handover Request message includes the following information:
l Old eNB UE X2AP ID - this provides the X2 signaling association for future messages
between the source and target eNBs.
l Cause - this element indicates to the MME the reason for the handover including reasons
such as the radio network layer, transport network layer etc.
l ECGI - this is the global id of the eNB and is expressed as a PLMN identity plus the
entire 28bit cell identity.
l GUMMEI (Globally Unique MME Identifier) - this is the identity of the MME that is
currently serving the UE.
l UE Context Information - this contains the following information:
MME UE S1AP ID - this provides the target eNB with the signaling association
reference with the MME across the S1-MME interface for specific UE.
UE Security Capabilities - this information element defines the UE capabilities in
terms of its RF, E-RAB formats etc. These are typically defined by referencing the
category of the LTE device.
AS Security Information - the purpose of the Security Context IE is to provide
security related parameters to the eNB. These are used to derive security keys for
User Plane traffic and RRC signaling messages and for security parameter generation
for subsequent X2 or intra eNB handovers.
UE Aggregate Maximum Bit Rate - this element is used to define the total bandwidth
in Mbit/s that can be allocated to the UE for all E-RABs that are established.
E-RABs to be Setup List - this identifies the E-RAB ID, E-RAB QoS, GTP
information and RRC Context for each EPS Bearer. The latter provides details on the
current configuration and the implementation of the air interface protocols.
l UE History Information -this is information about cells that a UE has been served by in
the active state prior to the target cell.
l Trace Activation - this O (Optional) parameter is able to start trace procedures on the
Target eNB. In so doing, it indicates which interfaces to trace and where to send the
information.
l SRVCC Operation Possible - this indicates to the target eNB whether SRVCC (Single
Radio Voice Call Continuity) is available, i.e. the UE can be handed over from the
E-UTRAN to CS (Circuit Switched) 2G/3G systems.
l Target eNB To Source eNB Transparent Container- this includes handover information
for the UE. This, in essence, is an RRC Connection Reconfiguration message defining
the lower layer configuration on the new cell.
l Criticality Diagnostics - this is sent by the eNB when parts of a received message have
not been comprehended or were missing, or if the message contained logical errors.
When applicable, it contains information about which parameters were not
comprehended or were missing.
SN Status Transfer
The SN Status Transfer procedure is used to transfer the uplink and downlink PDCP (Packet
Data Convergence Protocol) SN (Sequence Number) and HFN (Hyper Frame Number) status
from the source eNB to the target eNB during an X2 handover for each respective E-RAB for
which PDCP SN and HFN status preservation applies. These E-RAB(s) are identified in the
handover preparation phase based on the RRC Context parameters in the Handover Request.
The source eNB initiates the SN Status Transfer procedure. In so doing, it stops the
assignment of PDCP SNs to downlink SDUs and stops delivering uplink SDUs towards the
EPC (Evolved Packet Core). Finally it sends the SN Status Transfer message to the target
eNB.
For E-RAB that have had forwarding preservation agreed the source eNB forwards the uplink
packets to the target eNB and routes downlink packets to the target eNB that will assign its
own sequence numbers to the packets based on the value of the PDCP DL Count received
from the target eNB.
The information in the SN Status Transfer message includes:
l Old eNB UE X2AP ID - this is the X2 signaling association of the source eNB.
l New eNB UE X2AP ID - this is the X2 signaling association of the target eNB.
l E-RABs Subject to Transfer - this lists the E-RAB that have been identified to have
forwarding applied based on their QoS. Each E-RAB will have the following parameters
detailed for them:
Receive Status of UL PDCP SDUs - this optional parameter provides a bit map of
missing PDCP Sequence Numbers.
UL Count Value - this is the PDCP-SN and HFN of the next uplink SDU (Service
Data Unit) to be forwarded to the EPC.
DL Count Value - this is the PDCP-SN and HFN of the first downlink SDU to be
formatted into a PDCP SU for delivery to the UE.
UE Context Release
The UE Context Release message is sent once a handover has been successfully completed
and enables the source eNB to release all resources associated with the UE.
UE Context Release
Old eNB UE X2AP ID
eNB New eNB UE X2AP ID eNB
Source Target
UE Context Release
Handover Cancel
The Handover Cancel message is sent from the source eNB to the target eNB to cancel a
handover that is currently in progress.
Handover Cancel
Old eNB UE X2AP ID
New eNB UE X2AP ID
eNB eNB
Cause
Source Target
Handover Cancel
Figure 4-8 illustrates how two of the Load Indication message parameters can be set to
indicate the uplink overload and interference requirements on an eNB.
The Load Indication message also provides the Relative Narrowband Tx Power bitmap and
associated parameters. This effectively indicates to neighboring cells the power levels
transmitted per PRB.
The Reported Characteristics parameter is used to indicate: PRB Periodic, TNL load
Indication Periodic or HW Load Indication Periodic.
4.1.7 X2 Setup
The purpose of the X2 Setup procedure is to exchange application level configuration data
needed for two eNBs to interoperate correctly over the X2 interface. This procedure erases
any existing application level configuration data in the two nodes and replaces it by the one
received. This procedure also resets the X2 interface in a similar fashion to a Reset procedure.
X2 Setup Request
The X2 Setup Request message includes:
l Global eNB ID - this is the global id of the eNB and is expressed as the first 20bits of the
cell ID in the case of a macro eNB and for a home eNB it is the entire 28bit cell identity.
l Served Cells - this contains a list of the cells supported by the eNB. For each cell the
following information is provided:
ECGI (E-UTRAN Cell Global Identifier).
PCI (Physical Cell Identifier).
EARFCN (E-UTRA Absolute Radio Frequency Channel Number).
TAC (Tracking Area Code).
Broadcast PLMNs - including FDD and TDD configuration.
Neighbor Cells - including ECGI, PCI and EARFCN.
l GU Group ID (Globally Unique Group Identifier) - this is all the pools to which the eNB
belongs to.
X2 Setup Request
Global eNB ID
Served Cells
- Served Cell Information
- Neighbor Information
-- ECGI
-- PCI
-- EARFCN
GU Group Id List (C)
eNB eNB
X2 Setup Request
X2 Setup Response
X2 Setup Response
Global eNB ID
Served Cells
- Served Cell Information
- Neighbor Information
-- ECGI
-- PCI
-- EARFCN
GU Group Id List (C)
Criticality Diagnostics
X2 Setup Response
The X2 Setup Response message simply reflects the information included in the request but
this time the values are associated with the neighbor that received the request message.
GTP-U
SCTP UDP
IP IP
Layer 2 Layer 2
Layer 1 Layer 1
S1-MME S1-U
The S1AP also include various Class 2 procedures which are always considered to be
successful and therefore do not require a response.
4.2.3 S1 Setup
The S1 Setup procedure is used to exchange configured data which is required in the MME
and in the eNB respectively to ensure a proper interoperation. The S1 Setup procedure is
triggered by the eNB and is the first S1AP procedure which will be executed. Figure 4-15
illustrates the S1 Setup Request parameters.
The eNB informs the MME of its Global eNB Identity, supported TA (Tracking Areas),
Broadcasted PLMN(s) and CSG information, as well as Default Paging DRX information.
In response to the S1 Setup Request messages the MME sends a S1 Setup Response. This
includes the served GUMMEI(s) and relative MME capacity. In addition, this message can
also include a MME name, e.g. Primary MME.
Initial UE Message
When the eNB has received, from the radio interface, the first Uplink NAS message
transmitted on an RRC connection to be forwarded to an MME, the eNB invokes the NAS
Transport procedure and sends the Initial UE Message to the MME including the NAS
message as a NAS-PDU. Note that the first Uplink NAS message is always received in the
RRC Connection Setup Complete message.
The Downlink NAS Transport message contains the identifiers referencing the UE, the
NAS-PDU and a possible Handover Restriction List. The latter is used to update the eNB on
roaming area or access restrictions.
The Uplink NAS Transport message is similar, however the current E-UTRAN CGI and TAI
are added.
l Handover Restriction List - this optional parameter is used to update the eNB on roaming
area or access restrictions.
l UE Radio Capability - this optional parameter provides the eNB with initial UE radio
capability.
l Subscriber Profile ID for RAT/Frequency Priority - this optional parameter is used to
define camp priorities in Idle Mode and to control inter-RAT/inter-frequency handover in
Active Mode.
l CS Fallback Indicator - this optional parameter indicates that a fallback to the CS domain
is needed.
l SRVCC Operation Possible - this optional parameter indicates if SRVCC is possible.
UE Context Modification
The purpose of the UE Context Modification procedure is to modify the established UE
Context. It enables the MME to modify the:
l Security Key.
l Subscriber Profile ID for RAT/Frequency priority.
l UE Aggregate Maximum Bit Rate.
l CS Fallback Indicator.
Figure 4-22 illustrates the E-RAB Setup Response message and the eNB E-RAB address
parameters for downlink data delivery.
If the eNB wants to remove all remaining E-RABs e.g. for user inactivity, the UE Context Release
Request procedure is used instead.
4.2.8 S1 Handover
The E-UTRAN supports multiple scenarios for handover, for example intra MME, inter MME,
inter S-GW, inter RAT, etc. For these different scenarios typically the same message set is
used, however the information elements within the messages may be different. A handover
involves three phases:
l Handover preparation.
l Handover resource allocation.
l Handover notification.
eNB
Source MME
Handover Required
Handover Required
MME UE S1AP ID
eNB UE S1AP ID
Handover Type
Cause
Target ID
Direct Forwarding Path Availability (O)
SRVCC HO Indication (O)
Source to Target Transparent Container
Source to Target Transparent Container Secondary (O)
MS Classmark 2 (C) if SRVCC to GERAN
MS Classmark 3 (C) if SRVCC to GERAN
The Request Type parameter is part of Location Reporting and is detailed in Section 4.2.15
4.2.13 Reset
The purpose of the Reset procedure is to initialize or re-initialize the E-UTRAN, or part of
E-UTRAN S1AP UE-related contexts, in the event of a failure in the EPC or vice versa.
Trace Start
The purpose of the Trace Start procedure is to allow the MME to request the eNB to start a
trace session for a UE in ECM_Connected mode.
The Trace Activation parameter includes:
l E-UTRAN Trace ID - this is the E-UTRAN Trace ID and is composed of the Trace
Reference (leftmost 6 octets) and Trace Recording Session Reference (last 2 octets).
l Interfaces To Trace - this is a bit map with each position represents a eNB interface. The
first bit =S1-MME, second bit =X2, third bit =Uu with all other bits reserved for future
use. The value 1 indicates should be traced and the value 0 indicates should not be
trace.
l Trace depth - this indicates the level of the trace, options include:
Minimum.
Medium.
Maximum.
Minimum without Vendor Specific Extension.
Medium without Vendor Specific Extension.
Maximum without Vendor Specific Extension.
l Trace Collection Entity IP Address - this is the Transport Layer Address to send the trace.
Deactivate Trace
The purpose of the Deactivate Trace procedure is to allow the MME to request the eNB to
stop the trace session, for the indicated trace reference.
4.2.16 Overload
The purpose of the Overload Start procedure is to inform an eNB to reduce the signaling load
towards the concerned MME.
The Overload Start message indicates the Overload Action to be performed. This is either:
l Reject all RRC connection establishments for non-emergency Mobile Originated Direct
Transfer.
l Reject all RRC connection establishments for Signaling.
l Permit Emergency Sessions only.
Overload Stop
The purpose of the Overload Stop procedure is to signal to an eNB the MME is connected to
that the overload situation at the MME has ended and normal operation can resume.
4.2.18 Paging
The paging of UEs in Idle Mode is facilitated by the MME to send a Paging message to all
eNBs managing the UEs TAI (Tracking Area Identity) or TAIs. Figure 4-39 illustrates the
Paging message and its parameter.
Each GTP Tunnel supports one EPS Bearer, i.e. E-RAB. Thus multiple tunnels exist for multiple UEs.
l S (Sequence) - this flag indicates the presence of a meaningful value of the Sequence
Number field. For the Echo Request, Echo Response, Error Indication and Supported
Extension Headers Notification messages, the S flag is be set to '1'. Since the use of
Sequence Numbers is optional for G-PDUs, the PDN-GW, S-GW and eNB should set the
flag to '0'. However, when a G-PDU is being relayed by the Indirect Data Forwarding for
Inter RAT HO procedure, then if the received G-PDU has the S flag set to '1', then the
relaying entity shall set S flag to '1' and forward the G-PDU.
l PN (N-PDU Number) - this flag indicates the presence of a meaningful value of the
N-PDU Number field. When it is set to '1', the N-PDU Number field is present and
interpreted.
l Message Type - this field indicates the type of GTP-U message.
l Length - this field indicates the length in octets of the payload, i.e. the rest of the packet
following the mandatory part of the GTP header (that is the first 8 octets).
l TEID (Tunnel Endpoint Identifier) - this field unambiguously identifies a tunnel
endpoint in the receiving GTP-U protocol entity. The receiving end side of a GTP tunnel
locally assigns the TEID value the transmitting side has to use. The TEID is used by the
receiving entity to find the EPS Bearer, except for the following cases:
The Echo Request/Response and Supported Extension Headers notification messages,
where the Tunnel Endpoint Identifier is set to all zeroes.
The Error Indication message where the Tunnel Endpoint Identifier is set to all zeros.
Optional Fields
l Sequence Number - this is used for G-PDUs, an increasing sequence number for the
original IP packets transmitted via GTP-U tunnels, when transmission order must be
preserved.
l N-PDU Number - this is used at the Inter SGSN Routing Area Update procedure and
some inter-system handover procedures (e.g. between 2G and 3G radio access networks).
It coordinates the data transmission for acknowledged mode of communication between
the 2G MS (Mobile Station) and the SGSN (Serving GPRS Support Node).
l Next Extension Header Type - this defines the type of Extension Header that follows this
field in the GTP-PDU, e.g. PDCP PDU number.
Following the Extension Header Content a Next Extension Header Content is added. This
indicates if an additional extension header is added, if not, it is set to zero.
Currently there are two defined extension headers, namely UDP Port and PDCP PDU number.
For the GTP-U tunnel setup between two nodes for forwarding user traffic, e.g. between eNBs
for direct forwarding over X2, Echo Request path maintenance message are not sent except if
the forwarded data and the normal data are sent over the same path.
Path Failure
A path counter is used to manage each path. This is used in conjunction with a T3-Response
Timer and N3-Requests parameter. The path counter is reset each time an Echo Response is
received on the path and incremented when the T3-Response Timer expires for any Echo
Request message sent on the path. The path is classed as down if the counter exceeds
N3-Requests. In this case, the GTP-U peer may notify the Operation and Maintenance
network element. In addition, the GTP-U peer will also notify the upper layer of the path
failure, so that EPS contexts associated with the path may be deleted. The recommended
value for the N3-Requests parameter is 5 and the T3-Response Timer is usually 20 seconds.
This message is sent only in case a GTP entity was required to interpret a mandatory
Extension Header but the GTP entity was not yet upgraded to support that extension header.
The peer GTP entity may retry to use all the extension headers with that node, in an attempt to
verify it has been upgraded.
5 Glossary
G M (Mandatory)
MAC (Medium Access Control)
GBR (Guaranteed Bit Rate) MAC-I (Message Authentication
GERAN (GSM/EDGE Radio Code - Integrity)
Access Network) MAG (Mobile Access Gateway)
GTP (GPRS Tunneling Protocol) MCC (Mobile Country Code)
GTP-U (GPRS Tunneling ME (Mobile Equipment)
Protocol - User) MIB (Master Information Block)
GTPv1-U (GPRS Tunneling MIMO (Multiple Input Multiple
Protocol Version 1 - User Plane) Output)
GTPv2-C (GPRS Tunneling MME (Mobility Management
Protocol Version 2 - Control) Entity)
GU Group ID (Globally Unique MMEC (MME Code)
Group Identifier) MNC (Mobile Network Code)
GUMMEI (Globally Unique MS (Mobile Station)
MME Identifier) MSB (Most Significant Bits)
GUTI (Globally Unique MSIN (Mobile Subscriber
Temporary Identity) Identity Number)
M-TMSI (MME - Temporary
H Mobile Subscriber Identity)
HA (Home Agent) N
HARQ (Hybrid Automatic Repeat
Request) NAS (Non Access Stratum)
HeNB (Home Evolved Node B) non-GBR (non - Guaranteed Bit
HeNB-GW (Home Evolved Node Rate)
B - Gateway) NSAPI (Network layer Service
HFN (Hyper Frame Number) Access Point Identifier)
HPLMN (Home Public Land
Mobile Network) O
HRPD (High Rate Packet Data) O (Optional)
HSS (Home Subscriber Server) O&M (Operations and
I Maintenance)
OFDMA (Orthogonal Frequency
IE (Information Elements) Division Multiple Access)
IETF (Internet Engineering Task
Force) P
P (Polling)