畢海霞

(西安電子工程研究所 西安 710100)

0 引言

當前戰(zhàn)爭中，多軍兵種協(xié)同的需求越來越迫切，協(xié)同作戰(zhàn)所需的傳輸信息量急劇上升，傳輸業(yè)務種類也越來越多。自組網(wǎng)因其無中心、自組織、多跳路由和動態(tài)拓撲的特征，網(wǎng)絡快速部署、抗毀性強和組網(wǎng)靈活等優(yōu)點，成為了近年來軍事信息化應用中的研究熱點。自組網(wǎng)的網(wǎng)絡協(xié)議分為物理層，數(shù)據(jù)鏈路層，網(wǎng)絡層，傳輸層和應用層四部分。應用層的設計高效與否會影響整個自組網(wǎng)系統(tǒng)的性能，本文就此開展研究，提出了一種適用于自組網(wǎng)的流媒體應用層設計。

自組網(wǎng)應用層是一套基于PC 或嵌入式平臺的軟件系統(tǒng)，主要實現(xiàn)通信業(yè)務、運維管理類兩部分功能。通信業(yè)務實現(xiàn)網(wǎng)絡通信功能，主要包括語音、視頻、撥號通話、短消息、01 數(shù)據(jù)、02 指令通信功能;此外，運維管理類用戶信息管理可以從點名業(yè)務中獲取應用層用戶信息，包括用戶狀態(tài)、漫游狀態(tài)等信息等。

網(wǎng)絡管理包括拓撲顯示、用戶信息管理、網(wǎng)絡參數(shù)配置和自組網(wǎng)設備狀態(tài)管理四部分功能，其中拓撲顯示實現(xiàn)點到點鏈路查詢、業(yè)務拓撲查詢和實時拓撲查詢，分別反映網(wǎng)絡本地節(jié)點和任意另外一個節(jié)點間的鏈路連接信息，網(wǎng)絡傳輸業(yè)務的連接信息和即時的網(wǎng)絡拓撲連接信息;用戶信息管理通過點名及自組網(wǎng)設備狀態(tài)管理功能獲取自組網(wǎng)用戶信息，生成用戶信息數(shù)據(jù)庫，一方面為通信業(yè)務類功能提供通信時所需的通信錄，另一方面為運維管理類功能提供網(wǎng)絡維護時所需的用戶信息;網(wǎng)絡參數(shù)配置主要對自組網(wǎng)設備的IP 地址、網(wǎng)關地址、頻段及頻點等信息進行配置。

ANI(Application Network Interface)接口及隊列調度，對通信業(yè)務、網(wǎng)絡管理及運維支撐三部分功能產(chǎn)生及收到的數(shù)據(jù)包進行封包或解包，并根據(jù)業(yè)務的優(yōu)先級進行發(fā)送和接收隊列的調度。

1 系統(tǒng)總體架構

自組網(wǎng)應用層通信示意圖如下所示。對音視頻業(yè)務，應用層采集攝像頭和話筒數(shù)據(jù)后，進行音視頻編碼，然后在網(wǎng)絡協(xié)議控制下，進入通信網(wǎng)絡進行傳輸，對端收到音視頻數(shù)據(jù)，進行解碼及恢復工作;對數(shù)據(jù)類通信業(yè)務，應用層接收到數(shù)據(jù)后，在網(wǎng)絡協(xié)議處理后，進入通信網(wǎng)絡傳輸至對端;對網(wǎng)絡管理類及運維支撐類數(shù)據(jù)，應用層進行解析后，與底層協(xié)議進行交互，或進入通信網(wǎng)路。

通過對應用層軟件功能進行分析，可將其分解為以下子功能:

(1)實現(xiàn)VOIP 語音及視頻，包括語音及視頻的采集、編碼及封包和解包。

(2)實現(xiàn)對通信業(yè)務的差異化處理(封裝ANI頭，不同的優(yōu)先級及QoS 處理策略)，并實現(xiàn)網(wǎng)絡管理及運維支撐類業(yè)務的功能。

(3)實現(xiàn)一個可移植、穩(wěn)健的平臺，功能包括操作系統(tǒng)適配，socket 抽象，消息包管理，進程監(jiān)控，定時器管理及日志等。

