Sunday 16 May 2021

LTE: TDD Overview

  Thanks www.sharetechnote.com

LTE TDD Overview                          

 

 

 

Features

FDD

TDD

Frame Stracture

10 ms radio frame, 1 ms sub frame

10 ms radio frame, 1 ms sub frame

Switching Points

N/A

5 ms or 10 ms periodicity

DL Control Channel

Can Schedule 1 DL and 1 UL subframe at a time

Can schedule 1 DL and multiple UL sub-frame at a time

UL Control Channel

Single Ack/Nack corresponding to 1DLsub frame

Ack/Nack corresponding to multiple DL sub frame

PRACH Preamble Format

0,1,2,3

0,1,2,3,4(Short RACH)

PRACH Configuration

 

 

Special Slot usage

N/A

DwPTS : RS, Data and Control

UpPTS : SRS and Short RACH

HARQ Timing

K = 4 (fixed)

DL : Async, UL :Sync

K = varying depending on Subframe Config

DL : Async, UL : Sync

Ack/Nack Feedback ModeOne Transmission one Ack/NackBundling or Multiplexed
SR/DCI 0 Timing4 msVarying
DCI 0/PUSCH Timing4 msVarying

System Information Variation

 

SIB1

 

 

Frame Structure

 

< Subframe(UL/DL) Configuration >

 

 

< Special Subframe Length >

 

Special Subframe

Configuration

Length in Samples (Normal CP)

Length in OFDM Symbols (Normal CP)

DwPTS

GP

UpPTS

DwPTS

GP

UpPTS

0

6592 Ts

 

2560 Ts

3

10

1

1

19760 Ts

 

2560 Ts

9

4

1

2

21952 Ts

 

2560 Ts

10

3

1

3

24144 Ts

 

2560 Ts

11

2

1

4

26336 Ts

 

2560 Ts

12

1

1

5

6592 Ts

 

5120 Ts

3

9

2

6

19760 Ts

 

5120 Ts

9

3

2

7

21952 Ts

 

5120 Ts

10

2

2

8

24144 Ts

 

5120 Ts

11

1

2

 

For the examples of TDD resource grids for each Subframe DL/UL Configuration and Special Subframe Configuration, see Frame Structure Frame Type 2 Overview section.

 

 

 

Switching Points

 

 

Now the question comes, who decides the sequence of these subframes. That has been defined by 3GPP with the name TDD Frame Configurations. There are fixed patterns of these configurations and network operator has to choose out of these defined patters. There are total 7 TDD configurations as shown below:



And there comes a Special subframe which comes when there is transition from downlink subframe to uplink subframe. It has three parts –  DwPTS(Downlink Pilot Time Slot),GP (Guard Period) and UpPTS (Uplink Pilot Time Slot) and all of these have configurable lengths, which depends upon Special subframe configuration.

Special subframe configuration as shown below:



  • DwPTSis considered as a “normal” DL subframe and carries reference signals and control information as well as data for those cases when sufficient duration is configured. It also carries PSS.
  • GPis used to control the switching between the UL and DL transmission. Switching between transmission directions has a small hardware delay for both UE and eNodeB and needs to be compensated by GP. GP has to be large enough to cover the propagation delay of DL interferes. Its length determines the maximum supportable cell size.
  • UpPTSis primarily intended for sounding reference signals (SRS) transmission from UE. Mainly used for RACH transmission.


How Special subframe configuration impact Cell Size?

In TDD , there are 9 special subframe configuration, each have different number of OFDM symbols for DwPTS,GP and UpPTS. Special subframe guard period impact the size of cell, it represent how much propagation delay it can compensate. Longer guard period can compensate more propagation delay result a longer cell size.






PRACH Preamble Format

 

Refer to 36.211 5.7 Physical random access channel for the details.

 

 

 

RACH Configuration

 

 

 

Special Slot Usage

 

< RB Allocation on Special Subframe >

 

Refer to 36.213 7.1.7 Modulation order and transport block size determination for the details.

 

 

 

HARQ Timing

 

In case of FDD, it is pretty simple and obvious for UE to transmit HARQ ACK or NACK. UE start preparing the response as soon as it completes the decoding PDSCH and transmit it 4 ms (4 TTI) later. But in TDD, UE cannot transmit the response in such a fixed timing as in FDD. It has to wait until it gets the next chance for UL transmission and the next chance will be different depending on UL/DL configuration. Even when UE gets the chance to transmit the UL, it is may not always possible to transmit all the necessary response. For example, if UE gets too many DL subframe before the UL subframe, it will be difficult to transmit the all the reply in the UL transmission because PUCCH space is not big enough to accomodate all the HARQ ACK/NACK. So they came out with very complicated/confusing table as shown below to define HARQ response to cope with this kind of situation. In this section, I will explain how to interpret this table and figure out the exact HARQ response timing for each UL/DL configuration.

 

