交换拥塞导致未接通问题分析报告.doc

交换设备拥塞导致未接通
问题分析报告
问题描述:
8月13日—8月15日期间,在路测中发现主叫呼叫建立成功后,CN下发Disconnect （Cause_value：(42)Switching equipment congestion交换设备拥塞）导致发生3次未接通。
问题分析：
1.乐山钟楼-2未接通 发生时间：2012-8-13 09:39:26
UE在乐山钟楼-2小区下完成RB建立后，CN下发Disconnect （Cause_value：(42)Switching equipment congestion交换设备拥塞）导致本次呼叫未接通。从路测数据来看，当时无线环境较好(PCCPCH RSCP=-45dbm,PCCPCH C/I=20db)。具体路测信令如下图所示：

2.岷江中街245号-3未接通发生时间：2012-8-13 15:22:35
UE在岷江中街245号-3小区下完成RB建立后，CN下发Disconnect （Cause_value：(42)Switching equipment congestion交换设备拥塞）导致本次呼叫未接通。从路测数据来看，当时无线环境较好(PCCPCH RSCP=-51dbm,PCCPCH C/I=19db)。具体路测信令如下图所示：

3.乐山卫校-1未接通发生时间：2012-8-15 15:26:37
UE在乐山卫校-1小区下完成RB建立后，CN下发Disconnect （Cause_value：(42)Switching equipment congestion交换设备拥塞）导致本次呼叫未接通。具体后台信令如下图所示：

通过以上3次未接通的信令来看，全部是在RB建立后，CN下发Disconnect （Cause_value：(42)Switching equipment congestion交换设备拥塞）导致的未接通。从UTRAN网络的信令流程来看，UE在完成RB建立后，无线网的准备工作已经基本完成，UE就在等待CN给其下发ALTERING。具体如下图所示：

由于这三次呼叫被叫号码都是10086，所以我们使用局间呼叫的信令流程来进行问题定位分析。从核心网的信令流程来看，这三次未接通的信令流程，都是在step 18:MSS-A用H.248 ADD_Request命令通知MGW A准备主叫Iu侧承载时，发生错误。具体如下图所示：

