專利名稱：信令處理方法
技術領域：
本發(fā)明涉及通信領域，尤其涉及信令的處理。
背景技術：
在CDMA(Code Division Multiple Access，碼分多址接入)智能網(wǎng)業(yè)務，如預付費業(yè)務和CDMA MSC(Mobile Switching Center，移動交換中心)/SSP(Service Switching Point，業(yè)務交換點)的信令交互諸多流程中，存在一種特殊的情況當主叫預付費用戶呼叫普通被叫用戶并接通被叫使得被叫震鈴，但在被叫摘機應答前，主叫預付費用戶放棄了呼叫。對于這種情形，在IS-826協(xié)議中有相應的規(guī)定，但沒有相應的實現(xiàn)流程。
與本發(fā)明有關的現(xiàn)有技術是根據(jù)IS-826協(xié)議第4章第8.×.19節(jié)的定義，對上述存在的特殊情況的處理流程，其如圖1所示，包括如下步驟步驟1，主叫用戶在始發(fā)局發(fā)起呼叫，始發(fā)局中的MSC收到主叫號碼撥打的被叫號碼。
步驟2，始發(fā)局中的MSC檢測Origination_Attempt_Authorized觸發(fā)器是否滿足觸發(fā)條件，當確認滿足時發(fā)送ORREQ(始呼請求)消息到SCP(Service Control Point，業(yè)務控制點)。
步驟3，SCP經(jīng)過檢查并確認該主叫用戶擁有足夠的余額和權限后，繼續(xù)本次呼叫，并返回orreq(始呼請求響應)通知始發(fā)局中的MSC繼續(xù)本次呼叫的處理，該消息中的DMH_SVCID(智能業(yè)務標志)參數(shù)用來通知始發(fā)局本次呼叫是智能網(wǎng)PPS(預付費業(yè)務)呼叫。
步驟4，始發(fā)局對主叫用戶撥打的被叫號碼進行分析后準備路由，觸發(fā)Calling_Routing_Address_Available(主叫路由地址可用)觸發(fā)器，發(fā)送ANLYZD(分析信息請求)消息到SCP。
步驟5，SCP經(jīng)過檢查發(fā)現(xiàn)需要對該PPS用戶播放余額通知，于是發(fā)送SEIZERES(捕獲資源請求)消息到IP(Intelligent Peripheral，智能外設)，請求獲得放音資源。
步驟6，IP收到SEIZERES消息后，分配放音資源并將該資源對應的TLDN(臨時本地用戶號碼)通過SEIZERES(捕獲資源響應)消息返回給SCP。
步驟7，SCP發(fā)送CONNRES(連接資源請求)消息到始發(fā)局中的MSC，要求MSC連接到IP的話路。
步驟8，MSC向IP發(fā)送call setup(建立話音通道)請求，請求連接到IP的話路。
步驟9，當IP發(fā)現(xiàn)放音話路已經(jīng)連接后，發(fā)送INSTREQ(放音指示請求)消息到SCP，請求放音指示。
步驟10，SCP發(fā)送SRFDIR(放音指示)到IP，通過ANNLIST(語音列表)參數(shù)指示IP放音。
步驟11，IP根據(jù)ANNLIST參數(shù)的指示對用戶放音。
步驟12，放音完畢，IP返回一個空的srfdir(放音指示響應)消息到SCP。
步驟13，SCP返回anlyzd(分析信息響應)消息到始發(fā)局中的MSC。
步驟14，始發(fā)局中的MSC釋放其到IP的話路。
步驟15，SCP發(fā)送instreq(指示請求響應)消息到IP，并結束SCP和IP之間的消息對話。
步驟16，始發(fā)局中的MSC通過call setup(呼叫建立)消息接續(xù)到被叫局的話路，被叫用戶震鈴。
步驟17，被叫用戶無人接聽，主叫用戶放棄呼叫，并發(fā)送call abandon(呼叫放棄)消息給始發(fā)局的MSC。
步驟18，始發(fā)局的MSC發(fā)送call release(呼叫釋放)消息給被叫移動設備，釋放連接到被叫移動設備的話路。
步驟19，SCP長時間沒有收到任何MSC過來的消息一直到SCP SLPI(業(yè)務邏輯處理實例)超時，因此SCP決定下發(fā)CCDIR(呼叫激活測試請求)消息到MSC，檢測MSC的狀態(tài)，所述CCDIR消息中攜帶MSCID(MSC的標志)、MSID(移動設備標志)、MDN(移動設備號碼)、billingID(計費標識，用來標志本次呼叫)等參數(shù)，其中的BillingID參數(shù)用來標志該呼叫。
步驟20，始發(fā)局中的MSC發(fā)現(xiàn)本局并未存在和接收到BillingID能夠關聯(lián)的呼叫，于是返回RETURN ERROR(呼叫錯誤)消息給SCP。所述消息中攜帶著ReleaseCause(呼叫釋放原因)參數(shù)。
在IS-826標準中，對所述ReleaseCause參數(shù)進行了定義，如下The ReleaseCause(RELCAUSE)parameter identifies the call release cause.Therelease cause applies to the call associated with a BillingID.(ReleaseCause參數(shù)標志呼叫釋放原因，釋放原因與BillingID參數(shù)由關聯(lián)。)對ReleaseCause參數(shù)的詳細定義如表1所示

