好的，我们继续“智行一号”的深度探索。它已经学会了寻找并连接正确的“云端大脑”，现在，我们将进入整个V2X技术体系中最核心、最硬核的部分——服务质量（QoS）保障。这决定了V2X通信究竟是“尽力而为”的普通聊天，还是“使命必达”的生命保障。

深度解析 3GPP TS 23.287：5.4 QoS handling for V2X communication (Part 1 - PC5 QoS模型与参数)

本文技术原理深度参考了3GPP TS 23.287 V18.4.0 (2024-09) Release 18规范中，关于“5.4.1 QoS handling for V2X communication over PC5 reference point”和“5.4.2 PC5 QoS parameters”的核心章节，旨在为读者深度剖析NR V2X如何构建一个精细化、可量化的QoS保障体系，为不同V2X业务开辟差异化的“VIP通道”。

引言：为生命安全信息开辟“绿色通道”

我们的主角“智行一号”正在高速公路上以100km/h的速度行驶。此时，在它的数据通信管道中，同时奔涌着三股数据流：

1. 一股是来自前方车辆的PC5消息：“紧急制动，有碰撞风险！”

2. 一股是来自乘客手机热点的Uu数据流：“正在缓存超高清电影……”

3. 一股是来自路侧单元的PC5消息：“前方1公里处有充电桩。”

如果这三股数据流在无线资源紧张时发生“拥堵”，应该让谁先行？答案不言而喻。V2X系统的首要任务，就是确保第一股“救命”的数据流，能够享有绝对的、无条件的最高优先级。如何从技术上实现这种区分和保障，就是第5.4节“QoS handling”要解决的核心问题。

本章内容是NR V2X相对于传统C-V2X在技术上实现飞跃的关键所在。我们将遵循“长章节拆分”的原则，在Part 1中，首先聚焦于PC5接口的QoS模型、核心参数以及它们背后的设计哲学。

---

1. 从“尽力而为”到“按需服务”：NR PC5 QoS模型的革命 (5.4.1.1)

在LTE V2X时代，PC5的QoS主要依赖于一个相对简单的优先级参数（ProSe Per-Packet Priority - PPPP）。而NR V2X则引入了一套与5G Uu接口一脉相承的、更为精细和强大的QoS模型。

5.4.1.1.1 General overview

For NR based PC5, a QoS model similar to that defined in TS 23.501 for Uu reference point is used, i.e. based on 5QIs, with additional parameter of Range… For the V2X communication over NR based PC5 reference point, a PC5 QoS Flow is associated with a PC5 QoS Rule and the PC5 QoS parameters…

深度解读：

这段话宣告了一场革命：NR PC5的QoS管理，从一个粗放的“优先级时代”，迈入了一个精细化的“QoS流（QoS Flow）时代”。

• PC5 QoS Flow: 这是NR PC5 QoS的最小调度单元。可以把它想象成一条为特定业务数据专门开辟的、具有明确服务质量承诺的“虚拟管道”。所有被映射到同一个QoS Flow的数据包，都将获得相同的转发待遇（如调度优先级、时延预算等）。

• PC5 QoS Rule: 这是将数据包“分拣”到不同QoS Flow的“交通规则”。规则中定义了详细的包过滤器（Packet Filter Set），例如“所有发往广播地址、且V2X服务类型为‘碰撞预警’的数据包，都应进入QoS Flow A”。

• PC5 QoS Parameters: 这是描述每条QoS Flow服务质量的“性能指标”，例如时延、可靠性、速率等。

规范中的“Figure 5.4.1.1.1-1: Per-Flow PC5 QoS Model for NR PC5”清晰地展示了这个流程：

1. V2X应用层产生一个数据包。

2. V2X层根据预设的PC5 QoS Rules对数据包进行检测和分类，为其打上一个**QFI（QoS Flow Identifier）**的标签，这个过程称为“classification and marking”。

3. **接入层（AS Layer）看到这个QFI标签后，就知道这个数据包属于哪个QoS Flow，然后将其映射到一个具有相应QoS保障的无线承载（SL radio bearer）**上进行传输。

这个模型的引入，使得NR V2X的QoS保障能力，从简单的“谁比谁更重要”，升级到了可以为每一种V2X业务提供“可量化的、端到端的服务质量承诺”。

---

2. “VIP通道”的性能指标：详解PC5 QoS参数 (5.4.2)

