大唐TD数据业务时延优化.docx
《大唐TD数据业务时延优化.docx》由会员分享，可在线阅读，更多相关《大唐TD数据业务时延优化.docx（13页珍藏版）》请在冰点文库上搜索。
大唐TD数据业务时延优化
基于4A4B数据业务时延优化
大唐移动
1.概述
XX移动2013年开展数据业务端到端优化专题，领导投诉打开网页时延大，用户感知不好。
为此，核心网、无线侧开展测试分析，以减小时延，提升用户感知。
2.问题现象
2.1.Ping包时延长
据了解，大唐TD时延随着数据包长度的增长会急剧增长，华为（平凉）增长不明显。
服务器
包长
大唐TD时延
华为TD时延
XX服务器
128
211.47
219.00
512
441.76
300.00
1024
696.48
314.00
2.2.打开新浪网页时延长
使用搜狗浏览器（可记录时间），打开新浪主页，统计结果如下：
忙时
45-55秒
闲时
27-31秒
2.3.FTP下载时间长
使用FlashFXP下载8M文件，统计下载速率和时间如下：
忙时
727.5kbps
99秒
闲时
923.1kbps
76秒
3.问题分析
3.1.核心网侧分析结果
3.1.1.核心网侧存在极少量丢包
从测试业务看，互联网业务（包括新浪浏览、互联网下载）核心网存在偶尔丢包情况，而FTP下载过程中未发现丢包情况现象。
整体丢包比例在0.1%以下。
从终端时延感知分析，由于核心网丢包后，通过无线侧传递到终端后，终端再上发重传请求，再通过核心网上发服务器，这一过程相对耗时较长，不利于用户感知。
3.1.2.核心网侧存在少量乱序
在页面访问和互联网下载中，核心网侧下发的TCP数据乱序，导致终端收到的TCP层数据乱序。
但由于乱序的数据包时间间隔小，需要终端连续3次DupACK引发快速重传或超时重传，所以乱序导致的重传很少发生，对时延影响较小。
3.1.3.核心网存在少量数据分片
数据在通过SGSN传输后，存在IP数据再次分片的现象，不利于传输效率的提升，对时延有较小的影响。
通过Iu接口部分数据统计，粗略分析分片数据占整体业务数据约4.3%。
前期核心网侧通过修改防火墙的MSS值，已经对TCP协议的分片做了很大程度优化，从14％左右的分片率降低到2％左右，但是无法解决UDP协议的分片，如果想减小UDP协议报文分片，需要修改全网SGSN、GGSN、交换机、防火墙的MTU值，这个操作涉及范围太大，对网络影响非常大，因此不建议进行修改。
3.1.4.业务平台下发数据有延迟
在页面访问和无线音乐业务测试中，发现终端上发GET请求并收到ACK确认后，SP服务器过了较长时间才开始下发数据，造成时延大，感知不好。
从打开新浪页面的响应时延统计（即HTTP的200OK响应消息到GET请求消息之间的时长），大部分时延在60-80ms，但有近3%的请求响应时延大于200ms，个别请求响应时延大于1秒。
但该问题涉及服务器厂家，仅核心网优化还无法解决。
3.1.5.其它优化建议
利用缓存加速设备，对于一些热门网站的页面整体进行缓存，避免终端与服务器的直接交互，加快请求-响应的回复时间，提高用户感知。
从信令流程看，访问网页过程中，初始数据包传输量较少，要经过两次或三次的终端确认消息，服务器才能逐渐加大每次数据量的下发。
而页面访问中，存在很多小容量的页面内容，一次完整下发可以有效减少由于交互确认产生的延时。
根据现有网元，尝试增加TCP初始传输，增加初始数据的数据量。
3.2.无线侧分析结果
3.2.1.空口物理层上行存在误块
RNC的FP层收到NodeB对等层的QE218和CRCI校验错误，导致重传，影响时延。
QE218是由于NodeB物理层数据接收不全，导致无法正确译码或误块。
分析发现NodeB侧没有收到终端的有效信号，终端没有发送数据。
并非所有的QE218都会导致重传，但含有有效数据的QE218会导致上行重传，影响时延。
通过对CRCI校验错误时的log分析，NodeB让终端上调发送功率，但是终端侧上调不明显，从而NodeB接收到的信号功率过弱，产生CRCI校验错误，无法正确译码数据，导致上行重传，影响时延。
3.2.2.空口物理层下行存在译码错误
空口下行丢包或终端物理层的译码错误，导致重传。
重传较多时，对时延影响较大。
RNC的RLC层下发的数据，经过NodeB的物理层，到达终端的物理层后，终端给NodeB反馈译码错误，要求重传。
NodeB重传了4次，终端仍然反馈译码错误，导致上层RNC的RLC层重传。
通过分析发现，RNC侧RLC层重传了一次或多次后，终端才正确接收。
重传次数越多，时延越大。
重传的数据量越多，时延越大。
3.2.3.TCP层的丢包、乱序、重传
通过Wireshark分析发现，TCP层存在丢包、乱序、重传现象，对时延影响较大。
分析发现，TCP层的丢包和乱序，有两个原因：
1.核心网侧的丢包和乱序；
2.空口物理层的丢包和译码错误导致的TCP层丢包、乱序；
TCP层的丢包需要TCP层的重传。
空口问题导致TCP乱序次数多、量大时也导致TCP层的重传，影响时延。
3.2.4.无线侧参数配置不合理
FTP下载速率一般在720kbps左右。
分析信令过程，发现：
1.FTP下载开始前，RNC给终端分配的上行速率是32kbps，在FTP下载开始很短的时间内，终端上报4B测量报告，RNC将终端上行调整为16kbps，上行速率不升反降。
而上行速率低会影响下行速率。
2.FTP下载过程中，上行速率一直在16kbps左右。
根据以往测试经验，上行16kbps时FTP下载速率一般在700kbps左右。
如果要减小时延，提升用户感知，需要调整无线参数，保证并提高FTP下载过程中的上行速率。
同时，参考我司南京TD网络打开网页优化经验，需要调整无线侧参数进行验证测试，主要是上下行上调档数和速率、4A和4B测量报告门限和定时器等。
3.3.无线参数调整验证
参照我司南京TD网络前期的打开网页优化经验，调整如下参数：
参数名称
修改后的值
参数含义
当前配置的解释
一、二、三类业务4A事件门限
8k－128
32k－256
64k－512
终端侧缓冲区中数据量大于该门限时，终端会触发4A测量报告过程
单位：
字节
降低4A测量报告门限、减少触发时间，使得业务量大时，更容易满足4A测量报告门限，触发上调，缩短时延，提升感知
当前配置：
当终端是32kbps速率，终端缓冲区在200毫秒内都大于256字节时，终端会发送4A测量报告，请求RNC上调上行速率；
当终端是64kbps速率，终端缓冲区在200毫秒内都大于512字节时，终端会发送4A测量报告，请求RNC上调上行速率；
终端上报了4A测量报告后，16秒内不会再次发送4A测量报告，避免频繁调整
一、二、三类业务4A触发时间
32k－200
64k－200
终端侧缓冲区中数据量大于上述门限，并在在该触发时间内，一直都大于上述门限时，终端就发送4A测量报告
单位：
毫秒
一、二、三类业务4A事件滞后时间
32k－16000
64k－16000
终端侧发送了4A测量报告后，在该定时器间隔内，不会再上报4A测量报告；
单位：
毫秒
一、二、三类业务4B事件门限
32k－128
64k－128
终端侧缓冲区中数据量小于该门限时，终端会触发4B测量报告过程
单位：
字节
降低4B测量报告门限、增加了触发时间，使得更不容易满足4B测量报告门限，尽在真正的业务量小时，才触发发送4B测量报告，触发下调，避免降速，提升感知
当前配置：
当终端是32kbps速率，终端缓冲区在5000毫秒内都小于128字节时，终端会发送4B测量报告，请求RNC下调上行速率；
当终端是64kbps速率，终端缓冲区在5000毫秒内都小于128字节时，终端会发送4B测量报告，请求RNC下调上行速率；
终端上报了4B测量报告后，16秒内不会再次发送4B测量报告，避免频繁调整
一、二、三类业务4B事件触发时间
8k－5000
32k－5000
64k－5000
终端侧缓冲区中数据量小于上述门限，并在在该触发时间内，一直都小于上述门限时，终端就发送4B测量报告
单位：
毫秒
一、二、三类业务4B事件滞后时间
32k－16000
64k－16000
终端侧发送了4B测量报告后，在该定时器间隔内，不会再上报4B测量报告；
单位：
毫秒
PS速率上调档数1
128k
上行上调时，上行速率
当前配置：
128kbps，即：
当终端上报了4A，RNC给终端上行上调速率时，首选128kbps；如果128kbps的资源不够，RNC会尝试上行64kbps的速率；
PS速率下调档数2
64k，32k
上行下调时，上行速率
当前配置：
下调分2档，当终端在128kbps速率下，上报了4B测量报告，RNC给终端上行下调速率时，会降到64kbps；如果在64kbps速率下上报4B，RNC给终端上行下调速率时，会降到32kbps；
48k和96k背景类和交互类配置标志属性
增强配置
3.4.本次对比分析
上述参数修改后，测试发现时延和感知有明显改善。
3.4.1.Ping包测试结果
Ping包大小
修改前（单位：
毫秒）
修改后（单位：
毫秒）
128字节
208-261
188-200
512字节
297-418
220-297
1024字节
443-707
256-261
分析总结
根据测试、分析，ping包时延与以下4个因素有关：
1.ping包的大小：
ping的包越小，传输时间越少，时延就越小；
2.ping包时的上行速率：
上行速率越大，传输时间越少，时延就越小；
3.ping包时的操作过程和网络参数配置：
ping包慢时，终端上报了4B测量报告，网络侧调整了4A测量报告门限（8K的触发时间没有修改，是640ms），导致终端后续没有满足4A测量报告标准，没有上调上行速率。
后续，建议将8K业务的触发时间也修改为200ms。
4.测试设备的差异性：
同样条件下，不同PC+数据卡（性能等），对4A测量报告标准的满足程度不同，导致上行升速或者没有升速，从而时延不同；
5.个别时延较大的突发点，与空口质量或终端有关：
下行有丢包或物理层译码错误、上行有QE218和CRCI校验错误。
下行有重传，基站侧下发数据后终端反馈要求重传，反复4次后会产生丢包。
可以认为是偶尔的空口环境导致的数据译错从而反馈要求重传。
上行有QE218和CRCI校验错误，基站侧要求终端上调功率，但是终端侧偶尔上调不明显，发送功率过小导致。
3.4.2.打开新浪网页测试结果
修改后（单位：
秒）
修改前（单位：
秒）
忙时
19-33
45-58
闲时
15-19
27-38
分析总结
根据测试、分析，打开网页与以下2个因素有关：
1.上行速率：
打开新浪主页过程中，由于TCP连接多（在200个以上），TCP上行数据量大，通过无线侧网络参数优化，让终端尽可能快速地使用上行空闲资源，以提高上行速率，如从原来的64K调整为128K，对时延改善约在12-30秒左右。
2.与空口环境有关：
分析时延较大的测试log，偶尔出现的大时延情况，发现与空口环境导致的终端物理层译码错误引起的丢包重传有关。
3.个别终端时延受限，与SIM卡的下行签约速率低有关。
3.4.3.FTP下载测试结果
修改后
修改前
忙时
965.5kbps
727.5kbps
闲时
1.326Mbps
923.1kbps
分析总结
根据测试、分析，FTP与以下2个因素有关：
1.上行速率：
根据测试经验，上行速率与FTP下载速率的关系如下：
上行业务
下载速率
16K
720kbps
32K
1.08Mbps
128K
1.32Mbps
2.SIM卡的上下行签约速率：
下载速率不能超过签约的上行和下行速率。
如果签约的下行速率太小，比如384K，将导致实际下载速率不会超过384kbps。
3.4.4.打开手机新浪测试结果
修改后（单位：
秒）
修改前（单位：
秒）
忙时
4.30
5.25
闲时
2.91
5.23
3.4.5.打开手机搜狐测试结果
修改后（单位：
秒）
修改前（单位：
秒）
忙时
2.91
3.65
闲时
1.79
2.95
3.5.对网络KPI的影响分析
2013年3月20日（星期三）晚上19:
00左右，进行了上述参数修改。
修改前后一周内RNC941的KPI指标如下：
可以看出，各项KPI指标正常。
后续还需要继续观察KPI指标。
3.6.对网络容量的影响分析
通过调整上调/下调档、4A/4B测量报告门限，让终端尽快使用网络空闲资源。
当有其它用户接入时，如果空闲资源不足，或者没有空闲资源，RNC会通过抢占算法，对原有用户进行业务降速，留出资源，然后再接入新用户。
因此，此次参数调整对网络的容量没有影响。
3.7.空口错误及重传分析
参数修改前后，各项业务的空口下行重传和上行的QE218、CRCI校验错误统计如下：
业务类型及场景
Ping包
访问页面
FTP下载
修改前
修改后
修改前
修改后
修改前
修改后
空口下行重传
0.00%
3.25%
0.76%
0.46%
0.50%
0.30%
空口上行QE218、CRCI校验错误
0.38%
1.47%
1.89%
0.52%
2.09%
0.71%
可以看出，参数修改后，页面访问和FTP下载业务，空口下行的重传比例、空口上行的QE218、CRCI校验错误的比例，均有所下降，在时延方面有改善。
但ping包测试并没有改善，而且在参数修改后，几次ping包测试的情况如下：
次序
空口下行重传
空口上行QE218、CRCI校验错误
1
4.50%
1.90%
2
0.34%
1.38%
3
8.77%
0.00%
4
3.49%
2.04%
5
0.00%
0.00%
6
0.68%
2.72%
7
0.00%
0.82%
由上表统计可以看出，即使在参数修改后，ping包的下行重传和上行QE218、CRCI错误比例还是没有规律。
为了进一步分析该问题，已于2013年3月25日晚使用联芯8310终端进行了RNC、NodeB、终端的同时抓包，后续联合分析。
3.8.主要成果
通过本次专题工作，主要取得了一下成果：
1.提升了各项业务的PS时延，提升了用户感知；
业务类型及场景
修改后
修改前
提升率
Ping128字节的包
188ms
208ms
9.6%
Ping512字节的包
220ms
297ms
25.9%
Ping1024字节的包
256ms
443ms
42.2%
新浪主页访问（忙时）
33s
58s
43.1%
新浪主页访问（闲时）
19s
38s
50.0%
FTP下载速率（忙时）
965.5kbps
727.5kbps
32.5%
FTP下载速率（闲时）
1.326Mbps
923.1kbps
43.6%
手机新浪主页访问
3.47s
5.24s
33.7%
手机搜狐主页访问
2.19s
3.26s
32.8%
2.对各项业务，总结出了影响时延的各种因素，认识了问题，便于今后的推广和测试分析；
4.分析结论
1.通过RNC侧信令面、用户面、NodeB抓包分析，可以得出ping包、网页打开、FTP时延大主要因为上行速率受限导致。
不同的上行速率（16K、32K、64K、128K）对时延和用户感知影响较大。
2.由于PS上调和下调档位以及4A、4B的门限和触发时间等参数的设置需要平衡资源、KPI和用户的感知。
尤其是容量受限时，要收紧4A、4B的门限，保证网络容量，但此时用户感知会差一些。
3.终端的差异性对时延也有突发影响。
测试分析发现中兴MC315上网卡的RLC层连续2次没有收到TCP层的GET消息，导致该TCP连接延时增大了8秒多。
4.个别时延较大的突发点，与空口质量或终端有关：
下行有丢包或物理层译码错误、上行有QE218和CRCI校验错误。
5.SIM卡的签约属性（业务QoS属性）对用户感知有影响。
上行或下行签约速率低，会限制最大传输速率，影响用户感知。
升级会员 