GPRS业务测试流程及案例分析.ppt

GPRS业务测试流程及案例分析.ppt

《GPRS业务测试流程及案例分析.ppt》由会员分享，可在线阅读，更多相关《GPRS业务测试流程及案例分析.ppt（108页珍藏版）》请在冰点文库上搜索。

GPRS业务测试流程及案例分析,中兴通讯移动事业部2006-12-12,目录,GPRS现状与GPRS业务测试概述GPRS业务测试内容GPRS业务测试工具介绍GPRS专题优化介绍及案例分析,Internet,GPRS数据业务概述,GPRS现状,GPRS是当今世界移动通信技术向第三代迈进的主流技术，是第二代移动通信技术向第三代技术演进的一个非常重要、不可或缺的过程和里程碑，是介于第二代移动通信与第三代移动通信之间的2.5代移动通信技术。

据统计，目前全世界有172个国家的400多个移动通信运营商采用了GSM标准，占全球总数的72%，已有99个国家的移动通信运营商投入了GPRS运营。

其中，在全球移动通信客户排名前10位的移动通信运营商中，已有沃达丰、法国电信和英国电信等7家选用了GPRS技术。

中国移动在分析世界和中国通信的发展形势后，紧跟世界主流技术，选择了GPRS技术，并于1999年开始搭建GPRS实验网。

经过4年多的建设和不断完善,截止到2003年底中国移动GPRS网络已经覆盖全国所有省（市、自治区），网络遍布全国240多个大中城市。

因此,如何保证广大移动用户随时都能方便快捷地使用GPRS成为中国移动运营商的当务之急！

GPRS数据业务概述,GPRS对GSM网络的影响,GPRS的引入对已有的GSM话音业务有一定的影响，这是因为网络干扰增加导致在小区边缘的通信中断概率增加，话音服务面积收缩，越区切换的掉话率有一定程度的升高。

对于话音业务，其网络规划完成以后网络的频率干扰主要决定于频率分配和话务量。

GPRS引入后，增加了GSM信道的利用率，而信道利用率的增加表现为网络干扰的增加。

经实验证明，GPRS业务每增加5%，载干比（C/I）则下降0.21dB，当GPRS业务占用60%信道时，载干比下降2dB。

在GPRS引入的初期，如果采用将PDCH配置在BCCHTRX的策略，则不会对语音业务产生影响，因为此时PDCH属于BCCH频率组，不会对属于其它频率组的TCH产生干扰，同时对属于BCCH频率组的TCH由于载干比较高，因此也不会产生太大影响。

GPRS数据业务概述,GPRS网络优化与GSM网络优化的关系,GPRS网络的优化比GSM网络的优化更为复杂。

GSM网络作为GPRS的承载网，与GPRS共用基站和频谱资源，这就决定了GPRS网络与GSM网络优化相互关联，又相互制约。

首先，GPRS与GSM网络优化在整体上是一致的，加强GSM无线环境的优化工作对于GPRS的优化十分重要。

提升网络整体载干比水平可以使更多的GPRS手机享受高级的编码方案，从而提高系统的吞吐量，使已在CS-2编码方式下的手机进一步减少分组重发的比率，使实际数据传输速率达到最高。

其次，GPRS与GSM无线网络优化又存在冲突。

由GPRS引入的新增干扰，一定程度上使得话音质量下降，切换掉话率提高，进而导致原有话音服务面积缩小。

由于两者使用同一频段资源，因而在容量配置上存在着冲突。

GPRS若采用在CCCH上接入的方式，则CCCH的负荷将有较大的增加。

GPRS引入了灵活的话音、数据信道分配策略，无线资源调度变得更为复杂，将会导致切换次数的增加，因此对原网的接入成功率，切换成功率略有影响。

当GPRS网络优化和GSM网络优化发生冲突时，在现阶段应当以话音业务优先。

GPRS数据业务概述,GPRS服务与用户群体之间的关系,GPRS网络不同于GSM网络,GSM的资源使用方式是独占式使用,一旦资源分配给移动台,在用户挂机之前会一直占用,用户得到的服务质量和其他移动台无关;GPRS的资源使用方式是共享式使用,系统资源要按照QoS和用户的需求进行共享式地动态分配,用户得到的服务质量和其他移动台有直接的关系!

