劉牧洲 關(guān) 蕾 周 晶 仇劍書 于 希

中國(guó)聯(lián)通研究院 北京 100176

引言

低空空域是指真實(shí)高度一千米及以下的可飛行區(qū)域[1]。低空空域的使用和管理如同我國(guó)中高空空域一般，需要遵循嚴(yán)格的審批與報(bào)備流程[2]。低空經(jīng)濟(jì)是以低空空域?yàn)橐劳?，以通航產(chǎn)業(yè)為主導(dǎo)，涉及低空飛行、航空旅游、支線客運(yùn)、通航服務(wù)、科研教育、跳傘、空中體育運(yùn)動(dòng)等眾多行業(yè)的經(jīng)濟(jì)概念[3]。

低空經(jīng)濟(jì)正式出現(xiàn)于今年年初由中共中央、國(guó)務(wù)院印發(fā)的《國(guó)家綜合立體交通網(wǎng)規(guī)劃綱要》中。該綱要指出“發(fā)展交通運(yùn)輸平臺(tái)經(jīng)濟(jì)、樞紐經(jīng)濟(jì)、通道經(jīng)濟(jì)、低空經(jīng)濟(jì)”，其中低空經(jīng)濟(jì)首次上升到國(guó)家規(guī)劃層面，堪稱意義重大。

無(wú)人機(jī)是低空應(yīng)用中極具代表性的載體之一，其已在諸如農(nóng)業(yè)植保、物流運(yùn)輸、應(yīng)急安防、能源巡檢、水域巡查、娛樂(lè)直播等行業(yè)場(chǎng)景中作為革新替代方案頻頻出現(xiàn)，并已逐步催生出“無(wú)人機(jī)+行業(yè)應(yīng)用”的全新產(chǎn)業(yè)發(fā)展模式，有望為泛在低空市場(chǎng)經(jīng)濟(jì)注入新活力。然而，在無(wú)人機(jī)結(jié)合典型行業(yè)應(yīng)用的整體良好發(fā)展背景下，以測(cè)控、監(jiān)管、數(shù)據(jù)閉塞等為首的舊有痛點(diǎn)問(wèn)題也持續(xù)為其商用發(fā)展帶來(lái)不可忽視的負(fù)面影響，因此亟需通過(guò)技術(shù)創(chuàng)新予以解決。

第五代蜂窩通信技術(shù)(5G)具備了大帶寬、低延時(shí)、抗干擾、廣接入、多波束指向等鮮明特點(diǎn)，可天然賦予網(wǎng)聯(lián)化無(wú)人機(jī)包括高清實(shí)時(shí)數(shù)圖傳輸、遠(yuǎn)程低時(shí)延控制、全生命周期監(jiān)管、精準(zhǔn)位置定位在內(nèi)的四大實(shí)際應(yīng)用級(jí)能力。

可以預(yù)見(jiàn)，5G網(wǎng)絡(luò)技術(shù)與無(wú)人機(jī)創(chuàng)新業(yè)務(wù)的融合，將有利于兩者互惠互哺式的共同發(fā)展。5G網(wǎng)絡(luò)技術(shù)憑借自身特性，可將無(wú)人機(jī)核心的測(cè)控及數(shù)據(jù)傳輸服務(wù)帶至全新高度上，并有助于無(wú)人機(jī)創(chuàng)新業(yè)務(wù)向垂直行業(yè)和特定場(chǎng)景進(jìn)行滲透。相應(yīng)地，無(wú)人機(jī)創(chuàng)新業(yè)務(wù)必將成為5G網(wǎng)絡(luò)技術(shù)應(yīng)用的重要分支，為5G網(wǎng)絡(luò)未來(lái)發(fā)展注入新動(dòng)能。

