51学通信

深度解析 3GPP TR 21.917：12 New Radio (NR) enhancements other than layer 1 (非物理层增强)

23分钟阅读

深度解析 3GPP TR 21.917：12 New Radio (NR) enhancements other than layer 1 (非物理层增强)

本文技术原理深度参考了3GPP TR 21.917 V17.0.1 (2023-01) Release 17规范中，关于“12 New Radio (NR) enhancements other than layer 1 (非物理层增强)”的核心章节。本文将揭示5G Rel-17如何超越物理层的“速度与激情”，在协议栈的更高层面进行精细化“内功”修炼，通过智慧压缩和体验遥测，为5G网络注入效率与感知的双重动力。

1. “元境”APP的瓶颈：一位AR应用开发者的“上行”与“体验”双重焦虑

Sophia，是一家炙手可热的AR社交应用“元境（MetaVerse-Next）”的首席架构师。她的应用，允许用户在现实世界中，通过手机或AR眼镜，实时创建和分享高精度的3D虚拟化身（Avatar）和AR物件。这款应用，是“滨海智慧新区”运营商展示其5G网络能力的明星产品。

然而，随着用户量的激增，Sophia的团队正面临两个难以逾越的瓶颈，这些瓶颈，已经超出了应用层优化的范畴：

  1. “首包之困”：当用户在嘉年华现场，想将一个刚刚捏好的、酷炫的3D烟花AR模型分享给朋友时，这个模型的初始数据包虽然不大（几十KB），但由于是未经优化的原始数据，上传过程总有那么零点几秒的延迟。在追求“即时分享”的社交体验中，这点延迟足以让兴奋感大打折扣。更重要的是，在网络拥塞或边缘地带，这个“首包”的上传失败率明显偏高，严重影响了核心功能。

  2. “体验迷雾”：后台的用户反馈系统里，充斥着大量模糊的抱怨：“有点卡”、“戴着AR眼镜有点晕”、“偶尔会掉线”。但当Sophia的运维团队去复现时，却一切正常。他们拥有详尽的服务器日志，却唯独缺少最关键的一环——用户侧的、端到端的真实体验数据。他们不知道，问题究竟出在用户的手机性能、不稳定的无线环境、运营商的网络抖动，还是应用自身的渲染bug。他们如同在浓雾中开船，只能靠猜测去“优化”。

“我们的瓶颈，已经不在应用本身，而在连接的‘智慧’层面。”Sophia在一次与新区5G专家（我们的老朋友，周毅总工）的技术交流会上坦言，“我们需要网络不仅能‘传输’数据，更能‘理解’并‘优化’我们的数据，同时，向我们‘开放’它所感知的用户体验。”

周毅微笑着打开了TR 21.917的第12章。“Sophia，你的痛点，Rel-17已经给出了答案。答案不在物理层，而在更高的协议层。”

2. 超越物理层：5G的“智慧数据流”革命

第12章的标题——“非物理层增强”，本身就揭示了Rel-17演进的一个重要方向：当物理层的速率和时延在不断逼近香农极限时，新的性能增长点，将来自于对数据流本身的智能化处理。

  • 物理层（L1） 关心的是：如何将一串“0101”比特流，更快、更可靠地从A点搬到B点。

  • 非物理层（L2/L3及以上） 则开始关心：我们能否在发送前，让这串“0101”变得更短（数据压缩）？我们能否在传输后，知道这次“搬运”带给用户的真实感受是怎样的（体验测量）？

这正是12.1节的UDC（上行数据压缩） 和12.2节的QoE管理所要完成的使命。它们是5G从“傻快”的管道，走向“智慧”数据平台的关键一步。

3. 12.1 NR上行数据压缩 (UDC)：为“元境”的AR模型“瘦身”

Sophia的“首包之困”，本质上是上行链路的效率问题。尤其对于AR/VR这类应用，未经压缩的原始数据（如点云、模型文件），包含了大量的冗余信息。

12.1 NR Uplink Data Compression (UDC)

