基于公用通信网络的区域级 C-V2X应用系统技术要求 应用系统技术要求

Posted 2023-01-06 爱是与世界平行

1 范围

本文件规定了基于公用通信网络的区域级C-V2X应用系统的技术、功能和场景要求。

本文件适用于基于公用通信网络的区域级C-V2X应用系统技系统设计和建设，为智能网联汽车与产业相关部门和企业提供标准化共性基础服务。

2 规范性引用文件

下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅所注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。

YD/T 3709-2020 基于LTE的车联网无线通信技术 消息层技术要求

YD/T 3340-2018 基于LTE的车联网无线通信技术 空中接口技术要求

T/CASE 53-2020 合作式智能运输系统 车用通信系统 应用层及应用数据交互标准(第一阶段)

T/CSAE 157-2020 合作式智能运输系统 车用通信系统 应用层及应用数据交互标准（第二阶段）

T/ITS 0098-2017 合作式智能运输系统 通信架构

3 术语和定义

下列术语和定义适用于本文件。

3.1 V2X 车用无线通信技术 V2X wireless communication technology for vehicles

车载单元与其他设备通讯，包括但不限于车载单元之间通讯（V2V），车载单元与路侧单元通讯（V2I）,车载单元与行人设备通讯（V2P），车载单元与网络之间通讯（V2N）。

3.2 C-V2X 基于蜂窝网络的车用无线通信技术 cellular vehicle to everything

C-V2X 中的 C 是指蜂窝（Cellular），它是基于 4G/5G 等蜂窝网通信技术演进形成的车用无线通信技术，包含了两种通信接口:一种是车、人、路之间的短距离直接通信接口（PC5），另一种是终端和基站之间的通信接口（Uu），可实现长距离和更大范围的可靠通信。C-V2X 是基于 3GPP 全球统一标准的通信技术，包含 LTE-V2X 和 5G-V2X。

3.3 短程无线通信 dedicated short range communication

用于车辆、基础设施等交通要素之间进行短程通信的无线通信方式。

3.4 第Ⅰ类服务类型

第Ⅰ类服务类型支持自动驾驶的数据服务，编号Ⅰ。

3.5 第Ⅱ类服务类型

第Ⅱ类服务类型支持辅助驾驶的数据服务，编号Ⅱ。

4 符号和缩略语

T/CASE 53-2020、T/CSAE 157-2020、T/ITS 0098界定的以及下列缩略语适用于本文件。

C-V2X：基于蜂窝网络的车用无线通信技术（Cellular Vehicle to Everything）

NR-V2X：5G V2X（New Radio V2X）

LBS:基于位置的服务（Location Based Services）

SBA：以服务为基础的架构（Service Based Architecture）

eMBB：增强移动宽带（Enhanced Mobile Broadband）

URLLC：超可靠低延迟通信（Ultra Reliable Low Latency Communication）

SPAT：信号灯相位与配时消息（Signal Phase and Timing Message）

MAP：地图消息

RSI：路侧消息（Roadside Information）

RSW：路侧安全消息（Roadside Safety Message）

APP：应用程序

RTK: 实时差分定位

SSR: 状态空间表达，常用于精确点定位

OEM：原始设备制造商（Original Equipment Manufacturer）

5 基于公用通信网络的区域级 C-V2X 应用系统

5.1 系统架构

车路云一体化融合控制系统，主要由云控应用平台、云控基础平台、路侧设施设备、通信网、车辆及其他交通参与者以及相关支撑平台构成，其各子系统通过外部网络进行数据交互。本标准中基于公用通信网络的区域级C-V2X应用系统从属于云控应用平台。此应用与云控基础平台的区域云范围内存在数据交互关系，见图1和附录A。

平台主要功能如下：

a) 云控基础平台：云控基础平台以车辆、道路、环境等实时动态数据为核心， 结合支撑云控应用的已有交通相关系统与设施的数据，为智能网联汽车与产业相关部门和企业提供标准化共性基础服务，见图 1 和图 2。

b) 云控应用平台主要涉及管理机构、第三方机构、汽车企业等管理、监管和应用单位，并提供非实时应用和实时协同应用服务，见图 1。

