高速公路车路协同网络需求研究

1 概述

1.1 高速公路车路协同系统的建设现状

（1）政策现状

车路协同（车联网）是传统汽车产业与信息通信行业加速融合发展的产物，对于实现传统产业转型升级和“换道超车”起到至关重要的作用，在提升车辆行驶安全、提高交通效率、提供出行信息服务和支持自动驾驶等方面具有重要的意义。
全球范围内，汽车智能化、网联化和电动化催生的车联网产业已经成为包括美、欧、亚等汽车发达国家或地区的重要战略性方向，各国家和地区纷纷加快产业布局、制定发展规划、推进车联网产业化进程。我国也高度重视车联网产业发展，国家各个部委正在积极推动车联网技术研究和产业落地。
2016 年 4 月，《交通运输部信息化十三五发展规划》中提出了要推进智慧公路示范工程，选取重点区域公路项目或路段，开展高速无线通信、车路协同等智能应用。2017 年 1 月，交通运输部在《推进智慧交通发展行动计划》，提出推动智慧交通试点示范工程，推广应用具有短程通信、电子标识、高精度定位、自动监测、自动驾驶等功能的智能运输装备。新建或改造智能交通核心技术检测平台及试验场所，提高车载智能终端、车路协同设备等智能化运输装备的检测能力。2018年 2 月，交通运输部在《加快推进新一代国家交通控制网和智慧公路试点》中提出路运一体化车路协同试点方向。2018年 11 月，工信部发布《车联网（智能网联汽车）直连通信使用 5905-5925MHz 频段的频率管理规定（暂行）》，确定了基于 LTE-V2X 技术的车联网（智能网联汽车）直连通信的工作频段及使用要求。12 月，工信部印发《车联网（智能网联汽车）产业发展行动计划》
，推动形成深度融合、创新活跃、安全可信、竞争力强的车联网产业新生态。2019 年 7 月，交通运输部《数字交通发展规划纲要》中提出推进车联网部署应用。 2019 年 9 月，中共中央、国务院《交通强国建设纲要》提出，加强智能网联汽车（智能汽车、自动驾驶、车路协同）研发，形成自主可控完整的产业链。2020 年 2 月，国家发改委牵头十一部委印发《智能汽车创新发展战略》，提出到 2025 年，智能交通系统相关设施建设取得积极进展，车用无线通信网络（LTE-V2X 等）实现区域覆盖。2020 年 4 月，工信部发布《关于推动 5G 加快发展的通知》，提出要促进“5G+ 车联网”协同发展，推动将车联网纳入国家新型信息基础设施建设工程，促进 LTE-V2X 规模部署。建设国家级车联网先导区，丰富应用场景，探索完善商业模式。2020 年 8 月，交通运输部印发《关于推动交通运输领域新型基础设施建设的指导意见》，提出结合 5G 商用部署，统筹利用物联网、车联网、光纤网等，推动交通基础设施与公共信息基础设施协调建设。
2021 年 2 月，中共中央、国务院印发《国家综合立体交通网规划纲要》，提出推进交通基础设施网与信息网融合发展，推动车联网部署和应用。2021 年 5 月，住建部、工信部联合印发《关于确定智慧城市基础设施与智能网联汽车协同发展第一批试点城市的通知》，确定北京、上海、广州、武汉、长沙、无锡等 6 个城市为智慧城市基础设施与智能网联汽车协同发展第一批试点城市 ；12 月，确定重庆、深圳、厦门等 10 个城市为第二批试点城市。2021 年 7 月，工信部联合 10 部门印发《5G 应用“扬帆”行动计划（2021-2023 年）》，提出要强化汽车、通信、交通等行业的协同，共同建立完备的 5G 与车联网测试评估体系。2021 年 11 月，工业和信息化部发布了《“十四五”信息通信行业发展规划》，提出要加强基于 C-V2X的车联网基础设施部署的顶层设计，“条块结合”推进高速公路车联网升级改造和国家级车联网先导区建设。2021 年 12 月，国家标准化管理委员会、中央网信办、科技部等 10 部门印发《“十四五”推动高质量发展的国家标准体系建设规划》的通知，提出要完善智能网联汽车标准体系，加快智能驾驶辅助、自动驾驶、汽车无线充电、网联通信、信息安全等标准研制。
2017 年至 2021 年，工业和信息化部、公安部、交通运输部及国家标准化管理委员会发布《国家车联网产业标准体系建设指南》系列文件，提出发挥标准在车联网产业生态环境构建中的引领和规范作用。
政策的引导促进了车联网行业的发展，在国家及各部委的政策引导下，近年来各地方政府也积极落实，各省市在开展智慧高速的建设过程中，也将车路协同示范验证考虑在内，目前北京、河北、江苏、浙江、江西、广东、湖南、海南、四川、山东等省市均在探索车路协同在智慧高速中的应用，大大加快了车路协同系统的验证。

（2）项目现状

目前国内多条高速公路的设计和建设中均考虑了车路协同的示范验证，包括延崇高速北京段、京雄高速北京段、京沪高速北京、山东及江苏段、京台高速山东泰安至枣庄段、贵阳至安顺复线、成宜高速等多个项目。
延崇高速北京段是 2022 年冬奥会的重要交通保障通道，是交通运输部绿色公路、智慧公路、品质工程的示范路，全长约 3.2KM，其中车路协同测试段 18KM。车路协同示范路段涉及隧道、服务区、匝道分合流、主线四种应用场景，项目中的智能网联车辆均为奥组委专用车辆，围绕冬奥服务。车路协同示范路段主线设置的高清摄像机、毫米波雷达、RSU等设备均利用沿线照明灯杆进行部署。作为第一条车路协同示范高速，目前该路段已经通车运行，可支持 L4+ 自动驾驶。
京雄高速按照“雄安质量”的总要求，打造新时代可持续发展的高速公路新模式，京雄高速北京段全线 27KM，全线建设车路协同试验路段，在匝道分合流、主线、桥梁三种应用场景部署车路协同系统，并在最内侧车道设置自动驾驶车道，开展车路协同及自动驾驶试点应用研究。除全息感知及车路协同通信系统的设置外，建设基于北斗卫星导航系统的地面时空服务系统，为具有北斗增强信号处理功能的车载终端和路侧设施设备提供稳定可靠的高精度定位和授时服务，支撑重点营运车辆精准管控、车路协同、自动驾驶、应急管理与指挥调度等应用实现。
京沪高速车路协同示范验证路段贯穿北京、天津、河北、山东、江苏等 5 个省市，涉及路段长度约 670 公里，应用场景包括分合流安全预警与诱导场景、隧道安全预警与诱导场景、准全天候辅助通行场景、自由流差异化服务场景等。
项目将完成 10000 辆 C-V2X 车载终端搭载，实现车路协同应用场景 100 个，建成包括部级车路协同平台、区域车路协同云控平台、智慧物流平台、高精地图平台在内的多个云平台，通过车路协同基础设施的规模部署，构建车联网先导应用环境，对车路协同技术及应用场景进行全面测试验证，项目具有“省域跨度大、覆盖范围长、应用场景多、车载终端体量大”等亮点。
京台高速山东泰安至枣庄段是山东省第一条智慧高速，全长 189KM，选取满庄收费站至贤村水库特大桥单侧约20km 建设车路协同试验路段。车路协同示范路段涉及服务区、匝道分合流、桥梁、主线四种应用场景。针对货车占比高的特性，在示范路段最外侧设置自动驾驶专用车道，支持货车编队和 L3 级以上车辆的自动驾驶。
贵阳至安顺复线是贵州省智慧高速重点建设项目，全长 90 公里，全线设置车路协同示范路段，并利用起点 21 公里
路段先试先行，开展智能网联汽车（车路协同）测试与自动驾驶比赛示范应用，在已建设施的基础上增加必要的软硬件设施，进行智慧交通产品测试、自动驾驶仿真测试、车路协同场景验证测试、货车编队测试及示范、专用车道柔性管控测试及示范，促进贵州省智能交通和智能网联汽车产业发展。
蜀道集团通过申请 5905~5925MHz 频道，基于 LTE-V2X 技术，分阶段在蓉城二绕约 8 公里路段、成宜高速约 157公里路段开展车路协同试点。通过部署视频监控、车辆综合检测（毫米波雷达）、气象检测、北斗定位、可变情报板、IP 广播、可变限速标志、RSU 和边缘计算单元等前端系统，实现道路路况、车辆、气象等综合信息的采集和车 - 路（V2I）应用信息的发布，通过车路协同中心云平台、智能网联车载终端、移动 APP、路侧交通诱导设施等联动构建完整的车路协同服务体系。

1.2 高速公路车路协同网络面临的主要问题

1.2.1 网络结构不尽合理

目前国内各省（市、自治区）的高速公路主要采用树型多级管理模式，高速公路通信网络系统与管理模式基本相应，形成“省（市、自治区）通信中心 - 区域 / 路段通信（分）中心 - 基层通信站”的三级管理架构。
image.png
高速公路通信网络干线层数据交换网络与传统的高速公路业务管理逻辑高度同构，表现为典型的下级节点以上级通信节点为核心构成星型结构，总体形成多级树形结构。网络结构以解决上下级节点数据传输为主，同级节点之间没有直接的信息交互。
车路协同要求为车辆提供全程的高时效信息交互服务。这就必然要求边缘节点之间、路段分中心之间进行实时的数据交互。同级节点之间的数据流量急剧增加，而现有网络结构无法适应数据多点流向的复杂应用需求。

1.2.2 网络设备承载能力受限

按照《高速公路通信技术要求》，各省（市、自治区）的高速公路网络系统由省域干线传输网（简称“干线网”）和路段接入网（简称“接入网”）两层系统组成。
干线网方面 ：通过前期调研（结果详见后表）可以发现，各省（市、自治区）高速公路通信网传输网正在向以 OTN 为主流技术体制的方向演变。部分省份仍然采用 SDH 技术。少数省份没有实施单独的传输网。除了以四川为代表的少数省份，其余省（市、自治区）均未实施干线层路由型 IP 网。
接入网方面 ：国内高速公路接入网的通信设备多样，新旧技术混杂的情况，以太网、SDH、MSTP 等多种新旧网络技术并存。早期通信设备（例如 ：STM-1 的 ONU 设备）业务适应和承载能力受限，不足以支撑车路协同、智慧交通等新型业务信息高速可靠交互的带宽需求，必然会出现网络上管理消息传递不畅、调度不够灵活、链路保护不完善等诸多问题。
image.png
总体来看，高速公路通信网承载的业务已经全面向IP 业务演进，通信传输业务需求呈爆发式增长趋势，现有通信传输设备的提档升级势在必行。

1.2.3 网络需求有待系统梳理

车路协同应用是未来高速公路网络承载的主要业务。
按照《智能网联汽车技术路线图 2.0》，车路协同等高新技术仍在发展中，具体的解决方案存在多种技术选择。
网络架构以及部署方案的选择需要由场景需求来决定，车路协同的体系建设非常复杂，加之国内行业组织提出的应用场景中，很多实用的网络相关指标并没有明确量化。另外，个人用户、行业车辆、高速公路运营公司、政府部门对车路协同业务的需求存在差异化 ：个人关注的是如何提高安全性、驾驶体验 ；车端设备关注的是数据是否可信、可靠，信息量是否充足、如何有效使用 ；高速公路运营公司关心的是效益和成本、道路的安全与畅通 ；政府 ( 或公安部门 ) 的需求是高速公路管控，优化交通治理。综上，车路协同体系网络设计开展的依据有待系统研究和梳理，高速公路车路协同试点项目建设可落地可推广的应用领域有待明确，营运车辆和个人车辆的车路协同应用场景标准有待进一步细化和量化，以尽量避免系统建成后的网络方案反复调整。

1.2.4 网络体系演进迭代困难

国内高速公路网络系统基本成型，由于近几年通信技术发展迅速，设备更新换代较快，早期采用的通信网络设备技术相对落后，无法通过简单方式（例如 ：增加或替换通信板卡），实现网络设备提档升级。另外，随着网络拓扑从传统树型网络向网状网演变，边缘通信节点能力需要升级，节点之间的通信链路需要补充，这都需要大量的资金投入，且要强化顶层设计，按规划、有步骤地实施，以保证网络平稳演进迭代。

1.2.5 网管维护体系普遍薄弱

按照高速公路通信的三级管理架构 ：“省级通信中心 - 区域 / 路段通信（分）中心 - 基层通信站”，各级通信节点的维护分别落在省级管理部门（如 ：省监控结算中心）和路公司两个层面，导致通信网络的运维和后期运营的技术管理和行政管理存在不统一、多交叉、多界面，网管维护系统建设普遍薄弱。
按照《高速公路通信技术要求》，干线网络网管系统和接入网络网管系统均有功能要求，但在实际建设中，由于设备种类不同，网络管理信息不畅，无法实现一套后端平台进行统一维护。车路协同这种复杂业务更是加剧了上述矛盾，编制技术方案时需要考虑高速公路运维能力弱的实际情况。

2 高速公路车路协同 体系框架

