SGSN RAB指配策略优化总结报告

爱卫生

转载自移动网络优化企业联盟--交流论坛---专家推荐---案例分析版块。原文档下载地址是：
http://www.amno.cc/bbs/showbbs.asp?bd=32&id=1507&totable=1

SGSN RAB指配策略优化总结报告

一、 背景福建WCDMA无线网络有三个厂家设备（华为、中兴、阿朗），自2009年5月17日试商用以来，阿朗片区的3G PDP上下文激活成功率一直较中兴、华为低，经中创信令平台采集历史记录发现，阿朗片区存在不少“语义错误”的PDP激活失败原因值，而其他厂家不存在该原因值的PDP激活失败。

二、 问题分析经分析，阿朗RNC与中兴SGSN配合存在如下信令交互过程：

1. 用户激活了2个PDP上下文，RAB ID分别为5，6；

2. RNC为了节省资源，当RAB ID=5的上下文一段时间没有数据传输的时候，RNC发起RAB ID=5的PDP上下文的RAB释放流程；

3. 完成RAB ID =5的RAB释放后，用户又需要在RAB ID =5的上下文上进行数据传输，因为发送业务请求消息（类型DATA）到SGSN；

4. SGSN在收到业务请求时，对RAB ID为5和6都下发RAB指派消息；RNC对RAB ID =5 的RAB指派返回指派成功，对RAB ID =6的RAB指派返回指派失败；而后RAB ID = 5的PDP上下文能够正常业务，但由于RNC返回RAB指派失败，SGSN对RAB ID =6的PDP上下文会发起去活流程，在SGSN侧认为，RAB建立没有成功，去激活时自然不需要下发RAB释放消息给RNC。但阿朗的RNC侧在已经存在RAB的情况下收到同一个RAB ID的RAB建立消息时，当做RAB修改流程来处理，由于RAB指派消息里面的参数没有变化，所以修改失败，给SGSN回了RAB指派失败消息，但保留了该RAB。

5. 用户收到RAB ID =6的PDP上下文去活消息后，又继续对该PDP上下文发起激活，激活过程中，SGSN必然再次给RNC下发RAB建立消息，由于RNC的RAB已经存在，自然RAB指派还是失败，用户激活失败，而SGSN收到RAB指派失败消息，在激活失败的处理中也不会通知RNC释放该RAB；之后关于此RAB ID的PDP上下文必然都将激活失败。

通过信令流程的分析，我们可以确定导致PDP激活失败的原因是阿朗RNC对已经存在RAB的情况下收到同一个RAB ID的RAB建立消息时，由于RAB指派消息里面的参数没有变化，会发生RAB指配（修改）失败,并给SGSN回了RAB指派失败消息。而中兴\华为RNC 对这种类型的RAB指派不判断RAB指派消息里面的参数有没变化按正常的RAB修改流程来执行，不会出现RAB指派失败消息。

只有阿朗RNC对这类型的RAB指派消息处理有问题，需要求阿朗在RNC侧解决该问题，但3GPP对这种场景的信令没有做明确的要求，且阿朗做该补丁需要的周期较长，于是我们考虑在SGSN侧进行消息交互策略调整。

三、 解决方案

经咨询厂家，中兴SGSN设备有两个安全变量有助解决该问题：

1．业务请求过程中是否对已存在RAB的PDP上下文进行RAB重建安全变量：

该安全变量未打开，在业务请求过程中，对该用户的所有RAB都进行重建，即不管RAB是否存在都再次重建。

安全变量打开后，在业务请求过程中，则对于那些RAB已经建立的PDP上下文不再进行RAB重建。只对那些RAB已经释放的PDP上下文进行RAB重建。

2．激活过程中由于RAB指派失败是否给RNC发送RAB释放消息安全变量：

安全变量未打开，在激活或者二次激活过程中，如果RAB指派失败，按照协议流程处理，不会给RNC发送RAB Release Request消息。

考虑到出现该问题的根源为中兴SGSN在收到业务请求时，对RAB ID为5和6都下发RAB指派消息导致的，所以我们只需将“业务请求过程中是否对已存在RAB的PDP上下文进行RAB重建”这个安全变量打开即可解决该问题。

四、 实施效果

福建联通于8月31日凌晨在SGSN52上把“业务请求过程中是否对已存在RAB的PDP上下文进行RAB重建”这个安全变量打开，打开后我们分场景对信令进行跟踪:

1) 同时激活两个RAB，一条RAB释放后，手机主动发起的业务请求

SERVICE REQUEST
N_DataReqEvent	SECURITY MODE COMMAND
N_DataIndEvent	SECURITY MODE COMPLETE
N_DataReqEvent	COMMON ID
N_DataReqEvent	RAB ASSIGNMENT REQUEST
N_DataReqEvent	RAB ASSIGNMENT REQUEST
N_DataIndEvent	RAB ASSIGNMENT RESPONSE
N_DataIndEvent	RAB ASSIGNMENT RESPONSE
N_DataIndEvent	RAB RELEASE REQUEST
N_DataReqEvent	RAB ASSIGNMENT REQUEST
N_DataIndEvent	RAB ASSIGNMENT RESPONSE
N_DataIndEvent	IU RELEASE REQUEST
N_DataReqEvent	IU RELEASE COMMAND
N_DataIndEvent	IU RELEASE COMPLETE

从以上信令可以看出，一条RAB释放后，手机主动发起业务请求，SGSN还是会同时下发两条RAB指派消息。

2) 同时激活两个RAB，一条RAB释放后，网络侧下发寻呼引起的业务请求

N_UnitdataReqEvent	PAGING
N_UnitdataReqEvent	PAGING
SERVICE REQUEST
N_DataReqEvent	SECURITY MODE COMMAND
N_DataIndEvent	SECURITY MODE COMPLETE
N_DataReqEvent	COMMON ID
N_DataReqEvent	RAB ASSIGNMENT REQUEST
N_DataIndEvent	RAB ASSIGNMENT RESPONSE
N_DataIndEvent	DIRECT TRANSFER

从以上信令可以看出，一条RAB释放后，网络侧下发寻呼引起的业务请求时，SGSN只会对需要建立的RAB发起RAB指派消息。

通过以上信令的对比，我们可以得出“业务请求过程中是否对已存在RAB的PDP上下文进行RAB重建”这个安全变量只对网络侧下发寻呼引起的业务请求生效。

该安全变量修改后，经过半个月观察，发现“语义错误”引起的PDP激活失败几乎消失，说明之前“语义错误”引起的PDP激活失败主要是由网络侧下发寻呼引起的业务请求的场景下产生的，通过修改前后的指标对比，发现阿朗片区的PDP激活成功率修改后提高了一个多百分点，达到预期效果。