LTE Messages Analysis

RRC Connection Request
Direction: UE => E-UTRAN

Signalling Radio Bearer: SRB0
RLC Mode: TM
Logical Channel: CCCH
Transport Channel: UL-SCH
RRC CONNECTION REQUEST message is used to request the E-UTRAN for the
establishment of an RRC connection. It is sent as part of the Random Access
procedure. It is transferred using SRB0on the Common Control Channel (CCCH)
because neither SRB1 nor a Dedicated Control Channel (DCCH) has been setup at
this point.
IEs in RRC CONNECTION REQUEST message are given below:
ue-Identity (Initial UE-Identity): This IE is included to facilitate contention

resolution by lower layers. It can be either S-TMSI (40-bits) or a bit string
of randomValue (40-bits). If the upper layers provide S-TMSI, then S-TMSI is
used as the ue-Identity; else a random value in the range of 0 240-1 is
drawn and used as the ue-Identity. Upper layers provide the S-TMSI if the UE
is registered in the TA of the current cell
establishmentCause:The main cause values and the corresponding NAS

procedure whichtriggers the RRC connection establishment are presented
below:
emergency: This corresponds to NAS Procedure MO-CS fallback Emergency
call
mt-Access: Corresponding NAS procedures areService Request (paging
response for PS domain) or Extended Service Request(MT-CS fallback)
mo-Signalling: Corresponding NAS procedures are Attach, Detach, and TAU
mo-Data: Corresponding NAS Procedures areService Request and
Extended Service Request
RRC Connection Setup
Direction: E-UTRAN => UE
RLC Mode: TM
Transport Channel: DL-SCH
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
RLC Mode: AM
Logical Channel: DCCH
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:
selectedPLMN-Identity: This IE points to a PLMN-Id in the plmn-IdentityList of SIB1. The IE plmn-IdentityList is

transmitted in SIB1 when the cell belong to more than one PLMN.The value of this IE equals to 1 if the 1st PLMN is
selected from the plmn-IdentityList included in SIB1, 2 if the 2nd PLMN is selected from the plmn-IdentityList
included in SIB1 and so on
registeredMME: This IE is optional, and is included when available. This is the identity of the MME with which the
UE is (previously) registered with. If upper layers provide the 'Registered MME', then the IE registeredMME is set as
follows:
If the PLMN identity of the 'Registered MME' is different from the PLMN selected by the upper layers
(selectedPLMN-Identity) then include the plmnIdentity in the registeredMME and set the mmegi and the mmecto
the value received from upper layers
dedicatedInfoNAS: This IE includes the initial NAS message from the UE
RRC Connection Reject

RLC Mode: TM
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
RRC: Security Mode Command

RLC Mode: AM
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.
RRC: Security Mode Complete

RLC Mode: AM
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 doesnt start ciphering in the uplink before it has sent the SECURITY MODE COMPLETE message to
the eNodeB
RRC: Security Mode Failure

RLC Mode: AM
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
RLC Mode: AM
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 UEs 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 doesnt 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
This message contains only one IE as shown below;

ue-CapabilityRequest: List of the RATs for which the UE is requested to transfer the UE radio access capabilities
i.e. E-UTRA, UTRA, GERAN-CS, GERAN-PS, CDMA2000
UE Capability Information
RLC Mode: AM
The UE CAPABILITY INFORMATION message is used to transfer of UE radio access

capabilities requested by the E-UTRAN in UE CAPABILITY ENQUIRY.
ueCapabilityRAT-Container is the container for the UE capabilities of the

indicated RAT. The encoding is defined in the specification of each RAT. For E-UTRA,
the encoding of UE capabilities is defined in the IE UE-EUTRA-Capability which is
explained below
Some important parameters in UE-EUTRA-Capability IE are given below:

accessStratumRelease: Set to Rel8, Rel9, Rel10 and so on (based on the UEs release)
maxNumberROHC-ContextSessions: Set to the maximum number of concurrently active ROHC contexts supported
by the UE. cs2 corresponds with 2 (context sessions), cs4 corresponds with 4 and so on
ue-Category: As per Rel10, the possible values are 1 to 8 (Ref: TS 36.306)
ue-TxAntennaSelectionSupported: TRUE indicates that the UE is capable of supporting UE transmit antenna
selection as described in TS 36.213
halfDuplex: If halfDuplex is set to true, only half duplex operation is supported for the band, otherwise full duplex
operation is supported. This entry is present in each of the supported bands
bandListEUTRA: One entry corresponding to each supported E-UTRA band listed in the same order as
insupportedBandListEUTRA
interFreqBandList: One entry corresponding to each supported E-UTRA band listed in the same order as
insupportedBandListEUTRA
interFreqNeedForGaps: Indicates need for measurement gaps when operating on the E-UTRA band given by the
entry in bandListEUTRA and measuring on the E-UTRA band given by the entry in interFreqBandList
interRAT-BandList: One entry corresponding to each supported band of another RAT listed in the same order as in
the interRAT-Parameters
interRAT-NeedForGaps: Indicates need for DL measurement gaps when operating on the E-UTRA band given by the
entry in bandListEUTRA and measuring on the inter-RAT band given by the entry in the interRAT-BandList
SupportedBandUTRA-FDD: UTRA band as defined in TS 25.101
SupportedBandGERAN: GERAN band as defined in TS 45.005
RRC Connection Reconfiguration
RLC Mode: AM
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
Differences with 3G system's radio resource configuration procedure:

In LTE, RRC CONNECTION RECONFIGURATION is the only message used to perform all logical, transport, and
physical channel configurations where as in case UMTS, there exists Transport Channel, Physical Channel and Radio
Bearer Reconfiguration messages
In LTE, RRC CONNECTION RECONFIGURATION can also be used to send NASdedicated signalling to the UE to reduce
the latency whereas this option is not available in 3G
LTE has only one RRC connected mode state (RRC_CONNECTED), so it has only one Temporary Radio Network
Temporary Identity (RNTI) i.e. C-RNTI
In 3G, MEASUREMENT CONTROL is used to setup/modify/release measurements where as in
LTE, RRCCONNECTION RECONFIGURATION message is the only message for this purpose
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
If the UE is unable to comply with (part of) the configuration included in

the RRC CONNECTIONRECONFIGURATION message, the UE shall continue using the configuration used prior to the
reception of RRCCONNECTION RECONFIGURATION message. If the security has not been activated, UE should
leaveRRC_CONNECTED state, else, UE initiates the connection re-establishment procedure which is used to
resumeSRB1 operation and to reactivate security
RRC Connection Reconfiguration Complete
RLC Mode: AM
The RRC CONNECTION RECONFIGURATION COMPLETE message is used to confirm the successful completion
of an RRC CONNECTION RECONFIGURATION
RRC Connection Reestablishment Request