GPRS数据业务测试的影响因素,影响测试指标的外在原因,测试卡类别以及HLR参数的不同测试手机型号以及手机软件版本的不同测试电脑型号、所安装系统软件以及应用软件安装情况的不同测试软件版本的不同测试人员测试方法以及现场判断测试数据可靠性能力的不同,GPRS数据业务测试的影响因素,GPRS业务测试准备,配备全球通测试卡若干，设置测试卡HLR数据如下：

Priority:

HighPriority;DelayClass:

BestEffort;Reliability:

Class3;PeakThroughput:

2048kbit/s;MeanThroughput:

BestEffort测试终端采用SAGEMOT290或SAGEMOT490;测试手机要求K或以上版本;手机设置为自动双频模式;串口速率设置为115200;时隙设置为3+1/4+1模式;测试模式设置为Data/Trace测试软件采用CDS3.0以上版本测试电脑应保证1.2G以上主频，256M以上内存;重新安装WindowsXP操作系统,不能安装与测试无关的软件;将托盘中的任何与网络通讯相关的程序关闭,如MSN等;关闭Windows的自动更新功能,GPRS数据业务测试的影响因素,GPRS业务测试准备,保证Ping和FTP的测试服务器正常工作。

同时应保证用户具有上传和下载数据的权限,保证可对服务器进行Ping和FTP测试被测城市应保证其测试服务器在测试检查期间的可用性，如果当地服务器不能使用，测试人员将选择异地服务器进行测试保证邮件系统的正常工作准备大小为150K，500K的文件若干确认WAP测试站点正常工作,由运营商指定,GPRS数据业务测试原则,CQT测试原则,测试时间：

视客户要求而定，通常安排在周一至周五9:

00-19:

00进行地点选择原则：

1.在城市中选20-40个测试点。

具体测试点分布要求:

火车站、机场、三星级以上酒店、大型商场休闲区、大学学校、大型居民区、商务场所、旅游景区2.测试点按照地理、话务因素综合考虑均匀分布，突出重点区域3.在测试前测量当前位置的无线信号，检查信号强度，确保在该点有GPRS覆盖，避免在测试过程中频繁小区重选（重选次数控制在3-4次之内）,GPRS数据业务测试原则,适用环境：

市区主要道路和重要高速、铁路干线测试时间：

视客户要求而定，通常安排在周一至周五9:

00-19:

00进行测试速度：

在市区保持正常行驶速度，一般车速在30-35公里/小时，在高速公路上车速一般不应低于70公里测试路线：

要求均匀覆盖市区主要街道，并且尽量不重复；环城高速、高架桥、市区到机场公路必须进行测试测试时长：

根据城市的规模来定，也可以根据用户的要求确定每个城市的测试时长,DT测试原则,目录,Internet,GPRS现状与GPRS业务测试概述GPRS业务测试内容GPRS业务测试工具介绍GPRS专题优化介绍及案例分析,GPRS测试项目介绍,GPRS测试目的和分类,测试目的：

通过对市区重要场所和市区主要道路测试，从用户感受的角度评估城市GPRS网络质量，为GPRS网络优化提供参考和依据按照测试形式可以分为两类：

路测（DT，DriveTest）、定点拨打测试（CQT，CallQualityTest）,?

