劉曉江 趙可心

摘要：突發(fā)自然災(zāi)害時(shí)，應(yīng)急通信對搶險(xiǎn)救災(zāi)工作至關(guān)重要。為了使基層救援隊(duì)快速獲取災(zāi)區(qū)的實(shí)際情況并安排下一步救援方案，設(shè)計(jì)并實(shí)現(xiàn)了基于網(wǎng)頁實(shí)時(shí)通信（Web Real-Time Communication，WebRTC）的應(yīng)急指揮調(diào)度系統(tǒng)，在救援現(xiàn)場通過服務(wù)級聯(lián)的方式快速構(gòu)建前后方通信指揮體系，通過采集終端實(shí)時(shí)獲取現(xiàn)場位置及音視頻信息并回傳給指揮部。介紹了系統(tǒng)總體架構(gòu)，對客戶端、前方服務(wù)和后方服務(wù)進(jìn)行了闡述，給出了各模塊功能及軟件實(shí)現(xiàn)方案。

關(guān)鍵詞：應(yīng)急通信；網(wǎng)頁實(shí)時(shí)通信；指揮調(diào)度

中圖分類號：TN91文獻(xiàn)標(biāo)志碼：A文章編號：1008-1739（2022）17-57-04

0引言

近年來，隨著一些突如其來災(zāi)害的侵襲，各級政府越來越意識到應(yīng)急能力建設(shè)的重要性，其中，應(yīng)急通信是災(zāi)害來臨后重要的一環(huán)，加強(qiáng)信息能力，有利于提高決策質(zhì)效[1]。

但是，目前基層應(yīng)急管理部門仍有一些急需解決的問題。例如，如何使基層先遣救援隊(duì)伍快速、準(zhǔn)確地獲取災(zāi)區(qū)的實(shí)際受災(zāi)情況，從而迅速安排下一步救援方案?；诖爽F(xiàn)狀，設(shè)計(jì)了基于網(wǎng)頁實(shí)時(shí)通信（Web Real-Time Communication，WebRTC）的應(yīng)急指揮調(diào)度系統(tǒng)，在救援現(xiàn)場通過服務(wù)級聯(lián)的方式快速構(gòu)建前后方通信指揮體系。

應(yīng)急指揮調(diào)度系統(tǒng)將業(yè)務(wù)與現(xiàn)場通信場景深度融合，提供設(shè)備定位、一鍵通信、現(xiàn)場信息回傳和音視頻組會等應(yīng)急指揮功能，支持在救援現(xiàn)場迅速展開，實(shí)現(xiàn)分鐘級開設(shè)，從根本上解決了區(qū)縣級救援部門技術(shù)人員不足、裝備便攜性差、設(shè)備配置繁瑣以及建設(shè)資金短缺等問題，提高現(xiàn)場應(yīng)急通信[2-3]保障效率，為救援指揮提供網(wǎng)絡(luò)支撐。

1系統(tǒng)總體設(shè)計(jì)

本系統(tǒng)由客戶端、前方服務(wù)和后方服務(wù)3部分組成，如圖1所示。從部署場景來看，分為后方指揮中心、現(xiàn)場指揮部和一線救援現(xiàn)場。當(dāng)災(zāi)害發(fā)生，救援人員首先會攜帶部署了前方服務(wù)的便攜式現(xiàn)場指揮平臺趕赴現(xiàn)場，搭建現(xiàn)場指揮部。救援現(xiàn)場通過自組網(wǎng)[4]形成一個(gè)局域網(wǎng)，前方服務(wù)和所有采集終端通過此局域網(wǎng)連接起來，一線救援人員攜帶安裝了客戶端的各種采集終端（執(zhí)法記錄儀、單兵和無人機(jī)）奔赴一線救援現(xiàn)場，客戶端實(shí)時(shí)采集救援現(xiàn)場音視頻，再通過WebRTC技術(shù)回傳給現(xiàn)場指揮部，實(shí)現(xiàn)現(xiàn)場指揮部和一線救援現(xiàn)場音視頻的互通。除了現(xiàn)場指揮部，本系統(tǒng)還包含后方指揮中心，后方指揮中心和前方指揮部經(jīng)互聯(lián)網(wǎng)實(shí)現(xiàn)互聯(lián)互通，前方服務(wù)搭建完成后根據(jù)需要通過路由器和后方服務(wù)建立連接，然后前方指揮部通過私網(wǎng)穿越技術(shù)將現(xiàn)場視頻推送給后方指揮中心。系統(tǒng)的主要功能———音視頻傳輸是基于WebRTC進(jìn)行設(shè)計(jì)。WebRTC是一種Web瀏覽器原生支持的點(diǎn)對點(diǎn)進(jìn)行實(shí)時(shí)音視頻通信及通用數(shù)據(jù)傳輸?shù)募夹g(shù)。媒體的傳送部分使用ICE（Interactive Session Establishment）技術(shù)，支持對4種類型NAT（Network Address Translation）或防火墻的穿透，實(shí)現(xiàn)點(diǎn)對點(diǎn)、點(diǎn)對多點(diǎn)等多種方式媒體通路的建立和傳送[5]。

