陳 琛，趙麗娟

(1.陜西省人防(民防)指揮信息保障中心，陜西 西安 710061;2.西安雷信科技有限責(zé)任公司 研發(fā)部，陜西 西安 710061)

演示系統(tǒng)要求能夠在兩臺(tái)計(jì)算機(jī)之間通過(guò)高速UWB 通信設(shè)備傳輸流媒體。發(fā)送端通過(guò)音視采集設(shè)備采集音視頻數(shù)據(jù)，然后通過(guò)UWB 通信系統(tǒng)傳輸，并能夠在一定距離之內(nèi)的另一臺(tái)計(jì)算機(jī)上將發(fā)送端采集到的音視頻數(shù)據(jù)實(shí)時(shí)、流暢的播放。其需求分為:

(1)因?yàn)閁WB 演示系統(tǒng)的物理層是建立在單工通信的模式上的，所以發(fā)送端得不到接收端的任何應(yīng)答消息，通信雙方無(wú)法進(jìn)行握手應(yīng)答。針對(duì)這種單工通信，需要設(shè)定一種通信協(xié)議，來(lái)實(shí)現(xiàn)并且保證可靠的通信傳輸。

(2)由于無(wú)線UWB 通信系統(tǒng)無(wú)線鏈路的不穩(wěn)定性，在傳輸過(guò)程中可能會(huì)出現(xiàn)丟幀或誤碼，所以需要設(shè)計(jì)適合信道傳輸?shù)臄?shù)據(jù)鏈路層幀格式，保證傳輸?shù)目煽啃浴?/p>

(3)由于高速UWB 通信系統(tǒng)具有高數(shù)據(jù)傳輸速率，在音視頻數(shù)據(jù)傳輸與接收端音視頻回放過(guò)程中，會(huì)產(chǎn)生與其速率不匹配的問(wèn)題。系統(tǒng)需要提高音視頻數(shù)據(jù)處理的速率，保證音視頻數(shù)據(jù)實(shí)時(shí)、流暢的播放。

1 通信協(xié)議過(guò)程分析與實(shí)現(xiàn)

(1)系統(tǒng)對(duì)象和協(xié)議流程的分析與實(shí)現(xiàn)。

通信協(xié)議是指通信雙方的一種約定。約定包括對(duì)數(shù)據(jù)格式、同步方式、傳送速度、傳送步驟、檢糾錯(cuò)方式以及控制字符定義等問(wèn)題做出統(tǒng)一規(guī)定，通信雙方必須共同遵守。因此，也叫做通信控制規(guī)程，或稱(chēng)傳輸控制規(guī)程［1－2］。本文在物理層設(shè)備單工通信的要求下，根據(jù)協(xié)議工程的開(kāi)發(fā)方法，制定了適合無(wú)線UWB 通信系統(tǒng)的通信協(xié)議。

首先發(fā)送信令幀建立發(fā)端與收端的通信鏈路，當(dāng)通信鏈路建立成功后，按照協(xié)議規(guī)定的幀結(jié)構(gòu)發(fā)送音視頻格式信息與音視頻數(shù)據(jù)。這種協(xié)議機(jī)制可以完成演示系統(tǒng)的信令傳輸以及音視頻數(shù)據(jù)傳輸，建立穩(wěn)定通信鏈路，保證收端可以接收到發(fā)端音視頻數(shù)據(jù)，并且在接收機(jī)上回放。

(2)消息交互過(guò)程分析。

根據(jù)上述協(xié)議流程，以MSC 圖的形式給出發(fā)送端與接收機(jī)之間消息交互的過(guò)程，如圖1 所示。

圖1 信息交互MSC 圖

前面曾經(jīng)提到，因?yàn)樯蠈恿髅襟w的傳輸是基于底層的單向信道，也就是說(shuō)，發(fā)送端向接收機(jī)無(wú)論是傳輸信令消息還是音視頻的數(shù)據(jù)消息，接收機(jī)無(wú)論是接收成功或者接收失敗都不會(huì)反饋?lái)憫?yīng)信號(hào)給發(fā)送端，通信雙方無(wú)法進(jìn)行握手應(yīng)答。這樣就給建立鏈路連接以及傳輸數(shù)據(jù)帶來(lái)了很大的困難。本設(shè)計(jì)采取的解決方案是，發(fā)送端每隔一定時(shí)間重復(fù)發(fā)送通信控制信令幀，接收機(jī)采用狀態(tài)機(jī)控制接收流程。接收機(jī)在某一個(gè)狀態(tài)監(jiān)聽(tīng)鏈路，當(dāng)收到通信鏈路傳來(lái)的該狀態(tài)對(duì)應(yīng)的信令幀時(shí)，進(jìn)行數(shù)據(jù)處理。若接收機(jī)在該狀態(tài)收到其他的信令幀，接收機(jī)不接收該信令幀，將之拋棄，原地等待屬于它自己的信令幀。

