GPRS典型案例分析.ppt

1、GPRS典型案例分析,移动研究所网规网优部,课程目的,学习完本课程，你将能够： 熟悉GPRS业务排障方法 掌握GPRS业务CQT&DT测试后台分析方法 掌握GPRS业务信令跟踪分析方法,目录,ATTACH问题 PDP激活问题 WAP问题 FTP问题 其它问题,概述,ATTACH问题,Attach故障特点,Attach成功率低，Attach时延长,概述,ATTACH问题,Attach故障解决 关闭SGSN鉴权； 采用一步接入方式； 检查覆盖； 防止频繁的小区重选； 排查干扰，提高C/I； 检查RACH或AGCH信道配置； 检查GPRS ENABLED参数设置； 检查Gb links load，调

2、整NSEI配置； GPRS核心网调整。,手机无法登陆GPRS网络,ATTACH问题,问题描述： 在某地网络，有用户反映手机GPRS Attach不能成功。 现象为手机发送Attach request，SGSN返回attach accept消息，而后面BSC上发信令为LLC unkown information。,解决方法 将P-TMSI由disable调整为enable，故障解决。,故障分析 根据信令流程，BSS侧负责TBF流的建立，后面应为手机和SGSN的透传信令，正常流程应为手机向SGSN发送Attach complete。 BSC相关数据没有发现问题。 从全局测试来看，与SGSN对接的所

3、有BSC下所带基站都有相同问题情况，初步判断为SGSN侧的问题。 经检查，有数据改动，即P-TMSI 由原来的enable 改为disable。导致P-TMSI无法分配，用户无法上GPRS。,ATTACH失败,问题：频繁的小区重选（600216033260021）导致ATTACH时延过长（14.55s）。 解决方案：提高60021CRH由8dB到10dB,调整60332RXLEVACCESSMIN由10dB到12dB。,ATTACH问题,ATTACH失败,问题：网络向手机发送Packet Access Reject消息作为对Packet Resource Request消息的应答，此消息中包含

4、“Wait_Indication”域，其值赋予T3172，当手机收到Packet Access Reject消息后，启动T3172，在T3172运行期间，网络不允许手机在同一小区内再次发起分组接入尝试。该事件由无线资源紧张所致。 解决方案：扩充静态PS信道。,ATTACH问题,目录,ATTACH问题 PDP激活问题 WAP问题 FTP问题 其它问题,概述,PDP激活问题,PDP激活故障特点,PDP激活成功率低，PDP激活失败，PDP激活时间长,PDP激活故障原因,移动台原因 APN设置错误 OoS错误 PDP地址错误 手机与网络不兼容,无线网络原因 无线网络信号质量差 存在干扰 无线资源不可用

5、或拥塞,核心网原因 DNS解析错误 SGSN与GGSN之间的GTP异常,路由更新频繁 该区域位于LAC边缘地带，路由更新引起PDP激活不成功或时延过长,概述,PDP激活故障解决 检查覆盖 防止频繁的小区重选 排查干扰，提高C/I 检查RACH或AGCH信道配置 检查Gb links load，调整NSEI配置 合理设置T3168 timer 检查GPRS参数设置，合理设置BSC级参数DRX_TIMER_MAX 打开SGSN的cache，缩短DNS的解析时间 检查GGSN的处理功能，如果DHCP或RADIUS 服务器配置不当，或者GGSN处理能力不够，会造成PDP激活速度慢，甚至PDP激活失败。

6、,PDP激活问题,PDP激活失败,问题：在20022重选到20281后，由于20281AGCH紧张导致。 解决方案：控制20281覆盖范围，适当增加20281AGCH配置。,PDP激活问题,PDP激活失败,问题：由于连续发生两次小区重选（CELLID: 10071 Channel:2CELLID: 111 Channel:90CELLID: 114 Channel:512）长时间无时隙分配引起PDP激活失败。 解决方案：提高60021CRH由6dB到10dB。,PDP激活问题,PDP激活失败,问题：由于没有申请到PS信道导致PDP激活失败。 解决方案：增加8540站点的静态PS信道，将MFR由

