-----基于3GPP R2-2508032文档深度解读
如果你以为6G会在5G的基础上"加功能"，那可能要失望了。
2025年11月，Qualcomm在3GPP RAN2 #132会议上提交了一份技术提案（R2-2508032），核心主张只有一个字：减。
删SDAP的RQoS机制、简化RACH分区、重构MAC层格式——这些在5G时代曾被寄予厚望的设计，在6G的技术清单上正被逐一划掉。
这不是技术倒退。这可能是一场关于"算力墙"的提前狙击战。
100Gbps的代价：协议处理成为新瓶颈
6G的目标峰值速率是100Gbps，是5G的10倍。但现实是：链路速率可以靠物理层堆天线，但协议处理能力不是线性增长的。
想象一下，一个100Gbps的链路，单个MAC PDU（传输块）的大小可能超过500KB，里面塞着数百个数据包🟡。如果还沿用5G那套"逐包检查"的机制，基带处理器会先被烧穿。
Qualcomm在R2-2508032中直言不讳🟢：
展开剩余87%"SDAP came at a high hardware processing cost since it introduced a mandatory per-packet header check for every DL packet when SDAP is configured."
5G引入的SDAP层，最初的设计意图是通过RQoS（Reflective QoS）机制，让网络能动态调整QoS流到承载的映射。听起来很灵活，但现实是：Qualcomm的field experience显示，RQoS的部署率极低🟡。原因很简单：控制面（Control Plane）完全可以搞定flow-to-bearer mapping，根本不需要在每个下行包上做实时检查。
于是，Qualcomm的Proposal 2直截了当：6G不支持RQoS机制🟢。
这不是偷懒，这是对5G教训的反思。
RACH分区的"组合爆炸"：当功能变成负担
如果说SDAP的问题是"用不上"，那RACH（随机接入信道）分区的问题就是"用不起"。
5G Rel-17引入了RACH分区（RACH Partitioning），初衷是让UE能在Msg1阶段就"早期指示"自己的feature组合（比如RedCap、SDT、切片等）。每种feature组合需要单独配置一块RACH资源。
假设有N个独立feature，理论上可能的组合数呈指数级增长🟡。每次新增一个feature，RACH资源的碎片化就加剧一次。
18个月还在修bug，这本身就说明设计有问题。Qualcomm在R2-2508032中指出🟢：
"This design approach led to poor scalability and very inefficient use of RACH resources. It also created overly complex signaling for RACH configurations, so much that CRs for fixing related problems were still submitted 18 months after Rel-17 was frozen."
更要命的是，RACH配置是通过SIB1下发的，更新周期很慢。如果某个区域突然涌入大量UE（比如演唱会、体育赛事），RACH资源根本来不及调整，结果就是接入拥塞、失败率飙升。
Qualcomm的Proposal 3提出🟢：避免RACH分区，改用动态或按需分配。比如网络检测到拥塞后，通过Msg2/B临时分配额外资源；或者让UE主动请求RACH资源（on-demand）。
这或许更接近灵活性的本质——不是预配置所有可能性，而是响应式调整。
MAC层的"碎片化灾难
5G的MAC层设计，用"碎片化"来形容毫不为过。
MAC CE：失控的信令机制
MAC CE（MAC Control Element）的数量在Rel-15到Rel-19期间暴涨，每个新功能都倾向于引入自己的MAC CE。这些MAC CE的设计缺乏统一规范：
逻辑信道ID（LCID）是扁平的ID空间，UE解析时需要查表（table lookup），硬件不友好 有些MAC CE有长度字段，有些没有，解析逻辑不一致 没有MAC层重传机制，可靠性差Qualcomm在Observation 5中指出🟢：
"MAC CEs in 6G can be designed in a more structured way to enable efficient processing and meet the stricter timing requirements expected in 6G."
Proposal 4的核心诉求🟢：MAC CE应该成为一个灵活的、可扩展的信令机制，而不是一个"feature堆"。具体建议包括：
结构化的LCID组织方式（比如分层编码，而非扁平ID） 所有MAC CE都包含长度字段（统一解析逻辑） 支持不同的payload格式（适配多样化消息类型）MAC PDU：Code Block的连锁反应
MAC PDU格式还有个隐藏的性能杀手：Code Block（CB）的独立性缺失。
在5G中，一个Transport Block（TB）由多个Code Block组成。如果某个CB解码失败，整个TB都要重传——哪怕其他CB都已经成功了。
这在5G时代或许还能忍受，但6G的TB可能达到500KB+，包含数百个MAC子PDU🟡。如果一个小小的CB出错，就要拖累整个大TB重传，这简直是带宽的噩梦。
Qualcomm在Observation 6中警告🟢：
"In NR, failure of a single code block (CB) can delay the delivery of PDUs in other CBs. This problem can be more serious in 6G with its much larger TBs."
Proposal 5提出了两个方向🟢：
CB独立性：让每个MAC subPDU完全包含在单个CB内，CB之间互不依赖 TB元数据：在TB开头附加元数据，标明后续MAC CE和MAC subPDU的数量、长度等，接收端可以快速解析第二个方案尤其巧妙。现在的做法是逐个解析MAC subheader才能知道下一个subPDU在哪里，处理起来像"盲人摸象"。如果有了元数据，接收端一次性就知道整个TB的结构，解析速度可以大幅提升。
回到原点：Rel-15基线的理念
Qualcomm的Proposal 1最有意思🟢：L2应该支持一个最小功能集（minimum baseline functionalities），并且这个基线就是Rel-15。
为什么是Rel-15？因为Rel-16到Rel-19的所有功能，都是在Rel-15的架构约束下"打补丁"。现在6G有机会重新设计，那为什么不回到原点，重新审视每个功能的必要性？
这个最小功能集包括：
数据传输、加密/解密、完整性保护 ARQ（协议错误检测与恢复） 分段与重组、头压缩 SDU标记（如QFI） 重排序与顺序/乱序交付、重复丢弃注意，这里面没有SDAP。Qualcomm的逻辑很清晰：QoS flow这个抽象层要保留（因为它足够灵活），但SDAP层本身可以不要。
这种"做减法"的勇气，在通信标准的演进史上并不多见。毕竟，删功能比加功能难多了——你得说服所有利益相关方，某个曾经被寄予厚望的设计"其实没那么有用"。
结语：算力的尽头，是设计的克制
6G的用户平面设计，表面上是在讨论SDAP、RACH、MAC，但本质上是在回答一个更深层的问题：
当链路速率提升10倍，我们是否有能力让协议处理也提升10倍？
如果答案是"不能"，那唯一的出路就是简化协议栈，删掉那些"看起来很美、实际没人用"的功能。
Qualcomm的这份提案，像是给整个行业泼了盆冷水：别再幻想"更多功能=更强大"了，先把100Gbps的链路跑起来再说。
这不是倒退，这是克制。
毕竟，最好的设计，往往不是做加法，而是知道什么时候该做减法。
数据来源: 3GPP R2-2508032 (Qualcomm Incorporated, RAN2 #132, Dallas, 2025-11-17)术语参考: 3GPP TS 38.300 (Release 15), TS 38.321, TS 37.324可靠性标注: 🟢 文档直接引用 | 🟡 基于文档的合理推断
发布于：北京市旺鼎策略提示：文章来自网络，不代表本站观点。
沪深京指数
推荐资讯