WCDMA PDP激活成功率是衡量分组域SGSN设备运行的重要指标。本文根据SGSN的性能统计数据，对Iu模式PDP激活成功率进行初步评估，结合CHR日志、用户跟踪、Iu口信令抓包等信息对产生PDP激活失败的场景进行详细的分析，并给出优化建议。
指标定义如下：
PDP激活成功率（不含用户原因）=（成功次数[B]＋用户原因[C]）÷请求次数[A]×100%
PDP激活成功率（含用户原因）=成功次数[B] ÷请求次数[A]×100%
说明：请求次数[A]指Iu模式 MS激活会话请求次数
成功次数[B]指Iu模式 MS激活会话成功次数
用户原因[C]指下列指标之和
Iu模式激活失败次数（请求的服务未签约）
Iu模式激活失败次数（未知APN）
Iu模式激活失败次数（用户鉴权失败）
Iu模式 激活失败次数（DNS解析失败）
Iu模式 激活失败次数 (未知PDP地址或类型)
非用户原因[D]指下列指标之和
Iu模式激活失败次数（RAB指配失败）
Iu模式激活失败次数（GGSN拒绝）
Iu模式激活失败次数（未定义原因）
一、 PDP激活成功率概述
首先通过话统数据进行失败原因分析，激活失败原因如下：
1、非用户原因分析
表1-1Iu模式PDP激活失败非用户原因统计
失败原因 失败次数 非用户原因总失败次数 失败次数百分比
Iu模式激活失败次数（RAB指配失败） 12921 13989 92.37%
Iu模式激活失败次数（DNS解析失败） 801 13989 5.73%
Iu模式激活失败次数（GGSN拒绝） 243 13989 1.74%
Iu模式激活失败次数（未定义原因） 24 13989 0.17%
2、用户原因分析
表1-2 Iu模式PDP激活失败用户原因统计
失败原因 失败次数 非用户原因总失败次数 失败次数百分比
Iu模式激活失败次数（请求的服务未签约） 6316 8441 74.83%
Iu模式激活失败次数（用户鉴权失败） 1318 8441 15.61%
Iu模式激活失败次数（未知APN） 807 8441 9.56%
二、 RAB指配失败分析
在3G网络中，RAB在终端和CN节点间提供满足QoS要求的信令和用户面传输质量。在PDP激活过程中，当SGSN和UE、GGSN协商好QoS后，便根据该QoS下发RAB指配请求，PS RAB的指配是由SGSN控制的，因为在PDP激活过程中，SGSN最终和终端、GGSN协商了QoS，而这个QoS又决定了RAB为非接入层提供的服务质量。
下面主要通过SGSN的CHR日志和用户消息跟踪分析RAB指配失败原因和失败场景，由于CHR对PDP激活失败原因“RAB指配失败”的场景统计不具体，后续也针对SGSN01 Iu口进行了抓包分析。
RAB指配失败对应的CHR外部原因值为SM_RAB_ASSGIN_FAILED详细统计分析其对应的内部原因如下：
CHR内部原因 失败次数 占总网络原因失败次数百分比
SM_RAB_ASSIGN_RSP_FAIL 395 59.94%
SM_RAB_ASSIGN_RSP_FAIL_TRAFFIC_CALSS_NOT_AVAILABLE 246 37.33%
SM_RAB_ASSIGN_RSP_TIMEOUT 16 2.43%
SM_RAB_ASSIGN_RSP_FAIL_INVALID_RAB_PARAMETERS_COMBINE 2 0.30%
可以看出SM_RAB_ASSIGN_RSP_FAIL和TRAFFIC_CALSS_NOT_AVAILABLE的失败次数最多，以下对这两种情况进行分析：
1、 SM_RAB_ASSIGN_RSP_FAIL场景分析：
SM_RAB_ASSIGN_RSP_FAIL中失败原因为radio-connection-with-UE-Lost (46)的场景分析，此原因表示RNC和UE失去无线连接，突然信号不好，网络侧与UE之间的连接断开了。之后SGSN发送DT_SM_ACT_PDP_REJ给MS，失败原因为“protocol-error-unspecified”。
出现此情况有两方面的原因:
UE侧原因：UE没有完成去激活流程就与网络失去联系，多数和终端的行为有关，如用户直接把数据卡从电脑拔掉，UE突然掉电，进入无信号覆盖或信号较弱区域等。
RAN侧原因：无线信号干扰较强和信号被建筑物遮挡，影响终端与所在小区的联系。
通过统计可以分析出失败次数较多的TOP RNC，也是无线侧配合改进的依据。
优化建议:UE原因不建议优化，以节省无线资源；RAN侧原因可以由无线侧配合检测出信号弱和高干扰的服务区,加强网络覆盖和排除干扰；
2、 TRAFFIC_CALSS_NOT_AVAILABLE场景分析：
从用户跟踪看：这个用户在进行两个PDP激活，NSAPI为5的已经激活了，APN为3GNET，请求的QOS为interactive类型。但是NSAPI为6（APN为3gwap）的有时候能激活成功，有时候就失败。对上图的解释：消息跟踪显示，MS在332行进行了NSAPI为5的PDP激活，后业务正常，到3686行时，在NSAPI为5的PDP还存在的情况下，进行了NSAPI为6的PDP激活，也成功了。之后两个PDP均由于非活动原因释放了RAB。当MS发起业务请求时，核心网需要根据终端携带的Uplink data status信元判断为哪个PDP的业务请求，从而决定如何下发RAB的指配请求，该信元为可选信元，由于本次终端侧没有携带该信元上来，因此SGSN的处理方式为同时将两个RAB请求下发给RNC。参见协议3GPP TS 24.008第10.5.7章节：
For a Service Request of type "data", the MS may include the Uplink data status information element in the SERVICE REQUEST message. The Uplink data status information indicates which preserved PDP contexts have pending uplink data to be sent. If the Uplink data status information element is included in the SERVICE REQUEST message with service type "data", the network may use this information to determine which of the RABs for the preserved PDP contexts to re-establish.
后续的跟踪显示，RNC对NSAPI为5的RAB请求成功建立，对NSAPI为6的RAB请求，建立失败，且该失败导致后续终端后续反复PDP激活，且一直失败。直到20多分钟后，NSAPI为6的RAB建立成功，该次成功和前面的失败情况完全相同，因此判断是RNC侧对多个APN激活时资源分配处理的问题，随后经过RNC侧实施可以支持多RAB指配的LICENSE后，指标有显著提升，从原忙时98.65%提升至99.23%，同时也提升了用户的使用感知。
3、 Iu口抓包深入分析
结合现网情况，由于CHR分析对PDP激活失败原因“RAB指配失败”的场景统计具体不到服务区，因此这里对DGSGSN Iu信令面接口抓包做深入分析，选取22:00到23:00的数据，进行分析。得到的失败原因分布如下：
表2-2RAB失败原因分布
失败原因 次数
requested-traffic-class-not-available 191
radio_connection_with_UE_lost 150
release_due_to_utran_Generated Reason 29
failure_in_the_radio_interface Procedure 16
no_resource_available 7
unspecified_failure 7
invalid_RAB_ID 4
invalid_rab_parameter 2
主要的RAB失败原因有8种：Requested Traffic Class not Available(18)，radio-connection-with-UE-Lost(46)，Release Due To UTRAN Generated Reason(15)， Failure in the Radio Interface Procedure(14)，no-resource-available(114)，unspecified failure， invalid_rab_parameter 和invalid_RAB_ID。
1） Requested Traffic Class not Available(18)
对于此原因的失败，参见TRAFFIC_CALSS_NOT_AVAILABLE场景分析，需要RNC侧配合解决多RAB支持的情况；
2） Radio-connection-with-UE-Lost(46)
UE侧原因：UE没有完成去激活流程就与网络失去联系，多数和终端的行为有关，如用户直接把数据卡从电脑拔掉，UE突然掉电，进入无信号覆盖或信号较弱区域等。RAN侧：无线信号干扰较强和信号被建筑物遮挡，影响终端与所在小区的联系；
3） Release Due To UTRAN Generated Reason(15)
对比正常流程中RAB_AssignmentRequest消息参数和失败流程中参数，核心网下发RAB_AssignmentRequest消息携带参数正常，需要无线侧定位解决；
4） Failure in the Radio Interface Procedure(14)
对比正常流程中RAB_AssignmentRequest消息参数和失败流程中参数，核心网下发RAB_AssignmentRequest消息携带参数正常，需要无线侧定位解决
5） no-resource-available(114)
对比分析interactive和background类型RAB指配请求携带的参数均合法正常。可能因为无线资源不足，无线优先级低的业务资源分配不能保障。该失败原因分布相对集中，只存在于RNC2（LAC: 42321）下的27811服务区，建议无线重点关注此服务区的资源情况并定位出具体失败场景。
三、 用户原因分析
1、 请求的服务未签约
这种情况是用户失败原因中的重要原因跟踪这类失败用户可以看到，失败消息中携带携带拒绝原因值均为“requested service option not subscribed”。
失败现象a：漫游用户
该类失败主要是用户的签约信息不匹配，或者用户已欠费停机。对现网分析发现，这些用户基本都是漫游到东莞的用户，8618602835933的用户跟踪显示，该用户在SGSN内已附着，但使用DSP USPUPDP命令查询不到该用户的任何签约信息，说明该用户已经欠费停机或根本没有签约GPRS业务。
失败现象b：用户签约信息不匹配
用户在HLR中签约IPV4，但是却发起IPV6的PDP激活，因此被SGSN直接拒绝。
对于这种拒绝原因值的场景， 由于用户收到拒绝消息后会在短时间内重复尝试多次，某些手机可能自动重复发起PDP激活请求，因此这种用户对网络指标影响很大。
2、 用户鉴权失败
从信令跟踪来看，此类用户为预付费用户，需要GGSN到OCS或者AAA鉴权。鉴权失败则SGSN侧给用户回复鉴权失败，该场景下也会导致终端频繁激活，从而影响PDP激活指标。可以由OSC检查用户信息，如用户欠费，则及时以短信等方式通知用户续费
四、 结论及建议
引起PDP激活失败的主要的非用户原因为“RAB指配失败”；主要的用户原因为 “请求的服务未签约”和“用户鉴权失败”。对于“RAB指配失败”与无线侧相关，核心网侧配合优化，根据Iu口抓包分析，给出了“RAB指配失败”中不同原因所占比例及TOP服务区。对于用户原因“请求的服务未签约”和“用户鉴权失败”，建议OSC及时更新用户数据，对于欠费用户及时以短信方式通知用户续费等方式解决，以提升用户感知,增加收益
总结如下表所示：
原因分类 性能统计失败原因 CHR内部失败原因 用户消息中携带的失败原因 场景描述及优化建议
非用户原因 RAB指配失败 SM_RAB_ASSIGN_RSP_FAIL misc:0x72 (114): no-resource-available 描述：RNC侧相关资源不足（功率、CE、带宽等资源）引起。
建议：核心网根据Iu接口抓包分析给出该失败原因的分布情况,无线配合核查是否存在小区闭塞,资源不足的情况并实施优化。
radioNetwork:0x2e (46): radio-connection-with-UE-Lost 描述：RNC和UE失去无线连接，突然信号不好，引起RAB指配失败。
建议：需要无线侧配合检测出信号弱和高干扰的服务区,加强网络覆盖和排除干扰。
radioNetwork:0xf (15): release-due-to-utran-generated-reason 描述：由于UTRAN产生的原因导致RNC触发的RAB释放，可能因小区闭塞或者公共信道不可用引起。
建议：核心网根据Iu接口抓包分析给出该失败原因的分布情况,需要无线侧协助分析解决。
Failure in the Radio Interface Procedure(14) 描述：处理过程在空口发生失败。
建议：核心网下发RAB_AssignmentRequest消息携带参数正常，,需要RNC侧分析解决。
No Radio Resources Available in Target cell (53) 描述：在RAB指配过程中发生资源迁移流程，由目的RNC 为此次迁移分配无线资源。如果资源全部或者部分分配失败，目的RNC 向CN 发送RELOCATION FAILURE 消息在该消息中给出失败原因。
建议：核心网根据Iu接口抓包分析该原因的分布规律,需要RNC侧分析解决。
SM_RAB_ASSIGN_RSP_ FAIL_ TRAFFIC-CLASS-NOT-AVAILABLE radioNetwork:0x12 (18): requested-traffic-class-not-available 描述：RNC对NSAPI为5的RAB请求成功建立，对NSAPI为6的RAB请求，建立失败，且该失败导致后续终端后续反复PDP激活，且一直失败。直到20多分钟后，NSAPI为6的RAB建立成功，该次成功和前面的失败情况完全相同。
建议：怀疑该问题是SGSN和RNC配合问题，需要同RNC侧配合解决。
SM_RAB_ASSIGN_RSP_TIMEOUT 无 描述：RNC侧回复IU RELEASE COMPLETE消息太慢，导致流程嵌套。
建议：需要RNC侧定位回复IU RELEASE COMPLETE消息慢的问题。
用户原因 请求的服务未签约 SM_NO_MATCHED_SUBSCRIBE_INFO Cause:requested-service-option-not-subscribed (33) 用户欠费或激活PDP与签约数据不匹配，导致激活失败。
鉴权失败 SM_USER_AUTHENTICATION_FAILED Cause:user-authentication-failed (29) 用户为预付费用户，OSC鉴权失败导致，可能原因为用户欠费导致，需要及时短信通知用户续交话费。
|