GPRS测试项目介绍,GPRS测试项目,GPRSAttach时延、成功率测试GPRSPDP激活时延、成功率测试Ping时延、成功率测试FTP下载、上传速率WAP登陆、刷新时延、成功率测试WAP下载（图铃）速率、成功率测试Kjava下载成功率测试SMS点到点时延、成功率测试MMSPUSH时延、PUSH成功率、端到端成功率测试,FTP下载、上传速率WAP登陆、刷新时延、成功率测试WAP下载（图铃）速率、成功率测试,CQT,DT,GPRS测试项目介绍,CQT测试内容定义和方法,GPRS测试项目介绍,CQT测试内容定义和方法,GPRS测试项目介绍,CQT测试内容定义和方法,GPRS测试项目介绍,CQT测试内容定义和方法,GPRS测试项目介绍,DT测试内容定义和方法,GPRS测试项目介绍,DT测试内容定义和方法,GPRS测试项目介绍,DT测试内容定义和方法,GPRS测试项目介绍,测试项目超时定义,目录,Internet,GPRS现状与GPRS业务测试概述GPRS业务测试内容GPRS业务测试工具介绍GPRS专题优化介绍及案例分析,GPRS测试软件CDS的使用方法,CDS用户界面,GPRS测试软件CDS的使用方法,CDS软件装载说明,测试中常见问题总结,CDS4.0版本现在还不稳定，在信令解码（比如C/I、RxQual、Ms-TxPower等）中存在一些BUG在采集参数选项中CDS默认只采集GSMC/ITrace和RLC/MACControlMSG,其实LLCMSG等参数选项对事件的分析也能起到一定作用，最好将信令采集完整注意测试用笔记本电脑在安装测试软件前必须重装操作系统，不能安装与测试无关的其它软件;将托盘中的任何与网络通讯相关的程序关闭,如MSN等;关闭Windows的自动更新功能，否则会影响Ping、FTP等所有与数据上传、下载有关的测试项目测试手机各参数一定要设置正确，测试手机必须为K或以上软件版本,测试中常见问题总结,WAP刷新不是刷新首页，而是深度为3的随机刷新准确设置测试项目时间间隔以及超时时间，这些测试项目属性的设置对测试结果有很大影响每个测试点测试前需要重启一下测试手机，这样不仅可以清除缓存空间，也可以使测试手机选择到最好小区WAP图铃下载的URL不同，下载速率的差别也很大WAP测试应以所有文字信息全部显示为准，所以应在WAP测试时去掉设置中的“下载页面中的图标”选项当FTP测试中出现长时间无流量时，可让司机适当降低车速MMS测试中最好选择NOKIA智能手机做为测试终端（不同手机测试测试结果差别很大）,GPRS现状与GPRS业务测试概述GPRS业务测试内容GPRS业务测试工具介绍GPRS专题优化介绍及案例分析,Internet,目录,专题ATTACH问题,Attach优化方法关闭SGSN鉴权检查覆盖防止频繁的小区重选排查干扰，提高C/I检查RACH或AGCH信道配置检查静态PS信道、动态PS信道配置检查GPRSENABLED参数设置检查Gblinksload，调整NSEI配置,专题ATTACH问题,Attach故障案例一:

手机无法登陆GPRS网络,问题描述某区域用户反应不能登陆GPRS网络，检查网络配置无异常，实地测试的确无法登陆GPRS网络。

故障分析进行了GPRS配置数据检查，开通GPRS功能小区的NSEI、NSVI、RAC等各项GPRS参数配置均正确检查BSCBRP板配置，发现有一块BRP板已经配置了21个静态GPRS信道和41个GPRS动态信道，总数超过了每块BRP板上PS信道的配置要求解决方法调整该BRP板上配置的GPRS信道数少于40条（最好不要超过35条），保存配置数据后业务恢复正常。

专题ATTACH问题,Attach故障案例二:

手机无法登陆GPRS网络,问题描述：

在中兴某海外网络，有用户反映手机GPRSAttach不能成功。

现象为手机发送Attachrequest，SGSN返回attachaccept消息，而后面BSC上发信令为LLCunkowninformation。

故障分析：

根据信令流程，BSS侧负责TBF流的建立，后面应为手机和SGSN的透传信令，正常流程应为手机向SGSN发送Attachcomplete。

检查BSC相关数据没有发现问题。

从全局测试来看，与SGSN对接的所有BSC下所带基站都有相同问题情况，初步判断为SGSN侧的问题。

经SGSN的工程师检查，有数据改动，即P-TMSI由原来的enable改为disable。

导致P-TMSI无法分配，用户无法上GPRS。

解决方法：

