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

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20180908G0ZBCF00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券