51学通信

深度解析 3GPP TS 23.287：5.4 QoS handling (Part 4 - Uu接口QoS与网络能力开放)

20分钟阅读

好的，我们继续V2-V2X QoS的深度探索。在前几篇中，我们已经彻底剖析了PC5接口精细化的QoS体系。现在，是时候将目光转向“智行一号”的另一条生命线——Uu接口，看看它在与“云端大脑”进行广域通信时，其服务质量是如何被保障的。

深度解析 3GPP TS 23.287：5.4 QoS handling (Part 4 - Uu接口QoS与网络能力开放)

本文技术原理深度参考了3GPP TS 23.287 V18.4.0 (2024-09) Release 18规范中，关于“5.4.5 QoS handling for V2X communication over Uu reference point”的核心章节，旨在为读者深度剖析V2X业务在通过5G蜂窝网络传输时，如何利用5GS强大的QoS框架和网络能力开放功能，实现端到云的、可预测、可动态调整的服务质量保障。

引言：从“车际协同”到“云端共舞”

我们的主角“智行一号”不仅是一位“近战高手”，能够通过PC5接口与身边的伙伴进行毫秒级的战术协同；它更是一位“战略家”，能够通过Uu接口，与远在千里之外的“云端大脑”（V2X应用服务器）进行一场宏大的“云端共舞”。

这场“舞蹈”的“舞步”质量——即Uu接口的服务质量（QoS）——直接决定了V2X网联智能应用的成败。无论是下载高精度地图的流畅度，还是远程驾驶指令的实时性，都高度依赖于5G网络为Uu链路提供的QoS保障能力。

与PC5的“自组织”QoS不同，Uu的QoS是一场由网络主导的、V2X应用服务器深度参与的、UE协同执行的“交响乐”。本篇文章，我们将聚焦于5.4.5节，深入探索这场交响乐的三大乐章：

  1. 基础乐章： V2X业务如何融入5GS标准的QoS框架。

  2. 华彩乐章： V2X应用服务器如何扮演“客座指挥”，主动影响网络QoS决策。

  3. 变奏乐章： 网络如何响应应用的需求，动态调整QoS策略。

1. 基础乐章：融入5GS QoS框架 (5.4.5.1 General)

5.4.5.1 General

The V2X service data can be delivered via Non-GBR QoS Flow as well as GBR QoS Flow (i.e. using the GBR resource type or the Delay-critical GBR resource type) as specified in TS 23.501.

5QI 75 specified in TS 23.501 is intended to be only used for the delivery of V2X messages over MBS.

深度解读与场景演绎：

这段话的核心思想是：V2X Uu QoS并非另起炉灶，而是完全构建在5G系统（5GS）通用的QoS框架之上。这意味着，“智行一号”的V2X数据流，与我们手机上网、看视频的数据流，在网络看来，共享同一套QoS处理逻辑。

  • 复用QoS Flow模型: 所有的V2X Uu数据，都会被映射到一个Uu QoS Flow中。这条Flow可以是GBR类型（如用于远程驾驶视频回传），也可以是Non-GBR类型（如用于上报车辆状态）。

  • 使用标准5QI: 每条QoS Flow都由一个**5QI（5G QoS Identifier）**来标识其服务等级。这个5QI与我们在PC5中谈到的PQI在概念上类似，但它是专门用于Uu接口的。

场景演绎：远程驾驶的QoS“身份证”

当“智行一号”需要与云端控制中心建立远程驾驶连接时，会涉及到两条关键数据流：

  1. 上行视频流: 车载高清摄像头将实时画面传回控制中心。这是一个典型的需要持续带宽保障的业务。网络会为其建立一条GBR类型的QoS Flow，并分配一个代表“高质量视频”的5QI（例如5QI 2或4）。

  2. 下行控制信令: 控制中心的驾驶员发出的转向、刹车指令。这是典型的对时延和可靠性要求极高的业务。网络会为其建立一条Delay-critical GBR或高优先级Non-GBR的QoS Flow，并分配一个代表“超可靠低时延”的5QI（例如5QI 81）。

  • MBS的专属5QI: 规范特别提到了一个专为V2X over MBS场景设计的5QI 75。这意味着当网络通过MBS广播V2X消息（如区域性事故预警）时，会使用这个专属的QoS等级，以确保其在无线空口上的传输质量。

2. 华彩乐章：应用服务器的“客座指挥” (5.4.5.2)

在标准的5G QoS流程中，QoS策略主要由核心网的PCF根据用户签约和网络策略来决定。但对于V2X这样专业的应用，**V2X应用服务器（AS）**作为最了解业务需求的“专家”，它的话语权至关重要。5.4.5.2节就定义了AS如何扮演“客座指挥”，向网络提出QoS建议。

5.4.5.2.1 General