c) 区域级 C-V2X 应用系统：该服务中包含车辆注册管理、地理围栏服务、场景服务三类基础服务，亦可灵活扩展其他应用服务。主要应用云控基础平台所提供的数据为地理围栏范围内车辆提供相应场景数据服务，见图 2。

5.2 系统功能

公用通信网络的区域级C-V2X应用系统由车辆注册管理、地理围栏服务、场景服务等功能组成，并与云控基础平台互联互通，采用通讯技术和地理围栏技术，能够通过公用通信网络向区域内车辆提供车联网基础数据信息、应用层版本信息，向平台提供场景服务类型分类信息。该系统应融合数据运算，网络技术和位置服务，能够实现区域内车辆与C-V2X车联网应用云的通信。

5.2.1 云控基础平台

云控基础平台在功能上应至少具备以下3部分：

a) 边缘云：边缘云是云控基础平台中最接近车辆及道路等端侧的运行环境,主要面向网联汽车提供增强行车安全的实时性与弱实时性云控应用基础服务。

b) 区域云：区域云面向区域级交通监管与交通执法以及域内车辆等提供基础服务，是多个边缘云的汇聚点, 主要面向交通运输和交通管理部门提供弱实时性或非实时性交通监管、执法等云控应用的基础服务，并面向网联汽车提供提升行车效率和节能性的弱实时性服务。

c) 中心云：中心云面向交通决策部门、车辆设计与生产企业、交通相关企业及科研单位， 基于多个区域云数据的汇聚，为其提供多维度宏观交通数据分析的基础数据与数 据增值服务,主要面向交通决策部门、车辆设计与生产企业、 交通相关企业及科研单位，提供宏观交通数据分析与基础数据增值服务。

5.2.2 云控应用平台

云控应用主要包括增强行车安全和提升行车效率与节能性的智能网联驾驶应用、提升交通运行性能的智能交通应用，以及车辆与交通大数据相关应用。根据云控应用对传输时延要求的不同，可以分为实时协同应用和非实时协同应用。

5.2.3 区域级 C-V2X 应用系统

5.2.3.1 应用服务

区域级 C-V2X 应用系统基于云控应用平台，主要为客户提供以下 3 类应用服务：

a) 基础服务：为应用和机制提供基础数据服务，便于建立管理机制；

b) 公共服务：为公众提供全过程安全监管、城市交通规划、智能救援、互动管理、保险、租赁、数据共享等服务，提高公共出行建设和出行效率；

c) 产业服务：为 OEM 厂商提供 C-V2X 服务。

5.2.3.2 功能模块

C-V2X 应用服务应至少包含以下功能模块：

a) 车辆注册管理：对进入 C-V2X 服务区域内的车辆进行域内 C-V2X 服务使能注册，授权，并分配Token，密钥以及该平台所提供场景服务类型分类返回外部云，从而最终传递给车机端应用于C-V2X 服务；

b) 地理围栏服务：根据车机端上报的位置信息判断车辆是否处于 C-V2X 服务区域内并返回结果的典型 LBS 服务，其中 C-V2X 服务区域可根据基础设施布设开通情况进行更新；

c) 场景服务：将平台可以提供的 C-V2X 服务分类打包并分别提供给不同类型 5G 网络切片使用；

d) 地理位置校正服务：该服务通过连续接收卫星数据并进行优化各种主要的系统误差源，如电离层误差、对流层误差、轨道误差和多径效应，建立了全网电离层延迟和对流层延迟的误差模型。优化后空间误差将被经由云控基础平台和 RSU 通过 PC5 口直接下发到车辆用于 C-V2X 高精定位。

6 基础要求

6.1 通讯技术要求

6.1.1 4G/5G 网络通讯

车辆通过4G/5G与C-V2X应用建立安全连接后，获取到相应的场景服务相应分类，应具备：

a) 5G 切片功能车机通过 Uu 口获取到切片后具有不同 Qos 的数据；

