5G RRC Messages - RRCSetupRequest

Th RRCSetupRequest message is used to request the establishment of an RRC connection.

  • Signaling radio bearer : SRB0
  • RLC-SAP : TM
  • Direction : UE to Network
  • Channel mapping : CCCH → UL-SCH → PUSCH
  • The RRCSetupRequest is sent as a MSG3 during the contention based Random Access procedure. The Resource Block allocation for the RRCSetupRequest is provided within the Random Access Response message (MSG2)
  • The contents of RRCSetupRequest includes a UE identity and an establishment cause
  • ue-Identity occupies the payload of 39bits. UE identity can be either r andom value (39bits) or part of 5G-S-TMSI (39 bits). The total length of 5G-S-TMSI is 48 bits; out of 48bits, 39 bits are sent in this message and the remaining 8 bits will be sent in RRCSetupComplete (MSG5). The complete 5G-S-TMSI is not included within the RRCSetupRequest because it would make the message size too large
  • If the UE has already registered with the 5G Core Network using a previous RRC Connection, and the AMF has already allocated a 5G-S-TMSI then the UE identity within the RRCSetupRequest can be signaled using the 39 least significant bits from the 5G-S-TMSI. The set of 39 bits are sufficient to minimize the probability of multiple UE using the same UE identity. If 5G-S-TMSI is not available, the UE populates the ue-Identity field with a random number within the range 0 to (2^39) - 1
  • establishmentCause occupies the payload of 4bits. There are 10 cause values (refer the figure) which can be encoded using 4 bits
  • The content of the RRCSetupRequest bas been carefully specified to limit the (RRC) message size to 48 bits. In general, it is important for MSG3 to be small because it cannot be segmented, i.e. it is transferred using Transparent Mode RLC which docs not support segmentation
  • The ue-Identity (39bits) and establishmentCause (4bits) generates a total of 43 bits. In addition, it is necessary to include 1 bit to signal the choice between the two types of UE identity. Similarly, it is necessary to include 2 bits to signal the choice between four potential CCCH messages : {RRCSetupRequest, RRCResumeRequest, RRCReestablishmentRequest, RRCSystemlnfoRequest}. Finally, 1 bit is included to signal the choice between the existing set of four CCCH messages and a message extension which can be used to introduce new messages in the future. So, the RRC layer contributes the payload of 48 bits for this message (MSG3)
  • The UE adds an 8 bit MAC header to the RRCSetupRequest so the total message size is 48 + 8 = 56 bits. It should be noted that this corresponds to the smallest value that can be configured for ra-Msg3SizeGroupA. This means that the UE always selects a ‘Group A’ PRACH preamble when sending an RRCSetupRequest (this statement is applicable when the Base Station configures ‘Group A’ and ‘Group B’ PRACH preambles, otherwise the message size does not impact the preamble selection procedure)
  • The UE starts the T300 timer after transmitting the RRCSetupRequest. The value of T300 is broadcast within SIB-1. The RRC Connection Setup procedure fails if T300 expires before the UE receives the RRCSetup message (MSG4).
  • The RRC layer docs not support retransmissions of MSG3 within a specific connection setup attempt. However, HARQ re-transmissions of MSG3 can be triggered at the MAC layer while T300 is running. The Base Station triggers HARQ re-transmissions of MSG3 using DCI Format 0_0 to provide a new uplink resource allocation on the PUSCH. The CRC bits belonging to the DCI arc scrambled using the Temporary C-RNTI. The Contention Resolution timer is re-started after a HARQ re-transmission of MSG3, but T300 is not re-started