基于JSP網(wǎng)絡(luò)路徑控制優(yōu)化研究

摘 要：網(wǎng)絡(luò)路徑控制系統(tǒng)是運(yùn)用通信技術(shù)、計算機(jī)技術(shù)以及網(wǎng)絡(luò)技術(shù)來傳輸音頻、路由選擇、文字、圖像、數(shù)據(jù)等的網(wǎng)絡(luò)虛擬路由選擇。網(wǎng)絡(luò)路徑控制使用電視、音響等外部設(shè)備以及專用的路由選擇軟件、硬件，通過計算機(jī)網(wǎng)絡(luò)在兩地或多地同時召開實時路由選擇，與會者運(yùn)用圖像、語音等多種方式交流信息，可以遠(yuǎn)距離開展協(xié)同工作以及實時進(jìn)行信息交流、共享。在地理上分散的與會者使用網(wǎng)絡(luò)路徑控制可以共聚一處，方便與會成員之間真實、直觀的交流信息，從而達(dá)到替代傳統(tǒng)網(wǎng)絡(luò)路徑控制的目的。

關(guān)鍵詞：JSP；網(wǎng)絡(luò)；路徑

中圖分類號：TP301

網(wǎng)絡(luò)路徑控制系統(tǒng)在一些高可靠性應(yīng)用場合，如公安、軍隊、應(yīng)急指揮等，常使用線路備份來保證路由選擇質(zhì)量。通常情況下視訊系統(tǒng)需要支持兩條線路，即E1線路和IP線路。開會過程中，如果當(dāng)前使用的主用線路如IP線路出現(xiàn)網(wǎng)絡(luò)斷開或者網(wǎng)絡(luò)丟包等故障時，網(wǎng)絡(luò)路徑控制系統(tǒng)必須能實時切換到備用線路如E1線路，從而保障網(wǎng)絡(luò)路徑控制的正常進(jìn)行。

為滿足這種需求，主備鏈路備份被應(yīng)用到網(wǎng)絡(luò)路徑控制系統(tǒng)的實際組網(wǎng)中。路由選擇系統(tǒng)中MCU和終端同時支持IP線路和E1線路，當(dāng)主用線路故障時，路由選擇系統(tǒng)先進(jìn)行丟包補(bǔ)償以及帶寬動態(tài)調(diào)整，盡可能保證路由選擇質(zhì)量。當(dāng)網(wǎng)絡(luò)嚴(yán)重丟包時，采用上述措施后還不能保證路由選擇的音路由選擇質(zhì)量或者線路斷開時，該系統(tǒng)可在最短時間內(nèi)，自動的由主用線路切換到備用線路，保證網(wǎng)絡(luò)路徑控制的正常召開。

1 網(wǎng)絡(luò)路徑優(yōu)化控制設(shè)計

1996年ITU_T批準(zhǔn)JSP標(biāo)準(zhǔn)后，網(wǎng)絡(luò)路徑控制的技術(shù)以及市場都發(fā)生巨大變化，更多的公司競相開發(fā)基于JSP標(biāo)準(zhǔn)的新產(chǎn)品，更多的用戶采用基于JSP標(biāo)準(zhǔn)的產(chǎn)品構(gòu)造自己的網(wǎng)絡(luò)路徑控制系統(tǒng)。在基于JSP的網(wǎng)絡(luò)路徑控制中，一個簡單的路由選擇系統(tǒng)包括：網(wǎng)守、網(wǎng)關(guān)、多點控制單元和終端。圖1是最常見的一種域類型中的JSP系統(tǒng)，在一個域中，只有一個網(wǎng)守，至少包括一個終端。

終端在包交換網(wǎng)絡(luò)中，作為節(jié)點設(shè)備能提供實時、雙向通信。對于JSP終端，語音通信是必選的，數(shù)據(jù)通信能力、圖像編解碼器、T.120數(shù)據(jù)路由選擇協(xié)議是可選的，必須支持JSP標(biāo)準(zhǔn)，JSP標(biāo)準(zhǔn)用于控制信道使用情況及信道性能。

網(wǎng)關(guān)——能提供JSP路由選擇節(jié)點設(shè)備與其他ITU標(biāo)準(zhǔn)相兼容的終端之間的轉(zhuǎn)換功能，主要轉(zhuǎn)換傳輸格式和通信規(guī)程，當(dāng)電路交換網(wǎng)絡(luò)端與包交換網(wǎng)絡(luò)端通信時，網(wǎng)關(guān)執(zhí)行呼叫建立、呼叫拆除、語音和圖像編解碼器轉(zhuǎn)換等工作。網(wǎng)關(guān)使用H.225協(xié)議、JSP協(xié)議與終端進(jìn)行通信。為JSP系統(tǒng)的一個可選件。