2客戶端

客戶端是呈現(xiàn)系統(tǒng)業(yè)務(wù)的上層應(yīng)用，分為后方指揮客戶端、指揮客戶端和移動客戶端，分別部署于指揮中心、現(xiàn)場指揮部和救援現(xiàn)場3個(gè)場景。

2.1后方指揮客戶端

后方指揮客戶端部署于后方應(yīng)急管理用戶的指揮中心，用于對現(xiàn)場的統(tǒng)一指揮和協(xié)調(diào)調(diào)度。后方指揮客戶端功能主要是和前方建立通信、查看現(xiàn)場視頻。

2.2前方指揮客戶端

前方指揮客戶端包含指揮客戶端和移動客戶端，部署于現(xiàn)場指揮部，即根據(jù)災(zāi)害事故需要，臨時(shí)開設(shè)的用于災(zāi)害事故現(xiàn)場附近的指揮場所，用于指揮調(diào)度應(yīng)急救援力量和資源。指揮客戶端運(yùn)行于現(xiàn)場指揮平臺，包含“GIS調(diào)度”和“監(jiān)控調(diào)度”2個(gè)界面，“GIS調(diào)度”基于百度離線地圖實(shí)現(xiàn)，地圖上通過添加標(biāo)注來顯示終端位置和在線離線狀態(tài)，點(diǎn)擊標(biāo)注發(fā)起調(diào)閱；“監(jiān)控調(diào)度”可以同時(shí)調(diào)閱4路移動端視頻。指揮員使用前方指揮客戶端可根據(jù)需要隨時(shí)調(diào)配現(xiàn)場終端資源，掌控現(xiàn)場指揮的全要素。

指揮客戶端基于VUE框架開發(fā)，移動客戶端通過原生+H5混合開發(fā)，2種客戶端共用前端部分，與服務(wù)端通過websocket[6]連接。

2.3移動客戶端

移動客戶端安裝在多模終端或者單兵圖傳設(shè)備，單兵終端可以通過HDMI外接無人機(jī)。移動客戶端承擔(dān)了現(xiàn)場災(zāi)情匯報(bào)、指令接收等任務(wù)。功能主要包含上報(bào)位置和采集現(xiàn)場視頻向服務(wù)端傳輸高清視頻。音視頻編解碼采用硬編碼，支持主流視頻格式和音頻格式。

3前方服務(wù)

前方服務(wù)為現(xiàn)場各類客戶端提供業(yè)務(wù)支撐，主要包含終端配置模塊、業(yè)務(wù)控制模塊和媒體服務(wù)模塊。

3.1終端配置模塊

終端配置模塊主要負(fù)責(zé)對終端賬號進(jìn)行配置和管理。不同的客戶端軟件通過賬號注冊到服務(wù)器上，才能進(jìn)行各項(xiàng)業(yè)務(wù)流程，賬號分為業(yè)務(wù)調(diào)度類、指揮終端類和移動終端類，可進(jìn)行分組管理，不同組的賬號互相不可見，互不影響。指揮終端類可設(shè)置優(yōu)先級，同一組內(nèi)，在鏈路資源緊張的情況下，高級別指揮客戶端可以強(qiáng)拆低級別的視頻調(diào)閱業(yè)務(wù)。

