LTE Timing Advance Command

What is Timing advance in LTE and why is it required?

As UE is not always stationary with respect to eNB, the variation in distance between UE and eNB will reflect in UL transmission time (msg received at eNB). Due to the change, eNB encounters interference as UL transmission of different UE's can be overlapping.

How is it achieved?

To avoid this kind of interference, eNB will either periodically or need basis correct the UE to either advance or delay the UL transmission with a granularity of 16 Ts(basic time unit).
UE receives the Timing Advance (TA) in either the MAC CE Timing Advance command or in RAR during RACH procedure.

1. if UE receives the TA in MAC CE or
   if UE receives the TA in RAR and if preamble index is not selected by UE or
   if UE receives the TA in RAR and if time alignment timer is not running
• apply the Timing Advance command
• start or restart time alignment timer
2. else ignore the Timing Advance command

The new correction is valid till the expiry of time alignment timer. As cyclix prefix (CP) is added to start of each OFDM symbol, the overlapping interference at eNB can be ignored till the time it's not exceeding the Tcp (Duration of Cyclix Prefix).

What happens if Time alignment timer is expired?

When Time alignment timer is expired, UE is assumes to have lost UL sync with eNB and

1. releases PUCCH/SRS configuration
2. flush all HARQ buffers
3. clear any configured UL & DL grants

How does UE obtain the time alignment timer configuration?