将P-TMSI由disable调整为enable，故障解决。

专题ATTACH问题,Attach故障案例三:

ATTACH失败,问题：

频繁的小区重选（600216033260021）导致ATTACH时延过长（14.55s）。

解决方案：

提高60021CRH由8dB到10dB,调整60332RXLEVACCESSMIN由10dB到12dB,专题ATTACH问题,Attach故障案例四:

ATTACH失败,问题：

网络向手机发送PacketAccessReject消息作为对PacketResourceRequest消息的应答，此消息中包含“Wait_Indication”域，其值赋予T3172，当手机收到PacketAccessReject消息后，启动T3172，在T3172运行期间，网络不允许手机在同一小区内再次发起分组接入尝试。

该事件由无线资源紧张所致。

解决方案：

扩充静态PS信道。

专题PDP激活问题,PDP激活优化方法关闭SGSN鉴权检查核心网各网元处理能力（DNS解析APN错误或者过慢、GGSN关于APN的配置数据不完整、DHCP或RADIUS服务器故障、HLR和SGSN对通配符APN格式的兼容性问题、SGSN和GGSN的GTP信令的兼容性问题、SGSN构造APN的配置问题、GGSN处理过慢、DNS和GGSN的主备用状态）防止频繁的小区重选排查干扰，提高C/I检查RACH或AGCH信道配置，提高接入和立即指配成功率检查静态PS信道、动态PS信道配置检查Gblinksload，调整NSEI配置检查GPRS参数设置，合理设置DrxTimeMax、MFR、T3168,专题PDP激活问题,PDP故障案例一:

PDP激活失败,问题：

在20022重选到20281后，由于20281AGCH紧张导致。

解决方案：

控制20281覆盖范围，适当增加20281AGCH配置。

专题PDP激活问题,PDP故障案例二:

PDP激活失败,问题：

由于连续发生两次小区重选（CELLID:

10071Channel:

2CELLID:

111Channel:

90CELLID:

114Channel:

512）长时间无时隙分配引起PDP激活失败。

解决方案：

提高60021CRH由6dB到10dB。

专题PDP激活问题,PDP故障案例三:

PDP激活失败,问题：

由于没有申请到PS信道导致PDP激活失败。

解决方案：

增加8540站点的静态PS信道，将MFR由5调整到2。

专题PDP激活问题,PDP故障案例四:

PDP激活失败,问题：

在CQT测试时经常出现偶尔PDP激活时延过长的现象。

经过对10个点100次的PDP激活测试,发现7次时延异常的现象，具体挂表结果如下：

专题PDP激活问题,PDP故障案例四:

PDP激活失败,正常情况下几个接口上的耗时情况如下：

专题PDP激活问题,PDP故障案例四:

PDP激活失败,从几次异常测试结果可以看出，主要耗时是在Gb口以下和Radius与WAP网关间，其中第六次GGSN与Radius间的耗时比较长，是因为GGSN第一次发送的Accountingrequest消息没有被WAP网关接收到，也就是说，我们在WAP网关侧没有看到GGSN第一次发送的Accountingrequest消息，只看到了GGSN第二次重新发送的Accountingrequest消息，而且WAP网关收到后及时给予了响应。

导致这种现象的原因可能是Accountingrequest消息在传输中丢失或者Radius的处理异常。

另外六次则是因为Gb口以下和Radius与WAP网关间的耗时过长。

GGSN向Radius发送AccountingRequest消息，等待Radius的响应，并启动相应的等待定时器，在相应的WAP网关侧，我们发现WAP网关在收到AccountingRequest消息后没有给予响应，由于GGSN没有收到AccountingRequest消息的响应消息，导致等待定时器超时，然后GGSN重新发送AccountingRequest消息，在相应的WAP网关侧，我们发现WAP网关此次给予了响应，GGSN收到Radius转发的AccountingResponse消息，这时GGSN才对手机的PDP激活请求进行响应。

专题PDP激活问题,PDP故障案例四:

