專利名稱：一種實現(xiàn)應用服務器狀態(tài)一致的方法和應用服務器的制作方法
技術領域：
本發(fā)明屬于通信技術領域，具體涉及一種實現(xiàn)應用服務器狀態(tài)一致的方法和應用 服務器。
背景技術：
互聯(lián)網工程任務組(Internet Engineering Task Force, IETF)定義的信令傳輸 協(xié)議(Signal Transport Protocol, SIGTRAN)中，應用服務器(Application Server, AS) 包括消息傳遞部分第三級用戶適配層(MTP3User Adaptation layer，M3UA)、消息傳遞部分 第二級用戶適配層(MTP2User Adaptation layer，M2UA)、ISDN 用戶適配層(IUA)、SCCP 用 戶適配層(SUA)和V5用戶適配層(V5UA)等。M3UA、M2UA、IUA、SUA、V5UA均封裝在流控制 傳輸協(xié)議(Stream Control Transmission Protocol, SCTP)中，SCTP 又封裝在因特網協(xié)議 (IP)中。SIGTRAN協(xié)議被作為傳統(tǒng)電路交換網絡(Switched Circuit Network, SCN)域信 令及其用戶協(xié)議在IP網絡的適配協(xié)議，主要在IP域對等端節(jié)點或信令網關與IP域端節(jié)點 間對SCN域信令及其用戶協(xié)議進行適配。請參照圖1和圖2所示，SIGTRAN協(xié)議的應用場合分為兩種，圖1和圖2均以M3UA 為例，其他SIGTRAN協(xié)議類似。圖1是IP域信令端節(jié)點(IP Singalling Endpoint，IPSEP) 點業(yè)務交互，SIGTRAN協(xié)議用于承載SCN域信令及其用戶協(xié)議數據的邏輯通道稱為IP業(yè)務 服務進程(IP ServerProcessJPSP)，分為客戶端和服務器端。圖2是在信令網關(SG)與 IP域信令端節(jié)點(IPSEP)間的交互，SIGTRAN協(xié)議承載SCN域信令及其用戶協(xié)議數據的邏 輯通道分別是網關上的信令網關進程(SignalIingGateway Process, SGP)和IP域端節(jié)點 上的應用服務進程(Application ServerProcess，ASP)。應用服務器AS是協(xié)議描述的邏輯實體。AS包含一個或者多個應用服務器進程 ASP，ASP通過底層的SCTP進行數據傳輸。AS用來處理特定路由關鍵字的業(yè)務，比如某個AS 為特定范圍的PSTN (Public SwitchedTel印hone Network)中繼的呼叫處理服務，使用的關 鍵字組合是 SI0/DPC/CIC_Range (Service Information Octed/Destination PointCode/ Circuit Identification Code_Range)。本端將需要處理的業(yè)務消息交給AS，然后通過AS 選擇通道將業(yè)務消息發(fā)送到對端。請參閱圖3所示，應用服務器進程ASP狀態(tài)有3個，分別為宕機狀態(tài)(ASP_D0WN)、 去激活狀態(tài)(ASP_INACTIVE)和激活狀態(tài)(ASP_ACTIVE)。應用服務器AS狀態(tài)有4個，宕 機狀態(tài)(AS_D0WN)、去激活狀態(tài)(AS_INACTIVE)、激活狀態(tài)(AS_ACTIVE)和緩沖狀態(tài)(AS_ PENDING)。ASP和AS狀態(tài)的變化圖請參閱圖3、4所示。只有AS處于AS_ACTIV的狀態(tài)下 才將本端的業(yè)務數據通過ASP發(fā)送到對端。維護ASP基本通道狀態(tài)的管理消息是服務進程 狀態(tài)管理消息(Service ProcessState Maintenance，SPSM)，包括停止使用應用服務器進 程消息(ASPDown)、停止使用應用服務器進程響應消息(ASPDownAck)、啟用應用服務器進 程消息(ASPUp)以及啟用應用服務器進程消息(ASPUpAck)等消息。維護ASP業(yè)務通道狀 態(tài)的管理消息是服務進程業(yè)務管理消息(Service Process Traffice Maintenance, SPTM)包括有取消激活應用服務器進程消息(ASPInactive)、取消激活應用服務器進程響應消息 (ASPInactiveAck)、激活應用服務器進程消息(ASPActive)以及激活應用服務器進程響應 消息(ASPActiveAck)等消息。局間通過SPSM/TM對SP狀態(tài)進行維護。應用服務器AS狀 態(tài)變化由應用服務器進程ASP狀態(tài)的變化和緩沖定時單元超時兩個事件決定。發(fā)明人在研究現(xiàn)有技術和實踐中發(fā)現(xiàn)當本端發(fā)生或者檢測出AS狀態(tài)異常， SIGTRAN協(xié)議中目前還沒有設計相應的通知機制，從而可能存在兩端的AS狀態(tài)不一致且無 法恢復，導致兩端應用服務器業(yè)務數據不能正常發(fā)送。

