《边缘计算产业联盟：高速公路车路协同网络需求研究报告（2022）（73页）.pdf》由会员分享，可在线阅读，更多相关《边缘计算产业联盟：高速公路车路协同网络需求研究报告（2022）（73页）.pdf（73页珍藏版）》请在三个皮匠报告上搜索。

1、车路协同网络需求研究2022 年 版本 1.034目 录CONTNTS前言 01缩略语 67参考文献 69高速公路车路协同网络面临的主要问题 071.2高速公路车路协同系统的建设现状041.1概述 0301高速公路车路协同系统的网络架构152.2高速公路车路协同业务的体系架构112.1高速公路车路协同体系框架 1002车路协同业务内容分析173.1路段接入网需求分析503.3车路协同业务对网络安全的需求分析553.5车路协同业务部署场景分析393.2车路协同业务对省干网络需求分析533.4车路协同业务对网络运维的需求分析603.6高速公路车路协同网络需求分析 1603结束语 660401高速公

2、路车路协同网络需求研究前 言PREFACE车路协同（车联网）是传统汽车行业、交通行业与信息通信行业加速融合发展的产物，对于实现传统产业转型升级和“换道超车”起着至关重要的作用，在提升车辆行驶安全、提高通行效率、完善出行信息服务等方面具有重要的意义。为推动车路协同的发展，国家及各部委出台了一系列的政策，2016 年 4 月，在交通运输部信息化十三五发展规划中提出了开展高速无线通信、车路协同、区域路网协同管理、出行信息服务等智能应用。2018 年 2 月，交通运输部加快推进新一代国家交通控制网和智慧公路试点中提出路运一体化车路协同试点方向。11 月，工信部车联网（智能网联汽车）直连通信使用 590

3、5-5925MHz 频段的频率管理规定（暂行），确定了车联网（智能网联汽车）直连通信的工作频段及使用要求。12 月，工信部印发车联网（智能网联汽车）产业发展行动计划 ，推动形成深度融合、创新活跃、安全可信、竞争力强的车联网产业新生态。2019 年 9 月，中共中央、国务院交通强国建设纲要提出，加强智能网联汽车（智能汽车、自动驾驶、车路协同）研发，形成自主可控完整的产业链。2020 年 2 月，国家发改委牵头十一部委发布 智能汽车创新发展战略 ， 提出智能交通系统和智慧城市相关设施建设取得积极进展，车用无线通信网络（LTE-V2X 等）实现区域覆盖。2017 年至 2021 年，工业和信息化部、

4、公安部、交通运输部及国家标准化管理委员会发布国家车联网产业标准体系建设指南系列文件，提出发挥标准在车联网产业生态环境构建中的引领和规范作用。在国家、行业政策的指引下，全国智慧高速公路的建设都把车路协同作为一项重要的试点示范内容。这与高速公路全封闭性、 车辆行驶方向相对固定、 现有信息基础设施设置比较完善等特点密不可分， 同时沿线具有匝道分合流、隧道、服务区、收费站等多种构造物，便于打造车路协同的多种应用场景。回传网络在车路协同的建设中发挥着中枢神经的作用，支撑车路协同系统演进的全过程，覆盖路侧、边缘计算中心、 区域计算中心、 数据平台等各个环节。 但目前在高速公路车路协同网络建设中面临标准缺乏

5、、 业务需求不明确、应用场景不清晰等问题。高速公路车路协同网络需求研究详细介绍了高速公路车路协同的建设现状及面临的主要问题，提出了高速公路场景下车路协同的体系架构，并结合业务内容及部署场景，详细分析了高速公路场景下车路协同业务对路段接入网、省干网络、网络安全及网络运维的需求。为建设单位、设计单位、设备厂商、工程集成商和运营商在部署和应用时提供参考。本研究由中国公路工程咨询集团有限公司、华为技术有限公司、四川省公路规划勘察设计研究院有限公司、中国信息通信研究院、北京交科公路勘察设计研究院有限公司、苏交科集团股份有限公司、中国通信建设集团设计院有限公司、中国移动上海产业研究院、湖南高速、中信科移动

6、通信技术股份有限公司、高新兴科技集团股份有限公司等单位共同完成，主要编写人包括前 言0102关于智慧交通网络特设组由边缘计算产业联盟（ECC）的边缘计算网络基础架构工作组（ECNI）工作组和IMT-2020(5G)推进组蜂窝车联 （C-V2X）工作组，在 2021 年 4 月联合发起成立的产业工作组，通过提供智慧交通网络的相关规范、测试床和最佳实践等产业活动，为智慧交通产业提供经过验证的网络方案，推动智慧交通产业的健康和持续的发展。关于边缘计算产业联盟（ECC）边缘计算网络基础架构工作组（ECNI）工作组边缘计算作为新兴产业应用前景广阔，产业同时横跨 OT、IT、CT 多个领域。边缘计算网络基

7、础架构工作组（ECNI）是由ECC 和网络 5.0 技术创新联盟于 2019 年联合成立，围绕边缘计算网络开展规范 / 标准 / 测试床 / 示范方案等领域开展产业发展工作，致力于打造边缘计算网络产业，促进边缘计算产业发展。更多详细信息，欢迎点击：关于 IMT-2020(5G) 推进组蜂窝车联（C-V2X）工作组蜂 窝 车 联（C-V2X） 工 作 组 成 立 于2017 年 6 月份，负责组织开展 C-V2X、MEC、网络与平台、安全相关技术方向的研究和验证工作，以及基础设施部署、应用推广、商业模式和运营等工作。目前，300 余家科研院所、企业形成了“产、学、研、用”合作、“汽车、信息通信、

8、交通”等多行业协同的成员联盟。国际上蜂窝车联（C-V2X）工作组与 5GAA、SAE 等组织紧密联系，国内与 C-ITS、CAICV、TIAA等组织、联盟合作，共同推动 C-V2X 的快速健康发展。更多详细信息，欢迎点击：前 言02张艳、樊升印、 刘利文、 张猛威 宋军、 吴彦君、 赵凤毅、 敖日格勒 蒋贵川、 冯光宇、 易雷、 汪正勇 余冰雁、 鲍叙言、 雷凯茹 刘见振、王珣中国公路工程咨询集团有限公司华为技术有限公司四川省公路规划勘察设计研究院有限公司中国信息通信研究院北京交科公路勘察设计研究院有限公司牵头单位参与单位苏交科集团股份有限公司 中国通信建设集团设计院有限公司 中国移动上海产业

9、研究院 湖南高速信息科技有限公司中信科移动通信技术股份有限公司 高新兴科技集团股份有限公司 华录易云科技有限公司 新唐信通 ( 浙江 ) 科技有限公司 中兴通讯股份有限公司 华设设计集团股份限公司 北京信安世纪科技股份有限公司 郑州信大捷安信息技术股份有限公司湖南湘江智能科技创新中心有限公司艾少龙、 刘金伟、 刘玲慧 张长新、 苏建伟、 崔亚明 张青山、 郑至城、 敖婷 傅耘、 邓翔、 刘永 徐晖、 邓小惠、栾彧君 吴冬升、 王传奇、 曾少旭 佘红艳、马威、王碧云 李静林、 黄莉、 张陆安 陈晓、 王强、 白平在 奚加荣、 丁闪闪、 张吉 焦靖伟、 汪宗斌、 付军 刘献伦、 王广辉、 徐文洁

10、高培基、谭敏、毛荣标智慧交通网络特设组研究报告，总评审：宋 军 博士 （智慧交通网络特设组联执主席，ECNI 联执主席）余冰雁 博士 （智慧交通网络特设组联执主席）03概述0104（1 ）政策现状车路协同（车联网）是传统汽车产业与信息通信行业加速融合发展的产物，对于实现传统产业转型升级和 “换道超车”起到至关重要的作用，在提升车辆行驶安全、提高交通效率、提供出行信息服务和支持自动驾驶等方面具有重要的意义。全球范围内，汽车智能化、网联化和电动化催生的车联网产业已经成为包括美、欧、亚等汽车发达国家或地区的重要战略性方向，各国家和地区纷纷加快产业布局、制定发展规划、推进车联网产业化进程。我国也高度重

11、视车联网产业发展，国家各个部委正在积极推动车联网技术研究和产业落地。2016 年 4 月，交通运输部信息化十三五发展规划 中提出了要推进智慧公路示范工程， 选取重点区域公路项目或路段，开展高速无线通信、车路协同等智能应用。2017 年 1月，交通运输部在推进智慧交通发展行动计划 ，提出推动智慧交通试点示范工程，推广应用具有短程通信、电子标识、高精度定位、自动监测、自动驾驶等功能的智能运输装备。新建或改造智能交通核心技术检测平台及试验场所，提高车载智能终端、车路协同设备等智能化运输装备的检测能力。2018年 2 月，交通运输部在加快推进新一代国家交通控制网和智慧公路试点中提出路运一体化车路协同试

12、点方向。2018年 11月，工信部发布车联网（智能网联汽车）直连通信使用 5905-5925MHz 频段的频率管理规定（暂行） ，确定了基于 LTE-V2X 技术的车联网（智能网联汽车）直连通信的工作频段及使用要求。12 月， 工信部印发车联网（智能网联汽车）产业发展行动计划 ，推动形成深度融合、创新活跃、安全可信、竞争力强的车联网产业新生态。2019 年 7 月，交通运输部数字交通发展规划纲要中提出推进车联网部署应用。 2019 年 9 月，中共中央、国务院交通强国建设纲要提出，加强智能网联汽车（智能汽车、自动驾驶、车路协同）研发，形成自主可控完整的产业链。2020 年 2 月，国家发改委牵

13、头十一部委印发智能汽车创新发展战略 ，提出到 2025 年，智能交通系统相关设施建设取得积极进展，车用无线通信网络（LTE-V2X 等）实现区域覆盖。2020 年 4 月，工信部发布关于推动 5G 加快发展的通知 ，提出要促进 “5G+ 车联网”协同发展，推动将车联网纳入国家新型信息基础设施建设工程，促进 LTE-V2X 规模部署。建设国家级车联网先导区，丰富应用场景，探索完善商业模式。2020 年 8 月，交通运输部印发关于推动交通运输领域新型基础设施建设的指导意见 ，提出结合 5G 商用部署，统筹利用物联网、车联网、光纤网等，推动交通基础设施与公共信息基础设施协调建设。高速公路车路协同系统

14、的建设现状1.1高速公路车路协同系统的建设现状05高速公路车路协同系统的建设现状2021 年 2 月，中共中央、国务院印发国家综合立体交通网规划纲要 ，提出推进交通基础设施网与信息网融合发展，推动车联网部署和应用。2021 年 5 月，住建部、工信部联合印发关于确定智慧城市基础设施与智能网联汽车协同发展第一批试点城市的通知 ，确定北京、上海、广州、武汉、长沙、无锡等 6 个城市为智慧城市基础设施与智能网联汽车协同发展第一批试点城市； 12 月，确定重庆、深圳、厦门等 10 个城市为第二批试点城市。2021 年 7 月，工信部联合 10 部门印发5G 应用 “扬帆”行动计划（2021-2023

15、年） ，提出要强化汽车、通信、交通等行业的协同，共同建立完备的 5G 与车联网测试评估体系。2021 年 11月， 工业和信息化部发布了 “十四五”信息通信行业发展规划 ， 提出要加强基于 C-V2X的车联网基础设施部署的顶层设计，“条块结合” 推进高速公路车联网升级改造和国家级车联网先导区建设。2021 年 12 月，国家标准化管理委员会、中央网信办、科技部等 10 部门印发 “十四五”推动高质量发展的国家标准体系建设规划的通知，提出要完善智能网联汽车标准体系，加快智能驾驶辅助、自动驾驶、汽车无线充电、网联通信、信息安全等标准研制。2017 年至 2021 年，工业和信息化部、公安部、交通运

16、输部及国家标准化管理委员会发布国家车联网产业标准体系建设指南系列文件，提出发挥标准在车联网产业生态环境构建中的引领和规范作用。政策的引导促进了车联网行业的发展，在国家及各部委的政策引导下，近年来各地方政府也积极落实，各省市在开展智慧高速的建设过程中，也将车路协同示范验证考虑在内，目前北京、河北、江苏、浙江、江西、广东、湖南、海南、四川、山东等省市均在探索车路协同在智慧高速中的应用，大大加快了车路协同系统的验证。06高速公路车路协同系统的建设现状（2）项目现状目前国内多条高速公路的设计和建设中均考虑了车路协同的示范验证，包括延崇高速北京段、京雄高速北京段、京沪高速北京、山东及江苏段、京台高速山东

17、泰安至枣庄段、贵阳至安顺复线、成宜高速等多个项目。延崇高速北京段是 2022 年冬奥会的重要交通保障通道，是交通运输部绿色公路、智慧公路、品质工程的示范路，全长约 33.2KM，其中车路协同测试段 18KM。车路协同示范路段涉及隧道、服务区、匝道分合流、主线四种应用场景，项目中的智能网联车辆均为奥组委专用车辆，围绕冬奥服务。车路协同示范路段主线设置的高清摄像机、毫米波雷达、RSU等设备均利用沿线照明灯杆进行部署。作为第一条车路协同示范高速，目前该路段已经通车运行，可支持 L4+ 自动驾驶。京雄高速按照 “雄安质量”的总要求，打造新时代可持续发展的高速公路新模式，京雄高速北京段全线 27KM，全

18、线建设车路协同试验路段，在匝道分合流、主线、桥梁三种应用场景部署车路协同系统，并在最内侧车道设置自动驾驶车道，开展车路协同及自动驾驶试点应用研究。除全息感知及车路协同通信系统的设置外，建设基于北斗卫星导航系统的地面时空服务系统，为具有北斗增强信号处理功能的车载终端和路侧设施设备提供稳定可靠的高精度定位和授时服务，支撑重点营运车辆精准管控、车路协同、自动驾驶、应急管理与指挥调度等应用实现。京沪高速车路协同示范验证路段贯穿北京、天津、河北、山东、江苏等 5 个省市，涉及路段长度约 670 公里，应用场景包括分合流安全预警与诱导场景、隧道安全预警与诱导场景、准全天候辅助通行场景、自由流差异化服务场景

19、等。项目将完成 10000 辆 C-V2X 车载终端搭载，实现车路协同应用场景 100 个，建成包括部级车路协同平台、区域车路协同云控平台、智慧物流平台、高精地图平台在内的多个云平台，通过车路协同基础设施的规模部署，构建车联网先导应用环境，对车路协同技术及应用场景进行全面测试验证，项目具有 “省域跨度大、覆盖范围长、应用场景多、车载终端体量大”等亮点。京台高速山东泰安至枣庄段是山东省第一条智慧高速，全长 189KM，选取满庄收费站至贤村水库特大桥单侧约20km 建设车路协同试验路段。车路协同示范路段涉及服务区、匝道分合流、桥梁、主线四种应用场景。针对货车占比高的特性，在示范路段最外侧设置自动驾

20、驶专用车道，支持货车编队和 L3 级以上车辆的自动驾驶。贵阳至安顺复线是贵州省智慧高速重点建设项目，全长 90 公里，全线设置车路协同示范路段， 并利用起点 21 公里路段先试先行， 开展智能网联汽车 （车路协同）测试与自动驾驶比赛示范应用， 在已建设施的基础上增加必要的软硬件设施，进行智慧交通产品测试、 自动驾驶仿真测试、 车路协同场景验证测试、 货车编队测试及示范、 专用车道柔性管控测试及示范，促进贵州省智能交通和智能网联汽车产业发展。蜀道集团通过申请 59055925MHz 频道，基于 LTE-V2X 技术，分阶段在蓉城二绕约 8 公里路段、成宜高速约 157公里路段开展车路协同试点。通

21、过部署视频监控、 车辆综合检测（毫米波雷达） 、 气象检测、 北斗定位、 可变情报板、 IP 广播、可变限速标志、RSU 和边缘计算单元等前端系统，实现道路路况、车辆、气象等综合信息的采集和车 - 路（V2I）应用信息的发布，通过车路协同中心云平台、智能网联车载终端、移动 APP、路侧交通诱导设施等联动构建完整的车路协同服务体系。07高速公路车路协同网络面临的主要问题1.2.1 网络结构不尽合理目前国内各省（市、自治区）的高速公路主要采用树型多级管理模式，高速公路通信网络系统与管理模式基本相应，形成 “省（市、自治区）通信中心 - 区域 / 路段通信（分）中心 - 基层通信站”的三级管理架构。

