应用分层技术分析定位接入层上行调度问题

杨宇晨

福建省厦门市思明区筼筜街道莲岳社区，福建厦门，361001

0 引言

随着智能终端的普及化、功能的完善化，移动互联网迅猛发展，用户对于移动业务体验的要求越来越高。与此同时，移动网络结构日趋复杂，网络场景多样化，影响用户体验的因素越来越难以判断。传统的KPI指标已经不能反映出用户业务过程的感知体验，如何快速定位网络问题、提升用户业务感知是当前网络优化中面临的一个难题。本文结合现网用户感知问题，介绍了如何利用wicap、qxdm及基站TTI抓包等多种分析手段，快速定位LTE基站的不正常调度问题的根因，最后通过对无线侧调度参数的优化，使得用户的业务感知得到大幅改善。

1 问题现象

某地市运营商自3月底开始，出现较多用户投诉，内容为“4G信号正常，但用户打开网页慢，加载图片慢”，截至4月底共收到100多单相关的投诉单。

投诉终端中苹果、安卓手机都有。投诉点所占用的基站状态、KPI指标正常，现场测试RSRP良好、SINR良好、FTP上传下载速率正常，ping时延正常。但在打开淘宝网页、刷微信朋友圈的时候，会频繁出现加载等待时延过长现象，尤其是微信语音上传出现较为明显的延迟和超时情况，严重影响用户感知[1]。

2 问题分析

2.1 投诉小区KPI、KQI分析

选取投诉较为集中的JK中心-1进行KPI，KQI分析发现，小区KPI及KQI均较为正常，三次握手及页面响应时延也在正常范围内。

2.2 投诉小区现场测试

现场优化人员到投诉站点测试，现场覆盖良好，RSRP为-65dbm、SINR在20以上，下载峰值速率111M，上传峰值速率65M，但是终端发微信语音、连接淘宝APP等均有很大概率出现延迟现象，与用户投诉现象一致。

2.3 手机抓包分析

通过手机用wicap以及高通工具qxdm同时进行抓包分析。从wicap抓包看到手机TCP层从11∶26∶21.897开始到11∶26∶25.283这段时间里，手机应用层连续发了8个1300byte的IP包以及一个932byte的IP包。

我们再从高通工具qxdm抓包打开PDCP层的消息看到从583-7号子桢到922-6号子桢这3.389秒（时间与图1用wicap抓包的时间吻合）内，PDCP层共发出了4个1300byte大小的IP包，以及一个932byte大小的IP包（见图2）。

图1 wicap 抓包

图2 PDCP 层消息

也就是说，从系统帧583-7到922-6这段时间内，应用层一共发了8个1300byte大小的IP包，而PDCP层只发出了4个，被PDCP层丢弃了4个。且PDCP层从发出第一个到发出第二个间隔了3.289秒。是什么原因造成了PDCP层发送这个IP包用了这么长时间？我们继续打开RLC层消息进行分析（图3）。

图3 RLC 层消息

从图3RLC层上行消息包看到来自PDCP层的字节，RLC层将其一共分成26个SDU进行分段传输，直至904-7号子帧才将这个IP包传完，历时3.210秒，且每个pdu字节数都比较小，最大仅118个字节[2]。我们继续打开MAC层消息查看eNodeB是怎么调度的（图4）。

图4 MAC 层消息

从图4MAC层上行消息看到手机在583-7的BSR消息中请求调度字节数为2915字节，而enodeb给的授权字节数一直未能满足手机需要发送的IP包的大小，因此RLC层不得不将消息包分成26个SDU进行传输。且期间存在较长时间不调度，导致第一个1300byte的IP包就发送了3.210秒，手机上看到的现象就是转圈转了3～4秒后才将消息发出。

3 手机抓包分析结论

从以上分析可以初步判断，eNodeB的上行调度存在问题，即终端首次发送SR请求后，eNodeB对BSR调度字节数小，且存在较长时间不连续调度，导致时延较大。而同时基站也存在较多无效调度，浪费了大量的空口资源。

