大唐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属性)对用户感知有影响。
上行或下行签约速率低,会限制最大传输速率,影响用户感知。