LTE网络数传流量问题分析定位与解决方案

1 前言

5G建网初期，LTE网络依然是运营商的主体运营网络，兼顾着大量数传流量业务和VOLTE语音业务的重任，而数传流量业务也是LTE网络最主要的业务，同时也是运营商的收入支柱，更是能引起用户感知的敏感区域。显然数传流量的质量，尤其是整个数传过程中发生的问题，也成了LTE网络的主要难题，因此对LTE网络数传流量问题的分析过程以及解决方案必然是优化人员研究的重点课题。该论文正是从潜在的速率影响因素着手直到对数传流量问题的总体定位分析，乃至UDP和TCP问题解决思路深入浅出的探讨，最后用实际案例的验证来完善了整个论文的研究过程。为现在及今后解决LTE数传流量问题的分析与处理方面，提供了完全可以借鉴的实战性参考价值。

2 LTE网络数传流量问题定位总体思路

2.1 LTE数传问题的影响因素

让我们更加直白的用因果关系分析图来说明LTE数传问题的影响因素，如图1所示。

图1 LTE数传问题影响因素图

2.2 LTE吞吐率异常概念及表现

吞吐率异常是指用户应用层或MAC层吞吐率偏低或存在较大波动，吞吐率波动可以从LTE测试工具吞吐率统计上直观的表示出来，分为定点TCP和定点UDP吞吐量异常。异常主要有两种表现；吞吐量波动大和偏低。TCP采用滑动窗口传输数据，故异常表现较多；包括吞吐量平稳但低于峰值5%以上、能达峰值且有“掉坑”，后又慢“爬坡”的现象或能达峰值而有“陡峭”现象，而UDP由于面向无连接、不保证可靠交付的传输特性，故异常表现平稳但达不到峰值。

2.2.1 LTE吞吐率正常与异常对比

理想情况下UE下行峰值吞吐量如图2所示，TCP流量异常“慢爬坡”及“掉坑”现象如图3所示。

图2 理想情况下UE下行峰值吞吐量

图3 TCP流量异常“慢爬坡”及“掉坑”现象

2.3 吞吐率问题总体定位思路及步骤

2.3.1 吞吐率问题判断总体思路

吞吐率问题总体判断思路分四步去判断：第一步判断问题范围是全网普遍，还是Top小区问题；第二步核查告警与参数，对影响吞吐率的基本因素进行逐个排查；第三步判断问题类型是由UDP的还是TCP引起的；第四步就是分段隔离判断，是“空口问题”还是“非空口问题”。

2.3.2 吞吐率问题判断通用步骤详解

通用步骤1：判断问题范围是否全网普遍问题。重点关注网络公用网元，取出整网原始话统数据，结合RB占用率、用户数和MCS分布来初步判定；如果是TOP小区问题，那么非Top小区公共网元可以直接排除，重点排查不同之处。

通用步骤2：核查告警及参数。从历史问题统计60%的网上性能问题都是由参数设置错误或者告警引起的,此步骤分3个核查动作：

① 核查动作1：外部事件及历史操作检 ；涉及到核心网方面是否增加或更改配置，传输方面涉及改造或割接、PIR和CIR等，基站方面核心参数是否发生修改、RB/DL grant分配不足、IBLER不收敛、MIMO/TM转换模式问题、RRU通道问题、CCE分配问题、功率参数问题、ICIC问题、调度算法问题、RANK问题等。

② 核查动作2：对核查出明显影响业务速率的告警，采取先闭环再分析最后消除的原则。分析告警时需注意速率变化时间和告警发生时间的关联及范围，内容如表1所示。

③ 核查动作3：参数核查优先分析无线网参数设置，必要时对其他参数也要进行核查，分为eNodeB参数（详见表2）和非eNodeB参数核查。

通用步骤3：判断该数传业务问题是由UDP还是TCP引起的，具体又细分3小步去判定：

① 第1步如果当前是TCP流量不足，则先用单线程UDP上/下行灌包“探路”，看UDP上/下行流量能否达到峰值，一般情况UDP与TCP流量都难达到峰值。如果UDP流量能达到峰值而TCP不能，显然问题原因将被锁定在TCP本身传输机制上。

② 第2步采用最简单的方法-UDP灌包来判定是否为UDP类问题，操作过程与判断方法如下：

【操作方法】采用iperf网络流量的检测工具，将iperf.exe分别放置在服务器的UE/PC的C盘根目录下，然后打开DOS窗口，输入cd C:，将当前路径调整到iperf所在的C盘下； 在接收方侧输入iperf-s-u-I 1，然后回车，表示建立起接受服务；在发送方侧输入iperf-c x.x.x.x -u-i 1 -b 100m –t 9999，其中-c x.x.x.x表示连接到该IP，-u表示灌UDP包，-i 1表示每秒显示一次灌包出口流量，-b 100m表示每秒灌100 Mbits的包。