(4)實現(xiàn)UI用戶界面，便于用戶操作。

綜上分析，應用層邏輯架構如下圖所示。

圖1 應用層邏輯架構

2 信令面協(xié)議設計

2.1 VoIP 協(xié)議分析

VoIP(Voice Over Internet Protocol)是建立在Internet 基礎上的新型數(shù)字化傳輸技術，是在IP(Internet Protocol)網(wǎng)上進行實時音視頻，數(shù)據(jù)和文件等業(yè)務傳輸?shù)募夹g［1］。

H.323［2］和SIP［3］是VoIP 協(xié)議中最主要的兩種信令面協(xié)議，分別由ITU-T 和IETF 制定。兩者均利用RTP/RTCP(Real-Time Protocol/Real-Time Control Protocol)作為多媒體通信的應用層控制協(xié)議，因此，兩者所提供的信令功能類似;但由于制定機構不同，兩者在設計風格上差別巨大。

下表從幾個方面對兩種協(xié)議進行比較與分析:

表1 H.323 和SIP 協(xié)議比較

續(xù)表

綜上分析，H.323 基于傳統(tǒng)的電話信令架構而設計，協(xié)議發(fā)展較成熟，但由于架構龐雜，難以理解和實現(xiàn)。并且，H.323 的版本更新必須遵循向前兼容的原則，這意味著，隨著應用的不斷更新，即使某些舊特性不再具有應用價值也不會被淘汰掉，而同時新特性不斷累加，這無疑將導致協(xié)議越來越來龐雜。而SIP 協(xié)議在設計時遵循了簡單、開放、兼容和可擴展等原則。隨著應用的發(fā)展，被淘汰的舊的首部和取值將逐漸消失，保證了協(xié)議的簡潔。同時，SIP 協(xié)議在消息格式上編碼更方便，使得SIP 協(xié)議在擴展方面能夠產(chǎn)生更有效率的應用。因此，本設計中選用SIP 協(xié)議作為VoIP 信令面協(xié)議。

2.2 傳統(tǒng)的SIP 系統(tǒng)及呼叫流程

一個SIP 系統(tǒng)主要由網(wǎng)絡服務器和用戶代理(User Agent)組成。UA(User Agent)也稱作SIP 終端，而網(wǎng)絡服務器包括代理服務器、注冊服務器和重定向服務器等。SIP 會話主要由這四個應用實體來完成［6］。

●用戶代理

UA 為終端用戶的通信提供多功能的界面。目前的SIP UA 通?？芍С终Z音，即時消息和視頻等多種業(yè)務。其主要功能包括會話發(fā)起，會話保持，會話轉接等6］。

●代理服務器

代理服務器的主要功能是路由并轉發(fā)用戶的呼叫請求。當某用戶發(fā)起會話時，其UA 會生成一個SIP 請求消息并發(fā)送至對應的代理服務器，然后，代理服務器將請求消息轉發(fā)至對端的UA，從而搭建起用戶間交互的橋梁［6］。

●重定向服務器

重定向服務器的功能不同于代理服務器。當收到用戶請求時，重定向服務器并不轉發(fā)，而是執(zhí)行查找操作，獲得被請求用戶的地址信息，并將其回復給請求用戶。請求用戶接收到地址信息后，將直接向被請求用戶發(fā)送會話請求［6］。

●注冊服務器

注冊服務器的主要功能是處理用戶的注冊請求，從而完成用戶地址的更新。當用戶登錄時，UA會向注冊服務器發(fā)送注冊消息，并將自己的IP 地址告訴注冊服務器，注冊服務器將用戶的IP 地址與用戶綁定，以方便其他用戶對其進行查找［6］。

傳統(tǒng)的SIP 呼叫流程如下圖所示。

圖2 SIP 會話的建立過程

2.3 適用于自組網(wǎng)系統(tǒng)的SIP 協(xié)議

