51学通信

深度解析 3GPP TS 23.501：5.37 XR与交互式媒体支持

22分钟阅读

本文技术原理深度参考了3GPP TS 23.501 V18.9.0 (2025-03) Release 18规范中，关于“5.37 Support for high data rate low latency services, eXtended Reality (XR) and interactive media services”的核心章节，旨在为读者提供一个5G网络如何通过一系列精密的协同机制，支撑未来沉浸式、交互式应用的全景视图。

深度解析 3GPP TS 23.501：5.37 XR与交互式媒体支持

欢迎来到“解构5G核心网”系列。随着我们对5G探索的深入，今天我们将触及5G承诺中最令人心驰神往的领域——XR（扩展现实）、云游戏和全息通信等沉浸式交互媒体。这些应用不仅仅是“更快”的视频，它们代表了人机交互的未来，对网络提出了前所未有的、多维度的严苛挑战。

在正式进入5.37章节的深度解析之前，我们需要简要提及5.36 RIM Information Transfer。这是一个相对底层的机制，全称为“Remote Interference Management Information Transfer”，允许RAN节点之间通过核心网（AMF）透明地传递与远程干扰管理相关的信息。这是一种RAN内部的协同机制，对核心网的功能和架构影响较小，因此我们在此简述带过，将焦点完全集中在更具革命性的5.37章节。

5.37章节是5G技术演进的“集大成者”，它将QoS、策略控制、用户面功能、RAN调度等多个领域的能力进行了深度融合与增强，其目标不再是简单地保障连接，而是要主动管理和保障端到端的交互体验。

为了将这些高度抽象的技术概念具象化，让我们引入今天的主角——Leo，一位专业的XR体验设计师。他正置身于一场未来派的户外音乐节，戴着先进的AR眼镜。他看到的不再仅仅是真实的舞台，而是一个叠加了虚拟特效、允许他与虚拟偶像实时互动的增强现实世界。他的每一次头部转动、每一次手势操作，都需要网络在毫秒之内做出响应，否则虚拟与现实的割裂感（即“晕动症”）将彻底摧毁这次沉浸式体验。

我们将跟随Leo的视角，剖析5G网络是如何协同其“十八般武艺”，为这场极致的XR盛宴提供坚如磐石的网络支撑的。

1. XR的挑战：一个多维度的网络“考卷” (5.37.1 General)

规范首先概述了支撑XR和交互式媒体所需的“能力工具箱”。这不仅仅是一个功能，而是一系列功能的协同作战。

This clause provides an overview of 5GS functionalities for support of XR services (AR/VR applications) and interactive media services that require high data rate and low latency communication… Further enhancements for these interactive media services are as follows:

  • The 5GS may support QoS policy control for multi-modal traffic, see clause 5.37.2.
  • The 5GS may support network information exposure which can be based on ECN markings for L4S, see clause 5.37.3 or 5GS exposure API, see clause 5.37.4.
  • The 5GS may support PDU Set based QoS handling including PDU Set identification and marking, see clause 5.37.5.
  • The 5GS may ensure that the UL and DL packets together meet the requested round trip delay and also update the delay for UL and DL considering QoS monitoring results, see clause 5.37.6.
  • The 5GS may perform per-flow Packet Delay Variation (PDV) monitoring and policy control according to AF provided requirements, see clause 5.37.7.
  • The 5GC may provide traffic assistance information to the NG-RAN to enable Connected mode DRX power saving, see clause 5.37.8.

解读：