發(fā)明內容
本發(fā)明要解決的問題是克服現(xiàn)有技術兩端的應用服務器狀態(tài)不一致且無法恢復 的缺陷，提供一種實現(xiàn)應用服務器狀態(tài)一致的方法和應用服務器，使得兩端應用服務器狀 態(tài)保持一致，保證兩端應用服務器業(yè)務數據能夠正常發(fā)送。為實現(xiàn)上述目的，本發(fā)明提供的技術方案是一種實現(xiàn)應用服務器狀態(tài)一致的方 法，包括步驟A)本端接收對端發(fā)過來的業(yè)務數據，然后檢測本端應用服務器是否處于激活狀 態(tài)；B)如果本端應用服務器狀態(tài)不是處于激活狀態(tài)，應用服務器進程按照協(xié)議規(guī)則發(fā) 起停止使用應用服務器進程請求消息給對端；C)本端應用服務器進程接收到對端發(fā)送過來的停止使用應用服務器進程請求消 息后，更新本地應用服務器進程狀態(tài)，并根據應用服務器進程狀態(tài)計算應用服務器的狀態(tài)。本發(fā)明實施例中，所述計算應用服務器的狀態(tài)之后還進一步包括步驟D)設置本地緩沖定時單元，在緩沖定時單元到時之前，如果本端是客戶端則不發(fā) 起新的SPSM/TM流程，如果本端是服務器端則不處理SPSM/TM消息。本發(fā)明實施例中，所述方法還進一步包括步驟E)緩沖定時單元到時，根據本地應用服務器進程狀態(tài)，計算當前應用服務器狀態(tài)， 按照協(xié)議規(guī)則繼續(xù)SPSM/TM流程。本發(fā)明實施例中，步驟B)中，如果本端屬性為客戶端，發(fā)起消息為停止使用應用 服務器進程消息；如果本端屬性為服務器端，發(fā)起消息為停止使用應用服務器進程響應消 肩、ο本發(fā)明實施例中，步驟C)中，如果本端是服務器端，則根據協(xié)議回應相應的消息； 服務器端的停止使用應用服務器進程響應消息通過流控制傳輸協(xié)議傳輸到應用服務器進 程客戶端，應用服務器進程客戶端從流控制傳輸協(xié)議收到停止使用應用服務器進程響應消 息后，根據協(xié)議進行處理并更新本地記錄的應用服務器進程狀態(tài)，然后根據應用服務器進 程狀態(tài)計算應用服務器的狀態(tài)。一種應用服務器，包括檢測單元，用于檢測本端應用服務器是否處于激活狀態(tài)；發(fā)送單元，與檢測單元連接，用于發(fā)送停止使用應用服務器進程請求消息給對 端；接收單元，用于接收對端發(fā)送過來的停止使用應用服務器進程請求消息；
計算單元，與接收單元連接，用于根據本地應用服務器進程狀態(tài)，計算應用服務器的狀態(tài)。本發(fā)明實施例中，所述應用服務器還進一步包括緩沖定時單元，分別與接收單元、發(fā)送單元、計算單元連接，用于設置一定緩沖時 間，在緩沖定時單元到時之前，如果本端是客戶端不發(fā)起新的ASPSM/TM流程，如果本端是 是服務器端不處理ASPSM/TM消息；緩沖定時單元到時，應用服務器根據本地應用服務器進 程狀態(tài)，計算當前應用服務器狀態(tài)，按照協(xié)議規(guī)則繼續(xù)ASPSM/TM流程。與現(xiàn)有技術相比，本發(fā)明實施例本端接收對端發(fā)過來的業(yè)務數據，然后檢測本端 應用服務器是否處于激活狀態(tài)；如果本端應用服務器狀態(tài)不是處于激活狀態(tài)，應用服務器 進程按照協(xié)議規(guī)則發(fā)起停止使用應用服務器進程請求消息給對端；對端在接收到停止使用 應用服務器進程請求消息后，更新本地應用服務器進程狀態(tài)，并根據應用服務器進程狀態(tài) 計算應用服務器的狀態(tài)，從而使對端和本端的AS狀態(tài)保持一致。通過本發(fā)明提供的方法和 應用服務器，解決了現(xiàn)有技術中AS狀態(tài)不一致而且無法恢復的問題，使得兩端AS狀態(tài)保持 一致，保證兩端應用服務器業(yè)務數據能夠正常發(fā)送。


