前年在苏州某测试区做V2X场景验证的时候，碰到一个很棘手的问题。测试车辆通过路口时，能收到路侧单元发来的红绿灯信息，但总是延迟3到5秒才触发。这个延迟在自动驾驶场景下是致命的，车辆时速50公里，5秒钟能跑出去70米，早就闯红灯了。

排查了一个星期，最后发现是车载网关处理V2X消息的优先级配置有问题。V2X数据被当成了普通的业务数据，和大量的传感器数据混在一起排队处理，导致延迟累积。调整优先级之后，延迟降到了80毫秒，才算过关。

这件事让我对车载网关和V2X路侧单元的配合有了更深的理解。今天就从实践角度，聊聊这两个设备怎么协同工作。

V2X通信到底在解决什么问题

先说V2X是什么。V2X就是Vehicle-to-Everything，车联万物。具体包括V2V（车对车）、V2I（车对基础设施）、V2P（车对行人）、V2N（车对网络）。

很多人觉得无人车有激光雷达、摄像头、毫米波雷达，传感器这么多，还要V2X干什么？实际情况是，车载传感器的感知范围有限。激光雷达最远看两三百米，遇到弯道、坡道、障碍物遮挡，更是看不到。

V2X可以突破视距限制。路口装一个路侧单元（RSU），可以把红绿灯状态、路口的所有车辆信息、行人信息广播出去。车辆在几百米外就能提前知道路口的情况，提前做决策。

另一个典型场景是盲区预警。前车急刹车，它会通过V2X广播这个消息。后面几辆车都能收到，即使被大货车挡住看不到，也能提前减速。这在高速公路上很有用。

还有协同驾驶场景。多辆无人车编队行驶，通过V2X保持队形、同步加减速。或者在路口，通过V2X协商通行顺序，比传统的红绿灯效率更高。

这些场景都需要车载网关和路侧单元打交道。

C-V2X通信技术的选择

V2X有两种技术路线：DSRC和C-V2X。DSRC基于WiFi技术，北美用得多。C-V2X基于蜂窝网络技术，中国、欧洲在推。

C-V2X又分两个模式。Uu模式就是走4G/5G基站，车和云端通信。PC5模式是直连通信，车和车、车和路侧单元直接通信，不经过基站。

V2X最核心的场景，比如碰撞预警、路口通行，都用PC5直连模式。因为延迟要求太高了，走基站绕一圈来不及。PC5模式的延迟理论上可以做到20毫秒以内。

但PC5通信需要专用的频段。国内分配的是5905-5925MHz，带宽20MHz。这个频段只能用于V2X，不能用于其他通信。

车载网关要支持C-V2X，就得集成专门的C-V2X模组。这个模组和普通的4G/5G模组不一样，虽然都是基于3GPP标准，但协议栈有差异。市面上做C-V2X模组的主要是高通、华为海思、大唐高鸿。

有些网关会同时集成4G/5G模组和C-V2X模组。4G/5G走Uu模式，用于车云通信。C-V2X走PC5模式，用于车路和车车通信。两个模组各司其职。

也有方案是用一个支持双模的模组，同时支持Uu和PC5。成本能省一些，但性能上会有妥协。

路侧单元的部署方式

路侧单元装在哪里，怎么部署，对通信效果影响很大。

最常见的是红绿灯路口。RSU通常装在路口的信号灯杆上，离地面5到8米。它会接收交通信号机的信号，知道当前是红灯还是绿灯，还有多少秒变灯。然后把这些信息通过C-V2X广播出去。

广播频率一般是10Hz，也就是每100毫秒发一条消息。消息内容包括路口ID、信号灯相位、倒计时、车道信息。消息格式遵循SAE J2735标准，叫做SPAT（Signal Phase and Timing）。

车载网关接收到SPAT消息后，要解析、校验、然后转发给域控制器。域控制器根据红绿灯状态决策是否通过路口。

第二种部署是高速公路。在容易发生事故的路段，比如急弯、长下坡、隧道口，部署RSU。它可以把路面状况、气象信息、前方拥堵信息广播出去。

高速公路上车速快，通信距离要求更远。普通的RSU有效通信距离是300-500米，高速公路上可能要做到800米甚至1公里。这对天线和发射功率都有更高要求。

