通信人家园

标题: 为什么VoLTE需要TTI捆绑？ [查看完整版帖子] [打印本页]

时间: 2016-7-18 10:18

作者: donnar 标题: 为什么VoLTE需要TTI捆绑？

本帖最后由 donnar 于 2016-7-18 10:22 编辑

通常，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数量增加了。

附件: 无标题.jpg (2016-7-18 10:17, 54.78 KB) / 下载次数 0
https://www.txrjy.com/forum.php?mod=attachment&aid=MjkyMzQ3fDM5MjM5ZmZkfDE3MzMwMjQ4NjR8MHww

时间: 2016-7-18 17:41

作者: nick13371

很清楚! 感謝樓主

时间: 2016-7-28 15:28

作者: 沐雨有事

TTI BUNDLING只能使用有小区边缘信号差的区域，语音时才用。其它的最好不要用。

通信人家园 (https://www.txrjy.com/)