圖1是SIGTRAN協(xié)議系統(tǒng)結構示意圖；圖2是SIGTRAN協(xié)議系統(tǒng)結構示意圖；圖3為應用服務器進程的狀態(tài)變化示意圖；圖4為應用服務器的狀態(tài)變化示意圖；圖5為本發(fā)明實施例提供的一種實現(xiàn)應用服務器狀態(tài)一致的方法流程圖；圖6為本發(fā)明實施例提供的一種應用服務器結構示意圖。
具體實施例方式下面通過具體的實施例并結合附圖對本發(fā)明作進一步詳細的描述。本發(fā)明的主要思想是建立一種信令流程機制，解決現(xiàn)有技術中AS狀態(tài)不一致而 且無法恢復的問題，使得兩端應用服務器狀態(tài)一致，保證兩端應用服務器業(yè)務數據能夠正 常發(fā)送。請參閱圖5所示，圖5為本發(fā)明實施例提供的一種實現(xiàn)應用服務器狀態(tài)一致的方 法流程圖，包括以下步驟步驟501 本端接收對端發(fā)過來的業(yè)務數據；步驟502 本端檢測本端應用服務器AS是否處于激活狀態(tài)；本實施例中，本端檢測本端應用服務器AS是否處于激活狀態(tài)的周期為連續(xù)檢測 100次。當然，也可以根據實際需要選擇其它值。步驟503 檢測到本端應用服務器AS狀態(tài)不是激活狀態(tài)，應用服務器進程ASP按 照協(xié)議規(guī)則發(fā)送ASPDown請求消息給對端；連續(xù)檢測到兩端AS狀態(tài)不一致的情況下，SP根據本端是客戶端或服務器端按照 協(xié)議規(guī)則發(fā)起相應的ASP Down流程。如果發(fā)起端ASP屬性為客戶端，ASPDown請求消息 為ASPDown消息；如果發(fā)起端ASP屬性為服務器端，ASPDown請求消息為ASPDownAck消息。ASPDown請求消息通過流控制傳輸協(xié)議SCTP傳輸到對端。步驟504 對端應用服務器進程ASP接收到ASPDown請求消息后，更新本地應用服 務器進程ASP狀態(tài)，并根據應用服務器進程ASP狀態(tài)計算應用服務器AS狀態(tài)；步驟505 如果對端是服務器端，則還需要根據協(xié)議回應ASPDown響應消息， ASPDown響應消息通過SCTP傳輸到ASP客戶端；步驟506 =ASP客戶端從SCTP收到ASPDown響應消息后，根據協(xié)議進行處理并更新 本地記錄的ASP狀態(tài)，然后根據ASP狀態(tài)計算AS狀態(tài)；步驟507 設置本地緩沖定時單元，在緩沖定時單元到時之前，如果本端是客戶端 則不發(fā)起新的SPSM/TM流程，如果本端是是服務器端則不處理SPSM/TM消息；本實施例中，進一步的，為了避免數據擁塞，保持數據的正常發(fā)送，還包括步驟步驟508 緩沖定時單元到時，根據本地應用服務器進程ASP狀態(tài)，計算當前應用 服務器AS狀態(tài)，按照協(xié)議規(guī)則繼續(xù)SPSM/TM流程。需要說明的是，本發(fā)明實施例中，一個應用服務器既可以是本端，也可以是對端， 本端和對端是相對而言的。通過以上實施例提供的方法，使兩端應用服務器狀態(tài)達到一致，保證兩端應用服 務器業(yè)務數據能夠正常發(fā)送。請參閱圖6所示，圖6為本發(fā)明實施例提供的一種應用服務器結構示意圖，包括檢測單元601，用于檢測本端應用服務器是否處于激活狀態(tài)；發(fā)送單元602，與檢測單元連接，用于發(fā)送停止使用應用服務器進程請求消息給對 端；如果應用服務器屬性為客戶端，ASPDown請求消息為ASPDown消息；如果應用服務 器屬性為服務器端，ASPDown請求消息為ASPDownAck消息。ASPDown請求消息通過流控制 傳輸協(xié)議SCTP傳輸到對端。接收單元603，用于接收對端發(fā)送過來的停止使用應用服務器進程請求消息；計算單元604，與接收單元連接，用于根據本地應用服務器進程狀態(tài)，計算應用服 務器的狀態(tài)；進一步的，本實施例中，為了避免數據擁塞，保持數據的正常發(fā)送，應用服務器還 包括緩沖定時單元605，分別與發(fā)送單元602、接收單元603、計算單元604連接，用于設 置一定緩沖時間，在緩沖定時單元到時之前，如果本端是客戶端不發(fā)起新的SPSM/TM流程， 如果本端是是服務器端不處理SPSM/TM消息；緩沖定時單元到時，應用服務器根據本地應 用服務器進程ASP狀態(tài)，計算當前應用服務器狀態(tài)，按照協(xié)議規(guī)則繼續(xù)SPSM/TM流程。通過本實施例提供的應用服務器連續(xù)周期性的檢測，使得本端和對端應用服務器 的狀態(tài)達到一致，保證兩端應用服務器業(yè)務數據能夠正常發(fā)送。綜上所述，本發(fā)明實施例提供了一種實現(xiàn)應用服務器狀態(tài)一致的方法，還提供了 一種應用服務器，通過本發(fā)明實施例公開的技術方案使SIGTRAN協(xié)議中兩端的應用服務器 狀態(tài)保持一致，保證兩端應用服務器業(yè)務數據能夠正常發(fā)送。以上內容是結合具體的優(yōu)選實施方式對本發(fā)明所作的進一步詳細說明，不能認定 本發(fā)明的具體實施只局限于這些說明。對于本發(fā)明所屬技術領域的普通技術人員來說，在
6不脫離本發(fā)明構思的前提下，還可以做出若干簡單推演或替換，都應當視為屬于本發(fā)明的 保護范圍。
權利要求
1.一種實現(xiàn)應用服務器狀態(tài)一致的方法，其特征在于，包括步驟A)本端接收對端發(fā)過來的業(yè)務數據，然后檢測本端應用服務器是否處于激活狀態(tài)；B)如果本端應用服務器狀態(tài)不是處于激活狀態(tài)，應用服務器進程按照協(xié)議規(guī)則發(fā)起停 止使用應用服務器進程請求消息給對端；以及C)本端應用服務器進程接收到對端發(fā)送過來的停止使用應用服務器進程請求消息后， 更新本地應用服務器進程狀態(tài)，并根據應用服務器進程狀態(tài)計算應用服務器的狀態(tài)。
2.根據權利要求1所述的方法，其特征在于，計算應用服務器的狀態(tài)之后還進一步包 括步驟D)設置本地緩沖定時單元，在緩沖定時單元到時之前，如果本端是客戶端則不發(fā)起新 的SPSM/TM流程，如果本端是服務器端則不處理SPSM/TM消息。
3.根據權利要求2所述的方法，其特征在于，還進一步包括步驟E)緩沖定時單元到時，根據本地應用服務器進程狀態(tài)，計算當前應用服務器狀態(tài)，按照 協(xié)議規(guī)則繼續(xù)SPSM/TM流程。
4.根據權利要求1所述的方法，其特征在于，步驟B)中，如果本端屬性為客戶端，發(fā)起 消息為停止使用應用服務器進程消息；如果本端屬性為服務器端，發(fā)起消息為停止使用應 用服務器進程響應消息。
5.根據權利要求4所述的方法，其特征在于，步驟C)中，如果本端是服務器端，則根據 協(xié)議回應相應的消息；服務器端的停止使用應用服務器進程響應消息通過流控制傳輸協(xié)議 傳輸到應用服務器進程客戶端，應用服務器進程客戶端從流控制傳輸協(xié)議收到停止使用應 用服務器進程響應消息后，根據協(xié)議進行處理并更新本地記錄的應用服務器進程狀態(tài)，然 后根據應用服務器進程狀態(tài)計算應用服務器的狀態(tài)。
6.根據權利要求1所述的方法，其特征在于，所述步驟A)中，檢測本端應用服務器是否 處于激活狀態(tài)的周期為連續(xù)檢測100次。
7.一種應用服務器，其特征在于，包括檢測單元，用于檢測本端應用服務器是否處于激活狀態(tài)；發(fā)送單元，與檢測單元連接，用于發(fā)送停止使用應用服務器進程請求消息給對端；接收單元，用于接收對端發(fā)送過來的停止使用應用服務器進程請求消息；計算單元，與接收單元連接，用于根據本地應用服務器進程狀態(tài)，計算應用服務器的狀態(tài)。
8.根據權利要求7所述的應用服務器，其特征在于，還進一步包括緩沖定時單元，分別與接收單元、發(fā)送單元、計算單元連接，用于設置一定緩沖時間，在 緩沖定時單元到時之前，如果本端是客戶端不發(fā)起新的ASPSM/TM流程，如果本端是是服務 器端不處理ASPSM/TM消息；緩沖定時單元到時，應用服務器根據本地應用服務器進程狀 態(tài)，計算當前應用服務器狀態(tài)，按照協(xié)議規(guī)則
全文摘要
本發(fā)明公開了一種實現(xiàn)應用服務器狀態(tài)一致的方法和應用服務器，其中方法包括步驟A)本端接收對端發(fā)過來的業(yè)務數據，然后檢測本端應用服務器是否處于激活狀態(tài)；B)如果本端應用服務器狀態(tài)不是處于激活狀態(tài)，應用服務器進程按照協(xié)議規(guī)則發(fā)起停止使用應用服務器進程請求消息給對端；以及C)本端應用服務器進程接收到對端發(fā)送過來的停止使用應用服務器進程請求消息后，更新本地應用服務器進程狀態(tài)，并根據應用服務器進程狀態(tài)計算應用服務器的狀態(tài)。通過本發(fā)明提供的方法和應用服務器，解決了現(xiàn)有技術中AS狀態(tài)存在不一致而且無法恢復的問題，使得兩端AS狀態(tài)保持一致，保證兩端應用服務器業(yè)務數據能夠正常發(fā)送。
文檔編號H04L29/06GK101997863SQ20091018972
公開日2011年3月30日 申請日期2009年8月24日 優(yōu)先權日2009年8月24日
發(fā)明者馬宏博 申請人:中興通訊股份有限公司