1、GPRSGPRS典型案例分析典型案例分析案例一：案例一：PDP激活成功率降低激活成功率降低l 描述：某省公司GPRS业务的PDP context成功率最近不稳定，有一定程度的降低。从网元告警情况分析未发现明显异常，需要工程师到现场处理。案例一：案例一：PDP激活成功率降低激活成功率降低二.处理过程 通过Traffica对现网的历史数据进行分析，PDPcontext激活失败的原因按类型分布如下：案例一：案例一：PDP激活成功率降低激活成功率降低三.分析在所有的失败原因里，主要是如下几个原因：0 x1E:占 95.34%，原因为用户APN错误0 x5C:占 0.52%，原因为用户未填写APN0 x
2、67:占 2.04%，原因为用户请求的服务未登记0 x90:占 0.08%，原因为用户激活过程未完成即被中断0XB2:占 2.02%，原因为用户激活过程未完成即被中断 其中0 x1E，0 x5C，0 x67均为用户原因，在KPI里不必考虑，而B2和90是对KPI有影响的。这两个错误的原因基本都是由于激活请求没有得到响应而产生。其中以B2数量较大，须重点分析。案例一：案例一：PDP激活成功率降低激活成功率降低三.分析 30日下午对现网数据进行实时分析，从15：20到15点35分采集了15分钟的数据，采集到29次B2事件。其中13次均为同一用户所为。该用户使用APN“ZHTKJ.HZ.SD.MNC
3、*.MCC*.GPRS”进行PDPcontext激活。进一步分析该用户的行为，发现该用户每分钟做一次PDPcontext激活，而且信令流程不同于一般的手机用户，应该是使用功能不完善的通讯软件在进行数据业务。并且由于未能成功建立通信连接而不断重拨，导致以上业务失败次数的增加。进一步对上午忙时的数据进行分析，同样发现该类用户在不断重复此项活动。这个APN的失败次数占到所有APN失败次数的52%。因此可以确定是该类用户使用某种不规范的终端工具，未能激活数据业务，自动重试，从而导致KPI的降低。案例一：案例一：PDP激活成功率降低激活成功率降低三.分析 进一步在Gp口检查该APN的激活情况，该请求正确
4、的发送到了目的GGSN，使用的是GTPv1。而从所有发到该目的GGSN的消息看该GGSN不能识别GTPv1的消息，只能处理GTPv0的消息，因此在激活过程中时间较长。SGSN的处理方式为先用GTPv1发3次请求，每次间隔3秒，若无回应则用GTPv0再发。因此第一次GTPv0的消息是在12秒以后才能发出，而该用户未能配合这类情况，在到达12秒之前就已经中断了该次激活，从而导致激活不成功 案例一：案例一：PDP激活成功率降低激活成功率降低四.结论从数据分析的情况看此次故障和核心网无关。建议查找该类用户，了解情况，并协商解决。建议联系目的GGSN所在的省分公司，解决GTP版本的问题。从GGSN侧解决
5、此问题。案例二：案例二：SGSN的的Gr Link负载不均衡负载不均衡一.描述 多条Gr Link中只有一部分的信令负荷为0，即该Gr Link的单向信令传输不生效。案例二：案例二：SGSN的的Gr Link负载不均衡负载不均衡二.处理过程 通过OLT命令查询相应的Gr LinklocalSequenceNumber(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-serviceChang
6、eCondition(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)案例三：话单中上网时间为案例三：话单中上网时间为0的问题的问题三.分析SGSN产生的S-CDR话单c g 1 _ 2 0 0 9 0 2 0 1 9 5 0
7、 0 0 7.c d r.b o s s:1 8 7 8 3 7 3 5 6 6 1 46001415203590620090131202240 0 8613022175033 220.206.129.48 220.206.129.2541535848641CMWAP.MNC001.MCC460.GPRS m n c 0 0.m c c 4 6 0.g p rs 10.100.152.3060F5 5184 70360821 80 00 83678 29686501FF00000000040000000102739673737482FFFF200902019422402009020194400
8、7 1047 案例三：话单中上网时间为案例三：话单中上网时间为0的问题的问题三.分析 一般来说：用户使用的时长在话单中取Duration字段，而不是timeUsage。只有在内容计费的同时又需要对子业务进行时长计费的时候在将该参数改为Enabled，如下面话单所示：listOfTrafficVolumes(12)：-changeTime(6)value:09 02 01 04 39 45+08 00-recordOpeningTime(13)value:09 02 01 04 22 18+08 00-duration(14)value:1047 而不是而不是-timeUsage(7)value
9、:0案例三：话单中上网时间为案例三：话单中上网时间为0的问题的问题三.分析检查FlexiISN3.0上Charging Class的设置：默认情况下，ChargingClass 里面的 Time项设置是 Disabled，在Disabled状态下，Timeusage的数值为0。打开Time值设置后，话单中 timeUsage 字段为实际流量。案例三：话单中上网时间为案例三：话单中上网时间为0的问题的问题四.结论 在不需要对子业务记录时长时关闭Time选项，在需要对子业务记录时长时再打开该选项。案例四：案例四：SGSN重启后部分重启后部分BVC状态不一致状态不一致 一.描述 SGSN重启动完成后
10、检查BVC状态均正常。但测试发现有部分基站下面GPRS业务不可用。在BSC上检查基站的GPRS为blocked状态。在SGSN重启后出现的这种现象，与核心网版本无关。案例四：案例四：SGSN重启后部分重启后部分BVC状态不一致状态不一致 二.处理过程 通过BSS侧的开关GPRS功能或者SGSN侧的NSVC闭解锁操作能够清除不正常的BSS状态。案例四：案例四：SGSN重启后部分重启后部分BVC状态不一致状态不一致 三.分析重置过程如下图所示：BSS SGSN BVC-RESET(BVCI=0)BVC-RESET(BVCI0,CELLid)-BVC-RESET-ACK(BVCI)FLOW-CONT
11、ROL-BVC-ACK -.案例四：案例四：SGSN重启后部分重启后部分BVC状态不一致状态不一致 三.分析1.在SGSN开始重启动之后，所有Gb的物理连接被中断。在BSC侧，当一个NSE(PCU)连接的所有NS-VC都为不可用的状态时，相关的BVC会被隐性地设置为BVC-BLOCK状态，也不会有消息通知BSSGP对端。2.当SGSN重启动完成后，Gb接口的物理连接被恢复。SGSN将发起BVC-RESET(signalling)程序。我们知道，SGSN侧只配置NSE(PCU)的的信息，关于每个BTS的BVC信息是动态的，没有手工配置数据。这里的BVC复位不是对于某一个BSS(CELL)发起的，
12、而是BVCI=0，标示这是复位信令BVC，只是通知到PCU。案例四：案例四：SGSN重启后部分重启后部分BVC状态不一致状态不一致 三.分析3.在收到BVC-RESET-ACK后，SGSN将NSE的状态置为可用状态。SGSN发起的复位程序即告完成。4.接下来，PCU侧根据控制的BTS状态，发起对于每一个BTS的BVC-RESET程序，通过该程序将BVC转换到可用状态。这时的复位程序是对于PTP(点到点)BVC，是对于单个BTS的，其中携带有BVCI和小区标示。同时，BSC会启动定时器TgbReset(T1)。5.在收到BVC-RESET PDU后，SGSN将BVCI和CELLid存储在动态数据
13、库中，标示BVCI为unblocked状态。并通过BVC-RESET-ACK消息向BSC确认该BVCI信息。案例四：案例四：SGSN重启后部分重启后部分BVC状态不一致状态不一致 三.分析6.在收到BVC-RESET-ACK消息后，BSC设置BVC状态为unblocked，并停止定时器TgbReset(T1)。然后发起Flow-Control-BVC程序。7.如果在定时器TgbReset超时后仍没有收到BVC-RESET-ACK消息，BSC会重发BVC-RESET消息，直到尝试次数达到计数器BVCResetRetries。如果仍然没有响应，BSC停止BVC-RESET程序，BVC状态保持为bl
14、ocked。案例四：案例四：SGSN重启后部分重启后部分BVC状态不一致状态不一致 三.分析根据现场观察到的情况，SGSN侧已经存储了相关的BVCI和Cellid信息，这说明SGSN已经收到了BSC发送过来的BVC-RESET消息。但是BSC侧并没有将相关BVC的状态置为unblock状态。因此问题发生在上述第5步和第六步之间。其中，可能的原因有：1.SGSN没有应答BVC-RESET-ACK消息，比如处理器忙的原因；2.SGSN应答的BVC-RESET-ACK消息没有成功发送给BSC，比如链路层上的过载而被丢弃；3.BSC收到了BVC-RESET-ACK消息，但无法处理，比如处理器忙的原因。
15、案例四：案例四：SGSN重启后部分重启后部分BVC状态不一致状态不一致 三.分析根据我们的经验，在SGSN重启后的短时间内Gb接口出现拥塞的可能性还是比较大的。一个BSC下的BVC复位完成是有先后顺序的，在完成复位后，BTS就立即投入工作状态。这时来自终端的重新附着请求量是很大的，在短时间内可能造成接口的过载。这时过载控制机制会被启动以逐步消除过载，其中可能会造成部分PDU被丢弃。那么对于后续的BVC复位程序是会造成影响的。根据当前网络参数配置，定时器TgbReset缺省设置为3秒，计数器BVCResetRetries也为3次。理论上说，如果Gb下行链路如果出现超过9秒的拥塞，而这期间有BSC
16、发起的BVC-RESET程序在执行，就可能出现我们看到的这种情况。案例四：案例四：SGSN重启后部分重启后部分BVC状态不一致状态不一致 四.结论作为改进的建议，可以适当加大BVC-RESET的定时器，以及增加BVC-RESET的重复尝试次数。比如TgbReset=12秒，BVCResetRetries=10次BSS参数取值范围及缺省值TgbReset 1-120s/3s Guards the reset procedureBVCResetRetries 1-100/3案例五：案例五：SGSN上安装上安装Feature378的的License后后无法激活无法激活PDP 一.描述 Flexi-I
17、SN添加新的License后存在一定概率无法正常激活PDP。案例五：案例五：SGSN上安装上安装Feature378的的License后后无法激活无法激活PDP 二.处理过程 SGSN Feature 378的解释为 SGSN GTP Information sending，激活该Feature后，SGSN向GGSN额外发送以下消息.Cell Global Identity(CGI).MS time zone.International Mobile Equipment Identity and Software Version Number(IMEISV)of the MS.Radio Ac
18、cess Type(RAT)案例五：案例五：SGSN上安装上安装Feature378的的License后后无法激活无法激活PDP 二.处理过程 根据现象分析，并非同一手机的每一次PDP激活都是失败的，在检查完SGSN的配置后以及与Flexi-ISN的连通性后，将目光转移到Flexi-ISN的配置上来案例五：案例五：SGSN上安装上安装Feature378的的License后后无法激活无法激活PDP 三.分析通过抓包分析可以看到：案例五：案例五：SGSN上安装上安装Feature378的的License后后无法激活无法激活PDP 三.分析在同一Flexi-ISN上激活的用户2G是无效的，但是3G
19、是有效的。进一步检查Flexi-ISN 中 Service access control:GERAN Allowed 被设置成 False。如果该值设置成 False，而且SGSN发送的消息中RAT字段在无线接入类型是 GERAN 的时候，PDP激活会被拒绝。如果该值设置成 False，而且SGSN发送的消息不包含RAT字段的时候，PDP激活仍然会被允许。而参数UTRAN Allowed 被设置成 True，所以3G用户并不受影响。把该值设置成 True 后，问题解决。案例五：案例五：SGSN上安装上安装Feature378的的License后后无法激活无法激活PDP 三.分析案例五：案例五：
20、SGSN上安装上安装Feature378的的License后后无法激活无法激活PDP 四.结论将UTRAN Allowed 和GERAN Allowed被设置成 True才能保证业务的正常使用。案例六：案例六：Inter-SGSN路由区更新后路由区更新后APN GOI丢失丢失 一.描述 用户在激活PDP context状态下切换到相邻SGSN然后继续GPRS会话，后续SGSN下生成的计费话单中没有填写APN_OI。计费中心在分拣话单时认为是错单。案例六：案例六：Inter-SGSN路由区更新后路由区更新后APN GOI丢失丢失 二.处理过程 按照3GPP相关规范，SGSN之间通过GTP程序SG
21、SN_Context_Request传递用户的MM Context和PDP context。在Release 99中，PDP context中的APN字段只包含APN_NI并不包含APN_OI。(APN_OI:MNC002.MCC460.GPRSAPN_NI:UNIWAP）3GPP TS 29.060 V3.12.0(2019-03)Release 997.7.29PDP Context The APN is the Access Point Name in use in the old SGSN.I.e.the APN sent in the Create PDP Context reque
22、st message.7.7.30Access Point Name The Access Point Name contains a logical name that is the APN Network Identifier(see 3GPP TS 23.060).案例六：案例六：Inter-SGSN路由区更新后路由区更新后APN GOI丢失丢失 二.处理过程 而在Release 4之后，规范对相关字段进行了修改，PDP context中的APN将同时包含APN_NI和APN_OI。3GPP TS 29.060 V4.4.0(2019-03)Release 47.7.29PDP Cont
23、extThe APN is the Access Point Name in use in the old SGSN.This APN field shall be composed of the APN NetworkIdentifier part and the APN Operator Identifier part.案例六：案例六：Inter-SGSN路由区更新后路由区更新后APN GOI丢失丢失 三.分析 用户是在Release 99的SGSN下发起激活PDP context的。在路由区更新到相邻SGSN的时候，APN_OI不会被传递过去。在这之后如果有继续的SGSN改变，APN_O
24、I也不会再被填充。案例六：案例六：Inter-SGSN路由区更新后路由区更新后APN GOI丢失丢失 四.结论 差异是由于规范的变化引起的，按照向下兼容的规则SGSN都能够接受Release 99的消息。计费中心应当调整其后处理软件以兼容和支持更多的网元版本。案例七：单向案例七：单向RAU更新失败更新失败 一.描述 从LAC9525至LAC9753单向RAU失败。案例七：单向案例七：单向RAU更新失败更新失败 二.处理过程 路由区更新失败，从PAPU上解析相应LAC地址，DNS解析正常。在GN口抓包：没有发现从LAC9753所在PAPU发至LAC9525所在PAPU的SGSN context
25、request 消息，即新的SGSN没有向旧的SGSN发送SGSN context request 消息 案例七：单向案例七：单向RAU更新失败更新失败 三.分析 新的 SGSN不向旧的SGSN发送SGSN context request消息的可能原因是：1）新的SGSN没有解析到新的SGSN的PAPU ip地址；2）新的SGSN认为手机的RAI(MCC+MNC+LAC+RAC)应该是自己处理的。案例七：单向案例七：单向RAU更新失败更新失败 三.分析 检查SGSN10发现LAC9525下的小区曾经加载成功的日志。MAIN LEVEL COMMAND EJL:PAPU=4;LOADING PR
26、OGRAM VERSION 7.5-6SGSN SZHSG10BNK 2019-06-16 03:35:05NETWORK CONFIGURATION DATA OUTPUTNSEI-00351PAPU-04MCC-460 MNC-00 LAC-09525 RAC-001 CI-03901 BVCI-00386 STATE-WO案例七：单向案例七：单向RAU更新失败更新失败 三.分析 手机从LAC9525 到 LAC9753，将向SGSN10发起RAU request。SGSN10检查RAI(MCC+MNC+LAC+RAC),发现这个路由区应该是自己处理的。然而SGSN10检查SMMU（GSB
27、ASE)）并不能找到该用户的信息，导致LAC9525到LAC9753的RAU失败。所以，BSC侧对LAC数据的错误配置，是导致本次RAU失败的原因。案例七：单向案例七：单向RAU更新失败更新失败 四.结论 1.在SGSN的LAC 关联里只保留与其实际相关联的LAC信息，删除不必要的LAC。2.在BSC侧检查，保证没有同一个LAC的小区分别挂在不同的SGSN上的情况。案例八：案例八：GSBASE程序模块告警程序模块告警一.描述 某省分由于业务推广，用户量增加比较多，SGSN扩容无法跟上，容量已经接近饱和。最近不断出现告警。检查发现SGSN容量应该在64万，用MMN查看的用户数已经达到62万，而用
28、GHP察看M-CDR有15万，S-CDR有2万。从S-CDR的情况看业务量并没有很大的增长，不理解为什么SGSN会有GSBASE程序模块告警。案例八：案例八：GSBASE程序模块告警程序模块告警二.处理过程 MCDR（15万）代表着实际的附着用户数，SCDR（2万）代表着实际的PDP激活数量，MMN（62万）代表着GSBASE 的用户数，即从HLR得到的尚未purge的用户数，其中包含着当前附着的，以及已经去附着但没有被purge掉的。案例八：案例八：GSBASE程序模块告警程序模块告警三.分析 MCDR（15万）代表着实际的附着用户数，SCDR（2万）代表着实际的PDP激活数量，MMN（62
29、万）代表着GSBASE 的用户数，即从HLR得到的尚未purge的用户数，其中包含着当前附着的，以及已经去附着但没有被purge掉的。案例八：案例八：GSBASE程序模块告警程序模块告警三.分析 MM里面的DET,STT，UDC和UDL来减少detach用户存在于GSBASE 里的数量。DET:DETACH TIMER 附着用户从上一次去激活算起，如果在DET时间内均未发起PDP激活请求，则由网络侧对用户发起DETACH。STT:DETACHED SUBSCRIBER STORAGE TIME 用户完成DETACH后（可以是手机侧发起，也可以是网络侧发起）STT参数开始计时，如果在STT时间内
30、没有再发起ATTACH请求，那么将被打上标签，在特定的时间进行Purge。案例八：案例八：GSBASE程序模块告警程序模块告警三.分析 UDC:UTILISATION RATE DEPENDENT CLEANING UDL:UTILISATION RATE ZERO LIMIT 如果ATTACH用户的比例在UDC已下时，DET生效。如果ATTACH用户的比例在UDC和UDL之间时，DET时间为(-SST)*(current_usage_level-UDC)/(UDL-UDC)+SST如果ATTACH用户的比例超过UDL的范围是DET时间为0。案例八：案例八：GSBASE程序模块告警程序模块告警
31、三.分析 案例八：案例八：GSBASE程序模块告警程序模块告警三.分析 SGSN的SMMU中的GSBASE数据库最多可以存储SMMU标称值的132%。多出的32%是为了预留给已经不在SGSN中附着但是仍然存在SGSN的GSBASE数据库中的用户。例如：SGSN的附着用户数为64万时，每个SMMU的附着用户数为最高为16万，而GSBASE数据库中存储的最多用户数为211万案例八：案例八：GSBASE程序模块告警程序模块告警三.分析 可以通过减小STT值（缺省1天，即减小用户在GSBASE 的存储时间）；减小UDC（缺省80%，），减小UDL（缺省100%）来降低SGSN的负荷下面是一个例子：RE
32、ADY STATE TIMER.(RDY)000-44 mmm-ssSTANDBY STATE TIMER.(STBY)000-44 mmm-ssMS REACHABLE TIMER.(MSRT)140-00 mmm-ssDETACH TIMER.(DET)02-00 hh-mmPERIODIC RA UPDATE TIMER.(PRAU)066-00 mmm-ssVLR PERIODIC CLEANING START TIME.(CTIM)4:12 hh:mmDETACHED SUBSCRIBER STORAGE TIME.(STT)001-00 ddd-hhUTILISATION RATE DEPENDENT CLEANING.(UDC)85%UTILISATION RATE ZERO LIMIT.(UDL)95%案例八：案例八：GSBASE程序模块告警程序模块告警四.结论 DET等参数并非越小越好，要根据实际情况进行调整。