PDP激活失败,正是由于Gi口的耗时过长，使得无线侧的定时器超时而释放了TBF资源，所以手机在接收PDP激活接受消息时，重新进行了TBF的建立，这又进一步增加了在无线口上的延时。

因此，WAP网关的响应过慢，是导致PDP激活时延过长根本原因。

专题PDP激活问题,PDP故障案例五:

PDP激活失败,在中国移动集团公司第三方测试的准备工作中，发现GPRSCQT的火车站测试点有PDP激活失败的现象，并且多次测试问题始终存在。

从信令来看，当下行的立即指配信息里出现了右图中ARFCN为809的时候，PDP激活会不成功。

专题PDP激活问题,PDP故障案例五:

PDP激活失败,809这个频点是不正常的，但这是根据手机收到基站发出的层三消息解出来的。

这个立即支配消息是为了分配下行的TBF，也就是意味着网络已收到PDP激活申请且给手机回复了PDPactivateaccept消息，但此消息未能通过空中接口。

当时怀疑是否因测试软件导致，询问CDS软件研发工程师，回复软件应该没有问题，也不像测试手机问题，所以网络下发的消息编码存在问题的可能性比较大。

对同个BSC下的三晋国际饭店测试没有发现同样的问题。

调整频点和无线参数等也没有解决问题，于是怀疑是否为基站的问题。

重启基站，重做基站数据，仍然没有效果。

将天线直接接到BTS机柜上测试看是否是因为分布系统的问题，但在测试中还是存在PDP激活失败，所以也排除分布系统的问题。

对GB口进行挂表测试，出现三次PDP激活失败。

这三次失败在GB口信令中体现为：

MS发给SGSNAPCR,然后SGSN都立即回复一个APAC给MS。

但是在SGSN回复APAC给MS7s8s后,在GB数据里发现了RSTA，在该信令中发现“RadiocontactlostwithMS”的信息，同时还有一个LLCD（=LLC-DISCARDED）的信令。

见下图：

专题PDP激活问题,PDP故障案例五:

PDP激活失败,专题PDP激活问题,PDP故障案例五:

PDP激活失败,总之,虽然在CDS的LOG里存在PDP失败,但是从GB数据里反应出的流程却是完整的,而且SGSN都是在收到MS的APCR后就立即回复了APAC。

因此分析结果表明这几次的PDP激活失败并非由核心网引起，可能是由无线侧导致了手机未能收到SGSN发的APAC而产生TIMEOUT。

由于无线质量、GPRS统计和参数、核心网、分布系统等都没有问题，这时我们把重点放在基站硬件这一侧。

因为8593也会出现闪断，怀疑是否因传输误码率过高而导致，所以要求更换传输，换完传输后进行测试，还是没有效果。

由于在8591测试时PDP激活成功率为100，把8591的BTS和8593的BTS进行调换再测试。

在调换完后的200次PDP激活测试中，8593没有出现一次失败，而原来好的小区8591出现了5次PDP激活失败。

最终更换了8593BTS，问题得到解决。

专题Ping问题,Ping优化方法优化PingServer,将PingServer搬到FW内检查覆盖防止频繁的小区重选排查干扰，提高C/I检查静态PS信道、动态PS信道配置检查Gblinksload，调整NSEI配置检查GPRS参数设置，合理设置DrxTimeMax、MFR、T3168优化测试测试电脑，关闭所有系统软件以及应用软件的自动更新功能,专题Ping问题,Ping故障案例一:

不同时间间隔造成PING时延不同,问题：

Ping测试中时间间隔设置为4s-12s测试结果有很大差别。

经过核心网挂表测试发现Ping时延不稳定是因为测试过程中出现其他一些数据包，这些垃圾数据包是由杀毒软件和一些应用软件自动更新造成的。

解决方案：

重新安装操作系统，不能安装与测试无关的软件，将托盘中的任何与网络通讯相关的程序关闭，关闭Windows的自动更新功能。

专题Ping问题,Ping故障案例二:

Ping失败,问题：

PING失败时误码率很高，查看网管指标发现此时干扰比较严重，但是其他时段几乎没有干扰，基本可以确定该干扰是外部干扰。

解决方案：