22、高速公路通信网络干线层数据交换网络与传统的高速公路业务管理逻辑高度同构，表现为典型的下级节点以上级通信节点为核心构成星型结构，总体形成多级树形结构。网络结构以解决上下级节点数据传输为主，同级节点之间没有直接的信息交互。1.2高速公路车路协同网络面临的主要问题图 1.2-1 现阶段高速公路通信网络架构有区域中心的三级管理架构省通信中心干线传输网路段通信分中心路段接入网路段通信分中心路段接入网片区通信中心片区通信中心基层通信站基层通信站基层通信站基层通信站基层通信站基层通信站无区域中心的三级管理架构骨干层通信网省通信中心路段通信分中心路段通信接入网路段通信接入网市通信中心市通信中心路段通信分中心基

23、层通信站基层通信站基层通信站基层通信站基层通信站基层通信站08高速公路车路协同网络面临的主要问题车路协同要求为车辆提供全程的高时效信息交互服务。这就必然要求边缘节点之间、路段分中心之间进行实时的数据交互。同级节点之间的数据流量急剧增加，而现有网络结构无法适应数据多点流向的复杂应用需求。1.2.2 网络设备承载能力受限按照高速公路通信技术要求 ，各省（市、自治区）的高速公路网络系统由省域干线传输网（简称 “干线网” ）和路段接入网（简称 “接入网” ）两层系统组成。干线网方面： 通过前期调研（结果详见后表）可以发现，各省（市、自治区）高速公路通信网传输网正在向以 OTN 为主流技术体制的方向演变

24、。 部分省份仍然采用SDH技术。 少数省份没有实施单独的传输网。 除了以四川为代表的少数省份，其余省（市、自治区）均未实施干线层路由型 IP 网。接入网方面： 国内高速公路接入网的通信设备多样，新旧技术混杂的情况，以太网、SDH、MSTP 等多种新旧网络技术并存。早期通信设备（例如 ： STM-1 的 ONU 设备）业务适应和承载能力受限，不足以支撑车路协同、智慧交通等新型业务信息高速可靠交互的带宽需求，必然会出现网络上管理消息传递不畅、调度不够灵活、链路保护不完善等诸多问题。序号省份传输系统技术体制1北京2 个 10G 以太网（收费、监控）2福建骨干（OTN）+ 接入（MSTP、PTN 等多

25、种）3湖南骨干（OTN+PTN 混合组网）+ 接入（MSTP、PTN 等多种）4贵州骨干（OTN）+ 接入（SDH、MSTP、PTN 等多种）5浙江骨干（OTN）+ 接入（MSTP、PTN 等多种）6河北骨干（STM-64/STM-16/STM-4 ASON+SDH）+ 接入（MSTP、SDH 等多种）7江西骨干（OTN+IPRAN）+ 接入（MSTP、PTN 等多种）8云南骨干（ASON+OTN）+ 接入（MSTP、PTN 等多种）9广西骨干（OTN）+ 接入（MSTP、PTN 等多种）10甘肃骨干（OTN+SDH）+ 接入（MSTP、PTN 等多种）11四川骨干（OTN+ 路由器）+ 接入

26、（MSTP、PTN、以太网等多种）12辽宁骨干（OTN）+ 接入（MSTP、PTN 等多种）13吉林骨干（OTN+SDH）+ 接入（MSTP、PTN、以太网等多种）14山西骨干（OTN）+ 接入（MSTP、PTN 等多种）15河南骨干（OTN+PTN）+ 接入（MSTP、PTN 等多种）16湖北骨干（OTN+SDH）+ 接入（MSTP、PTN、以太网等多种）17广东骨干（近期 OTN+SDH，远期全网 OTN）+ 接入（MSTP、PTN、以太网等多种）表 1.2-1 全国主要省份高速公路传输网技术统计表09高速公路车路协同网络面临的主要问题总体来看，高速公路通信网承载的业务已经全面向IP 业务

27、演进，通信传输业务需求呈爆发式增长趋势，现有通信传输设备的提档升级势在必行。1.2.3 网络需求有待系统梳理车路协同应用是未来高速公路网络承载的主要业务。按照智能网联汽车技术路线图 2.0 ，车路协同等高新技术仍在发展中，具体的解决方案存在多种技术选择。网络架构以及部署方案的选择需要由场景需求来决定，车路协同的体系建设非常复杂，加之国内行业组织提出的应用场景中，很多实用的网络相关指标并没有明确量化。另外，个人用户、行业车辆、高速公路运营公司、政府部门对车路协同业务的需求存在差异化 ： 个人关注的是如何提高安全性、驾驶体验 ； 车端设备关注的是数据是否可信、可靠，信息量是否充足、如何有效使用；

28、高速公路运营公司关心的是效益和成本、道路的安全与畅通 ； 政府 ( 或公安部门 ) 的需求是高速公路管控，优化交通治理。综上，车路协同体系网络设计开展的依据有待系统研究和梳理，高速公路车路协同试点项目建设可落地可推广的应用领域有待明确，营运车辆和个人车辆的车路协同应用场景标准有待进一步细化和量化，以尽量避免系统建成后的网络方案反复调整。1.2.4 网络体系演进迭代困难国内高速公路网络系统基本成型，由于近几年通信技术发展迅速，设备更新换代较快，早期采用的通信网络设备技术相对落后，无法通过简单方式（例如 ： 增加或替换通信板卡） ，实现网络设备提档升级。另外，随着网络拓扑从传统树型网络向网状网演变

29、，边缘通信节点能力需要升级，节点之间的通信链路需要补充，这都需要大量的资金投入，且要强化顶层设计，按规划、有步骤地实施，以保证网络平稳演进迭代。1.2.5 网管维护体系普遍薄弱按照高速公路通信的三级管理架构 ： “省级通信中心 - 区域 / 路段通信（分）中心 - 基层通信站” ，各级通信节点的维护分别落在省级管理部门（如 ： 省监控结算中心）和路公司两个层面，导致通信网络的运维和后期运营的技术管理和行政管理存在不统一、多交叉、多界面，网管维护系统建设普遍薄弱。按照高速公路通信技术要求 ，干线网络网管系统和接入网络网管系统均有功能要求，但在实际建设中，由于设备种类不同，网络管理信息不畅，无法实

30、现一套后端平台进行统一维护。车路协同这种复杂业务更是加剧了上述矛盾，编制技术方案时需要考虑高速公路运维能力弱的实际情况。10高速公路车路协同的建设现状高速公路车路协同体系框架0211区域计算平台CB业务运营平台A路侧感知设备FRSUG OBUE路侧通知设备省中心路段中心路段分中心边缘终端AB ACCEFC/CFPC5UuDF/FDD路侧边缘计算平台A4气象传感器A5道路传感器A1毫米波雷达A2摄像头A3激光雷达BC/CBDC/CDAD高速公路车路协同业务的体系架构2.1高速公路车路协同业务的体系架构图 2.1-1 高速公路车路协同业务的体系架构12高速公路车路协同业务的体系架构车路协同业务系统

31、主要由路侧终端、边缘端、云端、外部应用组成，其中一个路侧边缘计算平台会连接多组路侧感知设备，一个区域计算平台连接多个路侧边缘计算平台，一个业务运营平台连接多个区域计算平台。其业务架构和业务流向如图 2.11 所示 ： 整体架构图流程来源于实际项目经验，某些业务数据流向可能和一些标准规定有一定的出入。1）路侧感知设备（A）主要是指路侧声光一体机、情报板等设备，其采集的数据根据其数据类型和业务需求不同分别输入到业务运营平台（B） 、区域计算平台（C） 、路侧边缘计算平台（D） 。2）路侧边缘计算平台（D）进行数据融合计算并把结果形成标准的消息帧，把相应的消息帧传输给区域计算平台（C） 、路侧 RS

32、U（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）可以根据需求通过

33、Uu 口连接区域计算平台（C）或业务运营平台（B） ，获取相应的数据服务。此外，考虑到某些路侧感知设备智能化水平较高，处理分析结果可满足业务场景应用需求，因此存在路侧感知设备直接传输数值至 RSU 的过渡场景。2.1.1 三级业务平台架构路侧边缘计算平台： 实时获取路侧传感器数据进行融合计算，以高性能计算能力提供更高精度和更可靠的融合感知结果和交通事件，完成目标的识别、分类、追踪和轨迹拼接等功能，还能够对车辆车牌识别、运动属性预测等，为路侧交通参与者提供准确的数据服务。路侧边缘计算平台的感知缓存主要存储路侧传感器历史数据，同时对于路侧海量、繁杂的数据进行清洗过滤，抽取业务所需的数据发送给区域计

34、算平台。区域计算平台： 区域计算平台完成设备管理、模型管理、算法管理和应用管理，以及和边缘计算平台节点管理等相关功能。同时对路侧传感器的结构化数据、路侧边缘计算平台融合感知的结构化数据进行提取，将计算结果按照标准 T/CSAE 53-2020 和 T/CSAE 157-2020 对应用层要求，形成标准消息帧，发送给路侧 RSU 和业务运营平台。业务运营平台： 业务运营平台根据需求有选择性的从路侧感知设备获取所需的实时数据，历史数据可以从路侧计算平台的感知缓存处获取。业务运营平台对全域数据进行挖掘分析，以支撑路侧智能网联汽车整体运行环境，为智能网联汽车提供高精地图、智能导航、交通引导等服务支持，

35、为交通指挥调度提供高精度态势认知等服务支持。同时业务运营平台可对终端设备和边缘设备进行统一的管理，提供针对所有路侧、边缘和区域设备 “接入- 监控 - 管理”的服务，包括对设备的查询、修改和升级配置、删除节点等。收集路侧单元设备的基本信息和状态性能信息，监控设备运行情况，及时对工作异常设备进行故障诊断，并基于终端管理协议对路侧单元设备进行远程管理。13高速公路车路协同业务的体系架构2.1.2 业务接口AD 接口： 为路侧传感器设备与路侧边缘计算平台之间的接口（包括感知缓存） ，主要负责路侧传感器数据根据业务需求上传原始数据至路侧边缘计算平台。AB 接口： 为路侧传感器设备与业务运营平台之间的接

36、口，主要负责业务运营平台根据业务需求直接从路侧传感器获取实时数据。AC 接口： 为路侧传感器设备与区域计算平台之间的接口，主要负责区域计算平台根据业务需求直接从路侧传感器获取实时数据，或进行传感器直接输出的结构化数据的获取。DC/CD 接口： 为路侧边缘计算平台与区域计算平台之间的接口，主要负责路侧边缘计算的结构化数据上传至区域计算平台，和业务运营平台下发业务数据或设备管理数据至路侧边缘计算平台。CB/BC 接口： 为区域计算平台与业务运营平台之间的接口，主要负责业务运营平台把标准的消息帧传递给业务运营平台，或业务运营平台根据业务需求，获取路侧传感器历史数据，同时业务运营平台根据请求下发相应的

37、事件数据。CE 接口： 区域计算平台与路侧通知设备之间的接口，区域计算平台把交通事件信息下发给路侧通知设备，包括但不限于道路危险状况提、限速提醒、道路施工提醒、弯道提醒、前方拥堵等信息。DF/FD 接口： 路侧边缘计算平台与路侧 RSU 之间的接口，主要负责路侧边缘计算平台融合传感器数据后，将计算结果按照标准 T/CSAE 53-2020 和 T/CASE 157-2020 对应用层要求，把数据打包为标准规定的消息帧格式，发给路侧 RSU，同时 RSU 会把接收到 OBU 的数据发给路侧边缘计算平台，丰富其数据，提高其算法的准确度。CF/FC 接口： 区域计算平台与路侧 RSU 之间的接口，区

38、域计算平台接收业务运营平台下发的数据，区域计算平台结合实际情况做处理，把数据下发给区域内的 RSU ； 同时 RSU 会把相关信息发送给区域平台和业务运营平台，通过这种方式和其它区域内的 RSU 进行数据交互，比如前方事故预警，可以跨区域进行预警信息的播报。GB/BG、GC/CG 接口： 车辆 OBU 与区域计算平台和业务运营平台之间的接口，OBU 根据需求通过 Uu 口和区域计算平台或业务运营平台进行数据互通。根据图 2.11，车路协同网络数据业务流向见表 2.1-1：表 2.11 车路协同数据流向描述业务流数据流向数据描述接口上行 业务路侧感知设备 业务运行平台（图 2.11 ： A B）

39、1）激光雷达点云原始数据， 包括雷达 ID、 检测物体三维位置数据等；2）摄像头视频数据 ； 3）毫米波雷达轨迹数据。AB路侧感知设备 路侧边缘计算平台 （图 2.11： A D）1）激光雷达点云原始数据， 包括雷达 ID、 检测物体三维位置数据等；2）摄像头视频数据 ； 3）毫米波雷达轨迹数据。AD14高速公路车路协同业务的体系架构业务流数据流向数据描述接口上行 业务路侧感知设备 区域计算平台（图 2.11 ： AC）1）毫米波雷达目标轨迹数据，交通流量统计数据，包括流量、车距、车速、排队长度等信息 ； 2）相机输出的结构化数据，包括车辆抓拍违规违章，包括超速、压线、逆行、禁止大货车等。AC

40、路侧边缘计算平台 区域计算（图 2.11 ： DC）对路侧传感器数据进行细粒度融合感知得到的结构化数据，包括交通元素的 ID、位置、速度、航向角、形状大小等。DC区域计算平台 业务运营平台（图 2.11 ： CB）全域的融合感知结构化数据以及路侧感知设备结构化数据形成 v2x可用的标准消息帧。CB车载 OBU 路侧 RSU （图 2.11 ： G F）车辆实时状态数据（位姿、速度等） ，车辆通过实时广播将自身的实时状态告知周围车辆和路侧 RSU。PC5车载 OBU 业务运营平台或区域计算平台（图 2.11 ：GB、GC）车辆 OBU 根据需要把自身的状态数据（位姿、速度等）通过 Uu 口发送给

41、业务运营平台或区域计算平台。Uu路侧 RSU 区域计算平台 （图 2.11 ： FC）RSU 把收到的 OBU 数据上传给区域计算平台，和区域内的其它RSU 数据共享。FC路侧 RSU 路侧边缘计算平台（图 2.1-1 ： FD）RSU 把 OBU 的数据发送给路侧边缘计算平台，丰富其数据，提高路侧边缘计算平台的数据融合精准度。FD下行 业务业务运营平台 车载 OBU（图 2.11 ： BG）车辆 OBU 通过 Uu 蜂窝口向运行平台发出数据请求， 包括软件更新、下载、地图服务等，业务运营平台根据车载 OBU 的请求，提供相应的服务数据 ；Uu区域计算平台 路侧 RSU（图 2.11 ： CF

42、）区域计算平台下发区域内数据或业务运营平台给 RSU，实现区域内或区域间的数据共享。CF区域计算平台 路侧通知设备（图 2.11 ： CE）控制指令下发（文字显示指令、声音播报指令等显示当前路面交通状况） 。CE路侧 RSU 车载 OBU （图 2.11 ： FG）路侧 RSU 通过 PC5 接口向周围的交通参与者广播从区域计算中心的得到的数据，OBU 可以选择性地接收数据，进行车辆辅助驾驶。PC5业务运营平台 区域计算平台（图 2.11 ： BC）业务运营平台把其它区域内的 RSU 上报的消息进行下发，实现不同区域 RSU 数据共享。BC路侧边缘计算平台RSU（图 2.11 ： DF）路侧边

