放音問題故障處理分析

王道春

【摘要】 針對目前所用軟交換設備，對主叫呼叫流程進行闡述，并運用實例對由于放音問題引起的障礙進行分析處理。

【關鍵詞】 主叫呼叫流程 端局放音

運營商之間或者運營商內部均使用了不同廠家軟交換端局設備，這樣設備對接時就會存在信令、放音等的協調配合等數據要求。一些特殊參數理解的不一致以及執行行業數據規范不到位，都會造成用戶投訴出現，網絡感知度受到一定的影響。下面就這一障礙進行論述。

1、首先闡述移動終端的呼叫流程，這樣有助于我們對后續問題的分析處理。

主叫流程，移動用戶做主叫時的信令過程是從MS向BTS請求信道開始，到主叫用戶的TCH指配完成為止。主叫經過四個階段：接入階段，鑒權加密階段，TCH指配階段，取被叫用戶路由信息階段。接入階段手機和BTS建立了暫時固定的關系；鑒權加密階段完成對主叫用戶的身份確認；TCH指配階段實現主叫用戶的話音信道的確定；取被叫用戶路由信息階段主要包括：MSC向HLR請求路由信息；HLR向VLR請求漫游號碼；VLR回送被叫用戶的漫游號碼；HLR向MSC回送被叫用戶的MSRN。MSC通過路由信息對被叫用戶的路由信息分析，得到被叫用戶的局向，然后進行話路接續。

當用戶輸入被叫號碼進行呼叫時， MS將在隨機接入信道向BSS發送信道請求專用信道消息。BSC為其分配相應的信道并通知MS；隨后MS將在為其分配的SDCCH上發送業務類型為移動發起呼叫CM請求消息。該消息被BSS透明的傳送至MSC，MSC收到CM業務請求消息后，通過處理接入請求消息通知VLR；由VLR在數據庫中查詢該MS是否有鑒權三參組；如果有，將直接向MSC下發鑒權命令； MSC收到VLR發送的鑒權命令后，通過BSS向MS下發鑒權請求，在該命令中含有鑒權參數，MS收到鑒權請求分析得出鑒權結果；通過鑒權響應消息送達MSC，再由MSC鑒權結果回送VLR，由VLR 核對MS上報的鑒權結果和從HLR取得的鑒權參數中的結果。鑒權通過后，VLR將向MSC下發加密命令，并通知MSC該MS此次接入請求已獲通過，MSC通過BSS通知MS業務請求獲得通過，然后MSC向MS下發加密命令；MS收到此命令并完成加密后，回送加密完成消息，到此MS完成了 整個接入階段的工作。

經過接入階段和鑒權加密過程，主叫用戶合法身份得到確認，并接入網絡。MS會發送呼叫建立消息；MSC收到此消息后向VLR查詢該用戶的相關業務信息，由VLR決定此次呼叫可以繼續；通過完成呼叫消息向MSC回送該用戶數據；MSC收到該信息后，通過呼叫繼續消息，經BSS通知MS呼叫在繼續處理之中，并向BSC發送指配請求消息指派接口電路；由BSC向BTS、MS指定無線資源，MS收到該指令后，占用成功回送分配完成消息，到此TCH指配階段完成本局的無線資源和接口電路均已成功分配。MSC收到指配完成消息進行被叫分析，發送路由請求消息；HLR收到該消息后，根據被叫IMSI獲取被叫所在的VLR，并向其請求漫游號碼；被叫所在的VLR收到請求漫游號碼消息為對應的MS分配MSRN，，然后在請求漫游號碼響應消息中回送給HLR；HLR得到該MSRN后，向主叫所在MSC發送路由信息響應消息，MSC從該消息中得到被叫的MSRN；根據MSRN進行局間中繼選路，并向被叫所在的MSC發送IAI消息。這樣主叫信令流程基本結束。

2、對呼叫流程我們已經有了一個比較全面的認識。下面闡述一列由于沒有按照規范的流程放音造成的障礙。此次障礙僅涉及到本端發起端局至對端落地端局的信令交互和話音搭建部分，涉及到主叫呼叫流程的部分環節。

