为什么VoLTE需要TTI捆绑？

donnar

通常，LTE网络的整体链路预算受限于PUSCH信道的误块率BLER要求。评估PUSCH的BLER时，要重点考虑上行链路传输的调制和编码方案MCS、以及处于小区边缘的UE发送数据时用到的资源块RB数量。如果我们想通过选择MCS和RB数实现最大的覆盖率，比如MCS选用QPSK、上行链路每次传输使用1个RB，则在部署VoLTE业务时会遇到麻烦。

VoLTE支持自适应多速率编码方法（Adaptive Multi-rate Coder，AMR）。如果我们选用一个普通的AMR速率，比如12.23kbps或12.65kbps，我们会发现，如果坚持单次用1个RB在上行链路完成数据传输，就必须在RLC层对VoLTE数据包进行分段(Segmentation)，并且对每一分段采用独立的HARQ过程进行传输。因为对于比如长度为33字节的VoIP数据包（包含L1/L2层的头部信息）在1ms的时间内发送，物理层的速率需要达到312kbps，而在小区边缘往往无法达到这个要求。

由于数据包分段会带来新的问题，因此比较可行的方法是在上行链路使用2RB传输，从未避免使用数据包分段。

再回到链路预算，由于在小区边缘的上行传输从1RB变成2RB，我们必须考虑到接收器灵敏度的影响——特别是eNB接收器必须克服的噪声带宽会提高3dB。为了提高上行数据传输成功率，我们可以增加更多的HARQ传输，比如8个HARQ传输（正常情况下是4个HARQ传输）。于是，现在的问题不再是覆盖（链路预算），而是时延。对于AMR语音，连续语音片段之间相隔20毫秒，即我们只有20ms时间在处理一段语音，而8个HARQ传输需要64ms（每个HARQ传输需要等8个子帧，即8ms才能收到A/N），对语音业务来说，这太长了。因此我们必须靠TTI捆绑来帮忙。

TTI bundling将HARQ传输捆绑在一起，其中每个HARQ传输占用1个TTI（1毫秒）。通常，TTI bundling会将4个HARQ传输捆绑在一起。这让我们能在20ms的AMR语音窗口内完成8个HARQ传输的处理。

因此，使用了TTIbundling和最大8个HARQ传输，我们就能够克服1个TTI内上行链路PUSCH信道的RB数从1提高到2所带来的对链路预算的不利影响。

当然TTIbundling也有局限：

1，  TTI bundling只适用于上行链路；

2，  当使用TTIbundling时，UE被限制为1个TTI内最多使用3个RB；

3，  TTI bundling时UE只能使用QPSK

4，  所有的无线承载（不仅仅是承载语音的数据无线承载）都必须使用TTI bundling；

正因如此，eNB需要有个判断标准为某个UE打开TTI bundling，比如这个UE处于小区边缘（SINR较差），且UE只使用语音业务（QCI=1）使得1个TTI内使用的RB数量增加了。