43、缘计算平台将标准 v2x 消息发给路侧 RSU，RSU 进行广播给周边的车辆或相邻 RSU。DF区域计算平台 路侧边缘计 算 平 台（ 图 2.11 ： CD）区域计算平台把计算的相关业务数据和设备管控数据下发给路侧边缘计算平台，形成闭环。CD15高速公路车路协同系统的网络架构2.2高速公路车路协同系统的网络架构高速公路车路协同系统的网络可以细分为路段接入网和省干网两部分，网络架构如图 2.2-1所示 ：路段接入网负责把路侧设备、边缘计算单元等设备和路段分中心（区域计算平台）互联； 没有路段分中心的，直接和路段中心（区域计算平台）互连。其中，路侧设备包括 RSU、智能化路侧感知设备（各类摄像头

44、、激光雷达、毫米波雷达等） 、动态交通情报板、路侧气象感知站等，边缘计算单元可通过对路侧设备输出的原始数据信息进行融合判断，提取结构化道路及目标物状态信息，实现数据的分析、处理，以支持车路协同各种应用； 很多车路协同业务在路侧网络完成业务流程，对网络实时性和带宽要求高。 路段接入网的网络架构可能有多种模式，以支持边缘计算单元全分布或相对集中等多种部署方式。 省干网络负责路段分中心间通信互连、路段分中心到路段中心间通信互连、路段中心间通信互连、路段中心至省中心的通信互连、以及省中心与 2C 服务商 /2B 用户间业务通信。路段分中心间，路段分中心到路段中心间的车路协同业务通信有实时性要求。 UU

45、 模式的车路协同信息是通过连接到 2B 用户 （包括运营商）的外联专线来传输的。计算中心内部网络，是标准的云中心网络架构； 与 2C 服务商/2B用户的外联网络为专线网络。 这两种网络类型的需求明确，都已经大量部署，有比较统一的网络方案。 故本文不做进一步网络需求分析。图 2.2-1 车路协同网络架构图全国交通服务中心省级交通业务平台2C服务商/2B用户区域计算平台收费站/服务区边缘计算平台路侧设备全国交通服务中心省级交通服务中心路段接入网路段（分）中心省干网专网气象感知 情报板雷达摄像机RSU路段（分）中心路段（ 分 ） 中心16高速场景车路协同网络需求分析0317车路协同业务内容分析3.1

46、车路协同业务内容分析车路协同业务对网络建设起到导向作用，为了合理归纳网络需求，本小节应用场景选自目前行业认可度较高的业务相关标准，具体为合作式智能运输系统 车用通信系统 应用层及应用数据交互标准 （T/CSAE 53-2020） （下文使用标准代指） 、 合作式智能运输系统 车用通信系统应用层及应用数据交互标准 （T/CSAE 1572020） （下文使用标准代指） 、基于车路协同的高等级自动驾驶数据交互内容 （T/CSAE 1582020） （下文使用标准代指） ， 并将场景分为安全、 效率、信息服务和交通管理四大类，安全类涵盖 7 个业务场景，效率类涵盖 4 个业务场景，信息服务类涵盖 3

47、 个业务场景，交通管理类涵盖 1 个业务场景。针对每个场景，下文从场景定义和业务流两方面进行介绍，其中业务流介绍中列出了实现对应应用场景所需要的主要交互消息，不一定是所有消息，实际实现中，可根据不同的需求和服务水平，使用更多的消息。由于本小节的业务内容是高速车路协同网络建设的需求导向，不涉及 V2V 内容，因此本小节只分析标准、标准和标准中的 V2I 场景和 V2I/V2V 场景中的 V2I 业务内容。本小节每一个应用场景均可通过 PC5 通讯和 Uu 通讯两种方式实现。由于不同业务场景的数据处理需求不同以及设备 / 平台在系统架构中的定位和功能不同，因此根据处理终端不同可划分为以下几种业务流

48、 ：PC5 通讯方式： . 处理终端为路侧感知设备： 目前的感知设备具有简单的数据处理分析功能，当感知设备的处理分析能力可以满足应用场景时，路侧感知设备即为此场景业务流中的数据处理终端。如前方拥堵提醒场景，目前智能摄像机可检测道路拥堵排队长度，摄像机将道路排队长度信息推送至 RSU，RSU 广播 RSI 消息，车辆接收后，车载应用结合自身的定位和行驶数据信息，判断是否进行拥堵提醒。18车路协同业务内容分析Uu 通讯方式： . 处理终端为区域计算平台： 分为 2 种，一种是区域计算平台直接通过感知设备获取结构化感知数据，并将结果数据推送至智能网联车辆。另一种是路侧边缘计算平台实现感知数据融合处理

49、，或再结合智能网联车辆的请求信息，处理生成结果数据并通过区域计算平台将结果数据推送至智能网联车辆。 . 处理终端为区域计算平台 / 业务运营平台： 当只需要收集车辆信息，不需要关联路侧感知设备采集的信息时，平台将预设的消息进行下发或收齐车辆信息进行融合分析，对时延不敏感时，处理终端为业务运营平台。如浮动车数据采集，车辆上报 BSM 信息至业务运营平台，支持平台形成交通状态评估报告。 . 处理终端为路侧边缘计算平台： 当业务场景对时延具有严格要求且需要对感知设备采集的信息进行融合处理时，路侧边缘计算平台为处理终端，既可以满足时延的需求，也可以进行数据融合处理。如协作式变道场景，路侧边缘计算平台根

50、据车辆行驶意图和感知设备采集的信息， 进行融合处理， 生成调度信息并推送至 RSU， RSU 周期性广播 RSC 消息，车辆接收 RSC 消息，车载应用结合自身的定位和行驶数据信息 , 安全行驶。 . 处理终端为区域计算平台： 当业务场景对时延要求不高且需要实现较大范围内的感知与消息广播时，需要以区域计算平台为处理终端。如基于路侧感知的交通状况识别，路侧感知设备（例如摄像头、雷达等）对周边交通状况进行探测，路侧边缘计算平台将处理后的结果数据发送至区域计算平台，平台将数据推送至 RSU，RSU 周期性广播 RAM 消息，车辆接收 RAM 消息，车载应用结合自身的定位和行驶数据信息，判断是否对驾驶

51、员进行提示。 . 处理终端为业务运营平台： 当需要从业务运营平台下发消息支撑应用场景落地或者通过 RSU 收集基本信息，支持信息服务时，处理终端为业务运营平台。需要从业务运营平台下发消息支撑应用场景如车内标牌，业务运营平台下发标志牌信息至 RSU，RSU 广播 RSI 消息，车辆接收后，车载应用判断是否对驾驶员进行提醒。通过 RSU 收集基本信息，支持信息服务的场景如浮动车数据采集，车端周期性广播 BSM 消息，RSU 接收 BSM 消息后上传至业务运营平台，平台进行数据融合处理，进行交通状态分析、事件检测等，为局部或区域的交通管理提供数据支持。3.1.1 安全类应用场景3.1.1.1 限速预

52、警选自标准。智能网联车辆行驶过程中，在超出限定速度的情况下，限速预警 SLW 应用对智能网联车辆驾驶员进行预警，提醒驾驶员减速行驶。业务流：(1) 直连通信方式（PC5） ： . 通过本地配置，RSU 获得 MAP 消息和限速信息（也可以通过平台下发的方式获得）; . RSU 周期性广播 MAP 和 RSI 消息，车辆 OBU 接收消息后， 车载应用结合自身的定位和行驶数据信息分析，如果不满足限速要求，则触发 SLW 预警。RSU智能网联车辆19业务流：(1) 直连通信方式（PC5） ： . 路侧感知设备将感知信息发送给路侧边缘计算平台 ； . 路侧边缘计算平台将处理后的数据发送至 RSU;

53、. RSU 广播 SSM 消息 , 车辆 OBU 接收后，车载应用结合自身的定位和行驶数据信息，制定车辆的行驶策略。123智能网联车辆道路车辆路侧边缘计算平台路侧感知设备RSU(2) 蜂窝通讯方式 (Uu)： . 车辆周期性上报 BSM 信息 ； . 路侧感知设备将感知信息发送至路侧边缘计算平台，平台进行融合计算 ； . 路侧边缘计算平台将处理后的结果数据上报至区域计算平台 ； . 区域计算平台通过 Uu 口对进入范围的车辆推送 SSM 消息，车端接收到后，车载应用结合自身的定位和行驶数据信息，制定车辆的行驶策略。路侧边缘计算平台路侧感知设备3241智能网联车辆道路车辆区域计算平台RSU(2)

54、 蜂窝通讯方式 (Uu)：车辆周期性上报 BSM 信息，平台通过 Uu 口下发 MAP 消息和 RSI消息，车辆 OBU 接收后，获取到限速信息，车载应用结合自身的定位和行驶数据信息分析，如果不满足限速要求，则触发 SLW 预警。业务运营平台智能网联车辆3.1.1.2 基于协同式感知的异常驾驶行为识别选自标准。自动驾驶车辆在真实路况行驶时，如果能提前得知周边存在的异常驾驶的车辆，则可以更好的辅助车辆进行路径的规划。基于协同式感知的异常驾驶行为识别指通过路侧感知设备不断感知周边车辆的运行状况，实时的识别当前范围内所存在的异常行驶的车辆，例如逆行车辆、慢行车辆（行驶速度明显低于其他车辆） 、快行车

55、辆（行驶速度明显高于其他车辆）等，并将感知结果发送给自动驾驶车辆，辅助车辆做出正确的决策控制。20业务流：(1) 直连通信方式（PC5） ： . 路侧感知设备将感知信息传输至路侧边缘计算平台 ； . 路侧边缘计算平台处理生成交通参与者信息或道路异常状况信息 ；并将信息发送至 RSU ； . RSU 广播 SSM 消息，OBU 接收到后结合车载应用判断是否进行预警 / 提示等。123智能网联车辆交通参与者/障碍物路侧边缘计算平台路侧感知设备RSU(2) 蜂窝通讯方式 (Uu)： . 车辆周期性上传车辆 BSM 信息 ； . 路侧感知设备感知到数据上报路侧边缘计算平台， 平台进行融合计算； . 路

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

57、： . 智能网联汽车向 RSU 发送行驶意图信息 VIR ； . RSU 将车辆行驶意图信息发送至路侧边缘计算平台 ； . 路侧感知设备将其感知的信息发送至路侧边缘计算平台 ; . 路侧边缘计算平台综合收集到的信息，进行处理，生成调度信息，发送至 RSU ； . RSU 广播调度信息 RSC，OBU 接收后结合车载应用分析，完成变道或延迟变道。34251智能网联车辆道路车辆路侧边缘计算平台路侧感知设备RSU(2) 蜂窝通讯方式 (Uu)： . 车辆周期性上报 BSM 消息，并上报 VIR 消息至区域计算平台 ； . 区域计算平台将 BSM、VIR 等消息发送至路侧边缘计算平台 ； . 路侧感知

58、设备将感知到的车辆信息发送至路侧边缘计算平台，平台综合感知信息与车辆 BSM、VIR 等消息进行融合计算 ； . 路侧边缘计算平台将处理后的结果数据上报至区域计算平台 ； . 区域计算平台通过 Uu 口发送 RSC 消息至车辆，OBU 接收后结合车载应用分析，完成变道或延迟变道。路侧边缘计算平台路侧感知设备35142智能网联车辆道路车辆区域计算平台3.1.1.5 协作式车辆汇入选自标准。在道路入口匝道处，通过汇聚周边车辆信息进而生成调度信息，协调匝道和主路汇入车道车辆，引导匝道车辆安全、高效的汇入主路。3.1.1.4 协作式变道选自标准。智能网联车辆在行驶过程中需要变道，将行驶意图发送至路侧边

59、缘计算平台或区域计算平台，平台通过路侧感知设备收集道路车辆信息，综合处理生成调度信息发送至车辆，车辆根据自身情况调整驾驶行为，使得智能网联车辆能够安全完成变道或延迟变道。22车路协同业务内容分析(2) 蜂窝通讯方式 (Uu)： . 车辆周期性上传 BSM 消息并上报 VIR 消息至区域计算平台 ； . 区域计算平台将 BSM、VIR 等消息发送至路侧边缘计算平台 ； . 路侧感知设备将感知到的车辆信息发送至路侧边缘计算平台，平台综合感知信息与车辆 BSM、VIR 等消息进行融合计算 ； . 路侧边缘计算平台将处理后的结果数据上报至区域计算平台 ； . 区域计算平台通过 Uu 口下发 RSC 消

60、息至车辆，OBU 接收到后，结合自身行驶状态以及道路信息、周围交通参与者信息，生成最终的驾驶行为策略或轨迹规划，安全有效地通过匝道口。路侧边缘计算平台路侧感知设备35142智能网联车辆道路车辆区域计算平台业务流：(1) 直连通信方式（PC5） ： . 智能网联汽车向 RSU 发送行驶意图信息 VIR ； . RSU 将车辆行驶意图信息发送至路侧边缘计算平台 ； . 路侧感知设备将其感知的信息发送至路侧边缘计算平台 ; . 路侧边缘计算平台综合收集到的信息，进行处理，生成调度信息，发送至 RSU ； . RSU 广播 RSC 消息，车辆的 OBU 接收消息后，结合自身行驶状态以及道路信息、周围交

61、通参与者信息，生成最终的驾驶行为策略或轨迹规划，安全有效地通过匝道口。34251智能网联车辆道路车辆路侧边缘计算平台路侧感知设备RSU3.1.1.6 基于路侧协同的自动驾驶车辆 “脱困”选自标准。正常情况下，自动驾驶车辆在行驶过程中依赖车辆感知设备感知周边环境，并将感知结果作为车辆决策控制的输入，即自动驾驶车辆自身输出决策控制策略，在某些极端情况下，出现自动驾驶车辆无法应对的场景时，自动驾驶车辆停止自动驾驶。自动驾驶车辆发送请求信息，RSU/ 平台下发控制消息，使得车辆 “脱困”23车路协同业务内容分析业务流：(1) 直连通信方式（PC5） ：基于路侧协同规划的自动驾驶车辆 “脱困” . 智能

62、网联汽车向 RSU 发送求助信息 VIR ； . RSU 上报求助信息至路侧边缘计算平台 ； . 路侧感知设备将其感知的信息发送至路侧边缘计算平台 ； . 路侧边缘计算平台处理生成调度信息，发送至 RSU ； . RSU 广播 CIM、RSC 消息，智能网联车辆按调度信息行驶，驶出 “受困”区域。34251智能网联车辆道路车辆路侧边缘计算平台路侧感知设备RSU基于路侧控制的自动驾驶车辆 “脱困” . 智能网联汽车向 RSU 发送求助信息 VIR ； . RSU 上报求助信息至路侧边缘计算平台 ； . 路侧感知设备将其感知的信息发送至路侧边缘计算平台 ； . 路侧边缘计算平台处理生成调度信息，发

63、送至 RSU ； . RSU 广播 CIM、RSCV 消息，智能网联车辆接收后，按引导信息行驶并发送响应消息。34251智能网联车辆道路车辆路侧边缘计算平台路侧感知设备RSU(2) 蜂窝通讯方式 (Uu)：基于路侧协同规划的自动驾驶车辆 “脱困” . 车辆周期性上传 BSM 信息和请求消息 VIR 至区域计算平台 ； . 区域计算平台将 BSM、VIR 等消息发送至路侧边缘计算平台 ； . 路侧感知设备将周围路况信息上传至路侧边缘计算平台，平台综合感知信息与车辆 BSM、VIR 等消息进行融合计算 ； . 路侧边缘计算平台将处理后的结果数据上报至区域计算平台 ； . 区域计算平台综合分析并通过

64、 Uu 口下发 CIM、RSC 消息，智能网联车辆接收后，按引导信息行驶并发送响应消息。路侧边缘计算平台路侧感知设备35142智能网联车辆道路车辆区域计算平台24车路协同业务内容分析基于路侧控制的自动驾驶车辆 “脱困” . 智能网联汽车向区域计算平台发送求助信息 VIR ； . 路侧感知设备将其感知的信息发送至区域计算平台 ； . 路侧感知设备将其感知的信息发送至路侧边缘计算平台，平台综合感知信息与车辆 VIR 等消息进行融合计算 ;； . 路侧边缘计算平台将处理后的结果数据上报至区域计算平台 ； . 区域计算平台通过 Uu 口向车辆发送 CIM、RSCV 消息，智能网联车辆接收后，按引导信息

