好的，我们继续进行深度拆解。这是本系列的第七篇文章，将深入剖析旨在解决Solution 1核心缺陷的Solution #2。

深度解析 3GPP TR 23.700-19：6.2 Solution #2: 建立专用EPS承载的用户面方案

本文技术原理深度参考了3GPP TR 23.700-19 V1.0.0 (2025-09) Release 20规范。在上一篇文章中，我们剖析了Solution #1，一个将IMS信令和语音都放在默认承载上的“All-in-One”方案，并指出了其在QoS区分上的根本性缺陷。本文将紧接着深入探讨 6.2 Solution #2，这是一个重要的演进方案，它直面Solution 1的痛点，提出了为IMS信令和语音数据建立分离的EPS承载这一核心思想，试图在NB-IoT NTN这条“乡间小路”上，规划出“快车道”和“慢车道”。

引言：从“混合交通”到“分道行驶”

让我们回到科学家Evelyn博士在喜马拉雅科考站的场景。在使用基于Solution 1的卫星终端时，她发现通话质量很不稳定。有时在紧急汇报关键数据时，声音会突然卡顿，甚至听不清对方的回应。经过Alex团队的分析，这正是因为IMS信令（如SIP Keep-alive消息）和RTP语音包在同一个“单车道”上相互干扰导致的。

“很明显，‘混合交通’的模式行不通，” Alex在复盘会议上说道，“我们需要为VIP车队（语音流）和偶尔经过的救护车（信令）规划不同的车道。这就是Solution 2的核心思想——分道行驶。它试图在NB-IoT有限的承载能力之上，借鉴VoLTE的成功经验，为信令和语音建立独立的EPS承载。今天，我们的任务就是要弄清楚，这条‘分道行驶’的路，具体要怎么修？又会遇到哪些新的路障？”

Solution 2是用户面（UP）方案阵营中的一次关键尝试，它代表了通过更精细化的承载管理来解决QoS问题的思路。

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

本节用七条原则，清晰地勾勒出了Solution 2的架构蓝图和关键行为。

• UE camps on an eNB that supports NB-IoT (GEO) satellite access
• The UE indicates its support of IMS voice over NB-IoT in attach/TAU request
• The MME indicates IMS voice over PS session is supported to UE.
• UE requests to establish an IP type PDN connection with IMS APN via user plane.
• IMS signalling is transmitted via the default EPS bearer.
• IMS voice data is transmitted via a dedicated EPS bearer.
• The dedicated EPS bearer may be established together with the default EPS bearer.

Alex逐条解读这些原则，并与Solution 1进行对比：

1. “UE驻留在支持NB-IoT (GEO)卫星接入的eNB上。” —— 这是场景设定，与Solution 1相同。
2. “UE在attach/TAU请求中表明其对NB-IoT上IMS语音的支持。” —— 这是能力协商，与Solution 1相同。“地理链接一号”依然需要先亮明身份。
3. “MME向UE表明支持IMS PS语音会话。” —— 这是网络侧的能力确认，同样与Solution 1的逻辑一致。
4. “UE请求通过用户面为IMS APN建立一个IP类型的PDN连接。” —— 表明这仍然是一个纯粹的用户面方案，所有数据都将通过用户面（S1-U接口）传输。
5. “IMS信令通过默认EPS承载传输。” —— 这是第一个关键点。与Solution 1不同，默认承载现在有了明确的分工，它只负责传输“慢车道”上的IMS信令。
6. “IMS语音数据通过一个专用的EPS承载传输。” —— 这是Solution 2的核心灵魂。它引入了一个新的、专用的承载，专门用于在“快车道”上传输实时性要求高的RTP语音包。这从根本上解决了Solution 1中信令与语音相互干扰的问题。
7. “专用EPS承载可以与默认EPS承载一同建立。” —— 这是一个关键的优化。为了缩短呼叫建立时间，方案提出，这个用于语音的专用承载，最好不要等到用户拨号时才去动态建立，而是在UE附着网络、建立IMS PDN连接的同时，就作为“套餐”一并创建好。这种“预建立”机制，是应对GEO高时延的有效手段。

“先生们，女士们，看到了吗？” Alex在白板上画出两条并行的通道，“Solution 2的设计思想非常清晰：用空间换取质量。它通过消耗NB-IoT宝贵的承载资源（使用了两个承载），换来了信令与语音的物理隔离，为实现差异化QoS奠定了基础。”

