GPRS业务测试流程及案例

《GPRS业务测试流程及案例》由会员分享，可在线阅读，更多相关《GPRS业务测试流程及案例（108页珍藏版）》请在装配图网上搜索。

1、GPRS业务测试流程及案例分析GPRS现状现状GPRS是当今世界移动通信技术向第三代迈进的主流技术，是第二代移动通信技术向第三代技术演进的一个非常重要、不可或缺的过程和里程碑，是介于第二代移动通信与第三代移动通信之间的2.5代移动通信技术。据统计，目前全世界有172个国家的400多个移动通信运营商采用了GSM标准，占全球总数的72%，已有99个国家的移动通信运营商投入了GPRS运营。其中，在全球移动通信客户排名前10位的移动通信运营商中，已有沃达丰、法国电信和英国电信等7家选用了GPRS技术。中国移动在分析世界和中国通信的发展形势后，紧跟世界主流技术，选择了GPRS技术，并于1999年开始搭建

2、GPRS实验网。经过4年多的建设和不断完善,截止到2003年底中国移动GPRS网络已经覆盖全国所有省(市、自治区)，网络遍布全国240多个大中城市。因此,如何保证广大移动用户随时都能方便快捷地使用GPRS成为中国移动运营商的当务之急！GPRS对对GSM网络的影响网络的影响GPRS的引入对已有的GSM话音业务有一定的影响，这是因为网络干扰增加导致在小区边缘的通信中断概率增加，话音服务面积收缩，越区切换的掉话率有一定程度的升高。对于话音业务，其网络规划完成以后网络的频率干扰主要决定于频率分配和话务量。GPRS引入后，增加了GSM信道的利用率，而信道利用率的增加表现为网络干扰的增加。经实验证明，GP

3、RS业务每增加5%，载干比(C/I)则下降0.21dB，当GPRS业务占用60%信道时，载干比下降2dB。在GPRS引入的初期，如果采用将PDCH配置在BCCH TRX的策略，则不会对语音业务产生影响，因为此时PDCH属于BCCH频率组，不会对属于其它频率组的TCH产生干扰，同时对属于BCCH频率组的TCH由于载干比较高，因此也不会产生太大影响。GPRS网络优化与网络优化与GSM网络优化的关系网络优化的关系GPRS网络的优化比GSM网络的优化更为复杂。GSM网络作为GPRS的承载网，与GPRS共用基站和频谱资源，这就决定了GPRS网络与GSM网络优化相互关联，又相互制约。首先，GPRS与GSM

4、网络优化在整体上是一致的，加强GSM无线环境的优化工作对于GPRS的优化十分重要。提升网络整体载干比水平可以使更多的GPRS手机享受高级的编码方案，从而提高系统的吞吐量，使已在CS-2编码方式下的手机进一步减少分组重发的比率，使实际数据传输速率达到最高。其次，GPRS与GSM无线网络优化又存在冲突。由GPRS引入的新增干扰，一定程度上使得话音质量下降，切换掉话率提高，进而导致原有话音服务面积缩小。由于两者使用同一频段资源，因而在容量配置上存在着冲突。GPRS若采用在CCCH上接入的方式，则CCCH的负荷将有较大的增加。GPRS引入了灵活的话音、数据信道分配策略，无线资源调度变得更为复杂，将会导

5、致切换次数的增加，因此对原网的接入成功率，切换成功率略有影响。当GPRS网络优化和GSM网络优化发生冲突时，在现阶段应当以话音业务优先。GPRS服务与用户群体之间的关系服务与用户群体之间的关系GPRS网络不同于GSM网络,GSM的资源使用方式是独占式使用,一旦资源分配给移动台,在用户挂机之前会一直占用,用户得到的服务质量和其他移动台无关;GPRS的资源使用方式是共享式使用,系统资源要按照QoS和用户的需求进行共享式地动态分配,用户得到的服务质量和其他移动台有直接的关系!影响测试指标的外在原因影响测试指标的外在原因 测试卡类别以及 HLR参数的不同测试手机型号以及手机软件版本的不同测试电脑型号、

6、所安装系统软件以及应用软件安装情况的不同测试软件版本的不同测试人员测试方法以及现场判断测试数据可靠性能力的不同GPRS业务测试准备业务测试准备 配备全球通测试卡若干，设置测试卡HLR数据如下：Priority:High Priority;Delay Class:Best Effort;Reliability:Class 3;Peak Throughput:2048kbit/s;Mean Throughput:Best Effort 测试终端采用SAGEM OT290或SAGEM OT490;测试手机要求K或以上版本;手机设置为自动双频模式;串口速率设置为115200;时隙设置为3+1/4+1模

7、式;测试模式设置为Data/Trace 测试软件采用CDS3.0以上版本 测试电脑应保证1.2G以上主频，256M以上内存;重新安装Windows XP 操作系统,不能安装与测试无关的软件;将托盘中的任何与网络通讯相关的程序关闭,如MSN等;关闭Windows的自动更新功能GPRS业务测试准备业务测试准备 保证Ping和FTP的测试服务器正常工作。同时应保证用户具有上传和下载数据的权限,保证可对服务器进行Ping和FTP测试 被测城市应保证其测试服务器在测试检查期间的可用性，如果当地服务器不能使用，测试人员将选择异地服务器进行测试 保证邮件系统的正常工作 准备大小为150K，500K的文件若干

8、 确认WAP测试站点正常工作,由运营商指定CQT测试原则测试原则测试时间：测试时间：视客户要求而定，通常安排在周一至周五 9:00-19:00进行地点选择原则：地点选择原则：1.1.在城市中选20-40个测试点。具体测试点分布要求:火车站、机场、三星级以上酒店、大型商场休闲区、大学学校、大型居民区、商务场所、旅游景区 2.2.测试点按照地理、话务因素综合考虑均匀分布，突出重点区域 3.3.在测试前测量当前位置的无线信号，检查信号强度，确保在该点有GPRS覆盖，避免在测试过程中频繁小区重选（重选次数控制在3-4次之内)适用环境适用环境：市区主要道路和重要高速、铁路干线测试时间测试时间：视客户要求

