遠程駕駛交通工具的網絡時延分析

王立愷 劉維維 安媛

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

1 引言

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

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

2 遠程駕駛的參數傳輸需求

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

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

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

若某一方NAT 規范較為嚴格，雙方無法建立通信，遠程駕駛

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

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

3 時延測試和性能分析

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

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

測試方法：控制端將固定大小的1000 個指令數據以及發送時間戳通過不同協議傳送，傳輸到中轉服務器，中轉服務器轉發到車載端，由于車載端與控制端為同一臺機器，他們的當前時間是一致，這樣也避免的對時問題。由此記錄協議發送時間、時延采樣值，通統計數據計算均值、方差、發送總時間，以測試他們的發送性能。

測試過程：

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

UDP 測試中，因為定時的TCP 在時延比發送周期低的情況下會退化成UDP，所以我們不再選用TCP 來測試網絡性能。由于UDP 并未規定以何種發送速率發送數據，如果不阻塞一段時間發送，路由器很快就會排隊阻塞，所以我們使用間隔固定時間來測試UDP。經過測試，發送周期太長或太短都不能盡如人意。最終我們確定三組數據來說明當前網絡傳輸的特點，分別以20 毫秒、30 毫秒、35 毫秒為間隔。如表2 所示。

表1：TCP 測試數據統計表

表2：UDP 測試數據統計表

表3：遠程駕駛協議時間測試數據表

表4：遠程駕駛協議改進，時間測試數據表

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

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

4 改進措施

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

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

5 結論

本系統選擇了羅技G29 Driving Force 控制套件作為遠程駕駛艙；選用了C++實現硬件交互，選用python 編寫了遠程駕駛傳輸功能，進行了參數傳輸實驗，分析了網絡時延。實驗結果顯示，當前網絡系統可以支撐中低速交通工具的遠程駕駛，并提出了改進措施。同時，實驗表明，當前網絡尚不能達到10ms 時延，無法支持高速交通工具的遠程駕駛。