51学通信

深度解析 3GPP TS 23.501：5.45 & 5.46 QoS监控与AIML辅助 (从网络自知到应用智能)

20分钟阅读

本文技术原理深度参考了3GPP TS 23.501 V18.9.0 (2025-03) Release 18规范中，关于“5.45 QoS Monitoring”和“5.46 Assistance to AI/ML Operations in the Application Layer”的核心章节，旨在为读者提供一个5G网络如何从被动的性能保障者，演进为主动的、具备自我感知能力和应用辅助智能的“智慧网络”的全景视图。

深度解析 3GPP TS 23.501：5.45 & 5.46 QoS监控与AI/ML辅助 (从网络自知到应用智能)

欢迎来到“解构5G核心网”系列。在前面的文章中，我们已经探索了5G如何通过切片、冗余传输等机制，为不同业务构建定制化的、高可靠的“虚拟专属公路”。然而，仅仅修好路是不够的，我们还需要知道路况如何，甚至需要网络本身能够成为智能交通系统的一部分，主动为路上的“车辆”（应用）提供导航和调度建议。

今天，我们将深入探讨规范中两个极具前瞻性的章节：5.45 QoS Monitoring（QoS监控） 和 5.46 Assistance to AI/ML Operations in the Application Layer（对应用层AI/ML操作的辅助）。这两个章节标志着5G网络的一个根本性转变：从一个单纯的数据管道，演变为一个能够自我感知（监控自身性能）并主动赋能（辅助上层应用）的智能平台。

为了将这些抽象但强大的概念联系起来，让我们进入今天的综合场景：“未来城市（Future City）”。这座城市的“大脑”——一个名为**“City Brain”**的AI驱动的城市管理平台，正通过5G网络，对城市的交通、环境、安全进行着精细化的实时管理。

  • QoS监控的挑战： “City Brain”需要实时接收来自全市数千个关键路口摄像头的高清视频流，用于交通事故的瞬时检测。任何视频流的延迟、抖动或带宽下降，都可能导致事故响应的延误。

  • AI/ML辅助的挑战： “City Brain”需要通过联邦学习（Federated Learning），利用在城市中行驶的数万辆网联汽车的实时数据，来训练一个更精准的交通拥堵预测模型，但前提是不能将任何车辆的原始行驶数据上传到云端，以保护用户隐私。

我们将跟随“City Brain”的视角，看看5G网络是如何通过5.45 QoS监控来保障其“千里眼”的清晰稳定，又是如何通过5.46 AI/ML辅助来为其“最强大脑”的训练提供关键助力的。

1. 让网络拥有“心率计”：QoS监控 (5.45 QoS Monitoring)

传统的QoS机制更多是“配置与保障”，即网络根据策略为业务流分配资源并尽力满足其要求。但网络并不会主动、实时地告诉应用“我现在为你提供的服务质量到底怎么样”。5.45章节弥补了这一环，为网络安装了“心率计”和“血压计”。

QoS monitoring comprises of measurements of QoS monitoring parameters and reports of the measurement result for a QoS Flow and can be enabled based on 3rd party application requests and/or operator policies configured in the PCF.

1.1 核心理念：从“保障”到“感知”

QoS监控的核心，是允许AF（应用功能，即“City Brain”）按需向网络（通过PCF）订阅特定QoS Flow的性能指标。网络（主要是UPF和RAN）会进行实时测量，并将结果上报。这使得应用层能够实时感知其数据流在5G网络中的真实传输质量。

1.2 可监控的关键指标

规范定义了多个可被监控的核心指标，每一个都对应着应用体验的关键维度：

1.2.1 包延迟监控 (5.45.2 Packet delay monitoring)

QoS Monitoring for packet delay allows for the measurement of UL packet delay, DL packet delay or round trip packet delay between UE and PSA UPF. The details of the QoS Monitoring for packet delay are described in clause 5.33.3.

这允许“City Brain”精确测量从交通摄像头（UE）到边缘UPF（PSA）的上行延迟，以及从控制中心到摄像头的下行延迟，乃至往返延迟（RTT）。这对于需要远程控制摄像头（如调整焦距、转动方向）的场景至关重要。

1.2.2 拥塞信息监控 (5.45.3 Congestion information monitoring)

The NG-RAN may be required to provide the UL and/or DL QoS Flow congestion information to UPF… The UPF may be required to monitor and expose the UL and/or DL QoS Flow congestion information reported from the NG-RAN.

这允许“City Brain”获取到其视频流所经过的无线链路的拥塞程度（例如，一个拥塞百分比）。这比我们之前在5.37章节中讨论的ECN/L4S机制更进一步，它不仅能让应用被动感知拥塞，还能让AF主动查询和获取量化的拥塞数据，用于更宏观的流量调度和网络分析。

1.2.3 数据率监控 (5.45.4 Data rate monitoring)

The QoS Monitoring for data rate allows the measurement of the UL and/or DL data rate per QoS flow at the PSA UPF and it can be applied to a Non-GBR or GBR QoS flow.

