Preamble Collision Handling in eNodeB

RAN
,
1

Hi experts, I have some queries regarding preambles.

As we know, an eNodeB has 64 preambles available. In MSG-1 (Random Access Request), multiple UEs may send requests to the eNodeB. If a group of UEs happens to use the same preamble signature, how does the eNodeB determine which UE to grant the RAR (Random Access Response) to?

2

The gNB will issue a single RAR for both UEs that used the same preamble, assigning them the same RAPID, same TC-RNTI, and same TA. However, since the UEs are at different locations, the TA value will be correct for only one of them.

As a result:

  • One UE will send the RRC Request with the correct TA, while the other will use an incorrect TA.
  • There are multiple possible outcomes:
    1. Neither RRC Request reaches the gNB.
    2. Both RRC Requests reach the gNB.
    3. Only one RRC Request is successfully received.

Based on these scenarios, contention resolution will take place.

3

RAR is not sent to specific UEs. Rather, RAR is sent to specific preambles that are recieved by eNodeB

4

In the given scenario, two UEs transmit the same preamble & both receive a single RAR message containing identical parameters (RAPID, TC-RNTI, TA, PUSCH resources, TPC, and MCS). Since only the eNB is aware of the intended recipient, both UEs assume the RAR belongs to them.

As a result, both UEs transmit an RRC Connection Request, each using a random number as a UE identity along with an establishment cause. The eNB then responds with an RRC Connection Setup message, which includes the contention resolution identity ( it includes the actual ue identity in it) corresponding to the actual UE that initially transmitted the preamble.

Upon receiving the RRC Connection Setup, the correct UE (which has correct ue identity)successfully decodes the message and responds with an RRC Connection Setup Complete, finalizing the connection. However, the other UE, due to a UE identity mismatch, fails to decode the message. Consequently, it restarts the random access procedure by re-initiating preamble transmission to establish uplink synchronization again.

5

From the start of MSG-1 to MSG-4 (RRC Connection Setup), the network cannot distinguish between different UEs facing the same issue. Am I correct?

Also, is this related to the concept of false preamble detection?

6

Here are a few more scenarios:

  • If both UEs send an RRC Connection Request using the same PUSCH resource to the eNB, there is a possibility of collision or interference in the time and frequency domain at the eNB level. This can result in one of the UEs being discarded during MSG3 transmission due to the collision. The discarded UE will then retry the RACH procedure.

  • In another scenario, suppose two UEs—one near the cell and one at the cell edge—successfully decode the RAR message and proceed to send MSG3 using PUSCH resources. The UE with the correct Timing Advance (TA) provided by the network may successfully transmit its RRC Connection Request. However, the other UE, due to differences in timing, distance, and network conditions, may not be successfully decoded by the eNB. Consequently, this UE will have to reattempt the RACH preamble transmission.

7

Silambarasan, A question on the scenario 1 you mentioned, where if both UEs are near the cell, wouldn’t both MSG3 get corrupted during reception? Can’t understand how one survives and other not.