3、V2X协议栈解析：PC5接口与Uu接口、C-V2X Layer 1/Layer 2、V2X消息集（BSM/RSM/RSI/MAP/SPAT）
好，咱们进入第三讲。这一章是V2X通信的“硬核”部分，说白了就是搞明白数据到底是怎么从你的车发出去，又是怎么被别的车或路侧设备收到的。我当年刚接触V2X协议栈时，看着那一堆分层和接口，说实话有点懵。但后来在TBOX项目里调通了第一帧PC5消息后，整个逻辑就豁然开朗了。
今天咱们重点拆解三块内容：PC5和Uu这两个接口的区别、C-V2X的物理层和MAC层，以及最常用的那几个V2X消息。嗯，这些都是你写代码时绕不开的东西。
3.1 PC5接口与Uu接口：直连 vs 上云
V2X通信有两种路径，一个是车跟车直接聊（PC5），另一个是车通过基站转发（Uu）。这两个接口，我习惯把它们比作“对讲机”和“打电话”。
- PC5接口（直连通信）：不经过基站，车与车、车与路侧单元直接通信。延迟极低，一般在20毫秒以内。适合碰撞预警、紧急刹车这类场景。
- Uu接口（蜂窝通信）：走4G/5G基站，数据先上传到云端，再下发。延迟相对高一些，但覆盖范围广。适合远程诊断、路径规划这类不要求实时性的业务。
关键点：在TBOX里，PC5和Uu是共存的。PC5负责安全类消息，Uu负责非安全类消息。我见过一些方案把PC5和Uu混用，结果导致高优先级消息被低优先级消息阻塞——这是个坑，后面会细说。
为什么会设计两个接口？你想想看，如果两辆车都在高速上以120km/h行驶，刹车距离只有几十米。这时候如果消息还要绕一圈基站再回来，黄花菜都凉了。PC5就是为了解决这个“最后一公里”的实时性问题。
我记得在某个项目中，客户要求TBOX同时支持PC5 Mode 4（直连模式）和Uu Mode 3（基站调度模式）。当时调试时发现，PC5模式下资源冲突概率比预期高，后来通过调整感知阈值才解决。嗯，这里要注意，PC5的资源选择算法（SPS）在密集场景下容易出问题，建议预留调参接口。
3.2 C-V2X Layer 1 / Layer 2：物理层与MAC层
这一节稍微有点硬，但我会尽量讲得接地气。C-V2X的协议栈分为三层：物理层（L1）、数据链路层（L2）和应用层（L7）。咱们今天只聊L1和L2，因为应用层后面有专门章节。
3.2.1 物理层（Layer 1）
物理层负责把二进制数据变成无线电波发出去。C-V2X用的是OFDM（正交频分复用）技术，跟4G/5G同源。但有个关键区别：C-V2X的物理层是专门为高速移动场景优化的。
- 频段：中国用的是5.9GHz频段（5905-5925MHz），共20MHz带宽。
- 子载波间隔：15kHz，跟LTE一样。
- TTI（传输时间间隔）：1ms，也就是每毫秒可以发一个子帧。
- MCS（调制编码策略）：支持QPSK、16QAM、64QAM。我建议在高速场景下用QPSK，虽然速率低，但抗干扰能力强。
个人经验：在TBOX的射频前端设计时，一定要关注接收灵敏度。我曾经遇到过一款模组，在实验室测试时性能完美，但装车后因为天线位置不佳，导致PC5通信距离从500米骤降到200米。后来我们加了LNA（低噪声放大器）才解决。所以，物理层的坑往往不在芯片本身，而在天线匹配和布局。
3.2.2 数据链路层（Layer 2）
L2层主要包含MAC（介质访问控制）和RLC（无线链路控制）。对于V2X来说，MAC层是最核心的，因为它决定了“谁在什么时候发数据”。
C-V2X的MAC层有两种资源分配模式：
- Mode 3（基站调度）：由基站（eNB/gNB）统一分配资源。适合Uu接口。
- Mode 4（自主调度）：车辆自己感知信道并选择资源。适合PC5接口。
Mode 4里有个关键算法叫SPS（半持续调度）。简单说，就是车辆先监听一段时间，看看哪些资源块被占用了，然后挑一个空闲的来用，并且持续使用一段时间。这样可以减少频繁的资源重选，降低延迟。
// 伪代码：SPS资源选择流程（简化版）
// 1. 感知阶段：监听100ms，记录每个子帧的RSRP（参考信号接收功率）
// 2. 排除阶段：排除RSRP高于阈值的资源
// 3. 选择阶段：从剩余资源中随机选一个
// 4. 预留阶段：连续使用该资源20次，然后重新选择
uint16_t sps_select_resource(int16_t rsrp_threshold) {
uint16_t candidate[100];
uint8_t count = 0;
for (int i = 0; i < 100; i++) {
if (rsrp_measure[i] < rsrp_threshold) {
candidate[count++] = i;
}
}
if (count == 0) {
// 没有可用资源，提高阈值重试
return sps_select_resource(rsrp_threshold + 3);
}
return candidate[rand() % count];
}
避坑指南：我曾经在Mode 4的SPS实现中踩过一个坑——资源重选太频繁。当时为了追求低延迟，我把资源预留次数设成了5次，结果导致大量碰撞。后来参考3GPP标准，发现预留次数建议在10-20次之间。嗯，这里要记住：不是越快越好，稳定更重要。
3.3 V2X消息集：BSM/RSM/RSI/MAP/SPAT
好了，底层协议聊完了，咱们看看应用层到底在传什么。V2X消息集由SAE J2735和国标GB/T 31024定义。我挑几个最常用的来讲。
3.3.1 BSM（基本安全消息）
BSM是V2V通信中最基础的消息，每辆车每秒发10次（100ms周期）。它包含：
- 车辆ID（临时ID，保护隐私）
- 经纬度、海拔
- 速度、加速度、航向角
- 刹车状态、转向灯状态
- 车辆尺寸
BSM的编码用的是ASN.1 UPER（非对齐压缩编码），说白了就是把数据压到最省空间。一个BSM消息通常只有几十个字节。
3.3.2 RSM（路侧安全消息）
RSM是路侧单元（RSU）发的，用来广播它感知到的交通参与者信息。比如RSU通过摄像头或雷达检测到有行人横穿马路，就会发RSM告诉周围的车辆。
RSM和BSM的结构很像，但多了个“置信度”字段。因为RSU的传感器不一定100%准确，所以需要告诉车辆“我检测到前面有行人，但置信度只有80%”。
3.3.3 RSI（路侧信息消息）
RSI用于发布交通事件和标志信息。比如：前方施工、事故、限速、天气预警等。RSI的特点是“区域广播”，它会在一个地理围栏内广播，只有进入该区域的车辆才会收到。
3.3.4 MAP（地图消息）
MAP消息描述的是路口的拓扑结构。它包含：
- 车道数量、车道宽度
- 车道连接关系（哪个车道可以转到哪个车道）
- 停止线位置
- 限速信息
MAP消息是V2I应用的基础。没有MAP，车辆就不知道自己在哪个车道，也无法做车道级导航。
3.3.5 SPAT（信号灯消息）
SPAT消息告诉你红绿灯的状态。它包含：
- 每个相位（Phase）的当前状态（红/黄/绿）
- 剩余时间（比如绿灯还剩5秒）
- 下一个状态及时间
SPAT和MAP是配对使用的。MAP告诉你有几个车道，SPAT告诉你每个车道对应的灯是什么颜色。
| 消息类型 | 发送方 | 周期 | 典型应用 |
|---|---|---|---|
| BSM | 车辆 | 100ms | 碰撞预警、盲区检测 |
| RSM | RSU | 100ms | 行人检测、弱势交通参与者预警 |
| RSI | RSU | 事件触发 | 施工预警、事故预警 |
| MAP | RSU | 1s | 车道级导航、绿波通行 |
| SPAT | RSU | 100ms | 红灯预警、绿灯起步提醒 |
个人建议：在TBOX中实现消息解析时，建议用代码生成工具（如ASN1C）自动生成编解码代码。我早期手写过BSM的编解码，结果因为字节序问题折腾了两天。后来改用工具生成，半小时搞定。嗯，别跟自己过不去。
好了，这一章的内容就到这里。PC5和Uu接口的选择、L1/L2层的实现细节、以及五种核心消息的解析，都是你在TBOX开发中每天要面对的东西。下一章咱们聊聊V2X应用层的开发，包括碰撞预警算法和路径规划——那才是真正有意思的部分。