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

更多车路协同精华知识分享地址：https://www.yuque.com/lovebetterworld/c-v2x

整理自：《城市场景车路协同网络需求研究》2022版本1.0

1 我国城市场景车路协同建设现状

作为跨行业、跨领域技术和产业融合发展的重要载体，我国多个城市积极开展车路协同建设，投资建设新型 基础设施 ( 简称新基建 )，带动众多互联网企业、汽车制造商等纷纷投入，孵化形成新型产业，探索更多新业态、 新模式。

1.1 典型城市建设情况

无锡市依托车联网先导区建设，已实现车联网规模覆盖，并计划于 2022 年年底完成无锡市车联网全域覆盖。 在此基础上，无锡市大力推进物联感知设备部署，推动城市基础设施网联化、智能化改造，提升城市基础设施建 设与管理智能化水平，逐步推动道路状态感知、智能公交、出租车、急救等领域的应用。从显见的拥堵提示、盲 区预警、限速等数字化交通标识，到不引人注意的 RSU（路侧单元）、智能化信号机，车联网的覆盖正向着无锡市 区全域覆盖的目标加速推进。据了解，该市从 2020 年开始，打造了南山车联网小镇、慧海湾小镇、山水城科教产 业园等特色产业园区，加速发展交通事件提示、精准公交、盲区预警、路险信息等 40 余项“车联网”应用。

长沙市重点推进车路协同道路智能化改造，加快 5G（第五代移动通信技术）及“车联网”安全身份认证等网 络设施建设，推进基于“车城网”平台的智慧交通平台、城市信息模型平台、云控平台等。“作为首批试点城市， 努力将‘试点’变为‘示范’”。长沙湘江新区相关负责人表示，目前长沙市建设双智发展城市已经形成了智能化基 础设施建设、新型网络基础设施建设、“车城网”平台建设、示范应用、标准法规建设等 5 大建设任务 18 个具体 项目为主体内容的试点方案。预计到 2023 年，长沙将初步建立智能、高效、安全的新型基础设施体系和“车城网” 平台。长沙将规模化应用具备智能驾驶功能的智能网联公交、环卫、物流、出租车等示范场景，并初步建立起适 应产业发展的政策法规、标准规范和安全保障体系。

上海市大力推进城市数字化转型，实行智慧城市、智能交通、智能网联汽车与智慧能源深度融合一体化的战略， 推广多元化应用示范工作。以智慧物流为例，2021 年 7 月，科创企业驭势科技与国际化工企业巴斯夫合作，根据 双方的规划，无人驾驶物流车将作为巴斯夫浦东基地智能制造的组成部分，实现与现有生产、调度系统无缝对接， 提高基地的智能物流水平。上海市也在积极推进风险等级齐备、测试场景完善的开放道路测试环境建设。嘉定区 的智能网联汽车正从测试向示范应用、商业化运营的目标大步迈进。目前，全区开放测试道路达 315 公里，将于 2022 年年底实现全域开放。上海市交通委表示，未来将继续深入开展智慧道路建设，探索开放城市快速路、高 速公路等道路测试场景，推进车路协同技术应用，支撑自动驾驶汽车在复杂路况下的适应能力。

广州市在 2019 年城市智慧汽车基础设施与机制建设试点基础上，依托城市信息模型基础平台推进双智发展 试点。聚焦车城融合赋能城市治理和社会服务，在广州人工智能与数字经济试验区核心区开展琶洲“车城网”试点、 在黄埔区开展智慧交通新基建项目、在广汽汽车城开展番禺“车联网”项目。其中，琶洲“车城网”试点项目以琶 洲会展中心区、互联网创新集聚区为重点，整合广州市 5G、智慧灯杆、交管、城市信息模型基础数据等基础设施， 形成琶洲车城感知网络。同时，建设标准统一、逻辑协同、开源开放、支撑多类应用和城市级数据处理的“车城网” 平台。基于琶洲车城感知网络和“车城网”平台向多个城市管理和服务领域的赋能，结合多领域需求建设车城融 合应用，包括未来出行形态、城市交通治理、城市安全与综合管理、“车城网”示范体验应用等，实现“一网、一 平台、N 应用”的格局。

北京市建设高级别自动驾驶示范区，示范区专门组建智能化基础设施的投资、建设、运营、运维公司，在商 业化探索方面处于国内领先地位。据了解，在示范区建设取得初步成果的基础上，示范区推进工作组推出“V 伙 伴”合作计划，通过政企深度合作，共同解决产业落地中遇到的各项难题，支持企业积极开展智能网联汽车新技术、 新产品、新模式的探索应用与生态构建。

武汉市在智能驾驶、高精地图、地理空间信息等领域有着较好的技术基础和产业体系，发展智能网联汽车具 备较强优势。依托雄厚的汽车产业基础和现代化城市基础设施，武汉市积极探索规模化、可持续运营的智能网联 汽车商业化应用。2021 年 6 月下旬，华为（武汉）智能网联汽车产业创新中心在武汉经开区揭牌，推动智能网联 汽车技术成果转化与先行先试，打造智能网联汽车产业生态圈，助力武汉市万亿元级汽车产业集群建设。

除以上典型城市案例以外，在我国“新基建”政策的牵引下，2020 年以来全国车路协同项目呈井喷趋势，全 国有近百个项目启动建设，涉及的城市有杭州、宁波、绍兴、德清、成都、福州和柳州等城市，建设内容除了网联 汽车封闭测试场以外，还包括城市开放道路、公交（含 BRT）专用道、停车场 / 库、景区和园区道路等。

1.2 业务应用遵循标准

目前国内城市场景车路协同实现的业务应用主要集中在安全驾驶、通行效率、信息服务、交通管理等方面， 大多遵循标准 T/CSAE 53-2020《合作式智能运输系统车用通信系统应用层及应用数据交互标准（第一阶段）》中 的场景，而 T/CSAE 157-2020《合作式智能运输系统车用通信系统应用层及应用数据交互标准 ( 第二阶段 )》中的 业务应用尚未规模落地，与其他自动驾驶类、远程遥控驾驶类业务应用一并均处于测试、验证、完善中。

表1.1–2 T/CSAE157定义的车路协同应用（第二阶段）

1.3 城市车路协同应用的发展展望

1.3.1 车路协同应用时间表

中国智能网联汽车产业创新联盟（CAICV）、IMT-2020（5G）推进组 C-V2X 工作组、中国智能交通产业联盟 （C-ITS）、中国智慧交通管理产业联盟（CTMA）共同发布的《C-V2X 产业化路径及时间表研究》，对车路协同应用 时间表进行了研究与预测。

