遠(yuǎn)程駕駛交通工具的網(wǎng)絡(luò)時延分析

王立愷 劉維維 安媛

（1.徐州市公安局交通警察支隊(duì) 江蘇省徐州市 221000 2.徐州工程學(xué)院 江蘇省徐州市 221018）

1 引言

自動駕駛尚未完全成熟，遠(yuǎn)程駕駛卻具有廣泛的應(yīng)用場景。在生產(chǎn)方面，在惡劣環(huán)境與危險場所等駕駛員無法達(dá)到的區(qū)域，駕駛員無需親臨，就可駕駛礦車、重型汽車等有風(fēng)險的交通工具，還可以隨時輪換人力，交替休息，避免疲勞駕駛。在生活方面，人們遇到喝酒等不方便開車的情況時，可以讓駕駛員遠(yuǎn)程操作輕松送回車庫。車載端不再有駕駛員，提升了車輛的運(yùn)力，同時也避免了司機(jī)或乘客的違法犯罪行為。在防災(zāi)避險方面，駕駛員可以在山體滑坡、地震、火山噴發(fā)等災(zāi)難中，運(yùn)輸人員和物資。由于5G 的到來，基于5G 的業(yè)務(wù)標(biāo)準(zhǔn)正在走向商業(yè)部署，遠(yuǎn)程駕駛急需解決的高延遲和高丟包率問題將緩步解決?？梢灶A(yù)見，遠(yuǎn)程駕駛將極大提升操作效率并節(jié)省人力，并在未來大有可為。

對于車外無線通信，主流的方式包括了3G/4G、DSRC、RFID、ZigBee 等。近兩年，華為、谷歌等眾多企業(yè)都希望使汽車成為新一代互聯(lián)網(wǎng)設(shè)備，資本的涌入和5G 高速率、低時延、大連接的特點(diǎn)都使得蜂窩網(wǎng)絡(luò)成為主流技術(shù)，國內(nèi)外相關(guān)企業(yè)掀起了將5G 技術(shù)應(yīng)用于車車、車路通信的熱潮。

2 遠(yuǎn)程駕駛的參數(shù)傳輸需求

參數(shù)傳輸是指遠(yuǎn)程駕駛員和遠(yuǎn)程車輛用戶之間進(jìn)行通信，主要是將上述模擬參數(shù)傳輸給對方。遠(yuǎn)程駕駛具有一定的實(shí)時性。從駕駛艙提取的數(shù)據(jù)，是即時的狀態(tài)信息，若從控制端到車載端的時延是50ms，t1 時刻控制端發(fā)送報文m1 為方向盤右轉(zhuǎn)90 度，那么（t1+50）ms 時車輛方向盤就應(yīng)該處在90 度狀態(tài)。接著t2 時刻發(fā)送報文m2 為方向盤左轉(zhuǎn)360 度，但m2 在鏈路上丟失了，接收端（t2+50）后的某個時刻發(fā)送確認(rèn)報文，發(fā)送端則在（t2+100）ms后某時刻重傳報文，接著接收端在（t2+150ms）后某時刻接收到重傳。

對于高速行駛的汽車而言，150ms 后的駕駛情況已經(jīng)大為不同。若汽車時速為我國城市公路限速的40 公里每小時，則150ms 后汽車移動1.65m。在一臺小轎車差不多移動半個車身的距離之后，方向盤左轉(zhuǎn)360 度，無疑是非常危險的。因此對于遠(yuǎn)程駕駛而言，丟失報文的重傳是難以接受的。同理可知，延遲過高，車輛當(dāng)下所處的環(huán)境也會與發(fā)送的操縱指令要面臨的環(huán)境大相徑庭；丟包率高，會使得汽車控制的指令失序和控制不當(dāng)。

控制端依賴互聯(lián)網(wǎng)遠(yuǎn)程控制車載端，車載端依靠蜂窩網(wǎng)絡(luò)通信基站進(jìn)行傳輸，網(wǎng)絡(luò)環(huán)境不穩(wěn)定。由于NAT 轉(zhuǎn)換技術(shù)的存在，網(wǎng)絡(luò)穿透成為一個必要的選擇方案。NAT 技術(shù)在不同運(yùn)營商有不同的實(shí)現(xiàn)方案，簡單的是將內(nèi)網(wǎng)設(shè)備分配外網(wǎng)靜態(tài)IP，外部只要訪問此靜態(tài)IP，就可以與內(nèi)網(wǎng)對應(yīng)設(shè)備通信；較為嚴(yán)格的是為內(nèi)網(wǎng)設(shè)備分配固定的動態(tài)IP 與端口號，外部同樣有辦法訪問；最嚴(yán)格的NAT策略是，為內(nèi)網(wǎng)設(shè)備映射動態(tài)IP 與端口，并記錄與該端口通信的外部設(shè)備IP，其他設(shè)備不可訪問。

