摘要：本文基于3GPP R2-2508033提案，分析了6G服务感知框架选择通用化路径而非应用定制化的技术原因。通过证明XR视频编码与AI token生成在流量元数据层面的同构性，提出通用框架是QoS抽象第三次跃迁的必然结果，并论述了这一选择对6G标准化的战略意义。

关键词：6G服务感知，通用框架，流量元数据，QoS演进，PDU Set，XR，移动AI

一、问题的提出

3GPP RAN2工作组在讨论6G服务感知框架时，需要回答一个根本问题：是为XR、移动AI等每一类应用定制专属协议，还是抽象出一套通用框架？

这个问题并不新鲜。5G时代，网络切片曾被寄予厚望，希望通过为不同应用场景提供定制化的端到端网络能力来解决QoS问题。然而商业化实践表明，过度定制化导致标准复杂度和运营成本双重上升，最终成为"技术上可行、商业上难以持续"的典型案例。

6G能否避免重蹈覆辙？但问题在于，XR和移动AI这些新应用的流量特征确实与传统eMBB大不相同：

• 视频编码器会产生帧间依赖关系
• AI模型推理会生成具有不同重要性的token序列

如果RAN对这些应用特征一无所知，如何提供真正有效的QoS保障？

这正是3GPP R2-2508033提案的切入点：

初步研究应聚焦于识别6G用例的共同流量特征，并探索如何通过通用框架向RAN和UE提供这些信息。

二、流量特征的同构性：源编码的必然结果

要理解为什么通用框架可行，首先需要回答一个更基础的问题：XR视频和AI推理看起来如此不同，为什么能用同一套框架描述？

答案藏在信息论的基本原理里——两者都使用了源编码（Source Coding）。

2.1 XR视频编码的依赖性

H.264/H.265视频编码器在处理一段XR视频时，会将其分解为三种类型的帧。根据3GPP TS 26.522的定义：

帧类型	编码方式	依赖关系	Packet重要性
I帧	帧内编码	独立，不依赖其他帧	最高
P帧	预测编码	依赖前一个I帧或P帧	中等
B帧	双向预测	依赖前后帧	最低（压缩率最高）

图1：XR视频I/P/B帧依赖关系示意

这种分级不是工程师的主观设计，而是源编码的数学必然。为了降低比特率，编码器必须利用帧间的时间相关性——后续帧只传输与参考帧的差异。这种"差异编码"天然导致了两个结果：

• Packet间依赖关系：P帧无法独立解码，必须先成功接收其依赖的I帧
• Packet重要性差异：丢失I帧会导致整个GOP（Group of Pictures）崩溃，而丢失B帧只影响单帧质量

2.2 AI token生成的依赖性

当一个Transformer模型（如GPT）生成文本时，使用的是autoregressive机制——每个新token的生成都依赖所有之前的tokens。这通过self-attention机制实现：每个token通过Query-Key-Value计算，从之前的所有tokens中"查询"相关信息。

图2：Transformer Token序列依赖示意

从传输角度看，这意味着：

• Token序列依赖第N个token的生成依赖前N-1个tokens，丢失早期token会影响后续所有输出
• Token重要性差异某些token（如关键词、转折词）对语义贡献更大，类似视频的I帧

这本质上也是源编码——AI将原始输入编码为token序列，利用序列内的统计相关性来压缩表示。

2.3 同构性的本质

从RAN的视角看，XR视频编码和AI tokenization在流量元数据层面是同构的：

表1：XR与AI流量特征对比：

维度	XR视频编码	移动AI推理	共同特征
源编码方式	帧间差异编码 (H.264/H.265)	序列autoregressive (Transformer)	利用统计相关性压缩
Packet依赖性	P/B帧依赖I帧	后续token依赖前序token	链式/树形依赖关系
Packet重要性	I > P > B	关键token > 填充token	分级重要性
丢失影响	I帧丢失→GOP崩溃	关键token丢失→语义崩溃	级联故障风险
时间敏感性	帧渲染deadline	推理响应deadline	延迟敏感

核心观察：两者都因源编码引入了packet间依赖和重要性分级。

这意味着，RAN不需要理解"这是视频I帧"还是"这是AI关键token"——它只需要知道两个元数据：

• Inter-packet Dependency（包间依赖）：packet A是否依赖packet B。
• Packet Importance（包重要性）：packet的相对重要性等级。