2019-2021 年，在国家车联网示范区、先导区、特定园区规模部署路侧设施，形成示范应用。编制 C-V2X 路 侧单元与交通、交管设施接口规范，进行相关设备研发。

2022-2025 年，在典型城市、高速公路逐步扩大 C-V2X 基础设施覆盖范围。

2025 年以后，在主要城市、主要区域、主要公路逐步实现 C-V2X 全面覆盖。

1.3.2 车路协同实现路径

车路协同需要“聪明的车”和“智慧的路”，在推进智能网联汽车不断发展进步的同时，也应注重智慧道路建 设以及两者的协同发展。

（1）加大、加快智能路侧设备研发与测试

加大路侧感知、边缘计算、信息交互等设备和系统的研发力度，规范功能和性能要求。研究面向智能路侧设 备的测试评估方法，推进测试体系建设，开展规模化测试，验证智能路侧设备的适用性和可靠性。

（2）推进新型道路基础设施建设

坚持基础设施和车辆协同发展，研究道路智能化分级方法，加大新型基础设施投资力度，分阶段、分区域推 进道路基础设施的数字化、智能化建设，逐步形成泛在感知、精准管控的服务能力，实现重要交通基础设施的数 字化管理和全路网运行的智能化服务，与智慧交通、交通管理信息化协同推进。

（3）建设标准体系

结合我国现阶段城市交通与城市本身、城市交通管理体制的特点，进一步完善车路协同技术以及城市交通管 控技术标准体系。充分考虑通信、汽车、交通管控设施等标准的兼容性，进一步完善和落实交通基础设施与 V2X 设备的接口规范、数据共享相关标准。

（4）选取有条件城市、道路开展试点工作

充分利用车联网先导区、智慧城市建设、双智城市试点、道路基础设施新建和升级改造的机会，加快新型道 路基础设施的部署和应用。选取基础条件较好的城市和道路试点，优先开展行业之间的示范应用。

（5）探索车路协同运营模式，推动车路协同生态及产业发展

探索车联网管理机制和运营模式。以市场需求为导向，进一步加强市场培育，规范市场秩序，完善产业发展环境， 形成包括监管方、建设方、承建方、设备商、运营商、车企及用户间的完善的产业生态体系。

2 城市场景的道路及网络现状

2.1 城市道路分类

对城市道路可按道路等级、道路功能分类。

（1）按道路等级分类

城市道路依据其在道路网中的地位、交通功能及对沿线的服务功能等，分为城市快速路、主干路、次干路和 支路四个等级。

快速路一般设置中央分隔带（墩）、全部控制出入，保证交通连续通行，单向设置不少于两条车道，并设有配 套的交通安全与管理设施。快速路两侧一般不设置可能会吸引大量车流、人流的公共建筑物的出入口 ；主干道连 接城市主要分区，以交通功能为主。其两侧一般不设置吸引大量车流、人流的公共建筑物的出入口。次干路与主 干路结合组干路网，以集散交通的功能为主，兼有服务功能。支路一般与次干路，以及居住区、工业区、交通设 施等内部道路相连接，解决局部地区交通，以服务功能为主。

（2）按道路功能分类

2019 年以后，为解决近 20 年来城市发展理念、方式、道路交通需求发生的深刻变化，城市道路从“快主次支” 的简单划分拓展到了“3 大类，4 中类，8 小类，干路与街道”的更注重道路功能结构的精细化分类。

A、道路功能大类

按照城市道路所承担的城市活动特征，将城市道路分为干线道路、支线道路，以及联系两者的集散道路三个 大类。

三大类的分类基于不同距离城市交通活动的组织。干线道路承担城市中、长距离联系交通，集散道路和支线 道路共同承担城市中、长距离联系交通的集散和城市中、短距离交通的组织。

B、道路功能中类

根据《城市综合交通体系规划标准》 GB/T51328-2018，城市道路中类划分与城市功能连接、城市用地服务的 关系如下表所示。

C、道路功能小类

根据《城市综合交通体系规划标准》 GB/T51328-2018，道路功能小类主要细化了干线道路的类别，细分了支路， 纳入了部分非市政权属的道路。各类别道路功能、设计车速及交通量如下表所示。

道路设计车速限制车辆运行速度上限，决定了车路协同网络时延性能要求 ；规划及实际交通流量对交通流运 行速度产生影响，对车辆遮挡程度产生影响，从而对网络连接稳定性等产生影响，对车路协同网络性能提出不同 的要求。根据《城市综合交通体系规划标准》 GB/T51328-2018，各等级道路红线宽度基本要求如下表所示。

道路红线宽度影响数字化设施的覆盖情况，从而影响其布设形式和位置，应在车路协同网络设备设计时予以 充分考虑。

（3）城市地下道路分类

城市地下道路根据服务对象、服务车型以及长度可分为不同类别，不同类别对通信性能存在不同需求。

A、按服务对象分类。可分为机动车专用地下道路和机动车与非机动车共用地下道路 ；

B、根据服务车型分类。可分为混行车地下道路和小客车专用地下道路 ；

C、按主线封闭段长度分类

可分为四类。第一，长度大于 3000 米为特长距离地下道路；第二，长度 1000 米到 3000 米为长距离地下道路； 长度 500 到 1000 米为中等距离地下道路 ；长度小于 500 米为短距离地下道路。隧道长度当前是地道设计防火等 级等的依据。

地下道路长度将影响通信性能，在通信网络设计时需予以着重考虑。

2.2 城市道路设施建设及运行管理权属

城市道路设施作为城市基础设施归属不同主体管辖，因此，车路协同场景的建设和使用需得到相关使用及管 理主体的认可，并与不同部门对接。城市道路设施的规划、建设、运维、管理主要涉及的部门有发改委、规资委（局）、 交通委、住建委、公安交警，信息通信则涉及工信局、大数据局以及电信运营商、信息管线和铁塔公司。

2.3 城市管线及网络资源现状

城市道路交叉口管线资源情况 国内城市在道路交叉口横向预埋过路管道大致分为三个阶段 ：

第一阶段，较早期建设的城市道路，未考虑预埋，如需敷设通信光缆要自行掘路铺设，然后恢复。

第二阶段，为确保道路建成后，强、弱电线缆横向穿越道路交叉口时不开挖机动车道，在道路交叉口附近均 考虑预留、预埋横向过路钢管，钢管直径一般在 100-160mm、钢管数量在 2-4 根。