9、而定，通常安排在周一至周五 9:00-19:00进行测试速度：测试速度：在市区保持正常行驶速度，一般车速在30-35公里/小时，在高速公路上车速一般不应低于70公里测试路线：测试路线：要求均匀覆盖市区主要街道，并且尽量不重复；环城高速、高架桥、市区到机场公路必须进行测试测试时长：测试时长：根据城市的规模来定，也可以根据用户的要求确定每个城市的测试时长DT测试原则测试原则GPRS测试目的和分类测试目的和分类测试目的：通过对市区重要场所和市区主要道路测试，从用户感受的角度评估城市GPRS网络质量，为GPRS网络优化提供参考和依据按照测试形式可以分为两类：路测（DT，Drive Test）、定点拨打

10、测试(CQT，Call Quality Test)?GPRS测试项目测试项目GPRS Attach时延、成功率测试GPRS PDP激活时延、成功率测试Ping时延、成功率测试FTP下载、上传速率WAP登陆、刷新时延、成功率测试WAP下载(图铃)速率、成功率测试Kjava下载成功率测试SMS点到点时延、成功率测试MMS PUSH时延、PUSH成功率、端到端成功率测试FTP下载、上传速率WAP登陆、刷新时延、成功率测试WAP下载(图铃)速率、成功率测试CQT DTCQT测试测试内容定义和方法内容定义和方法KPIKPI定定 义义测试方法测试方法精度精度统计粒统计粒度度ATTACH平均附着时长各次at

11、tach成功的时间相加/成功attach的次数 使用测试终端和测试软件，自动记录测试日志,由测试软件统计功能给出0.01秒10次ATTACH附着成功率GPRS成功Attach次数/总尝试次数100 使用测试终端和测试软件，自动记录测试日志,由测试软件统计功能给出0.01%10次PDP激活平均时长各次PDP激活成功的时间相加/成功attach的次数使用测试终端和测试软件，自动记录测试日志,由测试软件统计功能给出0.01秒10次PDP激活成功率GPRS成功PDP激活次数/总尝试次数100 使用测试终端和测试软件，自动记录测试日志,由测试软件统计功能给出0.01%10次各次ping成功的时间相加/p

12、ing成功的次数 使用测试终端和测试软件，自动记录测试日志,由测试软件统计功能给出0.01秒CQT测试测试内容定义和方法内容定义和方法KPIKPI定定 义义测试方法测试方法精度精度统计粒统计粒度度WAP平均首页显示时间各次WAP首页成功显示的时间相加/WAP首页显示成功次数 使用测试终端和测试软件，自动记录测试日志,由测试软件统计功能给出0.01秒10次WAP首页登陆成功率WAP首页显示成功次数/尝试WAP登陆次数100使用测试终端和测试软件，自动记录测试日志,由测试软件统计功能给出0.01%10次WAP平均页面刷新时间各次WAP刷新成功显示的时间相加/WAP刷新成功显示次数使用测试终端和测试

13、软件，自动记录测试日志,由测试软件统计功能给出0.01秒10次WAP页面刷新成功率WAP页面刷新成功次数/尝试页面刷新次数100使用测试终端和测试软件，自动记录测试日志,由测试软件统计功能给出0.01%10次WAP平均图铃下载速率 实际成功下载数据量（Byte）/实际成功下载时间(秒)使用测试终端和测试软件，自动记录测试日志,由测试软件统计功能给出0.01KBit/SKPIKPI定定 义义测试方法测试方法精度精度统计统计粒度粒度FTP下载速率 实际下载数据量（Byte）/实际下载时间(秒)使用测试终端和测试软件，自动记录测试日志,由测试软件统计功能给出0.01KB/S1次FTP上传速率实际上传

14、数据量（Byte）/实际下载时间(秒)使用测试终端和测试软件，自动记录测试日志,由测试软件统计功能给出0.01KB/S1次Kjava下载成功率下载成功次数/下载测试总次数100%使用测试终端和测试软件，自动记录测试日志,由测试软件统计功能给出0.01%5次MMS端到端PUSH平均时长各次PUSH成功的时间相加/成功PUSH的次数使用测试终端和测试软件，自动记录测试日志,由测试软件统计功能给出0.01秒10次MMS端到端PUSH成功率用户成功接收PUSH消息条数用户应接收PUSH消息条数100 使用测试终端和测试软件，自动记录测试日志,由测试软件统计功能给出CQT测试测试内容定义和方法内容定义和

15、方法KPIKPI定定 义义测试方法测试方法精度精度统计粒统计粒度度SMS端到端PUSH平均时长各次短信接收成功的时间相加/短信成功接收的次数使用测试终端和测试软件，自动记录测试日志,由测试软件统计功能给出0.01秒10次SMS端到端PUSH成功率用户成功接收短信条数用户应接收短信条数100 使用测试终端和测试软件，自动记录测试日志,由测试软件统计功能给出0.01%10次CQT测试测试内容定义和方法内容定义和方法DT测试测试内容定义和方法内容定义和方法KPIKPI定定 义义测试方法测试方法精度精度FTP下载速率 实际下载数据量（Byte）/实际下载时间(秒)使用测试终端和测试软件，自动记录测试日

16、志,由测试软件统计功能给出0.01KB/SFTP上传速率实际上传数据量（Byte）/实际下载时间(秒)使用测试终端和测试软件，自动记录测试日志,由测试软件统计功能给出0.01KB/SWAP平均首页显示时间各次WAP首页成功显示的时间相加/WAP首页显示成功次数 使用测试终端和测试软件，自动记录测试日志,由测试软件统计功能给出0.01秒WAP首页登陆成功率WAP首页显示成功次数/尝试WAP登陆次数100使用测试终端和测试软件，自动记录测试日志,由测试软件统计功能给出0.01%WAP平均页面刷新时间WAP页面刷新成功指被选择浏览的页面在60秒内文本信息完整正确的显示时长使用测试终端和测试软件，自动