b) 接收 C-V2X 消息集能力车辆通过 4G/5G Uu 口移动通信网络首先与车厂 C-V2X 云建立，进而再与 C-V2X 应用建立安全连接；

c) 短程、远程无线通信能力的路侧设备，将有关交叉口（车道）信息广播给具有短程通信能力的车辆（V2I）；

d) 短程无线通信能力的路侧设备，将道路数据与信号灯实时状态数据，发送给车辆（V2I）。

6.1.2 5G 网络切片通讯

其中终端（UE）侧支持按照应用选择接入不同的切片，相关C-V2X应用APP分化为两类：第一类支持自动驾驶；第二类支持辅助驾驶。

这两类APP将会选择不同的切片。第一类会选择时延和可靠性更优的URLLC切片，第二类选择eMBB切片。根据场景服务类型分类中的定义，车机端会得到从车联网区域应用云下发的该车辆场景服务类型结果，为车机端C-V2X应用APP选择不同切片提供签约判断依据，为使用两类APP提供入口判断。

6.2 系统数据交互

在实际应用中，各功能模块之间存在各种各样的信息交互。各个模块间以及系统内原始感知数据、控制数据等的数据流，详见附件B-D所示。

6.2.1 车端与 C-V2X 应用数据交互

车端在完成注册后发送BSM消息到C-V2X应用，后者根据该车机能力和当前通信方式，通过标准C-V2X应用标准消息集选择下发不同场景数据供车端使用。同时为解决应用层版本协议更迭可能产生的版本不匹配问题，在标准BSM消息外叠加标注版本号信息来解决此问题，从而保证服务的完整性和可持续性。

6.2.1.1 基本工作原理

车辆完成了注册流程，收到了正确信息后，车端能够开始与C-V2X应用进行应用数据（如：BSM、MAP、SPAT等）交互，必须在上下行消息中新增非对称消息头。

a) 车端上行发送包含特殊头部的 BSM 消息到 C-V2X 应用并与之交互；

b) C-V2X 应用下发叠加头部的下行消息（MAP、SPAT、RSI 等），消息结构如图 5 所示；

c) 上下行消息交互频率应符合如下表 3 推荐值。

消息	上/下行方式	发送频率
BSM	上报	10HZ
SPAT	下发	2HZ
MAP	下发	2HZ
RSI静态	下发	1HZ
RSI半静态	下发	2HZ
RSI动态	下发	10HZ
RSM	下发	1HZ

6.2.1.2 数据交互要求

数据交互过程中针对数据、单位等应满足表4要求。

数据	单位	备注
OEMID	string	标识接入 C-V2X 应用车辆生产厂
上行报文大版本号	string	BSM 消息应用层版本号目前设置始终为 1
上行报文小版本号	string	BSM 消息应用层版本号与大版本号配合使用比如 10 表示 17 版本；11 表示 19 版本
下行报文大版本号	string	车端请求云端下发消息应用层版本号目前设置始终为 1
下行报文小版本号	string	车端请求云端下发消息应用层版本号与大版本号配合使用比如 10 表示 17 版本；11 表示 19 版本

注：其他上下行消息如BSM,MAP,SPAT,RSI参考国家发布相关标准。

6.3 场景服务类型

具备不同通信和自动驾驶能力的汽车在完成区域内C-V2X服务注册后，由C-V2X应用分配不同的场景服务类型，从而匹配下发不同等级粒度的服务数据到车端。其中具有5G能力的车辆还可以通过5G网络特有的切片功能，使用到不同切片，不同Qos的数据服务。

结合车辆联网模式以及车辆分类，最终给车辆分配合适的场景服务类型并下发到车机端。对于此场景服务类型的分类，也可以手动修改单车结果，将5G和NR-V2X的网络连接方式下输出结果集合减小。

7 功能要求

7.1 车辆注册管理

具备接收C-V2X消息集能力车辆在进入C-V2X服务区域后，上报车辆注册信息到C-V2X应用完成C-V2X服务使能，为车辆后续提供匹配的数据服务。

7.1.1 基本工作原理

车辆完成了注册流程，收到了正确信息后，车机端能够开始与C-V2X应用进行应用数据（如：BSM、MAP、SPAT等）交互，必须在上下行消息中新增非对称消息头。