若某一方NAT 規(guī)范較為嚴(yán)格，雙方無法建立通信，遠(yuǎn)程駕駛

也就成了空談。為了節(jié)省成本，跨越公網(wǎng)的遠(yuǎn)程駕駛系統(tǒng)中，往往用具備公網(wǎng)IP 的中轉(zhuǎn)服務(wù)器作為跳板，雙方登錄成功之后，發(fā)送測試報文給中轉(zhuǎn)服務(wù)器。服務(wù)器每確認(rèn)連接雙方后，為雙方socket開辟消息緩存隊(duì)列，新建兩個線程，輪詢開始，一旦一方發(fā)送數(shù)據(jù)則轉(zhuǎn)發(fā)給另一方。將遠(yuǎn)程駕駛員的報文轉(zhuǎn)發(fā)給遠(yuǎn)程車輛用戶，同時將遠(yuǎn)程車輛用戶的報文發(fā)送給遠(yuǎn)程駕駛員。這樣雙方都感知不到中轉(zhuǎn)服務(wù)器的存在，卻可以對無公網(wǎng)IP 的設(shè)備進(jìn)行通信，他們都存在于同一個私人虛擬局域網(wǎng)中。

在近距離遠(yuǎn)程駕駛中，參數(shù)傳輸?shù)牧硪环N模式是局域網(wǎng)內(nèi)組播通信，常用于車聯(lián)網(wǎng)內(nèi)部網(wǎng)絡(luò)。由于ROS 系統(tǒng)普遍應(yīng)用于當(dāng)前無人駕駛行業(yè)，在ROS 系統(tǒng)中人們一般都采用了LCM 傳輸協(xié)議（Lightweight Communications and Marshalling）用于信息傳輸，速度較快而且封裝簡易。我們也采用LCM 作為局域網(wǎng)內(nèi)的組播通信，實(shí)現(xiàn)局域網(wǎng)內(nèi)的遠(yuǎn)程駕駛。lcm-gen 工具可以根據(jù)不同編程語言生成與其適應(yīng)的數(shù)據(jù)結(jié)構(gòu)，利用它來生成自定義的駕駛控制數(shù)據(jù)結(jié)構(gòu)。LCM 采用了組播推送-訂閱模式。在控制端，初始化按鈕中嵌入LCM 消息體初始化代碼，設(shè)置組播地址和生命周期（最大跳數(shù)），前者是控制端設(shè)置訂閱地址，只有車載端訂閱對應(yīng)地址才能接收消息，后者確定該組播報文經(jīng)過多少跳之后自動刪除。同時將5ms 周期計時器和發(fā)送信息函數(shù)綁定在信號槽。

3 時延測試和性能分析

遠(yuǎn)程駕駛傳輸協(xié)議對參數(shù)傳輸而言至關(guān)重要，控制信息在10字節(jié)以內(nèi)，加上協(xié)議本身的報文首部，我們需要讓協(xié)議在傳輸 的報文過程中保持低丟包率和低延時，我們可以利用UDP、TCP 傳輸在同一時間與遠(yuǎn)程駕駛協(xié)議傳輸同一數(shù)據(jù)，以此測試出協(xié)議的可靠性。

測試條件：位于北京、帶寬為1Mbps、操作系統(tǒng)為Ubuntu 18.04 公網(wǎng)服務(wù)器，作為中轉(zhuǎn)服務(wù)器；位于湖南、帶寬為100Mbp、操作系統(tǒng)為Windows 10 的PC，作為車載端與控制端的服務(wù)器。

測試方法：控制端將固定大小的1000 個指令數(shù)據(jù)以及發(fā)送時間戳通過不同協(xié)議傳送，傳輸?shù)街修D(zhuǎn)服務(wù)器，中轉(zhuǎn)服務(wù)器轉(zhuǎn)發(fā)到車載端，由于車載端與控制端為同一臺機(jī)器，他們的當(dāng)前時間是一致，這樣也避免的對時問題。由此記錄協(xié)議發(fā)送時間、時延采樣值，通統(tǒng)計數(shù)據(jù)計算均值、方差、發(fā)送總時間，以測試他們的發(fā)送性能。

測試過程：

TCP 測試為例，由于控制端需要按固定頻率讀取指令，TCP 發(fā)送該報文時，按照一定的頻率來傳輸。網(wǎng)絡(luò)環(huán)境良好情況下，當(dāng)周期時間高于ACK 報文的發(fā)送時間，流量控制和擁塞控制將不起作用，TCP 退化為UDP。TCP 按照周期30ms 的頻率發(fā)送數(shù)據(jù)，不產(chǎn)生丟包情況，往返時延采樣均值為74.537ms，但由于等待了30ms，可見當(dāng)前網(wǎng)絡(luò)端到端延遲至多為45ms。表1 為TCP 測試統(tǒng)計表。