17、记录测试日志,由测试软件统计功能给出0.01秒WAP页面刷新成功率WAP页面刷新成功次数/尝试页面刷新次数100使用测试终端和测试软件，自动记录测试日志,由测试软件统计功能给出0.01%KPIKPI定定 义义测试方法测试方法精度精度WAP平均图铃下载速率 实际成功下载数据量（Byte）/实际成功下载时间(秒)使用测试终端和测试软件，自动记录测试日志,由测试软件统计功能给出0.01KBit/SWAP图铃下载成功率 WAP铃声、图片成功下载次数/尝试铃声、图片下载次数100 使用测试终端和测试软件，自动记录测试日志,由测试软件统计功能给出0.01%覆盖率 GPRS覆盖公里数/总测试距离（Km）10

18、0%使用测试终端和测试软件，自动记录测试日志,由测试软件统计功能给出0.01%掉线率 掉线次数/总FTP下载尝试次数100%使用测试终端和测试软件，自动记录测试日志,由测试软件统计功能给出0.01%使用测试终端和测试软件，自动记录测试日志,由测试软件统计功能给出DT测试测试内容定义和方法内容定义和方法KPIKPI定定 义义测试方法测试方法精度精度平均RAU间隔距离 总RAU次数/总测试距离使用测试终端和测试软件，自动记录测试日志,由测试软件统计功能给出0.01km平均小区重选间隔时间 总小区重选次数/总测试时间使用测试终端和测试软件，自动记录测试日志,由测试软件统计功能给出0.01秒平均小区重

19、选间隔距离 总小区重选次数/总测试距离使用测试终端和测试软件，自动记录测试日志,由测试软件统计功能给出0.01kmDT测试测试内容定义和方法内容定义和方法测试测试项目项目超时定义超时定义KPIKPI超时时间超时时间KPIKPI超时时间超时时间ATTACH附着时长15SFTP下载时长(CQT)180SPDP激活时长15SFTP下载时长(DT)180SMMS接收时长100S(有些设置为150S)SMS接收时长300SPing时长5SKjava下载时长300SWAP首页显示时间(CQT)60SWAP首页显示时间(DT)60SWAP页面刷新时间(CQT)60SWAP页面刷新时间(DT)60SWAP图铃

20、下载时长(CQT)150SWAP图铃下载时长(DT)200SGPRS测试软件CDS的使用方法CDS用户界面用户界面GPRS测试软件CDS的使用方法CDS软件装载说明软件装载说明测试中常见问题总结CDS 4.0版本现在还不稳定，在信令解码（比如C/I、RxQual、Ms-TxPower等）中存在一些BUG在采集参数选项中CDS默认只采集GSM C/I Trace和RLC/MAC Control MSG,其实LLC MSG等参数选项对事件的分析也能起到一定作用，最好将信令采集完整注意测试用笔记本电脑在安装测试软件前必须重装操作系统，不能安装与测试无关的其它软件;将托盘中的任何与网络通讯相关的程序关

21、闭,如MSN等;关闭Windows的自动更新功能，否则会影响Ping、FTP等所有与数据上传、下载有关的测试项目测试手机各参数一定要设置正确，测试手机必须为K或以上软件版本测试中常见问题总结WAP刷新不是刷新首页，而是深度为3的随机刷新准确设置测试项目时间间隔以及超时时间，这些测试项目属性的设置对测试结果有很大影响每个测试点测试前需要重启一下测试手机，这样不仅可以清除缓存空间，也可以使测试手机选择到最好小区WAP图铃下载的URL不同，下载速率的差别也很大WAP测试应以所有文字信息全部显示为准，所以应在WAP测试时去掉设置中的“下载页面中的图标”选项 当FTP测试中出现长时间无流量时，可让司机适

22、当降低车速MMS测试中最好选择NOKIA智能手机做为测试终端（不同手机测试测试结果差别很大）专题ATTACH问题qAttach优化方法优化方法关闭SGSN鉴权检查覆盖防止频繁的小区重选排查干扰，提高C/I检查RACH或AGCH信道配置检查静态PS信道、动态PS信道配置检查GPRS ENABLED参数设置检查Gb links load，调整NSEI配置 专题ATTACH问题Attach故障案例一故障案例一:手机无法登陆手机无法登陆GPRS网络网络p 问题描述问题描述 某区域用户反应不能登陆GPRS网络，检查网络配置无异常，实地测试的确无法登陆GPRS网络。p 故障分析故障分析 进行了GPRS配置

23、数据检查，开通GPRS功能小区的NSEI、NSVI、RAC等各项GPRS参数配置均正确 检查BSC BRP板配置，发现有一块BRP板已经配置了21个静态GPRS信道和41个GPRS动态信道，总数超过了每块BRP板上PS信道的配置要求p 解决方法解决方法 调整该BRP板上配置的GPRS信道数，保存配置数据后业务恢复正常。专题ATTACH问题Attach故障案例二故障案例二:手机无法登陆手机无法登陆GPRS网络网络p 问题描述：问题描述：有用户反映手机GPRS Attach 不能成功。现象为手机发送Attach request，SGSN 返回attach accept 消息，而后面BSC上发信令为

24、LLC unkown information。p 故障分析：故障分析：根据信令流程，BSS侧负责TBF流的建立，后面应为手机和SGSN的透传信令，正常流程应为手机向SGSN发送Attach complete。检查BSC相关数据没有发现问题。从全局测试来看，与SGSN对接的所有BSC下所带基站都有相同问题情况，初步判断为SGSN侧的问题。经SGSN的工程师检查，有数据改动，即P-TMSI 由原来的enable 改为disable。导致P-TMSI无法分配，用户无法上GPRS。p 解决方法：解决方法：将P-TMSI由disable调整为enable，故障解决。专题ATTACH问题Attach故障案

