基站对TA调整值的处理漏洞导致RTP严重丢包异常案例
2019年10月
目 录
一、 二、 三、 四、
第1页, 共8页
问题描述 ................................................................................................................... 2 分析过程 ................................................................................................................... 2 解决措施 ................................................................................................................... 7 经验总结 ................................................................................................................... 8
【摘要】广州中兴区域某宏站小区RTP严重丢包，UE在较短的一段时间内多次成功收到大小相近的TA调整命令，最终导致UE的上行TA调整出错，上行链路性能恶化，基站收不到UE发来的PUSCH上的语音数据，使得语音数据RTP丢包严重。通过修改TA调整维护代码，对下行PDSCH的HARQfail做进一步判断，当该HARQfail属于上述“假HARQfail”时，需要将历史值清空为初始值，来保证实际上已经传输成功的TA调整值不在参与TA值计算。通过这种保护，可以解决该问题。 【关键字】RTP丢包、TA调整、 【业务类别】丢包率优化
一、 问题描述
广州中兴区域某宏站小区RTP严重丢包，分析UE LOG时发现，UE在较短的一段时间内多次成功收到大小相近的TA调整命令，最终导致UE的上行TA调整出错，上行链路性能恶化，基站收不到UE发来的PUSCH上的语音数据，使得语音数据RTP丢包严重。上行链路NI高（如达到-90dBm）会较容易导致该问题发生，UE反馈的带TA的PDSCH的ACK基站没有解对，且对应的所有重传的PDSCH的ACK基站也没有解对。一旦进入TA调偏，就进入了一个恶性循环，这个问题就会出现。
二、 分析过程
广州VoLTE定点测试中，发现终端在某宏站小区下，RTP严重丢包。
问题复现：为了排查问题，用MATE 10终端连接QXDM按三方测试规范进行测试抓LOG，再次复现了UE的RTP丢包问题，情况说明如下：
1. 4_0414-144954896_source_1.MDM:
source1有TA连续下发，source2接收端看丢包率69% 2. 4_0414-144954896_source_2.MDM:
source2有TA连续下发，source1接收端看丢包率48% 3. 2_0414-141339280_source_1.MDM:
source1有TA连续下发，source2接收端看丢包率74%
进一步分析UE log发现UE在较短的一段时间内多次成功收到大小相近的TA调整命令，最
第2页, 共8页
终导致UE的上行TA调整出错，上行链路性能恶化，但是此时TAT定时器没有超时，导致上行链路的PUSCH、PUCCH和SRS发射时间调整出错。基站在PUSCH上收不到UE发来的语音数据，在PUCCH或PUSCH上也不能正确收到PDSCH的ACK/NACK反馈，最终导致语音数据大量丢包。
如附图一所示，是PDSCH的MAC数据组包情况。其中，“SFN”是系统帧号，“Sub-FN”是子帧号，“HARQID”表示HARQ进程号，“TA Val”是TAC MAC CE中携带的TA调整量大小，单位是16Ts。
从附图一可以看出，从帧号28子帧号6到帧号188子帧号6这段时间UE间隔约50ms就会收到一次TA调整命令。
附图一：UE连续收到PDSCH的携带的TA调整命令:
第3页, 共8页
从附图二可以看到，UE在收到一次新传后，尽管已经解对，但是仍然会收到3次重传。PDSCH的新传和对应的重传一定是在同一个HARQ进程；如果某一个子帧的PDSCH数据是重传，则它的NDI必然和相同HARQ进程之前的传输一致，如果是新传，则NDI会翻转（0变为1，或者1变为0）；重传和新传的“TB size“一样。从附图一中可以看出，HARQID=6的进程中，帧号FrameNum（或SFN）=28，子帧号SubframeNum（或Sub-FN）=6的PDSCH带了TA调整值（”Relative TA Val（16xTs）“有数据），此时UE的”CRC Result“是”Pass“，表示UE成功收到了该PDSCH的数据。然后，帧号29子帧号6，帧号30子帧号6和帧号31子帧号6的PDSCH同样属于
第4页, 共8页
HARQID=6的进程中，且”NDI“值没有变，都是1，可见这两个PDSCH子帧是帧号28子帧号6的PDSCH的重传。这3个重传UE都成功收到，且”Discard reTx Present“是None，表示UE认为对应的PDSCH数据是新传。这种情况下，UE只会使用新传对应的数据，即使用新传的TA调整值去调整UE的上行信道发射时间。同时，基站会认为这种情况属于PDSCH的HARQfail，即PDSCH传输失败。
附图二：UE连续收到PDSCH的重传:
从附图一和附图二可知，在从帧号28子帧号6到帧号188子帧号6的1600ms内，UE不断收到TA调整命令，这段时间UE的TA累积调整值是53*16Ts=848Ts，这个时间远远超出了CP的长度（144Ts），会导致上行链路（PUSCH、PUCCH和SRS）的接收性能急剧恶化。
从附图三可知，此时UE在PUSCH上，尽管授权量“PUSCH TB”很小（只有9bytes），但是还是有大量的传输次数达到4次（“Re-txIndex”为Fourth）。上行最大传输次数是4，说明此时UE测看已经HARQfail，即UE发给基站的PUSCH基站始终收不到，这会导致RTP丢包严重。
第5页, 共8页
相关推荐：
loading