網(wǎng)守——網(wǎng)守為JSP節(jié)點提供呼叫控制服務(wù)。當(dāng)JSP網(wǎng)守存在于路由選擇系統(tǒng)時，必須提供：地址翻譯、帶寬控制、許可控制與區(qū)管理功能等服務(wù)，呼叫控制信令、呼叫管理、帶寬管理、呼叫鑒權(quán)等為可選功能，在一個JSP通信域中可以包含多個網(wǎng)關(guān)，但在該通信域中，只能由某個網(wǎng)守負(fù)責(zé)地址轉(zhuǎn)換和管理。這是JSP系統(tǒng)的一個可選組件。

多點控制單元（MCU）應(yīng)用于三個以上節(jié)點設(shè)備的網(wǎng)絡(luò)路徑控制，在點到點的通信中不需要該組件。一個MCU包含一個多點控制器（MC）以及多點處理器（MP），其中可以包含多個或者不包含MP，終端間JSP控制信息需要MC進(jìn)行處理，這決定MC對音路由選擇的處理能力，特殊情形下，MC通過判斷是否需要對某些路由選擇流、音頻流進(jìn)行多點廣播，以此控制路由選擇資源，媒體信息流由MP進(jìn)行處理，主要通過混合、切換和處理等三種方式對音頻、路由選擇、數(shù)據(jù)信息進(jìn)行處理。

圖1 位于一個域內(nèi)的JSP系統(tǒng)

在JSP標(biāo)準(zhǔn)中，規(guī)定了基于包交換網(wǎng)絡(luò)的多媒體通信系統(tǒng)、系統(tǒng)組成單元、各單元間通信過程，不包括包交換網(wǎng)絡(luò)自身的內(nèi)容。由于多媒體通信必須滿足高實時性、低傳輸抖動以及足夠帶寬等要求，因此從傳輸時延、傳輸抖動、傳輸帶寬、媒體流同步、多點通信、可靠性、安全性以及NAT等方面對IP網(wǎng)絡(luò)提出了更高組網(wǎng)要求。

2 網(wǎng)絡(luò)路徑控制系統(tǒng)的傳輸優(yōu)化

伴隨著互聯(lián)網(wǎng)技術(shù)的飛速發(fā)展，路由選擇通信領(lǐng)域不斷出現(xiàn)新的技術(shù)和應(yīng)用，以及在保證網(wǎng)絡(luò)服務(wù)質(zhì)量情況下對核心寬帶骨干網(wǎng)技術(shù)的應(yīng)用，網(wǎng)絡(luò)傳輸能力的進(jìn)一步提高，將促進(jìn)JSP網(wǎng)絡(luò)路徑控制系統(tǒng)的快速發(fā)展。網(wǎng)絡(luò)路徑控制系統(tǒng)未來的發(fā)展趨勢有以下幾點：

2.1 JSP與SIP的互通

SIP的概念最早在1996年由IETF的多方多媒體會話控制工作組首先提出，SIP系統(tǒng)比JSP系統(tǒng)更加簡單、靈活。它的應(yīng)用目標(biāo)：基于互聯(lián)網(wǎng)實現(xiàn)數(shù)據(jù)、音路由選擇實時通信，從而將音路由選擇通信應(yīng)用大眾化。

SIP發(fā)展趨勢被部分業(yè)內(nèi)人士所看好，SIP已應(yīng)用于許多新的環(huán)境，如Web、即時消息等，基于SIP的語音應(yīng)用較為成熟以及相關(guān)的各種SIP產(chǎn)品也相繼出現(xiàn)，但是目前運(yùn)營商所建網(wǎng)絡(luò)路徑控制網(wǎng)絡(luò)仍以JSP協(xié)議為主，因此JSP網(wǎng)絡(luò)路徑控制系統(tǒng)與SIP的互通成為趨勢。

2.2 固網(wǎng)領(lǐng)域與移動領(lǐng)域的互通

3G的大范圍的使用、移動終端的移動性和便攜性，網(wǎng)絡(luò)路徑控制將更能滿足客戶溝通的需求。移動網(wǎng)絡(luò)和固定網(wǎng)絡(luò)在視訊會話和傳輸協(xié)議等方面存在不同，因此移動網(wǎng)和固網(wǎng)視訊業(yè)務(wù)的融合將是未來發(fā)展的趨勢。

2.3 視訊終端穿越公私網(wǎng)