25、例三故障案例三:ATTACH失败失败问题：问题：频繁的小区重选（600216033260021）导致ATTACH时延过长（14.55s）。解决方案：解决方案：提高60021CRH由8dB到10dB,调整60332RXLEVACCESSMIN由10dB到12dB 专题ATTACH问题Attach故障案例四故障案例四:ATTACH失败失败问题：问题：网络向手机发送Packet Access Reject消息作为对Packet Resource Request消息的应答，此消息中包含“Wait_Indication”域，其值赋予T3172，当手机收到Packet Access Reject消息后，启

26、动T3172，在T3172运行期间，网络不允许手机在同一小区内再次发起分组接入尝试。该事件由无线资源紧张所致。解决方案：解决方案：扩充静态PS信道。专题PDP激活问题qPDP激活优化方法激活优化方法关闭SGSN鉴权检查核心网各网元处理能力（DNS解析APN错误或者过慢、GGSN关于APN的配置数据不完整、DHCP或RADIUS服务器故障、HLR和SGSN对通配符APN格式的兼容性问题、SGSN和GGSN的GTP信令的兼容性问题、SGSN构造APN的配置问题、GGSN处理过慢、DNS和GGSN的主备用状态）防止频繁的小区重选排查干扰，提高C/I检查RACH或AGCH信道配置，提高接入和立即指配成

27、功率检查静态PS信道、动态PS信道配置检查Gb links load，调整NSEI配置检查GPRS参数设置，合理设置DrxTimeMax、MFR、T3168专题PDP激活问题PDP故障案例一故障案例一:PDP激活失败激活失败问题：问题：在20022重选到20281后，由于20281AGCH紧张导致。解决方案：解决方案：控制20281覆盖范围，适当增加20281AGCH配置。专题PDP激活问题PDP故障案例二故障案例二:PDP激活失败激活失败问题：问题：由于连续发生两次小区重选（CELLID:10071 Channel:2CELLID:111 Channel:90CELLID:114 Chann

28、el: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激活失败激活失败正常情况下几

29、个接口上的耗时情况如下：专题PDP激活问题PDP故障案例四故障案例四:PDP激活失败激活失败从几次异常测试结果可以看出，主要耗时是在Gb口以下和Radius与WAP网关间，其中第六次GGSN与Radius间的耗时比较长，是因为GGSN第一次发送的Accounting request消息没有被WAP网关接收到，也就是说，我们在WAP网关侧没有看到GGSN第一次发送的Accounting request消息，只看到了GGSN第二次重新发送的Accounting request消息，而且WAP网关收到后及时给予了响应。导致这种现象的原因可能是Accounting request消息在传输中丢失或者R

30、adius的处理异常。另外六次则是因为Gb口以下和Radius与WAP网关间的耗时过长。GGSN向Radius发送Accounting Request消息，等待Radius的响应，并启动相应的等待定时器，在相应的WAP网关侧，我们发现WAP网关在收到Accounting Request消息后没有给予响应，由于GGSN没有收到Accounting Request消息的响应消息，导致等待定时器超时，然后GGSN重新发送Accounting Request消息，在相应的WAP网关侧，我们发现WAP网关此次给予了响应，GGSN收到Radius转发的Accounting Response消息，这时GGS

31、N才对手机的PDP激活请求进行响应。专题PDP激活问题PDP故障案例四故障案例四:PDP激活失败激活失败正是由于Gi口的耗时过长，使得无线侧的定时器超时而释放了TBF资源，所以手机在接收PDP激活接受消息时，重新进行了TBF的建立，这又进一步增加了在无线口上的延时。因此，WAP网关的响应过慢，是导致PDP激活时延过长根本原因。专题PDP激活问题PDP故障案例五故障案例五:PDP激活失败激活失败在中国移动集团公司第三方测试的准备工作中，发现GPRS CQT的火车站测试点有PDP激活失败的现象，并且多次测试问题始终存在。从信令来看，当下行的立即指配信息里出现了右图中ARFCN为809的时候，PDP

32、激活会不成功。专题PDP激活问题PDP故障案例五故障案例五:PDP激活失败激活失败809这个频点是不正常的，但这是根据手机收到基站发出的层三消息解出来的。这个立即支配消息是为了分配下行的TBF，也就是意味着网络已收到PDP激活申请且给手机回复了PDP activate accept消息，但此消息未能通过空中接口。当时怀疑是否因测试软件导致，询问CDS软件研发工程师，回复软件应该没有问题，也不像测试手机问题，所以网络下发的消息编码存在问题的可能性比较大。对同个BSC下的三晋国际饭店测试没有发现同样的问题。调整频点和无线参数等也没有解决问题，于是怀疑是否为基站的问题。重启基站，重做基站数据，仍然没

33、有效果。将天线直接接到BTS机柜上测试看是否是因为分布系统的问题，但在测试中还是存在PDP激活失败，所以也排除分布系统的问题。对GB口进行挂表测试，出现三次PDP激活失败。这三次失败在GB口信令中体现为：MS发给SGSN APCR,然后SGSN都立即回复一个APAC给MS。但是在SGSN回复APAC给MS 7s8s后,在GB数据里发现了RSTA，在该信令中发现“Radio contact lost with MS”的信息，同时还有一个LLCD(=LLC-DISCARDED)的信令。见下图：专题PDP激活问题PDP故障案例五故障案例五:PDP激活失败激活失败专题PDP激活问题PDP故障案例五故障

34、案例五:PDP激活失败激活失败总之,虽然在CDS的LOG里存在PDP失败,但是从GB数据里反应出的流程却是完整的,而且SGSN都是在收到MS的APCR后就立即回复了APAC。因此分析结果表明这几次的PDP激活失败并非由核心网引起，可能是由无线侧导致了手机未能收到SGSN发的APAC而产生TIMEOUT。由于无线质量、GPRS统计和参数、核心网、分布系统等都没有问题，这时我们把重点放在基站硬件这一侧。因为8593也会出现闪断，怀疑是否因传输误码率过高而导致，所以要求更换传输，换完传输后进行测试，还是没有效果。由于在8591测试时PDP激活成功率为100，把8591的BTS和8593的BTS进行调