表1從表1可以看出，IS-826標準僅僅定義了ReleaseCause參數(shù)的內(nèi)容可以通過8位字節(jié)的長度表示，但是如何表示卻沒有具體的定義。
經(jīng)過上述步驟后，如果SCP接收到該呼叫錯誤消息，則釋放所有與該呼叫相關的系統(tǒng)資源，SLPI(Service Logic Process Instance，業(yè)務邏輯處理實例)結束。
由上述現(xiàn)有技術的技術方案可以看出，現(xiàn)有技術中，在主叫放棄呼叫后，始發(fā)局中的MSC需要一直等待從SCP發(fā)送過來的CCDIR(呼叫激活測試)消息；而且MSC在接收到CCDIR消息后，檢查本局并不存在CCDID消息中BillingID參數(shù)所指示的呼叫上下文，才返回錯誤的CCDIR消息，之后SCP發(fā)現(xiàn)錯誤后再釋放自己的SLPI自動機。由于上述這些情況，現(xiàn)有技術存在如下的缺陷始發(fā)局中的MSC等待從SCP發(fā)送過來的CCDIR的過程中，以及SCP在消極等待MSC的呼叫激活測試回應的過程中均會占用資源，從而浪費了SCP的資源，而且影響SCP的處理速度。

發(fā)明內(nèi)容
本發(fā)明的目的是提供一種信令處理方法，通過本發(fā)明，能夠節(jié)省SCP的資源，能夠提高SCP的處理速度。
本發(fā)明的目的是通過以下技術方案實現(xiàn)的本發(fā)明提供一種信令處理方法，其包括A、當主叫用戶所在的端局獲知到主叫用戶釋放呼叫后，將與所述呼叫的有關信息發(fā)送給所述主叫用戶所在的數(shù)據(jù)處理中心；B、所述數(shù)據(jù)處理中心根據(jù)所述信息釋放與所述主叫用戶的呼叫有關的資源。
其中，所述步驟A具體包括當主叫用戶所在的移動交換中心MSC獲知到主叫用戶釋放呼叫后，將與所述呼叫的有關信息發(fā)送給業(yè)務控制點SCP。
其中，所述步驟A具體包括當主叫用戶所在的MSC獲知到主叫用戶釋放呼叫的信息后，通過主叫話機請求ODISCONNECT消息將與所述呼叫的有關信息發(fā)送給SCP，所述消息中攜帶著與所述呼叫的有關信息。
其中，與所述呼叫的有關信息包括觸發(fā)器型號Trigtype、本次呼叫的計費標識BillingID以及呼叫釋放原因ReleaseCause參數(shù)。
其中，與所述呼叫的有關信息還包括主叫用戶移動設備所在的MSC的MSC標志MSCID、主叫移動設備標志MSID以及主叫移動設備號碼MDN參數(shù)。
其中，所述步驟B具體包括所述SCP根據(jù)所述信息釋放與所述主叫用戶的呼叫有關的資源。
其中，所述步驟B具體包括B1、所述SCP根據(jù)所述BillingID參數(shù)查找相應的呼叫自動機；B2、根據(jù)所述Trigtype參數(shù)和ReleaseCause參數(shù)中的值確認釋放該呼叫時，釋放SCP上與該呼叫自動機相關的資源。
其中，所述步驟B還包括發(fā)送odiSconnect消息給MSC。
其中，步驟B2中，在釋放SCP上與該呼叫相關的資源的過程之前還包括根據(jù)接收到的MSCID、MSID、MDN寫失敗的日志文件。
由上述本發(fā)明提供的技術方案可以看出，本發(fā)明中，當主叫用戶所在的端局獲知到主叫用戶釋放呼叫后，將與所述呼叫的有關信息發(fā)送給所述主叫用戶所在的數(shù)據(jù)處理中心；然后所述數(shù)據(jù)處理中心根據(jù)所述信息釋放與所述主叫用戶的呼叫有關的資源。通過本發(fā)明，當主叫用戶釋放呼叫后，能夠及時將相關信息傳送給數(shù)據(jù)處理中心，如智能網(wǎng)中的SCP，從而能夠使數(shù)據(jù)處理中心及時獲知與主叫用戶的呼叫有關的信息，并根據(jù)所獲知的信息及時進行處理，因此本發(fā)明能夠節(jié)省數(shù)據(jù)處理中心的資源，能夠提高數(shù)據(jù)處理中心的處理速度。


