專利名稱：一種呼叫處理方法
技術領域：
本發明涉及移動通信技術，特別公開一種呼叫處理方法。
背景技術：
第三代移動通信WCDMA(Wideband Code Division Multiple Access，碼分多址接入網)3GPP(3rd Generation Partnership Project，第三代移動通信標準化伙伴項目)R4(Release 4)將核心網絡電路域MSC(Mobile services SwitchingCenter，移動交換中心)拆分為MSC Server(移動軟交換服務器)和MGW(MediaGateway，媒體網關)兩個設備，從而實現了業務控制和業務承載的分離，其中核心網絡電路域MSC server與MGW是兩個獨立的設備，中間通過Mc接口進行連接。MSC Server設備主要完成呼叫控制、媒體網關完成承載控制。Mc接口是MSC Server和MGW之間的控制接口，MSC Server通過Megaco/H.248協議對MGW進行控制。
如圖1所示，為呼叫的處理的基本流程，其中移動軟交換服務器1為呼叫始發服務器，移動軟交換服務器2為呼叫匯接服務器，處理流程包括以下步驟S1、MSC Server1接收到入局的攜帶著被叫終端號碼called party number的IAM(Initial address message)呼叫消息；S2、MSC Server1分析被叫終端號碼，確定此呼叫的路由方式是移動軟交換服務器2所對應的局點，那么MSC Server1就向MSC Server2發送IAM消息；正常情況下，MSC Server2通過去被叫終端的媒體網關和電路接續呼叫，但是，當MSC Server2因各種故障無法正常接續本次呼叫時，執行步驟S3；S3、MSC Server2向MSC Server1返回一個REL(Release message)消息通知接續本次呼叫失敗；S4、當MSC Server1收到REL消息后，向MSC Server2返回一個RLC(Release complete message)確認消息，并釋放呼叫。
REL消息中，攜帶有指示接續失敗原因的原因值，MSC Server1可以對這些原因值進行統計分析。但是在呼叫始發端并沒有根據REL攜帶原因值設置不同的處理流程，而是一律采用釋放呼叫的處理方式進行簡單處理，降低了呼叫的成功率、影響了用戶的滿意度。
并且，現有REL消息中攜帶的原因值是根據ITU-T Q.850協議中定義的失敗原因代碼填寫的，ITU-T Q.850協議中涉及的失敗原因都是根據R99組網模式中出現的故障類型進行定義，對于因分離架構而引入新的兩類能夠造成路由失敗的故障媒體網關故障和電路全忙并沒有進行定義新的原因值。
發明內容
本發明公開一種呼叫處理方法，以解決現有技術中，因始發移動軟交換服務器不區別接續失敗原因，簡單的進行釋放呼叫處理而造成的呼叫成功率低的問題。
一種呼叫處理方法，包括如下步驟A、第一移動軟交換服務器將攜帶被叫終端地址的呼叫消息發送給第二移動軟交換服務器進行接續；B、第二移動軟交換服務器在接續所述呼叫失敗時，返回攜帶原因值的REL消息，所述原因值標識接續失敗的原因；C、第一移動軟交換服務器根據本地路由配置信息判斷是否可以通過第三移動軟交換服務器接續所述呼叫，如果是則執行步驟D；如果否則執行步驟E；D、第一移動軟交換服務器將所述呼叫消息發送給第三移動軟交換服務器進行接續；E、第一移動軟交換服務器釋放所述呼叫。
當所述原因值為相關的非被叫終端不可達原因值時，第一移動軟交換服務器執行所述判斷。
所述非被叫終端不可達原因值包括標識去被叫終端的媒體網關故障和/或電路全忙的原因值。
所述步驟B包括所述的媒體網關故障或電路全忙由第二移動軟交換服務器根據本地可用資源信息進行確認。
所述方法還包括統計所述原因值并進行分析的步驟。
本發明的有益效果如下應用本發明所述方法，當呼叫接續失敗時，根據本地路由配置信息選擇可用的其他軟交換服務器進行迂回路由，呼叫的成功率；進一步，將接續失敗的原因分為兩大類，一類是被叫終端自身造成的不可達，另一類包括現有原因中所有其他原因，在始發端軟交換服務器側，利用現有的REL消息中攜帶的原因值對兩類原因進行判斷，如果是第一類，則釋放呼叫，不再占用系統資源進行無意義的迂回，如果是第二類，根據本地路由配置信息，當有可用的其他服務器可以接續本次呼叫時進行迂回路由；并且，對現有的原因值進行擴充，增加了由于移動軟交換服務器和媒體網關分離架構下的兩類故障出局媒體網關和出局電路全忙的原因值，使始發端軟交換服務器可以識別這兩種接續失敗原因，從而利用上述的迂回方法進一步提高了呼叫成功率，同時提高了對原因值進行統計和分析的可靠性。
圖1為現有技術中呼叫處理流程圖；圖2為本發明所述通過其他軟交換服務器迂回的呼叫處理流程圖。
具體實施例方式
隨著組網方式的變化，網絡結構更加靈活，在一次呼叫選路過程中，如果不是由于被叫終端忙、關機等無法接通產生的呼叫失敗，而是由于路由局自身的問題導致無法成功路由本次呼叫時，完全可以利用移動軟交換服務器進行迂回路由處理流程如圖2所示其中，步驟S1～S3和現有技術相同；S4、當MSC Server1收到REL消息后，向MSC Server2返回一個RLC確認消息，這時并不直接釋放呼叫，而是分析REL中Cause參數的原因值，根據制定的迂回路由策略進行判斷，如果是可以迂回路由的接續失敗原因，則執行步驟S5；否則釋放呼叫。
這里所述的迂回路由策略設置在移動軟交換服務器的配置信息中，在迂回路由策略中，將接續失敗的原因值分為兩大類第一類為被叫終端忙、關機等暫時無法接通產生的接續失敗，例如現有ITU-T Q.850協議中原因值為17、18等接續失敗原因，對應的原因值稱為終端不可達原因值，這時，應該立即釋放，不再占用系統資源；第二類是進行匯接的移動軟交換服務器方由于線路等原因無法正常路由呼叫導致的接續失敗，包括除被叫終端不可達之外的所有其他原因，本發明將這些原因稱為非被叫終端不可達原因，相對的原因值稱為非被叫終端不可達原因值，這時，如果網絡結構允許，可以通過另一個移動軟交換服務器進行迂回路由，接續呼叫。
因此，移動軟交換服務器在收到REL消息后，首先分析REL中Cause參數的原因值是否屬于第二類原因值，如果是，根據路由數據配置重新選擇一個出局路由，執行步驟S5。
具體如何將原因值分為第一類和第二類，由運營商根據資源可用情況、服務質量策略等因素確定，并不限定本發明的保護范圍。
在這一步驟中，也可以對所有接續失敗的呼叫選擇可用移動軟交換服務器進行迂回路由，但是，如果是第一類原因，則后續的迂回多數是沒有意義的，造成系統資源的浪費，因此，較佳的實現方式還是根據具體原因進行分類的處理方式。
S5、MSC Server1發送IAM消息，目的地為進行迂回路由的軟交換服務器3；S6、S7、S8、S9、在MSC Server3上，經過對被叫號碼分析，能夠找到路由被叫的可用的媒體網關和電路，呼叫繼續接續，最終完成通話，否則還可以接著按照本發明提供的方法查找第四個可以迂回路由的軟交換服務器，直到所有的路由都不通時，再釋放呼叫。
通過本發明提供的方法，利用REL消息中攜帶有具體接續失敗的原因值，靈活的處理不同原因引發的路由失敗，提高了呼叫的成功率。
為實現上述方法，在MSC Server2發送給MSC Server1的REL消息中，必須攜帶明確的原因值，以便決定是否進行迂回路由，但是核心網分離架構下的較常出現兩種故障媒體網關故障和電路全忙故障，由于現有技術中沒有對這兩種故障定義原因代碼和處理流程，導致主叫MSC Server首先無法從返回的REL消息中識別出確切的接續失敗原因而不能選擇正確的處理流程進行迂回路由，降低了呼叫的成功率，同時因為無法明確統計接續失敗原因，造成整個系統的性能分析也存在一定失誤。
為解決上述問題，需要在ITU-T Q.850協議中對現有的接續失敗原因值進行擴展，擴展BICC/ISUP信令中Cause參數的Cause value的枚舉定義，增加如下兩個定義Cause value 35新增此枚舉值用于表示電路全忙；Cuase value 36新增此枚舉值用于表示媒體網關故障。
同時，在MSC Server的迂回策略的第二類原因值中，增加35和36兩項，在MSC Server在檢查到該原因值時，不釋放呼叫，而是重新路由到其他MSCServer進行接續。
35和36兩個原因值是現有ITU-T Q.850協議中沒有用到的兩個空閑代碼，也可以選擇其他空閑代碼，只要BICC/ISUP消息中Cause參數的字段位數支持即可。
并且在MSC Server的相關處理流程中，增加判斷媒體網關是否故障或電路是否全忙的步驟，媒體網關和電路的當前使用情況都登記在MSC Server的資源信息中并隨時更新的，具體過程為MSC Server和媒體網關之間通過Mc接口利用物理線路連接，媒體網關在上電后，向MSC server請求注冊認證，MSC server將通過注冊認證的媒體網關設置為可用媒體網關并登記，之后MSC server和媒體網關可以實時或周期性發送心跳消息檢測線路是否故障，媒體網關側也可以通過相關消息的交互主動要求MSC server去激活，MSC server將出現線路故障或要求去激活的媒體網關設置為不可用媒體網關并進行登記，這樣，MSC server可以隨時掌握當前所配置媒體網關的可用情況；對于電路的使用情況，也在當前可用資源中進行登記，作為MSC server路由呼叫時進行線路選擇的依據。
當去被叫終端的媒體網關不止一個時，只有全部媒體網關都故障或者沒有故障的媒體網關電路都忙時，MSC Server才無法路由本次呼叫，這時，路由MSC Server需要將接續失敗原因在REL消息中通知主叫MSC Server。
綜上，對MSC-SERVER1而言，呼叫開始路由至MSC-SERVER2，但在MSC-SERVER2呼叫失敗，返回REL消息，MSC-SERVER1檢查原因值，如果是35或者是36，那么就根據迂回策略，不釋放呼叫，而是重新路由到MSC-SERVER3上，繼續接續呼叫，從而提高了用戶的滿意度。
顯然，本領域的技術人員可以對本發明進行各種改動和變型而不脫離本發明的精神和范圍。這樣，倘若本發明的這些修改和變型屬于本發明權利要求及其等同技術的范圍之內，則本發明也意圖包含這些改動和變型在內。
權利要求
1.一種呼叫處理方法，其特征在于，包括如下步驟A、第一移動軟交換服務器將攜帶被叫終端地址的呼叫消息發送給第二移動軟交換服務器進行接續；B、第二移動軟交換服務器在接續所述呼叫失敗時，返回攜帶原因值的REL消息，所述原因值標識接續失敗的原因；C、第一移動軟交換服務器根據本地路由配置信息判斷是否可以通過第三移動軟交換服務器接續所述呼叫，如果是則執行步驟D；如果否則執行步驟E；D、第一移動軟交換服務器將所述呼叫消息發送給第三移動軟交換服務器進行接續；E、第一移動軟交換服務器釋放所述呼叫。
2.如權利要求1所述的方法，其特征在于，所述步驟C中當所述原因值為相關的非被叫終端不可達原因值時，第一移動軟交換服務器執行所述判斷。
3.如權利要求2所述的方法，其特征在于，所述非被叫終端不可達原因值包括標識去被叫終端的媒體網關故障和/或電路全忙的原因值。
4.如權利要求3所述的方法，其特征在于，所述步驟B包括所述的媒體網關故障或電路全忙由第二移動軟交換服務器根據本地可用資源信息進行確認。
5.如權利要求1、2、3或4所述的方法，其特征在于，所述方法還包括統計所述原因值并進行分析的步驟。
全文摘要
本發明公開一種呼叫處理方法，以解決現有技術中，因始發移動軟交換服務器不區別接續失敗原因，簡單的進行釋放呼叫處理而造成的呼叫成功率低的問題。一種呼叫處理方法，包括如下步驟第一移動軟交換服務器將攜帶被叫終端地址的呼叫消息發送給第二移動軟交換服務器進行接續；第二移動軟交換服務器在接續所述呼叫失敗時，返回攜帶原因值的REL消息，所述原因值標識接續失敗的原因；第一移動軟交換服務器根據本地路由配置信息判斷是否可以通過第三移動軟交換服務器接續所述呼叫，如果是則將所述呼叫消息發送給第三移動軟交換服務器進行接續；如果否則釋放所述呼叫。
文檔編號H04W76/06GK1885991SQ20051007689
公開日2006年12月27日 申請日期2005年6月20日 優先權日2005年6月20日
發明者朱浩鵬, 廖志軍 申請人:華為技術有限公司