车联网C-V2X技术分析（1）
1 C-V2X:Cellular Vehicle-to-Everything
1.1 车联网
车联网（Internet of Vehicles, IoV / Vehicle-to-Everything, V2X）是以车辆为核心节点，通过无线通信技术实现车与车（V2V）、车与道路基础设施（V2I）、车与行人（V2P）、车与云端（V2N）之间实时数据交互的网络系统。其核心目标是提升交通安全、提高通行效率、降低能耗，并为自动驾驶提供支撑。
典型应用场景：碰撞预警、红绿灯诱导、远程诊断、高精地图更新等。
核心组件说明：
-
车载单元（OBU）：安装在汽车上的通信模组。
-
路侧单元（RSU）：安装在路边的设备，通常与红绿灯、摄像头等集成。
-
行人用户终端（P-UE）：行人的智能手机等设备。
| 缩写 | 英文全称 | 中文释义 |
|---|---|---|
| V2V | Vehicle-to-Vehicle | 车与车通信 |
| V2I | Vehicle-to-Infrastructure | 车与道路基础设施通信 |
| V2P | Vehicle-to-Pedestrian | 车与行人通信 |
| V2N | Vehicle-to-Network | 车与云端/网络通信 |
| RSU | Roadside Unit | 路侧单元 |
| P-UE | Pedestrian User Equipment | 行人用户终端 |
| OBU | On-Board Unit | 车载单元 |
| DSRC | Dedicated Short Range Communications | 专用短程通信 |
1.1.1 四大典型应用场景
-
V2V (车对车)：车辆间实时共享位置、速度、方向等状态信息，实现碰撞预警、协同变道等。
-
V2I (车对基础设施)：车辆与红绿灯、路侧单元等通信，获取信号灯状态、道路施工等信息，实现“绿灯畅行”。
-
V2P (车对行人)：车辆检测到周围行人（尤其是手机用户），向驾驶员发出预警，避免碰撞。
-
V2N (车对网络)：车辆通过4G/5G网络连接到云平台，获取实时交通、高精地图、娱乐等广泛信息。
精读 SAE J2735 标准，这是V2X世界的“通用语言”。理解基本安全消息（BSM）、信号相位与配时消息（SPAT）、地图数据消息（MAP） 等的具体数据结构和含义。
1.1.1.1 V2V
V2V（Vehicle-to-Vehicle，车对车通信） 是指两个车载终端（V-UE）之间通过 PC5 参考点（Sidelink，侧行链路） 直接交换动态行驶数据与意图信息的通信模式。其核心特征是不经过网络基础设施（gNB/eNB）转发，属于设备对设备（D2D）通信在高速移动场景下的特定实现。
eNB（evolved Node B）：4G LTE 网络的无线接入点（基站）
gNB：5G NR（New Radio）网络的无线接入点（基站）
两者都是 3GPP 标准中的无线接入网节点，负责空中接口（Uu 口）与终端（手机、OBU 等）之间的通信。
其标准基础为3GPP TS 23.285（LTE-V2X）及TS 23.287（5G-V2X）中定义的直连通信（Direct Communication） 模式，物理层承载于ITS专用频段（5.9GHz），旨在实现亚20ms端到端时延及99.999%可靠性的道路安全消息交互。
-
承载接口：PC5（Sidelink），工作于 ITS 专用频段（5.905~5.925 GHz，中国）。
-
通信模式：支持 广播（Broadcast）、组播（Groupcast） 与 单播（Unicast）。广播为 V2V 安全应用的基础模式。
-
传输方向：侧行链路（SL-SCH，Sidelink Shared Channel），独立于上行（UL）与下行（DL）链路。
1.1.1.1.1 V2V 通信架构图（协议数据面）
- V2V Uu蜂窝接口 以及 V2V PC5直连接口
- 通信架构图
| 模块 | 关键专业术语与机制 |
|---|---|
| PC5 接口物理信道 | PSCCH（控制）、PSSCH（数据）、PSFCH（反馈，仅NR）——与Uu的PDCCH/PDSCH/PUCCH对应但独立。 |
| 同步参考源 | GNSS（优先级0） > gNB（优先级1） > UE转发（优先级2/3），影响RF频偏跟踪策略。 |
| 资源分配模式 | Mode 2 是V2V主流：侦听（Sensing）→ 资源排除 → 随机选择 → 半静态预留（SCI通告）。 |
| 协议栈承载 | 接入层（AS）直接承载V2V业务，高层（网络层/消息层）在AS之上 |
| 蜂窝辅助 | Uu接口非必需，仅在需要基站调度（Mode 1）或获取同步时启用，与直连通信解耦。 |
V2V与手机协议栈的对比
| 概念 | 手机（Uu） | V2V（PC5） |
|---|---|---|
| 物理信道 | PDCCH/PDSCH/PUCCH/PUSCH | PSCCH/PSSCH/PSFCH/PSBCH |
| 资源分配 | 基站集中调度（DCI） | UE自主感知（Mode 2）或基站调度（Mode 1） |
| 同步来源 | 基站同步信号（SSB） | GNSS优先，UE间同步为辅 |
| HARQ | 上下行均有，基站控制 | NR-V2X支持，LTE-V2X仅广播无HARQ |
| 移动性 | 切换（Handover）管理 | 直连无切换，仅需维护同步跟踪 |
HARQ（Hybrid Automatic Repeat reQuest，混合自动重传请求）是现代蜂窝通信（4G LTE / 5G NR）中的关键技术，用来在不可靠的无线链路上实现高可靠、低时延的数据传输。
缩写对照表
| 缩写 | 英文全称（如适用） | 中文全称 |
|---|---|---|
| V2V | Vehicle-to-Vehicle | 车对车通信 |
| UE | User Equipment | 用户终端（车载终端） |
| PC5 | ProSe Direct Communication interface（3GPP 定义） | PC5 接口（侧行链路直连接口） |
| PSCCH | Physical Sidelink Control Channel | 物理侧行链路控制信道 |
| SCI | Sidelink Control Information | 侧行链路控制信息 |
| PSSCH | Physical Sidelink Shared Channel | 物理侧行链路共享信道 |
| BSM | Basic Safety Message | 基本安全消息（SAE J2735 定义） |
| PSFCH | Physical Sidelink Feedback Channel | 物理侧行链路反馈信道（NR-V2X 引入） |
| HARQ | Hybrid Automatic Repeat reQuest | 混合自动重传请求 |
| NR | New Radio | 5G 新空口 |
| gNB | next generation Node B | 5G 基站 |
| eNB | evolved Node B | LTE 基站 |
| Uu | （空中接口，无特定全称） | Uu 接口（UE 与 RAN 之间的蜂窝链路） |
| Mode 1 | （资源分配模式 1） | 集中式资源调度模式（由基站通过 DCI 分配） |
| Mode 2 | （资源分配模式 2） | 分布式自主资源调度模式（UE 感知+预留） |
| DCI | Downlink Control Information | 下行控制信息（基站调度指令） |
| AS | Access Stratum | 接入层 |
| PHY | Physical layer | 物理层 |
| MAC | Medium Access Control | 媒体接入控制层 |
| SL-SCH | Sidelink Shared Channel | 侧行链路共享信道（传输用户数据） |
| SL-BCH | Sidelink Broadcast Channel | 侧行链路广播信道（传输系统信息） |
| RLC | Radio Link Control | 无线链路控制层 |
| PDCP | Packet Data Convergence Protocol | 分组数据汇聚协议层 |
| ROHC | Robust Header Compression | 鲁棒性头压缩（IP 头压缩机制） |
| RRC | Radio Resource Control | 无线资源控制层 |
| SL-RRC | Sidelink Radio Resource Control | 侧行链路无线资源控制（用于 PC5 的 RRC 信令） |
| SC-FDMA | Single Carrier Frequency Division Multiple Access | 单载波频分多址（LTE 上行及侧行链路调制方式） |
| OFDM | Orthogonal Frequency Division Multiplexing | 正交频分复用（NR 侧行链路调制方式） |
| TM | Transparent Mode | 透明模式（RLC 无分段/重组） |
| UM | Unacknowledged Mode | 非确认模式（RLC 无重传） |
| AM | Acknowledged Mode | 确认模式（RLC 支持重传） |
1.1.1.1.2 V2V 的物理层与 MAC 层关键机制：资源分配模式
- 物理层信道结构（Sidelink 专属信道）
| 物理信道 | 功能 | 承载内容 |
|---|---|---|
| PSCCH（物理侧行链路控制信道） | 指示 PSSCH 的时频资源位置、MCS（调制编码方案）、优先级（ProSe Per-Packet Priority） | 侧行链路控制信息（SCI）格式 1-A / 2-A/2-B |
| PSSCH（物理侧行链路共享信道） | 传输用户面数据（即 BSM 载荷） | MAC PDU（传输块） |
| PSFCH（物理侧行链路反馈信道） | 仅 NR-V2X（R16+） 支持，承载 HARQ ACK/NACK，用于单播/组播可靠性增强 | HARQ 反馈信息 |
| PSBCH（物理侧行链路广播信道） | 承载侧行链路主信息块（MIB-SL），包含同步子帧配置和带宽信息 | 用于初始同步和系统信息获取 |
- MAC 层资源分配模式
| 资源分配模式 | 调度主体 | 适用场景 | 信令流程 | 对物理层影响 |
|---|---|---|---|---|
| Mode 1 （基站调度） | gNB/eNB | 有网络覆盖区域 | UE通过Uu的SR（调度请求） 申请资源，基站通过 DCI（下行控制信息） 在PDCCH上动态分配Sidelink Grant（调度授权） | 资源确定，干扰可控，类似传统UL调度（UL调度：Uplink Scheduling，上行调度） |
| Mode 2 （自主感知选择） | UE自身 | 无网络覆盖/部分覆盖区域 | UE通过侦听（Sensing） 其他UE的SCI（PSCCH承载）内容，解析资源预留周期与优先级，在资源池（Resource Pool） 中通过半静态调度（SPS）自主选择空闲资源块（子信道+时隙） | MAC层需维护感知窗口与选择窗口，PHY层需持续进行信号能量检测 |
V2V 的资源分配与手机（Uu）完全不同，手机依赖基站调度（DCI），而 V2V 主要依赖 UE 自主感知。
-
Mode 1（集中式调度）：基站（gNB）通过 DCI（下行控制信息 Downlink Control Information）动态分配侧行链路资源。适用于有基站覆盖的场景。
-
Mode 2（分布式自主调度——V2V 主流模式）：
-
机制：UE 持续侦听（Sensing）资源池内的 PSCCH/PSSCH，测量 SL-RSRP（侧行链路参考信号接收功率），解码 SCI 以获取其他 UE 的资源预留信息（预留周期）。
-
选择策略：在候选资源窗口内，排除被高优先级业务预留的资源，然后从剩余候选集中随机选择传输资源。资源选择后通过 SCI 向周围节点宣告 半静态预留（Semi-persistent reservation），可连续使用 k 个周期（如 5~15 个周期）。
-
应对高密度：引入资源重选计数器（Resource Reselection Counter），当碰撞概率升高或随机计数归零时触发重选。
-
对比：
手机通过Uu接口上网，使用的是蜂窝上行调度（UL Scheduling），协议栈里不叫“Mode 1”。
| 对比维度 | 手机蜂窝通信（Uu） | V2X Mode 1（PC5） |
|---|---|---|
| 通信接口 | Uu（手机↔基站） | PC5（车↔车/路） |
| 资源分配对象 | 上行数据（PUSCH） | Sidelink数据（PSSCH） |
| 资源决策者 | 基站（gNB/eNB） | 基站（gNB） |
| 调度信令 | DCI（UL Grant） | DCI（Sidelink Grant） |
| 协议术语 | UL Scheduling / UL Grant | Mode 1（Sidelink资源分配模式） |
| 适用场景 | 手机上网、打电话 | V2V/V2I直连通信 |
手机不属于Mode 1。 Mode 1是V2X Sidelink（PC5接口）的专有术语，手机蜂窝通信（Uu接口）使用的是“UL Scheduling（上行调度）”，两者在3GPP协议中归属不同的信道和流程。
- 同步与时间/频率跟踪
V2V 缺少基站作为统一的同步源，因此采用分层同步参考源机制：
-
优先级 0：GNSS（全球导航卫星系统），提供绝对时间参考（UTC 时钟），所有车辆以 GNSS 为最高优先级时可直接对齐子帧边界。
-
优先级 1：基站（gNB/eNB）同步信号。
-
优先级 2/3：其他 UE 转发的同步信号（通过 PSBCH 中的 SLSS（侧行链路同步信号）和 S-PSS/S-SSS 序列）。
对 RF 调试的影响：在无 GNSS 覆盖的隧道或地下车库场景，V2V 需依赖 UE-to-UE 同步，此时频偏估计（CFO）和时偏估计（TO）的算法精度要求高于普通蜂窝手机，因为需要补偿相对运动产生的多普勒频移（可达 ±1.5kHz @ 5.9GHz, 车速 250km/h）。
1.1.1.1.3 V2V 物理层（PHY）信号处理流程
-
波形与参数集（Numerology）：基于OFDM（正交频分多路复用技术Orthogonal Frequency Division Multiplexing），支持子载波间隔15kHz（LTE-V2X）及30kHz/60kHz（NR-V2X），循环前缀（CP）长度针对高速移动场景进行优化以对抗多径时延扩展。
-
同步源选择（SyncRef）：V2V没有统一基站时钟时，UE需从GNSS（全球导航卫星系统）、gNB或其他Sidelink同步源中选择优先级最高的参考作为频率/时间同步基准。同步信号通过S-SSB（Sidelink同步信号块） 广播。
-
HARQ（混合自动重传请求）：
-
广播（Broadcast）：无HARQ反馈，采用盲重传（预配置重复次数）。
-
单播（Unicast）/组播（Groupcast）：支持基于PSFCH的ACK/NACK反馈，触发重传，可靠性进一步提升。
-
1.1.1.1.4 V2V 核心数据单元：BSM（基本安全消息）
V2V的应用层核心数据为 BSM（Basic Safety Message，基本安全消息），遵循SAE J2735标准。其端到端流程如下：
-
数据采集：V-UE A通过车载总线（CAN/CAN-FD）读取GNSS经纬度、速度矢量、航向角、加速度、刹车/转向状态、车辆尺寸等。
-
编码：将上述数据按照J2735定义的ASN.1/DER或UPER格式序列化为二进制负载。
-
协议栈封装：该负载依次下传至网络层（UDP/IP或GeoNetworking）→ 安全层（添加ECDSA签名及假名证书）→ PDCP/RLC/MAC（添加SCI控制信息）→ PHY（OFDM调制）。
-
周期性广播：V-UE A通过PSSCH信道以100ms（典型值）的固定周期向外广播该BSM消息。
-
接收与解析：V-UE B的PHY检测到PSCCH上的SCI，根据SCI指示的资源位置解调PSSCH，向上逐层解密、验签、解码，最终还原V-UE A的状态。
-
应用触发：V-UE B的V2X应用层将本车状态与V-UE A状态进行碰撞时间（TTC，Time to Collision） 计算，若低于安全阈值，则触发HMI预警（声光/制动预充）。
SCI ： Sidelink Control Information， 侧行链路控制信息。
| 属性 | 规范细节 | 来源 |
|---|---|---|
| 生成周期 | 典型值 10 Hz（100ms），紧急制动场景可提升至 50ms | SAE J2735 / ETSI EN 302 637-2 |
| 核心数据域 | Part I（必选）：时间戳、经纬度、高程、位置精度（半轴）、速度（三维）、航向角、方向盘转角、刹车状态（四轮独立）、车辆长度/宽度。 Part II（可选）：轨迹预测（路径点序列）、外部光源状态、车辆事件标志（ABS激活、ESC激活） | SAE J2735 |
| 序列化格式 | ASN.1 PER（Unaligned）编码，典型报文长度约 150~300 字节 | IEEE 1609.2 / SAE J2735 |
1.1.1.1.5 V2V 典型应用场景与端到端数据流
- V2V数据流
| 阶段 | 步骤 | 协议层/功能模块 | 技术要点 |
|---|---|---|---|
| 发送端 (V-UE A) | 1 | 感知层输入 | 多源传感器融合：IMU（惯性测量单元）提供加速度/角速度，GNSS提供绝对坐标，轮速计提供里程，方向盘转角提供意图。这些原始数据由车载ECU（电子控制单元）采集并同步时间戳。 |
| 2 | 应用层生成BSM载荷 | 生成BSM（基本安全消息），包含Part I（必选核心数据）和Part II（可选扩展数据）。生成周期严格遵循 10Hz（100ms） 标准。 | |
| 3 | 消息层编码 | 按照 SAE J2735 标准，使用 ASN.1 PER（包编码规则） 进行序列化压缩，典型BSM报文长度约150~300字节。 | |
| 4 | 安全层签名 | 按照 IEEE 1609.2 标准，使用 ECDSA（椭圆曲线数字签名算法） 对消息进行签名，附上假名证书，确保消息来源可信且防篡改。接收端需实时检查证书吊销列表（CRL）。 | |
| 5 | MAC层资源感知与选择 | 执行 Mode 2 分布式感知：在侦听窗口内测量SL-RSRP，解码其他UE的SCI（侧行链路控制信息），排除已被预留的资源，然后在候选集中随机选择。 | |
6 | 物理层发送 | 通过 PSCCH（承载SCI） 和 PSSCH（承载BSM载荷），在5.9GHz ITS频段以 100ms 周期广播发送。 | |
| 接收端 (V-UE B) | 7 | 物理层接收与同步跟踪 | RF前端完成下变频和模数转换，基带进行频偏补偿（CFO估计） 和信道估计（基于SL-DMRS），以克服多普勒频移。 |
| 8 | MAC层解析SCI | 解析PSCCH中的SCI，获取PSSCH的具体时频资源位置、MCS（调制编码方案）和优先级。 | |
| 9 | 安全层验签 | 使用证书链验证签名有效性，并核对CRL（证书吊销列表），若验签失败则丢弃该消息。 | |
| 10 | 应用层融合本车数据 | 将接收到的BSM与本车传感器数据进行时空同步校准（将对方坐标统一映射到本车参考系），然后计算TTC（碰撞时间） 等关键安全指标。 | |
| 11 | 预警/制动决策 | 若TTC低于阈值（如<2.5s），触发HMI（人机界面）预警或向AEB（自动紧急制动）系统发送执行请求。 |
当发生前车急刹车，或者出现故障，非正常操作车辆时，即前车紧急电子刹车灯预警（EEBL/Emergency Electronic Brake Light）：
-
广播无连接特性：前车通过PC5接口以 广播（Broadcast） 方式发送BSM，覆盖半径内的所有V-UE（后车、旁车、对向车辆）均能接收到同一份数据包。不存在“点对点连接”或“握手”过程，这是V2V与蜂窝通信的本质区别之一。
-
独立决策（非集中控制）：接收端车辆各自运行本地的预警算法。同一辆前车急刹车时：
-
正后方车辆：计算相对距离/速度，TTC急剧缩短，触发AEB紧急制动。
-
侧方车道车辆：因横向速度分量为零或相对速度较小，TTC较大，可能仅触发预警（如仪表盘闪烁）而不执行制动。
-
对向车道车辆：航向相反，相对速度极大，但纵向距离方向相反（相对位置矢量方向不同），算法通过碰撞角度判定过滤无效预警。
-
TTC：Time-to-Collision（碰撞时间）
定义为：在当前相对速度和加速度不变的情况下，两车从当前时刻到发生碰撞所剩余的预测时间（秒）。它是衡量碰撞风险最核心的指标，数值越小代表风险越高。
AEB：Automatic Emergency Braking（自动紧急制动）
定义为：一种主动安全系统，当通过传感器（雷达/摄像头）或V2X数据计算出TTC低于预设安全阈值（如2.5秒），且检测到驾驶员未采取有效制动操作时，系统自动触发制动执行器以减缓或避免碰撞。在V2X场景中，AEB可由本车传感器触发，也可由接收到的BSM消息辅助触发（称为AEB-P，即行人保护自动紧急制动）。
1.1.1.2 V2I
V2I（Vehicle-to-Infrastructure，车对基础设施） 是C-V2X的四大核心通信模式之一（V2V/V2I/V2P/V2N）。它定义了车辆与道路沿线部署的各类物理设施之间的数据交换规范，旨在获取超视距的道路环境信息。
RSU（Road Side Unit，路侧单元） 是实现V2I通信的核心物理实体。从协议栈视角看，RSU是一个具有固定地理位置的专用UE（用户终端），但它与普通车载UE（OBU）存在显著差异：
-
协议栈层面：RSU同样遵循3GPP定义的PC5和Uu接口协议栈（PHY/MAC/RRC等），但RSU通常具备更高的发射功率等级（Class 1/2）和更优的天线分集能力。
-
网络角色：RSU在系统中既作为PC5接口的数据源端（广播路况/信号灯消息），也作为Uu接口或光纤回传网络的网关节点（连接边缘云与核心网）。
1.1.1.2.1 RSU内部功能模块架构
RSU是一个集通信、感知、计算与控制于一体的边缘复合设备。其内部逻辑架构如下：
1.1.1.2.2 RSU在系统中的典型部署与通信流
1.1.1.2.3 从通信协议栈视角解读RSU的关键特征
| 特征维度 | 车载UE (OBU) | 路侧RSU |
|---|---|---|
| 地理位置 | 动态、高速变化 | 静态、绝对坐标固定且精确（RTK定位） |
| 发射功率 | 通常为Class 3 (23dBm) | 通常为Class 1/2 (26~33dBm)，覆盖半径更大 |
| 同步参考源 | 依赖GNSS或基站（eNB/gNB）同步 | 通常部署高精度时钟源（IEEE 1588v2 / GNSS双频），作为区域同步主时钟候选 |
| MAC层资源分配 | Mode 2（自主感知选择）为主 | Mode 1（基站调度）或Mode 2均可，但RSU常作为资源池配置的广播锚点 |
| 消息优先级 | BSM（基本安全消息）为周期性高频发送 | 广播消息中MAP与SPAT具备最高优先级（直接影响路口安全决策） |
| RF前端挑战 | 面临大动态多普勒频偏和频繁切换 | 静态部署，信道条件相对稳定，但需处理多径衰落（城市峡谷效应）和并发多UE接入的干扰 |
1.1.1.2.4 RSU广播的核心V2I消息集（协议层）
RSU通过PC5接口周期性或事件触发地广播以下标准化消息（主要依据SAE J2735和ETSI ITS标准）：
-
MAP（地图数据消息）：描述路口车道级拓扑结构（车道数量、宽度、转向关系、停止线位置、允许转向等）。车辆接收后用于本地地图匹配，以确定自身所处车道。
-
SPAT（信号相位与配时消息）：实时提供红绿灯的当前相位状态（红/黄/绿）、剩余时长及下一周期的相位计划。车辆结合MAP和自身速度，可计算绿波车速建议（Green Light Optimal Speed Advisory, GLOSA）或闯红灯预警。
-
RSM（路侧安全消息）：RSU融合自身挂载的摄像头/雷达感知数据后，向覆盖范围内的车辆广播检测到的非机动车、行人、路障等动态障碍物信息。此为V2I对单车感知的重要补充（超视距）。
-
RSI（路侧信息消息）：传递道路临时状况，如施工区、交通事故、限速变更、恶劣天气预警等。
1.1.1.3 V2P
V2P（Vehicle-to-Pedestrian，车对行人通信） 是指车辆（V-UE）与弱势交通参与者（VRU，Vulnerable Road User） 的终端（P-UE，Pedestrian UE）之间，通过 PC5 接口（Sidelink） 直接交换位置、速度、航向等动态信息的通信模式。其核心目标是解决车辆传感器（摄像头/雷达）在遮挡（非视距，NLOS） 或恶劣天气条件下无法有效检测行人的安全痛点。
1.1.1.3.1 介绍
- 标准定义（3GPP TS 22.185）
V2P 严格定义为 V-UE（车载终端）与 P-UE（行人用户终端）之间的直连通信。
-
P-UE 的逻辑实体：不限定为“手机”，而是指行人随身携带的、具备 V2X（PC5）通信能力的任何便携式设备。
-
物理形态：包括智能手机、智能手表、手持式 V2X 警示牌，甚至为视障人士设计的专用穿戴式接收器。
- 商用现实（产业落地）
在实际路测和量产部署中，P-UE 的载体确实就是智能手机。
-
目前主流的落地方式是在智能手机的基带芯片（Modem）中，启用 PC5 Sidelink 功能。
-
例如，高通（Qualcomm）的骁龙 Modem（如 X65/X70）已集成 V2X 功能，搭载这些芯片的 Android 手机，无需插入车联网专用 SIM 卡，即可在 5.9GHz ITS 频段广播行人位置信息。
- PC5 和 V2N / Uu
| 通信路径 | 技术术语 | 是否属于 V2P？ | 说明 |
|---|---|---|---|
| 手机 ↔ 车辆（直连，不经过基站） | PC5 直连（V2P） | 是（标准定义） | 依赖手机自身 Modem 支持 5.9GHz PC5 收发。特点：无网络覆盖也能预警（如地下车库、隧道）。 |
| 手机 ↔ 基站 ↔ 云 ↔ 车辆（经过蜂窝网） | V2N（车对网络） 或 Uu 上报 | 否（严格不属于 V2P） | 这是手机利用传统 4G/5G Uu 接口上传位置，云端再推送给车辆。特点：依赖网络覆盖，时延较高（通常 > 100ms），通常用于地图众包或红绿灯请求，不用于紧急碰撞预警。 |
支持 V2P 的手机并不是安装了一个 APP 那么简单，而是在底层基带（Modem）的协议栈中，新增了一个独立的“侧行链路（Sidelink）协议栈”。
射频（RF）通路：手机内部天线需要额外支持 5.905~5.925GHz（中国 ITS 频段） 的收发。这与手机连接 Wi-Fi 或 5G 是不同的射频通道（类似 Wi-Fi 的独立物理链路，但协议完全不同）。
固件（FW）层面：手机 Modem 固件中需要集成 PC5 物理层（PSCCH/PSSCH） 和 MAC 层（Mode 2 自主资源感知） 的处理能力。
应用层（APP）：高德地图、百度地图等 APP 通过系统 API（如 Android 的 V2X 接口）获取到底层 Modem 解析出的 VRU-BSM（行人基本安全消息），才能在屏幕或语音上触发“侧方有行人经过”的预警。
V2P 就是指车和手机（作为行人终端）之间的直连通信。 这个手机必须是一台内置了 V2X（PC5）通信模组的智能手机，而不是依赖蜂窝网络（4G/5G）上传位置的那个“手机上网功能”。它本质上是让手机变成了一台工作在 5.9GHz 频段的“移动信标”，直接向周围的汽车广播自己的位置。
1.1.1.3.2 V2X当前的应用情况
- 手机：鼓励发展，但非强制
-
政策现状：目前的主流政策是“鼓励”而非“强制”。例如，中国工信部等八部门在《汽车行业稳增长工作方案（2025—2026年）》中，明确提出要“鼓励汽车前装V2X、5G等高性能通信模块”。这主要针对汽车，但反映了国家层面对V2X技术应用的引导方向。
-
App生态：目前已有一些利用V2X技术的手机App。例如，星云互联的CDAS（协作式驾驶辅助系统） 可以通过V2X技术为驾驶员和行人提供辅助驾驶功能；驿联智行App 也宣称提供“泛V2X信息服务”。随着技术的普及，未来这类应用会更多。
- 手表等可穿戴设备：法规聚焦传统通信，V2X非必需
-
法规重点：当前针对智能手表等可穿戴设备的强制性法规，主要关注传统的蜂窝通信（如4G/5G） 和射频认证。例如，在中国，带蜂窝功能的智能手表需办理SRRC（无线电发射设备型号核准）认证。
-
V2X现状：目前，V2X功能并非可穿戴设备的强制性要求。不过，已有公司在探索相关应用，例如在2026年国际消费类电子产品展览会（CES）上，有厂商发布了名为“S2X VRU Client”的平台，声称可部署在智能手机和可穿戴设备上。这表明技术方向存在，但距离成为标配还很远。
- 盲人辅助设备：积极探索V2X，潜力巨大
对于导盲杖这类为视障人士设计的专用设备，情况则有所不同。虽然目前没有法规强制要求，但V2X技术被认为是提升其安全性的重要方向。
-
研究与应用：已有学术研究提出“基于V2X技术的智能导盲杖设计方案”。这类设备的核心优势在于，能通过接收路侧设备（RSU）广播的V2X地图（MAP）消息来获取道路信息，实现“车-人”协同预警，这是传统传感器无法做到的。
-
技术组合：这类设备通常会结合多种技术，例如：
-
高精度定位：使用北斗定位模块或高精度GNSS定位。
-
环境感知：通过超声波传感器或摄像头（结合YOLOv8等视觉算法）探测周围障碍物。
-
V2X通信：作为核心补充，实现与车辆和基础设施的“对话”。
-
1.1.1.3.3 V2P 系统架构图
1.1.1.3.4 V2P 数据流与碰撞预警触发序列图
1.1.1.3.5 V2P 关键技术挑战（协议与 RF 视角）
V2P 区别于 V2V/V2I 的核心技术难点：
| 挑战维度 | 技术细节 |
|---|---|
| 低功耗 PC5 设计 | P-UE（手机）电池容量有限。3GPP R17 引入了 Sidelink DRX（不连续接收） 机制，使 P-UE 无需持续监听所有子帧，仅在配置的“On-duration”窗口内唤醒侦听 PSCCH，其余时间休眠。这与 Uu 接口的 DRX 机制同源但针对 Sidelink 专属优化。 |
| 链路预算不足（覆盖受限） | 5.9GHz 频段路径损耗大，P-UE 天线增益低（通常 -2~0 dBi）且存在人体遮挡损耗（10~15dB）。V-UE 的等效全向辐射功率（EIRP）远高于 P-UE，导致上下行链路不对称（V-UE 能听到 P-UE，但 P-UE 可能收不到 V-UE 信号）。 |
| 定位精度与时间同步 | 行人定位依赖 GNSS（精度 3~5 米），在高层建筑密集区（城市峡谷）或室内（地下通道）GNSS 失锁时，P-UE 定位误差可达数十米，导致假阳性预警（误报）或漏警。3GPP 要求 V2P 应用需达到 0.5~1.5 米的定位精度。 |
| 高动态随机轨迹预测 | 行人可在 0.5 秒内急停或折返，无法用匀速运动模型（CV）或匀加速模型（CA）准确描述。业界采用概率占据栅格（POG） 或长短期记忆网络（LSTM） 进行意图预测，这属于应用层算法范畴，但需要底层 PC5 提供稳定低于 50ms 的端到端时延（R17 目标）。 |
1.1.1.4 V2N
V2N（Vehicle-to-Network，车对网络） 是指车辆（V-UE）通过 Uu 接口（即传统的4G/5G蜂窝链路）与网络侧（基站、核心网、云平台及应用服务器）进行双向数据通信的模式。其核心特征包括：
| 维度 | V2N 的技术特征 |
|---|---|
| 承载接口 | Uu 接口（UE 与 RAN 之间的空中接口），复用商用蜂窝网络（4G LTE / 5G NR） |
| 通信对端 | V2X 应用服务器（V2X AS）、OEM 云平台、交通管控中心、地图服务商等 |
| 通信范围 | 广域覆盖，依赖基站覆盖范围，理论可达数十公里 |
| 时延要求 | 相对宽松（通常 > 100ms），远高于 V2V 的 < 20ms 要求 |
| 网络依赖性 | 完全依赖蜂窝网络覆盖，无网络覆盖时 V2N 功能不可用 |
核心特征：V2N 本质上是车辆“上网”的通道，它让车辆不再是一个信息孤岛，而是接入整个互联网和云服务的移动终端。
1.1.1.4.1 V2N 系统架构图
下图从端到端视角展示 V2N 的完整通信路径，包含车辆终端、无线接入网、核心网、边缘计算节点及应用服务器各层级的交互关系。
1.1.1.4.2 V2N 协议栈（Uu 接口视角）
从协议分层角度看，V2N 的协议栈与标准智能手机的蜂窝协议栈完全一致，因为 V2N 本质就是车辆作为 UE 接入蜂窝网络。
| 协议层 | 功能定位 | V2N 特有考量 |
|---|---|---|
| 应用层 | V2X 业务逻辑（导航、OTA、远程诊断、路况推送） | 使用标准互联网协议（HTTP/HTTPS、MQTT、WebSocket）与云端通信 |
| NAS 层 | 5G-MM（注册/鉴权/位置更新）、5G-SM（PDU 会话建立/QoS 流管理） | 车载 UE 的 NAS 子集通常不包含 IMS 语音/SMS，仅激活数据 APN 和紧急呼叫 APN |
| RRC 层 (L3/AS) | 连接控制、系统信息广播、测量上报 | 针对高速移动场景（>250km/h）优化测量报告参数和多普勒频偏补偿 |
| PDCP (L2/AS) | IP 头压缩（ROHC）、加密/完整性保护 | 功能与手机完全一致 |
| RLC (L2/AS) | 分段/重组、ARQ 重传（AM 模式） | 功能与手机完全一致 |
| MAC (L2/AS) | 逻辑信道↔传输信道映射、HARQ、资源调度 | 资源调度为集中式（UL Grant），由基站通过 DCI 分配 |
| PHY (L1/AS) | 物理信道（PDCCH/PDSCH/PUCCH/PUSCH）、OFDM/SC-FDMA 调制 | 车载 UE 通常支持更高发射功率等级（Class 1/2）和 4x4 MIMO |
1.1.1.4.3 V2N 典型应用场景
- 信息娱乐与导航
-
实时路况与交通信息：导航应用通过 V2N 获取全局路况、事故、施工等信息。
-
动态高精地图更新：通过 V2N 下行通道（含 MBMS 广播）向覆盖区域内车辆推送高精地图增量更新。
-
天气与道路预警：恶劣天气、路面湿滑等区域性信息通过 V2N 推送至车辆。
- 车辆远程管理
-
OTA 软件升级：车企通过 V2N 向车辆推送固件/软件升级包。
-
远程诊断与车况监控：车辆通过 V2N 上行通道将故障码、运行状态上报 OEM 云平台。
-
车队管理与防盗追踪：车队管理者通过 V2N 实时监控车辆位置与状态。
- 安全与效率增强（与 MEC 结合）
-
V2N 紧急制动预警：哈曼等厂商已推出可投入生产的 V2N 技术，通过云分析引擎检测前方拥堵并发出紧急制动警报。
-
交通事件信息共享：通过 V2N 实现事故、障碍物等事件信息的广域分发。
-
信号灯信息推送：交通控制中心通过 V2N 将信号灯配时信息推送给接近路口的车辆。
- 自动驾驶辅助
-
远程遥控驾驶：在复杂或危险场景下，通过 V2N（Uu 接口）实现低时延远程操控。
-
协同决策：V2N 将云端全局态势感知（如区域交通流量预测）下发至车辆，辅助自动驾驶决策。
1.1.1.4.4 V2N 与 V2V/V2I/V2P 的核心差异
| 对比维度 | V2N (车对网络) | V2V / V2I / V2P (直连通信) |
|---|---|---|
| 通信接口 | Uu（蜂窝链路） | PC5（侧行链路 Sidelink） |
| 通信方式 | 需经过基站和核心网 | 设备间直接通信，无需网络中转 |
| 网络依赖 | 完全依赖蜂窝网络覆盖 | 不依赖蜂窝网络，无 SIM 卡也可工作 |
| 通信范围 | 广域（基站覆盖范围，公里级） | 短距（数百米，典型 300~1000m） |
| 典型时延 | > 100ms（eMBB）/ < 20ms（uRLLC 结合 MEC） | < 20ms（安全类应用） |
| 典型应用 | OTA 升级、导航、路况信息、远程诊断 | 碰撞预警、盲区检测、信号灯交互 |
| QoS 保障 | 由核心网统一管理（5QI 等） | 由 UE 自主感知资源（Mode 2）或基站调度（Mode 1） |
| 协议栈归属 | 标准 3GPP Uu 协议栈（含 NAS） | 3GPP PC5 协议栈（无 NAS，安全层独立） |
1.1.1.4.5 V2N 的 Uu 接口与智能手机的蜂窝通信的差异
两者的 3GPP 协议基线（AS 层 RRC/PDCP/RLC/MAC/PHY）完全一致，但 NAS 层业务子集、RRC 参数配置（针对高速优化）、RF 前端设计（功率/温度/天线）以及系统集成形态（协处理器 vs. 主控 SoC）存在显著差异。
- 两者在物理芯片组与主控系统间的集成关系的差异
- 协议栈分层对比图
| 对比层级 | 智能手机 Uu | V2N 车载 Uu | 差异实质 |
|---|---|---|---|
| NAS 层（业务能力） | 全功能：支持注册、鉴权、TAU。支持 PDU 会话类型：IMS（VoLTE/VoNR）、互联网（DNN）、专用（企业）。支持 SMS over NAS和 USSD。 | 裁剪子集：注册/鉴权/TAU 功能与手机一致，但 PDU 会话仅配置 数据 APN（如 v2x.data） 和 eCall APN。不支持 IMS（无 VoLTE/VoNR 自然人语音），不支持 SMS/USSD。 | 协议分析时，无需关注 SIP（IMS）信令和 SMS 流程，抓包重心放在标准 5G-MM/SM 和 eCall 流程上。 |
| RRC 层（移动性参数） | 标准参数：定时器（如 T300/T301）、测量触发量（A3 offset）面向 低速（≤120km/h） 和 中低速切换（Handover）场景。 | 高速增强参数： • 测量周期（measCycleSCell）缩短，以更快响应信道变化。 • A3 偏移量（a3-Offset）更小，更早触发切换。 • 支持 条件切换（CHO），减少高速移动下的切换中断时延（< 0ms 目标）。 • 上报测量中携带多普勒频偏估计值。 | Modem 配置参数需按 3GPP TS 38.331 的“高速铁路（HST）”专用配置下发。RIL 层需支持解析专用于车载的 SIB（如 SIB21/22 携带 V2X 配置）。 |
| PDCP / RLC / MAC（L2） | 标准功能：ROHC（头压缩）、加密/完整性保护、ARQ（RLC AM）、HARQ。调度为集中式（基站 DCI 分配 UL Grant）。 | 功能完全相同，但 QoS 流（5QI）配置可针对车载业务分配更高优先级（如 eCall 使用 5QI=1/5 的高优先级）。MAC 层调度与手机无差异。 | 零学习成本，你的 MAC/RLC/PDCP 知识可直接迁移。 |
| PHY 层（L1） | 标准物理信道：PDCCH/PDSCH/PUCCH/PUSCH/PRACH。同步源为基站 SSB（同步信号块）。 | 与手机完全一致。同步源同样为基站 SSB（V2N 不涉及 GNSS 同步，那是 PC5 的事情）。 | 零学习成本。注意车载场景下需处理更大多普勒频移（基带算法由底层 FW 处理，你需关注上层测量上报值）。 |
| RF 前端（射频） | 功率等级：通常 Class 3（23 dBm ±2），部分支持 Class 2（26 dBm）。 天线：2x2 MIMO 为标配，4x4 仅高端机。 温度范围：消费级，0~35°C。 频段：支持全球数十个频段（漫游）。 | 功率等级：通常 Class 1（33dBm） 或 Class 2，以补偿金属车体屏蔽损耗（约 10~15dB）。 天线：4x4 MIMO 为标配，部署于车顶（鲨鱼鳍），增益远高于手机。 温度范围：车规级 -40~85°C（AEC-Q100 认证），散热设计更严苛。 频段：仅支持目标市场频段（如中国 B3/B5/B8/B41），无全球漫游需求（但需支持 eCall 的特定频段）。 | 射频调试时需关注高功率输出下的线性度（ACLR/EVM） 和车规温度范围内的频偏补偿。天线调试需面对整车电磁兼容（EMC） 干扰（发动机/电机噪声）。 |
| 系统集成形态 | AP + Modem 融合 SoC：应用处理器（AP）和基带（Modem）集成在同一芯片封装（如 Snapdragon 8 系列），共享内存，通过 QMI/DIAG 接口交互。 | 协处理器架构：T-Box 中的蜂窝模组是一颗独立的 MCU+Modem 协处理器，运行轻量化 RTOS（如 ThreadX）。它与车机主控（域控制器）通过 PCIe/USB/以太网 连接，主控发送 AT 指令（如 3GPP TS 27.007 扩展命令）控制拨号和获取信号状态。 | 你熟悉的 RIL（Radio Interface Layer）逻辑依然适用，但宿主不再是一个操作系统（Android），而是车机主控（QNX/Linux）。需学习车载专用的 AT 扩展指令集（如 AT+CEMODE 控制 eCall 模式，AT+CSCON 监控连接状态）。 |
| SIM / eSIM 形态 | 可插拔 SIM 或 eSIM，用户可更换/下载运营商配置文件。 | 焊接式 eSIM（M2M 形态），固定焊接在 T-Box PCB 上，通常预置多个运营商配置文件（按国家/地区切换），不支持用户物理拔插或自行下载。 | 测试时需关注 M2M 远程 SIM 配置切换（eSIM RSP） 流程，而非物理卡槽管理。 |
1.1.1.5 V2X通信模式的横向对比
V2X的四种通信模式，本质上可以归结为两种通信接口（PC5 和 Uu）与两种通信对象（直连终端和网络基础设施）的组合。
- V2X 四种通信模式总览图
V2V / V2I / V2P / V2N 在同一个交通场景中的共存关系及其承载接口。
- 四种模式核心特征横向对比表
| 对比维度 | V2V (车-车) | V2I (车-路) | V2P (车-行人) | V2N (车-网络) |
|---|---|---|---|---|
| 通信对端 | 其他车载终端 (V-UE) | 路侧终端 (RSU) | 行人终端 (P-UE，手机/穿戴设备) | V2X应用服务器 / 云平台 |
| 承载接口 | PC5 (Sidelink) | PC5 (Sidelink) | PC5 (Sidelink) | Uu (蜂窝链路) |
| 是否经核心网 | 否（直连） | 否（直连） | 否（直连） | 是（经基站+核心网） |
| 是否包含 NAS 层 | 否 | 否 | 否 | 是（与手机完全相同） |
| 主要消息类型 | BSM（基本安全消息） 位置/速度/航向/刹车 | SPAT（信号相位与配时） MAP（地图数据） RSI（路侧信息） | VRU-BSM（行人安全消息） 位置/速度/航向/定位精度 | HTTP/HTTPS/MQTT 数据流 （OTA包/路况JSON/地图瓦片） |
| 典型时延 | < 20 ms（安全类） | < 50 ms（信号灯信息） | < 20 ms（碰撞预警） | > 100 ms（常规） < 20ms（uRLLC+MEC） |
| 覆盖范围 | 300~1000m（PC5典型覆盖） | 300~1000m（RSU广播覆盖） | 300~500m（受限于P-UE发射功率） | 广域（基站覆盖范围，公里级） |
| 资源分配模式 | Mode 2（分布式感知） 为主 | Mode 1（基站调度）或 Mode 2 | Mode 2（P-UE自主感知+节能DRX） | 集中式调度（UL Grant via DCI） |
| 同步参考源 | GNSS优先（无基站场景） | GNSS 或 基站同步 | GNSS优先（手机定位依赖GPS） | 基站 SSB（与手机完全相同） |
| 核心应用场景 | 前向碰撞预警（FCW） 盲区预警（BSW） 车辆编队（Platooning） | 闯红灯预警（RLVW） 绿波车速引导（GLOSA） 施工/事故区域预警 | 行人横穿预警 弱势交通参与者保护 | OTA 升级 实时路况导航 远程诊断 eCall（紧急呼叫） |
- 协议栈分层对比：PC5（V2V/V2I/V2P）vs. Uu（V2N）
PC5 家族（V2V/V2I/V2P）：无 NAS 层，不经过核心网，依赖 GNSS 同步，资源分配以分布式感知（Mode 2）为主，面向低时延安全类应用。
Uu 家族（V2N）：包含完整 NAS 层，经过核心网，依赖基站同步，资源分配为集中式调度（UL Grant），面向广域数据类应用。
1.1.1.6 车载V2X和手机蜂窝的对比
| V2V / V2I / V2P (PC5) | V2N (Uu) | |
|---|---|---|
| Modem 调度逻辑 | 全新领域：MAC 层需实现 Sensing + Resource Selection（Mode 2），不再解析 DCI。 | 与手机完全一致：解析 DCI，按 UL Grant 发送 PUSCH。 |
| RF 调谐重点 | 5.9GHz ITS 频段 + 多普勒频偏补偿（相对速度大）。 | 蜂窝频段（与手机相同），但发射功率更高（Class 1/2），温度范围更宽（-40~85°C）。 |
| 协议分析 | 抓取 PC5 接口的 SCI 和 BSM/SPAT/MAP载荷。 | 抓取 Uu 接口的 RRC/NAS 信令（与手机抓 Log 完全相同）。 |
| 同步机制 | GNSS 优先，无 GNSS 时需跟踪其他 UE 的 SLSS。 | 基站 SSB（与手机完全相同）。 |
| 系统集成 | 需额外支持 PC5 协议栈的激活和配置（预配置或通过 SIB 下发）。 | T-Box 通过标准 AT 命令拨号，与手机 RIL 流程一致。 |
| 测试重点 | 资源碰撞率、覆盖范围、同步维持时间。 | 吞吐量、切换成功率、eCall 功能。 |
1.1.1.7 相互协同
实际车载系统中，四种模式协同工作：
-
V2V 提供即时安全（本车与周围车辆的碰撞预警）。
-
V2I 提供路口环境信息（信号灯相位、限速、施工区）。
-
V2P 扩展感知边界（发现传感器遮挡下的行人）。
-
V2N 提供广域背景信息（全局路况、OTA、地图更新）。
典型融合场景示例：车辆通过 V2N 获取前方 5 公里处拥堵信息，通过 V2I 接收当前路口信号灯配时，通过 V2V 监控前车急刹，通过 V2P 探测盲区中即将横穿的行人 —— 四者共同输入决策规划模块，实现安全高效的自动驾驶。
- 分析一个具体场景的端到端流程：传感器（如GPS/雷达）-> 生成BSM消息 -> 通过PC5接口广播 -> 周边车辆接收并解析 -> 应用层触发预警算法 -> 人机交互（HMI）提示。
1.1.2 车路云一体化架构
1.1.2.1 车路云一体化系统架构
-
车端 (Vehicle)——聪明的“执行终端” 核心是车载单元（OBU）和自动驾驶域控制器（ADCU）。OBU负责通过PC5接口与周围车辆、路侧设备直连通信，并通过Uu接口接入蜂窝网络。ADCU则融合本车传感器和来自路侧、云端的信息，做出最终的驾驶决策。
-
路侧层 (Road)——智慧的“感知延伸” 由路侧单元（RSU）、摄像头/雷达、信号机等构成。它弥补了单车感知的盲区，能将超视距或复杂环境下的信息（如路口全貌）实时广播给车辆。
-
云端 (Cloud)——强大的“中枢大脑” 这是系统的核心，采用“边缘云-区域云-中心云”三级架构。
-
边缘云：部署在路侧，提供毫秒级的数据处理，实现实时响应。
-
区域云：负责一个城市或区域的交通调度与管理。
-
中心云：进行全局数据汇聚、AI模型训练等，是系统的“终极大脑”。 这三者共同构成了云控基础平台，它是整个系统的“桥梁”和“纽带”，负责打通数据孤岛。
-
-
络层 (Network)——可靠的“连接纽带”
-
C-V2X (PC5)：用于车与车（V2V）、车与路（V2I）、车与人（V2P）的超低时延直连通信。
-
4G/5G (Uu)：用于车与云（V2N）的大带宽、广覆盖通信。
-
光纤/以太网：用于路侧设备与云端的稳定、高带宽数据回传。
-
低轨卫星：作为补充，用于解决偏远地区的地面网络覆盖盲区。
-
1.1.2.2 核心数据流与协同逻辑
系统的价值在于数据驱动的闭环协同。
-
全要素数字映射：车端和路侧的传感器将物理世界的交通参与者、道路状况等实时数字化。
-
多源数据融合：这些数据通过边缘云进行初步融合与处理，实现低时延的本地协同。
-
分层决策与控制：
-
边缘云负责处理需要毫秒级响应的实时事件（如碰撞预警）。
-
区域/中心云负责秒级或更长时间尺度的全局优化（如绿波通行、区域调度）。
-
-
全局赋能：云端汇聚的海量数据，可用于训练自动驾驶AI大模型，再通过OTA等方式赋能给每一辆车。
1.1.2.3 关键支撑与标准体系
如此复杂的系统，离不开标准和安全体系的支撑。
-
标准先行：中国已发布《车路云一体化系统白皮书》、T/CSAE 295系列团体标准等一系列文件，统一了架构、数据交互等规范。
-
安全为基：PKI（公钥基础设施） 和跨域身份互认体系是保障V2X通信安全、防止恶意信息注入的关键。
-
高精地图：作为“数字底座”，为所有参与者提供统一的时空参考。
1.1.3 C2V和自动驾驶
C-V2X是自动驾驶从“单车智能”进化到“车路协同”的关键基础设施和“超级传感器”。
从“单车智能”到“协同智能”协作图
| 维度 | 单车智能 (单车) | 协同智能 (单车 + C-V2X) |
|---|---|---|
| 感知范围 | 受限于传感器物理特性，通常在200米内 | 超视距，可达数百米甚至更远，能“看见”拐角或拥堵路段的状况 |
| 感知能力 | 易受雨、雪、雾、强光等天气和光线影响 | 不受天气环境影响，信息通过无线电波传输，稳定可靠 |
| 信息维度 | 获取的是本车传感器探测到的“局部”信息 | 可获取全局信息，如整个路段的交通流量和信号灯配时 |
| 决策基础 | 基于自身感知进行“独立”决策 | 能与其他车辆和设施相互协作，做出更优的全局决策 |
1.1.3.1 协议层面
-
接入层与网络层：负责最基础的信号收发，确保消息能准确到达。
-
消息层：将信息“翻译”成所有车辆都能理解的标准化格式，比如基本安全消息（BSM） 包含车辆的位置、速度、方向等。
-
应用层：是自动驾驶的“大脑”，它接收处理后的消息，并作出决策，例如判断是否有碰撞风险，并触发紧急制动。
1.1.3.2 网络层面
两个主要通信接：
- PC5接口（直连通信）：“群聊”模式
车辆、路侧单元（RSU）、行人手机等设备通过PC5接口直接通信。这种模式不依赖基站，时延极低（可低至20毫秒），是保障行车安全的关键。
- 应用场景：前向碰撞预警、盲区监测、紧急车辆优先通行等。
- Uu接口（蜂窝通信）：“上网”模式
车辆通过Uu接口连接到4G/5G基站，再接入核心网和云端。这种模式覆盖范围广、带宽大，用于获取大容量、非实时的信息。
- 应用场景：获取实时路况、高精地图更新、远程诊断、车载娱乐等
1.1.3.3 能力协同
-
阶段一：信息辅助：C-V2X作为高级驾驶辅助系统（ADAS） 的补充传感器，提供“超视距”预警信息，提升L1/L2级自动驾驶的安全性。
-
阶段二：协同控制：在限定场景下（如高速公路），C-V2X实现车辆间的协同控制，支持更高级别的自动驾驶（L3/L4），例如车辆编队行驶。
-
阶段三：云控驾驶：C-V2X融入“车路云一体化”系统，车辆不再是信息孤岛，而是作为云端“全局大脑”的一个执行单元，为L5级全场景无人驾驶铺平道路。同时，C-V2X获取的海量数据还能用于训练自动驾驶的AI大模型，形成数据闭环，持续提升系统能力。
理解C-V2X与自动驾驶的关系，关键在于理解“协同”二字。C-V2X通过其标准化的协议栈和独特的双模网络架构，将“车”与“路”、“人”、“云”紧密连接，为自动驾驶提供了超越自身传感器极限的“集体智慧”从“单车智能”走向“车路协同”的关键使能技术。
1.1.4 技术演进与标准
C-V2X技术由3GPP主导制定，其演进路线如下：
| 3GPP版本 | 完成时间 | 核心特性 | 说明 |
|---|---|---|---|
| Release 14 | 2017年3月 | 基础LTE-V2X | 首次引入C-V2X概念，定义了基于PC5接口的直连通信，支持基本道路安全服务。 |
| Release 15 | 2018年6月 | 增强LTE-V2X | 对LTE-V2X进行增强，提升了速率、可靠性和时延性能。 |
| Release 16 | 2020年7月 | 首个5G NR-V2X | 引入5G新空口（NR）技术，支持更高级的自动驾驶用例，如车辆编队、高级驾驶等。 |
| Release 17 | 2022年6月 | 增强NR-V2X | 增强直连通信，重点优化了V2P场景，并提升了可靠性和降低了时延。 |
1.1.5 DSRC
DSRC（Dedicated Short-Range Communications，专用短程通信） 是早于C-V2X出现的第一代车联网（V2X）直连通信技术标准。其技术核心建立在 IEEE 802.11p 物理层标准之上，本质上是Wi-Fi技术在高速移动环境下的特定变体。
从协议栈视角定义：
-
物理层（PHY）：基于IEEE 802.11p，采用OFDM调制，在5.9GHz频段划分7个信道（每个10MHz带宽）。
-
数据链路层（MAC）：基于 IEEE 1609.4，采用 CSMA/CA（载波侦听多路访问/冲突避免） 机制，即节点在发送前先侦听信道是否空闲。
-
网络/传输层：基于 IEEE 1609.3，定义了WAVE（Wireless Access in Vehicular Environments）网络服务，包括IPv6和WSMP（WAVE短消息协议）。
-
消息层/应用层：与C-V2X相同，同样采用 SAE J2735 定义BSM（基本安全消息）等消息集，以及 SAE J2945 系列应用规范。
工作频段：全球统一分配在 5.850 GHz ~ 5.925 GHz（ITS专用频段），共75MHz带宽。
DSRC的协议栈架构
1.1.5.1 C-V2X vs. DSRC：主流技术对比
| 对比维度 | C-V2X (蜂窝车联网) | DSRC (专用短程通信) |
|---|---|---|
| 技术基础 | 基于3GPP标准的蜂窝网络技术（4G/5G） | 基于IEEE 802.11p的Wi-Fi技术 |
| 多址接入方式 | 基于资源池的调度式 （Mode 1: 基站调度；Mode 2: UE自主感知+半静态预留） | CSMA/CA（竞争式） 节点侦听信道空闲后发送，碰撞后随机退避 |
| 同步机制 | 严格同步（依赖GNSS或基站定时） | 无严格同步要求（异步系统） |
| 通信模式 | 双模通信：既有直连通信（PC5），又有网络通信（Uu） | 单模通信：主要是直连通信 |
| 调制与编码 | 支持更灵活的MCS（调制编码方案）和HARQ（混合自动重传请求） | OFDM，固定编码调制方案（可选速率集） |
| 网络集成 | 原生集成：Uu接口与PC5接口共用核心网，无缝支持V2N | 需通过RSU网关接入上层网络 |
| 通信距离 | 更远，尤其在5G下优势明显 | 较短，通常在100-400米 |
| 网络覆盖 | 可复用现有庞大的蜂窝网络基础设施 | 需要新建大量路侧单元，成本高 |
| 演进路径 | 清晰且后向兼容，从4G平滑演进到5G | 演进路线相对不明确 |
| 主要支持方 | 中国、欧洲（部分）、美国（近年转向） | 美国（早期）、日本（部分） |
1.1.5.2 DSRC未来趋势——分区域现状分析
结论先行：DSRC在全球主流市场已不再作为新建车联网的首选技术，但尚未完全退网；C-V2X已确立为下一代车联网的全球主导标准。
- 中国：完全转向C-V2X
-
中国自2018年起即明确C-V2X为唯一国家级车联网技术路线。
-
工信部已将5.9GHz频段（5905~5925MHz）划归C-V2X专用，DSRC在中国无商用部署空间。
-
所有量产C-V2X车型（如一汽红旗、福特、通用等中国车型）均采用LTE-V2X（PC5）。
- 美国：政策转向，频谱重新分配
-
美国联邦通信委员会（FCC）于 2020年 做出重大裁决：
-
将原5.9GHz频段的 5.850-5.895GHz（45MHz） 重新分配给非授权Wi-Fi使用。
-
将 5.895-5.925GHz（30MHz） 保留给 C-V2X 专用（且明确排除DSRC）。
-
-
美国交通部（USDOT）已停止对DSRC的新项目资助，转向支持C-V2X。主要车企（福特、通用、丰田北美）均已从DSRC迁移至C-V2X路线。
- 欧洲：从ITS-G5向C-V2X过渡
-
欧洲早期倾向于 ITS-G5（即欧洲版DSRC，基于IEEE 802.11p）。
-
但欧盟委员会于 2023年 发布的《互联出行倡议》中，已明确将 5G-V2X（含PC5） 列为未来统一标准，并鼓励成员国部署C-V2X路侧设施。
-
目前欧洲处于双技术并存过渡期，但新建项目已明显向C-V2X倾斜。
- 日本：特殊案例
-
日本拥有独立的DSRC标准（ARIB T-109，工作于760MHz频段），主要用于ETC（不停车收费）和V2I安全预警。
-
但日本也在积极推动C-V2X部署，其5.9GHz频段已为C-V2X预留，未来将逐步融合。
1.1.5.2 DSRC技术失利的核心原因（技术层面）
从通信原理角度，DSRC在以下关键指标上落后于C-V2X，导致其未被选为演进方向：
-
MAC层机制先天缺陷：CSMA/CA在高密度车辆场景下（如拥堵路口）会发生严重的隐藏节点与暴露节点问题，导致碰撞概率指数上升，可靠性无法满足5.9GHz频段下V2V安全应用要求。
-
无演进路径：DSRC止步于802.11p，无法向5G NR平滑演进。而C-V2X从LTE-V2X（R14）到NR-V2X（R16/R17）持续增强，支持车辆编队、高级驾驶等复杂场景。
-
同步与资源利用效率：DSRC缺乏集中式或分布式资源协调机制，频谱利用效率低于C-V2X的资源池半静态预留方案。
-
产业链体量差距：C-V2X复用全球庞大的蜂窝通信产业链（芯片、模组、基站），成本优势与技术迭代速度远超DSRC。
结论：作为技术研究者，DSRC属于已进入维护期、不再有标准演进的“遗留技术”。当前及未来全部V2X系统级研究与商用部署应聚焦于 3GPP定义的C-V2X（PC5 + Uu） 架构。
1.2 C-V2X车联网网络架构
车联网的协议栈包括Uu（蜂窝） 和 PC5（直连） 。
1.2.1 Uu 接口（蜂窝通信）
Uu 接口是车载终端（UE）与基站（gNB）之间的接口，其协议栈结构和手机蜂窝通信完全一致。
-
通信方式：终端通过4G/5G基站连接到核心网和云平台。
-
特点：通信距离远、覆盖范围广、带宽大。主要用于V2N（车对网络）场景，如获取远端交通信息、在线导航、影音娱乐等。
-
技术基础：蜂窝网络技术。
-
控制面（Control Plane）：负责传输信令消息，主要承载 RRC（无线资源控制） 和 NAS（非接入层）协议。
缩写 英文全称 中文释义 职责 RRC Radio Resource Control 无线资源控制 L3 层协议，负责连接管理、系统消息广播、测量报告、切换控制 NAS Non-Access Stratum 非接入层 位于 RRC 之上，终端与核心网之间直接交互，负责注册、鉴权、服务请求、会话管理 -
用户面（User Plane）：负责传输用户业务数据，在蜂窝网络中主要是IP数据包。
-
SDAP层（L2）：将QoS流映射到数据无线承载（DRB）。
-
PDCP层（L2）：进行IP头压缩（ROHC）、加密和完整性保护。
-
RLC层（L2）：负责数据的分段/重组和ARQ重传。
-
MAC层（L2）：进行调度、HARQ、逻辑信道到传输信道的映射。
-
PHY层（L1）：处理编码、调制、多天线映射等物理层信号。
-
| 缩写 | 英文全称 | 中文释义 | 职责 |
|---|---|---|---|
| SDAP | Service Data Adaptation Protocol | 服务数据适配协议 | L2 最上层，将 QoS 流映射到 DRB（数据无线承载） |
| PDCP | Packet Data Convergence Protocol | 分组数据汇聚协议 | IP 头压缩（ROHC）、加密、完整性保护 |
| RLC | Radio Link Control | 无线链路控制 | 数据分段/重组，通过 ARQ 机制重传 |
| MAC | Medium Access Control | 媒体接入控制 | 调度、HARQ、逻辑信道↔传输信道映射 |
| PHY | Physical Layer | 物理层 | L1，编码、调制、多天线映射 |
| ROHC | Robust Header Compression | 健壮头压缩 | 将 IP 包头从 40 字节压缩到 3~4 字节，节省空口资源 |
|---|---|---|---|
| ARQ | Automatic Repeat reQuest | 自动重传请求 | 与 HARQ 配合的链路层重传机制（RLC 层用） |
| HARQ | Hybrid Automatic Repeat reQuest | 混合自动重传请求 | 物理层/MAC 层的"纠错+重传"机制 |
| DRB | Data Radio Bearer | 数据无线承载 | 用户面数据在空口上的承载通道 |
| QoS | Quality of Service | 服务质量 | 区分不同业务（语音/视频/数据）的带宽、时延、可靠性要求 |
1.2.2 PC5 接口（直连通信）
PC5 是车载终端之间（V2V）或与路侧单元（V2I）直连通信的接口。
-
通信方式：设备与设备之间直接通信，无需经过基站。
-
特点：低时延、高可靠。专为V2V（车对车）、V2I（车对基础设施）、V2P（车对行人）这类对实时性要求极高的安全应用设计。
-
工作频段：主要在5.9GHz的智能交通系统专用频段。
-
技术名称：在3GPP标准中，这种直连通信方式被称为 “Sidelink” （侧行链路）。
-
控制面（Control Plane）：主要用于传输SBCCH（侧行链路广播控制信道 Sidelink Broadcast Control Channel），包含 SL-RRC（Sidelink Radio Resource Control 侧行链路无线资源控制）。
- 功能差异：与Uu口的RRC不同，SL-RRC不处理与基站的连接管理，而是专注于PC5接口的资源池配置、同步参考源选择等。
-
用户面（User Plane）：负责传输V2X业务数据，这些数据可以是 IP类型（仅支持IPv6）或 非IP类型。非IP类型用于传输由上层定义的V2X消息，如基于IEEE 1609的WSMP（WAVE短消息协议）。
- 层间交互：PC5用户面支持单播、组播和广播三种通信方式。上层协议（V2X层）会通知AS层（接入层）本次传输使用哪种方式。
-
关于V2X层：在应用层和AS层之间，还存在一个 V2X层。其主要功能是进行消息的编解码（如将BSM编码为ASN.1 PER格式），并将消息映射到对应的PC5 QoS流。
1.2.2.1 PC5接口协议栈结构图
PC5接口（侧行链路） 协议栈
在PC5接口的协议栈中，物理层（L1）和MAC层（L2）是紧密协作的底层核心。
1.2.2.2 物理层 (PHY)
物理层是PC5接口的最底层，负责将MAC层传来的数据比特，最终转换成在5.9GHz频段上传输的无线电波。
-
四大物理信道：物理层通过四种信道完成不同任务。
-
PSCCH (Physical Sidelink Control Channel): 物理侧行链路控制信道，承载SCI (Sidelink Control Information，侧行链路控制信息)。SCI是“数据说明书”，告诉接收方数据的“位置”（时频资源）、“格式”（调制编码方案）和“优先级”。
-
PSSCH (Physical Sidelink Shared Channel): 物理侧行链路共享信道，承载实际的V2X业务数据（如BSM消息）。PSSCH是数据传输的“货运车厢”，一个传输块（TB）必须与它关联的SCI在同一个子帧内传输。
-
PSFCH (Physical Sidelink Feedback Channel): 物理侧行链路反馈信道，仅存在于NR-V2X（5G）中。它用于接收端向发送端反馈HARQ (Hybrid Automatic Repeat reQuest，混合自动重传请求)的ACK/NACK，是实现高可靠通信的关键。
-
PSBCH (Physical Sidelink Broadcast Channel): 物理侧行链路广播信道，用于广播同步信号和最基本的系统信息（MIB-SL），是终端间建立同步的基础。
-
-
资源单位：子信道与子帧/时隙：物理层定义了通信的“时间-频率”基本单位。
-
频域单位 - 子信道 (Sub-channel)：资源池在频域上被划分为多个子信道。一个PSSCH可以占用一个或多个连续的子信道。这类似于将高速公路划分为多条车道。
-
时域单位 - 子帧/时隙 (Subframe/Slot)：在时间维度上，LTE-V2X以子帧（1ms） 为单位；NR-V2X则引入了更灵活的时隙（Slot）。
-
资源池 (Resource Pool)：是预定义的时频资源集合，Mode 2下车辆就在这个“停车场”里自主选择“车位”（资源）。
-
-
同步机制 (Synchronization)：车辆间通信前必须先“对表”。同步源遵循严格的优先级：GNSS (Global Navigation Satellite System，全球导航卫星系统) > 基站 (gNB/eNB) > 其他车辆。在没有GNSS和基站的场景下，车辆可通过PSBCH广播的同步信号（SLSS）来相互同步。
1.2.2.3 媒体接入控制层 (MAC)
MAC层负责将物理层的资源合理分配给各个应用。
-
核心职责：资源分配模式 (Mode 1 vs. Mode 2)
-
Mode 1 (网络调度模式)：适用于有基站覆盖的场景。车辆向基站申请，基站通过Uu接口下发Sidelink Grant来分配资源。优点是可靠性高，能有效避免干扰。
-
Mode 2 (自主资源选择模式)：适用于无基站覆盖的场景。车辆自主从预配置的资源池中选择资源。Mode 2是实现“去中心化”通信的核心。
-
-
Mode 2 的核心机制：基于感知的资源选择：这是MAC层最复杂、最核心的部分。整个过程是连续的闭环。
-
感知 (Sensing)：车辆持续监听并解码其他车辆的SCI，记录资源占用情况。
-
资源排除 (Resource Exclusion)：车辆根据感知结果，排除已被高优先级业务占用或信号强度（SL-RSRP）过高的资源。
-
资源选择 (Resource Selection)：车辆从剩余的候选资源中，随机选择一个进行发送。
-
半持续调度 (SPS, Semi-Persistent Scheduling)：为减少开销，车辆选定资源后会周期性地使用该资源，直到触发重选。这好比在固定车位长期停车，直到需要挪车为止。
-
-
其它关键功能
-
HARQ (混合自动重传请求)：NR-V2X的关键增强。接收端通过PSFCH反馈，发送端根据反馈决定是否重传，极大提升了可靠性。
-
优先级处理与逻辑信道复用：MAC层负责将来自上层的、具有不同优先级的逻辑信道数据复用到一个传输信道上，并优先处理高优先级的业务。
-
数据包过滤：根据数据包中的源和目标Layer-2 ID进行过滤，确保只接收与自己相关的数据。
1.2.3 Uu与PC5接口协议栈的核心差异
| 对比维度 | Uu 接口 (蜂窝通信) | PC5 接口 (直连通信) |
|---|---|---|
| 通信对象 | 车载终端 (UE) ↔ 基站 (gNB) | 车载终端 (UE) ↔ 车载终端 (UE) |
| 核心功能 | 广域覆盖、高速数据传输、信令控制 | 低时延、高可靠的短距直连通信 |
| 控制面顶层协议 | NAS (非接入层) | V2X层 (无NAS) |
| 用户面数据类型 | IP数据包 (IPv4/IPv6) | IP (仅IPv6) 和 非IP (如WSMP) |
| 用户面L2层 | SDAP, PDCP, RLC, MAC | SDAP, PDCP, RLC, MAC (与Uu功能类似) |
| 资源分配方式 | 基站集中调度 (通过DCI) | UE自主感知 (Mode 2) 或基站调度 (Mode 1) |
| 同步参考源 | 基站同步信号 (SSB) | GNSS (全球导航卫星系统) 优先 |
1.2.4 Mode1和Mode2的对比
1.2.4.1 差异对比
| 对比维度 | Mode 1 (网络调度模式) | Mode 2 (终端自主模式) |
|---|---|---|
| 定义 | 基站（gNB）统一调度、分配通信资源。 | 车辆（UE）通过“感知”和“竞争”来获取通信资源。 |
| 资源决策者 | 基站 (gNB) | 车辆终端 (UE) 自身 |
| 网络依赖 | 强依赖：必须在蜂窝网络覆盖下工作。 | 无依赖：可在无网络覆盖区域独立工作。 |
| 主要优势 | 可靠性高、可预测性强，能有效避免资源碰撞。 | 灵活性高、时延低，去除了与基站的信令交互过程，响应更快。 |
| 主要劣势 | 覆盖受限，依赖基站，有单点故障风险。 | 存在碰撞风险，高密度场景下可能出现资源选择冲突。 |
| 适用场景 | 城市主干道、高速等有稳定蜂窝网络覆盖的区域。 | 隧道、地下停车场、偏远地区等无网络覆盖或网络不稳定的区域。 |
1.2.4.2 信令流程对比
- Mode 1:
| 步骤 | 行为主体 | 技术细节 |
|---|---|---|
| 前提条件 | UE & gNB | UE 必须先完成 RRC 连接建立（与手机驻网流程完全一致）。UE 需处于 RRC_CONNECTED 状态，且已获得 V2X 业务授权（通过 NAS 层 V2X 服务授权流程）。 |
| 步骤 1 | UE（内部） | UE 的应用层生成了 V2X 数据（如 BSM 消息）。MAC 层检测到有数据待传，但当前没有可用的 Sidelink Grant。这与手机 UL 数据到达但无 UL Grant 的场景完全一致。 |
| 步骤 2 | UE → gNB | UE 通过 Uu 接口向基站发送 SR（Scheduling Request，调度请求），告知基站“我有数据要发”。基站收到 SR 后，通过 UL Grant（DCI 0_0/0_1）给 UE 分配上行资源，用于 UE 上报 BSR（Buffer Status Report，缓冲区状态报告）。BSR 中携带了 V2X 逻辑信道组（LCG）的待传数据量，以及业务优先级（PPP/5QI）。关键差异：手机只有 UL BSR；V2X Mode 1 需要同时上报 V2X 业务的 BSR，且基站通过专用的 DCI format 3_0/3_1 来调度 Sidelink 资源。 |
| 步骤 3 | gNB（内部） | 基站调度器根据以下因素综合决策：① UE 上报的 BSR（数据量）；② V2X 业务的 QoS 要求（5QI/PQI，如时延<20ms）；③ 当前 Sidelink 资源池的负载情况；④ 其他 UE 的调度请求。基站决定分配给该 UE 的具体时频资源（子信道 + 时隙） 和 MCS（调制编码方案）。 |
| 步骤 4 | gNB → UE | 基站通过 PDCCH（物理下行控制信道） 下发 DCI format 3_0 或 3_1。这个 DCI 中封装的就是 Sidelink Grant，包含：① 资源分配（频域子信道位置、时域时隙偏移）；② MCS；③ 功率控制命令（TPC）。这与手机接收 DCI 0_0/0_1 调度 PUSCH 的逻辑完全一致，只是 DCI 格式不同，且调度对象是 PSSCH（而非 PUSCH）。 |
| 步骤 5 | UE（内部） | UE 的 PHY 层盲检 PDCCH，用 SL-RNTI（或 V2X 专用 RNTI）成功解析 DCI 后，提取 Sidelink Grant。MAC 层根据 Grant 中的时频位置，组装 MAC PDU（包含 BSM 载荷），准备在 PC5 接口发送。 |
| 步骤 6 | UE → 其他UE | UE 在授权的资源上，通过 PSCCH（承载 SCI，侧行链路控制信息） 和 PSSCH（承载 BSM 数据） 广播 V2X 消息。PSCCH 中的 SCI 向周围车辆指示：① 当前 PSSCH 的时频资源位置；② MCS；③ 优先级；④ 是否预留未来周期资源。这与手机在 UL Grant 指定的资源上发送 PUSCH 的逻辑相同，只是物理信道和承载内容不同。 |
- Mode 2:
| 步骤 | 行为主体 | 技术细节（结合你的Modem背景） |
|---|---|---|
| 前提条件 | UE（预配置） | UE 必须预先获得 Sidelink 资源池（Resource Pool） 配置。来源有两个：① 网络侧通过 SIB21（LTE）或 SIB12（NR）广播下发；② 出厂预配置（无网络覆盖场景）。资源池定义了可用的频域范围（子信道数）、时域周期（如 100ms）、以及资源选择窗口参数。这与手机获取小区系统信息（SIB1/SIB2）的逻辑类似，但内容完全不同。 |
| 步骤 1（持续循环） | UE（内部） | 感知（Sensing） 是 Mode 2 最核心的机制。UE 在感知窗口（Sensing Window） 内持续工作：① 接收并解码周围车辆发出的 SCI（侧行链路控制信息），从中提取其他车辆的 资源预留信息（预留周期、占用的子信道）；② 测量每个子信道上的 SL-RSRP（Sidelink 参考信号接收功率），评估信道质量。③ 记录每个候选资源的占用状态和干扰水平。这类似于手机测量邻区 RSRP，但手机是被动测量用于切换，而 V2X UE 是主动感知用于资源选择。 |
| 步骤 2（资源排除） | UE（内部） | 当数据到达时，UE 在 资源选择窗口（Selection Window） 内执行资源排除：① 排除 自身无法监听的时隙（如半双工限制导致的盲区）；② 排除被 高优先级业务 预留的资源（通过解码 SCI 中的优先级字段，与自身待发数据的优先级比较）；③ 排除 SL-RSRP 高于阈值 的资源（代表已被占用且信号较强）。排除的目标：确保候选资源集合中，剩余的资源在感知窗口内未被高优先级业务占用，且干扰水平可接受。 |
| 步骤 3（资源选择） | UE（内部） | 从排除后的候选资源集合中，UE 的 MAC 层随机选择一个资源作为 PSSCH 的发送位置。这个随机选择不是“无脑随机”，而是结合了 历史资源预留信息 和 资源碰撞概率 的综合算法（具体由 MAC 层实现，标准允许厂商自行优化）。 |
| 步骤 4（资源预留，半静态调度） | UE（内部） | UE 在发送的 SCI 中携带资源预留指示，告知周围车辆：① 当前使用的时频资源位置；② 未来 1~3 个周期（每个周期为 100ms） 将继续占用同样的资源进行周期性广播（如 BSM）。这就是 半静态预留（Semi-persistent reservation），核心目的是：降低后续资源选择的概率，提前用“公告”的方式把资源锁住，减少与他车的碰撞风险。预留计数器（Resource Reselection Counter）递减到 0 时，UE 触发一次新的感知和资源选择流程。 |
| 步骤 5（发送） | UE → 其他UE | 与 Mode 1 的步骤 6 完全相同——在选定的资源上通过 PSCCH/PSSCH 广播 V2X 消息。周围车辆根据 SCI 中的预留信息，更新自己的资源占用记录。 |
1.2.4.3 使用场景
-
Mode 1 (网络调度模式)
-
城市密集区：车辆密集，通信需求大且复杂。基站可进行全局优化，有效避免干扰。
-
高速公路：车辆高速行驶，需要高可靠性的通信保障。基站调度可确保关键安全消息的优先传输。
-
十字路口：交通流量大且冲突风险高，需要基站进行精确的资源协调。
-
-
Mode 2 (终端自主模式)
-
隧道与地下停车场：GPS信号和网络信号可能丢失，Mode 2可依靠预配置信息继续工作。
-
偏远地区：基站覆盖不到的地方，车辆之间仍需通信以保证安全。
-
应急场景：基站因灾害受损时，Mode 2可作为备用通信手段。
-
1.2.4.4 BSM (Basic Safety Message，基本安全消息)
V2X 通信中最基础、最核心的消息。车辆以10Hz（每100ms） 的频率向外广播，包含：
-
位置：经纬度、海拔。
-
运动状态：速度、航向角、加速度。
-
车辆属性：长度、宽度。
-
控制状态：刹车状态、方向盘转角、档位。
-
应用场景：前向碰撞预警、盲区监测、变道辅助等。
-
SPAT (Signal Phase and Timing，信号灯相位与配时消息)：由路侧单元（RSU）发出，告知周边车辆当前红绿灯的相位状态（红/黄/绿）和倒计时，实现“绿波车速引导”或“闯红灯预警”。
-
MAP (Map Data，地图数据消息)：由RSU发出，提供高精度的局部路口地图信息，如车道数量、宽度、转向关系、停止线位置等。车辆结合SPAT和自身位置，可做出更准确的驾驶决策。
-
RSI (Road Side Information，路侧信息消息)：由RSU发出，广播临时的道路异常事件，如前方施工、事故、恶劣天气等。
-
RSM (Road Safety Message，路侧安全消息)：由RSU发出，包含RSU自身传感器（如摄像头、雷达）检测到的非机动车、行人等弱势交通参与者的信息。
1.2.5 车联网和蜂窝网的区别
架构对比：蜂窝网 vs. 车联网
架构关键差异点（基于协议栈视角）
| 架构维度 | 蜂窝通信网 (LTE/NR) | C-V2X 车联网 |
|---|---|---|
| 核心接口 | 仅 Uu（UE至RAN） | PC5（直连）与 Uu（蜂窝）双模并存 |
| 通信拓扑 | 星型拓扑：所有终端必须通过基站汇聚 | 混合拓扑：支持终端间网状直连（Sidelink），同时保留星型上行链路 |
| 资源分配模式 | 集中式调度：由基站（gNB/eNB）通过DCI（下行控制信息）动态分配资源 | 分布式感知（Mode 2）：UE自主感知空闲资源并竞争选择（基于侦听和资源预留机制） |
| 移动性管理 | 依赖网络侧的切换（Handover） 流程维持连接 | 直连通信下无切换概念，依赖同步参考源（GNSS或基站）维持时间/频率同步 |
| 数据流向 | 上下行链路（UL/DL）为主 | 侧行链路（Sidelink） 为主要数据面，上下行链路作为辅助或V2N（车对网络）业务通道 |
| 时延与可靠性 | 面向eMBB（增强移动宽带）和uRLLC（超可靠低延迟通信），但Uu接口物理层环路时延较高 | PC5接口针对低时延（<20ms） 和高可靠性（>99.999%） 进行物理层（如PSCCH/PSSCH信道）和MAC层（盲重传）专项优化 |
C-V2X的核心是 3GPP 定义的通信标准。从协议栈的角度看，在 LTE/5G 协议栈基础上，为“车”这个特殊终端做了关键扩展。
1.2.6 V2X（PC5）与蜂窝（Uu）协议栈分层对比
1.2.6.1 AS层
接入层（AS）——C-V2X协议栈的底层核心
-
“不变”的基础：C-V2X的接入层（AS）与手机蜂窝通信的AS层在子层结构上同源，同样包含 PHY（物理层）、MAC（媒体接入控制）、RLC（无线链路控制）、PDCP（分组数据汇聚协议） 等子层。对于NR-V2X（5G）的用户面，还包含 SDAP（服务数据适配协议） 子层；控制面则包含 RRC（无线资源控制） 子层。
-
“变”的关键：C-V2X在传统Uu接口之外，引入了一个全新的接口 —— PC5接口（侧行链路，Sidelink）。
-
PC5（直连通信）：这是C-V2X的“灵魂”。它允许车辆（UE）不经过基站，直接与其他车辆（V2V）、路侧单元（V2I）或行人终端（V2P）通信。这种直连模式是满足车联网低时延（端到端可低至20ms）、高可靠要求的关键。
-
Uu（蜂窝通信）：这是车辆与基站之间的通信接口，用于 V2N（车对网络） 场景，如获取云端路况、高精地图等。
-
1.2.6.1.1 L1
专属信道与同步机制
| 维度 | 蜂窝网 (Uu) | V2X (PC5) |
|---|---|---|
| 物理信道 | PDCCH（控制）、PDSCH（下行数据）、PUCCH（上行控制）、PUSCH（上行数据）、PRACH（随机接入）。 | PSCCH（控制，承载 SCI）、PSSCH（数据，承载 BSM 等）、PSFCH（HARQ 反馈，仅 NR）、PSBCH（广播主信息块 MIB-SL，含同步信息）。 |
| 同步来源 | 基站 SSB（同步信号块）+ SIB1 提供时间和频率同步。UE 基于 SSB 进行小区搜索和频偏补偿（CFO）。 | 优先级 0：GNSS（全球卫星定位系统） 提供绝对时钟（UTC），用于子帧边界对齐。 优先级 1：基站（若覆盖）。 优先级 2/3：其他 UE 转发的 SLSS（侧行链路同步信号）。 |
| 参考信号 | DM-RS、SRS（探测参考信号）、CSI-RS（信道状态信息参考信号）。 | SL-DM-RS（解调参考信号）、SL-CSI-RS（仅 NR-V2X）、SL-SRS（可选）。 |
| 多普勒频移应对 | 以基站为参考，频偏范围相对可控（低速/中速）。 | 面对 相对速度 > 500 km/h 的场景（对向车流），多普勒频移可达 ±1.5~2.0 kHz @ 5.9GHz，对 RF 前端的 AGC 和频偏估计算法提出更苛刻要求。 |
1.2.6.1.2 L2
Uu和V2X的核心差异在 MAC
| 子层 | 蜂窝网 (Uu) | V2X (PC5) |
|---|---|---|
| PDCP | 功能一致。头压缩（ROHC）、加密（Ciphering）、完整性保护、按序递交。 | 功能一致。NR-V2X 支持 ROHC，LTE-V2X 不支持。 |
| RLC | 支持 TM/UM/AM 三种模式。AM 模式用于业务数据，ARQ 重传由基站控制。 | 支持 TM/UM/AM。NR-V2X 单播/组播支持 AM 模式（ARQ），广播仅 TM/UM。 |
| MAC | 集中式调度：UE 向基站（gNB）发送 SR（调度请求）和 BSR（缓冲区状态报告），基站通过 DCI（下行控制信息）动态分配 UL Grant。上行同步（TA） 由基站维护。 | 分布式自主调度（Mode 2 — 主流）：UE 通过侦听（Sensing）资源池，测量 SL-RSRP，解码 SCI 获取预留信息，自主选择空闲资源并半静态预留。无集中调度器。 此外，NR-V2X 支持 MAC CE（控制单元）传递功率余量报告（PHR）等，但与网络无关。 |
| 模式 | 全称 | 核心特点 | 可靠性 |
|---|---|---|---|
| TM | Transparent Mode（透明模式） | 不添加RLC头，基本透传 | 无保证 |
| UM | Unacknowledged Mode（非确认模式） | 有RLC头，无重传 | 部分保证 |
| AM | Acknowledged Mode（确认模式） | 有RLC头，有重传机制 | 高可靠 |
1.2.6.1.3 L3
| 维度 | 蜂窝网 (Uu) | V2X (PC5) |
|---|---|---|
| RRC 功能定位 | 集中式控制。UE 的 RRC 状态（空闲/连接/非激活）由基站（gNB）通过系统信息（SIB）和专用信令统一管理。切换（Handover）完全由网络侧触发。 | 分布式协商。SL-RRC（侧行链路 RRC）仅用于直连通信参数协商（如资源池、MCS 表）。无切换概念，车辆移动时自主保持同步跟踪。若失去 GNSS 同步，需通过 PSBCH（物理侧行广播信道）交互同步信号（SLSS）。 |
| RRC 消息承载 | 通过 SRB（信令无线承载）在 Uu 上传输。 | 通过 SL-SRB（侧行链路信令无线承载）在 PC5 上传输。 |
1.2.6.2 NAS 层
| 维度 | 蜂窝网 (Uu) | V2X (PC5) |
|---|---|---|
| NAS 是否存在 | 存在且必需。包含 5G-MM（注册、鉴权、位置更新）和 5G-SM（PDU 会话建立、QoS 流管理）。NAS 信令终结于 AMF/SMF（核心网网元）。 | 不存在。V2V 直连通信属于 UE 之间端到端通信，不经核心网转发，因此无需建立与核心网的 NAS 会话。UE 仅需预先配置 V2X 授权（通过 Uu 的 NAS 获取），直连通信本身不携带任何 NAS 信令。 |
1.2.7 C-V2X 和手机蜂窝的区别
- 协议栈视角：同源（3GPP），但裁剪与增强
车载蜂窝通信模组与智能手机的区别
| 协议层 | 智能手机 (UE) | 车载蜂窝模组 (T-Box / V-UE) | 差异实质 |
|---|---|---|---|
| NAS层（非接入层） | 完整支持 5G-MM（注册/鉴权/TAU）和5G-SM（PDU会话建立）。支持IMS（VoLTE/VoNR语音）、SMS短信、紧急呼叫（eCall需单独APN）。 | 裁剪子集。必须支持eCall（紧急呼叫，法规强制）、远程诊断/OTA（通过特定APN）。通常不支持VoLTE/VoNR自然人语音通话（除非娱乐系统授权），不支持SMS短信业务。 | 车载NAS更聚焦于“机器通信”（M2M）和“安全回传”，不承载自然人通信业务。 |
| RRC层（L3/AS） | 支持标准连接控制、测量报告、切换（Handover）。 | 在标准RRC基础上，增加了高速移动增强（如多普勒频偏预补偿上报）和V2X专用SIB（系统信息块） 的解析能力。 | 相同信令流程，但参数配置针对时速250km/h以上场景优化。 |
| 接入层（L2/L1） | 支持常规eMBB业务（大带宽）。 | 在支持常规蜂窝频段基础上，额外支持ITS专用频段（5.9GHz）的PC5物理层（PSCCH/PSSCH）处理。 | 这是本质区别：车载模组是 “Uu + PC5”双模基带，手机基带无PC5能力。 |
- 射频前端视角：功率等级与天线配置不同
| 射频维度 | 智能手机 | 车载蜂窝模组 | 技术原因 |
|---|---|---|---|
| 发射功率（Power Class） | 通常 Class 3 (23 dBm) 或 Class 2 (26 dBm) | 通常支持 Class 1 (33 dBm) 或 Class 2，且PC5接口有独立功率等级（如Class 3@23dBm，但覆盖要求更高） | 车辆外壳屏蔽损耗大（金属车体），需更高发射功率保证上行链路预算；PC5需保证数百米直连覆盖。 |
| 天线配置 | 2x2 MIMO为标配，4x4仅高端机型。 | 4x4 MIMO为标配，且常外置鲨鱼鳍天线组，支持多频段共体设计。 | 车辆天线位置优越（车顶），空间不受限，可部署更高增益阵列。 |
| 工作频段支持 | 全球数十个蜂窝频段（B1~B41等），支持漫游。 | 蜂窝部分仅部署目标市场频段（如中国B3/B5/B8/B41等），但额外固定支持ITS 5.9GHz频段（PC5）。 | 车载无全球漫游刚需，但PC5频段为强制标配。 |
- 系统集成视角
| 维度 | 相同 | 不同 |
|---|---|---|
| 物理形态 | 车载OBU内部确实封装了一颗蜂窝基带芯片（Modem），其内部架构（DSP+ARM核）与手机Modem同源（如高通SA515M/SA525M，或华为Balong）。 | 它没有独立的操作系统（Android/iOS）。手机是“AP（应用处理器）+ Modem”双芯片架构；车载中，Modem仅作为外设，挂载在车机主控（域控制器）或T-Box的MCU上，通过PCIe/USB等接口传输AT指令和数据。 |
| 功能承载 | 数据面（IP数据流）完全一致——车辆可通过蜂窝网络在线导航、听音乐、下载OTA升级包，这与手机使用数据业务无异。 | 语音通话（VoLTE/VoNR）和短信（SMS）通常被禁用或阉割，因为车载场景中自然人语音交互走的是蓝牙免提（HFP协议）映射手机，而非车载本机号码。车载eCall是特殊的紧急IP语音（通过IMS，但UI不向用户开放）。 |
| 协议栈归属 | NAS层均接入同一核心网（5GC/EPC），获得IP地址。 | NAS层不发起IMS注册（除非专门配置了车载语音业务），因此车载蜂窝模块本质上是一个 “纯数据终端”，附带eCall紧急能力。 |
车载通信模块（T-Box / V-UE）是一个“双模3GPP UE”：
蜂窝模组（Uu）：是一个裁剪了自然人通话/短信业务的纯数据类Cat.4/Cat.6/5G RedCap或eMBB终端，其AS层协议与手机完全一致（共享3GPP基线代码），但NAS层只激活数据APN和紧急呼叫APN，不激活IMS语音/SMS APN。
V2X模组（PC5）：是在同一基带芯片（或协处理器）上，独立运行的侧行链路通信子系统，拥有独立的PHY/MAC/RRC状态机，工作在5.9GHz ITS频段，与蜂窝Uu链路时分或频分复用，但逻辑上完全解耦。
1.2.8 车联网专用层
C-V2X 协议栈在接入层（AS）之上，专门为高速移动的车联网环境构建了网络与传输层、安全层、消息层和应用层。这四层共同构成了 C-V2X 的“车联网专用层”，是实现 V2X 智能交通应用的核心。
协议栈分层图
1.2.8.1 网络与传输层：基于位置的“智能路由”
这层的核心是GeoNetworking（地理网络）协议。它解决的是“数据包如何在高速移动的车辆间高效传递”的问题。
-
核心机制：它不依赖固定的IP地址，而是使用地理位置进行寻址和路由。数据包的目标可以是一个地理区域（如“前方500米内的所有车辆”），而非一个具体的设备ID。
-
多跳转发（Multi-hop）：通过车辆间的接力转发，实现“超视距”通信。当前方发生事故，信息可以通过一辆接一辆的车向后传递，突破单车的通信覆盖范围。
-
传输协议：GeoNetworking之上通常运行BTP（基本传输协议），为上层应用提供更简洁的传输服务。同时，它也支持承载标准的 UDP/IP 数据包。
对工程师的价值：理解GeoNetworking是分析V2X通信时延、丢包和覆盖范围等问题的基础。
GeoNetworking（地理网络协议）是由ETSI（欧洲电信标准协会）为智能交通系统（ITS）定义的一套网络层协议标准。 它是一套专为车辆自组织网络（VANET）设计的、基于地理位置信息进行数据包路由和转发的协议。
即，它让车辆不依赖IP地址，而是根据“地理位置”来收发信息，解决了传统IP协议在高速移动的车联网中效率低下的问题。
- 核心思想：地理寻址与转发
传统互联网通信依赖IP地址（如192.168.1.1）来定位设备。但在车联网中，车辆高速移动，IP地址会频繁变化，效率极低。GeoNetworking的核心创新在于使用地理位置作为通信的核心依据。
-
地理寻址 (Geographical Addressing)：数据包的收件人不再是一个固定的ID（如IP地址），而是一个物理区域，例如“北京市朝阳区建国门外大街1号附近500米范围内的所有车辆”。
-
地理转发 (Geographical Forwarding)：数据包的传递路径不是预先设定好的，而是由沿途的车辆根据实时的地理位置动态决定的。
- 工作机制
GeoNetworking的工作机制包含以下几个核心环节：
-
邻居信息表 (Neighbour Location Table)：每辆支持GeoNetworking的车都会维护一张表，记录周围车辆的位置、速度和地址等信息。
-
贪婪转发 (Greedy Forwarding)：这是最基本的数据转发策略。当一辆车需要转发数据时，它会查看自己的邻居信息表，然后选择距离目标区域最近的那辆车作为下一跳。这个过程会不断重复，直到数据到达目标区域。
-
多跳传输 (Multi-hop)：GeoNetworking支持多跳传输，即数据包可以通过中间车辆作为中继，一跳一跳地传递到更远的地方。这使得信息能够远超单辆车的通信范围，实现“超视距”传播。
-
区域广播 (Geocast/Broadcast)：这是一种非常典型的应用，车辆可以向一个特定地理区域内的所有节点广播信息。例如，前方发生事故的车辆可以向后方1公里范围内的所有车辆广播预警。
- 在协议栈中的位置
在C-V2X协议栈中，GeoNetworking位于网络层与传输层。
-
下层：它依赖底层的接入层（如PC5接口）提供的通信链路。
-
上层：它为上层协议（如BTP，即基本传输协议）提供服务，而V2X应用（如碰撞预警）则运行在BTP之上。
- 标准与实现
GeoNetworking是欧洲ETSI ITS标准体系的核心组成部分。其主要规范文档是 ETSI EN 302 636 系列。
-
开源实现：社区有一些开源实现，如Vanetza，可用于研究和开发。
-
与中国C-V2X的关系：中国的C-V2X标准体系在直连通信的网络层和传输层，也采纳了与GeoNetworking设计理念和功能类似的技术。
GeoNetworking的重要性体现在：
实现“超视距”感知：它是V2V和V2I实现多跳通信、扩展感知范围的核心技术。
支撑安全应用：它是实现碰撞预警、紧急刹车提醒等主动安全应用的网络基础。
理解系统行为：理解GeoNetworking，有助于分析和定位V2X通信中的时延、丢包等问题，尤其是在复杂的城市环境中。
1.2.8.2 安全层：V2X通信的“信任基石”
安全层确保每一条V2X消息都来自合法的发送者，且内容未被篡改。其基础是公钥基础设施（PKI）。
-
身份认证与消息完整性：每个V2X消息都附带一个数字签名。发送方使用其私钥签名，接收方使用发送方证书中的公钥验证签名。这个流程由 IEEE 1609.2 标准定义。
-
隐私保护（假名证书）：为防止车辆轨迹被长期追踪，系统会为车辆分发大量短期有效的假名证书（Pseudonym Certificate）。车辆会周期性切换证书和链路层标识符，避免被关联。
-
低延迟验证：为满足V2X安全应用低于20毫秒的时延要求，安全层采用证书吊销列表（CRL） 和短效证书的组合机制，避免在线查询带来的延迟。
1.2.8.3 消息层：V2X世界的“通用语言”
消息层定义了车辆间交换信息的标准化“语法和词汇”，是不同品牌车辆能够相互理解的基础。
-
核心标准：主要由美国汽车工程师协会（SAE）制定的 SAE J2735 标准定义。
-
消息编码：所有消息采用 ASN.1（抽象语法标记一） 进行编码，这是一种紧凑、高效的二进制编码方式。
-
关键消息类型：SAE J2735 定义了17种基本消息类型，其中最核心的包括：
| 消息类型 | 英文全称 | 发送方 | 核心作用 | 关键数据 |
|---|---|---|---|---|
| BSM | Basic Safety Message | 车辆 (V2V) | 最基础、最核心的消息，相当于车辆的“数字心跳”。它让车辆能持续向周围广播自身状态，是所有安全应用的基础。 | 位置、速度、航向、刹车状态、车辆尺寸等。 |
| SPAT | Signal Phase and Timing | 路侧单元 (RSU) (V2I) | 广播路口信号灯的实时状态和倒计时。 | 当前灯色（红/黄/绿）、剩余秒数等。 |
| MAP | Map Data | 路侧单元 (RSU) (V2I) | 提供路口及周边道路的高精度地图信息。 | 车道数量、宽度、走向、停止线位置等。 |
| RSM | Road Side Message | 路侧单元 (RSU) (V2I) | 分享RSU通过自身传感器（如摄像头）探测到的交通参与者信息。 | 行人、非机动车的位置和速度等。 |
| RSI | Road Side Information | 路侧单元 (RSU) (V2I) | 广播交通事件和道路状况信息。 | 前方施工、事故、限速等。 |
1.2.8.4 应用层：V2X价值的最终体现
应用层是V2X技术的“用户界面”，它消费下层传来的数据，实现具体的智能交通场景。
-
核心场景：基于这些标准化消息，应用层可实现数十种V2X应用场景。
-
主动安全类：前向碰撞预警（FCW）、交叉路口碰撞预警（ICW）、紧急制动预警（EBW） 等。
-
通行效率类：绿波车速引导，根据SPAT消息建议车速。
-
协同控制类：协同自适应巡航控制（C-ACC），通过V2V通信实现更紧密、平稳的编队行驶。
-
| 应用场景 | 英文缩写 | 依赖消息 | 核心逻辑 |
|---|---|---|---|
| 前向碰撞预警 | FCW | BSM | 前车急刹（减速度>0.4g），其BSM的“紧急制动”标志位置位。后车收到后计算 TTC（碰撞时间） ，若TTC过短则预警。 |
| 交叉路口碰撞预警 | ICW | BSM, MAP | 两车通过BSM获知彼此位置和速度。结合MAP计算各自到达路口中心的预计时间（TTI） ，若TTI接近则有碰撞风险。 |
| 盲区/变道预警 | BSW/LCW | BSM | 本车打转向灯准备变道。若收到盲区内或后方快速接近的车辆的BSM，计算出有碰撞风险则预警。 |
| 闯红灯预警 | RLVW | SPAT, MAP | 本车结合MAP和自身位置判断是否接近路口，并根据SPAT判断当前信号灯状态，若为红灯且车辆可能越线则预警。 |
| 绿波车速引导 | GLOSA | SPAT, MAP | 车辆根据SPAT和MAP信息，结合自身速度，计算出可以不停车通过路口的经济车速区间并推荐给驾驶员。 |
| 紧急车辆避让 | EVW | BSM (高优先级) | 紧急车辆（如救护车）广播含特殊优先级的BSM。周围车辆收到后，在屏幕上提示避让方向和距离。 |
1.2.9 车路云协同系统
“车路云协同”是一个分层解耦、协同决策的复杂大系统。将感知、计算和决策能力分布在“车端”、“路侧”和“云端”，通过“网络”进行实时协同，实现1+1+1>3的系统增益。
1.2.9.1 分层架构
| 层级 | 核心组件 | 核心职责 |
|---|---|---|
| 车端 | OBU、ADCU、车载传感器 | 感知环境、执行决策。OBU负责V2X通信，ADCU融合本车传感器与V2X信息做出驾驶决策。 |
| 路侧 | RSU、摄像头/雷达、信号机 | 超视距感知与信息广播。弥补单车感知盲区，广播信号灯状态、施工/事故信息。 |
| 云端 | 边缘云、区域云、中心云 | 全局态势感知与协同决策。边缘云负责低时延实时处理，区域云负责城市级调度，中心云负责全局数据汇聚与AI训练。 |
| 网络 | PC5、Uu、光纤 | 数据通道。PC5保障低时延直连，Uu实现广域覆盖，光纤提供路侧回传。 |
| 安全支撑 | PKI、高精地图、标准体系 | 系统基石。保障通信可信、提供统一时空参考、确保互联互通。 |
1.2.9.2 端到端数据流与协同逻辑
流程拆解：
| 阶段 | 步骤 | 技术要点 |
|---|---|---|
| 感知阶段 | ①~③ | RSU通过摄像头/雷达进行路侧感知，在MEC上完成多源数据融合（时间/空间同步校准），生成RSM（路侧安全消息）和RSI（路侧信息）。 |
| 交互阶段 | ④~⑥ | RSU通过PC5接口周期广播MAP（地图）、SPAT（信号灯相位）和RSI（路侧信息）。车辆结合自身GNSS/IMU数据进行时空同步，将路侧信息映射到本车坐标系。 |
| 决策阶段 | ⑦~⑧ | 车辆根据SPAT和MAP信息：① 若判断有闯红灯风险，触发RLVW（闯红灯预警）并请求AEB（自动紧急制动）；② 若为绿灯，计算GLOSA（绿波车速引导）建议。 |
| 数据闭环阶段 | ⑨~⑫ | 车辆将BSM（基本安全消息）和决策状态上报云端；路侧将统计信息（车流量、排队长度）上报云端。云端汇聚全局数据，更新AI模型和路侧控制策略。 |
1.2.9.3 与传统“单车智能”的关键差异
| 维度 | 单车智能 (Autonomous) | 车路云协同 (V2X+Cloud) |
|---|---|---|
| 感知范围 | 受限于传感器物理特性（通常<200米） | 超视距感知（可达数百米至公里级） |
| 感知鲁棒性 | 易受雨、雪、雾、强光等天气影响 | 不受天气影响，V2X直连信号稳定可靠 |
| 决策基础 | 基于本车传感器“独立”决策 | 融合全局态势（路侧+云端+本车）进行协同决策 |
| 交通效率 | 独立车辆无法实现全局优化 | 全局交通调度（信号灯配时优化、拥堵疏导） |
| 系统演进 | 依赖单车算力持续堆叠 | 云端AI驱动，持续OTA进化 |
1.2.9.4 关键支撑技术
| 支撑技术 | 作用 |
|---|---|
| PKI / V2X证书体系 (IEEE 1609.2) | 保障消息来源可信、防篡改、隐私保护（假名证书） |
| 高精地图 (HD Map) | 提供车道级静态信息，作为时空基准（MAP消息） |
| 边缘计算 (MEC) | 将算力下沉到路侧，保障毫秒级响应时延 |
| 时间同步 (GNSS / IEEE 1588v2) | 确保所有节点在同一时间基准上，实现精确时空校准 |
| 标准化体系 | 中国已发布《车路云一体化系统白皮书》、T/CSAE 295系列等标准，统一架构与数据交互规范 |
1.2.9.5 车路云协同 vs. 车联网
车联网（V2X）是车路云协同的“通信底座”，而车路云协同是车联网的“终极系统形态”。
| 维度 | 车联网 (V2X) | 车路云协同系统 |
|---|---|---|
| 覆盖范围 | 侧重于单点通信链路（V2V/V2I/V2P/V2N） | 从“链路”升级为端到端全链路系统 |
| 系统复杂度 | 协议栈维度（接入层→应用层） | 系统维度（端、边、网、云、图、安六大体系） |
| 核心目标 | 确保车辆能“听得见”周围环境（通信可达） | 确保车辆能“听得懂、反应快、决策准”（智能协同） |
| 决策主体 | 车辆接收信息后自行独立决策 | 车辆与云端/路侧协同决策，云端可优化全局策略 |
车路云协同是车联网技术的最高级应用形态。它把车联网当作“神经网络”（负责感知和通信），把云端当作“大脑”（负责思考和决策），把路侧当作“眼睛和耳朵”（负责超视距感知），三者协同完成单个车辆无法完成的全局最优驾驶与交通调度。
2 智能汽车的硬件结构和软件结构分析
智能汽车的硬件电子电气架构（EEA，Electronic & Electrical Architecture） 设计，其趋势是从“一个功能一个盒子”的分布式架构，向“一个大脑控制全身”的集中式架构演进。
-
分布式架构（传统汽车）：全车有70-100个独立的ECU（电子控制单元）。每个ECU控制一个特定功能（如车窗、雨刮），功能固化，协同困难。
-
域集中式架构（多数现代智能汽车）：将功能相近的ECU整合到3-5个功能域控制器中。例如：智驾域、座舱域、车身域等。全车ECU数量可降至30-50个。
-
中央计算+区域架构（最前沿的智能汽车）：这是当前的主流趋势。全车由1个中央计算平台（大脑）+ 2-4个区域控制器（四肢）构成。ECU数量可精简至20个左右，甚至10个以内。
2.1 硬件连接图
当前主流的智能汽车采用中央计算平台（Central Compute Platform）+ 区域控制器（Zonal Controller）的电子电气架构（EEA）。
2.1.1 中央计算平台（1个机箱，多块板卡）
中央计算平台通常包含三个核心域控制器：
| 域控制器 | 功能 | 典型OS |
|---|---|---|
| 智能驾驶域控制器（ADCU） | 环境感知、决策规划、控制执行 | QNX |
| 智能座舱域控制器（CDC） | 仪表、中控、HUD、座椅控制、语音交互 | Android |
| 中央网关（CGW） | 跨域数据路由、网络协议转换、防火墙 | 实时操作系统（RTOS） |
-
智驾核心板：搭载智驾SoC（系统级芯片），如英伟达Orin、地平线征程等。负责处理摄像头、雷达等传感器数据，进行环境感知和路径规划。高端车型可能采用多颗智驾芯片实现算力堆叠或冗余。
-
座舱核心板：搭载座舱SoC，如高通SA8295。负责仪表盘、中控娱乐、语音交互等。
-
基础服务/网关板：搭载高性能MCU（微控制器），如NXP S32G。负责整车控制、电源管理、网络路由等。
三者通过车载以太网（100BASE-T1，未来演进至光通信骨干网）互联，实现座舱、智驾、车身三域数据的实时交互与算力动态调度。
2.1.2 区域控制器（ZCU）（2-4个独立板卡）
区域控制器不再按功能域划分，而是按车辆的物理区域部署。典型布局为前、左、右、后四个ZCU。搭载车规级MCU。
-
前ZCU：连接制动、转向等底盘执行器
-
左/右ZCU：连接车门、车窗、灯光等车身电器
-
后ZCU：连接BMS、VCU等动力系统
-
数据路由：作为该区域的“数据枢纽”，将传感器数据转发给中央计算平台。
-
执行指令：接收中央平台的指令，通过CAN/LIN总线控制该区域的执行器（如车灯、车窗、电机等）。
2.1.3 通信与网关系列（独立板卡）
-
T-Box（远程信息处理盒）：独立的通信模组，包含基带处理器和RF前端，负责4G/5G蜂窝通信（V2N）。
-
V2X模组（直连通信模组）：可能独立，也可能集成在T-Box内。包含V2X基带处理器和RF前端，负责PC5直连通信（V2V/V2I）。
-
中央网关：功能可能由中央计算平台的基础服务板或独立的网关板卡承担。
2.1.4 传感器与执行器
它们是车辆的“神经末梢”，数量众多，分布在车身各处。每个传感器和执行器内部都有一颗简单的芯片（MCU或ASIC）。
-
传感器：摄像头（LVDS/以太网）、毫米波/激光雷达（以太网/CAN）、超声波雷达（CAN）、IMU/GNSS（以太网）
-
执行器：通过CAN/CAN-FD/LIN总线挂载在ZCU或直接连接域控制器
2.1.5 通信网络
| 总线 | 速率 | 典型用途 |
|---|---|---|
| 车载以太网 | 100Mbps ~ 10Gbps | 主干网、智驾/座舱数据 |
| CAN / CAN-FD | 1~5 Mbps | 底盘/动力/车身控制 |
| LIN | 20 kbps | 低速执行器（车窗、座椅等） |
| LVDS | Gbps级 | 摄像头视频传输 |
2.2 软件结构图
智能汽车的软件架构遵循 “分层解耦、服务化” 的设计理念。其核心标准是 AUTOSAR（Automotive Open System Architecture），通过分层隔离实现软硬件解耦。
2.2.1 应用层
应用层承载具体的业务逻辑功能，每个功能模块封装为独立的软件组件（SWC）：
-
智能驾驶：自适应巡航（ACC）、自动紧急制动（AEB）、车道保持（LKA）、自动辅助导航驾驶（NOA）、自主代客泊车（AVP）
-
智能座舱：导航、语音交互、影音娱乐、人机界面（HMI）
-
车身控制：灯光、门窗、空调等传统车身功能
-
V2X应用：BSM生成/解析、SPAT/MAP处理、碰撞预警算法
2.2.2 中间件与运行时环境（RTE）
RTE是AUTOSAR架构的核心中间件，位于应用层与基础软件之间，实现应用与底层硬件的隔离。在此基础上，现代智能汽车进一步引入 SOA（面向服务的架构） 理念：
-
SOA服务框架：将系统功能拆分为独立、松耦合的“服务”，通过标准化接口实现服务间的动态调用
-
DDS / SOME/IP：数据分发服务，支持跨域、跨ECU的高效通信
2.2.3 系统软件层
系统软件层采用纵向分层、横向分区的架构：
-
虚拟机监视器（Hypervisor）：在一套计算平台上运行多个操作系统，实现安全隔离。例如智驾域跑QNX、座舱域跑Android、通讯域跑Linux
-
基础软件（BSW）：包含MCAL（微控制器抽象层）、ECU抽象层和基础服务层，提供通信、诊断、网络管理、功能安全等通用服务
2.2.4 硬件层
-
异构计算SoC：集成AI单元、通用计算单元、控制单元、视觉处理单元等
-
车规MCU：如英飞凌TC3xx、NXP S32K等，运行实时控制任务
2.2.5 软硬件协同关系
| 协同维度 | 实现方式 |
|---|---|
| 硬件抽象 | MCAL层将硬件寄存器操作抽象为标准API，应用层无需关心底层MCU型号 |
| 算力调度 | Hypervisor在同一SoC上隔离多个OS，按需分配AI/GPU/CPU资源 |
| 数据流闭环 | 传感器数据 → 智驾域（感知/决策）→ 执行器（制动/转向），全程由中央计算平台调度 |
| 服务化通信 | 应用通过SOA/DDS调用服务，不关心服务部署在哪个ECU或OS上 |
智能汽车的硬件是“中央计算 + 区域控制”的分布式骨架，软件是“分层解耦 + 服务化”的模块化灵魂。两者通过标准化的硬件抽象层（MCAL） 和 服务化的中间件（RTE/SOA） 实现解耦，使汽车从“功能固化的硬件产品”转变为“可软件定义、持续进化的智能终端”。
2.3 通讯域
通讯域（Connectivity Domain）是一个逻辑功能域。它的物理载体通常是 中央网关（Central Gateway, CGW） 或 基础服务域控制器。
-
硬件上：它连接着下方的T-Box、Wi-Fi、GNSS，也连接着上方的ADCU（Autonomous Driving Control Unit 自动驾驶控制单元）和CDC（座舱域控制器 Cockpit Domain Controller），以及右方的ZCU区域控制器。
-
软件上：Linux提供了强大的网络路由（NAT/路由表）、流量整形和防火墙能力。在此之上，它运行着V2X的消息层（SAE J2735编解码）和SOME/IP服务编排，将收到的“前车急刹（BSM）”数据，精准地封装成服务，分别推送给ADCU（触发AEB制动）和CDC（触发仪表盘预警）。
-
包含的总线：它管辖V2X（逻辑消息）、蜂窝（IP隧道）、WiFi/蓝牙（外部设备交互），同时也通过下方的区域控制器（ZCU Zone Control Unit 区域控制单元）间接管理CAN（Controller Area Network 控制器局域网）/LIN（Local Interconnect Network 局部互联网络）总线上的诊断和配置数据。
它负责“理解”和“分发”数据。它运行路由协议、防火墙、网络地址转换（NAT）、DoIP（基于IP的诊断）、OTA更新调度以及SOME/IP（基于IP的面向服务的中间件）服务发现。它承担V2X、蜂窝（4G/5G）、Wi-Fi、蓝牙以及CAN/LIN/Ethernet等总线的管理、路由和调度工作。
2.3.1 通讯模块的物理组成
通讯域涉及三个核心物理模块：T-Box（蜂窝通信）、V2X模组（直连通信） 和中央网关（数据路由）。
关于V2X模组形态：V2X模组可能以独立芯片或独立板卡存在，也可能集成在T-Box内部。目前主流方案是5G+V2X一体化T-Box，在同一块PCB上同时集成蜂窝基带和V2X基带，共享部分资源（如电源、时钟、MCU管理通道）。
2.3.2 硬件连接示意图
| 连接 | 接口类型 | 用途 |
|---|---|---|
| T-Box ↔ 中央网关 | 车载以太网（100BASE-T1） | 主要数据通道，传输V2X消息、远程诊断、OTA数据 |
| T-Box ↔ 中央网关 | CAN/CAN-FD | 备份控制通道，传输电源管理、唤醒/休眠信号 |
| T-Box ↔ 车机（座舱域） | USB | 为车机提供上网通道（类似USB网卡） |
| V2X模组 ↔ AP | PCIe / SDIO / SPI | 高速内部总线，传输V2X基带与AP之间的BSM/SPAT数据 |
| GNSS ↔ AP | UART / I2C | 传输NMEA定位数据及PPS秒脉冲信号 |
| 中央网关 ↔ 各域控制器 | 车载以太网 / CAN | 数据路由与跨域通信 |
| 模块 | 核心芯片 | 连接方式 | 职责 |
|---|---|---|---|
| T-Box | 蜂窝基带 + AP | 以太网→中央网关；RF→蜂窝天线 | 4G/5G蜂窝通信（V2N），远程控制/OTA/eCall |
| OBU | V2X基带 + AP + 安全芯片 | 以太网→中央网关；RF→V2X天线 | PC5直连通信（V2V/V2I/V2P），BSM/SPAT收发 |
| 中央网关板 | 网关MCU + 以太网Switch | 以太网骨干连接所有域 | 跨域路由、防火墙、DoIP诊断、SOME/IP服务发现 |
| 区域控制器 (ZCU) | 车规MCU (如TC3xx) | 以太网上行→网关；CAN/LIN下行→执行器 | 物理区域数据汇聚、执行器驱动、电源管理 |
| 传感器层 | ISP/DSP | LVDS/以太网→智驾域 | 环境感知数据采集 |
| 执行器/ECU | 专用MCU | CAN-FD/LIN→ZCU | 制动/转向/电池/车身控制 |
2.3.3 软件结构分层全景图
| 层级 | 核心组件 | 运行位置 | 功能 |
|---|---|---|---|
| 应用层 | 智驾/座舱/V2X/远程应用 | QNX/Android/Linux | 业务逻辑：ACC、AEB、导航、BSM预警、远程控制 |
| 中间件层 | DDS/ROS2、SOME/IP、MQTT、V2X协议栈 | 各OS内 | 服务发现、数据分发、协议转换、安全加密 |
| 操作系统层 | Hypervisor + 多OS | 各域SoC/MCU | 资源隔离、任务调度、驱动框架 |
| HAL层 | 各硬件抽象驱动 | 各OS内核 | 屏蔽硬件差异，向上提供统一API |
2.3.4 模块间数据流与协同关系
-
V2X预警流：OBU接收PC5消息 → 解析BSM/SPAT → 安全验签 → 以太网传给中央网关 → 网关路由给智驾域（AEB决策）和座舱域（HMI预警）
-
远程控制流：手机App → 云端 → T-Box蜂窝下行 → 中央网关 → 区域控制器 → CAN总线 → 执行器（车门/空调）
-
OTA升级流：云端 → T-Box蜂窝下行 → 中央网关 → 目标ECU（ADCU/CDC/ZCU）
| 缩写 | 英文全称 | 中文释义 | 所在语境 |
|---|---|---|---|
| OBU | On-Board Unit | 车载单元 | V2X 通信的车载终端，接收 RSU/周边车辆发来的 PC5 消息 |
| PC5 | PC5 Interface（3GPP 定义的直接通信接口） | PC5 直连通信接口 | C-V2X 车与车/车与路直连的空中接口（名称来源于 3GPP 技术规范，无显式英文展开） |
| BSM | Basic Safety Message | 基本安全消息 | 车辆周期性广播的自身状态（位置/速度/航向等） |
| SPAT | Signal Phase and Timing | 信号灯相位与配时消息 | RSU 广播的红绿灯相位/倒计时信息 |
| AEB | Autonomous Emergency Braking | 自动紧急制动 | 智驾域基于 V2X 预警触发的主动安全决策 |
| HMI | Human-Machine Interface | 人机交互界面 | 座舱域向驾驶员展示碰撞预警/红绿灯信息的界面 |
| T-Box | Telematics Box | 车载远程通信终端 | 车辆接入蜂窝网的网关设备，连接云端与车内网络 |
| CAN | Controller Area Network | 控制器局域网 | 车内总线，T-Box 下行指令经 CAN 送达执行器 |
| ECU | Electronic Control Unit | 电子控制单元 | 车内各类嵌入式控制器的总称 |
| ADCU | Autonomous Driving Control Unit | 自动驾驶控制单元 | 智驾域控制器 |
| CDC | Connected Data Center（车载数据记录/数据中心）/ Chassis Domain Controller（底盘域控制器） | 车载数据平台 / 底盘域控 | OTA 场景中通常指车载数据中心（记录/转发数据）；若指底盘域则另当别论 |
| ZCU | Zone Control Unit / Zonal Control Unit | 区域控制单元 | 新一代电子电气架构中按物理分区布置的控制器 |
2.3.5 TBOX
T-Box（Telematics BOX，远程信息处理盒） 是安装在车辆上的 蜂窝通信网关（4G/5G Uu 接口）。它的核心任务，是让汽车接入互联网和运营商核心网（V2N），实现车与云端的双向数据交换。
T-Box 就是手机蜂窝模组的“车规级加强版”——它把手机里的“4G/5G Modem”移植到了车上，并注入了专为汽车服务的上层业务逻辑。
T-Box 是车内的“通信外设”，通过车载网络与车内所有核心域控制器相连，同时也承载着外部天线。
2.3.5.1 T-Box 的硬件连接图
| 连接方向 | 接口/介质 | 传输内容 |
|---|---|---|
| 蜂窝天线 → RF | 射频同轴线缆 | 4G/5G 空口信号 |
| Modem → AP | PCIe / USB / SPI（内部总线） | IP 数据包（AT 指令交互） |
| MCU → CAN 总线 | 双绞线（CAN_H/L） | 车速、油门、故障码、车门状态 |
| AP → 中央网关 | 车载以太网 | IP 诊断、大块 OTA 数据 |
| AP → 座舱域 | USB | 为车机提供 4G/5G 热点共享 |
2.3.5.2 T-Box 的软件结构图
T-Box 的软件分层与 OBU 最大的区别在于：它包含完整的 NAS 层（非接入层），因为它需要与运营商核心网（5GC/EPC）进行鉴权、注册和会话管理，同时它的应用层主要面向远程信息处理（Telematics）。
| 比维度 | 智能手机（Uu） | 车载 T-Box（Uu） |
|---|---|---|
| NAS 业务能力 | 完整支持：IMS（VoLTE/VoNR）、SMS、互联网、专用 APN | 裁剪子集：仅保留数据 APN 和 eCall 紧急 APN；不支持 IMS（语音）和 SMS |
| 操作系统 | Android / iOS（带 GUI 和庞大应用框架） | Linux（无 GUI） 或轻量级 RTOS |
| RIL 交互方式 | Java RIL（Android 架构）或 QMI 接口 | 标准 3GPP AT 命令（TS 27.007）+ 扩展车载 AT（如 +CEMODE、+CSCON） |
| 射频调试 | 消费级温度（0~35°C） + 有限频段 | 车规级温度（-40~85°C） + 高功率 PA |
| 电源管理 | 电池供电，强调省电（PSM/eDRX） | 常电（KL30） 供电，强调低功耗待命（唤醒快，<100ms） |
| 传输内容 | 互联网数据 + 实时音视频 | M2M （机对机 machine to machine）数据（JSON 报文、二进制固件包、故障码） |
T-Box 的上层业务主要有：
远程控制（手机控车）：T-Box 接收云端下发的加密指令，通过内部 MCU 转换成 CAN 报文，发送给车身控制器（BCM），打开车门或启动空调。这涉及到 PKI 密钥管理和 CAN 信号定义。
eCall（紧急呼叫）：发生碰撞时，T-Box 自动拨号（通过数据通道建立 IMS 紧急呼叫），并将车辆位置（GPS）和碰撞传感器数据发送给救援中心。
OTA（空中升级）：T-Box 作为“下载代理”，从云端拉取巨大的固件包（约 1~10GB），校验后通过车载以太网分发给座舱域或智驾域。这里涉及 HTTP Range 下载、差分升级（Delta OTA）和完整性校验。
数据采集（Data Collector）：T-Box 周期性（如 5 分钟）采集整车 CAN 信号（车速、剩余电量、故障码），封装成 JSON，通过 MQTT 推送给 OEM 云平台，用于大数据分析或远程诊断。
2.3.6 OBU
OBU（On-Board Unit，车载单元） 是安装在车辆上的 V2X 专用通信终端。它的核心任务，是让车辆能与周围环境（其他车辆、路侧设施、行人）进行 不依赖基站（蜂窝网）的直接对话，即通过 PC5 接口（Sidelink）实现低时延、高可靠的直连通信。
T-Box（远程信息处理盒）和OBU（车载单元）是智能网联汽车中的两个核心通信设备。它们虽然物理上可能集成在一起，但在设计目标、通信对象和核心功能上有本质区别。T-Box是车辆连接云端（V2N）的“数据网关”，而OBU是车辆连接周围环境（V2X）的“安全对讲机”。
2.3.6.1 OBU 的硬件连接图
| 连接方向 | 接口/介质 | 传输内容 |
|---|---|---|
| 输入（天线） | 射频同轴线缆（5.9GHz / GNSS） | V2X 空口信号、GNSS 射频信号 |
| 输出（车内） | 车载以太网（100BASE-T1） | BSM/SPAT 解码后消息、诊断日志、固件升级数据 |
| 输出（车内） | CAN/CAN-FD | 碰撞预警触发信号（备份通道，低时延） |
| 供电 | KL30（常电）/ KL15（点火信号） | 9~36V 宽压输入，支持休眠唤醒 |
BSM：（Basic Safety Message）基本安全消息 车辆周期性广播的自身状态（位置/速度/航向等）
SPAT：（Signal Phase and Timing 信号灯相位与配时消息）RSU 广播的红绿灯相位/倒计时信息
2.3.6.2 OBU 的软件结构图
OBU 的软件遵循 “分层隔离、安全优先” 的设计原则，核心差异在于 不包含 NAS 层（因为直连通信不经过核心网）。
无基站依赖：脱离蜂窝网络依然能预警。
无 NAS 层：不与核心网直接交互。
无复杂 GUI：不跑 Android 大型应用，专注于毫秒级响应。
有 HSM 硬件加速：确保每条 V2X 消息都经过 ECDSA 签名/验签，抵御恶意攻击。
有高精度 GNSS：提供厘米级/亚米级定位，作为 BSM 的位置数据基础。
有标准协议栈：完整实现 3GPP PC5（接入层）+ SAE J2735（消息层）+ IEEE 1609.2（安全层），确保跨品牌、跨车型互通。
2.3.7 5G+V2X一体化T-Box
T-Box模块对应蜂窝，OBU模块对应V2X。这属于分离式架构（Discrete Architecture），两者在物理上是独立的PCB板卡或独立的模组。
5G+V2X一体化T-Box，OBU的“功能（PC5直连通信）”被集成进了T-Box内部，但在逻辑上，V2X功能域依然存在。
2.3.7.1 两种硬件架构对比（分离式 vs. 一体化）
2.3.7.1.1 分离式架构
-
物理形态：T-Box和OBU是两块独立的PCB，各自拥有独立的基带处理器、RF前端、天线接口和电源管理。
-
连接方式：两者通过车载以太网或CAN总线连接。
-
优缺点：开发灵活，可独立采购模块，但成本高、占用空间大、功耗高。
2.3.7.1.2 一体化架构
-
物理形态：单块PCB板，或单个系统级封装（SiP）模组。
-
芯片组合：
-
方案A（双芯片）：一颗独立的蜂窝基带芯片（如高通X70）+ 一颗独立的V2X基带芯片（如高通SA515M），但共用同一颗应用处理器（AP）和同一电源管理芯片（PMIC），封装在同一屏蔽罩内。
-
方案B（单芯片）：一颗SoC同时集成蜂窝（Uu）和V2X（PC5）基带处理单元（如高通Snapdragon Auto 5G Modem-RF Gen 2），物理上只有一颗基带芯片，但内部有两个独立的协议处理核。
-
-
RF前端：可能共用部分射频前端（如PA/LNA），但通常蜂窝（Sub-6GHz）和V2X（5.9GHz）频段相差较远，更多采用独立的天线接口和独立的收发通路。
在单芯片集成方案中，两套协议栈在硬件上拥有独立的 CPU/DSP 核心，在软件上则通过虚拟机 (Virtual Machine, VM) 实现强隔离。它们通常运行在独立的虚拟机中，每个虚拟机拥有自己独立的操作系统（OS）和内存空间。
架构图
- 物理硬件单元分离
在芯片内部，为蜂窝和V2X协议栈各自分配了专属的硬件处理单元。
-
独立的处理器核心（Core）：芯片不再使用单一核心处理所有通信任务，而是为蜂窝和V2X分别配备独立的CPU核心或DSP（数字信号处理器）。
-
独立的硬件加速器：对于计算密集型的操作，如V2X必须的ECDSA签名/验签，会使用独立的硬件加速引擎来完成，确保不占用主CPU资源。
- 软件与任务执行隔离
物理硬件的分离，为实现软件层面的强隔离提供了基础。
-
专属的实时操作系统（RTOS）：每个协议处理核上，可以运行独立的、为特定任务优化的轻量级RTOS。负责V2X的内核运行的是对实时性要求极高的RTOS，以确保响应延迟的确定性。
-
独立的内存与缓存：每个处理核拥有自己专属的内存和缓存空间，彻底杜绝了不同协议栈之间的数据干扰。
-
工作负载隔离（Hypervisor）：通过管理程序（Hypervisor）支持，将不同安全等级的任务（如信息娱乐系统与V2X安全应用）在逻辑上进行隔离。一个核的故障或重启不会影响另一个。
- 协议栈状态机与流程分离
在软件逻辑上，两套协议栈各自拥有完整、独立的状态机和流程。
-
独立的3GPP协议栈：蜂窝侧运行标准的Uu接口协议栈（含NAS/AS层），V2X侧则运行独立的PC5接口协议栈（无NAS层）。两者互不干扰。
-
独立的资源管理：各自管理自己的无线资源，如蜂窝侧由基站调度，V2X侧则自主进行资源感知和选择（Mode 2）。
软件架构
-
蜂窝协议栈（Uu）：包含NAS（非接入层）、RRC、PDCP、RLC、MAC、PHY。
-
V2X协议栈（PC5）：包含SL-RRC、PDCP（NR-V2X）、RLC、MAC、PHY（PSCCH/PSSCH）。
在一体化T-Box中，软件表现为：
-
独立的状态机：Uu协议栈负责手机卡注册、PDU会话；PC5协议栈负责GNSS同步、资源池感知（Mode 2）。两者在基带内部是并行运行、互不干扰的进程。
-
共享应用层：一体化后，T-Box的AP（应用处理器）需要同时处理两类数据。它将V2X的BSM/SPAT解码后，分发给中央网关；将蜂窝下发的OTA包，分发给座舱域。
此架构的关键在于 Type-1 Hypervisor（虚拟机监视器）。它直接运行在硬件之上，其作用是：
-
硬件分区：将物理 CPU 核心（Core1和Core2）、内存等硬件资源进行虚拟化和隔离，为每个虚拟机提供独立的运行环境。
-
操作系统承载：在每个虚拟CPU上，可以运行完全独立的操作系统（OS）。
-
安全通信：提供受控的虚拟机间通信机制（如共享内存），确保数据交换的安全。
在硬件上，两套协议栈使用独立的CPU和DSP核心；
在软件上，则是通过Hypervisor创建的两个独立虚拟机来运行的。
每个虚拟机拥有独立的操作系统和内存空间，实现了彻底的隔离。
这种设计的核心目的，就是通过物理和逻辑的双重隔离，确保V2X这一关键安全功能在任何情况下都不会受到其他系统的干扰。
总结：
| 行业术语 | 物理含义 | 逻辑含义（功能域） |
|---|---|---|
| T-Box（独立） | 只有蜂窝（4G/5G）模组的板卡。 | V2N域：处理远程控制、OTA、诊断数据。 |
| OBU（独立） | 只有V2X（PC5）模组的板卡。 | V2X域：处理BSM、SPAT、安全验签。 |
| V-Box | 部分厂商将集成5G+V2X的盒子称为V-Box（Vehicle Box）。 | 融合域：物理上是一个盒子，逻辑上包含V2N和V2X两个域。 |
| 5G+V2X 一体化T-Box | 单板集成方案。 | 兼容域：物理上无独立OBU，但V2X功能并未消失，而是作为T-Box的一个子功能模块存在。 |
2.3.7.3 设计哲学
将V2X（PC5）功能从蜂窝（Uu）芯片中独立出来，并非技术上的不能，而是一种基于功能安全、部署灵活性和商业战略的审慎设计。
原因：
- 首要动因：功能安全与域隔离
-
安全等级不同：V2X（特别是V2V）直接关系到行车安全，属于功能安全（Functional Safety） 范畴。而传统的蜂窝通信属于信息娱乐等非安全范畴。将两者在物理上隔离，可以防止信息娱乐系统的任何故障或网络攻击影响到关键的V2X安全功能。
-
“安全域”独立运行：独立的V2X芯片可以打造一个不受蜂窝网络状态影响的“安全域”。即使车辆的4G/5G网络断开或受到攻击，V2X的安全预警功能依然能独立、可靠地运行。
-
满足车规严苛要求：V2X芯片必须满足AEC-Q100等严苛的车规级标准，适应-40℃至125℃的极端温度和高振动环境。将满足不同可靠性要求的通信功能分开设计，是更稳妥的工程实践。
- 关键差异：技术特性与设计哲学的根本不同
V2X（PC5）与蜂窝通信（Uu）在技术需求上存在根本性差异，强行集成会大幅增加芯片的设计复杂度。
-
通信模式：蜂窝是“终端-基站”模式，而V2X是“设备到设备（D2D）”的直连模式，协议栈有显著不同。
-
核心需求：
-
V2X（PC5）：追求极低时延（<20ms）和超高可靠性（99.999%）。
-
蜂窝（Uu）：侧重高带宽、广覆盖。
-
-
网络依赖：V2X的一大优势是不依赖蜂窝网络即可工作，这一核心优势要求其射频前端在物理上独立于蜂窝模块。
- 现实因素：标准分歧与全球部署的灵活性
V2X技术的全球标准尚未统一，主要分为 DSRC（基于Wi-Fi） 和 C-V2X（基于蜂窝） 两大阵营。独立的V2X芯片方案能让车厂：
-
灵活选择不同的V2X技术组合，如“蜂窝芯片 + 独立的V2X芯片”。
-
已有芯片厂商推出了单芯片同时支持DSRC和C-V2X的双模方案。
