数据业务测试流程及案例分析

上传人:枫** 文档编号:568739242 上传时间:2024-07-26 格式:PPT 页数:93 大小:3.93MB
返回 下载 相关 举报
数据业务测试流程及案例分析_第1页
第1页 / 共93页
数据业务测试流程及案例分析_第2页
第2页 / 共93页
数据业务测试流程及案例分析_第3页
第3页 / 共93页
数据业务测试流程及案例分析_第4页
第4页 / 共93页
数据业务测试流程及案例分析_第5页
第5页 / 共93页
点击查看更多>>
资源描述

《数据业务测试流程及案例分析》由会员分享,可在线阅读,更多相关《数据业务测试流程及案例分析(93页珍藏版)》请在金锄头文库上搜索。

1、(E)GPRS业务测试流程及案例分析(E)GPRS数据业务概述(E)GPRS对对GSM网络的影响网络的影响(E)GPRS的引入对已有的GSM话音业务有一定的影响,这是因为网络干扰增加导致在小区边缘的通信中断概率增加,话音服务面积收缩,越区切换的掉话率有一定程度的升高。对于话音业务,其网络规划完成以后网络的频率干扰主要决定于频率分配和话务量。(E)GPRS引入后,增加了GSM信道的利用率,而信道利用率的增加表现为网络干扰的增加。经实验证明,(E)GPRS业务每增加5%,载干比(C/I)则下降0.21dB,当(E)GPRS业务占用60%信道时,载干比下降2dB。在(E)GPRS引入的初期,如果采用

2、将PDCH配置在BCCHTRX的策略,则不会对语音业务产生影响,因为此时PDCH属于BCCH频率组,不会对属于其它频率组的TCH产生干扰,同时对属于BCCH频率组的TCH由于载干比较高,因此也不会产生太大影响。(E)GPRS数据业务概述(E)GPRS网络优化与网络优化与GSM网络优化的关系网络优化的关系(E)GPRS网络的优化比GSM网络的优化更为复杂。GSM网络作为(E)GPRS的承载网,与(E)GPRS共用基站和频谱资源,这就决定了(E)GPRS网络与GSM网络优化相互关联,又相互制约。首先,(E)GPRS与GSM网络优化在整体上是一致的,加强GSM无线环境的优化工作对于(E)GPRS的优

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

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

5、机型号以及手机软件版本的不同测试电脑型号、所安装系统软件以及应用软件安装情况的不同测试软件版本的不同测试人员测试方法以及现场判断测试数据可靠性能力的不同(E)GPRS数据业务测试的影响因素(E)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或以上版本

6、;手机设置为自动双频模式;串口速率设置为115200;时隙设置为3+1/4+1模式;测试模式设置为Data/Trace测试软件采用CDS3.0以上版本测试电脑应保证1.2G以上主频,256M以上内存;重新安装Windows XP 操作系统,不能安装与测试无关的软件;将托盘中的任何与网络通讯相关的程序关闭,如MSN等;关闭Windows的自动更新功能(E)GPRS数据业务测试的影响因素(E)GPRS业务测试准备业务测试准备保证Ping和FTP的测试服务器正常工作。同时应保证用户具有上传和下载数据的权限, 保证可对服务器进行Ping和FTP测试被测城市应保证其测试服务器在测试检查期间的可用性,如果

7、当地服务器不能使用,测试人员将选择异地服务器进行测试保证邮件系统的正常工作准备大小为150K,500K的文件若干确认WAP测试站点正常工作,由运营商指定(E)GPRS数据业务测试原则CQT测试原则测试原则测试时间:测试时间: 视客户要求而定,通常安排在周一至周五 9:00-19:00进行地点选择原则:地点选择原则: 1.1.在城市中选20-40个测试点。具体测试点分布要求:火车站、机场、三星级以上酒店、大型商场休闲区、大学学校、大型居民区、商务场所、旅游景区 2.2.测试点按照地理、话务因素综合考虑均匀分布,突出重点区域 3.3.在测试前测量当前位置的无线信号,检查信号强度,确保在该点有(E)