65、行驶并发送响应消息。路侧边缘计算平台路侧感知设备35142智能网联车辆道路车辆区域计算平台业务流：(1) 直连通信方式（PC5） ：基于路侧协同规划的自动驾驶车辆 “脱困” . 通过业务运营平台下发道路危险状况信息至区域计算平台（区域计算平台也可以通过本地配置的方式得到） ； . 区域计算平台将信息下发至 RSU（RSU 也可以通过本地配置的方式得到）; . RSU 周期性广播 RSI 消息，车辆 OBU 接收 RSI 消息，车载应用结合自身的定位和行驶数据信息，判断是否进行道路危险状况提示。3.1.1.7 道路危险状况提示选自标准。智能网联车辆行驶到潜在危险状况 ( 如前方急转弯等 ) 路段

66、，存在发生事故风险时，道路危险状况提示 HLW 应用对智能网联车辆驾驶员进行预警。123智能网联车辆区域计算平台业务运营平台RSU(2) 蜂窝通讯方式 (Uu)： . 车辆周期性上传车辆 BSM 消息 ； . 平台匹配信息，通过 Uu 口对行车路线上的车辆推送 RSI 消息，车载应用结合自身的定位和行驶数据信息，判断是否进行道路危险状况提示。业务运营平台智能网联车辆25车路协同业务内容分析3.1.1.8 弱势交通参与者碰撞预警选自标准。智能网联车辆在行驶中，与周边道路维修人员、摩托车等弱势交通参与者存在碰撞危险时，弱势交通参与者碰撞预警 VRUCW 应用将对车辆驾驶员进行预警。业务流：(1)

67、直连通信方式（PC5） ： . 路侧感知设备将其感知的信息发送至路侧边缘计算平台 ； . 路侧边缘计算平台将处理后的消息发送至 RSU ； . RSU 广播 RSM 消息，车辆的 OBU 接收后，车载应用结合自身的定位和行驶数据信息进行判断，若存在弱势交通参与者碰撞风险，则对驾驶员进行预警。123智能网联车辆路侧边缘计算平台路侧感知设备RSU弱势交通参与者(2) 蜂窝通讯方式 (Uu)： . 车辆周期性向区域计算平台上报 BSM 信息 ； . 路侧感知设备将感知到的交通参与者信息发送至路侧边缘计算平台，平台进行融合计算 ； . 路侧边缘计算平台将处理后的结果数据上报至区域计算平台 ； . 区域

68、计算平台通过 Uu 口对进入范围的车辆推送 RSM 消息，OBU 接收到后，车载应用结合自身的定位和行驶数据信息进行判断，若存在弱势交通参与者碰撞风险，则对驾驶员进行预警。路侧边缘计算平台路侧感知设备3241智能网联车辆弱势交通参与者区域计算平台3.1.2 效率类应用场景3.1.2.1 前方拥堵提醒选自标准。智能网联车辆行驶前方发生交通拥堵状况，前方拥堵提醒 TJW 应用将对驾驶员进行提醒。由于感知设备（如摄像头）具有交通拥堵检测功能，因此不需要边缘计算单元处理，感知设备可直接将识别结果通过 RSU/ 平台下发车辆，为车辆提供信息服务。26车路协同业务内容分析业务流：(1) 直连通信方式（PC

69、5） ： . 感知设备将拥堵信息发送至 RSU ； . RSU 广播 RSI 消息，车辆 OBU 接收到道路拥堵信息后，根据自身位置判断是否进行预警。12智能网联车辆道路车辆路侧感知设备RSU(2) 蜂窝通讯方式 (Uu)： . 车辆周期性上传 BSM 信息 ； . 感知设备上传拥堵信息至区域计算平台 ； . 平台匹配信息，通过 Uu 口对进入范围的车辆推送道路拥堵信息 RSI，车端接收到消息后结合车载应用分析，判断是否对驾驶员进行预警。路侧感知设备231智能网联车辆道路车辆区域计算平台3.1.2.2 协作式优先车辆通行选自标准。协作式优先车辆通行是指智能交通系统调度交通资源针对优先车辆采取提

70、前预留车道和封闭道路等方式，为优先车辆提供安全高效到达目的地的绿色通道。优先车辆包括警车、消防车、救护车、工程抢险车、事故勘查车等，未来也可以基于该场景提供差异化行车服务。(1) 直连通信方式（PC5） ：提前预留车道 . 智能网联汽车向 RSU 发送车辆基本信息与行驶意图信息 VIR，包括对于前方指定车道进行预留的请求 ； . RSU 上报请求信息至路侧边缘计算平台 ； . 路侧感知设备将其感知的信息发送至路侧边缘计算平台 ; . 路侧边缘计算平台结合请求信息与道路交通信息，处理生成调度信息，发送至 RSU ； . RSU 进行广播 RSC 信息，其他车辆 OBU 接受后结合车载应用安全及时

71、离开预留车道，为优先车辆让行。34251智能网联车辆道路车辆路侧边缘计算平台路侧感知设备RSU27车路协同业务内容分析车道禁行 / 封闭场景处于管制路段处或其上游的 RSU 通过本地配置的方式获取封闭车道或禁行信息，在管制开始前与管制期间，广播此信息，同时可以对特定车辆下发驾驶引导信息 ； 车辆接收 RSU 的车道禁行 / 封闭信息和引导信息 RSC，能够及时、安全地调整驾驶行为，遵循交通管制。RSU智能网联车辆车道禁行 / 封闭场景车辆周期性上传 BSM 信息，在管制开始前与管制期间，区域计算平台 / 业务运营平台向接近和通过该区域的车辆发送封闭车道或禁行信息，同时可以对特定车辆下发驾驶引导

72、信息 RSC，车辆接收到车道禁行 / 封闭信息后，能够及时、安全地调整驾驶行为，遵循交通管制。智能网联车辆区域计算平台/业务运营平台(2) 蜂窝通讯方式 (Uu)：提前预留车道 . 智能网联汽车向区域计算平台发送 BSM 信息与行驶意图信息 VIR，包括对于前方指定车道进行预留的请求 ； . 区域计算平台将 BSM、VIR 等消息发送至路侧边缘计算平台 ； . 路侧感知设备将其感知的信息发送至路侧边缘计算平台，平台综合感知信息与车辆 BSM、 VIR 等消息进行融合计算， 处理生成调度信息 ; . 路侧边缘计算平台将处理后的结果数据上报至区域计算平台 ； . 区域计算平台通过 Uu 口向车辆发

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

74、28车路协同业务内容分析业务流：(1) 直连通信方式（PC5） ： . 感知设备将路况信息上报至路侧边缘计算平台，平台进行融合处理 ； . 路侧边缘计算平台处理后的结果数据上报至区域计算平台 ； . 区域计算平台向相关范围内的 RSU 下发消息 ； . RSU 接收后对外广播 RAM 消息，OBU 接收后结合车载应用制定车辆的行驶策略。路侧边缘计算平台路侧感知设备2143智能网联车辆道路车辆区域计算平台RSU(2) 蜂窝通讯方式 (Uu)： . 车辆周期性上传 BSM 信息 ； . 感知设备将感知到的交通流信息上报至路侧边缘计算平台，平台进行融合计算 ; . 路侧边缘计算平台将处理后的结果数据

75、上报至区域计算平台 ； . 区域计算平台通过 Uu 口下发 RAM 消息至车辆，OBU 接收后结合车载应用制定车辆的行驶策略。路侧边缘计算平台路侧感知设备3241智能网联车辆道路车辆区域计算平台业务流：(1) 直连通信方式（PC5） ： . 业务运营平台下发标志牌信息至区域计算平台（区域计算平台可以通过本地配置的方式得到） ； . 区域计算平台将信息下发至 RSU; . RSU 广播 RSI 消息，车辆 OBU 接收到后结合车载应用判断是否对车辆进行提醒。123智能网联车辆区域计算平台业务运营平台RSU3.1.2.4 车内标牌选自标准。车内标牌 IVS 应用将给予驾驶员相应的交通标牌提示，保证

76、车辆的安全行驶。29车路协同业务内容分析(2) 蜂窝通讯方式 (Uu)：车辆上传 BSM 信息至平台，平台通过 Uu 口下发 RSI 消息，车辆接收到信息后，根据自身车辆位置等相关信息判断是否进行标志牌信息提醒。智能网联车辆区域计算平台/业务运营平台3.1.3.2 场站路径引导服务选自标准。在场站内部区域（如服务区等） ，向进入的车辆提供站点地图信息、车位信息、服务信息等，同时为车辆提供路径引导服务。3.1.3 信息服务类应用场景3.1.3.1 差分数据服务选自标准。利用布设在区域内的基础设施（如 GNSS 基准站，地基增强系统等） ，监测视野内的 GNSS 卫星，通过集中数据处理，分类获得误

77、差改正参数和完好性信息并播发给范围内的车辆，从而使车辆定位精度提升或实现符合一定要求的坐标偏转。业务流：(1) 直连通信方式（PC5） ： . 业务运营平台将差分数据信息发送至区域计算平台（区域计算平台可以通过本地配置的方式得到） ； . 区域计算平台将差分数据信息发送至 RSU ； . RSU 广播 RTCM 消息，车辆 OBU 接收后更新车辆定位数据。123智能网联车辆区域计算平台业务运营平台RSU(2) 蜂窝通讯方式 (Uu)： 平台获得误差改正参数和完好性信息 RTCM 消息，通过 Uu 口对下发给周边车辆，车辆更新定位数据。业务运营平台智能网联车辆30车路协同业务内容分析业务流：(1

78、) 直连通信方式（PC5） ： . 智能网联车辆向 RSU 发送入场 / 离场信息或服务请求消息 VIR（包括自身信息、入场 / 离场请求以及意图信息等） ； . RSU 将相关请求信息发送至路侧边缘计算平台 ； . 路侧感知设备将场站内信息（场站内道路环境、停车信息等）上传至路侧边缘计算平台 ； . 路侧边缘计算平台结合智能网联车辆的请求信息以及路侧感知设备上传的信息，为 RSU 下发场站地图信息（包括场站内地图信息、各类车位信息和服务点信息） ，同时下发路径引导信息 ； . RSU 广播 PAM 消息，车辆 OBU 接收后结合车载应用分析，实现内部路径规划，前往目的地。34251智能网联车

79、辆道路车辆路侧边缘计算平台路侧感知设备RSU(2) 蜂窝通讯方式 (Uu)： . 智能网联车辆通过 Uu 口发送入场 / 离场信息或服务请求 VIR 消息 （包括自身信息、入场 / 离场请求以及意图信息等）至区域计算平台 ； . 区域计算平台将 VIR 等消息发送至路侧边缘计算平台 ； . 路侧感知设备将场站内信息（场站内道路环境、停车信息等）上传路侧边缘计算平台， 平台综合感知信息与车辆 VIR 等消息进行融合计算； . 路侧边缘计算平台将处理后的结果数据上报至区域计算平台 ； . 区域计算平台结合智能网联车辆的请求信息以及路侧感知设备上传的信息，通过 Uu 口为智能网联车辆下发 PAM 消

80、息，包括场站内地图信息、各类车位信息和服务点信息，车辆 OBU 接收后结合车载应用分析，实现内部路径规划，前往目的地。路侧边缘计算平台路侧感知设备35142智能网联车辆道路车辆区域计算平台3.1.3.3 高精地图版本对齐及动态更新选自标准。自动驾驶车辆的安全可靠运行依赖高精度地图的数据，因此要保证自动驾驶车辆能够获得到最新的地图数据。高精地图版本对齐及动态更新可以通过路端对自动驾驶车辆的高精地图进行动态更新，保证车辆能够获取到最新最完整的高精地图数据，为车辆安全可靠运行提供支撑。31车路协同业务内容分析3.1.3.4 道路收费服务选自标准。道路收费服务是指，车辆行进到高速公路的收费区域时，车辆

81、接收路侧发布的收费信息，并通过车路交互完成缴费业务。收费站点部署 V2X RSU 设备，连接后台收费系统，车辆安装 V2X OBU 设备，当车辆进入收费区域，完成相互身份认证后，自动执行收费操作。根据收费体系的发展，此业务场景有待进一步完善、落地。业务流：(1) 直连通信方式（PC5） ： . 通过预先配置的方式 RSU 获取高精度地图信息（也可以通过平台下发获取） ，RSU 广播最新地图版本消息 ； . 车辆 OBU 接收后，比对地图版本信息，版本不一致时，车辆发送更新请求消息至 RSU; . RSU 下发高精度地图数据，OBU 接收到 RAM、CIM 消息后，完成高精度地图更新。RSU智能

82、网联车辆123(2) 蜂窝通讯方式 (Uu)： . 区域计算平台 / 业务运营平台通过 Uu 口下发最新地图版本消息 ； . 车辆 OBU 接收后，比对地图版本信息，版本不一致时，车辆发送更新请求消息 ; . 区域计算平台 / 业务运营平台根据车辆请求消息，下发高精度地图数据，OBU 接收到 RAM、CIM 消息后，完成高精度地图更新。智能网联车辆123区域计算平台/业务运营平台业务流：(1) 直连通信方式（PC5）车辆驶入高速收费路段 ： . RSU-1 对外广播道路收费服务信息，包括支持的收费服务列表及对应的收费信息等 ； . 智能网联车辆进入收费区域，收到 RSU-1 广播的收费服务信息

83、后，确定交互的安全模式和收费服务类型 ； . RSU-1 通过与平台收费系统交互获取交易信息 ； . RSU-1 将交易信息和站点信息等发送给智能网联车辆 ； . 智能网联车辆记录站点信息，并根据消费信息生成收费交易凭证，发送至 RSU-1； . RSU-1 收到智能网联车辆的交易凭证后，向智能网联车辆发送交易结果和驶入提示（不一定进行费用结算） 。RSU-1平台（收费系统）312456智能网联车辆道路收费服务业务流程图 (PC5- 进入收费段 )32车路协同业务内容分析(2) 直连通信方式（PC5）车辆驶出高速收费路段 ： . RSU-2 对外广播道路收费服务信息，包括支持的收费服务列表及对

84、应的收费信息等 ； . 智能网联车辆进入收费区域，收到 RSU-2 广播的收费服务信息后，确定交互的安全模式和收费服务类型 ； . RSU-2 通过与平台收费系统交互获取交易信息 ； . RSU-2 将交易信息和站点信息等发送给智能网联车辆 ； . 智能网联车辆记录站点信息，并根据消费信息生成收费交易凭证，发送至 RSU-2 ； . RSU-2 收到智能网联车辆的交易凭证后，向智能网联车辆发送交易结果和驶出提示。RSU-2平台（收费系统）312456智能网联车辆 道路收费服务业务流程图 (PC5- 出收费段 )业务流：(1) 直连通信方式（PC5） ： . RSU 收集智能网联汽车发送的 BS

85、M 消息、VIR 消息 ； . RSU 将信息发送至区域计算平台 ； . 区域计算平台将信息发送至业务运营平台，平台处理生成交通评估报告。321智能网联车辆区域计算平台业务运营平台RSU3.1.4 交通管理类应用场景3.1.4.1浮动车数据采集选自标准。浮动车数据采集是指，平台通过接收通信范围内车辆发送的信息（包括行驶状态、驾驶意图以及感知信息等） ，进行数据的融合与交通状态分析，形成基于浮动车数据的交通状态评估。(2) 蜂窝通讯方式 (Uu)： 平台接收通信范围内车辆发送 BSM、VIR 信息，形成交通状态评估报告。业务运营平台智能网联车辆33车路协同业务内容分析3.1.5 业务流模型及时延

86、分析本文中的业务总时延指事件发生至智能网联汽车端接收并处理完成的时间。目前行业相关部门组织等（包括 5GAA、3GPP 等）未制定总时延量化指标，因此下文侧重介绍各模型的总时延计算方法，后续各地实际部署业务中可根据此计算方法和总时延、处理时延等对各层网络时延提出要求。根据不同业务，场景数据流模型分为以下几种。3.1.5.1 PC5 通讯方式选自标准。自动驾驶车辆的安全可靠运行依赖高精度地图的数据，因此要保证自动驾驶车辆能够获得到最新的地图数据。高精地图版本对齐及动态更新可以通过路端对自动驾驶车辆的高精地图进行动态更新，保证车辆能够获取到最新最完整的高精地图数据，为车辆安全可靠运行提供支撑。 3

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