2. 方案详述与架构图景：6.2.1 Description

本节通过架构图和协议栈图，更直观地展示了“分道行驶”是如何实现的。

This solution aims to resolve KI#1 by supporting the IMS voice call over NB-IoT (GEO) via one IMS PDN connection, with default and dedicated bearers as existing IMS voice support over WB-E-UTRAN.

这句话点明了Solution 2试图模仿的目标——“existing IMS voice support over WB-E-UTRAN” (现有的宽带E-UTRAN上的IMS语音支持)，也就是我们熟知的VoLTE。VoLTE就是通过“一个默认承载 + 一个专用承载”的模式来工作的。Solution 2的目标，就是将这套成熟的模式， 최대한地“移植”到资源受限的NB-IoT NTN上。

2.2.1 架构图解读

规范中的 “Figure 6.2.2-1: IMS signalling via default EPS bearer and voice data via a dedicated EPS bearer” 清晰地展示了数据流路径：

• IMS信令 (IMS Signaling): UE -> RAN -> S-GW -> P-GW -> P-CSCF。这条路径承载在默认EPS承载 (Default EPS Bearer) 上，对应到空口是DRB1。
• 语音数据 (Voice data): UE -> RAN -> S-GW -> P-GW -> AGW。这条路径承载在专用EPS承载 (Dedicated EPS Bearer) 上，对应到空口是DRB2。

值得注意的是，两条路径在核心网侧都属于同一个IMS PDN连接，共享同一个IP地址。P-GW会根据TFT（Traffic Flow Template，业务流模板）来区分数据包，将IMS信令包和语音包分别路由到各自的承载上。

2.2.2 协议栈解读

规范中的 “Figure 6.2.2-3: Protocol stack for IMS signalling” 和 “Figure 6.2.2-4: Protocol stack for IMS voice data” 展示了两条路径的协议栈。

两者在底层（PHY/MAC/RLC/PDCP）和高层IP层面之上基本相同。核心区别在于：

• 语音数据协议栈 (Figure 6.2.2-4): 在PDCP层明确标注了 (ROHC)，即Robust Header Compression（健壮性头压缩）。这是语音传输的关键优化。一个RTP/UDP/IP头加起来有40字节（IPv4）或60字节（IPv6），对于几十字节的语音净荷来说，开销巨大。ROHC可以将这些头部压缩到只有1-4个字节，极大地节省了空口带宽。Solution 2明确了在语音专用承载上要启用ROHC。
• 信令协议栈 (Figure 6.2.2-3): 通常不使用ROHC，因为信令包的大小和格式多变，压缩效果不佳且可能引入不必要的复杂性。

Alex总结道：“通过这两组图，Solution 2的实现路径已经非常清晰了。它通过建立两个独立的DRB，并在专用DRB上启用ROHC，在架构层面为信令的可靠性和语音的高效传输提供了保障。接下来，我们要看的是，建立这两个承载的具体信令流程是怎样的。”

3. 流程剖析：6.2.2 Procedures - “双车道”的修建过程

本节通过详细的信令流程图，展示了从UE附着到IMS呼叫的完整过程。

3.1 附着与IMS PDN连接建立 (6.2.2.1)

这是整个流程的起点，也是“预建立”专用承载的关键所在。规范的 “Figure 6.2.2.1-1: Attach and IMS PDN connection establishment Procedure” 展示了这一过程。

• 步骤 1-2: 附着请求 (Attach Request) Evelyn博士的“地理链接一号”开机，向MME发起附着请求。请求中会包含：

  • RAT type = NB-IoT (GEO): 告知网络当前的接入类型。
  • Support for IMS voice over NB-IoT: 声明自己的语音能力。
  • 可选地，直接在Attach Request中包含建立IMS PDN连接的请求 (PDN Connectivity Request)，这是一种加速流程的优化。

• 步骤 3-4: 鉴权与位置更新 MME与HSS进行交互，完成用户鉴权，并验证用户是否签约了NB-IoT上的IMS语音服务。

• 步骤 5: 核心步骤 - Create Session Request (创建会话请求) 这是建立“双车道”的关键。MME向S-GW/P-GW发起Create Session Request。在这个请求中，MME会携带UE的能力和签约信息。P-GW作为策略执行点，会根据这些信息做出一个重要决策：是否在创建默认承载的同时，就为这个用户预先建立一个专用的语音承载？

  One optimization to reduce the call setup time is to pre-establish the dedicated bearer prior to the IMS voice call setup… the P-GW establishes a dedicated EPS bearer for IMS media plane in association with the establishment of the default bearer.

  这个决策是运营商策略配置的结果。如果P-GW决定预建立，那么接下来的流程就会同时建立两个承载。