35、换再测试。在调换完后的200次PDP激活测试中，8593没有出现一次失败，而原来好的小区8591出现了5次PDP激活失败。最终更换了8593BTS，问题得到解决。专题Ping问题qPing优化方法优化方法优化Ping Server,将Ping Server搬到FW内检查覆盖防止频繁的小区重选排查干扰，提高C/I检查静态PS信道、动态PS信道配置检查Gb links load，调整NSEI配置检查GPRS参数设置，合理设置DrxTimeMax、MFR、T3168优化测试测试电脑，关闭所有系统软件以及应用软件的自动更新功能专题Ping问题Ping故障案例一故障案例一:不同时间间隔造成不同时间间隔造

36、成PING时延不同时延不同问题：问题：Ping测试中时间间隔设置为4s-12s测试结果有很大差别。经过核心网挂表测试发现Ping时延不稳定是因为测试过程中出现其他一些数据包，这些垃圾数据包是由杀毒软件和一些应用软件自动更新造成的。解决方案：解决方案：重新安装操作系统，不能安装与测试无关的软件，将托盘中的任何与网络通讯相关的程序关闭，关闭Windows的自动更新功能。专题Ping问题Ping故障案例二故障案例二:Ping失败失败问题：问题：PING失败时误码率很高，查看网管指标发现此时干扰比较严重，但是其他时段几乎没有干扰，基本可以确定该干扰是外部干扰。解决方案：解决方案：查找外部干扰。专题Pi

37、ng问题Ping故障案例三故障案例三:Ping失败失败问题：问题：由于小区的C/I低导致较高的BLER（小区BCCH CI5.9）。查看规划数据，微蜂窝8800、7660、8750是同BCCH。解决方案：解决方案：控制8800、7660、8750覆盖，调整8800、7660、8750频点。专题WAP问题qWAP优化方法优化方法优化WAP网关、移动梦网服务器、Gi口检查覆盖防止频繁的小区重选排查干扰，提高C/I检查静态PS信道、动态PS信道配置检查Gb links load，调整NSEI配置检查GPRS参数设置，合理设置DrxTimeMax、MFR、T3168优化测试测试电脑，关闭所有系统软件以

38、及应用软件的自动更新功能专题WAP问题WAP故障案例一故障案例一:WAP刷新失败刷新失败问题：问题：出现WAP reply失败的时候GPRS的质量为6级，从服务小区和邻区的测量来看，存在着邻频的干扰。解决方案：解决方案：更改频点。专题WAP问题WAP故障案例一故障案例一:WAP图铃下载速率低图铃下载速率低问题：问题：通过分析看出RLC数据重传率高，从OMC统计数据看Gb link的负荷在测试时段已高达64%，从而导致下载速率低。解决方案：解决方案：重新调整NSEI以减低Gb link load，从而提高GPRS CQT的下载速率。专题WAP问题WAP故障案例三故障案例三:WAP登陆失败登陆失败

39、问题：问题：在*宾馆WAP登陆测试中，通过跟踪Gb口发现，手机上行发送Get(URL=http:/)，网络侧回复了一个PDU，具体内容为：Your request for a service could not be fulfilled,please try again or contact your operator if the problem persists。这种现象是因为移动梦网服务器出现问题。解决方案：解决方案：与核心网工程师沟通解决。专题WAP问题WAP故障案例四故障案例四:WAP登陆和刷新时延过长登陆和刷新时延过长GB口口WAP测试流程测试流程专题WAP问题WAP故障案例四故障

40、案例四:WAP登陆和刷新时延过长登陆和刷新时延过长 MI SC Accounting Res.Accounting Req Access Accept Access Request Active PDP context accept Active PDP context request Attach accept Attach request Ack Reply get Ack Connect reply GPRS核 心网 W ap 网关 Connect SP get Reply PCU RAD I US WAP测试信令流程测试信令流程问题：问题：信令分析发现，网关在CONNECT到CONNE

41、CT REPLY和GET到REPLY间存在响应时延长，需重复发送GET请求,甚至会出现没有响应的情况，尤其是GET与REPLY间经常出现较大的信令时延，有的甚至达到几十秒,对手机访问WAP速度有较大影响。我们初步认为打开WAP网页时超过20秒以上的大时延基本都是由网关时延引起的。解决方案：解决方案：核心网工程师针对WAP网关进行优化。专题WAP问题WAP错误代码含义错误代码含义WTP层协议发生错误层协议发生错误 专题WAP问题WAP错误代码含义错误代码含义WSP层协议发生错误层协议发生错误 专题WAP问题WAP错误代码含义错误代码含义HTTP协议发生错误协议发生错误 专题MMS问题qMMS优化

42、方法优化方法优化相关核心网网关及接口、移动Radius到省内检查覆盖防止频繁的小区重选排查干扰，提高C/I检查静态PS信道、动态PS信道配置检查Gb links load，调整NSEI配置检查GPRS参数设置，合理设置DrxTimeMax、MFR、T3168专题MMS问题MMS故障案例一故障案例一:MMS发送失败发送失败问题：通过挂表发现手机首先PDP激活，APN为CMWAP，但是手机随后没有任何发起任何信令。这种情况是由于手机软件进程吊死所致。解决方案：重装手机操作系统。专题MMS问题MMS故障案例二故障案例二:MMS接收失败接收失败问题：通过挂表发现手机首先建立了WSP层的连接，然后发起G