無(wú)人機(jī)應(yīng)用數(shù)據(jù)可大致分為視頻和測(cè)控兩類。其中，視頻數(shù)據(jù)作為無(wú)人機(jī)行業(yè)應(yīng)用的最主要價(jià)值之一，其能否可靠有效傳輸一直備受關(guān)注。在傳統(tǒng)無(wú)人機(jī)作業(yè)時(shí)，所采集的視頻數(shù)據(jù)通常是借助微波通信鏈路或存儲(chǔ)至SD卡中待任務(wù)完成后導(dǎo)出的方式。在5G網(wǎng)絡(luò)廣覆蓋的大環(huán)境下，無(wú)人機(jī)在視頻業(yè)務(wù)傳輸上的需求與日俱增。其中，實(shí)時(shí)視頻傳輸對(duì)于要求低至毫秒級(jí)的遠(yuǎn)程控制技術(shù)將起到有利的輔助作用，因此對(duì)視頻傳輸?shù)膶?shí)時(shí)性也愈發(fā)嚴(yán)苛。由于5G網(wǎng)絡(luò)大帶寬特性，無(wú)人機(jī)對(duì)于實(shí)時(shí)視頻的清晰度要求已經(jīng)達(dá)到了1080p以上。在5G通信鏈路串聯(lián)的網(wǎng)聯(lián)無(wú)人機(jī)體系中，傳統(tǒng)無(wú)人機(jī)存在的時(shí)效性差、傳輸質(zhì)量低等固有問(wèn)題已得到了明顯的改善。本文所論述的相關(guān)流媒體協(xié)議正是決定了在“互聯(lián)網(wǎng)公路”上以何種方式運(yùn)輸?shù)母静呗?，流媒體技術(shù)水平的高低決定著整個(gè)過(guò)程中用戶體驗(yàn)的好壞，其將最終確保視頻數(shù)據(jù)的流轉(zhuǎn)可以實(shí)現(xiàn)應(yīng)用需求下的最理想效果[4]。

1 流媒體協(xié)議介紹與優(yōu)劣淺析

流媒體是指在Internet/Intranet中使用流式傳輸技術(shù)的連續(xù)時(shí)基媒體，如：音頻、視頻或多媒體文件。流式媒體在播放前并不下載整個(gè)文件，只將開(kāi)始部分內(nèi)容存入內(nèi)存，流式媒體的數(shù)據(jù)流隨時(shí)傳送隨時(shí)播放，只是在開(kāi)始時(shí)有一些延遲。流媒體實(shí)現(xiàn)的關(guān)鍵技術(shù)就是流式傳輸。流媒體具有明顯的優(yōu)點(diǎn)：由于不需要將全部數(shù)據(jù)下載，因此等待時(shí)間可以大大縮短；由于流文件往往小于原始文件的數(shù)據(jù)量，并且用戶也不需要將全部流文件下載到硬盤，從而節(jié)省了大量的磁盤空間；由于采用了實(shí)時(shí)傳輸協(xié)議，更加適合動(dòng)畫、視音頻在網(wǎng)上的實(shí)時(shí)傳輸。

1.1 RTMP協(xié)議

RTMP(Real Time Messaging Protocol)是一種版權(quán)歸屬于Adobe公司、建立在TCP傳輸層協(xié)議之上、默認(rèn)使用非公共端口1935的TCP/IP體系內(nèi)的應(yīng)用層協(xié)議[5]。通常，在終端與服務(wù)器側(cè)建立TCP鏈接完成后，RTMP協(xié)議會(huì)要求這兩端建立“握手式”的RTMP Connection鏈接，并在傳輸中將協(xié)議規(guī)定的基本數(shù)據(jù)單元消息拆分成若干可動(dòng)態(tài)變更大小的消息塊，這些分割后的消息塊最終借助TCP鏈接通道進(jìn)行傳輸，并在末端被按序拼接成流媒體數(shù)據(jù)，通過(guò)Flash插件進(jìn)行播放。

RTMP在傳輸時(shí)延表現(xiàn)上要好于基于HTTP的流媒體協(xié)議，且其穩(wěn)定性較為可靠，并有廣泛的實(shí)施基礎(chǔ)，國(guó)內(nèi)多數(shù)平臺(tái)和編解碼設(shè)備均支持RTMP流格式。