The purpose of RRC CONNECTION RE-ESTABLISHMENT procedure is to re-establish the RRC connection,
which involves the resumption of SRB1 operation and the re-activation of security (without changing algorithms).
The UE shall only initiate this procedure when AS security has been activated.
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 doesnt 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
RRC Connection Reestablishment Request Message

RLC Mode: TM
IEs in RRC CONNECTION REESTABLISHMENT REQUEST message are given below:
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
RRC Connection Reestablishment

RLC Mode: TM
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
RLC Mode: AM
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.
RRC Connection Reestablishment Reject

RLC Mode: TM
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
MOBILITY FROM EUTRA COMMAND message

RLC Mode: AM
Some of the IEs in MOBILITY FROM EUTRA COMMAND message are described below:
cs-FallbackIndicator: Indicates if the CS Fallback procedure to UTRAN or GERAN is triggered

Purpose: Indicates which type of mobility procedure the UE is requested to perform (Handover, CCO, eCSFBetc)
TargetRAT-Type: This IE indicates the target RAT type (utra, geran, cdma2000-1XRTT, cdma2000-HRPD)
TargetRAT-MessageContainer: This field contains a message specified in another standard, as indicated by the
targetRAT-Type. It carries information about the target cell identifier(s) and radio parameters relevant for the
target RAT. This means that the actual handover command message is built by the target RAT and is sent to the
source eNodeB. The source eNodB includes this actual handover command in the MOBILITY FROM EUTRA COMMAND
CarrierFreq: Contains the carrier frequency of the target GERAN cell
SystemInfoListGERAN: If the IE purpose is CCO and if this field is not present, the UE has to acquire SI/PSI from
the GERAN cell
Mobility from E-UTRA failure
Either of the following condition is treated as Mobility from E-UTRA failure
T304 expiry (mobility from E-UTRA failure)
If the UE does not succeed in establishing the connection to the target RAT
If the UE is unable to comply with (part of) the configuration included in
theMobilityFromEUTRACommand message
If there is a protocol error in the inter RAT information included in the MobilityFromEUTRACommandmessage,
causing the UE to fail the procedure according to the specifications applicable for the target RAT
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
RLC Mode: AM
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
The UE can be requested to perform the following types of measurements:
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
Signalling Radio Bearer: SRB1 or SRB2
RLC Mode: AM
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
Signalling Radio Bearer: SRB2 or SRB1
RLC Mode: AM
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 IE dedicatedInfoType shall carry dedicatedInfoNAS or dedicatedInfoCDMA2000-1XRTT (in case

ofCDMA2000 1XRTT information) or dedicatedInfoCDMA2000-HRPD (in case of CDMA2000 HRPD information)
RRC Connection Release
RLC Mode: AM
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
Some of the IEs in RRC CONNECTION RELEASE message

ReleaseCause: The IE releaseCause is used to indicates the reason for releasing the RRC
Connection(Ex:- loadBalancingTAUrequired, cs-FallbackHighPriority, or other)
RedirectedCarrierInfo: The redirectedCarrierInfo indicates a carrier frequency which is used to redirect the UE to
an E-UTRA or an inter-RAT carrier frequency
IdleModeMobilityControlInfo: This IE provides dedicated cell reselection priorities.
FreqPriorityListX: Provides a cell reselection priority for each frequency, by means of separate lists for each RAT
(including E-UTRA)
SystemInformation: Container for system information of the GERAN cell. Each OCTET STRING in
SystemInfoListGERAN contains one complete System Information (SI) message as defined in TS 44.018
cellInfoList: Used to provide system information of one or more cells on the redirected inter-RAT carrier frequency.
The system information can be used if, upon redirection, the UE selects an inter-RAT cell indicated by
the physCellId and carrierFreq (GERAN) or by the physCellId (other RATs).
utra-BCCH-Container: Contains System Information Container message as defined in TS 25.331
Paging
Signalling Radio Bearer: N/A
RLC Mode: TM
Logical Channel: PCCH
Transport Channel: PCH
E-UTRAN initiates the paging procedure by transmitting a PAGING message at the UE's paging occasion as
specified in TS 36.304. E-UTRAN may address multiple UEs within a PAGING message by including
onePagingRecord for each UE
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
IEs in PAGING message:

CN-Domain: Indicates the origin of paging (ps or cs)
UE-Identity: Provides the NAS identity of the UE that is being paged (S-TMSI or IMSI)
SystemInfoModification: If present, this IE indicates a BCCH modification other than SIB10, SIB11 and SIB12
etws-Indication: If present, this IE indicates an ETWS primary notification and/or ETWS secondary notification
cmas-Indication: If present, this IE indicates a CMAS notification
Master Information Block
RLC Mode: TM
Logical Channel: BCCH
Transport Channel: BCH
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)
IEs in the MASTER INFORMATION BLOCK message

dl-Bandwidth: Transmission bandwidth configuration, nRB in downlink. The value n6 corresponds to 6 resource
blocks, n15 to 15 resource blocks and so on. Possible values are n6, n15, n25, n50, n75, and n100. Table1 below
gives the corresponding mapping to the actual channel bandwidth (Reference: 3GPP TS 36.101)
systemFrameNumber: Defines the 8 most significant bits of the SFN
phich-Config: This IE is used to specify the PHICH configuration
System Information Block Type 1
RLC Mode: TM
SystemInformationBlockType1 (SIB1) contains information relevant when evaluating if a UE is allowed to

access a cell. Also, it supplies the UE with the scheduling of other system information. SIBs other than SIB1 are
carried in SystemInformation (SI) messages and mapping of SIBs to SI messages is flexibly configurable
byschedulingInfoList included in SIB1
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
Some of the IEs in SystemInformationBlockType1 message:

