好的，我们继续进行深度拆解。这是本系列的第十一篇文章，将聚焦于对纯控制面方案进行优化的Solution #6。
深度解析 3GPP TR 23.700-19：6.6 Solution #6: CP-IMS语音的专用承载QoS方案
本文技术原理深度参考了3GPP TR 23.700-19 V1.0.0 (2025-09) Release 20规范。在上一篇中，我们探讨了Solution #5——一个革命性但对网络架构冲击巨大的纯控制面方案。本文我们将深入分析 6.6 Solution #6，这个方案可以看作是**在控制面承载（Control Plane CIoT EPS Optimisation）的框架下，试图借鉴用户面成熟的QoS模型（默认承载+专用承载）**的一次精巧尝试。它旨在解决一个核心问题：即使所有数据都走控制面，我们能否依然为信令和语音提供清晰的QoS区分？
引言：在“市府大楼”里划分“VIP通道”
让我们再次回到Alex的团队。他们对Solution 5的“天才构想”赞叹不已，但对其要求MME处理海量语音数据的颠覆性设计深感忧虑。团队成员Lily提出了一个问题：“既然我们能在用户面为语音建立专用承载（DRB），为什么不能在控制面，也为语音建立一种‘专用承载’呢？这样MME不就知道哪些NAS包是语音，哪些是信令了吗？”
Alex赞许地说道：“Lily，你这个问题正好切中了Solution 6的核心！Solution 6正是沿着这个思路展开的。它不再满足于让语音和信令都挤在同一个默认的控制面通道里，而是尝试在控制面内部，也为IMS语音开辟出一条逻辑上的‘VIP通道’。这个‘VIP通道’，在EPC的术语体系里，就是专用EPS承载 (Dedicated EPS Bearer)。”
这个想法听起来有些矛盾：控制面优化本是为了避免建立承载的开销，为何又要回头在控制面里建立专用承载？这正是Solution 6的精妙与复杂所在。
1. 方案总纲：6.6.0 High-level solution Principles (高层解决方案原则)
本节用四个原则，清晰地阐述了Solution 6的设计哲学。
- Procedure on Data Transport in Control Plane CIoT EPS Optimisation is used as baseline.
- EPS enhancement to support dedicated bearer for the IMS voice service over NB-IoT(GEO).
- IMS signalling is transmitted via the default bearer, IMS voice data is transmitted via the dedicated bearer.
- Dedicated bearer can be pre-established during IMS PDN connection establishment to reduce delay…
Alex逐条解读这些看似熟悉但内涵已然不同的原则：
-
“基于控制面CIoT EPS优化程序。”
- 这明确了技术底座。与Solution 5一样，所有的数据，无论是信令还是语音，最终都将被封装在NAS消息中，通过控制面路径
UE -> eNB -> MME进行传输。这是理解本方案的大前提。
- 这明确了技术底座。与Solution 5一样，所有的数据，无论是信令还是语音，最终都将被封装在NAS消息中，通过控制面路径
-
“EPS增强以支持在NB-IoT(GEO)上为IMS语音业务建立专用承载。”
- 这是本方案最核心的创新点。它明确提出，要在NB-IoT上打破“不支持专用承载”的常规限制。注意，这里的“专用承载”虽然借用了用户面的术语，但它的数据路径是经过MME的，这与Solution 2中的用户面专用承载有着本质区别。
-
“IMS信令通过默认承载传输，IMS语音数据通过专用承载传输。”
- 这清晰地阐明了QoS区分机制。通过建立两个逻辑上独立的EPS承载（一个默认，一个专用），即便它们最终都汇聚到控制面上传输，但在承载管理层面，它们拥有各自的承…”
- “专用承载可以被预建立…”
- 这是一个关键的性能优化。与Solution 2一样，为了避免在通话时因动态建立承载而引入高时延，这个专用的控制面承载也应该在附着或PDN连接建立时就一并创建好。
“所以，Solution 6的本质，” Alex在白板上画了一个大框代表“控制面”，并在框内画了两条并行的逻辑通道，“它是在控制面的‘大框架’内，完整地‘复刻’了一套用户面的‘默认+专用’承载管理模型。UE和网络会维护两个独立的承载上下文（Bearer Contexts），每个都有自己的EBI（EPS Bearer Identity）和QoS参数。但当数据发送时，这两个逻辑承载的数据包，都会被殊途同归地送入控制面信道（SRB）进行传输。”
2. 方案详述：6.6.1 Description - 逻辑与物理的分离
本节通过架构图和协议栈图，揭示了这种“逻辑承载”与“物理路径”分离的精妙设计。
The solution proposes to remove those restrictions mentioned above [dedicated bearer is not supported over NB-IoT]… The solution is based on CP CIoT EPS Optimisation. To enable the IMS voice transmission via NB-IoT control plane, an IMS PDN connection containing one default bearer and one dedicated bearer is proposed…
Figure 6.6.1-1 展示的架构图，在UE和RAN侧，清晰地画出了两个独立的信令无线承载（SRB）：
- SRB X: 用于承载默认承载上的IMS信令。
- SRB Y: 用于承载专用承载上的IMS语音。
这暗示了，为了在空口实现两条逻辑控制面承载的QoS区分，底层可能也需要两个独立的SRB，这与Solution 5中引入新SRB的思想不谋而合。
协议栈解读
Figure 6.6.1-2 (信令协议栈) 和 Figure 6.6.1-3 (语音协议栈) 展示了更深层次的区别。两者的数据路径都是 ... -> RRC -> NAS -> S1-AP -> MME。
- 关键区别在NAS层:
- 在UE侧，当IMS应用层产生一个信令包或语音包后，NAS层会根据这个包的目的（信令vs语音），将其封装成一个
NAS Data PDU，并打上对应的EBI（例如，默认承载的EBI-1给信令，专用承载的EBI-2给语音）。 - 在MME侧，当MME从S1-AP消息中解封装出
NAS Data PDU后，它会检查PDU头部的EBI。如果EBI是EBI-1，MME就知道这是信令，将其转发到IMS信令对应的SGW/PGW路径；如果EBI是EBI-2，MME就知道这是语音，将其转发到IMS语音对应的SGW/PGW路径。
- 在UE侧，当IMS应用层产生一个信令包或语音包后，NAS层会根据这个包的目的（信令vs语音），将其封装成一个
通过在NAS层使用EBI进行区分，Solution 6巧妙地在MME这个“中转站”实现了数据流的分拣，从而将逻辑上的两个承载映射到了核心网中两条不同的处理路径上。
- 语音协议栈的ROHC: 与Solution 2类似，Figure 6.6.1-3 中在NAS层之上明确标注了 (ROHC)。这意味着，在封装进NAS PDU之前，语音包的IP/UDP/RTP头会被ROHC压缩。这是控制面方案节省带宽的关键一环。
3. 流程剖析：6.6.2 Procedures - “隐形”专用承载的建立
本节的 “Figure 6.6.2.1: IMS signalling and voice data delivery in CIoT EPS Optimisation…” 通过一个非常详细的信令流程图，展示了这套复杂机制的运作过程。
-
步骤 0-2: 附着与能力交换
- UE在
Attach Request中声明支持“CP CIoT EPS Optimisation”和“IMS voice over NB-IoT”。 - MME在
Attach Accept中回应该能力，并告知UE网络支持NB-IoT上的IMS语音。
- UE在
-
步骤 3-5: 预建立“双承载”
-
UE发起
PDN Connectivity Request请求连接IMS APN。 -
MME向SGW/PGW发起
Create Session Request。 -
核心决策: 与Solution 2类似，PGW会根据UE能力和运营商策略，决定是否同意建立“一个默认+一个专用”的承载组合。
-
如果同意，PGW会在响应中返回两个承载的信息。
-
MME向UE发送
PDN connectivity Accept，其中会包含两个EPS承载ID (EBI-1 和 EBI-2)。
Editor’s note: Whether new QCI is needed for supporting IMS voice service over NB-IoT NTN via GEO is FFS.
一个编辑注再次提醒我们，那个专用于控制面语音的承载，应该使用什么样的QCI，是一个悬而未决的问题。
-
-
步骤 6-9: IMS信令传输 (使用默认承载 EBI-1)
- UE发起IMS注册或呼叫，将SIP消息封装在NAS PDU中，并标记为EBI-1。
- eNB通过
S1-AP Initial UE Message将这个NAS PDU送给MME。 - MME检查EBI为EBI-1，将包解封后，通过S11-U接口发往SGW/PGW，最终到达IMS网络。
-
步骤 11-17: IMS语音传输 (使用专用承载 EBI-2)
- IMS呼叫协商完成后，P-CSCF通过PCRF向P-GW下发用于语音流的PCC规则。
- P-GW可能会通过
Update Bearer Request流程，更新专用承载的TFT（如果之前是阻塞的）。 - 下行语音: P-GW收到下行语音包，通过专用承载（承载2）的路径，经SGW发往MME。MME加密并封装成NAS PDU（标记为EBI-2），通过
Downlink S1-AP Message发给eNB，最终由eNB通过SRB Y传给UE。 - 上行语音: 流程相反，UE将语音包封装成NAS PDU（标记为EBI-2），通过SRB Y发送出去。
4. 影响分析：6.6.3 Impacts on Services, Entities and Interfaces
Solution 6的改动是深远的，它试图在不根本改变MME角色的前提下，实现控制面的QoS区分。
- UE:
- 需要支持在CP优化模式下，同时管理默认和专用两个EPS承载上下文。
- NAS层需要能根据流量类型（信令/语音）打上不同的EBI。
- eNB:
- 可能需要支持新的SRB来区分不同承载的空口传输（这取决于RAN的最终实现）。
- MME:
- 需要支持在NB-IoT上建立和管理专用EPS承载。
- 核心改动: 需要具备基于NAS PDU中的EBI，对上行和下行数据包进行“分拣”和“路由”的能力，将它们导向不同的SGW隧道。这虽然仍是在处理NAS消息，但逻辑上已经非常接近一个数据包路由器。
- S-GW/P-GW:
- 需要支持在NB-IoT上建立专用承载，并为其应用特定的PCC规则和QoS策略。
5. 结论：精巧的“折衷”，依然沉重的代价
Alex最后对Solution 6进行了总结：“Solution 6无疑是一个非常精巧的设计。它试图在Solution 5的‘革命’和传统方案的‘保守’之间，找到一条中间道路。它通过在控制面内部复刻一套承载管理体系，解决了纯控制面方案的QoS区分难题。”
“它的优点在于：”
- “清晰的QoS模型： 通过逻辑上的双承载分离，为信令和语音提供了明确的QoS区分机制，这是它相比Solution 1和5的巨大进步。”
- “保留了控制面的高优先级： 整个业务流依然享受控制面传输带来的天然高优先级。”
“然而，这种精巧的‘折衷’，依然带来了沉重的代价：”
- “MME的复杂化： 虽然没有像Solution 5那样要求MME直接处理RTP流，但要求MME根据EBI进行数据包分拣，依然极大地增加了其处理逻辑的复杂性，使其功能边界变得模糊。”
- “对NB-IoT标准的重大扩展： 方案的成立，建立在‘NB-IoT支持专用承载’这一重大增强之上。这需要对UE、RAN和核心网的规范进行全面的修订。”
- “信令开销： 建立和管理两个EPS承載，无论是在用户面还是控制面，都会引入额外的NAS会话管理（SM）信令开销，这在高时延的GEO链路上是不容忽视的。”
“总而言之，Solution 6像一位建筑师，试图在一栋为办公设计的‘市府大楼’里，通过精巧的内部改造，隔出一条既能走人又能跑车的‘多功能通道’。设计虽然巧妙，但改造的成本和对大楼结构的长期影响，仍然是巨大的。这也让我们不禁反思，是不是有更简单、更直接的方法来实现控制面的语音承载？这正是Solution 7等后续方案将要为我们揭示的。”
FAQ
Q1：Solution 6的核心思想是什么？它与Solution 2和Solution 5有什么异同？ A1：Solution 6的核心思想是在控制面承载（CP CIoT Optimization）的框架下，通过建立逻辑上的“默认承载”和“专用承载”来分离IMS信令和语音。
- 与Solution 2的相同点： 都采用了“默认承载传信令，专用承载传语音”的双承载QoS模型。
- 与Solution 2的不同点： Solution 2是纯用户面方案，承载的数据路径是
UE->eNB->SGW；而Solution 6是控制面方案，承载的数据路径是UE->eNB->MME->SGW。 - 与Solution 5的相同点： 都是纯控制面方案，数据都经过MME。
- 与Solution 5的不同点： Solution 5只使用一个默认承载（逻辑上），通过引入新的SRB在空口区分语音和信令；而Solution 6在NAS层之上引入了两个逻辑EPS承载，通过EBI来区分，为QoS管理提供了更清晰的框架。
Q2：方案中“逻辑承载”和“物理路径”的分离是什么意思？ A2：这意味着在上层（NAS层及以上），UE和核心网（MME, SGW, PGW）会为信令和语音维护两个独立的、逻辑上的EPS承载上下文，每个都有自己的身份（EBI）和QoS参数。但在下层（空口），这两个逻辑承载的数据包，最终都可能被打包并通过同一个或多个物理的信令无线承载（SRB）进行传输。MME作为关键的“转换点”，负责将从SRB上收到的混合数据，根据其NAS头中的EBI，重新“分拣”到核心网内部对应的逻辑承载隧道中。
Q3：为什么这个方案也需要一个新的QCI？ A3：因为需要一个新的QoS参数集来描述“在控制面上传输的实时语音流”这一特殊的业务特性。现有的任何一个QCI（无论是GBR还是non-GBR）都不能准确地描述这种场景。这个新的QCI需要定义的参数可能包括：一个非常大的分组延迟预算（PDB）以适应GEO卫星的高时延，一个较低的丢包率，以及一个特定的优先级。这个QCI将被关联到那个专用于语音的逻辑EPS承载上。
Q4：这个方案对MME的负担相比Solution 5是减轻了还是加重了？ A4：相对Solution #5，MME的数据面处理负担减轻了，但控制面和逻辑处理的复杂性可能增加了。减轻是因为MME不再需要直接解析和处理海量的、没有标准头部（可能只有ROHC压缩头）的RTP包，它只需要处理标准的、带有EBI的NAS PDU。增加是因为MME现在需要管理两种不同的承载上下文，并具备基于EBI进行数据包“分拣”和路由的复杂逻辑，这在标准的MME功能中是不存在的。总的来说，它将Solution 5中纯粹的性能挑战，部分转化为了逻辑实现的复杂性挑战。
Q5：Solution 6是否解决了NB-IoT上建立专用承载的技术难题？
A5：没有，它将这个问题作为了一个前提。规范明确指出 EPS enhancement to support dedicated bearer for the IMS voice service over NB-IoT(GEO)，这意味着该方案的成立，依赖于3GPP的其他工作组（特别是RAN和CT组）能够完成对NB-IoT标准的增强，使其原生支持专用承载的建立和管理。Solution 6本身只是定义了“如果能够建立专用承载，我们该如何使用它”，而没有解决“如何建立”这个根本性的问题。