Time alignment timer value is received in SIB-2 (common to all UE's) and mac-MainConfig (UE specific value). 

UE applies the value received in SIB-2 when moving from idle to connected mode or during rrc connection reestablishment radio link recovery phase.

When UE receives dedicated time alignment timer in either the rrc connection setup or rrc connection reconfiguration, UE will apply the new value during the next timer restart.

TimeAlignmentTimer ::= ENUMERATED {
sf500, sf750, sf1280, sf1920, sf2560, sf5120,
sf10240, infinity}

References

1. 3GPP 36.213
2. 3GPP 36.321

LTE Random Access Procedure (RACH)

When is RACH Procedure triggered?

RACH procedure is triggered when UE is camped on to a cell and any of the below conditions happens

1. UE requires UL synchronization with eNB for sending UL data 
• UE is moving from idle to connected  or
• Handover to other cell (Target eNB may/may not provide dedicated preamble through rrc reconfiguration message of source eNB).
2. eNB receives DL data but finds UL synchronization with UE is lost (PDCCH order).
• eNB notifies UE to do PRACH by sending DCI 1A with/without a dedicated preamble info.
3. UE doesn't have any grant to transmit UL Data and finds PUCCH resources are not configured/released for transmission of SR
• eNB doesn't configure UE with any PUCCH resources for SR transmission or
• When max-SR transmission have reached, UE releases PUCCH resources or
• Time alignment timer expiry, UE releases PUCCH resources.

Different types of RACH Procedures and their differences

RACH procedures are of two types

1. Non-Contention Based:
• UE uses the dedicated preamble allocated by  eNB.
• Scenario: Handover and PDCCH order.
2. Contention Based
• Preamble is selected by MAC itself. While doing RACH procedure several UE's may selected the same preamble, so additional contention resolution is required. Contention resolution procedure is assumed to be completed when UE receives contention resolution MAC CE or DCI 0 with C-RNTI for the transmitted msg3.

RACH procedure

RACH procedure sequence is as follows

1. Preamble selection: If Preamble index is not provided to UE, based on the msg3 size, power level and other parameters in RACH-CommonConfig, UE will select a preamble index.
2. RACH Transmission: Based on the prach-config parameter, UE computes the prach transmission opportunity and transmits preamble index on PRACH channel. At the same time RA-RNTI is computed based on the RACH transmission parameters.
                                            RA-RNTI = t_id +10* f_id
3. PDCCH RA-RNTI Montioring: 3ms/sub-frames after RACH transmission sub-frame, UE will start monitoring the PDCCH channel for RA-RNTI for a duration of RA-Response window irrespective of the measurement gap.
4. RAR Reception: If UE successfully receives Random Access Resonse (RAR) on RA-RNTI  and contains the same preamble index in the received RAPID.
   If Preamble index was provide by eNB, RACH procedure ended and is considered as successful
   else UE proceeds to contention resolution procedure.
• apply Timing Advancement Command (TAC)
• update the Temp C-RNTI to the value received (only in case of contention resolution process)
• use the received UL grant for transmitting msg3 (only in case of contention resolution process)
5. RAR Reception: Else if UE successfully receives Random Access Resonse (RAR) on RA-RNTI  but contains back off indicator.
• set the back off parameter in UE to the BI value received in RAR.
6. RAR Failure Case:If UE fails to receive RAR within RA-Response window or if received RAR doesn't contain the transmitted preamble index in any of the RAPID's, RACH procedure is considered as unsuccessful
• increment PREAMBLE_TRANSMISSION_COUNT by 1  
• if PREAMBLE_TRANSMISSION_COUNT is PreambleTransMax +1, indicate RACH problem to upper layers.
• if the preamble was selected by UE, UE will select a random back off time from 0 to back off parameter before going to retry RACH procedure.
• retry the RACH procedure step (1).

What does UE send in UL for the received RAR-GRANT?

Based on the below conditions which triggered RACH procedure MAC will be forming the TB (msg3)

1. If RACH is triggered due to CCCH data, msg3 will be either RRC connection request or RRC connection re-establishment request.
2. Else if Grant is received in the 1st RAR and RACH is not triggered due to CCCH data and UE contains a valid C-RNTI; MAC will include the C-RNTI MAC CE along with the UL data/BSR.

Contention Resolution Procedure

Contention resolution procedure is applicable only if preamble index is selected by UE. UE starts/restarts contention resolution timer for transmission of msg3 or non-adaptive HARQ re-transmisssion of msg3. After transmission of msg3, UE will monitor the PDCCH channel for C-RNTI/Temp C-RNTI till contention resolution timer is expired irrespective of the measurement gap.

If UE receives data notification on PDCCH channel and 

1.  If C-RNTI MAC CE was included in the msg3 and if RACH was due to PDCCH order and PDCCH transmission was addressed to C-RNTI or  if RACH was triggered by MAC itself and PDCCH transmission was addressed to C-RNTI and contains UL grant for new transmission
• consider Contention resolution as successful.
• stop contention resolution timer
• discard Temp C-RNTI
• RACH procedure is considered successful.
2. Else if msg3 was CCCH data and UE receives PDCCH transmission addressed to Temp C-RNTI and MAC PDU decodes successfully and contains the contention resolution id in msg3.
• consider Contention resolution as successful.
• stop contention resolution timer
• set C-RNTI to Temp C-RNTI.
• discard Temp C-RNTI
• RACH procedure is considered successful.
3. Else consider contention resolution is not successful.

If contention resolution timer expires, contention resolution is not successful.

If contention resolution is not successful then

1. if time alignment timer is running, stop the time alignment timer
2. flush HARQ buffer used for msg3
3. increment PREAMBLE_TRANSMISSION_COUNT by 1  
4. if PREAMBLE_TRANSMISSION_COUNT is PreambleTransMax +1, indicate RACH problem to upper layers.
5. UE will select a random back off time from 0 to back off parameter before going to retry RACH procedure.

What happens when lower layers sends RACH problem indication?

When upper layers receives RACH problem indication, UE will re-try to camp on to the same cell, while parallel doing PLMN search to find any other alternative cells.

RACH parameters obtained from SIB-2 and Mobility message

RadioResourceConfigCommon in SIB-2/RRC mobility message contains all the parameters required for RACH (prach-config & RACH-ConfigCommon).

PRACH-ConfigSIB ::= SEQUENCE {
     rootSequenceIndex INTEGER (0..837),
     prach-ConfigInfo PRACH-ConfigInfo
}

PRACH-ConfigInfo ::= SEQUENCE {
     prach-ConfigIndex INTEGER (0..63),
     highSpeedFlag BOOLEAN,
     zeroCorrelationZoneConfig INTEGER (0..15),
     prach-FreqOffset INTEGER (0..94)
}

RACH-ConfigCommon ::= SEQUENCE {
      preambleInfo SEQUENCE {
              numberOfRA-Preambles ,
              preamblesGroupAConfig SEQUENCE {
                       sizeOfRA-PreamblesGroupA,
                       messageSizeGroupA ENUMERATED {b56, b144, b208, b256},
                       messagePowerOffsetGroupB
       },
      powerRampingParameters SEQUENCE {
               powerRampingStep ENUMERATED {dB0, dB2,dB4, dB6},
               preambleInitialReceivedTargetPower,
      },
      ra-SupervisionInfo SEQUENCE {
               preambleTransMax,
              ra-ResponseWindowSize,
              mac-ContentionResolutionTimer
     },
    maxHARQ-Msg3Tx INTEGER (1..8), 
}

In case of handover additional RACH-ConfigDedicated is included in mobility message which contains dedicated preamble index for non-contention based RACH procedure.

RACH-ConfigDedicated ::= SEQUENCE {
     ra-PreambleIndex INTEGER (0..63),
     ra-PRACH-MaskIndex INTEGER (0..15)
}

References

1. 3GPP 36.321