隨著基于JSP協(xié)議的路由選擇系統(tǒng)應(yīng)用大眾化，研究JSP協(xié)議如何穿越NAT/防火墻也是當(dāng)今的一個熱點問題。

2.4 編解碼方式由硬件轉(zhuǎn)向軟件

由于計算機(jī)和附屬板卡的處理速度明顯提高，以前許多需要專用設(shè)備進(jìn)行的數(shù)據(jù)處理過程，現(xiàn)在可以由計算機(jī)及其內(nèi)置的通用板卡來完成。

2.5 產(chǎn)品協(xié)議類型從H.320向JSP轉(zhuǎn)化

在初期，基于ISDN線路、符合H.320協(xié)議的視訊產(chǎn)品占主要比例。隨著IP協(xié)議的普遍應(yīng)用和互聯(lián)網(wǎng)的高速發(fā)展，發(fā)展基于IP網(wǎng)的多媒體系統(tǒng)成為一種趨勢，符合JSP協(xié)議的產(chǎn)品比例急劇上升。

在現(xiàn)有的網(wǎng)絡(luò)路徑控制系統(tǒng)基礎(chǔ)上，讓MCU主備鏈路都為IP鏈路，終端主用鏈路為IP鏈路、備用鏈路為E1鏈路，通過擴(kuò)展的BFD對IP鏈路和E1鏈路進(jìn)行連通性檢測和特定碼流的帶寬檢測。當(dāng)主用鏈路出現(xiàn)故障時，系統(tǒng)首先使用進(jìn)行丟包補(bǔ)償和帶寬動態(tài)調(diào)整，來盡最大可能的保證路由選擇質(zhì)量。當(dāng)鏈路嚴(yán)重丟包，采用丟包補(bǔ)償和帶寬動態(tài)調(diào)整后還不能保證音路由選擇質(zhì)量或者線路斷開時，不需外界人為干預(yù)，路由選擇系統(tǒng)可在最短時間內(nèi)，由主用鏈路自動切換到備用鏈路，保證遠(yuǎn)程JSP路徑選擇的正常進(jìn)行。

在完成雙鏈路備份功能的過程中，本人主要工作包括以下幾個方面：（1）實現(xiàn)了MCU和終端的軟件狀態(tài)機(jī)，當(dāng)主用鏈路或者備用鏈路需要切換時，根據(jù)兩條鏈路的當(dāng)前狀態(tài)，依據(jù)狀態(tài)機(jī)的狀態(tài)和狀態(tài)機(jī)切換步驟，可以完成主用鏈路和備用鏈路之間的動態(tài)切換。（2）創(chuàng)建BFD會話，利用BFD對主用線路和備用線路實現(xiàn)檢測，對業(yè)務(wù)使用鏈路進(jìn)行小數(shù)據(jù)量的鏈路連通性檢測，對當(dāng)前不使用鏈路（為主用鏈路時）進(jìn)行特定碼率的帶寬檢測。（3）當(dāng)主用鏈路和備用鏈路的BFD狀態(tài)發(fā)生改變時，MCU的相關(guān)模塊要進(jìn)行相關(guān)處理操作。（4）當(dāng)主用鏈路和備用鏈路的BFD狀態(tài)發(fā)生改變時，終端的相關(guān)模塊要進(jìn)行相關(guān)處理操作。

在完成上述內(nèi)容后，路由選擇所用鏈路發(fā)生故障時，可以自動切換到另一條鏈路上，路由選擇繼續(xù)召開，可以滿足客戶的高可靠性和實時性要求。

3 BFD路由選擇優(yōu)化技術(shù)

3.1 BFD協(xié)議優(yōu)化

對于IP網(wǎng)絡(luò)，在故障檢測方面主要存在如下問題：（1）部分路由控制協(xié)議在對網(wǎng)絡(luò)線路進(jìn)行鏈路故障檢測時，仍然使用傳統(tǒng)的Hello協(xié)議，導(dǎo)致發(fā)現(xiàn)鏈路故障以及修復(fù)鏈路故障的時間太長；（2）在IP網(wǎng)絡(luò)中，部分控制協(xié)議不支持線路故障檢測機(jī)制。在這種情形下，雙向轉(zhuǎn)發(fā)檢測（BFD）技術(shù)出現(xiàn)了，它能夠?qū)W(wǎng)絡(luò)鏈路進(jìn)行更快的鏈路故障檢測，縮短鏈路故障響應(yīng)時間，大大縮短故障網(wǎng)絡(luò)的恢復(fù)時間，滿足了IP網(wǎng)絡(luò)中線路快速故障檢測的要求，提高網(wǎng)絡(luò)鏈路的可靠性。