表1 告警核查表

表2 eNodeB参数核查表

【判断方法】若吞吐率与TCP业务基本持平或者比TCP还低，则进入UDP类问题定位；若吞吐率明显大于TCP业务，则进入TCP类问题定位。

③ 第3步判断是否为TCP类问题的具体操作过程与判断方法如下：

【操作方法】在接收方建立接收服务器，输入命令iperf-s-I 1–w 512 k，其中–s表示建立接收服务器，-I 1表示每1秒显示一次接收到的流量，-w 512 k表示接收方的接收窗口是512 kbyte。与UDP的接收服务器相比，少了–u选项，在发送方输入命令iperf-c x.x.x.x–t 10 000–i 1 – w 512k，其中-c x.x.x.x表示连接到该IP，–t 10000表示灌包时长为1 000 m，–i 1表示每1秒显示一次灌包出口流量，–w 512 k表示发送方的接收窗口为512 Kbyte。两个操作过程都需注意发送方的灌包速率和持续时间，可以根据需要进行调整。

【判断方法】若吞吐率明显小于UDP业务，则进入TCP类问题定位。

通用步骤4：根据网元将数据业务分隔为空口问题与非空口问题去判断。

3 UDP流量问题定位

3.1 UDP流量问题定位总思路

UDP流量问题定位通常采用“追根溯源”法；即对服务器、eNodeB入口、空口、UE和PC进行逐点排查，看“水”流到哪里被“节流”，排查内容如图4所示。

图4 追根溯源法逐点排查图

3.1.1 服务器侧流量不足问题定位

【问题现象】：灌包出口流量比指定的灌包流量低。

【定位思路】：服务器侧流量不足可以从应用层输出流量不足和服务器限速两方面入手定位；前者可细化从Iperf工具的版本问题和配置参数错误定位，后者又可细化从网卡硬件能力不足、配置错误、防火墙限速、改包或截断定位。

【排查步骤】：①检查电脑性能、测试便携、服务器性能是否配置够高。短呼测试时，FTP服务器所用的操作系统，推荐使用Windows Vista、Linux内核2.6.19之后的版本。搬迁或升级前后的测试必须要使用相同的测试UE设备。②检查测试工具性能受限或进行了限速配置也会导致速率无法达到预期效果。③检查iperf灌包工具的版本及参数是否使用正确，UDP灌包最好使用Windows命令行1.7.0及以后版本的iperf。有的网卡对包长“敏感”，需要修改包长，看出口流量能否达到灌包设置值。

3.1.2 eNodeB入口流量不足问题定位

【问题现象】：MML命令DSP ETHPORT、DSP IPPATH或者在M2 000传输性能跟踪-IP Link Monitoring中，发现流量过低。

【排查思路】：eNodeB入口流量不足排查从传输链路上某个网元网卡限速或存在微波传输带宽受限及传输丢包3种情况考虑排查。

【排查步骤】：①检查传输链路带宽设置，确保整个链路中所有网元及接口全部为千兆级和自协商。②若传输侧用微波来传输数据，带宽需要大于空口峰值。③传输UDP丢包测试在核心网支持的情况下，可以使用UDP环回测试方式来测试S1传输状态。

3.1.3 空口问题定位

【问题现象】：在eNodeB入口流量充足的情况下，在UE侧接收到的流量却不足。

【排查思路】：具体排查思路从四个方面考虑；即空口质量差、话务及容量、通道/干扰及切换。

（1）空口质量差分析：空口信道质量是影响数传流量最明显的因素，可以通过BLER、RSRP、SINR等指标来衡量，具体排查分3步：第1步检查BLER时在M2 000上启动BLER监测，若BLER大于12%的话，会导致部分RB用于重传数据影响吞吐量，此时需改善无线环境；第2步检查RSRP、SINR值，只有小区RSRP值在-85 dBm以上，SINR值在26 dB以上，数传峰值测试中才可能实际峰值逼近理论峰值，若SINR值不正常，也需改善无线环境；第3步检查平均CQI、MCS；【话统】小区的平均CQI出现下降、上下行MCS出现下降、上下行MCS各阶比例出现明显变化等情况。

（2）话务及容量分析，如表4所示。

表4 话务/容量影响速率分析表