第三阶段，多杆合一、多管合一阶段。考虑应对今后智慧城市建设需求、避免反复开挖道路，在交叉口处充 分考虑预留预埋管道资源，下图为某交叉口的预埋管道及管线布设示意图。其中，采用预埋钢管横向穿越机动车道， PVC 管用于路段，敷设于人行道或隔离带下方。

管道埋设如下图所示 ：包括十根排管，其中各管道中具体敷设的线缆包括网线、电源、光纤、综合箱电缆、 机箱电缆、信号灯电缆，另外还考虑预留管道空间。

目前全国对横向过路预埋管的数量和规格尚无统一规定（规范或标准），以上横向过路预埋管道一般只供交 通和交警部门使用。

2.4 车路协同网络需求和业务流向的问题

网络需求有待系统梳理

网络架构以及部署方案的选择由场景需求来决定，个人用户、行业车辆、政府部门对车路协同业务需求的出 发点不同，车路协同应用按照服务对象可分为 ToC、ToB、ToG 类的应用，其中 ToC 应用关注的是如何提高安全性、 驾驶体验；ToB 类应用关心的是信息是否可信、可靠，信息量是否充足、如何有效使用；ToG 应用关注的是服务政府、 优化交通治理、改善民生。不同场景下，对网络需求的侧重点不同。当前行业重点还是做试点示范建设和场景探索， 对网络需求的关注不足，导致网络设计依据不足。

业务流向尚无明确标准

车路协同涉及的 RSU 和边缘计算平台等业务单元，是业务的汇聚者，也是分发者，同时也是管理平台的数据 提供者。比如边缘计算平台，既要接收各类传感器的数据和信息，也要传输信息给 RSU，传输数据和业务信息给 云端管理平台。而 RSU 既要接收路侧边缘计算的信息，也需要广播业务数据给 OBU, 同时又要传输业务信息给云 端管理平台。因此需要详细梳理各个部分的业务流程，助力车路协同网络需求的梳理。

2.5 外场部署存在的问题

道路设备部署缺乏系统性规范

车路协同外场部署涉及 RSU 和感知系统、计算单元的部署，系统复杂，对安装要求较高。针对城市道路的 普通路口，由于不同路口交通设备配置不同，路口施工条件不同，树木、灯杆等环境因素也不同，在工程安装时， 需要考虑多种工程建设方案，因地制宜。直道、立交、隧道、匝道等不同部署现场，对设备部署的要求不同，需 要根据路侧设备的特殊性，输出不同场景下的部署方式分类和规范指导。城市道路改扩建和新建城市道路网络的 选用以及所需管道、杆件、基站等设施的建设需求，需要在道路（含桥梁、地道）主体工程建设中统一考虑，但 目前还缺乏相应的设计规范标准的指导。

网络方案选择缺乏合理的依据

车路协同路侧网络一般有两类，一是基于 4G/5G、Wi-Fi 网络的无线网络，另外一类是基于光纤的有线网络。 无线网络部署相对容易，但易受到外界因素影响和干扰。有线网络，安全性较高且信息传递效率比较稳定，但可 能需要额外的施工，造价成本偏高一些。目前不同部署场景针对网络方案选择的需求不明确，评估的方法也待深 入研究。

2.6 车路协同网络架构和性能的问题

烟囱式网络缺乏统一的架构规划

各城市车路协同示范区和先导区的网络建设，都是分散开展。由于接入设备种类较多，以及多级边缘计算的 参与，车路协同的接入网络结构较复杂，缺乏包含接入网络、汇聚网络、计算网络的统一的网络架构，需要整理 车路协同网络规划的需求，为以后统一规划承载网提供依据。

车路协同系统对网络需求尚不明确

车路协同系统中的视频流、车路协同消息、设备管理信息等有不同的网络需求，车路协同网络中存在车辆、 各种传感器、RSU、路侧计算单元、区域运算中心等多个角色对同步授时的需求也不尽相同。需要根据实际的业 务情况，整理各段网络的功能、性能、服务质量需求。

3 城市场景车路协同业务架构

城市场景车路协同业务架构主要由路侧终端、边缘端、云端、外部应用组成，其中一个路侧边缘计算平台会 连接多组路侧感知设备，一个区域计算平台连接多个路侧边缘计算平台，一个业务运营平台连接多个区域计算平台。 其业务架构和业务流向如图 2.1–1 所示。

需要说明的是，本文中车路协同业务系统架构是当前比较多采用的一个业务架构。

3.1 三级业务平台架构

3.1.1 路侧边缘计算平台

实时获取路侧感知设备数据进行融合计算，以高性能计算能力提供更高精度和更可靠的融合感知结果和交通 事件，完成目标的识别、分类、追踪和轨迹拼接等功能，还能够对车辆进行车牌识别、运动属性预测等，为 路侧交通参与者提供准确的数据服务。同时对路侧海量、繁杂的数据进行清洗过滤，抽取业务所需的数据发 送给区域计算平台。

路侧边缘计算平台根据需要，融合区域计算平台和 RSU 的数据，形成模型计算结果，将计算结果按照标准 T/ CSAE53-2020 和 T/CASE157-2020 对应用层要求，发送给路侧 RSU。 需要说明的是，部分实际系统中采用了路侧计算设备（如工控机等），本文中也将其视作路侧边缘计算平台。

3.1.2 区域计算平台

区域计算平台完成设备管理、模型管理、算法管理、应用管理和路侧边缘计算平台节点管理等相关功能。同 时对路侧传感器的结构化数据、路侧边缘计算平台融合感知的结构化数据、OBU 上报的车辆状态结构化数 据进行提取与融合。

区域计算平台将多个路侧边缘计算平台数据汇总，融合后将应用数据输送给业务运营平台，同时可以通过 Uu 口与车端进行通信。

3.1.3 业务运营平台

业务运营平台根据需求可以包含应用服务、数据服务、设备服务、安全服务、运营服务等，有选择性地从路 侧感知设备获取所需的实时数据，或从路侧边缘计算平台的感知缓存拉取短时历史数据。其中 ：

应用服务为智能网联汽车提供高精地图、智能导航、交通引导等服务支持，为交通指挥调度提供高精度态势 认知、信号控制策略优化等服务支持 ；

数据服务对全域数据进行挖掘分析，以支撑路侧智能网联汽车宏观运行环境 ；

设备服务可对终端设备和全域内的设备进行统一的管理，提供针对所有路侧、边缘和区域的设备（或平台）“接 入 - 监控 - 管理”的服务，包括对设备的查询、修改和升级配置、删除节点等，同时收集路侧单元设备的基本 信息和状态性能信息，监控设备运行情况，及时对工作异常设备进行故障诊断，并基于终端管理协议对路侧 单元设备进行远程管理 ；

