2018 03 27 RRC - krishnaramb/cplusplus GitHub Wiki

• RRC Idle
• RRC Connected
• Acquisition of an SI message
• Connection Control

• RRC connection establishment is used to make the transition from RRC Idle to connected mode.
• UE must make the transition to RRC Connected mode before transferring any application data, or completing any signalling procedure
• RRC connection establishment procedure is always initiated by UE but triggered by UE or network
• UE triggers the rrc connection establishment procedure if the end user starts any application data or UE moves into a new tracking area and has to complete the Tracking area update procedure
• Note that the initial Non-Access Stratum(NAS) message is transfered as part of the RRC connection establishment procedure.

• The RRC connection request is sent as part of the Random Access Porcedure. It is transfered using SRB0 on the common control channel (CCCH) because neither SRB1 nor a Dedicated Control channel (DCCH) have been setup at this point.
• The content of RRC connection request is as shown below:

Q. How the UE identity is signalled during the rrc connection setup procedure? 💥

The UE identity is signalled using SAE temporary mobile subscriber indentity (S-TMSI) if it is registerd with the tracking area to which the currnet cell belongs, otherwise a UE selects a random number from range 0 to $2^{40}-1$

❗The establishment cause within the RRC connection request is determined by the NAS procedure for which the connection is being established.:punch:

👀 The UE starts the T300 timer after transmissting the RRC connection request msg. The value of T300 is boradcasted in the SIB2. Note that 👋 unlike UMTS lte doesn't have N300 timer to manage retransmission of the RRC connection request message. So RRC layaer sneds the RRC Connection Request message only once per establishment procedure.

• HARQ retransmission from the MAC layer can be used to improve the reliablity of tranferring the RRC Connection Request and RRC Connection Setup Mesages. 👊

Q. what happens if random access contention doesn't occur during RRC connection setup request? 💥

UE proceeds to wait for the RRC connection setup msg from the network. The UE has successfully completed the random access procedure so has been allocated a C-RNTI (signalled witin random access response msg). Now UE monitors the PDCCH for a downlink allocation addressed to its C-RNTI. The PDCCH specifies the set of PDSCH resource blocks used to transfer the RRC connection setup msssage. The RRC connection setup message is transferred using SRB0 on the CCCH.

Q. Describe how and when SRB1 is configured? When would SRB2 be configured? ❓

The RRC Connection Setup message contains configuration information for SRB 1. This allows subsequent signalling to use the DCCH logical channel. SRB 2 is always configured after security activation so the RRC Connection Setup message does not include any information regarding SRB 2👊. The eNode B can instruct the UE to apply a default configuration for SRB 1, or it can instruct the UE to apply a specific configuration. SRB2 has lower-priority than SRB1. i.e. a value of 3 represents lower-priority than a value of 1. Note that both SRB1 and SRB2 always use acknowledged mode RLC. 👍

Q. what does the RRC connection setup msg define?:boom:

Apart from the information required for seting up SRB1, it also defines configuration information for the PDSCH, PUCCH, and PUSCH physical channels. It also includes the information for uplink power control, CQI reporting, the sounding reference signal, antenna configuration and scheduling request.

After receiving an RRC Connection Setup msg, the UE stops the T300 timer and makes the transition to RRC Connected state. The content of RRC connection setup complete is as shown. .

• The Transaction Identifier, combined with the message type, identifies the RRC procedure with the UE
• The Selected PLMN Identity defines a pointer to a PLMN listed within SIB1, i.e. UE select the PLMN to which they want to connect when a cell belongs to more than a single PLMN
• The Registered MME information is optional, and is included when available. It becomes available after a UE has registered with an MME. The MME is identified by its Globally Unique MME Identity (GUMMEI) which is a concatenation of the PLMN identity, MME Group Identity (MMEGI) and MME Code (MMEC). The MMEC identifies the MME within its group
• The UE also includes its initial Non-Access Stratum (NAS) message within the RRC Connection Setup Complete message. NAS messages are specified within 3GPP TS 24.301. As indicated within Table 284, the NAS message could be an Attach, Detach, Tracking Area Update, Service Request or Extended Service Request message
• The Globally Unique MME Identity (GUMMEI) Type information was added within the release 10 version of the specifications. This can be signalled using values of ‘native’ or ‘mapped’. The ‘native’ value indicates that the GUMMEI has been assigned by the Evolved Packet Core (EPC), whereas the ‘mapped’ value indicates that the GUMMEI has been derived from 2G/3G identifiers. This information can impact the selection of an MME for the UE
• The eNode B extracts the NAS message from the RRC Connection Setup Complete message and forwards it to an MME using the S1 Application Protocol (S1-AP) Initial UE Message. Forwarding this message does not form part of the RRC establishment procedure but is described within this section for completeness