第三种是园区和矿区。这种封闭场景通常会部署比较密集的RSU网络。不仅用于红绿灯和预警，还用于车辆调度。RSU知道每辆车的位置和速度，可以协调车辆避免冲突。

封闭场景的RSU通常会联网，接入到统一的调度平台。车载网关不仅要接收RSU广播的消息，有时还要主动向RSU发送消息，比如请求通行权、报告异常情况。

通信协议栈的细节

C-V2X PC5模式的协议栈，从下到上是这样的：

物理层和MAC层用的是LTE的技术，但做了专门优化。传统LTE需要基站调度，PC5是分布式的，没有中心节点。设备之间通过感知和预留资源的方式，自主选择传输时机。

网络层和传输层，V2X消息通常封装在UDP里。虽然也可以用TCP，但考虑到实时性，UDP更合适。IP地址通常用IPv6，因为V2X设备数量庞大，IPv4地址不够用。

应用层才是V2X真正的业务逻辑。这一层的标准主要是SAE J2735和ISO TS 19091。定义了各种消息类型：BSM（Basic Safety Message，基本安全消息）、SPAT（信号灯消息）、MAP（地图消息）、RSI（路侧信息）、RSM（路侧单元消息）。

每种消息都有详细的数据结构定义。比如BSM，包含车辆ID、位置、速度、航向角、加速度、车辆尺寸、转向灯状态等等。数据用ASN.1格式编码，压缩后大概200-400字节。

车载网关收到V2X消息后，要做几件事：

第一是解码和校验。验证消息格式是否正确，数据是否完整。如果收到的是加密消息，还要解密。

第二是时间戳校验。V2X消息都带有时间戳，要验证时间是否在合理范围内。如果时间戳和当前时间差太多，说明可能是重放攻击，要丢弃。

第三是位置相关性过滤。车辆可能同时收到几十个RSU和周围车辆的消息。不是所有消息都有用，要根据位置筛选。比如车辆在往东开，收到西边路口的红绿灯消息就没意义，可以过滤掉。

第四是转发给域控制器。把有用的消息通过车内以太网发给域控制器。转发的时候可能要做协议转换，比如把ASN.1格式转成JSON或者Protobuf，方便域控制器处理。

这一系列处理要在极短时间内完成，通常要求在10毫秒以内。否则加上空口传输、域控制器处理的时间，总延迟就超标了。

延迟预算的分配

V2X通信端到端延迟的要求很严格。从RSU发送消息，到车辆接收并做出反应，整个链路延迟要在100毫秒以内。有些场景，比如碰撞预警，甚至要求50毫秒。

这100毫秒怎么分配？

RSU内部处理5-10毫秒。从接收交通信号或者采集数据，到编码、封装、发送V2X消息。

空口传输10-20毫秒。PC5模式的理论延迟很低，但实际上受信道质量、资源冲突、重传等因素影响，会有波动。

车载网关接收和处理10-15毫秒。从射频接收、解码、校验、过滤到转发。

车内以太网传输5-10毫秒。从网关到域控制器。

域控制器处理30-50毫秒。解析消息、融合到感知结果、做决策规划。

执行延迟10-20毫秒。控制指令从域控制器到线控系统，再到执行器动作。

可以看到，每个环节的延迟都必须控制好。车载网关虽然只占10-15毫秒，但也不能松懈。特别是在高负载情况下，如果网关处理不过来，延迟就会飙升。

降低网关处理延迟的方法，一是用专门的硬件加速。把V2X消息的解码和校验用FPGA或者ASIC实现，比软件处理快得多。二是优化软件架构，用零拷贝、多线程、无锁队列这些技术，减少数据搬运和等待时间。

消息认证和安全机制

V2X通信的安全性非常重要。如果攻击者伪造一条"前方有障碍物"的消息，车辆收到后会紧急制动，可能导致追尾事故。如果伪造红绿灯消息，让车辆以为是绿灯其实是红灯，后果更严重。

所以V2X消息必须有安全机制。中国和欧洲都制定了V2X安全认证体系，基于PKI（公钥基础设施）。

每个V2X设备，包括车载网关和RSU，都有一个数字证书。发送V2X消息的时候，用私钥对消息签名。接收方用证书验证签名，确认消息确实来自合法设备，没有被篡改。

但这里有个矛盾。数字签名和验证需要加解密运算，很耗时。一个256位的ECDSA签名验证，在普通CPU上要几毫秒。车辆每秒要处理几百条V2X消息，如果每条都验证，延迟会爆掉。