43、ET请求接收彩信，随后WAP网关将彩信在WTP分割后，向手机发送WTP层的分段，当传送到第六个分段后该消息中的GTR和TTR都为0，说明该分段既不是整个消息中某组的最后一块，也不是整个消息的最后一块，但是手机却回应了ACK，紧接着又发起一个Transaction(Invoke)。这种情况是由于手机软件故障所致。解决方案：重装手机操作系统。专题MMS问题MMS故障案例三故障案例三:MMS接收失败接收失败问题：通过Gi口挂表发现手机在发起Get请求后，在10ms左右的时间连续多次重发Get请求（Get请求重发定时器为10s），导致WAP网关来不得处理手机的Session，从重发时间间隔来看，不可能

44、是手机连续接收彩信。这种情况是由于手机软件故障所致。解决方案：重装手机操作系统。专题MMS问题MMS故障案例四故障案例四:MMS发送失败发送失败问题：通过挂表我们发现手机首先上行发送WSP 层的Connect 信令，建WSP 层的连接，但是WAP 网关没有回应Connect Reply，手机等待5 秒后重Connect，但是始终没有回应Connect Reply，达到最大重发次数5 次后，WSP 层的建链失败，最终导致彩信发送失败。导致此次MMS发送失败的原因为WAP网关过于繁忙没有回应Connect Reply。解决方案：请核心网工程师配合解决。专题FTP问题qFTP优化方法优化方法优化FT

45、P Server，将FTP Server搬到FW内 检查覆盖防止频繁的小区重选排查干扰，提高C/I检查静态PS信道、动态PS信道配置检查Gb links load，调整NSEI配置调整DLB、ULB、DLBH、ULBH参数，动态调整CS的比例 检查GPRS参数设置，合理设置DrxTimeMax、MFR、T3168、T3192打开CS3、CS4专题FTP问题FTP故障案例一故障案例一:FTP下载失败下载失败问题：问题：MS 重选到小区41921后，DL TBF一直没被建立导致长时间下行无数据传输，最终导致了PDP掉线.经检查该小区在测试时间段内的GPRS KPI：下行时隙分配拥塞率比较高，这是为

46、什么没能建立DL TBF的主要原因所在。解决方案：解决方案：增加该小区静态PS信道。专题FTP问题FTP故障案例二故障案例二:FTP下载速率过低下载速率过低问题：问题：第一次cell reselection（9052）使数据传输恢复时间变长而导致长时间TBF挂起。之后重建时由于小区30553数据业务繁忙只申请到一条PS信道，在数据下传过程中又发生了第二次cell reselection（5280），然后因为数据传输恢复时间变长而导致长时间TBF挂起。在重建时小区30152数据业务繁忙导致一直申请不到下行的PS信道导致三次PING失败，最终申请到了4条PS信道，下载成功。导致平均下载速率只有8.

47、11kbit/s。解决方案：解决方案：扩充30553、30152静态PS信道；调整30553RXLEVACCESSMIN由10到12。专题FTP问题FTP故障案例三故障案例三:FTP下载失败下载失败问题：问题：MS从43372重选到42093后，又从42093重选到1531后又频繁重选回1531后，电平降到-94dBm，拖了一段时间后PDP掉线。解决方案：解决方案：控制42093、1531覆盖。专题FTP问题FTP故障案例四故障案例四:FTP下载失败下载失败问题：问题：MS跨LAC从83重选到1483后，就频繁的小区重选148318621741，导致长时间的TBF挂起，最终PDP掉线。从地形看

48、，该处是一座立交桥，桥下无主控区。解决方案：解决方案：调整1483 CRH由6到10，确定该地点的主控小区。专题FTP问题FTP故障案例五故障案例五:FTP下载速率低下载速率低问题：问题：MS拿到的PDCH不稳定，跳变频繁，PS争抢频繁，导致了DL FTP速率低。解决方案：解决方案：增加CI2631的静态PS信道。专题FTP问题FTP故障案例六故障案例六:FTP下载速率低下载速率低案例说明：案例说明：在*路和*桥路附近，手机从宏站小区重选至室外微蜂窝52484（八万人体育馆），BCCH109。由于室外微蜂窝主要是针对某个热点地区，或者覆盖比较差的区域采用的覆盖方式。我们在GPRS测试时，车经过

49、室外微蜂窝的时间比较短，尽量不要让手机重选至这样的小区，这样会增加小区重选的次数和减少吞吐量。在这个案例中，我们发现这个小区主要是覆盖八万人体育场的外场，所以我们鼓励慢速移动的手机占用此小区，快速移动的手机不要重选进这样的小区。52484参数设置为：PET=20s，TEO=0。为了保证手机在一段时间内不重选进此小区，设置PET20s，TEO30db，即在52484的信号出现在MS的邻区20s内给C2一个人为的衰减值30db，使其他小区的C1，C2大过本小区5s，这样手机即不会选进室外微蜂窝。专题FTP问题FTP故障案例六故障案例六:FTP下载速率低下载速率低专题FTP问题FTP故障案例六故障案

50、例六:FTP下载速率低下载速率低问题：问题：在复测时我们发现，在同一个地点，此时52484的C1=25，C221，从15:40:33.764至15:53:586持续20s后，C2值升至53。由于复测时，车行驶的地方为一个交通灯口，车流量大、拥堵。我们原先设置的PET20s远远小于堵车的时间。解决方案：解决方案：将这个小区的PET设置为200s，这样小区重选发生的可能性就大大降低了。专题高BLERBLER概述概述BLER反应信道受干扰的情况，但在小数据传输中可以看到下行BLER总是比较高，重传的BLOCK中很大的一部分是由于PCU的无线传输特性决定的，PCU在下行传输时，判断数据是否快要发送完了

51、，在数据快要结束前N个BLOCK(N由PCU参数决定)的时候确定TBF快要结束，在下行TBF的结尾处最后的一个BLOCK发送之后而在对它的确认包回来之前，PCU重复发送这些未确认的BLOCK直到收到确认包。此时如果发生该BLOCK的接收错误，手机可以马上从后面的BLOCK中获得而不必要求重传，手机在计算BLER的时候把这部分BLOCK也计算在内，从而导致BLER的计算值比较高，因此小数据传输下行BLER并不代表系统真正的无线性能，在大数据量传输时的BLER可以真实的反映出系统的无线性能。测试中同时观察C/I、质量、手机发射功率、重传率以及信道的RLC层速率，这些都是反应信道质量的重要指标。专题

