http://howltestuffworks.blogspot.com/2011/10/rrc-connection-request.
html
LTE: 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 SRB0 on 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 are“Service 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 are“Service Request” and “Extended
Service Request”
Example1: RRC CONNECTION REQUEST message with ue-Identity as a randomValue
Example2: RRC CONNECTION REQUEST message with ue-Identity as s-TMSI
Posted by Kumara Swamy
LTE: UE Identities
S-TMSI:
S-TMSI (SAE-Temporary Mobile Subscriber Identity) is a temporary UE
identity provided by the EPC which uniquely identifies the UE within the
tracking area
The S-TMSI is the shortened form of the GUTI to enable more efficient
radio signalling procedures (e.g. paging and Service Request). For paging
purposes, the mobile is paged with the S-TMSI. The S-TMSI shall be
constructed from the MMEC and the M-TMSI
The UE shall include S-TMSI in the RRC Connection Request message if
(provided by the upper layers) the UE is registered in the TA of the current
cell
<S-TMSI> = <MMEC><M-TMSI>
LTE: RRC Connection Setup
Direction: E-UTRAN => UE
Signalling Radio Bearer: SRB0
RLC Mode: TM
Logical Channel: CCCH
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
Example: RRC CONNECTION SETUP
Posted by Kumara Swamy
LTE: RRC Connection Setup Complete
Direction: UE => E-UTRAN
Signalling Radio Bearer: SRB1
RLC Mode: AM
Logical Channel: DCCH
Transport Channel: UL-SCH
The RRC CONNECTION SETUP COMPLETE message is used to confirm the
successful completion of an RRC connection establishment. Some of the IEs
in this message are explained below:
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 mmec to the
value received from upper layers
dedicatedInfoNAS: This IE includes the initial NAS message from the UE
Example1: RRC CONNECTION SETUP COMPLETE message without
registeredMME IE
Example2: RRC CONNECTION SETUP COMPLETE message with registeredMME
IE included
LTE: RRC Connection Reject
Direction: E-UTRAN => UE
Signalling Radio Bearer: SRB0
RLC Mode: TM
Logical Channel: CCCH
Transport Channel: DL-SCH
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
REQUEST after receiving RRC CONNECTION REJECT, where as in the
case of UMTS, the procedure is repeated for N300 times
Example: RRC CONNECTION REJECT Message
LTE RRC: Security Mode Command
Direction: E-UTRAN => UE
Signalling Radio Bearer: SRB1
RLC Mode: AM
Logical Channel: DCCH
Transport Channel: DL-SCH
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 COMMAND
message 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 the SECURITY
MODE COMMAND.
The UE shall apply integrity protection using the indicated algorithm
(EIA) and the integrity key, KRRCint immediately, 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.
Example: Security Mode Command
More details about the security architecture and different kinds of keys are
explained
LTE RRC: Security Mode Complete
Direction: UE => E-UTRAN
Signalling Radio Bearer: SRB1
RLC Mode: AM
Logical Channel: DCCH
Transport Channel: UL-SCH
The SECURITY MODE COMPLETE message is used to confirm the successful
completion of a SECURITY MODE COMMAND.
The UE shall send SECURITY MODE COMPLETE message integrity protected but
un-ciphered.
i.e., the UE doesn’t start ciphering in the uplink before it has sent the
SECURITY MODE COMPLETE message to the eNodeB
Example: SECURITY MODE COMPLETE
LTE RRC: Security Mode Failure
Direction: UE => E-UTRAN
Signalling Radio Bearer: SRB1
RLC Mode: AM
Logical Channel: DCCH
Transport Channel: UL-SCH
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 the SECURITY MODE COMMAND message, i.e. neither
applies integrity protection nor ciphering
More details about the security architecture and different kinds of keys are
explained here
LTE: RRC Connection Reconfiguration
Direction: E-UTRAN => UE
Signalling Radio Bearer: SRB1
RLC Mode: AM
Logical Channel: DCCH
Transport Channel: DL-SCH
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, RRC CONNECTION RECONFIGURATION
message is the only message for this purpose
E-UTRAN includes the mobilityControlInfo (Handover) only when AS-
security has been activated, and SRB2 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 CONNECTION RECONFIGURATION message, the UE shall continue
using the configuration used prior to the reception of RRC CONNECTION
RECONFIGURATION message. If the security has not been activated, UE
should leave RRC_CONNECTED state, else, UE initiates the connection re-
establishment procedure which is used to resume SRB1 operation and to
reactivate security
Example1: RRC CONNECTION RECONFIGURATION to setup SRB2 and DRB
Example2: RRC CONNECTION RECONFIGURATION - Measurement
Configuration
LTE: RRC Connection Reconfiguration Complete
Direction: UE => E-UTRAN
Signalling Radio Bearer: SRB1
RLC Mode: AM
Logical Channel: DCCH
Transport Channel: UL-SCH
The RRC CONNECTION RECONFIGURATION COMPLETE message is used to
confirm the successful completion of an RRC CONNECTION RECONFIGURATION
Example: RRC CONNECTION RECONFIGURATION COMPLETE
Reference: 3GPP TS 36.331
LTE: 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 doesn’t initiate
this procedure, instead, it moves to RRC_IDLE directly
The UE initiates the RRC CONNECTION RE-ESTABLISHMENT procedure when one
of the following conditions is met:
Upon detecting radio link failure; or
Upon handover failure; or
Upon mobility from E-UTRA failure; or
Upon integrity check failure indication from lower layers; or
Upon an RRC CONNECTION RECONFIGURATION failure
RRC Connection Reestablishment Request Message
Direction: UE => E-UTRAN
Signalling Radio Bearer: SRB0
RLC Mode: TM
Logical Channel: CCCH
Transport Channel: UL-SCH
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 the reestablishmentCause 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
Example: RRC CONNECTION REESTABLISHMENT REQUEST
LTE: RRC Connection Reestablishment
Direction: E-UTRAN => UE
Signalling Radio Bearer: SRB0
RLC Mode: TM
Logical Channel: CCCH
Transport Channel: DL-SCH
The purpose of this procedure is to re-establish the RRC connection, which
involves the resumption of SRB1, 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-establish SRB1. 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
Reference: 3GPP TS 36.331
Example: RRC CONNECTION REESTABLISHMENT
Posted by Kumara Swamy
LTE: RRC Connection Reestablishment Complete
Direction: UE => E-UTRAN
Signalling Radio Bearer: SRB1
RLC Mode: AM
Logical Channel: DCCH
Transport Channel: UL-SCH
The RRC CONNECTION REESTABLISHMENT COMPLETE message is used to confirm
the successful completion of an RRC 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 and
KRRCint respectively.
Example: RRC CONNECTION REESTABLISHMENT COMPLETE message
LTE: RRC Connection Reestablishment Reject
Direction: E-UTRAN => UE
Signalling Radio Bearer: SRB0
RLC Mode: TM
Logical Channel: CCCH
Transport Channel: DL-SCH
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'
Example: RRC CONNECTION REESTABLISHMENT REJECT message
LTE: RRC Connection Release
Direction: E-UTRAN => UE
Signalling Radio Bearer: SRB1
RLC Mode: AM
Logical Channel: DCCH
Transport Channel: DL-SCH
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-fallback to 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 eNodeB sends 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
Reference: 3GPP TS 36.331
Example1: Simple RRC CONNECTION RELEASE message
Example2: RRC CONNECTION RELEASE message IdleModeMobilityControlInfo