傳統(tǒng)的SIP 協(xié)議采用了C/S 架構。由于SIP 協(xié)議用戶數(shù)目過于龐大，必須由專門的服務器完成用戶注冊(用戶自身信息，包括ID 與地址之間的映射關系等注冊于服務器上)，以及用戶的鑒權，重定向等工作。再通過邀請(INVITE)流程發(fā)起會話建立，協(xié)商雙方的用戶面(語音)編碼方式、傳輸?shù)刂?端口等信息，為后續(xù)傳輸用戶面語音幀的RTP/RTCP協(xié)議協(xié)商和分配資源，除此之外，INVITE 流程還包括一系列后續(xù)雙方的行為交互，包括振鈴、轉接、接聽/拒絕等等。

而自組網(wǎng)應用層的需求具有以下幾個特點:，

●節(jié)點數(shù)目少

自組網(wǎng)節(jié)點數(shù)目一般為幾十個。

●SIP 終端IP 地址固定

由于應用場景的特殊性，每個SIP 終端在使用前必須配置好IP 地址。即使IP 地址發(fā)生變更，也會通過網(wǎng)絡傳輸告知其他相關SIP 終端。且，每個SIP 終端上均保存了其他SIP 終端的IP 地址。

●自組網(wǎng)中節(jié)點地位平等

出于抗毀性的考慮，自組網(wǎng)各節(jié)點地位平等，任何一個節(jié)點損毀都不會影響其他節(jié)點的通信。如果設置其中某些節(jié)點作為SIP 網(wǎng)絡中的服務器，那如果該節(jié)點被毀，則網(wǎng)絡將癱瘓。

綜上分析，自組網(wǎng)應用場景下，SIP 協(xié)議中的服務器是不可以也無需存在的。針對該需求，剔除服務器的功能，將SIP 會話流程修改如下:

圖3 適用于自組網(wǎng)的SIP 會話流程

(1)用戶A 向用戶B 通過“INVITE”消息發(fā)起會話請求，會話請求消息體中帶有用戶A 的媒體屬性描述;

(2)用戶B 振鈴，向用戶A 返回響應消息“180 RINGING”，用戶A 播放回鈴音;

(3)用戶B 摘機，并向用戶A 返回對“INVITE”請求的響應消息“200 OK”，響應消息的消息體中帶有用戶B 的媒體屬性描述;

(4)用戶A 發(fā)送針對響應消息“200 OK”的ACK 確認請求消息。此時，用戶A 與B 會話建立，開始進行多媒體會話;

(5)用戶B 掛機，用戶B 向用戶A 發(fā)送Bye 請求消息;

(6)用戶A 返回對Bye 請求消息的“200 OK”響應消息，通話結束。

3 用戶面協(xié)議設計

3.1 RTP/RTCP 協(xié)議分析

在流媒體研究中，對音視頻文件的實時傳輸要求較低的時延和較小的丟包率?；谶B接的TCP協(xié)議是一種可靠的傳輸層協(xié)議，但為保證可靠傳輸而設計的三次握手機制，擁塞控制技術和重發(fā)機制導致開銷增大，時延增加，無法很好地支持穩(wěn)定速率的流媒體數(shù)據(jù)的平滑傳輸;而無連接的傳輸層協(xié)議UDP 沒有任何QoS 保證，無法保證數(shù)據(jù)的可靠傳送。為解決上述矛盾，實現(xiàn)流媒體數(shù)據(jù)在IP 上的實時可靠傳輸，需要在傳輸層和應用層協(xié)議之間增加一個通信控制層，即RTP/RTCP［7］協(xié)議。RTP 可提供編碼數(shù)據(jù)的實時傳輸，RTCP 則向會話中的所有成員周期性地發(fā)送控制信息反饋數(shù)據(jù)傳送情況，以便對發(fā)送速率，服務質量和擁塞進行控制。其端到端傳輸流程描述如下:

音視頻信息經(jīng)編碼器處理后形成多媒體數(shù)據(jù)流，RTP 協(xié)議對多媒體數(shù)據(jù)進行封裝后交由網(wǎng)絡傳輸。對端網(wǎng)絡傳輸模塊接收到多媒體數(shù)據(jù)后交由RTP 協(xié)議進行解封處理，然后音視頻解碼模塊對數(shù)據(jù)進行解碼，恢復原有音視頻信號。在對多媒體數(shù)據(jù)進行封裝和解封時，RTP 協(xié)議會根據(jù)數(shù)據(jù)包中所攜帶的載荷類型、時間戳、幀邊界等包頭信息對音視頻信號進行同步控制。

