51学通信

深度解析 3GPP TS 23.287：5.4 QoS handling (Part 3 - PC5 QoS在三大通信模式中的应用)

22分钟阅读

好的，我们继续V2X QoS的深度探索。在Part 2中，我们已经完全掌握了PC5 QoS的“菜单详情”和标准化的“官方菜单”（PQI表）。现在，是时候看看“智行一号”这位“大厨”是如何根据不同的“上菜”方式（广播、组播、单播），来灵活运用这些QoS规则，烹饪出满足不同“食客”（V2X业务）口味的“佳肴”了。

深度解析 3GPP TS 23.287：5.4 QoS handling (Part 3 - PC5 QoS在三大通信模式中的应用)

本文技术原理深度参考了3GPP TS 23.287 V18.4.0 (2024-09) Release 18规范中，关于“5.4.1.1.2 Deriving PC5 QoS parameters and assigning PFI for PC5 QoS Flow”、“5.4.1.1.3 Handling of PC5 QoS Flows based on PC5 QoS Rules”、“5.4.1.2 QoS handling for broadcast mode”、“5.4.1.3 QoS handling for groupcast mode”和“5.4.1.4 QoS handling for unicast mode”的核心章节，旨在为读者深度剖析PC5 QoS体系在广播、组播、单播三种通信模式下的具体运作流程与差异化处理机制。

引言：从“理论菜单”到“后厨实操”

在之前的篇章中，我们的主角“智行一号”已经是一位理论功底深厚的“美食评论家”。它能看懂复杂的QoS“菜单”（PQI表），也理解每一道“菜品”（QoS特性）背后的深意。但真正的考验，来自于“后厨”的实际操作。

当一份“订单”（V2X应用层的数据请求）下来时，“智行一号”的V2X层这位“大厨”该如何行动？它如何将这份抽象的订单，转化为一个具体的、带有明确QoS标签的“菜肴”（PC5 QoS Flow），并最终交由“传菜员”（接入层）送出？这个过程，根据“上菜”方式的不同——是“大堂广播”、是“包间组播”、还是“情侣座单播”——其操作流程和关键环节都有着微妙而重要的区别。

本篇文章，我们将聚焦于V2X“后厨”的QoS实操流程。首先，我们会深入剖析通用的“备菜”流程——即如何派生QoS参数并分配QFI。然后，我们将分别进入广播、组播、单播三个不同的“厨房”，详细考察QoS在每种模式下的差异化应用，揭示NR V2X QoS体系的灵活性与强大适应能力。

1. “备菜”的艺术：通用的QoS Flow派生与管理流程 (5.4.1.1.2 & 5.4.1.1.3)

无论采用哪种通信模式，当V2X应用层传来一份新的数据请求时，“智行一号”的V2X层都需要执行一套标准的“备菜”流程。

1.1 第一步：派生QoS参数 - “看单配菜”

5.4.1.1.2 Deriving PC5 QoS parameters and assigning PFI for PC5 QoS Flow

When a service data packet or request from the V2X application layer is received, the UE determines if there is any existing PC5 QoS Flow matching the service data packet or request, i.e. based on the PC5 QoS Rules…

If there is no PC5 QoS Flow matching…, the UE derives PC5 QoS parameters defined in clause 5.4.2 as below:

  • If the application layer provides the V2X Application Requirements…, the V2X layer determines the PC5 QoS parameters based on the V2X Application Requirements;
  • Otherwise, the V2X layer determines the PC5 QoS parameters based on the mapping of the V2X service type to PC5 QoS parameters defined in clause 5.1.2.1.

深度解读与场景演绎：

这个流程建立了一个清晰的QoS参数来源优先级：应用层实时指定 > PCF策略预设映射。