解决办法是硬件加速。车载网关要配备专门的安全芯片或者加密加速器，能够并行处理多个签名验证任务。高通的V2X芯片组、华为海思的Balong 5000系列，都内置了这种加密加速能力。

还有一个问题是证书管理。V2X证书不能长期使用，为了保护隐私和安全，通常每个证书只用几分钟到几小时。车辆需要持有一批证书，轮换使用。证书快用完了，要从证书管理系统申请新的。

这个证书申请和更新的过程，就需要车载网关通过4G/5G网络和后台系统通信。所以网关既要支持PC5模式收发V2X消息，又要支持Uu模式管理证书。两个功能要协同工作。

覆盖范围和通信可靠性

RSU的有效通信距离通常是300-500米。但这是理想情况，实际使用中会受很多因素影响。

建筑物遮挡是最大的问题。城市环境里高楼林立，V2X信号会被建筑物挡住或者反射。车辆在路口转弯的时候，刚好被建筑遮挡，可能收不到RSU的消息。

解决办法是多点部署。一个路口可能需要装2-4个RSU，从不同方向覆盖。这样即使一个方向被遮挡，其他方向还能收到。但这会增加建设成本。

多径衰落也是个挑战。信号从RSU到车辆，可能走直射路径，也可能经过建筑反射走多条路径。多条路径的信号叠加，可能增强也可能相互抵消。这会导致通信质量不稳定。

C-V2X在物理层做了优化，用了OFDM调制和信道编码，能对抗一定程度的多径。但在复杂城市环境，通信成功率还是会受影响。

干扰也不能忽视。虽然V2X有专用频段，但同频段内多个设备同时发送，还是会互相干扰。特别是在车流密集的路口，可能有几十辆车、多个RSU同时发送消息。

PC5模式有冲突避免机制，设备在发送前会先侦听信道，如果信道忙就等待。但这不能完全避免冲突，还是可能出现丢包。

所以V2X通信的可靠性做不到100%。通常设计目标是在200米范围内，消息接收成功率达到90-95%。剩下的5-10%丢包，要靠应用层的容错设计来弥补。

比如RSU每100毫秒发一次红绿灯消息，连续发多次。即使某一次丢包了，车辆还能收到后续的消息。域控制器也要做超时处理，如果一段时间收不到V2X消息，要切换到纯视觉识别红绿灯的模式。

实际测试中遇到的问题

我们在多个测试场做过V2X验证，遇到过各种问题。

第一个问题是时钟同步。V2X消息的时间戳精度要求很高，毫秒级。如果车载网关和RSU的时钟不同步，时间戳校验就会出错，消息会被丢弃。

RSU通常通过GPS或者北斗授时，精度可以达到微秒级。车载网关也要有GPS授时，但有些网关的GPS只用于定位，没有接授时信号。这就导致时钟漂移。

后来我们要求网关必须支持GPS授时，并且定期和NTP服务器同步。两重保险，确保时钟准确。

第二个问题是坐标系转换。V2X消息里的位置信息用的是WGS84经纬度坐标。但域控制器通常用局部笛卡尔坐标系，以车辆当前位置为原点。网关收到RSU消息后，要做坐标转换。

坐标转换看似简单，但在高精度要求下，投影误差、地球曲率、高程都要考虑。如果转换不准确，域控制器判断RSU位置就会有偏差，严重时可能影响决策。

我们后来在网关里集成了高精度的坐标转换库，支持多种坐标系和投影方式。同时和域控制器约定好统一的坐标系，避免混乱。

第三个问题是消息风暴。在某些场景下，比如大型路口、高速公路收费站，车流量很大。每辆车都在广播BSM消息，网关可能同时收到上百条消息。

如果每条消息都转发给域控制器，会把车内网络打爆。网关要做聚合和过滤。比如只转发距离车辆200米以内的车辆消息，更远的不管。或者对消息做优先级排序，只转发最重要的那些。

第四个问题是设备兼容性。V2X虽然有标准，但不同厂商的实现还是有差异。我们测试的时候发现，某品牌的RSU发的消息，某品牌的车载网关解析不出来。抓包看发现是ASN.1编码的可选字段处理不一致。

后来只能联系双方厂商，对照标准修改实现。这种互操作性问题在V2X大规模部署前必须解决，否则不同厂商的设备没法一起工作。