2.1 高速公路车路协同业务的体系架构

image.png
车路协同业务系统主要由路侧终端、边缘端、云端、外部应用组成，其中一个路侧边缘计算平台会连接多组路侧感知设备，一个区域计算平台连接多个路侧边缘计算平台，一个业务运营平台连接多个区域计算平台。其业务架构和业务流向如图 2.1–1 所示 ：整体架构图流程来源于实际项目经验，某些业务数据流向可能和一些标准规定有一定的出入。
1）路侧感知设备（A）主要是指路侧声光一体机、情报板等设备，其采集的数据根据其数据类型和业务需求不同分别输入到业务运营平台（B）、区域计算平台（C）、路侧边缘计算平台（D）。
2）路侧边缘计算平台（D）进行数据融合计算并把结果形成标准的消息帧，把相应的消息帧传输给区域计算平台（C）、路侧 RSU（F）。
3）区域计算平台（C）进行区域数据以及业务运营平台（B）的数据整合，及 OBU（G）上报车辆自身状态信息的融合，把相应的消息传输给路侧 RSU（F）和路侧通知设备（E），同时把相应的业务数据传输给业务运行平台（B），实现区域内和区域间的数据共享。
4）业务运行平台（B）通过 Uu 口与车载 OBU（G）交互，OBU 上报车辆自身状态信息，同时业务运营平台为车辆提供相应的数据服务。
5）路侧 RSU（F）通过 PC5 接口与车载 OBU（G）和其它路侧交通参与者通信，把区域计算平台（C）的全域消息帧广播给路侧交通参者，实现区域内的 RSU 数据共享。
6）OBU（G）可以根据需求通过 Uu 口连接区域计算平台（C）或业务运营平台（B），获取相应的数据服务。此外，考虑到某些路侧感知设备智能化水平较高，处理分析结果可满足业务场景应用需求，因此存在路侧感知设备直接传输数值至 RSU 的过渡场景。

2.1.1 三级业务平台架构

路侧边缘计算平台 ：实时获取路侧传感器数据进行融合计算，以高性能计算能力提供更高精度和更可靠的融合感知结果和交通事件，完成目标的识别、分类、追踪和轨迹拼接等功能，还能够对车辆车牌识别、运动属性预测等，为路侧交通参与者提供准确的数据服务。路侧边缘计算平台的感知缓存主要存储路侧传感器历史数据，同时对于路侧海量、繁杂的数据进行清洗过滤，抽取业务所需的数据发送给区域计算平台。
区域计算平台 ：区域计算平台完成设备管理、模型管理、算法管理和应用管理，以及和边缘计算平台节点管理等相关功能。同时对路侧传感器的结构化数据、路侧边缘计算平台融合感知的结构化数据进行提取，将计算结果按照标准 T/CSAE 53-2020 和 T/CSAE 157-2020 对应用层要求，形成标准消息帧，发送给路侧 RSU 和业务运营平台。
业务运营平台 ：业务运营平台根据需求有选择性的从路侧感知设备获取所需的实时数据，历史数据可以从路侧计算平台的感知缓存处获取。业务运营平台对全域数据进行挖掘分析，以支撑路侧智能网联汽车整体运行环境，为智能网联汽车提供高精地图、智能导航、交通引导等服务支持，为交通指挥调度提供高精度态势认知等服务支持。同时业务运营平台可对终端设备和边缘设备进行统一的管理，提供针对所有路侧、边缘和区域设备“接入 - 监控 - 管理”的服务，包括对设备的查询、修改和升级配置、删除节点等。收集路侧单元设备的基本信息和状态性能信息，监控设备运行情况，及时对工作异常设备进行故障诊断，并基于终端管理协议对路侧单元设备进行远程管理。

2.1.2 业务接口

AD 接口 ：为路侧传感器设备与路侧边缘计算平台之间的接口（包括感知缓存），主要负责路侧传感器数据根据业务需求上传原始数据至路侧边缘计算平台。
AB 接口 ：为路侧传感器设备与业务运营平台之间的接口，主要负责业务运营平台根据业务需求直接从路侧传感器获取实时数据。
AC 接口 ：为路侧传感器设备与区域计算平台之间的接口，主要负责区域计算平台根据业务需求直接从路侧传感器获取实时数据，或进行传感器直接输出的结构化数据的获取。
DC/CD 接口 ：为路侧边缘计算平台与区域计算平台之间的接口，主要负责路侧边缘计算的结构化数据上传至区域计算平台，和业务运营平台下发业务数据或设备管理数据至路侧边缘计算平台。
CB/BC 接口 ：为区域计算平台与业务运营平台之间的接口，主要负责业务运营平台把标准的消息帧传递给业务运营平台，或业务运营平台根据业务需求，获取路侧传感器历史数据，同时业务运营平台根据请求下发相应的事件数据。
CE 接口 ：区域计算平台与路侧通知设备之间的接口，区域计算平台把交通事件信息下发给路侧通知设备，包括但不限于道路危险状况提、限速提醒、道路施工提醒、弯道提醒、前方拥堵等信息。
DF/FD 接口 ：路侧边缘计算平台与路侧 RSU 之间的接口，主要负责路侧边缘计算平台融合传感器数据后，将计算结果按照标准 T/CSAE 53-2020 和 T/CASE 157-2020 对应用层要求，把数据打包为标准规定的消息帧格式，发给路侧 RSU，同时 RSU 会把接收到 OBU 的数据发给路侧边缘计算平台，丰富其数据，提高其算法的准确度。
CF/FC 接口 ：区域计算平台与路侧 RSU 之间的接口，区域计算平台接收业务运营平台下发的数据，区域计算平台结合实际情况做处理，把数据下发给区域内的 RSU ；同时 RSU 会把相关信息发送给区域平台和业务运营平台，通过这种方式和其它区域内的 RSU 进行数据交互，比如前方事故预警，可以跨区域进行预警信息的播报。
GB/BG、GC/CG 接口 ：车辆 OBU 与区域计算平台和业务运营平台之间的接口，OBU 根据需求通过 Uu 口和区域计算平台或业务运营平台进行数据互通。
根据图 2.1–1，车路协同网络数据业务流向见表 2.1-1：
image.png
image.png

2.2 高速公路车路协同系统的网络架构

高速公路车路协同系统的网络可以细分为路段接入网和省干网两部分，网络架构如图 2.2-1 所示 ：
路段接入网负责把路侧设备、边缘计算单元等设备和路段分中心（区域计算平台）互联 ；没有路段分中心的，直接和路段中心（区域计算平台）互连。其中，路侧设备包括 RSU、智能化路侧感知设备（各类摄像头、激光雷达、毫米波雷达等）、动态交通情报板、路侧气象感知站等，边缘计算单元可通过对路侧设备输出的原始数据信息进行融合判断，提取结构化道路及目标物状态信息，实现数据的分析、处理，以支持车路协同各种应用 ；很多车路协同业务在路侧网络完成业务流程，对网络实时性和带宽要求高。 路段接入网的网络架构可能有多种模式，以支持边缘计算单元全分布或相对集中等多种部署方式。
省干网络负责路段分中心间通信互连、路段分中心到路段中心间通信互连、路段中心间通信互连、路段中心至省中心的通信互连、以及省中心与 2C 服务商 /2B 用户间业务通信。路段分中心间，路段分中心到路段中心间的车路协同业务通信有实时性要求。 UU 模式的车路协同信息是通过连接到 2B 用户（包括运营商）的外联专线来传输的。
计算中心内部网络，是标准的云中心网络架构 ；与 2C 服务商/2B用户的外联网络为专线网络。这两种网络类型的需求明确，都已经大量部署，有比较统一的网络方案。 故本文不做进一步网络需求分析。
image.png

3 高速场景车路协同网络需求分析

3.1 车路协同业务内容分析

车路协同业务对网络建设起到导向作用，为了合理归纳网络需求，本小节应用场景选自目前行业认可度较高的业务相关标准，具体为《合作式智能运输系统 车用通信系统 应用层及应用数据交互标准》（T/CSAE 53-2020）（下文使用标准①代指）、《合作式智能运输系统 车用通信系统应用层及应用数据交互标准》（T/CSAE 157－2020）（下文使用标准②代指）、《基于车路协同的高等级自动驾驶数据交互内容》（T/CSAE 158 －2020）（下文使用标准③代指），并将场景分为安全、效率、信息服务和交通管理四大类，安全类涵盖 7 个业务场景，效率类涵盖 4 个业务场景，信息服务类涵盖 3 个业务场景，交通管理类涵盖 1 个业务场景。针对每个场景，下文从场景定义和业务流两方面进行介绍，其中业务流介绍中列出了实现对应应用场景所需要的主要交互消息，不一定是所有消息，实际实现中，可根据不同的需求和服务水平，使用更多的消息。
由于本小节的业务内容是高速车路协同网络建设的需求导向，不涉及 V2V 内容，因此本小节只分析标准①、标准②和标准③中的 V2I 场景和 V2I/V2V 场景中的 V2I 业务内容。
本小节每一个应用场景均可通过 PC5 通讯和 Uu 通讯两种方式实现。由于不同业务场景的数据处理需求不同以及设备 / 平台在系统架构中的定位和功能不同，因此根据处理终端不同可划分为以下几种业务流 ：

PC5 通讯方式：

① . 处理终端为路侧感知设备 ：目前的感知设备具有简单的数据处理分析功能，当感知设备的处理分析能力可以满足应用场景时，路侧感知设备即为此场景业务流中的数据处理终端。如前方拥堵提醒场景，目前智能摄像机可检测道路拥堵排队长度，摄像机将道路排队长度信息推送至 RSU，RSU 广播 RSI 消息，车辆接收后，车载应用结合自身的定位和行驶数据信息，判断是否进行拥堵提醒。
② . 处理终端为路侧边缘计算平台 ：当业务场景对时延具有严格要求且需要对感知设备采集的信息进行融合处理时，路侧边缘计算平台为处理终端，既可以满足时延的需求，也可以进行数据融合处理。如协作式变道场景，路侧边缘计算平台根据车辆行驶意图和感知设备采集的信息，进行融合处理，生成调度信息并推送至 RSU，RSU 周期性广播 RSC 消息，车辆接收 RSC 消息，车载应用结合自身的定位和行驶数据信息 , 安全行驶。
③ . 处理终端为区域计算平台 ：当业务场景对时延要求不高且需要实现较大范围内的感知与消息广播时，需要以区域计算平台为处理终端。如基于路侧感知的交通状况识别，路侧感知设备（例如摄像头、雷达等）对周边交通状况进行探测，路侧边缘计算平台将处理后的结果数据发送至区域计算平台，平台将数据推送至 RSU，RSU 周期性广播 RAM 消息，车辆接收 RAM 消息，车载应用结合自身的定位和行驶数据信息，判断是否对驾驶员进行提示。
④ . 处理终端为业务运营平台 ：当需要从业务运营平台下发消息支撑应用场景落地或者通过 RSU 收集基本信息，支持信息服务时，处理终端为业务运营平台。需要从业务运营平台下发消息支撑应用场景如车内标牌，业务运营平台下发标志牌信息至 RSU，RSU 广播 RSI 消息，车辆接收后，车载应用判断是否对驾驶员进行提醒。通过 RSU 收集基本信息，支持信息服务的场景如浮动车数据采集，车端周期性广播 BSM 消息，RSU 接收 BSM 消息后上传至业务运营平台，平台进行数据融合处理，进行交通状态分析、事件检测等，为局部或区域的交通管理提供数据支持。

Uu 通讯方式：

① . 处理终端为区域计算平台 ：分为 2 种，一种是区域计算平台直接通过感知设备获取结构化感知数据，并将结果数据推送至智能网联车辆。另一种是路侧边缘计算平台实现感知数据融合处理，或再结合智能网联车辆的请求信息，处理生成结果数据并通过区域计算平台将结果数据推送至智能网联车辆。
② . 处理终端为区域计算平台 / 业务运营平台 ：当只需要收集车辆信息，不需要关联路侧感知设备采集的信息时，平台将预设的消息进行下发或收齐车辆信息进行融合分析，对时延不敏感时，处理终端为业务运营平台。如浮动车数据采集，车辆上报 BSM 信息至业务运营平台，支持平台形成交通状态评估报告。

3.1.1 安全类应用场景

3.1.1.1 限速预警

选自标准①。智能网联车辆行驶过程中，在超出限定速度的情况下，限速预警 SLW 应用对智能网联车辆驾驶员进行预警，提醒驾驶员减速行驶。
业务流：
(1) 直连通信方式（PC5）：
① . 通过本地配置，RSU 获得 MAP 消息和限速信息（也可以通过平台下发的方式获得）;
② . RSU 周期性广播 MAP 和 RSI 消息，车辆 OBU 接收消息后，车载应用结合自身的定位和行驶数据信息分析，如果不满足限速要求，则触发 SLW 预警。
image.png
(2) 蜂窝通讯方式 (Uu) ：
车辆周期性上报 BSM 信息，平台通过 Uu 口下发 MAP 消息和 RSI消息，车辆 OBU 接收后，获取到限速信息，车载应用结合自身的定位和行驶数据信息分析，如果不满足限速要求，则触发 SLW 预警。
image.png

