下行HARQ

对于MAC来说，HARQ是最复杂的一部分。

原理不多说了，对于HARQ重传来说，4次传输的HARQ重传机制是效率最高的，因此我们的基站也是采用的这样的方式。

TDD系统中，下行的HARQ进程数目是与下行子帧个数有关系的；比如TDD 1的配置下，下行的HARQ进程数目是7个，TDD 2的配置下，下行的HARQ进程数目是10个。这样的HARQ进程数目的设计其实主要是因为严格限定了每个子系统的处理时延。

理论上，HARQ数目可以多一些，因为这个是纯粹的逻辑限制，不是物理限制；但是越多的HARQ进程，带来的相应的处理就会越复杂，比如MAC需要维护的HARQ Buffer就变得更多。以TDD 2，特殊子帧配置7为例，8个下行子帧，2个上行子帧，HARQ的进程数目是10个。它意味着在做满速率下行业务的时候，如果每个子系统处理时间是OK的，那么在MAC层对每一次调度关联的HARQ进程数目在满调度的情况下是刚好够用的。如下图所示：

TDD配置2的绑定窗口是【9 0 1 3】、【4 5 6 8】这样的，假设从9号子帧开始分HARQ进程号0，对于HARQ反馈，【9 0 1 3】的下行反馈在【7】号子帧上来，【4 5 6 8】的在【2】号子帧上来。

从0开始，到9号HARQ进程，在上图的第三个无线帧的0号子帧刚好用完；而我们的基站因为HARQ处理时序问题，总不能及时尽快的释放HARQ进程，导致子帧1刚好没有空闲的HARQ进程可用，那么就会导致因为HARQ进程耗尽而得不到调度。接着后面释放的HARQ进程是4个【0 1 2 3】可以给后面的用，再往后【4 5 6 7】可以用；再往后，因为上一个7号子帧对应的下行调度只有3次（其中有一次是因为特殊子帧1号帧没有得到调度），所以只释放了3个HARQ进程，那么刚好图示中最后一个无线帧的6号子帧也会因为没有多余的HARQ进程而得不到调度。如此往复。

所以会产生这样一个效果，默认配置，特殊子帧配置7的情况下，有1/3的特殊子帧得不到调度。那么在一个30ms的周期内，固定有2个特殊子帧不能调度，如此在单用户调度的情况下，损失的PRB利用率就可以计算得到，为2/24 = 8.3%。

TDD 1的情况下HARQ处理如下，不再过多解释。

同样，PRB利用率的损失就是2/18 = 11.1%。

正常不会存在HARQ进程耗尽而不能调度的情况，因此基站有一个峰值速率开关来规避这个问题，开关名字是：LTE_PEAK_THP_TMP_SLN。

HARQ在重传过程中，遵循的RV版本号的变换的【0 2 3 1】，MCS的选择是按照协议的【29 30 31】去选取。

在PUCCH里面的HARQ位置，对于TDD的公式如下：

c的取值范围为{0, 1, 2, 3}，就是从PDCCH占用的符号数来的。

M就代表该上行时隙要回应的可能的下行时隙的最大个数，其实就是TDD配置下的bundling窗口的大小。

i就代表应该回应ACK/NACK的按照先后顺序的第几个下行子帧。

举个例子，如果是M=4，20M带宽，N_PUCCH_1 = 8，该值意思为前面的资源已经被SR占用，现在的HARQ的起始从这里开始