88、至 RSU传输时延 BRSU 广播传输时延处理时延A路侧感知设备处理时延 BRSU处理时延 C智能网联车辆12智能网联车辆道路车辆路侧感知设备RSURSU智能网联车辆此数据流模型的总时延为：总时延 = 传输时延RSU 广播传输时延处理时延 智能网联车辆（A）不需要感知设备等参与，由 RSU 事先配置好信息，直接下发至智能网联车辆的流量模型如下。该模型涉及的主要场景为限速预警、协作式优先车辆通行。34车路协同业务内容分析 3.1.5.1.2. 处理终端为路侧边缘计算平台由路侧边缘计算平台完成计算的数据流模型分为下列两种。（A）路侧感知设备将感知到的信息发送至路侧边缘计算平台，边缘计算进行融合处理

89、后将消息通过 RSU 广播至智能网联汽车。涉及的主要场景主要有基于协同式感知的异常驾驶行为识别、感知数据共享。根据感知的目前物是道路车辆、弱势交通参与者、交通参与者 / 障碍物不同可分为如下三种模型。三种模型的时延分析相同。123智能网联车辆道路车辆路侧边缘计算平台路侧感知设备RSU123智能网联车辆交通参与者/障碍物路侧边缘计算平台路侧感知设备RSU123智能网联车辆弱势交通参与者路侧边缘计算平台路侧感知设备RSU此数据流模型的总时延为：总时延 = 传输时延 A路侧感知设备至路侧边缘计算平台传输时延 B路侧边缘计算平台至 RSU传输时延 CRSU 广播传输时延处理时延 A路侧感知设备处理时延

90、 B路侧边缘计算平台处理时延 CRSU处理时延 D智能网联车辆（B）需要智能网联车辆发送特定的请求信息，路侧感知设备将感知到的信息发送至路侧边缘计算平台，边缘计算进行融合处理后将消息通过 RSU 广播至智能网联汽车。涉及的主要场景主要如下表。序 号应用场景1协作式变道2协作式车辆汇入3基于路侧协同的自动驾驶车辆“脱困”4场站路径引导服务5协作式优先车辆通行34251智能网联车辆道路车辆路侧边缘计算平台路侧感知设备RSU此数据流模型的总时延为：总时延 =MAX（传输时延 AOBU 至 RSU传输时延 BRSU 至路侧边缘计算平台处理时延 CRSU，传输时延 C路侧感知设备至路侧边缘计算平台处理时

91、延 A路侧感知设备）传输时延 D路侧边缘计算平台至 RSU传输时延 ERSU 广播传输时延处理时延 B路侧边缘计算平台处理时延 CRSU处理时延 D智能网联汽车注：路侧边缘计算平台通过 RSU 获取车辆信息和通过路侧感知设备获取路侧信息可同时进行，因此模型总时延此部分取较大者。35车路协同业务内容分析 3.1.5.1.4. 处理终端为业务运营平台该模型主要分为 2 种数据流模型。（A）数据流由车端到平台端。主要应用场景为浮动车数据采集。 3.1.5.1.3. 处理终端为区域计算平台当业务场景对时延要求不高且需要实现较大范围内的感知与消息广播时，需要以区域计算平台为处理终端。涉及的主要场景有基于

92、路侧感知的交通状况识别，路侧感知设备（例如摄像头、雷达等）周期性对周边的交通状况进行探测，感知数据发送至区域计算平台进行处理，处理后的数据推送至 RSU，RSU 周期性广播 RAM 消息，车辆的 OBU 接收 RAM消息，车载应用结合自身的定位和行驶数据信息，对驾驶员进行提示。路侧边缘计算平台路侧感知设备2143智能网联车辆道路车辆区域计算平台RSU此数据流模型的总时延为：总时延 = 传输时延 A路侧感知设备至路侧边缘计算平台传输时延 B路侧边缘计算平台至区域计算平台传输时延 C区域计算平台至 RSU传输时延 DRSU 广播传输时延处理时延 A路侧感知设备处理时延 B路侧边缘计算平台处理时延

93、C区域计算平台处理时延 CRSU处理时延D智能网联车辆序 号应用场景1道路危险状况提示2高精地图版本对齐及动态更新3差分数据服务4车内标牌此数据流模型的总时延为：总时延 = 传输时延 AOBU 至 RSU传输时延 BRSU 至区域计算平台传输时延 C区域计算平台至业务运营平台处理时延 ARSU处理时延 B区域计算平台321智能网联车辆区域计算平台业务运营平台RSU此数据流模型的总时延为：总时延 = 传输时延 A业务运营平台至区域计算平台 传输时延 B区域计算平台至 RSU传输时延 CRSU 广播处理时延 A区域计算平台处理时延 BRSU处理时延 C智能网联车辆123智能网联车辆区域计算平台业务

94、运营平台RSU36车路协同业务内容分析3.1.5.2 Uu 通讯方式 3.1.4.2.1. 处理终端为区域计算平台（A）智能网联汽车周期性上报数据至区域计算平台，感知设备上传处理后的感知信息至区域计算平台，平台将消息下发至智能网联车辆。因感知设备的数据处理能力满足场景应用需求，不需要经过路侧边缘计算平台。涉及的场景主要是前方拥堵提醒。路侧感知设备231智能网联车辆道路车辆区域计算平台此数据流模型的总时延为：总时延 = 传输时延 A路侧感知设备至区域计算平台传输时延 B区域计算平台至车辆处理时延 A路侧感知设备处理时延 B区域计算平台处理时延 C智能网联车辆序 号应用场景1弱势交通参与者碰撞预警

95、2基于协同式感知的异常驾驶行为识别3感知数据共享4基于路侧感知的交通状况识别（B）智能网联汽车周期性上报数据至区域计算平台， 感知设备上传感知信息至区域计算平台， 平台汇聚信息完成处理，处理结果信息下发至智能网联车辆。涉及的主要场景如下表。根据感知的目前物是道路车辆、弱势交通参与者、交通参与者 / 障碍物不同可分为如下三种模型。三种模型的时延分析相同。37车路协同业务内容分析路侧感知设备231智能网联车辆道路车辆区域计算平台路侧感知设备231智能网联车辆区域计算平台弱势交通参与者路侧感知设备231智能网联车辆交通参与者/障碍物区域计算平台此数据流模型的总时延为：总时延 = 传输时延 A路侧感知

96、设备至路侧边缘计算平台传输时延 B路侧边缘计算平台至区域计算平台+ 传输时延 C区域计算平台至车辆处理时延 A路侧感知设备处理时延 B路侧边缘计算平台+ 处理时延 C区域计算平台处理时延 D智能网联车此数据流模型的总时延为：总时延 =MAX（传输时延 AOBU 至区域计算平台传输时延 B区域计算平台至路侧边缘计算平台处理时延 C区域计算平台，传输时延 C路侧感知设备至路侧边缘计算平台处理时延 A路侧感知设备）传输时延 D路侧边缘计算平台至区域计算平台传输时延 E区域计算平台至车辆处理时延 B路侧边缘计算平台处理时延 C区域计算平台处理时延 D智能网联汽车（C）智能网联汽车周期性上报请求信息至区

97、域计算平台，区域计算平台下发消息至路侧边缘计算平台，感知设备上传信息至路侧边缘计算平台，路侧边缘计算平台结合车辆请求信息和路侧感知信息进行处理，结果通过区域计算平台下发至智能网联车辆。涉及的主要场景如下表。序 号应用场景1协作式变道2协作式车辆汇入3基于路侧协同的自动驾驶车辆“脱困”4协作式优先车辆通行5场站路径引导服务路侧边缘计算平台路侧感知设备35142智能网联车辆道路车辆区域计算平台注：路侧边缘计算平台通过区域计算平台获取车辆信息和通过路侧感知设备获取路侧信息可同时进行，因此模型总时延此部分取较大者。38车路协同业务内容分析此数据流模型的总时延为：总时延 = 传输时延 A车端至区域计算平

98、台 / 业务运营平台 3.1.5.2.2. 处理终端为区域计算平台 / 业务运营平台（A）数据流由车端到平台端。主要应用场景为浮动车数据采集。智能网联车辆区域计算平台/业务运营平台（C）数据流由平台端到车端。 涉及的主要场景如下表。此数据流模型的总时延为：总时延 = 传输时延 A区域计算平台 / 业务运营平台至车端序 号应用场景1差分数据服务2车内标牌3限速预警4道路危险状况提示5协作式优先车辆通行智能网联车辆区域计算平台/业务运营平台此数据流模型的总时延为：总时延 =2传输时延车端至区域计算平台 / 业务运营平台至车端传输时延车端至区域计算平台 / 业务运营平台处理时延 A车端至区域计算平台

99、 / 业务运营平台处理时延 B智能网联车辆（B）数据流需要在车端与平台端之间交互多次。 主要应用场景为高精地图版本对齐与动态更新。智能网联车辆123区域计算平台/业务运营平台39车路协同业务部署场景分析3.2车路协同业务部署场景分析本研究中车路协同业务部署场景按照高速公路组成要素，分为一般路段、主线隧道、收费站互通、枢纽互通、服务区5 大场景，其中一般路段场景涵盖长直路段、桥梁、弯道、上下坡等路段。各场景部署方案中的设备布设间距根据目前市场上视频、雷达的检测范围按照常规情形进行示例，实际项目可根据具体业务需求及设备性能进行调整。主线隧道服务区一般路段段收费站互通枢纽互通40车路协同业务部署场景

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

101、前方低能见度提醒、前方路面结冰提示 ； . 交通事件提醒 ： 前方交通拥堵、交通事故、道路抛洒、占道施工提醒 ； . 车道级限速提醒及行车引导 ： 分车道限速提醒、客货车通行车道提醒、车道通行状态提醒。 . 信息服务： 前方服务区、收费站、停车场提醒。3.2.1.2 部署方案 方案一： 路侧部署 感知设备部署双幅 6 车道及以下高速公路，双侧对等按 400 米间隔布设 2 台高清摄像机、1 对毫米波雷达。其中，2 台高清摄像机分别对准来车和去车方向，毫米波雷达的监测范围不小于 200 米范围。双幅 8 车道及以上高速公路，双侧对等按 400 米间隔布设 4 台高清摄像机、1 对毫米波雷达。其中

102、 2 台高清摄像机对准来车方向、2 台高清摄像机对准去车方向、毫米波雷达的监测范围不小于 200 米范围。 通信设备部署RSU 按双侧 Z 字形，单侧间距 800 米设置 1 个 RSU。 边缘计算设备部署双侧对等按 800 米间隔布设 1台边缘计算设备，可满足同时接入至少 8 台摄像机、4 台毫米波雷达的性能需求。 控制与诱导设施部署网联化车辆安装 OBU 接收 RSU 或中心发布交通控制与诱导信息。通过可变信息情报板、导航软件、小程序等多样化手段，将辅助通行信息及时发布给非网联车辆。一般路段按间隔不大于 5KM 间隔设置门架式可变情报板。123441车路协同业务部署场景分析图 3.2-1

103、双向 6 车道及以下双侧部署示意图图 3.2-2 双向 8 车道及以上双侧部署示意图 方案二： 中央分隔带部署 感知设备部署双幅 6 车道及以下高速公路，中央分隔带按 400 米间隔布设 4 台高清摄像机、1 对毫米波雷达。其中，2 台摄像机对准一侧道路的来车和去车方向，2 台摄像机对准另一侧道路的来车和去车方向，毫米波雷达的监测范围不小于 200 米半径范围。双幅 8 车道及以上高速公路，中央分隔带按 400 米间隔布设 8 台高清摄像机、1 对毫米波雷达。其中，每 2 台摄像机分别对准双侧道路的来车和去车方向，毫米波雷达的监测范围不小于 200 米半径范围。 通信设备部署中央分隔带按 40

104、0 米设置 1 个 RSU，RSU 满足半径 400 米的通信范围。 边缘计算设备部署双向 6 车道及以下，中央分隔带按 800 米间隔布设 1台边缘计算设备，可满足同时接入至少 8 台摄像机、4 台毫米波雷达的性能需求。双向 8 车道及以上，中央分隔带按 400 米间隔布设 1台边缘计算设备， 控制与诱导设施部署网联化车辆安装 OBU 接收 RSU 或中心发布交通控制与诱导信息。通过可变信息情报板、导航软件、小程序等多样化手段，将辅助通行信息及时发布给非网联车辆。一般路段按间隔不大于 5KM 间隔设置门架式可变情报板。1234400米400米400米双向6车道以内400米400米400米双向

105、8车道及以上42车路协同业务部署场景分析图 3.2-3 双向 6 车道及以下中央分隔带部署示意图图 3.2-4 双向 8 车道及以上中央分隔带部署示意图13.2.2 主线隧道3.2.2.1 场景描述由于隧道路段运营环境特殊，一旦隧道洞内发生事故，存在车流疏散困难、救援难度大等问题，将影响路段甚至整个路网的运营效率。同时，由于隧道出入洞口段为光线突变段，行驶通过该段时，驾驶员的视觉生理反应需要消耗时间，产生 “白洞效应”和 “黑洞效应” ， 导致出入口附近的交通事故频发。本场景基于车路协同技术实现车辆在隧道前、 隧道中、隧道后的全过程安全预警及诱导服务，重点减少由于隧道黑白洞效应引发的交通事故，

106、同时实现洞内事故提前告知功能。根据合作式智能运输系统 + 车用通信系统应用层及应用数据交互标准 ，结合高速公路实际情况，隧道安全预警及诱导服务实现的功能主要包括： 隧道内安全预警隧道内火灾提示预警、隧道内抛洒物提醒、前方施工占道提醒、隧道内拥挤提示、隧道内交通事故提醒、隧道内应急车道被占提示等。 隧道出 （入）口安全预警隧道出（入）口交通事故提醒、隧道出（入）口违停提醒。 隧道限速相关提醒驶入 （出）隧道提醒、限速提醒、违法抓拍提醒。23双向8车道以内400米400米400米400米400米400米双向6车道以内43500米500米150米150米150米150米150米150米500米500

107、米150米150米150米150米150米150米车路协同业务部署场景分析3.2.2.2 部署方案由于隧道与前后相接路段的关联性强，通常将隧道洞外 500 米范围的路段划入隧道管控区域，统一部署感知、通信及边缘计算等设备。隧道视外场点位分布情况， 组建多个现场接入网（目前多为光纤环网） ， 实现感知、 通信等设备与边缘计算设备的互联。现场接入网传输带宽、网络时延、可靠性等指标应满足车路协同业务场景要求。 感知设备部署(1) 隧道洞外路段感知设备部署原则同 “一般路段” ，紧密结合前后路段点位设置情况，确保洞口区域感知的全覆盖。(2) 隧道洞内路段部署方式一：隧道洞内路段按不大于200米间隔 （

108、曲线段适当加密） 布设感知点位， 每个点位配置1台高清摄像机和1套毫米波雷达，毫米波雷达监测范围不小于 200 米范围，每个感知点位实现隧道洞内 150 米路段信息感知全覆盖。边缘计算有两种部署方式 ： 分布式（如图 3.2-5）和集中式（如图 3.2-6） 。图 3.2-5 部署方式一（分布式边缘计算）示意图图 3.2-6 部署方式一（集中式边缘计算）示意图144500米500米200米200米200米200米200米200米500米500米200米200米200米200米200米200米车路协同业务部署场景分析图 3.2-7 部署方式二（分布式边缘计算）示意图图 3.2-8 部署方式二（集

109、中式边缘计算）示意图 部署方式二隧道洞内路段按不大于 400 米间隔（曲线段适当加密）布设感知点位，每个点位配置 2 台高清摄像机和 2 套毫米波雷达，分别对准上下行方向，毫米波雷达监测范围不小于 200 米范围，每个感知点位实现隧道洞内 300 米路段信息感知全覆盖。边缘计算有两种部署方式 ： 分布式（如图 3.2-7）和集中式（如图 3.2-8） 。 通信设备部署(1) 隧道洞外路段通信设备部署同原则 “一般路段” ， 紧密结合前后路段点位设置情况， 确保洞口区域通信的全覆盖。 隧道洞口路段按照 “一般路段”进行部署。(2) 隧道洞内路段 部署方式一：RSU 按照 300 米间距，与视频监