2 IR－UWB 數(shù)據(jù)鏈路層方案的關(guān)鍵技術(shù)

(1)多線程控制設(shè)計(jì)。

流媒體，包括音視頻數(shù)據(jù)是連續(xù)的大量數(shù)據(jù)，需要保證其傳輸?shù)倪B續(xù)性、可靠性，要求播放數(shù)據(jù)的流暢性。由于無(wú)線UWB 通信系統(tǒng)無(wú)線信道自身環(huán)境的特點(diǎn)，會(huì)使得數(shù)據(jù)傳輸突然中斷，或者丟失數(shù)據(jù)幀。這時(shí)會(huì)中斷應(yīng)用層傳輸鏈路，使終端軟件死機(jī)。終端軟件采取多線程控制機(jī)制解決這個(gè)問(wèn)題。

線程是進(jìn)程中的一個(gè)實(shí)體，是被系統(tǒng)獨(dú)立調(diào)度和分派的基本單位。線程有就緒、阻塞和運(yùn)行3 種基本狀態(tài)［3］。當(dāng)通信鏈路發(fā)生故障時(shí)，終端軟件會(huì)因此被Windows 操作系統(tǒng)掛起，只有人為的在Windows 任務(wù)管理器中結(jié)束進(jìn)程，才能退出程序。采用多線程控制機(jī)制，當(dāng)出現(xiàn)這一問(wèn)題時(shí)，接收或者發(fā)送線程在等待一定時(shí)間后會(huì)自動(dòng)退出，或者通過(guò)父線程去中止子線程，終端程序不會(huì)終止。這時(shí)通信系統(tǒng)會(huì)要求重新發(fā)送或者接收一幀數(shù)據(jù)，繼續(xù)流媒體的傳輸。用這種方式可以避免因?yàn)殒溌穼觽鬏斪枞鴮?dǎo)致的程序完全癱瘓。

(2)多信道傳輸設(shè)計(jì)。

發(fā)送端與接收機(jī)雙方的控制命令數(shù)據(jù)量很小，因此PC 端直接調(diào)用API 接口通過(guò)USB 接口傳輸設(shè)備來(lái)發(fā)送或者接收信令幀。為了讓USB 接口上傳輸?shù)臄?shù)據(jù)簡(jiǎn)單化或者說(shuō)提高傳輸?shù)男剩绦驅(qū)⒁纛l數(shù)據(jù)傳輸和視頻數(shù)據(jù)傳輸分離，分別為它們創(chuàng)建不同的通信信道。在音視頻各自不同的信道上可以同時(shí)進(jìn)行多媒體數(shù)據(jù)的發(fā)送和接收。

演示系統(tǒng)在數(shù)據(jù)鏈路層將建立3 個(gè)通信信道，它們分別是:

BYTE mSignalChno 用來(lái)傳輸通信信令的信道

BYTE mAudioChno 用來(lái)傳輸音頻數(shù)據(jù)的信道

BYTE mVideoChno 用來(lái)傳輸視頻數(shù)據(jù)的信道

(3)接收狀態(tài)機(jī)控制設(shè)計(jì)。

狀態(tài)機(jī)是一個(gè)有向圖形，由一組節(jié)點(diǎn)和一組相應(yīng)的轉(zhuǎn)移函數(shù)組成軟件開(kāi)發(fā)的形式化方法。狀態(tài)機(jī)通過(guò)響應(yīng)一系列事件而“運(yùn)行”。每個(gè)事件都在屬于“當(dāng)前”節(jié)點(diǎn)的轉(zhuǎn)移函數(shù)的控制范圍內(nèi)，其中函數(shù)的范圍是節(jié)點(diǎn)的一個(gè)子集。函數(shù)返回“下一個(gè)”(也許是同一個(gè))節(jié)點(diǎn)。這些節(jié)點(diǎn)中至少有一個(gè)必須是終態(tài)，當(dāng)?shù)竭_(dá)終態(tài)，狀態(tài)機(jī)停止［4］。

由于UWB 通信系統(tǒng)采用單工通信機(jī)制，發(fā)送端得不到接收端的任何反饋信號(hào)。為解決這一問(wèn)題，終端程序采用狀態(tài)機(jī)來(lái)控制接收流程。終端程序有4 種轉(zhuǎn)換狀態(tài)，分別是IDLE、CONNECTING、CONNECTED、MEDIAOPENED。