安全服务对区域的设备接入安全、平台运营安全、数据应用与存储安全、交换机网络安全、运维安全等全域 安全进行管控 ；

运营服务将应用服务和数据服务的数据提供给政府或个人。

3.2 业务接口

AD 接口 ：为路侧感知设备与路侧边缘计算平台之间的接口，主要负责路侧传感器数据根据业务需求上传原 始数据至路侧边缘计算平台。

AB 接口 ：为路侧感知设备与业务运营平台之间的接口，主要负责业务运营平台根据业务需求直接从路侧传 感器获取实时数据，或获取传感器输出的结构化数据。

AC 接口 ：为路侧感知设备与区域计算平台之间的接口，主要负责区域计算平台根据业务需求直接从路侧传感 器获取实时数据，或获取传感器输出的结构化数据。

DC/CD 接口 ：为路侧边缘计算平台与区域计算平台之间的接口，主要负责路侧边缘计算的结构化数据上传至 区域计算平台，和业务运营平台下发业务数据至路侧边缘计算平台。

CB/BC 接口：为区域计算平台与业务运营平台之间的接口，主要负责区域计算平台把标准的消息帧传递给业务运 营平台，或业务运营平台根据业务需求，获取路侧传感器历史数据，同时业务运营平台根据请求下发相应的事件数据。

CE 接口 ：区域计算平台与路侧通知设备之间的接口，区域计算平台把交通事件信息下发给路侧通知设备，包 括但不限于道路危险状况提、限速提醒、道路施工提醒、弯道提醒、前方拥堵等信息。

DF/FD 接口 ：路侧边缘计算平台与路侧 RSU 之间的接口，主要负责路侧边缘计算平台融合传感器数据后，将 计算结果按照标准 T/CSAE53-2020 和 T/CASE157-2020 对应用层要求，把数据打包为标准规定的消息帧格式，发给路侧 RSU，同时 RSU 会把接收到 OBU 的数据发给路侧边缘计算平台，丰富其数据，提高其算法的准确度。（注： 目前 RSU 作为协议栈的主体，但是随着应用消息种类的增加，RSU 应只负责消息的转发，而路侧边缘计算平台负 责消息栈的实现，这种结构会更能满足未来的发展趋势）。

CF/FC 接口 ：区域计算平台与路侧 RSU 之间的接口，区域计算平台接收业务运营平台下发的数据，区域计算 平台结合实际情况做处理，把数据下发给区域内的 RSU；同时 RSU 会把相关信息发送给区域平台至业务运营平台， 通过这种方式实现跨区域的 RSU 数据交互，比如前方事故预警，可以跨区域进行预警信息的播报。

KF 接口：信号机和路侧 RSU 之间的接口，信号机把红绿灯的信号数据发送给 RSU，支撑绿波引导等场景应用。

KD 接口 ：信号机与路侧边缘计算平台的接口，信号机把红绿灯的信号数据发送到路侧边缘计算平台，路侧 边缘计算平台在使用信号灯数据的同时，可以把数据传输给上层应用平台。

GB/BG、GC/CG 接口 ：车辆 OBU 与区域计算平台和业务运营平台之间的双向接口，OBU 根据需求通过 Uu 口与区域计算平台或业务运营平台进行数据互通。

BU/UB 接口 ：业务运营平台与外部应用的接口，业务运营平台对全域的数据进行挖掘分析，形成整体城市交 通信息，把相应的数据和应用推送给相关的政府城市级应用平台，同时可以根据需求请求外部平台的数据及应用， 形成数据共享。

3.3 业务流向

路侧感知设备（A）采集的传感器数据根据其数据类型和业务需求不同分别输入到业务运营平台（B）、区域计 算平台（C）、路侧边缘计算平台（D）。

路侧边缘计算平台（D）连接多组路侧感知设备（A），进行区内数据融合计算并把结果形成标准的消息帧，把 相应的消息帧传输给区域计算平台（C）、路侧 RSU（F）。

区域计算平台（C）融合多个路侧边缘计算平台（D）数据、业务运营平台（B）数据、OBU（G）车辆自身状态信息， 并将融合感知结果传输给路侧 RSU（F）和路侧通知设备（E），将业务数据传输给业务运营平台（B），实现区 域内和区域间的数据共享。

业务运营平台（B）融合多个区域计算平台（C）的结构化数据、OBU（G）车辆自身状态信息，将业务数据传 输给外部应用（U）中的城市大脑、交警平台、城管平台、MaaS 平台、车企 TSP 平台，进行数据交互共享。同时， 如有需要，业务运营平台（B）可以直接获得路侧感知设备（A）中的实时路侧数据。

路侧 RSU（F）通过 PC5 接口将标准应用数据输送给车载 OBU（G），路侧 RSU 的数据可以来源于路侧边缘 计算平台（D）和区域计算平台（B）。

红绿灯信号信息通过信号机（K）将红绿灯消息输送给路侧RSU（F），路侧RSU进行整合标准的V2X消息进行广播， 如果 RSU 没有信息整合的能力，可以通过路侧边缘计算平台（D）按需求把红绿灯信号消息发送给 RSU。

此外，考虑到某些路侧感知设备智能化水平较高，处理分析结果可满足业务场景应用需求，因此存在路侧感 知设备直接传输数据至 RSU 的过渡场景。

根据图 2.1-1，车路协同网络数据业务流向见表 2.1-1

4 城市场景车路协同网络架构

在城市场景车路协同业务架构的基础上，本文提炼了车路协同网络架构。城市场景车路协同的网络分为接入网， 汇聚网和计算中心网络，网络架构如图 2.2 所示 ：

接入网负责路侧设备、路侧边缘计算平台和车路协同区域计算中心间的信息交互。其中，路侧设备包括 RSU、 智能化路侧感知设备（各类摄像头、激光雷达、毫米波雷达等）、动态交通情报板、路侧气象感知站等，路侧边缘 计算平台可通过对路侧设备输出的原始数据信息进行融合判断，提取结构化道路及目标物状态信息，实现数据的 分析、处理，以支持车路协同多样应用 ；很多车路协同业务在接入路侧网络完成业务流程，对网络实时性和带宽 要求高。接入网的网络架构会有多种模式，以支持边缘计算全分布或相对集中等多种部署方式。