场景演绎：一份“加急”的订单

  1. V2X应用层传来一份“传感器共享”的数据请求。

  2. V2X层首先检查PC5 QoS Rules，看是否已经有一条现成的QoS Flow可以承载这份数据。

  3. 发现没有匹配的Flow，需要创建一条新的。此时，它开始确定这条Flow的QoS参数。

  4. 它首先“询问”应用层：“这份订单有什么特殊要求吗？”

    • 情况A (应用层指定): 应用层回复：“这是一份高级别自动驾驶用的数据，要求PDB必须小于50ms！” V2X层会以此为准，生成一套满足该需求的QoS参数。

    • 情况B (应用层未指定): 应用层“沉默”。V2X层则会拿出PCF下发的“数字驾照”，查找其中关于“传感器共享”这个V2X服务类型的预设映射规则，例如，规则规定该服务对应PQI 58（PDB=100ms, PER=10⁻²等）。V2X层将使用这套默认参数。

1.2 第二步：创建/更新QoS Flow - “贴条码，入档案”

After deriving the PC5 QoS parameters, the UE performs the following:

  • If there is no existing PC5 QoS Flow that fulfils the derived PC5 QoS parameters:
  • The UE creates a new PC5 QoS Flow for the derived PC5 QoS parameters; and
  • The UE then assigns a PFI and derives PC5 QoS Rule for this PC5 QoS Flow.
  • Otherwise, the UE updates the PC5 Packet Filter Set in the PC5 QoS Rule for such PC5 QoS Flow.

深度解读与场景演绎：

  • PFI (PC5 Flow Identifier): 这是PC5 QoS Flow的唯一标识符，功能上与Uu接口的QFI完全相同。可以理解为给这条新创建的“虚拟管道”分配的一个内部编号。

  • 创建新Flow: 如果派生出的QoS参数（如PDB=50ms）在现有所有Flow中都找不到能满足的，V2X层就会创建一个全新的PC5 QoS Flow，为它分配一个新的PFI（例如PFI=10），并将这套QoS参数与PFI=10绑定，记录在“PC5 QoS Context”这个档案里。同时，它还会创建一条新的PC5 QoS Rule，规定“凡是满足某某特征的数据包，都应使用PFI=10”。

  • 复用现有Flow: 如果派生出的QoS参数（如PDB=100ms）与某条已存在的Flow（例如PFI=8）的参数完全一致，那么V2X层就不会创建新的Flow，而是在PFI=8对应的QoS Rule中，增加一条新的包过滤器，让新的数据也能被这条旧的Flow承载。

这个流程确保了QoS Flow的资源被高效复用，避免了为每一个细微的数据流都去创建一条独立的管道。

2. “大堂广播”的QoS实操：广播模式 (5.4.1.2)

5.4.1.2 QoS handling for broadcast mode V2X communication over PC5 reference point

When PC5 broadcast is used…, the following principles are followed…:

  • PC5 QoS parameters defined in clause 5.4.2 are applied.
  • The V2X layer determines the PC5 QoS parameters based on the V2X Application Requirements (if available) or the mapping of the V2X service type…
  • The V2X layer assigns a PC5 QoS Flow Identifier (PFI) and derives the PC5 QoS Rule…

深度解读与场景演绎：

广播模式的QoS处理，完全遵循我们刚刚描述的通用“备菜”流程。

场景演绎：广播“基本安全消息 (BSM)”

  1. 应用层周期性地生成BSM数据包。

  2. V2X层接收到后，为其派生QoS参数。由于BSM通常没有特殊的实时需求，V2X层会直接查找PCF策略中为BSM服务类型预设的QoS映射，得到对应的PQI和详细参数。

  3. V2X层为此创建一个QoS Flow，分配一个PFI，并建立QoS Rule：“所有目的地址为广播地址、服务类型为BSM的数据包，都走这个PFI”。

  4. V2X层将BSM数据包和这个PFI一同交给接入层。

  5. 接入层看到PFI后，查询QoS Context档案，得知其对应的具体QoS特性（如优先级、PDB等），然后根据这些特性，为其在广播信道上选择合适的无线资源进行发送。

广播模式QoS的关键点：

  • 本地决策: 整个QoS参数派生和Flow创建过程，完全由发送方UE自主完成，无需与接收方进行任何协商。

  • 尽力而为的保障: 虽然有QoS参数指导资源分配，但由于广播是无连接、无反馈的，其QoS保障本质上是一种基于优先级的“尽力而为”，无法做到像单播那样的确定性保障。

3. “包间组播”的QoS实操：组播模式 (5.4.1.3)

5.4.1.3 QoS handling for groupcast mode V2X communication over PC5 reference point

The QoS handling described in clause 5.4.1.2 is applied.

深度解读与场景演绎：

规范在这里的表述非常简洁：组播的QoS处理，与广播完全相同。

这意味着，“智行一号”在向它的卡车编队发送组播消息时，其内部的QoS参数派生、QoS Flow创建和管理流程，与它向全世界广播BSM消息时，是一模一样的。唯一的区别在于，最终数据包的目的地址，从一个公共的广播L2 ID，变成了一个特定的组播L2 ID。

组播模式QoS的关键点：

  • 与广播同构: 继承了广播QoS的所有特点，包括本地决策和基于优先级的尽力而为保障。

  • Range参数的应用: 正如我们在Part 1中学到的，独特的Range参数主要应用于组播场景，为QoS保障附加了地理距离的约束，使得资源可以更精准地用于保障组内近距离成员的通信质量。

4. “情侣座单播”的QoS实操：单播模式 (5.4.1.4)

单播模式的QoS处理，引入了一个全新的、至关重要的环节——协商。

5.4.1.4 QoS handling for unicast mode V2X communication over PC5 reference point

The QoS handling described in clause 5.4.1.2 is applied with the following additions:

  • The PFI and PC5 QoS parameters are negotiated during the Layer-2 link establishment procedure, as described in clause 6.3.3.1, or during the Layer-2 link modification procedure, as described in clause 6.3.3.4.

深度解读与场景演绎：

单播的QoS不再是发送方“一厢情愿”的本地决策，而是一个双方“情投意合”的协商结果。

场景演绎：建立远程驾驶的“生命线”

“智行一号”需要与路侧单元（RSU）建立一条PC5单播链路，用于远程驾驶。

  1. 发起方“提亲” (发起请求):

    • “智行一号”的V2X层首先按照通用的“备菜”流程，为远程驾驶的视频回传和控制信令，派生出两条不同的QoS Flow需求（比如一个GBR Flow，一个超低时延的Non-GBR Flow），并为它们暂定了PFI和QoS参数。

    • 在6.3.3.1节定义的L2链路建立请求消息中，“智行一号”会将这两条QoS Flow的完整需求清单（包含PFI、PQI、GFBR/MFBR等）发送给RSU。这相当于说：“我想和你建立连接，并且我希望你能在视频方面满足A标准，在控制方面满足B标准。你同意吗？”

  2. 接收方“审批” (协商与接受):

    • RSU收到了这份“需求清单”。它会根据自身的处理能力和当前的资源状况，来评估自己能否满足这些QoS要求。

    • 如果RSU认为自己完全可以满足，它就会在L2链路建立接受消息中，原封不动地返回这份QoS清单，表示“我同意！”。

    • 如果RSU认为某些要求过高（比如它无法支持那么高的视频码率），它可能会在返回的消息中，对QoS参数进行“还价”，提出一个自己能接受的、较低的QoS水平。

    • 双方通过这一来一回的信令交互，最终就这条单播链路上所有QoS Flow的参数达成了一致。

单播模式QoS的关键点：

  • 协商机制: QoS参数由通信双方共同协商确定，这是与广播/组播最本质的区别。

  • 确定性保障: 协商成功后，意味着接收方也对这个QoS水平做出了承诺。结合单播链路的HARQ反馈和重传机制，可以实现更具确定性的QoS保障。

  • 动态修改: 如果在通信过程中，业务需求发生变化（比如需要增加一条新的QoS Flow，或调整现有Flow的码率），双方还可以通过L2链路修改流程，对QoS参数进行动态的重新协商。

总结：因“人”施“策”，因“事”制“宜”

