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

交换设备拥塞导致未接通 问题分析报告 问题描述: 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侧承载时，发生错误。具体如下图所示： 局间呼叫核心网信令流程简介： 移动用户A拨打移动用户B，UE-A在初始直传消息CM SERVICE REQUEST携带的信元CM service type中指明业务为移动主叫建立； MSS-A收到Call Setup消息，即用MAP_SEND_ROUTING_INFORMATION向HLR要被叫用户的漫游号码； HLR用MAP_PROVIDE_ROAMING_NUMBER向被叫用户UE-B所登记的VLR B要漫游号码； VLR B用MAP_PROVIDE_ROAMING_NUMBER向HLR返回UE-B的漫游号码； HLR用MAP_PROVIDE_ROAMING_NUMBER向MSS-A返回UE-B的漫游号码； MSS-A在发送直传消息Call Proceeding通知UE-A呼叫继续处理； MSS-A用漫游号码向MSS-B发起BICC消息IAM； MSS-B收到IAM即向UE-B发起寻呼； UE-B响应寻呼； MSS-B用直传消息Call Setup建立与UE-B的信令连接； UE-B检查承载能力通过后，即用直传消息Call Confirmed向MSS-B响应； MSS-B用H.248 ADD_Request命令通知MGW B准备被叫网络侧承载，承载收发模式为双向； MGW B网络侧承载准备完成，用H.248 ADD_Reply命令响应； MSS-B用BICC APM消息将承载信息告诉MSS-A； MSS-A用H.248 ADD_Request命令通知MGW A准备主叫网络侧承载，承载收发模式为单向ReceiveOnly； MGW A网络侧承载准备完成，用H.248 ADD_Reply命令响应； Nb接口初始化，MGW A和MGW B建立网络间的承载； MSS-A用H.248 ADD_Request命令通知MGW A准备主叫Iu侧承载，承载收发模式为单向ReceiveOnly； MGW A Iu侧承载准备完成，用H.248 ADD_Reply命令响应； MSS-A用Allocate Channel命令通知RNS为UE-A分配无线专用信道； RNS在信道分配成功后，用Allocation Complete消息同时MSS-A； MSS-B的被叫号码收全后，向MSS-A回BICC ACM； MSS-B用H.248 ADD_Request命令通知MG