PLMN-IdentityList: List of PLMN identities. The first listed PLMN-Identity is the primary PLMN
TrackingAreaCode: A trackingAreaCode that is common for all the PLMNs listed
Cellidentity: Identity of the cell
CellBarred: 'barred means the cell is barred
IntraFreqReselection: Used to control cell reselection to intra-frequency cells when the highest ranked cell is
barred, or treated as barred by the UE
CSG-Indication: If this IE is set to TRUE the UE is only allowed to access the cell if the CSG identity matches an
entry in the CSG whitelist that the UE has stored
p-Max: Maximum power value applicable for the cell. If this IE is absent, then the UE applies the maximum power
according to the UE capability
freqBandIndicator: Operating frequency band of the cell as defined in TS 36.101 [Table 5.5-1].
si-Periodicity: Periodicity of the SI-message in radio frames, such that rf8 denotes 8 radio frames, rf16 denotes 16
radio frames, and so on
sib-MappingInfo: List of the SIBs mapped to this SystemInformation message. There is no mapping information
of SIB2; it is always present in the first SystemInformation message listed in the schedulingInfoList list.
si-WindowLength: Common SI scheduling window for all SIs. Unit in milliseconds, where ms1 denotes 1
millisecond, ms2 denotes 2 milliseconds and so on
systemInfoValueTag: Common for all SIBs other than MIB, SIB1, SIB10, SIB11 and SIB12. Change of MIB and SIB1 is
detected by acquisition of the corresponding message
csg-Identity: Identity of the Closed Subscriber Group within the primary PLMN the cell belongs to. This field is
present in a CSG cell
ims-EmergencySupport: Indicates whether the cell supports IMS emergency bearer services for UEs in limited
service mode. If absent, IMS emergency call is not supported by the network in the cell for UEs in limited service
mode

RLC Mode: TM
SystemInformationBlockType2 (SIB2) contains radio resource configuration
information that is common for all UEs. It contains access barring information, radio
resource configuration of common and shared channels, timers and constants which
are used by UEs, uplink power control information etc.
SIB2 is not specifically included in the scheduling information in SIB1 but it is

always mapped to the SI message that corresponds to the first entry in the list of SI
messages in schedulingInfoList in SIB1
SIB2 also gives information about the uplink carrier frequency and the uplink
channel bandwidth in terms of number of Resource Blocks
Some of the IEs in SystemInformationBlockType2:
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
RLC Mode: TM
The SystemInformationBlockType3 (SIB3) contains cell re-selection information

common for intra-frequency, inter-frequency and/or inter-RAT cell re-selection (i.e.
applicable for more than one type of cell re-selection but not necessarily all)
SIB3 also contains cell reselection priority information for the concerned
carrier frequency or a set of frequencies
RLC Mode: TM
The SystemInformationBlockType4 (SIB4) contains intra-frequency neighboring

cell information for intra-LTE intra-frequency cell reselection, such as neighbor cell
list, and black listed Cell list

RLC Mode: TM
The SystemInformationBlockType5 (SIB5) contains neighbor cell related

information for inter-frequency cell-reselection i.e. the information about neighbor E-
UTRA frequencies
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)
The purpose of the Additional update result IE is to provide additional

information about the result of a combined attach procedure. 00-no additional
information; 01-CS Fallback not preferred; 10-SMS only; 11-reserved
Attach Reject
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
The ATTACH COMPLETE message is sent by the UE to the network in response to

anATTACH ACCEPT message
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
If the ACTIVATE DEFAULT BEARER CONTEXT REQUEST message combined with

theATTACH ACCEPT is not accepted by the UE due to failure in the UE's ESM sublayer, then
the UE shall not send ATTACH COMPLETE message. Instead, it shall initiate the detach
procedure by sending a DETACH REQUEST message to the network. Further UE's behavior
is implementation specific
Tracking Area Update Request
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...)
The UE initiates the TAU procedure by sending TRACKING AREA UPDATE
REQUESTmessage. The IEs (some of them are explained below) in this message
include EPS update type, NAS key set identifier, Old GUTI, GPRS ciphering key sequence
number, Old P-TMSI signature, Additional GUTI, UE network capability, Last visited
registered TAI, DRX parameter, UE radio capability information update needed, EPS
bearer context status, MS network capability, Old location area identification, Supported
Codecs, Additional update type, Voice domain preference and UE's usage setting, Device
properties 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 Old GUTI shall be handled as follows:

UEs supporting A/Gb mode or Iu mode or both:
- If TIN = "P-TMSI" and the UE holds a valid P-TMSI and RAI, the UE shall map the P-TMSI and
RAI into the Old GUTI IE, and include Old GUTI type IE with GUTI type set to "mapped
GUTI". Additionally, if the UE holds a valid GUTI, then it shall be indicated in the
IE Additional GUTI
- If TIN = GUTI or RAT-related TMSI and the UE holds a valid GUTI, the UE shall indicate
the GUTI in the Old GUTI IE, and include Old GUTI type IE with GUTI type set to "native
GUTI"
UEs not supporting A/Gb mode or Iu mode: The UE shall include a valid GUTI in the Old
GUTI IE. In addition, the UE shall include Old GUTI type IE with GUTI type set to "native
GUTI"
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 purpose of the Device properties IE is to indicate if the MS is configured

for NAS signalling low priority. The network uses the Device properties IE for core-
network congestion handling and for charging purposes. This IE can indicate MS is not
configured for NAS signalling low priority or MS is configured for NAS signalling low
priority
GUTI
The Globally Unique Temporary UE Identity (GUTI) provides an unambiguous
identification of the UE that does not reveal the UE or the user's permanent identity in
the EPS
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
Globally Unique MME Identifier (GUMMEI) shall be constructed from

the MCC, MNC and MME Identifier (MMEI). The MMEI shall be constructed from an MME
Group ID (MMEGI) and an MME Code (MMEC). The structure of the GUTI is illustrated in
the figure below
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 UEs 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,
SQN xor AK = 6e323b36c46c

AMF: 5555
MAC: a3df0e6e323b6391
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 only important IE in the AUTHENTICATION FAILURE message is authentication failure

parameter which is sent if and only if the EMM cause is #21 "synch failure". It shall include the
response to the authentication challenge from the USIM, which is made up of the AUTS parameter
NAS: Security Mode Command

The purpose of the NAS security mode control procedure is to take an EPS security context into
use, and initialize and start NAS signalling security between the UE and the MME. The MME starts
this procedure by sending SECURITY MODE COMMAND message
The MME may send a SECURITY MODE COMMAND in order to change the NAS security algorithms for
a current EPS security context already in use
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)

Identity
Request
The identification procedure is used by the network to request a particular UE to provide specific
identification parameters, e.g. IMSI, IMEI etc
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 doesnt 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"

Service Request
The SERVICE REQUEST message is sent by the UE to the network to request the establishment of a NAS
signalling connection and of the radio and S1 bearers
The UE shall send the 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 mode, has uplink cdma2000 signalling pending to be transmitted over E-UTRAN
e) The UE performs an inter-system change from S101 mode to S1 mode and has user data pending
For the above cases, if the UE is not configured for NAS signalling low priority, the UE initiates
the service request procedure by sending a SERVICE REQUEST message to the MME
For the above cases, if the UE is configured for NAS signalling low priority, but the network
doesnt 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 doesnt follow the structure of standard L3 message
(see the example below)
The IE KSI and sequence numbers 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
Extended Service Request

