Sunday 16 May 2021

LTE: Timing Advance

 Timing Advance

 

Timing Advance is a MAC CE that is used to control Uplink signal transmission timing. Network (eNodeB in this case) keep measuring the time difference between PUSCH/PUCCH/SRS reception and the subframe time and can send a 'Timing Advance' command to UE to change the PUSCH/PUCCH transmission to make it better aligned with the subframe timing at the network side. If PUSCH/PUCCH/SRS arrives at the network too early, network send a Timing Advance command to UE saying "Transmit your signal a little bit late", If PUSCH/PUCCH/SRS arrives at the network too late, network send a Timing Advance command to UE saying "Transmit your signal a little bit early".

 

MAC PDU for Timing Advance is as follows. It is one byte data and the first two bits are reserved and set to be always 0. The remaining 6 bits carries Timing Advance command value ranging from 0 to 63.

 

As you see in the following figures, for Rel 8,9,10 there is no special tag for each component carrier, meaning that even in Carrier Aggregation single Timing Advanced value apply to all the component carriers. But in Rel 11, the first 2 bits are allocated to indicate whether the value is for PCC or SCC. If TAG id is 0, it means it is for PCC.

 

< 36.321 Rel 8,9,10 - Figure 6.1.3.5-1: Timing Advance Command MAC control element >

 

< 36.321 Rel 11 - Figure 6.1.3.5-1: Timing Advance Command MAC control element >

 

 

Then how to translate each value of TA(Timing Advance) value to physical 'time' delay or advance value. It is described in detail in 36.213 4.2.3 Transmission timing adjustments. Simply put, the UL transmit timing is controlled by following equation.

 

UL Transmission Time = (UL Transmittion Time for Previous subframe) + (TA value - 31) x 16 samples.

                   , where 1 sample is about 0.033 us and 16 samples is about 0.52 us.

 

By this calcuation, you can see that the maximum timing change by single TA value (0 or 63) is about 16.7 us (I hope my calculation is right. please let me know if this calculation is wrong).

 


The Timing Advance is equal to 2 x propagation delay assuming that the same propagation delay value applies to both downlink and uplink directions. So, UE1 needs to start it’s uplink at t1+2δ1 whereas UE2 should start it’s uplink at t1+2δ2. This will ensure that both of the uplink transmissions (from UE1 and UE2) reach the eNodeB at the same time which means that at the eNodeB, both uplink and downlink subframes are time aligned.
If the Timing Advance is not applied, then the start of uplink transmission from UE2 for subframe #n+1 will overlap with the end of uplink transmission from UE1 for subframe #n. Assuming that same resource blocks are assigned to UE1 in subframe #n and UE2 in subframe #n+1, this overlap creates interference which causes reception failures at the eNodeB. If a proper value of Timing Advance is applied, then these subframes won’t collide.

Timing Advance Command in LTE
The eNodeB estimates the initial Timing Advance from PRACH sent by the UE. PRACH is used as timing reference for uplink during UE’s initial access, radio link failure, during Handover etc…The eNodeB sends Timing advance command in Random Access Response (RAR). Once the UE is in connected mode, the eNodeB keep estimating Timing Advance and sends Timing Advance Command MAC Control Element to the UE, if correction is required.
The UE shall adjust the timing of its uplink transmission at subframe #n+6 for a Timing Advance Command received in subframe #n
The UE shall adjust the timing of its transmissions with a relative accuracy better than or equal to ±4*TS seconds to the signalled timing advance value compared to the timing of preceding uplink transmission
The timing advance command indicates the change of the uplink timing relative to the current uplink timing as multiples of 16Ts.
NTA is the timing offset between uplink and downlink radio frames at the UE, expressed in units of Tswhere Ts = 1/(2048x15000) = 1/30720000 sec
    Timing Advance Command in MAC RAR