IDLE 表示接收機(jī)處于初始化狀態(tài)。

CONNECTING 表示接收線程首次收到了流媒體數(shù)據(jù)連接信令，但尚未完成視頻回放初始化工作。

CONNECTED 表示主線程完成了視頻回放初始化工作，等待流格式。

MEDIAOPENED 設(shè)定了流格式，等待流數(shù)據(jù)。

接收機(jī)初始化后處于IDLE 狀態(tài)，當(dāng)接收機(jī)收到音視頻流連接信令幀后，接收機(jī)觸發(fā)媒體數(shù)據(jù)流連接，且狀態(tài)由IDLE 狀態(tài)轉(zhuǎn)換為CONNECTING 狀態(tài)(由于接收端可能連續(xù)收到多次音視頻流連接信令幀，為防止造成多次初始化，并且防止接收線程在主線程重初始化過(guò)程中，使用Filter 導(dǎo)致出錯(cuò)，增加了CONNECTING 狀態(tài))。當(dāng)媒體數(shù)據(jù)流建立連接后，接收機(jī)構(gòu)建本地用于接收與播放用的Filter，并將其狀態(tài)改為CONNECTED 狀態(tài)。當(dāng)接收機(jī)收到音視頻數(shù)據(jù)格式幀，并且接收機(jī)狀態(tài)為CONNECTED 時(shí)，將其狀態(tài)轉(zhuǎn)換為MEDIAOPENED 狀態(tài)。當(dāng)接收機(jī)收到音視頻數(shù)據(jù)幀，并且接收機(jī)狀態(tài)為MEDIAOPENED 時(shí)，將數(shù)據(jù)以Sample 的形式傳遞給下一級(jí)Filter 進(jìn)行渲染與播放。為了避免音頻數(shù)據(jù)和視頻數(shù)據(jù)的相互干擾，演示程序?qū)⒁纛l的接收與視頻的接收分離。

(4)數(shù)據(jù)鏈路層幀結(jié)構(gòu)。

數(shù)據(jù)鏈路層的幀格式分為兩種:一種是建立通信的信令幀;一種是攜帶流媒體的數(shù)據(jù)幀。無(wú)論是信令幀還是數(shù)據(jù)幀都具有同步幀頭、幀頭、同步幀尾這3 個(gè)部分。由于無(wú)線UWB 通信系統(tǒng)無(wú)線信道的特點(diǎn)，在傳輸過(guò)程中可能會(huì)丟失數(shù)據(jù)。為解決這一問(wèn)題，給音視頻數(shù)據(jù)加入同步幀頭以及同步幀尾，從而保證數(shù)據(jù)在傳輸過(guò)程中嚴(yán)格幀同步，提高系統(tǒng)性能，減少誤碼。

幀同步頭的格式為:

Const UCHAR pLnkPacketBegin［LEN_LINKSYNHEADER］={0x12，0x34，0x56，0x78};

幀同步尾的格式為:

Const UCHAR pLnkPacketEnd［LEN_LINKSYNEND］={0x09，0x87，0x65，0x43};

幀頭格式為:

typedef struct{

BYTE chno;信道號(hào)

BYTE type;分組類(lèi)型

DWORD length;分組PAYLOAD 長(zhǎng)度

}PacketHeader，*pPacketHeader

數(shù)據(jù)鏈路層通信信令有

cmd_DeviceConfig 傳輸發(fā)送端采集設(shè)備配置信息;

cmd_VideoStreamConnect 建立視頻流連接;

cmd_AudioStreamConnect 建立音頻流連接;

cmd_DisconnectRequest 取消連接。

信令幀格式如圖2 所示。

圖2 信令幀結(jié)構(gòu)

數(shù)據(jù)幀格式如圖3 所示。

圖3 數(shù)據(jù)幀結(jié)構(gòu)

數(shù)據(jù)幀攜帶音視頻媒體格式信息，以及音視頻數(shù)據(jù)流。其類(lèi)型定義如下所示:

組幀函數(shù)為:

long conFrame(UCHAR* frame，UCHAR* pAyload，SignalingPack* pSignal，long len，UCHAR cno，UCHAR type)

3 數(shù)據(jù)鏈路層傳輸流程

3.1 信令幀傳輸流程

如圖4 所示，用戶(hù)在發(fā)送端演示程序界面上點(diǎn)擊“Call”按鈕，程序中定義一個(gè)信令幀數(shù)據(jù)變量sig，發(fā)送端調(diào)用CallServer()函數(shù)發(fā)起對(duì)接收機(jī)的呼叫請(qǐng)求。

圖4 發(fā)送信令幀流程圖