The EXTENEDED SERVICE REQUEST message is sent by the UE to the network to initiate a "CS
fallback or 1xCS fallback call" or respond to an "MT CS fallback or 1xCS fallback" request from the
network
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 cdma2000signalling 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 cdma20001xRTT, 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 IEs 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

NAS Level Congestion Control
When the network detects EMM signalling congestion, it may perform NAS level congestion
control. The NAS level congestion control consists of general NAS level mobility
management control andsubscribed APN based congestion control
Under general overload conditions the network may reject mobility management signalling
requests from UEs. The network should not reject requests for emergency bearer services and
requests from high priority users
When general NAS level mobility management control is active, the network may prioritize
rejecting messages that has the NAS signalling low priority indicator before rejecting messages
without the NAS signalling low priority indicator
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

CS Service Notification
The CS SERVICE NOTIFICATION message is sent by the network to notify a UE in EMM-CONNECTED
mode (i.e. NAS signalling connection is already established for the UE) about an incoming CS
service (excluding SMS) over SGs
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
Detach Request (UE initiated)

The UE shall initiate the detach procedure when:
- the UE is switched of
- the USIM is removed from the UE
- the EPS capability of the UE is disabled (detach for EPS services only)
- the UE in CS/PS mode 1 or CS/PS mode 2 of operation wishes to detach for
both EPS services and non-EPS services or for non-EPS services only via a
combined detach procedure etc...
The UE initiates the detach procedure by sending a DETACH

REQUEST message
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 of
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
If the UE is to be switched of, the UE shall try for a period of 5 seconds to

send theDETACH REQUEST message. During this period, the UE may be
switched of as soon as the DETACH REQUEST message has been sent
When the DETACH REQUEST message is received by the network, with

the Detach typeIE set to switch of, the network shall not send a DETACH
ACCEPT message to the UE
When the DETACH REQUEST message is received by the network, with
the Detach typeIE set to normal detach, the network shall send a DETACH
ACCEPT message to the UE
If the Detach type IE set to normal detach and if the UE doesnt

receive DETACH ACCEPT message before the timer T3421 is expired, it shall
re-transmit the DETACH REQUEST message. Upon the 5th expiry of T3421
timer, the UE shall perform local detach
The network and the UE shall deactivate the EPS bearer context(s) locally
without peer-to-peer signalling between the UE and the MME
Detach Request (Network Initiated)

The detach procedure is either initiated by the UE or by the network. The
network
initiates the detach procedure:
- To detach the UE for EPS services or non-EPS services or both

- To disconnect the UE from the last PDN to which it is connected
- To inform the UE to re-attach to the network and re-establish all PDN
connections
If the MME performs a local detach (i.e. no explicit signalling), it will inform
the UE with an EMM message (e.g. SERVICE REJECT or TRACKING AREA
UPDATE REJECT) with EMM cause #10 "implicitly detached" only when the UE
initiates any EMM procedure
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 MME initiates the detach procedure by sending a DETACH

REQUEST message to the UE
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 IE indicates that "re-attach required", the UE shall

deactivate all the active EPS bearer context(s) locally and then send
a DETACH ACCEPT message to the network. Furthermore, the UE shall,
initiate attach or combined attach procedure. The UE should also re-establish
any previously established PDN connections (user interaction is necessary in
some cases when the UE cannot re-activate the EPS bearer(s) automatically)
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
For UE initiated Detach procedure, check my earlier post here
Reference 3GPP TS 24.301

Detach Accept
The DETACH ACCEPT message is sent either by the network or the UE to
indicate that the detach procedure has been completed
In the case of an UE initiated DETACH REQUEST , with the Detach type IE set
to switch of, 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
In the case of network initiated DETACH REQUEST, the UE shall

send DETACH ACCEPTmessage, to indicate the successful completion of the
detach procedure

Transport of NAS messages
The purpose of the transport of NAS messages procedure is to carry SMS
messages in anencapsulated form between the MME and 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 network initiates this procedure by sending a DOWNLINK NAS

TRANSPORT message which contains the actual SMS message in the NAS
message container IE
The IE NAS message container is used to encapsulate the SMS messages
transferred between the UE and the network. This IE can contain SMS
messages such as CP-DATA, CP-ACK, or CP-ERROR
Activate Default EPS Bearer Context Request
The purpose of the default bearer context activation procedure is to
establish a default EPS bearer context between the UE and the EPC.
The default EPS bearer context activation procedure is initiated by the
network as a response to the PDN CONNECTIVITY REQUEST message from
the UE.
The default bearer is a non-Guaranteed Bit Rate (GBR) bearer. A dedicated
bearer can be either a GBR or a non-GBR bearer.
The default bearer remains established throughout the lifetime of the PDN
connection to provide the UE with IP connectivity to the PDN
The default bearer context activation procedure can be part of the Attach
procedure, and if the attach procedure fails, the UE shall consider that the
default bearer activation has implicitly failed
Once the UE is successfully attached, the UE can request the MME to set up
connections to additional PDNs. For each additional connection, the MME will
activate a separate default EPS bearer context
The MME shall initiate the default bearer context activation procedure by
sending anACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST message
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
When the default bearer is activated as the response to a stand-alone PDN
CONNECTIVITY REQUEST message apart from the attach procedure, the MME
shall send the ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST message
alone, and start the timer T3485
The MME shall assign and include an EPS bearer identity in the ACTIVATE
DEFAULT EPS BEARER CONTEXT REQUEST message.
The MME shall retrieve the PTI (Procedure Transaction Identity) from the PDN
CONNECTIVITY REQUEST message and include it in the ACTIVATE DEFAULT
EPS BEARER CONTEXT REQUEST message
Typical IEs in ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST message
include EPS bearer identity, Procedure transaction identity (PTI), EPS QoS,
Access point name (APN), PDN address, Negotiated QoS, Negotiated LLC
SAPI, Packet flow Identifier, APN-AMBR (APN aggregate maximum bit
rate), ESM cause, and Protocol configuration options etc
The network shall include the IE ESM cause, if the network allocated a PDN
address of a PDN type which is diferent from the PDN type requested by the
UE

