《LTE TDD overview》

文档链接：http://www.sharetechnote.com/

帧结构

上下行子帧配比：

<特殊子帧长度>：

<切换时间点>：

< PRACH Preamble Format>:

详细信息参考协议：36.211 5.7 物理随机接入信道

< RACH COnfiguration>:

<特殊时隙用途>：

<特殊子帧上的RB分配>：

详细信息参考协议：36.213 7.1.7 调职顺序与传输块大小的决定

< HARQ 时间>：

FDD中，对于UE来说，发送HARQ ACK/NACK比较容易。UE一旦完成PDSCH解码，就会做好发送ACK/NACK响应，并且会在4ms（即4个TTI）后发送出去。但是 ，对于TDD来说，不会以固定时隙来做出响应。TDD中，UE必须等到它获得下次上行传送的机会，而下次上行传送的机会随着上下行的配比的不同而不同。甚至，就算UE获得下次上行传送的机会，也不会都去响应。比如说，UE在上行子帧之前收到太多的下行子帧，那么它就会很难在上行传输信道上全部做出响应，这是因为PUCCH的空间有限，不能容纳全部的HARQ ACK/NACK消息。

< UE针对收到的PDSCH，回复ACK/NACK的时间点>

下表显示了： UE针对收到的PDSCH，回复ACK/NACK的时间点

问题是：该如何读懂上表呢？下面针对上表的每一行给出描述
情况1： UL/DL Configuration 0
在这种情况下，UE根据下面的规则来回复ACK/NACK(针对其收到的PDSCH)

也就是说：
UE在子帧2，4，7，9上发送ACK/NACK
* 如果UE在子帧2上发送ACK/NACK，那么UE是在前一个系统帧的子帧6上接收到PDSCH的
* 如果UE在子帧4上发送ACK/NACK，那么UE是在当前系统帧的子帧0上接收到PDSCH的
* 如果UE在子帧7上发送ACK/NACK，那么UE是在当前系统帧的子帧1上接收到PDSCH的
* 如果UE在子帧9上发送ACK/NACK，那么UE是在当前系统帧的子帧5上接收到PDSCH的

情况2： UL/DL Configuration 1
在这种情况下，UE根据下面的规则来回复ACK/NACK(针对其收到的PDSCH)

也就是说：
UE在子帧2，3，7，8上发送ACK/NACK
* 如果UE在子帧2上发送ACK/NACK，那么UE是在前一个系统帧的子帧5，6上接收到PDSCH的
* 如果UE在子帧3上发送ACK/NACK，那么UE是在前一个系统帧的子帧9上接收到PDSCH的
* 如果UE在子帧7上发送ACK/NACK，那么UE是在当前系统帧的子帧0，1上接收到PDSCH的
* 如果UE在子帧8上发送ACK/NACK，那么UE是在当前系统帧的子帧4上接收到PDSCH的

情况3： UL/DL Configuration 2
在这种情况下，UE根据下面的规则来回复ACK/NACK(针对其收到的PDSCH)

也就是说：
UE在子帧2，7上发送ACK/NACK
* 如果UE在子帧2上发送ACK/NACK，那么UE是在前一个系统帧的子帧4，5，6，8上接收到PDSCH的
* 如果UE在子帧7上发送ACK/NACK，那么UE是在前一系统帧的子帧9或当前系统帧的子帧0，1，3上接收到PDSCH的
*
——————————后面的情况以此类推———————————–

< eNB针对收到的PUSCH，回复ACK/NACK的时间点 >:

下表显示了：eNB针对收到的PUSCH，回复ACK/NACK的时间点

情况1： UL/DL Configuration 0
也就是说：
UE在子帧2,3,4,7,8,9上发送PUSCH
* 如果UE在子帧2上发送PUSCH，那么eNB会在当前系统帧的子帧6上回复ACK/NACK
* 如果UE在子帧3上发送PUSCH，那么eNB会在下一个系统帧的子帧0上回复ACK/NACK
* 如果UE在子帧4上发送PUSCH，那么eNB会在下一个系统帧的子帧0上回复ACK/NACK
* 如果UE在子帧7上发送PUSCH，那么eNB会在下一个系统帧的子帧1上回复ACK/NACK
* 如果UE在子帧8上发送PUSCH，那么eNB会在下一个系统帧的子帧5上回复ACK/NACK
* 如果UE在子帧9上发送PUSCH，那么eNB会在下一个系统帧的子帧5上回复ACK/NACK

情况2： UL/DL Configuration 1

也就是说：
UE在子帧2,3,7,8上发送PUSCH
* 如果UE在子帧2上发送PUSCH，那么eNB会在当前系统帧的子帧6上回复ACK/NACK
* 如果UE在子帧3上发送PUSCH，那么eNB会在当前系统帧的子帧9上回复ACK/NACK
* 如果UE在子帧7上发送PUSCH，那么eNB会在下一个系统帧的子帧1上回复ACK/NACK
* 如果UE在子帧8上发送PUSCH，那么eNB会在下一个系统帧的子帧4上回复ACK/NACK

——————————–后面的情况以此类推———————————–

< SR/DCI 0 Timing>

SR和DCI 0消息之间的时间延迟在3GPP协议中没有明确的规定，所以，基本上当eNB收到SR后，可以在任何可用的下行子帧上发送DCI 0消息。但是根据eNB和测试环境，可能需要最小的时间间隔。

< DCI 0/PUSCH Timing>

如果UE在子帧n接收到DCI 0消息，那么UE会在子帧n+k上发送PUSCH消息（k定义如下表）

< 问题调试>

针对前面所描述的ACK-NACK传输机制，你的第一映象是什么呢？是不是很困惑，想想就觉得很复杂，是不是？
然而更加困惑的问题是：问题排查/定位
以UL/DL Configuration 2为例，假设UE在子帧2上发送了一个NACK消息，你如何知道这个NACK消息是针对子帧4，还是子帧5，还是子帧6，还是子帧8下发的PDSCH消息所反馈的呢？（如你所知，在FDD中，这毫无疑问，这个NACK消息肯定是针对前一个系统帧的子帧9下发的PDSCH消息所反馈的，原因是FDD中，消息间隔总是4个子帧），但是在TDD中，这就有点难以判断了。。。
如此，在TDD中，该如何定位（子帧4，子帧5，子帧6，子帧8）中的哪个呢？这就需要提供详细的UE log和网络侧log（eNodeB log）了，然后根据以下步骤来尝试定位：
1. 在特定系统帧号SFN和子帧号上检查UCI消息（标记为：‘SFN_n:Subframe_2’），然后定位导致NACK的HARQ过程；
2. 在’SFN_n:Subframe_2’附近浏览PDSCH，这时你还不能准确的标记出到底是哪个子帧；
3. 上上下下多浏览几个，找出与第1）步相同帧号的HARQ，这就是要找的帧。

< ACK/NACK反馈模式>

正如上面所述，在TDD中，可以在多个子帧上发送ACK/NACK消息。以下图为例，UE在子帧2上反馈ACK/NACK消息（可以用来针对之前的4个PDSCHs消息）。那么当UE在子帧2上发送了NACK消息后，eNB该做什么呢？是不是必须重传这4个PDSCHs消息，还是仅仅重传导致NACK的PDSCH消息？

对于上面的问题，到底是4个PDSCHs要全部重传，还是仅仅只重传一个导致NACK的PDSCH，这取决于RRC消息中的‘tdd-AckNackFeedbackMode’参数的设置
**if tdd-AckNackFeedbackMode set as bundling—->4个PDSCHs需全部重传；
if tdd-AckNackFeedbackMode set as multiplexing—->仅需重传一个；**