• <strike id="fdgpu"><input id="fdgpu"></input></strike>
    <label id="fdgpu"></label>
    <s id="fdgpu"><code id="fdgpu"></code></s>

  • <label id="fdgpu"></label>
  • <span id="fdgpu"><u id="fdgpu"></u></span>

    <s id="fdgpu"><sub id="fdgpu"></sub></s>
    首頁(yè)>>>技術(shù)>>>語(yǔ)音板卡  語(yǔ)音板卡產(chǎn)品
     
    借助Dialogic SS7板卡實(shí)現雙機箱系統容錯能力

    目錄

    摘要

      在使用Dialogic® NetStructure®SS7組件的SS7環(huán)境中,為了實(shí)現"5個(gè)9"的可用性和提高容錯能力,可以將一個(gè)SS7端結點(diǎn)擴展在兩個(gè)機箱上。通過(guò)將SS7節點(diǎn)部署于多個(gè)機箱之上可以將信令點(diǎn)的功能分離,進(jìn)而將多機箱內的硬件處理器相互獨立出來(lái),由此在一個(gè)處理器發(fā)生故障的情況下,另外一個(gè)處理器還能夠繼續工作,整個(gè)系統還可以正常運行。

      Dialogic網(wǎng)擎SS7組件就是專(zhuān)為這種雙處理器方法而設計的,它提供了一種可將一個(gè)點(diǎn)代碼分散到兩個(gè)主動(dòng)SS7協(xié)議引擎上的架構。使用這種技術(shù),只要在分離的兩個(gè)機箱中同時(shí)安裝Dialogic網(wǎng)擎SS7信令卡,一個(gè)SS7鏈路集內的鏈路就可以分散到這兩個(gè)機箱中處理。這種雙機箱方法可帶來(lái)高可用性和出色的容錯能力,本文將探討這種雙機箱方案的設計與實(shí)施。

    介紹

      因為公共電話(huà)網(wǎng)用戶(hù)對于服務(wù)可靠性的期望日益增高,因而設備生產(chǎn)商和系統集成商提出了高容錯能力和高可用性要求,即通常所說(shuō)的'五個(gè)9'可用性(要求系統在99.999%的時(shí)間都可以工作)。

      這種系統應在部分硬件或軟件發(fā)生故障時(shí),也能夠繼續提供服務(wù)。當通信網(wǎng)中的信令組件發(fā)生故障時(shí),有許多眾所周知的方法來(lái)保證系統繼續工作:

    • 到每個(gè)端結點(diǎn)建立多條信令通路(SS7鏈路和鏈路集)

    • 通過(guò)獨立的接口和電纜來(lái)分配這些信道

    • 將單個(gè)信令點(diǎn)的SS7終端處理分配到單個(gè)機箱內的多個(gè)處理板卡上進(jìn)行處理

    • 物理隔離和復制針對單個(gè)信令點(diǎn)的SS7接口(Dialogic® NetStructure®SIU和SS7板卡)

    • 在兩個(gè)機箱之間劃分信令點(diǎn)的功能,包括應用層(本文的主題)。

      上面所列的前3個(gè)方案可以通過(guò)在兩個(gè)相鄰的交互點(diǎn)之間部署多條鏈路(64或56Kbps)來(lái)實(shí)現(根據定義,這些鏈接將全部放在同一個(gè)鏈路集中)。最后兩個(gè)方案可以通過(guò)在兩個(gè)機箱內采用兩個(gè)獨立但互相協(xié)作的SS7協(xié)議棧來(lái)完成。這兩個(gè)機箱通常情況下是分開(kāi)的,但可以通過(guò)互連來(lái)提供更高的故障恢復能力。


    圖表(圖1)描述了雙容錯系統協(xié)議間的關(guān)系。

    多個(gè)機箱上部署一個(gè)SS7信令點(diǎn)

      在多個(gè)機箱上部署一個(gè)SS7信令點(diǎn),將正常的處理器與另一個(gè)故障的處理器隔離開(kāi),使整個(gè)系統在一個(gè)組件處理器或機箱完全故障的情況下可以繼續工作。與通用的故障恢復架構相同,有許多方法可以實(shí)現這種設置,每種方法均有其各自的優(yōu)缺點(diǎn)。

      Dialogic® NetStructure®SS7信令板卡采用一個(gè)2N通道并且能夠將點(diǎn)代碼分布在兩個(gè)主動(dòng)SS7協(xié)議引擎上。這樣就允許一個(gè)SS7鏈路集中的鏈路分布在兩個(gè)獨立的機箱中,并且每個(gè)機箱中都安裝了SS7信令卡。

      系統的兩部分之間需要提供兩條通信路徑,一條在MTP層,使用MTP2數據鏈路作為傳輸協(xié)議,另一條在第4層或User Part層,在兩部分的第4層協(xié)議之間傳送進(jìn)程間訊息。第二條通路通常通過(guò)使用Dialogic提供的TCP/IP Ethernet和RSI(容錯接口,Resilient Socket Interface)軟件來(lái)完成。這種組合提供了一個(gè)SS7接口,協(xié)議處理分散在兩個(gè)機箱中進(jìn)行。這兩個(gè)機箱在物理上是獨立,在網(wǎng)絡(luò )上卻像一個(gè)整體。

      同時(shí)還需要考慮維護狀態(tài)信息,并且檢測應用層的指示,這些內容在本文的后面部分討論。


    概念

    雙MTP3概念

      為了使運行在分散硬件上的雙MTP3處理能夠維護狀態(tài)信息并且(在某種路由狀態(tài)下)有選擇地交換發(fā)送訊息,需要在兩個(gè)系統之間建立一個(gè)特殊的鏈路集作為單點(diǎn)代碼進(jìn)行工作。圖2顯示了這樣一個(gè)系統的路由情況,包括兩部分,A和B,處于MTP3層。

      正常運行狀態(tài)下,可用的鏈路在MTP A和MTP B之間平均分配。MTP A從本地SS7協(xié)議的第4層(User part)接收到的訊息在與相鄰節點(diǎn)相連的鏈路上發(fā)送。同樣,MTP B接收到的訊息也從本身與相鄰節點(diǎn)的鏈路發(fā)送。

      當連接到MTP A或連接到 MTP B的所有鏈路均發(fā)生故障時(shí),訊息通過(guò)MTP A和MTP B之間的鏈路集發(fā)送到其它MTP,并由該MTP在可用的鏈路上重新發(fā)送。參見(jiàn)圖3。

      MTP A和MTP B之間的鏈路集的設置方法與任何其它SS7鏈路和鏈路集相同。如果有額外的數據設置表明此鏈路與其它連接相鄰節點(diǎn)的鏈路不同,則應區別對待。

      每個(gè)MTP接收的訊息總是傳送到'本地'第4層協(xié)議上。假設本地User Part總是可用的。

    MTP上的狀態(tài)機

      SS7協(xié)議的第4層為每一呼叫或事務(wù)處理維護狀態(tài)信息。有兩種可能的方法:一種方法是將狀態(tài)信息復制到組成信令點(diǎn)的N個(gè)系統中,第二種方法是分割數據,使每一半狀態(tài)數據存貯在系統的對應部分中,而這樣任何一個(gè)子架發(fā)生故障都會(huì )使系統容量減少1/N。

      第一種方法需要一個(gè)在容錯系統的N個(gè)組件間復制狀態(tài)數據的可靠方法。如果這N個(gè)系統使用大量CPU時(shí)鐘來(lái)同步,則這種方法效率非常低。

      因為復制過(guò)程中故障可能發(fā)生在任何點(diǎn),很難保證所有的系統都包含相同的數據,所以這里采用第二種(2N)方法。



    雙電話(huà)操作(基于CIC)

      一個(gè)SS7系統使用ISUP、TUP或其他國家電話(huà)第4層電路交換控制協(xié)議,可以通過(guò)分離兩個(gè)物理實(shí)體(可以是同一機箱中或兩個(gè)獨立機箱的兩套板卡)之間的電路終端(每個(gè)電路有OPC、DPC和CIC組合唯一標識)來(lái)實(shí)現容錯。盡管對于處理SS7和媒介的兩套板卡可以使用相同的方法,但下面的描述仍然討論兩個(gè)機箱的情況。

      一個(gè)雙ISUP/TUP系統通過(guò)激活每個(gè)機箱中的一半電路協(xié)議狀態(tài)機進(jìn)行工作。每個(gè)ISUP/TUP層通過(guò)本地MTP3發(fā)送所有的傳送流量。本地MTP3采用與相鄰S(chǎng)S7節點(diǎn)之間的本地鏈路進(jìn)行傳輸,如果該鏈路發(fā)生故障,則采用機箱之間的SS7鏈路。

      遠程SS7端結點(diǎn)不用與任何連接到任一機箱的SS7鏈路共享負荷;因此,不能保證一個(gè)機箱接收的訊息可以加載到連接于另一個(gè)機箱的電路上。為了解決這個(gè)問(wèn)題,ISUP/TUP層預檢測每個(gè)接收訊息中的CIC,以判斷設置中是否記錄了該電路。如果沒(méi)有,則將接收的訊息發(fā)送(象一個(gè)MTP3傳送指示)到負責處理未知電路訊息的任務(wù)中。在一個(gè)雙ISUP/TUP系統中,這個(gè)任務(wù)由第二個(gè)機箱中運行的第二套ISUP/TUP協(xié)議進(jìn)行處理。訊息被標記為由一個(gè)ISUP/TUP拒接的訊息。因此如果第二個(gè)ISUP/TUP協(xié)議不能識別電路,則這個(gè)訊息將作為來(lái)自未知電路的訊息依照ISUP/TUP協(xié)議來(lái)處理。因此在這種情況下,如果兩個(gè)系統都不識別該信息,就可以防止該信息在系統間不停的傳來(lái)傳去。

    此過(guò)程如圖4所示。


      
    盡管RSI和TCP/IP方法可能是最簡(jiǎn)單的,但是訊息本身通過(guò)一個(gè)依賴(lài)于應用程序的機制從一個(gè)系統傳送到另一個(gè)系統。

      SIU通過(guò)使用以太網(wǎng)從媒介處理中分離SS7接口來(lái)處理容錯問(wèn)題,兩個(gè)SIU作為一個(gè)點(diǎn)代碼進(jìn)行容錯,如圖5所示。通過(guò)分離SS7接口,SIU也允許系統最多可以由32個(gè)處理語(yǔ)音電路(媒介)的應用節點(diǎn)組成。

    雙SCCP問(wèn)題(子系統狀態(tài)管理)

      SCCP通過(guò)支持可尋址子系統概念提高了訊息傳遞部分(MTP)的路由能力。所有已知的本地和遠程子系統的路由可用性(允許狀態(tài)或禁止狀態(tài))在SCCP層中進(jìn)行管理。

      在一個(gè)由N個(gè)SCCP層(或多個(gè)SCCP例程)組成作為同一點(diǎn)代碼的系統中,用戶(hù)應用和遠程端結點(diǎn)需要能夠通過(guò)任何SCCP例程交換SCCP數據訊息,并且希望每個(gè)SCCP中的路由表都是相同的。為了達到這個(gè)目的,需要使用廣播機制增強SCCP層,這種機制將本地或遠程的路由狀態(tài)的任何改變發(fā)送到廣播任務(wù)。廣播任務(wù)負責將路由變化傳送到N-1(其它)SCCP例程。在一個(gè)雙系統中,廣播任務(wù)只是另一個(gè)SCCP層,這兩層使用基于訊息的API進(jìn)行通信。在一個(gè)雙機箱/子架環(huán)境中,這些訊息可以由RSI和TCP/IP以太網(wǎng)組合來(lái)傳遞。


      
    SCCP總是將接收指示傳遞給同一機箱的SCCP用戶(hù)任務(wù)。參見(jiàn)圖6。

    雙TCAP操作

      TCAP層的2N配置與2N ISUP/TUP協(xié)議的操作方法相同。系統管理的事務(wù)在兩個(gè)TCAP層之間平均分配,每個(gè)TCAP層管理一半事務(wù)的狀態(tài)和傳送組件。每個(gè)事務(wù)永遠只屬于一個(gè)TCAP。對于由本地TCAP用戶(hù)初始化的事務(wù),它屬于接收第一個(gè)用戶(hù)傳送數據要求的TCAP。對于由遠程TCAP實(shí)體初始化的事務(wù),此事務(wù)屬于從SCCP層接收第一個(gè)事務(wù)訊息的TCAP協(xié)議(BEGIN或QUERY)。因此,遠程初始化事務(wù)的負荷分擔由SS7網(wǎng)絡(luò )如何在連接系統兩部分的SS7鏈路之間分配第一個(gè)TCAP訊息(BEGIN或QUERY)來(lái)定義。

      為了允許快速識別每個(gè)接收訊息都擁有該事務(wù)狀態(tài)機的TCAP,在一個(gè)mN系統中,每個(gè)TCAP協(xié)議都擁有一個(gè)唯一的邏輯標識值或例程值(一個(gè)數字)。以原始事務(wù)id的方式為每一個(gè)發(fā)送訊息編號,并且在來(lái)自遠程TCAP實(shí)體的每一個(gè)目標事務(wù)id響應中加以反映。

      除了BEGIN或QUERY以外,所有TCAP層對于任何訊息的接收處理都是通過(guò)恢復事務(wù)id的例程bit開(kāi)始,由此來(lái)快速確定此訊息是否正在由正確的TCAP處理(該TCAP擁有針對此事務(wù)的激活的狀態(tài)機)。如果不是,訊息恢復操作退出,將此訊息傳遞給處理該例程訊息的模塊,如圖7所示。


    圖7 雙TCAP操作

      另一TCAP協(xié)議的模塊標識符使用TCP_MSG_S_TCI訊息進(jìn)行配置,此訊息使用兩個(gè)參數:TCAP instance和module_id。(此訊息將在附錄A中詳細介紹)。對于A(yíng)方,本地TCAP例程是0,遠程TCAP例程是1;因此,此訊息應該用來(lái)設置遠程TCAP的module_id,例程1的module_id為0x34。在B方,本地TCAP例程是1,TCP_MSG_S_TCI_ID訊息應該用來(lái)設置例程0(從B方視為遠程TCAP),其module_id為0x24。

      每個(gè)TCAP將所有接收的信息傳遞到同機箱中的TCAP用戶(hù)任務(wù)中。根據每一個(gè)TCAP中不同的應用層或用戶(hù),將TCAP層的本地應用程序發(fā)送的傳送會(huì )話(huà)和組件原語(yǔ)傳遞給正確的TCAP。在雙系統環(huán)境中,接收訊息可以在任何MTP和SCCP層上共享;因此,一個(gè)TCAP層接收由其它TCAP處理的應用在激活事務(wù)上的TCAP訊息是可能的。

    TCAP用戶(hù)(GSM-MAP、IS41-MAP、INAP)


      TCAP用戶(hù),如GSM-MAP、IS41和INAP等,與它們使用的TCAP層緊密地結合。在一個(gè)多TCAP系統中,TCAP用戶(hù)之間共享事務(wù),在雙TCAP系統中平均分配。在TCAP層完成了接受到的訊息針對相應TCAP狀態(tài)機的處理;因此,在TCAP用戶(hù)層不需要額外的處理。參見(jiàn)圖8。


    配置

      面向Linux V2.00和Windows V2.00的Dialogic開(kāi)發(fā)包支持雙機箱SS7系統配置,并且提供了設置雙系統操作MTP、ISUP、TUP和NUP層的必要命令和參數。SCCP、TCAP和TCAP-User層的配置與單(無(wú)容錯)系統的配置方式完全相同――使用離散的訊息,既可以將此功能嵌入用戶(hù)自己的程序中,也可以使用s7_play實(shí)體。

      在雙機箱系統中,為了配置的目的,應將兩個(gè)部分分開(kāi)對待,每個(gè)部分都有獨立的配置文件。

    MTP3的配置

      在雙MTP系統中,一個(gè)鏈路集內的鏈路應該在兩個(gè)系統間平均分配。兩部分的邏輯參考參數(如link_id和linkset_id)都應該從0開(kāi)始。系統每部分的鏈路和鏈路集都使用相同范圍的標識符(標記符/句柄)。

      需要使用一條額外的鏈路集來(lái)連接兩個(gè)MTP3平臺,以使單個(gè)點(diǎn)代碼可以在兩個(gè)平臺間共享。與標準SS7鏈路集的定義方式相同,使用MTP_LINKSET配置命令,并且使用相同的值(均設置為兩個(gè)平臺間共享的平臺點(diǎn)代碼的值)。這個(gè)鏈路集需要將參數的bit 15設置為1,表明此鏈路集連接兩個(gè)使用相同點(diǎn)代碼的MTP3協(xié)議。鏈路通過(guò)MTP_LINK命令添加到鏈路集。

      每一目標路由(包括相鄰節點(diǎn))都應該指明兩個(gè)鏈路集。主要的是連接本地MTP到相鄰節點(diǎn)的鏈路集的標識符。參數應該用來(lái)表示連接共享一個(gè)本地點(diǎn)代碼的兩個(gè)MTP3層的鏈路集。參數應該設為0x0001,表明第二個(gè)鏈路集已經(jīng)被指定,并且只有在通過(guò)主要鏈路集無(wú)法路由到目標節點(diǎn)的情況下,才可使用這個(gè)鏈路集來(lái)路由傳輸流量。所有其它參數的含義都與用戶(hù)手冊中描述的單MTP設置中的參數相同。


    對于MTP A:


    對于MTP B:


      
    注意:這些不包括任何設置或定義信令板卡的命令,應該象定義標準的非雙系統一樣定義。  MTP_ROUTE 參數針對ISUP而設置,在上例中用戶(hù)部分SI=5。


    對于MTP A:

    MTP_CONFIG 0 0 0x0000
    MTP_LINKSET 0 300 1 0x8000 300 0x8
    MTP_LINKSET 1 400 1 0x0000 300 0x8
    MTP_LINK 0 0 0 0 0 1 0 0 0x4006
    MTP_LINK 1 1 0 0 0 0 16 16 0x0006
    MTP_ROUTE 300 0 0x0020
    MTP_ROUTE 400 1 0x0020 0x0001 0
    MTP_ROUTE 600 1 0x0020 0x0001 0

    對于MTP B:
    MTP_CONFIG 0 0 0x0000
    MTP_LINKSET 0 300 1 0x8000 300 0x8
    MTP_LINKSET 1 500 1 0x0000 300 0x8
    MTP_LINK 0 0 0 0 0 1 0 0 0x6006
    MTP_LINK 1 1 0 1 0 0 16 16 0x0006
    MTP_ROUTE 300 0 0x0020
    MTP_ROUTE 500 1 0x0020 0x0001 0
    MTP_ROUTE 600 1 0x0020 0x0001 0

      連接兩個(gè)MTP3層的鏈路集應該提供足夠的鏈路,以帶來(lái)足夠的信令帶寬,從而允許一個(gè)MTP3的所有流量都可以通過(guò)第二個(gè)MTP3路由。設計者也應該注意,為了使每個(gè)MTP3可以傳送另一個(gè)MTP3的流量,系統的每一部分在正常工作情況下的負荷不應超過(guò)50%(所有的處理和信令通道帶寬)。SS7系統通常的最大負荷為20~40%。

      機箱間鏈路的激活方式必須同連接平臺和遠程SS7節點(diǎn)的其它鏈路的激活方式相同。這可以通過(guò)使用mtpsl工具或通過(guò)從應用程序傳送MTP鏈路或鏈路集激活命令訊息來(lái)實(shí)現。

    ISUP和TUP的配置

      對于ISUP,其它ISUP協(xié)議(其它系統中)的module_id通過(guò)設置ISUP_CONFIG命令中的可選參數來(lái)指定。應該設置ISUP_CONFIG的選項位ISPF_DUAL,表明ISUP應該將從MTP3接收的任何未知電路實(shí)體的訊息傳送到這個(gè)軟件任務(wù)。

      同樣,對于TUP,TUP_CONFIG的應該設置為第二個(gè)機箱中TUP模塊的module_id,并且設置TUPF_DUAL選項位。通常情況下ISUP的任務(wù)標識符設置為0x23。對于發(fā)送未知電路ISUP訊息的任務(wù),A方的標識符為0x73,B方的標識符為0x63。通常分配給TUP的任務(wù)標識符為0x4a。對于發(fā)送未知電路TUP訊息的任務(wù),A方的標識符為0x93,B方的標識符為0x83。用戶(hù)應該設置一個(gè)LOCAL任務(wù),以便將發(fā)送到這個(gè)任務(wù)的訊息傳送到另一個(gè)平臺上的ISUP或TUP協(xié)議層。這可以通過(guò)使用RSI任務(wù)和REDIRECTION命令(稍后介紹)來(lái)輕松實(shí)現。

    注:Dialogic® NetStructure®CPM8、SPCI2S或SPCI4板卡上運行ISUP和TUP。

      當ISUP或TUP協(xié)議在Dialogic網(wǎng)擎SS7板卡上運行時(shí),B方SEPTEL_CP命令的l1_flags參數必須設置為包括bit 9(0x0200)。

    下面的例子說(shuō)明了ISUP和TUP配置命令:

    A方
    * 配置ISUP模塊:
    * ISUP_CONFIG
    []
    ISUP_CONFIG 0 0 0 0x0435 4 64 0x73
    *
    * 設置TUP參數:
    * TUP_CONFIG
    []
    TUP_CONFIG 0 0 0 0x8141 4 64 0x93
    *

    B方
    * 配置ISUP模塊:
    * ISUP_CONFIG
    []
    ISUP_CONFIG 0 0 0 0x0435 4 64 0x63
    *
    * 設置TUP參數:
    * TUP_CONFIG
    []
    TUP_CONFIG 0 0 0 0x8141 4 64 0x83
    *

      兩個(gè)系統中的電路組既可以從0開(kāi)始編號,也可以?xún)蓚(gè)系統間隔標號。如果使用第一種方法,整個(gè)系統的容量就是單ISUP/TUP協(xié)議層系統容量的2倍;如果使用第二種方法,系統總容量與單ISUP/TUP協(xié)議層系統的容量相同。對于這兩種情況,每半部分控制獨立的CIC范圍,如圖11和12所示。



      
    系統兩部分之間沒(méi)有重復電路組("單容量"系統,如圖12所示)的系統在一部分故障的情況下能夠激活(配置)另一部分沒(méi)有使用的電路組。這個(gè)過(guò)程可以使用xxx_MSG_CNF_GRP訊息配置電路組來(lái)實(shí)現。由此可以為另一單元中失效的電路提供SS7信令資源以及ISUP或TUP狀態(tài)機。但是,如果電路終端本身仍然同故障單元物理上相連,那么信令能夠為這些電路實(shí)現的唯一進(jìn)程就是硬件阻塞。

    SCCP的配置

      在SCCP層,每個(gè)SCCP協(xié)議的配置都應該使用相同的本地子系統、遠程信令點(diǎn)和遠程子系統數據。

      smb_id配置參數用于識別狀態(tài)更新時(shí)的目標節點(diǎn),并且應該設置為一個(gè)任務(wù)的id。這個(gè)任務(wù)能夠在雙系統中將這一信息傳遞給其它SCCP模塊。在大多數情況下,SCCP使用0x33作為任務(wù)標識符,并且smb_id在A(yíng)方應該設置為0x53,在B方應該設置為0x43。可以使用system.txt文件中的一個(gè)REDIRECTION語(yǔ)句來(lái)將這些訊息路由到RSI或相似的任務(wù),以便將其傳遞到通過(guò)以太網(wǎng)連接的其它SCCP層。此外,SCCP smb_flags配置參數應設置為0x001c。

    TCAP的配置

      在一個(gè)多TCAP環(huán)境中,每一TCAP具有一個(gè)唯一的例程,它是在SCCP邊緣使用事務(wù)id編碼的,這樣可以為接收訊息快速分析正確的目標TCAP。第一個(gè)TCAP例程值通常應該為0,下一個(gè)為1。

      tid_ninst參數控制使用事務(wù)id中的多少位對例程數據進(jìn)行編碼。在一個(gè)雙系統中,1位就可以區分兩個(gè)TCAP。(注意tid_ndref必須足夠大,可以對最高的dialogue_id值進(jìn)行編碼。在一個(gè)同時(shí)支持2048個(gè)對話(huà)的系統中,tid_ndref的值必須大于等于11}。

      兩個(gè)TCAP部分的邏輯dialogue_id的范圍可以相同(這樣運行在這兩個(gè)系統上的兩個(gè)應用進(jìn)程將在相同的dialogue_id范圍內工作),也可以使用不同的范圍。

    機箱間的通信

      容錯接口(RSI)軟件從它的輸入隊列中獲取具有目標節點(diǎn)的訊息,而不獲取RSI本身的訊息,并且將這些訊息發(fā)送給TCP/IP以太網(wǎng)遠程端的同等RSI任務(wù)。通信采用TCP/IP套接字,一端作為服務(wù)器,另一端作為客戶(hù)端。

      在接收端,RSI獲取從以太網(wǎng)接收的訊息,并且將它們通過(guò)本地訊息傳輸系統傳遞到原始訊息目標所標識的任務(wù)中(幀頭dst字段)。如果兩個(gè)RSI任務(wù)通過(guò)以太網(wǎng)進(jìn)行的通信發(fā)生故障,傳遞到RSI通過(guò)以太網(wǎng)進(jìn)行發(fā)送的訊息將被丟棄。

      系統中運行的兩個(gè)RSI任務(wù)(每半個(gè)系統一個(gè))使用相同的唯一的模塊id,通常為0xb0。這必須在帶有LOCAL定義的兩個(gè)系統的system.txt文件中加以聲明,使用FORK_PROCESS命令開(kāi)始。RSI程序將其模塊id作為可選的命令行參數,前綴為'-m'。例如:

      ./rsi -m0xb0

      任何發(fā)送到使用指定模塊id的RSI的訊息都會(huì )由本地RSI任務(wù)進(jìn)行處理,并且不會(huì )通過(guò)以太網(wǎng)傳輸。

      主機與每個(gè)從機間的RSI連接使用rsicmd工具激活。rsicmd工具的用法如下:

    rsicmd []

      是這個(gè)特殊信道的邏輯標識符。RSI通過(guò)匹配訊息例程值(由GCT_set_instance設置,缺省值為0)和link_id值來(lái)選擇輸出通道。對于大多數的雙系統,兩個(gè)系統之間建立一條RSI連接就足夠了,因此這個(gè)參數應該設為0。

      指定一個(gè)模塊id,當指定的RSI連接失效時(shí),此模塊id將收到通知(一個(gè)訊息)。這個(gè)參數的設置可以將這些指示傳遞給應用任務(wù)或者本地管理事件查看程序,如s7_log等。

      應該依據下表進(jìn)行設置:

    連接類(lèi)型 rem_addr ink_type值
    服務(wù)器 B方的IP地址 0(客戶(hù)端)
    客戶(hù)端 0 1(服務(wù)器)

      系統的一端需要設置為客戶(hù)端,另一端設置為服務(wù)器。

      指定了連接所使用的TCP/IP套接字端口號。每個(gè)RSI連接(應該具有唯一的link_id)必須使用唯一的端口號,從9000開(kāi)始。

      是可選的,指定了傳送訊息的RSI模塊。

      對于所有可以通過(guò)RSI連接(與系統另半部分相連)訪(fǎng)問(wèn)的目標節點(diǎn),system.txt文件中必須插入一條REDIRECT語(yǔ)句(第二個(gè)ISUP、TUP、SCCP和/或TCAP協(xié)議的module_id值)。

      例如,一個(gè)雙ISUP系統應該由兩個(gè)ISUP部分組成,每部分缺省module_id都為0x23。A方ISUP的配置數據表示另一個(gè)ISUP部分的module_id為0x73;因此,在A(yíng)方將會(huì )有一個(gè)重定向的動(dòng)作來(lái)對經(jīng)過(guò)RSI發(fā)送往0x73的任何訊息重新定向。在B方,應該有一個(gè)REDIRECT語(yǔ)句將B方RSI所接收的所有目標為0x73的訊息路由到本地ISUP,標識為0x23。具體情況如圖13所示。



      
    運行在信令卡上的協(xié)議模塊,接收端(對方)的REDIRECT語(yǔ)句應該通過(guò)ssd或ssds驅動(dòng)(通常情況下module_id為0x20)來(lái)對訊息進(jìn)行重定向,如圖14所示。

    下表給出了系統雙方都應該使用的module_id值。
    模塊 A方設置 B方設置
    本地ISUP 0x23 0x23
    對方ISUP 0x73 0x63
    本地TUP 0x4a 0x4a
    對方TUP 0x93 0x83
    本地SCCP 0x33 0x33
    對方SCCP 0x53 0x43
    本地TCAP 0x14 0x14
    對方TCAP 0x34 0x24
    本地MAP 0x15 0x15
    本地IS41 0x25 0x25
    本地INAP 0x35 0x35

    對于容錯應用的考慮

      在一個(gè)SS7接口中嵌有應用的雙系統中,應用或者SS7組件故障將導致該部分系統完全癱瘓。

      在一個(gè)雙電路交換應用(使用ISUP或TUP)中,物理電路終端分布在組成系統的兩個(gè)機箱中,因此如果系統的一部分發(fā)生故障,將導致一部分電路的物理故障。在SS7終端,硬件故障通常通過(guò)發(fā)送硬件阻塞(也稱(chēng)為硬件隔離)來(lái)處理。這樣所有受這部分硬件影響的當前呼叫都會(huì )被拆除,表示這些電路不能被選擇用于呼叫,直到硬件隔離解除。如果電路故障恢復,則硬件隔離即會(huì )被解除。

      但是,在前面所述的配置中,系統繼續工作的部分對于故障電路一無(wú)所知(這部分配置數據保存在故障的部分中),因此不能發(fā)送硬件隔離命令。解決這個(gè)問(wèn)題的一個(gè)辦法就是配置電路組,這樣可以為另一部分的電路組保留空間。當一個(gè)電路組發(fā)生故障時(shí),這些備份的電路組可以由繼續工作的部分進(jìn)行配置,允許向與故障機箱物理連接的電路發(fā)送硬件隔離命令。

      也可以采用物理上隔離應用媒介/電路處理和SS7協(xié)議狀態(tài)信息,使兩個(gè)應用程序可以利用兩個(gè)SS7接口進(jìn)行通信(SIU采用這種方法)。物理隔離可以采用RSI和以太網(wǎng)來(lái)實(shí)現。

      如果需要,應用可以通過(guò)使用基于訊息的API和RSI/以太網(wǎng)進(jìn)行通信,來(lái)在節點(diǎn)間進(jìn)行互相檢查以檢測故障。定義用戶(hù)具體信息必須出于這個(gè)目的。

      在一個(gè)雙TCAP系統中,系統的一部分故障會(huì )導致TCAP狀態(tài)信息的丟失(例如,事務(wù)狀態(tài)和任何尚待傳輸的存儲部件)。在智能網(wǎng)絡(luò )環(huán)境中,如果可能,此事務(wù)相關(guān)的呼叫將被拆除。在移動(dòng)/無(wú)線(xiàn)環(huán)境中,任何相關(guān)的掛起的移動(dòng)服務(wù)(例如短訊息)都可能超時(shí),操作將報告為出現故障。這些操作應該在系統繼續工作的部分中再次執行。

      與SS7協(xié)議進(jìn)行通信的應用必須在邏輯電路id和每個(gè)SS7預先配置的會(huì )話(huà)id范圍內工作。系統的兩部分既可以使用相同范圍值,這些值只在每部分內部使用,也可以在不同的范圍內運行。

    設置System.txt值

      下圖展示了一個(gè)雙ISUP/TUP/SCCP/TCAP系統中各模塊之間的關(guān)系,以及系統兩部分的config.txt文件中的相應條目。參見(jiàn)圖15。


    主機協(xié)議的System.txt

    A方
    REDIRECT 0x34 0xb0 * TCAP to chassis B
    REDIRECT 0x53 0xb0 * SCCP to chassis B
    REDIRECT 0x73 0xb0 * ISUP to chassis B
    REDIRECT 0x93 0xb0 * TUP to chassis B
    *
    REDIRECT 0x24 0x14 * TCAP from chassis B
    REDIRECT 0x43 0x33 * SCCP from chassis B
    REDIRECT 0x63 0x23 * ISUP from chassis B
    REDIRECT 0x83 0x4a * TUP from chassis B

    B方
    REDIRECT 0x24 0xb0 * TCAP to chassis A
    REDIRECT 0x43 0xb0 * SCCP to chassis A
    REDIRECT 0x63 0xb0 * ISUP to chassis A
    REDIRECT 0x83 0xb0 * TUP to chassis A
    *
    REDIRECT 0x34 0x14 * TCAP from chassis A
    REDIRECT 0x53 0x33 * SCCP from chassis A
    REDIRECT 0x73 0x23 * ISUP from chassis A
    REDIRECT 0x93 0x4a * TUP from chassis A

      system.txt文件必須也包括主機上運行的所有本地SS7協(xié)議,如ISUP、TUP、SCCP或TCAP(如果有),以及應用程序任務(wù)、配置工具(如s7_mgt)和調試工具的LOCAL定義。這里也應該通過(guò)FORK_PROCESS語(yǔ)句來(lái)啟動(dòng)相應的驅動(dòng)和支持任務(wù),在相應的程序員手冊中有詳細描述。

    信令處理器板卡協(xié)議的System.txt

    A方
    REDIRECT 0x34 0xb0 * TCAP to chassis B
    REDIRECT 0x53 0xb0 * SCCP to chassis B
    REDIRECT 0x73 0xb0 * ISUP to chassis B
    REDIRECT 0x93 0xb0 * TUP to chassis B
    *
    REDIRECT 0x24 0x20 * TCAP from chassis B through ssd
    REDIRECT 0x43 0x20 * SCCP from chassis B through ssd
    REDIRECT 0x63 0x20 * ISUP from chassis B through ssd
    REDIRECT 0x83 0x20 * TUP from chassis B through ssd

    B方
    REDIRECT 0x24 0xb0 * TCAP to chassis A
    REDIRECT 0x43 0xb0 * SCCP to chassis A
    REDIRECT 0x63 0xb0 * ISUP to chassis A
    REDIRECT 0x83 0xb0 * TUP to chassis A
    *
    REDIRECT 0x34 0x20 * TCAP from chassis A through ssd
    REDIRECT 0x53 0x20 * SCCP from chassis A through ssd
    REDIRECT 0x73 0x20 * ISUP from chassis A through ssd
    REDIRECT 0x93 0x20 * TUP from chassis A through ssd

      system.txt文件也必須包括所有應用程序任務(wù)、配置工具(如s7_mgt)和調試工具的LOCAL定義。這里也應該通過(guò)FORK_PROCESS語(yǔ)句來(lái)啟動(dòng)相應的驅動(dòng)和支持任務(wù),在相應的程序員手冊中有詳細描述。

    附錄A:TCAP設置例程模塊ID訊息

    說(shuō)明:

      這個(gè)訊息為一個(gè)指定的TCAP例程設置module_id。當發(fā)送任何來(lái)自網(wǎng)絡(luò )上的帶有事務(wù)id中指定例程的訊息時(shí),TCAP使用這個(gè)module_id作為目標節點(diǎn)。

    訊息格式:

    訊息標頭  
    字段名稱(chēng) 含義
    類(lèi)型 TCP_MSG_S_TCI_ID (0x5794)
    Id Instance
    src 發(fā)送module_id
    dst TCP_TASK_ID(0x14)
    rsp_req 用于請求確認
    class 0
    status 0
    err_info 0
    len 1

    參數域

    偏移量 大小 名稱(chēng)
    0 1 module_id


    參數描述:
    Instance
      應該發(fā)送至指定module_id的任何接收訊息的事務(wù)ID中設置的例程值。
    module_id
      對于指定例程,module_id用作TCAP發(fā)送訊息的目標。

    如欲了解更多信息,請訪(fǎng)問(wèn):http://www.Dialogic.com/

    融合通信專(zhuān)欄>>應用>>



    相關(guān)鏈接:
    鼎銘語(yǔ)音卡成功打造蘭州自來(lái)水客服中心 2005-07-19
    TMS-FZY錄音系統閃亮登場(chǎng) 2005-07-18
    Ai-Logix公司助力中國錄音市場(chǎng) 推出特價(jià)開(kāi)發(fā)包 2005-07-18
    Intel® NetStructure® 主機媒體處理軟件 2005-07-11
    GVOS 8.2 SP1 (ADL)& CT ADE 結構 2005-07-07

    相關(guān)頻道:  電信_與_語(yǔ)音板卡  電信_與_語(yǔ)音板卡  電信_與_信令  語(yǔ)音板卡_與_信令
               語(yǔ)音板卡_與_信令

    亚洲精品网站在线观看不卡无广告,国产a不卡片精品免费观看,欧美亚洲一区二区三区在线,国产一区二区三区日韩 千阳县| 沐川县| 东乌| 双辽市| 丰县| 宜宾市| 两当县| 南京市| 大足县| 富平县| 贵德县| 麦盖提县| 阿拉善盟| 大洼县| 抚州市| 泰来县| 邯郸县| 酒泉市| 武隆县| 青岛市| 香格里拉县| 诸暨市| 咸阳市| 峡江县| 澜沧| 凌云县| 建宁县| 文水县| 浦城县| 博白县| 肇源县| 栖霞市| 婺源县| 宝兴县| 阿坝县| 洪湖市| 修水县| 枣阳市| 临猗县| 阳泉市| 观塘区| http://444 http://444 http://444 http://444 http://444 http://444