< ACK/NACK from UE for PDSCH >

 

Following table shows the Ack/Nack Transmission Timing from UE for the PDSCH it recieved.

 

 

Problem is how to interpret this table. Following shows how to interpret each raw of the table.

 

Case 1 : UL/DL Configuration 0

 

In case of UL/DL Configuration 0, Ack/Nack response timing for the PDSCH that is received by UE is transmitted according to the following rule.

 

 

How do you interpret this table and DL/UL correlation ?

 

It says

  • UE transmit Ack/Nack at subframe 2,4,7,9
  • At subframe 2, UE transmit Ack/Nack for PDSCH it received at subframe 6 in previous SFN
  • At subframe 4, UE transmit Ack/Nack for PDSCH it received at subframe 0 in current SFN
  • At subframe 7, UE transmit Ack/Nack for PDSCH it received at subframe 1 in current SFN
  • At subframe 9, UE transmit Ack/Nack for PDSCH it received at subframe 5 in current SFN

 

Case 2 : UL/DL Configuration 1

 

In case of UL/DL Configuration 1, Ack/Nack response timing for the PDSCH that is received by UE is transmitted according to the following rule.

 

How do you interpret this table and DL/UL correlation ?

 

It says

  • UE transmit Ack/Nack at subframe 2,3,7,8
  • At subframe 2, UE transmit Ack/Nack for PDSCH it received at subframe 5,6 in previous SFN
  • At subframe 3, UE transmit Ack/Nack for PDSCH it received at subframe 9 in previous SFN
  • At subframe 7, UE transmit Ack/Nack for PDSCH it received at subframe 0,1 in current SFN
  • At subframe 8, UE transmit Ack/Nack for PDSCH it received at subframe 4 in current SFN

 

 

Case 3 : UL/DL Configuration 2

 

In case of UL/DL Configuration 2, Ack/Nack response timing for the PDSCH that is received by UE is transmitted according to the following rule.

 

 

How do you interpret this table and DL/UL correlation ?

 

It says

  • UE transmit Ack/Nack at subframe 2,7
  • At subframe 2, UE transmit Ack/Nack for PDSCH it received at subframe 4,5,6,8 in previous SFN
  • At subframe 7, UE transmit Ack/Nack for PDSCH it received at subframe 9 in previous SFN and 0,1,3 in current SFN

 

Please try to do the same analysis for the remaining UL/DL Configuration on your own. It would be the best way for you to understand the meaning of the table clearly.

 

 

< ACK/NACK from eNB for PUSCH >

 

 

Case 1 : UL/DL Configuration 0

 

 

 

Case 2 : UL/DL Configuration 1

 

 

SR/DCI 0 Timing

 

The Time delay between SR(Scheduling Request) and DCI 0 is not clearly specified in 3GPP specification. So basically, NW can send DCI 0 in any available DL subframe after reception of SR, but depending on the eNodeB and Test Equipment some minimum time interval may be required.

 

 

DCI 0/PUSCH Timing

 

If UE recieves DCI 0 at subframe n, it should send PUSCH at subframe n + k where k is defined as follow. I will post some graphical explanation for this table later. Until then, give it a try on your own to understand this table.

 

36-213 V9.3.0 (2010-10) Table 8-2 k for TDD configurations 0-6

 

 

Issues with Debugging

 

What was your first impression about all the Ack-Nack report mechanism described above ?

My first impression was "So complicated !" and "So.. So.. So.. confusing".

Unfortunately.. there is more serious problem than the 'confusing things'. It is about troubleshooting issues.

 

Let's assume that you are using DL/UL Configuration 2. and suppose UE sent a NACK at Subframe 2.

How did you know whether the NACK is for PDSCH at subframe 4 or 5 or 6 or 8 ? (As you know, in FDD.. the answer is so simple since the ACK/NACK from the UE is always for the PDSCH that it received 4 subframe before. If it is FDD, the answer is supposed to be 'it is for PDSCH received at subframe 8 in previous SFN), but in TDD case it is different as you may guess.

 

 

Then how do you correlate the NACK to the specific PDSCH which caused the NACK. It is completely dependent on how much detailed information that your UE log or Network log provide. If UE log or Network log provide ACK/NACK information and HARQ process number for every subframe.. you can try following procedure.

    i) First, check UCI info at specific SFN and subframe number (let's label this as 'SFN_n:Subframe_2') and locate the HARQ process number that caused NACK.

    ii) Go to transmitted PDSCH list 'around' SFN_n:Subframe_2 (at this point, you would not know exactly which subframe you have to pin point out).

    iii) Look through several subframes upwards and downwards to find the subframe that is marking the same HARQ process number as you got at step i). That is the subframe that caused NACK.

 

 

 