The Timing Advance Command in RAR takes 11 bits and it can indicate an index value TA (0, 1, 2… 1282) which used to control the amount of timing adjustment that UE has to apply. The amount of the time alignment is given by NTA = TA × 16. The Timing Advance obtained via RAR is always positive
Example1 (TA = 0): When the received TA = 0  NTA = 0 so no timing adjustment required.
Example2 (TA = 1): If TA = 1  Timing Adjustment = NTA = 16 Ts 16/30720000 sec = 0.5208 μs ⇨ Distance = (3x108x0.5208x10-6)/2 = 78.12m which is the minimum
Example3 (TA = 1282): When the received TA = 1282  NTA = 1282x16Ts 1282x16/30720000 sec = 667.66 μs ⇨ Distance = (3x108x667.66x10-6)/2 = 100.15Km which is the maximum propagation distance
The maximum distance value (of slightly above 100Km) would facilitate cell radius of up to 100Km.
    Timing Advance Command MAC CE
In the case of Timing Advance Command MAC CE, it indicates relative Timing Advance which is 6-bit index value TA (0, 1, 2… 63). In this case, NTA,new = NTA,old + (TA  − 31)×16 where NTA,old  is the current timing adjustment and NTA,new indicates new value. Here, adjustment of NTA value by a positive or a negative amount indicates advancing or delaying the uplink transmission timing by a given amount respectively
Timing Advance command in MAC RAR and MAC CE are illustrated below



Uplink Time Alignment
It was discussed above how the eNodeB controls Timing Advance that each UE has to apply. Once the UE gets a Timing Advance Command, UE applies it and now the question is for how long the UE uses the received Timing Advance value?
The eNodeB provides the UE with a configurable timer called timeAlignmentTimer. TimeAlignmentTimer is used to control how long the UE is considered uplink time aligned
The value of the timer is either UE specific (timeAlignmentTimerDedicated) and managed through dedicated signalling between the UE and the eNodeB, or cell specific (timeAlignmentTimerCommon) which is indicated in SIB2. In both cases, the timer is normally restarted whenever a new Timing Advance is given by the eNodeB. At the time of restart, the timer is restarted to a UE specific value if configured; otherwise it is restarted to a cell specific value
The UE starts/restarts the TimeAlignmentTimer based on the condition when it received the Timing Advance Command.
  • The Timing Advance Command is received in MAC RAR but timeAlignmentTimer is not already running: This case may arise in situations like, timeAlignmentTimer has expired (connected mode), Initial access from RRC_IDLE, during RRC Connection Re-establishment procedure etc…After the reception of RAR, the UE shall apply the Timing Advance Command value received in RAR and start timeAlignmentTimer. If the contention is not resolved/successful, then the UE stops timeAlignmentTimer, else, the UE continues running the timer
  • The Timing Advance Command is received in MAC RAR as part of non-contention based Random Access procedure (ex: PDCCH Order):  After the reception of RAR, the UE shall apply the Timing Advance Command value received in RAR and starts/restart the timeAlignmentTimer
  • The Timing Advance Command is received in MAC RAR as part of contention based Random Access procedure in connected mode and timeAlignmentTimer is already running: This could be in situations like UE is requesting for uplink resources but UE doesn’t have valid PUCCH resources for SchedulingRequest etc…After the reception of RAR, the UE shall ignore the received Timing Advance Command value and shouldn’t restart the timeAlignmentTimer
  • When a Timing Advance Command MAC CE is received, the UE shall apply the received value of Timing Advance Command value and start/restart timeAlignmentTimer

As discussed before, the eNodeB continuously measures timing of uplink signal from the UE and adjusts the uplink transmission timing by sending the Timing Advance Command to the UE. If the UE has not received a Timing Advance Command until the expiry of timeAlignmentTimer, the UE assumes that it has lost the uplink synchronization. Hence, prior to any PUSCH/PUCCH/SRS transmission in the uplink, an explicit timing-re-alignment phase using the random access procedure must be performed to restore the uplink time alignment
The UE shall perform the following actions upon the expiry of timeAlignmentTimer:
  • Flush all HARQ buffers;
  • If configured, release PUCCH resources of Periodic CQI and Scheduling Request, and also SRS configuration. By doing so, the UE doesn’t perform transmission of SRS/PUCCH while timeAlignmentTimer is not running. The eNodeB has to configure these parameters again in order for the UE to transmit SRS/Periodic CQI/Scheduling Request after UE starts timeAlignmentTimer
  • Clear configured downlink assignments and uplink grants. i.e., release SPS grant (uplink) and assignment (downlink) if configured

The UE shall not perform any uplink transmission except the Random Access Preamble transmission when timeAlignmentTimer is not running.








No comments:

Post a Comment

If You have any concern you are free to message/comment me.