非资源问题小区深度研究.docxVIP

非资源问题分析 非资源问题解决方案 通过以下几个方面进行问题分析 硬件不支持EDGE的载频核查 目前完成相关硬件信息整理工作，下周完成这些载频是否影响现网数据业务分析。 12月1日月初流量最大时，提取全网非资源问题小区。 目前已经提取完成，12月1日全网存在495个小区存在非资源问题。 具体小区如下: 参数对比 通过比对嘉兴和满意度较好的湖州参数，发现湖州下行EDGE初始编码基本设置在MCS7-MCS8，而嘉兴主要设置在MCS6-MCS7。 非资源问题小区现场CQT测试 目前完成5个CQT点测试，并从中找出一些规律及问题，详细分析见后面报告。 卡特网元设备及传输告警 该部分内容未能完成。 非资源问题小区现场测试分析 本周提出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后立刻发送后面的数