7、5调整到2。,PDP激活问题,PDP激活失败,问题：在CQT测试时经常出现偶尔PDP激活时延过长的现象。经过对10个点100次的PDP激活测试,发现7次时延异常的现象，具体挂表结果如下：,PDP激活问题,PDP激活失败,PDP激活问题,PDP激活失败,故障分析：,PDP激活问题,测试结果可以看出，主要耗时是在Gb口以下和Radius与WAP网关间，其中第六次GGSN与Radius间的耗时比较长，是因为GGSN第一次发送的Accounting request消息没有被WAP网关接收到。导致这种现象的原因可能是Accounting request消息在传输中丢失或者Radius的处理异常。 另外六

8、次则是因为Gb口以下和Radius与WAP网关间的耗时过长。GGSN向Radius发送Accounting Request消息，等待Radius的响应，并启动相应的等待定时器，在相应的WAP网关侧，发现WAP网关在收到Accounting Request消息后没有给予响应，由于GGSN没有收到Accounting Request消息的响应消息，导致等待定时器超时，然后GGSN重新发送Accounting Request消息，在相应的WAP网关侧，我们发现WAP网关此次给予了响应，GGSN收到Radius转发的Accounting Response消息，这时GGSN才对手机的PDP激活请求进行响

9、应。 正是由于Gi口的耗时过长，使得无线侧的定时器超时而释放了TBF资源，所以手机在接收PDP激活接受消息时，重新进行了TBF的建立，这又进一步增加了在无线口上的延时。 因此，WAP网关的响应过慢，是导致PDP激活时延过长根本原因。,目录,ATTACH问题 PDP激活问题 WAP问题 FTP问题 其它问题,概述,WAP问题,WAP问题特点 WAP首页显示成功率低 WAP首页显示时间长 WAP页面刷新成功率低 WAP首页刷新时间长。,WAP故障原因 无线侧的覆盖、干扰、小区重选问题 Gb口两端数据配置问题 WAP网关接续时间过长 WAP参数设置问题,WAP故障解决 对WAP网关进行优化； GPR

10、S核心网优化 ； 检查覆盖； 防止频繁的小区重选； 排查干扰，提高C/I； 检查Gb links load，调整NSEI配置。,WAP图铃下载速率低,问题：通过分析看出RLC数据重传率高，从OMC统计数据看Gb link的负荷在测试时段已高达64%，从而导致下载速率低。 解决方案：重新调整NSEI以减低Gb link load，从而提高GPRS CQT的下载速率。,WAP问题,WAP图铃下载速率低,问题：通过分析看出RLC数据重传率高，从OMC统计数据看Gb link的负荷在测试时段已高达64%，从而导致下载速率低。 解决方案：重新调整NSEI以减低Gb link load，从而提高GPRS

11、CQT的下载速率。,WAP问题,WAP登陆失败,问题：在*宾馆WAP登陆测试中，通过跟踪Gb口发现，手机上行发送Get(URL=)，网络侧回复了一个PDU，具体内容为：Your request for a service could not be fulfilled,please try again or contact your operator if the problem persists。这种现象是因为移动梦网服务器出现问题。 解决方案：与核心网工程师沟通解决。,WAP问题,WAP登陆和刷新时延过长,WAP问题,WAP登陆和刷新时延过长,WAP测试信令流程,问题：信令分析发现，网关在C

12、ONNECT到CONNECT REPLY和GET到REPLY间存在响应时延长，需重复发送GET请求,甚至会出现没有响应的情况，尤其是GET与REPLY间经常出现较大的信令时延，有的甚至达到几十秒,对手机访问WAP速度有较大影响。 解决方案：核心网工程师针对WAP网关进行优化。,WAP问题,问题：在手机Get需要的网页后，WAP网关回“URL NOT EXIST”消息。该消息是WAP网关收到SP服务器回应的“服务暂时中断”消息后作出的响应。 解决方案：该次测试在CDS后处理软件中将被剔除。不作为一次测试尝试。,假事件,WAP问题,目录,ATTACH问题 PDP激活问题 WAP问题 FTP问题 其