用戶現象描述為：近日頻繁出現本網用戶投訴撥打疆內異地電話，手機上顯示“用戶忙”，但是用戶聽不到任何提示音。我們對各種被叫情況進行了深入細致的撥打測試，結果顯示屬于交換提供的錄音通知問題。問題具體詳實描述是用戶撥打本局用戶，用戶正忙或者拒絕，本局可以正常索引錄音通知，主叫用戶可聽到提示音“您撥的用戶正忙，請稍后再撥”；對于被叫用戶是疆內非本局用戶（主要是本網其他端局下用戶），當被叫用戶正忙或者拒絕時，主叫用戶聽不到任何語音提示，電話中斷。

我們針對四種情況分本端局放音消息、對端局放音消息，分用戶正忙和用戶拒接進行信令跟蹤，同時我們聯系T局工程師同步進行跟蹤。我們對4種情況進行了信令消息的對比；本局時均能正常聽到正確的語音提示，而在對端局時存在問題。T局工程師給出了呼叫消息過程，并進行了問題定位。

對端端局給T局回ACM消息指示被叫局放音，同時消息中攜帶有被叫用戶忙的原因值，告訴了用戶正確的狀態，如圖1所示。

對端端端局沒有被叫放音消息回復，然后續發送REL消息給T局要求拆線，如圖2所示：

故障定位：T局工程師根據捕捉到的信令消息，確定故障為對端端局原因。依據通信行業相關數據規范規定：一般對于被叫用戶狀態應由落地局交換機進行放音，而對端局因為自身的某些問題，將其設置由被叫用戶狀態放音改為由主叫局進行放音。雖然此種由本端局進行放音，雙方信令消息協調好在規范中也是可行的；但是由于對端局交換發給本端局的消息類型格式與本端局不匹配，造成本端局無法識別處理，不能正確提供主叫用戶有效放音提示。影響現象就是——本端局用戶撥打疆內對端局下用戶（該用戶正在通話中或者拒接），主叫用戶聽不到“被叫用戶忙”的錄音通知，直接退出呼叫狀態。

解決方法：一是由對端局將被叫用戶狀態放音改回由對端局局放音；二是對端局嚴格按照ISUP消息信令格式指示本端局進行放音，使這個問題得到有效解決。但是解決此問題需要上級主管部門進行協調兩家設備供應商才能得到有效地執行。因此我局就這一障礙形成文上報主管部門并及時地得到了解決。

通過這個實例我們能夠認識到，要想進一步提高核心網維護技能，應該扎實掌握各種呼叫流程，準確理解所包含消息的含義；同時嚴格按照數據規范進行數據制作，對故障定位要能熟練運用信令跟蹤，從而及時的排除故障。

參 考 文 獻

[1] GSM業務呼叫流程

【摘要】 針對目前所用軟交換設備，對主叫呼叫流程進行闡述，并運用實例對由于放音問題引起的障礙進行分析處理。

【關鍵詞】 主叫呼叫流程 端局放音

運營商之間或者運營商內部均使用了不同廠家軟交換端局設備，這樣設備對接時就會存在信令、放音等的協調配合等數據要求。一些特殊參數理解的不一致以及執行行業數據規范不到位，都會造成用戶投訴出現，網絡感知度受到一定的影響。下面就這一障礙進行論述。

1、首先闡述移動終端的呼叫流程，這樣有助于我們對后續問題的分析處理。

主叫流程，移動用戶做主叫時的信令過程是從MS向BTS請求信道開始，到主叫用戶的TCH指配完成為止。主叫經過四個階段：接入階段，鑒權加密階段，TCH指配階段，取被叫用戶路由信息階段。接入階段手機和BTS建立了暫時固定的關系；鑒權加密階段完成對主叫用戶的身份確認；TCH指配階段實現主叫用戶的話音信道的確定；取被叫用戶路由信息階段主要包括：MSC向HLR請求路由信息；HLR向VLR請求漫游號碼；VLR回送被叫用戶的漫游號碼；HLR向MSC回送被叫用戶的MSRN。MSC通過路由信息對被叫用戶的路由信息分析，得到被叫用戶的局向，然后進行話路接續。