3.1.1.2 基于协同式感知的异常驾驶行为识别

选自标准③。自动驾驶车辆在真实路况行驶时，如果能提前得知周边存在的异常驾驶的车辆，则可以更好的辅助车辆进行路径的规划。基于协同式感知的异常驾驶行为识别指通过路侧感知设备不断感知周边车辆的运行状况，实时的识别当前范围内所存在的异常行驶的车辆，例如逆行车辆、慢行车辆（行驶速度明显低于其他车辆）、快行车辆（行驶速度明显高于其他车辆）等，并将感知结果发送给自动驾驶车辆，辅助车辆做出正确的决策控制。
业务流：
(1) 直连通信方式（PC5）：
① . 路侧感知设备将感知信息发送给路侧边缘计算平台 ；
② . 路侧边缘计算平台将处理后的数据发送至 RSU;
③ . RSU 广播 SSM 消息 , 车辆 OBU 接收后，车载应用结合自身的定位和行驶数据信息，制定车辆的行驶策略。
(2) 蜂窝通讯方式 (Uu) ：
① . 车辆周期性上报 BSM 信息 ；
② . 路侧感知设备将感知信息发送至路侧边缘计算平台，平台进行融合计算 ；
③ . 路侧边缘计算平台将处理后的结果数据上报至区域计算平台 ；
④ . 区域计算平台通过 Uu 口对进入范围的车辆推送 SSM 消息，车端接收到后，车载应用结合自身的定位和行驶数据信息，制定车辆的行驶策略。
image.png

3.1.1.3 感知数据共享

选自标准②。路侧感知设备探测到周围其他车辆或道路异常状况信息，如 ：道路交通事件（如交通事故等）、车辆异常行为 ( 超速、逆行、非常规行驶和异常静止等 )、道路障碍物（如落石、遗撒物、枯枝等）等信息，并将探测到的信息发送至其他车辆，实现感知数据共享。
业务流：
(1) 直连通信方式（PC5）：
① . 路侧感知设备将感知信息传输至路侧边缘计算平台 ；
② . 路侧边缘计算平台处理生成交通参与者信息或道路异常状况信息 ；并将信息发送至 RSU ；
③ . RSU 广播 SSM 消息，OBU 接收到后结合车载应用判断是否进行预警 / 提示等。
image.png
(2) 蜂窝通讯方式 (Uu) ：
① . 车辆周期性上传车辆 BSM 信息 ；
② . 路侧感知设备感知到数据上报路侧边缘计算平台，平台进行融合计算；
③ . 路侧边缘计算平台将处理后的结果数据上报至区域计算平台 ；
④ . 区域计算平台通过 Uu 口推送 SSM 消息至智能网联车辆，OBU 接收到后结合车载应用判断是否进行预警 / 提示等。
image.png

3.1.1.4 协作式变道

选自标准②。智能网联车辆在行驶过程中需要变道，将行驶意图发送至路侧边缘计算平台或区域计算平台，平台通过路侧感知设备收集道路车辆信息，综合处理生成调度信息发送至车辆，车辆根据自身情况调整驾驶行为，使得智能网联车辆能够安全完成变道或延迟变道。
业务流：
(1) 直连通信方式（PC5）：
① . 智能网联汽车向 RSU 发送行驶意图信息 VIR ；
② . RSU 将车辆行驶意图信息发送至路侧边缘计算平台 ；
③ . 路侧感知设备将其感知的信息发送至路侧边缘计算平台 ;
④ . 路侧边缘计算平台综合收集到的信息，进行处理，生成调度信息，发送至 RSU ；
⑤ . RSU 广播调度信息 RSC，OBU 接收后结合车载应用分析，完成变道或延迟变道。
image.png
(2) 蜂窝通讯方式 (Uu) ：
① . 车辆周期性上报 BSM 消息，并上报 VIR 消息至区域计算平台 ；
② . 区域计算平台将 BSM、VIR 等消息发送至路侧边缘计算平台 ；
③ . 路侧感知设备将感知到的车辆信息发送至路侧边缘计算平台，平台综合感知信息与车辆 BSM、VIR 等消息进行融合计算 ；
④ . 路侧边缘计算平台将处理后的结果数据上报至区域计算平台 ；
⑤ . 区域计算平台通过 Uu 口发送 RSC 消息至车辆，OBU 接收后结合车载应用分析，完成变道或延迟变道。
image.png

3.1.1.5 协作式车辆汇入

选自标准②。在道路入口匝道处，通过汇聚周边车辆信息进而生成调度信息，协调匝道和主路汇入车道车辆，引导匝道车辆安全、高效的汇入主路。
业务流：
(1) 直连通信方式（PC5）：
① . 智能网联汽车向 RSU 发送行驶意图信息 VIR ；
② . RSU 将车辆行驶意图信息发送至路侧边缘计算平台 ；
③ . 路侧感知设备将其感知的信息发送至路侧边缘计算平台 ;
④ . 路侧边缘计算平台综合收集到的信息，进行处理，生成调度信息，发送至 RSU ；
⑤ . RSU 广播 RSC 消息，车辆的 OBU 接收消息后，结合自身行驶状态以及道路信息、周围交通参与者信息，生成最终的驾驶行为策略或轨迹规划，安全有效地通过匝道口。
image.png
(2) 蜂窝通讯方式 (Uu) ：
① . 车辆周期性上传 BSM 消息并上报 VIR 消息至区域计算平台 ；
② . 区域计算平台将 BSM、VIR 等消息发送至路侧边缘计算平台 ；
③ . 路侧感知设备将感知到的车辆信息发送至路侧边缘计算平台，平台综合感知信息与车辆 BSM、VIR 等消息进行融合计算 ；
④ . 路侧边缘计算平台将处理后的结果数据上报至区域计算平台 ；
⑤ . 区域计算平台通过 Uu 口下发 RSC 消息至车辆，OBU 接收到后，结合自身行驶状态以及道路信息、周围交通参与者信息，生成最终的驾驶行为策略或轨迹规划，安全有效地通过匝道口。
image.png

3.1.1.6 基于路侧协同的自动驾驶车辆“脱困”

选自标准③。正常情况下，自动驾驶车辆在行驶过程中依赖车辆感知设备感知周边环境，并将感知结果作为车辆决策控制的输入，即自动驾驶车辆自身输出决策控制策略，在某些极端情况下，出现自动驾驶车辆无法应对的场景时，自动驾驶车辆停止自动驾驶。自动驾驶车辆发送请求信息，RSU/ 平台下发控制消息，使得车辆“脱困”。
业务流：
(1) 直连通信方式（PC5）：
基于路侧协同规划的自动驾驶车辆“脱困”
① . 智能网联汽车向 RSU 发送求助信息 VIR ；
② . RSU 上报求助信息至路侧边缘计算平台 ；
③ . 路侧感知设备将其感知的信息发送至路侧边缘计算平台 ；
④ . 路侧边缘计算平台处理生成调度信息，发送至 RSU ；
⑤ . RSU 广播 CIM、RSC 消息，智能网联车辆按调度信息行驶，驶出“受困”区域。
image.png
基于路侧控制的自动驾驶车辆“脱困”
① . 智能网联汽车向 RSU 发送求助信息 VIR ；
② . RSU 上报求助信息至路侧边缘计算平台 ；
③ . 路侧感知设备将其感知的信息发送至路侧边缘计算平台 ；
④ . 路侧边缘计算平台处理生成调度信息，发送至 RSU ；
⑤ . RSU 广播 CIM、RSCV 消息，智能网联车辆接收后，按引导信息行驶并发送响应消息。
image.png
(2) 蜂窝通讯方式 (Uu) ：
基于路侧协同规划的自动驾驶车辆“脱困”
① . 车辆周期性上传 BSM 信息和请求消息 VIR 至区域计算平台 ；
② . 区域计算平台将 BSM、VIR 等消息发送至路侧边缘计算平台 ；
③ . 路侧感知设备将周围路况信息上传至路侧边缘计算平台，平台综合感知信息与车辆 BSM、VIR 等消息进行融合计算 ；
④ . 路侧边缘计算平台将处理后的结果数据上报至区域计算平台 ；
⑤ . 区域计算平台综合分析并通过 Uu 口下发 CIM、RSC 消息，智能网联车辆接收后，按引导信息行驶并发送响应消息。
image.png
基于路侧控制的自动驾驶车辆“脱困”
① . 智能网联汽车向区域计算平台发送求助信息 VIR ；
② . 路侧感知设备将其感知的信息发送至区域计算平台 ；
③ . 路侧感知设备将其感知的信息发送至路侧边缘计算平台，平台综合感知信息与车辆 VIR 等消息进行融合计算 ; ；
④ . 路侧边缘计算平台将处理后的结果数据上报至区域计算平台 ；
⑤ . 区域计算平台通过 Uu 口向车辆发送 CIM、RSCV 消息，智能网联车辆接收后，按引导信息行驶并发送响应消息。
image.png

3.1.1.7 道路危险状况提示

选自标准①。智能网联车辆行驶到潜在危险状况 ( 如前方急转弯等 ) 路段，存在发生事故风险时，道路危险状况提示 HLW 应用对智能网联车辆驾驶员进行预警。
业务流：
(1) 直连通信方式（PC5）：
基于路侧协同规划的自动驾驶车辆“脱困”
① . 通过业务运营平台下发道路危险状况信息至区域计算平台（区域计算平台也可以通过本地配置的方式得到）；
② . 区域计算平台将信息下发至 RSU（RSU 也可以通过本地配置的方式得到）;
③ . RSU 周期性广播 RSI 消息，车辆 OBU 接收 RSI 消息，车载应用结合自身的定位和行驶数据信息，判断是否进行道路危险状况提示。
image.png
(2) 蜂窝通讯方式 (Uu) ：
① . 车辆周期性上传车辆 BSM 消息 ；
② . 平台匹配信息，通过 Uu 口对行车路线上的车辆推送 RSI 消息，车载应用结合自身的定位和行驶数据信息，判断是否进行道路危险状况提示。
image.png

3.1.1.8 弱势交通参与者碰撞预警

选自标准①。智能网联车辆在行驶中，与周边道路维修人员、摩托车等弱势交通参与者存在碰撞危险时，弱势交通参与者碰撞预警 VRUCW 应用将对车辆驾驶员进行预警。
业务流：
(1) 直连通信方式（PC5）：
① . 路侧感知设备将其感知的信息发送至路侧边缘计算平台 ；
② . 路侧边缘计算平台将处理后的消息发送至 RSU ；
③ . RSU 广播 RSM 消息，车辆的 OBU 接收后，车载应用结合自身的定位和行驶数据信息进行判断，若存在弱势交通参与者碰撞风险，则对驾驶员进行预警。
image.png
(2) 蜂窝通讯方式 (Uu) ：
① . 车辆周期性向区域计算平台上报 BSM 信息 ；
② . 路侧感知设备将感知到的交通参与者信息发送至路侧边缘计算平台，平台进行融合计算 ；
③ . 路侧边缘计算平台将处理后的结果数据上报至区域计算平台 ；
④ . 区域计算平台通过 Uu 口对进入范围的车辆推送 RSM 消息，OBU 接收到后，车载应用结合自身的定位和行驶数据信息进行判断，若存在弱势交通参与者碰撞风险，则对驾驶员进行预警。
image.png

3.1.2 效率类应用场景

3.1.2.1 前方拥堵提醒

选自标准①。智能网联车辆行驶前方发生交通拥堵状况，前方拥堵提醒 TJW 应用将对驾驶员进行提醒。由于感知设备（如摄像头）具有交通拥堵检测功能，因此不需要边缘计算单元处理，感知设备可直接将识别结果通过 RSU/ 平台下发车辆，为车辆提供信息服务。
业务流：
(1) 直连通信方式（PC5）：
① . 感知设备将拥堵信息发送至 RSU ；
② . RSU 广播 RSI 消息，车辆 OBU 接收到道路拥堵信息后，根据自身位置判断是否进行预警。
image.png
(2) 蜂窝通讯方式 (Uu) ：
① . 车辆周期性上传 BSM 信息 ；
② . 感知设备上传拥堵信息至区域计算平台 ；
③ . 平台匹配信息，通过 Uu 口对进入范围的车辆推送道路拥堵信息 RSI，车端接收到消息后结合车载应用分析，判断是否对驾驶员进行预警。
image.png

3.1.2.2 协作式优先车辆通行