这是最直观的监控，允许“City Brain”实时查看每个交通摄像头的实际上行视频码率是否达到了预设的目标（如8Mbps），或者是否存在异常的下降。

1.3 监控流程

  1. AF发起请求： “City Brain”（AF）向PCF发起一个QoS监控请求，指定它关心哪个UE（或哪类业务）的哪个数据流（通过SDF模板识别），以及需要监控哪些指标（如DL延迟、UL拥塞度）。

  2. PCF授权与下发策略： PCF对AF的请求进行鉴权，并将其转化为具体的PCC规则，下发给SMF。

  3. SMF配置网络： SMF根据PCC规则，向UPF和NG-RAN下发相应的测量指令。例如，它会通过N4接口，指示UPF为特定的QoS Flow开启时延测量；通过N2接口，指示NG-RAN开启对空口拥塞度的监控。

  4. UPF/RAN执行与上报： UPF和NG-RAN执行测量任务。UPF会收集自身的测量结果和来自NG-RAN（通过GTP-U扩展头上报）的测量结果，进行汇总，并按照SMF的指令（例如，周期性上报，或在超过阈值时上报）将报告发送给SMF。

  5. 结果传递给AF： SMF将收到的监控报告传递给PCF，PCF再最终将结果通知给订阅该事件的“City Brain”（AF）。

场景代入：

为了保障十字路口摄像头的视频流质量，“City Brain”向PCF订阅了该视频流的上行包延迟和上行拥塞度。

  • PCF生成策略，SMF指示UPF和gNB开始监控。

  • 在晚高峰期间，gNB检测到空口拥塞度上升到30%，它将这个信息通过GTP-U头上报给UPF。

  • UPF同时测量到数据包从gNB到它的传输延迟增加了5ms。

  • UPF将这些信息汇总，通过N4接口上报给SMF，SMF再通过PCF通知”City Brain”。

  • “City Brain”收到通知后，立即做出决策：暂时将该摄像头的视频码率从4K降低到1080p，以适应网络拥塞，保证视频的连续性，同时向交通管理系统发出预警。

2. 从“工具”到“伙伴”：5G对AI/ML的辅助 (5.46)

如果说QoS监控是让网络学会了“看”，那么AI/ML辅助就是让网络学会了“说”和“做”，成为应用层智能任务的得力助手。

This clause describes the list of 5GC enablers to support the following AI/ML operations in the Application layer over the 5G System:

  • AI/ML operation splitting between AI/ML endpoints;
  • AI/ML model/data distribution and sharing;
  • Distributed/Federated Learning.

2.1 核心理念：网络即服务（NaaS）的智能化延伸

5G网络积累了海量的、实时的、与UE状态和网络环境相关的数据。这些数据对于上层的AI应用来说，是一座巨大的金矿。5.46章节的核心，就是定义一套标准的API和流程，让AF可以安全、高效地“挖掘”这座金矿，请求网络为其AI任务提供决策支持。

2.2 核心能力：成员UE选择辅助 (5.46.2 Member UE selection assistance functionality)

这是本章最核心、最具代表性的功能，完美契合了联邦学习等分布式AI场景的需求。

5G System may support Member UE selection assistance functionality to assist the AF to select member UE(s) that can be used in application operations such as AI/ML based applications (e.g. Federated Learning)…

Receiving a request from the AF that shall include a list of target member UE(s)… and one or more filtering criteria as specified in Table 4.15.13.2-1 of TS 23.502… (e.g. UE current location, QoS requirements, DNN, preferred access/RAT type…).

流程解析：

  1. AF（“City Brain”）提出“招募”需求： “City Brain”想要启动一轮联邦学习，它向NEF（网络开放功能）发送一个“成员选择辅助”请求。这个请求包含了：

    • 目标群体 (target member UEs): 例如，所有在线的、已授权参与该项目的网联汽车。

    • 过滤条件 (filtering criteria): 这是关键！AF可以提出非常精细的条件，例如：

      • 位置： “必须位于三环以内的车辆”。

      • 网络状态： “当前必须通过5G NR接入，且上行链路能够提供至少5Mbps的带宽”。

      • UE状态： “电池电量必须大于80%”（此信息需要UE配合上报）。

      • QoS能力： “能够支持低时延的QoS Flow”。

  2. NEF扮演“猎头”和“协调官”： NEF接收到这个复杂的请求后，开始在5GC内部进行“尽职调查”。它会：

    • 查询AMF： 获取UE的当前位置（TAI、Cell ID）、接入类型（NR/LTE）。

    • 查询PCF/SMF： 了解UE当前的PDU会话状态和QoS情况。

    • 查询NWDAF： 获取关于UE历史移动性、网络拥塞预测等更深度的分析数据。

    • 查询UDM： 获取UE的签约信息。

  3. NEF返回“候选人名单”： NEF将所有满足条件的UE筛选出来，形成一个**“候选UE列表”**，并可能附带额外的信息（如每台车的具体位置、预估的网络质量等），返回给“City Brain”。

  4. AF做出最终选择： “City Brain”从这个高质量的候选名单中，选择最终参与本轮联邦学习的车辆，并向它们下发训练任务。