Ack/Nack Feedback Mode

 

As described above, in TDD LTE ibe subframe can transmit ACK/NACK for multiple subframe as shown below. In the following figure as an example, UE send ACK/NACK for 4 PDSCHs in subframe 2. What should eNB do if the subframe 2 send NACK ? Does it have to retransmit the whole 4 PDSCHs ? or transmit only PDSCH which is NACKed ?

 

The answer to the question gets different depending on tdd-AckNackFeedbackMode setting in RRC message (e.g, RRC Connection Setup or RRC Connection Reconfiguration).

If it is set to be 'bundling', eNB should retransmit all the PDSCH. If it is sent to be 'multiplexing', eNB should retransmit the only PDSCH which is NACKed.

 

 

 

Followings are some of the items that is worth noticing from 3GPP 36.213 10.1.3 TDD HARQ-ACK feedback procedures (I revised the statement a little bit to make it simple and hopefully clearer)

  • For TDD UL/DL configuration 5 and a UE that does not support aggregating more than one serving cell, only HARQ-ACK bundling is supported.
  • If a UE that supports Carrier Aggregation is configured by higher layers to use HARQ-ACK bundling, PUCCH format 1b with channel selection according to the set of Tables 10.1.3-2/3/4 or according to the set of Tables 10.1.3-5/6/7, or PUCCH format 3 for transmission of HARQ-ACK shall be used.
  • PUCCH format 1b with channel selection according to the set of Tables 10.1.3-2/3/4 or according to the set of Tables 10.1.3-5/6/7 is not supported for TDD UL/DL configuration 5.
  • TDD HARQ-ACK bundling is performed per codeword across M multiple DL subframes associated with a single UL subframe n, by a logical AND operation of all the individual PDSCH transmission (with and without corresponding PDCCH/EPDCCH) HARQ-ACKs and ACK in response to PDCCH/EPDCCH indicating downlink SPS release
  • For TDD HARQ-ACK multiplexing and a subframe n with M >1, spatial HARQ-ACK bundling across multiple codewords within a DL subframe is performed by a logical AND operation of all the corresponding individual HARQ-ACKs. PUCCH format 1b with channel selection is used in case of one configured serving cell
  • For TDD HARQ-ACK multiplexing and a subframe n with M = 1, spatial HARQ-ACK bundling across multiple codewords within a DL subframe is not performed, 1 or 2 HARQ-ACK bits are transmitted using PUCCH format 1a or PUCCH format 1b, respectively for one configured serving cell.
 

 

You would notice the variable 'M' in many of the statement above. M is defined to be "the number of elements in the set K defined in Table 10.1.3.1-1". Following examples would give you clearer idea on the meaning of M.

 

 

 

System Information Variation

 

 

 

Q. In TDD, why special sub-frame is used for switching Downlink (DL) to Uplink (UL) . Why not for UL to DL ? What’s the reason Please clarify.

There are 2 versions of the answer , some people will get satisfied with version 1, others with version 2. Both are correct, but that’s how we all learn , what convinces us.

Version 1:

For TDD, in the Downlink , due to path distance DL signal can be delayed. Due to path distance , path delay is created. Delay can cause collision between UL and DL signals. The guard period provides enough time for DL delayed signal to arrive due to path distance, and also gives enough opportunity for (User Equipment)UE to receive UL timing advance command from the Base station.

Follow up Question. Why special sub-frame only in DL to UL, why not from UL to DL ?

UE always transmit in UL after receiving grant from the BS. BS can advance or retard the UL timing command as needed. Once DL signal is received completely then UE can send command /signal in return with respective timing ( UE cannot transmit on its own before receiving a complete response from the DL) . So we need a guard period for DL to UL switching, to avoid collisions. Whereas in case of UL to DL switching there is no need of Guard period, as eNodeB has timing advance feature plus there will be minimum chance of collision in UL to DL case.





In DL to UL switching , a Guard Period is needed , ” To avoid the time advanced UL to collide with the delayed DL”



Version 2:

A simple answer is in TDD because there is no duplex Frequency and all management must be done on the same path, then UE should first receive info about up-link(most important one is Time scheduling ). Therefore, Downlink should always be done before Uplink in TDD mode.

If you have anything else to add , feel free to write it in the comments below.

 


No comments:

Post a Comment

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