專利名稱:一種檢測d通道狀態(tài)的方法
技術(shù)領(lǐng)域:
本發(fā)明涉及網(wǎng)絡信令傳輸領(lǐng)域,尤其涉及一種檢測D通道狀態(tài)的方法。
背景技術(shù):
隨著IP網(wǎng)絡技術(shù)的逐步成熟,電路交換網(wǎng)與數(shù)據(jù)分組網(wǎng)的融合是必然趨 勢,出現(xiàn)了在IP網(wǎng)絡上傳輸七號信令等電路交換信令協(xié)議的需求。為了滿足 在IP網(wǎng)纟各上4專專IH言令十辦"i義的需求,IETF (Internet Engineering Task Force, 因特網(wǎng)工程任務組)制訂的IP網(wǎng)絡信令傳輸協(xié)議(SIGTRAN協(xié)議)支持通過IP 網(wǎng)絡傳輸傳統(tǒng)電路交換信令。2005年IETF工作組正式發(fā)布了ISDN Q.921用 戶適配層協(xié)議IUA (lntegated Services Digital Network(ISDN) Q,921-User Adaptation Layer)。 IUA協(xié)議定義了通過流控制傳輸協(xié)i義(SCTP, Stream control Transmission Protocol)來實現(xiàn)4言令網(wǎng)關(guān)(SG, Signaling Gateway) Q.921和媒體網(wǎng)關(guān)控制器(MGC, Media Gateway Controller)Q.931之間的消 息傳遞。
根據(jù)RFC4233的規(guī)定,現(xiàn)有技術(shù)中沒有MGC和SG上D通道狀態(tài)保持一
因經(jīng)常會導致兩邊狀態(tài)不一致、無法及時恢復,導致消息丟失,業(yè)務損失巨 大。
從上述內(nèi)容可以看出,就現(xiàn)有技術(shù)而言,無法及時獲得MGC上的D通道 狀態(tài)和SG上的D通道狀態(tài),致使消息丟失、業(yè)務損失巨大,系統(tǒng)可靠性差。
發(fā)明內(nèi)容
本發(fā)明提供了 一種檢測D通道狀態(tài)的方法,解決了現(xiàn)有技術(shù)中無法及時獲得MGC上的D通道狀態(tài)和SG上的D通道狀態(tài)的問題。 本發(fā)明是通過以下技術(shù)方案實現(xiàn) 一種4企測D通道狀態(tài)的方法,包括 發(fā)送查詢D通道狀態(tài)的查詢信息;
接收到所述查詢信息后,將接收端的D通道狀態(tài)信息置于回應信息內(nèi), 反饋給發(fā)送端;
發(fā)送端根據(jù)接收端反饋的所述回應信息,獲取接收端的D通道狀態(tài)。 所述發(fā)送端為媒體網(wǎng)關(guān)控制器或信令網(wǎng)關(guān),所述接收端為信令網(wǎng)關(guān)或媒 體網(wǎng)關(guān)控制器。
獲取接收端的D通道狀態(tài)后,若判定接收端D通道狀態(tài)與發(fā)送端D通道 狀態(tài)不一致,發(fā)出警告信息,請求釋放接收端的D通道或建立發(fā)送端的D通 道,恢復D通道狀態(tài)。
D通道建立成功后,設(shè)置D通道查詢等待定時器,以便檢測是否在預定 時間內(nèi)收到接收端的回應信息。
需要說明的是,D通道的建立可以是在系統(tǒng)初始化的時候?qū)崿F(xiàn),也可以 是在系統(tǒng)開始工作一段時間之后,D通道需要修復或重建時實現(xiàn)。
所述方法進一步包括 設(shè)置D通道狀態(tài)查詢計數(shù)器,發(fā)送查詢信息后,計數(shù)值增加1;收到接 收端回應信息后,計數(shù)值清零。
所述計數(shù)值增加到預定值時,發(fā)出警告信息,請求釋放接收端的D通道。
由上述本發(fā)明提供的技術(shù)方案可以看出,本發(fā)明提供了 一種檢測D通道 狀態(tài)的方法,提出及時獲取D通道狀態(tài)信息的方法,使得MGC和SG上的D通
道狀態(tài)信息可以及時被提取,提高系統(tǒng)可靠性。
圖1為本發(fā)明實施例提供的IUA在SIGTRAN協(xié)議棧中所處位置的結(jié)構(gòu)示意
圖2為本發(fā)明實施例提供的MGC主動查詢SG上D通道狀態(tài)的操作流程示意圖。
具體實施例方式
本發(fā)明提供的技術(shù)方案包括
發(fā)送查詢D通道狀態(tài)的查詢信息;可以是按照 一定的時間間隔來執(zhí)行發(fā) 送操作,也可以是隨機執(zhí)行發(fā)送操作;
這里需要說明一下,在發(fā)送端的D通道建立成功之后,馬上為其設(shè)置D通 道查詢等待定時器和D通道狀態(tài)查詢計數(shù)器,其中
D通道查詢等待定時器,用于檢測發(fā)送端是否在預定時間內(nèi)收到接收端 的回應信息;
D通道狀態(tài)查詢計數(shù)器,發(fā)送查詢信息后,計數(shù)值增加1;收到接收端回 應信息后,計數(shù)值清零。當D通道狀態(tài)查詢計數(shù)器的計數(shù)值增加到預定值 時,表明發(fā)送端未能在預定時間內(nèi)接收接收端返回的回應信息,可以認定接 收端D通道與發(fā)送端D通道狀態(tài)不一致,發(fā)出警告信息,請求釋放接收端的D 通道,恢復接收端的D通道狀態(tài)。
接收到所述查詢信息后,將接收端的D通道狀態(tài)信息置于回應信息內(nèi), 反饋給發(fā)送端;
發(fā)送端根據(jù)接收端反饋的所述回應信息,獲取接收端的D通道狀態(tài)。發(fā) 送端可以根據(jù)其接收到的接收端反饋的所述回應信息,判斷發(fā)送端上的D通 道狀態(tài)和接收端上的D通道狀態(tài)是否一致,判定發(fā)送端上的D通道狀態(tài)和接 收端上的D通道狀態(tài)不一致時,發(fā)出警告信息,請求釋放當前接收端的D通 道或發(fā)起建立當前發(fā)送端的D通道;也就是說,如果獲取到的接收端的D通 道狀態(tài)為可用,而發(fā)送端的D通道狀態(tài)為不可用,則發(fā)送端立即發(fā)起建立D通道請求。如果發(fā)送端的D通道狀態(tài)為可用,接收端的D通道狀態(tài)為不可
用,那么發(fā)送端立即發(fā)起D通道釋放請求。
所述發(fā)送端為々某體網(wǎng)關(guān)控制器(MGC, Media Gateway Controller)或 信令網(wǎng)關(guān)(SG, Signaling Gateway),所述接收端為信令網(wǎng)關(guān)或媒體網(wǎng)關(guān) 控制器。
對MGC上的D通道和SG上的D通道而言,在執(zhí)行本發(fā)明提供的技術(shù)方案 過程中,需要增加兩個原語,這兩個原語為D通道狀態(tài)查詢(Status Request)和狀態(tài)應答(Status Confirm ):
狀態(tài)查詢用Status Request表示,MGC上的IUA定時向發(fā)送查詢SG上
的D通道狀態(tài);
狀態(tài)應答用Status Confirm表示,SG上接收到來自MGC的D通道狀態(tài) 查詢后,向MGC回應當前D通道狀態(tài)信息;
在SG或MGC上的D通道建立成功后,為其設(shè)置Tw (D通道查詢等待定時 器),目的是檢測在一段時間內(nèi)是否收到對端的應答。
Q931 (對應于MGC)發(fā)起查詢消息后,D通道狀態(tài)查詢次數(shù)加1,即D 通道狀態(tài)查詢計數(shù)器的計數(shù)值增加1,若發(fā)送端收到接收端的應答,則D通道 狀態(tài)查詢次數(shù)清0,即D通道狀態(tài)查詢計數(shù)器的計數(shù)值置零。
可以為D通道狀態(tài)查詢計數(shù)器設(shè)置一個預定值,如用MaxStatusReqNum (最大查詢次數(shù))表示,當Q931發(fā)起查詢消息后查詢次數(shù)累加,如果達到該 最大次數(shù)就認為對端(即Q921,對應于SG)的D通道已經(jīng)不通。
本發(fā)明實施例提供的技術(shù)方案中,可以通過擴展QPTM (Q.921/Q.931 Boundary Primitives Transport Messages, Q.921或者Q.931邊界原語傳輸消 息,IUA的一種消息類別)消息實現(xiàn)D通道狀態(tài)查詢。
如現(xiàn)有的Q PTM消息內(nèi)容為
Q.921/Q.931 Boundary Primitives Transport (QPTM) Messages 0 Reserved (預留)1 Data Request Message (確認數(shù)據(jù)請求消息)
2 Data Indication Message (確iM^才居指示消息)
3 Unit Data Request Message (非確{人豸史才居^"求消息)
4 Unit Data Indication Message (非確i人凄t據(jù)指示消息)
5 Establish Request ( D通道建立i貪,長)
6 Establish Confirm (D通道建立確認)
7 Establish Indication (D通道建立才旨示)
8 Release Request ( D通道釋放請求)
9 Release Confirm ( D通道釋放確認) 10 Release Indication (D通道釋放指示)
11 to 127 Reserved by the IETF (IETF預留字段) 128 to 255 Reserved for IETF誦Defined QPTM extensions (預留用于 IETF定義的QPTM擴展)
經(jīng)過擴展后的QPTM消息內(nèi)容如下
Q.921/Q.931 Boundary Primitives Transport (QPTM) Messages
0Reserved
1Data Request Message
2Data Indication Message
3Unit Data Request Message
4Unit Data Indication Message
5Establish Request
6Establish Confirm
7Establish Indication
8Release Request
9Release Confirm
10Release Indication
11Status Request ( D通道狀態(tài)查詢請求)12 Status Confirm ( D通道^l犬態(tài)查詢確i人) 13 to 127 Reserved by the IETF
128 to 255 Reserved for IETF-Defined QPTM extensions
上述QPTM消息內(nèi)容中的數(shù)字O, 1, 2……255表示QPTM消息中的具 體消息類型。比較QPTM消息擴展前后的內(nèi)容,可知
QPTM消息內(nèi)容在為IETF留下來的保留位處,增加了兩個參數(shù)Status Request (狀態(tài)查詢)和Status Confirm (狀態(tài)應答)。
IUA消息包含一個公共消息頭,其后可以跟隨零個或者多個可變參數(shù),
所述可變參數(shù)由消息類型確定。現(xiàn)有的可變參數(shù)包括:
Reserved 0x0000 Interface Identifier (integer)(接口標識符(整型))0x0001
Not Used in IUA 0x0002 Interface Identifier (text)(接口標識符(文本)) 0x0003
INFO String(信息字符串) 0x0004
DLCI (數(shù)據(jù)鏈路連接標識符) 0x0005
Not Used in IUA 0x0006
Diagnostic Information (診斷信息) 0x0007
Interface Identifier Range (接口標識符范圍) 0x0008
Heartbeat Data (心跳數(shù)據(jù)) 0x0009
Not Used in IUA 0x000a
Traffic Mode Type (業(yè)務模式類型) 0x000b
Error Code (錯誤代碼) 0x000c
Status (狀態(tài)) OxOOOdProtocol Data (協(xié)議數(shù)據(jù)) Release Reason (釋》丈原因) T曰Status (TEI狀態(tài)) ASP Identifier (ASP標識符) Not Used in IUA 增加D通道狀態(tài)查詢后的可變參數(shù)包括: Parameter Name (參數(shù)名稱)
0x000e 0x000f 0x0010 0x0011 0x0012-0x003f
Parameter ID
(參數(shù)的消息類型序號)
Reserved 0x0000
Interface Identifier (integer)0x0001
Not Used in IUA0x0002
Interface Identifier (text)0x0003
INFO String0x0004
DLCI0x0005
Not Used in IUA0x0006
Diagnostic Information0x0007
Interface Identifier Range0x0008
Heartbeat Data0x0009
Not Used in IUA0x0003
Traffic Mode Type0x000b
Error Code0x000c
StatusOxOOOd
Protocol DataOxOOOe
R6l63S6 R63S0DOxOOOf
TEI Status0x0010
ASP Identifier0x0011
DL Status ( D通道狀態(tài))0x0012Not Used in IUA 0x0013 - 0x003f
比較擴展前后的可變參數(shù)內(nèi)容可知,擴展后增加了一個可變參數(shù)DL
Status , DL Status為接收端回應發(fā)送端D通道狀態(tài)查詢時所攜帶的D通道狀 態(tài)的信息參數(shù)。擴展后的Status Confirm包含的D通道狀態(tài)參數(shù)結(jié)構(gòu)為
0 12 3
01234567890123456789012345678901
I Tag (0x0012) I Lengths I
I DLStatus I
其中DL Status參數(shù)的值定義為
DL—RELEASE 0x0 D通道已經(jīng)被釋放
DL—AWAIT—EST 0x1 D通道等待建立狀態(tài)
DL—ESTABLISH 0x2 D通道建立狀態(tài)
DL—AWAIT—REL 0x3 D通道等待釋放狀態(tài) 根據(jù)以上擴展消息,MGC向SG查詢D通道狀態(tài)使用Status Request消 息,消息包含公共消息頭和IUA消息頭;而SG向MGC應答D通道狀態(tài)使用 Status Confirm消息,消息包含公共消息頭、IUA消息頭以及D通道狀態(tài)消息 結(jié)構(gòu)。
接下來,以MGC為發(fā)送端、SG為接收端為例說明本發(fā)明實施例所述的 方法提供的技術(shù)方案
在MGC上的D通道建立成功后,為其設(shè)置定時器。
步驟A、 MGC上的Q931定時向MGC上的IUA發(fā)送查詢D通道狀態(tài)的信自.
步驟B、 MGC上的Q931向IUA查詢D通道狀態(tài),D通道狀態(tài)查詢計數(shù)器的 計數(shù)值增加1,同時啟動D通道查詢等待定時器Tw,如果在Tw沒有超時的時 間段內(nèi),收到SG的回應信息,則執(zhí)行步驟C,否則執(zhí)行步驟l。步驟C 、 MGC上的IUA接收到Q931的D通道查詢消息(Status Request)后,通過將該消息組裝成IUA消息格式,然后IUA選擇合適的 SCTP (Stream Control Transmission Protocol,流控制傳輸協(xié)議)偶聯(lián)將消 息成功發(fā)送到SG;
步驟D. SG上的IUA收到對端MGC上的消息,通過解析將消息Status Request發(fā)送到SG上的Q921;
步驟E、 SG上的Q921收到D通道狀態(tài)查詢消息后將自己的D通道狀態(tài)通 過Status Confirm消息發(fā)送給SG上的IUA;
步驟F、 SG上的IUA將接收到的Status Confirm消息轉(zhuǎn)換成IUA消息格式 發(fā)送給MGC上的IUA;
步驟G、 MGC上IUA收到該IUA格式消息后,將該消息轉(zhuǎn)換成Q931可以 識別的消息——狀態(tài)應答(Status Confirm )消息,然后將該消息發(fā)送到 MGC上的Q931。
步驟H、 Q931收到狀態(tài)應答消息后將狀態(tài)查詢次數(shù)清0,然后判斷是否 和自己的狀態(tài)一致。如果一致執(zhí)行步驟l,否則執(zhí)行步驟J。
步驟l、 當Tw超時后,判斷狀態(tài)查詢次數(shù)是否大于或者等于 MaxStatusReqNum,如果小于則執(zhí)行步驟B,否則執(zhí)行步驟上
步驟J、 Q931認為對端D通道已經(jīng)不可用,然后發(fā)起D通道釋放請求, 請求釋放D通道,同時狀態(tài)查詢次數(shù)清零,即狀態(tài)查詢計數(shù)器清零。
由上述內(nèi)容可知本發(fā)明所提供的技術(shù)方案通過擴展IUA的QPTM消息來 查詢SG上的D通道狀態(tài),這樣防止了兩端D通道狀態(tài)不一致的問題,同時也 提前預防了因D通道不可用導致大量數(shù)據(jù)的丟失的問題,提高了系統(tǒng)的可靠 性。
下面結(jié)合附圖2對本發(fā)明所采用的方法進行說明。 其處理流程如下步驟1, MGC上的Q931定時向MGC上的IUA查詢D通道狀態(tài),Q931發(fā)起 D通道狀態(tài)查詢消息(Status Request)后,查詢次數(shù)加1,即D通道狀態(tài)查 詢計數(shù)器的計數(shù)值增加1,同時啟動Tw;之后需定時查看Tw,若Tw未超時執(zhí) 行步驟2,否則執(zhí)行步驟8。
步驟2, MGC上的IUA收到Q931的D通道狀態(tài)查詢消息后,選擇合適的 偶聯(lián)將消息發(fā)送到SG上的SCTP;
步驟3, SG上的SCTP收到D通道狀態(tài)查詢消息后,將該消息解碼,獲得 D通道狀態(tài)查詢數(shù)據(jù)指示,并將該D通道狀態(tài)查詢數(shù)據(jù)指示發(fā)送至該SG上的 IUA;
步驟4,該IUA收到所述D通道狀態(tài)查詢數(shù)據(jù)指示后,向其所屬的Q921發(fā) 起D通道狀態(tài)查詢請求;
所述Q921收到D通道狀態(tài)查詢請求后,立即向SG上的IUA應答D通道狀 態(tài)消息,即反饋D通道狀態(tài)應答(Status Confirm )至該SG上的IUA;
步驟5, IUA將D通道狀態(tài)應答發(fā)送至SG上的SCTP; SG上的SCTP選沖奪 合適的偶聯(lián)將Status Confirm發(fā)送至MGC上的SCTP, MGC上的SCTP將該消 息解碼,獲得D通道狀態(tài)應答數(shù)據(jù)指示;
步驟6, MGC上的SCTP獲得D通道狀態(tài)應答數(shù)據(jù)指示后,將該D通道狀 態(tài)應答數(shù)據(jù)指示發(fā)送至該MGC上的IUA;
步驟7, MGC上的IUA收到SG上的D通道狀態(tài)應答數(shù)據(jù)指示后,找到該D 通道歸屬的Q931,向該Q931發(fā)送D通道狀態(tài)應答消息;Q931收到D通道狀 態(tài)應答消息后將查詢次數(shù)清O,然后判斷收到的狀態(tài)應答中攜帶的狀態(tài)是否 和自己狀態(tài)一致,如果一致執(zhí)行步驟8,否則執(zhí)行步驟9;
步驟8 :若Tw已超時,判斷查詢次數(shù)是否等于最大次數(shù) MaxStatusReqNum,如果小于則執(zhí)行步驟1;否則執(zhí)行步驟9。
步驟9:查詢次數(shù)清零(也就是說D通道狀態(tài)查詢計數(shù)器清零),Q931發(fā)送D通道釋放消息給SG。
從上述內(nèi)容可以看出,通過本發(fā)明提供的檢測D通道狀態(tài)的方法,可及 時獲取MGC和SG上的D通道狀態(tài)信息,保證在MGC和SG上的D通道狀態(tài)一 致,防止出現(xiàn)MGC和SG上的D通道狀態(tài)不一致、無法及時恢復的問題,提高 了系統(tǒng)的可靠性。
以上所述,僅為本發(fā)明較佳的具體實施方式
,但本發(fā)明的保護范圍并不 局限于此,任何熟悉本技術(shù)領(lǐng)域的技術(shù)人員在本發(fā)明揭露的技術(shù)范圍內(nèi),可 輕易想到的變化或替換,都應涵蓋在本發(fā)明的保護范圍之內(nèi)。因此,本發(fā)明 的保護范圍應該以權(quán)利要求書的保護范圍為準。
權(quán)利要求
1、一種檢測D通道狀態(tài)的方法,其特征在于,包括發(fā)送查詢D通道狀態(tài)的查詢信息;接收到所述查詢信息后,將接收端的D通道狀態(tài)信息置于回應信息內(nèi),反饋給發(fā)送端;發(fā)送端根據(jù)接收端反饋的所述回應信息,獲取接收端的D通道狀態(tài)。
2、 根據(jù)權(quán)利要求1所述方法,其特征在于,所述發(fā)送端為媒體網(wǎng)關(guān)控 制器或信令網(wǎng)關(guān),所述接收端為信令網(wǎng)關(guān)或媒體網(wǎng)關(guān)控制器。
3、 根據(jù)權(quán)利要求1所述方法,其特征在于,獲取接收端的D通道狀態(tài) 后,若判定接收端D通道狀態(tài)與發(fā)送端D通道狀態(tài)不一致,發(fā)出警告信息, 請求釋放接收端的D通道或請求建立發(fā)送端的D通道。
4、 根據(jù)權(quán)利要求1所述方法,其特征在于,D通道建立成功后,設(shè)置D 通道查詢等待定時器,以便檢測是否在預定時間內(nèi)收到接收端的回應信息。
5、 根據(jù)權(quán)利要求1所述方法,其特征在于,所述方法進一步包括 設(shè)置D通道狀態(tài)查詢計數(shù)器,發(fā)送查詢信息后,計數(shù)值增加1;收到接收端回應信息后,計數(shù)值清零。
6、 根據(jù)權(quán)利要求5所述方法,其特征在于,所述計數(shù)值增加到預定值 時,發(fā)出警告信息,請求釋放接收端的D通道。
全文摘要
本發(fā)明涉及網(wǎng)絡信令傳輸領(lǐng)域,本發(fā)明提供了一種檢測D通道狀態(tài)的方法及裝置,保證能夠及時獲悉MGC上D通道狀態(tài)和SG上D通道狀態(tài),防止了兩端D通道狀態(tài)不一致的問題,提高了系統(tǒng)的可靠性。
文檔編號H04L29/08GK101420339SQ20081014755
公開日2009年4月29日 申請日期2008年8月28日 優(yōu)先權(quán)日2008年8月28日
發(fā)明者張坤左, 梁慶永 申請人:中興通訊股份有限公司