选自标准②。协作式优先车辆通行是指智能交通系统调度交通资源针对优先车辆采取提前预留车道和封闭道路等方式，为优先车辆提供安全高效到达目的地的绿色通道。优先车辆包括警车、消防车、救护车、工程抢险车、事故勘查车等，未来也可以基于该场景提供差异化行车服务。
(1) 直连通信方式（PC5）：提前预留车道
① . 智能网联汽车向 RSU 发送车辆基本信息与行驶意图信息 VIR，包括对于前方指定车道进行预留的请求 ；
② . RSU 上报请求信息至路侧边缘计算平台 ；
③ . 路侧感知设备将其感知的信息发送至路侧边缘计算平台 ;
④ . 路侧边缘计算平台结合请求信息与道路交通信息，处理生成调度信息，发送至 RSU ；
⑤ . RSU 进行广播 RSC 信息，其他车辆 OBU 接受后结合车载应用安全及时离开预留车道，为优先车辆让行。
image.png
车道禁行 / 封闭场景
处于管制路段处或其上游的 RSU 通过本地配置的方式获取封闭车道或禁行信息，在管制开始前与管制期间，广播此信息，同时可以对特定车辆下发驾驶引导信息 ；车辆接收 RSU 的车道禁行 / 封闭信息和引导信息 RSC，能够及时、安全地调整驾驶行为，遵循交通管制。
image.png
(2) 蜂窝通讯方式 (Uu) ：提前预留车道
① . 智能网联汽车向区域计算平台发送 BSM 信息与行驶意图信息 VIR，包括对于前方指定车道进行预留的请求 ；
② . 区域计算平台将 BSM、VIR 等消息发送至路侧边缘计算平台 ；
③ . 路侧感知设备将其感知的信息发送至路侧边缘计算平台，平台综合感知信息与车辆 BSM、VIR 等消息进行融合计算，处理生成调度信息 ;
④ . 路侧边缘计算平台将处理后的结果数据上报至区域计算平台 ；
⑤ . 区域计算平台通过 Uu 口向车辆发送 RSC 信息，其他车辆接收后结合车载应用分析，驶离预留车道，为优先车辆让行。
image.png
车道禁行 / 封闭场景
车辆周期性上传 BSM 信息，在管制开始前与管制期间，区域计算平台 / 业务运营平台向接近和通过该区域的车辆发送封闭车道或禁行信息，同时可以对特定车辆下发驾驶引导信息 RSC，车辆接收到车道禁行 / 封闭信息后，能够及时、安全地调整驾驶行为，遵循交通管制。
image.png

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

选自标准③。自动驾驶车辆在真实路况行驶时，如果能提前得知前方路段的交通情况，则可以更好的辅助车辆进行路径的规划。基于路侧感知的交通状况识别指在混合交通环境下，由路侧感知设备不断感知周边道路交通信息，实时的识别当前路段的交通流及拥堵状况，并通过 RSU/ 平台将感知结果发送给自动驾驶车辆，辅助车辆做出正确的决策控制。
为了实现较大范围内的交通状况识别与引导，PC5 通讯中，以区域计算平台为该应用场景的处理终端。
业务流：
(1) 直连通信方式（PC5）：
① . 感知设备将路况信息上报至路侧边缘计算平台，平台进行融合处理 ；
② . 路侧边缘计算平台处理后的结果数据上报至区域计算平台 ；
③ . 区域计算平台向相关范围内的 RSU 下发消息 ；
④ . RSU 接收后对外广播 RAM 消息，OBU 接收后结合车载应用制定车辆的行驶策略。
image.png
(2) 蜂窝通讯方式 (Uu) ：
① . 车辆周期性上传 BSM 信息 ；
② . 感知设备将感知到的交通流信息上报至路侧边缘计算平台，平台进行融合计算 ;
③ . 路侧边缘计算平台将处理后的结果数据上报至区域计算平台 ；
④ . 区域计算平台通过 Uu 口下发 RAM 消息至车辆，OBU 接收后结合车载应用制定车辆的行驶策略。
image.png

3.1.2.4 车内标牌

选自标准①。车内标牌 IVS 应用将给予驾驶员相应的交通标牌提示，保证车辆的安全行驶。
业务流：
(1) 直连通信方式（PC5）：
① . 业务运营平台下发标志牌信息至区域计算平台（区域计算平台可以通过本地配置的方式得到）；
② . 区域计算平台将信息下发至 RSU;
③ . RSU 广播 RSI 消息，车辆 OBU 接收到后结合车载应用判断是否对车辆进行提醒。
image.png
(2) 蜂窝通讯方式 (Uu) ：
车辆上传 BSM 信息至平台，平台通过 Uu 口下发 RSI 消息，车辆接收到信息后，根据自身车辆位置等相关信息判断是否进行标志牌信息提醒。
image.png

3.1.3 信息服务类应用场景

3.1.3.1 差分数据服务

选自标准②。利用布设在区域内的基础设施（如 GNSS 基准站，地基增强系统等），监测视野内的 GNSS 卫星，通过集中数据处理，分类获得误差改正参数和完好性信息并播发给范围内的车辆，从而使车辆定位精度提升或实现符合一定要求的坐标偏转。
业务流：
(1) 直连通信方式（PC5）：
① . 业务运营平台将差分数据信息发送至区域计算平台（区域计算平台可以通过本地配置的方式得到）；
② . 区域计算平台将差分数据信息发送至 RSU ；
③ . RSU 广播 RTCM 消息，车辆 OBU 接收后更新车辆定位数据。
image.png
(2) 蜂窝通讯方式 (Uu) ：平台获得误差改正参数和完好性信息 RTCM 消息，通过 Uu 口对下发给周边车辆，车辆更新定位数据。
image.png

3.1.3.2 场站路径引导服务

选自标准②。在场站内部区域（如服务区等），向进入的车辆提供站点地图信息、车位信息、服务信息等，同时为车辆提供路径引导服务。
业务流：
(1) 直连通信方式（PC5）：
① . 智能网联车辆向 RSU 发送入场 / 离场信息或服务请求消息 VIR（包括自身信息、入场 / 离场请求以及意图信息等）；
② . RSU 将相关请求信息发送至路侧边缘计算平台 ；
③ . 路侧感知设备将场站内信息（场站内道路环境、停车信息等）上传至路侧边缘计算平台 ；
④ . 路侧边缘计算平台结合智能网联车辆的请求信息以及路侧感知设备上传的信息，为 RSU 下发场站地图信息（包括场站内地图信息、各类车位信息和服务点信息），同时下发路径引导信息 ；
⑤ . RSU 广播 PAM 消息，车辆 OBU 接收后结合车载应用分析，实现内部路径规划，前往目的地。
image.png
(2) 蜂窝通讯方式 (Uu) ：
① . 智能网联车辆通过 Uu 口发送入场 / 离场信息或服务请求 VIR 消息（包括自身信息、入场 / 离场请求以及意图信息等）至区域计算平台 ；
② . 区域计算平台将 VIR 等消息发送至路侧边缘计算平台 ；
③ . 路侧感知设备将场站内信息（场站内道路环境、停车信息等）上传路侧边缘计算平台，平台综合感知信息与车辆 VIR 等消息进行融合计算；
④ . 路侧边缘计算平台将处理后的结果数据上报至区域计算平台 ；
⑤ . 区域计算平台结合智能网联车辆的请求信息以及路侧感知设备上传的信息，通过 Uu 口为智能网联车辆下发 PAM 消息，包括场站内地图信息、各类车位信息和服务点信息，车辆 OBU 接收后结合车载应用分析，实现内部路径规划，前往目的地。
image.png

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

选自标准③。自动驾驶车辆的安全可靠运行依赖高精度地图的数据，因此要保证自动驾驶车辆能够获得到最新的地图数据。高精地图版本对齐及动态更新可以通过路端对自动驾驶车辆的高精地图进行动态更新，保证车辆能够获取到最新最完整的高精地图数据，为车辆安全可靠运行提供支撑。
业务流：
(1) 直连通信方式（PC5）：
① . 通过预先配置的方式 RSU 获取高精度地图信息（也可以通过平台下发获取），RSU 广播最新地图版本消息 ；
② . 车辆 OBU 接收后，比对地图版本信息，版本不一致时，车辆发送更新请求消息至 RSU;
③ . RSU 下发高精度地图数据，OBU 接收到 RAM、CIM 消息后，完成高精度地图更新。
image.png
(2) 蜂窝通讯方式 (Uu) ：
① . 区域计算平台 / 业务运营平台通过 Uu 口下发最新地图版本消息 ；
② . 车辆 OBU 接收后，比对地图版本信息，版本不一致时，车辆发送更新请求消息 ;
③ . 区域计算平台 / 业务运营平台根据车辆请求消息，下发高精度地图数据，OBU 接收到 RAM、CIM 消息后，完成高精度地图更新。
image.png

3.1.3.4 道路收费服务

选自标准②。道路收费服务是指，车辆行进到高速公路的收费区域时，车辆接收路侧发布的收费信息，并通过车路交互完成缴费业务。收费站点部署 V2X RSU 设备，连接后台收费系统，车辆安装 V2X OBU 设备，当车辆进入收费区域，完成相互身份认证后，自动执行收费操作。根据收费体系的发展，此业务场景有待进一步完善、落地。
业务流：
(1) 直连通信方式（PC5）车辆驶入高速收费路段 ：
① . RSU-1 对外广播道路收费服务信息，包括支持的收费服务列表及对应的收费信息等 ；
② . 智能网联车辆进入收费区域，收到 RSU-1 广播的收费服务信息后，确定交互的安全模式和收费服务类型 ；
③ . RSU-1 通过与平台收费系统交互获取交易信息 ；
④ . RSU-1 将交易信息和站点信息等发送给智能网联车辆 ；
⑤ . 智能网联车辆记录站点信息，并根据消费信息生成收费交易凭证，发送至 RSU-1；
⑥ . RSU-1 收到智能网联车辆的交易凭证后，向智能网联车辆发送交易结果和驶入提示（不一定进行费用结算）。
image.png
(2) 直连通信方式（PC5）车辆驶出高速收费路段 ：
① . RSU-2 对外广播道路收费服务信息，包括支持的收费服务列表及对应的收费信息等 ；
② . 智能网联车辆进入收费区域，收到 RSU-2 广播的收费服务信息后，确定交互的安全模式和收费服务类型 ；
③ . RSU-2 通过与平台收费系统交互获取交易信息 ；
④ . RSU-2 将交易信息和站点信息等发送给智能网联车辆 ；
⑤ . 智能网联车辆记录站点信息，并根据消费信息生成收费交易凭证，发送至 RSU-2 ；
⑥ . RSU-2 收到智能网联车辆的交易凭证后，向智能网联车辆发送交易结果和驶出提示。
image.png

3.1.4 交通管理类应用场景

3.1.4.1 浮动车数据采集

选自标准②。浮动车数据采集是指，平台通过接收通信范围内车辆发送的信息（包括行驶状态、驾驶意图以及感知信息等），进行数据的融合与交通状态分析，形成基于浮动车数据的交通状态评估。
业务流：
(1) 直连通信方式（PC5）：
① . RSU 收集智能网联汽车发送的 BSM 消息、VIR 消息 ；
② . RSU 将信息发送至区域计算平台 ；
③ . 区域计算平台将信息发送至业务运营平台，平台处理生成交通评估报告。
image.png
(2) 蜂窝通讯方式 (Uu) ：平台接收通信范围内车辆发送 BSM、VIR 信息，形成交通状态评估报告。
image.png

3.1.5 业务流模型及时延分析

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

3.1.5.1 PC5 通讯方式

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

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

（A）不需要感知设备等参与，由 RSU 事先配置好信息，直接下发至智能网联车辆的流量模型如下。该模型涉及的主要场景为限速预警、协作式优先车辆通行。
此数据流模型的总时延为 ：
总时延 = 传输时延RSU 广播传输时延 ~RSU广播传输时延~ ＋处理时延 ~智能网联车辆~
image.png
（B）不需要感知设备等参与，由 RSU 事先配置好信息，根据车辆请求信息，完成数据下发。该模型涉及的主要场景为高精地图版本对齐及动态更新。
此数据流模型的总时延为 ：
总时延 =2×传输时延 ~RSU广播传输时延~＋传输时延 ~OBU至RSU~ ＋处理时延 A~RSU~＋处理时延 B ~智能网联车辆~
image.png
（C）目前的感知设备具有简单的数据处理分析功能，当感知设备的处理分析能力可以满足应用场景时，路侧感知设备将处理后的结果发送至RSU，RSU 进行广播，为车辆提供服务。主要应用场景有前方拥堵提醒。
此数据流模型的总时延为 ：
总时延 = 传输时延 A ~路侧感知设备至RSU~ ＋传输时延 B~RSU广播传输时延~＋处理时延A ~路侧感知设备~＋处理时延 B~RSU~ ＋处理时延 C ~智能网联车辆~
image.png

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

