1
问题现象
局方在路测拉网中发现使用小文件上传,会几率出现UE切换后上行断流问题。基站版本为V4.16.10.20P50(单模对应V3.40.20.10P70),该问题影响路测拉网的上行小文件下载成功率和10s上传的速率。
在UE和服务器抓包的结果如下图所示,可以明显看到切换后,UE侧发送了大量的数据,但是在服务器侧是没有收到这些数据的。
图1 UE和服务器侧抓包结果
2
问题定位
1. 信令分析
分析路测信令,切换未发生失败。
2. 路测log分析
分析路测log,可以发现断流出现有一定的概率,如下图所示,4次切换中,RSRP和SINR都比较好,不可能因为覆盖问题导致断流。另外查看129->340两次切换,第一次切换后速率影响不大,而第二次切换后速率直接掉0:
图2UE侧log分析
由于问题和切换强相关,而且目标侧小区不会固定在某个站点出现,所以可以排除和传输相关。
更换终端(局方使用XZ2手机测试)为XZP也同样会复现,但是更换到MF980终端,问题不复现。所以问题可能和基站/终端之间兼容有关。
抓取基站log,分析发现用户大于切换后PDCP SN跳变,如下图所示:
图3 基站抓包发现切换后PDCP SN跳变
同时,log中也明显发现切换后基站收到的UE的报文都落在了PDCP窗口之外,导致被丢弃。
图4 切换后的报文都落在了PDCP窗口之外
查看目前基站对UE的切换配置中携带了fullconfig开关:
图5 UE的切换配置中携带了fullconfig开关
也就是要求UE在切换后,UE发送的PDCP SN序号要再从0开始,如下是UE的PDCP头,SN序号从第5位开始共12bit:
图6 PDCP数据PDU格式
如下是如果切换收到了fullconfig开关,一般终端回在切换后重置UE的PDCP SN号,UE发送的PDCP SN号会重置为:
图7 fullconfig开关打开后正常切换后PDCP SN从开始
3
分析结论
目前基站在配置UE fullconfig之后,要求UE发送的PDCP SN初始化为0,但是对比局方测试的XZ2和XZP终端,在基站配置UE fullconfig之后,UE切换后第一包PDCP SN号为0x59C,导致基站PDCP的reordering_window的起始位置移动到0x59C,而随后收到的PDCP SN(001,002…)都在reordering_window的起始位置之前,就全部被基站丢弃,不会投递到服务器。
图8切换后UE的PDCP SN不从开始
图9 PDCP SN重排序窗口示例
查看log,发现XZ2/XZP手机每次切换后第一个PDCP SN号都不对,但是为何不是每次切换都断流。研发确认原因如下:
目前的PDCP SN的范围是0~4095(12bit),reordering_window大小为2048,如果切换后UE第一个PDCP SN号+ reordering_window大小>4096,则这一包丢弃,随后一包(001)作为reordering_window的起始位置,因此不会断流。如下是统计的是否断流和切换后第一个PDCP SN的关系表,其中满足PDCP SN+ reordering_window
图10 是否断流和切换后第一个PDCP SN的关系表
可以看到基本符合预期,但是其中标黄的两次虽然满足PDCP SN+ reordering_window
4
解决方法
基站侧修改PDCP的处理方式,修改后即使UE切换后第一个 PDCP SN不为0,如下图所示为 0x6AA,
切换后也不会断流.
图11 UE切换后第一个 PDCP SN 是 0x6AA
图12切换后不出现断流
领取专属 10元无门槛券
私享最新 技术干货