查找外部干扰。

专题Ping问题,Ping故障案例三:

Ping失败,问题：

由于小区的C/I低导致较高的BLER（小区BCCHCI5.9）。

查看规划数据，微蜂窝8800、7660、8750是同BCCH。

解决方案：

控制8800、7660、8750覆盖，调整8800、7660、8750频点。

专题WAP问题,WAP优化方法优化WAP网关、移动梦网服务器、Gi口检查覆盖防止频繁的小区重选排查干扰，提高C/I检查静态PS信道、动态PS信道配置检查Gblinksload，调整NSEI配置检查GPRS参数设置，合理设置DrxTimeMax、MFR、T3168优化测试测试电脑，关闭所有系统软件以及应用软件的自动更新功能,专题WAP问题,WAP故障案例一:

WAP刷新失败,问题：

出现WAPreply失败的时候GPRS的质量为6级，从服务小区和邻区的测量来看，存在着邻频的干扰。

解决方案：

更改频点。

专题WAP问题,WAP故障案例一:

WAP图铃下载速率低,问题：

通过分析看出RLC数据重传率高，从OMC统计数据看Gblink的负荷在测试时段已高达64%，从而导致下载速率低。

解决方案：

重新调整NSEI以减低Gblinkload，从而提高GPRSCQT的下载速率。

专题WAP问题,WAP故障案例三:

WAP登陆失败,问题：

在红楼宾馆WAP登陆测试中，通过跟踪Gb口发现，手机上行发送Get（URL=http:

/），网络侧回复了一个PDU，具体内容为：

Yourrequestforaservicecouldnotbefulfilled,pleasetryagainorcontactyouroperatoriftheproblempersists。

这种现象是因为移动梦网服务器出现问题。

解决方案：

与核心网工程师沟通解决。

专题WAP问题,WAP故障案例四:

WAP登陆和刷新时延过长,GB口WAP测试流程,专题WAP问题,WAP故障案例四:

WAP登陆和刷新时延过长,WAP测试信令流程,问题：

信令分析发现，网关在CONNECT到CONNECTREPLY和GET到REPLY间存在响应时延长，需重复发送GET请求,甚至会出现没有响应的情况，尤其是GET与REPLY间经常出现较大的信令时延，有的甚至达到几十秒,对手机访问WAP速度有较大影响。

我们初步认为打开WAP网页时超过20秒以上的大时延基本都是由网关时延引起的。

解决方案：

核心网工程师针对WAP网关进行优化。

专题WAP问题,WAP错误代码含义WTP层协议发生错误,专题WAP问题,WAP错误代码含义WSP层协议发生错误,专题WAP问题,WAP错误代码含义HTTP协议发生错误,专题MMS问题,MMS优化方法优化相关核心网网关及接口、移动Radius到省内检查覆盖防止频繁的小区重选排查干扰，提高C/I检查静态PS信道、动态PS信道配置检查Gblinksload，调整NSEI配置检查GPRS参数设置，合理设置DrxTimeMax、MFR、T3168,专题MMS问题,MMS故障案例一:

MMS发送失败,问题：

通过挂表发现手机首先PDP激活，APN为CMWAP，但是手机随后没有任何发起任何信令。

这种情况是由于手机软件进程吊死所致。

解决方案：

重装手机操作系统。

专题MMS问题,MMS故障案例二:

MMS接收失败,问题：

通过挂表发现手机首先建立了WSP层的连接，然后发起GET请求接收彩信，随后WAP网关将彩信在WTP分割后，向手机发送WTP层的分段，当传送到第六个分段后该消息中的GTR和TTR都为0，说明该分段既不是整个消息中某组的最后一块，也不是整个消息的最后一块，但是手机却回应了ACK，紧接着又发起一个Transaction（Invoke）。

这种情况是由于手机软件故障所致。

解决方案：

重装手机操作系统。

专题MMS问题,MMS故障案例三:

MMS接收失败,问题：

通过Gi口挂表发现手机在发起Get请求后，在10ms左右的时间连续多次重发Get请求（Get请求重发定时器为10