RACH Failure can happen due to Multiple issues and there might be multiple reasons, I have listed down a list of RACH Failure reasons that can happen in 5G-NR.

RACH process is a PHY/MAC Level procedure, but the RACH Configuration is provided by the upper layers i.e. RRC Layer.

RACH Failure Reasons in 5G NR

The Random Access Channel (RACH) procedure is the "first handshake" between the User Equipment (UE) and the gNB. In 5G NR, where beamforming and high frequencies (mmWave) come into play, the RACH process is more complex than its predecessor in LTE. A failure here means the UE remains "blind" to the network, unable to establish a connection, perform a handover, or recover from a radio link failure.

Understanding why RACH fails is critical for RF optimization and network troubleshooting. In this post, we’ll break down the common reasons for RACH failures in 5G NR across the different stages of the procedure.

1. Incorrect PrachConfigCommon

The UE can receive incorrect PRACH Configuration common from upper layers i.e through dedicated message during handover or through dedicated message for NSA addition or from SIB1 during initial acquisition. Whenever UE receives any message it checks the ASN for the message and validates it before passing on that information to lower layers.

In the case of RACH Configuration, the RRC Checks the Configuration and validates it before sending that configuration to PHY/MAC Layer.

The most common issue seen is incorrect SSBperRACHocassion mapping.

Sample NR RACH Configuration

     rach-ConfigCommon setup :
                     rach-ConfigGeneric
                     prach-ConfigurationIndex 75,
                     msg1-FDM one,
                     msg1-FrequencyStart 0,
                     zeroCorrelationZoneConfig 0,
                     preambleReceivedTargetPower -109,
                     preambleTransMax n10,
                     powerRampingStep dB4,
                     ra-ResponseWindow sl20
                         ,
                     totalNumberOfRA-Preambles 8,
                     ssb-perRACH-OccasionAndCB-PreamblesPerSSB one : n8,
                     ra-ContentionResolutionTimer sf16,
                     prach-RootSequenceIndex l139 : 71,
                     msg1-SubcarrierSpacing kHz120,
                     restrictedSetConfig unrestrictedSet

2. Preamble Transmission Failures (Msg1)

The first step involves the UE sending a preamble. If the gNB doesn't "hear" this preamble, the process stops before it even begins.

• Poor Uplink Coverage: The UE might be able to decode the SSB (Downlink), but its transmission power isn't enough to reach the gNB. This is a common issue in cell edge scenarios.
• High Interference (PUI): High Uplink interference on the PRACH resources can mask the UE's preamble, making it impossible for the gNB to detect it.
• Incorrect PRACH Configuration: If the prach-ConfigurationIndex or msg1-FrequencyStart parameters in SIB1 don't match the actual network deployment, the UE will transmit on the wrong resources.
• RSI (Root Sequence Index) Conflict: If neighboring cells use the same or highly correlated Root Sequence Indices, the gNB might experience preamble collisions or false detections, leading to failure.

3. Random Access Response (RAR) Failures (Msg2)

Once the gNB detects a preamble, it sends a RAR. If the UE fails to receive Msg2, it will continue to retransmit Msg1 until preambleTransMax is reached.

• Msg2 Reception Failure: The UE will declare msg2 reception failure if it did not detect msg2 with RA-RNT before the RAR timer expires
• PDCCH/PDSCH Blocking: In heavily loaded cells, the gNB might not have enough CCEs (Control Channel Elements) to schedule the RAR on the PDCCH, or enough physical resources for the PDSCH.
• Beam Misalignment: In 5G, the RAR is typically sent using the same beam as the detected SSB. If the UE has moved or the channel has changed rapidly, the beam used for Msg2 might not provide enough coverage.
• ra-ResponseWindow Expiry: If the ra-ResponseWindow is configured too short, the UE might stop listening for the RAR before the gNB has a chance to schedule it.
• Back-off Indication: If the Cell/beam is congested the gNB might send msg2 to UE with a Back-off indication, asking the UE to not trigger RACH for a certain duration.

4. RAPID Mismatch in msg2

• RAPID mismatch: If there is a RAPID mismatch, then the gNB will indicate that in the msg2, the then UE discards msg2 and triggers RACH again.
• Back-off Indication: If there is RAPID Mismatch then gNB can also indicate Back Off timer value.
• BO (Back off) range is from [0-15]
• As indicated above, If there is congestion at gNB then gNB can send RAPID mismatch with BO value, so Backs off from sending RACH again for the configured BO Value duration.
• Back off indication can only be sent when there is a RAPID mismatch and BO value is configured in msg2. If either of the two is missing UE does not apply Back off timer.

5. Contention Resolution Failures (Msg3 & Msg4)

In Contention-Based Random Access (CBRA), multiple UEs might pick the same preamble at the same time.

• Msg3 Decoding Failure: The gNB might receive the preamble but fail to decode Msg3 (RRC Setup Request) due to poor PUSCH SINR or interference.
• Msg4 Timer Expiry (ra-ContentionResolutionTimer): After sending Msg3, the UE starts this timer. If it doesn't receive Msg4 (Contention Resolution) before the timer expires, it assumes a collision occurred and restarts the process.
• Max Number of Retransmissions: If the UE repeatedly fails the contention resolution, it will eventually abort the RACH procedure and report a MAC-level failure.

6. Parameter Misconfigurations

Sometimes the failure isn't physical, but logical.

• Preamble Power Ramping: If powerRampingStep is too low, the UE doesn't increase its power quickly enough to overcome temporary fading.
• SSB-to-PRACH Mapping: In 5G, preambles are mapped to specific SSB beams. If the ssb-perRACH-Occasion is misconfigured, the UE may select an inappropriate PRACH occasion for its best beam.