當用戶輸入被叫號碼進行呼叫時， MS將在隨機接入信道向BSS發送信道請求專用信道消息。BSC為其分配相應的信道并通知MS；隨后MS將在為其分配的SDCCH上發送業務類型為移動發起呼叫CM請求消息。該消息被BSS透明的傳送至MSC，MSC收到CM業務請求消息后，通過處理接入請求消息通知VLR；由VLR在數據庫中查詢該MS是否有鑒權三參組；如果有，將直接向MSC下發鑒權命令； MSC收到VLR發送的鑒權命令后，通過BSS向MS下發鑒權請求，在該命令中含有鑒權參數，MS收到鑒權請求分析得出鑒權結果；通過鑒權響應消息送達MSC，再由MSC鑒權結果回送VLR，由VLR 核對MS上報的鑒權結果和從HLR取得的鑒權參數中的結果。鑒權通過后，VLR將向MSC下發加密命令，并通知MSC該MS此次接入請求已獲通過，MSC通過BSS通知MS業務請求獲得通過，然后MSC向MS下發加密命令；MS收到此命令并完成加密后，回送加密完成消息，到此MS完成了 整個接入階段的工作。

經過接入階段和鑒權加密過程，主叫用戶合法身份得到確認，并接入網絡。MS會發送呼叫建立消息；MSC收到此消息后向VLR查詢該用戶的相關業務信息，由VLR決定此次呼叫可以繼續；通過完成呼叫消息向MSC回送該用戶數據；MSC收到該信息后，通過呼叫繼續消息，經BSS通知MS呼叫在繼續處理之中，并向BSC發送指配請求消息指派接口電路；由BSC向BTS、MS指定無線資源，MS收到該指令后，占用成功回送分配完成消息，到此TCH指配階段完成本局的無線資源和接口電路均已成功分配。MSC收到指配完成消息進行被叫分析，發送路由請求消息；HLR收到該消息后，根據被叫IMSI獲取被叫所在的VLR，并向其請求漫游號碼；被叫所在的VLR收到請求漫游號碼消息為對應的MS分配MSRN，，然后在請求漫游號碼響應消息中回送給HLR；HLR得到該MSRN后，向主叫所在MSC發送路由信息響應消息，MSC從該消息中得到被叫的MSRN；根據MSRN進行局間中繼選路，并向被叫所在的MSC發送IAI消息。這樣主叫信令流程基本結束。

2、對呼叫流程我們已經有了一個比較全面的認識。下面闡述一列由于沒有按照規范的流程放音造成的障礙。此次障礙僅涉及到本端發起端局至對端落地端局的信令交互和話音搭建部分，涉及到主叫呼叫流程的部分環節。

用戶現象描述為：近日頻繁出現本網用戶投訴撥打疆內異地電話，手機上顯示“用戶忙”，但是用戶聽不到任何提示音。我們對各種被叫情況進行了深入細致的撥打測試，結果顯示屬于交換提供的錄音通知問題。問題具體詳實描述是用戶撥打本局用戶，用戶正忙或者拒絕，本局可以正常索引錄音通知，主叫用戶可聽到提示音“您撥的用戶正忙，請稍后再撥”；對于被叫用戶是疆內非本局用戶（主要是本網其他端局下用戶），當被叫用戶正忙或者拒絕時，主叫用戶聽不到任何語音提示，電話中斷。

我們針對四種情況分本端局放音消息、對端局放音消息，分用戶正忙和用戶拒接進行信令跟蹤，同時我們聯系T局工程師同步進行跟蹤。我們對4種情況進行了信令消息的對比；本局時均能正常聽到正確的語音提示，而在對端局時存在問題。T局工程師給出了呼叫消息過程，并進行了問題定位。

對端端局給T局回ACM消息指示被叫局放音，同時消息中攜帶有被叫用戶忙的原因值，告訴了用戶正確的狀態，如圖1所示。

對端端端局沒有被叫放音消息回復，然后續發送REL消息給T局要求拆線，如圖2所示：