场景代入： “City Brain”的联邦学习任务

  1. 需求： “City Brain”需要招募1000辆车，在晚高峰期间，于东三环区域，共同训练一个新的拥堵预测模型。

  2. 向NEF请求： 它发送请求：“目标群体：所有‘未来交通’项目成员车辆。过滤条件：TAI列表 = [东三环区域的TAIs]；时间窗口 = 17:00-19:00；网络要求 = 能够建立一个上行速率不低于2Mbps的QoS Flow；UE状态 = 车辆正在行驶中”。

  3. NEF的“海选”： NEF开始工作，它与AMF、PCF、NWDAF等多个NF交互，从数万辆在线汽车中，筛选出了1500辆完全符合条件的候选车辆。

  4. “City Brain”的“终选”： “City Brain”收到了这1500辆车的列表。它的AI算法根据更复杂的内部逻辑（例如，考虑车辆的分布密度），从中挑选出最终的1000辆车，并通过应用层信道向它们派发了模型训练任务。

通过这个流程，5G网络不再是一个被动的管道，而是成为了AI应用实现过程中的一个智能调度伙伴，帮助应用在正确的时间、正确的地点，找到了最合适的执行者。

5. FAQ

Q1: QoS监控是由哪个网络功能（NF）最终执行测量的？

A:

测量是由最靠近数据源头的NF执行的。

  • 对于RAN侧的指标（如空口时延、无线拥塞度），测量由NG-RAN（基站）执行。

  • 对于核心网侧的指标（如N3/N9隧道时延、数据率），测量由UPF执行。

UPF通常会作为测量结果的汇聚点。它收集自身的测量数据，并接收由NG-RAN在GTP-U扩展头中上报的测量数据，然后将完整的端到端（UE-UPF）性能报告发送给SMF。

Q2: AF可以直接从UPF获取QoS监控数据吗？

A:

可以，这是一种更高效的“直连”模式。规范在5.20d (User Plane Direct 5GS Information Exposure)中提到，为了降低信令链路的负载和延迟，SMF可以授权并指示UPF，将某些监控事件的报告直接发送给一个已知的、受信任的消费者（如位于边缘的AF或L-NEF），而无需经过SMF → PCF → NEF的漫长路径。这对于需要极低延迟反馈的边缘计算应用尤其重要。

Q3: AI/ML辅助功能是否会泄露我的个人隐私？

A:

不会。3GPP在设计这个功能时，充分考虑了隐私保护。

  • AF的请求是“群发”和“匿名的”： AF向NEF发起的请求，是面向一个群体（如所有车辆），并提出一组条件。它并不知道具体哪个UE满足这些条件。

  • NEF作为“隐私屏障”： NEF在内部进行筛选，它只会向AF返回满足条件的UE列表，并且返回的ID可以是临时的、经过脱敏的标识符，而非用户的永久身份（SUPI）。

  • 联邦学习的隐私特性： 联邦学习技术本身就是为隐私保护而设计的。原始数据（如您的精确行驶轨迹）始终保留在您的设备上，只有经过本地训练后生成的、不含个人信息的模型更新参数才会被上传。

Q4: 在“成员UE选择”中，NEF是如何知道UE的电池电量等设备状态的？

A:

这是一个很好的问题。网络本身通常是不知道UE的电池电量等纯设备信息的。这需要UE与网络的协同。

  1. UE上报： UE的应用或者操作系统，可以通过NAS信令，主动地将一些自身的状态信息（如电池电量、CPU负载、是否处于充电状态等）上报给网络（AMF）。这种上报通常是可选的，并且需要用户授权。

  2. 网络存储与利用： AMF接收到这些信息后，会将其存储在UE的上下文中。当NEF在进行成员筛选时，就可以向AMF查询这些状态信息，作为其过滤条件之一。

这个机制体现了5G从单纯的网络信息，扩展到了网络信息与终端信息相融合的智能决策。

Q5: 如果没有5.46的AI/ML辅助功能，应用就不能实现联邦学习了吗？

A:

仍然可以实现，但效率和效果会大打折扣。

  • 没有网络辅助的情况： 应用服务器（AF）只能采用“盲选”或“粗选”的方式。例如，它可能会向所有在线的UE都下发一个试探性的任务请求，然后等待UE的回应。

  • 带来的问题：

    • 资源浪费： 大量网络状况不佳（如信号差、带宽低）或UE状态不合适（如电量低）的设备也会收到请求，造成信令风暴。

    • 训练失败率高： 很多被选中的UE可能因为网络问题无法完成模型训练和上传，导致本轮学习失败或效果不佳。

    • 用户体验差： 在不合适的时候（如用户正在玩游戏）启动AI任务，会严重影响用户体验。

而5G的AI/ML辅助功能，通过网络的“预筛选”，确保了AF从一开始接触到的就是高质量的、有意愿、有能力的候选者，极大地提升了分布式AI应用的成功率和效率，同时降低了对网络和用户的干扰。

关系图谱