GPRS测试问题总结分析.docx
- 文档编号:26239627
- 上传时间:2023-06-17
- 格式:DOCX
- 页数:19
- 大小:647.02KB
GPRS测试问题总结分析.docx
《GPRS测试问题总结分析.docx》由会员分享,可在线阅读,更多相关《GPRS测试问题总结分析.docx(19页珍藏版)》请在冰豆网上搜索。
GPRS测试问题总结分析
1.测试问题总结分析
1.1Attach成功率
对于Attach成功率低的问题,我们从此次测试中总结出主要有以下几个因素导致该项指标差:
1)信令异常
2)无线信道资源紧张
3)无GPRS信号
4)在Attach过程中因发生位置更新而导致超时失败
以下我们结合实例加以分析说明:
例一:
某城市CQT测试点佳程酒店(第4、6次)、华天大酒店(第3次)、福利华大酒店(第1次)。
现象描述:
以佳程酒店为例。
手机当时服务小区为:
LAC=29450,CI=13040,BCCH=5,BSIC=07。
手机能正常接收到网络发送的SystemInformationType13消息,说明此小区是支持GPRS功能的。
但是手机连续发送AttachRequest都没有成功。
下图为手机Attach失败Um口上的信令流程。
原因分析:
Attach尝试开始时,手机向网络发送AttachRequest消息,并启动定时器T3310,如果此消息中不包含P-TMSI(临时移动台识别码),则网络向手机发送IdentityRequest消息,要求手机发送IMSI(国际移动用户识别码),手机回应IdentityResponse(含IMSI)消息。
然后手机正常接收到AttachAccept后,回应AttachComplete,T3310停止。
若T3310超时,手机会向网络再次发送AttachRequest消息,并重新启动T3310。
从手机收到的PacketUplinkAck/Nack消息可知,网络已经收到了手机发送的IdentityResponse消息。
但此后手机再没有收到网络发送的任何消息。
发生这种现象的原因有:
O网络已经发送了AttachAccept消息,由于无线环境差,手机没有接收到。
O由于无线资源紧张,网络没有空闲信道来发送AttachAccept消息。
另外,手机锁定的小区CI=13040,应该为室内微蜂窝,载频数配置一般较少,容易发生无线资源拥塞现象。
例二:
某城市CQT测试点国际金融大厦(第8次)、华天大酒店(第5次)等。
现象描述:
以湖南国际金融大厦为例。
在Attach过程中,手机锁定小区:
LAC=29505,CI=24101,BCCH=514,BSIC=15,没有发生小区重选。
手机在多次发送AttachRequest消息后,最后收到AttachReject消息,Cause:
GPRSservicesnotallowed。
原因分析:
发生这种现象的可能原因:
O网络没有正确的接收到手机发送的IdentityResponse消息(含IMSI),认为此IMSI没有注册GPRS功能。
O在Gb或Gr接口间传送用户信息时,发送错误,SGSN认为此IMSI没有注册GPRS功能。
例三:
某城市CQT测试点天仁大酒店(第2次)、温哥华广场(第9次)。
现象描述:
以天仁大酒店为例。
手机第1次Attach失败,第2次成功,总共用时约15.08秒,超过了CMCC要求的15秒。
原因分析:
手机在第1次Attach开始时锁定的小区为:
LAC=33051,CI=2353,BCCH=37,BSIC=24,并在此小区上发送了AttachRequest消息。
但是之后手机发生了小区重选,锁定的新小区为LAC=33501,CI=2351,BCCH=23,BSIC=24,因此造成了Attach尝试失败。
随后手机在新小区上进行了第2次Attach尝试并成功。
1.2
Attach平均时间
在这次测试中,各地的GPRSAttach时间相比年初时有了很明显的提高,一般都在2秒之内,但也有一些城市的指标相对要低些,平均时间在4秒以上。
从后期数据分析中我们总结出,影响GPRS平均附着时间的原因主要有以下几方面:
1)SGSN处理速度慢。
SGSN和No.7有关的配置不正确或者SGSN的处理速度慢,影响登记的速度。
2)STP的负荷过高。
若Gr信令路由经过了STP,部分STP由于已经信令负荷和处理器负荷偏高,在此基础上加入GPRS的信令流量,将严重地影响GPRS登记以及其它和STP相关的信令流程的速度。
3)未开通GPRS功能的GPRS手机反复重试造成的信令负荷增加。
Gb信令和Gr信令激增导致Attach时延增大或Attach成功率下降。
4)因为Attach超时而失败。
(见Attach成功率分析)
以下我们结合实例加以分析说明:
例一:
某城市CQT测试点万科大厦的10次Attach所用时间均在11秒以上,对测试的整体影响较大,下面做出分析。
现象描述:
Attach成功,但是时间较长,均超过11秒。
在Attach的过程中,手机经常发生小区重选,还有短暂性的NoService现象。
原因分析:
观察原始测试数据回放,发现测试点的上行信道的分配模式为固定模式(Fixed),如下图。
结合当地的基站硬件设备和以往测试经验,判断为SAGEM手机和Motorola网络在Fixed分配模式下的不兼容问题。
从而导致上行信道性能极差,手机经常进行不正常的小区重选,延缓了Attach成功时间。
另外从测试的其它项目也可以看出,手机与网络的不兼容问题对网络的整体运行水平影响很大,如WAP首页显示时间等。
例二:
某城市CQT测试点萧山国际机场(第5次)、富豪酒店(第6次)等。
现象描述:
以萧山国际机场第5次为例。
手机进行AttachRequest用时为8.9秒。
原因分析:
从手机进行Attach过程的信令流程看,在手机向网络发送IdentityResponse消息后,网络没有做出正常应答,即向手机发送AttachAccept消息,而是在T3370(设置为6秒,当网络发送IdentityRequest后启动,收到IdentityResponse后停止)超时后,向手机再次发送IdentityRequest消息。
发生这种情况的原因可能是由于无线环境差,网络没有正确接收到手机发送的IdentityResponse,T3370超时后,再次要求MS发送Identity,即IMSI。
延长了Attach成功时间。
1.3
PDP激活成功率
PDP激活成功率是衡量网络质量的一个基本指标,它反映了GPRS网络对于用户手机获取IP地址请求响应的能力。
从这次测试来看,影响PDP激活成功的可能于无线信道资源、无线环境质量以及网络参数配置等有关。
以下我们结合实例加以分析说明。
例一:
某城市CQT测试点贵都大酒店(第5-8次)
现象描述:
手机发送ActivatePDPContextRequest消息后,没有发送ChannelRequest消息。
最终PDP激活失败。
如下图。
原因分析:
从后台路测分析软件的层3消息中(见下图)可以看出,手机在发送了ActivatePDPContextRequest消息后,网络没有做出任何反映。
发生这种情况的可能原因有:
O由于无线环境差,网络没有收到手机发送的ActivatePDPContextRequest消息,因此不会做出任何动作。
O由于无线资源紧张,网络无空闲信道对手机的请求做出回应。
O网络收到手机的请求,但是信息在核心网络各接口之间的传递时,由于硬件工作不稳定或协议出现错误,造成PDP激活请求失败。
例二:
某城市CQT测试点丽晶大酒店(第1-10次)
现象描述:
手机发送ActivatePDPContextRequest,网络回应ActivatePDPContextReject。
原因分析:
如下图,RejectCause:
Networkfailure。
当问题存在于SGSN之外,如:
DNS未能正确地将WAP网站名称映射成IP地址,SGSN将向手机发送含此原因的拒绝消息。
例三:
某城市CQT测试点麒麟饭店(第4次)
现象描述:
手机发送PDP激活请求后,网络回应PDPActivateReject,Cause:
insufficientresources。
如下图。
原因分析:
当网络因为无线资源缺乏,无法响应手机的PDP激活请求,则向手机发送含此种原因的拒绝消息。
1.4
PDP平均激活时间
在此次PDP激活测试中,大多数城市的PDP激活时间均在1秒左右,只有个别的在三秒以上。
我们通过观察分析,觉得影响PDP激活快慢的原因可能有以下几方面:
1)SGSN构造APN的配置问题
SGSN在构造APN解析的时候,开始不能附加正确的运营商标识(MNC000.MCC460.GPRS),造成APN解析失败,之后重试才附加正确的运营商标识,APN解析成功,这种情况会减慢PDP激活的速度。
2)DNS解析APN过慢
APNDNS解析过慢,多发生在漫游时使用归属地GGSN(区域性APN业务)的情形,这种情况下应该检查是本省DNS故障还是根DNS故障,然后作相应的处理。
3)GGSN处理过慢
多数情况是由于DHCP(动态主机配置协议)或Radius服务器配置不当的原因,也可能是由于GGSN处理能力不够,不能负担大IP地址池的DHCP服务工作,这种情况下应该对GGSNDHCP服务器的配置进行检查和优化,或者考虑设置独立的DHCP服务器。
4)DNS和GGSN的主备用状态
检查主备用DNS服务器、APN所对应的主备用GGSN是否都工作正常,如果主用DNS或者主用GGSN已经瘫痪,使用备用DNS/GGSN,则也会降低PDP激活的速度。
1.5
WAP网站登陆成功率
WAP测试是日常GPRS用户使用频率最多的一项业务,它的好坏直接影响到用户对GPRS网络质量的满意度。
在进行WAP测试时,往往会受到多方面的因素影响,不仅有GPRS网络内部的质量,而且还受到外部核心网以及WAP服务器等多方面因素的影响,所以有的城市WAP登陆成功率低原因也是多方面的。
在这我们将结合测试案例进行分析说明。
例一:
某城市CQT测试点商贸饭店(第9、10次)、喜来登酒店(4、5、6、7、8)
现象描述:
PDP激活失败
原因分析:
WAP登陆的第一步需要PDP激活,因此PDP激活失败将直接导致WAP登陆失败。
PDP激活失败原因分析见PDP激活成功率。
例二:
某城市CQT测试点商贸饭店(第3、4、6次)
现象描述:
从信令流程上看,GPRSMS进行PDP激活是成功的,没有发生频繁的小区重选,信号强度为-50dBm左右,但是WAP登陆因超时而失败。
原因分析:
从分析软件上可以看出,在手机登陆WAP网站的过程中,下行链路上的TBF基本处于Closed状态(如下图),且下行链路上很少出现建立下行链路所必须的PacketDownlinkAssignment消息。
出现这种情况的原因大致有两点:
O小区话务量高,PDCH为动态分配,且话务分配的级别高于数据业务分配,因此无可用资源用作PDCH。
O由于外部网络差或WAP网站的瓶颈作用,无数据向MS发送,造成WAP登陆超时。
例三:
某城市CQT测试点凤凰饭店(第10次)
现象描述:
PDP激活成功,随后的WAP登陆超时失败。
原因分析:
PDP激活后,在进行WAP登陆时发生了频繁的小区重选,从而影响了正常性的WAP网站的数据下传,最终造成WAP登陆超时失败。
手机发生小区重选先后锁定的小区有:
4259242371240824221242591
见下图。
1.6
WAP平均首页显示时间
在使用WAP业务的时候,网页打开的快慢同样也能直接的影响在用户满意度,这个指标的好坏同样也受到多方面的影响。
在测试中部分城市的WAP首页显示时间较长,超过10秒以上,高于平均水平有5、6秒之多。
以下我们将结合案例进行具体分析。
例一:
某城市CQT测试点太平洋广场(第3次)、万友康年酒店(第2次)、新重庆广场(第2、3、5、9、10次)
现象描述:
以太平洋广场为例。
PDP激活正常,用时0.90秒,WAP首页显示时间为35.37秒。
原因分析:
手机在整个WAP网站登陆的过程中一直锁定小区:
LAC=33154,CI=10451,BCCH=14,BSIC=75,RXLEV=-76dBm左右,没有发生小区重选。
因此分析导致WAP首页显示时间超长的可能原因有:
O手机锁定的小区的话务量高,PDCH为动态分配,且话务分配的级别高于数据业务分配,因此无可用资源用作PDCH来下载网页。
从分析软件的看,TBF长时间处于Closed状态。
O由于外部网络差或WAP网站的瓶颈作用,无数据向MS发送,下行的TBF处于Closed状态,造成WAP登陆用时过长。
例二:
某城市CQT测试点人民宾馆(第4次)
现象描述:
手机第1次PDP激活失败,第2次成功。
PDP激活用时24.08秒,WAP首页显示时间30.62秒,因此此次WAP首页显示时间超长主要是由于PDP激活慢造成的。
原因分析:
手机在整个WAP网站登陆的过程中一直锁定小区:
LAC=33154,CI=10092,BCCH=11,BSIC=52,RXLEV=-70dBm左右,没有发生小区重选。
从回放原始测试数据看,手机进行第1次PDP激活的过程中,当网络向手机发送PacketDownlinkAssignment消息后,两者之间的GPRSRLC/MAC层的消息中断。
从网络发送PacketDownlinkAssignment的内容可以看出所分配的下行信道启用了跳频功能。
因此从现象上看,怀疑为其中的载频硬件模块工作不稳定,造成手机不能稳定的捕获(seize)到网络所分配的信道,导致PDP激活失败。
当PDP激活记时器超时后,手机发起第2次PDP激活请求,从网络发送的PacketDownlinkAssignment消息内容看,网络分配的下行信道没有开启跳频功能,并且激活成功。
1.7
PING成功率
一般来说,PING测试的成功率都比较高,在90%以上,但也出现了个别城市该项指标低于80%。
在进行测试时手机与笔记本电脑已连接好,并拨号连接到IP网上,说明PDP已经激活。
因此我们认为原因可能有以下几点:
1)Gb采用帧中继,如果分配时隙过少容易造成Gb接口拥塞
2)Gn和Gi接口由于网络设计不当,造成数据流量过大产生过多冲突
3)路由器相关参数设置不当
1.8
FTP应用层下载速率
在这次测试中,各地的FTP下载速率相比年初时有了很明显的提高,大多都在3KB/S以上,但也有一些城市的指标相对要低些,在2KB/S以下。
我测试数据的后分析中,我们总结出影响FTP下载速慢的原因大致有如下几种:
1)GPRS无线资源局限
2)由于覆盖不好导致频繁小区重选或更新
3)边缘区域的频繁的LA/RAUpdating
4)无线信号质量差导致RLC重传率高
5)网络中CS的设置
6)FTP服务器是否正常工作
以下我们将结合案例进行具体分析。
例一:
某城市CQT测试点希尔顿酒店
现象描述:
以希尔顿酒店为例。
测试次数1次,实际下载数据大小500Kbyte,平均下载速率1.36KB/S,低于CMCC要求的最小下载速率1.5KB/S。
手机一直锁定小区:
LAC=16661,CI=40571,BCCH=06,BSIC=43,没有发生小区重选。
原因分析:
从后台分析软件可以看出,在此次下载的过程中网络只分配了1个下行信道,造成数据下载输率慢。
网络分配信道少的原因除无线资源紧张外,还有就是网络本身的设置问题。
另外从该小区的GSMNeighboringCells窗口(如下图)可以看出,此小区的CellReselection参数CRO为-6dB,可能也是因为小区的话务量大,被人为的减少小区覆盖范围,希望周围小区能够为其分担部分话务。
例二:
某城市CQT测试点21世纪大酒店
现象描述:
以21世纪大酒店为例。
测试次数1次,实际下载数据大小500Kbyte平均下载速率1.48KB/S,低于CMCC要求的最小下载速率1.5KB/S。
原因分析:
从测试的原始数据回放可以看出,测试点的信号覆盖情况比较乱,共有两个小区的信号强度相当,造成手机发生较为频繁的小区重选。
此外这两个小区分别属于两个不同的路由区,小区重选将导致路由区更新过程的发生。
如下图。
另外,在数据下载的过程中还出现了数据误码和数据重传的现象。
因此以上种种原因共同影响了FTP的数据下载的绝对速率,延长了数据下载时间。
1.9
公里掉线比
在此次的GPRS网络评估中,掉线的定义为:
计算机与手机之间的PPP连接断开,即计算机提示拨号连接断开;或尽管PPP连接显示正常但在网络信号良好的情况下超过3分钟不能传输数据(使用PING验证)。
对于因拨号连接断开而造成的掉线,原因可能有以下几方面:
1)Modem中断。
当无线环境差,手机和网络之间消息传递的误码率升高,Modem会降低连接速度和其它相关参数,增强纠错能力,来适应相应的无线环境。
但是通过自身的调节仍无法满足正常的通信要求时,Modem将中断连接。
另外影响Modem正常通信除无线环境质量外,Modem本身质量的好坏也是其中因素之一。
2)GPRS核心网络之间参数设置不当。
由于无线环境差,将引起手机与网络之间一些数据和信令的误码甚至丢失。
这时手机和网络将启动重发机制。
但是由于网络之间的参数设置不当,导致资源的提前释放,重发信息丢失。
3)数据库相邻小区问题。
相邻小区错误或不全,导致小区重选、位置更新和路由区更新失败,引起掉线。
另外,在某些城市出现了较多的因为3分钟无数据传输并且使用PING验证后仍无法继续进行数据下载的掉线情况,在路测中观察到由于小区重选,RR状态处于PacketIdleMode达到一定时长后,由READY到STANDBY的定时器T3314超时,GMM状态就会从READY变为STANDBY。
此时如果进行PING验证,仍然无法让数据继续传输。
根据GPRS小区重选的理论,在GMM状态为READY时,作小区重选时会发CELLUPDATE消息,作路由区重选时会发RAUPDATE消息;但GMM状态为STANDBY时,仅在作路由区重选时发路由区更新消息,小区重选时并不向SGSN作CELLUPDATE。
所以当GMM进入STANDBY后如果进行频繁的小区重选,只要不进行RAUPDATE,SGSN不知道手机所在的小区,这样就会造成传输停止,做PING验证也没有作用,但此时如作话音呼叫,因为话音呼叫结束后手机需要作一次RAUPDATE,SGSN重新获得小区信息,传输又可继续进行。
如下图:
1.10
公里覆盖率
随着GPRS网络多年的建设和完善,基本上各测试城市的室内和室外网络均实现了良好的GPRS信号覆盖,但在个别的城市个别路段,我们还是发现了GPRS手机长时间脱网以及在系统消息中无SystemInformationType13,但在这些地区却有较好的GSM网络信号覆盖,如从测试软件可以观察到手机IMSIAttach成功,但是不能进行GPRSAttach,这说明在这些小区中的GPRS功能还没开通,所以造成了GPRS网络的不连续覆盖的情况。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- GPRS 测试 问题 总结 分析
![提示](https://static.bdocx.com/images/bang_tan.gif)