UDP 測試中，因?yàn)槎〞r的TCP 在時延比發(fā)送周期低的情況下會退化成UDP，所以我們不再選用TCP 來測試網(wǎng)絡(luò)性能。由于UDP 并未規(guī)定以何種發(fā)送速率發(fā)送數(shù)據(jù)，如果不阻塞一段時間發(fā)送，路由器很快就會排隊(duì)阻塞，所以我們使用間隔固定時間來測試UDP。經(jīng)過測試，發(fā)送周期太長或太短都不能盡如人意。最終我們確定三組數(shù)據(jù)來說明當(dāng)前網(wǎng)絡(luò)傳輸?shù)奶攸c(diǎn)，分別以20 毫秒、30 毫秒、35 毫秒為間隔。如表2 所示。

表1：TCP 測試數(shù)據(jù)統(tǒng)計表

表2：UDP 測試數(shù)據(jù)統(tǒng)計表

表3：遠(yuǎn)程駕駛協(xié)議時間測試數(shù)據(jù)表

表4：遠(yuǎn)程駕駛協(xié)議改進(jìn)，時間測試數(shù)據(jù)表

從測試結(jié)果可以看出發(fā)送周期過小，使得鏈路上隊(duì)列阻塞，丟包率變大。隨發(fā)送周期變大，丟包率減小，時延也因此升高。周期再度增大，自身等待時延就成了影響報文時延和發(fā)送總時長的主要因素。遠(yuǎn)程駕駛要求傳輸時延低，發(fā)送頻率高，在當(dāng)前網(wǎng)絡(luò)條件下，30ms 的周期在UDP 測試中表現(xiàn)最好，它的指令只需平均大約38ms 就可以到達(dá)車載端，且無丟包，方差最小，網(wǎng)絡(luò)傳輸狀態(tài)也最穩(wěn)定。其次是20ms，發(fā)送時間最短，雖有丟包，但滿足了時延低、頻率高的特點(diǎn)。

在外網(wǎng)中轉(zhuǎn)操作參數(shù)Round-Trip 時延測試中，按照初始參數(shù)PacingRate 為20ms，指令需31ms 就可到達(dá)車載端，發(fā)送總時間短，缺點(diǎn)是方差太大，從表3 可以看出，增大帶寬估計的AdjustSize 值相對于減小帶寬估計的太小，而且調(diào)整網(wǎng)絡(luò)參數(shù)的頻率太低。雖然時延較低，但網(wǎng)絡(luò)發(fā)送窗口變成了“慢擴(kuò)大、快縮小”，造成收斂速度慢，時延不穩(wěn)定?？傮w上比上述30ms 為周期UDP 不相伯仲，遠(yuǎn)程駕駛協(xié)議的優(yōu)點(diǎn)是自發(fā)地調(diào)整發(fā)送頻率，而UDP 不會知道最佳周期是多少。

4 改進(jìn)措施

基于上述遠(yuǎn)程駕駛協(xié)議，網(wǎng)絡(luò)收斂速度慢、不穩(wěn)定的問題，出現(xiàn)在發(fā)送窗口的計算上，對于將帶寬調(diào)節(jié)參數(shù)AdjustSize，估計的太小，且車載端發(fā)送反饋報文頻率不夠高，使得調(diào)整參數(shù)速度慢。把該參數(shù)的調(diào)節(jié)策略改為，判斷延遲變化幅度做出細(xì)微調(diào)整：AdjustSize 初始值為1，若當(dāng)下時延比上一次時延高50ms，則AdjustSize 減少到0.65 倍，若高10ms，則減少到0.85 倍；若上一次時延比此次高50ms，則AdjustSize 增加到5 倍，若高10ms，則擴(kuò)大到1.35 倍。將原有的每50 個報文發(fā)送一次反饋，替換為10個報文發(fā)送一次。改變策略之后，如表4 所示。

調(diào)整之后，單次發(fā)送時延變成了大概30ms。從圖可以看出，在開始的1s 內(nèi)，發(fā)送頻率開始快速收斂，RTT 在50ms～60ms 之間，偶爾抖動到70ms 也可以迅速調(diào)整，可見此次改進(jìn)是成功的，相較于固定30ms 周期的UDP，發(fā)送速率更快，延遲更低。

5 結(jié)論

本系統(tǒng)選擇了羅技G29 Driving Force 控制套件作為遠(yuǎn)程駕駛艙；選用了C++實(shí)現(xiàn)硬件交互，選用python 編寫了遠(yuǎn)程駕駛傳輸功能，進(jìn)行了參數(shù)傳輸實(shí)驗(yàn)，分析了網(wǎng)絡(luò)時延。實(shí)驗(yàn)結(jié)果顯示，當(dāng)前網(wǎng)絡(luò)系統(tǒng)可以支撐中低速交通工具的遠(yuǎn)程駕駛，并提出了改進(jìn)措施。同時，實(shí)驗(yàn)表明，當(dāng)前網(wǎng)絡(luò)尚不能達(dá)到10ms 時延，無法支持高速交通工具的遠(yuǎn)程駕駛。