UE切换后出现上行断流问题分析

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切换后不出现断流