LTE RACH Procedure With Call Flow

LTE RACH Procedure with Call Flow
The Base station continuously broadcast MIB's and SIB's. When the UE powers on, it syncs up with the network and it looks for these messages. Here on, the explanation is provided for the initial connectivity of the UE. i.e. when the UE is powered on: 1. First, the UE has to synchronize with the network at the frame and slot level. The Primary Synchronization Signal is responsible for slot synchronization. The Synchronization Signal are sent only on time slots (1st and 11th) of each frame. PSS is send at the last OFDM symbol of the 1st and 11th slot of each frame.
Query_1: How does UE know to look for the PSS synchronization signal? Well, UE doesn't need to worry much for this. As, the synchronization signal are always sent only on the center 62 sub carriers irrespective of the channel bandwidth (1.25,3,5,10,20). Therefore, UE will look for the central sub carriers, i.e at the last OFDM symbol of the 1st time slot and again at the last OFDM symbol of the 11th slot. With this UE synchronizes at the slot level. The Secondary Synchronization Signal is responsible
for frame synchronization. Using both these signals, the UE derives the Physical Cell ID of the corresponding cell.
Query_2: How does UE know to look for the SSS synchronization signal? Once, when the PSS is identified, SSS is always send at the slot before the PSS is present. In other words, SSS immediately precedes the PSS. Let's see how the UE derives the Cell ID using these two signals: From PSS: PHYSICAL LAYER CELL IDENTITY is derived. It carries the value of 0, 1 and 2. From SSS: PHYSICAL LAYER CELL IDENTITY GROUP is derived. It can take the value to 0 to 167. Formula: Cell ID= (3*PHYSICAL LAYER CELL IDENTITY GROUP) + PHYSICAL LAYER CELL IDENTITY
2. Once the UE synchronizes with the network, it proceeds to read MIB and then requires the following info for camping on a cell: PLMN id Tracking Area Id Cell Id Radio and Core n/w capabilities (for it's n/w selection) 3. The above information is being broadcast by the network in order to help the UE for it's selection process. 4. This broadcast is known as SYSTEM INFORMATION which is MIB and SIB's. The call flow for the UE to read the System information is mentioned below:
UE Cell Selection Procedure

Query_3: How does the UE read MIB? The MIB is transmitted on physical channel (BCCH-BCH-PBCH) and it always occupies the central 72 sub carriers in the Frequency domain irrespective of the channel bandwidth. The first transmission of the MIB is scheduled in sub-frame number 0 of radio frames for which the SFN mod 4 = 0 repetitions are scheduled in sub-frame 0 of all other radio frames From the MIB, UE gets the following information: Channel bandwidth in terms of Resource Blocks SFN (System Frame Number) PHICH configuration (used for HARQ ACK/NACK) 5. Till now, the UE has synchronized itself with the Cell with the help of PSS and SSS; followed by reading the MIB. Now, UE will proceed to read SIB1 and SIB2 which carriers important information for the UE to select a Cell. To know more about SIB's and it's working, click here
6. After the above process the UE is synchronized with the network in the Downlink direction and have read SIB1 and SIB 2. Now, it needs to
synchronize in the Uplink direction
7. For this to happen, RAP (Random Access Procedure) is initiated
RACH is common in FDD and TDD

There are two types of RAP: 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:
Contention based RACH procedure

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 retransmitted 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 RRCconnectionSetup and 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 S1AP MME Configuration Update

Some information like (MME name, part of GUTI [GUMMEI], MMEcapacity) is provided by MME through interface S1 in an S1AP MME Configuration Update message
5. This communication happens after the S1 interface establishment between the eNB and MME. The call flow can be identified below:
S1AP Configuration Update Procedure

LTE RACH Procedure With Call Flow

Uploaded by

Copyright:

Available Formats

LTE RACH Procedure With Call Flow

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

LTE RACH Procedure With Call Flow

Uploaded by

Copyright:

Available Formats

LTE RACH Procedure with Call Flow

UE Cell Selection Procedure

7. For this to happen, RAP (Random Access Procedure) is initiated

RACH is common in FDD and TDD

Contention based RAP

Contention based RACH procedure

Non-contention based RAP

Non Contention Based RAP S1AP MME Configuration Update

S1AP Configuration Update Procedure

You might also like