然而，隨著Adobe公司停止更新Flash，以及越來(lái)越多的游覽器不再支持或棄用Flash，導(dǎo)致RTMP的泛用性開(kāi)始逐步降低?；赥CP底層傳輸協(xié)議也會(huì)存在連接態(tài)較差時(shí)的緩存累積所造成的時(shí)延增加問(wèn)題。此外，其所采用的非公用1935端口亦有難以通過(guò)防火墻的缺陷。在正式版本中，RTMP協(xié)議不能支持HEVC(H.265)/AV1等新一代視頻編碼標(biāo)準(zhǔn)。

如表1所示，RTMP協(xié)議也存在多個(gè)變種方案。

表1 RTMP協(xié)議的多個(gè)變種協(xié)議

1.2 RTSP協(xié)議

RTSP(Real Time Streaming Protocol)是一種全公開(kāi)可建立在TCP或UDP(RTP)傳輸層協(xié)議之上的TCP/IP體系內(nèi)的應(yīng)用層協(xié)議。RTSP協(xié)議的工作原理是限定已構(gòu)建的TCP握手鏈接或RTP(在TCP/IP體系內(nèi)高于UDP傳輸層協(xié)議，但默認(rèn)配合RTCP控制協(xié)議采用UDP傳輸)通道，交織傳送其保障信息與流媒體數(shù)據(jù)到服務(wù)器側(cè)。但因RTSP協(xié)議規(guī)定保障信息要與數(shù)據(jù)分至不同信道進(jìn)行傳輸，其對(duì)實(shí)施的環(huán)境要求尤為苛刻。

1.3 HLS協(xié)議

HLS(HTTP Live Streaming)是由美國(guó)蘋果公司提出的一種基于HTTP的流媒體協(xié)議[6]。HLS協(xié)議的工作原理是將完整的流媒體數(shù)據(jù)分割成一些固定大小的片流以及可以索引下載這些片流的以m3u8為后綴的播放列表。在播放時(shí)，終端會(huì)率先下載m3u8后綴的播放列表信息，然后根據(jù)其中描述按序下載片流并播放。在直播時(shí)，由于m3u8播放列表信息會(huì)實(shí)時(shí)更新，因此終端需要重復(fù)獲取該列表并按照最新內(nèi)容找到對(duì)應(yīng)片流進(jìn)行下載并播放。因此，在直播情況下，HLS協(xié)議所產(chǎn)生的時(shí)延要遠(yuǎn)超其他非HTTP鏈接方式的流媒體協(xié)議。

基于此，美國(guó)蘋果公司在HLS協(xié)議基礎(chǔ)上提出了低時(shí)延版本的LHLS協(xié)議(Low-latency HLS)。該協(xié)議的最主要變化在于m3u8播放列表的更新部分會(huì)以單獨(dú)增量信息形式被下載，免除了HLS協(xié)議對(duì)m3u8播放列表的重復(fù)下載情況。另外，LHLS協(xié)議采取片流實(shí)時(shí)封裝形式，減少了HLS協(xié)議下片流完整封裝后才可按序下載所產(chǎn)生的時(shí)延，使得直播延時(shí)進(jìn)一步被降低。

1.4 SRT協(xié)議

SRT(Secure Reliable Transport)是由跨國(guó)網(wǎng)絡(luò)視頻技術(shù)巨頭Haivision公司開(kāi)發(fā)的一種新式開(kāi)源流媒體協(xié)議，是一種新興的流媒體協(xié)議[7]。SRT協(xié)議的原理是基于UDP傳輸層協(xié)議，并加入ARQ、FEC等數(shù)據(jù)糾錯(cuò)恢復(fù)機(jī)制，充分實(shí)現(xiàn)了穩(wěn)定和快速的傳輸效果，并可進(jìn)一步兼容對(duì)稱加密(AES-128/256)來(lái)實(shí)現(xiàn)數(shù)據(jù)安全。其中，SRT協(xié)議的ARQ機(jī)制為選擇性重傳方式，當(dāng)網(wǎng)絡(luò)帶寬出現(xiàn)抖動(dòng)，丟包率上升時(shí)，該機(jī)制才會(huì)被觸發(fā)，相較于TCP丟包恢復(fù)機(jī)制極大節(jié)省了帶寬資源。

