Hi Experts,
How gNB intialize/select RACH common config parameters?
Admin note: this post was updated with image below.
For SA deployment, random access parameters are broadcasted on SIB1 while the device is in Idle Mode. For connected mode, the UE shall receive through RRC Reconfiguration
However, for NSA deployment such parameters are sent trough RRC reconfiguration on LTE side.
The UE must follow strict rules to apply RA parameters (defined at 38.321 and 38.211). You might also find some clarification:
https://www.sharetechnote.com/html/5G/5G_RACH.html
And:
RACH is the first uplink message which is sent by the UE to the Network for uplink synchronization via the PRACH channel and RACH is handled by the MAC Layer.
In LTE and NR there is a basic difference in the RACH procedure LTE there was no concept of the beam but, In NR SSB (Synchronization Signal / Physical Broadcast Channel (SS/PBCH) Blocks) is associated with the different beams.
Uplink synchronization in a 5G NR cell is crucial for ensuring efficient communication between the user equipment (UE) and the gNB (5G base station). It helps maintain the proper timing and frequency alignment between the UE and the gNB, allowing for accurate data transmission and reception
Initial Access 
When a UE first connects to a 5G NR cell, it must synchronize with the gNB’s downlink signal to acquire the necessary information for establishing uplink synchronization. The UE does this by decoding the Primary Synchronization Signal (PSS) 
, Secondary Synchronization Signal (SSS) 
, and the broadcast channel (BCH) 
, which contains essential system information.
Random Access Procedure 
Once the UE has obtained the necessary downlink information, it initiates the uplink synchronization process by performing a Random Access Procedure (RAP). The UE transmits a Random Access Preamble (RAP) 
on the Physical Random Access Channel (PRACH) to notify the gNB of its intention to establish an uplink connection.
Random Access Response 
Upon receiving the RAP, the gNB sends a Random Access Response (RAR) 
back to the UE on the Physical Downlink Shared Channel (PDSCH). The RAR contains crucial timing and frequency corrections 
, as well as an initial uplink grant, allowing the UE to adjust its transmission and align with the gNB’s timing and frequency.
Uplink Transmission 
After applying the corrections and receiving the uplink grant, the UE begins its uplink transmission on the Physical Uplink Shared Channel (PUSCH) 
. This transmission is now synchronized with the gNB’s timing and frequency, ensuring accurate and efficient data transfer.
Continuous Synchronization 
Once the uplink synchronization is established, the UE and the gNB maintain this synchronization throughout the connection. The gNB continuously monitors the UE’s uplink transmission and provides necessary timing and frequency adjustments to maintain accurate and efficient communication .
In summary, uplink synchronization in a 5G NR cell is vital for maintaining accurate and efficient communication between the UE and the gNB. It starts with the UE acquiring downlink information, followed by the Random Access Procedure, the gNB’s response, and the UE’s uplink transmission. The synchronization is continuously maintained, ensuring seamless and efficient data transfer in the 5G NR network. 
LinkedIn: 
1 Like
Hello Experts.
I had a query about RACH process.
Now, when we get the contention resolution MSG4 from gNB…
What are the parameters the gNB is verifying to pass the contention resolutions to assign a C-RNTI for a specific UE?
Is it just based on TC-RNTI verification which was assigned by gNB to UE in MSG2 or additional parameters are checked?
2 Likes
In Msg3, UE sends a 48-bit, long random number uniquely generated.
It is an MAC parameter.
When gNB receives msg3, it can decode only single msg3 at max.
So if multiple UEs are sending msg3, then max 1 UE data will pass the CRC at gNB or may not even be even 1.
Now, at this point, gNB won’t get to know which UE sent msg3.
So it will reply back with msg4 carrying the same 48 bits that it decoded.
All the UEs that sent msg3 will receive this msg and try to match the received 48 bits with its locally generated 48 bits that it transmitted in msg3.
Now, since it is a unique number randomly generated only for single UE, it will match.
So, except the UE for which it matches, will continue with the RRC connection, and the rest of the UEs will drop.
These 48 bits are called contention resolution identity.
Probability that 2 UEs will generate the same 48 bit random number is = 1/(2^48) < 10^(-15)
Highly highly unlikely
1 Like
Just add on little bit more on this
- Above situation only occurs when more than one UE select same preamble for contention based RACH procedure (msg1).
- If transmitted preamble is same, then received msg2 content (RAPID, UL resources for msg3) would also be same for those UEs.
- Hence all the UEs that selected same preamble in msg1, would transmit msg3 at the same time frequency resources, but with different content (48 bit unique MAC identity)
- However, gNB would decode only one msg3 from one UE.
And rest of the procedure is same as explained above.
1 Like
Are you sure? UE is sending 48bits of random value in RRCSetupRequest message.
Will you please share any log print here?
I have always observed 39bits.
and for UE contention resolution- UE check if CCCH SDU(RRCSetupRequest) of 6 Bytes should be match with MAC supPDU(msg4) of UE Contention resolution identity of 6 Bytes.
