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

交换设备拥塞导致未接通 问题分析报告 问题描述: 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