由路侧边缘计算平台完成计算的数据流模型分为下列两种。
（A）路侧感知设备将感知到的信息发送至路侧边缘计算平台，边缘计算进行融合处理后将消息通过 RSU 广播至智能网联汽车。涉及的主要场景主要有基于协同式感知的异常驾驶行为识别、感知数据共享。
根据感知的目前物是道路车辆、弱势交通参与者、交通参与者 / 障碍物不同可分为如下三种模型。三种模型的时延分析相同。
image.png
此数据流模型的总时延为 ：
总时延 = 传输时延 A ~路侧感知设备至路侧边缘计算平台~＋传输时延 B ~路侧边缘计算平台至RSU~ ＋传输时延 C~RSU广播传输时延~＋处理时延 A ~路侧感知设备~＋处理时延 B ~路侧边缘计算平台~＋处理时延 C~RSU~ ＋处理时延 D ~智能网联车辆~
（B）需要智能网联车辆发送特定的请求信息，路侧感知设备将感知到的信息发送至路侧边缘计算平台，边缘计算进行融合处理后将消息通过 RSU 广播至智能网联汽车。涉及的主要场景主要如下表。
image.png
此数据流模型的总时延为 ：
总时延 =MAX（传输时延 A~OBU至RSU~ ＋传输时延 B~RSU至路侧边缘计算平台~＋处理时延 C~RSU~，传输时延 C ~路侧感知设备至路边缘计算平台~＋处理时延 A ~路侧感知设备~）＋传输时延 D ~路侧边缘计算平台至RSU~ ＋传输时延 E~RSU广播传输时延~＋处理时延 B ~路侧边缘计算平台~＋处理时延 C~RSU~ ＋处理时延 D ~智能网联汽车~
注：路侧边缘计算平台通过 RSU 获取车辆信息和通过路侧感知设备获取路侧信息可同时进行，因此模型总时延此部分取较大者。

3.1.5.1.3. 处理终端为区域计算平台

当业务场景对时延要求不高且需要实现较大范围内的感知与消息广播时，需要以区域计算平台为处理终端。涉及的主要场景有基于路侧感知的交通状况识别，路侧感知设备（例如摄像头、雷达等）周期性对周边的交通状况进行探测，感知数据发送至区域计算平台进行处理，处理后的数据推送至 RSU，RSU 周期性广播 RAM 消息，车辆的 OBU 接收 RAM消息，车载应用结合自身的定位和行驶数据信息，对驾驶员进行提示。
此数据流模型的总时延为 ：
总时延 = 传输时延 A ~路侧感知设备至路侧边缘计算平台~＋传输时延 B ~路侧边缘计算平台至区域计算平台~＋传输时延 C ~区域计算平台至RSU~ ＋传输时延 D~RSU广播传输时延~＋处理时延 A ~路侧感知设备~＋处理时延 B ~路侧边缘计算平台~＋处理时延 C ~区域计算平台~＋处理时延 C~RSU~ ＋处理时延 D ~智能网联车辆~
image.png

3.1.5.1.4. 处理终端为业务运营平台

该模型主要分为 2 种数据流模型。
（A）数据流由车端到平台端。主要应用场景为浮动车数据采集。
此数据流模型的总时延为 ：
总时延 = 传输时延 A~OBU至RSU~ ＋传输时延 B~RSU至区域计算平台~＋传输时延 C ~区域计算平台至业务运营平台~＋处理时延 A~RSU~ ＋处理时延 B ~区域计算平台~
image.png
image.png
此数据流模型的总时延为 ：
总时延 = 传输时延 A ~业务运营平台至区域计算平台~ ＋ 传输时延 B ~区域计算平台至RSU~ ＋传输时延 C~RSU广播~＋处理时延 A ~区域计算平台~＋处理时延 B~RSU~ ＋处理时延 C ~智能网联车辆~
image.png

3.1.5.2 Uu 通讯方式

3.1.4.2.1. 处理终端为区域计算平台

（A）智能网联汽车周期性上报数据至区域计算平台，感知设备上传处理后的感知信息至区域计算平台，平台将消息下发至智能网联车辆。因感知设备的数据处理能力满足场景应用需求，不需要经过路侧边缘计算平台。涉及的场景主要是前方拥堵提醒。
image.png
此数据流模型的总时延为 ：
总时延 = 传输时延 A ~路侧感知设备至区域计算平台~＋传输时延 B ~区域计算平台至车辆~＋处理时延 A ~路侧感知设备~＋处理时延 B ~区域计算平台~＋处理时延 C ~智能网联车辆~
（B）智能网联汽车周期性上报数据至区域计算平台，感知设备上传感知信息至区域计算平台，平台汇聚信息完成处理，处理结果信息下发至智能网联车辆。涉及的主要场景如下表。
image.png
根据感知的目前物是道路车辆、弱势交通参与者、交通参与者 / 障碍物不同可分为如下三种模型。三种模型的时延分析相同。
image.png
此数据流模型的总时延为 ：
总时延 = 传输时延 A ~路侧感知设备至路侧边缘计算平台~＋传输时延 B ~路侧边缘计算平台至区域计算平台~ + 传输时延 C ~区域计算平台至车辆~＋处理时延 A ~路侧感知设备~＋处理时延 B ~路侧边缘计算平台~ + 处理时延 C ~区域计算平台~＋处理时延 D ~智能网联车~
（C）智能网联汽车周期性上报请求信息至区域计算平台，区域计算平台下发消息至路侧边缘计算平台，感知设备上传信息至路侧边缘计算平台，路侧边缘计算平台结合车辆请求信息和路侧感知信息进行处理，结果通过区域计算平台下发至智能网联车辆。涉及的主要场景如下表。
image.png
此数据流模型的总时延为 ：
总时延 =MAX（传输时延 A~OBU至区域计算平台~＋传输时延 B ~区域计算平台至路侧边缘计算平台~＋处理时延 C~ 区域计算平台~，传输时延 C ~路侧感知设备至路侧边缘计算平台~＋处理时延 A ~路侧感知设备~）＋传输时延 D ~路侧边缘计算平台至区域计算平台~＋传输时延 E ~区域计算平台至车辆~＋处理时延 B ~路侧边缘计算平台~＋处理时延 C ~区域计算平台~＋处理时延 D ~智能网联汽车~
注：路侧边缘计算平台通过区域计算平台获取车辆信息和通过路侧感知设备获取路侧信息可同时进行，因此模型总时延此部分取较大者。

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

（A）数据流由车端到平台端。主要应用场景为浮动车数据采集。
image.png
此数据流模型的总时延为 ：
总时延 = 传输时延 A ~车端至区域计算平台/业务运营平台~
（B）数据流需要在车端与平台端之间交互多次。主要应用场景为高精地图版本对齐与动态更新。
image.png
此数据流模型的总时延为 ：
总时延 =2×传输时延~车端至区域计算平台/业务运营平台至车端~＋传输时延~车端至区域计算平台/业务运营平台~＋处理时延 A ~车端至区域计算平台/业务运营平台~＋处理时延 B ~智能网联车辆~
（C）数据流由平台端到车端。涉及的主要场景如下表。
image.png
此数据流模型的总时延为 ：
总时延 = 传输时延 A ~区域计算平台/业务运营平台至车端~

3.2 车路协同业务部署场景分析

本研究中车路协同业务部署场景按照高速公路组成要素，分为一般路段、主线隧道、收费站互通、枢纽互通、服务区5 大场景，其中一般路段场景涵盖长直路段、桥梁、弯道、上下坡等路段。各场景部署方案中的设备布设间距根据目前市场上视频、雷达的检测范围按照常规情形进行示例，实际项目可根据具体业务需求及设备性能进行调整。
image.png

3.2.1 一般路段

3.2.1.1 场景描述

高速公路一般路段具有长直路段视野良好，车速较快，转弯路段易发事故等特点，如遇团雾、大雨等恶劣天气，车辆通行安全与效率会受到极大影响。本场景运用车路协同技术，实现恶劣路域环境辅助通行、限速信息提醒与车道级行车引导、异常交通事件预警与路径规划、周边信息服务等场景，全面提升高速一般路段的车辆安全与通行效率。
根据《合作式智能运输系统 + 车用通信系统应用层及应用数据交互标准》，结合高速公路实际情况，高速一般路段辅助通行实现的功能主要包括 ：
① . 道路危险状况提示 ：前方急转弯提醒、前方连续下坡提醒、事故多发路段提醒 ；
② . 恶劣天气警示 ：前方团雾提示、前方低能见度提醒、前方路面结冰提示 ；
③ . 交通事件提醒 ：前方交通拥堵、交通事故、道路抛洒、占道施工提醒 ；
④ . 车道级限速提醒及行车引导 ：分车道限速提醒、客货车通行车道提醒、车道通行状态提醒。
⑤ . 信息服务 ：前方服务区、收费站、停车场提醒。

3.2.1.2 部署方案

方案一：路侧部署
①感知设备部署
双幅 6 车道及以下高速公路，双侧对等按 400 米间隔布设 2 台高清摄像机、1 对毫米波雷达。其中，2 台高清摄像机分别对准来车和去车方向，毫米波雷达的监测范围不小于 200 米范围。
双幅 8 车道及以上高速公路，双侧对等按 400 米间隔布设 4 台高清摄像机、1 对毫米波雷达。其中 2 台高清摄像机对准来车方向、2 台高清摄像机对准去车方向、毫米波雷达的监测范围不小于 200 米范围。
②通信设备部署
RSU 按双侧 Z 字形，单侧间距 800 米设置 1 个 RSU。
③边缘计算设备部署
双侧对等按 800 米间隔布设 1 台边缘计算设备，可满足同时接入至少 8 台摄像机、4 台毫米波雷达的性能需求。
④控制与诱导设施部署
网联化车辆安装 OBU 接收 RSU 或中心发布交通控制与诱导信息。
通过可变信息情报板、导航软件、小程序等多样化手段，将辅助通行信息及时发布给非网联车辆。一般路段按间隔不大于 5KM 间隔设置门架式可变情报板。
image.png
方案二：中央分隔带部署
①感知设备部署
双幅 6 车道及以下高速公路，中央分隔带按 400 米间隔布设 4 台高清摄像机、1 对毫米波雷达。其中，2 台摄像机对准一侧道路的来车和去车方向，2 台摄像机对准另一侧道路的来车和去车方向，毫米波雷达的监测范围不小于 200 米半径范围。
双幅 8 车道及以上高速公路，中央分隔带按 400 米间隔布设 8 台高清摄像机、1 对毫米波雷达。其中，每 2 台摄像机分别对准双侧道路的来车和去车方向，毫米波雷达的监测范围不小于 200 米半径范围。
② 通信设备部署
中央分隔带按 400 米设置 1 个 RSU，RSU 满足半径 400 米的通信范围。
③边缘计算设备部署
双向 6 车道及以下，中央分隔带按 800 米间隔布设 1 台边缘计算设备，可满足同时接入至少 8 台摄像机、4 台毫米波雷达的性能需求。
双向 8 车道及以上，中央分隔带按 400 米间隔布设 1 台边缘计算设备，
④控制与诱导设施部署
网联化车辆安装 OBU 接收 RSU 或中心发布交通控制与诱导信息。
通过可变信息情报板、导航软件、小程序等多样化手段，将辅助通行信息及时发布给非网联车辆。一般路段按间隔不大于 5KM 间隔设置门架式可变情报板。
image.png

3.2.2 主线隧道

3.2.2.1 场景描述

由于隧道路段运营环境特殊，一旦隧道洞内发生事故，存在车流疏散困难、救援难度大等问题，将影响路段甚至整个路网的运营效率。同时，由于隧道出入洞口段为光线突变段，行驶通过该段时，驾驶员的视觉生理反应需要消耗时间，产生“白洞效应”和“黑洞效应”，导致出入口附近的交通事故频发。本场景基于车路协同技术实现车辆在隧道前、隧道中、隧道后的全过程安全预警及诱导服务，重点减少由于隧道黑白洞效应引发的交通事故，同时实现洞内事故提前告知功能。
根据《合作式智能运输系统 + 车用通信系统应用层及应用数据交互标准》，结合高速公路实际情况，隧道安全预警及诱导服务实现的功能主要包括 ：
①隧道内安全预警
隧道内火灾提示预警、隧道内抛洒物提醒、前方施工占道提醒、隧道内拥挤提示、隧道内交通事故提醒、隧道内应急车道被占提示等。
②隧道出（入）口安全预警
隧道出（入）口交通事故提醒、隧道出（入）口违停提醒。
③隧道限速相关提醒
驶入（出）隧道提醒、限速提醒、违法抓拍提醒。

3.2.2.2 部署方案