A V2X Application Server may request notifications on QoS Sustainability Analytics for an indicated geographic area and time interval in order to adjust the application behaviour in advance with potential QoS change.

深度解读：

这里引入了一个非常高级的概念——QoS可持续性分析 (QoS Sustainability Analytics)。

  • 从“被动接受”到“主动预测”: 传统QoS是UE发起业务，网络根据策略被动地分配资源。而QoS可持续性分析，则允许AS主动地向网络“咨询”：“我计划在明天下午2点到4点，在北京市海淀区，为1000辆车提供需要5QI=X保障的远程驾驶服务。请你分析一下，届时该区域的网络资源，**能否扛得住（sustain）**我的QoS需求？”

  • 网络分析与反馈: 这个请求会通过NEF，最终送达5G核心网的“数据分析大脑”——NWDAF (Network Data Analytics Function)。NWDAF会根据历史数据、网络负荷预测模型等，进行分析，然后将分析结果（如“预测成功率99%”，或“预测届时网络拥堵，成功率可能降至80%”）反馈给V2X AS。

场景演绎：大型车队的路径规划

一个大型物流公司的V2X平台（AS），计划在第二天安排一个由50辆自动驾驶卡车组成的编队，从北京出发前往天津。这个编队需要全程保持高质量的Uu连接，用于协同调度和状态监控。

  1. AS发起QoS分析请求: 物流平台向5G网络发起一个QoS Sustainability Analytics订阅请求。请求中包含了：

    • Analytics ID: “QoS Sustainability”

    • Location information: 从北京到天津的整条高速公路路径。

    • QoS requirements: 编队业务所需的5QI及其对应的GBR速率。

    • Analytics target period: 明天的具体时间段。

  2. NWDAF进行分析: 核心网的NWDAF收到了这个“远期规划”。它开始分析明天在该条高速公路沿线，所有基站的预测负荷情况。

  3. 网络反馈预测结果: NWDAF通过NEF向物流平台返回分析结果：“预测京津高速北京段在上午9-10点因早高峰，网络负荷较重，可能无法完全满足您的GBR需求。建议避开该时段，或在该路段暂时降低视频回传码率”。

  4. AS调整业务策略: 物流平台收到这个“情报”后，可以提前调整自己的业务策略。例如，它可能会将车队的出发时间推迟到10点以后，或者在应用层设计一个降级逻辑，在进入拥堵路段时自动降低对网络的带宽要求。

这个机制，使得V2-V2X AS与5G网络之间，从简单的“服务使用者”与“服务提供者”关系，升级为一种深度协作、主动预测、协同优化的智能伙伴关系。

3. 变奏乐章：基于应用层需求的QoS动态变更 (5.4.5.3)

除了“远期规划”，V2X AS还需要在业务进行中，根据实时情况，对QoS进行动态调整。5.4.5.3节就为此提供了“快速通道”。

5.4.5.3 QoS Change based on Extended NG-RAN Notification to support Alternative Service Requirements

To support V2X applications that can operate with different configurations (e.g. different bitrates or delay requirements), the V2X Application Server (V2X AS), acting as the Application Function, can provide, in addition to the requested level of service requirements, Alternative Service Requirements to the 5GS.

深度解读：

这里引入了另一个高级QoS特性——备选服务需求 (Alternative Service Requirements)。

  • 从“单一目标”到“多档选项”: 传统的QoS请求，是AS告诉PCF：“我需要达到A标准”。而有了Alternative Service Requirements，AS可以告诉PCF：“我最希望达到A标准（如20Mbps码率），但如果网络实在满足不了，我也能接受B标准（10Mbps码率）或C标准（5Mbps码率），但不能再低了”。

  • 网络侧的智能决策: PCF会将这套“多档选项”下发给网络。当无线环境发生变化时（例如，“智行一号”驶入信号边缘区域），基站（gNB）可以自主地、快速地在这几个预设的档位之间进行切换，而无需每次都去麻烦核心网的PCF重新做决策。

场景演绎：可伸缩的视频流

“智行一号”正在通过Uu链路，向家人直播沿途的风景。这是一个典型的自适应码率视频业务。

  1. AS提供多档需求: 视频平台（AS）在为这条流请求QoS时，向PCF提供了Alternative Service Requirements:

    • 首选: 5QI=X, GBR=8Mbps (1080p高清)

    • 备选1: 5QI=Y, GBR=4Mbps (720p标清)

    • 备选2: 5QI=Z, GBR=1Mbps (360p流畅)

  2. 网络下发策略: PCF将这套“三档 QoS菜单”通过SMF下发到gNB和UE。

  3. gNB的自主“降档”: “智行一号”驶入了一个信号较弱的区域，gNB发现无法再保障8Mbps的GBR。此时，它无需向PCF汇报，而是直接查询本地存储的“备选菜单”，自主决定将这条QoS Flow的保障等级降至4Mbps。

  4. gNB通知应用: 同时，gNB通过“扩展的NG-RAN通知”机制，将这次QoS变更事件通知给核心网，并最终送达V2X AS。

  5. 应用层适配: 视频平台收到通知后，立即指示“智行一号”的应用层，将视频编码的码率从1080p降至720p，从而与网络提供的QoS能力相匹配，保证了视频的连续播放，避免了卡顿。