110、控点位同址部署，每处点位设置 1 个 RSU，RSU 通信范围不小于 300 米半径范围。 部署方式二：RSU 按照 400 米间距，与视频监控点位同址部署，每处点位设置 1 个 RSU，RSU 通信范围不小于 400 米半径范围。 边缘计算设备部署隧道及相接洞外路段应作为一个区域，进行集中管控，原则上部署 1 套边缘计算设备，支持全域业务数据的协同计算分析。若因隧道太长，设备太多，可部署多套边缘计算设备，并采用强协同工作模式。边缘计算设备可依托隧道洞口或洞内变电所设置，具备支持区域内所有感知、通信等的接入能力。1km 及以上隧道，边缘计算设备宜采用设备级的硬件容错机制，例如 ： 双机热备 ；

111、 3km 及以上隧道，边缘计算设备应采用站点级的系统容错机制，例如 ： 双活机房。2345车路协同业务部署场景分析 控制与诱导设施部署网联化车辆安装 OBU 接收 RSU 或中心发布交通控制与诱导信息。通过可变信息情报板（利旧） 、导航软件等智能化手段，将隧道状态信息及时发布给非网联车辆，实现隧道场景事件的预警与诱导服务。 隧道时钟同步需求V2X 设备 RSU 和 OBU 的正常通信需要设备保持时钟同步。当前，RSU 和 OBU 主要是通过 GNSS 信号来保持时钟同步的。但隧道场景内无 GNSS 信号，不能依赖 GNSS 信号实现时间同步。为了实现 V2X 设备间的正常通信，需要网络来为 R

112、SU 和 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 之间正常通信的同步需求前提下，进一步考虑多径时延、信号传播

113、时延、RSU 自身时间误差、OBU 从 RSU 获得同步时钟的误差等因素的影响，故会高于 LTE-V2X 通信自身的同步精度要求（作为参考，LTE-TDD 时钟同步要求是1.5us） ，但具体的经验数值有待在实践中提出并予以验证。 隧道内定位设施隧道洞内部署定位设施，采用车辆辅助定位或路侧主动定位方式，实现满足车路协同的高精度定位功能。可参照基于移动通信网的高精度定位总体技术要求 （YD/T 3936-2021） 、3GPPTR22.872v16.1.0。3.2.3 收费站互通3.2.3.1 场景描述收费站互通是连接高速公路与地方普通公路或城市道路的落地互通，由于主线和匝道的车速差异大、变道行

114、为多、变道窗口期短、驾驶员视野受限等原因，容易产生违法驾驶行为，从而容易发生交通事故、降低通行效率。456图 3.29 隧道同步通信示意图RSU ARSU BRSURSU通信业务隧道PC5 空口同步PC5 空口同步车B车A46车路协同业务部署场景分析本场景通过建设基于车路协同的安全预警及诱导系统，对分合流区域过往车辆进行预警提醒，尽量避免主线车辆与匝道车辆的碰撞事故发生。根据合作式智能运输系统 + 车用通信系统应用层及应用数据交互标准 ，结合高速公路实际情况，本场景安全预警及诱导服务实现的功能主要包括： 合流区安全预警右侧匝道车辆汇入提醒、左侧主线车辆行驶提醒、合流区域交通事故提醒、合流区域下

115、游主线交通拥挤程度提醒 ； 分流区安全预警左侧车辆变道提醒、前方车辆慢行提醒、前方车辆停车提醒、前方车辆逆行提醒 ； 收费车道运行状态提醒出（入）口收费车道排队长度或时长提醒、出（入）口车道开关闭状态提醒 主线及匝道信息远端诱导收费站前的主线及匝道限速信息提醒、主线及匝道的交通拥挤情况提醒。衔接普通道路运行状态提醒，相邻普通道路交通运行状态提醒。3.2.3.2 部署方案由于收费站互通与前后相接路段的关联性强，通常将互通前后 2km 范围的路段划入收费站互通管控区域，统一部署感知、通信及边缘计算等设备。现场接入网传输带宽、网络时延、可靠性等指标应满足车路协同业务场景要求。 感知设备部署以分流鼻或

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

117、变情报板或通过 APP 向非网联车辆发布交通状况、交通事件信息。车路协同业务部署场景分析3.2.4 枢纽互通3.2.4.1 场景描述枢纽互通是不同高速公路相交位置，实现不同高速公路上的车辆转换。枢纽互通在分合流交织区域易发生车辆碰撞、违规变道、车辆违停、车辆逆行等违规行为。本场景通过建设基于车路协同的分合流安全预警及诱导系统，对分合流区域过往车辆进行预警提醒，尽量避免主线车辆与匝道车辆的碰撞事故发生。根据合作式智能运输系统 + 车用通信系统应用层及应用数据交互标准 ，结合高速公路实际情况，分合流安全预警及诱导服务实现的功能主要包括： 合流区安全预警右侧匝道车辆汇入提醒、左

118、侧主线车辆行驶提醒、合流区域交通事故提醒、合流区域下游主线交通拥挤程度提醒 ； 分流区安全预警左侧车辆变道提醒、前方车辆慢行提醒、前方车辆停车提醒、前方车辆逆行提醒 ； 主线及匝道信息服务主线及匝道限速信息提醒、道路施工提示。3.2.4.2 部署方案由于枢纽互通与前后相接路段的关联性强，通常将枢纽互通 1km 半径范围内的路段划入枢纽互通管控区域，统一部署感知、通信及边缘计算等设备。 感知设备部署以分流鼻或合流鼻顶点为基准点，主线上游 125m 左右立杆，布设高清摄像机及毫米波雷达，感知主线车道分合流鼻顶点前后至少各100m 米范围内的交通状况及交通事件。 通信设备部署互通前后门架布中央各设

119、1台 RSU，向半径 400 米范围内的网联车辆发布交通状况及交通事件。12312图 3.2-9 收费站互通部署示意图检测范围200m检测范围200m125m125m125m检测范围200m检测范围200m125m48 边缘计算设备部署每个互通依托收费站布设一台边缘计算服务器，可满足同时接入至少 8 台摄像机、4 台雷达的性能需求。同时互通及相接路段应作为一个区域，部署的边缘计算还应同时支持全域业务数据的协同计算分析。 控制与诱导设施部署网联化车辆安装 OBU 接收 RSU 或中心发布交通控制与诱导信息。选择性地在分合流的起点或终点设置可变情报板或通过 APP 向非网联车辆发布交通状况、交通事

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

121、辆停车提醒、前方车辆逆行提醒 ； 服务区信息提醒服务区停车位提醒、卫生间侧位提醒、人流量提醒等。 主线交通运行状态提醒出口下游主线路段交通拥挤程度提醒、应急车道停车提醒、限速提醒等。车路协同业务部署场景分析34检测范围200m检测范围200m检测范围200m125m125m检测范围200m125m125m图 3.2-10 枢纽互通部署示意图123449车路协同业务部署场景分析3.2.5.2 部署方案除特殊情况，服务设施一般按照上下行方向划为两个独立的管控区域，分别考虑。另外，由于服务设施与前后相接路段的关联性强，通常将服务设施 2km 半径范围内的路段划入服务设施管控区域，统一部署感知、通信及

122、边缘计算等设备。现场接入网络组建原则同 “收费站互通” 。 感知设备部署以分流鼻顶点为基准点，主线上游 125m 左右立杆，布设 2 台高清摄像机及1台毫米波雷达，感知主线车道分流鼻顶点前后至少各100m 米范围内的交通状况及交通事件。以合流鼻顶点为基点，主线下游 125m 左右立杆，布设 2 台高清摄像机及1台毫米波雷达，感知主线车道合流鼻顶点前后至少各100m 米范围内的交通状况及交通事件。 通信设备部署服务区出入口复用交安标志杆件，各设 1台 RSU，向半径 400 米范围内的网联车辆发布交通状况及交通事件。 边缘计算设备部署服务设施及相接路段应作为一个区域，进行集中管控，原则上两侧服务

123、（停车）区各部署 1 套边缘计算设备，支持全域业务数据的协同计算分析。边缘计算设备可依托服务设施管理用房设置， 具备支持区域内所有感知、 通信等的接入能力。 控制与诱导设施部署网联化车辆安装 OBU 接收 RSU 或中心发布交通控制与诱导信息。选择性地在分合流的起点或终点设置可变情报板或通过 APP 向非网联车辆发布交通状况、交通事件信息。1234服务区服务区检测范围200m检测范围200m检测范围200m检测范围200m125m125m125m125m图 3.2-11 服务区部署示意图50路段接入网需求分析基于对车路协同业务的流量模型和通信需求分析、业务部署方案分析，本节主要从网络架构、网络

124、功能和网络性能三方面，就车路协同业务对路段接入网的需求进行分析和小结。3.3路段接入网需求分析图 3.3-1 路段接入网架构图3.3.1 路段接入网的总体架构路段接入网负责把路侧设备、边缘计算等设备和路段分中心（区域计算平台）互联 ；没有路段分中心的，直接和路段中心 （区域计算平台） 互连， 网络架构如图 3.3-1 所示。在路段接入网中，最关键部分是以边缘计算为核心的路侧网络。如图 3.3-2 所示，边缘计算和相关的路侧设备构成了一个相对独立的车路协同边缘计算域，完成感知融合计算和车路协同信息的实时发送，路侧网络有比较高的实时性和大带宽需求。边缘计算路侧设备雷达情报板气象感知RSU摄像机路段

125、接入网图 3.3-2 车路协同的路侧网络路段中心/路段分中心收费站/服务区边缘计算雷达情报板气象感知RSU摄像机区域计算平台路段接入网51路段接入网需求分析3.3.2 路段接入网的功能要求 路段 1-1 路段接入网需要支持边缘计算的各种部署模式边缘计算有多种部署模式， 有分布部署到各杆站， 有相对集中到通信机房和隧道变电机房等， 有部署边缘计算备份的，有独立逻辑业务区的边缘计算。 路段接入网需要保证边缘计算各种部署模式下，都能满足车路协同业务的通信带宽和延迟要求，保证网络安全，流量无绕行。 路段 1-2 路段接入网需要具备良好的扩展性，支持分路段、分步骤逐步建设 ；高速公路车路协同业务一般是统

126、一规划，分路段逐步建设，或分区域（关键区域先建，其它区域后续补充建）逐步建设。路段接入网需要满足扩展性建设需求，新建网络不影响原有网络，新建网络和原有网络可以融合为一个网络系统。 路段 1-3 路段接入网需要满足多个业务设备间各种通信要求，具备灵活通信能力；车路协同系统的路侧设备和计算单元等设备间有比较复杂的业务流通信，而且业务场景和业务实现的变化也会导致通信方式的变化，因此要求路段接入网能按业务需求，灵活地和快速地支持任何设备间的通信需求，以及新增设备的通信要求。 路段 1-4 路段接入网需要具备多业务承载能力车路协同系统中的视频流、车路协同消息、设备管理信息等有不同的网络需求和安全隔离要求

127、，路段接入网需要能按各业务要求提供多业务承载和业务隔离。3.3-1 业务流的 QoS 等级建议表优先级业务流补充说明高优先级 1设备管理流业务平台管理路侧设备和网络设备的管理业务流高优先级 2车路协同消息边缘计算处理后的结构化数据高优先级 3传到边缘计算的融合感知流（大流量）在路侧网络中，摄像头、雷达、传感器、信号灯等传送到边缘计算处理的数据流中优先级 1电子信号板信息信息发布，主要是给人看的低优先级（Best Effort）上传到路段中心云里备份的融合感知流（大流量）路段接入网要确保高优先级的业务流不会被低于其优先级的业务流影响传输质量。 路段 1-5 路段接入网需要具备冗余保护能力，支持链

128、路级、设备级保护；车路协同信息需要高可靠传输， 需要路段接入网能有 （单次或多次）断纤通信保护能力， 通信设备的单点故障保护能力。 路段 1-6 路段接入网设备应支持各类设备接入端口及协议需要。52路段接入网需求分析路侧通信设备需要和路侧设备、传感器等互联，需要支持 GE 电口、GE 光口、RS485、RS422、RS232、RJ45 等接口，并支持 POE 供电 ； 通信设备按需支持 10GE、25GE、50GE、100GE 等接口，做网络设备互联组网。路侧通信设备需支持所连传感器的物联协议接入，如当前路面传感器、能见度传感器和气象传感器采用 ModBus，Serial/TCP 等协议。 路

129、段 1-7 路段接入网设备在某些场景下，需要满足终端设备高精度时间同步要求，支持部署 PTP 协议 ；RSU 和激光雷达等设备需要高精度时间同步，一般是通过 GNSS 和网络来进行时间同步。在隧道等没有 GNSS 信号的场景中，RSU 只能通过网络来保持时间同步 ( 详见 3.2.2)。 路段 1-8 路段接入网应支持 IPv6 部署，并具备 IPv6 Only 演进能力。 IPv4 地址已经枯竭，网络向 IPv6 演进是必然方向，也是国家发展战略。交通行业是国家重点推进 IPv6 战略的 17个重点行业之一。2021 年 7 月中央网信办、国家发改委、工信部联合发布关于加快推进互联网协议第六

130、版（IPv6）规模部署和应用工作的通知 ，计划到 2025 年网络要大规模部署 IPv6 Only，2030 年全网演进到 IPv6 Only。因此路段接入网需要支持 IPv6 设备和业务，具备全网平滑演进到 IPv6 Only 的能力。3.3.3 路段接入网性能要求 路段 2-1 路段路侧通信网络应满足路侧摄像机、雷达、传感器、边缘计算等设备通信带宽要求 ；在网络设计时，按各设备带宽要求和网络结构计算总带宽需求，并且在保护倒换时也能保证关键业务的带宽需求。路侧网络的带宽需求，应基于各部署场景的所有设备带宽需求来计算，详见 3.2 节。 路段 2-2 路段接入网需要满足车路协同业务延迟要求 ；

131、路侧网络中，边缘计算和 RSU 间，摄像头、雷达和边缘计算间通信延迟满足业务段到段延迟要求，具体延迟计算公式详见 3.1.2 节； 路段 2-3 路段接入网需要满足车路协同高可靠性要求 ；单链路故障和任意单点设备故障的业务的中断时间小于 200ms，网络可靠性满足 99.999% 要求 ； 路段 2-4 路段接入网应具备 1K-10K 级节点部署和网络管理能力；路段接入网的规模和高速公路的长度正相关。 路段 2-5 路侧通信网络设备应支持室外部署，工作温度范围 -4065 度。路侧网络设备一般是部署在室外，需要按室外安装运维要求设计。53车路协同业务对省干网络需求分析3.4车路协同业务对省干网

132、络需求分析本节主要从总体架构、功能要求和性能要求三个方面，就车路协同业务对省干网络的需求进行分析。3.4.1省干网络的总体架构省干网络负责省中心、路段中心、路段分中心以及 2C 服务商 /2B 用户的互连，具体包括路段中心间通信互连、路段中心至省中心的通信互连、路段分中心间通信互连、路段分中心至省中心的通信互连、以及省中心与 2C 服务商 /2B 用户间业务通信。省干网络的总体架构如图 3.4.1 所示。全国交通服务中心省级交通业务平台2C服务商/2B用户区域计算平台路段（分）中心路段（分）中心路段（分）中心省干网全国交通服务中心省级V2X服务中心专网图 3.4-1 省干网络总体架构图3.4.

133、2 省干网络的功能要求 省干1-1 应具备综合业务承载能力，支持承载收费业务、监控业务和车路协同业务等多种业务。车路协同系统中的收费业务、监控业务、车路协同业务等有不同的网络需求和安全隔离要求，省干网需要能按各业务要求提供多业务承载和业务隔离。54车路协同业务对省干网络需求分析 省干 1-2 应具备快速保护倒换能力。省干网络应能提供端到端和局部的网络保护，实现对链路故障和中间节点故障的保护，应能提供与业务网络的对接保护，包括双归保护、双节点冗余保护等。省干网络所承载的业务比较重要，应具备快速保护倒换能力，避免因链路故障和中间节点故障导致的业务中断。并应实现业务 50ms 以内的保护倒换。 省干