一条PC5 QoS Flow的服务质量，是由一系列精确的参数来定义的。5.4.2节详细列出了这些“性能指标”，它们共同构成了V2X业务的“SLA（服务等级协议）”。

2.1 核心标识：PQI (5.4.2.1)

5.4.2.1 PQI

A PQI is a special 5QI, as defined in clause 5.7.2.1 of TS 23.501, and is used as a reference to PC5 QoS characteristics…

• PQI (PC5 QoS Identifier): 这是PC5 QoS的灵魂。它是一个标量数值（一个整数），但它代表了一整套预定义的PC5 QoS特性组合。PQI就像一个“套餐编号”，比如“1号套餐”代表“超低时延、超高可靠”，“2号套餐”代表“中等时延、一般可靠”。网络和UE只需要协商PQI这一个数字，就等于就一整套复杂的QoS参数达成了共识，极大地简化了信令交互。

2.2 速率保障：PC5 Flow Bit Rates (5.4.2.2) & PC5 Link Aggregated Bit Rates (5.4.2.3)

对于需要持续数据传输的业务（如视频），速率保障至关重要。

• GFBR/MFBR (Guaranteed/Maximum Flow Bit Rate):

  • GFBR (保证流比特率): 承诺一条GBR类型的QoS Flow至少能获得的比特率。

  • MFBR (最大流比特率): 允许这条QoS Flow最多可以使用的比特率。

  • 场景演绎: “智行一号”在PC5单播链路上回传一路高清视频，这条QoS Flow的GFBR可能是20Mbps，MFBR可能是50Mbps。这意味着即使无线环境很差，系统也要想办法保证它20Mbps的速率；如果环境好，它最多可以用到50Mbps，再多就不行了，以防它挤占其他业务的资源。

• PC5 LINK-AMBR (per link Aggregate Maximum Bit Rate):

  • 这是一个针对PC5单播链路的总速率上限。它限制了在这条链路上，所有非GBR类型的QoS Flow加起来的总速率不能超过一个阈值。

  • 场景演绎: “智行一号”与路侧单元建立了一条PC5单播链路。除了刚才那路GBR视频流，它还在传输一些非GBR的数据（如日志上报、状态查询等）。PC5 LINK-AMBR就规定了所有这些非GBR数据流的总和，比如不能超过10Mbps。

2.3 距离维度：Range (5.4.2.4) - V2X的特色参数

这是PC5 QoS参数中最具V2X特色的一个。

5.4.2.4 Range

The Range value indicates the applicability of the PC5 QoS parameters in PC5 communication, i.e. when the receiving UEs are not within the Range specified distance from the transmitting UE, the communication is best effort.

深度解读与场景演绎：

• Range (范围): 单位是米。它为QoS保障附加了一个地理距离的约束。QoS承诺只在发送方和接收方之间的距离小于这个Range值时才有效。超出了这个距离，通信就退化为“尽力而为（best effort）”。

• 场景演绎：“换道辅助”的距离感

  “智行一号”准备向左变道，它需要与左后方的车辆进行一次“协同换道”信息交互。这个V2X业务的QoS参数中，可能包含PQI=X (代表低时延) 和 Range=150米。

  • 当左后方车辆距离它100米时，无线层会采取一切手段（如更高的发射功率、更鲁棒的编码方式、HARQ重传等）来确保这条消息能够满足PQI X所定义的低时延、高可靠要求。

  • 而对于一辆远在300米外的车辆，即使它也收到了这条消息，底层协议栈知道它已经超出了150米的QoS保障范围，因此可能不会为它进行重传，或者会用更节省资源的发射方案。

为什么引入Range参数？

因为在无线通信中，距离是成本。要在更远的距离上实现同样的QoS，需要消耗指数级增长的无线资源（主要是发射功率）。Range参数的引入，使得QoS保障变得更加精准和高效。它告诉底层物理层：“把好钢用在刀刃上”，只为真正有威胁的、近距离范围内的通信，提供最高等级的资源保障。这个参数目前主要用于组播模式。

2.4 默认值：Default Values (5.4.2.5)

A UE may be configured with default values for PC5 QoS parameters for a particular V2X service type… The default value will be used if the corresponding PC5 QoS parameter is not provided by upper layer.

这是一种容错和简化机制。PCF下发的策略中，可以为每种V2X业务类型配置一套默认的QoS参数。当上层应用在发起通信时，如果“偷懒”没有指定具体的QoS需求，V2X层就会自动使用这套预设的默认值，确保通信依然能够以一种合理的方式进行。

---