（3）通道/干扰分析：通道问题主要是小区通道不平衡，将会影响下行SINR，导致选阶异常影响流量。华为测试UE可以在PROBE上通过RSRP Measurement观察两天线接收功率是否平衡。M2 000后台可以打开RSSI相关测量项，获取小区RSSI话统数据，对比分析可发现小区通道不平衡问题。干扰主要是邻区干扰，严重时会极度影响数传吞吐量。它的现象是无论怎么调整天线，UE测出的SINR都极低而RSRP却极好。干扰又分内或外干扰；内干扰是PCI规划或RF配置不合理导致小区间干扰，造成MCS偏低，而外干扰会导致IBER偏高或MCS偏低。

（4）切换分析：切换分析只考虑路测，定点测试可以忽略。影响有；乒乓切换影响数传连续性、切换时延过大导致调度次数减少、切换不及时导致小区信道质量远低于邻区及UE实际SINR低、切换失败及异常等都会影响速率下降甚至业务中断。

3.1.4 UE无法数传问题定位

【问题现象】：无法进行UDP灌包，UE侧PC无流量。

【定位思路】：UE能够正常接入小区，说明信令面及传输物理链路正常，那么无法数传很可能是参数、软件设置错误、路由信息配置错误等原因引起。

【排查步骤】：首先保证UE能够正常接入后再检 以下参数；检查服务器侧有没有配回程路由、检查UE业务PC上的路由信息、检查电脑防火墙配置。然后在S1口信令中检查用户开户信息AMBR设置是否为0情况，此因也会出现能接入但无法数传的情况。最后检查商用终端对ROHC头压缩功能支持情况，如果不支持但eNodeB又开启了该功能，就会造成无法数传的现象，需将eNodeB的ROHC头压缩算法关闭。

4 TCP流量问题定位

4.1 TCP吞吐率影响因素

TCP吞吐率影响因素有峰值与均值两个方面：一方面TCP的峰值速率受通道带宽、发送窗口、RTT时延三个因素影响。TCP的峰值速率（bps）=窗口大小（bit）/RTT（s），在通道带宽不受限的情况下，发送窗口越大，RTT时延越小则TCP的速率越高。另一方面TCP的平均速率还与速率抖动及丢包有关。RTT时延抖动直接影响速率抖动。在TCP发送机制中，应用层丢包引起的发送窗口减半会影响吞吐率均值。TCP基本传输参数的配、空口或有线传输通道问题导致的 包和时延增加、UE和PC性能、防火墙设置等因素都是TCP吞吐率降低的主要原因。

4.2 TCP流量问题定位思路

TCP流量问题定位思路：确定UDP没有问题后，TCP问题需要根据具体情况分析；如果是吞吐量平稳但达不到峰值，则需要查看发送/接收窗口等相关参数设置是否合理及已优化，RTT是否过大；如果能达到峰值但是速率波动大，有掉坑现象，则需要检查是否有丢包、严重乱序、RTT波动等现象发生。

4.3 TCP速率波动大的原因分析

较常见的速率波动原因有TCP层丢包以及传输时延波动两种。TCP层丢包的原因可能是带宽拥塞，缓存超时或软件限制；有线传输中的交换机、路由器、核心网等都有带宽限制，速率超过门限后会发生丢包；在无线侧PDCP层为了保证不同业务等级的服务质量，有丢弃定时器Discard Timer，缓存的数据包在定时器超时之前仍未发走，则会被主动丢弃；另外防火墙、网卡设置等也可能引起丢包。

传输时延波动可能有空口BLER、空口调度周期、PC性能等原因。因为TCP用了双向传输，所有上行或下行的稳定及突发BLER都会引起时延波动；空口调度周期设置不合理会导致数据包或TCP ACK缓存，也会引起时延波动；另外发送方/接收方的电脑性能同样会影响应用层与TCP层数据包的递交时延，照样会引起时延波动。

4.3.1 TCP速率波动大原因分析检查步骤

第1步检查无线环境及参数：若UDP灌包没有问题，则观察空口上/下行BLER是否过高或有突变的现象，若有则先解决该问题后再做TCP业务；若无BLER过高或突变的问题，则通过命令将PDCP DiscordTimer改为无限长。在eNodeB LMT中输出命令LST STANDARDQCI和MOD RLCPDCPPARAGROUP将指定QCI等级的DiscardTimer改为无限长，然后UE重新接入后再做TCP业务，以避免PDCP DiscardTimer设置过小导致的丢包问题；若修改SR调度周期不能解决问题，则将上行设置为采用预调度或固定调度来做业务，看问题是否能解决。

第2步检查电脑配置：PC性能比不足会导致窗口收缩，检查PC性能确认满足配置要求、将UE PC以及服务器的防火墙关闭或者修改便携或服务器的TCP参数。