由于隧道与前后相接路段的关联性强，通常将隧道洞外 500 米范围的路段划入隧道管控区域，统一部署感知、通信及边缘计算等设备。
隧道视外场点位分布情况，组建多个现场接入网（目前多为光纤环网），实现感知、通信等设备与边缘计算设备的互联。
现场接入网传输带宽、网络时延、可靠性等指标应满足车路协同业务场景要求。
①感知设备部署
(1) 隧道洞外路段
感知设备部署原则同“一般路段”，紧密结合前后路段点位设置情况，确保洞口区域感知的全覆盖。
(2) 隧道洞内路段
部署方式一：
隧道洞内路段按不大于200 米间隔（曲线段适当加密）布设感知点位，每个点位配置1台高清摄像机和1套毫米波雷达，毫米波雷达监测范围不小于 200 米范围，每个感知点位实现隧道洞内 150 米路段信息感知全覆盖。边缘计算有两种部署方式 ：分布式（如图 3.2-5）和集中式（如图 3.2-6）。
image.png
部署方式二：
隧道洞内路段按不大于 400 米间隔（曲线段适当加密）布设感知点位，每个点位配置 2 台高清摄像机和 2 套毫米波雷达，分别对准上下行方向，毫米波雷达监测范围不小于 200 米范围，每个感知点位实现隧道洞内 300 米路段信息感知全覆盖。边缘计算有两种部署方式 ：分布式（如图 3.2-7）和集中式（如图 3.2-8）。
image.png
②通信设备部署
(1) 隧道洞外路段
通信设备部署同原则“一般路段”，紧密结合前后路段点位设置情况，确保洞口区域通信的全覆盖。隧道洞口路段按照“一般路段”进行部署。
(2) 隧道洞内路段
部署方式一：
RSU 按照 300 米间距，与视频监控点位同址部署，每处点位设置 1 个 RSU，RSU 通信范围不小于 300 米半径范围。
部署方式二：
RSU 按照 400 米间距，与视频监控点位同址部署，每处点位设置 1 个 RSU，RSU 通信范围不小于 400 米半径范围。
③边缘计算设备部署
隧道及相接洞外路段应作为一个区域，进行集中管控，原则上部署 1 套边缘计算设备，支持全域业务数据的协同计算分析。若因隧道太长，设备太多，可部署多套边缘计算设备，并采用强协同工作模式。边缘计算设备可依托隧道洞口或洞内变电所设置，具备支持区域内所有感知、通信等的接入能力。1km 及以上隧道，边缘计算设备宜采用设备级的硬件容错机制，例如 ：双机热备 ；3km 及以上隧道，边缘计算设备应采用站点级的系统容错机制，例如 ：双活机房。
④控制与诱导设施部署
网联化车辆安装 OBU 接收 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 间通信的正常。
image.png
2、网络时钟同步精度
网络时钟同步的精度需求，需要在 OBU 之间正常通信的同步需求前提下，进一步考虑多径时延、信号传播时延、RSU 自身时间误差、OBU 从 RSU 获得同步时钟的误差等因素的影响，故会高于 LTE-V2X 通信自身的同步精度要求（作为参考，LTE-TDD 时钟同步要求是±1.5us），但具体的经验数值有待在实践中提出并予以验证。
⑥隧道内定位设施
隧道洞内部署定位设施，采用车辆辅助定位或路侧主动定位方式，实现满足车路协同的高精度定位功能。可参照《基于移动通信网的高精度定位总体技术要求》（YD/T 3936-2021）、3GPPTR22.872v16.1.0。

3.2.3 收费站互通

3.2.3.1 场景描述

收费站互通是连接高速公路与地方普通公路或城市道路的落地互通，由于主线和匝道的车速差异大、变道行为多、变道窗口期短、驾驶员视野受限等原因，容易产生违法驾驶行为，从而容易发生交通事故、降低通行效率。
本场景通过建设基于车路协同的安全预警及诱导系统，对分合流区域过往车辆进行预警提醒，尽量避免主线车辆与匝道车辆的碰撞事故发生。
根据《合作式智能运输系统 + 车用通信系统应用层及应用数据交互标准》，结合高速公路实际情况，本场景安全预警及诱导服务实现的功能主要包括 ：
①合流区安全预警
右侧匝道车辆汇入提醒、左侧主线车辆行驶提醒、合流区域交通事故提醒、合流区域下游主线交通拥挤程度提醒 ；
Ⅱ分流区安全预警
左侧车辆变道提醒、前方车辆慢行提醒、前方车辆停车提醒、前方车辆逆行提醒 ；
③收费车道运行状态提醒
出（入）口收费车道排队长度或时长提醒、出（入）口车道开关闭状态提醒
④主线及匝道信息远端诱导
收费站前的主线及匝道限速信息提醒、主线及匝道的交通拥挤情况提醒。
⑤衔接普通道路运行状态提醒，相邻普通道路交通运行状态提醒

3.2.3.2 部署方案

由于收费站互通与前后相接路段的关联性强，通常将互通前后 2km 范围的路段划入收费站互通管控区域，统一部署感知、通信及边缘计算等设备。
现场接入网传输带宽、网络时延、可靠性等指标应满足车路协同业务场景要求。
①感知设备部署
以分流鼻或合流鼻顶点为基准点，主线上游 125m 左右立杆，布设 2 台高清摄像机及 1 台毫米波雷达，感知主线车道分合流鼻顶点前后至少各 100m 米范围内的交通状况及交通事件。
②通信设备部署
互通前后门架布中央各设 1 台 RSU，向半径 400 米范围内的网联车辆发布交通状况及交通事件。
③边缘计算设备部署
每个互通依托收费站布设一台边缘计算服务器，可满足同时接入至少 8 台摄像机、4 台雷达的性能需求。同时互通及相接路段应作为一个区域，部署的边缘计算还应同时支持全域业务数据的协同计算分析。
④控制与诱导设施部署
网联化车辆安装 OBU 接收 RSU 或中心发布交通控制与诱导信息。
选择性地在分合流的起点或终点设置可变情报板或通过 APP 向非网联车辆发布交通状况、交通事件信息。
image.png

3.2.4 枢纽互通

3.2.4.1 场景描述

枢纽互通是不同高速公路相交位置，实现不同高速公路上的车辆转换。枢纽互通在分合流交织区域易发生车辆碰撞、违规变道、车辆违停、车辆逆行等违规行为。本场景通过建设基于车路协同的分合流安全预警及诱导系统，对分合流区域过往车辆进行预警提醒，尽量避免主线车辆与匝道车辆的碰撞事故发生。
根据《合作式智能运输系统 + 车用通信系统应用层及应用数据交互标准》，结合高速公路实际情况，分合流安全预警及诱导服务实现的功能主要包括 ：
①合流区安全预警
右侧匝道车辆汇入提醒、左侧主线车辆行驶提醒、合流区域交通事故提醒、合流区域下游主线交通拥挤程度提醒 ；
②分流区安全预警
左侧车辆变道提醒、前方车辆慢行提醒、前方车辆停车提醒、前方车辆逆行提醒 ；
③主线及匝道信息服务
主线及匝道限速信息提醒、道路施工提示。

3.2.4.2 部署方案

由于枢纽互通与前后相接路段的关联性强，通常将枢纽互通 1km 半径范围内的路段划入枢纽互通管控区域，统一部署感知、通信及边缘计算等设备。
①感知设备部署
以分流鼻或合流鼻顶点为基准点，主线上游 125m 左右立杆，布设高清摄像机及毫米波雷达，感知主线车道分合流鼻顶点前后至少各 100m 米范围内的交通状况及交通事件。
②通信设备部署
互通前后门架布中央各设 1 台 RSU，向半径 400 米范围内的网联车辆发布交通状况及交通事件。
③边缘计算设备部署
每个互通依托收费站布设一台边缘计算服务器，可满足同时接入至少 8 台摄像机、4 台雷达的性能需求。同时互通及相接路段应作为一个区域，部署的边缘计算还应同时支持全域业务数据的协同计算分析。
④控制与诱导设施部署
网联化车辆安装 OBU 接收 RSU 或中心发布交通控制与诱导信息。
选择性地在分合流的起点或终点设置可变情报板或通过 APP 向非网联车辆发布交通状况、交通事件信息。
image.png

3.2.5 服务区

3.2.5.1 场景描述

高速公路服务区集停车、公共厕所、加油、餐饮等服务功能于一体，单侧或双侧布置于高速主线两侧。车辆驶进（离）服务区时，主线车辆与匝道车辆车速差异大，易发生交通事故。本场景通过建设基于车路协同的服务区安全预警及诱导系统，对进出服务区的车辆进行安全预警与信息服务。
根据《合作式智能运输系统 + 车用通信系统应用层及应用数据交互标准》，结合高速公路实际情况，本场景实现的功能主要包括：
①合流区安全预警
右侧匝道车辆汇入提醒、左侧主线车辆行驶提醒、合流区域交通事故提醒、合流区域下游主线交通拥挤程度提醒 ；
②分流区安全预警
左侧车辆变道提醒、前方车辆慢行提醒、前方车辆停车提醒、前方车辆逆行提醒 ；
③服务区信息提醒
服务区停车位提醒、卫生间侧位提醒、人流量提醒等。
④主线交通运行状态提醒
出口下游主线路段交通拥挤程度提醒、应急车道停车提醒、限速提醒等。

3.2.5.2 部署方案

除特殊情况，服务设施一般按照上下行方向划为两个独立的管控区域，分别考虑。另外，由于服务设施与前后相接路段的关联性强，通常将服务设施 2km 半径范围内的路段划入服务设施管控区域，统一部署感知、通信及边缘计算等设备。现场接入网络组建原则同“收费站互通”。
①感知设备部署
以分流鼻顶点为基准点，主线上游 125m 左右立杆，布设 2 台高清摄像机及 1 台毫米波雷达，感知主线车道分流鼻顶点前后至少各 100m 米范围内的交通状况及交通事件。
以合流鼻顶点为基点，主线下游 125m 左右立杆，布设 2 台高清摄像机及 1 台毫米波雷达，感知主线车道合流鼻顶点前后至少各 100m 米范围内的交通状况及交通事件。
②通信设备部署
服务区出入口复用交安标志杆件，各设 1 台 RSU，向半径 400 米范围内的网联车辆发布交通状况及交通事件。
③边缘计算设备部署
服务设施及相接路段应作为一个区域，进行集中管控，原则上两侧服务（停车）区各部署 1 套边缘计算设备，支持全域业务数据的协同计算分析。边缘计算设备可依托服务设施管理用房设置，具备支持区域内所有感知、通信等的接入能力。
④控制与诱导设施部署
网联化车辆安装 OBU 接收 RSU 或中心发布交通控制与诱导信息。
选择性地在分合流的起点或终点设置可变情报板或通过 APP 向非网联车辆发布交通状况、交通事件信息。
image.png

3.3 路段接入网需求分析

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

3.3.1 路段接入网的总体架构

路段接入网负责把路侧设备、边缘计算等设备和路段分中心（区域计算平台）互联 ；没有路段分中心的，直接和路段中心（区域计算平台）互连，网络架构如图 3.3-1 所示。
image.png
在路段接入网中，最关键部分是以边缘计算为核心的路侧网络。如图 3.3-2 所示，边缘计算和相关的路侧设备构成了一个相对独立的车路协同边缘计算域，完成感知融合计算和车路协同信息的实时发送，路侧网络有比较高的实时性和大带宽需求。
image.png

3.3.2 路段接入网的功能要求

[ 路段 1-1] 路段接入网需要支持边缘计算的各种部署模式
边缘计算有多种部署模式，有分布部署到各杆站，有相对集中到通信机房和隧道变电机房等，有部署边缘计算备份的，有独立逻辑业务区的边缘计算。 路段接入网需要保证边缘计算各种部署模式下，都能满足车路协同业务的通信带宽和延迟要求，保证网络安全，流量无绕行。
[ 路段 1-2] 路段接入网需要具备良好的扩展性，支持分路段、分步骤逐步建设 ；
高速公路车路协同业务一般是统一规划，分路段逐步建设，或分区域（关键区域先建，其它区域后续补充建）逐步建设。路段接入网需要满足扩展性建设需求，新建网络不影响原有网络，新建网络和原有网络可以融合为一个网络系统。
[ 路段 1-3] 路段接入网需要满足多个业务设备间各种通信要求，具备灵活通信能力 ；
车路协同系统的路侧设备和计算单元等设备间有比较复杂的业务流通信，而且业务场景和业务实现的变化也会导致通信方式的变化，因此要求路段接入网能按业务需求，灵活地和快速地支持任何设备间的通信需求，以及新增设备的通信要求。
[ 路段 1-4] 路段接入网需要具备多业务承载能力
车路协同系统中的视频流、车路协同消息、设备管理信息等有不同的网络需求和安全隔离要求，路段接入网需要能按各业务要求提供多业务承载和业务隔离。
image.png
路段接入网要确保高优先级的业务流不会被低于其优先级的业务流影响传输质量。
[ 路段 1-5] 路段接入网需要具备冗余保护能力，支持链路级、设备级保护 ；
车路协同信息需要高可靠传输，需要路段接入网能有（单次或多次）断纤通信保护能力，通信设备的单点故障保护能力。
[ 路段 1-6] 路段接入网设备应支持各类设备接入端口及协议需要。
路侧通信设备需要和路侧设备、传感器等互联，需要支持 GE 电口、GE 光口、RS485、RS422、RS232、RJ45 等接口，并支持 POE 供电 ；通信设备按需支持 10GE、25GE、50GE、100GE 等接口，做网络设备互联组网。
路侧通信设备需支持所连传感器的物联协议接入，如当前路面传感器、能见度传感器和气象传感器采用 ModBus，Serial/TCP 等协议。
[ 路段 1-7] 路段接入网设备在某些场景下，需要满足终端设备高精度时间同步要求，支持部署 PTP 协议 ；
RSU 和激光雷达等设备需要高精度时间同步，一般是通过 GNSS 和网络来进行时间同步。在隧道等没有 GNSS 信号的场景中，RSU 只能通过网络来保持时间同步 ( 详见 3.2.2)。
[ 路段 1-8] 路段接入网应支持 IPv6 部署，并具备 IPv6 Only 演进能力。
IPv4 地址已经枯竭，网络向 IPv6 演进是必然方向，也是国家发展战略。交通行业是国家重点推进 IPv6 战略的 17个重点行业之一。2021 年 7 月中央网信办、国家发改委、工信部联合发布《关于加快推进互联网协议第六版（IPv6）规模部署和应用工作的通知》，计划到 2025 年网络要大规模部署 IPv6 Only，2030 年全网演进到 IPv6 Only。因此路段接入网需要支持 IPv6 设备和业务，具备全网平滑演进到 IPv6 Only 的能力。