52、高BLERBLER案例案例1内部干扰问题内部干扰问题问题：问题：是该站点覆盖小区，但是高BLER。解决方案：解决方案：更改GTRX或者更换频点。专题高BLERBLER案例案例2小区重选问题小区重选问题问题：问题：已经越过了该小区的主控范围，但是不向邻小区重选。解决方案：解决方案：调高该邻小区的CRH。专题小区重选问题小区重选的时候手机会暂时中断数据传输，在这里数据中断的时长主要包括：重选后数据暂停的时间、TCP Slow Start启动的时间，这一过程大约需要410秒，直至TCP正常传输。路测过程中，要特别注意观察，是否有频繁小区重选或乒乓小区重选发生，小区信号覆盖过小或不稳定都会导致频繁、乒

53、乓小区重选，同时还要注意观察，是否由于小区重选参数设置不合理导致过覆盖，这里注意对CRO、CRH等相关参数的调整。TCP Slow Start过程，在小区重选后数据暂停的时长约410秒，手机在新小区驻留后需要0.55秒的时间获得资源分配，如果有资源可以分配的话，此时手机已经有少量数据的发送和接收（通过IP分析软件观察），此时使用PING来检验就可以看到GPRS连接已经恢复。在TCP的数据连接恢复过程中再次发生的小区重选会严重影响给TCP的数据连接恢复。小区重选与路由更新概述小区重选与路由更新概述专题小区重选与路由更新问题小区重选与路由更新概述小区重选与路由更新概述小区重选的时候手机会暂时中断数

54、据传输，在这里数据中断的时长主要包括：重选后数据暂停的时间、TCP Slow Start启动的时间，这一过程大约需要410秒，直至TCP正常传输。路测过程中，要特别注意观察，是否有频繁小区重选或乒乓小区重选发生，小区信号覆盖过小或不稳定都会导致频繁、乒乓小区重选，同时还要注意观察，是否由于小区重选参数设置不合理导致的过覆盖现象，这里注意对CRO、CRH等相关参数的调整。TCP Slow Start过程，在小区重选后数据暂停的时长约410秒，手机在新小区驻留后需要0.55秒的时间获得资源分配，如果有资源可以分配的话，此时手机已经有少量数据的发送和接收（通过IP分析软件观察），此时使用PING来检

55、验就可以看到GPRS连接已经恢复。在TCP的数据连接恢复过程中再次发生的小区重选会严重影响TCP数据连接的恢复。专题小区重选与路由更新问题DT测试中会发生小区重选，在重选后的数据中断和恢复期间数据量非常小，TCP慢启动之后，数据传输恢复。恢复时间长度不一，这和重选时TCP数据传输当时的具体情况有关，一般410秒，极端恶劣情况下达12分钟，但此时如果停止行驶，数据传输会在短时间内恢复。FTP的数据传输在经历RAU的时候同时也进行了小区重选，此时的数据中断情况同小区重选一样，在RAU之后继续的小区重选也会给TCP的数据连接恢复带来负作用，路测过程中应观察重要路段或重要场所是否有不合理的RAU事件发

56、生。在RAU之后可以使用PING来验证GPRS承载已经恢复。小区重选与路由更新概述小区重选与路由更新概述专题小区重选与路由更新问题小区重选案例小区重选案例1C2参数设置不合理问题参数设置不合理问题问题：问题：车辆沿机场高速从北向南行驶，红圈处占用小区高教科研4（BCCH：560）。继续南行，高教科研4的电平逐渐降低，低至94dBm以下时，仍不发生小区重选。长时间电平小于94dBm，造成无覆盖。经检查发现此时该小区与相邻小区的小区重选参数设置情况如下：专题小区重选与路由更新问题小区重选案例小区重选案例1C2参数设置不合理问题参数设置不合理问题 小区名小区名Rexlev（dBm）RXLEVACCE

57、SSMINCRHCROTOC2高教科高教科研研4-103-100826023下墟下墟3-80-10088028殷巷殷巷3-84-100810026解决方案：控制小区解决方案：控制小区高教科研4（BCCH：560）的覆盖，修改高教科研4小区CRO由26到20。专题小区重选与路由更新问题路由更新案例路由更新案例1跨越跨越SGSN路由区更新故障路由区更新故障 每次穿越RAC区时，都发生掉线，且都伴随着RAU Failure。通过仔细分析，SGSN内的数据错误是导致这种路由更新失败的原因。关系GPRS路由更新的参数主要有3部分，即：(1)每个MSC到SGSN的归属位置 (2)每个BSC到MSC的归属位

58、置 (3)每个小区的归属的RAC区以上3个参数必须与现行网络中硬件设备的连接一致才能保证GPRS手机路由更新的正常进行。专题NSEI规划NSEI规划概述规划概述GPRS协议栈BSSGP层中，为了便于管理，每个GPRS小区被赋予了一个BSSGP虚连接BVC（NSEIBVCI），一个BVC必须隶属于一个NSE。其中NSE为网络服务设备实体，是全网统一编码的，以NSEI来标识。一般来说一个BSC被划分为一个服务实体，为了可扩展性，ZXG10系统中也允许BSC下挂若干个NSE。BSSGP虚连接（BVC）为不同的BSSGP实体间通讯提供了一种途径。对等的PTP（点对点）、PTM（点对多）和信令实体间传送