局间呼叫核心网信令流程简介：
step 1: 移动用户A拨打移动用户B，UE-A在初始直传消息CM SERVICE REQUEST携带的信元CM service type中指明业务为移动主叫建立；
step 2: MSS-A收到Call Setup消息，即用MAP_SEND_ROUTING_INFORMATION向HLR要被叫用户的漫游号码；
step 3: HLR用MAP_PROVIDE_ROAMING_NUMBER向被叫用户UE-B所登记的VLR B要漫游号码；
step 4: VLR B用MAP_PROVIDE_ROAMING_NUMBER向HLR返回UE-B的漫游号码；
step 5: HLR用MAP_PROVIDE_ROAMING_NUMBER向MSS-A返回UE-B的漫游号码；
step 6: MSS-A在发送直传消息Call Proceeding通知UE-A呼叫继续处理；
step 7: MSS-A用漫游号码向MSS-B发起BICC消息IAM；
step 8: MSS-B收到IAM即向UE-B发起寻呼；
step 9: UE-B响应寻呼；
step 10: MSS-B用直传消息Call Setup建立与UE-B的信令连接；
step 11: UE-B检查承载能力通过后，即用直传消息Call Confirmed向MSS-B响应；
step 12: MSS-B用H.248 ADD_Request命令通知MGW B准备被叫网络侧承载，承载收发模式为双向；
step 13: MGW B网络侧承载准备完成，用H.248 ADD_Reply命令响应；
step 14: MSS-B用BICC APM消息将承载信息告诉MSS-A；
step 15: MSS-A用H.248 ADD_Request命令通知MGW A准备主叫网络侧承载，承载收发模式为单向ReceiveOnly；
step 16: MGW A网络侧承载准备完成，用H.248 ADD_Reply命令响应；
step 17: Nb接口初始化，MGW A和MGW B建立网络间的承载；
step 18: MSS-A用H.248 ADD_Request命令通知MGW A准备主叫Iu侧承载，承载收发模式为单向ReceiveOnly；
step 19: MGW A Iu侧承载准备完成，用H.248 ADD_Reply命令响应；
step 20: MSS-A用Allocate Channel命令通知RNS为UE-A分配无线专用信道；
step 21: RNS在信道分配成功后，用Allocation Complete消息同时MSS-A；
step 22: MSS-B的被叫号码收全后，向MSS-A回BICC ACM；
step 23: MSS-B用H.248 ADD_Request命令通知MGW B准备被叫Iu侧承载，承载收发模式为双向；
step 24: MGW B Iu侧承载准备完成，用H.248 ADD_Reply命令响应；
step 25: MSS-B用Allocate Channel命令通知RNS为UE-B分配无线专用信道；
step 26: RNS在信道分配成功后，用Allocation Complete消息同时MSS-B；
step 27: UE-B振铃后，用直传消息Alerting通知MSS-B；
step 28: MSS-B用BICC消息CPG通知MSS-A，UE-B已振铃；
step 29: MSS-A用直传消息Alerting通知UE-A；
step 30: MSS-B用H.248 Modify_Request命令通知MGW B向MGW A送回铃音；
step 31: MGW B 向MGW A播放回铃音，并用H.248 Modify_Reply命令响应；
step 32: 移动用户B按下通话按钮，UE-B用直传消息Connect通知MSS-B；
step 33: MSS-B用H.248 Modify_Request命令通知MGW B修改Iu侧承载，激活IWF或语音处理模块；
step 34: MGW B用H.248 Modify_Reply命令响应；
17
step 35: MSS-B用H.248 Modify_Request命令通知MGW B停送回铃音，并修改网络侧承载，激活IWF或语音处理模块；
step 36: MGW B回铃音停送，网络侧承载修改后，用H.248 Modify_Reply命令响应；
step 37: MSS-B用BICC消息ANM通知MSS-A，UE-B已应答，MSS-A和MSS-B的连接建立；
step 38: MSS-B用直传消息Connect Ack通知UE-B与MSS-B连接建立；
step 39: MSS-A在收到MSS-B的BICC消息ANM后，即用H.248 Modify_Request命令通知MGW A修改网络侧承载，激活语音处理模块；
step 40: MGW A用H.248 Modify_Reply命令响应；
step 41: MSS-A用H.248 Modify_Request命令通知MGW A修改Iu侧承载，激活语音处理模块；
step 42: MGW A用H.248 Modify_Reply命令响应；
step 43: MSS-A用直传消息Connect通知UE-A；
step 44: UE-A用直传消息Connect Ack通知MSS-A与UE-A连接建立；
step 45: 两个3G终端间的通信连接建立；
step 46: UE-A挂断电话，MSS A 检测用户挂机，通过BICC REL消息通知MSS B；
step 47: MSS B 发Release消息给UE-B,通知US-B释放业务；
step 48: MSS A发送H.248命令Subtract给MGW A, 要求清除被叫Iu侧承载；
step 49: MGW A完成Iu侧承载的清除，发送H.248命令Subtract_Reply给MSS A作为响应;
step 50: MSS A发送H.248命令Subtract给MGW A, 要求清除网络侧承载，MGW A 返回Subtract_Reply作为响应；
step 51: MSS B发送H.248命令Subtract给MGW B, 要求清除被叫Iu侧承载；
step 52: MGW B完成Iu侧承载的清除，发送H.248命令Subtract_Reply给MSSB作为响应;
18
MSS B发送H.248命令Subtract给MGW A, 要求清除网络侧承载，MGW B 返回Subtract_Reply作为响应；

协议中对于CN下发DISCONECCT（Cause_value“switching equipment congestion” ）的定义是：该原因表示产生这一原因的交换设备正在历经高业务量周期。
通过以上的具体分析，我们可以看出：这三次未接通，是由于核心网的问题所造成。对于此类问题现象，其他地市也出现过。以下是青岛移动针对此类问题现象的一个解决案例。具体如下：
通过统计发现QDAGS15（爱立信软交换设备）每个小时出100次左右EOS3748的现象，交换机没有出直接告警，但可以看出QDAGS15存在ENUM=1009，MGW20侧出现GCP 500 错误。EOS 3748表示收到原因为Switching Equipment Congestion的释放消息,具体表现为Server侧出现ENUM 1009事件 ，通过到相应机框的GPB板用te log read 打印分析trace log可以发现发送有问题的Context的时隙及对应的PCM设备号:对上述电路进行闭解，重新定义电路数据后恢复正常，问题得到解决。
解决建议:
建议核心网针对这三次问题发生时刻的系统负荷情况。确认是否是由于负荷过高，造成此类问题出现。如果是，建议扩容。如果不是，建议核查相关设备是否存在故障或者是由于相关参数设置不合理所造成的。