在多媒體數(shù)據(jù)傳輸過程中，RTP/RTCP 協(xié)議多運行于UDP 協(xié)議之上。這是因為RTCP 協(xié)議能實時進行質量和擁塞控制，無需下層的傳輸層協(xié)議進行QoS 保證;同時，UDP 協(xié)議的傳輸時延低于TCP協(xié)議，能保證多媒體數(shù)據(jù)流的流暢傳輸。當然，當存在對可靠性要求非常高的數(shù)據(jù)傳輸需求時，也可將RTP/RTCP 協(xié)議運行于TCP 協(xié)議之上，數(shù)據(jù)和控制信令的傳輸即適用于該類情況。

圖4(a)表示了RTP/RTCP 與各種網(wǎng)絡協(xié)議的關系。

3.1 適用于自組網(wǎng)系統(tǒng)的用戶面協(xié)議

軍事應用中，自組網(wǎng)系統(tǒng)的業(yè)務主要分為音視頻和數(shù)據(jù)兩部分。按照傳統(tǒng)的RTP 使用方法，音視頻一般采用UDP 傳輸，而數(shù)據(jù)和控制指令采用TCP傳輸。考慮到系統(tǒng)對時延要求較高，尤其是火控數(shù)據(jù)，而TCP 連接建立過程中需要三次握手，若采用該協(xié)議，將對時延指標的實現(xiàn)帶來巨大壓力。因此，本系統(tǒng)所有通信業(yè)務的傳輸均采用UDP 協(xié)議。

由于音視頻數(shù)據(jù)對時延和抖動要求較高，因此，必須使用RTP/RTCP 監(jiān)控數(shù)據(jù)傳輸，保證傳輸質量，因此，音視頻傳輸協(xié)議棧定義如圖4(b)所示

由于軍事應用中的某些數(shù)據(jù)(比如火指控數(shù)據(jù))對時延要求非常高，若使用SIP+RTP/RTCP 的方式進行傳輸，則在真正的數(shù)據(jù)傳輸前，必須首先進行四次SIP 握手，這將導致時延大幅增加。因此，建議數(shù)據(jù)傳輸時，不使用SIP 進行信令交互，同時，數(shù)據(jù)面協(xié)議中不封裝RTP/RTCP 頭以減小數(shù)據(jù)量。數(shù)據(jù)傳輸協(xié)議棧修改如圖4(c)所示。

圖4 自組網(wǎng)用戶面協(xié)議棧圖示

4 結束語

本文分析了應用層流媒體協(xié)議的特性，針對自組網(wǎng)的應用需求，進行了協(xié)議選型。由于自組網(wǎng)系統(tǒng)具有節(jié)點平等，移動性強及無線傳輸質量差的網(wǎng)絡特性，對所選擇的SIP 和RTP/RTCP 協(xié)議架構及呼叫流程進行了修改，使其適用于自組織網(wǎng)絡，是一種可行的自組網(wǎng)流媒體協(xié)議。

［1］郝中偉，郝中娜.基于WEB 的呼叫中心［J］.信息技術，2002，(6):61-64.

［2］H.323 Standards.http://www.h323forum.org/standards/.

［3］J.Rosenberg，H.Schulzrinne，G.Camarillo.SIP:Session Initiation Protocol.RFC 3261，IETF，June，2002.

［4］林韜.基于SIP 的多媒體通信研究與實現(xiàn)，［D］.北京:北京郵電大學，2009:2-18.

［5］崔學敏.視頻通信協(xié)議技術的分析研究與應用［D］.昆明:昆明理工大學，2007:3-12.

［6］韓磊磊.基于P2P-SIP 的VoIP 關鍵技術研究［D］.鄭州:解放軍信息工程大學，2010:44-20.

［7］RFC3550，RTP:A Transport Protocol for Real-Time Applications.