Activate
Default EPS Bearer Context Accept
After receiving the ACTIVATE DEFAULT EPS BEARER CONTEXT
REQUEST message, the UE shall stop timer T3396 if it is running for the APN
indicated in the message and send anACTIVATE DEFAULT EPS BEARER
CONTEXT ACCEPT message.
The UE should check the Procedure transaction identity (PTI) in
the ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST message to identify
the UE requested PDN connectivity procedure to which this default bearer
context activation is related.
When the default bearer is activated as part of the attach procedure, the UE
shall send the ACTIVATE DEFAULT EPS BEARER CONTEXT ACCEPT message
together with ATTACH COMPLETE message.
When the default bearer is activated in response to the stand-alone PDN
CONNECTIVITY REQUEST message, the UE shall send the ACTIVATE DEFAULT
EPS BEARER CONTEXT ACCEPTmessage alone.
The UE shall include EPS bearer identity and Procedure transaction identity
IEs in theACTIVATE DEFAULT EPS BEARER CONTEXT ACCEPT message
The IE Protocol configuration options is included in the message when
the UE wishes to transmit (protocol) data (e.g. configuration parameters,
error codes or messages/events) to the network
Upon receipt of the ACTIVATE DEFAULT EPS BEARER CONTEXT
ACCEPT message, the MME shall stop the timer T3485, if the timer is running
Activate Dedicated EPS Bearer Context Request

The purpose of the dedicated EPS bearer context activation procedure is to
establish an EPS bearer context with a specific QoS and TFT between the UE
and the EPC.
A PDN connection consists of one Default EPS bearer and, depending on the
service for which the connection is used, a number of dedicated EPS bearers.
FYI.., a default EPS bearer is established during the Attach or Standalone PDN Connectivity
procedure. Any additional EPS bearer that is established for the same PDN connection is
referred to as a dedicated EPS bearer. Dedicated EPS bearers are activated and deactivated
depending on the service used but the default bearer remains established throughout the
lifetime of the PDN connection. The network decides if dedicated bearers need to be setup
or not and what QoS settings should be applied for the dedicated bearers.
The dedicated EPS bearer can be either guaranteed bit rate (GBR) or non-
GBR.
The dedicated EPS bearer context activation procedure is initiated by the
NW, but may be requested by the UE by means of the UE requested bearer
resource allocation/modification procedure.
This procedure can be part of the attach procedure or be initiated together
with theDefault EPS bearer context activation procedure when the UE
initiates a stand-alone PDN connectivity procedure.
If the attach procedure or the Default EPS bearer context
activation procedure fails, then the UE shall consider that the dedicated
bearer activation has implicitly failed.
The MME shall initiate the dedicated bearer context activation procedure by
sending anACTIVATE DEDICATED EPS BEARER CONTEXT REQUEST message
and start the timer T3485
The MME allocates and includes the EPS Bearer Identity in the ACTIVATE
DEDICATED EPS BEARER CONTEXT REQUEST message.
The MME shall include the EPS bearer identity of the associated default
bearer as theLinked EPS Bearer Identity in the ACTIVATE DEDICATED EPS
BEARER CONTEXT REQUESTmessage.
If this procedure was initiated by a UE requested bearer resource
allocation/modification procedure, the ACTIVATE DEDICATED EPS BEARER
CONTEXT REQUEST message shall contain the Procedure Transaction
Identity (PTI) value received by the MME from the UE
The other IEs in the ACTIVATE DEDICATED EPS BEARER CONTEXT
REQUEST include EPS QoS, Traffic Flow Template (TFT), Transaction Id,
Negotiated QoS, Negotiated LLC SAPI, Radio Priority, Packet flow Id, Protocol
configuration options etc

Activate Dedicated EPS Bearer Context Reject
The UE may reject the ACTIVATE DEDICATED EPS BEARER CONTEXT
REQUEST from the MME by sending an ACTIVATE DEDICATED EPS BEARER
CONTEXT REJECT message.
The ACTIVATE DEDICATED EPS BEARER CONTEXT REJECT message shall
include the EPS Bearer Identity and an ESM Cause value indicating the
reason for rejecting the dedicated EPS bearer context activation request.
The ACTIVATE DEDICATED EPS BEARER CONTEXT REJECT message contains
an ESM cause that typically indicates one of the following values:
#26: insufficient resources

#31: request rejected, unspecified
#41: semantic error in the TFT operation
#42: syntactical error in the TFT operation
#43: invalid EPS bearer identity
#44: semantic error(s) in packet filter(s)
#45: syntactical error(s) in packet filter(s) or
#95 111: protocol errors
After receiving the ACTIVATE DEDICATED EPS BEARER CONTEXT

REJECT message, the MME shall stop the timer T3485 and abort the
dedicated EPS bearer context activation procedure
Activate Dedicated EPS Bearer Context Accept

The ACTIVATE DEDICATED EPS BEARER CONTEXT ACCEPT message is sent by
the UE to the network to acknowledge the activation of a dedicated EPS
bearer context associated with the same PDN address (es) and APN as an
already active EPS bearer context
Upon receipt of the ACTIVATE DEDICATED EPS BEARER CONTEXT
REQUEST message, the UE shall stop timer T3396, if it is running for the APN
associated with the PDN connection and check the received TFT before
taking it into use.
The linked EPS Bearer Identity included in the ACTIVATE DEDICATED EPS
BEARER CONTEXT REQUEST message indicates to the UE to which default
bearer, IP address and PDN the dedicated bearer is linked.
The UE shall include EPS bearer identity and Procedure transaction identity
IEs in theACTIVATE DEDICATED EPS BEARER CONTEXT ACCEPT message.
The IE Protocol configuration options is included in the message when
the UE wishes to transmit (protocol) data (e.g. configuration parameters,
error codes or messages/events) to the network
Upon receipt of the Activate Dedicated EPS Bearer Context Accept message,
the MME shall stop the timer T3485
PDN Connectivity Request