汇聚网把区域计算中心和市级计算中心互联起来，通过接入网把路侧设备和市级业务管理平台互联，完成车 路协同业务信息的汇总和备份，设备的统一网管，支持多个车路协同区域计算中心的汇聚组网。其中单个车路协 同区域计算中心负责区域内 V2X 业务和信息的实时处理，车路协同市计算中心负责全局交通数据汇聚、管理、分析， 以及全局的策略管理和配置发下。

需要说明的是，城市场景车路协同业务架构中的区域计算平台，在网络架构中对应部署于区域计算中心 ；业 务架构中的业务运营平台，在网络架构中对应部署于市级计算中心 ；业务架构中的外部应用平台，在网络架构中 对应部署于智慧城市 / 市政系统。另外，计算中心内部网络，是标准的云中心网络架构 ；市级计算中心的外联网 络为专线网络，这两种网络类型的需求明确，都已经大量部署，有标准的网络方案，故本文不做进一步网络需求 分析。

5 城市场景车路协同网络需求分析

5.1 车路协同业务分析

车路协同业务对网络建设起到导向作用，为了合理研究网络需求，本小节应用场景选自目前行业认可度较高 的业务相关标准，具体为《合作式智能运输系统车用通信系统应用层及应用数据交互标准》（T/CSAE53-2020）（下 文使用标准①代指）、《合作式智能运输系统车用通信系统应用层及应用数据交互标准》（T/CSAE157－2020）（下 文使用标准②代指）、《基于车路协同的高等级自动驾驶数据交互内容》（T/CSAE158 －2020）（下文使用标准③代指）， 并将场景分为安全、效率、信息服务、交通管理四大类，安全类涵盖 13 个业务场景，效率类涵盖 6 个业务场景， 信息服务类涵盖 3 个业务场景，交通管理类涵盖 1 个业务场景。针对每个场景，下文从场景定义和业务流向两方 面进行介绍。

在每个业务场景中，结合相关标准定义以及起草组单位的实际项目经验，本文描述了该应用场景的参考性业 务流向，不构成规范性要求；给出了该应用场景需要的主要交互消息，在实际实现中可根据不同的需求和服务水平， 使用更多的消息。

此外，本小节每一个应用场景均可通过 PC5 通讯和 Uu 通讯两种方式实现。由于不同业务场景的数据处理需 求不同以及设备 / 平台在系统架构中的定位和功能不同，因此根据处理终端不同可划分为以下几种业务流向 ：

5.1.1 PC5通讯方式：

① 处理终端为路侧感知设备 ：目前的感知设备具有简单的数据处理分析功能，当感知设备的处理分析能力可 以满足应用场景时，路侧感知设备即为此场景业务流中的数据处理终端。如前方拥堵提醒场景，目前智能摄像机 可检测道路拥堵排队长度，摄像机将道路排队长度信息推送至 RSU，RSU 广播 RSI 消息，车辆接收后，车载应用 结合自身的定位和行驶数据信息，判断是否进行拥堵提醒。

② 处理终端为路侧边缘计算平台 ：当业务场景对时延有严格要求且需要对感知设备采集的信息进行融合处理时，路侧边缘计算平台为处理终端，既可以满足时延的需求，也可以进行数据融合处理。如交叉路口碰撞预警场 景，路侧边缘计算平台对感知设备采集的信息进行融合处理并推送至 RSU，RSU 周期性广播 RSM 消息，车辆接 收 RSM 消息，车载应用结合自身的定位和行驶数据信息，判断是否需要对驾驶员进行预警。

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

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

5.1.2 Uu通讯方式：

① 处理终端为区域计算平台 ：分为 2 种，一种是区域计算平台直接通过感知设备获取结构化感知数据，并将 结果数据推送至智能网联车辆。另一种是路侧边缘计算平台实现感知数据融合处理，或再结合智能网联车辆的请 求信息，处理生成结果数据并通过区域计算平台将结果数据推送至智能网联车辆。

② 处理终端为区域计算平台 / 业务运营平台：当只需要收集车辆信息，不需要关联路侧感知设备采集的信息、 信号机信息时，平台将预设的消息进行下发或收齐车辆信息进行融合分析，处理终端为区域计算平台 / 业务运营 平台。如浮动车数据采集，车辆上报 BSM 信息至区域计算平台 / 业务运营平台，支持平台形成交通状态评估报告。

5.2 安全类应用场景

5.2.1 限速预警

选自标准①。智能网联车辆行驶过程中，在超出限定速度的情况下，限速预警 SLW 应用对智能网联车辆驾驶 员进行预警，提醒驾驶员减速行驶。

业务流：

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

通过本地配置，RSU 获得 MAP 消息和限速信息（也可以通过平 台下发的方式获得）；

① RSU 周期性广播 MAP 和 RSI 消息，车辆 OBU 接收消息后， 车载应用结合自身的定位和行驶数据信息分析，如果不满足 限速要求，则触发 SLW 预警。

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

车辆周期性上报 BSM 信息，平台通过 Uu 口下发 MAP 消息和 RSI 消息，车辆 OBU 接收后，获取到限速信息，结合车载应用 判断是否需要对驾驶员进行预警。

5.2.2 闯红灯预警

选自标准①。智能网联车辆经过有信号控制的交叉口 ( 车道 )，车辆存在不按信号灯规定或指示行驶的风险时， 闯红灯预警 RLVW 应用对驾驶员进行预警。

业务流：

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

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

② RSU 对外广播 SPAT 消息和 MAP 消息，车辆 OBU 接收后， 车载应用结合自身的定位和行驶数据信息，判断是否需要对 驾驶员进行预警。

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

平台通过 Uu 口下 SPAT、MAP 消息，车辆 OBU 接收到后结合 车载应用判断是否需要对驾驶员进行预警。

5.2.3 基于路侧感知的“僵尸车”识别

选自标准③。自动驾驶车辆在真实路况行驶时，常因其他物体遮挡而存在感知盲区，并且车辆的感知距离有限。 “僵尸车”指一定时间内停放到道路禁停区域内的车辆。基于路侧感知的“僵尸车”识别指在混合交通环境下，由 路侧感知设备不断感知周边道路交通信息，动态的识别出其覆盖范围内的“僵尸车”，并将感知结果通过 RSU 或 平台发送给智能网联车辆，辅助车辆做出正确的决策控制。由于感知设备（如摄像头）具有“僵尸车”识别功能， PC5 通讯中，不需要边缘计算单元处理，感知设备可直接将识别结果通过 RSU 进行广播，为车辆提供预警。

业务流：

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

① 感知设备将感知到的“僵尸车”信息发给 RSU ；

② RSU 广播 SSM 消息，智能网联汽车 OBU 接收到信息后结合 自身的定位和行驶数据信息，生成路径规划，避让“僵尸车”。

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

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

