6G协议栈瘦身：统一传输与极简生命周期管理方案

1. 6G协议栈瘦身的必要性：从58368 bits浪费说起

在5G向6G演进的过程中，协议栈设计正面临前所未有的挑战。作为一名长期跟踪无线通信协议栈开发的工程师，我亲眼见证了5G协议栈如何从最初的简洁设计逐渐变得臃肿。最典型的例子就是R2-2508043提案中提到的那个惊人数字：58368 bits——这相当于7.3KB的数据量，仅仅为了传输一个简单的"是/否"判断。

这种资源浪费并非偶然，而是5G协议栈设计哲学的自然结果。当前的协议栈架构存在三个根本性问题：

1. 功能重复：同一类数据（如RSRP测量值）需要维护两套完全不同的协议栈逻辑，仅仅因为它们分别服务于UE侧和网络侧的AI模型
2. 设计割裂：网络侧AI任务使用MDT/SON框架（控制面CP），而UE侧AI任务则采用用户面（UP）解决方案
3. 过度配置：协议设计倾向于为所有可能场景预留最大资源，导致实际使用中大量资源闲置

提示：在无线通信系统中，控制面(CP)负责信令传输，用户面(UP)负责业务数据传输。传统上认为CP适合小数据量、低延迟的信令，UP适合大数据量传输。

2. 数据传输框架的统一化设计

2.1 当前架构的问题本质

在5G网络中，数据传输架构的选择往往基于数据来源而非数据用途。这种设计导致：

• 协议栈冗余：UE需要同时维护CP和UP两套协议栈逻辑
• 开发复杂度：工程师需要处理不同接口的行为差异
• 资源浪费：无法根据实际需求动态分配传输资源

我曾在实际项目中遇到一个典型案例：为了支持网络侧AI模型的RSRP数据收集，团队不得不修改MDT框架；而几周后，另一个需求要求同样的RSRP数据用于UE侧模型训练，又得在UP通道上重新实现类似功能。

2.2 OPPO提案的核心创新

R2-2508043提案提出了颠覆性的设计思路："以终点定架构，而非以起点定架构"。具体实现包括：

1. 统一传输管道：

   • 终结于OAM的数据：统一使用优化后的MDT/SON框架
   • 终结于RAN的数据：统一通过CP或UP上报，不区分用途

2. 智能接口抽象层：

cpp复制// 伪代码示例：统一数据传输接口
class AIDataTransport {
public:
    vir