The PDN connectivity procedure is used by the UE to request the setup of a
default EPS bearer to a PDN.
The UE requests connectivity to a PDN by sending a PDN CONNECTIVITY
REQUEST message to the network. If this request is accepted by the network,
then it initiates the establishment of a default EPS bearer context
activation procedure.
This procedure is used either to establish the first default bearer (PDN
CONNECTIVITY REQUEST is sent along with initial attach message), or to
establish subsequent default bearers to additional PDNs (a stand-alone PDN
CONNECTIVITY REQUEST is sent by the UE).
If the UE is in EMM-IDLE mode, the Service Request procedure is performed
before the PDN Connectivity procedure can be initiated.
If there is already a PDN connection for emergency bearer services
established, the UE shall not request an additional PDN connection for
emergency bearer services.
A UE attached for emergency bearer services shall not request a PDN
connection to any other PDN.
When the PDN CONNECTIVITY REQUEST message is sent together with
an ATTACH REQUESTmessage, the UE shall not include the APN.
When requesting connectivity to an additional PDN, the UE shall include the
requested APN (in the stand-alone PDN CONNECTIVITY REQUEST)
except for emergency bearer services
The UE may set the ESM information transfer flag in the PDN
CONNECTIVITY REQUESTmessage to indicate that it has ESM information,
i.e. protocol configuration options, or APN, or both, that needs to be
transferred to the MME after the NAS signalling security has been activated
If the ESM information transfer flag is set in PDN CONNECTIVITY
REQUEST message, the MME initiates (after NAS sigalling security is activated)
the ESM information requestprocedure in which the UE can provide the
MME with protocol configuration options or APN or both.
If the UE wishes to connect to a PDN using default APN, it need
not include the APN in theAccess Point Name IE in the ESM INFORMATION
RESPONSE or PDN CONNECTIVITY REQUEST(stand-alone) message. The only
exceptional case is, if the connectivity to a PDN using the default APN
requires PAP/CHAP, then the UE should include the APN in the Access point
name IE
The UE shall set the Request Type IE to "initial request" when the UE is
establishing a new PDN connectivity to a PDN in an attach procedure or in a
stand-alone PDN connectivity procedure.
The UE shall set the Request Type IE to "emergency" when the UE is
requesting a new PDN connectivity for emergency bearer services.
The Request Type IE is set to "handover" when the connectivity to a PDN is
established upon handover from a non-3GPP access network and the UE was
connected to that PDN before the handover to the 3GPP access network
The other IEs in the PDN CONNECTIVITY REQUEST message include EPS
Bearer Identity, Procedure Transaction Identity, PDN Type, and Device
Properties etc
If the UE includes ESM information transfer flag in the PDN CONNECTIVITY
REQUESTmessage, the MME waits for completion of the ESM information
request procedure before proceeding with the PDN connectivity procedure.
The MME then checks if connectivity with the requested PDN can be
established.
If requested APN is not included in the PDN CONNECTIVITY REQUEST or
the ESM INFORMATION RESPONSE message and the request type is diferent
from "emergency", the MME shall use the default APN as the requested APN.
If the request type is "emergency", the MME shall use the APN configured for
emergency bearer services

PDN
Connectivity Reject
If the PDN CONNECTIVITY REQUEST cannot be accepted by the network,
then the MME shall send a PDN CONNECTIVITY REJECT message to the UE.
The PDN CONNECTIVITY REJECT message shall contain the Procedure
Transaction Identity (PTI) which should match the PTI value in the PDN
CONNECTIVITY REQUEST sent by UE
Also, this message shall contain an ESM cause value which indicates the
reason for rejecting the UE requested PDN connectivity.
The ESM cause IE typically indicates one of the following ESM cause values:
#8: operator determined barring
#26: insufficient resources
#27: missing or unknown APN
#28: unknown PDN type
#29: user authentication failed
#30: request rejected by Serving GW or PDN GW
#31: request rejected, unspecified
#32: service option not supported
#33: requested service option not subscribed
#34: service option temporarily out of order
#35: PTI already in use
#38: network failure
#50: PDN type IPv4 only allowed
#51: PDN type IPv6 only allowed
#53: ESM information not received
#54: PDN connection does not exist
#55: multiple PDN connections for a given APN not allowed
#95 111: protocol errors
#112: APN restriction value incompatible with active EPS bearer context.
If the ESM cause value is #26 "insufficient resources" or #27 "missing or

unknown APN", the network may include a value for timer T3396 in the PDN
CONNECTIVITY REJECT message. In such a case, the UE should take diferent
actions depending on the timer value and reject cause. Refer to section
6.5.1.4 in the 3GPP TS 24.301 for detailed information
PDN Disconnect Request

The purpose of the PDN Disconnect procedure is for a UE to request the
network to disconnect 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.
Successful completion of this procedure means that, all EPS bearer contexts
established towards this PDN, including the default EPS bearer context, are
released.
In order to disconnect from the last PDN (the one and the only PDN to which
the UE has the connection), the UE should not use PDN disconnect
procedure. Instead, it shall use detach procedure
In order to request PDN disconnection from a PDN, the UE shall send a PDN
DISCONNECT REQUEST message to the MME and start the timer T3492.
In this message, The UE shall set the value of Linked EPS Bearer
Identity IE as the EPS Bearer Identity of default bearer associated with the
PDN for which UE is sending the disconnect request.
If the network accepts the PDN DISCONNECT REQUEST sent by the UE, then
it shall send theDEACTIVATE EPS BEARER CONTEXT REQUEST message
including the linked EPS bearer identity of the default bearer associated with
the PDN to disconnect from.
If the network doesnt accept the PDN DISCONNECT REQUEST sent by the
UE, the MME shall send a PDN DISCONNECT REJECT message to the UE which
shall contain the PTI and anESM cause IE indicating the cause for the
rejection
Upon receipt of the DEACTIVATE EPS BEARER CONTEXT REQUEST or PDN
DISCONNECT REJECT message, the UE shall stop the timer T3492
If there is no response received for the PDN DISCONNECT REQUEST before
the expiry of the timer T3492, the UE shall resend the PDN DISCONNECT
REQUEST and shall reset and restart timer T3492. This retransmission is
repeated four times, i.e. on the fifth expiry of timer T3492, the UE shall abort
the procedure and deactivate all EPS bearer contexts for this PDN connection
locally without peer-to-peer signalling between the UE and the MME
Deactivate EPS Bearer Context Request

The purpose of the EPS bearer context deactivation procedure is to
deactivate an EPS bearer context or disconnect from a PDN by deactivating
all EPS bearer contexts to that PDN.
This procedure is initiated by the network, and it may be triggered by the UE
by means of the Bearer Resource Modification or PDN Disconnect procedure.
If a NAS signalling connection exists when the MME initiates this procedure,
then the MME shall initiate the EPS bearer context deactivation procedure by
sending a DEACTIVATE EPS BEARER CONTEXT REQUEST message to the UE
and start the timer T3495.
If there no NAS signalling connection exists when the MME initiates this
procedure, then the ESM entity in the MME shall locally deactivate the EPS
bearer context towards the UE without any peer-to-peer ESM signalling
between the MME and the UE.
The DEACTIVATE EPS BEARER CONTEXT REQUEST message contains an ESM
cause typically indicating one of the following:
#8: operator determined barring
#36: regular deactivation
#38: network failure
#39: reactivation requested or
#112: APN restriction value incompatible with active EPS bearer context
If the deactivation is triggered by a UE initiated bearer resource modification
or PDN disconnect procedure, the DEACTIVATE EPS BEARER CONTEXT
REQUEST message shall contain the PTI value received from the UE in the
corresponding message.
When the MME wants to deactivate all EPS bearer contexts to a PDN and
thus disconnect the UE from the PDN, the MME shall include the EPS Bearer
Identity of the default bearer associated to the PDN in the DEACTIVATE EPS
BEARER CONTEXT REQUEST message.
If the MME doesnt receive a response for DEACTIVATE EPS BEARER
CONTEXT REQUESTbefore the expiry of the timer T3495, the MME shall
resend this message and shall reset and restart T3495. This retransmission is
repeated four times, i.e. on the fifth expiry of T3495, the MME shall abort the
procedure and deactivate the EPS bearer context locally without any peer-to-
peer ESM signalling between the MME and the UE.
The IE Protocol Configuration Options is included in the message if the
network wishes to transmit (protocol) data (e.g. configuration parameters,
error codes or messages/events) to the UE.