• 步骤 5-8 & 11-13: 承载建立过程

  • P-GW在响应中会包含对两个承载（一个默认，一个专用）的描述。
  • MME收到响应后，会向eNB发起Initial Context Setup Request，请求在空口建立两个对应的DRB（DRB1和DRB2）。
  • eNB通过RRC Connection Reconfiguration消息，配置UE建立这两个DRB。

最终，当附着流程完成时，UE不仅连接到了网络，而且已经拥有了两条通往IMS APN的、分工明确的用户面通道。

3.1.1 专用承载的TFT（业务流模板）难题

在预建立专用承载时，有一个棘手的问题：此时我们还不知道未来通话的对端IP地址和端口，那么该如何为这个专用承载配置TFT呢？ TFT是P-GW和UE用来识别哪些数据包应该走哪个承载的规则。

规范在步骤5的描述中提出了三种巧妙的替代方案 (alternatives):

• Alt#1 (无TFT): P-GW在预建立时不给UE下发上行TFT。UE在后续SIP呼叫协商完成后，知道了语音流的五元组信息，自行将RTP包映射到这个专用承载上。最简单，但缺乏网络侧的强力控制。
• Alt#2 (阻塞型TFT): P-GW先下发一个“阻塞所有流量”的上行TFT。在SIP呼叫建立过程中，P-GW通过Dedicated Bearer Modification流程，再更新这个TFT为正确的五元组规则。安全可控，但会在呼叫过程中引入额外的信令开销。
• Alt#3 (预配置TFT): 运营商预先在P-GW和UE上配置好用于GEO语音的固定端口范围或IP地址范围，TFT直接使用这些预配置的规则。例如，规定所有发往媒体网关（AGW）特定IP段的数据包都走此专用承载。实现简单，但缺乏灵活性。

Editors’ note: The above EPC optimization requires E2E evaluation… whether saving of RRC messages would make comparable impact to CST is to be assessed.

一个编辑注提醒我们，这些优化方案的实际效果需要端到端的评估。节省几条RRC消息，与SIP信令本身巨大的时延相比，可能只是杯水车薪。

3.2 移动始发 (MO) 和移动终止 (MT) 呼叫 (6.2.2.2 & 6.2.2.3)

一旦承载建立完毕，后续的呼叫流程就相对简单了。

• IMS注册: 通过已建立的默认承载（DRB1）完成。
• MO Call (主叫):
  1. Evelyn博士拨号，UE通过默认承载发送SIP INVITE消息。
  2. IMS核心网进行信令交互。
  3. P-CSCF通过PCRF触发P-GW进行资源授权。
  4. 关键步骤: 如果专用承载已预建立，P-GW可能只需要执行一次承载修改流程来更新TFT（对应Alt#2）。如果未预建立，P-GW则会触发完整的专用承载建立流程。
  5. 协商完成后，RTP语音包通过专用承载（DRB2）进行传输。
• MT Call (被叫): 流程类似，网络侧先通过默认承载向UE发送INVITE，后续流程与MO call基本一致。

4. 影响分析：6.2.3 Impacts on Services, Entities and Interfaces

本节总结了Solution 2对各个网络实体带来的改动。相比Solution #1，其影响更广、更深。

• UE:
  • 需要支持在NB-IoT上同时激活和管理两个用户面承载（一个默认，一个专用）。
  • 可能需要支持本地更新TFT（Alt#1）。
• RAN (eNB):
  • 核心要求：必须支持在NB-IoT UE上建立专用承载 (Support dedicated bearer establishment)。 这是对标准NB-IoT能力的一个重要增强。
• MME:
  • 需要支持在附着/PDN连接建立过程中，同时处理默认和专用承载的建立信令。
• P-GW:
  • 需要具备根据UE能力和签约，在会话建立之初就决策是否要“预建立”专用承载的策略逻辑。
  • 需要支持为专用承载配置上述三种TFT替代方案。
• HSS:
  • 签约数据需要增加一个标识，以指示该用户是否允许在NB-IoT NTN上使用IMS语音并建立专用承载。