此外，SRT協(xié)議規(guī)定每10毫秒就會(huì)向數(shù)據(jù)發(fā)送方報(bào)送RTT(數(shù)據(jù)往返時(shí)延)、新增數(shù)據(jù)、數(shù)據(jù)包接收率及可用緩沖區(qū)大小等信息，來(lái)幫助判斷連續(xù)兩個(gè)數(shù)據(jù)包的間隔是否突破時(shí)延設(shè)定限制，若超過(guò)該限定值，則從傳遞列表中將其舍棄。

在擁有諸多優(yōu)點(diǎn)的同時(shí)，SRT協(xié)議由于其雙向點(diǎn)對(duì)點(diǎn)傳輸?shù)奶匦?，只適合于兩端間的高質(zhì)量低時(shí)延數(shù)據(jù)交互，而不適用于針對(duì)大數(shù)量級(jí)終端做流媒體數(shù)據(jù)分發(fā)。

1.5 RIST協(xié)議

RIST(Reliable Internet Stream Transport)是一種面向公網(wǎng)數(shù)據(jù)丟包問(wèn)題而被提出的通用性流媒體協(xié)議。該協(xié)議可支持雙向傳輸，但依舊延續(xù)了RTP傳輸協(xié)議的大部分特征，采用RTCP協(xié)議作為可靠傳輸?shù)谋Ｕ蠙C(jī)制。因此，RIST協(xié)議的初始版本需要建立兩路信息通道，一條用以傳輸RTCP控制信息，另一條則傳輸媒體流數(shù)據(jù)。同時(shí)，由于RIST協(xié)議沿用RTP協(xié)議的傳輸方式，使用IP地址和端口作為會(huì)話，導(dǎo)致服務(wù)端要通過(guò)不斷增加端口數(shù)量才能匹配更多的客戶端，且RIST并未定義視頻流標(biāo)識(shí)。

隨后，RIST協(xié)議進(jìn)行了大改，在初期版本基礎(chǔ)上增加多路數(shù)據(jù)復(fù)用傳輸信道、DTLS加密、數(shù)據(jù)空包刪除、可支持高比特率高延遲場(chǎng)景等功能，增加了該協(xié)議的可用性，但卻不能兼容初始版本。

1.6 QUIC協(xié)議

QUIC(Quick UDP Internet Connection)是基于UDP傳輸層協(xié)議的流媒體協(xié)議，有別于TCP鏈接的三次握手，其通過(guò)建立單個(gè)RTT的低時(shí)延鏈接，且在此之后的連接可復(fù)用實(shí)現(xiàn)無(wú)RTT的數(shù)據(jù)可靠傳輸。在擁塞控制機(jī)制上，QUIC協(xié)議在TCP協(xié)議基礎(chǔ)上進(jìn)行改進(jìn)，可做到擁塞控制的靈活調(diào)整，并適用嚴(yán)格遞增的數(shù)據(jù)包序號(hào)代替字節(jié)序號(hào)和ACK確認(rèn)機(jī)制，改善重傳歧義問(wèn)題[8]。QUIC協(xié)議不似TCP協(xié)議那樣，在終端IP地址和端口變更的時(shí)候，可以完成連接遷移，而無(wú)需新建鏈接。此外，QUIC協(xié)議采用FEC機(jī)制來(lái)實(shí)現(xiàn)數(shù)據(jù)糾錯(cuò)恢復(fù)，加強(qiáng)了數(shù)據(jù)傳輸?shù)目煽啃?，但亦?huì)對(duì)帶寬資源造成負(fù)擔(dān)。

1.7 WEBRTC協(xié)議

WEBRTC(Web Real Time Communications)是一種由美國(guó)谷歌公司研發(fā)的公開(kāi)流媒體協(xié)議。該協(xié)議可分別采用TCP或UDP協(xié)議進(jìn)行媒體流數(shù)據(jù)傳輸。但無(wú)論是哪種方式下的數(shù)據(jù)傳輸，WEBRTC協(xié)議都需要在發(fā)送端與接收端建立鏈接，并借助第三方信令服務(wù)器來(lái)進(jìn)行數(shù)據(jù)交互。WEBRTC協(xié)議支持AV1/HEVC(H.265)等新一代視頻編碼標(biāo)準(zhǔn)[9]。