134、1-3 扩展性强，既能满足现有业务需要，同时能够支撑未来业务发展。为满足当前高速公路收费系统、监控系统和办公系统等业务系统的承载需要，特别是满足包含车路协同业务在内的智慧高速业务承载要求，同时考虑到业务的持续演进发展，需要建设一张能满足现有业务需要，同时支撑未来业务发展的承载网络。 省干1-4 应具备 OAM（Operations and Maintenance）机制，具备统一管控、业务质量可视、故障智能定位、性能监测和智能运维等功能。多个业务系统的承载网络独立运维，维护成本高，因此省干网络应具备统一管控，业务质量可视，故障智能定位，实现智能运维。 省干1-5 应具有 QOS（Quality

135、of Service）机制。省干网要确保高优先级的业务流不会被低于其优先级的业务流影响传输质量，用来解决网络延迟和阻塞等问题。 省干1-6 应提供完善的网管系统， 采用图形化界面实现拓扑管理、 配置管理、 故障管理、 性能管理、 安全管理等功能；并可通过北向接口与上层网管系统相连。用以保障网络系统能够正常、高效运行，使网络系统中的资源得到更好的利用。 省干1-7 具备全网时间同步功能。省干网络所有设备统一时间信息，便于网络监测和管理。 省干1-8 应支持 IPv6 部署。省干网络应具备 IPv6 Only 网络演进能力。IPv4 地址已经枯竭，网络向 IPv6 Only 演进是必然方向，也是国

136、家发展战略。IPv6 Only 网络，适合长期演进和大规模部署，符合车路协同对省干网络的发展需求。3.4.3 省干网络的性能要求 省干 2-1 大带宽，能够满足未来业务增长的需要。随着车路协同业务的不断丰富，所需要的带宽也会越来越大，因此省干网络的带宽需要满足未来业务增长的需要。 省干 2-2 高可靠性。省干网络及设备需要通过提供冗余能力保证业务的可靠运行。核心设备、单台设备的关键部件和主要链路必须有冗余，同时主要链路有足够带宽，保证业务高峰时不会出现大面积网络拥塞 ； 应通过各类链路级和设备级保护实现业务 50ms 以内的保护倒换 ； 应支持平滑重启功能，实现故障的快速切换和恢复。车路协同信

137、息需要高可靠传输，需要省干网络能有（单次或多次）断纤通信保护能力，通信设备的单点故障保护能力。省干2-3高QoS。 省干网络必须针对不同的业务应用需求， 如丢包率、 延迟、 抖动和带宽等， 提供不同的服务质量保证，以实现同时承载收费、监控等业务。省干网要有资源预留能力来确保高优先级的业务流不会被低于其优先级的业务流影响传输质量，用来解决网络延迟和阻塞等问题。55车路协同业务对网络安全的需求分析3.5车路协同业务对网络安全的需求分析3.5.1 车路协同业务面临的安全威胁分析3.5.1.1 路侧设备面临的安全威胁路侧设备是车路协同系统的核心单元，它的安全关系到车辆和道路交通的整体安全。它所面临的主

138、要安全威胁如下： 非法接入路侧设备通常通过有线接口与交通基础设施及业务云平台交互。黑客可以利用这些接口接入路侧设备，非法访问设备资源并对其进行操作和控制，从而造成覆盖区域内交通信息混乱。攻击者甚至还能通过被入侵或篡改的路侧设备发起反向攻击，入侵整个交通专用网络及应用系统，在更大范围内危害整个系统的安全。 运行环境风险路侧设备中也会驻留和运行多种应用、提供多种服务，也会出现敏感操作和数据被篡改、被伪造和被非法调用的风险。 设备漏洞路侧设备及其附件（智能交通摄像头等终端）可能存在安全漏洞，导致路侧设备被远程控制、入侵或篡改。 远程升级风险通过非法的远程固件升级可以修改系统的关键代码，破坏系统的完整

139、性。黑客可通过加载未授权的代码并执行来篡改系统、关闭安全功能，导致路侧设备被远程控制、入侵或篡改。 部署维护风险路侧设备固定在部署位置后，可能由于部署人员的失误，或交通事故、风、雨等自然原因导致调试端口或通信接口暴露或者部署位置变动，降低了路侧设备物理安全防御能力，使破坏和控制成为可能。1234556车路协同业务对网络安全的需求分析3.5.1.2 路侧边缘计算面临的安全威胁路侧边缘计算边缘设施的资源和能力有限，难以提供与云中心同等级的安全能力，同时在物理位置、网络边界、业务类型等多方面发生了变化，在安全性方面也面临新的挑战。 设备安全风险路侧边缘计算平台设备涉及的安全风险包括但不限于：设备配置

140、缺陷 ： 包括各类设备基线配置不当、设备登录和访问控制策略配置不当、设备资源管理策略配置不当等引发的非法用户登录、非授权攻击等安全问题 ；设备管理安全： 包括因设备维护的管理通道缺乏双向认证或匹配的加密算法引发的窃听、劫持和篡改攻击，设备安全漏洞更新不及时导致的安全隐患等 ； 设备安全漏洞 ： 包括设备涉及的硬件漏洞、软件漏洞，以及容器、操作系统、数据库开发等第三方组件漏洞等 ；设备级安全防护措施不当： 因未部署恰当的设备级入侵检测系统、 抗 DDoS、 防火墙等防攻击手段， 导致无法及时发现、拦截和响应针对设备的非法访问、入侵等安全风险 ；设备故障风险 ： 因设备自身的电源、内存等硬件故障导

141、致的故障，导致设备无法正常工作从而影响服务。 物理环境安全风险边缘计算节点可能部署在无人值守机房或者路边，往往安保措施较为薄弱，更易遭受物理接触攻击。同时攻击者还可以非法访问物理服务器的 I/O 接口，获得网络设备中敏感信息。另外，由于边缘计算节点分布式部署，依赖远程运维，升级和补丁修复不及时，会导致攻击者利用漏洞进行攻击。 边缘计算平台面临的安全风险边缘计算平台提供了车路协同应用部署和运行涉及的环境和服务，其面临的安全威胁如下： 边缘计算平台与管理系统、第三方应用之间传输的数据存在被拦截、篡改等风险 ； 边缘计算平台提供边缘计算应用部署环境，攻击者可通过恶意边缘计算应用对边缘计算平台发起非授

142、权访问，导致敏感数据泄露或 (D)DoS 攻击等 ； 边缘计算平台自身以 NFV 或者容器的方式部署，存在虚拟化方面的安全威胁 ； 边缘计算应用面临的安全风险边缘计算应用存在的安全威胁如下： 攻击者可以非法访问边缘计算应用，导致应用的敏感数据发生泄露 ； 边缘计算应用生命周期管理中，存在非法创建、删除、更新风险 ； 边缘计算应用存在恶意消耗边缘计算系统的资源，造成边缘计算系统其它服务不可用的风险 ； 边缘计算应用在遭受攻击后产生的过载流量会造成对边缘计算系统的 (D)DoS 攻击。123457车路协同业务对网络安全的需求分析3.5.1.3 车路协同网络面临的安全威胁路侧边缘计算平台到云服务平台

143、的通信网络面临的安全风险主要有以下几方面： 窃听： 攻击者通过监视网络数据获得敏感信息 , 从而导致信息泄密。 重传： 攻击者事先获得部分或全部信息 , 以后将此信息发送给接收者； 伪造 ： 攻击者通过模拟合法用户，向接收者发送伪造信息。 篡改 ： 攻击者对合法用户之间的通讯信息进行修改、删除、插入 , 再将伪造的信息发送给接收者。 拒绝服务攻击 ： 攻击者通过某种方法使系统响应减慢甚至瘫痪 , 阻止合法用户获得服务 ； 行为否认 ： 通讯实体否认已经发生的行为； 电子欺骗 ： 通过假冒合法用户的身份来进行网络攻击 , 从而达到掩盖攻击者真实身份 , 嫁祸他人的目的 ； 非授权访问 ： 没有预

144、先经过同意 , 就使用网络或计算机资源被看作非授权访问。它主要有以下几种形式 : 假冒、身份攻击、非法用户进入网络系统进行违法操作、合法用户以未授权方式进行操作等 ； 传播病毒、通过网络传播计算机病毒 , 其破坏性非常高 , 而且用户很难防范。3.5.2 车路协同对网络安全需求3.5.2.1 省干网络安全需求 省干安全 1 应限制省干网络与其他网络的互联，避免因网络互连开放引起外部网络攻击 ； 如业务需求必须进行互通时，需要考虑部署安全防护，满足相关等级保护要求。 省干安全 2 对于非信任网络应启用安全路由协议机制，避免非法连接和路由攻击。 省干安全 3 应安装网络安全评估分析软件，扫描分析网

145、络，及时发现并修正存在的弱点和漏洞。支持通过安全评估分析软件，可以对省干网络的状态进行实时监控，及时发现安全隐患。 省干安全 4 应遵循最小化服务原则，关闭所有不需要的服务，避免增加网络的安全风险。 省干安全 5 不同安全等级的业务间需通过网络技术进行隔离，不同安全等级的业务间互访需通过安全平台进行策略管控。 省干安全 6 在与其他网络互联处要有流量监测能力，能基于骨干网络出入流量进行安全分析，并通过整网安全监控平台进行信息汇总，进行攻击溯源和处置。 省干安全 7 省干网络设备应具备设备内生安全，通过操作系统防护、软件完整性保护、数据机密性保护等手段保证网元自身的安全可信能力。3.5.2.2

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

147、能力，确保连接可信 ；网络设备应能够限制与感知节点通信的目标地址，以避免对陌生地址的攻击行为；3.5.2.3 云中心网络安全需求参考 GB/T 22239-2019信息安全技术 网络安全等级保护基本要求中云计算安全三级相关要求。3.5.2.4 网络安全的运维需求车路协同网络安全的运维管理是以资产为保护对象展开的一系列管理，监控，运维等操作，安全的运维系统建设经常面临投资大，但防御效果不佳，部分安全设备无法 100% 发挥作用，安全运维严重依赖安全人员的专业技能以及对各类安全设备的熟练操作，依靠大量的人工操作保障安全体系的运营等问题。根据车路协同网络自身业务特性及组网架构，网络安全的运维需求包括

148、以下三点内容 集中管理需求集中管理包括对资产，漏洞，知识库及情报的管理，对于资产的精准识别和全量探测是网络安全运维管理的必要前提。资产管理 ：车路协同网络中海量路侧设备部署在公路边，相对于数据中心的设备，其运维和管理的成本及复杂度更高，资产的集中管理能够提供全局化、可视化、实时化的全网资产状态感知，有助于运维人员清晰直观的了解资产的重要等级，软硬件配置，运行状态等信息。漏洞管理 :资产的漏洞为网络攻击提供了可行性，能够标识资产的脆弱性，通过对漏洞的及时管理能够有效降低攻击成功的可能性知识库管理 ：安全设备的检测能力依赖知识库的覆盖广度和时效性，对漏洞库，病毒库，补丁库等知识库集中管理 能够有效

149、发挥安全设备的检测能力，车路协同网络中部分设备无法直连互联网进行知识库升级，通过自动化升级管理可以避免人工误操作、U 盘传播病毒等安全风险。12159车路协同业务对网络安全的需求分析 情报管理 ：情报是辅助威胁判定的重要信息，通过关联 0 Day 漏洞，新型攻击事件等情报，提前做好预防，必要时通过手动更新知识库的方式进行专项防护。 统一监控需求统一监控包括资产风险评估，设备状态监控，态势感知以及可视化展现等功能，在资产的集中管理的基础上，结合业务系统及信息资产的重要性，对资产进行风险评估，对可能导致生产业务受损的关键资产进行识别和风险评估，为安全运维操作提供处置依据。 资产风险评估：车路协同网

150、络中，不同重要程度的资产受到损害时产生的影响有所不同，通过对资产的漏洞，网络攻击评估威胁发生的坑性，结合资产的重要程度，能够评估出资产的风险等级，针对不同的风险等级需要部署响应的安全防护策略。 设备状态监控 ：关键的网络设备、边界设备、安全设备遭受攻击时，设备的可用性会受到损害，影响整个网络的可靠稳定运行。对设备状态的监控能够实时感知设备的 CPU 资源、内存资源、存储资源的消耗情况，避免资源耗尽或设备宕机导致网络故障。 安全态势感知 ：安全态势感知包括对终端、网络、云平台的海量安全数据进行统一格式化处理，通过降噪，归并去重，分组聚合，关联分析挖掘高危安全事件，通过排序，统计、趋势预测等方式进

151、行展示等内容。跨云网的全面的安全态势感知能力的有效运用有助于运维人员识别关键威胁事件，了解事件全面，对于后续的处置操作提供关键的决策依据 。 协同运维需求安全运维包括安全响应管理、安全审计、安全评估、溯源取证、威胁报告输出等功能。运维过程中将大量的分析，取证，响应等人工处置操作以及专家经验转化成程序和脚本自动化完成，最大化安全设备的防护能力，可以有效减少运维人员的学习及培训成本，提升运维效率，同时降低误操作及误判的概率。 安全响应 ：根据对威胁事件的分析判断，安全响应动作可能包括发出告警、隔离、阻断、添加黑 / 白名单、忽略以及延后处理等操作，涉及不同网络设备、安全设备的操作和配置，应包含终端

152、、网络、云平台的端到端安全处置策略，通过网络设备、安全设备、终端设备之间的协同联动，精准溯源、近源阻断勒索病毒等高危安全事件、避免人工操作慢、响应不及时导致威胁进一步扩散。 安全审计：安全审计是对运维人员的操作进行合规性检查，对于误操作或恶意操作导致的网络安全事故进行事后审查和问题复现，同时也对运维人员的操作进行合规性约束。 威胁报告：对网络安全态势以及运维结果输出威胁分析及处置报告，有助于及时总结和评价网络安全态势以及运维处置效果。自动化，定制化的周期性生成威胁报告能够规范报告格式及内容，减少运维人员的重复工作。2360车路协同业务对网络运维的需求分析3.6.1车路协同业务的网络管理系统3.

153、6车路协同业务对网络运维的需求分析图 3.61 车路协同网络管控业务流向图省级交通服务中心路段服务中心路测终端省中心设备管理平台路段（分）中心业务设备管理平台路侧通知设备感知缓存路侧边缘计算平台毫米波雷达摄像头激光雷达路侧感知设备RSU道路传感器气象传感器61车路协同业务对网络安全的需求分析车路协同网络管控业务流向即为设备状态数据的流向，见图 3.61。终端和路段区域的设备需要接入路段分中心业务设备管理平台，进行全域感知、计算和接入网设备管理与运维，建立设备运行状况的模型，记录、查询路侧设备的全生命周期，检测和评估路段接入网数通设备的工作状态及预警预测。终端设备包括路侧传感器、路侧通知设备 ；

154、 路侧边缘计算平台包括雷达储存和视频储存设备以及平台集群设备 ； 省中心设备管理平台实现省干传输网和数据核心网设备运行状况记录、查询及预警预测。序号管理对象设备类型1省中心设备管理平台核心路由器2云中心交换机3传输设备4路段（分）中心网络管理平台杆上交换机5路侧汇聚交换机（路由器）6路侧边缘计算平台7区域计算平台数通设备8路段（分）中心业务管理平台业务运营平台数通设备9摄像机10激光雷达11毫米波雷达12气象环境传感器13微型气象站14道路环境传感器15路侧边缘计算平台16RSU17其它设备车路协同相关设备、设施表 3.6-1 设备管理对象分类3.6.2 网络运维管理体系需求需要组织运行维护机

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

