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.
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
Preamble Max Transmissions
gNB configures the max number of preambles the UE can transmit during the RACH process, if UE does not receive msg2 for the RACH preamble sent out, it waits for the random access response timer to expire and triggers RACH again. After ‘n’ number of tries if there is no response UE might declare rach failure or start the RACH process gain.
- Msg1 Collision in high density cells
- Msg1 detection failure due to low SNR at gNB
- UE transmitting RACH at lower power
Msg2 Reception failure
- The UE will declare msg2 reception failure if it did not detect msg2 with RA-RNT before the RAR timer expires.
- Another reason could be gNB did not detect the PRACH and did not transmit msg2, Since there is no ACK from gNB for msg1 , so UE does not know if msg1 was received successfully or not and Only msg2 reception indicates that gNB has received the PRACH preamble and sent a response.
- There might be instances where when the cell/beam is congested and gNB might not have resources to allocate PDCCH for msg2 PDSCH which might cause PDCCH blocking. This will result in gNB unable to allocate msg2 resources within the RA Response window.
- 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.
RAPID Mismatch in msg2
- If there is a RAPID mismatch, then the gNB will indicate that in the msg2, the then UE discards msg2 and triggers RACH again.
- If there is RAPID Mismatch then gNB can also indicate Back Off timer value.
- BO range is from [0-15]
- As indictated 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.
Msg3/Msg4 Failure
- Msg3 detection failure at gNB, there can be a scenario where UE is sending PUSCH at a lower power causing pusch detection failure at gNB.
- Conention resolution Failure, if UE did not receive msg4 before the contention resolution timer expires then it will declare RACH failure.
Further Reading: