好的，我们继续深入V-V2X技术的心脏地带——QoS处理。在上一篇中，我们已经了解了NR PC5 QoS的宏观模型和核心参数。现在，是时候揭开这些参数背后的“物理意义”，看看它们是如何被精确量化，并最终指导“智行一号”的每一次无线发射行为的。

深度解析 3GPP TS 23.287：5.4 QoS handling (Part 2 - PC5 QoS特性映射与标准化PQI表)

本文技术原理深度参考了3GPP TS 23.287 V18.4.0 (2024-09) Release 18规范中，关于“5.4.3 PC5 QoS characteristics”和“5.4.4 Standardized PQI to QoS characteristics mapping”的核心章节，旨在为读者完整呈现PC5 QoS参数与底层无线特性的映射关系，并深度解读标准化的PQI参数表，揭示V2X业务差异化服务的最终奥秘。

引言：从“套餐编号”到“菜单详情”

在Part 1中，我们的主角“智行一号”已经学会了使用PQI这个“套餐编号”来描述V2X业务的QoS需求。当它需要发送一条“紧急碰撞预警”时，它知道应该请求“90号套餐”；当它要加入车辆编队时，它可能会请求“21号套餐”。

但是，无线通信的底层物理世界，并不认识抽象的“套餐编号”。它只懂一些非常具体的“物理语言”，比如：这条消息的优先级有多高？它能容忍的延迟是多少毫秒？它能接受多大的丢包率？

本篇文章的核心任务，就是揭示从PQI这个“套餐编号”到具体无线性能指标这张“菜单详情”的完整映射过程。我们将首先深入5.4.3节，逐一剖析构成这张“菜单”的六大核心QoS特性。然后，我们将聚焦于5.4.4节，完整呈现并深度解读那张至关重要的“标准化PQI表”，看看3GPP是如何为典型的V2X业务量身定制它们的“VIP套餐”的。

---

1. PC5 QoS的“菜单详情”：六大核心特性详解 (5.4.3)

5.4.3节定义了与每个PQI值相关联的一系列底层QoS特性。这些特性绝大多数继承自5G Uu接口的QoS框架（TS 23.501），但在V2X的语境下，它们的内涵和作用有了新的侧重。

5.4.3.1 General

This clause specifies the PC5 QoS characteristics associated with PQI. The following characteristics defined in TS 23.501 applies, with differences explained in following clauses:

1 Resource Type (GBR, Delay critical GBR or Non-GBR);

2 Priority Level;

3 Packet Delay Budget;

4 Packet Error Rate;

5 Averaging window…;

6 Maximum Data Burst Volume…

1.1 资源类型 (Resource Type) - “预留座”还是“随便坐”？

• 定义: 这是QoS特性的根本分类，决定了无线资源是被预留还是共享。

  • GBR (Guaranteed Bit Rate - 保证比特率): 适用于需要持续、稳定带宽的业务，如视频流。系统会为其预留专用的无线资源，就像买了“预留座”的电影票。

  • Delay-critical GBR (延迟关键型GBR): GBR的一种，对时延的要求比普通GBR更苛刻。

  • Non-GBR (非保证比特率): 适用于突发性、对带宽不敏感的业务，如 большинство V2X安全短消息。它们共享一个公共的资源池，就像在餐厅里“随便坐”，有空位就能用。

1.2 优先级 (Priority Level) - “谁先走”？

5.4.3.3 Priority Level

… The Priority Level shall be used to different treatment of V2X service data across different modes of communication, i.e. broadcast, groupcast, and unicast.

• 定义: 这是一个数值，数字越小，优先级越高。它是在资源发生竞争时的最终仲裁者。

• 场景演绎: “智行一号”的无线模块在同一个时刻，既有一个PQI为91的“紧急轨迹对齐”消息要发，也有一个PQI为58的“传感器共享”消息要发。查询PQI表后，发现前者的Priority Level是2，后者是4。于是，无线调度器会毫不犹豫地先为Priority Level为2的消息分配资源。这个机制确保了在任何情况下，最高优先级的业务总能优先被服务。

1.3 分组时延预算 (Packet Delay Budget - PDB) - “必须在多长时间内送到”？

5.4.3.4 Packet Delay Budget

… when used for PC5 communication, the PDB associated with the PQI defines an upper bound for the time that a packet may be delayed between sending UE and receiving UE(s) over PC5 reference point.

• 定义: 单位是毫秒（ms）。它定义了一个数据包从离开发送方天线，到抵达接收方天线，所能容忍的最大端到端空口时延。PDB是衡量V2X业务实时性的核心指标。

• 场景演绎: 一个用于“协同碰撞避免”的业务，其PDB可能被设定为10ms。这意味着从“智行一号”决定发送这条消息，到底层的无线协议栈完成所有处理（编码、调度、发送）并被对方成功接收，整个过程必须在10ms内完成。任何可能导致超过这个时延的操作（如长时间的排队等待）都必须被避免。