Deactivate EPS Bearer Context Accept
The UE after receiving the DEACTIVATE EPS BEARER CONTEXT
REQUEST message, shall delete the EPS bearer context identified by the EPS
bearer identity.
If the EPS bearer identity indicated in the DEACTIVATE EPS BEARER CONTEXT
REQUEST is that of the default bearer to a PDN, the UE shall delete all EPS
bearer contexts associated to the PDN.
After deactivating the identified EPS bearer context (s), the UE shall respond
to the MME with the DEACTIVATE EPS BEARER CONTEXT ACCEPT message.
If due to the EPS bearer context deactivation, there is only one PDN
connection active and that is for emergency bearer services, then the UE
shall consider itself attached for emergency bearer services only
In the DEACTIVATE EPS BEARER CONTEXT ACCEPT message, the UE shall
include Procedure Transaction Identity (PTI) as received in the DEACTIVATE
EPS BEARER CONTEXT REQUESTmessage
Other IEs in the DEACTIVATE EPS BEARER CONTEXT ACCEPT message
include, EPS bearer identity and Protocol configuration options
Bearer Resource Allocation Request

The purpose of the UE requested bearer resource allocation procedure is (for
an UE) to request an allocation of bearer resources for a traffic flow
aggregate.
The UE requests a specific QoS demand (QCI) and optionally sends a
Guaranteed Bit Rate (GBR) requirement for a new traffic flow aggregate.
If accepted by the network, this procedure invokes a dedicated EPS bearer
context activation procedure or an EPS bearer context modification
procedure.
If there is a PDN connection for emergency bearer services established, the
UE shall not request additional bearer resources for this PDN connection.
The UE initiates this procedure by sending a BEARER RESOURCE
ALLOCATION REQUESTmessage to the MME and starts the timer T3480.
The UE shall include the IE Linked EPS bearer identity and set it as the
EPS bearer identity of the default EPS bearer associated with the requested
bearer resource.
The UE shall set the TFT operation code in the Traffic flow aggregate IE to
"Create new TFT".
In the Required traffic flow QoS IE, the UE shall indicate a QCI (QoS Class
Identifier) and, if the UE also includes a GBR, the additional GBR required for
the traffic flow aggregate.
If the bearer resource allocation request is accepted by the network, the
MME shall send either an ACTIVATE DEDICATED EPS BEARER CONTEXT
REQUEST or MODIFY EPS BEARER CONTEXT REQUEST message with a
PTI value received in the BEARER RESOURCE ALLOCATION
REQUEST message.
If the UE doesnt receive response to the BEARER RESOURCE ALLOCATION
REQUESTmessage before the expiry of the timer T3480, the UE shall resend
this message and reset/restart T3480. This retransmission is repeated four
times, i.e. on the fifth expiry of T3480, the UE shall abort the procedure,
release the PTI allocated for this activation.
The Protocol Configuration Options IE is included in the BEARER
RESOURCE ALLOCATION REQUEST message if the UE wishes to transmit
(protocol) data (e.g. configuration parameters, error codes or
messages/events) to the network.
The UE shall include the IE Device Properties in this message if the UE is
configured for NAS signalling low priority

Bearer Resource Allocation Reject
If the bearer resource allocation request cannot be accepted by the network,
then the MME sends a BEARER RESOURCE ALLOCATION REJECT message to
the UE.
The BEARER RESOURCE ALLOCATION REJECT message shall contain
the Procedure Transaction Identity (PTI) which is equal to the PTI value in
the BEARER RESOURCE ALLOCATION REQUEST received from the UE
This message shall also contain an ESM Cause value indicating the reason
for rejecting the UE requested bearer resource allocation.
The UE, after receiving the BEARER RESOURCE ALLOCATION
REJECT message, shall stop the timer T3480 and release the traffic flow
aggregate description associated to the received PTI value
If the ESM cause value is #26 "insufficient resources", the network may
include a value for timer T3396 value IE in the BEARER RESOURCE
ALLOCATION REJECT message. Depending on the timer value, the UE shall
take diferent actions as explained in 6.5.3.4 in 3GPP TS 24.301
Bearer Resource Modification Request

The purpose of the UE requested bearer resource modification procedure is
for a UE to request a modification or release of bearer resources for a traffic
flow aggregate or modification of a traffic flow aggregate by replacing or
adding packet filters.
When requesting a modification of bearer resources for a traffic flow
aggregate or a modification of a traffic flow aggregate, the UE can modify
the existing GBR.
If the network accepts this procedure, it invokes a dedicated EPS bearer
context activation, an EPS bearer context modification, or an EPS bearer
context deactivationprocedure.
If there is a PDN connection for emergency bearer services established, the
UE shall not request a modification of bearer resources for this PDN
connection.
In order to request the modification of bearer resources for one traffic flow
aggregate, the UE shall send a BEARER RESOURCE MODIFICATION
REQUEST message to the MME
The UE shall include the EPS bearer identity of the EPS bearer associated
with the traffic flow aggregate in the EPS bearer identity for packet
filter IE.
To request a change of the GBR without changing the packet filter(s), the UE
shall set the TFT operation code in the Traffic flow aggregate IE to "no TFT
operation" and include the packet filter identifier(s) to which the change of
the GBR applies in the Packet filter identifier parameter in the parameters
list.
The UE shall indicate the new GBR requested for the EPS bearer context in
the Required traffic flow QoS IE.
To request a modification of a traffic flow aggregate, the UE shall set the TFT
operation code in the Traffic flow aggregate IE to "Replace packet filters in
existing TFT" or "Add packet filters to existing TFT".
If the TFT operation code is set to "Add packet filters to existing TFT", the UE
shall include the existing packet filter identifier(s) to which the newly added
packet filter(s) is linked in the parameters list.
To request a release of bearer resources, the UE shall set the TFT operation
code in the Traffic flow aggregate IE to "Delete packet filters from existing
TFT".
If the UE includes the Required Traffic Flow QoS IE, the UE shall set the QCI to
the current QCI value of the EPS bearer context.
If the bearer resource modification requested is accepted by the network,
the MME shall send ACTIVATE DEDICATED EPS BEARER CONTEXT REQUEST,
MODIFY EPS BEARER CONTEXT REQUEST or DEACTIVATE EPS BEARER
CONTEXT REQUEST message with a PTI which matches the value used for
the BEARER RESOURCE MODIFICATION REQUEST message.
If the bearer resource modification requested cannot be accepted by the
network, the MME shall send a BEARER RESOURCE MODIFICATION
REJECT message to the UE.

