好的，我们继续进行深度拆解。这是本系列的第十篇文章，将聚焦于另一个极具独创性的控制面承载方案——Solution #5。

深度解析 3GPP TR 23.700-19：6.5 Solution #5: 基于控制面承载和新SRB的IMS语音方案

本文技术原理深度参考了3GPP TR 23.700-19 V1.0.0 (2025-09) Release 20规范。在我们详细剖析了Solution 4这一强大的用户面NIDD+I1方案之后，我们的视线将转向另一条截然不同的技术路径——控制面承载 (Control Plane CIoT EPS Optimisation)。本文将深入解读 6.5 Solution #5，这是一个纯粹的控制面解决方案，它大胆地提出不仅要用控制面传输IMS信令，还要为实时语音流开辟一条全新的信令无线承载（SRB）通道，试图在不占用任何用户面资源的情况下，完成IMS语音通话的壮举。

引言：当“高速公路”修进了“市府大楼”

让我们再次想象Evelyn博士在喜马拉雅山的通信场景。之前的用户面方案，无论是单承载、双承载还是NIDD，都是在为语音和信令规划公共的“用户面高速公路”。但现在，Solution 5的工程师们提出了一个惊人的想法：“既然用户面高速公路（DRB）又窄又难修，我们为什么不直接借道‘市府大楼’（控制面）内部的专用通道呢？”

控制面，特别是承载NAS信令的SRB（信令无线承载），在网络中拥有天然的最高优先级和可靠性保障。NB-IoT的“CP CIoT EPS优化”已经允许少量用户数据搭乘信令通道的“便车”。Solution 5则将这一思想推向了极致。

“这个方案的想法非常激进，” 5G工程师Alex在他的团队讨论会上说道，“它相当于要在MME这座‘市府大楼’里，不仅为偶尔通行的信令‘公文’（IMS信令）开辟通道，还要为持续不断的语音‘市民流’（RTP语音）修建一条全新的、专用的‘内部高速路’（新的SRB）。这不仅是对MME功能的一次巨大挑战，更是对无线资源管理（SRB的定义和使用）的一次根本性突破。”

1. 方案总纲：6.5.0 High-level solution Principles (高层解决方案原则)

本节用一句话，点明了Solution 5的革命性核心。

This solution is underpinned by the usage of a new SRB (Signalling Radio Bearer) dedicated to transmit voice packets using Control Plane CIoT EPS Optimisation which needs to be defined by RAN WGs.

Alex为团队剖析了这句话中的每一个关键词：

• “Control Plane CIoT EPS Optimisation”: 这明确了方案的技术基石。所有数据（信令和语音）都将封装在NAS消息中，通过控制平面从UE发送到MME。
• “a new SRB (Signalling Radio Bearer)”: 这是整个方案的核心灵魂和最大技术难点。标准的RRC连接中，通常只有SRB0, SRB1, SRB2，它们都用于传输控制信令。该方案提出，需要RAN工作组（RAN WGs）去定义一种全新的SRB，我们称之为SRBx。
• “dedicated to transmit voice packets”: 这个新的SRBx的唯一使命，就是传输实时语音包。

“所以，Solution 5的蓝图非常清晰，” Alex在白板上画出了控制面的路径，“它要在现有的信令通道之外，平行地开辟出一条专门用于语音的‘特快信令通道’。信令和语音虽然都走控制面，但它们将行驶在不同的‘车道’（不同的SRB）上，从而实现物理隔离和差异化QoS。”

2. 方案详述：6.5.1 Description - “空中立交桥”的构建

2.1 需求分析：为何需要新的SRB？ (6.5.1.1 Requirements)

To support IMS voice service, two service data flows (SDFs) need to be supported: one for IMS signalling and the other for IMS voice packets… these two SDFs need to be carried over two separate signalling radio bearers (SRBs) over the air in order to meet the different QoS requirements.

规范在这里给出了必须引入新SRB的根本原因：IMS信令和IMS语音包对QoS的需求截然不同。

• IMS信令流: 要求高可靠性 (high reliability)。信令消息决不能丢失，因此承载它的SRB（如SRB1/2）通常使用需要确认和重传的RLC AM（Acknowledged Mode，确认模式）。
• IMS语音流: 要求低时延 (stringent delay requirements)。语音包对实时性要求极高，可以容忍少量丢包（通过语音编码的容错机制弥补），但无法容忍因重传带来的额外时延。因此，承载它的新SRBx不能使用RLC AM模式，而应该使用不需确认的RLC UM（Unacknowledged Mode，非确认模式）或TM（Transparent Mode，透明模式）。

因为现有的SRB都工作在RLC AM模式下，无法满足语音的低时延需求，所以，定义一个工作在UM/TM模式下的新SRB，是本方案在无线侧成立的逻辑前提。

2.2 网络架构与承载映射 (6.5.1.2 & 6.5.1.4)