1.4 分组差错率 (Packet Error Rate - PER) - “允许丢多少个包裹”？

5.4.3.5 Packet Error Rate

The Packet Error Rate (PER) is defined in clause 5.7.3.5 of TS 23.501.

• 定义: 这是一个概率值，如10⁻⁵。它定义了一个数据包在传输过程中，因为信道噪声等原因导致不可恢复的错误（即最终丢失）的最大可接受概率。PER是衡量V2X业务可靠性的核心指标。

• 场景演绎: 对于“远程驾驶控制信令”，其PER可能会被要求达到10⁻⁵，即平均每发送十万个数据包，最多只允许丢失一个。为了达到这个苛刻的指标，底层无线协议会采用非常鲁棒的编码方式、HARQ重传等机制来对抗无线信道的衰落。

1.5 & 1.6 GBR业务的附加特性

• Averaging Window (平均窗口): 定义了计算GBR/MFBR速率的时间窗口长度。

• Maximum Data Burst Volume (MDBV - 最大数据突发量): 定义了在PDB时间内，系统需要有能力处理的最大数据量。

---

2. V2X业务的“官方菜单”：标准化PQI表深度解读 (5.4.4)

现在，我们已经了解了构成“菜单详情”的所有菜品。5.4.4节和其中的“Table 5.4.4-1: Standardized PQI to QoS characteristics mapping”就是3GPP的“大厨们”精心设计的“官方推荐菜单”。这张表将典型的V2X业务，与我们刚刚学到的六大QoS特性进行了完美的绑定。

让我们挑选几个典型的“套餐”，结合“智行一号”的场景，进行深度剖析。

Table 5.4.4-1: Standardized PQI to QoS characteristics mapping

| PQI Value | Resource Type | Default Priority Level | Packet Delay Budget | Packet Error Rate | Example Services |

| :--- | :--- | :--- | :--- | :--- | :--- |

| 21 | GBR | 3 | 20 ms | 10⁻⁴ | Platooning between UEs - Higher degree of automation |

| 55 | Non-GBR | 3 | 10 ms | 10⁻⁴ | Cooperative lane change - higher degree of automation |

| 58 | Non-GBR | 4 | 100 ms | 10⁻² | Sensor information sharing - lower degree of automation |

| 90 | Delay Critical GBR | 3 | 10 ms | 10⁻⁴ | Cooperative collision avoidance; Sensor sharing – Higher degree of automation |

| 91 | (NOTE 1) | 2 | 3 ms | 10⁻⁵ | Emergency trajectory alignment; Sensor sharing – Higher degree of automation |

(注：上表为规范表格的简化和重点摘录)

套餐解读一：PQI 91 - “十万火急，使命必达”

• 业务场景: 紧急轨迹对齐。想象两辆车即将发生侧面碰撞，它们需要在最后几毫秒内，通过PC5链路协商出一个紧急避让轨迹。

• 菜单详情:

  • PDB = 3ms: 极致的时延要求！从决策到对方收到，必须在3毫秒内完成，这几乎是物理层处理的极限。

  • PER = 10⁻⁵: 极致的可靠性！十万分之一的丢包率，确保这条救命的指令几乎不可能丢失。

  • Priority Level = 2: 极高的优先级！在资源竞争中，它将战胜几乎所有其他业务。

  • Resource Type: 表中NOTE 1指出，GBR和Delay Critical GBR PQI只能用于单播。这意味着这种业务需要通过预先建立的PC5单播链路来承载，以获得资源保障。

套餐解读二：PQI 21 - “队列行军，步调一致”

• 业务场景: 高等级自动驾驶车辆编队（Platooning）。编队内的车辆需要持续、稳定地交换控制信息，以保持精确的车距和同步的加减速。

• 菜单详情:

  • Resource Type = GBR: 明确需要预留资源。因为编队通信是持续性的，不能有时断时续的风险。

  • PDB = 20ms: 时延要求很高，但相比碰撞避免，稍有缓和。

  • PER = 10⁻⁴: 可靠性要求也很高。

  • Priority Level = 3: 优先级高，但低于最紧急的碰撞避免类业务。

套餐解读三：PQI 55 vs. PQI 58 - “差之毫厘，谬以千里”

• 业务场景: 这两个PQI都与“传感器信息共享”或“协同换道”有关，但后面跟着一个关键的定语：“higher degree of automation” vs “lower degree of automation”。

• 菜单详情对比:

  • PQI 55 (高级别自动驾驶): PDB=10ms, PER=10⁻⁴, Priority=3。

  • PQI 58 (低级别自动驾驶): PDB=100ms, PER=10⁻², Priority=4。

• 深度剖析: 这个对比完美地体现了QoS设计的精髓。对于一个L4/L5级别的自动驾驶车辆（higher degree），传感器数据是其做出驾驶决策的关键输入，其时效性和可靠性直接关系到行车安全，因此必须使用PQI 55的苛刻指标。而对于一个L2级别的辅助驾驶系统（lower degree），传感器数据更多是给驾驶员提供一个“参考信息”，即使延迟稍大或偶尔丢失，后果也不严重，因此可以使用PQI 58的宽松指标，从而节省宝贵的无线资源。

---

总结：QoS，V2X业务差异化服务的基石

通过对5.4.3和5.4.4节的深度解读，我们终于打通了V2X QoS的“任督二脉”。从上层应用的业务需求，到底层无线的物理特性，一条清晰、量化的映射路径已经完整地展现在我们面前。

• 六大QoS特性（资源类型、优先级、PDB、PER等），共同构成了描述V2X业务无线需求的**“标准语言”**。

• 标准化的PQI表，则是3GPP专家们用这门语言，为我们谱写的一曲**“V2X业务交响乐”**。每一个PQI值，都是一个和谐的音符，精确地定义了特定业务在通信时应有的“节奏”（时延）、“音准”（可靠性）和“声部”（优先级）。

“智行一号”现在已经彻底理解了QoS的内涵。当它需要发送不同类型的V2X消息时，它不再是简单地将数据“扔”出去，而是会为每一条消息，附上一个代表着其“身份”和“使命”的PQI。而整个PC5无线网络，都会像一个训练有素的交响乐团，根据这些PQI指挥棒，为不同声部的乐器（V2X业务）提供恰如其分的演奏资源，最终合奏出一曲安全、高效的智能交通乐章。

在接下来的文章中，我们将继续完成5.4节的剩余部分，探讨这些QoS原则在广播、组播、单播三种不同模式下的具体应用，以及Uu接口的QoS处理机制。

---

FAQ

Q1：PCF下发的策略可以直接指定PDB、PER这些参数，还是只能指定PQI？

A1：PCF策略非常灵活。它可以直接为某个V2X服务类型指定一个标准化的PQI。同时，规范也支持非标准化QoS的配置，即PCF可以下发一个自定义的QoS参数组合（包括PDB, PER, Priority等）。UE收到后，需要用这一整套自定义的参数去配置底层。5.4.3.1 General中的NOTE提到，V2X layer may derive non-standardized PC5 QoS characteristics...，这通常适用于一些标准PQI无法满足其特殊需求的新型V2X业务。

Q2：从PQI表中看，GBR业务的优先级（如PQI 21的Priority=3）并不总是最高的，这是否合理？

A2：非常合理。QoS设计的核心是按需保障，而非“唯快不破”。优先级（Priority Level）解决的是资源冲突时的调度问题，应该留给那些突发性强、时延预算极低的业务。例如，PQI 91的“紧急轨迹对齐”业务，它平时不出现，一出现就是性命攸关，必须抢占一切资源，所以优先级最高。而PQI 21的“车辆编队”业务，虽然也很重要，但它是持续性的，系统已经为其预留了GBR资源。它的主要需求是稳定的带宽，而不是在每一毫秒都去和其他突发业务抢占瞬时资源。因此，它的优先级略低是完全合理的，这避免了持续性的GBR业务对更紧急的突发安全业务造成不必要的调度阻塞。

Q3：这张PQI表是固定不变的吗？未来可以增加新的PQI值吗？

A3：这张表是可以演进的。表格下方的NOTE 1明确指出：“For Standardized PQI to QoS characteristics mapping, the table will be extended/updated to support service requirements for other identified V2X services.” 随着V2X技术的发展，未来必然会涌现出新的应用场景（如协同感知、远程遥控等），它们会对QoS提出新的、更多样化的需求。届时，3GPP会在新的Release版本中，对这张表进行修订，增加新的PQI条目，或者调整现有PQI的参数，以适应技术和业务的发展。

Q4：为什么有些PQI（如90和91）同时对应了多个“Example Services”？

A4：这是因为这些不同的V2X业务，从通信特性的角度看，其需求是相似或相同的。例如，“协同碰撞避免”和“高级别自动驾驶的传感器共享”，虽然上层应用逻辑完全不同，但它们对底层通信的要求都是“极低时延、极高可靠”。因此，可以将它们映射到同一个PQI，共享同一套QoS参数。这体现了QoS设计的归一化和收敛思想，避免了为每一个细分业务都去定义一套独立的QoS参数，简化了系统的复杂性。

Q5：UE如何获得这张PQI表？是预置在终端里吗？

A5：是的。这张标准化的PQI到QoS特性的映射表，是3GPP规范的一部分，它应该被预置在所有符合该版本规范的V2X终端和网络设备（如基站）中。这是一种“共同的知识”，是所有设备能够对PQI这个“暗号”达成共识的基础。当PCF下发一个PQI=91的策略时，UE和网络设备都会在自己本地的“标准库”中查到它对应3ms的PDB和10⁻⁵的PER，从而采取一致的QoS处理行为。