三、通用框架 vs 应用定制：标准化的权衡

既然XR和AI的流量特征在元数据层面同构，为什么不直接为每个应用定制协议，而要费力抽象通用框架。

3.1 通用框架的三大技术优势

3.1.1 标准化成本可控

3GPP的历史教训是：每引入一个新的应用特定协议，都需要在L2/L3多个层面协调修改。5G网络切片就是典型案例——虽然技术上可行，但为了支持eMBB、URLLC、mMTC三大场景，标准文档的复杂度已经让很多运营商望而却步。

如果为XR定义一套协议，为AI定义另一套，为未来的触觉互联网再定义第三套，标准复杂度将指数级增长。

通用框架将复杂度封装在参数化层面：RAN只需要支持"依赖关系"和"重要性等级"两个元数据字段，具体的取值由应用层填充。

3.1.2 产业生态健康

从生态角度看，通用框架降低了新应用进入门槛。假设未来出现了"脑机接口"应用，只要其流量特征也符合"源编码引入依赖性"的模式，就可以直接复用现有框架，而无需等待3GPP标准化一套新协议（这通常需要2-3年）。

这类似于TCP/IP战胜ATM的原因——TCP/IP的通用性让任何应用都能快速接入，而ATM的电路交换思维要求为每种应用定制虚电路类型。

3.1.3 技术演进路径清晰

通用框架为未来的增强留下了空间。例如：

• 当前可能只需要3级重要性分级（High/Medium/Low）
• 未来如果XR编码演进到更精细的10级分级，框架只需要扩展参数范围，而不需要重构协议

3.2 通用框架的实现边界

当然，通用框架也有其局限性。关键在于抽象层次的选择：

• 过于抽象：如果只保留"QoS Flow"级别的抽象（5G现状），无法捕捉packet级别的细粒度差异
• 过于具体：如果定义"I帧packet""P帧packet"等应用特定语义，又回到了定制化老路

3GPP Rel-18引入的PDU Set概念找到了一个平衡点：

PDU Set = 一个应用层数据单元（如一帧视频、一组相关tokens）对应的多个PDU

图3：PDU Set概念图解

PDU Set提供了比QoS Flow更细的粒度（packet组级别），但又不涉及具体的应用语义。3GPP TS 26.522定义了PDU Set的三个关键属性：

属性	缩写	含义
PDU Set Sequence Number	PSSN	标识数据单元的顺序
PDU Set Size	PSSize	数据单元大小
PDU Set Importance	PSI	数据单元的相对重要性

RAN调度器可以基于PSI做智能丢弃——在拥塞时优先丢弃低重要性的PDU Set，而不是盲目地按FIFO丢弃。这正是"有限耦合"的体现：RAN感知了流量元数据，但并不理解应用逻辑。

四、历史纵深：QoS抽象的第三次跃迁

把视角拉长到移动通信的演进史，会发现服务感知框架不是孤立的技术创新，而是QoS抽象范式的延续。

4.1 第一次跃迁：从电路到分组（2G→3G）

2G时代的GSM使用电路交换，每个语音通话独占一条64kbps的时隙。这种方式简单粗暴——QoS就是"能不能建立连接"，建立后就保证恒定比特率。

3G的UMTS引入了UMTS Bearer概念，标志着第一次跃迁：从面向连接的电路交换，转向面向流的分组交换。QoS开始用Guaranteed Bit Rate (GBR)、Maximum Bit Rate (MBR)等参数描述，而非简单的"通或断"。

4.2 第二次跃迁：从连接到流（3G→5G）

4G LTE进一步演进为EPS Bearer，但本质仍是基于连接的抽象——每个应用对应一个或多个Bearer，QoS参数在连接建立时协商。

5G NR引入了QoS Flow，实现了第二次跃迁：从面向连接转向面向流量。QoS Flow不再与特定连接绑定，而是根据流量特征（5QI、GBR/Non-GBR）动态映射。这使得5G可以在同一个PDU Session内支持多种QoS需求。

但5G的QoS Flow仍是静态参数——5QI、GFBR、MFBR等在建立时设定，运行中很少改变。这对eMBB够用，但对XR这种动态调整码率、帧率的应用就显得僵化了。

4.3 第三次跃迁：从静态QoS到动态流量元数据（5G→6G）

