GPRS测试中案例分析
GPRS DT测试典型案例分析
CMCC 年度巡检的考核指标
GSM-DT的考核指标
覆盖率、接通率、话音质量、掉话率
GSM-DT的考核指标
覆盖率、掉线率、FTP下载速率 WAP测试，包括登陆成功率、首页显示时长等等 图、铃下载测试，包括下载成功率、下载速率等等
All rights reserved 2004, Alcatel Shanghai Bell
All rights reserved 2004, Alcatel Shanghai Bell
典型案例－2：结论
小区重选参数（如CRO、CRH）的调整对GSM网络相关性能 及GPRS网络的相关性能的影响不尽相同，需综合考虑。 本例我们考虑话务量的均衡和手机能够正常重选，调低高教科 研4的CRO从26到20。
GPRS-DT典型案例分析 GPRS-DT典型案例分析
ASB/MCG/RND Dec01, 2004
GPRS-DT优化工作介绍
GPRS-DT优化工作和GSM-DT优化工作的特点
两者有许多相同的方面 GPRS的优化工作比GSM更加复杂
All rights reserved 2004, Alcatel Shanghai Bell
All rights reserved 2004, Alcatel Shanghai Bell
典型案例－1：正常访问WAP的过程
A t ta c h r e q u e s t A t ta c h a c c e p t A c ti v e PDP c o n te x t re q u e s t G PRS 核 心 网
All rights reserved 2004, Alcatel Shanghai Bell
典型案例－5：WAP图、铃下载失败的案例
诺西GPRS典型案例分析资料
案例二：SGSN的Gr Link负载不均衡
三.分析
SGSN与两个LSTP各有一个link set，每个link set中都含有 16条link，每个link set中的link是在内部控制下自动实现了均衡 负荷（在有效link的个数之内）。SGSN通过HSTP（GZH1和 GZH2）建立了两个route set，而且每个route set中都均衡地使 用了这两个link set，在所有的route set中都只有是同一个link set 的优先级高。
案例三：话单中上网时间为0的问题
三.分析
SGSN产生的S-CDR话单
cg1_20090201050007.cdr.boss: 18 783735661 46001415203590620090131202240 0 8613022175 033 220.206.129.48 220.206.129.2541535 848641CMWAP.MNC001.MCC460.GPRS mnc00.mcc460.gprs 10.100.152.306 0F5 5184 70360821 80 00 83678 29686501FF000000000400000001027396737 37482FFFF2009020104224020090201044007 1047
案例一：PDP激活成功率降低
三.分析
30日下午对现网数据进行实时分析，从15：20到15点35分采集 了15分钟的数据， 采集到29次B2事件。其中13次均为同一用户 所为。该用户使用APN “ZHTKJ.HZ.SD.MNC***.MCC***.GPRS” 进行PDPcontext激活。 进一步分析该用户的行为， 发现该用户 每分钟做一次PDPcontext激活，而且信令流程不同于一般的手 机用户，应该是使用功能不完善的通讯软件在进行数据业务。并 且由于未能成功建立通信连接而不断重拨， 导致以上业务失败 次数的增加。 进一步对上午忙时的数据进行分析， 同样发现该类用户在不断 重复此项活动。这个APN的失败次数占到所有APN失败次数的 52%。因此可以确定是该类用户使用某种不规范的终端工具，未 能激活数据业务，自动重试，从而导致KPI的降低。
GPRS测试问题总结分析
1.测试问题总结分析1.1Attach成功率对于Attach成功率低的问题，我们从此次测试中总结出主要有以下几个因素导致该项指标差：1)信令异常2)无线信道资源紧张3)无GPRS信号4)在Attach过程中因发生位置更新而导致超时失败以下我们结合实例加以分析说明：例一：某城市CQT测试点佳程酒店（第4、6次）、华天大酒店（第3次）、福利华大酒店（第1次）。
现象描述：以佳程酒店为例。
手机当时服务小区为：LAC=29450，CI＝13040，BCCH ＝5，BSIC=07。
手机能正常接收到网络发送的System Information Type13消息，说明此小区是支持GPRS功能的。
但是手机连续发送AttachRequest都没有成功。
下图为手机Attach失败Um口上的信令流程。
原因分析：器T3310，如果此消息中不包含P-TMSI（临时移动台识别码），则网络向手机发送Identity Request消息，要求手机发送IMSI（国际移动用户识别码），手机回应Identity Response（含IMSI）消息。
然后手机正常接收到Attach Accept后，回应Attach Complete，T3310停止。
若T3310超时，手机会向网络再次发送Attach Request消息，并重新启动T3310。
从手机收到的Packet Uplink Ack/Nack消息可知，网络已经收到了手机发送的Identity Response消息。
但此后手机再没有收到网络发送的任何消息。
发生这种现象的原因有：网络已经发送了Attach Accept消息，由于无线环境差，手机没有接收到。
由于无线资源紧张，网络没有空闲信道来发送Attach Accept消息。
另外，手机锁定的小区CI＝13040，应该为室内微蜂窝，载频数配置一般较少，容易发生无线资源拥塞现象。
例二：某城市CQT测试点国际金融大厦（第8次）、华天大酒店（第5次）等。
测试用例(GSM+GPRS)
3、确保测试手机与对比手机使用同一家运营商的SIM卡。
测试步骤：
1、测试手机拨打对比手机并接听，同时向本机发送消息。
2、记录发送和接收的情况。
3、每个短信息之间相隔约10秒。
4、重复以上步骤2、3、4。
6、保存文件。
记录内容：
1、发送或是接收消息失败后，现场记录失败的地点、LOG的时间、LOG文件名。
2、重复上面的过程10次。
记录内容：
1、搜网或是注册失败后，现场记录失败的地点、LOG的时间、LOG文件名。
2、分析LOG文件时，分析失败的原因，统计成功率。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
Area
Data/Time
Environment
2、分析LOG文件时，分析失败的原因，统计成功率。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
Area
Data/Time
Environment
Short Call MT 2
No.
DUT.
REF.
Description
初始条件：
1、打开测试工具Channel Server、Logel、DspLogger。
Area
Data/Time
Environment
Short Call MO 1
诺西GPRS典型案例分析精品文档
案例三：话单中上网时间为0的问题
二.处理过程
检查SGSN产生的S-CDR与SA-CDR，并进性对 比，发现S-CDR与SA-CDR的上下行流量相同，排除 了话单错误的可能性，接下来需要对比原始话单与计 费中心产生的话单的qubie
案例三：话单中上网时间为0的问题
三.分析
GGSN产生的SA-CDR话单
------>localSequenceNumber(4) value: 20 ------>timeOfFirstUsage(5) value: 09 02 01 04 22 18 +08 00 ------>timeOfLastUsage(6) value: 09 02 01 04 39 45 +08 00 ------>timeUsage(7) value: 0 ------>serviceChangeCondition(8) value: 0 ------>sgsnAddress(10) -------->SEQUENCE(16) ---------->iPTextV4Address(2) value: 220.206.129.48 ------>volumeUplink(12) value: 83678 ------>volumeDownlink(13) value: 296865 ------>serviceIdentifier(17) value: 33554433 -->consolidationResult(35) value: normal(0)
•
NA0 07FF05/007-255-005 HSTP1 AV-SP 5
• NA0 07FF05/007-255-005 HSTP1 UA NA0 07FF04/007-255-004 HSTP2 AV-EX 7 NA0 07FF05/007-255-005 HSTP1 AV-SP 5
关于GPRS相关参数设置不合理影响GPRS上网的案例分析
3、通过对某基站-2小区的指标提取，发现上、下行RS/GPRS TBF建立失败次数较多。
4、通过对基站传输E1链路和基站空闲时隙数进行核查，存在3条E1链路且均工作正常，传输空闲时隙数为192。
（1）基站传输故障导致用户无法占用高编码上网；
（2）基站传输E1链路过少导致上网较慢；
（3）基站PDCH信道不足导致用户无法占用PDCH信道；
（4）基站参数或用户参数设置错误导致用户无法上网；
（5）基站空闲时隙数配置不足导致上网较慢。
处理技巧分析
1、通过网优人员现场测试，确定当地主要为某基站-2小区覆盖，测试手机显示当地接收电平在-83dBm左右，覆盖良好。
7、通过对该小区信道重新配置并调整相关参数以后，回访用户，用户表示已能正常上网，核查该小区相关性能指标，未见任何指标异常。
经验总结
用户反映在某特定区域无法上网，在确定非个别原因而是大面积的情况下，应该首先检查自身网络环境是否工作正常，相关参数设置是否合理，在确定了非网络异常的情况下再进行相关优化处理。这样在确定了自身网络工作正常的情况下可以避免一些不必要的投诉。
案例主题
关于GPRS相关参数设置不合理影响GPRS上网案例分析
投诉内容描述
客户提出在某中学附近无法使用手机上网，称周围用户都无法正常使用。因此是希望对我司能尽快排除问题、恢复正常使用有强烈意愿。
投诉处理难点
投诉问题主要可能为基站故障或者资源不足造成用户无法正常上网或上网较慢的情况：导致这类问题的原因有：
5、核查该基站小区信道配置和话务量情况，其中静态PDCH信道配置数为4个，忙时每线话务量在0.2Erl左右，且实时占用的PDCH较多。
(E)GPRS案例分析-(E)GPRS日常监控处理分析
（E）GPRS案例分析(E) GPRS日常问题及告警监控处理分析1分析目的 (2)2分析方法 (2)3分析数据 (2)3.1 分析数据范围 (2)3.2 分析数据工具 (2)3.3 参与人员 (2)4 常见问题分析过程及处理方法 (3)GPRS /(E)GPRS Sleeping Cell 监控及处理流程 (3)4.1GPRS Sleeping Cell 监控 (3)4.2GPRS Sleeping Cell 处理 (4)4.3GPRS Sleeping Cell处理后的监控 (4)4.4EGPRS Sleeping Cell监控 (4)4.5EGPRS Sleeping Cell处理 (5)4.6EGPRS Sleeping Cell处理后的监控 (5)5. 3273告警监控及处理 (6)3.13273告警监控及处理流程 (6)5.13273告警监控 (6)5.23273告警处理 (7)5.33273告警处理后的监控 (7)6. 7725告警（BTS级告警）监控及处理 (8)6.17725告警监控 (8)6.27725告警处理 (8)6.37725告警处理后的监控 (8)7 .GPRS无线侧流量异常监控及处理 (9)7.1GPRS无线侧流量异常监控 (9)7.2GPRS无线侧流量异常处理 (9)7.3GPRS无线侧流量异常处理后监控 (9)8High Immediate Assignment Message处理 (10)9其他BSC级告警的监控与处理 (11)9.13019/3020告警处理 (11)9.23031告警处理 (12)10 分析结论： (13)1分析目的由于(E)GPRS网络的不断扩大，网络中出现的问题也越来越多，例如睡眠小区的问题和3273/7725告警的问题。
这些都会直接影响到用户对数据业务的使用，严重的影响了用户感知度。
为了提高网络的质量，我们通过实际操作和试验，得出了日常问题监控的方法，及时发现问题并及时处理。
GPRS DT、CQT测试中异常问题分析
GPRS DT/CQT测试中异常问题分析1.GPRS DT测试中的异常问题分析3．1测试过程中手机发起上行的PDP deactivated消息在DT FTP下载测试中，MS已成功登陆FTP Server，并已经开始下载数据，FTP下载进度为9％，在经过一次小区重选后，发现在事件列表中有PDP Deactivated的消息，在层三消息中可以看到是手机发起的上行消息，之后的FTP下载不能继续进行，在一系列的Ping fail后，FTP掉线。
层三信令显示如下：Direction Type Layer 3 MessageUL GPRS SM Deactivate PDP Context RequestDL RR System Information Type 13UL RR Channel RequestDL RR Immediate AssignmentDL GPRS SM Deactivate PDP Context Accept发生这种情况可能有3种原因：一是手机在测试过程中电缆的某个接口发生了松动，这样手机可能会发出PDP去激活申请。
二是手机本身存在一些问题也可能导致这个问题。
三是测试用的笔记本电脑可能存在一些问题。
由于上述几种情况都属于外在原因，不能代表网络的真实情况，在计算掉线时不应计算这种情况，在仪表生成的测试报告中需手工将手机上发PDP去激活而导致的掉线情况排除。
但是手机上发PDP去激活消息后的一系列Ping fail会影响到DT测试的覆盖率，生成报告有相应的无覆盖的时间及记载里程，同样应手工排除手机上发PDP去激活情况对应的无覆盖里程。
3．2登陆服务器与开始下载数据之间发生小区重选导致掉线DT FTP下载设置为循环下载，在某一次下载开始时，手机发起尝试连接FTP Server、经过用户名、密码验证后，成功登陆FTP Server，之后发生小区重选，然后开始下载数据，但之后的下载过程不能下载一个字节的数据，一系列的Ping Success之后掉线，在实际测试中此类事件发生的概率并不高。