② 感知设备实时上报“僵尸车”信息至区域计算平台 ；

③ 平台通过 Uu 口对进入范围的车辆推送 SSM 消息，OBU 接 收后，车载应用结合自身的定位和行驶数据信息，生成路径 规划，避让“僵尸车”。

5.2.4 交叉路口碰撞预警

选自标准①。当智能网联车辆驶向交叉路口，与侧向行驶的车辆存在碰撞危险时，交叉路口碰撞预警 ICW 应 用将对智能网联车辆驾驶员进行预警。

业务流：

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

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

② 路侧边缘计算平台将处理后的消息发送至 RSU ； ③ RSU 广播 RSM 消息，车辆 OBU 接收后，车载应用结合自身 的定位和行驶数据信息，判断是否需要对驾驶员进行预警。

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

① 车辆周期性向区域计算平台上报 BSM 信息 ；

② 路侧感知设备将感知到的车辆信息发送至路侧边缘计算平 台，平台进行融合计算 ；

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

④ 区域计算平台通过 Uu 口对进入范围的车辆推送 RSM 消息， 车辆 OBU 接收后，车载应用结合自身的定位和行驶数据信息， 判断是否需要对驾驶员进行交叉口碰撞预警。

5.2.5 左转辅助

选自标准①。当智能网联车辆在交叉路口左转，与对向驶来的车辆存在碰撞危险时，左转辅助功能 LTA 应用 将对智能网联车辆驾驶员进行预警。

业务流：

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

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

② 路侧边缘计算平台将处理后的消息发送至 RSU ；

③ RSU 广播 RSM 消息，车辆 OBU 接收后，车载应用结合自身 的定位和行驶数据信息，判断是否需要对驾驶员进行预警。

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

① 车辆周期性向区域计算平台上传 BSM 信息 ；

② 路侧感知设备将感知到的车辆信息发送至路侧边缘计算平 台，平台进行融合计算 ；

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

④ 区域计算平台通过 Uu 口对进入范围的车辆推送 RSM 消息， 车辆 OBU 接收到后，车载应用结合自身的定位和行驶数据 信息，判断是否需要对驾驶员进行预警。

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

选自标准①。智能网联车辆在行驶中，与周边行人（含义拓展为广义上的弱势交通参与者，包括行人、自行车、 电动自行车等）存在碰撞危险时，弱势交通参与者碰撞预警 VRUCW 应用将对车辆驾驶员进行预警。

业务流：

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

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

② 路侧边缘计算平台将处理后的消息发送至 RSU ；

③ RSU 广播 RSM 消息，车辆的 OBU 接收后，车载应用结合自 身的定位和行驶数据信息进行判断，若存在弱势交通参与者 碰撞风险，则对驾驶员进行预警。

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

① 车辆周期性向区域计算平台上报 BSM 信息 ；

② 路侧感知设备将感知到的交通参与者信息发送至路侧边缘计 算平台，平台进行融合计算 ；

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

④ 区域计算平台通过 Uu 口对进入范围的车辆推送 RSM 消息， OBU 接收到后，车载应用结合自身的定位和行驶数据信息进 行判断，若存在弱势交通参与者碰撞风险，则对驾驶员进行 预警。

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

选自标准③。自动驾驶车辆在真实路况行驶时，如果能提前得知周边存在的异常驾驶的车辆，则可以更好的 辅助车辆进行路径的规划。基于协同式感知的异常驾驶行为识别指在混合交通环境下，可以通过路侧感知设备不 断感知周边车辆的运行状况，实时的识别当前范围内所存在的异常行驶的车辆，例如逆行车辆、慢行车辆（行驶 速度明显低于其他车辆）、快行车辆（行驶速度明显高于其他车辆）等，并将感知结果发送给自动驾驶车辆，辅助 车辆做出正确的决策控制。

业务流：

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

① 路侧感知设备将感知信息发送给路侧边缘计算平台 ；

② 路侧边缘计算平台将处理后的数据发送至 RSU ；

③ RSU 广播 SSM 消息 , 车辆 OBU 接收后，车载应用结合自身 的定位和行驶数据信息，制定车辆的行驶策略。

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

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

② 路侧感知设备将感知信息发送至路侧边缘计算平台，平台进 行融合计算 ；

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

④ 区域计算平台通过 Uu 口对进入范围的车辆推送 SSM 消息， 车端接收到后，车载应用结合自身的定位和行驶数据信息， 制定车辆的行驶策略。

5.2.8 感知数据共享

选自标准②。路侧感知设备探测到周围其他交通参与者（包括车辆、行人、骑行者等目标物）或道路异常状 况信息，如：道路交通事件（如交通事故等）、车辆异常行为 ( 超速、驶离车道、逆行、非常规行驶和异常静止等 )、 道路障碍物（如落石、遗撒物、枯枝等）及路面状况（如积水、结冰等）等信息，并将探测到的信息发送至其他车 辆，实现感知数据共享。

业务流：

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

① 路侧感知设备将感知信息传输至路侧边缘计算平台 ；

② 路侧边缘计算平台处理生成交通参与者信息或道路异常状况 信息 ；并将信息发送至 RSU ；

③ RSU 广播 SSM 消息，OBU 接收到后结合车载应用判断是否 进行预警 / 提示等。

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

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

② 路侧感知设备感知到数据上报路侧边缘计算平台，平台进行 融合计算 ；

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

④ 区域计算平台通过 Uu 口推送 SSM 消息至智能网联车辆， OBU 接收到后结合车载应用判断是否进行预警 / 提示等。

5.2.9 协作式变道

选自标准②。智能网联车辆在行驶过程中需要变道，将行驶意图发送至路侧边缘计算平台或区域计算平台， 平台通过路侧感知设备收集道路车辆信息，综合处理生成调度信息发送至车辆，车辆根据自身情况调整驾驶行为， 使得智能网联车辆能够安全完成变道或延迟变道。

业务流：

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

① 智能网联汽车向 RSU 发送行驶意图信息 VIR ；

② RSU 将车辆行驶意图信息发送至路侧边缘计算平台 ；

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

④ 路侧边缘计算平台综合收集到的信息进行处理，生成调度信 息，发送至 RSU ；

⑤ RSU 广播调度信息 RSC，OBU 接收后结合车载应用分析，完 成变道或延迟变道。

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

① 车辆周期性上报 BSM 消息，并上报 VIR 消息至区域计算平台；

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

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

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

⑤ 区域计算平台通过 Uu 口发送 RSC 消息至车辆，OBU 接收后 结合车载应用分析，完成变道或延迟变道。