规范中的 “Figure 6.5.1.4-1: Bearer mapping for IMS voice over GEO… using CP CIoT” 直观地展示了这种新的映射关系：

• RRC/NAS/IMS信令: IMS signalling → NAS signalling → RRC signalling → 映射到 SRB1bis (或标准SRB1/2) → 空口
• IMS语音: Voice packets → 映射到 SRBx (新的SRB) → 空口

在UE内部，IMS应用层生成的语音包，不再经过IP/UDP协议栈，而是直接被一个新的NAS子层封装，然后交给RRC层，由RRC层将其映射到这个新的SRBx上进行传输。

数据到达eNB后，eNB会将来自SRB1bis和SRBx的数据都封装在S1-AP消息中，通过S1-MME接口发送给MME。

2.3 PDN连接类型的灵活性 (6.5.1.3 PDN connection types)

本方案对PDN连接类型提供了极大的灵活性，可以是IP类型，也可以是非IP类型（Non-IP）。

• a) IP类型PDN: 如果PDN连接是IP类型，那么UE在将语音包交给NAS层封装前，依然会为其添加IP/UDP/RTP头。这意味着MME收到的NAS包里，载荷是一个完整的IP包。
• b) & c) Non-IP类型PDN: 如果PDN连接是非IP类型，那么UE在封装时就可以省去IP/UDP头，只保留一个极简的RTP头或纯语音净荷（即NIDD）。这意味着MME收到的NAS包里，载荷是一个Non-IP数据包。这种方式显然效率更高。

无论哪种方式，MME在收到NAS包并解封后，都需要将里面的载荷（无论是IP包还是Non-IP包）通过S11-U接口转发给S-GW/P-GW。如果是非IP包，后续还需要在P-GW侧进行协议转换，这与Solution 3的思路类似。

2.4 协议开销的极限压缩 (6.5.1.5 & 6.5.1.6)

Solution 5对协议开销的“压榨”达到了登峰造极的地步。Table 6.5.1.5-1 对语音包在控制面传输时的各层开销进行了详细分析，并给出了一个惊人的“Best Case”：

• MAC层: 1字节
• RLC层: 0字节 (使用RLC TM模式)
• RRC层: 0字节 (通过优化，让SRBx直接承载NAS PDU，无需RRC头)
• NAS协议层: 0字节 (通过优化，让MME能根据数据来自SRBx就默认其为语音包，无需NAS头)
• NAS安全层: 1字节 (只保留序列号，假设完整性保护被省略)
• IP/UDP/RTP层: 1字节 (使用Non-IP PDN，只保留1字节的RTP序列号)

总计：3字节！

The overhead data rate depends on the packet rate. For example, for a 3B … overhead per packet and 50 packets per second … the overhead data rate would be 1200 bps (1.2 kbps).

这个计算结果令人印象深刻。即使在每秒50包的高发包率下，总的协议开销也只有1.2kbps，这为在极窄带宽下实现高质量语音提供了可能。

为了实现0字节的RRC和NAS开销，6.5.1.6节提出：

• 既然SRBx是语音专用，那么空口上可以通过SRBx的逻辑信道ID来唯一标识语音包，不再需要RRC头。
• eNB在将SRBx收到的数据上报给MME时，可以在S1-AP消息中加入一个指示（如SRB identity），告诉MME：“这个NAS PDU来自语音专用的SRBx”。MME据此就可以直接将其识别为语音包，无需再解析NAS头部。

3. 方案影响分析：一场深刻的变革

Solution 5虽然看似优雅高效，但它对现有网络架构和流程的冲击是巨大的。

• UE:
  • 需要支持全新的SRBx，包括其建立和配置流程。
  • RRC和NAS协议栈需要重大修改，以支持将语音包映射到SRBx，并实现“零开销”封装。
• eNodeB (RAN):
  • 核心改动: 必须支持定义、建立和管理一种全新的、工作在RLC UM/TM模式下的SRB (SRBx)。
  • S1-AP接口需要增强，以向上层（MME）指示数据包的来源SRB。
• MME (改动最大):
  • 不再是纯粹的信令处理中心，而是需要深度参与到用户数据的传输中，扮演了数据包转发的角色。
  • 需要支持SRBx的建立和管理信令。
  • 需要能够根据S1-AP消息中的SRB ID，将接收到的NAS PDU区分是信令还是语音，并将语音PDU转发到S11-U接口。这要求MME具备类似S-GW的转发能力。
• PGW:
  • 如果采用Non-IP PDN，P-GW需要具备NIDD与IP之间的协议转换能力（类似Solution #3）。

4. 结论：天才的构想，沉重的现实

Alex最后总结道：“Solution 5是一个充满想象力的、天才般的构想。它试图通过在控制面开辟‘专车道’的方式，完美地解决GEO NB-IoT语音通信在QoS和效率上的双重难题。”

“它的优点无与伦比：”