本系統(tǒng)配置模塊基于SpringMVC框架開發(fā)，可通過Web界面實(shí)現(xiàn)對終端賬號資源的管理與維護(hù)。

3.2業(yè)務(wù)控制模塊

業(yè)務(wù)控制模塊是系統(tǒng)的核心模塊，主要負(fù)責(zé)業(yè)務(wù)的邏輯控制、實(shí)現(xiàn)視頻調(diào)閱和組會等業(yè)務(wù)功能。

業(yè)務(wù)控制模塊分為坐席接入層和業(yè)務(wù)控制層。坐席接入層實(shí)現(xiàn)調(diào)度臺的接入、賬號管理及權(quán)限管理，完成業(yè)務(wù)控制層和不同賬號之間的消息轉(zhuǎn)發(fā)；業(yè)務(wù)控制層提供業(yè)務(wù)邏輯處理服務(wù)，采用room機(jī)制管理業(yè)務(wù)單元，使用有限狀態(tài)機(jī)控制業(yè)務(wù)邏輯。

視頻調(diào)閱和組會均采用會議模型的設(shè)計(jì)思想，調(diào)閱是和一個(gè)移動終端組會，分發(fā)移動終端的視頻，會議是和多個(gè)移動終端組會，分發(fā)所有在會終端的混屏畫面。

視頻調(diào)閱主要分為指揮端調(diào)閱多個(gè)采集終端（各調(diào)閱相互獨(dú)立）和多個(gè)指揮端調(diào)閱一個(gè)采集終端2種場景，基于此需求，采用資源池化機(jī)制，增加視頻調(diào)閱標(biāo)識。當(dāng)調(diào)閱資源標(biāo)識相同時(shí)，業(yè)務(wù)控制模塊通過媒體服務(wù)增加一路視頻調(diào)閱資源的分發(fā)（多調(diào)一）。若當(dāng)前業(yè)務(wù)控制模塊中沒有該視頻調(diào)閱標(biāo)識，媒體服務(wù)在業(yè)務(wù)控制模塊的控制下拉取一次視頻調(diào)閱資源（一調(diào)一或一調(diào)多）。

調(diào)閱一個(gè)移動客戶端的基本流程如圖2所示。

①指揮客戶端發(fā)送調(diào)閱請求，業(yè)務(wù)控制模塊收到請求后向媒體服務(wù)器申請資源，申請資源成功后，將申請的room ID返回給指揮客戶端。

②業(yè)務(wù)控制模塊向媒體服務(wù)器申請成員資源，申請資源成功后，將①中的room ID發(fā)送給移動客戶端。

③指揮客戶端收到room ID后，與媒體服務(wù)器進(jìn)行媒體協(xié)商，設(shè)置sdp offer為發(fā)送音頻，接收音視頻，協(xié)商完成后將指揮客戶端的媒體元素的ID發(fā)送給業(yè)務(wù)控制模塊。

④移動客戶端收到room ID后，與媒體服務(wù)器進(jìn)行媒體協(xié)商，設(shè)置sdp offer為發(fā)送音視頻，接收音頻，協(xié)商完成后將移動客戶端的媒體元素的ID發(fā)送給業(yè)務(wù)控制模塊。

⑤業(yè)務(wù)控制模塊收到2個(gè)媒體元素的ID后，向媒體服務(wù)器發(fā)送消息連接2個(gè)媒體元素。

⑥2個(gè)客戶端媒體流連接成功，調(diào)閱完成。

當(dāng)一個(gè)指揮客戶端調(diào)閱多個(gè)移動客戶端，即進(jìn)行多次如圖2所示的流程。當(dāng)多個(gè)指揮客戶端調(diào)閱一個(gè)移動客戶端，在指揮客戶端發(fā)送調(diào)閱請求后，業(yè)務(wù)控制模塊不再向媒體服務(wù)器申請資源，而是將移動客戶端已在的room ID返回給指揮客戶端，并向指揮客戶端分發(fā)移動客戶端的視頻。