3.3.3 路段接入网性能要求

[ 路段 2-1] 路段路侧通信网络应满足路侧摄像机、雷达、传感器、边缘计算等设备通信带宽要求 ；
在网络设计时，按各设备带宽要求和网络结构计算总带宽需求，并且在保护倒换时也能保证关键业务的带宽需求。
路侧网络的带宽需求，应基于各部署场景的所有设备带宽需求来计算，详见 3.2 节。
[ 路段 2-2] 路段接入网需要满足车路协同业务延迟要求 ；
路侧网络中，边缘计算和 RSU 间，摄像头、雷达和边缘计算间通信延迟满足业务段到段延迟要求，具体延迟计算公式详见 3.1.2 节；
[ 路段 2-3] 路段接入网需要满足车路协同高可靠性要求 ；
单链路故障和任意单点设备故障的业务的中断时间小于 200ms，网络可靠性满足 99.999% 要求 ；
[ 路段 2-4] 路段接入网应具备 1K-10K 级节点部署和网络管理能力 ；
路段接入网的规模和高速公路的长度正相关。
[ 路段 2-5] 路侧通信网络设备应支持室外部署，工作温度范围 -40~65 度。
路侧网络设备一般是部署在室外，需要按室外安装运维要求设计。

3.4 车路协同业务对省干网络需求分析

本节主要从总体架构、功能要求和性能要求三个方面，就车路协同业务对省干网络的需求进行分析。

3.4.1 省干网络的总体架构

省干网络负责省中心、路段中心、路段分中心以及 2C 服务商 /2B 用户的互连，具体包括路段中心间通信互连、路段中心至省中心的通信互连、路段分中心间通信互连、路段分中心至省中心的通信互连、以及省中心与 2C 服务商 /2B 用户间业务通信。省干网络的总体架构如图 3.4.1 所示。
image.png

3.4.2 省干网络的功能要求

[ 省干 1-1] 应具备综合业务承载能力，支持承载收费业务、监控业务和车路协同业务等多种业务。
车路协同系统中的收费业务、监控业务、车路协同业务等有不同的网络需求和安全隔离要求，省干网需要能按各业务要求提供多业务承载和业务隔离。
[ 省干 1-2] 应具备快速保护倒换能力。省干网络应能提供端到端和局部的网络保护，实现对链路故障和中间节点故障的保护，应能提供与业务网络的对接保护，包括双归保护、双节点冗余保护等。
省干网络所承载的业务比较重要，应具备快速保护倒换能力，避免因链路故障和中间节点故障导致的业务中断。并应实现业务 50ms 以内的保护倒换。
[ 省干 1-3] 扩展性强，既能满足现有业务需要，同时能够支撑未来业务发展。
为满足当前高速公路收费系统、监控系统和办公系统等业务系统的承载需要，特别是满足包含车路协同业务在内的智慧高速业务承载要求，同时考虑到业务的持续演进发展，需要建设一张能满足现有业务需要，同时支撑未来业务发展的承载网络。
[ 省干 1-4] 应具备 OAM（Operations and Maintenance）机制，具备统一管控、业务质量可视、故障智能定位、性能监测和智能运维等功能。
多个业务系统的承载网络独立运维，维护成本高，因此省干网络应具备统一管控，业务质量可视，故障智能定位，实现智能运维。
[ 省干 1-5] 应具有 QOS（Quality of Service）机制。
省干网要确保高优先级的业务流不会被低于其优先级的业务流影响传输质量，用来解决网络延迟和阻塞等问题。
[ 省干 1-6] 应提供完善的网管系统，采用图形化界面实现拓扑管理、配置管理、故障管理、性能管理、安全管理等功能；并可通过北向接口与上层网管系统相连。
用以保障网络系统能够正常、高效运行，使网络系统中的资源得到更好的利用。
[ 省干 1-7] 具备全网时间同步功能。
省干网络所有设备统一时间信息，便于网络监测和管理。
[ 省干 1-8] 应支持 IPv6 部署。省干网络应具备 IPv6 Only 网络演进能力。
IPv4 地址已经枯竭，网络向 IPv6 Only 演进是必然方向，也是国家发展战略。IPv6 Only 网络，适合长期演进和大规模部署，符合车路协同对省干网络的发展需求。

3.4.3 省干网络的性能要求

[ 省干 2-1] 大带宽，能够满足未来业务增长的需要。
随着车路协同业务的不断丰富，所需要的带宽也会越来越大，因此省干网络的带宽需要满足未来业务增长的需要。
[ 省干 2-2] 高可靠性。省干网络及设备需要通过提供冗余能力保证业务的可靠运行。核心设备、单台设备的关键部件和主要链路必须有冗余，同时主要链路有足够带宽，保证业务高峰时不会出现大面积网络拥塞 ；应通过各类链路级和设备级保护实现业务 50ms 以内的保护倒换 ；应支持平滑重启功能，实现故障的快速切换和恢复。
车路协同信息需要高可靠传输，需要省干网络能有（单次或多次）断纤通信保护能力，通信设备的单点故障保护能力。
[省干2-3]高 QoS。省干网络必须针对不同的业务应用需求，如丢包率、延迟、抖动和带宽等，提供不同的服务质量保证，以实现同时承载收费、监控等业务。
省干网要有资源预留能力来确保高优先级的业务流不会被低于其优先级的业务流影响传输质量，用来解决网络延迟和阻塞等问题。

3.5 车路协同业务对网络安全的需求分析

3.5.1 车路协同业务面临的安全威胁分析

3.5.1.1 路侧设备 面临的安全威胁

路侧设备是车路协同系统的核心单元，它的安全关系到车辆和道路交通的整体安全。它所面临的主要安全威胁如下：
①非法接入
路侧设备通常通过有线接口与交通基础设施及业务云平台交互。黑客可以利用这些接口接入路侧设备，非法访问设备资源并对其进行操作和控制，从而造成覆盖区域内交通信息混乱。攻击者甚至还能通过被入侵或篡改的路侧设备发起反向攻击，入侵整个交通专用网络及应用系统，在更大范围内危害整个系统的安全。
②运行环境风险
路侧设备中也会驻留和运行多种应用、提供多种服务，也会出现敏感操作和数据被篡改、被伪造和被非法调用的风险。
③设备漏洞
路侧设备及其附件（智能交通摄像头等终端）可能存在安全漏洞，导致路侧设备被远程控制、入侵或篡改。
④远程升级风险
通过非法的远程固件升级可以修改系统的关键代码，破坏系统的完整性。黑客可通过加载未授权的代码并执行来篡改系统、关闭安全功能，导致路侧设备被远程控制、入侵或篡改。
⑤部署维护风险
路侧设备固定在部署位置后，可能由于部署人员的失误，或交通事故、风、雨等自然原因导致调试端口或通信接口暴露或者部署位置变动，降低了路侧设备物理安全防御能力，使破坏和控制成为可能。

3.5.1.2 路侧边缘计算面临的安全威胁

路侧边缘计算边缘设施的资源和能力有限，难以提供与云中心同等级的安全能力，同时在物理位置、网络边界、业务类型等多方面发生了变化，在安全性方面也面临新的挑战。
①设备安全风险
路侧边缘计算平台设备涉及的安全风险包括但不限于 ：
设备配置缺陷 ：包括各类设备基线配置不当、设备登录和访问控制策略配置不当、设备资源管理策略配置不当等引发的非法用户登录、非授权攻击等安全问题 ；
设备管理安全 ：包括因设备维护的管理通道缺乏双向认证或匹配的加密算法引发的窃听、劫持和篡改攻击，设备安全漏洞更新不及时导致的安全隐患等 ；
设备安全漏洞 ：包括设备涉及的硬件漏洞、软件漏洞，以及容器、操作系统、数据库开发等第三方组件漏洞等 ；
设备级安全防护措施不当：因未部署恰当的设备级入侵检测系统、抗 DDoS、防火墙等防攻击手段，导致无法及时发现、拦截和响应针对设备的非法访问、入侵等安全风险 ；
设备故障风险 ：因设备自身的电源、内存等硬件故障导致的故障，导致设备无法正常工作从而影响服务。
②物理环境安全风险
边缘计算节点可能部署在无人值守机房或者路边，往往安保措施较为薄弱，更易遭受物理接触攻击。同时攻击者还可以非法访问物理服务器的 I/O 接口，获得网络设备中敏感信息。另外，由于边缘计算节点分布式部署，依赖远程运维，升级和补丁修复不及时，会导致攻击者利用漏洞进行攻击。
③边缘计算平台面临的安全风险
边缘计算平台提供了车路协同应用部署和运行涉及的环境和服务，其面临的安全威胁如下 ：
• 边缘计算平台与管理系统、第三方应用之间传输的数据存在被拦截、篡改等风险 ；
• 边缘计算平台提供边缘计算应用部署环境，攻击者可通过恶意边缘计算应用对边缘计算平台发起非授权访问，导致敏感数据泄露或 (D)DoS 攻击等 ；
• 边缘计算平台自身以 NFV 或者容器的方式部署，存在虚拟化方面的安全威胁 ；
④边缘计算应用面临的安全风险
边缘计算应用存在的安全威胁如下 ：
• 攻击者可以非法访问边缘计算应用，导致应用的敏感数据发生泄露 ；
• 边缘计算应用生命周期管理中，存在非法创建、删除、更新风险 ；
• 边缘计算应用存在恶意消耗边缘计算系统的资源，造成边缘计算系统其它服务不可用的风险 ；
• 边缘计算应用在遭受攻击后产生的过载流量会造成对边缘计算系统的 (D)DoS 攻击。

3.5.1.3 车路协同网络面临的安全威胁

路侧边缘计算平台到云服务平台的通信网络面临的安全风险主要有以下几方面 ：
• 窃听 ：攻击者通过监视网络数据获得敏感信息 , 从而导致信息泄密。
• 重传 ：攻击者事先获得部分或全部信息 , 以后将此信息发送给接收者 ；
• 伪造 ：攻击者通过模拟合法用户，向接收者发送伪造信息。
• 篡改 ：攻击者对合法用户之间的通讯信息进行修改、删除、插入 , 再将伪造的信息发送给接收者。
• 拒绝服务攻击 ：攻击者通过某种方法使系统响应减慢甚至瘫痪 , 阻止合法用户获得服务 ；
• 行为否认 ：通讯实体否认已经发生的行为 ；
• 电子欺骗 ：通过假冒合法用户的身份来进行网络攻击 , 从而达到掩盖攻击者真实身份 , 嫁祸他人的目的 ；
• 非授权访问 ：没有预先经过同意 , 就使用网络或计算机资源被看作非授权访问。它主要有以下几种形式 : 假冒、身份攻击、非法用户进入网络系统进行违法操作、合法用户以未授权方式进行操作等 ；
• 传播病毒、通过网络传播计算机病毒 , 其破坏性非常高 , 而且用户很难防范。

3.5.2 车路协同对网络安全需求

3.5.2.1 省干网络安全需求

[ 省干安全 1] 应限制省干网络与其他网络的互联，避免因网络互连开放引起外部网络攻击 ；如业务需求必须进行互通时，需要考虑部署安全防护，满足相关等级保护要求。
[ 省干安全 2] 对于非信任网络应启用安全路由协议机制，避免非法连接和路由攻击。
[ 省干安全 3] 应安装网络安全评估分析软件，扫描分析网络，及时发现并修正存在的弱点和漏洞。支持通过安全评估分析软件，可以对省干网络的状态进行实时监控，及时发现安全隐患。
[ 省干安全 4] 应遵循最小化服务原则，关闭所有不需要的服务，避免增加网络的安全风险。
[ 省干安全 5] 不同安全等级的业务间需通过网络技术进行隔离，不同安全等级的业务间互访需通过安全平台进行策略管控。
[ 省干安全 6] 在与其他网络互联处要有流量监测能力，能基于骨干网络出入流量进行安全分析，并通过整网安全监控平台进行信息汇总，进行攻击溯源和处置。
[ 省干安全 7] 省干网络设备应具备设备内生安全，通过操作系统防护、软件完整性保护、数据机密性保护等手段保证网元自身的安全可信能力。

3.5.2.2 路段接入网安全需求

