RACH(Contention/Non-Contention) in LTE

There are two types of RAP(RACH(Contention/Non-Contention)):

• Contention based RAP
• Non-contention based RAP

Contention based RAP

In contention based, multiple UE’s attempt to connect to the network at the same time. The eNB is intelligent enough to tackle this situation because every UE should be unique to the network.

The UE’s can always send the same Preamble ID to the network, thereby resulting on collisions. This kind of collision is called “Contention” and is known as “Contention based” RACH Process. The network would go through additional process to resolve these contention and hence this process is called “Contention Resolution” step.

The below mentioned call flow would explain elaborately:

RACH Process

1. In the first message the UE provides an indication to the network about it’s resource requirement. This carries the Preamble ID, RA-RNTI

Query_4: How does UE gets or selects these parameters:

a. Most of the information is passed on to the UE through SIB2 (click here, to know more about SIB2 parameters)

    i. UE MAC layer has to select the Preamble sequence (Group A or Group B)

    ii. UE will configure itself with the max retires it will try for sending RAP (if it doesn’t receive RAR)

   iii. Also, after every retry, how much power level has to be increased for transmitting the RAP

   iv. UE MAC layer constructs the RAP message and passes it to the UE PHY layer. UE PHY layer will transmit this message through PRACH

   v. Once the UE has transmiited the RAP on PRACH, it will start looking for RAR immediately after 3 sub-frames. This number i.e. 3 sub-frame is specified by 3GPP.

Query_5: How long should UE monitor the frames for RAR?

This sub-frame number is again specified in SIB2 and is known as window length; so, after the 3 sub-frames as mentioned above, UE will start looking for RAR in the sub-frames as mentioned by the Window length. If by that time UE doesn’t receive RAR, it will go back to transmit RAP

2. The eNB conveys the resources reserved for this UE along with the Timing Advance (TA), Preamble ID and T-CRNTI (a number generated by eNB and asks the UE to send the RRC connection)

3. UE sends the RRC connection Request using resources given by the eNB. It also sends the identifier (CRI) to the eNB which is used to resolve the Contention.

4. The eNB runs an algorithm and generates C-RNTI which will be a permanent ID for the UE till the connection is alive. The eNB sends the UE identifier. In this step, the UE which has received the ID continues while other UE’s will back off and try again.

Scenario:

Multiple UE’s attempt to access the network:

1. So, the UEs initiates RACH with same Preamble sequence, RA-RNTI

2. Therefore, the UEs will receive the same T-C-RNTI and resource allocation from eNB

3. All UEs would send msg 3 (RRCconnectionRequest)  message through the same resource allocation to the Network

4. Once, when msg3 is transmitted, two Timers are started:

a. T300 : Transmission of RRCconnectionRequest

b. Contention Resolution Timer: broadcasted in SIB2. If the UE doesn’t receive msg4 (Contention Resolution message) within this timer, then it go back to Step 1 i.e. transmitting RAP. If there is a HARQ NACK for msg3 (RRCconnectionRequest) and it has to be re-transmitted then this Contention Resolution Timer will be re-started

Query_6: Now the big question: How should the eNB behave?

1. One: The signals act as interference to each other and eNB decode neither of them. In this case, none of the UE would have any response (HARQ ACK) from eNB and all UE will go back to Step 1.

2. Second: The eNB would successfully decode the message from only one UE and fail to decode from others. The decoded UE will get HARQ ACK from eNB

3. Third: eNB receives msg3 (RRCconnectionRequest) from both the UE’s. Here, eNB will send msg4 (Contention Resolution) with MAC CRI (Contention Resolution Identity) to both the UE’s. This CRI will carry a reflection of the RRCconnectionRequest as generated by one of the UE. The MAC layer of the UE will match the CRI (as received from msg4) with the CRI embedded in the RRCconnectionRequest. If it matches, then the UE will proceed to decode RRCconnectionSetupand the other UE’s will back off and return to Step1, i.e start the RA procedure again.

Contention Resolution process is again of two types:

1. MAC based Contention Resolution
=> C-RNTI on PDCCH 
=> uses the DCCH logical channel 
=> used in HO scenarios
==>The rule is: if the UE has a valid C-RNTI and is going for RA procedure then it will be a MAC based Contention Resolution procedure

2. L1 based Contention Resolution
=> CRI (Contention Resolution Identity) on DL-SCH based 
=> Contention Resolution is addressed to T-CRNTI
=> uses CCCH logical channel
==>The rule is: if the UE doesn’t has a valid C-RNTI and is going for RA procedure then it will be L1 based Contention Resolution procedure

Non-contention based RAP

This procedure is always initiated from network in case of a handover. For this procedure, the eNB reserves a set of preamble sequence. When this type of scenario is encountered the eNB allocates the set from this reserved pool.This entire procedure is controlled by the eNB. Hence. no question of collision.
The call flow is mentioned below:

 Non Contention Based RAP