組會流程和調(diào)閱流程基本相同，主要區(qū)別是第②步，組會會向多個(gè)移動客戶端發(fā)送room ID，多個(gè)移動客戶端收到room ID后，各自和媒體服務(wù)進(jìn)行媒體協(xié)商然后入會，媒體服務(wù)模塊將入會成功的移動終端的視頻進(jìn)行混屏，業(yè)務(wù)控制模塊再把混屏畫面分發(fā)給指揮端。

3.3媒體服務(wù)模塊

媒體服務(wù)是系統(tǒng)的媒體核心，接收以SIP為載體的控制核心的指令，對音視頻進(jìn)行匯聚、處理和分發(fā)，媒體服務(wù)器功能包括群組通信、轉(zhuǎn)碼、混合和視聽流的路由。媒體服務(wù)器中的一個(gè)重要概念是媒體管道，媒體管道是一系列媒體元素的鏈接，其中一個(gè)媒體元素的輸出流被送到一個(gè)或多個(gè)其他媒體元素，媒體元素是封裝特定媒體功能的模塊，例如RTP媒體元素和WebRTC媒體元素等，本系統(tǒng)用到的主要是WebRTC媒體元素。

媒體服務(wù)中關(guān)于音視頻處理的關(guān)鍵技術(shù)有MCU布局算法、語音降噪算法、語音活性檢測算法和動態(tài)幀率調(diào)整策略。會議中將多個(gè)成員的畫面合成為一個(gè)畫面輸出，媒體引擎采用的自調(diào)整算法根據(jù)參與混屏的成員數(shù)，自動調(diào)整畫面的布局。語音降噪算法由基于WebRTC插件開發(fā)的音頻優(yōu)化組件實(shí)現(xiàn)，將帶有噪聲的音頻流送入組件，對音頻流進(jìn)行降噪，實(shí)現(xiàn)了對音頻流的優(yōu)化處理，提升了音頻質(zhì)量。語音活性檢測算法通過音頻過濾組件和語音活動檢測（Voice Activity Detection，VAD）模塊實(shí)現(xiàn)，音頻過濾組件用于音頻流的實(shí)時(shí)監(jiān)測，VAD模塊用于初步的語音活性檢測，上層模塊依據(jù)音頻過濾組件提供的實(shí)時(shí)音頻參數(shù)和VAD模塊提供的語音決策，執(zhí)行混音優(yōu)選算法進(jìn)行混音，并進(jìn)行說話者上報(bào)及說話者的實(shí)時(shí)更新。動態(tài)幀率調(diào)整策略是視頻發(fā)送端根據(jù)接收端的帶寬估計(jì)等參數(shù)動態(tài)調(diào)整視頻發(fā)送的碼率和幀率，當(dāng)網(wǎng)絡(luò)條件好時(shí)，碼率和幀率會增大；反之，碼率和幀率則會降低，以快速且高解析度地適應(yīng)不斷變化的網(wǎng)絡(luò)環(huán)境。另外，媒體服務(wù)采用靜態(tài)JitterBuffer，將緩存報(bào)文個(gè)數(shù)設(shè)置為無限大的固定值，以優(yōu)化網(wǎng)絡(luò)帶寬低的時(shí)候視頻卡頓的情況，保證媒體流順暢平穩(wěn)處理。

4后方服務(wù)

后方服務(wù)和前方服務(wù)的組成基本相同，但是后方服務(wù)部署于互聯(lián)網(wǎng)，只管理后方指揮客戶端，不直接和現(xiàn)場各類終端通信，而是和前方服務(wù)建立連接，由前方服務(wù)推送現(xiàn)場的音視頻。前后方服務(wù)首先通過TCP建立連接，后方服務(wù)作為TCP Server，前方服務(wù)作為TCP Client，前方服務(wù)和后方服務(wù)建立連接后，后方服務(wù)根據(jù)前方服務(wù)的IP信息發(fā)起調(diào)閱。

3.3節(jié)中介紹了媒體服務(wù)器的一個(gè)特征———媒體管道，前后方媒體流的傳輸就是利用這種特性，將前后方媒體服務(wù)器鏈接成一個(gè)包含多個(gè)媒體元素的媒體管道來傳輸音視頻，如圖3所示。后方指揮中心調(diào)閱前方視頻的關(guān)鍵流程，如圖4所示。

