非资源问题小区深度分析.docx
- 文档编号:23708787
- 上传时间:2023-05-20
- 格式:DOCX
- 页数:11
- 大小:1.77MB
非资源问题小区深度分析.docx
《非资源问题小区深度分析.docx》由会员分享,可在线阅读,更多相关《非资源问题小区深度分析.docx(11页珍藏版)》请在冰豆网上搜索。
非资源问题小区深度分析
非资源问题分析
非资源问题解决方案
通过以下几个方面进行问题分析
1.硬件不支持EDGE的载频核查
目前完成相关硬件信息整理工作,下周完成这些载频是否影响现网数据业务分析。
2.12月1日月初流量最大时,提取全网非资源问题小区。
目前已经提取完成,12月1日全网存在495个小区存在非资源问题。
具体小区如下:
3.参数对比
通过比对嘉兴和满意度较好的湖州参数,发现湖州下行EDGE初始编码基本设置在MCS7-MCS8,而嘉兴主要设置在MCS6-MCS7。
4.非资源问题小区现场CQT测试
目前完成5个CQT点测试,并从中找出一些规律及问题,详细分析见后面报告。
5.卡特网元设备及传输告警
该部分内容未能完成。
非资源问题小区现场测试分析
本周提出35个WAP下载速率低,get重传率较高的小区进行现场测试,完成5个CQT点测试,测试结果如下
其中只要40838达到测试满分指标,其他4个测试点都未能达到测试指标。
下表为各测试点的无线指标
下表为各小区应用层指标
从以上各指标看,各小区不存在资源问题,但无论从无线还是应用层都存在一定重传问题。
下面针对每个问题小区进行详细分析
●小区20501
该小区的应用重传比较高,而无线重传也比较高,但从现场测试来看,手机可以一直使用M9的编码进行数据业务,并不存在无线干扰问题,只是由于时隙总在重新建立导致下载速率变慢,如下图:
下面针对测试时进行分析
下图为第一次FTP的第二次断流时的CDS信令截图。
从上图可以看出,核心网侧在48分04秒时发生2个数据包给手机,手机收到数据包后立刻回ACK给核心网,而在48分06秒和48分11秒重发之前的数据包给手机,说明核心网并未收到该数据包的确认消息,此时手机就一直发送当前已经收到的确认包小区给核心说明手机已经收到哪些数据包。
下图为IBS平台GB接口信令截图
从以上截图可以看出,核心网在48分30秒发送CDS截图中所接收的数据包,之后核心网侧一直向手机发送数据包直到手机TCP窗口满为止,当TCP窗口满了,核心网还未收到对48分30秒的数据包确认,就在48分32秒和48分37秒重发此数据包给手机,直到48分38秒核心网收到对在48分30秒发送的确认包,核心网侧继续重发未确认的数据包给手机。
由此可以看出,导致此次重发数据包的问题是由于手机发送的上行数据包一直未能发给核心网造成的,正常的数据包和上行确认包的时延间隔在1-2秒,而此次数据包与上行确认包的间隔为8.8秒。
下图为手机发送上行确认包时的无线资源截图
从上图可以看出,手机在48分06秒还在发送上行数据包,说明无线上行链路不存在问题,该问题可能是由于基站、传输、GP板卡问题造成。
●小区10601
该小区之前分析如下:
小区10601从无线指标来看,PD复用度很低,GP板卡和G-ATER负荷很低,TBF建立成功率很高,基本不存在无线问题,但WAP下载速率只有27.97kbps。
进行现场测试,如下
FTP的速率只有53kbps,WAP下载速率平均只有35kbps,从BEP来看,无线不存在任何干扰,手机也一直能够占用4个时隙。
下面针对应用层信令进行对比
第一次图铃下载分析
上图为无线侧应用层信令截图,从上图可以看出,核心网发送的连续7个数据包手机是在4秒的时间才接受完成的。
网络侧分别在29s发送1个,30.015s发送2个,30.031发送1个,30.5s发送1个,32.5s发送1个,33s发送1个,总共发送7个共用时4秒,当手机收到第7个数据包时立刻回复相对应的ACK,网络侧在33.015s又重发第7个数据包,手机刻回复相对应的ACK。
上图为IBS平台GB接口信令截图,从上图可以看出,网络侧连续下发的7个数据包是在591毫秒内完成的。
网络侧分别在176ms发送1个,587ms发送4个,591ms发送2个,在3591ms重发的第7个数据包,在4902ms得到手机的确认的ACK后立刻发送后面的数据包,在4976ms得到手机重发的ACK包。
从上面两个截图可以看到有部分UDP数据存在可能存在应用层干扰,下面针对第二次图铃下载继续分析
上图为无线侧应用层信令截图,从上图可以看出,核心网发送的连续7个数据包手机是在3秒的时间才接受完成的。
网络侧分别在3s发送1个,5.5s发送1个,6s发送2个,6.015s发送3个,总共发送7个共用时3秒,当手机收到第7个数据包时立刻回复相对应的ACK,网络侧在6.015s又重发第7个数据包,手机刻回复相对应的ACK。
上图为IBS平台GB接口信令截图,从上图可以看出,网络侧连续下发的7个数据包是在348毫秒内完成的。
网络侧分别在17ms发送1个,344ms发送4个,348ms发送2个,在3358ms重发的第7个数据包,在3919ms和3943ms得到手机的确认的ACK后立刻发送后面的数据包。
第二次测试中无UDP数据干扰。
从以上两次测试可以分析出以下问题
手机和网络侧都是得到响应的数据包后立刻响应,说明手机和核心网侧不存在问题。
网络侧在不到1秒内发送下来的数据包,手机侧使用了3-4秒的时间才接受完成,由于WAP重传机制为3秒无响应重发,因此网络侧要重发最后一个包,而该小区无线无任何问题,对于下行数据包的传输应该可以在更快的时间内完成,说明该问题可能由以下几个方面造成:
基站故障,传输故障,GP故障,GATER故障,因此该问题需要进一步进行分析定位。
该小区经过倒换载频后测试效果如下:
测试WAP时,时隙经常重配,测试FTP时只能得到1个时隙,而该时刻的PD复用度仅为0.25。
下面针对其中一次WAP业务进行分析
手机在4分13秒发起GET,4分14秒得到相应,4分16秒得到WTPRESULT,4分19秒完成5个数据包解决并回应确认消息,4分19秒得到重发的5号数据包,手机立刻回应确认。
从IBS平台GB接口截图看,核心网在4分41秒收到手机发送的get消息后,在377毫秒内把对get的相应包、WTPRESULT包及5个数据包全部发给手机,在4分44秒重发第5个数据包,在4分47秒得到第5个包的确认包及重传包。
由此可以看出,由于无线侧用了6秒的时间发送这7个数据包导致手机发送的确认包慢了,导致核心网侧重传5号包,而无线侧此时不存在任何资源问题和无线环境问题,因此可以确认该问题是由于基站、传输或GP板卡造成的,需要卡特厂家确认。
●小区20408
从CDS截图可以看出,手机用了8秒时间完成接收初始的7个数据包,因此导致重传产生,该问题与10601相同,是由于下发数据包慢造成的。
●小区20246
从CDS截图上看,手机用了1秒的时间接收完12到17号包,并在0分19秒立刻发送17号包的确认。
而手机分别在0分21秒、0分27收到3个重发17号包,并立刻发送确认包。
从CDS棘突来看,核心网侧在0分48秒发送完成12到17号包的发送,在没有得到上行确认包时,在0分51、0分54及0分57秒时重发17号包,当在0分57秒收到第一个17号包的确认时继续发送18号数据包。
由此可以看出,该小区的问题出上行链路上,手机收到数据包后立刻发送上行数据确认包,而网络侧等了9秒多才得到确认包,因此该问题可能由于基站、传输、GP板卡造成的
总结
通过以上案例总结出以下问题
●各小区都存上行或下行发送数据包慢的问题,需要卡特厂家确认该问题是由于基站、传输、GP板卡哪部分造成的。
●小区20501、10601、20408都处于同一GP板卡下,因此建议对该板卡进行检查,可能是造成该问题的主要原因
●如果是基站基站问题,是否只能通过逐一测试才能发现问题,是否可以通过其他统计收到查找硬件问题。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 资源 问题 小区 深度 分析