This work item specifies NR Uplink Data Compression (UDC), i.e. uplink data can be compressed at the UE and can be decompressed at the NG-RAN node. In this WI, DEFLATE based UDC solution is introduced which uses LTE UDC as baseline.

【深度解读】

Rel-17为此正式在5G NR中引入了UDC（上行数据压缩） 功能。

  • 工作原理：它如同在手机（UE）的协议栈中，内置了一个原生的“ZIP压缩器”。当“元境”App将一个3D模型数据包向下递交给协议栈时，PDCP（分组数据汇聚协议）层会先调用UDC功能，对这个数据包进行实时压缩，然后再加密、发送。数据抵达基站（gNB）后，gNB的PDCP层再调用“解压器”将其还原。

  • 技术基础：UDC采用了业界广泛使用的、成熟的DEFLATE压缩算法（ZIP、GZIP等压缩格式的核心算法），并借鉴了LTE时代已经标准化的UDC方案，确保了技术的可靠性和高效性。

One byte UDC header is introduced to indicate whether the PDCP SDU is compressed by UDC or not, whether the compression buffer is reset or not, and 4 validation bits of checksum are used to indicate whether the compression and decompression buffers are synchronous.

【深度解读】

为了管理这个压缩过程，UDC在每个PDCP包前，增加了一个极简的1字节“标签”（UDC header）。这个小小的标签，却包含了重要的控制信息：

  • 是否压缩：允许网络对不同的业务流（DRB, 数据无线承载）灵活地开启或关闭UDC。例如，可以只为“元境”的AR上传业务开启压缩，而VoIP语音则不压缩。

  • 缓冲区复位：DEFLATE算法是基于“字典”的。如果UE和gNB的“字典”不同步了，压缩和解压就会出错。UE或gNB可以通过这个标志位，通知对方“清空字典，我们重新开始”。

  • 校验和：用于快速验证双方的压缩上下文是否同步，确保解压的正确性。

字典的魔力：UDC的“专业模式”

简单的DEFLATE压缩已经很有用，但Rel-17还为UDC配备了“专业模式”——预定义字典，这正是解决Sophia“首包之困”的“杀手锏”。

Similar as for LTE UDC, to improve compression efficiency of the first packets, two types of pre-defined dictionary can be used for UDC. One is standard dictionary for SIP and SDP signalling as defined in RFC 3485, and another is operator defined dictionary.

【深度解读】

  • 字典的原理：DEFLATE算法的效率，来自于它能找到数据中的重复“词组”，并用一个简短的“代号”来替换。如果事先能为通信双方提供一本“常用词组速查表”（即字典），那么压缩效率，尤其是对第一个数据包的压缩效率，将得到极大的提升。

  • 两种字典：

    1. 标准字典：3GPP预定义了一本用于压缩SIP/SDP信令（IMS通话的核心信令）的字典。

    2. 运营商定义字典：这是最强大的功能！Sophia的团队可以与运营商合作，为“元境”App量身打造一本“专属字典”。

  • 场景还原：

    1. Sophia的团队分析了他们应用中最常见的AR模型，发现其中大量包含了如“球体”、“立方体”、“标准光照材质”等高频出现的3D几何和渲染元数据。

    2. 他们将这些高频“词组”提炼出来，制作成了一本“元境App专属字典”。

    3. 运营商通过OAM系统，将这本字典配置到了网络中，并通过RRC信令，告知“元境”用户的UE：“当你使用‘元境’App时，请加载这本专属字典来执行UDC压缩。”

    4. 现在，当一个用户分享那个3D烟花模型时，UE的UDC功能发现，这个模型80%的内容，都可以在“专属字典”里找到现成的“代号”。于是，第一个数据包的压缩率，从原来的30%飙升到了80%！上传延迟几乎消失，分享体验如丝般顺滑。

NR UDC can be applied to NR-DC, NE-DC and NGEN-DC scenarios. Also, NR UDC can be applied to split bearer type.

【深度解读】

UDC功能的设计具有很好的前瞻性，它能够无缝地工作在NR双连接（NR-DC）、EN-DC以及分离承载（split bearer） 等复杂的场景下，确保了无论用户的连接模式如何，都能享受到压缩带来的好处。

