目錄
摘要
在使用Dialogic® NetStructure®SS7組件的SS7環(huán)境中,為了實現(xiàn)"5個9"的可用性和提高容錯能力,可以將一個SS7端結(jié)點擴展在兩個機箱上。通過將SS7節(jié)點部署于多個機箱之上可以將信令點的功能分離,進而將多機箱內(nèi)的硬件處理器相互獨立出來,由此在一個處理器發(fā)生故障的情況下,另外一個處理器還能夠繼續(xù)工作,整個系統(tǒng)還可以正常運行。
Dialogic網(wǎng)擎SS7組件就是專為這種雙處理器方法而設計的,它提供了一種可將一個點代碼分散到兩個主動SS7協(xié)議引擎上的架構。使用這種技術,只要在分離的兩個機箱中同時安裝Dialogic網(wǎng)擎SS7信令卡,一個SS7鏈路集內(nèi)的鏈路就可以分散到這兩個機箱中處理。這種雙機箱方法可帶來高可用性和出色的容錯能力,本文將探討這種雙機箱方案的設計與實施。
介紹
因為公共電話網(wǎng)用戶對于服務可靠性的期望日益增高,因而設備生產(chǎn)商和系統(tǒng)集成商提出了高容錯能力和高可用性要求,即通常所說的'五個9'可用性(要求系統(tǒng)在99.999%的時間都可以工作)。
這種系統(tǒng)應在部分硬件或軟件發(fā)生故障時,也能夠繼續(xù)提供服務。當通信網(wǎng)中的信令組件發(fā)生故障時,有許多眾所周知的方法來保證系統(tǒng)繼續(xù)工作:
- 到每個端結(jié)點建立多條信令通路(SS7鏈路和鏈路集)
- 通過獨立的接口和電纜來分配這些信道
- 將單個信令點的SS7終端處理分配到單個機箱內(nèi)的多個處理板卡上進行處理
- 物理隔離和復制針對單個信令點的SS7接口(Dialogic® NetStructure®SIU和SS7板卡)
- 在兩個機箱之間劃分信令點的功能,包括應用層(本文的主題)。
上面所列的前3個方案可以通過在兩個相鄰的交互點之間部署多條鏈路(64或56Kbps)來實現(xiàn)(根據(jù)定義,這些鏈接將全部放在同一個鏈路集中)。最后兩個方案可以通過在兩個機箱內(nèi)采用兩個獨立但互相協(xié)作的SS7協(xié)議棧來完成。這兩個機箱通常情況下是分開的,但可以通過互連來提供更高的故障恢復能力。
圖表(圖1)描述了雙容錯系統(tǒng)協(xié)議間的關系。
多個機箱上部署一個SS7信令點
在多個機箱上部署一個SS7信令點,將正常的處理器與另一個故障的處理器隔離開,使整個系統(tǒng)在一個組件處理器或機箱完全故障的情況下可以繼續(xù)工作。與通用的故障恢復架構相同,有許多方法可以實現(xiàn)這種設置,每種方法均有其各自的優(yōu)缺點。
Dialogic® NetStructure®SS7信令板卡采用一個2N通道并且能夠?qū)Ⅻc代碼分布在兩個主動SS7協(xié)議引擎上。這樣就允許一個SS7鏈路集中的鏈路分布在兩個獨立的機箱中,并且每個機箱中都安裝了SS7信令卡。
系統(tǒng)的兩部分之間需要提供兩條通信路徑,一條在MTP層,使用MTP2數(shù)據(jù)鏈路作為傳輸協(xié)議,另一條在第4層或User
Part層,在兩部分的第4層協(xié)議之間傳送進程間訊息。第二條通路通常通過使用Dialogic提供的TCP/IP
Ethernet和RSI(容錯接口,Resilient Socket Interface)軟件來完成。這種組合提供了一個SS7接口,協(xié)議處理分散在兩個機箱中進行。這兩個機箱在物理上是獨立,在網(wǎng)絡上卻像一個整體。
同時還需要考慮維護狀態(tài)信息,并且檢測應用層的指示,這些內(nèi)容在本文的后面部分討論。
概念
雙MTP3概念
為了使運行在分散硬件上的雙MTP3處理能夠維護狀態(tài)信息并且(在某種路由狀態(tài)下)有選擇地交換發(fā)送訊息,需要在兩個系統(tǒng)之間建立一個特殊的鏈路集作為單點代碼進行工作。圖2顯示了這樣一個系統(tǒng)的路由情況,包括兩部分,A和B,處于MTP3層。
正常運行狀態(tài)下,可用的鏈路在MTP A和MTP B之間平均分配。MTP A從本地SS7協(xié)議的第4層(User
part)接收到的訊息在與相鄰節(jié)點相連的鏈路上發(fā)送。同樣,MTP B接收到的訊息也從本身與相鄰節(jié)點的鏈路發(fā)送。
當連接到MTP A或連接到 MTP B的所有鏈路均發(fā)生故障時,訊息通過MTP A和MTP
B之間的鏈路集發(fā)送到其它MTP,并由該MTP在可用的鏈路上重新發(fā)送。參見圖3。
MTP A和MTP B之間的鏈路集的設置方法與任何其它SS7鏈路和鏈路集相同。如果有額外的數(shù)據(jù)設置表明此鏈路與其它連接相鄰節(jié)點的鏈路不同,則應區(qū)別對待。
每個MTP接收的訊息總是傳送到'本地'第4層協(xié)議上。假設本地User Part總是可用的。
MTP上的狀態(tài)機
SS7協(xié)議的第4層為每一呼叫或事務處理維護狀態(tài)信息。有兩種可能的方法:一種方法是將狀態(tài)信息復制到組成信令點的N個系統(tǒng)中,第二種方法是分割數(shù)據(jù),使每一半狀態(tài)數(shù)據(jù)存貯在系統(tǒng)的對應部分中,而這樣任何一個子架發(fā)生故障都會使系統(tǒng)容量減少1/N。
第一種方法需要一個在容錯系統(tǒng)的N個組件間復制狀態(tài)數(shù)據(jù)的可靠方法。如果這N個系統(tǒng)使用大量CPU時鐘來同步,則這種方法效率非常低。
因為復制過程中故障可能發(fā)生在任何點,很難保證所有的系統(tǒng)都包含相同的數(shù)據(jù),所以這里采用第二種(2N)方法。
雙電話操作(基于CIC)
一個SS7系統(tǒng)使用ISUP、TUP或其他國家電話第4層電路交換控制協(xié)議,可以通過分離兩個物理實體(可以是同一機箱中或兩個獨立機箱的兩套板卡)之間的電路終端(每個電路有OPC、DPC和CIC組合唯一標識)來實現(xiàn)容錯。盡管對于處理SS7和媒介的兩套板卡可以使用相同的方法,但下面的描述仍然討論兩個機箱的情況。
一個雙ISUP/TUP系統(tǒng)通過激活每個機箱中的一半電路協(xié)議狀態(tài)機進行工作。每個ISUP/TUP層通過本地MTP3發(fā)送所有的傳送流量。本地MTP3采用與相鄰SS7節(jié)點之間的本地鏈路進行傳輸,如果該鏈路發(fā)生故障,則采用機箱之間的SS7鏈路。
遠程SS7端結(jié)點不用與任何連接到任一機箱的SS7鏈路共享負荷;因此,不能保證一個機箱接收的訊息可以加載到連接于另一個機箱的電路上。為了解決這個問題,ISUP/TUP層預檢測每個接收訊息中的CIC,以判斷設置中是否記錄了該電路。如果沒有,則將接收的訊息發(fā)送(象一個MTP3傳送指示)到負責處理未知電路訊息的任務中。在一個雙ISUP/TUP系統(tǒng)中,這個任務由第二個機箱中運行的第二套ISUP/TUP協(xié)議進行處理。訊息被標記為由一個ISUP/TUP拒接的訊息。因此如果第二個ISUP/TUP協(xié)議不能識別電路,則這個訊息將作為來自未知電路的訊息依照ISUP/TUP協(xié)議來處理。因此在這種情況下,如果兩個系統(tǒng)都不識別該信息,就可以防止該信息在系統(tǒng)間不停的傳來傳去。
此過程如圖4所示。
盡管RSI和TCP/IP方法可能是最簡單的,但是訊息本身通過一個依賴于應用程序的機制從一個系統(tǒng)傳送到另一個系統(tǒng)。
SIU通過使用以太網(wǎng)從媒介處理中分離SS7接口來處理容錯問題,兩個SIU作為一個點代碼進行容錯,如圖5所示。通過分離SS7接口,SIU也允許系統(tǒng)最多可以由32個處理語音電路(媒介)的應用節(jié)點組成。
雙SCCP問題(子系統(tǒng)狀態(tài)管理)
SCCP通過支持可尋址子系統(tǒng)概念提高了訊息傳遞部分(MTP)的路由能力。所有已知的本地和遠程子系統(tǒng)的路由可用性(允許狀態(tài)或禁止狀態(tài))在SCCP層中進行管理。
在一個由N個SCCP層(或多個SCCP例程)組成作為同一點代碼的系統(tǒng)中,用戶應用和遠程端結(jié)點需要能夠通過任何SCCP例程交換SCCP數(shù)據(jù)訊息,并且希望每個SCCP中的路由表都是相同的。為了達到這個目的,需要使用廣播機制增強SCCP層,這種機制將本地或遠程的路由狀態(tài)的任何改變發(fā)送到廣播任務。廣播任務負責將路由變化傳送到N-1(其它)SCCP例程。在一個雙系統(tǒng)中,廣播任務只是另一個SCCP層,這兩層使用基于訊息的API進行通信。在一個雙機箱/子架環(huán)境中,這些訊息可以由RSI和TCP/IP以太網(wǎng)組合來傳遞。
SCCP總是將接收指示傳遞給同一機箱的SCCP用戶任務。參見圖6。
雙TCAP操作
TCAP層的2N配置與2N ISUP/TUP協(xié)議的操作方法相同。系統(tǒng)管理的事務在兩個TCAP層之間平均分配,每個TCAP層管理一半事務的狀態(tài)和傳送組件。每個事務永遠只屬于一個TCAP。對于由本地TCAP用戶初始化的事務,它屬于接收第一個用戶傳送數(shù)據(jù)要求的TCAP。對于由遠程TCAP實體初始化的事務,此事務屬于從SCCP層接收第一個事務訊息的TCAP協(xié)議(BEGIN或QUERY)。因此,遠程初始化事務的負荷分擔由SS7網(wǎng)絡如何在連接系統(tǒng)兩部分的SS7鏈路之間分配第一個TCAP訊息(BEGIN或QUERY)來定義。
為了允許快速識別每個接收訊息都擁有該事務狀態(tài)機的TCAP,在一個mN系統(tǒng)中,每個TCAP協(xié)議都擁有一個唯一的邏輯標識值或例程值(一個數(shù)字)。以原始事務id的方式為每一個發(fā)送訊息編號,并且在來自遠程TCAP實體的每一個目標事務id響應中加以反映。
除了BEGIN或QUERY以外,所有TCAP層對于任何訊息的接收處理都是通過恢復事務id的例程bit開始,由此來快速確定此訊息是否正在由正確的TCAP處理(該TCAP擁有針對此事務的激活的狀態(tài)機)。如果不是,訊息恢復操作退出,將此訊息傳遞給處理該例程訊息的模塊,如圖7所示。
圖7 雙TCAP操作
另一TCAP協(xié)議的模塊標識符使用TCP_MSG_S_TCI訊息進行配置,此訊息使用兩個參數(shù):TCAP
instance和module_id。(此訊息將在附錄A中詳細介紹)。對于A方,本地TCAP例程是0,遠程TCAP例程是1;因此,此訊息應該用來設置遠程TCAP的module_id,例程1的module_id為0x34。在B方,本地TCAP例程是1,TCP_MSG_S_TCI_ID訊息應該用來設置例程0(從B方視為遠程TCAP),其module_id為0x24。
每個TCAP將所有接收的信息傳遞到同機箱中的TCAP用戶任務中。根據(jù)每一個TCAP中不同的應用層或用戶,將TCAP層的本地應用程序發(fā)送的傳送會話和組件原語傳遞給正確的TCAP。在雙系統(tǒng)環(huán)境中,接收訊息可以在任何MTP和SCCP層上共享;因此,一個TCAP層接收由其它TCAP處理的應用在激活事務上的TCAP訊息是可能的。
TCAP用戶(GSM-MAP、IS41-MAP、INAP)
TCAP用戶,如GSM-MAP、IS41和INAP等,與它們使用的TCAP層緊密地結(jié)合。在一個多TCAP系統(tǒng)中,TCAP用戶之間共享事務,在雙TCAP系統(tǒng)中平均分配。在TCAP層完成了接受到的訊息針對相應TCAP狀態(tài)機的處理;因此,在TCAP用戶層不需要額外的處理。參見圖8。
配置
面向Linux V2.00和Windows V2.00的Dialogic開發(fā)包支持雙機箱SS7系統(tǒng)配置,并且提供了設置雙系統(tǒng)操作MTP、ISUP、TUP和NUP層的必要命令和參數(shù)。SCCP、TCAP和TCAP-User層的配置與單(無容錯)系統(tǒng)的配置方式完全相同――使用離散的訊息,既可以將此功能嵌入用戶自己的程序中,也可以使用s7_play實體。
在雙機箱系統(tǒng)中,為了配置的目的,應將兩個部分分開對待,每個部分都有獨立的配置文件。
MTP3的配置
在雙MTP系統(tǒng)中,一個鏈路集內(nèi)的鏈路應該在兩個系統(tǒng)間平均分配。兩部分的邏輯參考參數(shù)(如link_id和linkset_id)都應該從0開始。系統(tǒng)每部分的鏈路和鏈路集都使用相同范圍的標識符(標記符/句柄)。
需要使用一條額外的鏈路集來連接兩個MTP3平臺,以使單個點代碼可以在兩個平臺間共享。與標準SS7鏈路集的定義方式相同,使用MTP_LINKSET配置命令,并且 和使用相同的值(均設置為兩個平臺間共享的平臺點代碼的值)。這個鏈路集需要將參數(shù)的bit
15設置為1,表明此鏈路集連接兩個使用相同點代碼的MTP3協(xié)議。鏈路通過MTP_LINK命令添加到鏈路集。
每一目標路由(包括相鄰節(jié)點)都應該指明兩個鏈路集。主要的是連接本地MTP到相鄰節(jié)點的鏈路集的標識符。參數(shù)應該用來表示連接共享一個本地點代碼的兩個MTP3層的鏈路集。參數(shù)應該設為0x0001,表明第二個鏈路集已經(jīng)被指定,并且只有在通過主要鏈路集無法路由到目標節(jié)點的情況下,才可使用這個鏈路集來路由傳輸流量。所有其它參數(shù)的含義都與用戶手冊中描述的單MTP設置中的參數(shù)相同。
對于MTP A:
對于MTP B:
注意:這些不包括任何設置或定義信令板卡的命令,應該象定義標準的非雙系統(tǒng)一樣定義! TP_ROUTE
參數(shù)針對ISUP而設置,在上例中用戶部分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
連接兩個MTP3層的鏈路集應該提供足夠的鏈路,以帶來足夠的信令帶寬,從而允許一個MTP3的所有流量都可以通過第二個MTP3路由。設計者也應該注意,為了使每個MTP3可以傳送另一個MTP3的流量,系統(tǒng)的每一部分在正常工作情況下的負荷不應超過50%(所有的處理和信令通道帶寬)。SS7系統(tǒng)通常的最大負荷為20~40%。
機箱間鏈路的激活方式必須同連接平臺和遠程SS7節(jié)點的其它鏈路的激活方式相同。這可以通過使用mtpsl工具或通過從應用程序傳送MTP鏈路或鏈路集激活命令訊息來實現(xiàn)。
ISUP和TUP的配置
對于ISUP,其它ISUP協(xié)議(其它系統(tǒng)中)的module_id通過設置ISUP_CONFIG命令中的可選 參數(shù)來指定。應該設置ISUP_CONFIG的選項位ISPF_DUAL,表明ISUP應該將從MTP3接收的任何未知電路實體的訊息傳送到這個軟件任務。
同樣,對于TUP,TUP_CONFIG的應該設置為第二個機箱中TUP模塊的module_id,并且設置TUPF_DUAL選項位。通常情況下ISUP的任務標識符設置為0x23。對于發(fā)送未知電路ISUP訊息的任務,A方的標識符為0x73,B方的標識符為0x63。通常分配給TUP的任務標識符為0x4a。對于發(fā)送未知電路TUP訊息的任務,A方的標識符為0x93,B方的標識符為0x83。用戶應該設置一個LOCAL任務,以便將發(fā)送到這個任務的訊息傳送到另一個平臺上的ISUP或TUP協(xié)議層。這可以通過使用RSI任務和REDIRECTION命令(稍后介紹)來輕松實現(xiàn)。
注:Dialogic® NetStructure®CPM8、SPCI2S或SPCI4板卡上運行ISUP和TUP。
當ISUP或TUP協(xié)議在Dialogic網(wǎng)擎SS7板卡上運行時,B方SEPTEL_CP命令的l1_flags參數(shù)必須設置為包括bit
9(0x0200)。
下面的例子說明了ISUP和TUP配置命令:
A方
* 配置ISUP模塊:
* ISUP_CONFIG
[]
ISUP_CONFIG 0 0 0 0x0435 4 64 0x73
*
* 設置TUP參數(shù):
* 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參數(shù):
* TUP_CONFIG
[]
TUP_CONFIG 0 0 0 0x8141 4 64 0x83
*
兩個系統(tǒng)中的電路組既可以從0開始編號,也可以兩個系統(tǒng)間隔標號。如果使用第一種方法,整個系統(tǒng)的容量就是單ISUP/TUP協(xié)議層系統(tǒng)容量的2倍;如果使用第二種方法,系統(tǒng)總?cè)萘颗c單ISUP/TUP協(xié)議層系統(tǒng)的容量相同。對于這兩種情況,每半部分控制獨立的CIC范圍,如圖11和12所示。
系統(tǒng)兩部分之間沒有重復電路組("單容量"系統(tǒng),如圖12所示)的系統(tǒng)在一部分故障的情況下能夠激活(配置)另一部分沒有使用的電路組。這個過程可以使用xxx_MSG_CNF_GRP訊息配置電路組來實現(xiàn)。由此可以為另一單元中失效的電路提供SS7信令資源以及ISUP或TUP狀態(tài)機。但是,如果電路終端本身仍然同故障單元物理上相連,那么信令能夠為這些電路實現(xiàn)的唯一進程就是硬件阻塞。
SCCP的配置
在SCCP層,每個SCCP協(xié)議的配置都應該使用相同的本地子系統(tǒng)、遠程信令點和遠程子系統(tǒng)數(shù)據(jù)。
smb_id配置參數(shù)用于識別狀態(tài)更新時的目標節(jié)點,并且應該設置為一個任務的id。這個任務能夠在雙系統(tǒng)中將這一信息傳遞給其它SCCP模塊。在大多數(shù)情況下,SCCP使用0x33作為任務標識符,并且smb_id在A方應該設置為0x53,在B方應該設置為0x43?梢允褂胹ystem.txt文件中的一個REDIRECTION語句來將這些訊息路由到RSI或相似的任務,以便將其傳遞到通過以太網(wǎng)連接的其它SCCP層。此外,SCCP
smb_flags配置參數(shù)應設置為0x001c。
TCAP的配置
在一個多TCAP環(huán)境中,每一TCAP具有一個唯一的例程,它是在SCCP邊緣使用事務id編碼的,這樣可以為接收訊息快速分析正確的目標TCAP。第一個TCAP例程值通常應該為0,下一個為1。
tid_ninst參數(shù)控制使用事務id中的多少位對例程數(shù)據(jù)進行編碼。在一個雙系統(tǒng)中,1位就可以區(qū)分兩個TCAP。(注意tid_ndref必須足夠大,可以對最高的dialogue_id值進行編碼。在一個同時支持2048個對話的系統(tǒng)中,tid_ndref的值必須大于等于11}。
兩個TCAP部分的邏輯dialogue_id的范圍可以相同(這樣運行在這兩個系統(tǒng)上的兩個應用進程將在相同的dialogue_id范圍內(nèi)工作),也可以使用不同的范圍。
機箱間的通信
容錯接口(RSI)軟件從它的輸入隊列中獲取具有目標節(jié)點的訊息,而不獲取RSI本身的訊息,并且將這些訊息發(fā)送給TCP/IP以太網(wǎng)遠程端的同等RSI任務。通信采用TCP/IP套接字,一端作為服務器,另一端作為客戶端。
在接收端,RSI獲取從以太網(wǎng)接收的訊息,并且將它們通過本地訊息傳輸系統(tǒng)傳遞到原始訊息目標所標識的任務中(幀頭dst字段)。如果兩個RSI任務通過以太網(wǎng)進行的通信發(fā)生故障,傳遞到RSI通過以太網(wǎng)進行發(fā)送的訊息將被丟棄。
系統(tǒng)中運行的兩個RSI任務(每半個系統(tǒng)一個)使用相同的唯一的模塊id,通常為0xb0。這必須在帶有LOCAL定義的兩個系統(tǒng)的system.txt文件中加以聲明,使用FORK_PROCESS命令開始。RSI程序?qū)⑵淠Kid作為可選的命令行參數(shù),前綴為'-m'。例如:
./rsi -m0xb0
任何發(fā)送到使用指定模塊id的RSI的訊息都會由本地RSI任務進行處理,并且不會通過以太網(wǎng)傳輸。
主機與每個從機間的RSI連接使用rsicmd工具激活。rsicmd工具的用法如下:
rsicmd
[]
是這個特殊信道的邏輯標識符。RSI通過匹配訊息例程值(由GCT_set_instance設置,缺省值為0)和link_id值來選擇輸出通道。對于大多數(shù)的雙系統(tǒng),兩個系統(tǒng)之間建立一條RSI連接就足夠了,因此這個參數(shù)應該設為0。
指定一個模塊id,當指定的RSI連接失效時,此模塊id將收到通知(一個訊息)。這個參數(shù)的設置可以將這些指示傳遞給應用任務或者本地管理事件查看程序,如s7_log等。
和應該依據(jù)下表進行設置:
連接類型 |
rem_addr |
ink_type值 |
服務器 |
B方的IP地址 |
0(客戶端) |
客戶端 |
0 |
1(服務器) |
系統(tǒng)的一端需要設置為客戶端,另一端設置為服務器。
指定了連接所使用的TCP/IP套接字端口號。每個RSI連接(應該具有唯一的link_id)必須使用唯一的端口號,從9000開始。
是可選的,指定了傳送訊息的RSI模塊。
對于所有可以通過RSI連接(與系統(tǒng)另半部分相連)訪問的目標節(jié)點,system.txt文件中必須插入一條REDIRECT語句(第二個ISUP、TUP、SCCP和/或TCAP協(xié)議的module_id值)。
例如,一個雙ISUP系統(tǒng)應該由兩個ISUP部分組成,每部分缺省module_id都為0x23。A方ISUP的配置數(shù)據(jù)表示另一個ISUP部分的module_id為0x73;因此,在A方將會有一個重定向的動作來對經(jīng)過RSI發(fā)送往0x73的任何訊息重新定向。在B方,應該有一個REDIRECT語句將B方RSI所接收的所有目標為0x73的訊息路由到本地ISUP,標識為0x23。具體情況如圖13所示。
運行在信令卡上的協(xié)議模塊,接收端(對方)的REDIRECT語句應該通過ssd或ssds驅(qū)動(通常情況下module_id為0x20)來對訊息進行重定向,如圖14所示。
下表給出了系統(tǒng)雙方都應該使用的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 |
對于容錯應用的考慮
在一個SS7接口中嵌有應用的雙系統(tǒng)中,應用或者SS7組件故障將導致該部分系統(tǒng)完全癱瘓。
在一個雙電路交換應用(使用ISUP或TUP)中,物理電路終端分布在組成系統(tǒng)的兩個機箱中,因此如果系統(tǒng)的一部分發(fā)生故障,將導致一部分電路的物理故障。在SS7終端,硬件故障通常通過發(fā)送硬件阻塞(也稱為硬件隔離)來處理。這樣所有受這部分硬件影響的當前呼叫都會被拆除,表示這些電路不能被選擇用于呼叫,直到硬件隔離解除。如果電路故障恢復,則硬件隔離即會被解除。
但是,在前面所述的配置中,系統(tǒng)繼續(xù)工作的部分對于故障電路一無所知(這部分配置數(shù)據(jù)保存在故障的部分中),因此不能發(fā)送硬件隔離命令。解決這個問題的一個辦法就是配置電路組,這樣可以為另一部分的電路組保留空間。當一個電路組發(fā)生故障時,這些備份的電路組可以由繼續(xù)工作的部分進行配置,允許向與故障機箱物理連接的電路發(fā)送硬件隔離命令。
也可以采用物理上隔離應用媒介/電路處理和SS7協(xié)議狀態(tài)信息,使兩個應用程序可以利用兩個SS7接口進行通信(SIU采用這種方法)。物理隔離可以采用RSI和以太網(wǎng)來實現(xiàn)。
如果需要,應用可以通過使用基于訊息的API和RSI/以太網(wǎng)進行通信,來在節(jié)點間進行互相檢查以檢測故障。定義用戶具體信息必須出于這個目的。
在一個雙TCAP系統(tǒng)中,系統(tǒng)的一部分故障會導致TCAP狀態(tài)信息的丟失(例如,事務狀態(tài)和任何尚待傳輸?shù)拇鎯Σ考T谥悄芫W(wǎng)絡環(huán)境中,如果可能,此事務相關的呼叫將被拆除。在移動/無線環(huán)境中,任何相關的掛起的移動服務(例如短訊息)都可能超時,操作將報告為出現(xiàn)故障。這些操作應該在系統(tǒng)繼續(xù)工作的部分中再次執(zhí)行。
與SS7協(xié)議進行通信的應用必須在邏輯電路id和每個SS7預先配置的會話id范圍內(nèi)工作。系統(tǒng)的兩部分既可以使用相同范圍值,這些值只在每部分內(nèi)部使用,也可以在不同的范圍內(nèi)運行。
設置System.txt值
下圖展示了一個雙ISUP/TUP/SCCP/TCAP系統(tǒng)中各模塊之間的關系,以及系統(tǒng)兩部分的config.txt文件中的相應條目。參見圖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(如果有),以及應用程序任務、配置工具(如s7_mgt)和調(diào)試工具的LOCAL定義。這里也應該通過FORK_PROCESS語句來啟動相應的驅(qū)動和支持任務,在相應的程序員手冊中有詳細描述。
信令處理器板卡協(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文件也必須包括所有應用程序任務、配置工具(如s7_mgt)和調(diào)試工具的LOCAL定義。這里也應該通過FORK_PROCESS語句來啟動相應的驅(qū)動和支持任務,在相應的程序員手冊中有詳細描述。
附錄A:TCAP設置例程模塊ID訊息
說明:
這個訊息為一個指定的TCAP例程設置module_id。當發(fā)送任何來自網(wǎng)絡上的帶有事務id中指定例程的訊息時,TCAP使用這個module_id作為目標節(jié)點。
訊息格式:
訊息標頭 |
|
字段名稱 |
含義 |
類型 |
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 |
參數(shù)域
參數(shù)描述:
Instance
應該發(fā)送至指定module_id的任何接收訊息的事務ID中設置的例程值。
module_id
對于指定例程,module_id用作TCAP發(fā)送訊息的目標。
如欲了解更多信息,請訪問:http://www.Dialogic.com/
|