a) 车端通过内置的整车厂 C-V2X 云系统地址以及各整车厂内部安全机制与整车厂 C-V2X 云系统通信上传车辆位置，再由整车厂 C-V2X 云系统与地理围栏服务交互，通过后者判断当前车辆是否处于 C-V2X 服务区域内，如果在区域内则直接返回该区域所对应的基础数据平台地址，反之，终止流程等待下次车端再次发起；

b) 注册过程由整车厂 C-V2X 云系统收集到车辆相关信息后发起，发送携带区域云平台分配给整车厂的不同代码以及车辆唯一标识信息到接入车辆管理模块，由其完成注册，并返回车辆是否注册成功状态给整车厂 C-V2X 云系统；

c) 上传整车厂代码、车辆信息、接入网络类型信息给接入车辆管理模块和场景服务类型分类模块以获取车辆的加密密钥（KEY），令牌（TOKEN）和该车辆的场景服务类型，以及基础数据平台地址并最终透传给相应车辆；

7.1.2 通信方式

车辆通过4G/5G Uu口移动通信网络与C-V2X应用建立安全连接。

7.1.3 主要技术要求

车辆注册管理的主要技术要求如下：

a) 定位精度≤10m；

b) 车速范围：0-120 km/h；

c) 5G 支持切片功能。

7.1.4 数据交互要求

车辆注册的消息结构如下表1所示。

表1 车辆注册的消息结构

7.2 场景服务

7.2.1 闯红灯预警

闯红灯预警（RLVW: Red Light Violation Warning）是指车辆经过有信号控制的交叉口（车道），

车辆存在不按信号灯规定或指示行驶的风险时，RLVW应用对驾驶员进行预警。本应用适用于城市及郊区道路及公路的交叉路口、环道的出入口和可控车道、高速路入口和隧道等有信号控制的车道。

7.2.1.1 基本工作原理

当车辆驶向具有信号控制的交叉路口（车道），遇信号灯即将变红或正处在红灯状态，但车辆未能停止在停止线内而继续前行时，RLVW应用将对该车驾驶员进行预警。

闯红灯预警流程如下：

a) 具有短程、远程通信能力的路侧单元（RSU）定时发送路口地理信息和信号灯实时状态信息；

b) 车辆依据本身 GNSS 地理信息，确定当前受管控信号的相位，并计算其与停止线的距离；

c) 车辆依据当前速度和其他交通参数预估到达路口的时间；

d) RLVW 将这些信息与接收到的红灯切换时刻及红灯保留时长信息进行对比分析，决定是否预警。

7.2.1.2 通信方式

具备短程、远程无线通信能力的路侧设备，将有关交叉口（车道）信息广播给具有短程通信能力的车辆（V2I）。

7.2.1.3 主要技术要求

RLVW基本主要技术要求如下：

a) 车辆车速范围（0～70）km/h；

b) 通信距离≥150m；

c) 数据更新频率典型值5Hz；

d）系统延迟≤100ms；

e）定位精度≤1.5m。

7.2.1.4 数据交互要求

数据	属性	备注
时刻	ms	-
路口 ID	-	-
入口 ID	-	-
车道宽度	m	-
车道中心线位置	deg	-
停车线位置	deg	-
车道属性	-	-
车道所属相位	deg	-
当前灯态	-	-
红绿灯剩余时间	s	-
红绿灯配时是否自适应控制	-	-

7.2.2 绿波车速引导

绿波车速引导（GLOSA: Green Light Optimal Speed Advisory）是指当装载车载单元（OBU）的车辆驶向信号灯控制交叉路口，收到由路侧单元（RSU）发送的道路数据及信号灯实时状态数据时，GLOSA 应用将给予驾驶员一个建议车速区间，以使车辆能够经济地、舒适地（不需要停车等待）通过信号路口。

7.2.2.1 基本工作原理

绿波车速引导工作原理如下：

a) 车辆根据收到的道路数据，以及本车的定位和运行数据，判定本车在路网中所处的位置和运行方向；