这段原文为我们列出了一份“能力清单”，每一项都直指XR业务的核心痛点：

  1. 多模态业务的策略控制： XR应用不只是单一的数据流。它同时包含上行的传感器数据（头部、手势）、下行的高清视频流、音频流，甚至触觉反馈流。这些数据流虽然服务于同一个应用，但其QoS需求截然不同。网络必须能够识别它们之间的关联性，并进行协同策略控制。

  2. 拥塞信息暴露 (ECN for L4S): XR对时延抖动极其敏感。传统的网络拥塞后丢包重传机制是灾难性的。L4S（低延迟、低损耗、可扩展吞吐）和ECN（显式拥塞通知）机制，允许网络在拥塞发生前就向应用“预警”，让应用主动调整码率，从而避免延迟和丢包。

  3. PDU Set处理： 应用层的一个逻辑数据单元（如一帧视频、一个完整的3D模型更新）可能被分割成多个IP包。网络需要理解这些IP包的“集体性”，确保整个“集合”（PDU Set）能在指定的时延预算（PSDB）内完整到达，否则单个包的准时到达毫无意义。

  4. 往返时延（RTT）保障： 对于交互式应用，往返时延是金标准。网络需要能够根据应用请求的RTT目标，智能地分解为上行和下行的时延预算，并进行监控和保障。

  5. 时延抖动（PDV）监控： 稳定的时延比单纯的低时延更重要。网络需要具备监控和控制时延抖动的能力。

  6. 智能节电： XR设备通常是电池供电。网络需要根据XR应用的周期性流量模式，智能地配置DRX（非连续接收），在保证低时延的同时最大限度地节省电量。

场景代入：

Leo的AR眼镜，正是上述所有挑战的集合体。它需要多模态支持（视频、音频、控制）；需要网络通过ECN for L4S提供拥塞预警；其渲染的每一个虚拟特效都是一个PDU Set；他与虚拟偶像的每一次互动都受限于RTT；视频流的流畅度取决于PDV；而眼镜的续航则依赖于智能DRX。

2. 识别“交响乐”：多模态业务的策略控制 (5.37.2 Policy control enhancements to support multi-modal services)

如何让网络知道多个看似独立的数据流，其实是在合奏一首“交响乐”？答案是引入一个新的标识符。

The Nnef_AFsessionWithQoS service allows the AF to provide, at the same time, for each data flow that belongs to the multi-modal service, a Multi-modal Service ID, the service requirements and the QoS monitoring requirements:

  • The Multi-modal Service ID is an explicit indication that data flows are related to a multi-modal service. The PCF may use this information to derive the correct PCC rules and to apply appropriate QoS policies for the data flows that are part of a specific multi-modal application.

核心机制：Multi-modal Service ID

  • AF发起： 当AR应用服务器（AF）为Leo的AR体验请求网络资源时，它会为所有相关的数据流（上行传感器、下行视频、下行音频等）打上一个相同的“多模态业务ID”。

  • PCF识别与关联： PCF收到这些带有相同ID的请求后，立即明白了它们属于同一个应用场景。这使得PCF能够：

    1. 进行关联策略决策： 例如，PCF可以制定一个策略：“只有当视频流的QoS得到保障时，才允许建立与之关联的触觉反馈流”。

    2. 简化管理： 运营商可以对这个ID进行整体的策略控制和计费，而不是对几十个独立的数据流逐一进行管理。

    3. 协同QoS监控： PCF可以同时为这些关联的数据流启动QoS监控，以评估整个多模态业务的端到端体验。

场景代入：

Leo的AR眼镜启动后，其应用服务器（AF）向PCF发起了3个独立的QoS请求，但都带了同一个ID：Multi-modal Service ID = "AR_Concert_Leo_123"。

  1. 请求1（视频流）： 要求5QI=84，高带宽。

  2. 请求2（音频流）： 要求5QI=1，低时延。

  3. 请求3（上行控制流）： 要求5QI=83，超低时延。

PCF看到这三个请求共享同一个ID，便知道它们是“一伙的”。它会同时对这三个请求进行授权，并生成关联的PCC规则下发给SMF，确保这首“AR交响乐”的三个“声部”都能得到应有的保障。

3. “从被动丢包到主动降速”：ECN Marking for L4S (5.37.3)

这是保障XR流畅体验的“黑科技”。它改变了网络应对拥塞的方式。

L4S (Low Latency, Low Loss and Scalable Throughput)… exposes congestion information by marking ECN bits in the IP header of the user IP packets between the UE and the application server to trigger application layer rate adaptation.

In 5G System, ECN marking for L4S is enabled on a per QoS Flow basis… is supported in either the NG-RAN… or in the PSA UPF…