故障定位：T局工程師根據捕捉到的信令消息，確定故障為對端端局原因。依據通信行業相關數據規范規定：一般對于被叫用戶狀態應由落地局交換機進行放音，而對端局因為自身的某些問題，將其設置由被叫用戶狀態放音改為由主叫局進行放音。雖然此種由本端局進行放音，雙方信令消息協調好在規范中也是可行的；但是由于對端局交換發給本端局的消息類型格式與本端局不匹配，造成本端局無法識別處理，不能正確提供主叫用戶有效放音提示。影響現象就是——本端局用戶撥打疆內對端局下用戶（該用戶正在通話中或者拒接），主叫用戶聽不到“被叫用戶忙”的錄音通知，直接退出呼叫狀態。

解決方法：一是由對端局將被叫用戶狀態放音改回由對端局局放音；二是對端局嚴格按照ISUP消息信令格式指示本端局進行放音，使這個問題得到有效解決。但是解決此問題需要上級主管部門進行協調兩家設備供應商才能得到有效地執行。因此我局就這一障礙形成文上報主管部門并及時地得到了解決。

通過這個實例我們能夠認識到，要想進一步提高核心網維護技能，應該扎實掌握各種呼叫流程，準確理解所包含消息的含義；同時嚴格按照數據規范進行數據制作，對故障定位要能熟練運用信令跟蹤，從而及時的排除故障。

參 考 文 獻

[1] GSM業務呼叫流程

【摘要】 針對目前所用軟交換設備，對主叫呼叫流程進行闡述，并運用實例對由于放音問題引起的障礙進行分析處理。

【關鍵詞】 主叫呼叫流程 端局放音

運營商之間或者運營商內部均使用了不同廠家軟交換端局設備，這樣設備對接時就會存在信令、放音等的協調配合等數據要求。一些特殊參數理解的不一致以及執行行業數據規范不到位，都會造成用戶投訴出現，網絡感知度受到一定的影響。下面就這一障礙進行論述。

1、首先闡述移動終端的呼叫流程，這樣有助于我們對后續問題的分析處理。

主叫流程，移動用戶做主叫時的信令過程是從MS向BTS請求信道開始，到主叫用戶的TCH指配完成為止。主叫經過四個階段：接入階段，鑒權加密階段，TCH指配階段，取被叫用戶路由信息階段。接入階段手機和BTS建立了暫時固定的關系；鑒權加密階段完成對主叫用戶的身份確認；TCH指配階段實現主叫用戶的話音信道的確定；取被叫用戶路由信息階段主要包括：MSC向HLR請求路由信息；HLR向VLR請求漫游號碼；VLR回送被叫用戶的漫游號碼；HLR向MSC回送被叫用戶的MSRN。MSC通過路由信息對被叫用戶的路由信息分析，得到被叫用戶的局向，然后進行話路接續。

當用戶輸入被叫號碼進行呼叫時， MS將在隨機接入信道向BSS發送信道請求專用信道消息。BSC為其分配相應的信道并通知MS；隨后MS將在為其分配的SDCCH上發送業務類型為移動發起呼叫CM請求消息。該消息被BSS透明的傳送至MSC，MSC收到CM業務請求消息后，通過處理接入請求消息通知VLR；由VLR在數據庫中查詢該MS是否有鑒權三參組；如果有，將直接向MSC下發鑒權命令； MSC收到VLR發送的鑒權命令后，通過BSS向MS下發鑒權請求，在該命令中含有鑒權參數，MS收到鑒權請求分析得出鑒權結果；通過鑒權響應消息送達MSC，再由MSC鑒權結果回送VLR，由VLR 核對MS上報的鑒權結果和從HLR取得的鑒權參數中的結果。鑒權通過后，VLR將向MSC下發加密命令，并通知MSC該MS此次接入請求已獲通過，MSC通過BSS通知MS業務請求獲得通過，然后MSC向MS下發加密命令；MS收到此命令并完成加密后，回送加密完成消息，到此MS完成了 整個接入階段的工作。

