城市场景车路协同网络需求研究（下）

5.3 效率类应用场景

5.3.1 动态车道管理

选自标准②。动态车道管理是针对交叉口的拥堵问题，通过交叉口处的动态划分车道功能可以实现对交叉口 进口道的空间资源进行实时地合理分配。

业务流：

1.直连通信方式（PC5）：

① 智能网联车辆上报车辆基本信息至 RSU ；

② RSU 上报车辆 BSM 信息至路侧边缘计算平台 ；

③ 路侧感知设备上报道路车辆信息至路侧边缘计算平台 ；

④ 路侧边缘计算平台根据收集的信息决策是否需要变更车道功 能分配方案 ；当车道功能分配方案需要变更，则将具体变更 功能的车道切换为过渡状态 ( 图中数据流④），禁止车辆驶入， 将 RSC 消息通过 RSU 发送给进入路口的智能网联车辆 ( 图 中数据流⑤、⑥）；

⑤ 路侧边缘计算平台根据路口对应区域的智能网联车辆信息和 路侧感知设备信息，确认变更功能车道已清空后，则将具体 变更功能的车道切换为最终变更状态 ( 图中数据流④），将 RSC 消息通过 RSU 发送给进入路口的智能网联车辆 ( 图中数 据流⑤、⑥）。

2.蜂窝通讯方式 (Uu)：

① 智能网联车辆通过 Uu 口上报车辆 BSM 信息至区域计算平台；

② 区域计算平台将 BSM 等消息发送至路侧边缘计算平台 ；

③ 路侧感知设备上报道路车辆信息至路侧边缘计算平台 ；

④ 路侧边缘计算平台根据收集的信息决策是否需要变更车道功能 分配方案 ；当车道功能分配方案需要变更，则将具体变更功能 的车道切换为过渡状态 ( 图中数据流④），禁止车辆驶入，并将 相关信息上报至区域计算平台，区域计算平台将 RSC 消息通过 Uu 口发送给进入路口的智能网联车辆 ( 图中数据流⑤和⑥）；

⑤ 路侧边缘计算平台根据路口对应区域的智能网联车辆信息和路 侧感知设备信息，确认变更功能车道已清空后，则将具体变更 功能的车道切换为最终变更状态 ( 图中数据流④），并将相关 信息上报至区域计算平台，区域计算平台将 RSC 消息通过 Uu 口发送给进入路口的智能网联车辆 ( 图中数据流⑤和⑥）；

5.3.2 绿波车速引导

选自标准①。绿波车速引导 GLOSA 应用将给予驾驶员一个建议车速区间，以使车辆能够经济地、舒适地 ( 不 需要停车等待 ) 通过信号路口。

业务流：

1.直连通信方式（PC5）：

① 通过直接配置的方式，RSU 获取到 MAP 信息，通过对接信 号机的方式，RSU 获取到 SPAT 消息（MAP、SPAT 也可以通 过平台下发的方式获得）；

② RSU 对外广播 SPAT 消息和 MAP 消息，车辆 OBU 接收 SPAT 消息和 MAP 消息，车载应用结合自身的定位和行驶数据信息， 计算出通过路口的引导车速区间，引导车辆通行。

2.蜂窝通讯方式 (Uu)：

平台通过 Uu 口下发 MAP、SPAT，车辆接收后，计算车速，引 导车辆通行。

5.3.3 前方拥堵提醒

选自标准①。智能网联车辆行驶前方发生交通拥堵状况，前方拥堵提醒 TJW 应用将对驾驶员进行提醒。。由 于感知设备（如摄像头）具有交通拥堵检测功能，因此不需要边缘计算单元处理，感知设备可直接将识别结果通 过 RSU/ 平台下发车辆，为车辆提供信息服务。

业务流：

1.直连通信方式（PC5）：

① 感知设备将拥堵信息发送至 RSU ；

② RSU 广播 RSI 消息，车辆 OBU 接收到道路拥堵信息后，根 据自身位置判断是否进行预警。

2.蜂窝通讯方式 (Uu)：

① 车辆周期性上传 BSM 信息 ；

② 感知设备上传拥堵信息至区域计算平台 ；

③ 区域计算平台通过 Uu 口对进入范围的车辆推送道路拥堵信 息 RSI，车端接收到消息后结合车载应用分析，判断是否对 驾驶员进行预警。

5.3.4 协作式优先车辆通行

选自标准②。协作式优先车辆通行是指智能交通系统调度交通资源针对优先车辆采取提前预留车道、封闭道 路或切换信号灯等方式，为优先车辆提供安全高效到达目的地的绿色通道。优先车辆包括警车、消防车、救护车、 工程抢险车、事故勘查车等，未来也可以基于该场景提供差异化行车服务。

业务流：

1.直连通信方式（PC5）：

●  提前预留车道

① 智能网联汽车向 RSU 发送车辆基本信息与行驶意图信息 VIR，包括对于前方指定车道进行预留的请求 ；

② RSU 上报请求信息至路侧边缘计算平台 ；

③ 路侧感知设备将其感知的信息发送至路侧边缘计算平台 ；

④ 路侧边缘计算平台结合请求信息与道路交通信息，处理生成 调度信息，发送至 RSU ；

⑤ RSU 进行广播 RSC 信息，其他车辆 OBU 接受后结合车载应 用分析，及时离开预留车道，为优先车辆让行。

●  车道禁行 / 封闭场景

处于管制路段处或其上游的 RSU 通过本地配置的方式获取封闭 车道或禁行信息，在管制开始前与管制期间，广播此信息，同 时可以对特定车辆下发驾驶引导信息 ；车辆接收 RSU 的车道禁 行 / 封闭信息和引导信息 RSC，能够及时、安全地调整驾驶行为， 遵循交通管制。

●  协作式信号灯优先通行场景

① 优先车辆按照规划好的路线进行行驶，接近信号灯控制路口， 向 RSU 发送行驶状态和优先请求 ；

② RSU 将请求信息发送至路侧边缘计算平台 ；

③ 路侧感知设备上传道路交通信息至路侧边缘计算平台 ；

④ 路侧边缘计算平台结合路口交通流情况，计算优先车辆到达 路口时间，向信号机下发控制指令，信号机生成具体的控制 方案，实现信号灯绿灯延长或红灯早断，以保证优先车辆能 够高效通过路口 ；

⑤ 路侧边缘计算平台同时下发驾驶引导信息至 RSU ；

⑥ RSU 广播 RSC 信息，优先车辆接收到驾驶引导信息后，结合 车载应用分析，进行通行。

2.蜂窝通讯方式 (Uu)：

●  提前预留车道

① 智能网联汽车向区域计算平台发送 BSM 信息与行驶意图信息 VIR，包括对于前方指定车道进行预留的请求 ；

② 区域计算平台将 BSM、VIR 等消息发送至路侧边缘计算平台；

③ 路侧感知设备将其感知的信息发送至路侧边缘计算平台，平 台综合感知信息与车辆 BSM、VIR 等消息进行融合计算，处 理生成调度信息 ；

④ 路侧边缘计算平台将处理后的结果数据上报至区域计算平台；

⑤ 区域计算平台通过 Uu 口向车辆发送 RSC 信息，其他车辆接 收后结合车载应用分析，驶离预留车道，为优先车辆让行。

●  车道禁行 / 封闭场景

车辆周期性上传 BSM 信息，在管制开始前与管制期间，区域计 算平台 / 业务运营平台向接近和通过该区域的车辆发送封闭车 道或禁行信息，同时可以对特定车辆下发驾驶引导信息 RSC， 车辆接收到车道禁行 / 封闭信息后，能够及时、安全地调整驾驶 行为，遵循交通管制。

●  协作式信号灯优先通行场景

① 优先车辆按照规划好的路线进行行驶，接近信号灯控制路口， 向区域计算平台发送行驶状态和优先请求 VIR ；

② 区域计算平台将 VIR 等消息发送至路侧边缘计算平台 ；

③ 路侧感知设备上传道路交通信息至路侧边缘计算平台，平台 结合路口交通流情况，计算优先车辆到达路口时间 ；

④ 路侧边缘计算平台向信号机下发控制指令，信号机生成具体 的控制方案，实现信号灯绿灯延长或红灯早断，以保证优先 车辆能够高效通过路口 ；

⑤ 路侧边缘计算平台将处理后的结果数据上报至区域计算平台；

⑥ 区域计算平台通过 Uu 口下发 RSC 信息，优先车辆接收到驾 驶引导信息后，结合车载应用分析，安全通行。

5.3.5 基于路侧感知的交通状况识别

选自标准③。自动驾驶车辆在真实路况行驶时，如果能提前得知前方路段的交通情况，则可以更好的辅助车 辆进行路径的规划。基于路侧感知的交通状况识别指在混合交通环境下，由路侧感知设备不断感知周边道路交通 信息，实时的识别当前路段的交通流及拥堵状况，并通过 RSU/ 平台将感知结果发送给自动驾驶车辆，辅助车辆 做出正确的决策控制。为了实现较大范围内的交通状况识别与引导，PC5 通讯中，以区域计算平台为该应用场景 的处理终端。

业务流：

1.直连通信方式（PC5）：

① 感知设备将路况信息上报至路侧边缘计算平台，平台进行融 合处理 ；

② 路侧边缘计算平台处理后的结果数据上报至区域计算平台 ；

③ 区域计算平台向相关范围内的 RSU 下发消息 ；

④ RSU 接收后对外广播 RAM 消息，OBU 接收后结合车载应用 制定车辆的行驶策略。

2.蜂窝通讯方式 (Uu)：

① 车辆周期性上传 BSM 信息 ；

② 感知设备将感知到的交通流信息上报至路侧边缘计算平台， 平台进行融合计算 ；

③ 路侧边缘计算平台将处理后的结果数据上报至区域计算平台；

④ 区域计算平台通过 Uu 口下发 RAM 消息至车辆，OBU 接收 后结合车载应用制定车辆的行驶策略。

5.3.6 车内标牌

选自标准①。车内标牌 IVS 应用将给予驾驶员相应的交通标牌提示，保证车辆的安全行驶。

业务流：

1.直连通信方式（PC5）：

① 业务运营平台下发标志牌信息至区域计算平台（区域计算平 台可以通过本地配置的方式得到）；

② 区域计算平台将信息下发至 RSU ；

③ RSU 广播 RSI 消息，车辆 OBU 接收到后结合车载应用判断 是否对车辆进行提醒。

2.蜂窝通讯方式 (Uu)：

车辆上传 BSM 信息至平台，平台通过 Uu 口下发 RSI 消息，车辆接收到信息后，根据自身车辆位置等相关信息判断是否进行标志牌信息提醒。

5.4 信息服务类应用场景

5.4.1 差分数据服务

选自标准②。利用布设在区域内的基础设施（如 GNSS 基准站，地基增强系统等），监测视野内的 GNSS 卫星， 通过集中数据处理，分类获得误差改正参数和完好性信息并播发给范围内的车辆，从而使车辆定位精度提升或实 现符合一定要求的坐标偏转。

业务流：

1.直连通信方式（PC5）：

① 业务运营平台将差分数据信息发送至区域计算平台（区域计 算平台可以通过本地配置的方式得到）；

② 区域计算平台将差分数据信息发送至 RSU ；

③ RSU 广播 RTCM 消息，车辆 OBU 接收后更新车辆定位数据。

2.蜂窝通讯方式 (Uu)：

平台获得误差改正参数和完好性信息 RTCM 消息，通过 Uu 口 对下发给周边车辆，车辆接收后更新车辆定位数据。

5.4.2 场站路径引导服务

选自标准②。在场站内部区域（如停车场，加油站等），向进入的车辆提供站点地图信息、车位信息、服务信息等， 同时为车辆提供路径引导服务。

业务流：

1.直连通信方式（PC5）：

① 智能网联车辆向 RSU 发送入场 / 离场信息或服务请求消息 VIR（包括自身信息、入场 / 离场请求以及意图信息等）；

② RSU 将相关请求信息发送至路侧边缘计算平台 ；

③ 路侧感知设备将场站内信息（场站内道路环境、停车信息等） 上传至路侧边缘计算平台 ；

④ 路侧边缘计算平台结合智能网联车辆的请求信息以及路侧感 知设备上传的信息，为 RSU 下发场站地图信息（包括场站内 地图信息、各类车位信息和服务点信息），同时下发路径引导 信息 ；

⑤ RSU 广播 PAM 消息，车辆 OBU 接收后结合车载应用分析， 实现内部路径规划，前往目的地。

2.蜂窝通讯方式 (Uu)：

① 智能网联车辆通过 Uu 口发送入场 / 离场信息或服务请求 VIR 消息（包括自身信息、入场 / 离场请求以及意图信息等） 至区域计算平台 ；

② 区域计算平台将 VIR 等消息发送至路侧边缘计算平台 ；

③ 路侧感知设备将场站内信息（场站内道路环境、停车信息等） 上传路侧边缘计算平台，平台综合感知信息与车辆 VIR 等消 息进行融合计算 ；

④ 路侧边缘计算平台将处理后的结果数据上报至区域计算平台；

⑤ 区域计算平台通过 Uu 口为智能网联车辆下发 PAM 消息，包 括场站内地图信息、各类车位信息和服务点信息，车辆 OBU 接收后结合车载应用分析，实现内部路径规划，前往目的地。

5.4.3 高精地图版本对齐及动态更新

选自标准③。自动驾驶车辆的安全可靠运行依赖高精度地图的数据，因此要保证自动驾驶车辆能够获得到最 新的地图数据。高精地图版本对齐及动态更新可以通过路端对自动驾驶车辆的高精地图进行动态更新的方式实现， 保证车辆能够获取到最新最完整的高精地图数据，为车辆安全可靠运行提供支撑。

业务流：

1.直连通信方式（PC5）：

① 通过预先配置的方式 RSU 获取高精度地图信息（也可以通过 平台下发获取），RSU 广播最新地图版本消息 ；

② 车辆 OBU 接收后，比对地图版本信息，版本不一致时，车辆 发送更新请求消息至 RSU ；

③ RSU 下发高精度地图数据，OBU 接收到 RAM、CIM 消息后， 完成高精度地图更新。

2.蜂窝通讯方式 (Uu)：

① 区域计算平台 / 业务运营平台通过 Uu 口下发最新地图版本 消息 ；

② 车辆 OBU 接收后，比对地图版本信息，版本不一致时，车辆 发送更新请求消息 ；

③ 区域计算平台 / 业务运营平台根据车辆请求消息，下发高精 度地图数据，OBU 接收到 RAM、CIM 消息后，完成高精度 地图更新。

5.5 交通管理类应用场景

5.5.1 浮动车数据采集

选自标准②。浮动车数据采集是指平台通过接收通信范围内车辆发送的信息（包括行驶状态、驾驶意图以及 感知信息等），进行数据的融合与交通状态分析，形成基于浮动车数据的交通状态评估。

业务流：

1.直连通信方式（PC5）：

① RSU 收集智能网联汽车发送的 BSM 消息、VIR 消息 ；

② RSU 将信息发送至区域计算平台 ；

③ 区域计算平台将信息发送至业务运营平台，平台处理生成交 通评估报告。

2.蜂窝通讯方式 (Uu)：

平台接收通信范围内车辆发送 BSM、VIR 信息，形成交通状态 评估报告。

6 业务时延模型分析

本文中的业务时延指事件发生至智能网联汽车端接收并处理完成的时间。目前行业相关部门组织等（包括 5GAA、 3GPP 等）未制定总时延量化指标，因此下文侧重介绍各模型的总时延计算方法，后续各地实际部署业务中可根据 此计算方法和总时延、处理时延等对各层网络时延提出要求。根据不同业务，场景数据流模型分为以下几种。

6.1 PC5通讯方式

6.1.1 处理终端为路侧感知设备 /RSU

（A）不需要信号机、感知设备等参与，由 RSU 事先配置好 信息，直接下发至智能网联车辆的流量模型如下。该模型涉及 的主要场景为限速预警、协作式优先车辆通行。

此数据流模型的总时延为 ：

总时延 = 传输时延RSU广播传输时延＋处理时延智能网联车辆

（B）不需要信号机、感知设备等参与，由 RSU 事先配置好 信息，根据车辆请求信息，完成数据下发。该模型涉及的主要场 景为高精地图版本对齐及动态更新。

此数据流模型的总时延为 ：

总时延 =2×传输时延RSU广播传输时延＋传输时延OBU至RSU ＋处理时延ARSU ＋处理时延B智能网联车辆

（C）需要信号机上传数据至 RSU，RSU 广播 SPAT、MAP、 RSI 消息，为智能网联车辆提供相关服务。该模型涉及的主要场 景有闯红灯预警、绿波车速引导。

此数据流模型的总时延为 ：

总时延 = 传输时延 A 信号机至RSU ＋传输时延 BRSU广播传输时延＋处理时延 ARSU ＋处理时延 B 智能网联车辆

注：此模型为RSU实时读取信号机信息，因此总时延包括信号机至RSU 的传输时延。

（D）目前的感知设备具有简单的数据处理分析功能，当感 知设备的处理分析能力可以满足应用场景时，路侧感知设备将 处理后的结果发送至 RSU，RSU 进行广播，为车辆提供服务。 主要应用场景有基于路侧感知的“僵尸车”识别、前方拥堵提醒。

此数据流模型的总时延为 ：

总时延 = 传输时延 A 路侧感知设备至RSU ＋传输时延 BRSU广播传输时延＋ 处理时延 A路侧感知设备＋处理时延 BRSU ＋处理时延 C 智能网联车辆

6.1.2 处理终端为路侧边缘计算平台

（A）路侧感知设备将感知到的信息发送至路侧边缘计算平台，边缘计算进行融合处理后将消息通过 RSU 广 播至智能网联汽车。涉及的主要场景主要如下表。

根据感知的目前物是道路车辆、弱势交通参与者、交通参与者 / 障碍物不同可分为如下三种模型。三种模型 的时延分析相同。

此数据流模型的总时延为 ：

总时延 = 传输时延 A 路侧感知设备至路侧边缘计算平台＋传输时延 B 路侧边缘计算平台至RSU ＋传输时延 CRSU广播传输时延＋处理时延A路侧感知设备＋处理时延 B 路侧边缘计算平台＋处理时延 CRSU ＋处理时延 D 智能网联车辆

（B）需要智能网联车辆发送特定的请求信息，路侧感知设备将感知到的信息发送至路侧边缘计算平台，边缘 计算进行融合处理后将消息通过 RSU 广播至智能网联汽车。涉及的主要场景主要如下表。

此数据流模型的总时延为 ：

总时延 =MAX（传输时延 AOBU至RSU ＋传输时延 BRSU至路侧边缘计算平台 ＋处理时延 CRSU，传输时延 C 路侧感知设备至路侧边缘计算平台＋处理时延 A 路侧感知设备）＋传输时延 D 路侧边缘计算平台至RSU ＋传输时延 ERSU广播传输时延 ＋处理时延 B 路侧边缘计算平台＋处理时延 CRSU ＋处理时延 D 智能网联汽车

注 ：路侧边缘计算平台通过 RSU 获取车辆信息和通过路侧感知设备获 取路侧信息可同时进行，因此模型总时延此部分取较大者。

（C）在协作式优先车辆通行场景中协作式信号灯优先通行 应用中，需要路侧边缘计算平台根据优先车辆请求信息、路侧 感知信息生成信控信息下发至信号机。动态车道管理场景流量 模型如下。

此数据流模型的总时延为 ：

总时延 =MAX（传输时延 AOBU至RSU ＋传输时延 BRSU至路侧边缘计算平台 ＋处理时延 CRSU，传输时延 C 路侧感知设备至路侧边缘计算平台＋处理时延 A 路侧感知设备）＋传输时延 D 路侧边缘计算平台至RSU ＋传输时延 ERSU广播传输时延 ＋处理时延 B 路侧边缘计算平台＋处理时延 D 智能网联汽车

注 ：路侧边缘计算平台通过 RSU 获取车辆信息和通过路侧感知设备获 取路侧信息可同时进行，因此模型总时延此部分取较大者。此外图中④ 与⑤＋⑥可以同时进行且④的数据较小，因此总时延不考虑④的时延。

6.1.3 处理终端为区域计算平台

当业务场景对时延要求不高且需要实现较大范围内的感知 与消息广播时，需要以区域计算平台为处理终端。涉及的主要场 景有基于路侧感知的交通状况识别，路侧感知设备对周边的交 通状况进行探测，路侧边缘计算平台完成感知数据处理后通过 区域计算平台推送至 RSU，RSU 周期性广播 RAM 消息，车辆 的 OBU 接收 RAM 消息，车载应用结合自身的定位和行驶数据 信息，对驾驶员进行提示。

此数据流模型的总时延为 ：

总时延 = 传输时延 A 路侧感知设备至路侧边缘计算平台＋传输时延 B 路侧边缘计算平台至区域计算平台＋传输时延 C 区域计算平台至RSU ＋传输时延 DRSU广播传输时延 ＋处理时延 A 路侧感知设备＋处理时延 B 路侧边缘计算平台＋处理时延 C ~区域 计算平台~＋处理时延 CRSU ＋处理时延 D 智能网联车辆

6.1.4 处理终端为业务运营平台

该模型主要分为 2 种数据流模型。

（A）数据流由车端到平台端。主要应用场景为浮动车数据采集。

此数据流模型的总时延为 ：

总时延 = 传输时延 AOBU至RSU ＋传输时延 BRSU至区域计算平台＋传输时 延 C 区域计算平台至业务运营平台＋处理时延 ARSU ＋处理时延 B 区域计算平台

（B）数据流由平台端到车端。涉及的主要应用场景如下。

此数据流模型的总时延为 ：

总时延 = 传输时延 A 业务运营平台至区域计算平台＋传输时延 B 区域计算平台至RSU ＋传输时延 CRSU广播＋处理时延 A 区域计算平台＋处理时延 BRSU ＋处理时延 C 智能网联车辆

6.2 Uu通讯方式

6.2.1 处理终端为区域计算平台

（A）智能网联汽车周期性上报数据至区域计算平台，感知 设备上传处理后的感知信息至区域计算平台，平台将消息下发至 智能网联车辆。因感知设备的数据处理能力满足场景应用需求， 不需要经过路侧边缘计算平台。涉及的场景主要是基于路侧感 知的“僵尸车”识别、前方拥堵提醒。

此数据流模型的总时延为 ：

总时延 = 传输时延 A 路侧感知设备至区域计算平台＋传输时延 B 区域计算平台至车辆 ＋处理时延 A 路侧感知设备＋处理时延 B区域计算平台＋处理时延 C 智能网联车辆

（B）智能网联汽车周期性上报数据至区域计算平台，感知设备上传信息至路侧边缘计算平台，平台将处理后 的数据通过区域计算平台下发至智能网联车辆。涉及的主要场景如下表。

根据感知的目前物是道路车辆、弱势交通参与者、交通参与者 / 障碍物不同可分为如下三种模型。三种模型 的时延分析相同。

此数据流模型的总时延为 ：

总时延 = 传输时延 A 路侧感知设备至路侧边缘计算平台＋传输时延 B 路侧边缘计算平台至区域计算平台 + 传输时延 C 区域计算平台至车辆＋处理时延 A 路侧感知设备＋处理时延 B 路侧边缘计算平台 + 处理时延 C 区域计算平台＋处理时延 D 智能网联车辆

（C）智能网联汽车周期性上报请求信息至区域计算平台，区域计算平台下发消息至路侧边缘计算平台，感知 设备上传信息至路侧边缘计算平台，路侧边缘计算平台结合车辆请求信息和路侧感知信息进行处理，结果通过区 域计算平台下发至智能网联车辆。涉及的主要场景如下表。

此数据流模型的总时延为 ：

总时延 =MAX（传输时延 AOBU至区域计算平台＋传输时延 B 区域计算平台至路侧边缘计算平台＋处理时延 C 区域计算平台，传输时延 C 路侧感知设备至路侧边缘计算平台＋处理时延 A 路侧感知设备）＋传输时延 D 路侧边缘计算平台至区域计算平台 ＋传输时延 E 区域计算平台至车辆＋处理时延 B 路侧边缘计算平台＋处理时延 C 区域计算平台＋处理时延 D 智能网联汽车

注 ：路侧边缘计算平台通过区域计算平台获取车辆信息和通过路侧感知 设备获取路侧信息可同时进行，因此模型总时延此部分取较大者。

（D）在协作式优先车辆通行场景中的协作式信号灯优先通 行应用中，车辆通过区域计算计算平台向路侧边缘计算平台发送 车辆信息，路侧边缘计算平台再收集路侧感知信息生成信控信 息下发至信号机并通过区域计算平台向车辆发送引导信息。此 类场景还有协作式车辆汇入、协作式交叉口通行、动态车道管理。

此数据流模型的总时延为 ：

总时延 =MAX（传输时延 AOBU至区域计算平台＋传输时延 B 区域计算平台至路侧边缘计算平台＋处理时延 C 区域计算平台，传输时延 C 路侧感知设备至路侧边缘计算平台＋处理时延 A 路侧感知设备）＋传输时延 D 路侧边缘计算平台至区域计算平台 ＋传输时延 E 区域计算平台至车辆＋处理时延 B 路侧边缘计算平台＋处理时延 C 区域计算平台＋处理时延 D 智能网联汽车

注 ：路侧边缘计算平台通过区域计算平台获取车辆信息和通过路侧感知 设备获取路侧信息可同时进行，因此模型总时延此部分取较大者。④的 时延小于⑤＋⑥，因此以⑤＋⑥计入总时延。

6.2.2 处理终端为区域计算平台 / 业务运营平台

（A）数据流由车端到平台端。主要应用场景为浮动车数据 采集。

此数据流模型的总时延为 ：

总时延 = 传输时延 A 车端至区域计算平台/业务运营平台

（B）数据流需要在车端与平台端之间交互多次。主要应用 场景为高精地图版本对齐与动态更新。

此数据流模型的总时延为 ：

总时延 =2×传输时延区域计算平台/业务运营平台至车端＋传输时延车端至区域计算平台/业务运营平台＋处理时延 A 车端至区域计算平台/业务运营平台＋处理时延 B 智能网联车辆

（C）数据流由平台端到车端。涉及的主要场景如下表。

此数据流模型的总时延为 ：

总时延 = 传输时延 A 区域计算平台/业务运营平台至车端

7 车路协同设备部署原则及网络需求

7.1 RSU 部署

RSU 是 C-V2X 技术的路侧单元，与车载单元（OBU）通信，可接收交通信号机实时消息、应用服务器下发的 路况信息或检测器检测到的实时交通信息，并动态播报给相关车辆，是车路协同系统中的关键单元。所以 RSU 的 部署是需要重点关注的问题。

7.1.1 RSU一般部署原则

除了传统规划设计中对目标覆盖物的确定、对数据流量的统计、对交通车辆密集程度的统计之外，也要考虑 RSU 对车车 V2V 通信的正面影响能力，即需要判断是否可以通过 RSU 作为网络中继给车与车之间构建额外通信 的机会，将更多孤立的车辆组织进这个车路协同体系中。

7.1.1.1 基于交通流量和业务流量热点的 RSU 部署原则

交通流量热点、业务流量热点通常可以从交管部门或运营商网优系统中获取，热点区域行驶的车辆和行人多， 交通流量大，RSU 服务的业务量也大，在热点区域进行 RSU 的重点部署、额外部署可以作为车路协同组网规划的 入口，从大热点到小热点逐步进行网络组织，这样可以有效解决 RSU 负载均衡的问题，同时解决资源竞争的问题。 基于交通流量和业务流量热点的 RSU 部署是 RSU 网络规划的切入点和核心步骤。

7.1.1.2 基于需求程度的 RSU 部署原则

此原则旨在最小化减少网络资源的浪费，例如目前存在联系的两个区域 A1 和 A2，两区域在合理站距内，但 经过 A1 区域的车辆通常会短时间内会行驶过区域 A2，而区域 A1、A2 均不是交通热点，那么如果在 A1 区已部 署了 RSU，车辆行驶过 A1 区域就会收到相应的服务信息，而直到驶离 A2 区域也不会有新的内容更新，则 A2 区 域完全没有必要再部署一台 RSU。因为车是沿道路行驶的，而车路协同广播信息复杂度较低，所以 V2X 网络规划 完全没有必要按照传统蜂窝网络一样实现无缝覆盖，反而应该最大程度避免过覆盖造成无线资源与投资的浪费甚 至网络干扰。

7.1.2 场景部署

城市场景规划中，RSU 应优先规划道路交叉路口，如交通道路交叉路口、学校、企事业单位等汇入交通主干 道路的路口，再规划交叉路口之间的路段。RSU 规划安装的位置可优先复用电警杆、监控杆部署，当电警杆或监 控杆不可用的时候，考虑使用信号灯杆或新立杆。

7.1.2.1 长直道路

根据 RSU 的实际覆盖半径确定部署间隔及部署点位，优先 复用电警杆、监控杆部署 RSU，当电警杆、监控杆不可用的时候， 再考虑使用信号灯杆或者新立杆，尽量与感知系统共杆部署。针 对道路两侧、道路中间无绿化带，或绿化带内灌木的密度不遮 挡路侧 RSU 信号的情况，可沿道路两侧交叉部署。针对道路中 间存在茂密树木绿化带、树木高度遮挡 RSU 直线传播路径，可 在同一点位道路两侧分别部署 RSU。

7.1.2.2 道路交叉口

7.1.2.2.1 丁字路口

在常规丁字路口，优先复用电警杆或监控杆部署至少 1 台 RSU，当电警杆或监控杆不可用的时候，考虑使用信号灯杆或新 立杆，根据现场实际环境（如树木建筑遮挡、监控区域要求、交 通流量密度等）弹性选择增加 1-2 台 RSU，尽量选择与感知系 统共杆部署，提高杆体复用率。

7.1.2.2.2 十字路口

优先复用电警杆、或监控杆部署感知设备，当电警杆、或 监控杆不可用的时候，考虑使用信号灯杆、或新立杆 ；对于普通 十字路口（中间区域无遮挡物），可采用与感知系统共杆部署的 方式在对角部署 2 台 RSU ；对于复杂十字路口（路口区域较为 开阔、交通流量密度大），可在路口四个转角点位与感知系统共 杆部署 4 台 RSU。

7.1.2.3 特定区域

环岛：根据环岛区域遮挡情况确定 RSU 数量。其他复杂环岛， 如高架下环岛、6 路口等多个路口环岛，根据实际遮挡和安装条 件情况调整数量和安装位置，确保 RSUGNSS 信号和覆盖信号 无遮挡。

乡村场景 ：乡村场景（通常不超过 4 车道）可单侧部署 RSU，优先部署在高风险区域（如急弯盲区、沿路村落、 交叉口等），路口布设原则可参考城市场景十字路口，当遮挡严重时应具体情况具体分析。RSU 的部署点位应兼顾 感知设备的部署点位，同位置部署。

山区场景 ：山区场景（通常不超过 2 车道）RSU 布设原则与乡村场景的类似，应优先在急弯处布设 RSU，在有 感知设备部署的情况下，同位置部署 RSU ；应避免在易山体滑坡等危险区域布设。

匝道 ：在匝道合流区 / 分流区和服务区的出入口处部署摄像设备和雷达设备，有效监视匝道出入口和主线路段 的车辆信息，若发现影响行车安全事件，及时通过 RSU 通报过路车辆。

每一个匝道的出入口 / 服务区的出入口部署 1 个 RSU，用于传输摄像设备、雷达、或融合感知节点上报的行车 安全事件信息。

隧道：V2X 设备 RSU 和 OBU 的正常通信需要设备保持时钟同步。当前，RSU 和 OBU 主要是通过 GNSS 信号 来保持时钟同步的。但隧道场景内无 GNSS 信号，不能依赖 GNSS 信号实现时间同步。为了实现 V2X 设备间的正 常通信，需要网络来为 RSU 和 OBU 提供时钟同步功能。

1.V2X 设备时钟同步需求和场景

如下图所示，车 A 接收 RSU_A 通过 PC5 空口发送的同步信号实现与 RSU_A 的信号同步。车 B 接收 RSU_B 通过 PC5 空口发送的同步信号实现与 RSU_B 的信号同步。为了实现车 A 与车 B 的正常通信，RSU_A 与 RSU_B 需 要实现信号同步。

网络需要为 RSU_A 和 RSU_B 提供时钟同步，不仅需要保障 RSU 和 OBU 间通信，还需要保障以及 OBU 间通 信的正常。

2.网络时钟同步精度

网络时钟同步的精度需求，需要在 OBU 之间正常通信的同步需求前提下，进一步考虑多径时延、信号传播时延、 RSU 自身时间误差、OBU 从 RSU 获得同步时钟的误差等因素的影响，故会高于 LTE-V2X 通信自身的同步精度要 求（作为参考，LTE-TDD 时钟同步要求是 ±1.5us），但具体的经验数值有待在实践中提出并予以验证。

7.2 感知系统部署

感知系统部署应满足以下原则

7.2.1 典型场景部署原则

根据道路环境典型场景设计不同的配置方案，根据场景的风险程度并综合考虑成本因素应用全感知或部分感 知方案。

由于每类场景具有不同的车道数量、中央隔离带、路口转弯半径等属性，具体设备数量也会有很大差异，本节仅说明各场景部署需求，详细设备规格、数量需要根据实际情况部署。

路口摄像机负责对进入感知区域的车辆等目标进行属性识别，雷达负责全感知等级区域的高性能目标识别。

所有摄像机、雷达都向系统贡献自己的感知数据，用于感知范围内的高精度融合感知。

7.2.1.1 长直道路

长直道路交通状况相对简单，在遵守交通规则的前提下，行人、非机动车和机动车都能够各行其道。对道路 感知主要以视频摄像机为主，需要具备机动车的轨迹跟踪能力。

7.2.1.2 道路交叉路口

道路交叉路口（十字路口、丁字路口等路口形态）是道路交通系统中的重要节点，是机动车、非机动车与行 人汇集和转向的区域。在整个道路路网中，交叉口是所有交通冲突的集中点，也是制约交通运行效率的重要影响 因素。 根据城市和乡村道路现况，对道路交叉口进行归纳、分类，针对不同类型的道路交叉口，在交叉口范围内适 当位置配置不同类型和数量的感知设备，感知设备主要以视频摄像机和雷达为主。

7.2.1.3 特定点位和区域

医院、学校、商圈等交通环境复杂、交通流量密集区域，需在路段配置的基础上增加雷达以提高感知能力。 »

环岛 ：环岛属于交叉口的一种特殊形式。道路环岛主要集中为城市主干路，路中绿化带宽度大，环岛直径长， 常规道路交叉口的设备配置无法完全覆盖环岛范围内的道路交通状况。需要在环岛交叉口进口和出口车道均 配置视频摄像机和雷达，以实现范围内全覆盖。

隧道出入口 ：隧道作为城市道路网络中特殊构造物，内部照度偏低且入口光环境过渡剧烈、空间封闭、驾驶 环境不良，车辆在行驶到隧道路段时，车速、车道等行驶状态较正常路段会发生变化，对隧道交通安全影响 巨大。在隧道出入口配置视频摄像机、雷达，对进入和驶出隧道范围内的车辆进行轨迹跟踪和身份识别。

乡村道路（含山区弯道、视野盲区等）：乡村道路环境复杂，多数时间交通情况较简单，采用部分感知等级进 行覆盖，在急弯、盲区等环境剧烈变化区域增设雷达。

匝道 ：匝道作为车辆汇入和驶出的路段，具有车流量大、速度慢、车辆连续变道等行车安全隐患。在匝道处 将同时配置卡口视频摄像机和雷达，实现车辆定位和准确跟踪能力。

7.2.2 分场景部署

7.2.2.1 长直道路

优先复用电警杆部署感知设备，当电警杆不 可用的时候，才考虑使用信号灯杆或者新立杆 ； 摄像头作为推荐必选项，对于一般的长直道路， 根据部署间隔及部署点位，每个点位（包括对向 车道 2 个独立点位）推荐至少 2 个摄像头 ；毫米 波雷达和激光雷达作为可选项，但如果选择部署， 优先推荐雷视共点部署 ；设备安装应避免树木等 遮挡，以免影响摄像头、雷达的感知效果。

长直道路感知覆盖示意图如下：

7.2.2.2 道路交叉路口

优先复用电警杆、或监控杆部署感知设备，当电警杆、或监控杆不可用的时候，考虑使用信号灯杆、或新立杆； 摄像头作为推荐必选项，对于一般的十字路口，推荐至少 4 个摄像头 ；毫米波雷达和激光雷达作为可选项，但如 果选择部署，优先考虑雷视共点部署 ；根据算力需求在落地机箱内部署 1-2 台路侧边缘计算设备。具体来说，感 知单元安装在路口的电警杆、监控杆、或者信号灯杆横臂上，高 6 ～ 8 米，安装位置尽量靠近道路中央位置，以 便更好地正对监控路段。设备安装应避免树木等遮挡，以免影响摄像头、雷达的感知效果。

备注 ：监控杆上摄像头可更好的防逆光、强光，可部分复用已有监控设备，选择电警杆或监控杆部署可用于 补充交管部门不允许使用信号灯杆挂载设备的地区。丁字路口的部署方案可类比十字路口的部署方案调整。

7.2.2.3 特定区域

7.2.2.3.1 环岛

对于环岛型交叉路口，根据实际遮挡和安装 条件情况调整数量和安装位置，确保 RSUGNSS 信号和覆盖信号无遮挡。传感器规划每个路段使 用 1个摄像头进行检测。4 路口则包含 4 个摄像头。 可选配毫米波雷达和激光雷达，并配置边缘计算。

7.2.2.3.2 公共场所

布设雷达、路口摄像设备 ；并配置边缘计算。

7.2.2.3.3 急弯盲区

在急弯道路上，可以通过 2 个摄像头（对象车 道独立点位）对交通参与者、交通事件、流量等进 行检测，可选配毫米波雷达和激光雷达，优先考虑 与摄像头共点部署。根据曲率，感知设备要覆盖范 围保证连续（包括杆下盲区）、无遮挡。感知单元 安装在道路上的监控杆，高 6 ～ 8 米，安装位置尽 量靠近道路中央位置，以便更好地正对监控路段。 设备安装应避免标识牌、树木等遮挡，以免影响 摄像头、雷达的感知效果，并配置边缘计算。

7.2.2.3.4 过村段

在进入和驶离村庄位置，各布设路口摄像设 备和雷达 ；并配置边缘计算。

7.2.2.3.5 乡村交叉口

每个进口方向布设路口摄像设备 A（前向感 知用）、路口摄像设备 B（后向感知用）；并配置边 缘计算。

7.2.2.3.6 山区盲陡易滑坡

危险区域布设 2 个雷达和 2 个路口摄像设备； 并配置边缘计算。

7.2.2.3.7 匝道

主道默认已部署感知设备。选择 1 个摄像头 仅覆盖匝道。摄像头覆盖匝道汇入车辆。主道传 感器按照主道部署间距连续覆盖。可选配毫米波 雷达和激光雷达。；并配置边缘计算。

7.2.2.3.8 隧道场景

在隧道出入口处分别布设雷达、路口摄像设 备 A（前向感知用）和路口摄像设备 B（后向感知 用），推荐必选摄像头部署同 RSU 部署方式，可 选配毫米波雷达和激光雷达，优先考虑与摄像头 共点部署 ；并配置边缘计算。

7.3 网络带宽需求分析

根据现有项目经验，车路协同主要路侧设备的带宽需求如下表所示。

表 路侧设备的带宽需求

注：各厂家设备的带宽需求会有所不同，表中所列举例数据供参考。

如某道路交叉口部署场景，共有 8 个立杆，20 个 900w 摄像头，8 个毫米波雷达，4 个 RSU，则路口接入环 的带宽需求 ：3020+48+35*4=772Mbps。

8 车路协同业务对接入网络需求分析

基于对车路协同业务的流量模型和通信需求分析、业务部署方案分析，本节主要从网络架构、网络功能和网 络性能三方面，就车路协同业务对接入网络的需求进行分析和总结。

8.1 接入网络总体架构

接入网络把车路协同系统的路侧设备，路侧边缘计算平台和区域计算中心（V2Xserver）互联起来，网络架构 如图 3.3-1 所示。（有些项目会将边缘计算集中部署，或和区域计算中心部署在一起。）

接入网可以细分为两个网络部分 ：接入路侧网络和接入回传网络。在边缘计算和区域计算中心部署在一起的 场景里，接入路侧网络和接入回传网络是融合在一起的，整个网络的时延和接入路侧网络的时延要求一样。

如图 3.3-2 所示，接入路侧网络负责路侧摄像机、雷达、路侧边缘计算平台等设备之间的通信，很多车路协同 业务在接入路侧网络完成业务流程，对网络实时性要求高 ；

如图 3.3-3 所示，接入回传网络负责区域计算中心和所管辖的路侧边缘计算平台间的通信，同时和接入路侧网 络一起，承担区域计算中心和路侧设备间的通信。接入回传网有实时通信要求，但没有接入路侧网络高。

8.2 接入网络功能需求

8.2.1 接入网络需要支持边缘计算的各种部署模式

边缘计算有多种部署模式，有分布部署到各路口和杆站，有相对集中到接入机房（机柜）或区域计算中心 ；有 些项目要求部署边缘计算备份。接入网络需要保证边缘计算各种部署模式的通信带宽和时延、网络安全、流量无 绕行等通信要求。

8.2.2 接入网络需要具备良好的扩展性，支持分区域、分步骤逐步建设 ；

城市车路协同业务一般是统一规划，分区域逐步建设，接入网方案需要满足扩展性建设需求，新建网络不影 响原有网络，一起融合为一个整体网络系统。

8.2.3 接入网络需要满足多个业务设备间各种通信要求，具备灵活通信能力 ；

车路协同系统的路侧设备和计算单元等设备间有比较复杂的业务流通信，而且业务场景和业务实现的变化也 会导致通信的变化，因此要求接入网能按业务需求，灵活快速地支持任何设备间的通信需求，和新增设备业务的 通信要求。

8.2.4 入网络需要具备多业务承载能力

车路协同系统中的视频流、车路协同消息、设备管理信息等有不同的网络需求和安全隔离要求，接入网需要 能按各业务要求提供多业务承载和业务隔离。

表 接入网络业务流的QoS等级建议

接入网络要确保高优先级的业务流不会被低于其优先级的业务流影响传输质量。

8.2.5 接入网络需要具备冗余保护能力，支持链路级、设备级保护 ；

车路协同业务需要高可靠传输，需要接入网络能有（单次或多次）断纤通信保护能力，通信设备的单点故障 保护能力。

8.2.6 接入网络设备应满足支持各类设备接入端口需要。

接入路侧网络设备需要和路侧设备、传感器等互联，需要支持 GE 电口、GE 光口、RS485、RS422、RJ45 等接口， 按需支持 POE 供电 ；接入网设备按需支持 10GE、25GE、50GE、100GE 等接口，做网络设备互联组网。 路侧通信设备按需支持所连传感器的物联协议接入，如路面传感器、能见度传感器和气象传感器常采用的 ModBus、Serial/TCP 等协议。

8.2.7 接入网络设备在某些场景下，需要满足终端设备高精度时间同步要求，支持部署PTP 协议；

RSU 和激光雷达等设备需要高精度时间同步，一般是通过 GNSS 和网络来进行时间同步。在隧道等没有 GNSS 信号的场景中，RSU 只能通过网络来保持时间同步（详见 3.1.2.3 中隧道场景时钟同步需求）。

9 车路协同业务对网络运维的需求分析

9.1 车路协同业务的网络管理系统

车路协同网络管控业务流向即为设备状态数据的流向，见图 3.6–1。终端和边缘区域的设备需要接入业务运 营平台，进行全域设备管理与运维，建立设备级运行状况的模型，记录、查询路侧设备的全生命周期，检测和评 估路侧设备的工作状态及预警预测。终端设备包括路侧感知设备、路侧通知设备、RSU、OBU ；路侧边缘计算平 台包括雷达储存和视频储存设备以及平台集群设备等 ；区域计算平台的集群设备以及整体网络设备。

9.2 网络运维平台需求

为支撑车路协同网络的运维，需建立网络与业务监控并重、端到端全覆盖、分级响应的网络运维平台，将面 向网络的分级监控与面向业务的场景监控相结合，工单任务直达运维团队，实现网络与业务问题的快速响应。

业务开通

对网络设备提供业务批量和快速开通的能力，同时支持业务模板定制化，提供业务开通差异化配置修改。 支持业务全生命周期管理，并能实现动态扩缩容调整。

网络全量设备可监可控

车路协同网络运维平台不仅需要对汇聚网、云平台侧网络等大网网络进行监控，还需要对接入网络进行监控， 确保网络全量设备可监、可控。

面向业务的场景监控

建立业务级场景监控，按用户及场景需求维度，定制化呈现网络告警、网络性能指标、运行指标等信息。需要 具备对业务流（五元组）进行 SLA（时延、丢包）实时精确监测，自动还原业务路径，出现故障后实现分钟级故障定位。

巡检管理

在云端进行设备巡检，实现对整网网络设备进行在线健康监测和巡检、，并生成巡检报告，同时提供专业的 修复建议，并生成巡检报告，自动发送给管理员。

基础信息监控

对设备告警、线路告警监控，显示告警级别、告警名称、定位信息、告警产生时间、告警恢复时间等。

性能指标监控和历史性能数据分析

通过实时性能分析工具查看当前设备的实时负载情况。呈现时延、带宽、可靠性等性能指标，可根据用户要 求及业务特点定制。提供历史性能数据查询功能，可以按照 1 小时、7 天、14 天、30 天、365 天等不同时间段进 行统计，同时提供自定义时间段的定制功能，支持导出到 xls、pdf 等格式。

远程升级管理

平台应具备软件 / 补丁版本管理、软件 / 补丁版本升级及软件 / 补丁版本回退功能。 软件 / 补丁版本管理支持设备 / 补丁版本的查询及升级进度的上报和查询，设备历史升级情况查询 ；支持整 包升级包或差分升级包的管理。 软件 / 补丁版本升级管理应具备对设备进行软件 / 补丁远程升级，支持手动或自动方式进行软件 / 补丁升级处 理 ；应具备对设备远程升级包的上传功能 ；支持单设备或设备批量升级。针对平台对设备自动升级的情况，必须 具备配置多个升级时间区间（含日期，时，分，秒等）及多种升级周期（含每天，每周，每月等）参数。软件 / 补丁版本回退应具备设备远程软件 / 补丁版本回退功能，具备回退到最后一次成功运行的设备软件 / 补 丁版本的功能。

SLA 服务指标监控

对故障处理时长、处理及时率等 SLA 指标监控。 拓扑及告警关联监控 ：呈现业务端到端拓扑，并与告警关联呈现。

网络拓扑发现

使用 ICMP、SNMP、LLDP、BGP-LS 等网络协议和技术能够自动快速的发现网络中二层和三层的网络设备， 并根据发现设备之间的关系自动生成全局的二层或三层的网络拓扑结构图。网络管理人员能够看到整个运营网络 系统的网络拓扑结构，包括各个分布地区的子网、各个子网之间的网络连接关系、及其每一子网上的资源和资源 的状态变化。具体信息如下： 各网络设备、网络协议、设备信息（卡、端口、接口、IP、MAC），设备之间的物理和逻辑关系，设备连接信息等。 通过对网络节点状态的轮询，实时监控网络中所有资源的状态。支持拓扑自动事故分析，拓扑图中设备的监控报警， 支持基于业务粒度的网络拓扑可视。

网络资源管理

可以对网络设备的可用性进行监控，监控设备接口的状态信息，包括接口名称、操作管理状态、ICMP 包率、 通断信息、接口发送接收速率等具体指标。监控设备关键资源使用情况，包括 CPU/ 内存使用率等关键资源使用率。 可以对网络设备间链路可用性进行监控，观察链路的通畅度。可以对网络设备进行搜索，搜索条件包括：设备名称、 ip 地址和设备类型等，可以快速的查看设备的运行状态，定位故障问题。

设备 IP、MAC 安全管理

通过终端识别实时监控网络中接入的终端用户，一旦发现异常终端或地址盗用的现象，会迅速产生告警。

配置管理

对网络设备的配置更改进行监控，发现变更后进行告警。提供设备运行配置和启动配置的基线化版本管理， 将每个设备相关的配置文件划分为不同版本管理。运维管理系统能够借助 SFTP上传下载网络设备配置文件，并 在管理服务器侧进行归档存储。这一功能在网络开通和调整时能够对不同阶段的配置情况进行存档。

安全管理

平台应提供完善的用户访问授权、身份认证与权限管理机制。对日常操作进行完整日志记录，并具备日志备 份功能，备份日志的保存支持存储不小于 7 天。当系统出现故障时，能够根据文件系统备份与数据库备份将运维 管理平台恢复到备份前的状态。平台应具备数据定期、自动、手动备份功能。

远程故障诊断

平台应支持支持提供多种丰富的诊断工具，方便管理员对网络异常跟因进行定位。包含基础网络诊断 ：ping、 TraceRoute、远程信息采集，以及应用质量诊断工具 ：检测 TCP 应用 AQM、时延、丢包率参数。

原文作者：爱是与世界平行

原文链接：https://blog.51cto.com/lovebetterworld/5669043