这个机制，赋予了5G网络极高的QoS自适应能力，使得网络和应用之间能够进行实时的、闭环的协同，为用户提供“永远在线”的平滑业务体验。

总结：云网协同，智能保障

通过对5.4.5节的深度剖析，我们看到了V2X Uu QoS保障体系的先进性与智能性。它不再是网络单方面提供的僵化管道，而是一个由网络、应用和终端三方共同参与的、动态的、可预测的协同系统。

  • 坚实的基础: V2X业务无缝融入5GS通用的QoS Flow和5QI框架，保证了技术的成熟与统一。

  • 应用的话语权: 通过QoS可持续性分析，V2X AS从被动的服务使用者，变成了可以主动预测网络能力、优化业务规划的**“战略伙伴”**。

  • 网络的自适应: 通过备选服务需求和扩展的RAN通知，网络获得了在无线环境变化时，进行快速、自主QoS调整的**“战术灵活性”**，并能与应用层进行实时联动。

“智行一号”的“云端共舞”不再是盲目的。在起舞之前，它可以和“舞伴”（网络）商议舞曲的节奏；在起舞之中，双方还可以根据现场气氛，默契地变换舞步。这种高度的协同与智能，正是5G赋能车联网，实现高级别网联自动驾驶的真正价值所在。

至此，我们已经完整地剖析了5.4节关于QoS处理的全部核心内容。在下一篇文章中，我们将进入5.5节，探讨V2X业务的“户口本”——签约数据。

FAQ

Q1：V2X AS如何与5G核心网的NWDAF进行通信？

A1：V2X AS不能直接与NWDAF通信。它必须通过一个指定的“安全网关”——NEF (Network Exposure Function)。V2X AS（此时扮演AF的角色）向NEF发起标准的API调用请求（Nnef_AnalyticsExposure_Subscribe），NEF会对AS的身份和权限进行鉴权，然后将合法的请求翻译成核心网内部的信令，转发给NWDAF。NWDAF的分析结果也会沿着原路返回。这个机制确保了核心网内部功能的安全性，防止其被外部应用直接、无序地访问。

Q2：QoS可持续性分析（QoS Sustainability Analytics）能做到100%准确吗？

A2：不能。它是一种基于历史数据、统计模型和网络当前状态的预测，而非确定性的承诺。其准确性取决于NWDAF分析模型的先进程度、历史数据的完备性以及网络负荷变化的突发性。但即使不是100%准确，它提供的趋势性和概率性分析结果，对于V2X AS进行中长期的业务规划和风险规避，仍然具有极高的参考价值。

Q3：备选服务需求（Alternative Service Requirements）和我们手机视频App的自适应码率（ABR）有什么关系？

A3：它们是网络层和应用层为实现同一目标（保障体验连续性）而进行的协同工作。手机App的ABR，通常是应用层自己根据检测到的网络吞吐量（如TCP拥塞窗口、丢包率）来被动地调整码率。而Alternative Service Requirements机制，则是网络层（gNB）主动地进行QoS“降档”，并明确地通知应用层：“我现在只能提供4Mbps了！”。应用层收到这个确定性的通知后，可以更快速、更精准地将码率调整到4Mbps。这种“网络通知+应用适配”的模式，比应用层自己“猜测”网络状况，响应更及时，体验更平滑。

Q4：一个PDU会话中可以有多条Uu QoS Flow吗？

A4：是的。一个PDU会话就像一条从UE到数据网络的“主管道”。在这条主管道中，可以并存多条具有不同QoS特性的QoS Flow。例如，“智行一号”为远程驾驶建立了一个PDU会话，这个会话中可以同时包含一条用于视频回传的GBR QoS Flow，和一条用于控制信令的超低时延QoS Flow。SMF负责管理和维护一个PDU会话内所有QoS Flow的生命周期。

Q5：这些高级的QoS功能，对运营商的网络建设提出了哪些要求？

A5：提出了很高的要求。要完整支持本章描述的功能，运营商的网络需要：1. 部署NWDAF：需要建设强大的网络数据分析平台，具备大数据采集、处理和建模分析能力。2. 升级PCF和NEF：需要支持与NWDAF和外部AF交互的最新接口和流程。3. 升级gNB和UE：需要支持“备选服务需求”的解析、存储和基于此的快速QoS切换能力，以及相关的RAN通知机制。4. 端到端网络切片能力：能够为V2X业务提供隔离的、性能可承诺的网络资源。这是一个系统性的、端到端的演进过程。

关系图谱