第3步检查各个网元端口协商：业务通道上的各个网元接口，eNodeB与传输设备，传输设备与SGW/PDN_GW、SGW/PDN-GW与Server都应该协商为1 000 M全双工。

第4步Wireshark抓包定位分析：A点抓包只需抓取包头100字节即可，一般命名局点名为：_UEPC.pcap；B点抓包如果实际组网环境有安全网关的话，B点抓包考虑到要能正确解密数据，必须要将IPSEC通道设置为空加密，同时抓包时必须抓完整的包，命名局点名为：_eNB.pcap，同时因该点数据量大，为防止占用内存过大，抓包保存时可使用多个文件，避免单个文件过大；C点抓包只需抓取包头150字节即可，命名局点名为：_UGW.pcap；D点抓包只需抓取包头100字节即可，命名局点名为：_Server.pcap。

5 案例

呼和浩特FHH-XX站点上下行速率异常问题定位解决过程

【现象描述】：对呼和浩特FHH-XX站点进行单站数传业务验证时，发现FTP上传/下载速率均比正常值偏低，上传峰值为2.3 Mbps左右，下载峰值为4.16 Mbps（呼和浩特目前单验速率要求为：下载速率大于45 Mbps；上行大于6 Mbps为达标值，统计时间均为30 s），据此初步判断为可能传输侧有问题。

【告警信息】：无

【原因分析】：根据处理流量定位问题的常规思路大体是：首先判断该数传业务是UDP的还是TCP的，如果当前是TCP流量不足，则先用单线程UDP上/下行灌包“探路”，看UDP上/下行流量能否达到峰值，此步骤是为了清理通道“小石头”；接着UDP流量问题定位采用“追根溯源”法，即从服务器到UE端到端的排查，看“水”流到哪里被“节流”了；最后如果UDP流量能够达到峰值而TCP不行，则将问题原因锁定TCP本身传输机制上。根据数据的流向，导致速率异常的故障原因可能包括；服务器数据源问题、PING存在时延或丢包、传输问题导致eNodeB入口流量不足、空口问题、UE PC侧问题、TCP参数和传输机制导致的问题。

【处理过程】：根据原因分析后实施对问题的逐步排查：第1步服务器数据源问题排查：经过更换数次服务器，低速率问题依然存在，至此服务器问题排除；第2步干扰问题排查：通过RSSI信令跟踪全带宽每个RB收到的干扰噪声强度，发现在-120 dbm左右，如果大于5 db以上，证明存在上行干扰，所以干扰问题排除；第3步ping业务排查：在后台PING测试，采用1 000字节的包，PING长度为100次，并未发现包存在时延抖动较大情况，而且显示丢包率为0.00%，说明PING业务正常；第4步UDP灌包测试：在进行UDP灌包测试的同时也需要进行后台流量监控，发现下行吞吐率稳定在60 Mbps，证明空口没有问题；第5步上行信道质量信息监测：在满足RSRP、SINR不同的条件要求下，才能保证UE获得的速率，测试上行RSRP是-108 dbm左右，上行SINR是21 dB左右，根据测试结果正常速率应该在8 Mbps以上，但实际上行流量仅为2.3 Mbps，说明上行业务速率受限；第6步信令分析：通过信令核查QCI等级标识当前为6，证明业务类型选择当前正常，丢包率低于百万分之一；第7步传输PTN问题排查：与传输侧相关人员核查相关参数配置后，显示均为不限速。经过一系列排查后问题的矛头只能指向了传输环，采取切断主隧道路由业务，倒用备用隧道路由进行业务承载，显示上行速率稳定在8 Mbps左右，下行速率稳定在53 Mbps左右，至此问题得以解决，也找到了问题根源。

【案例总结】：今后单验工作中如若出现速率异常等各类情况问题，可参照上述排查步骤进行处理。随着LTE网络用户递增的情况，因速率低而异常站点的问题可能会引起大面积用户投诉，所以单验过程除了处理好站点中、远速率问题以外，整个站点覆盖区域的速率问题更需关注。

6 总结

LTE网络数传流量问题处理起来虽然比较复杂，但是按照UDP还是TCP问题两大类来区分判断，问题再细化后逐个排查，各个难题也将会迎刃而解。对UDP问题可通过对服务器、eNodeB入口、空口、UE和PC等采用逐点排查手法去处理，同时重点关注传输丢包和空口干扰问题。而TCP问题重点应关注空口或有线传输通道、TCP窗口配、UE和PC性能、包和时延增加、防火墙设 等问题去分析处理。随着LTE数据业务的“井喷”时期，业务速率问题的判断、定位与处理工作会越来越多，但是只要找准思路、方法正确，办法总能把问题解决。