另需說(shuō)明的是，WEBRTC協(xié)議的最大缺點(diǎn)在于其不支持多路并發(fā)媒體流數(shù)據(jù)至對(duì)端。

1.8 小結(jié)

依前所述，參照TCP/IP體系，可在傳輸層將所有流媒體協(xié)議分成基于TCP協(xié)議和基于UDP協(xié)議的兩大類別，并結(jié)合其在應(yīng)用層控制策略的異同及獨(dú)有功能特點(diǎn)詳細(xì)區(qū)分。如表2所示，以下為相關(guān)流媒體協(xié)議的分類及特征簡(jiǎn)述。

表2 主要流媒體協(xié)議分類及特征

2 泛在低空網(wǎng)絡(luò)環(huán)境及流媒體協(xié)議適用方案

在網(wǎng)聯(lián)無(wú)人機(jī)的系統(tǒng)架構(gòu)中，網(wǎng)聯(lián)無(wú)人機(jī)的終端模組和地面控制需均通過(guò)5G網(wǎng)進(jìn)行數(shù)據(jù)傳輸和控制指令傳輸，并通過(guò)云平臺(tái)服務(wù)器加載各類應(yīng)用場(chǎng)景。如圖1所示，5G網(wǎng)絡(luò)需提供從無(wú)線網(wǎng)到核心網(wǎng)的整體網(wǎng)絡(luò)解決方案，以適配各種復(fù)雜應(yīng)用場(chǎng)景的網(wǎng)絡(luò)實(shí)現(xiàn)。

圖1 網(wǎng)聯(lián)無(wú)人機(jī)系統(tǒng)架構(gòu)

服務(wù)趨于多元化的泛在低空應(yīng)用場(chǎng)景的5G蜂窩網(wǎng)絡(luò)可分為以下四種組建方案：1)公共網(wǎng)絡(luò)；2)專用網(wǎng)絡(luò)；3)地空同頻混合網(wǎng)絡(luò)；4)地空異頻混合網(wǎng)絡(luò)。但是，泛在低空環(huán)境下的5G網(wǎng)絡(luò)，通常會(huì)出現(xiàn)帶寬抖動(dòng)，站點(diǎn)間信號(hào)頻繁切換等問(wèn)題。因此除了區(qū)分不同的網(wǎng)絡(luò)環(huán)境，還需要對(duì)上述問(wèn)題進(jìn)行綜合考慮，提出與之相適應(yīng)的流媒體方案。

在依托地面5G蜂窩網(wǎng)絡(luò)為泛低空應(yīng)用提供接入和數(shù)據(jù)傳輸服務(wù)的公共網(wǎng)絡(luò)方案中，首要遵循以服務(wù)地面用戶及應(yīng)用為主的原則，這就決定了所有地面基站設(shè)施的天線朝向優(yōu)先針對(duì)地面做信號(hào)覆蓋。此方案能夠解決絕大多數(shù)的無(wú)人機(jī)行業(yè)應(yīng)用訴求，實(shí)現(xiàn)其在低空300米以下的蜂窩接入，從而進(jìn)行各類數(shù)據(jù)低時(shí)延可靠回傳。但在這種方案下，要著重考量無(wú)人機(jī)行業(yè)應(yīng)用所占5G蜂窩帶寬資源的多少。綜前所述，宜采用以下優(yōu)先級(jí)排序：SRT＞QUIC＞RIST＞W(wǎng)EBRTC＞其他。

在專用網(wǎng)絡(luò)方案中，因無(wú)需考慮5G蜂窩帶寬資源分配問(wèn)題，所以采用基于UDP或TCP傳輸?shù)牧髅襟w協(xié)議各有利弊，難以給出確切的優(yōu)先級(jí)排序。