"Signalling Radio Bearers" (SRBs) are defined as Radio Bearers (RB) that are used only for the transmission of RRC and NAS messages. There are three types of SRBs defined.

• SRB0 is for RRC messages using the CCCH logical channel;
• SRB1 is for RRC messages (which may include a piggybacked NAS message) as well as for NAS messages prior to the establishment of SRB2, all using DCCH logical channel;
• SRB2 is for RRC messages which include logged measurement information as well as for NAS messages, all using DCCH logical channel. SRB2 has a lower-priority than SRB1 and is always configured by E-UTRAN after security activation.

In downlink piggybacking of NAS messages is used only for one dependant (i.e. with joint success/ failure) procedure: bearer establishment/ modification/ release.

In uplink NAS message piggybacking is used only for transferring the initial NAS message during connection setup.

NOTE: The NAS messages transferred via SRB2 are also contained in RRC messages, which however do not include any RRC protocol control information.

Imp note:

• Once security is activated, all RRC messages on SRB1 and SRB2, including those containing NAS or non-3GPP messages, are integrity protected and ciphered by PDCP. NAS independently applies integrity protection and ciphering to the NAS messages.

The RRC protocol offers the following services to upper layers:

• Broadcast of common control information;
• Notification of UEs in RRC_IDLE, e.g. about a terminating call, for ETWS, for CMAS;
• Transfer of dedicated control information, i.e. information for one specific UE.

Following are the main services that RRC expects from lower layers

• PDCP: integrity protection and ciphering
• RLC: reliable and in-sequence transfer of information, without introducing duplicates and with support for segmentation and concatenation.

Further details about the services provided by Packet Data Convergence Protocol layer (e.g. integrity and ciphering) are provided in TS 36.323 [8]. The services provided by Radio Link Control layer (e.g. the RLC modes) are specified in TS 36.322 [7]. Further details about the services provided by Medium Access Control layer (e.g. the logical channels) are provided in TS 36.321 [6]. The services provided by physical layer (e.g. the transport channels) are specified in TS 36.302 [3].

The RRC protocol includes the following main functions:

• Broadcast of system information:
  • Including NAS common information;
  • Information applicable for UEs in RRC_IDLE, e.g. cell (re-)selection parameters, neighbouring cell information and information (also) applicable for UEs in RRC_CONNECTED, e.g. common channel configuration information.
  • Including ETWS notification, CMAS notification;
• RRC connection control:
  • Paging;
  • Establishment/ modification/ release of RRC connection, including e.g. assignment/ modification of UE identity (C-RNTI), establishment/ modification/ release of SRB1 and SRB2, access class barring;
  • Radio configuration control including e.g. assignment/ modification of ARQ configuration, HARQ configuration, DRX configuration;
  • In case of CA, cell management including e.g. change of PCell, addition/ modification/ release of SCell(s) and addition/modification/release of STAG(s);
  • QoS control including assignment/ modification of semi-persistent scheduling (SPS) configuration information for DL and UL, assignment/ modification of parameters for UL rate control in the UE, i.e. allocation of a priority and a prioritised bit rate (PBR) for each RB;

NOTE: Random access is specified entirely in the MAC including initial transmission power estimation. 👏

When acquiring an SI message, the UE shall:

1. determine the start of the SI-window for the concerned SI message as follows:
2. for the concerned SI message, determine the number n which corresponds to the order of entry in the list of SI messages configured by schedulingInfoList in SystemInformationBlockType1;
3. determine the integer value x = (n – 1)*w, where w is the si-WindowLength;
4. the SI-window starts at the subframe #a, where a = x mod 10, in the radio frame for which SFN mod T = FLOOR(x/10), where T is the si-Periodicity of the concerned SI message;

• The motivation of RRC connection establishment is to establish the SRB1 and allows subsequent signaling to use the Dedicated Control Channel (DCCH) rather than the common control channel (CCCH) used by SRB0. Note that after "RRC Connection Setup Complete", SRB1 would be established, and all the RRC procedures before it, like rrc connection request, setup; all these happens in SRB0