SGSN RAB指配策略优化总结报告
一、 背景福建WCDMA无线网络有三个厂家设备（华为、中兴、阿朗），自2009年5月17日试商用以来，阿朗片区的3G PDP上下文激活成功率一直较中兴、华为低，经中创信令平台采集历史记录发现，阿朗片区存在不少“语义错误”的PDP激活失败原因值，而其他厂家不存在该原因值的PDP激活失败。
二、 问题分析经分析，阿朗RNC与中兴SGSN配合存在如下信令交互过程：
[attach]1321[/attach]
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激活成功率修改后提高了一个多百分点，达到预期效果。
| 欢迎光临 51学通信技术论坛 (http://www.51xuetongxin.com/bbs/) | Powered by Discuz! X2 |