LTE :when ongoing RACH will be aborted ?

Question

At handover time target ENB will give rach preamble to UE. Is it necessary that target ENB is to be sink with source ENB. How UE will do contention free rach when both or not in sink? Is their any case Contention free rach will fail?

Answer 1

Monitor Downlink
As discussed in the first answer, the UE then monitors the downlink for the Random Access (RA) - RNTI which can be calculated from the subframe and frequency resources (TDD Only) used to transmit the RACH preamble. The message returned from the eNB is called the Random Access Response (RAR). It must appear within a certain window that starts 3 subframes after the RACH transmissions and lasts for a number of subframes given by the ra-ResponseWindowSize. If this message is not seen at all by the UE it's indicative of insufficient transmit power and the diagram redirects us back to the Transmit Preamble box. Note the incrementing and checking of the preamble counter.

Contention Resolution
Probably not the best name for this box but ... Assuming the UE finds the RAR a couple of things could happen. One is that Random Access Preamble ID (RAPID) transmitted by the UE may not be identified by eNB in the RAR message. In this case, the eNB is responding to other UE that transmitted in the same RACH opportunity. In this case, it is again an indication of insufficient transmit power, and the diagram returns us to the Transmit Preamble box via a counter increment and check.

Another possible condition is that the UE finds it's RAPID in the RAR but fails the contention resolution process described in the first answer. In this case, the problem could have been congestion, or it could have been insufficient transmit power.

Note that I have smashed a couple of messages into a single box. Contention resolution actually involves 3 messages, the RAR, the RRC_Connection_Request, and the RRC_Connection_Setup. The UE will not will not wait forever for the completion of the calling ladder, via reception of the "setup" message and as such 2 timers are started after transmission of the "request" message, the Contention Resolution Timer and Timer T300.. The max value for the contention resolution timer is 64 subframes. The UE will not RACH while this timer is active.

Timer T300, has a much longer time scale, the minimum value of T300, (100ms) is longer than the maximum value of the contention resolution timer. Upon expiry of the contention resolution timer, the UE is allowed to transmit RACH preambles again, incrementing the counter. Upon expiry of T300, the UE abandons this "fork" of the process. (This seems another answer to "How does the UE know to abort the ongoing RACH process ... Although it's never 'done" here).

Bottom LIne
So the RACH process can be terminated successfully by successful reception of the RRC_Connection_Setup message.

On the "Unsuccessful" side, when the Max Preamble counter is exceeded, the higher layers are notified. What they decide to do is also another story.

I hope this helps and was actually the question you were asking!!!

Answer 2

Following is the RACH procedure

In case of collision RACH needs to be stopped or aborted which can happen in the following cases

1. two UEs send same RACH preamble at same time in step 1
2. Same Temp C-RNTI and up-link grant will be received by two UEs in step 2
3. In step 3 eNodeB does not receive Msg3 from due to interference.
4. In step 2/4 the UE does not receive Msg2/Msg4 from eNodeB will back-off after expiration of RACH specific timers.

Answer 3

This is my interpretation of the UE's view of the RACH procedure. One way to interpret the OP's question is: Given the UE has transmitted it's RACH Preamble, initiating the procedure, how does it (the UE) know when to stop. As opposed to the very nice "success oriented" view above this diagram walks through what happens when things fail. It may take more than 1 "window" worth of explantation, so I'll start by posting this picture and add some explanations as subsequent responses.

Answer 4

I should start by saying that the figure above comes from descriptions provided in 36.321 (the MAC Layer spec) and also contains the relevant parametrization from 36.331, the RRC specification, more specifically the Network configuration options from the SIBs that are employed in the algorithms described in the MAC.

Moving from top to bottom in the diagram:

Initialization
Having determined the need to transmit a RACH preamble, the UE, the UE will have been configured via SIB signalling the desired power that this signal should be received at the eNB. This is the preambleInitialReceivedTargetPower parameter pointed to in the diagram. The method by which the UE determines the actual transmit power from this parameter is outside the scope of this discussion. Let's just say that the UE may not transmit sufficient power to be received properly at the eNB.

Most importantly, here the UE initializes a counter called the Preamble_Transmission_Counter, which upon reaching a maximum count notifies the higher layers. (Expiry of this counter is one way the UE knows when to abort an "ongoing RACH procedure".)

Transmit Preamble
Moving down to the next box, the UE selects a preamble. There are rules associated with this, for example there could be preambles allocated for contention-based or contention-free access, and contention-free access can further divide the set of 64 preambles into Groups A and B, but those details are also beyond the scope of this discussion.

As there are several reasons that the process could fail overall, I note that the placement of this box is meant to indicate that a new preamble ID is drawn in the event that the UE needs to send another one.

The parenthetical items in this box are not used the first time through, but rather conditionally executed in subsequent iterations. For example the power would be incremented if the appropriate RA-RNTI is not found within the ra-ResponseWindowTime specified by the arrow. The power ramping step size is parametrized as pointed to in the diagram. (Units are in dB).

Another reason for RACH failure could be simple congestion of the RACH process, meaning too many UE are trying to RACH at the same time. Parenthetically shown is application of a random wait time which is calculated below. In the event of congestion, application of random wait times to multiple UE is intended to multiple UE is intended to better temporally space RACH transmissions.