地空同頻混合組網(wǎng)是指針對(duì)地面的蜂窩覆蓋與低空的蜂窩覆蓋采用相同頻段資源。在這樣的方案中，要首要解決地空間的信號(hào)互干擾問(wèn)題，因此所選用的流媒體協(xié)議應(yīng)以對(duì)帶寬資源影響較少為主，支持低時(shí)延穩(wěn)定傳輸為次。宜采用的優(yōu)先級(jí)排序與公共網(wǎng)絡(luò)方案中的結(jié)果類似。

地空異頻混合網(wǎng)絡(luò)，即地面使用現(xiàn)有公共蜂窩網(wǎng)絡(luò)信號(hào)進(jìn)行覆蓋，而空中則使用頻率相異的專用蜂窩網(wǎng)絡(luò)信號(hào)建立通信區(qū)域。終端在這樣的環(huán)境中，將不可避免地頻繁進(jìn)行網(wǎng)絡(luò)切換。由于網(wǎng)絡(luò)選擇計(jì)算復(fù)雜性高、網(wǎng)絡(luò)服務(wù)時(shí)間短、目標(biāo)網(wǎng)絡(luò)擁塞等原因，導(dǎo)致切換延遲高、切換次數(shù)多和切換中斷，嚴(yán)重影響流媒體服務(wù)的質(zhì)量和流暢度[10]。該方案下，需要考慮優(yōu)先采用基于UDP傳輸?shù)牧髅襟w協(xié)議，并且要具有一定的自適應(yīng)調(diào)整和抗干擾能力。優(yōu)先級(jí)排序大致如下：SRT＞QUIC＞RIST＞W(wǎng)EBRTC＞其他。

基于以上研究，在中國(guó)聯(lián)通5G(安陽(yáng))泛在低空測(cè)試基地，依托地面移動(dòng)網(wǎng)絡(luò)基礎(chǔ)設(shè)施搭建的5G測(cè)試環(huán)境進(jìn)行了流媒體協(xié)議技術(shù)指標(biāo)驗(yàn)證工作，具體驗(yàn)證方案如下：

①在拉流過(guò)程嘗試平臺(tái)側(cè)所支持的不同流媒體協(xié)議(QUIC/SRT/RIST/WebRTC/RTMP)；

②將視頻源數(shù)據(jù)通過(guò)HDMI接口傳輸?shù)?G機(jī)載終端，由后者完成編碼壓縮(H.264)和輸出清晰度調(diào)整(4K-3840×2160/1080P-1920×1080)；

③將分別驗(yàn)證經(jīng)由安陽(yáng)云服務(wù)器/阿里云服務(wù)器完成數(shù)據(jù)流轉(zhuǎn)，并在不同網(wǎng)絡(luò)連接方式下測(cè)試多組不同流媒體協(xié)議下的拉流效果，完成傳輸時(shí)延比對(duì)記錄。

驗(yàn)證結(jié)果表明：

1)在傳輸同等4K清晰度視頻條件下，各流媒體協(xié)議時(shí)延基本符合上述研究結(jié)論。

2)在傳輸同等1080P清晰度視頻條件下，各流媒體協(xié)議時(shí)延基本符合上述研究結(jié)論。

3 結(jié)語(yǔ)

隨著我國(guó)低空環(huán)境的逐步開(kāi)放，低空經(jīng)濟(jì)活動(dòng)的不斷多樣化和頻繁化，無(wú)人機(jī)應(yīng)用市場(chǎng)有望迎來(lái)飛速增長(zhǎng)。在這樣的背景下，視頻實(shí)時(shí)傳輸效果將成為衡量絕大多數(shù)5G網(wǎng)聯(lián)無(wú)人機(jī)應(yīng)用價(jià)值的主要指標(biāo)之一。選擇與5G網(wǎng)絡(luò)組建形式相適宜的流媒體協(xié)議，可有效保障實(shí)時(shí)流數(shù)據(jù)的可靠傳輸，實(shí)現(xiàn)最根本行業(yè)應(yīng)用的需求。一言以蔽之，流媒體協(xié)議會(huì)是控制5G網(wǎng)絡(luò)下的泛在低空應(yīng)用實(shí)現(xiàn)流媒體數(shù)據(jù)自傳輸?shù)匠尸F(xiàn)的最有利抓手。