(1)配置信令，將信令消息cmd_DeviceConfig 與發(fā)送端設(shè)備的配置信息，按照信令幀格式組幀處理。調(diào)用接口函數(shù)CUSBBase::UsbSnd()將信令幀通過(guò)USB接口設(shè)備向接收機(jī)發(fā)出。若發(fā)送錯(cuò)誤，則在應(yīng)用層顯示界面提示用戶(hù)發(fā)送失敗，請(qǐng)用戶(hù)重新發(fā)送。

(2)視頻連接信令，將信令消息cmd_VideoStream-Connect 按照信令幀格式組幀。調(diào)用接口函數(shù)CUSBBase::UsbSnd()將信令幀通過(guò)USB 接口設(shè)備向接收機(jī)發(fā)出。

(3)音頻連接信令，將信令消息cmd_AudioStreamConnect 按照信令幀格式組幀。調(diào)用接口函數(shù)CUSBBase::UsbSnd()將信令幀通過(guò)USB 接口設(shè)備向接收機(jī)發(fā)出。

3.2 音視頻數(shù)據(jù)幀發(fā)送流程

音視頻數(shù)據(jù)幀發(fā)送流程如圖5 所示。

圖5 音視頻數(shù)據(jù)幀發(fā)送流程圖

判斷發(fā)送端是否發(fā)送過(guò)流媒體的格式消息，若沒(méi)有發(fā)送過(guò)，說(shuō)明沒(méi)有建立通信鏈路，這時(shí)發(fā)送一次信令幀與音視頻格式幀，建立通信鏈路。然后每發(fā)送10 幀音視頻數(shù)據(jù)，重復(fù)發(fā)送一次信令幀與音視頻格式幀，確保單向通信鏈路的暢通。

判斷當(dāng)前傳輸?shù)牧髅襟w格式，如果是視頻格式數(shù)據(jù)，則將視頻格式數(shù)據(jù)組幀，調(diào)用USB 接口CUSBBase::UsbSnd()在視頻傳輸信道上傳輸。如果是音頻格式數(shù)據(jù)，則將音頻格式數(shù)據(jù)組幀，調(diào)用USB 接口CUSBBase::UsbSnd()在音頻傳輸信道上傳輸。發(fā)送端將流媒體格式數(shù)據(jù)發(fā)送成功后，同理按照上述機(jī)制向接收機(jī)傳輸視頻、音頻數(shù)據(jù)。

3.3 音視頻數(shù)據(jù)幀接收流程

音視頻數(shù)據(jù)幀接收流程如圖6 所示。

圖6 音視頻數(shù)據(jù)幀接收流程圖

當(dāng)接收機(jī)的本地音視頻Filter 構(gòu)建完成后，將用于USB 連接的句柄mpUsbFrame 通過(guò)Filter 的公共接口設(shè)置給USB Receiver，啟動(dòng)接收線程CUSBBase::XferInloop()，監(jiān)聽(tīng)視頻傳輸信道，接收視頻數(shù)據(jù)，同時(shí)將接收機(jī)的狀態(tài)更改為VIDEO CONNECTED，表示主線程完成了視頻回放初始化工作，等待視頻流格式數(shù)據(jù)。再將mpUsbFrame 設(shè)置給發(fā)送本地視頻數(shù)據(jù)的USB Sender。使得USB Sender 與USB Receiver 都指向mpUsbFrame。同理，實(shí)現(xiàn)音頻數(shù)據(jù)的接收。

4 結(jié)束語(yǔ)

IR－UWB 物理層通信設(shè)備只能進(jìn)行單工通信。為了支持該通信模式，本文給出了IR－UWB 演示系統(tǒng)數(shù)據(jù)鏈路層通信協(xié)議設(shè)計(jì)方案及音視頻數(shù)據(jù)傳輸方案。實(shí)現(xiàn)了在兩臺(tái)計(jì)算機(jī)之間通過(guò)高速UWB 通信系統(tǒng)傳輸流媒體。

［1］ CHEN K.Performance evaluation and enhancement of the CSMA/CA MAC Pro－tocol for 802.11 wireless LAN［C］.TaiPei，Taiwan:Proc IEEE PIMRC，1996.

［2］ 謝希仁.計(jì)算機(jī)網(wǎng)絡(luò)［M］.4 版.北京:電子工業(yè)出版社，2005.

［3］ WILLIAM S.操作系統(tǒng)－精髓與設(shè)計(jì)原理［M］.陳渝，譯.5 版.北京:電子工業(yè)出版社，2006.

［4］ 古天龍.軟件開(kāi)發(fā)的形式化方法［M］.北京:高等教育出版社，2005.