b) 判断车辆前方路口是否有信号灯，提取信号灯对应相位的实时状态；若有信号灯信息，则可直接显示给驾驶员；

c) GLOSA 应用根据本车的位置，以及信号灯对应相位的实时状态，计算本车能够在本次或下次绿灯期间不停车通过路口所需的最高行驶速度和最低行驶速度，并进行提示。

7.2.2.2 通信方式

具备短程无线通信能力的路侧设备，将道路数据与信号灯实时状态数据，发送给车辆（V2I）。

7.2.2.3 主要技术要求

GLOSA基本主要技术要求如下：

a) 车辆车速范围（0～70）km/h；

b) 通信距离≥150m；

c) 数据更新频率典型值5Hz；

d）系统延迟≤200ms；

e）定位精度≤1.5m；

f) 道路数据集更新频率典型值1Hz。

7.2.2.4 数据交互要求

数据	属性	备注
时刻	ms	-
节点	-	-
路段	-	-
车道	-	-
连接转向关系	deg	-
静态信息	-	-
实时状态信息	-	-
转向-相位关系	deg	-

7.2.3 红绿灯信息推送

红绿灯信息推送（TLI: Traffic Light Information）当装载车载单元（OBU）的车辆收到由路侧单元（RSU）发送的道路数据以及交通信号灯信息，TLI应用将给予驾驶员相应的交通信号灯信息，保证车辆的安全行驶。本应用适用于任何交通道路场景。

7.2.3.1 基本工作原理

红绿灯信息推送流程如下：

a) 车辆根据收到的道路数据，以及本车的定位和运行数据，判定本车在路网中所处的位置和运行方向；

b) 判断车辆前方道路是否有红绿灯数据，以及在当前时间段该红绿灯数据是否有效。若是，则直接显示给驾驶员；

7.2.3.2 通信方式

具备短程、远程无线通信能力的路侧设备，将有关交叉口（车道）信息广播给具有短程通信能力的车辆（V2I）。

7.2.3.3 主要技术要求

TLI基本主要技术要求如下：

a) 车辆车速范围（0～70）km/h；

b) 通信距离≥300m；

c) 数据更新频率典型值2Hz；

d）系统延迟≤100ms；

e）定位精度≤1.5m。

7.2.3.4 数据交互要求

数据	属性	备注
时刻	ms	-
路口 ID	-	-
入口 ID	-	-
车道宽度	m	-
车道中心线位置	deg	-
停车线位置	deg	-
车道属性	-	-
车道所属相位	deg	-
当前灯态	-	-
红绿灯剩余时间	s	-
红绿灯配时是否自适应控制	-	-

7.2.4 绿灯起步提醒

绿灯起步提醒（GLN: Green Light Notification）是指当装载车载单元（OBU）的车辆驶向信号灯控制交叉路口，收到由路侧单元（RSU）发送的道路数据及信号灯实时状态数据时，GLN 应用将在红灯倒计时结束前给予驻车驾驶员信号灯即将变绿的提醒，以使车辆能够安全、高效地通过信号路口。

7.2.4.1 基本工作原理

绿灯起步提醒工作原理如下：

a) 车辆根据收到的道路数据，以及本车的定位和运行数据，判定本车在路网中所处的位置和运行方向；

b) 判断车辆前方路口是否有信号灯，提取信号灯对应相位的实时状态，若有信号灯信息，则在红灯倒计时结束前给予驻车驾驶员信号灯即将变绿的提醒；

7.2.4.2 通信方式

具备短程无线通信能力的路侧设备，将道路数据与信号灯实时状态数据，发送给车辆（V2I）。

7.2.4.3 主要技术要求

GLN基本主要技术要求如下：

a) 车辆车速范围（0～70）km/h；

b) 通信距离≥150m；

c) 数据更新频率典型值5Hz；

d）系统延迟≤200ms；

e）定位精度≤1.5m；

f) 道路数据集更新频率典型值1Hz。

7.2.4.4 数据交互要求