6G服务感知框架代表着第三次跃迁：从静态QoS参数转向动态流量元数据。

关键变化在于时间尺度的缩短：

• 5G QoS Flow：参数在建立时协商，变化周期以秒计（如ABR切换）
• 6G流量元数据：参数随每个PDU Set变化，变化周期以毫秒计（如I帧和P帧交替）

这种细粒度的动态性，正是XR和AI应用的核心需求。当网络拥塞时：

• 传统QoS只能"降低整体码率"
• 基于流量元数据的调度可以"优先保障I帧，选择性丢弃B帧"

用户体验的差异是显著的。

4.4 三次跃迁的统一逻辑

从更深层看，三次跃迁的方向是一致的：QoS抽象越来越接近应用层的流量本质，而非网络层的传输机制。

表2：移动通信QoS抽象的三次跃迁对比

跃迁阶段	时代	抽象单位	QoS参数特征	变化周期	典型应用	核心局限
第一次	2G→3G	UMTS Bearer	连接级静态参数	连接建立时协商 会话期间固定	语音通话 低速数据	无法适应 突发流量
第二次	3G→5G	QoS Flow	流级静态参数 (5QI, GFBR)	以秒计 (ABR切换)	eMBB 视频流媒体	无法感知 包级差异
第三次	5G→6G	Traffic Metadata (PDU Set)	PDU组级 动态元数据	以毫秒计 (帧级)	XR 移动AI 触觉互联	待标准化

图4：QoS抽象粒度的演进趋势

五、标准化路径：RAN2的正确起点

理解了技术本质和历史纵深，就能明白3GPP R2-2508033提案的深意：聚焦共同流量特征的通用框架，是6G RAN2协议设计的正确起点。

5.1 起点的战略价值

5.1.1 避免方向性错误

如果一开始就陷入"XR需要什么""AI需要什么"的具体需求讨论，很容易走向定制化死胡同。通过先识别共性，再设计机制，可以确保标准化方向的正确性。

5.1.2 建立技术基础

识别流量元数据的共性（依赖关系、重要性分级），为后续L2调度、资源分配、拥塞控制等具体机制奠定基础。这些机制可以在统一的元数据框架下设计，而不是为每个应用单独开发。

5.1.3 保持标准演进空间

通用框架的参数化设计，允许未来根据新应用需求灵活扩展，而不必推倒重来。这对于6G这样的长周期技术演进至关重要。

5.2 后续工作的挑战

当然，从"识别流量特征"到"RAN实际使用"，还有很长的路要走：

挑战1：SA2 vs RAN2职责划分

• 流量元数据的定义和获取属于SA2范畴（应用层到核心网）
• RAN2关注的是"如何在L2协议中使用这些元数据"
• 需要明确两个工作组的协作界面

挑战2：隐私和商业机密

• 应用厂商是否愿意向网络暴露流量元数据？
• 需要设计粗粒度的元数据（如3级重要性），而非细粒度内容
• 平衡QoS优化需求与隐私保护要求

挑战3：实现复杂度

• RAN调度器如何高效处理PDU Set级别的细粒度信息？
• 涉及算法优化和硬件加速
• 需要在性能提升与实现成本之间权衡

但这些都是"如何做"的问题，前提是先确立"做什么"——而识别共同流量特征的通用框架，正是那个正确的"什么"。

六、结论

本文基于3GPP R2-2508033提案，系统分析了6G服务感知框架选择通用化路径的技术逻辑。主要结论如下：

核心观点

• 流量同构性：XR和AI等6G应用的流量特征在元数据层面同构——都因源编码引入了packet依赖性和重要性分级
• 通用框架优势：通用框架优于应用特定协议，在标准化成本、产业生态、演进路径三个维度都更优
• 历史必然性：服务感知框架代表QoS抽象的第三次跃迁，从静态参数转向动态流量元数据
• 战略起点：初步研究聚焦共同流量特征，是避免6G RAN2标准化走向定制化陷阱的关键起点

对于6G标准化工作，本文的分析提供了以下启示：

• 抽象层次选择：PDU Set级别的元数据是平衡通用性与精细度的合理选择。
• 参数化设计：通过参数化封装复杂度，而非定义应用特定协议。
• 演进兼容性：通用框架为未来新应用和新技术留下扩展空间。