8、GPRS覆盖,避免在测试过程中频繁小区重选(重选次数控制在3-4次之内)(E)GPRS数据业务测试原则适用环境适用环境:市区主要道路和重要高速、铁路干线测试时间测试时间:视客户要求而定,通常安排在周一至周五9:00-19:00进行测试速度:测试速度:在市区保持正常行驶速度,一般车速在30-35公里/小时,在高速公路上车速一般不应低于70公里测试路线:测试路线:要求均匀覆盖市区主要街道,并且尽量不重复;环城高速、高架桥、市区到机场公路必须进行测试测试时长:测试时长:根据城市的规模来定,也可以根据用户的要求确定每个城市的测试时长DT测试原则测试原则目录p (E E)GPRSGPRS现状与(现状与(

9、现状与(现状与(E E)GPRSGPRS业务测试概述业务测试概述业务测试概述业务测试概述p (E E)GPRSGPRS业务测试内容业务测试内容业务测试内容业务测试内容p (E E)GPRSGPRS业务测试工具介绍业务测试工具介绍业务测试工具介绍业务测试工具介绍p (E E)GPRSGPRS专题优化介绍及案例专题优化介绍及案例专题优化介绍及案例专题优化介绍及案例分析分析分析分析(E)GPRS测试项目介绍(E)GPRS测试目的测试目的和分类和分类测试目的:通过对市区重要场所和市区主要道路测试,从用户感受的角度评估城市(E)GPRS网络质量,为(E)GPRS网络优化提供参考和依据按照测试形式可以分为

10、两类:路测(DT,Drive Test)、定点拨打测试(CQT,Call Quality Test)?(E)GPRS测试项目介绍(E)GPRS测试测试项目项目(E)GPRS Attach时延、成功率测试(E)GPRS PDP激活时延、成功率测试Ping时延、成功率测试FTP下载、上传速率WAP登陆、刷新时延、成功率测试WAP下载(图铃)速率、成功率测试Kjava下载成功率测试SMS点到点时延、成功率测试MMS PUSH时延、PUSH成功率、端到端成功率测试FTP下载、上传速率WAP登陆、刷新时延、成功率测试WAP下载(图铃)速率、成功率测试CQT DT(E)GPRS测试项目介绍CQT测试测试内

11、容定义和方法内容定义和方法KPIKPI定定 义义测试方法测试方法精度精度统计粒统计粒度度ATTACH平均附着时长各次attach成功的时间相加/成功attach的次数 使用测试终端和测试软件,自动记录测试日志,由测试软件统计功能给出0.01秒10次ATTACH附着成功率(E)GPRS成功Attach次数/总尝试次数100 使用测试终端和测试软件,自动记录测试日志,由测试软件统计功能给出0.01%10次PDP激活平均时长各次PDP激活成功的时间相加/成功attach的次数使用测试终端和测试软件,自动记录测试日志,由测试软件统计功能给出0.01秒10次PDP激活成功率(E)GPRS成功PDP激活次

12、数/总尝试次数100 使用测试终端和测试软件,自动记录测试日志,由测试软件统计功能给出0.01%10次ping平均时延各次ping成功的时间相加/ping成功的次数 使用测试终端和测试软件,自动记录测试日志,由测试软件统计功能给出0.01秒10次ping成功率ping成功的次数/ping尝试次数100 使用测试终端和测试软件,自动记录测试日志,由测试软件统计功能给出0.01秒10次(E)GPRS测试项目介绍CQT测试测试内容定义和方法内容定义和方法KPIKPI定定 义义测试方法测试方法精度精度统计粒统计粒度度WAP平均首页显示时间各次WAP首页成功显示的时间相加/ WAP首页显示成功次数 使用

13、测试终端和测试软件,自动记录测试日志,由测试软件统计功能给出0.01秒10次WAP首页登陆成功率WAP首页显示成功次数/尝试WAP登陆次数100使用测试终端和测试软件,自动记录测试日志,由测试软件统计功能给出0.01%10次WAP平均页面刷新时间各次WAP刷新成功显示的时间相加/ WAP刷新成功显示次数使用测试终端和测试软件,自动记录测试日志,由测试软件统计功能给出0.01秒10次WAP页面刷新成功率WAP页面刷新成功次数/尝试页面刷新次数100使用测试终端和测试软件,自动记录测试日志,由测试软件统计功能给出0.01%10次WAP平均图铃下载速率 实际成功下载数据量(Byte)/实际成功下载时

14、间(秒)使用测试终端和测试软件,自动记录测试日志,由测试软件统计功能给出0.01KBit/S10次WAP图铃下载成功率 WAP铃声、图片成功下载次数/尝试铃声、图片下载次数100 使用测试终端和测试软件,自动记录测试日志,由测试软件统计功能给出0.01%5次图片5次铃声(E)GPRS测试项目介绍KPIKPI定定 义义测试方法测试方法精度精度统计粒统计粒度度FTP下载速率实际下载数据量(Byte)/实际下载时间(秒)使用测试终端和测试软件,自动记录测试日志,由测试软件统计功能给出0.01KB/S1次FTP上传速率实际上传数据量(Byte)/实际下载时间(秒)使用测试终端和测试软件,自动记录测试日

15、志,由测试软件统计功能给出0.01KB/S1次Kjava下载成功率下载成功次数/下载测试总次数100%使用测试终端和测试软件,自动记录测试日志,由测试软件统计功能给出0.01%5次MMS端到端PUSH平均时长各次PUSH成功的时间相加/成功PUSH的次数使用测试终端和测试软件,自动记录测试日志,由测试软件统计功能给出0.01秒10次MMS端到端PUSH成功率用户成功接收PUSH消息条数用户应接收PUSH消息条数100 使用测试终端和测试软件,自动记录测试日志,由测试软件统计功能给出0.01%10次MMS端到端成功率用户成功提取彩信的次数用户尝试提取彩信的次数100 使用测试终端和测试软件,自动

16、记录测试日志,由测试软件统计功能给出0.01%10次CQT测试测试内容定义和方法内容定义和方法(E)GPRS测试项目介绍KPIKPI定定 义义测试方法测试方法精度精度统计粒统计粒度度SMS端到端PUSH平均时长各次短信接收成功的时间相加/短信成功接收的次数使用测试终端和测试软件,自动记录测试日志,由测试软件统计功能给出0.01秒10次SMS端到端PUSH成功率用户成功接收短信条数用户应接收短信条数100 使用测试终端和测试软件,自动记录测试日志,由测试软件统计功能给出0.01%10次CQT测试测试内容定义和方法内容定义和方法(E)GPRS测试项目介绍DT测试测试内容定义和方法内容定义和方法KP

17、IKPI定定 义义测试方法测试方法精度精度FTP下载速率实际下载数据量(Byte)/实际下载时间(秒)使用测试终端和测试软件,自动记录测试日志,由测试软件统计功能给出0.01KB/SFTP上传速率实际上传数据量(Byte)/实际下载时间(秒)使用测试终端和测试软件,自动记录测试日志,由测试软件统计功能给出0.01KB/SWAP平均首页显示时间各次WAP首页成功显示的时间相加/ WAP首页显示成功次数 使用测试终端和测试软件,自动记录测试日志,由测试软件统计功能给出0.01秒WAP首页登陆成功率WAP首页显示成功次数/尝试WAP登陆次数100使用测试终端和测试软件,自动记录测试日志,由测试软件统

18、计功能给出0.01%WAP平均页面刷新时间WAP页面刷新成功指被选择浏览的页面在60秒内文本信息完整正确的显示时长使用测试终端和测试软件,自动记录测试日志,由测试软件统计功能给出0.01秒WAP页面刷新成功率WAP页面刷新成功次数/尝试页面刷新次数100使用测试终端和测试软件,自动记录测试日志,由测试软件统计功能给出0.01%(E)GPRS测试项目介绍KPIKPI定定 义义测试方法测试方法精度精度WAP平均图铃下载速率 实际成功下载数据量(Byte)/实际成功下载时间(秒)使用测试终端和测试软件,自动记录测试日志,由测试软件统计功能给出0.01KBit/SWAP图铃下载成功率 WAP铃声、图片

19、成功下载次数/尝试铃声、图片下载次数100 使用测试终端和测试软件,自动记录测试日志,由测试软件统计功能给出0.01%覆盖率 (E)GPRS覆盖公里数/总测试距离(Km)100%使用测试终端和测试软件,自动记录测试日志,由测试软件统计功能给出0.01%掉线率 掉线次数/总FTP下载尝试次数100%使用测试终端和测试软件,自动记录测试日志,由测试软件统计功能给出0.01%平均RAU间隔时间 总RAU次数/总测试时间使用测试终端和测试软件,自动记录测试日志,由测试软件统计功能给出0.01秒DT测试测试内容定义和方法内容定义和方法(E)GPRS测试项目介绍KPIKPI定定 义义测试方法测试方法精度精

20、度平均RAU间隔距离 总RAU次数/总测试距离使用测试终端和测试软件,自动记录测试日志,由测试软件统计功能给出0.01km平均小区重选间隔时间 总小区重选次数/总测试时间使用测试终端和测试软件,自动记录测试日志,由测试软件统计功能给出0.01秒平均小区重选间隔距离 总小区重选次数/总测试距离使用测试终端和测试软件,自动记录测试日志,由测试软件统计功能给出0.01kmDT测试测试内容定义和方法内容定义和方法(E)GPRS测试项目介绍测试测试项目超时定义项目超时定义KPIKPI超时时间超时时间KPIKPI超时时间超时时间ATTACH附着时长15SFTP下载时长(CQT)180SPDP激活时长15S

21、FTP下载时长(DT)180SMMS接收时长100S(有些设置为150S)SMS接收时长300SPing时长5SKjava下载时长300SWAP首页显示时间(CQT)60SWAP首页显示时间(DT)60SWAP页面刷新时间 (CQT)60SWAP页面刷新时间 (DT)60SWAP图铃下载时长(CQT)150SWAP图铃下载时长(DT)200S目录p (E E)GPRSGPRS现状与(现状与(现状与(现状与(E E)GPRSGPRS业务测试概述业务测试概述业务测试概述业务测试概述p (E E)GPRSGPRS业务测试内容业务测试内容业务测试内容业务测试内容p (E E)GPRSGPRS业务测试工

22、具介绍业务测试工具介绍业务测试工具介绍业务测试工具介绍p (E E)GPRSGPRS专题优化介绍及案例专题优化介绍及案例专题优化介绍及案例专题优化介绍及案例分析分析分析分析(E)GPRS测试软件CDS的使用方法CDS用户界面用户界面测试中常见问题总结CDS4.0版本现在还不稳定,在信令解码(比如C/I、RxQual、Ms-TxPower等)中存在一些BUG在采集参数选项中CDS默认只采集GSMC/ITrace和RLC/MACControlMSG,其实LLCMSG等参数选项对事件的分析也能起到一定作用,最好将信令采集完整注意测试用笔记本电脑在安装测试软件前必须重装操作系统,不能安装与测试无关的其

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

24、FTP测试中出现长时间无流量时,可让司机适当降低车速MMS测试中最好选择NOKIA智能手机做为测试终端(不同手机测试测试结果差别很大)p (E E)GPRSGPRS现状与(现状与(现状与(现状与(E E)GPRSGPRS业务测试概述业务测试概述业务测试概述业务测试概述p (E E)GPRSGPRS业务测试内容业务测试内容业务测试内容业务测试内容p (E E)GPRSGPRS业务测试工具介绍业务测试工具介绍业务测试工具介绍业务测试工具介绍p (E E)GPRSGPRS专题优化介绍及案例专题优化介绍及案例专题优化介绍及案例专题优化介绍及案例分析分析分析分析目录专题ATTACH问题qAttach优化

25、方法优化方法关闭SGSN鉴权检查覆盖防止频繁的小区重选排查干扰,提高C/I检查RACH或AGCH信道配置检查静态PS信道、动态PS信道配置检查(E)GPRSENABLED参数设置检查Gblinksload,调整NSEI配置专题ATTACH问题Attach故障案例一故障案例一: 手机无法登陆(手机无法登陆(E)GPRS网络网络p问题描述问题描述某区域用户反应不能登陆(E)GPRS网络,检查网络配置无异常,实地测试的确无法登陆(E)GPRS网络。p故障分析故障分析进行了(E)GPRS配置数据检查,开通(E)GPRS功能小区的NSEI、NSVI、RAC等各项(E)GPRS参数配置均正确Pcu时隙负荷

26、比较高。专题ATTACH问题Attach故障案例二故障案例二: 手机无法登陆(手机无法登陆(E)GPRS网络网络p 问题描述:问题描述:有用户反映手机(E)GPRSAttach不能成功。现象为手机发送Attachrequest,SGSN返回attachaccept消息,而后面BSC上发信令为LLCunkowninformation。p 故障分析:故障分析:根据信令流程,BSS侧负责TBF流的建立,后面应为手机和SGSN的透传信令,正常流程应为手机向SGSN发送Attachcomplete。检查BSC相关数据没有发现问题。从全局测试来看,与SGSN对接的所有BSC下所带基站都有相同问题情况,初步

27、判断为SGSN侧的问题。经SGSN的工程师检查,有数据改动,即P-TMSI由原来的enable改为disable。导致P-TMSI无法分配,用户无法上(E)GPRS。p 解决方法:解决方法:将P-TMSI由disable调整为enable,故障解决。专题ATTACH问题Attach故障案例三故障案例三: ATTACH失败失败问题:问题:频繁的小区重选(600216033260021)导致ATTACH时延过长(14.55s)。解决方案:解决方案:提高60021CRH由8dB到10dB,调整60332RXLEVACCESSMIN由10dB到12dB 专题ATTACH问题Attach故障案例四故障案

28、例四: ATTACH失败失败问题:问题:网络向手机发送PacketAccessReject消息作为对PacketResourceRequest消息的应答,此消息中包含“Wait_Indication”域,其值赋予T3172,当手机收到PacketAccessReject消息后,启动T3172,在T3172运行期间,网络不允许手机在同一小区内再次发起分组接入尝试。该事件由无线资源紧张所致。解决方案:解决方案:扩充静态PS信道。专题PDP激活问题qPDP激活优化方法激活优化方法关闭SGSN鉴权检查核心网各网元处理能力(DNS解析APN错误或者过慢、GGSN关于APN的配置数据不完整、DHCP或RA

29、DIUS服务器故障、HLR和SGSN对通配符APN格式的兼容性问题、SGSN和GGSN的GTP信令的兼容性问题、SGSN构造APN的配置问题、GGSN处理过慢、DNS和GGSN的主备用状态)防止频繁的小区重选排查干扰,提高C/I检查RACH或AGCH信道配置,提高接入和立即指配成功率检查静态PS信道、动态PS信道配置检查Gblinksload,调整NSEI配置检查(E)GPRS参数设置,合理设置DrxTimeMax、MFR、T3168专题PDP激活问题PDP故障案例一故障案例一: PDP激活失败激活失败问题:问题:在20022重选到20281后,由于20281AGCH紧张导致。解决方案:解决方

30、案:控制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激

31、活问题PDP故障案例四故障案例四: PDP激活失败激活失败问题:问题:在CQT测试时经常出现偶尔PDP激活时延过长的现象。经过对10个点100次的PDP激活测试,发现7次时延异常的现象,具体挂表结果如下:专题PDP激活问题PDP故障案例四故障案例四: PDP激活失败激活失败正常情况下几个接口上的耗时情况如下:专题PDP激活问题PDP故障案例四故障案例四: PDP激活失败激活失败从几次异常测试结果可以看出,主要耗时是在Gb口以下和Radius与WAP网关间,其中第六次GGSN与Radius间的耗时比较长,是因为GGSN第一次发送的Accountingrequest消息没有被WAP网关接收到,也就

32、是说,我们在WAP网关侧没有看到GGSN第一次发送的Accountingrequest消息,只看到了GGSN第二次重新发送的Accountingrequest消息,而且WAP网关收到后及时给予了响应。导致这种现象的原因可能是Accountingrequest消息在传输中丢失或者Radius的处理异常。另外六次则是因为Gb口以下和Radius与WAP网关间的耗时过长。GGSN向Radius发送AccountingRequest消息,等待Radius的响应,并启动相应的等待定时器,在相应的WAP网关侧,我们发现WAP网关在收到AccountingRequest消息后没有给予响应,由于GGSN没有收

33、到AccountingRequest消息的响应消息,导致等待定时器超时,然后GGSN重新发送AccountingRequest消息,在相应的WAP网关侧,我们发现WAP网关此次给予了响应,GGSN收到Radius转发的AccountingResponse消息,这时GGSN才对手机的PDP激活请求进行响应。专题PDP激活问题PDP故障案例四故障案例四: PDP激活失败激活失败正是由于Gi口的耗时过长,使得无线侧的定时器超时而释放了TBF资源,所以手机在接收PDP激活接受消息时,重新进行了TBF的建立,这又进一步增加了在无线口上的延时。因此,WAP网关的响应过慢,是导致PDP激活时延过长根本原因。

34、专题PDP激活问题PDP故障案例五故障案例五: PDP激活失败激活失败在中国移动集团公司第三方测试的准备工作中,发现(E)GPRSCQT的火车站测试点有PDP激活失败的现象,并且多次测试问题始终存在。从信令来看,当下行的立即指配信息里出现了右图中ARFCN为809的时候,PDP激活会不成功。专题PDP激活问题PDP故障案例五故障案例五: PDP激活失败激活失败809这个频点是不正常的,但这是根据手机收到基站发出的层三消息解出来的。这个立即支配消息是为了分配下行的TBF,也就是意味着网络已收到PDP激活申请且给手机回复了PDPactivateaccept消息,但此消息未能通过空中接口。当时怀疑是

35、否因测试软件导致,询问CDS软件研发工程师,回复软件应该没有问题,也不像测试手机问题,所以网络下发的消息编码存在问题的可能性比较大。对同个BSC下的三晋国际饭店测试没有发现同样的问题。调整频点和无线参数等也没有解决问题,于是怀疑是否为基站的问题。重启基站,重做基站数据,仍然没有效果。将天线直接接到BTS机柜上测试看是否是因为分布系统的问题,但在测试中还是存在PDP激活失败,所以也排除分布系统的问题。对GB口进行挂表测试,出现三次PDP激活失败。这三次失败在GB口信令中体现为:MS发给SGSNAPCR,然后SGSN都立即回复一个APAC给MS。但是在SGSN回复APAC给MS7s8s后,在GB数

36、据里发现了RSTA,在该信令中发现“RadiocontactlostwithMS”的信息,同时还有一个LLCD(=LLC-DISCARDED)的信令。见下图:专题PDP激活问题PDP故障案例五故障案例五: PDP激活失败激活失败专题PDP激活问题PDP故障案例五故障案例五: PDP激活失败激活失败总之,虽然在CDS的LOG里存在PDP失败,但是从GB数据里反应出的流程却是完整的,而且SGSN都是在收到MS的APCR后就立即回复了APAC。因此分析结果表明这几次的PDP激活失败并非由核心网引起,可能是由无线侧导致了手机未能收到SGSN发的APAC而产生TIMEOUT。由于无线质量、(E)GPRS

37、统计和参数、核心网、分布系统等都没有问题,这时我们把重点放在基站硬件这一侧。因为8593也会出现闪断,怀疑是否因传输误码率过高而导致,所以要求更换传输,换完传输后进行测试,还是没有效果。由于在8591测试时PDP激活成功率为100,把8591的BTS和8593的BTS进行调换再测试。在调换完后的200次PDP激活测试中,8593没有出现一次失败,而原来好的小区8591出现了5次PDP激活失败。最终更换了8593BTS,问题得到解决。专题Ping问题qPing优化方法优化方法优化PingServer,将PingServer搬到FW内检查覆盖防止频繁的小区重选排查干扰,提高C/I检查静态PS信道、

38、动态PS信道配置检查Gblinksload,调整NSEI配置检查(E)GPRS参数设置,合理设置DrxTimeMax、MFR、T3168优化测试测试电脑,关闭所有系统软件以及应用软件的自动更新功能专题Ping问题Ping故障案例一故障案例一: 不同时间间隔造成不同时间间隔造成PING时延不同时延不同问题:问题:Ping测试中时间间隔设置为4s-12s测试结果有很大差别。经过核心网挂表测试发现Ping时延不稳定是因为测试过程中出现其他一些数据包,这些垃圾数据包是由杀毒软件和一些应用软件自动更新造成的。解决方案:解决方案:重新安装操作系统,不能安装与测试无关的软件,将托盘中的任何与网络通讯相关的程

39、序关闭,关闭Windows的自动更新功能。专题Ping问题Ping故障案例二故障案例二: Ping失败失败问题:问题:PING失败时误码率很高,查看网管指标发现此时干扰比较严重,但是其他时段几乎没有干扰,基本可以确定该干扰是外部干扰。解决方案:解决方案:查找外部干扰。专题Ping问题Ping故障案例三故障案例三:Ping失败失败问题:问题:由于小区的C/I低导致较高的BLER(小区BCCHCI5.9)。查看规划数据,微蜂窝8800、7660、8750是同BCCH。解决方案:解决方案:控制8800、7660、8750覆盖,调整8800、7660、8750频点。专题WAP问题qWAP优化方法优化方

40、法优化WAP网关、移动梦网服务器、Gi口检查覆盖防止频繁的小区重选排查干扰,提高C/I检查静态PS信道、动态PS信道配置检查Gblinksload,调整NSEI配置检查(E)GPRS参数设置,合理设置DrxTimeMax、MFR、T3168优化测试测试电脑,关闭所有系统软件以及应用软件的自动更新功能专题WAP问题WAP故障案例一故障案例一:WAP刷新失败刷新失败问题:问题:出现WAPreply失败的时候(E)GPRS的质量为6级,从服务小区和邻区的测量来看,存在着邻频的干扰。解决方案:解决方案:更改频点。专题WAP问题WAP故障案例一故障案例一:WAP图铃下载速率低图铃下载速率低问题:问题:通

41、过分析看出RLC数据重传率高,从OMC统计数据看Gblink的负荷在测试时段已高达64%,从而导致下载速率低。解决方案:解决方案:重新调整NSEI以减低Gblinkload,从而提高(E)GPRSCQT的下载速率。专题WAP问题WAP故障案例三故障案例三:WAP登陆失败登陆失败问题:问题:在*宾馆WAP登陆测试中,通过跟踪Gb口发现,手机上行发送Get(URL=http:/),网络侧回复了一个PDU,具体内容为:Yourrequestforaservicecouldnotbefulfilled,pleasetryagainorcontactyouroperatoriftheproblemper

42、sists。这种现象是因为移动梦网服务器出现问题。解决方案:解决方案:与核心网工程师沟通解决。专题WAP问题WAP故障案例四故障案例四:WAP登陆和刷新时延过长登陆和刷新时延过长GB口口WAP测测试试流流程程专题WAP问题WAP故障案例四故障案例四:WAP登陆和刷新时延过长登陆和刷新时延过长WAP测测试试信信令令流流程程问题:问题:信令分析发现,网关在CONNECT到CONNECTREPLY和GET到REPLY间存在响应时延长,需重复发送GET请求,甚至会出现没有响应的情况,尤其是GET与REPLY间经常出现较大的信令时延,有的甚至达到几十秒,对手机访问WAP速度有较大影响。我们初步认为打开W

43、AP网页时超过20秒以上的大时延基本都是由网关时延引起的。解决方案:解决方案:核心网工程师针对WAP网关进行优化。专题WAP问题WAP错误代码含义错误代码含义WTP层协议发生错误层协议发生错误专题WAP问题WAP错误代码含义错误代码含义WSP层协议发生错误层协议发生错误专题WAP问题WAP错误代码含义错误代码含义HTTP协议发生错误协议发生错误专题MMS问题qMMS优化方法优化方法优化相关核心网网关及接口、移动Radius到省内检查覆盖防止频繁的小区重选排查干扰,提高C/I检查静态PS信道、动态PS信道配置检查Gblinksload,调整NSEI配置检查(E)GPRS参数设置,合理设置DrxT

44、imeMax、MFR、T3168专题MMS问题MMS故障案例一故障案例一:MMS发送失败发送失败问题:通过挂表发现手机首先PDP激活,APN为CMWAP,但是手机随后没有任何发起任何信令。这种情况是由于手机软件进程吊死所致。解决方案:重装手机操作系统。专题MMS问题MMS故障案例二故障案例二:MMS接收失败接收失败问题:通过挂表发现手机首先建立了WSP层的连接,然后发起GET请求接收彩信,随后WAP网关将彩信在WTP分割后,向手机发送WTP层的分段,当传送到第六个分段后该消息中的GTR和TTR都为0,说明该分段既不是整个消息中某组的最后一块,也不是整个消息的最后一块,但是手机却回应了ACK,紧

45、接着又发起一个Transaction(Invoke)。这种情况是由于手机软件故障所致。解决方案:重装手机操作系统。专题MMS问题MMS故障案例三故障案例三:MMS接收失败接收失败问题:通过Gi口挂表发现手机在发起Get请求后,在10ms左右的时间连续多次重发Get请求(Get请求重发定时器为10s),导致WAP网关来不得处理手机的Session,从重发时间间隔来看,不可能是手机连续接收彩信。这种情况是由于手机软件故障所致。解决方案:重装手机操作系统。专题MMS问题MMS故障案例四故障案例四:MMS发送失败发送失败问题:通过挂表我们发现手机首先上行发送WSP层的Connect信令,建WSP层的连

46、接,但是WAP网关没有回应ConnectReply,手机等待5秒后重Connect,但是始终没有回应ConnectReply,达到最大重发次数5次后,WSP层的建链失败,最终导致彩信发送失败。导致此次MMS发送失败的原因为WAP网关过于繁忙没有回应ConnectReply。解决方案:请核心网工程师配合解决。专题FTP问题qFTP优化方法优化方法优化FTPServer,将FTPServer搬到FW内检查覆盖防止频繁的小区重选排查干扰,提高C/I检查静态PS信道、动态PS信道配置检查Gblinksload,调整NSEI配置调整DLB、ULB、DLBH、ULBH参数,动态调整CS的比例检查(E)GP

47、RS参数设置,合理设置DrxTimeMax、MFR、T3168、T3192打开CS3、CS4专题FTP问题FTP故障案例一故障案例一:FTP下载失败下载失败问题:问题:MS重选到小区41921后,DLTBF一直没被建立导致长时间下行无数据传输,最终导致了PDP掉线.经检查该小区在测试时间段内的(E)GPRSKPI:下行时隙分配拥塞率比较高,这是为什么没能建立DLTBF的主要原因所在。解决方案:解决方案:增加该小区静态PS信道。专题FTP问题FTP故障案例二故障案例二:FTP下载速率过低下载速率过低问题:问题:第一次cellreselection(9052)使数据传输恢复时间变长而导致长时间TB

48、F挂起。之后重建时由于小区30553数据业务繁忙只申请到一条PS信道,在数据下传过程中又发生了第二次cellreselection(5280),然后因为数据传输恢复时间变长而导致长时间TBF挂起。在重建时小区30152数据业务繁忙导致一直申请不到下行的PS信道导致三次PING失败,最终申请到了4条PS信道,下载成功。导致平均下载速率只有8.11kbit/s。解决方案:解决方案:扩充30553、30152静态PS信道;调整30553RXLEVACCESSMIN由10到12。专题FTP问题FTP故障案例三故障案例三:FTP下载失败下载失败问题:问题:MS从43372重选到42093后,又从4209

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

50、。解决方案:解决方案:增加CI2631的静态PS信道。专题FTP问题FTP故障案例六故障案例六:FTP下载速率低下载速率低案例说明:案例说明:在*路和*桥路附近,手机从宏站小区重选至室外微蜂窝52484(八万人体育馆),BCCH109。由于室外微蜂窝主要是针对某个热点地区,或者覆盖比较差的区域采用的覆盖方式。我们在(E)GPRS测试时,车经过室外微蜂窝的时间比较短,尽量不要让手机重选至这样的小区,这样会增加小区重选的次数和减少吞吐量。在这个案例中,我们发现这个小区主要是覆盖八万人体育场的外场,所以我们鼓励慢速移动的手机占用此小区,快速移动的手机不要重选进这样的小区。52484参数设置为:PET

51、=20s,TEO=0。为了保证手机在一段时间内不重选进此小区,设置PET20s,TEO30db,即在52484的信号出现在MS的邻区20s内给C2一个人为的衰减值30db,使其他小区的C1,C2大过本小区5s,这样手机即不会选进室外微蜂窝。专题FTP问题FTP故障案例六故障案例六:FTP下载速率低下载速率低专题FTP问题FTP故障案例六故障案例六:FTP下载速率低下载速率低问问题题:在复测时我们发现,在同一个地点,此时52484的C1=25,C221,从15:40:33.764至15:53:586持续20s后,C2值升至53。由于复测时,车行驶的地方为一个交通灯口,车流量大、拥堵。我们原先设置

52、的PET20s远远小于堵车的时间。解解决决方方案案:将这个小区的PET设置为200s,这样小区重选发生的可能性就大大降低了。专题高BLERBLER概述概述BLER反应信道受干扰的情况,但在小数据传输中可以看到下行BLER总是比较高,重传的BLOCK中很大的一部分是由于PCU的无线传输特性决定的,PCU在下行传输时,判断数据是否快要发送完了,在数据快要结束前N个BLOCK(N由PCU参数决定)的时候确定TBF快要结束,在下行TBF的结尾处最后的一个BLOCK发送之后而在对它的确认包回来之前,PCU重复发送这些未确认的BLOCK直到收到确认包。此时如果发生该BLOCK的接收错误,手机可以马上从后面

53、的BLOCK中获得而不必要求重传,手机在计算BLER的时候把这部分BLOCK也计算在内,从而导致BLER的计算值比较高,因此小数据传输下行BLER并不代表系统真正的无线性能,在大数据量传输时的BLER可以真实的反映出系统的无线性能。测试中同时观察C/I、质量、手机发射功率、重传率以及信道的RLC层速率,这些都是反应信道质量的重要指标。专题高BLERBLER案例案例1内部干扰问题内部干扰问题问题:问题:是该站点覆盖小区,但是高BLER。解决方案:解决方案:更改GTRX或者更换频点。专题高BLERBLER案例案例2小区重选问题小区重选问题问题:问题:已经越过了该小区的主控范围,但是不向邻小区重选。

54、解决方案:解决方案:调高该邻小区的CRH。专题小区重选问题小区重选的时候手机会暂时中断数据传输,在这里数据中断的时长主要包括:重选后数据暂停的时间、TCPSlowStart启动的时间,这一过程大约需要410秒,直至TCP正常传输。路测过程中,要特别注意观察,是否有频繁小区重选或乒乓小区重选发生,小区信号覆盖过小或不稳定都会导致频繁、乒乓小区重选,同时还要注意观察,是否由于小区重选参数设置不合理导致过覆盖,这里注意对CRO、CRH等相关参数的调整。TCPSlowStart过程,在小区重选后数据暂停的时长约410秒,手机在新小区驻留后需要0.55秒的时间获得资源分配,如果有资源可以分配的话,此时手

55、机已经有少量数据的发送和接收(通过IP分析软件观察),此时使用PING来检验就可以看到(E)GPRS连接已经恢复。在TCP的数据连接恢复过程中再次发生的小区重选会严重影响给TCP的数据连接恢复。小区重选与路由更新概述小区重选与路由更新概述专题小区重选与路由更新问题小区重选与路由更新概述小区重选与路由更新概述小区重选的时候手机会暂时中断数据传输,在这里数据中断的时长主要包括:重选后数据暂停的时间、TCPSlowStart启动的时间,这一过程大约需要410秒,直至TCP正常传输。路测过程中,要特别注意观察,是否有频繁小区重选或乒乓小区重选发生,小区信号覆盖过小或不稳定都会导致频繁、乒乓小区重选,同

56、时还要注意观察,是否由于小区重选参数设置不合理导致的过覆盖现象,这里注意对CRO、CRH等相关参数的调整。TCPSlowStart过程,在小区重选后数据暂停的时长约410秒,手机在新小区驻留后需要0.55秒的时间获得资源分配,如果有资源可以分配的话,此时手机已经有少量数据的发送和接收(通过IP分析软件观察),此时使用PING来检验就可以看到(E)GPRS连接已经恢复。在TCP的数据连接恢复过程中再次发生的小区重选会严重影响TCP数据连接的恢复。专题小区重选与路由更新问题DT测试中会发生小区重选,在重选后的数据中断和恢复期间数据量非常小,TCP慢启动之后,数据传输恢复。恢复时间长度不一,这和重选

57、时TCP数据传输当时的具体情况有关,一般410秒,极端恶劣情况下达12分钟,但此时如果停止行驶,数据传输会在短时间内恢复。FTP的数据传输在经历RAU的时候同时也进行了小区重选,此时的数据中断情况同小区重选一样,在RAU之后继续的小区重选也会给TCP的数据连接恢复带来负作用,路测过程中应观察重要路段或重要场所是否有不合理的RAU事件发生。在RAU之后可以使用PING来验证(E)GPRS承载已经恢复。小区重选与路由更新概述小区重选与路由更新概述专题小区重选与路由更新问题小区重选案例小区重选案例1C2参数设置不合理问题参数设置不合理问题问问题题:车辆沿机场高速从北向南行驶,红圈处占用小区高教科研4

58、(BCCH:560)。继续南行,高教科研4的电平逐渐降低,低至94dBm以下时,仍不发生小区重选。长时间电平小于94dBm,造成无覆盖。经检查发现此时该小区与相邻小区的小区重选参数设置情况如下:专题小区重选与路由更新问题小区重选案例小区重选案例1C2参数设置不合理问题参数设置不合理问题 小区名小区名Rexlev(dBm)RXLEVACCESSMINCRHCROTOC2高教科高教科研研4-103-100826023下墟下墟3-80-10088028殷巷殷巷3-84-100810026解解决决方方案案:控控制制小小区区高教科研4(BCCH:560)的覆盖,修改高教科研4小区CRO由26到20。专题

59、小区重选与路由更新问题路由更新案例路由更新案例1跨越跨越SGSN路由区更新故障路由区更新故障每次穿越RAC区时,都发生掉线,且都伴随着RAUFailure。通过仔细分析,SGSN内的数据错误是导致这种路由更新失败的原因。关系(E)GPRS路由更新的参数主要有3部分,即:(1)每个MSC到SGSN的归属位置(2)每个BSC到MSC的归属位置(3)每个小区的归属的RAC区以上3个参数必须与现行网络中硬件设备的连接一致才能保证(E)GPRS手机路由更新的正常进行。专题NSEI规划NSEI规划概述规划概述(E)GPRS协议栈BSSGP层中,为了便于管理,每个(E)GPRS小区被赋予了一个BSSGP虚连

60、接BVC(NSEIBVCI),一个BVC必须隶属于一个NSE。其中NSE为网络服务设备实体,是全网统一编码的,以NSEI来标识。一般来说一个BSC被划分为一个服务实体,为了可扩展性,ZXG10系统中也允许BSC下挂若干个NSE。BSSGP虚连接(BVC)为不同的BSSGP实体间通讯提供了一种途径。对等的PTP(点对点)、PTM(点对多)和信令实体间传送BSSGPPDU时是以BVC为基础的。每条虚连接都有一个标识,为BVCI,它能使底层网络服务层将BSSGPPDU高效地路由到对等实体上。在一个网络服务实体(NSE)下,每个(E)GPRS小区可由BVCI唯一标识,一个网络服务实体有且仅有一条信令B

61、VC(BVCI=0)。专题NSEI规划NSEI规划前规划前在网络优化之前没有优化过NSEI,PCU的分配很是随便,甚至一个站上的两个小区都不在一个PCU下,这对(E)GPRSperformance有很大影响。因此,我们需要重新分配NSEI。比如下图就是没有经过合理配置的NSEI:专题NSEI规划NSEI规划后规划后在优化期间,PCU需要定期重新规划,也即重新分配小区的NSEI,在物理位置上尽量靠近,这样做的目的是为了在(E)GPRSDT的过程中避免频繁的RAU,从而提高(E)GPRSDT的Performance。下图就是经过优化过的NSEI分配:专题专题NSEI规划规划专题NSEI规划NSEI

62、规划案例规划案例2FTP下载失败下载失败问题:MS从CI1892重选到CI到481的同时跨了PCU,属于Inter-PCU的CellReselection,导致了数据传输长时间的停顿,最终发生了PDP掉线。经检查发现CI1892的NSEI值与周围站点不统一。解决方案:调整CI1892的NSEI值。专题BCCHTRX、TCHTRX(HF/NHF)下(E)GPRS性能比较BCCH TRX、TCH TRX(HF/NHF)下()下(E)GPRS性能比较性能比较为明确了解BCCH载频、TCH载频在跳频、非跳频及不同编码方式下FTP下载速率的变化情况,寻找特定小区进行了详尽的测试,具体情况如下:p无线环境

63、好、接收电平强无线环境好、接收电平强测试地点设在一写字楼内,由于楼内主要由微蜂窝覆盖,周边的无线环境较好,主控小区的电平远远高于相邻小区,接收电平在55dBm左右,在这种情况下通过测试发现,占用BCCH或TCH、跳频或非跳频之间的下载速率差异值不是很大。专题BCCHTRX、TCHTRX(HF/NHF)下(E)GPRS性能比较p无线环境好、接收电平低无线环境好、接收电平低测试地点为一写字楼内,用手机锁频到室外大站,接收电平在-85dBm左右,由于楼体的屏蔽虽然使服务小区电平很低,但周围的干扰电平也很低无线环境较干净。在这种情况下通过测试发现,占用BCCH或TCH、跳频或非跳频之间的下载速率差异值

64、不是很大。BCCH TRX、TCH TRX(HF/NHF)下()下(E)GPRS性能比较性能比较专题BCCHTRX、TCHTRX(HF/NHF)下(E)GPRS性能比较p无线环境差、接收电平低无线环境差、接收电平低测试地点为一16层建筑物顶层,用手机锁频的室外大站接收电平为80dBm左右,由于楼顶的无线环境较差,周围较多大站飘来的信号对当前小区带来干扰。在这种情况下通过测试发现,占用TCH载频在跳频和非跳频情况下的下载速率差异较大,CS12与CS34算法下下载速率差异较大。由于BCCH载频不参加跳频,所以在跳频或非跳频之间测试值并无太大差异。所以只统计了TCH载频在跳频或非跳频情况下的测试结果

65、。BCCH TRX、TCH TRX(HF/NHF)下()下(E)GPRS性能比较性能比较专题BCCHTRX、TCHTRX(HF/NHF)下(E)GPRS性能比较通过对测试结果的分析发现,在无线环境较差的条件下,打开跳频比关闭跳频的下载速率慢,打开CS34比CS12算法下的下载速率慢。造成上述现象的主要原因是:由于跳频技术的主要特点是将被干扰的信息块“打散”,分配到若干载频上,使得原来集中在一个载频上的干扰被几个载频分担了。通过如此做法可将由干扰带来的掉话概率大大降低。但对于(E)GPRS业务则恰恰相反,在非跳频的情况下干扰电平集中在一个频点上,因此只会对这一载频上的包做重传。但如果打开跳频,则

66、所有载频上都会有被干扰的信息快,因此都需要重传,从而大大降低下载速率。测试结果对比分析测试结果对比分析专题BCCHTRX、TCHTRX(HF/NHF)下(E)GPRS性能比较测试结果对比分析测试结果对比分析(E)GPRS数据传输性能与无线环境有直接的关系,而与信号接收电平关系不明显当无线环境很好时,在BCCH、TCH跳频和不跳频下测试的结果相差不大;但如果无线环境不好,TCH跳频情况下(E)GPRS性能要远差于非跳频的情况,特别当所在小区打开CS34功能时,影响更为明显,因此对于此种特定环境下为保证(E)GPRS性能,不建议开跳频,这与话音业务有一定的矛盾,需要权衡考虑不建议跳频TCH载频开C

67、S34功能,目前CS34功能仅限于在BCCH载频上开启专题假事件假事件案例假事件案例1FTP下载失败下载失败通过对Gi口抓包分析,发现在登陆FTP服务器成功后,FTP服务器就因收到RESET消息而停止发送数据。由于发送端已中止发送,而在手机终端侧FTP下载测试进程并没有停止,最终测试软件判断超时失败。该种情况主要是由于位置更新导致登陆服务器中断,FTP登陆时TCP协议进程因丢包出现错误,而从测试软件的表象上看,已显示成功登陆,但无法下载数据。专题假事件从测试设备抓包可以看到已经成功接收到FTP-DATA包,但是却没有将收到的数据包变为有效数据,最终导致接收窗口溢出,数据传输中止。而FTP下载测

68、试进程同样并没有停止,最终测试软件判断超时失败。该种情况同样是由于位置更新导致登陆服务器中断,虽然FTP登陆TCP协议进程正常,可以正常传输数据,但是FTP-DATA仍然出错。假事件案例假事件案例1FTP下载失败下载失败专题假事件总之,上述两种FTP下载的断线情况均是由于FTP协议出现错误导致,该错误出现在TCP/IP的传输层和应用层,而不是由(E)GPRS网络层故障引起。从测试软件上看,都是在登陆FTP服务器后无法接收应用层数据,最后超时显示FTPdownloadfail,统计为掉线一次。但是因PING可以成功,说明网络传输通路正常。假事件案例假事件案例1FTP下载失败下载失败专题假事件问题

69、:在手机Get需要的网页后,WAP网关回“URLNOTEXIST”消息。该消息是WAP网关收到SP服务器回应的“服务暂时中断”消息后作出的响应。解决方案:该次测试在CDS后处理软件中将被剔除。不作为一次测试尝试。假事件案例假事件案例2WAP图铃下载失败图铃下载失败专题假事件问题:MS在CI1763发送MMS时失败,从log中看被叫手机无相应信令下发,MS在此时处于Standby状态,查看信令发现该时段主叫手机有SMS进来。检查该时段OMCKPI看出该小区有很小比例的DLTBFDropRate是由于suspend和noresponse的原因导致的。判断次此CASE是由于SMS进来导致手机做了RAU,网络延迟加大造成的MMS发送失败。解决方案:关闭测试卡所有短信定制服务。假事件案例假事件案例3MMS发送失败发送失败

展开阅读全文
相关资源
正为您匹配相似的精品文档
相关搜索

最新文档


当前位置:首页 > 医学/心理学 > 基础医学

电脑版 |金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号