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 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
- 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
No comments:
Post a Comment
If You have any concern you are free to message/comment me.