总结：构建可量化的服务承诺

通过对5.4.1和5.4.2节的深度剖析，我们揭示了NR V2X QoS体系的精密设计。它不再是模糊的“高、中、低”优先级，而是一个由多个维度参数构成的、可量化的服务承诺体系。

• 以QoS Flow为核心的调度模型，实现了对业务数据的精细化区分和管理。

• 以PQI为纲的参数体系，用一个简单的标量，代表了一整套复杂的QoS特性，简化了信令，统一了认知。

• 多维度的QoS参数（速率、距离等），使得QoS保障能够更贴近V2X业务的真实需求，特别是创新的Range参数，为QoS赋予了地理空间的维度。

• 默认值机制，则为整个复杂的QoS系统提供了健壮性和易用性。

“智行一号”现在不仅知道该和谁说话，更重要的是，它知道了该用什么样的“语气”（QoS）来说话。它能够确保对“紧急制动”的呐喊，永远比对“附近有充电桩”的闲聊，更响亮、更清晰、更迅速地被听到。

在下一篇文章中，我们将继续深入5.4节，探讨这些抽象的QoS参数，是如何与更底层的无线特性（如优先级、时延预算、误码率）进行一一映射的，并为您完整呈现标准化的PQI参数表，敬请期待！

---

FAQ

Q1：PC5 QoS Flow和Uu QoS Flow是同一个东西吗？

A1：它们在设计思想上是同源的，都代表了QoS保障的最小粒度，但在具体实现和参数体系上是独立的。Uu QoS Flow由核心网的SMF控制，用于保障UE和UPF之间的端到端服务质量。而PC5 QoS Flow则由UE的V2X层和接入层自主管理（或在网络调度模式下由gNB辅助管理），用于保障UE与UE之间的直通链路服务质量。它们的QoS参数集也有所不同，最典型的就是PC5 QoS独有的“Range”参数。

Q2：PQI和5QI是什么关系？

A2：可以理解为PQI是5QI在PC5场景下的一个“特殊子集”或“特别版”。规范原文说“A PQI is a special 5QI”，意味着PQI在概念上继承了5QI，即用一个标量数字来代表一整套QoS特性。但PQI所对应的具体特性（如时延、可靠性、优先级等），是专门为V2X PC5通信场景而优化的。所以，当你在PC5的语境下讨论QoS时，应该使用PQI；在Uu的语境下，则使用5QI。

Q3：Range参数只用于组播吗？为什么广播和单播不用？

A3：根据当前规范（V18.4.0），Range参数明确规定只用于组播模式（Range is only used for groupcast mode communication over PC5 reference point.）。广播模式通常被用于发送普适性的基本安全消息，其设计目标是尽可能让周围所有人都听到，因此设定一个QoS保障距离的意义不大。而对于单播模式，其链路是点对点的，双方可以通过链路质量测量等方式实时感知信道状况，动态调整传输策略，对一个固定的Range参数依赖性不强。组播模式介于两者之间，它需要向一个特定但不确定的群体发送消息，Range参数可以很好地帮助底层在资源消耗和保障范围之间做出权衡。

Q4：谁来决定一个V2X业务具体使用哪个PQI？

A4：最终的决定权在PCF。在5.1.2.1节中我们学到，PCF下发的策略中，最核心的就是“V2X服务类型到PC5 QoS参数的映射”。这个映射关系中，就包含了为每个标准化的V2X服务类型（如碰撞预警、编队行驶等）预先分配好的PQI值。UE收到这个策略后，就会严格遵照执行。上层应用也可以向V2X层提出自己的QoS需求，但最终V2X层会基于PCF的策略进行裁决和映射。

Q5：PC5 LINK-AMBR和GFBR/MFBR有什么区别？为什么AMBR只针对非GBR流？

A5：GFBR/MFBR是针对单个GBR QoS Flow的“精细化”速率控制，它有明确的“保证”承诺，就像为某个VIP预留了专用车道。而PC5 LINK-AMBR是针对一条PC5单播链路上所有非GBR QoS Flow的“总盘子”控制，它不关心每个非GBR流具体用了多少，只关心它们的总和不能超标，就像一个多车道的“公共区域”，大家共享带宽，但总车流量不能超过路口容量。AMBR之所以只针对非GBR流，是因为GBR流已经有了自己更严格的GFBR/MFBR管控，无需再用AMBR来约束。这种设计分离了对“有承诺”和“尽力而为”两种流量的管控，使得QoS管理更加清晰和高效。