5.2.10 协作式车辆汇入

选自标准②。在道路入口匝道处，通过汇聚周边车辆信息进而生成调度信息，协调匝道和主路汇入车道车辆， 引导匝道车辆安全、高效的汇入主路。

业务流：

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

• RSU 引导匝道车辆汇入

① 智能网联汽车向 RSU 发送行驶意图信息 VIR ；

② RSU 将车辆行驶意图信息发送至路侧边缘计算平台 ；

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

④ 路侧边缘计算平台综合收集到的信息进行处理，生成调度信 息，发送至 RSU ；

⑤ RSU 广播 RSC 消息，车辆的 OBU 接收消息后，结合自身行 驶状态以及道路信息、周围交通参与者信息，生成最终的驾 驶行为策略或轨迹规划，安全有效地通过路口。

• 协作式匝道信号控制

① 智能网联车辆向 RSU 发送行驶意图信息 VIR ；

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

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

④ 路侧边缘计算平台结合主路、匝道支路交通流情况，生成信 号优化策略下发至信号机，以保证主路通畅 ；

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

⑥ RSU 广播 RSC 消息，位于主路或匝道的智能网联车辆 OBU 接收到驾驶引导信息后，结合车载设备应用分析，安全高效 通行。

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

• 区域计算平台引导匝道车辆汇入

① 车辆周期性上传 BSM 消息并上报 VIR 消息至区域计算平台 ；

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

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

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

⑤ 区域计算平台通过 Uu 口下发 RSC 消息至车辆，OBU 接收到 后，结合自身行驶状态以及道路信息、周围交通参与者信息， 生成最终的驾驶行为策略或轨迹规划，安全有效地通过路口。

• 协作式匝道信号控制

① 主路和匝道支路的智能网联车辆向区域计算平台上报车辆 BSM 消息和 VIR 消息 ；

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

③ 路侧感知设备上传主路与匝道交通信息至路侧边缘计算平台， 平台综合感知信息与车辆 BSM、VIR 等消息进行融合计算， 生成信号优化策略 ；

④ 路侧边缘计算平台将生成的信号优化策略下发至信号机，以 保证主路通畅 ；

⑤ 路侧边缘计算平台将处理后的结果数据上报至区域计算平台； ⑥ 区域计算平台同时通过 Uu 口下发 RSC 消息至车辆，位于主 路或匝道的智能网联车辆接收到驾驶引导信息后，结合车载 设备应用分析，安全通行。

5.2.11 协作式交叉口通行

选自标准②。根据即将准备通过路口的车辆行驶信息、目标交叉路口的信号灯信息、其他车辆上报的行驶信息、 以及路侧感知信息，生成通过交叉路口的通行调度信息并发送给智能网联车辆，调度车辆安全通过交叉口。

业务流：

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

• RSU 提前引导车辆换道行驶 /RSU 辅助车辆通过无信号灯控制 的交叉路口

① 智能网联汽车向 RSU 发送行驶意图信息 VIR ；

② RSU 将车辆行驶意图信息发送至路侧边缘计算平台 ；

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

④ 路侧边缘计算平台综合收集到的信息进行处理，生成调度信 息，发送至 RSU ；

⑤ RSU 广播 RSC 消息，车辆 OBU 接收消息后，结合自身行驶 状态以及道路信息、周围交通参与者信息，生成最终的驾驶 行为策略或轨迹规划，进行换道行驶或根据引导信息安全高 效地通过无信号灯路口。

• 协作式交叉口信号控制场景

① 智能网联车辆向 RSU 发送行驶意图信息 VIR ；

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

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

④ 路侧边缘计算平台结合路口交通流情况，生成信号优化策略 下发至信号机 ；

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

⑥ RSU 广播 RSC 消息，车辆接收到驾驶引导信息后，结合自身 行驶状态以及道路信息、周围交通参与者信息，生成最终的 驾驶行为策略或轨迹规划，安全高效地通过路口。

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

• 区域计算平台提前引导车辆换道行驶 / 区域计算平台辅助车辆 通过无信号灯控制的交叉路口

① 车辆周期性上传 BSM 消息并上报 VIR 消息至区域计算平台 ；

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

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

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

⑤ 区域计算平台通过 Uu 口发送 RSC 消息，车辆 OBU 接收消 息后，结合自身行驶状态以及道路信息、周围交通参与者信息， 生成最终的驾驶行为策略或轨迹规划，进行换道行驶或根据 引导信息安全高效地通过无信号灯路口。

• 协作式交叉口信号控制

① 智能网联车辆向区域计算平台上报车辆BSM消息和VIR消息；

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

③ 路侧感知设备上传道路交通信息至路侧边缘计算平台，平台 综合感知信息与车辆 BSM、VIR 等消息进行融合计算，生成 信号优化策略 ；

④ 路侧边缘计算平台将生成的信号优化策略下发至信号机 ；

⑤ 路侧边缘计算平台将处理后的结果数据上报至区域计算平台。 ⑥ 区域计算平台通过 Uu 口下发 RSC 消息至车辆，车辆 OBU 接收消息后，结合自身行驶状态以及道路信息、周围交通参 与者信息，生成最终的驾驶行为策略或轨迹规划，安全高效 地通过路口。

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

选自标准③。正常情况下，自动驾驶车辆在行驶过程中依赖车辆感知设备感知周边环境，并将感知结果作为 车辆决策控制的输入，即自动驾驶车辆自身输出决策控制策略，在某些极端情况下，出现自动驾驶车辆无法应对 的场景时，自动驾驶车辆停止自动驾驶。自动驾驶车辆发送请求信息，RSU/ 平台下发控制消息，使得车辆“脱困”。

业务流：

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

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

① 智能网联汽车向 RSU 发送求助信息 VIR ；

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

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

④ 路侧边缘计算平台处理生成调度信息，发送至 RSU ；

⑤ RSU 广播 CIM、RSC 消息，智能网联车辆接收后，按调度信 息行驶，为受困车辆让行。

• 基于路侧控制的自动驾驶车辆“脱困”

① 智能网联汽车向 RSU 发送求助信息 VIR ；

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

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

④ 路侧边缘计算平台处理生成调度信息，发送至 RSU ；

⑤ RSU 广播 CIM、RSCV 消息，智能网联车辆接收后，按引导 信息行驶并发送响应消息。

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

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

① 车辆周期性上传 BSM 信息和请求消息 VIR 至区域计算平台 ；

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

③ 路侧感知设备将周围路况信息上传至路侧边缘计算平台，平 台综合感知信息与车辆 BSM、VIR 等消息进行融合计算 ；

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