Bearer Resource Modification Reject
If the network cannot accept the bearer resource modification requested by
the UE, then the MME shall send a BEARER RESOURCE MODIFICATION
REJECT message to the UE.
The BEARER RESOURCE MODIFICATION REJECT message shall contain
the Procedure Transaction Identity (PTI) which should match the PTI
value received in the BEARER RESOURCE MODIFICATION REQUEST.
Also, this message shall contain an ESM cause value which indicates the
reason for rejecting the UE requested bearer resource modification.
If the bearer resource modification requested is for an established LIPA PDN
connection, then the network shall reply with a BEARER RESOURCE
MODIFICATION REJECT message with ESM cause #60 "bearer handling not
supported".
If the ESM cause value is #26 "insufficient resources", the network may
include a value for timer T3396 value IE in this message. In such a case, the
UE should take diferent actions depending on the timer value as specified in
section 6.5.4.4 in 3GPP TS 24.301.
After receiving the BEARER RESOURCE MODIFICATION REJECT message, the
UE shall stop the timer T3481 and release the traffic flow aggregate
description associated to the PTI value.
If the ESM cause included in the reject message is #43 "invalid EPS bearer
identity", the UE locally deactivates the EPS bearer context(s) without peer-
to-peer ESM signalling.
RRC Connection Release

RLC Mode: AM
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
Some of the IEs in RRC CONNECTION RELEASE message

ReleaseCause: The IE releaseCause is used to indicates the reason for releasing the RRC
Connection(Ex:- loadBalancingTAUrequired, cs-FallbackHighPriority, or other)
RedirectedCarrierInfo: The redirectedCarrierInfo indicates a carrier frequency which is used to redirect the UE to
an E-UTRA or an inter-RAT carrier frequency
IdleModeMobilityControlInfo: This IE provides dedicated cell reselection priorities.
FreqPriorityListX: Provides a cell reselection priority for each frequency, by means of separate lists for each RAT
(including E-UTRA)
SystemInformation: Container for system information of the GERAN cell. Each OCTET STRING in
SystemInfoListGERAN contains one complete System Information (SI) message as defined in TS 44.018
cellInfoList: Used to provide system information of one or more cells on the redirected inter-RAT carrier frequency.
The system information can be used if, upon redirection, the UE selects an inter-RAT cell indicated by
the physCellId and carrierFreq (GERAN) or by the physCellId (other RATs).
utra-BCCH-Container: Contains System Information Container message as defined in TS 25.331

LTE Messages Analysis

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

LTE Messages Analysis

Uploaded by

Copyright:

Available Formats

RRC Connection Request

Direction: UE => E-UTRAN

IEs in RRC CONNECTION REQUEST message are given below:

ue-Identity (Initial UE-Identity): This IE is included to facilitate contention

establishmentCause:The main cause values and the corresponding NAS

selectedPLMN-Identity: This IE points to a PLMN-Id in the plmn-IdentityList of SIB1. The IE plmn-IdentityList is

RRC Connection Reject

RRC: Security Mode Command

RRC: Security Mode Complete

RRC: Security Mode Failure

This message contains only one IE as shown below;

The UE CAPABILITY INFORMATION message is used to transfer of UE radio access

ueCapabilityRAT-Container is the container for the UE capabilities of the

Some important parameters in UE-EUTRA-Capability IE are given below:

Differences with 3G system's radio resource configuration procedure:

If the UE is unable to comply with (part of) the configuration included in

RRC Connection Reestablishment Request

RRC Connection Reestablishment Request Message

Direction: UE => E-UTRAN

IEs in RRC CONNECTION REESTABLISHMENT REQUEST message are given below:

RRC Connection Reestablishment

RRC Connection Reestablishment Reject

MOBILITY FROM EUTRA COMMAND message

cs-FallbackIndicator: Indicates if the CS Fallback procedure to UTRAN or GERAN is triggered

The UE can be requested to perform the following types of measurements:

The IE dedicatedInfoType shall carry dedicatedInfoNAS or dedicatedInfoCDMA2000-1XRTT (in case

Some of the IEs in RRC CONNECTION RELEASE message

IEs in PAGING message:

IEs in the MASTER INFORMATION BLOCK message

SystemInformationBlockType1 (SIB1) contains information relevant when evaluating if a UE is allowed to

Some of the IEs in SystemInformationBlockType1 message:

System Information Block Type 2

Direction: E-UTRAN => UE

SIB2 is not specifically included in the scheduling information in SIB1 but it is

Some of the IEs in SystemInformationBlockType2:

The SystemInformationBlockType3 (SIB3) contains cell re-selection information

The SystemInformationBlockType4 (SIB4) contains intra-frequency neighboring

System Information Block Type 5

The SystemInformationBlockType5 (SIB5) contains neighbor cell related

The purpose of the Additional update result IE is to provide additional

The ATTACH COMPLETE message is sent by the UE to the network in response to

If the ACTIVATE DEFAULT BEARER CONTEXT REQUEST message combined with

Tracking Area Update Request

The IE Old GUTI shall be handled as follows:

The purpose of the Device properties IE is to indicate if the MS is configured

Globally Unique MME Identifier (GUMMEI) shall be constructed from

SQN xor AK = 6e323b36c46c

Reference: 3GPP TS 24.301

The only important IE in the AUTHENTICATION FAILURE message is authentication failure

Reference: 3GPP TS 24.301

NAS: Security Mode Command

Reference: 3GPP TS 24.301

Reference: 3GPP TS 24.301

Reference: 3GPP TS 24.301

The UE shall send the SERVICE REQUEST message when:

Reference: 3GPP TS 24.301

Extended Service Request

Reference: 3GPP TS 24.301

Reference: 3GPP TS 24.301

Reference: 3GPP TS 24.301

Detach Request (UE initiated)

The UE initiates the detach procedure by sending a DETACH

If the UE is to be switched of, the UE shall try for a period of 5 seconds to