通过对PC5 QoS在三种通信模式下应用的深度剖析，我们看到了NR V2X QoS体系设计的精妙之处。它并非一套僵化的规则，而是一个能够根据不同交互场景，灵活调整其运作方式的智能系统。

  • 广播/组播模式: 采用发送方本地决策的QoS模型，流程简单高效，适合无连接、一对多的信息分发场景。QoS保障侧重于基于优先级的资源抢占。

  • 单播模式: 引入了端到端的QoS协商机制，使得QoS保障从发送方的“单方面声明”变成了通信双方的“共同契约”，能够提供更可靠、更具确定性的服务质量，完美契合了远程驾驶、高清数据传输等高级V2X应用的需求。

“智行一号”的“后厨”现在已经能够娴熟地应对各种订单了。无论是需要快速上菜的“大众快餐”（广播），还是需要精心烹制的“团队套餐”（组播），抑或是需要与食客反复沟通确认口味的“顶级私房菜”（单播），它都能运用恰当的QoS处理流程，保证每一份“菜肴”的品质。

至此，我们已经完整地剖析了PC5接口的QoS体系。在下一篇，也是5.4节的最后一篇中，我们将把目光转向Uu接口，看看“智行一号”在与云端大脑通话时，其QoS又是如何被保障的。

FAQ

Q1：PFI和PQI是什么关系？为什么需要两个标识符？

A1：PQI是QoS特性的“标准化名称”，它是一个全局的概念，所有设备对同一个PQI（如91）的理解都是一致的（3ms PDB, 10⁻⁵ PER等）。而PFI是一条具体QoS Flow的“本地实例ID”，它的作用范围仅限于当前UE（或一条单播链路）的内部。之所以需要两者，是因为可能会有多条不同的数据流，虽然它们需要相同类型的QoS保障（即对应同一个PQI），但由于它们的包过滤器不同（比如发往不同的目的地），它们仍然需要被区分为不同的QoS Flow实例，因此需要分配不同的PFI。简单说，PQI定义了“服务等级”，PFI标识了“服务实例”。

Q2：在广播模式下，接收方如何知道某个数据包的QoS等级？

A2：在广播模式下，QoS信息是内嵌在数据传输中的。发送方的接入层会根据PFI对应的QoS特性（特别是优先级），在物理层选择合适的资源块和传输格式来发送数据。接收方在解码物理层信号时，并不直接关心发送方最初的PFI或PQI是什么。它只关心能否成功接收数据。广播的QoS保障，主要体现在发送端资源分配的优先级上，是一种发送方侧的保障机制。

Q3：在单播的QoS协商中，如果双方无法达成一致（比如接收方一直“还价”，发起方不接受），会发生什么？

A3：如果经过信令交互，双方最终无法就一套共同可接受的QoS参数达成一致，那么这条PC5单播链路就会建立失败。上层V2X应用会收到一个连接失败的通知。这时，应用层可能需要采取降级策略，例如尝试用更低的QoS要求重新发起连接，或者放弃使用PC5单播，转而尝试其他通信方式（如Uu）。

Q4：为什么组播的QoS处理流程和广播是一样的，而不是像单播一样进行协商？

A4：这主要是由组播的“一对多”特性决定的。一个组播群组中可能有数量不定、动态变化的多个接收方。让发送方与每一个接收方都去进行QoS协商，会带来巨大的信令风暴和系统复杂性，是不现实的。因此，规范选择了与广播类似的、更简单的发送方决策模型。发送方根据自身对业务的理解和策略配置，决定一个“普适”的QoS等级并进行发送，接收方则“尽力而为”地去接收。

Q5：V2X层（V2X layer）和接入层（AS layer）在QoS处理中是如何分工的？

A5：它们是典型的策略与执行的分工关系。V2X层是“策略层”或“大脑”，它负责理解上层应用的需求和PCF的策略，进行QoS参数的派生、QoS Flow的创建与管理、将数据包分类并打上PFI标签。它的工作成果是告诉接入层：“这个数据包，请用PFI=10的规格来处理”。而接入层是“执行层”或“四肢”，它不关心业务逻辑，只认PFI。它根据PFI查询到具体的QoS特性（优先级、PDB等），然后负责所有底层的“脏活累活”，如无线资源申请/选择、信道编码、HARQ重传、物理层发送等，确保最终的无线传输行为能够满足策略层设定的QoS目标。

关系图谱