59、BSSGP PDU时是以BVC为基础的。每条虚连接都有一个标识，为BVCI，它能使底层网络服务层将BSSGP PDU高效地路由到对等实体上。在一个网络服务实体（NSE）下，每个GPRS小区可由BVCI唯一标识，一个网络服务实体有且仅有一条信令BVC（BVCI=0）。专题NSEI规划NSEI规划前规划前在网络优化之前没有优化过NSEI，PCU的分配很是随便，甚至一个站上的两个小区都不在一个PCU下，这对GPRS performance有很大影响。因此,我们需要重新分配NSEI。比如下图就是没有经过合理配置的NSEI：专题NSEI规划NSEI规划后规划后在优化期间，PCU需要定期重新规划，也即重新

60、分配小区的NSEI，在物理位置上尽量靠近，这样做的目的是为了在GPRS DT的过程中避免频繁的RAU，从而提高GPRS DT的Performance。下图就是经过优化过的NSEI分配：专题专题NSEI规划规划专题NSEI规划NSEI规划案例规划案例2FTP下载失败下载失败问题：MS从CI1892重选到CI到481的同时跨了PCU，属于Inter-PCU的Cell Reselection,导致了数据传输长时间的停顿，最终发生了PDP掉线。经检查发现CI1892的NSEI值与周围站点不统一。解决方案：调整CI1892的NSEI值。专题PANDEC、PANINC参数实验PANDEC、PANINC概述

61、概述 在无线链路失败控制中，PAN参数将与MS侧的定时器N3102一起使用。当移动台检测到发送窗口停止转动时（V(S)=V(A)+WS），移动台应启动定时器T3182；在收到PACKET UPLINK ACK/NACK导致V(S)V(A)+WS时，则停止T3182；当T3182超时后，移动台将把计数器N3102减去PANDEC，并执行该TBF的异常释放并接入重试；当移动台收到网络发送的“分组上行证实/未证实”消息允许V(S)或V(A)增加时，移动台将把计数器N3102增加PANINC，但是N3102值不能超过PANMAX所定义的值；当N31020时，MS将执行该TBF的异常释放，并将触发小区重

62、选。如果PANDEC，PANINC和PANMAX置为0值时，计数器N3102就无效。增加PANMAX和PANINC，减小PANDEC，可以减少MS在收不到Packet Uplink Ack时TBF异常释放并进行小区重选的可能，但也使MS在发送窗口停止，不能发送数据的情况下，较长时间占据无线资源，资源利用率不高。而减小PANMAX和PANINC，增加PANDEC，则容易使手机发生TBF异常释放并进行小区重选，降低小区TBF正常释放比例，影响数据传输速率。专题PANDEC、PANINC参数实验PANDEC、PANINC参数调整实验参数调整实验参数名参数名重要重要性性参数参数类型类型原原值值修改修改

63、值值BSCMSCPAN_DEC 高CELL 0 2BSC19MSC06PAN_INC 高CELL 0 1BSC19MSC06试验结果：试验结果：总体而言，对公里无覆盖比等GPRS DT测试指标有明显改善。专题PANDEC、PANINC参数实验PANDEC、PANINC参数调整实验前后相关区域电平分布图参数调整实验前后相关区域电平分布图专题MFR、DRX参数实验MFR、DRX概述概述 MFR（BS_PA_MFRMS）在每个小区中每个寻呼组都对应于一个寻呼子信道，移动台根据自身的IMSI计算出它所属的寻呼组，进而计算出属于该寻呼组的寻呼子信道位置，在实际网络中，移动台只“收听”它所属的寻呼子信道而

64、忽略其它寻呼子信道的内容，甚至在其它寻呼子信道期间关闭移动台中某些硬件设备的电源以节约移动台的功率开销（即DRX的来源）。寻呼信道复帧数（MFR）是指以多少复帧数作为寻呼子信道的一个循环。专题MFR、DRX参数实验MFR、DRX概述概述 DRX（DRX_TIMER_MAX）在DRX模式中，MS仅收听归属寻呼组的寻呼块，而在非DRX模式下，MS将收听所有的CCCH块。非DRX模式持续的时间由两个参数共同决定：NON_DRX_TIMER和DRX_TIMER_MAX，等于两者的最小值。DRX_TIMER_MAX设定MS在从分组传输模式进入分组空闲模式时，执行NON-DRX模式时长的最大值。NON_D

65、RX_TIMER由MS在GPRS附着的过程中和SGSN协商。NON_DRX_TIMER的大小可以在ATTACH REQUEST中看到；DRX_TIMER_MAX的数值可从System Information Type 13中看到。DRX_TIMER_MAX的取值范围为07，表达的取值遵循公式：2k-1（其中k=0时，表示参数值为0），即参数取值为：0，1s、2s、4s64s。专题MFR、DRX参数实验DRX模式与非模式与非DRX模式概述模式概述 当移动台处在DRX模式的时候，移动台只会监听和它寻呼组相关的寻呼子信道。若PCU判断该MS正处于DRX模式时，它将计算MS属于哪个寻呼组，并向BTS发

66、出资源分配消息，当BTS收到该消息后将在MS所侦听的CCCH信道上发出立即指配消息。BS_PA_MFRMS定义了寻呼信道的复帧数，目前现网的默认设置是5，也就是说MS在收听了自己寻呼组所对应的CCCH块后，将等待4个51复帧，继续收听的将是第6个51复帧的同样位置的CCCH块。MS如果错过了自己所侦听的寻呼子信道，它将不得不再等待，直到下一个寻呼子信道到来。如果MFR=5，那么在最坏的情况下，MS要收到立即指配的消息，就必须等待：5235ms=1175ms。如果立即指配消息随机出现，MFR=5，MS要等待的平均时间就是：235ms（5+4+3+2+1）/5=705ms 如果立即指配消息随机出现，MFR=2，等待的平均时间就减少为：235ms（2+1）/2=352.5ms 节约的时间为节约的时间为352.5ms！专题MFR、DRX参数实验DRX模式与非模式与非DRX模式概述模式概述 当MS由分组传输模式返回分组空闲模式时（比如TBF释放），在DRX_TIMER_MAX与NON_DRX_TIMER的共同作用下，如果MS进入非DRX传输的状态，将如下图所示：在非DRX模式期间内，MS将收听所