不同应用场景的差异

V2X在不同场景下的应用方式有很大差异。

城市道路场景，主要是红绿灯信息和路口冲突预警。RSU的密度比较大，基本每个信号灯路口都会部署。车载网关要能处理高频次的消息接收，同时做好功耗管理，不能一直全功率工作。

高速公路场景，重点是前向碰撞预警、紧急制动预警、道路危险状况提示。这些消息的优先级很高，延迟要求更严格。网关在处理高速场景的V2X消息时，要给予最高优先级，不能被其他业务数据阻塞。

矿区和港口场景，V2X不仅用于安全预警，还用于车辆调度。RSU会下发行驶指令，车辆要按照指令行驶到指定位置。这种场景下，V2X消息要求绝对可靠，不能丢失。

通常会配合应答机制。车辆收到调度指令后，要通过V2X回复确认消息。如果RSU没收到确认，会重发指令。这就需要车载网关支持双向通信，不仅能接收还能发送。

园区和校园场景，车速慢，安全要求没那么高。V2X可能更多用于优化通行效率，比如绿波通行、协同通过路口。这种场景对延迟的要求可以放宽一些，但对覆盖完整性要求高，不能有盲区。

和其他传感器的融合

V2X提供的信息最终要和车载传感器融合。这个融合通常在域控制器里做，但网关也要配合。

比如，摄像头识别到红灯，同时V2X也收到红灯消息。如果两个信息一致，置信度就高。如果不一致，可能是摄像头误识别，或者V2X消息有问题，需要进一步判断。

还有一种情况，摄像头看不清红绿灯，比如阳光直射导致过曝，或者被前车遮挡。这时候如果V2X能收到信号灯消息，就可以作为补充。

再比如盲区车辆。激光雷达和摄像头可能扫不到被遮挡的车辆，但那辆车在广播BSM消息。域控制器融合V2X信息后，能感知到盲区车辆的存在，提前做避让。

网关在这个过程中，要保证V2X消息的时间戳和传感器数据能对齐。所有数据都要有统一的时间基准，这样域控制器做融合的时候，才能把同一时刻的不同来源数据关联起来。

法规和标准的影响

V2X的部署受法规和标准影响很大。不同国家和地区，对V2X的要求不一样。

中国在推C-V2X，工信部已经分配了专用频段，交通部也在制定V2X的应用标准。一些城市开始强制要求新建道路要部署RSU，新上牌的商用车要配备V2X设备。

欧洲之前推DSRC，但现在也在转向C-V2X。欧盟委员会还在制定统一的V2X标准，要求车辆和基础设施之间能互联互通。

美国比较复杂，FCC把5.9GHz频段的一部分分配给了WiFi，V2X只剩下30MHz带宽。美国车企对C-V2X和DSRC都有支持，市场还在博弈中。

对车载网关来说，要支持不同地区的V2X标准。最好是软件可配置，通过升级固件就能适应不同市场。硬件上，射频前端要能覆盖不同的频段。

安全认证也是个合规要求。国内的CCSA制定了V2X安全技术规范，车载设备要通过认证才能商用。欧洲有类似的标准。网关不仅要支持技术协议，还要拿到相应的认证证书。

未来的演进方向

V2X技术还在快速发展中。5G NR V2X是下一代技术，对比LTE V2X有很大提升。延迟更低，可靠性更高，支持更高的车速和更密集的车流。

但5G V2X设备的成本还比较高，大规模商用还需要时间。现在是LTE V2X和5G V2X并存的阶段，车载网关要能兼容两种技术。

另一个趋势是V2X和5G网络的融合。未来的车载网关，可能用一个模组同时支持5G Uu模式和5G PC5模式，不需要分开的C-V2X模组。这样可以降低成本和功耗。

边缘计算也在和V2X结合。RSU不再只是简单的广播节点，而是有一定的计算能力。它可以聚合多辆车的数据，做局部的协同决策，然后把决策结果通过V2X下发。车载网关要能处理这种更复杂的交互。

从我自己这几年参与V2X项目的经验看，技术本身已经比较成熟了，最大的挑战在于大规模部署。RSU的建设成本、车辆的配备率、不同厂商设备的互操作性，这些都是需要时间解决的问题。但方向是明确的，V2X会成为智能网联汽车的标配，车载网关和RSU的配合也会越来越重要。