诺西GPRS典型案例分析.ppt

GPRS典型案例分析,案例一：PDP激活成功率降低,描述：某省公司GPRS业务的PDP context成功率最近不稳定，有一定程度的降低。从网元告警情况分析未发现明显异常，需要工程师到现场处理。,案例一：PDP激活成功率降低,二.处理过程 通过Traffica对现网的历史数据进行分析，PDPcontext激活失败的原因按类型分布如下：,案例一：PDP激活成功率降低,三.分析在所有的失败原因里，主要是如下几个原因：0 x1E:占 95.34%，原因为用户APN错误0 x5C:占 0.52%，原因为用户未填写APN0 x67:占 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*.MCC*.GPRS”进行PDPcontext激活。进一步分析该用户的行为，发现该用户每分钟做一次PDPcontext激活，而且信令流程不同于一般的手机用户，应该是使用功能不完善的通讯软件在进行数据业务。并且由于未能成功建立通信连接而不断重拨，导致以上业务失败次数的增加。进一步对上午忙时的数据进行分析，同样发现该类用户在不断重复此项活动。这个APN的失败次数占到所有APN失败次数的52%。因此可以确定是该类用户使用某种不规范的终端工具，未能激活数据业务，自动重试，从而导致KPI的降低。,案例一：PDP激活成功率降低,三.分析 进一步在Gp口检查该APN的激活情况，该请求正确的发送到了目的GGSN，使用的是GTPv1。而从所有发到该目的GGSN的消息看该GGSN不能识别GTPv1的消息，只能处理GTPv0的消息，因此在激活过程中时间较长。SGSN的处理方式为先用GTPv1发3次请求，每次间隔3秒，若无回应则用GTPv0再发。因此第一次GTPv0的消息是在12秒以后才能发出，而该用户未能配合这类情况，在到达12秒之前就已经中断了该次激活，从而导致激活不成功,案例一：PDP激活成功率降低,四.结论从数据分析的情况看此次故障和核心网无关。建议查找该类用户，了解情况，并协商解决。建议联系目的GGSN所在的省分公司，解决GTP版本的问题。从GGSN侧解决此问题。,案例二：SGSN的Gr Link负载不均衡,一.描述 多条Gr Link中只有一部分的信令负荷为0，即该Gr Link的单向信令传输不生效。,案例二：SGSN的Gr Link负载不均衡,二.处理过程 通过OLT命令查询相应的Gr Link ZOLT;=RECEIVED TRANSMITTED LINK ERLANGS ERLANGS=1 0.002 0.004 2 0.002 0.004 3 0.002 0.004 4 0.002 0.004 5 0.002 0.004 6 0.002 0.004 7 0.002 0.004 8 0.002 0.004 9 0.002 0.000 10 0.002 0.000 11 0.002 0.000 12 0.002 0.000 13 0.001 0.000 14 0.002 0.000 15 0.001 0.000 16 0.002 0.000 17 0.001 0.000 18 0.002 0.000 19 0.002 0.000 20 0.002 0.000 21 0.002 0.000 22 0.002 0.000 23 0.002 0.000 24 0.002 0.000 25 0.002 0.004 26 0.002 0.004 27 0.002 0.004 28 0.002 0.004 29 0.002 0.004 30 0.002 0.004 31 0.002 0.004 32 0.002 0.004 COMMAND EXECUTED,案例二：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的优先级高。,案例二：SGSN的Gr Link负载不均衡,三.分析 NVI:NA0,;SGSN CCSGSN06BNK 2008-12-26 18:10:48SIGNALLING ROUTE STATESDESTINATION:SP RS ROUTES:SPNET SP CODE H/D NAME STATE NET SP CODE H/D NAME STATE PRIO-NA0 07FEA3/007-254-163 SGSN6-OWN SP AS SIGNALLING END POINTNA0 07FF04/007-255-004 HSTP2 UA NA0 07FF04/007-255-004 HSTP2 AV-EX 7 NA0 07FF05/007-255-005 HSTP1 AV-SP 5NA0 07FF05/007-255-005 HSTP1 UA NA0 07FF04/007-255-004 HSTP2 AV-EX 7 NA0 07FF05/007-255-005 HSTP1 AV-SP 5,案例二：SGSN的Gr Link负载不均衡,四.解决方法 SGSN在对信令链路使用时，都是采用ITU-T推荐的4位SLS编码方式，也就是说，对同一SPC可以控制链路的最大个数只能是2的4次方个（即16个）。因此即使我们定义了32个链路，也会有一半的链路没有负荷。GROUP M:SLS BITS=INDEX NAME VALUE-M0 LINK_SLS_BIT_MASK 11111111M1 ROUTE_SLS_BIT_MASK 11111111M2 SLS_LENGTH 4M3 INTERNAL_SLS_LENGTH 5M4 NEW_SLS_IN_SCCP0CLASS NOT IN USE M5 LS_LICENCE_KEY_1 0M6 LS_LICENCE_KEY_2 0,案例二：SGSN的Gr Link负载不均衡,四.解决方法 我们可以通过修改每个route set下的两个link set的优先级来打破均衡，采用一主一备的方式工作,如下所示：NVI:NA0,;SGSN CCSGSN06BNK 2008-12-26 18:10:48SIGNALLING ROUTE STATESDESTINATION:SP RS ROUTES:SPNET SP CODE H/D NAME STATE NET SP CODE H/D NAME STATE PRIO-NA0 07FEA3/007-254-163 SGSN6-OWN SP AS SIGNALLING END POINTNA0 07FF04/007-255-004 HSTP2 UA NA0 07FF04/007-255-004 HSTP2 AV-EX 7 NA0 07FF05/007-255-005 HSTP1 AV-SP 5NA0 07FF05/007-255-005 HSTP1 UA NA0 07FF05/007-255-005 HSTP1 AV-EX 7 NA0 07FF04/007-255-004 HSTP2 AV-SP 5,案例三：话单中上网时间为0的问题,一.描述SA话单有用户的上下行流量，但是用户的时间长短是0,案例三：话单中上网时间为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)-volumeUplink(12)value:83678-volumeDownlink(13)value:296865-serviceIdentifier(17)value:33554433-consolidationResult(35)value:normal(0),案例三：话单中上网时间为0的问题,三.分析SGSN产生的S-CDR话单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:0,案例三：话单中上网时间为0的问题,三.分析检查FlexiISN3.0上Charging Class的设置：默认情况下，ChargingClass 里面的 Time项设置是 Disabled，在Disabled状态下，Timeusage的数值为0。打开Time值设置后，话单中 timeUsage 字段为实际流量。,案例三：话单中上网时间为0的问题,四.结论 在不需要对子业务记录时长时关闭Time选项，在需要对子业务记录时长时再打开该选项。,案例四：SGSN重启后部分BVC状态不一致,一.描述 SGSN重启动完成后检查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-CONTROL-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)发起的，而是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存储在动态数据库中，标示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状态保持为blocked。,案例四：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消息，但无法处理，比如处理器忙的原因。,案例四：SGSN重启后部分BVC状态不一致,三.分析根据我们的经验，在SGSN重启后的短时间内Gb接口出现拥塞的可能性还是比较大的。一个BSC下的BVC复位完成是有先后顺序的，在完成复位后，BTS就立即投入工作状态。这时来自终端的重新附着请求量是很大的，在短时间内可能造成接口的过载。这时过载控制机制会被启动以逐步消除过载，其中可能会造成部分PDU被丢弃。那么对于后续的BVC复位程序是会造成影响的。根据当前网络参数配置，定时器TgbReset缺省设置为3秒，计数器BVCResetRetries也为3次。理论上说，如果Gb下行链路如果出现超过9秒的拥塞，而这期间有BSC发起的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-ISN添加新的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 Access Type(RAT),案例五：SGSN上安装Feature378的License后无法激活PDP,二.处理过程 根据现象分析，并非同一手机的每一次PDP激活都是失败的，在检查完SGSN的配置后以及与Flexi-ISN的连通性后，将目光转移到Flexi-ISN的配置上来,案例五：SGSN上安装Feature378的License后无法激活PDP,三.分析通过抓包分析可以看到：,案例五：SGSN上安装Feature378的License后无法激活PDP,三.分析在同一Flexi-ISN上激活的用户2G是无效的，但是3G是有效的。进一步检查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,三.分析,案例五：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程序SGSN_Context_Request传递用户的MM Context和PDP context。在Release 99中，PDP context中的APN字段只包含APN_NI并不包含APN_OI。APN_NI:UNIWAP）,案例六：Inter-SGSN路由区更新后APN GOI丢失,二.处理过程 而在Release 4之后，规范对相关字段进行了修改，PDP context中的APN将同时包含APN_NI和APN_OI。,案例六：Inter-SGSN路由区更新后APN GOI丢失,三.分析 用户是在Release 99的SGSN下发起激活PDP context的。在路由区更新到相邻SGSN的时候，APN_OI不会被传递过去。在这之后如果有继续的SGSN改变，APN_OI也不会再被填充。,案例六：Inter-SGSN路由区更新后APN GOI丢失,四.结论 差异是由于规范的变化引起的，按照向下兼容的规则SGSN都能够接受Release 99的消息。计费中心应当调整其后处理软件以兼容和支持更多的网元版本。,案例七：单向RAU更新失败,一.描述 从LAC9525至LAC9753单向RAU失败。,案例七：单向RAU更新失败,二.处理过程 路由区更新失败，从PAPU上解析相应LAC地址，DNS解析正常。在GN口抓包：没有发现从LAC9753所在PAPU发至LAC9525所在PAPU的SGSN context 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 PROGRAM VERSION 7.5-6SGSN SZHSG10BNK 2007-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（GSBASE)）并不能找到该用户的信息，导致LAC9525到LAC9753的RAU失败。所以，BSC侧对LAC数据的错误配置，是导致本次RAU失败的原因。,案例七：单向RAU更新失败,四.结论 1.在SGSN的LAC 关联里只保留与其实际相关联的LAC信息，删除不必要的LAC。2.在BSC侧检查，保证没有同一个LAC的小区分别挂在不同的SGSN上的情况。,案例八：GSBASE程序模块告警,一.描述 某省分由于业务推广，用户量增加比较多，SGSN扩容无法跟上，容量已经接近饱和。最近不断出现告警。检查发现SGSN容量应该在64万，用MMN查看的用户数已经达到62万，而用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万）代表着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时间内没有再发起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程序模块告警,三.分析,案例八：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的负荷下面是一个例子：READY 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等参数并非越小越好，要根据实际情况进行调整。,