• “极致的效率和优先级： 通过全新的SRBx和零开销优化，它在理论上实现了最低的协议开销和最高的传输优先级，这是任何用户面方案都无法企及的。”
• “不占用用户面资源： 整个通话过程不建立DRB，为UE保留了宝贵的用户面承载能力去执行其他可能的物联网数据业务。”

“然而，它的‘革命性’也带来了沉重的现实代价：”

• “对RAN的颠覆性要求： 定义和实现一种新的SRB，是对3GPP无线协议的一次重大修改，其复杂性和影响远超用户面的简单增强。”
• “对MME角色的根本性改变： 它要求MME从一个‘信令交警’，变身为一个需要处理海量、实时语音数据包的‘交通枢纽’。这不仅对其处理性能提出了指数级的挑战，也打破了4G/5G核心网C/U分离（控制与用户分离）的核心设计哲学。”

“因此，Solution 5更像是一个理想化的‘理论模型’。它为我们展示了控制面承载的巨大潜力，但也揭示了这条路在工程实现和架构演进上可能遇到的巨大阻力。这个方案的价值，更多地在于启发我们思考，是否能在不如此‘颠覆’M-ME的前提下，借鉴其部分思想，找到更折衷、更具可行性的控制面解决方案。这也为我们接下来要学习的Solution 6和7等方案，埋下了伏笔。”

---

FAQ

Q1：Solution 5的核心思想是什么？它和之前的用户面方案（如Solution #2, #3）最根本的区别是什么？ A1：Solution 5的核心思想是完全通过控制平面（Control Plane）来传输IMS语音和信令，并通过定义一种全新的信令无线承载（new SRB）来专门承载实时语音包。它与用户面方案最根本的区别在于数据路径：用户面方案的数据（无论是IP还是NIDD）路径是 UE -> eNB -> S-GW -> P-GW；而Solution 5的路径是 UE -> eNB -> MME -> S-GW -> P-GW。所有的数据都必须先在MME进行一次“中转和处理”，这是对核心网架构的一次重大改变。

Q2：为什么现有的SRB（信令无线承载）不能直接用来传输语音？为什么一定要定义一个新的SRB？ A2：因为QoS需求不匹配。现有的SRB（如SRB1, SRB2）是为了保证信令的绝对可靠而设计的，它们工作在RLC的确认模式（AM）下。这意味着每个数据包都需要被确认，如果丢失或出错，就会触发重传。这种重传机制对于语音这种实时业务是“致命”的，因为它会引入不可预测的、巨大的时延，导致声音卡顿。而语音业务需要的是非确认模式（UM）或透明模式（TM），宁可丢弃一个包，也要保证后续包的实时到达。因此，必须定义一个工作在UM/TM模式下的新SRB，才能满足语音的低时延要求。

Q3：这个方案对MME的功能要求有何颠覆性的改变？ A3：颠覆性的改变在于，它要求MME从一个纯粹的信令处理节点，转变为一个信令与数据混合处理和转发的节点。在标准EPC架构中，MME只处理控制信令（S1-AP, NAS），从不“触碰”用户的IP数据包。而Solution 5要求MME能够接收海量的、封装在NAS消息中的实时语音包，对其进行解封装，然后通过S11-U接口转发给S-GW。这不仅对MME的硬件处理能力（吞吐量）提出了极高的要求，更重要的是，它模糊了控制面与用户面的功能界限，违背了EPC/5GC架构演进的核心原则。

Q4：方案中提到的“3字节”的极低协议开销是如何实现的？ A4：这是在最理想（Best Case）的假设下，通过“层层剥削”实现的：1) 在物理/MAC层，假设每个传输块只承载一个语音包，开销最小。2) 在RLC层，使用TM（透明模式），没有RLC头部，开销为0。3) 在RRC/NAS层，通过“带外信息”（即eNB告诉MME这个包来自语音专用SRB）来隐式传递信息，从而省去了RRC和NAS的头部，开销为0。4) 在应用层，使用NIDD，省去了IP/UDP头，只保留一个最小化的RTP头（如1字节序列号）。5) 在安全层，大胆假设可以省略完整性保护，只保留1字节的序列号用于防重放。这些假设都非常激进，需要标准协议的深度修改才能实现。

Q5：Solution 5这样的纯控制面方案，相比用户面方案（如Solution 3的NIDD），在现实中哪个更有可能被采纳？ A5：从标准化和工程实现的角度看，类似Solution 3的用户面方案更有可能被采纳或作为演进的基础。尽管Solution 5在理论上的效率和优先级最高，但它对MME和RAN的改动是颠覆性的，触及了网络架构的根基，标准化成本和风险极高。而Solution 3虽然也需要P-GW和UE进行较大改动，但它维持了C/U分离的基本架构，MME依然只负责信令，改动被限制在了用户面的边缘节点。这种“外科手术式”的改造，远比Solution 5的“器官移植”更容易被业界接受和实现。因此，Solution 5更多地是作为一种探索性的研究，其思想可能会被借鉴，但原方案直接落地的可能性相对较小。