圖1為現(xiàn)有技術中當主叫預付費用戶在被叫摘機應答前釋放呼叫時的處理流程圖；圖2為本發(fā)明提供的實施例中當主叫預付費用戶在被叫摘機應答前釋放呼叫時的處理流程圖。
具體實施例方式
針對本發(fā)明所述的方法，本發(fā)明提供了第一實施例，其主要思想是在主叫用戶所在的端局，如MSC發(fā)現(xiàn)主叫用戶放棄后，主動上報ODISCONNECT(主叫話機請求)消息給所述主叫用戶所在的數(shù)據(jù)處理中心，如SCP，SCP接收到該消息后，要求能夠識別這條特殊的ODISCONNECT消息，并釋放和清空與該呼叫相關聯(lián)的所有資源。其信令處理流程如圖2所示，包括步驟1，主叫用戶在始發(fā)局發(fā)起呼叫，始發(fā)局中的MSC收到主叫號碼撥打的被叫號碼。
步驟2，始發(fā)局中的MSC檢測Origination_Attempt_Authorized觸發(fā)器是否滿足觸發(fā)條件，當確認滿足時發(fā)送ORREQ(始呼請求)消息到SCP(Service Control Point，業(yè)務控制點)。
步驟3，SCP經(jīng)過檢查并確認該主叫用戶擁有足夠的余額和權限后，繼續(xù)本次呼叫，并返回orreq(始呼請求響應)通知始發(fā)局中的MSC繼續(xù)本次呼叫的處理，該消息中的DMH_SVCID參數(shù)用來通知始發(fā)局本次呼叫是智能網(wǎng)PPS(預付費業(yè)務)呼叫。
步驟4，始發(fā)局對主叫用戶撥打的被叫號碼進行分析后準備路由，觸發(fā)Calling_Routing_Address_Available(主叫路由地址可用)觸發(fā)器，發(fā)送ANLYZD(分析信息請求)消息到SCP。
步驟5，SCP經(jīng)過檢查發(fā)現(xiàn)需要對該PPS用戶播放余額通知，于是發(fā)送SEIZERES(捕獲資源請求)消息到IP(Intelligent Peripheral，智能外設)，請求獲得放音資源。
步驟6，IP收到SEIZERES消息后，分配放音資源并將該資源對應的TLDN通過SEIZERES(捕獲資源響應)消息返回給SCP。
步驟7，SCP發(fā)送CONNRES(連接資源請求)消息到始發(fā)局中的MSC，要求MSC連接到IP的話路。
步驟8，MSC向IP發(fā)送call setup(建立話音通道)請求，請求連接到IP的話路。
步驟9，當IP發(fā)現(xiàn)放音話路已經(jīng)連接后，發(fā)送INSTREQ(放音指示請求)消息到SCP，請求放音指示。
步驟10，SCP發(fā)送SRFDIR(放音指示)到IP，通過ANNLIST(語音列表)參數(shù)指示IP放音。
步驟11，IP根據(jù)ANNLIST參數(shù)的指示對用戶放音。
步驟12，放音完畢，IP返回一個空的srfdir(放音指示響應)消息到SCP。
步驟13，SCP返回anlyzd(分析信息響應)消息到始發(fā)局中的MSC。
步驟14，始發(fā)局中的MSC釋放其到IP的話路。
步驟15，SCP發(fā)送instreq(指示請求響應)消息到IP，并結束SCP和IP之間的消息對話。
步驟16，始發(fā)局中的MSC通過call setup(呼叫建立)消息接續(xù)到被叫局的話路，被叫用戶震鈴。
步驟17，被叫用戶無人接聽，主叫用戶放棄呼叫，并發(fā)送call abandon(呼叫放棄)消息給始發(fā)局的MSC。
步驟18，始發(fā)局的MSC發(fā)送call release(呼叫釋放)消息給被叫移動設備，釋放連接到被叫移動設備的話路。
步驟19，始發(fā)局的MSC在釋放話路后立即主動上報ODISCONNECT消息到SCP。所述消息中攜帶如下參數(shù)a、Trigtype(觸發(fā)器的型號)，用于標志始發(fā)局發(fā)送的ODISCONNECT消息檢測到的觸發(fā)器，如檢測到的觸發(fā)器為ODISCCONT觸發(fā)器時，其值標志為41。
b、始發(fā)局中的MSC的MSCID，用于標志主叫端始發(fā)局的MSC號，如當用戶在漫游地進行主叫時，在這里可以填寫主叫漫游地端局的真實MSCID。
c、BillingID，用于標志本次呼叫的唯一性參數(shù)，在這里可以填寫該呼叫真實BillingID信息，并與該呼叫前面操作的billing保持一致，以便SCP收到該參數(shù)后，使用其識別SCP上對應的呼叫自動機。
d、MSID of the calling party(主叫移動設備的唯一性標志)，用于標識主叫移動設備，在這里可以填寫真實的主叫移動設備的MSID信息。
e、MDN of the calling party(主叫移動設備號碼)，用于SCP在呼叫控制和計費處理時正確識別該呼叫的主叫用戶，在這里可以填寫主叫用戶使用移動設備的真實號碼。
f、ReleaseCause(呼叫釋放原因)，用于描述呼叫失敗的原因。本發(fā)明中的ReleaseCause參數(shù)是在現(xiàn)有IS-826標準中對其定義的基礎上進行定義，如表2所示