經過接入階段和鑒權加密過程，主叫用戶合法身份得到確認，并接入網絡。MS會發送呼叫建立消息；MSC收到此消息后向VLR查詢該用戶的相關業務信息，由VLR決定此次呼叫可以繼續；通過完成呼叫消息向MSC回送該用戶數據；MSC收到該信息后，通過呼叫繼續消息，經BSS通知MS呼叫在繼續處理之中，并向BSC發送指配請求消息指派接口電路；由BSC向BTS、MS指定無線資源，MS收到該指令后，占用成功回送分配完成消息，到此TCH指配階段完成本局的無線資源和接口電路均已成功分配。MSC收到指配完成消息進行被叫分析，發送路由請求消息；HLR收到該消息后，根據被叫IMSI獲取被叫所在的VLR，并向其請求漫游號碼；被叫所在的VLR收到請求漫游號碼消息為對應的MS分配MSRN，，然后在請求漫游號碼響應消息中回送給HLR；HLR得到該MSRN后，向主叫所在MSC發送路由信息響應消息，MSC從該消息中得到被叫的MSRN；根據MSRN進行局間中繼選路，并向被叫所在的MSC發送IAI消息。這樣主叫信令流程基本結束。

2、對呼叫流程我們已經有了一個比較全面的認識。下面闡述一列由于沒有按照規范的流程放音造成的障礙。此次障礙僅涉及到本端發起端局至對端落地端局的信令交互和話音搭建部分，涉及到主叫呼叫流程的部分環節。

用戶現象描述為：近日頻繁出現本網用戶投訴撥打疆內異地電話，手機上顯示“用戶忙”，但是用戶聽不到任何提示音。我們對各種被叫情況進行了深入細致的撥打測試，結果顯示屬于交換提供的錄音通知問題。問題具體詳實描述是用戶撥打本局用戶，用戶正忙或者拒絕，本局可以正常索引錄音通知，主叫用戶可聽到提示音“您撥的用戶正忙，請稍后再撥”；對于被叫用戶是疆內非本局用戶（主要是本網其他端局下用戶），當被叫用戶正忙或者拒絕時，主叫用戶聽不到任何語音提示，電話中斷。

我們針對四種情況分本端局放音消息、對端局放音消息，分用戶正忙和用戶拒接進行信令跟蹤，同時我們聯系T局工程師同步進行跟蹤。我們對4種情況進行了信令消息的對比；本局時均能正常聽到正確的語音提示，而在對端局時存在問題。T局工程師給出了呼叫消息過程，并進行了問題定位。

對端端局給T局回ACM消息指示被叫局放音，同時消息中攜帶有被叫用戶忙的原因值，告訴了用戶正確的狀態，如圖1所示。

對端端端局沒有被叫放音消息回復，然后續發送REL消息給T局要求拆線，如圖2所示：

故障定位：T局工程師根據捕捉到的信令消息，確定故障為對端端局原因。依據通信行業相關數據規范規定：一般對于被叫用戶狀態應由落地局交換機進行放音，而對端局因為自身的某些問題，將其設置由被叫用戶狀態放音改為由主叫局進行放音。雖然此種由本端局進行放音，雙方信令消息協調好在規范中也是可行的；但是由于對端局交換發給本端局的消息類型格式與本端局不匹配，造成本端局無法識別處理，不能正確提供主叫用戶有效放音提示。影響現象就是——本端局用戶撥打疆內對端局下用戶（該用戶正在通話中或者拒接），主叫用戶聽不到“被叫用戶忙”的錄音通知，直接退出呼叫狀態。

解決方法：一是由對端局將被叫用戶狀態放音改回由對端局局放音；二是對端局嚴格按照ISUP消息信令格式指示本端局進行放音，使這個問題得到有效解決。但是解決此問題需要上級主管部門進行協調兩家設備供應商才能得到有效地執行。因此我局就這一障礙形成文上報主管部門并及時地得到了解決。

通過這個實例我們能夠認識到，要想進一步提高核心網維護技能，應該扎實掌握各種呼叫流程，準確理解所包含消息的含義；同時嚴格按照數據規范進行數據制作，對故障定位要能熟練運用信令跟蹤，從而及時的排除故障。

參 考 文 獻

[1] GSM業務呼叫流程