⑤ 区域计算平台通过 Uu 口下发 CIM、RSC 消息，智能网联车 辆接收后，按调度信息行驶，为受困车辆让行。

• 基于路侧控制的自动驾驶车辆“脱困”

① 智能网联汽车向区域计算平台发送求助信息 VIR ；

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

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

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

⑤ 区域计算平台通过 Uu 口向车辆发送 CIM、RSCV 消息，智能 网联车辆接收后，按引导信息行驶并发送响应消息。

5.2.13 道路危险状况提示

选自标准①。智能网联车辆行驶到潜在危险状况(如桥下存在较深积水、路面有深坑、道路湿滑、前方急转弯等 ) 路段，存在发生事故风险时，道路危险状况提示 HLW 应用对智能网联车辆驾驶员进行预警。

业务流：

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

① 通过业务运营平台下发道路危险状况信息至区域计算平台（区 域计算平台也可以通过本地配置的方式得到）；

② 区域计算平台将信息下发至 RSU（RSU 也可以通过本地配置 的方式得到）；

③ RSU 周期性广播 RSI 消息，车辆 OBU 接收 RSI 消息，车载 应用结合自身的定位和行驶数据信息，判断是否进行道路危 险状况提示。

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

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

② 平台匹配信息，通过 Uu 口对行车路线上的车辆推送 RSI 消息， 车载应用结合自身的定位和行驶数据信息，判断是否进行道 路危险状况提示。

5.3 效率类应用场景

5.3.1 动态车道管理

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

业务流：

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

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

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

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

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

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

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

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

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

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

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

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

5.3.2 绿波车速引导

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

业务流：

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

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

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

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

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

5.3.3 前方拥堵提醒

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

业务流：

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

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

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

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

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

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

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

5.3.4 协作式优先车辆通行

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

业务流：

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

• 提前预留车道

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

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

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

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

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

• 车道禁行 / 封闭场景

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

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

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

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

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

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

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

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

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

• 提前预留车道

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

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

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

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

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

• 车道禁行 / 封闭场景

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

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

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

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

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

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

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

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

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

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

业务流：

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

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

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

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

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

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

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

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

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

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

5.3.6 车内标牌

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

业务流：

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

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

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

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

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

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

5.4 信息服务类应用场景

5.4.1 差分数据服务

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

业务流：

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

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

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

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

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

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

5.4.2 场站路径引导服务

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

业务流：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

业务流：

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

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

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

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

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

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

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

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

5.5 交通管理类应用场景

5.5.1 浮动车数据采集

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

业务流：

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

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

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

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

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

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

6 业务时延模型分析

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

6.1 PC5通讯方式

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

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

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

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

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

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

总时延 =2×传输时延_{RSU广播传输时延}＋传输时延_OBU至RSU ＋处理时延_ARSU ＋处理时延B_{智能网联车辆}

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

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

总时延 = 传输时延 A _{信号机至RSU} ＋传输时延 B_{RSU广播传输时延}＋处理时延 _ARSU ＋处理时延 B _{智能网联车辆}

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

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

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

总时延 = 传输时延 A _{路侧感知设备至RSU} ＋传输时延 B_{RSU广播传输时延}＋ 处理时延 A_{路侧感知设备}＋处理时延 B_RSU ＋处理时延 C _{智能网联车辆}

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

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

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

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

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

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

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

总时延 =MAX（传输时延 A_OBU至RSU ＋传输时延 B_{RSU至路侧边缘计算平台} ＋处理时延 C_RSU，传输时延 C _{路侧感知设备至路侧边缘计算平台}＋处理时延 A _{路侧感知设备}）＋传输时延 D _{路侧边缘计算平台至RSU} ＋传输时延 E_{RSU广播传输时延} ＋处理时延 B _{路侧边缘计算平台}＋处理时延 C_RSU ＋处理时延 D _{智能网联汽车}

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

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

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

总时延 =MAX（传输时延 A_OBU至RSU ＋传输时延 B_{RSU至路侧边缘计算平台} ＋处理时延 C_RSU，传输时延 C _{路侧感知设备至路侧边缘计算平台}＋处理时延 A _{路侧感知设备}）＋传输时延 D _{路侧边缘计算平台至RSU} ＋传输时延 E_{RSU广播传输时延} ＋处理时延 B _{路侧边缘计算平台}＋处理时延 D _{智能网联汽车}

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

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

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

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

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

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

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

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

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

总时延 = 传输时延 A_OBU至RSU ＋传输时延 B_{RSU至区域计算平台}＋传输时 延 C _{区域计算平台至业务运营平台}＋处理时延 A_RSU ＋处理时延 B _{区域计算平台}

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

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

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

6.2 Uu通讯方式

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7.1 RSU 部署

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

7.1.1 RSU一般部署原则

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

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

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

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

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

7.1.2 场景部署

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

7.1.2.1 长直道路

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

7.1.2.2 道路交叉口

7.1.2.2.1 丁字路口

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

7.1.2.2.2 十字路口

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

7.1.2.3 特定区域

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

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

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

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

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

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

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

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

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

2. 网络时钟同步精度

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

7.2 感知系统部署

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

7.2.1 典型场景部署原则

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

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

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

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

7.2.1.1 长直道路

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

7.2.1.2 道路交叉路口

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

7.2.1.3 特定点位和区域

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

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

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

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

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

7.2.2 分场景部署

7.2.2.1 长直道路

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

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

7.2.2.2 道路交叉路口

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

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

7.2.2.3 特定区域

7.2.2.3.1 环岛

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

7.2.2.3.2 公共场所

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

7.2.2.3.3 急弯盲区

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

7.2.2.3.4 过村段

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

7.2.2.3.5 乡村交叉口

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

7.2.2.3.6 山区盲陡易滑坡

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

7.2.2.3.7 匝道

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

7.2.2.3.8 隧道场景

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

7.3 网络带宽需求分析

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

表 路侧设备的带宽需求

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

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

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

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

8.1 接入网络总体架构

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

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

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

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

8.2 接入网络功能需求

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

9.2 网络运维平台需求

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

1. 业务开通

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

2. 网络全量设备可监可控

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

3. 面向业务的场景监控

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

4. 巡检管理

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

5. 基础信息监控

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

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

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

7. 远程升级管理

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

8. SLA 服务指标监控

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

9. 网络拓扑发现

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

10. 网络资源管理

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

11. 设备 IP、MAC 安全管理

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

12. 配置管理

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

13. 安全管理

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

14. 远程故障诊断

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