数据	属性	备注
时刻	ms	-
节点	-	-
路段	-	-
车道	-	-
连接转向关系	deg	-
静态信息	-	-
实时状态信息	-	-
转向-相位关系	deg	-
红绿灯剩余时间	s	-
红绿灯配时是否自适应	-	-

7.2.5 路侧单元信息

路边单元信息（RSI: Road Side Information）是指当装载车载单元（OBU）的车辆驶向信号灯控制交叉路口，收到由路侧单元（RSU）发送的RSI消息向周围车载单元发布的交通事件以及交通标志标牌信息。车载单元在判定消息的生效区域时，根据自身的定位与运行方向，以及消息本身提供的区域范围来进行判定，而后向驾驶员推送。

7.2.5.1 基本工作原理

路边单元信息工作原理如下：

a) 车辆根据收到的道路数据，以及本车的定位和运行数据，判定本车在路网中所处的位置和运行方向；

b) 接收到 RSI 信息后，车辆判断消息中携带的交通事件以及交通标志标牌信息的覆盖范围，是否在车辆行进方向上，如果在则显示相应交通标志标牌及交通事件信息。

7.2.5.2 通信方式

具备短程无线通信能力的路侧设备，将道路数据与RSI数据，发送给车辆（V2I）。

7.2.5.3 主要技术要求

RSI基本主要技术要求如下：

a) 车辆车速范围（0～70）km/h；

b) 通信距离≥150m；

c) 数据更新频率典型值5Hz；

d）系统延迟≤200ms；

e）定位精度≤1.5m。

7.2.5.4 数据交互要求

数据	属性	备注
时刻	ms	-
节点	-	-
路段	-	-
车道	-	-
连接转向关系	deg	-
标牌/标识内容	-	-
指示范围	-	-
有效时间	-	-
事件类型	-	-
事件优先级	-	-

7.2.6 基于交通灯的智能启停

基于交通灯的智能启停（TLBOS: Traffic Light Based Optimal Start/Stop）是指当装载车载单元（OBU）的车辆驶向信号灯控制交叉路口，收到由路侧单元（RSU）发送的道路数据及信号灯实时状态数据时，TLBOS应用将根据红灯倒计时信息来决定是否使能自动启停功能，以使车辆能够经济、舒适地通过信号路口。

7.2.6.1 基本工作原理

基于交通灯的智能启停原理如下：

a) 车辆根据收到的道路数据，以及本车的定位和运行数据，判定本车在路网中所处的位置和运行方向；

a) 判断车辆前方路口是否有信号灯，提取信号灯对应相位的实时状态，若有信号灯信息，则车将结合收到的红绿灯倒计时来决定是否使能自动启停功能；

b) 具体判断标准未绿灯状态下不启动自动启停功能；红灯倒计时在设定区间内不启动。

7.2.6.2 通信方式

具备短程无线通信能力的路侧设备，将道路数据与信号灯实时状态数据，发送给车辆（V2I）。

7.2.6.3 主要技术要求

TLBOS基本主要技术要求如下：

a) 车辆车速范围（0～70）km/h；

b) 通信距离≥150m；

c) 数据更新频率典型值2Hz；

d）系统延迟≤200ms；

e）定位精度≤1.5m；

f) 道路数据集更新频率典型值1Hz。

7.2.6.4 数据交互要求

数据	属性	备注
时刻	ms	-
路口 ID	-	-
入口 ID	-	-
车道宽度	m	-
车道中心线位置	deg	-
停车线位置	deg	-
车道属性	-	-
车道所属相位	deg	-
当前灯态	-	-
红绿灯剩余时间	s	-
红绿灯配时是否自	-	-

附 录 A（资料性附录）云控基础平台总体框架图

附 录 B（资料性附录）C-V2X 应用车辆注册流程

在实际应用中，各功能模块之间存在各种各样的信息交互，并形成模块间以及系统内原始感知数据、控制数据等的数据流向图。

车辆注册数据流向如下图所示。

附 录 C（资料性附录）C-V2X 应用服务场景数据流

服务场景数据流向如下图所示。

附 录 D（资料性附录）C-V2X 应用与云控应用平台交互

服务场景数据流向如下图所示。

.