核心机制：

  • 传统拥塞控制： 当网络拥塞时，路由器开始丢弃数据包。上层协议（如TCP）检测到丢包后，才大幅降低发送速率。这个过程是被动的、滞后的，并且会导致数据重传，对XR是致命的。

  • L4S + ECN：

    1. 标记： 当NG-RAN或UPF的队列开始有堆积趋势（但还未到丢包的程度）时，它不会丢弃数据包，而是在该数据包的IP头中设置一个**ECN（显式拥塞通知）**标记。

    2. 反馈： 接收端（UE或应用服务器）收到这个带有标记的数据包后，会在返回的确认包（如TCP ACK）中也带上一个标记，告知发送端：“前方路况开始拥堵，请稍微减速”。

    3. 主动降速： 发送端的L4S算法收到这个反馈后，会主动地、平滑地降低发送速率，从而避免了真正的拥塞和丢包的发生。

场景代入：

音乐节高潮时，大量观众上传视频导致基站上行开始拥堵。

  • 无L4S的情况： 基站开始丢弃Leo AR眼镜的上行头部姿态数据包。他的AR世界会突然卡住，然后发生“跳变”，体验极差。

  • 有L4S的情况：

    • 基站检测到上行队列正在变长，它开始为Leo的上行数据包打上ECN标记。

    • 远端的AR服务器收到了这些标记，并通过下行数据流中的反馈，告知了Leo的AR眼镜：“基站有点忙，请稍微降低一点你的头部姿态上报频率（比如从120Hz降到90Hz）”。

    • Leo的AR应用主动降低了上报频率，基站的拥塞得以缓解。

整个过程中，没有任何数据包被丢弃。Leo可能完全没有察觉到任何异常，或者只是感觉虚拟画面的响应极其轻微地“柔和”了一点，但绝不会出现卡顿或跳变。

4. “打包”交付：PDU Set处理机制 (5.37.5 PDU Set based Handling)

对于XR应用，单个数据包的准时到达意义不大，一个完整的应用数据单元（如一帧画面）的完整、准时交付才是关键。

A PDU Set is comprised of one or more PDUs carrying an application layer payload such as a video frame or video slice. The PDU Set based QoS handling by the NG-RAN is determined by PDU Set QoS Parameters in the QoS profile (specified in clause 5.7.7) and PDU Set Information provided by the PSA UPF via N3/N9 interface…

4.1 PDU Set的核心概念与参数

  • PDU Set: 一个或多个数据包的集合，它们在应用层构成一个逻辑单元。

  • PDU Set信息： UPF在处理下行数据时，通过应用层协议（如RTP头）识别出哪些数据包属于同一个PDU Set，并会在GTP-U头的扩展头中，为这些数据包打上标记，如：

    • PDU Set Sequence Number

    • End PDU of the PDU Set

    • PDU Set Importance (指示这个“数据包集合”的重要性)

  • PDU Set QoS参数：

    • PSDB (PDU Set Delay Budget): 整个PDU Set从发送端到接收端所需满足的时延预算。

    • PSER (PDU Set Error Rate): 整个PDU Set的允许丢失率。

4.2 场景代入：虚拟烟花的准时绽放

AR应用服务器要向Leo的眼镜发送一个绚丽的虚拟烟花特效。这个特效由30个IP包组成。

  1. UPF打包标记： UPF收到了这30个数据包，它识别出它们都属于同一个视频帧，于是为它们打上了相同的PDU Set Sequence Number，并在最后一个包上标记了End PDU of the PDU Set。

  2. RAN的“集体”调度： NG-RAN收到了这些带有PDU Set信息的数据包。它的调度器（Scheduler）的目标不再是孤立地处理每个包，而是要确保这整个PDU Set能够在PSDB（例如20ms）内被完整地调度和发送出去。

  3. 拥塞处理： 如果发生拥塞，需要丢包，RAN会根据PDU Set Importance来做决策。它可能会选择丢弃一个重要性较低的、完整的PDU Set（例如，一个背景贴图的更新），来为一个重要性高的PDU Set（如这个烟花特效）腾出资源。这避免了丢弃一个PDU Set中的部分数据包，导致“残缺”数据浪费带宽的无效传输。