156、 : 网络管理制度、安全管理制度、存储备份管理制度、故障管理制度、人员管理制度和质量考核制度等。62车路协同业务对网络运维的需求分析3.6.3 网络运维平台的需求为支撑车路协同网络的运维，需建立网络与业务监控并重、端到端全覆盖，省中心和路段（分）中心分级响应的网络运维平台，将面向网络的分级监控与面向业务的场景监控相结合，工单任务直达运维团队，实现网络与业务问题的快速响应。 业务开通对网络设备提供业务批量和快速开通的能力，同时支持业务模板定制化，提供业务开通差异化配置修改。支持业务全生命周期管理，并能实现动态扩缩容调整。 网络全量设备可监可控车路协同网络运维平台不仅需要对云中心网络、省干承载网和

157、路段接入网等大网网络进行监控，还需要对路侧通信网络进行监控，确保网络全量设备可监、可控。 面向业务的场景监控建立业务级场景监控，按用户及场景需求维度，定制化呈现网络告警、网络性能指标、运行指标等信息。需要具备对业务流（五元组）和 SLA（时延、丢包）进行实时精确监测，自动还原业务路径，出现故障后分钟级实现故障定界定位。 巡检管理对网络设备进行定时巡检，并产生巡检报告。 基础信息监控对设备告警、线路告警监控，显式告警级别，告警名称，定位信息，告警产生时间，告警恢复时间。 性能指标监控和历史性能数据分析通过实时性能分析工具查看当前设备的实时负载情况。呈现时延、带宽、可靠性等性能指标，可根据用户要求

158、及业务特点定制。提供历史性能数据查询功能，可以按照小时级、天、周、月、年等不同时间段进行统计，同时提供自定义时间段的定制功能，支持导出到 xls、pdf 等格式。 远程升级管理平台应具备软件版本管理、软件版本升级及软件版本回退功能。软件版本管理支持设备版本的查询及升级进度的上报和查询，设备历史升级情况查询 ； 支持整包升级包或差分升级包的管理。软件版本升级管理应具备对设备进行软件远程升级，支持手动或自动方式进行软件升级处理 ； 应具备对设备远程升级包的上传功能。针对平台对设备自动升级的情况，必须具备配置多个升级时间区间（含日期，时，分，秒等）及多种升级周期（含每天，每周，每月等）参数。软件版本

159、回退应具备设备远程软件版本回退功能，具备回退到最后一次成功运行的设备软件版本的功能。123456763车路协同业务对网络安全的需求分析 SLA 服务指标监控对故障处理时长、处理及时率等 SLA 指标监控。拓扑及告警关联监控 ： 呈现业务端到端拓扑，并与告警关联呈现 网络拓扑发现使用 ICMP、SNMP、LLDP 和 BGP-LS 等网络协议和技术能够自动快速的发现网络中二层和三层的网络设备，并根据发现设备之间的关系自动生成全局的二层或三层的网络拓扑结构图。网络管理人员能够看到整个运营网络系统的网络拓扑结构，包括各个分布地区的子网、各个子网之间的网络连接关系、及其每一子网上的资源和资源的状态变化

160、。具体信息如下：第二层和第三层网络设备、网络协议、设备信息（卡，端口，接口，IP, MAC） ，设备之间的物理和逻辑关系，设备连接信息等。通过对网络节点状态的轮询，实时监控网络中所有资源的状态。支持拓扑自动事故分析，拓扑图中设备的监控报警，支持基于业务粒度的网络拓扑可视 网络资源管理可以对网络设备的可用性进行监控， 监控设备接口的状态信息， 包括接口名称， 操作管理状态， ICMP 包率， 通断信息，接口发送接收速率等具体指标。监控设备关键资源使用情况，包括 CPU/ 内存使用率等关键资源使用率。可以对网络设备间链路可用性进行监控，观察链路的通畅度。可以对网络设备进行搜索，搜索条件包括： 设备

161、名称、ip 地址和设备类型等，可以快速的查看设备的运行状态，定位故障问题。 设备 IP、MAC 安全管理通过终端识别，实时监控网络中接入的终端用户，一旦发现异常终端或 IP 地址盗用的现象，会迅速产生告警。 配置管理对网络设备的配置更改进行监控，发现变更后进行告警。提供设备运行配置和启动配置的基线化版本管理，将每个设备相关的配置文件划分为不同版本管理。运维管理系统能够借助 FTP/TFTP上传下载网络设备配置文件，并在管理服务器侧进行归档存储。这一功能在网络开通和调整时能够对不同阶段的配置情况进行存档。 安全管理平台应提供完善的用户访问授权、身份认证与权限管理机制。对日常操作进行完整日志记录，

162、并具备日志备份功能，备份日志的保存支持存储不小于 7 天。当系统出现故障时，能够根据文件系统备份与数据库备份将运维管理平台恢复到备份前的状态。平台应具备数据定期、自动、手动备份功能。3.6.4 网络的运维需求车路协同业务对带宽、时延、可靠性等指标要求更高，在传输网故障处理、网络配置升级、现网结构优化等方面提出了更加严格的要求。891213111064车路协同业务对网络安全的需求分析3.6.4.1 路段接入网络的运维需求 故障处理提供 7*24 小时故障处理服务，普通故障处理时长不超过 8 小时，严重故障处理时间不宜超过 48 小时，网络可用性99.9。 网络配置升级设备配置升级需要尽量不影响车

163、路协同业务，影响到车路协同业务的升级需要在业务量较少的夜间时段进行，并且在2 小时内完成升级。 线网结构优化路段光纤运维管理工作分为 “日常维护”和 “技术维护”两大类，采用日常巡查、维护、应急抢修和综合管理的方式，路段光纤完好率需要达 99%。 网络设备优化网络设备更改，线路的迁移或优化改造，需要在业务量较少的夜间时段进行，并且在 2 小时内完成。 人工巡检机房每日巡检次数不少于 1 次，采用轮流巡检制，按实现安排的人员执行，确保机房的不间断管理。遇特殊事情或特殊安全事故时，维护人员 24 小时留守现场不间断进行巡检值班。 兼容管理兼容多个厂家、多种设备统一网管，全面检测设备的运行情况。 安

164、全管理设备具备很高的安全稳定性，不易遭受网络攻击，并具备完整的操作权限管理功能和完善的系统安全机制。3.6.4.2 省干承载网络的运维需求 故障处理提供 7*24 小时故障处理服务，普通故障处理时长不超过 4 小时，严重故障处理时间不宜超过 48 小时，网络可用性99.99。 网络配置升级设备配置升级需要尽量不影响车路协同业务，影响到车路协同业务的升级需要在业务量较少的夜间时段进行，并且在2 小时内完成升级。车路协同业务对网络安全的需求分析65 网络设备优化网络设备更改，需要在业务量较少的夜间时段进行，并且在 2 小时内完成。 人工巡检机房每日巡检次数不少于 2 次，采用

165、轮流巡检制，按实现安排的人员执行，确保机房的不间断管理。遇特殊事情或特殊安全事故时，维护人员 24 小时留守现场不间断进行巡检值班。 兼容管理兼容多个厂家、多种设备统一网管，全面检测设备的运行情况。 安全管理设备具备很高的安全稳定性，不易遭受网络攻击，并具备完整的操作权限管理功能和完善的系统安全机制。654366结束语随着车路协同相关政策及技术的稳步推进，高速公路通信技术的发展迎来了新的挑战。结合全国各省份高速公路通信网络的建设现状，高速公路车路协同网络面临着网络结构不合理、网络传输技术差异大、业务流向不明确、缺少相应建设规范以及后期运营能力不足等一系列问题。本课题梳理了高速公路车路协同业务体

166、系架构以及网络体系架构，围绕车路协同的业务内容及对各级网络的需求展开分析研究，主要研究内容如下： 业务内容分析车路协同业务需求对网络建设起到导向作用，为了合理规划需求，本研究应用场景选自目前行业认可度较高的标准，将场景分为安全类、效率类、信息服务类三大类，并给出场景的定义和业务流，同时根据不同业务流，给出 PC5 与 Uu两种通讯方式的场景数据流模型。 部署场景分析本研究按照高速公路组成要素，分为一般路段、主线隧道、收费站互通、枢纽互通、服务区 5 种场景，并给出 5 种场景的详细描述与基本的部署方案。 路段接入网需求分析基于对车路协同业务的流量模型和通信需求分析、业务部署方案分析、网络安全和

167、运维需求分析，重点从网络功能、网络性能和网络安全三个方面，就车路协同业务对路段接入网的需求进行研究分析。 省干网络需求分析重点从总体架构、功能要求和性能要求三个方面，就车路协同业务对省干网络的需求进行研究分析。 网络安全的需求分析针对车路协同业务面临的各类安全威胁，围绕车路协同系统的通用安全需求、路侧设备安全需求、路侧边缘计算安全需求以及车路协同网络安全需求展开研究分析。 网络运维的需求分析根据车路协同网络管控业务流向， 重点对网络运维管理系统需求、 网络运维平台需求以及网络的运维需求展开研究分析。总之，通信网络在车路协同系统建设中起着至关重要的作用，本课题通过对高速公路车路协同的网络需求进行

168、研究，为高速公路通信网络一体化建设奠定了良好的基础。随着后续研究工作的不断开展，高速公路车路协同的通信网络建设将更加高效、经济、合理！123456结束语67缩略语缩略语6712B 对企业 to Business22C 对客户to Customer35G 第 5 代移动通信技术5th Generation Mobile Communication Technology4API 应用程序接口Application Programming Interface5APP 应用Application6ASON 自动交换光网络Automatically Switched Optical Network7BG

169、P-LS 边界网关协议连接状态 BGPBorder Gateway Protocol- Link Status8CPU 中央处理器Central Processing Unit9C-V2X 蜂窝车联网通信Cellular Vehicle-to-Everything10Diff-Serv 区分服务 Differentiated Service11(D)DoS ( 分布式 ) 拒绝服务攻击Distributed Denial of Service12EV 装载通信系统的车辆Equipped Vehicle13FTP 文件传输协议File Transfer Protocol14GNSS 全球导航卫星

170、系统Global Navigation Satellite System15ICMP 互联网控制报文协议Internet Control Message Protocol16ID 标识Identity17I/O 输入 / 输出Input/Output18IP 互联网协议Internet Protocol19IPv4/v6 互联网协议第 4/6 版Internet Protocol Version 4/620LLDP 链路层发现协议Link Layer Discovery Protocol21LTE/4G 长期演进第 4 代通信技术 Long Term Evolution/4th Generat

171、ion68缩略语6822MAC 介质访问控制 Media Access Control23EC 边缘计算 Edge Computing24MSTP 多业务传送平台Multi- Service Transport Platform25NFV 网络功能虚拟化Network Function Virtualization26NV 未装载通信系统的普通车辆Normal Vehicle27OAM 操作管理与维护Operations, Administration and Maintenance28OBU 车载单元Onboard Unit29OTN 光传送网optical transport networ

172、k30PC5 直连通信接口 31POE 以太网供电Power over Ethernet32PTN 分组传送网Packet Transport Network33QoS 服务质量Quality of Service34RSU 路侧单元Road Side Unit35SDH 同步数字体系Synchronous Digital Hierarchy36SLA 服务级别协议Service Level Agreement37SLW 限速预警Speed Limitation Warning38SNMP 简单网管协议Simple Network Management Protocol39STM-N 同步传输

173、模块 N 级Synchronous Transport Module level N40TFTP 简单文件传输协议Trivial File Transfer Protocol41Uu 通用用户网络接口Universal User to Network interface42V2V 车与车通信Vehicle-to-Vehicle43V2X 车联网通信Vehicle-to-Everything44VRUCW 弱势交通参与者碰撞预警Vulnerable Road User Collision Warning69参考文献缩略语691中国汽车工程学会 . 合作式智能运输系统车用通信系统应用层及应用数据交

174、互标准（第一阶段）:T/CSAE 53-2020S. 北京： 2020.2中国汽车工程学会 . 合作式智能运输系统车用通信系统应用层及应用数据交互标准（第二阶段）:T/CSAE 157-2020S. 北京： 2020.3 中国汽车工程学会 . 基于车路协同的高等级自动驾驶数据交互内容 ： T/CSAE 158-2020S. 北京： 2020.4中国智能网联汽车产业创新联盟，IMT-2020（5G） 推进组 C-V2X 工作组，中国智能交通产业联盟，中国智慧交通管理产业联盟 . C-V2X 产业化路径和时间表研究 R. 北京： 2019.5中华人民共和国交通运输部 . 交通运输部 2012 年第

175、 3 号公告：高速公路通信技术要求S. 人民交通出版社，2012 年。6中华人民共和国工业与信息化部 . 国家车联网产业标准体系建设指南（工信部联科 2018 109 号） Z.2018 年。7中华人民共和国工业与信息化部 . 国家车联网产业标准体系建设指南（智能交通相关） （工信部联科2021 23 号）Z.2021 年。8中华人民共和国网络安全法 ，20179关键信息基础设施安全保护条例 ，202110中华人民共和国密码法 ，201911中华人民共和国个人信息保护法 ，202112中华人民共和国数据安全法 ，202113高速公路通信技术要求 ，201214数字交通 “十四五”发展规划 ，2

176、02115 孙亮 .甘肃省高速公路通信系统升级改造解决方案 J. 中国交通信息化，2017 年 7月。16陆柄聿等 . 高速公路通信资源经营模式研究 J. 中国交通信息化，2013 年 12 月。17 河北省高速公路 “十三五”通信系统网络发展规划 Z.2017 年。18 陈广辉 . 江西省高速集团取消省界收费站通信传输系统升级改造方案 J. 中国交通信息化，2019 年 10 月。19黄强 . 江西省高速集团信息化项目基础通信网二期升级改造方案 J. 中国交通信息化，2021 年 4 月。70缩略语7020云南省智慧高速建设实施方案（云交信息201711号）Z.2017 年。21 莫新强 .

177、 广西全区高速公路通信系统干线网络升级改造设计研究 J. 西部交通科技 ,2020 年 4 月。22广西高速公路干线通信网络改造项目设备采购与安装招标公告，2020 年 7月。23靖勃等 . 高速公路传输系统技术演进探析 J. 中国交通信息化，2018 年 9 月。24蔡权慧 . 高速公路 PTN 系统业务传输规划浅析 J. 工程与建设，2019 年第 33 卷第 3 期。25黄鹏 . 高速公路通信网络建设中 POTN 技术探析 J 中国交通信息化，2016 年 1月。26邸 赫 . 浅析辽宁省高速公路信息通信系统网络规划 J. 北方交通，2016 年第 3 期。27吉林省地方标准公路水路交通

178、运输基础通信网络技术规范 （DB22/T 2649-2017） 。28天津市地方标准高速公路通信技术要求 （DB12/T 645-2016） 。29梁铭 . 湖南省高速公路通信系统介绍 J. 中国交通信息产业 ,2009 年 6 月。30吴亚忠 . 浅析福建高速公路通信系统技术体制的发展和网络规划 J. 福建交通科技，2015 年第 4 期。31四川省交通运输厅四川省高速公路专用通信网规划 （2013 年）Z.2013 年。32吴思源等 . 湖北省高速公路通信系统干线传输网升级 J . 中国交通信息化，2018 年 11月。33 北京交科公路勘察设计研究院有限公司广东省深化收费公路制度改革取消

179、高速公路省界收费站研究专题 -干线通信系统研究Z.2019 年。342021 年 7月国家网信委 & 发改委 & 工信部联合发布 “ 关于加快推进互联网协议第六版 （IPv6）规模部署和应用工作的通知 ”35IMT-2020 5G 推进组， 面向车路协同路边设备运维管理平台 ，2021 年36中华人民共和国工业和信息化部 . 支持多业务承载的本地 IP/MPLS 网络工程设计规范： YD/T5226-2015. 北京：人民邮电出版社，2016.37GB/T 22239-2019 信息安全技术 网络安全等级保护基本要求38江苏省交通厅发布江苏省智慧高速公路建设技术指南 ，202039浙江省交通厅发布智慧高速公路建设指南（暂行） ，202140 清华大学智能产业研究院、百度 Apollo， 面向自动驾驶的车路协同关键技术与展望 ，202141基于移动通信网的高精度定位总体技术要求 （YD/T 3936-2021 ）423GPP TS 22.186 V16.2.0 (2019-06) Enhancement of 3GPP support for V2X scenarios（Release 16） ，2019