Professional Documents
Culture Documents
RRC Connection Request: Ue-Identity (Initial UE-Identity) : This IE Is Included To Facilitate Contention
RRC Connection Request: Ue-Identity (Initial UE-Identity) : This IE Is Included To Facilitate Contention
The RRC CONNECTION SETUP message is used to establish SRB1. It contains configuration information for SRB1.
This allows subsequent signaling to use the DCCH logical channel. The configuration for SRB1 can be a specific
configuration or the default configuration.
The RRC CONNECTION SETUP message may also contain configuration for PUSCH, PUCCH, PDSCH channels and
information regarding uplink power control, CQI reporting, the SRS, antenna configuration and scheduling requests
RRC Connection Setup Complete
Direction: UE => E-UTRAN
Signalling Radio Bearer: SRB1
RLC Mode: AM
Logical Channel: DCCH
Transport Channel: UL-SCH
The RRC CONNECTION SETUP COMPLETE message is used to confirm the successful completion of an RRC
connection establishment. Some of the IEs in this message are explained below:
The RRC CONNECTION REJECT message is used to reject the RRC connection establishment. This message
includes the IE waitTime which can be in the range from 0 to 16 seconds. Optionally, the NW can include the
IE extendedWaitTime for the purpose of Delay Tolerant access requests
Upon receiving the RRC CONNECTION REJECT message, the UE should start timer T302, with the timer value
set to waitTime. The UE is not allowed to send another RRCConnectionRequest for mobile originating calls, mobile
originating signalling, mobile terminating access and mobile originating CS fallback on the same cell on which RRC
CONNECTION REJECT is received until the expiry of T302
The following differences are noted as compared to UMTS RRC CONNECTION REJECT:
1. There is no RejectionCause in the case of LTE
2. RedirectionInfo which is used to redirect the UE to another frequency/RAT is not present in the case of
LTE
3. LTE requires the higher layers to initiate new RRC CONNECTION REJECT after receiving RRC CONNECTION
REJECT, where as in the case of UMTS, the procedure is repeated for N300 times
The SECURITY MODE COMMAND message is used to command the UE for the activation of AS security. E-
UTRAN always initiates this procedure prior to the establishment of Signalling Radio Bearer2 (SRB2) and Data
Radio Bearers (DRBs).
AS security comprises of the integrity protection of RRC signalling (SRBs) as well as the ciphering of RRC
signalling (SRBs) and user plane data (DRBs). The integrity protection algorithm is common for signalling radio
bearers SRB1 and SRB2. The ciphering algorithm is common for all radio bearers (i.e. SRB1, SRB2 and DRBs).
Neither integrity protection nor ciphering applies for SRB0.
The eNodeB sends integrity protected SECURITY MODE COMMAND message to the UE. The UE shall
derive KeNB and KRRCint which is associated with integrity protection algorithm indicated in the SECURITY MODE
COMMAND. Then, UE verifies the Integrity of the received SECURITY MODE COMMAND by checking the Message
Authentication Code (MAC) in the SECURITY MODE COMMAND message. If the SECURITY MODE COMMANDmessage
fails the integrity protection check, then the UE sends SECURITY MODE FAILURE to the eNodeB.
If the SECURITY MODE COMMAND passes the integrity protection check, then the UE shall derive the
encryption keys KRRCenc key and the KUPenc keys associated with the ciphering algorithm indicated in theSECURITY
MODE COMMAND.
The UE shall apply integrity protection using the indicated algorithm (EIA) and the integrity
key, KRRCintimmediately, i.e. integrity protection shall be applied to all subsequent messages received and sent by
the UE, including the SECURITY MODE COMPLETE message.
The UE shall apply ciphering using the indicated algorithm (EEA), KRRCenc key and the KUPenc key after
completing the procedure, i.e. ciphering shall be applied to all subsequent messages received and sent by the UE,
except for the SECURITY MODE COMPLETE message which is sent un-ciphered.
The SECURITY MODE COMPLETE message is used to confirm the successful completion of a SECURITY MODE
COMMAND.
The UE shall send SECURITY MODE COMPLETE message integrity protected but un-ciphered.
i.e., the UE doesn’t start ciphering in the uplink before it has sent the SECURITY MODE COMPLETE message to
the eNodeB
The SECURITY MODE FAILURE message is used to indicate an unsuccessful completion of a SECURITY MODE
COMMAND. i.e., if the SECURITY MODE COMMAND message fails the integrity protection check, then the UE
sends SECURITY MODE FAILURE to the eNodeB
Upon sending this message, the UE shall continue using the configuration used prior to the reception of
theSECURITY MODE COMMAND message, i.e. neither applies integrity protection nor ciphering
UE Capability Enquiry
Direction: E-UTRAN => UE
Signalling Radio Bearer: SRB1
RLC Mode: AM
Logical Channel: DCCH
Transport Channel: DL-SCH
The UE CAPABILITY ENQUIRY message is used to request the transfer of UE radio access capabilities forE-
UTRA as well as for other RATs (UTRA, GERAN-CS, GERAN-PS, and CDMA2000)
As the UE’s AS capability may contain several RATs capabilities, the information can be rather very large.
To reduce the overhead in the air interface during transition from RRC_IDLE mode to RRC_CONNECTED mode, MME
stores UE's AS capability and provides it to eNodeB during initial UE context setup over S1 interface. In case if the
MME doesn’t have the valid UE's AS capability, the MME does not provide UE's AS capability to
theeNodeB. The eNobeB has to acquire UE's AS capability from UE using UE CAPABILITY ENQUIRY.
NOTE: Change of the UE's GERAN UE radio capabilities in RRC_IDLE is supported by use of TRACKING AREA UPDATE
RRC CONNECTION RECONFIGURATION message is the command to modify an RRC connection. The purpose
of this procedure is,
• To establish/modify/release Radio Bearers
• To perform Handover
• To setup/modify/release Measurements
• To add/modify/release SCells
• Dedicated NAS Information might also be transferred from eNodeB to UE
E-UTRAN includes the mobilityControlInfo (Handover) only when AS-security has been activated,
andSRB2 with at least one DRB are setup but not suspended. The establishment of RBs (other than SRB1, which is
established during RRC connection establishment) is included only when AS-security has been activated
The RRC CONNECTION RECONFIGURATION COMPLETE message is used to confirm the successful
completion of an RRC CONNECTION RECONFIGURATION
The connection re-establishment succeeds only if the concerned cell is prepared i.e. has a valid UE
context. In case E-UTRAN accepts the re-establishment, SRB1 operation resumes while the operation of other radio
bearers remains suspended. If AS security has not been activated, the UE doesn’t initiate this procedure, instead,
it moves to RRC_IDLE directly
The UE initiates the RRC CONNECTION RE-ESTABLISHMENT procedure when one of the following conditions is met:
• Upon detecting radio link failure; or
• Upon handover failure; or
• Upon mobility from E-UTRA failure; or
• Upon integrity check failure indication from lower layers; or
• Upon an RRC CONNECTION RECONFIGURATION failure
ue-Identity: UE identity is included to retrieve UE context and to facilitate contention resolution by lower layers.
The UE Identity shall be set as follows:
1. Set the C-RNTI to the C-RNTI used in the source PCell (In case of handover and mobility from E-UTRA
failure) or used in the PCell in which the trigger for the re-establishment occurred (other cases);
2. Set the physCellId to the physical cell identity of the source PCell (handover and mobility from E-UTRA
failure) or of the PCell in which the trigger for the re-establishment occurred (other cases);
3. Set the shortMAC-I to the 16 least significant bits of the calculated MAC-I
reestablishmentCause: This IE indicates the failure cause that triggered the re-establishment procedure and shall
be set as follows:
1. If the re-establishment procedure was initiated due to reconfiguration failure (the UE is unable to comply
with the reconfiguration sent in RRC CONNECTION RECONFIGURATION), then set
thereestablishmentCause to the value 'reconfigurationFailure';
2. If the re-establishment procedure was initiated due to handover failure (intra-LTE handover failure or
inter-RAT mobility from EUTRA failure) then, set the reestablishmentCause to the value 'handoverFailure'
3. Set the reestablishmentCause to the value 'otherFailure' if the re-establishment procedure was triggered
due other causes than indicated in cases 1 and 2
The purpose of this procedure is to re-establish the RRC connection, which involves the resumption
ofSRB1, the re-activation of security and the configuration of only the PCell
The RRC CONNECTION REESTABLISHMENT message is used to resolve contention and to re-establishSRB1.
Since this message is used to resume SRB1, it is similar to RRCCONNECTION SETUP
See RRC CONNECTION REESTABLISHMENT REQUEST for more information on RRC Reestablishment procedure
RRC Connection Reestablishment Complete
Direction: UE => E-UTRAN
Signalling Radio Bearer: SRB1
RLC Mode: AM
Logical Channel: DCCH
Transport Channel: UL-SCH
The RRC CONNECTION REESTABLISHMENT COMPLETE message is used to confirm the successful completion of
anRRC connection reestablishment
After receiving RRC CONNECTION REESTABLISHMENT message, the SRB1 operation is resumed. The RRC
CONNECTION REESTABLISHMENT COMPLETE message and all the subsequent messages are (sent) ciphered and
integrity protected using previously configured (respective) algorithms and newly derived
keys KRRCenc andKRRCint respectively.
The RRC CONNECTION REESTABLISHMENT REJECT message is used to indicate the rejection of an RRC
CONNECTION REESTABLISHMENT REQUEST.
Upon receiving the RRC CONNECTION REESTABLISHMENT REJECT message, the UE shall leave
RRC_CONNECTED state with release cause 'RRC connection failure'
Mobility from E-UTRA Command
E-UTRAN initiates the 'mobility from E-UTRA' procedure to a UE in RRC_CONNECTED state.
TheeNodeB sends MOBILITY FROM EUTRA COMMAND possibly in response to a 'Measurement Report' message from
the UE or in response to reception of 'CS fallback indication' for the UE from MME. This procedure is initiated only
when AS-security has been activated.
The purpose of this procedure is to move a UE from E-UTRAN to a cell using another RAT,
e.g. GERAN,UTRA or CDMA2000 systems. The mobility from E-UTRA procedure covers the following types of
mobility:
1. Handover, i.e. the MOBILITY FROM EUTRA COMMAND message includes radio resources that have been allocated
for the UE in the target cell
2. Cell Change Order, i.e. the MOBILITY FROM EUTRA COMMAND message may include information facilitating access
of and/or connection establishment in the target cell, e.g. system information. Cell change order is applicable
only to GERAN
3. Enhanced CS fallback to CDMA2000 1xRTT, i.e. the MOBILITY FROM EUTRA COMMAND message includes radio
resources that have been allocated for the UE in the target cell
Some of the IEs in MOBILITY FROM EUTRA COMMAND message are described below:
If the criteria for ‘Mobility from E-UTRA failure’ is met,then the UE should stop T304, if running and act as below:
• If the cs-FallbackIndicator in the MobilityFromEUTRACommand message was set to 'TRUE', indicate to upper layers
that the CS Fallback procedure has failed
• Revert back to the configuration used in the source cell, excluding the configuration configured by
thephysicalConfigDedicated, mac-MainConfig and sps-Config
• Initiate the connection re-establishment procedure
Measurement Report
Direction: UE => E-UTRAN
Signalling Radio Bearer: SRB1
RLC Mode: AM
Logical Channel: DCCH
Transport Channel: UL-SCH
The UE reports measurement information in accordance with the measurement configuration as provided by E-
UTRAN. E-UTRAN provides the measurement configuration applicable for a UE in RRC_CONNECTED by means of
dedicated signalling, i.e. using the RRC CONNECTION RECONFIGURATION message
• Intra-frequency measurements: Measurements at the downlink carrier frequency (ies) of the serving
cell(s).
• Inter-frequency measurements: Measurements at frequencies that differ from any of the downlink
carrier frequency (ies) of the serving cell(s).
• Inter-RAT measurements of UTRA frequencies or of GERAN frequencies or
of CDMA2000 HRPD orCDMA2000 1xRTT frequencies
UL Information Transfer
Direction: UE => E-UTRAN
Signalling Radio Bearer: SRB1 or SRB2
RLC Mode: AM
Logical Channel: DCCH
Transport Channel: UL-SCH
A UE in RRC_CONNECTED state initiates the UL INFORMATION TRANSFER whenever there is a need to transfer NAS
or non-3GPP dedicated information, except at RRC connection establishment in which case the NAS information is
piggybacked to the RRC CONNECTION SETUP COMPLETE message
The UL INFORMATION TRANSFER procedure is almost similar to UPLINK DIRECT TRANSFER procedure in 3G-RNC
Either SRB2 or SRB1 (only if SRB2 not established yet) is used for this purpose. If SRB2 is suspended, the UE does
not send this message until SRB2 is resumed. When CDMA2000 information has to be transferred, the UE shall
initiate the procedure only if SRB2 is established
The IE dedicatedInfoType shall carry ‘dedicatedInfoNAS’ or ‘dedicatedInfoCDMA2000-1XRTT ‘(in case ofCDMA2000
1XRTT information) or ‘dedicatedInfoCDMA2000-HRPD’ (in case of CDMA2000 HRPD information)
DL Information Transfer
Direction: E-UTRAN => UE
Signalling Radio Bearer: SRB2 or SRB1
RLC Mode: AM
Logical Channel: DCCH
Transport Channel: DL-SCH
E-UTRAN initiates the DL information transfer procedure whenever there is a need to transfer NAS or non-
3GPP dedicated information. E-UTRAN initiates the DL information transfer procedure by sending the DL
INFORMATION TRANSFER message
Either SRB2 or SRB1 (only if SRB2 not established yet) is used. If SRB2 is suspended, E-UTRAN does not
send this message until SRB2 is resumed
DL INFORMATION TRANSFER procedure is almost similar to DOWNLINK DIRECT TRANSFER procedure in 3G-RNC
The RRC CONNECTION RELEASE message is used to command the release of an RRC connection. E-UTRAN
initiates the RRC connection release procedure to an UE in RRC_CONNECTED state
The RRC CONNECTION RELEASE procedure with redirection information can also be used for CS-fallbackto
GERAN or UTRAN
The RRC CONNECTION RELEASE procedure can also be used for MME load balancing. If an MME feels
overloaded, it can simply move the calls to other MME in the MME pool. The source MME releases the S1
connections of the UE towards the eNodeB asking the UE to perform a “load balancing TAU”. Then
the eNodeBsends RRC CONNECTION RELEASE message to the UE with cause ‘load balancing TAU required'. After
receiving this message, the UE initiates Tracking Area Updating procedure which is redirected to another MME
The eNodeB may provide a cell reselection priority for each frequency, by means of separate lists for each
RAT (including E-UTRA) in the RRC CONNECTION RELEASE message
There is no RRC CONNECTION RELEASE COMPLETE message defined in LTE. So, UE leaves RRC_CONNECTED
state without transmitting RRC CONNECTION RELEASE COMPLETE message
In LTE, there is only one type of PAGING where as in the case of 3G-system, Paging Type1 and Paging
Type2 are defined
The PAGING message may be used to inform UEs in RRC_IDLE and RRC_CONNECTED about a system
information change. If the UE receives a PAGING message including the systemInfoModification IE, it knows that
the system information will change at the next modification period boundary. The UE, if
thesystemInfoModification is included, should re-acquire the required system information using the system
information acquisition procedure
The PAGING message may also be used to inform ETWS (Earthquake and Tsunami Warning System)
capable UEs in RRC_IDLE and UEs in RRC_CONNECTED about presence of an ETWS primary notification and/or ETWS
secondary notification. An ETWS capable UE should re-acquire SIB10/SIB11 immediately if the etws-Indication is
included in the PAGING message
The PAGING message may also be used to inform CMAS (Commercial Mobile Alert System) capable UEs in
RRC_IDLE and UEs in RRC_CONNECTED about presence of one or more CMAS notifications. A CMAS capable UE
should re-acquire SIB12 immediately if the cmas-Indication is included in the PAGING message
The UE in RRC_IDLE validates each of the PagingRecord, if any, included in the PAGING message. If theue-
Identity included in the PagingRecord matches one of the UE identities allocated by upper layers, the ue-
Identity and the cn-Domain are forwarded to the upper layers
The MASTER INFORMATION BLOCK (MIB) includes a limited number of most essential and most frequently
transmitted parameters that are needed to acquire other information from the cell. The MIB is transmitted
onBCH while all other SYSTEM INFORMATION messages are transmitted on DL-SCH
As MIB is the most important information block, it is transmitted more frequently with a fixed scheduling.
The MIB uses a periodicity of 40ms and repetitions made within 40ms. The first transmission of the MIB is
scheduled in subframe #0 of radio frames for which the SFNmod4 = 0, and repetitions are scheduled in subframe #0
of all other radio frames
The MIB contains DL bandwidth of the cell, PHICH configuration and the System Frame Number (SFN)
SIB1 uses a fixed schedule with a periodicity of 80ms and repetitions made within 80ms. The first
transmission of SIB1 is scheduled in subframe #5 of radio frames for which the SFNmod8 = 0, and repetitions are
scheduled in subframe #5 of all other radio frames for which SFNmod2 = 0
SIB1 contains cell access related information (e.g. a PLMN identity list, tracking area code, cell identity,
etc.), information for cell selection (e.g. minimum required Rx level in the cell and offset), p-Max, frequency band
indicator, scheduling information, TDD configuration, SI-window length and system information value tag etc...
Upon receiving the SIB1 message the UE shall check the IE freqBandIndicator. The UE shall consider the
cell as barred if the frequency band indicated in the freqBandIndicator is not part of the frequency bands
supported by the UE
SIB2 also gives information about the uplink carrier frequency and the uplink
channel bandwidth in terms of number of Resource Blocks
UL-CarrierFreq: If this IE is absent (for FDD), the UL-Carrier Frequency value should
be determined from the default TX-RX frequency separation defined in TS
36.101 [Table 5.7.3-1]. For TDD, this parameter is absent and it is equal to the
downlink frequency
UL-Bandwidth: Transmission bandwidth configuration, NRB, in uplink. The
value n6 corresponds to 6 resource blocks, n15 to 15 resource blocks and so on. If this
parameter is absent for FDD then the uplink bandwidth is equal to the downlink
bandwidth. For TDD this parameter is absent and it is equal to the downlink
bandwidth
defaultPagingCycle: Default paging cycle value rf32 corresponds to 32 radio
frames, rf64 corresponds to 64 radio frames and so on
modificationPeriodCoeff: Actual modification period, expressed in number of radio
frames= modificationPeriodCoeff * defaultPagingCycle.The value n2 corresponds
to value 2, n4 corresponds to value 4, and so on
p-Max: Maximum power to be used in the target cell. If this IE is absent then the UE
applies the maximum power according to the UE capability
UL-CyclicPrefixLength: The value len1 corresponds to normal cyclic
prefix and len2 corresponds to extended cyclic prefix
RadioResourceConfigCommonSIB: The IE RadioResourceConfigCommonSIB is used to
specify common radio resource configurations e.g., the random access parameters
and the static physical layer parameters
System Information Block Type 3
Direction: E-UTRAN => UE
Signalling Radio Bearer: N/A
RLC Mode: TM
Logical Channel: BCCH
Transport Channel: DL-SCH
SIB3 also contains cell reselection priority information for the concerned
carrier frequency or a set of frequencies
System Information Block Type 4
Direction: E-UTRAN => UE
Signalling Radio Bearer: N/A
RLC Mode: TM
Logical Channel: BCCH
Transport Channel: DL-SCH
SIB5 includes neighbor cell list, carrier frequency, cell reselection priority,
threshold used by the UE when reselecting a higher/lower priority frequency than the
current serving frequency etc. It also contains a list of blacklisted inter-frequency
neighbouring cells
Attach Request
The UE includes ATTACH REQUEST (initial-NAS) message within RRC CONNECTION SETUP
COMPLETE message. The IE dedicatedInfoNAS in RRC CONNECTION SETUP COMPLETEincludes this
initial-NAS message
The IEs (some of them are explained below) in ATTACH REQUEST message
include EPS attach type, EPS mobile identity, UE network capability, ESM message
container, Old P-TMSI signature, Additional GUTI, Last visited registered TAI, DRX
parameter, Old location area identification, Additional update type, Voice domain
preference and UE's usage setting etc…
The IE EPS Attach Type indicates the purpose of the attach procedure. The value
can be EPS attach (to attach for EPS services only) or combined EPS/IMSI attach (to
attach for both EPS and non-EPS services) or EPS emergency attach (to attach for
emergency bearer services)
The IE EPS Mobile Identity can be GUTI, IMSI or IMEI. The UE shall include GUTI if
it holds a valid GUTI (either native GUTI or mapped GUTI). If there is no valid GUTI
available, the UE shall include the IMSI as EPS Mobile Identity IE. If the UE is attaching for
emergency bearer services and does not hold a valid GUTI, P-TMSI or IMSI as described
above, the IMEIshall be included in the EPS mobile identity IE
The purpose of the ESM message container IE is to enable piggybacked transfer of an ESM
message within an EMM message (This may contain IEs for example, EPS bearer identity, procedure
transaction identity, PDN connectivity request, PDN type, Request type, ESM information transfer
flag, EIT (ESM information transfer), Protocol Configuration Options (Configuration Protocol, DNS
Server Address Request etc..)
The IE Additional Update Type provides additional information about the type of
request for a combined attach procedure. Bit1 value 0 means that there is “no additional
information” and 1 means that “SMS only”
Voice domain preference and UE's usage setting IE shall be included if the UE
supports CS fallback and SMS over SGs, or if the UE is configured to support IMS voice, but
does not support 1xCS fallback. This IE provides the network with the UE's usage setting
and the voice domain preference for E-UTRAN. Refer to 3GPP TS 24.008,
section 10.5.5.28 for detailed information
The IE Last Visited Registered TAI shall be included if the UE holds a valid last
visited registered Tracking Area Identity (TAI)
Attach Accept
The ATTACH ACCEPT message is sent by the network to the UE to indicate that the
corresponding ATTACH REQUEST has been accepted. Typically, the ATTACH
ACCEPT message is piggy-backed on RRC CONNECTION RECONFIGURATION message
The result of the EPS attach is indicated in the IE EPS Attach Result. The result
can be either “EPS only” or “combined EPS/IMSI attach”. The result "combined EPS/IMSI
attach" indicates that the attach request for EPS and non-EPS services, or for EPS services
and "SMS only" have been successful. The result "EPS only" indicates that the attach
request for EPS services (only) has been successful but attach for non-EPS services or "SMS
only" (if requested by the UE in the ATTACH REQUEST) has failed
When the default bearer is activated as part of the attach procedure, the MME
shall send the ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST message together
with ATTACH ACCEPT message. The IE ESM Message Container is used for this purpose.
The network may also initiate the activation of dedicated bearers towards the UE by
invoking the dedicated EPS bearer context activation procedure
The GUTI Reallocation may be part of the attach procedure. If the ATTACH
REQUESTmessage includes the IMSI or IMEI, or if the MME considers the GUTI provided by
the UE is invalid, or if the GUTI provided by the UE was assigned by another MME, the
MME shall allocate a new GUTI to the UE. The MME shall include in the ATTACH
ACCEPT message the new assigned GUTI together with the assigned TAI list
The IE TAI List indicates a list of tracking areas for which the UE doesn't need to
perform a tracking area updating procedure when entered one of these TAs (in the list).
The TAIs in a TAI list assigned by an MME to a UE belongs to the same MME area
The MME includes EMM Cause IE when IMSI attach for non-EPS services is not
successful during a combined EPS/IMSI attach procedure
The purpose of the EPS network feature support IE is to indicate whether certain
features are supported by the network. It can indicate the following features whether
supported or not: IMS voice over PS session indicator (IMS VoPS), Emergency bearer
services indicator (EMC BS), Location services indicator in EPC (EPC-LCS), Location
services indicator in CS (CS-LCS), Support of EXTENDED SERVICE REQUEST for packet
services (ESRPS)
If the UE initiated ATTACH REQUEST cannot be accepted by the network, the MME
shall send an ATTACH REJECT message to the UE including an appropriate EMM cause
value
If the attach procedure fails due to a Default EPS bearer Setup Failure or an ESM
procedure failure or operator determined barring is applied on Default EPS Bearer
Context Activation during attach procedure, the MME shall combine the ATTACH
REJECT message with a PDN CONNECTIVITY REJECT message contained in the ESM
Message Container IE. In this case the EMM Cause value in the ATTACH REJECT message
shall be set to #19 "ESM failure"
If the attach request is rejected due to NAS level congestion control, the network
shall set the EMM cause value to #22 "congestion" and optionally assigns a back-off
timer T3346
Attach Complete
When the UE receives the ATTACH ACCEPT message combined with the ACTIVATE
DEFAULT EPS BEARER CONTEXT REQUEST message, it shall forward the ACTIVATE
DEFAULT EPS BEARER CONTEXT REQUEST message to the ESM sublayer. Once the ESM
sublayer indicates that the default EPS bearer context has been activated, the UE shall
send an ATTACH COMPLETE message together with an ACTIVATE DEFAULT EPS BEARER
CONTEXT ACCEPTmessage contained in the ESM message container IE to the network
The TRACKING AREA UPDATING (TAU) procedure is always initiated by the UE and
is used for (some of) the following purposes:
• Normal TAU: When the UE enters a tracking area that is not in the list of tracking areas
that the UE previously registered in the MME
• Combined TAU: When a UE operating in 'CS/PS mode 1' or 'CS/PS mode 2' enters a
tracking area that is not in the list of tracking areas that the UE previously registered in
the MME
• Periodic TAU: Upon the expiry of timer T3412, periodic TAU procedure is initiated to
periodically notify the availability of the UE to the network
• IMSI attach for non-EPS services when the UE is attached for EPS services. This procedure
is used by a UE in 'CS/PS mode 1' or 'CS/PS mode 2' of operation
• In various cases of inter-system change from “Iu mode to S1 mode” or from “A/Gb mode
to S1 mode” or from “S101 mode to S1 mode”
• MME load balancing: When the UE receives RRC CONNECTION RELEASE message with
cause ‘load balancing TAU required', it initiates TAU procedure
• To update certain UE specific parameters in the network (ex:- when the UE changes the
“UE network capability information” or the “MS network capability information” or the
UE specific DRX parameter etc...)
In the IE EPS update type the first 3 bits (LSBs) shall be used to indicate update
type (ex:- ‘TA updating’ or ‘combined TA/LA updating’ or ‘combined TA/LA updating
with IMSI attach’ or ‘periodic updating’). Additionally, if a UE has uplink user data
pending when it initiates the TAU procedure or uplink signalling not related to
the TAU procedure, it may also set an "active" flag (bit4) in this IE to indicate the request
to establish the user plane to the network and to keep the NAS signalling connection after
the completion of the TAU procedure
The IE Additional Update Type provides additional information about the type of
request for a TAU procedure. Bit1 value 0 means that there is “no additional information”
and 1 means that “SMS only”
Voice domain preference and UE's usage setting IE shall be included if the UE
supports CS fallback and SMS over SGs, or if the UE is configured to support IMS voice, but
does not support 1xCS fallback. This IE provides the network with the UE's usage setting
and the voice domain preference for E-UTRAN. Refer to 3GPP TS 24.008,
section 10.5.5.28 for detailed information
The IE Last Visited Registered TAI shall be included if the UE holds a valid last
visited registered Tracking Area Identity (TAI)
The GUTI also allows the identification of the MME and the network. It can be used
by the network and the UE to establish the UE's identity during signalling between them
in the EPS. The GUTI has two main components as explained below:
one that uniquely identifies the MME which allocated the GUTI (GUMMEI)
one that uniquely identifies the UE within the MME that allocated the GUTI (M-TMSI)
The MME allocates GUTI by initiating GUTI reallocation procedure or it can also be
implicitly reallocated during attach or tracking area updating procedures. Normally,
the GUTI reallocation will take place in conjunction with another mobility
management procedure, e.g. as part of tracking area updating
Authentication Request
The purpose of the EPS authentication and key agreement (AKA) procedure is to provide mutual
authentication between the user and the network and to agree on a key KASME
The EPS AKA procedure is always initiated and controlled by the network. However, the UE can
reject the EPS authentication challenge sent by the network. The UE shall proceed with an EPS
authentication challenge only if an USIM is present
When a NAS signalling connection exists, the network can initiate an authentication procedure at
any time. The network initiates the authentication procedure by sending an AUTHENTICATION
REQUEST message to the UE
The MME sends unciphered AUTHENTICATION REQUEST message to the UE which includes a random
number RAND and an authentication parameter AUTN. Now the UE’s job is to compute the
authentication response parameter RES and send it back to the MME in AUTHENTICATION
RESPONSE message
The value of RES is computed by the USIM using RAND, AUTN and the secret key ‘K’ which is
stored in the USIM.
The IE Authentication parameter RAND (EPS challenge) will carry the RAND of length 128-bits. It
provides the MS with a non-predictable number to be used to calculate the authentication
response parameter RES
The IE Authentication parameter AUTN (EPS challenge) will carry the AUTN of length 128-bits. It
provides the MS with a means of authenticating the network. The AUTN consists of (SQN xor AK)||
AMF||MAC = 48 + 16 + 64 = 128-bits. In the AUTHENTICATION REQUEST example below,AUTN value =
6e323b36c46c5555a3df0e6e323b6391 which means that,
Abbreviations:
AMF – Authentication Management Field
AK – Anonymity Key
ASME – Access Security Management Entity
AUTN – Authentication Token
MAC – Message Authentication Code
RAND – RANDom number
SQN – Sequence Number
Reference: 3GPP TS 24.301
Authentication Response
The UE processes the authentication challenge data received in AUTHENTICATION
REQUESTmessage (RAND and AUTN) and responds with an AUTHENTICATION RESPONSE message in order to
deliver a calculated authentication response RES to the network
In an EPS authentication challenge, the response calculated in the USIM (RES) is minimum 4 octets
and may be up to 16 octets in length. The RES is included in the IE Authentication response
parameter in the AUTHENTICATION RESPONSE message
Upon receipt of an AUTHENTICATION RESPONSE message the MME compares the received RES value
with the XRES (Expected Response) value. If RES == XRES, then the network considers that the UE
has successfully authenticated itself to the network
If the AUTHENTICATION RESPONSE returned by the UE is not valid (RES != XRES), the network
response depends upon the type of identity used by the UE in the initial NAS message (if GUTI was
used or IMSI was used) as explained below:
• If the GUTI was used, the network should initiate an identification procedure. If the IMSI given by
the UE during the identification procedure differs from the IMSI the network had associated with
the GUTI, the authentication should be restarted with the correct parameters. Otherwise, if the
IMSI provided by the UE is the same as the IMSI stored in the network (i.e.authentication has
really failed), the network should sends AUTHENTICATION REJECTmessage to the UE
• If the IMSI was used for identification in the initial NAS message, or the network decides not to
initiate the identification procedure after an unsuccessful authentication procedure, the network
should send an AUTHENTICATION REJECT message to the UE
Authentication Reject
Upon receipt of an AUTHENTICATION RESPONSE message the MME compares the
received RESvalue with the XRES (Expected Response) value. If RES == XRES, then the network
considers that the UE has successfully authenticated itself to the network
If the AUTHENTICATION RESPONSE returned by the UE is not valid i.e. RES != XRES, then the
network response depends upon the type of identity used by the UE in the initial NAS message as
explained below:
• If the GUTI was used, the network should initiate an identification procedure to obtain IMSI from
the UE. If the IMSI given by the UE during the identification procedure differs from the IMSI the
network had associated with the GUTI, the authentication should be restarted with the correct
parameters. Otherwise, if the IMSI provided by the UE is the same as the IMSI stored in the
network (i.e. authentication has really failed), the network should sendsAUTHENTICATION
REJECT message to the UE
• If the IMSI was used for identification in the initial NAS message, or the network decides not to
initiate the identification procedure after an unsuccessful authentication procedure, the network
should send an AUTHENTICATION REJECT message to the UE
Upon receipt of an AUTHENTICATION REJECT message, the UE shall abort any EMM signalling
procedure and enter state EMM-DEREGISTERED. Also, the UE shall set the update status to EU3
ROAMING NOT ALLOWED, delete the stored GUTI, TAI list, last visited registered TAI and KSIASME.
The USIM shall be considered as invalid until switching off the UE or the UICC containing the USIM
is removed
Additionally, If A/Gb or Iu mode is supported by the UE, it shall handle MM/GMM states and
parameters as explained in 3GPP TS 24.008 section 4.7.4.5
Authentication Failure
In an EPS authentication challenge, the UE shall check the authenticity of the core network by
means of the AUTN parameter received in the AUTHENTICATION REQUEST message. This enables
the UE to detect a false network. The UE shall send AUTHENTICATION FAILURE message to
indicate the EPS authentication failure
As explained in the post AUTHENTICATION REQUEST, the AUTN parameter is formed by SQN, AK,
AMF, and MAC. There could be 3 possible causes for the authentication failure as explained below:
a) MAC code failure: If the UE finds that the MAC code supplied by the core network in
theAUTN parameter is invalid, then the UE shall send an AUTHENTICATION FAILURE message to
the network, with the EMM cause #20 "MAC failure". The network may initiate an identification
procedure to obtain the IMSI from the UE or may also decides to terminate the authentication
procedure
b) Non-EPS authentication unacceptable: If the UE finds that the "separation bit" in the AMFfield
of AUTN supplied by the core network is 0, then the UE shall send an AUTHENTICATION
FAILURE message to the network, with the EMM cause #26 "non-EPS authentication
unacceptable". The network may initiate an identification procedure to obtain the IMSI from the
UE or may also decides to terminate the authentication procedure
c) SQN failure: If the UE finds that the SQN (supplied by the core network in the AUTN parameter) is
out of range, then the UE shall send an AUTHENTICATION FAILURE message to the network, with
the EMM cause #21 "synch failure". In this message, the UE should also include a re-
synchronization token AUTS provided by the USIM. By using this AUTS the network starts re-
synchronization procedure. The re-synchronization procedure requires the MME to delete all
unused authentication vectors for that IMSI and obtain new vectors from the HSS. Once the re-
synchronization is complete, the network shall initiate a new authentication procedure. Upon
receipt of two consecutive AUTHENTICATION FAILURE messages from the UE with EMM cause
#21 "synch failure", the network may terminate the authentication procedure by sending
an AUTHENTICATION REJECT message
The MME shall send the SECURITY MODE COMMAND message unciphered, but shall integrity
protect the message with the NAS integrity key based on KASME or mapped K'ASME indicated by
theeKSI included in the message
The MME shall set the security header type of the message to "integrity protected with new EPS
security context" since this message is only integrity protected but not ciphered
The MME shall include the replayed security capabilities of the UE (including the security
capabilities with regard to NAS, RRC and UP (user plane) ciphering etc...)
The MME shall include the replayed nonceUE if the UE included it in initial L3 message to the
network
Also, the MME shall send the selected NAS ciphering and integrity algorithms and the NAS Key Set
Identifier (eKSI) in the SECURITY MODE COMMAND message
The MME shall include both the nonceMME and the nonceUE when creating a mapped EPS security
context during inter-system change from A/Gb mode to S1 mode or Iu mode to S1 mode in EMM-
IDLE mode
Additionally, the MME may request the UE to send its IMEISV in the SECURITY MODE
COMPLETEmessage
The UE shall derive KNASenc and KNASint keys from the key KASME/K'ASME and the received EPS encryption and
integrity algorithms (respectively)
The network initiates the identification procedure by sending an IDENTITY REQUEST message to
the UE. The type of the identity is requested in the IE Identity Type 2
The MME can send an IDENTITY REQUEST message to an UE at any time while the UE is in EMM-
CONNECTED mode and the UE shall be ready to respond to an IDENTITY REQUEST message at any
time whilst in EMM-CONNECTED mode
After receiving the IDENTITY REQUEST message the UE shall respond with an IDENTITY
RESPONSEmessage to the network. The IDENTITY RESPONSE message shall contain the
identification parameters as requested by the network
If the network doesn’t receive IDENTITY RESPONSE message before the expiry of T3470, it shall
retransmit the IDENTITY REQUEST message and reset/restart the timer T3470. This retransmission
is repeated four times, i.e. on the fifth expiry of timer T3470, the network shall abort
theidentification procedure and any ongoing EMM procedure
Identity Response
After receiving the IDENTITY REQUEST message, the UE shall send an IDENTITY RESPONSE message
to the network. The IDENTITY RESPONSE message shall contain the identification parameters as
requested by the network
The UE shall include the requested identity in the IE Mobile Identity in the IDENTITY
RESPONSEmessage
If the UE cannot encode the requested identity in the IDENTITY RESPONSE message, e.g. because
no valid USIM is available, then it shall encode the identity type as "no identity"
For the above cases, if the UE is configured for NAS signalling low priority, but the network
doesn’t support EXTENEDED SERVICE REQUEST for packet services, the UE shall send SERVICE
REQUEST message to the MME
Upon receipt of the SERVICE REQUEST message, the MME may initiate the EMM common
procedures e.g. the authentication procedure and security mode control procedure
The UE shall treat that the service request procedure as successful, when the lower layers
indicate that the user plane radio bearer is successfully set up
The structure of SERVICE REQUEST message doesn’t follow the structure of standard L3 message
(see the example below)
The IE KSI and sequence number’s purpose is to provide the network with the key set
identifier(KSI) value of the current EPS security context and the short sequence number (5 LSBs of
the NAS COUNT value) applicable for the message that includes this IE
The purpose of the Short MAC IE is to protect the integrity of a SERVICE REQUEST message. This
field contains the 2 least significant octets of the MAC calculated for the SERVICE
REQUESTmessage
This message is also used if the UE wants to request the establishment of a NAS signalling
connection (and of the radio and S1 bearers) for packet services and if the UE needs to
provideadditional information that cannot be provided via a SERVICE REQUEST message
The UE shall send EXTENEDED SERVICE REQUEST message when:
a) The UE in EMM-IDLE mode receives a paging request with CN domain indicator set to "PS" from the
network
b) The UE, in EMM-IDLE mode, has pending user data to be sent
c) The UE, in EMM-IDLE mode, has uplink signalling pending
d) The UE in EMM-IDLE or EMM-CONNECTED mode is configured to use CS fallback and has a mobile
originating CS fallback request from the upper layer
e) The UE in EMM-IDLE mode is configured to use CS fallback and receives a paging request with CN
domain indicator set to "CS", or the UE in EMM-CONNECTED mode is configured to use CS
fallback and receives a CS SERVICE NOTIFICATION message
f) The UE in EMM-IDLE or EMM-CONNECTED mode is configured to use 1xCS fallback and has a
mobile originating 1xCS fallback request from the upper layer
g) The UE in EMM-CONNECTED mode is configured to use 1xCS fallback and
accepts cdma2000®signalling messages containing a 1xCS paging request received over E-UTRAN
h) The UE, in EMM-IDLE mode, has uplink cdma2000® signalling pending to be transmitted over E-
UTRAN
i) The UE, in EMM-IDLE or EMM-CONNECTED mode, is configured to use 1xCS fallback,
acceptscdma2000® signalling messages containing a 1xCS paging request received
over cdma2000®1xRTT, and the network supports dual Rx CSFB or provide CS fallback registration
parameters
j) The UE, in EMM-IDLE or EMM-CONNECTED mode, has uplink cdma2000® signalling pending to be
transmitted over cdma2000® 1xRTT, and the network supports dual Rx CSFB or provide CS
fallback registration parameters
k) The UE performs an inter-system change from S101 mode to S1 mode and has user data pending
NOTE: For cases a, b, c, h and k above, the EXTENEDED SERVICE REQUEST message is used only
if the UE is configured for NAS signalling low priority and the network supports EXTENEDED
SERVICE REQUEST for packet services. Otherwise, SERVICEREQUEST is used
Upon receipt of the EXTENDED SERVICE REQUEST message, the MME may initiate the EMM common
procedures e.g. the authentication procedure and security mode control procedure
The Service type IE specifies the purpose of the service request procedure. This IE can indicate
“mobile originating CS fallback or 1xCS fallback” or “mobile terminating CS fallback or 1xCS
fallback” or “mobile originating CS fallback emergency call or 1xCS fallback emergency call”, or
“packet services via S1”
The purpose of the CSFB response IE is to indicate whether the UE accepts or rejects a paging
forCSFB. The IE’s values could be either “CS fallback rejected by the UE” or “CS fallback accepted
by the UE” (see example2 below)
The IE EPS bearer context status shall be included if the UE wants to indicate the EPS bearer
contexts that are active within the UE
The UE shall include the IE Device properties if the UE is configured for NAS signalling low
priority. The network uses this IE for core-network congestion handling and for charging purposes
When the NAS level congestion control is active in mobility management, the network may include a
value for the back-off timer (T3346) in the reject messages
If the UE enters a new PLMN which is not in the list of equivalent PLMNs, it shall stop
timer T3346when initiating mobility management procedures in the new PLMN
When subscribed APN based congestion control is active for a particular APN, the network may
reject attach request from UEs with a subscription to this APN
A UE configured for NAS signalling low priority indicates this by including the Device properties IE
in the appropriate NAS message and setting the low priority indicator to "MS is configured for NAS
signalling low priority"
The UE shall set the low priority indicator to "MS is not configured for NAS signalling low priority"
for the following cases
• The UE has a PDN connection for emergency bearer services established or is establishing a
PDN connection for emergency bearer services
• The UE is accessing the network with access class 11 – 15
• The UE responds to paging
Service Reject
• If the SERVICE REQUEST or EXTENDED SERVICE REQUEST cannot be accepted by the network, then
the network shall send SERVICE REJECT message to the UE
• The MME shall specify an appropriate cause for rejecting the service request from the UE in the
IEEMM cause
• When the EMM cause value is #39 "CS service temporarily not available", the MME shall include a
value for timer T3442 in the SERVICE REJECT message (as shown in Example1 below). The UE shall
not try to send an EXTENDED SERVICE REQUEST message for MO services to the network, except
for MO CS fallback for emergency calls, until timer T3442 expires
• If the service request for MO services is rejected due to NAS Level Congestion Control, the
network shall set the EMM cause value to #22 "congestion" and assign a back-off timer T3346
Note: SGs interface (between MME and MSC server) is used for the mobility management and paging procedures
between EPS and CS domain
• This is basically paging procedure for CS services (excluding SMS) for the UEs in EMM-CONNECTED
mode
• This message may also include CS service related parameters e.g. Calling Line Identification, SS or
LCS related parameters
• After receiving the CS SERVICE NOTIFICATION message, the UE may request upper layers input i.e.
to accept or reject CS fallback before responding with an EXTENDED SERVICE REQUEST. The
response is indicated in the CSFB response IE in the EXTENDED SERVICE REQUEST message
• The purpose of the Paging identity IE is to indicate the identity used for paging for non-EPS
services. This identity could be either IMSI or TMSI
• If the network receives Calling Line Identification (CLI) via SGs, then it shall include it in the
IE CLI
• The network shall send the IE SS Code if it was received via SGs. It contains information on the
supplementary service transaction in the CS domain, which triggered the paging via SGs
• The network shall send the IE LCS Indicator if it was received via SGs. It indicates that the paging
was triggered by a terminating LCS request in the CS domain
• The Detach type IE included in this message indicates the type of detach.
4-bits are used for this purpose. 3-bits (LSBs) indicate whether the detach is
for ‘EPS detach’ or ‘IMSI detach’ or ‘Combined EPS/IMSI detach’. Bit-4
indicates if it is ‘normal detach’ or ‘switch off’
• If the UE has a valid GUTI, the UE shall set the EPS mobile identity IE as
GUTI. If the UE does not have a valid GUTI, then it shall populate the EPS
mobile identity IE with its IMSI. If the UE has neither a valid GUTI nor a valid
IMSI (with no USIM or invalid USIM), then the UE shall populate the EPS
mobile identity IE with its IMEI
• The network and the UE shall deactivate the EPS bearer context(s) locally
without peer-to-peer signalling between the UE and the MME
Reference: 3GPP TS 24.301
• If the detach procedure for EPS services is performed, then all the active
EPS bearer context(s) are deactivated locally without peer-to-peer signalling
between the UE and the MME
• The Detach type IE included in this message indicates the type of detach.
4-bits are used for this purpose. 3-bits (LSBs) indicate whether ‘re-attach
required’ or ‘re-attach not required’ or ‘IMSI detach’. Bit-4 is always set to
zero for network initiated detach
• If the detach type indicates "IMSI detach", then the UE shall not deactivate
any of the EPS bearer context(s). The UE shall send a DETACH
ACCEPT message to the network and re-attach to non-EPS services by
sending TRACKING AREA UPDATE REQUEST message with EPS update type IE
indicating "combined TA/LA updating with IMSI attach"
• The network may include an EMM cause IE to specify the reason for the
detach. If thedetach type indicates "IMSI detach" or "re-attach required",
then the UE shall ignore theEMM cause IE if received
• In the case of an UE initiated DETACH REQUEST , with the Detach type IE set
to ‘switch off’, the network shall not send a DETACH ACCEPT message to the
UE
• If the network receives a DETACH REQUEST , with the Detach type IE set to
‘normal detach’, the network shall send a DETACH ACCEPT message to the
UE
• The procedure may be initiated by the UE or the network and can only be
used when the UE is attached for EPS services and IMSI attached for non-EPS
services and is in EMM-CONNECTED mode
• In the UE initiated case, upon request from the SMS entity to send an SMS
message, the EMM entity in the UE initiates the procedure by sending
an UPLINK NAS TRANSPORTmessage including the SMS message in
the NAS message container IE
The RRC CONNECTION RELEASE message is used to command the release of an RRC connection. E-UTRAN
initiates the RRC connection release procedure to an UE in RRC_CONNECTED state
The RRC CONNECTION RELEASE procedure with redirection information can also be used for CS-fallbackto
GERAN or UTRAN
The RRC CONNECTION RELEASE procedure can also be used for MME load balancing. If an MME feels
overloaded, it can simply move the calls to other MME in the MME pool. The source MME releases the S1
connections of the UE towards the eNodeB asking the UE to perform a “load balancing TAU”. Then
the eNodeBsends RRC CONNECTION RELEASE message to the UE with cause ‘load balancing TAU required'. After
receiving this message, the UE initiates Tracking Area Updating procedure which is redirected to another MME
The eNodeB may provide a cell reselection priority for each frequency, by means of separate lists for each
RAT (including E-UTRA) in the RRC CONNECTION RELEASE message
There is no RRC CONNECTION RELEASE COMPLETE message defined in LTE. So, UE leaves RRC_CONNECTED
state without transmitting RRC CONNECTION RELEASE COMPLETE message