13、它问题,概述,FTP问题,FTP下载故障特点 RLC重传率高 TBF掉线和长时间停传 FTP下载速率慢,概述,FTP问题,概述,FTP问题,FTP下载故障解决 对FTP server进行优化； 动态调整CS的比例； 覆盖优化； 防止频繁的小区重选； 排查干扰，提高C/I； 合理设置T3192 timer 检查Gb links load，调整NSEI配置； 打开CS3、CS4。,FTP下载失败,问题：MS 重选到小区41921后，DL TBF一直没被建立导致长时间下行无数据传输，最终导致了PDP掉线. 经检查该小区在测试时间段内的GPRS KPI：下行时隙分配拥塞率比较高，这是为什么没能建立DL

14、 TBF的主要原因所在。 解决方案：增加该小区静态PS信道。,FTP问题,FTP下载失败,问题：MS从CI1892重选到CI到481的同时跨了PCU，属于Inter-PCU的Cell Reselection,导致了数据传输长时间的停顿，最终发生了PDP掉线。经检查发现CI1892的NSEI值与周围站点不统一。 解决方案：调整CI1892的NSEI值。,FTP问题,FTP下载速率低,问题：FTP下载过程中小区频繁重选，导致长时间TBF挂起。小区业务信道繁忙，用户较难申请PS信道。导致平均下载速率只有8.11kbit/s。 解决方案：扩充30553、30152静态PS信道；调整30553RXLEV

15、ACCESSMIN由10到14。,FTP问题,FTP下载失败,问题：MS从43372重选到42093后，又从42093重选到1531后又频繁重选回1531后，电平降到-94dBm，拖了一段时间后PDP掉线。 解决方案：控制42093、1531覆盖。,FTP问题,FTP下载失败,问题：MS跨LAC从83重选到1483后，就频繁的小区重选148318621741，导致长时间的TBF挂起，最终PDP掉线。从地形看，该处是一座立交桥，桥下无主控区。 解决方案：调整1483 CRH由6到10，确定该地点的主控小区。,FTP问题,FTP下载速率低,问题：MS拿到的PDCH不稳定，跳变频繁，PS争抢频繁，导

16、致了DL FTP速率低。 解决方案：增加CI2631的静态PS信道。,FTP问题,BS_CV_MAX设置不合理,FTP问题,问题描述 某GPRS网络中某个小区存在传输速率偏慢，该小区位于郊区，话务量不高。 故障分析 检查GPRS无线参数，BS_CV_MAX设置为15。经过分析该区域话务量低，无信道拥塞。BS_CV_MAX 最大发送块数，属于GPRS小区选项参数，用于系统提前了解到手机将何时上行传输结束，从而可以提高上行资源的利用率。BS_CV_MAX值设置过小MS 就有可能在网络返回证实消息之前重传RLC数据块，会导致无线资源的占用率过高。如果设置过高会导致滑动窗口程序的效率偏低，数据传输的速

17、率变慢。 故障处理 将BS_CV_MAX的设置值调整变小以提高重传率。将BS_CV_MAX调整成6后，传输速率明显提高。,FTP下载速率低,FTP问题,FTP下载速率低,问题：在复测时我们发现，在同一个地点，此时52484的C1=25，C221，从15:40:33.764至15:53:586持续20s后，C2值升至53。由于复测时，车行驶的地方为一个交通灯口，车流量大、拥堵。我们原先设置的PET20s远远小于堵车的时间。 解决方案：将这个小区的PET设置为200s，这样小区重选发生的可能性就大大降低了。,FTP问题,FTP下载失败,每次穿越RAC区时，都发生掉线，且都伴随着RAU Failur

