Random Access Procedure

Purpose:

1. To get uplink synchronization

2. To get radio resources in uplink direction to send L2/L3 messages.

UE gets all the random access related parameters of the cell by reading SIB-2.

UE triggers Random Access Procedure (RAP) by sending RACH preamble to the eNodeB on PRACH
(Physical Random Access Channel).

There are 64 preamble sequences available for an E-Cell and UE generates these 64 preambles for the
cell it wants to register.

However, all these 64 preamble sequences are not available for the UE. Few preamble sequences are
reserved by the eNodeB for non-contention based random access.

SIB-2 parameter numberofRaPreambles denotes the total number of preambles available to the UE to
choose from.

Therefore, number of RACH preambles reserved by the eNodeB for non-contention based RAP
= 64 – numberofRaPreambles

Preambles available to the UE are divided into two groups – Group A and Group B.

Parameter sizeOfRaPreamblesGroupA denotes the number of preambles available within Group A.

Hence, number of preambles in Group B = numberofRaPreambles – sizeOfRaPreamblesGroupA

UE needs to decide the group from which it will choose the preamble – Group A or Group B. Group is
decided on the basis of the size of the L2 or L3 message to be sent to eNodeB.

For example, at the time of registration, L3 message RRC Connection Request is sent to the eNodeB. If
the length of this message is greater than the SIB-2 parameter messageSizeGroupA, preamble will be
selected from Group B, else preamble will be selected from Group A.

From the selected group, UE randomly chooses a preamble.

Transmission of Random Access Preambles on the PRACH

In the frequency domain, a PRACH transmission has a bandwidth of 6 resource blocks. In the time
domain, the transmission is usually one subframe long, but it can be longer or shorter.

The PRACH transmission comprises of a cyclic prefix, a preamble sequence and a guard period. In turn,
the preamble sequence contains one or two PRACH symbols, which are usually 800 µs long. The UE
transmits the PRACH without any timing advance, but the guard period prevents it from colliding at the
eNodeB with the symbols that follow.

The above figure shows a resource element mapping for the PRACH using FDD mode, a normal cyclic
prefix, a 3MHz bandwidth, a PRACH configuration index of 5 and a PRACH frequency offset of 7.

Total 6 resource blocks are used by the UE to send RACH preamble. SIB-2 parameter prach-FreqOffset
tells the mapping of these resource blocks in the resource grid. For example, if the value of prach-
FreqOffset is 6, UE can use 6 resource blocks starting from resource block 7 for RACH request.

SIB-2 parameters used of deriving preamble sequences:

1. rootSequenceIndex
2. Highspeedflag
3. zeroCorrelationZoneConfig

Random Access Preamble formats:

Power requirement for RACH request transmission:

SIB-2 parameter preambleInitialReceivedtargetPower indicates the power to be used for first

transmission of RACH request. Its value varies from -120dBm to -90dBm.

SIB-2 parameter powerRampingStep is mainly used when eNodeB is not able to detect the RACH
request. In case of any failure, UE will retransmit the RACH request by increasing the power to
powerRampingStep factor.

SIB-2 parameter preambleTransMax decides how many times UE should transmit RACH preamble in
case of continuous failures. It is important to have this parameter, else the UE may drain all its battery if
there are constant RACH failures.

UE does not send any identifier while sending RACH preamble. eNB calculates UE identifier called RA-
RNTI by the timing of preamble transmission. If 2 different UEs transmit preamble at the same time,
eNodeB will derive the same RA-RNTI for both UEs.

Procedures after receiving Random Access request at the eNodeB

After receiving Random Access request, the eNodeB:

1. derives RA-RNTI from the time slot number in which the preamble is received.
2. calculates TC-RNTI (Temporary Cell – Radio Network Temporary Identity) for this UE. It is used
for further communication between the UE and the eNodeB.
3. calculates timing advance value which is transmitted to the UE as a part of Random Access
Response (RAR) message.
4. determines the information that will be used by the UE for sending L2/L3 message. These
information include:
a. resource blocks to be used for uplink transmission
b. modulation and coding scheme
c. hopping flag
d. power to be used by UE for PUSCH
e. UL delay
f. CSI field

eNodeB includes all these information in the RAR message and sends it to the UE on the DL-SCH.

If RACH preamble is sent at time X, UE should expect RAR to be received within the time gap of duration
Y, where the value of Y lies between

X+3 <= Y <= X + RA response window

where RA response window is determined by SIB-2 parameter ra-ResponseWindowSize.

Procedures after receiving RAR

After receiving RAR, the UE:

1. Saves TC-RNTI from RAR

2. Applies the received timing correction so that UE is synchronized in the uplink direction and can
transmit data to the eNodeB.
3. Uses uplink resource information present in RAR to transmit L2/L3 message to the eNodeB (e.g.
RRC Connection Request).

UE does not have a permanent identity. So it picks a random number as the UE identity. UE includes this
random number in the RRC Connection Request message.

Identities such as IMSI cannot be used at this stage as so security is configured till this point.

Types of RAP:
1. Contention based
2. Non-contention based

Contention based RAP

Preamble sequences are orthogonal to each other, so eNodeB can easily decode preamble sequences
from multiple UEs at the same time, provided each UE is using different preamble sequence.

But preamble sequences are selected by UEs in random order. So, it is possible that 2 UEs may choose
the same preamble sequence and send this preamble sequence to the eNodeB at the same time. It leads
to the possibility of collision.
Scenario:

UE-A and UE-B transmit the same RACH preamble in the uplink at the same time. In this case, there will
be a collision.

There are 2 possibilities:

Possibility 1: There is collision and the eNodeB is not able to decode the preamble sent by any UE. In this
case, both UEs will run back-off timer with some random value and initiate the Random Access
Procedure again.

Possibility 2: The eNodeB is able to decode preamble only from UE-A. In this case, the following will
occur:

a. eNodeB will send Random Access Response (RAR) in downlink with RA-RNTI for UE-A. Here, RA-
RNTI will be same for both UE-A and UE-B because both UEs have transmitted the RA preamble
at the same time. So, although RAR is intended for UE-A, both UEs will decode RAR and work on
it.
Both UEs will acquire the same TC-RNTI present in RAR. UE-B at this stage doesn’t know that the
eNodeB was not able to decode its preamble.

b. Both UEs will choose some random number as its initial identity and send L3 message (e.g. RRC
Connection Request) to the eNodeB and start timer T300.

c. eNodeB will not be able to decode message from UE-B as it is using the timing advance value
that was intended for UE-A.

d. eNodeB will send RRC Connection Setup message in the downlink for UE-A. Both UEs will decode
this message as it is addressed by TC-RNTI. eNodeB will include random number in this message
that was sent by UE-A.

Although both UEs will decode this message, random number sent and received by UE-B will mismatch.
Only at this stage, UE-B will come to know that it has lost out to some other UE in contention resolution.
Then UE-B will start the RAP again from the very beginning.
Non-contention based RAP
There are instances when, because of timing restrictions, contentions are not acceptable. Examples of
such instances are:

1. Handover
2. Resumption of downlink traffic

In such cases, dedicated preamble sequences are allocated to UE by eNodeB. As these sequences are
allocated by the eNodeB, there are no collisions and no contentions. So, the RAP is faster.

Instances when Random Access is used:

1. Initial access from RRC Idle.

2. RRC connection establishment
3. DL data download, when UE’s UL synchronization status is “non-synchronized”.
4. Data upload, when UE’s UL synchronization status is “non-synchronized”.
5. During handover, when uplink synchronization is needed with target cell.