防城港移动ATU测试下载速率低问题分析报告(终稿)20120508

1、防城港移动ATU测试下载速率低问题分析 中国移动防城港分公司2012年05月05日目 录第1章 背景31.1 问题背景31.2 组网图3第2章 分析过程42.1 分析思路42.2 时间段分析一62.2.1 SGSN侧分析62.2.2 RNC侧分析82.2.3 终端侧分析102.3 时间段分析二112.3.1 SGSN侧分析112.3.2 RNC侧分析132.3.3 终端侧分析152.4 时间段分析三162.4.1 SGSN侧分析162.4.2 RNC侧分析172.4.3 终端侧分析192.5 集中分析20第3章 分析总结23第1章 背景1.1 问题背景广西防城港移动分公司ATU测试下载速率不稳定，4月9日和4月23日集团测试均出现速率低于600 kb/s的情况，测试结果未能达标，下图为防城港移动分公司历次测试结果，区公司、防城港市公司、以及华为协同进行该问题处理，华为公司拉通网优、无线、核心网、数通工程师及公司研发，成立联合专项处理小组，逐段进行问题的排查定位。1.2 组网图第2章 分析过程2.1 分析思路 重点分析4月23日白天ATU测试速率低各接口跟踪的信令消息，解析TCP层报文，

2、端到端的分析，逐段排查定位。 下图为4月23日白天忙时ATU测试下载速率变化图，刚开始下载速率仍正常，后续持续的速率低，波动软大，甚至存在掉0情况，本文选取三个典型异常点进行分析（详细速率变化请查看附件）：2.2 下载速率正常时段 09：51至09：55时间段下载速率1.2M以上，分析异常时间段前先了解一下速率正常时段相对应的TCP报文交互信息：注：250Packets/Tick=1250kb/s从以上TCP报文可见FTP-DATA数据包持续的下发，偶尔出现TCP Previous regment lost(报文丢失)和TCP out-Of-Order（报文乱序）以及同一个报文不超过三次的TCP Dup ACK（重传申请报文），TCP Dup ACK重传请求是由于TCP Previous regment lost(报文丢失)先收到后续的报文而引起的，紧接着马上就收到了正常TCP out-Of-Order报文，因此服务器没有重传，整体过程没有报文丢失，只是前后报文偶尔乱序，对下载速率不造成影响；TCP Dup Ack报文原理：TCP报文中的Ack字段可以理解成对预期到达的下一个数据报文的

3、序列号。之所以看到Dup Ack，说明由于某些原因（例如中间节点丢包），Dup Ack发起方没有收到带预期序列号的报文，从而发送Dup Ack再次请求预期数据报文，直到收到预期报文，才会停止发送Dup Ack。TCP Retransmission报文原理：TCP Retransmission报文代表重传。所谓重传是指，在抓包节点上，具有相同TCP序列号的报文至少两次甚至多次经过。重传报文是一种很常见的影响数传速率的异常报文。以上为速率正常时对应的ATU终端上报的数据；2.3 时间段分析一 由于终端、RNC、SGSN服务器时间设置存在差异，上报的消息时间点稍微不同，对比如下：对应设备统计时间时间段终端9:28:289：28：33RNC9:28:229：28：38SGSN9:28:279：28：322.3.1 SGSN侧分析1） SGSN速率变化图；注：250Packets/Tick=1250kb/s2） TCP层消息分析1、45163 09：28：27 SGSN往RNC传送3905185报文，下一个传送报文为39066332、45172 09：28：27 SGSN收到RNC上报的3903

4、737（即3905185前一个报文）响应消息，告诉服务器已经收到3903737报文；注：该报文：Ack=3905185代表下一个响应报文是39051853、45174至45176 09：28：2709：28：31 SGSN迟迟未收到3905185 ack响应消息，服务器主动定时发送3905185重传消息；4、45180 09：28：32 间隔4秒后SGSN才收到3905185报文ACK响应消息；SGSN开始继续传送报文； 结论：SGSN按序收到服务器TCP报文且正常下发，未收到下游3905185ACK响应消息，FTP服务器停止发送后续报文，进行3905185报文重传，因此该时间段速率为0，可判断SGSN以下游丢包；2.3.2 RNC侧分析1） RNC速率变化图；注：250Packets/Tick=1250kb/s2）TCP层消息分析1、20049 09：28：22 RNC往NodeB传送3905185报文，下一个传送报文为39066332、20058 09：28：22 RNC收到NodeB上报的3903737（即3905185前一个报文）响应消息，告诉服务器已经收到3903737报文；