路段接入网安全需求中网络部分同省干网络安全需求，此外针对路侧通信网物联业务有以下需求 ：
①安全物理环境需求
• 网络设备所处的物理环境应不对感知节点设备造成物理破坏，如挤压、强振动 ；
• 网络设备在工作状态所处物理环境应能正确反映环境状态（如温湿度传感器不能安装在阳光直射区域）；
• 网络设备在工作状态所处物理环境应不对感知节点设备的正常工作造成影响，如强干扰、阻挡屏蔽等 ；
• 网络设备应具有可供长时间工作的电力供应（关键网关节点设备应具有持久稳定的电力供应能力）；
②安全区域边界
• 网络设备应保证只有授权的感知节点可以接入 ；
• 网络设备应保证感知节点具备二次认证能力，确保连接可信 ；
• 网络设备应能够限制与感知节点通信的目标地址，以避免对陌生地址的攻击行为；

3.5.2.3 云中心网络安全需求

参考 GB/T 22239-2019《信息安全技术 网络安全等级保护基本要求》中云计算安全三级相关要求。

3.5.2.4 网络安全的运维需求

车路协同网络安全的运维管理是以资产为保护对象展开的一系列管理，监控，运维等操作，安全的运维系统建设经常面临投资大，但防御效果不佳，部分安全设备无法 100% 发挥作用，安全运维严重依赖安全人员的专业技能以及对各类安全设备的熟练操作，依靠大量的人工操作保障安全体系的运营等问题。根据车路协同网络自身业务特性及组网架构，网络安全的运维需求包括以下三点内容
①集中管理需求
集中管理包括对资产，漏洞，知识库及情报的管理，对于资产的精准识别和全量探测是网络安全运维管理的必要前提。
• 资产管理 ：
车路协同网络中海量路侧设备部署在公路边，相对于数据中心的设备，其运维和管理的成本及复杂度更高，资产的集中管理能够提供全局化、可视化、实时化的全网资产状态感知，有助于运维人员清晰直观的了解资产的重要等级，软硬件配置，运行状态等信息。
• 漏洞管理 :
资产的漏洞为网络攻击提供了可行性，能够标识资产的脆弱性，通过对漏洞的及时管理能够有效降低攻击成功的可能性
• 知识库管理 ：
安全设备的检测能力依赖知识库的覆盖广度和时效性，对漏洞库，病毒库，补丁库等知识库集中管理 能够有效发挥安全设备的检测能力，车路协同网络中部分设备无法直连互联网进行知识库升级，通过自动化升级管理可以避免人工误操作、U 盘传播病毒等安全风险。
• 情报管理 ：
情报是辅助威胁判定的重要信息，通过关联 0 Day 漏洞，新型攻击事件等情报，提前做好预防，必要时通过手动更新知识库的方式进行专项防护。
②统一监控需求
统一监控包括资产风险评估，设备状态监控，态势感知以及可视化展现等功能，在资产的集中管理的基础上，结合业务系统及信息资产的重要性，对资产进行风险评估，对可能导致生产业务受损的关键资产进行识别和风险评估，为安全运维操作提供处置依据。
• 资产风险评估 ：
车路协同网络中，不同重要程度的资产受到损害时产生的影响有所不同，通过对资产的漏洞，网络攻击评估威胁发生的坑性，结合资产的重要程度，能够评估出资产的风险等级，针对不同的风险等级需要部署响应的安全防护策略。
• 设备状态监控 ：
关键的网络设备、边界设备、安全设备遭受攻击时，设备的可用性会受到损害，影响整个网络的可靠稳定运行。对设备状态的监控能够实时感知设备的 CPU 资源、内存资源、存储资源的消耗情况，避免资源耗尽或设备宕机导致网络故障。
• 安全态势感知 ：
安全态势感知包括对终端、网络、云平台的海量安全数据进行统一格式化处理，通过降噪，归并去重，分组聚合，关联分析挖掘高危安全事件，通过排序，统计、趋势预测等方式进行展示等内容。跨云网的全面的安全态势感知能力的有效运用有助于运维人员识别关键威胁事件，了解事件全面，对于后续的处置操作提供关键的决策依据。
③协同运维需求
安全运维包括安全响应管理、安全审计、安全评估、溯源取证、威胁报告输出等功能。
运维过程中将大量的分析，取证，响应等人工处置操作以及专家经验转化成程序和脚本自动化完成，最大化安全设备的防护能力，可以有效减少运维人员的学习及培训成本，提升运维效率，同时降低误操作及误判的概率。
• 安全响应 ：
根据对威胁事件的分析判断，安全响应动作可能包括发出告警、隔离、阻断、添加黑 / 白名单、忽略以及延后处理等操作，涉及不同网络设备、安全设备的操作和配置，应包含终端、网络、云平台的端到端安全处置策略，通过网络设备、安全设备、终端设备之间的协同联动，精准溯源、近源阻断勒索病毒等高危安全事件、避免人工操作慢、响应不及时导致威胁进一步扩散。
• 安全审计：
安全审计是对运维人员的操作进行合规性检查，对于误操作或恶意操作导致的网络安全事故进行事后审查和问题复现，同时也对运维人员的操作进行合规性约束。
• 威胁报告 ：
对网络安全态势以及运维结果输出威胁分析及处置报告，有助于及时总结和评价网络安全态势以及运维处置效果。自动化，定制化的周期性生成威胁报告能够规范报告格式及内容，减少运维人员的重复工作。

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

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

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

3.6.2 网络运维管理体系需求

需要组织运行维护机构，明确运营维护内容，建立运营维护流程，编制运维维护制度。
可靠的运维工作是系统实现建设目标、发挥效用的重要保障，为了避免“重建设、轻应用”的弊端，应成立专门的运维队伍。运行维护内容包括网络管理，故障管理，安全管理，系统和应用管理等。为保证运行维护体系的高效、协调运行，应依据管理环节、管理内容、管理要求制定统一的运行维护工作流程，实现运行维护工作的标准化、规范化。运行维护流程包含的环节有 : 日常运行维护、用户的运维请求、故障处理、问题跟踪等。为确保运行维护工作正常、有序、高质地进行，必须针对运行维护的管理流程和内容，制定相应的运行维护管理制度，实现各项工作的规范化管理。运行维护管理制度可分为 : 网络管理制度、安全管理制度、存储备份管理制度、故障管理制度、人员管理制度和质量考核制度等。

3.6.3 网络运维平台的需求

为支撑车路协同网络的运维，需建立网络与业务监控并重、端到端全覆盖，省中心和路段（分）中心分级响应的网络运维平台，将面向网络的分级监控与面向业务的场景监控相结合，工单任务直达运维团队，实现网络与业务问题的快速响应。
①业务开通
对网络设备提供业务批量和快速开通的能力，同时支持业务模板定制化，提供业务开通差异化配置修改。
支持业务全生命周期管理，并能实现动态扩缩容调整。
②网络全量设备可监可控
车路协同网络运维平台不仅需要对云中心网络、省干承载网和路段接入网等大网网络进行监控，还需要对路侧通信网络进行监控，确保网络全量设备可监、可控。
③面向业务的场景监控
建立业务级场景监控，按用户及场景需求维度，定制化呈现网络告警、网络性能指标、运行指标等信息。需要具备对业务流（五元组）和 SLA（时延、丢包）进行实时精确监测，自动还原业务路径，出现故障后分钟级实现故障定界定位。
④巡检管理
对网络设备进行定时巡检，并产生巡检报告。
⑤基础信息监控
对设备告警、线路告警监控，显式告警级别，告警名称，定位信息，告警产生时间，告警恢复时间。
⑥性能指标监控和历史性能数据分析
通过实时性能分析工具查看当前设备的实时负载情况。呈现时延、带宽、可靠性等性能指标，可根据用户要求及业务特点定制。提供历史性能数据查询功能，可以按照小时级、天、周、月、年等不同时间段进行统计，同时提供自定义时间段的定制功能，支持导出到 xls、pdf 等格式。
⑦远程升级管理
平台应具备软件版本管理、软件版本升级及软件版本回退功能。
软件版本管理支持设备版本的查询及升级进度的上报和查询，设备历史升级情况查询 ；支持整包升级包或差分升级包的管理。
软件版本升级管理应具备对设备进行软件远程升级，支持手动或自动方式进行软件升级处理 ；应具备对设备远程升级包的上传功能。针对平台对设备自动升级的情况，必须具备配置多个升级时间区间（含日期，时，分，秒等）及多种升级周期（含每天，每周，每月等）参数。
软件版本回退应具备设备远程软件版本回退功能，具备回退到最后一次成功运行的设备软件版本的功能。
⑧SLA 服务指标监控
对故障处理时长、处理及时率等 SLA 指标监控。
拓扑及告警关联监控 ：呈现业务端到端拓扑，并与告警关联呈现
⑨网络拓扑发现
使用 ICMP、SNMP、LLDP 和 BGP-LS 等网络协议和技术能够自动快速的发现网络中二层和三层的网络设备，并根据发现设备之间的关系自动生成全局的二层或三层的网络拓扑结构图。网络管理人员能够看到整个运营网络系统的网络拓扑结构，包括各个分布地区的子网、各个子网之间的网络连接关系、及其每一子网上的资源和资源的状态变化。具体信息如下 ：
第二层和第三层网络设备、网络协议、设备信息（卡，端口，接口，IP, MAC），设备之间的物理和逻辑关系，设备连接信息等。通过对网络节点状态的轮询，实时监控网络中所有资源的状态。支持拓扑自动事故分析，拓扑图中设备的监控报警，支持基于业务粒度的网络拓扑可视
⑩网络资源管理
可以对网络设备的可用性进行监控，监控设备接口的状态信息，包括接口名称，操作管理状态，ICMP 包率，通断信息，接口发送接收速率等具体指标。监控设备关键资源使用情况，包括 CPU/ 内存使用率等关键资源使用率。可以对网络设备间链路可用性进行监控，观察链路的通畅度。可以对网络设备进行搜索，搜索条件包括 ：设备名称、ip 地址和设备类型等，可以快速的查看设备的运行状态，定位故障问题。
（11）设备 IP、MAC 安全管理
通过终端识别，实时监控网络中接入的终端用户，一旦发现异常终端或 IP 地址盗用的现象，会迅速产生告警。
（12）配置管理
对网络设备的配置更改进行监控，发现变更后进行告警。提供设备运行配置和启动配置的基线化版本管理，将每个设备相关的配置文件划分为不同版本管理。运维管理系统能够借助 FTP/TFTP上传下载网络设备配置文件，并在管理服务器侧进行归档存储。这一功能在网络开通和调整时能够对不同阶段的配置情况进行存档。
（13）安全管理
平台应提供完善的用户访问授权、身份认证与权限管理机制。对日常操作进行完整日志记录，并具备日志备份功能，备份日志的保存支持存储不小于 7 天。当系统出现故障时，能够根据文件系统备份与数据库备份将运维管理平台恢复到备份前的状态。平台应具备数据定期、自动、手动备份功能。

3.6.4 网络的运维需求

车路协同业务对带宽、时延、可靠性等指标要求更高，在传输网故障处理、网络配置升级、现网结构优化等方面提出了更加严格的要求。

3.6.4.1 路段接入网络的运维需求

故障处理
提供 7*24 小时故障处理服务，普通故障处理时长不超过 8 小时，严重故障处理时间不宜超过 48 小时，网络可用性≥99.9％。
网络配置升级
设备配置升级需要尽量不影响车路协同业务，影响到车路协同业务的升级需要在业务量较少的夜间时段进行，并且在2 小时内完成升级。
线网结构优化
路段光纤运维管理工作分为“日常维护”和“技术维护”两大类，采用日常巡查、维护、应急抢修和综合管理的方式，路段光纤完好率需要达 99%。
网络设备优化
网络设备更改，线路的迁移或优化改造，需要在业务量较少的夜间时段进行，并且在 2 小时内完成。
人工巡检
机房每日巡检次数不少于 1 次，采用轮流巡检制，按实现安排的人员执行，确保机房的不间断管理。遇特殊事情或特殊安全事故时，维护人员 24 小时留守现场不间断进行巡检值班。
兼容管理
兼容多个厂家、多种设备统一网管，全面检测设备的运行情况。
安全管理
设备具备很高的安全稳定性，不易遭受网络攻击，并具备完整的操作权限管理功能和完善的系统安全机制。

3.6.4.2 省干承载网络的运维需求

故障处理
提供 7*24 小时故障处理服务，普通故障处理时长不超过 4 小时，严重故障处理时间不宜超过 48 小时，网络可用性≥99.99％。
网络配置升级
设备配置升级需要尽量不影响车路协同业务，影响到车路协同业务的升级需要在业务量较少的夜间时段进行，并且在2 小时内完成级。
网络设备优化
网络设备更改，需要在业务量较少的夜间时段进行，并且在 2 小时内完成。
人工巡检
机房每日巡检次数不少于 2 次，采用轮流巡检制，按实现安排的人员执行，确保机房的不间断管理。遇特殊事情或特殊安全事故时，维护人员 24 小时留守现场不间断进行巡检值班。
兼容管理
兼容多个厂家、多种设备统一网管，全面检测设备的运行情况。
安全管理
设备具备很高的安全稳定性，不易遭受网络攻击，并具备完整的操作权限管理功能和完善的系统安全机制