4. 12.2 NR QoE管理：为“体验迷雾”点亮“探路明灯”

解决了“上行”问题，Sophia将目光投向了更棘手的“体验”问题。她需要一双能“看穿”用户手机屏幕的“眼睛”。

12.2 NR QoE management and optimizations for diverse services

The QoE Measurement Collection function enables the collection of application layer measurements from the UE. The measurements are supported for Streaming services, MTSI services, and VR services.

【深度解读】

Rel-17为此引入了QoE（Quality of Experience，体验质量）测量收集功能。它的核心，是让网络有能力“请求”UE上的应用程序（在用户同意的前提下），上报其内部的、应用层面的关键体验指标。

…the feature of QoE Measurement Collection function is activated in the NG-RAN either by direct configuration from the OAM system (management-based activation), or by signalling from the OAM via the Core Network (signalling-based activation)…

【深度解读】

这个功能有两种激活方式：

  • 管理面激活：运营商的运维系统（OAM）可以直接对某个区域、某个用户群（例如，“元境App重度用户群”）下发一个长期的QoE测量任务。

  • 信令面激活：网络（如PCF）可以基于某些实时策略，通过核心网信令，对单个UE发起一次临时的QoE测量请求。

“上帝视角”的开启：App数据与无线数据的“时空同步”

QoE测量的革命性，不在于它能收集App数据，而在于它能将App数据与底层的无线测量数据（MDT），在同一个时间戳上，关联起来。

Radio-related measurements may be collected via immediate MDT for the supported services. The MCE/TCE performs the correlation of the immediate MDT results and the QoE measurement results collected at the same UE.

The following alignments are supported in this Release:

  • Alignment between a signalling-based QoE measurement and a signalling-based MDT measurement.
  • Alignment between a management-based QoE measurement and a management-based MDT measurement.

【深度解读】

场景还原：一位“元境”的重度AR眼镜用户，投诉他在昨晚20:15左右，于智慧港口区域，感到了明显的“眩晕”。

在过去，Sophia的团队对此束手无策。但现在，通过与运营商合作，他们获得了这样一份“时空同步”的日志：

| 时间戳 | QoE报告 (来自“元境”App) | MDT报告 (来自UE底层) | 根因分析 |

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

| 20:15:03 | VR稳定延迟: > 80ms
渲染帧率: < 45fps | 服务小区RSRP: -112dBm
邻区A RSRP: -110dBm | 信号质量差，处于切换边缘 |

| 20:15:04 | (数据中断) | RRC Reconfiguration (切换) | 正在进行小区切换 |

| 20:15:05 | VR稳定延迟: 25ms
渲染帧率: 90fps | 新服务小区RSRP: -95dBm | 切换成功，体验恢复 |

“天哪！这简直是开启了上帝视角！”Sophia在看到这份报告时惊叹道。

困扰他们数月的“体验迷雾”瞬间散去。问题不是出在他们的服务器或App渲染上，而是一次弱覆盖区域下的移动性管理事件（切换），导致了短暂的数据中断，从而引发了AR眼镜的渲染卡顿和眩晕。

有了这份报告，Sophia的团队可以：

  1. 精准甩锅…哦不，是精准定位：将问题反馈给运营商的网络优化团队（欧阳慧总工），并附上精确的时间、地点和无线测量证据。

  2. 主动优化：在App层面增加一个“预缓冲”机制。当底层上报即将发生切换时，应用可以提前加载一些渲染资源，以平滑渡过切换带来的短暂中断。

RAN可见QoE：让基站更“懂”你的视频

除了将数据上报给后台，Rel-17还引入了一种更轻量级的模式。

RAN visible QoE measurements are configured by the NG-RAN node, where a subset of QoE metrics is reported from the UE as an explicit IE to NG-RAN node. … RAN visible QoE measurements are supported for the DASH streaming and VR service.

【深度解读】

