目錄
摘要
在使用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/
|