交換擁塞導(dǎo)致未接通問題分析報告.doc

交換設(shè)備擁塞導(dǎo)致未接通問題分析報告問題描述: 8月13日8月15日期間,在路測中發(fā)現(xiàn)主叫呼叫建立成功后,CN下發(fā)Disconnect （Cause_value：(42)Switching equipment congestion交換設(shè)備擁塞）導(dǎo)致發(fā)生3次未接通。問題分析：1.樂山鐘樓-2未接通 發(fā)生時間：2012-8-13 09:39:26 UE在樂山鐘樓-2小區(qū)下完成RB建立后，CN下發(fā)Disconnect （Cause_value：(42)Switching equipment congestion交換設(shè)備擁塞）導(dǎo)致本次呼叫未接通。從路測數(shù)據(jù)來看，當(dāng)時無線環(huán)境較好(PCCPCH RSCP=-45dbm,PCCPCH C/I=20db)。具體路測信令如下圖所示：2.岷江中街245號-3未接通發(fā)生時間：2012-8-13 15:22:35UE在岷江中街245號-3小區(qū)下完成RB建立后，CN下發(fā)Disconnect （Cause_value：(42)Switching equipment congestion交換設(shè)備擁塞）導(dǎo)致本次呼叫未接通。從路測數(shù)據(jù)來看，當(dāng)時無線環(huán)境較好(PCCPCH RSCP=-51dbm,PCCPCH C/I=19db)。具體路測信令如下圖所示：3.樂山衛(wèi)校-1未接通發(fā)生時間：2012-8-15 15:26:37UE在樂山衛(wèi)校-1小區(qū)下完成RB建立后，CN下發(fā)Disconnect （Cause_value：(42)Switching equipment congestion交換設(shè)備擁塞）導(dǎo)致本次呼叫未接通。具體后臺信令如下圖所示：通過以上3次未接通的信令來看，全部是在RB建立后，CN下發(fā)Disconnect （Cause_value：(42)Switching equipment congestion交換設(shè)備擁塞）導(dǎo)致的未接通。從UTRAN網(wǎng)絡(luò)的信令流程來看，UE在完成RB建立后，無線網(wǎng)的準(zhǔn)備工作已經(jīng)基本完成，UE就在等待CN給其下發(fā)ALTERING。具體如下圖所示：由于這三次呼叫被叫號碼都是10086，所以我們使用局間呼叫的信令流程來進(jìn)行問題定位分析。從核心網(wǎng)的信令流程來看，這三次未接通的信令流程，都是在step 18:MSS-A用H.248 ADD_Request命令通知MGW A準(zhǔn)備主叫Iu側(cè)承載時，發(fā)生錯誤。具體如下圖所示：局間呼叫核心網(wǎng)信令流程簡介：step 1: 移動用戶A撥打移動用戶B，UE-A在初始直傳消息CM SERVICE REQUEST攜帶的信元CM service type中指明業(yè)務(wù)為移動主叫建立；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在發(fā)送直傳消息Call Proceeding通知UE-A呼叫繼續(xù)處理；step 7: MSS-A用漫游號碼向MSS-B發(fā)起B(yǎng)ICC消息IAM；step 8: MSS-B收到IAM即向UE-B發(fā)起尋呼；step 9: UE-B響應(yīng)尋呼；step 10: MSS-B用直傳消息Call Setup建立與UE-B的信令連接；step 11: UE-B檢查承載能力通過后，即用直傳消息Call Confirmed向MSS-B響應(yīng)；step 12: MSS-B用H.248 ADD_Request命令通知MGW B準(zhǔn)備被叫網(wǎng)絡(luò)側(cè)承載，承載收發(fā)模式為雙向；step 13: MGW B網(wǎng)絡(luò)側(cè)承載準(zhǔn)備完成，用H.248 ADD_Reply命令響應(yīng)；step 14: MSS-B用BICC APM消息將承載信息告訴MSS-A；step 15: MSS-A用H.248 ADD_Request命令通知MGW A準(zhǔn)備主叫網(wǎng)絡(luò)側(cè)承載，承載收發(fā)模式為單向ReceiveOnly；step 16: MGW A網(wǎng)絡(luò)側(cè)承載準(zhǔn)備完成，用H.248 ADD_Reply命令響應(yīng)；step 17: Nb接口初始化，MGW A和MGW B建立網(wǎng)絡(luò)間的承載；step 18: MSS-A用H.248 ADD_Request命令通知MGW A準(zhǔn)備主叫Iu側(cè)承載，承載收發(fā)模式為單向ReceiveOnly；step 19: MGW A Iu側(cè)承載準(zhǔn)備完成，用H.248 ADD_Reply命令響應(yīng)；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準(zhǔn)備被叫Iu側(cè)承載，承載收發(fā)模式為雙向；step 24: MGW B Iu側(cè)承載準(zhǔn)備完成，用H.248 ADD_Reply命令響應(yīng)；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命令響應(yīng)；step 32: 移動用戶B按下通話按鈕，UE-B用直傳消息Connect通知MSS-B；step 33: MSS-B用H.248 Modify_Request命令通知MGW B修改Iu側(cè)承載，激活I(lǐng)WF或語音處理模塊；step 34: MGW B用H.248 Modify_Reply命令響應(yīng)；17step 35: MSS-B用H.248 Modify_Request命令通知MGW B停送回鈴音，并修改網(wǎng)絡(luò)側(cè)承載，激活I(lǐng)WF或語音處理模塊；step 36: MGW B回鈴音停送，網(wǎng)絡(luò)側(cè)承載修改后，用H.248 Modify_Reply命令響應(yīng)；step 37: MSS-B用BICC消息ANM通知MSS-A，UE-B已應(yīng)答，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修改網(wǎng)絡(luò)側(cè)承載，激活語音處理模塊；step 40: MGW A用H.248 Modify_Reply命令響應(yīng)；step 41: MSS-A用H.248 Modify_Request命令通知MGW A修改Iu側(cè)承載，激活語音處理模塊；step 42: MGW A用H.248 Modify_Reply命令響應(yīng)；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 發(fā)Release消息給UE-B,通知US-B釋放業(yè)務(wù)；step 48: MSS A發(fā)送H.248命令Subtract給MGW A, 要求清除被叫Iu側(cè)承載；step 49: MGW A完成Iu側(cè)承載的清除，發(fā)送H.248命令Subtract_Reply給MSS A作為響應(yīng);step 50: MSS A發(fā)送H.248命令Subtract給MGW A, 要求清除網(wǎng)絡(luò)側(cè)承載，MGW A 返回Subtract_Reply作為響應(yīng)；step 51: MSS B發(fā)送H.248命令Subtract給MGW B, 要求清除被叫Iu側(cè)承載；step 52: MGW B完成Iu側(cè)承載的清除，發(fā)送H.248命令Subtract_Reply給MSSB作為響應(yīng);18MSS B發(fā)送H.248命令Subtract給MGW A, 要求清除網(wǎng)絡(luò)側(cè)承載，MGW B 返回Subtract_Reply作為響應(yīng)；協(xié)議中對于CN下發(fā)DISCONECCT（Cause_value“switching equipment congestion” ）的定義是：該原因表示產(chǎn)生這一原因的交換設(shè)備正在歷經(jīng)高業(yè)務(wù)量周期。通過以上的具體分析，我們可以看出：這三次未接通，是由于核心網(wǎng)的問題所造成。對于此類問題現(xiàn)象，其他地市也出現(xiàn)過。以下是青島移動針對此類問題現(xiàn)象的一個解決案例。具體如下：通過統(tǒng)計發(fā)現(xiàn)QDAGS15（愛立信軟交換設(shè)備）每個小時出100次左右EOS3748的現(xiàn)象，交換機沒有出直接告警，但可以看出QDAGS15存在ENUM=1009，MGW20側(cè)出現(xiàn)GCP 500 錯誤。EOS 3748表示收到原因為Switching Equipment Congestion的釋放消息,具體表現(xiàn)為Server