BFD（BidirectionalForwardingDetection）是一種高速的“Hello”機(jī)制，在實際應(yīng)用中，根據(jù)上層協(xié)議通知，然后在某條鏈路路徑上建立BFD會話，此時在會話通道上一對系統(tǒng)會周期性的發(fā)送檢測報文，如果在一段時間（即檢測時間）內(nèi)沒有接收到對端的BFD檢測報文，則認(rèn)為這條到相鄰系統(tǒng)的雙向轉(zhuǎn)發(fā)路徑此時已處于缺陷狀態(tài)，已出現(xiàn)鏈路故障，必須通知上層協(xié)議進(jìn)行處理。

3.2 檢測模式優(yōu)化

異步模式為BFD的主要操作模式，在這種模式下，在會話通道上一對系統(tǒng)會周期性地向?qū)Ψ桨l(fā)送BFD控制包，如果在一段時間內(nèi)都沒有接收到連續(xù)控制包，就認(rèn)為當(dāng)前會話狀態(tài)為“Down”。查詢模式為BFD的另一種操作模式，在這種模式下，BFD會話建立后，系統(tǒng)停止向?qū)Ψ桨l(fā)送控制包。在某個系統(tǒng)需要顯式驗證當(dāng)前鏈路的連接性時，系統(tǒng)在會話通道上發(fā)送一個短的BFD控制包，然后協(xié)議再次保持沉默?；芈暪δ転閮煞N模式的一個輔助功能，當(dāng)使用回聲功能時，本地發(fā)送一個BFD回聲包，遠(yuǎn)端系統(tǒng)通過它的轉(zhuǎn)發(fā)通道將它們環(huán)回回來。

3.3 支持流媒體的協(xié)議

多媒體應(yīng)用主要特點是音路由選擇的數(shù)據(jù)量比較大、實時性要求比較高。在網(wǎng)絡(luò)中，傳統(tǒng)的TCP協(xié)議是一個面向連接的傳輸層的協(xié)議，傳輸數(shù)據(jù)的可靠性主要依賴“發(fā)送數(shù)據(jù)——等待確認(rèn)已收到數(shù)據(jù)——再發(fā)送數(shù)據(jù)”的確認(rèn)機(jī)制來保證，由于重傳機(jī)制和擁塞控制機(jī)制的時延比較長，靈活性比較差，因此在實際應(yīng)用中TCP協(xié)議不適用于多媒體的實時傳輸。另一方面，相對于TCP協(xié)議，UDP協(xié)議的處理過程比較簡單，不需要確認(rèn)機(jī)制來保證傳輸數(shù)據(jù)的到達(dá)與否，傳輸時延小于TCP，并且能與音頻、路由選擇很好地配合，因此在實際應(yīng)用中，比較適合對實時性要求較高的多媒體通信。

3.4 實時傳輸協(xié)議RTP

實時傳輸協(xié)議RTP（Real-TimeTransportProtocol）主要是在多媒體應(yīng)用中為音頻、路由選擇等實時數(shù)據(jù)提供一種端到端的傳輸服務(wù)，該協(xié)議可以建立在TCP、ATM等面向連接的協(xié)議上。在實際應(yīng)用中，由RTP協(xié)議和UDP協(xié)議共同完成傳輸層的一些功能，由UDP分組來承載RTP的數(shù)據(jù)單元，RTP只負(fù)責(zé)保證音頻、路由選擇等實時數(shù)據(jù)的傳輸，但是它并不能保證所有數(shù)據(jù)包能夠順序傳輸，因此無法保證多媒體應(yīng)用中實時業(yè)務(wù)的服務(wù)質(zhì)量，在這種情況下，此時必須需要RTCP協(xié)議用來控制和監(jiān)視RTP的傳輸和服務(wù)質(zhì)量。因此，在多媒體應(yīng)用中，為保證傳輸質(zhì)量，RTP協(xié)議必須依賴RTCP協(xié)議提供如下服務(wù)：提供可靠的傳輸機(jī)制來確保數(shù)據(jù)包的順序傳輸、流量控制以及擁塞控制。

參考文獻(xiàn)：

[1]ITU-TRecommendationJSP，finalversion（1997），Packed_BasedMultimediaCommunicationsSystem.

[2]謝彬.VoIP信令協(xié)議JSP和SIP的比較[J].科技信息，2009，9：76.

[3]劉子文.基于IP的JSP路由選擇系統(tǒng)設(shè)計[J].當(dāng)代通信，2011，06：26-29.

作者簡介：郝榮彬（1976.6-），男，四川榮縣人，碩士，講師，研究方向：計算機(jī)應(yīng)用。