①后方指揮客戶端向后方服務(wù)發(fā)送調(diào)閱請求，后方業(yè)務(wù)控制模塊收到請求后向媒體服務(wù)器申請資源，申請資源成功后，將申請的room ID返回給指揮客戶端。

②指揮客戶端收到room ID后和后方媒體服務(wù)器進(jìn)行媒體協(xié)商，生成代表本端的WebRTC媒體元素，然后將ID發(fā)送后方業(yè)務(wù)控制模塊。

③后方業(yè)務(wù)控制模塊收到媒體元素的ID后，通過轉(zhuǎn)發(fā)服務(wù)發(fā)送給前方業(yè)務(wù)控制模塊。

④前方業(yè)務(wù)控制模塊收到后向媒體服務(wù)器申請資源，申請資源成功后，將申請的room ID發(fā)送給前方指揮客戶端。

⑤前方指揮客戶端收到room ID后，與前方媒體服務(wù)器進(jìn)行媒體協(xié)商，生成代表本端的WebRTC媒體元素，然后將ID發(fā)送前方業(yè)務(wù)控制模塊。

⑥前方業(yè)務(wù)控制模塊再通過轉(zhuǎn)發(fā)服務(wù)將媒體元素ID發(fā)送給后方業(yè)務(wù)控制模塊，轉(zhuǎn)發(fā)服務(wù)將前后方2個(gè)媒體元素連接，然后通過ICE技術(shù)進(jìn)行私網(wǎng)穿越[7]，至此前后方2個(gè)指揮客戶端媒體流連接成功。

⑦最后，前方指揮客戶端邀請前方移動客戶端入會，前方服務(wù)端將混屏后的媒體流發(fā)送給后方。

5結(jié)束語

應(yīng)急指揮調(diào)度系統(tǒng)在救援現(xiàn)場通過服務(wù)級聯(lián)的方式快速構(gòu)建前后方通信指揮體系，實(shí)現(xiàn)了在低帶寬、高時(shí)延、高抖動的不穩(wěn)定鏈路情況下的音視頻高質(zhì)量穩(wěn)定傳輸，保證了指揮部和救援現(xiàn)場的實(shí)時(shí)通信。系統(tǒng)重平臺、輕前端，終端輕松便攜，操作簡單，一張圖實(shí)現(xiàn)指揮，滿足應(yīng)急通信的大部分使用需求，在應(yīng)急通信行業(yè)中有廣泛地應(yīng)用前景。

但是，系統(tǒng)還有一些不足，目前支持的終端資源類型較單一，后續(xù)將接入更多類型的終端，例如監(jiān)控?cái)z像頭和手環(huán)等，豐富業(yè)務(wù)場景。

參考文獻(xiàn)

[1]翟琳.加強(qiáng)應(yīng)急能力建設(shè)，守護(hù)城市安全[N].中國應(yīng)急管理報(bào)，2022-03-10（2）.

[2]楊東曉.信息化技術(shù)在消防指揮中的應(yīng)用[J].消防界（電子版），2022，8（3）：52-54.

[3]周雄偉.新一代應(yīng)急通信系統(tǒng)發(fā)展展望[J].通信技術(shù)，2022，55（1）：1-6.

[4]李溯，魏書精，羅斯生，等.窄帶無線自組網(wǎng)在森林火災(zāi)現(xiàn)場應(yīng)急通信中的應(yīng)用研究[J].新農(nóng)業(yè)，2021（14）：56-59.

[5]付斌，楊鑫，王松，等.WebRTC技術(shù)研究及其應(yīng)用[J].電信科學(xué)，2013，29（9）：108-112.

[6]邵其專，蔣迪，莫熙.基于WebSocket技術(shù)面向電力調(diào)度的即時(shí)通信系統(tǒng)[J].電子設(shè)計(jì)工程，2020，28（6）：144-148.

[7]楊金花.STUN技術(shù)通信問題的研究[J].電子設(shè)計(jì)程，2015，23（6）：92-94.