UE通过SR告诉eNodeB是否需要上行资源以便用于UL-SCH传输，但并不会告诉eNodeB有多少上行数据需要发送（而是通过BSR上报的），UE要求被调度的缓冲区状态报告（BSR）置于控制信息单元，一个MAC PDU最多只能包含一个MAC BSR控制信息单元，并在共享信道上发送。

eNodeB收到SR后，给UE分配多少上行资源取决于eNodeB的实现，通常的做法是至少分配足够大于UE发送BSR的资源，如果用不满则用空的padding字节填充。上行数据的传输需要的资源是通过BSR来获得[3]。

BSR携带的是个索引值，它与实际字节大小的对应关系为：index=0表示某个逻辑信道组没有数据需要发送，index=63表示某个逻辑信道组有超过150K字节的数据需要发送。当UE有30个字节的数据需要发送时，只需要将BSR控制单元的值填为8。网络侧在解码BSR信息后，发现BSR的值等于8，就知道UE侧需要发送的数据量在26～31字节之间，为eNB给UE分配合适大小的资源提供了参考依据。

需要注意的是，这里并不意味着网侧就会给UE分配26个字节或31个字节对应的资源，UE也不能做类似的假定。因为网侧在收到BSR后，有可能只会分配极少数量的资源，比如这个例子中，网侧可能只会分配10个字节的资源给UE，而不是26个字节也不是31个字节，甚至很多时候，网侧在收到BSR后，并不会给该UE分配任何的上行资源。网侧如何给某个UE分配资源，是由设备厂家的算法决定的，UE不会也不应该对资源申请的结果做特定大小的假设[4]。

4 问题解决

4.1 基站侧TTI抓包分析

我们在Airscale站型收取问题小区的TTI trace，可以发现和手机侧抓包相印证，调度不连续，且初始的调度MCS偏小，所以TBS小，调度的数据量也少。部分时段，基站存在不连续调度。

4.2 调度参数调整测试

至此，时延问题基本确认为上行调度问题，我们对airscale基站的几个调度参数进行各种组合测试（图5）。

图5 优化参数

（1）默认参数下修改 iniMcsDl / iniMcsUl和iniPrbsUl 3个到优化值，测试微信语音秒发，结果ok。

（2）默认参数下只修改参数 iniUlMcs到优化值，测试故障现象依旧，结果nok。

（3）默认参数下只修改 iniUlMcs和iniPrbsUl到优化值，测试微信语音秒发，结果ok。

（4）默认参数下只修改 iniPrbsUl到优化值，测试微信语音秒发，结果ok。也验证了初始grant较小的问题。

（5）默认参数下只将ulsFdPrbAssignAl修改成mixeFD，测试故障现象依旧，结果nok。

4.3 优化实施

基于以上测试结论，与现网FSMF站型进行参数对齐，从优化的角度出发，建议将上述几个参数优化同时实施。对问题小区进行参数优化后，观察修改后的Airscale小区，KPI、KQI正常，尤其是上行流量相当的情况下，上行PRB利用率下降、系统负荷降低，经分析验证是因为上行调度正常后TCP重传减少了。同时，优化小区的三次握手时延下降显著。

4.4 结论

该厂商airscale站型iniPrbUl（初始的上行最大PRB）设置为1时，会导致初始调度有上行调度不响应的情况，因为上行初始化的PRB太小了，不满足UE的BSR请求的数据包的大小，按照通常的调度机制应该是eNodeB至少分配足够大于UE发送BSR的资源。预调度的开启有利于降低LTE系统时延，同时也会引起额外的RB资源消耗，建议在上行PRB利用率不高的情况下适度开启。

5 结语

本文从用户感知问题出发，创新应用wicap、qxdm及基站TTI抓包分析，快速定位LTE基站调度存在的问题。通过对上行调度机制的研究，提出对上行调度参数优化的方案。这种抽丝剥茧、分层分析的方法，在移动通信用户感知问题优化中具有普适性和参考意义。