5. 结论：更优的路径，更高的门槛

Alex最后总结道：“Solution 2为我们描绘了一幅更美好但也更复杂的图景。通过为信令和语音‘分道行驶’，它从根本上解决了Solution 1的QoS混乱问题，向着VoLTE的成熟架构迈进了一大步。这是它最大的优点。”

“然而，这条路也设置了更高的‘门槛’，” 他继续说道，“它的核心可行性，依赖于一个关键的假设——RAN和UE必须支持在NB-IoT上建立和管理专用承载。这在Rel-20的当时，可能还是一个需要RAN工作组进行研究和标准化的增强点。此外，‘预建立’虽然优化了时延，但也意味着即使用户不打电话，这个专用的语音承载也可能一直占用着宝贵的网络资源，带来了资源利用率的问题。”

“总而言之，Solution 2提供了一个在QoS保障上远优于Solution 1的、健壮的用户面方案。但它的实现，需要整个系统（从UE、RAN到核心网）进行更深度的协同增强。这也激励我们继续探索，是否存在成本更低、改动更小的方案，比如——那些剑走偏锋的控制面方案。”

---

FAQ

Q1：Solution 2相比Solution #1，最核心的改进是什么？ A1：最核心的改进是从“单承载混跑”演进为“双承载分离”。Solution 1将IMS信令和语音都放在同一个默认承载中，无法有效区分QoS。而Solution 2为IMS信令分配了默认承载，为IMS语音数据分配了一个新的、独立的专用承载。这种物理隔离，使得网络可以为两条数据流实施不同的QoS策略（如不同的调度优先级、启用ROHC等），从根本上解决了信令与语音的干扰问题，为保障通话质量奠定了坚实的架构基础。

Q2：什么是“预建立（pre-establishment）”专用承载？为什么它对GEO卫星场景特别重要？ A2：“预建立”是指在用户实际发起通话之前（例如，在UE开机附着网络、建立IMS PDN连接时），就提前将用于语音传输的专用承载创建好。这在GEO卫星场景下至关重要，因为动态建立一个专用承载需要多次信令往返，在GEO的高时延（往返>540ms）下，这个过程可能会持续数秒甚至更久，极大地延长了用户从拨号到听见回铃音的等待时间（即CST, Call Setup Time）。通过“预建立”，将这个最耗时的步骤提前完成，可以显著优化用户的通话体验。

Q3：Solution 2要求在NB-IoT上支持专用承载，这在技术上是一个大的挑战吗？ A3：是的，这是一个关键的技术增强点。标准的NB-IoT设计为了极度的简化和低功耗，其承载模型非常简单，通常只支持默认承载。引入对专用承载的支持，意味着UE和eNB的协议栈（特别是RRC和NAS层）都需要进行修改，以支持相关的建立、修改和释放流程。虽然这在技术上是可行的（借鉴了LTE的机制），但这确实是对NB-IoT原始设计理念的一个扩展，需要3GPP RAN工作组进行相应的标准化工作。

Q4：方案中提到的TFT（业务流模板）是什么？为什么在预建立承载时它会成为一个难题？ A4：TFT（Traffic Flow Template）是一组IP包过滤器（通常基于IP五元组：源/目的IP、源/目的端口、协议号），用于告诉P-GW和UE，哪些数据包应该被映射到哪个EPS承载上。难题在于，在“预建立”专用语音承载时，通话还没有发生，我们根本不知道未来的语音流将发往哪个具体的目的IP和端口。一个没有TFT的承载是无法工作的。因此，规范提出了三种变通方法（无TFT、阻塞TFT、预配置TFT），都是为了在信息不完整的情况下，临时解决TFT的配置问题。

Q5：Solution 2是否完美？它有什么潜在的缺点？ A5：不完美。它的主要潜在缺点有两个：1) 资源利用率低： “预建立”的专用承载，即使用户不打电话，也可能会一直占用着UE和网络中的承载上下文资源。对于NB-IoT这种为海量连接设计的技术，为每个可能打电话的用户都预留一个专用承载，可能会造成大量的资源浪费。2) 依赖RAN增强： 整个方案的可行性，强依赖于RAN和UE对专用承载的支持。如果这个增强无法实现或成本过高，那么该方案就成了空中楼阁。这些缺点，也正是驱动后续解决方案（如动态建立承载的UP方案，或完全不同的CP方案）被提出的原因。