这意味着，UE可以将一些最核心、最实时的QoE指标（例如，DASH视频的缓冲区大小、VR业务的延迟），直接上报给当前服务的基站（gNB）。

  • 好处：基站的调度器，第一次能够“看到”上层应用的实时“脸色”。如果它发现某个用户的视频缓冲区即将耗尽，它就可以在接下来的无线调度中，临时地、动态地为这个用户分配更多的资源，“拉他一把”。这使得无线资源的调度，从“尽力而为”，走向了“体验驱动”。

5. 总结：UDC与QoE，5G的“效率”与“感知”双翼

TR 21.917的第12章，虽然没有L1物理层那样惊心动魄的速率飞跃，但它所带来的，是一次更深刻、更具智慧的“内功”提升。UDC和QoE管理，如同为5G这只猛虎，插上了一对效率与感知的双翼。

  • UDC（上行数据压缩），通过为数据“瘦身”，尤其是利用“专属字典”为特定应用“精准瘦身”，极大地提升了上行传输效率，降低了时延和功耗。它让5G网络更“懂”数据。

  • QoE管理（QoE Management），通过打通应用层与无线层的“次元壁”，实现了体验与信令的“时空同步”，为网络优化和应用开发提供了前所未有的“上帝视角”。它让5G网络更“懂”用户。

对于像Sophia这样的应用开发者，这两项功能是“久旱逢甘霖”。它们第一次将网络的底层能力，与上层应用的真实需求，如此紧密地结合在了一起。5G，也因此不再仅仅是一个冰冷的通信管道，而是一个能够与应用“对话”、协同进化的智能使能平台。

FAQ

Q1：UDC（上行数据压缩）是强制开启的吗？它会消耗手机的CPU和电量吗？

A1：UDC是可选的，由网络侧（gNB）根据业务类型（DRB）来为UE配置是否开启。它确实会消耗一定的CPU计算资源和相应的电量。但对于大多数场景，压缩数据所节省的无线传输时间（从而节省了PA功耗）和重传开销，远远超过了压缩本身所消耗的计算功耗，因此总体上是更省电的。特别是对于上行受限或信道条件差的场景，UDC带来的增益尤其明显。

Q2：UDC的“运营商定义字典”是如何工作的？需要我手动安装吗？

A2：它是由运营商和应用提供商（如“元境”App的公司）合作，在后台完成配置的，对用户完全透明。应用提供商负责提炼和制作字典，运营商负责将字典部署到网络中。当你的UE使用该应用时，网络会通过RRC信令，自动指示你的UE加载并使用这本专属字典。你无需进行任何手动操作。

Q3：QoE测量收集功能会泄露我的隐私吗？

A3：3GPP在设计QoE功能时，对隐私保护有严格的规定。首先，所有QoE测量任务的开启，都需要得到用户的明确授权同意。其次，上报的数据通常是匿名的、统计性的，用于改善网络和应用服务，而非针对个人。最后，所有数据的收集和使用，都必须遵循当地的法律法规（如GDPR）。运营商和应用厂商有责任确保你的隐私数据安全。

Q4：QoE管理和我们App里自带的APM（应用性能监控）工具有什么不同？

A4：传统的APM工具，通常只能收集到应用层面的数据（如UI卡顿、网络请求时延等），它是一个“黑盒”，无法知道底层的网络发生了什么。而5G的QoE管理，其核心价值在于打通了应用层与无线物理层。它能将“App卡了”这个现象，与“此时此刻UE正好处在一个弱覆盖区域，RSRP只有-120dBm”这个物理层的事实，进行精确的时间戳关联，从而实现了从“知其然”到“知其所以然”的飞跃，为根因定位提供了最直接的证据。

Q5：作为一名应用开发者，我如何才能用上这些强大的UDC和QoE功能？

A5：你需要与移动运营商进行合作。对于UDC，你需要分析你应用的数据特征，制作一本高效的“专属字典”，并提供给运营商进行网络侧的配置。对于QoE，你需要根据3GPP定义的相关规范（如TS 26.5xx系列），在你的App中集成QoE上报的客户端（Agent），并与运营商协商你需要收集哪些指标，以及数据如何上报和使用。这将是一种全新的“网络-应用”深度协同开发模式。

关系图谱