电子文档交易市场
安卓APP | ios版本
电子文档交易市场
安卓APP | ios版本
换一换
首页 金锄头文库 > 资源分类 > DOCX文档下载
分享到微信 分享到微博 分享到QQ空间

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

  • 资源ID:270822757       资源大小:4.09MB        全文页数:22页
  • 资源格式: DOCX        下载积分:8金贝
快捷下载 游客一键下载
账号登录下载
微信登录下载
三方登录下载: 微信开放平台登录   支付宝登录   QQ登录  
二维码
微信扫一扫登录
下载资源需要8金贝
邮箱/手机:
温馨提示:
快捷下载时,用户名和密码都是您填写的邮箱或者手机号,方便查询和重复下载(系统自动生成)。
如填写123,账号就是123,密码也是123。
支付方式: 支付宝    微信支付   
验证码:   换一换

 
账号:
密码:
验证码:   换一换
  忘记密码?
    
1、金锄头文库是“C2C”交易模式,即卖家上传的文档直接由买家下载,本站只是中间服务平台,本站所有文档下载所得的收益全部归上传人(卖家)所有,作为网络服务商,若您的权利被侵害请及时联系右侧客服;
2、如你看到网页展示的文档有jinchutou.com水印,是因预览和防盗链等技术需要对部份页面进行转换压缩成图而已,我们并不对上传的文档进行任何编辑或修改,文档下载后都不会有jinchutou.com水印标识,下载后原文更清晰;
3、所有的PPT和DOC文档都被视为“模板”,允许上传人保留章节、目录结构的情况下删减部份的内容;下载前须认真查看,确认无误后再购买;
4、文档大部份都是可以预览的,金锄头文库作为内容存储提供商,无法对各卖家所售文档的真实性、完整性、准确性以及专业性等问题提供审核和保证,请慎重购买;
5、文档的总页数、文档格式和文档大小以系统显示为准(内容中显示的页数不一定正确),网站客服只以系统显示的页数、文件格式、文档大小作为仲裁依据;
6、如果您还有什么不清楚的或需要我们协助,可以点击右侧栏的客服。
下载须知 | 常见问题汇总

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

防城港移动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层报文,端到端的分析,逐段排查定位。 下图为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字段可以理解成对预期到达的下一个数据报文的序列号。之所以看到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上报的3903737(即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报文;注:该报文: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下降比较严重,引起丢包和重传,;由于该数据统计为终端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 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:02 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)主动上传,金锄头文库仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即阅读金锄头文库的“版权提示”【网址:https://www.jinchutou.com/h-59.html】,按提示上传提交保证函及证明材料,经审查核实后我们立即给予删除!

温馨提示:如果因为网速或其他原因下载失败请重新下载,重复下载不扣分。




关于金锄头网 - 版权申诉 - 免责声明 - 诚邀英才 - 联系我们
手机版 | 川公网安备 51140202000112号 | 经营许可证(蜀ICP备13022795号)
©2008-2016 by Sichuan Goldhoe Inc. All Rights Reserved.