远程驾驶交通工具的网络时延分析

王立恺 刘维维 安媛

（1.徐州市公安局交通警察支队 江苏省徐州市 221000 2.徐州工程学院 江苏省徐州市 221018）

1 引言

自动驾驶尚未完全成熟，远程驾驶却具有广泛的应用场景。在生产方面，在恶劣环境与危险场所等驾驶员无法达到的区域，驾驶员无需亲临，就可驾驶矿车、重型汽车等有风险的交通工具，还可以随时轮换人力，交替休息，避免疲劳驾驶。在生活方面，人们遇到喝酒等不方便开车的情况时，可以让驾驶员远程操作轻松送回车库。车载端不再有驾驶员，提升了车辆的运力，同时也避免了司机或乘客的违法犯罪行为。在防灾避险方面，驾驶员可以在山体滑坡、地震、火山喷发等灾难中，运输人员和物资。由于5G 的到来，基于5G 的业务标准正在走向商业部署，远程驾驶急需解决的高延迟和高丢包率问题将缓步解决。可以预见，远程驾驶将极大提升操作效率并节省人力，并在未来大有可为。

对于车外无线通信，主流的方式包括了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 值相对于减小带宽估计的太小，而且调整网络参数的频率太低。虽然时延较低，但网络发送窗口变成了“慢扩大、快缩小”，造成收敛速度慢，时延不稳定。总体上比上述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 时延，无法支持高速交通工具的远程驾驶。