表2從表2可以看出，當8位字節(jié)全部為0時，則表示沒有規(guī)定具體含義。當8位字節(jié)的最后1位為1，其它全部為0時，則表示主叫用戶呼叫釋放的原因。當8位字節(jié)的最后2位分別為1、0，其它全部為0時，則表示被叫用戶呼叫釋放的原因。當8位字節(jié)的最后2位分別為1、1，其它全部為0時，則表示Commanded Disconnect(命令連接失敗)。
g、SCP接收到ODISCONNECT消息后，根據(jù)所述ODISCONNECT消息中攜帶的信息釋放所有與該呼叫相關的系統(tǒng)資源，SLPI結束。并同時返回odisconnect響應消息通知主叫端的始發(fā)局清除所有與該呼叫有關的上下文。
在步驟g中，SCP接收到ODISCONNECT消息后，根據(jù)消息中攜帶的Billing ID參數(shù)查找相應的呼叫自動機，然后通過識別TRIGTYPE和releasecause中的commanded disconnect的值判斷出需要釋放該呼叫，并在釋放呼叫前根據(jù)接收到的MSCID、MSID、MDN寫失敗的日志文件，然后釋放SCP上一切與該呼叫自動機相關的資源(包括對話原語處理部分、呼叫自動機處理部分等占用的系統(tǒng)資源)，然后回odisconnect消息給MSC。
上述針對在被叫用戶摘機應答前，主叫用戶釋放呼叫的異常情況進行處理的流程。當用戶使用的移動設備移動到小區(qū)未覆蓋的區(qū)域內(nèi)時，可能會接收不到網(wǎng)絡信號而導致呼叫失敗，對于這些異常情況，只要MSC獲知到主叫用戶已經(jīng)釋放呼叫后，均可以采用主叫用戶端的MSC主動上報ODISCONNECT消息到SCP的方式通知SCP主叫已經(jīng)釋放呼叫，從而使SCP及時處理與主叫用戶的呼叫相關的資源。
由上述本發(fā)明的具體實施方案可以看出，本發(fā)明中MSC檢測到主叫用戶放棄呼叫后主動上報ODISCONNECT消息到SCP，這條消息會在Oanswer消息之前到達所述SCP。所述SCP接收到這條特殊的ODISCONNECT消息后，對其進行識別和處理后，返回odisconnect消息給MSC。通過本發(fā)明，對于智能網(wǎng)PPS業(yè)務主叫放棄流程進行了優(yōu)化，通過其MSC和SCP不必消極等待節(jié)省了SCP的資源、提高了SCP的處理效率。
以上所述，僅為本發(fā)明較佳的具體實施方式
，但本發(fā)明的保護范圍并不局限于此，任何熟悉本技術領域的技術人員在本發(fā)明揭露的技術范圍內(nèi)，可輕易想到的變化或替換，都應涵蓋在本發(fā)明的保護范圍之內(nèi)。因此，本發(fā)明的保護范圍應該以權利要求的保護范圍為準。
權利要求
1.一種信令處理方法，其特征在于，包括A、當主叫用戶所在的端局獲知到主叫用戶釋放呼叫后，將與所述呼叫的有關信息發(fā)送給所述主叫用戶所在的數(shù)據(jù)處理中心；B、所述數(shù)據(jù)處理中心根據(jù)所述信息釋放與所述主叫用戶的呼叫有關的資源。
2.根據(jù)權利要求1所述的方法，其特征在于，所述步驟A具體包括當主叫用戶所在的移動交換中心MSC獲知到主叫用戶釋放呼叫后，將與所述呼叫的有關信息發(fā)送給業(yè)務控制點SCP。
3.根據(jù)權利要求2所述的方法，其特征在于，所述步驟A具體包括當主叫用戶所在的MSC獲知到主叫用戶釋放呼叫的信息后，通過主叫話機請求ODISCONNECT消息將與所述呼叫的有關信息發(fā)送給SCP，所述消息中攜帶著與所述呼叫的有關信息。
4.根據(jù)權利要求1、2或3所述的方法，其特征在于，與所述呼叫的有關信息包括觸發(fā)器型號Trigtype、本次呼叫的計費標識BillingID以及呼叫釋放原因ReleaseCause參數(shù)。
5.根據(jù)權利要求4所述的方法，其特征在于，與所述呼叫的有關信息還包括主叫用戶移動設備所在的MSC的MSC標志MSCID、主叫移動設備標志MSID以及主叫移動設備號碼MDN參數(shù)。
6.根據(jù)權利要求4所述的方法，其特征在于，所述步驟B具體包括所述SCP根據(jù)所述信息釋放與所述主叫用戶的呼叫有關的資源。
7.根據(jù)權利要求6所述的方法，其特征在于，所述步驟B具體包括B1、所述SCP根據(jù)所述BillingID參數(shù)查找相應的呼叫自動機；B2、根據(jù)所述Trigtype參數(shù)和ReleaseCause參數(shù)中的值確認釋放該呼叫時，釋放SCP上與該呼叫自動機相關的資源。
8.根據(jù)權利要求7所述的方法，其特征在于，所述步驟B還包括發(fā)送odisconnect消息給MSC。
9.根據(jù)權利要求8所述的方法，其特征在于，步驟B2中，在釋放SCP上與該呼叫相關的資源的過程之前還包括根據(jù)接收到的MSCID、MSID、MDN寫失敗的日志文件。
全文摘要
本發(fā)明涉及一種信令處理方法，其核心是當主叫用戶所在的端局獲知到主叫用戶釋放呼叫后，將與所述呼叫的有關信息發(fā)送給所述主叫用戶所在的數(shù)據(jù)處理中心；然后所述數(shù)據(jù)處理中心根據(jù)所述信息釋放與所述主叫用戶的呼叫有關的資源。通過本發(fā)明，當主叫用戶釋放呼叫后，能夠及時將相關信息傳送給數(shù)據(jù)處理中心，如智能網(wǎng)中的SCP，從而能夠使數(shù)據(jù)處理中心及時獲知與主叫用戶的呼叫有關的信息，并根據(jù)所獲知的信息及時進行處理，因此本發(fā)明能夠節(jié)省數(shù)據(jù)處理中心的資源，能夠提高數(shù)據(jù)處理中心的處理速度。
文檔編號H04Q7/22GK1867084SQ20061005816
公開日2006年11月22日 申請日期2006年3月8日 優(yōu)先權日2006年3月8日
發(fā)明者程正岳 申請人:華為技術有限公司