5、注：该报文：Ack=3905185代表下一个响应报文是39051853、20060至20062 09：28：2209：28：27 RNC迟迟未收到3905185 ack响应消息，服务器主动定时发送3905185重传消息；4、20066 09：28：32 间隔4秒后RNC才收到3905185报文ACK响应消息；RNC开始继续传送报文； 结论：通过对比SGSN与RNC TCP层报文，RNC按序收到SGSN发送的TCP报文且正常下发，数量基本一致，RNC起到一个透传功能，从而判断RNC至SGSN网络正常，同样RNC未收到下游3905185ACK响应消息，FTP服务器停止发送后续报文，进行3905185报文重传，因此该时间段速率为0，可判断RNC以下游丢包；3） MAC层分析；通过MAC层分析可知RNC每时每刻的发包都等于收包，中间的没有错包重传，说明RNC到NB之间的MAC传输链路没有问题。结论：RNC至NodeB传输正常，因此推断NodeBATU终端侧丢包导致该时间段速率低；2.3.3 终端侧分析 从终端ATU上报数据可见：该时间段各个信道的C/I下降比较严重，引起丢包和重传，；由于该数据

6、统计为终端ATU设备，因此可能原因为：1、空口网络质量差 2、ATU终端设备不稳定2.4 时间段分析二 由于终端、RNC、SGSN服务器时间设置存在差异，上报的消息时间点稍微不同，对比如下：对应设备统计时间时间段终端9:23:079：23：13RNC9:23:019：23：07SGSN9:23:069：23：122.4.1 SGSN侧分析3） SGSN速率变化图；注：250Packets/Tick=1250kb/s该时间段典型的速率低的阶段，上图为速率 与 DUP ACK统计 叠加分布图，黑色线条代表速率变化图，红色小块代表DUP ACK超过3次的时间点。TCP的应答机制决定了TCP对于丢包/乱序应该保持高度敏感，根据TCP的设计，当服务器感知丢包发生时（连续收到3个重复的DUP ACK），服务端会启用拥塞避免算法，减小数据发送量，避免对丢包点的持续大数据量冲击而雪崩恶化； 服务器侧启动了拥塞避免机制，减少了数据发送窗口，影响到数据发送量，必然导致速率受到影响。综上，可知丢包/乱序对下载速率的影响很大，在下载速率低的情况下均有比较严重的丢包/乱序。4） TCP层消息分析1、25050

7、09：23：06 SGSN往RNC传送7575201报文，下一个传送报文为75766492、25059 09：23：06 SGSN收到RNC上报的7573753（即7575201前一个报文）响应消息，告诉服务器已经收到7573753报文；注：该报文：Ack=7575201代表下一个响应报文是75752013、25061至25078 SGSN连续收到7575201DUP ACK重传申请消息；4、25068 09：23：06 SGSN发送7575201报文的重传消息； 结论：SGSN按序收到服务器TCP报文且正常下发，下游未收到7575201报文或乱序导致终端发送DUP ACK申请，SGSN收到了DUP ACK便重传消息，由于该时间段持续收到DUP ACK消息，根据TCP协议服务器减少数据的发送量从而导致速率低；从TCP层分析可以定位SGSN下游丢包/乱序；2.4.2 RNC侧分析2） RNC速率变化图；注：250Packets/Tick=1250kb/s2）TCP层消息分析1、54 09：23：02 RNC往NodeB传送34217报文，下一个传送报文为356652、63 09：23：0

8、2 RNC收到NodeB上报的32769（即34217前一个报文）响应消息，告诉服务器已经收到32769报文；注：该报文：Ack=34217代表下一个响应报文是342173、65至82 RNC连续收到34217DUP ACK重传申请消息；4、72 09：23：02 RNC发送34217报文的重传消息； 结论：通过对比SGSN与RNC TCP层报文，RNC按序收到SGSN发送的TCP报文且正常下发，数量基本一致，RNC起到一个透传功能，从而判断RNC至SGSN网络正常，同样由于RNC下游7575201报文或乱序导致终端发送DUP ACK申请，SGSN收到了DUP ACK便重传消息，由于该时间段持续收到DUP ACK消息，根据TCP协议服务器减少数据的发送量从而导致速率低；从TCP层分析可以定位SGSN下游丢包/乱序；3） MAC层分析；日期时间RFNulDlRcvTbNumulDlSndTbNumulDlThroughPut2012/4/2309:23:01(23)2164452725682725686700002012/4/2309:23:01(43)2180452728512728514750002012/4/2309:23:01(63)2196452730172730172780002012/4/2309:23:01(83)2212452733002733004750002012/4/2309:23:02(03)2228452734922734923220002012/4/2309:23:02(23)2244452738082738085300002012/4/2309:23:02(43)2260452741152741155150002012/4

《防城港移动ATU测试下载速率低问题分析报告(终稿)20120508》由会员q****9分享，可在线阅读，更多相关《防城港移动ATU测试下载速率低问题分析报告(终稿)20120508》请在金锄头文库上搜索。