18、e。通过仔细分析， SGSN内的数据错误是导致这种路由更新失败的原因。 关系GPRS路由更新的参数主要有3部分，即： (1) 每个MSC到SGSN的归属位置 (2) 每个BSC到MSC的归属位置 (3) 每个小区的归属的RAC区 以上3个参数必须与现行网络中硬件设备的连接一致才能保证GPRS手机路由更新的正常进行 。,FTP问题,FTP下载速率不稳定,问题： 某区域用户投诉FTP下载速率变化极大，在很短时间内速率相差几十K以上。 该区域完全由A小区覆盖，其它小区覆盖未出现此类投诉，重点检查该小区与其它小区的差别。 发现该小区的T3168设置为4000ms，其它小区都设置为1000ms。 解决方

19、案： 定时器T3168值设置过大，数据正常传送时，速率较高； 当移动台接收到“分组上行指配”消息时，发送“请求分组资源”消息来做出应答，发送应答后，启动定时器T3168，当定时器T3168运行时，移动台不响应“分组下行指配”消息，造成在T3168时间内，没有下行数据传送，所以速率很低。 将T3168由4000ms修改为1000ms，FTP下载速率稳定，问题解决。,FTP问题,问题：车辆从北向南行驶，红圈处占用小区A。继续南行，A小区电平逐渐降低，低至94dBm以下时，仍不发生小区重选。长时间电平低于94dBm，造成覆盖差。经检查发现此时该小区与相邻小区的小区重选参数设置情况如下页表：,弱覆盖,

20、FTP问题,解决方案：控制小区高教科研4（BCCH：560）的覆盖，修改高教科研4小区CRO由26到20。,弱覆盖,FTP问题,FTP下载失败,通过对Gi口抓包分析，发现登陆FTP服务器后，FTP服务器因收到RESET消息而停止发送数据。由于发送端已中止发送，而在手机终端侧FTP下载测试进程并没有停止，最终测试软件判断超时失败。 该种情况主要是由于位置更新导致登陆服务器中断，FTP登陆时TCP协议进程因丢包出现错误，而从测试软件的表象上看，已显示成功登陆，但无法下载数据。,假事件,FTP下载失败,从测试设备抓包可以看到已经成功接收到FTP-DATA包，但是却没有将收到的数据包变为有效数据，最终

21、导致接收窗口溢出，数据传输中止。而FTP下载测试进程同样并没有停止，最终测试软件判断超时失败。 该种情况同样是由于位置更新导致登陆服务器中断，虽然FTP登陆TCP协议进程正常，可以正常传输数据，但是FTP-DATA仍然出错。,假事件,FTP下载失败,结论： 上述两种FTP下载的断线情况均是由于FTP协议出现错误导致，该错误出现在TCP/IP的传输层和应用层，而不是由GPRS网络层故障引起。 从测试软件上看，都是在登陆FTP服务器后无法接收应用层数据，最后超时显示FTP download fail，统计为掉线一次。,假事件,目录,ATTACH问题 PDP激活问题 WAP问题 FTP问题 其它问题

22、,PING问题一,问题：Ping测试中时间间隔设置为4s-12s测试结果有很大差别。经过核心网挂表测试发现Ping时延不稳定是因为测试过程中出现其他一些数据包，这些垃圾数据包是由杀毒软件和一些应用软件自动更新造成的。 解决方案：重新安装操作系统，不能安装与测试无关的软件，将托盘中的任何与网络通讯相关的程序关闭，关闭Windows的自动更新功能。,其它问题,问题：由于小区的C/I低导致较高的BLER（小区BCCH CI5.9）。查看规划数据，微蜂窝8800、7660、8750是同BCCH。 解决方案：控制8800、7660、8750覆盖，调整8800、7660、8750频点。,PING问题二,其它问题,MMS发送失败,问题： 松下GD88手机在发送大于15K以上的彩信时，成功率比较低，在发送大于30K的彩信时，成功率几乎为零。而使用其他型号的手机如本次我随身携带的NOKIA 6100发送大彩信完全正常且快速。 解决方案： 录制GB口信令发现， 松下EB-GD88彩信手机不完全支持GSM04.60规范(GPRS RLC/MAC层规范)，它不完全支持GSM04.60规范允许的BS_CV_MAX=13、14、15的基站参数设置，只支持BS_CV_MAX=1.12的设置。 建议将全网BS_CV_MAX由默认值15调整为6。,其它问题