5. FAQ

Q1: URLLC和本章介绍的XR/交互式媒体服务，有什么区别？

A:

URLLC是一个基础通信服务类别（由SST=2定义），它提供了低时延和高可靠性的网络能力。而XR/交互式媒体服务是构建在URLLC能力之上的一类具体应用。5.37章节定义的这些增强功能（如PDU Set处理、多模态支持等），正是为了让5G的URLLC能力能够更好地、更精细地服务于XR这类复杂的应用场景。可以理解为，URLLC是“高性能跑车”，而5.37是为这辆跑车配备的“导航系统”、“主动悬挂”和“驾驶辅助”，让它能在复杂的“XR赛道”上跑得又快又稳。

Q2: L4S/ECN机制是否需要应用本身的支持？

A:

是的，必须需要。L4S/ECN机制是一个端到端的协同机制，网络和应用（或终端操作系统）缺一不可。

  • 网络（RAN/UPF）负责检测拥塞趋势并标记ECN比特位。

  • 终端/应用负责接收和反馈ECN标记，并根据反馈主动调整自己的发送速率。

如果应用不具备L4S算法，即使网络在IP包上打了ECN标记，应用也无法识别和响应，这个机制就无法生效。因此，推广L4S需要整个生态（网络设备商、运营商、终端厂商、应用开发者）的共同努力。

Q3: 什么是PDU Set Importance？它和ARP有什么关系？

A:

两者都是优先级指标，但作用的粒度和层面不同。

  • ARP（分配与保持优先级）作用于QoS Flow层面。它决定了在网络资源竞争时，哪个QoS Flow应该被优先保留，哪个可以被抢占。它管理的是**“流”与“流”**之间的优先级。

  • PDU Set Importance作用于QoS Flow内部的PDU Set层面。它定义了在同一个QoS Flow内部，当需要丢弃数据时，哪个PDU Set应该被优先保留。它管理的是**“包集合”与“包集合”**之间的优先级。

例如，一个视频流QoS Flow，可能同时传输着关键帧（I帧）的PDU Set和非关键帧（P/B帧）的PDU Set。它们的PDU Set Importance就可以被设置得不同，以便在拥塞时，RAN会优先丢弃非关键帧，从而最大程度地保障视频质量。

Q4: “往返时延（RTT）保障”和PDB（包延迟预算）有什么不同？

A:

PDB和RTT都是时延指标，但衡量的维度不同。

  • PDB (Packet Delay Budget)是单向时延的预算。它定义了一个数据包从发送端到接收端所允许的最大延迟。UL PDB和DL PDB可以被独立配置。

  • RTT (Round-Trip Time)是往返时延。它衡量的是从一个指令发出，到收到该指令的响应所经过的总时间，即 RTT = UL Delay + DL Delay + 对端处理时延。

对于交互式应用，RTT是衡量用户体验的最终指标。AF可以向PCF请求一个RTT目标，PCF再智能地将这个总的RTT目标分解为对上行QoS Flow的UL PDB要求和对下行QoS Flow的DL PDB要求，并下发给SMF去执行。

Q5: 这些复杂的XR增强功能对手机的硬件和软件有什么要求？

A:

要求非常高，这也是为什么XR被视为5G的“杀手级应用”之一。

  • 硬件上： 需要高性能的调制解调器（Modem）来处理复杂的无线调度和低时延传输，需要强大的应用处理器（AP）来进行XR渲染，以及高效的电源管理来保证续航。

  • 软件上：

    • 操作系统/协议栈需要支持L4S/ECN、MPTCP/MPQUIC等新协议。

    • 应用层需要能够将数据打包成PDU Set，并能够根据网络的QoS监控反馈（如时延、拥塞）动态调整自身的行为。

    • NAS层也需要支持相关的能力协商，向网络表明自己支持这些高级功能。

这些功能的实现，需要从芯片、终端、操作系统到上层应用的全产业链协同创新。

关系图谱