好的，我们正式开启解决方案的深度探索之旅。这是本系列的第六篇文章，将首先概览所有解决方案的分布，然后深入剖析第一个、也是最基础的解决方案——Solution #1。
深度解析 3GPP TR 23.700-19：6.1 Solution #1: UP based IMS voice call over NB-IoT NTN (用户面承载方案)
本文技术原理深度参考了3GPP TR 23.700-19 V1.0.0 (2025-09) Release 20规范。在系统性地勘察了星地融合之路上的五大核心挑战（Key Issues）之后，我们正式进入这份技术报告最核心、最丰富的部分——第6章“解决方案”。本章如同一座琳琅满目的“技术军火库”，针对前述挑战，提出了多达20种不同的“武器装备”。本文将首先解读6.0节的“解决方案映射表”，为读者描绘一幅完整的技术路径图，然后将全部火力集中在第一个登场的方案——6.1 Solution #1，一种基于用户面（UP）承载的基础方案。
引言：从“问题清单”到“解题思路”
“好了，团队，我们已经完成了对那五座‘高山’（Key Issues）的详细勘察，” 5G工程师Alex在他的团队周会上说道，“我们知道了路的艰险，也明确了目标的高度。从今天起，我们的工作重心将从‘分析问题’转向‘评估方案’。第6章就是3GPP的顶级专家们为我们提供的‘登山攻略集’，包含了20种不同的攀登路线和装备组合。我们的任务，就是逐一研究，理解每一种方案的设计哲学、技术细节、优劣权衡。”
他顿了顿，指向屏幕，“我们不会一开始就迷失在细节的丛林里。首先，我们要看懂6.0节的‘地图总览’，了解每个方案都旨在解决哪个或哪些问题。然后，我们将从最简单、最符合直觉的Solution 1开始，看看‘常规武器’在这场特殊的战斗中表现如何。”
1. 解决方案地图总览：6.0 Mapping of Solutions to Key Issues
在深入任何一个具体方案之前，6.0节提供了一张至关重要的索引表，它将所有20个解决方案与它们旨在解决的5个Key Issues进行了映射。
6.0 Mapping of Solutions to Key Issues
Alex向团队解释道：“这张表格是我们未来几周工作的‘指南针’。它可以让我们在研究某个具体方案时，始终清楚它的目标和上下文。反过来，当我们聚焦于某个Key Issue时，也能快速找到所有相关的候选解决方案。”
Table 6.0-1: Mapping of Solutions to Key Issues (解决方案与核心问题的映射关系表)
| Solutions | KI#1 (IMS语音支持) | KI#2 (IMS增强) | KI#3 (紧急呼叫) | KI#4 (位置服务) | KI#5 (UE-SAT-UE) |
|---|---|---|---|---|---|
| #1 | X | ||||
| #2 | X | ||||
| #3 | X | ||||
| #4 | X | X | X | X | |
| #5 | X | ||||
| #6 | X | ||||
| #7 | X | X | |||
| #8 | X | ||||
| #9 | X | ||||
| #10 | X | ||||
| #11 | X | ||||
| #12 | X | ||||
| #13 | X | ||||
| #14 | X | ||||
| #15 | X | ||||
| #16 | X | ||||
| #17 | X | ||||
| #18 | X | ||||
| #19 | X | ||||
| #20 | X |
从这张表中，我们可以得出几个直观的结论：
- KI#1是重中之重： 解决基础的“GEO NB-IoT IMS语音支持”问题，吸引了最多的火力，从Solution 1到11（除#4、#7外）都聚焦于此。
- KI#2是优化焦点： “IMS增强”以减少时延和开销，是另一个研究热点，有大量的方案（#4, #7, 12-20）专门为此设计。
- KI#3和#4通常打包解决： Solution 4是一个“全能型”方案，它试图同时解决语音支持、IMS增强、紧急呼叫和位置服务四大难题。
- KI#5独树一帜： 没有任何一个方案同时跨越前四个KI和KI#5。这清晰地表明，KI#5（UE-SAT-UE通信）的研究是基于一个完全不同的架构（5GS）和场景，与其他基于EPC的研究路径是正交的。
“今天，我们的目标是Solution #1，” Alex圈出表格的第一行，“它旨在解决KI#1，一个纯粹的用户面承载方案。让我们看看，这条路走得通吗？”
2. 深度解读 6.1 Solution #1: 用户面承载方案
Solution 1可以被看作是解决GEO NB-IoT NTN上IMS语音问题的“最常规”或“最符合直觉”的尝试。它的核心思想是：尽量遵循标准的数据传输流程，将IMS信令和语音数据都通过用户面（User Plane）的默认承载来传输。
2.1 方案总纲：6.1.0 High-level solution Principles (高层解决方案原则)
本节用三条原则，精准地概括了Solution 1的精髓。
- The UE negotiates with MME on its capability of voice call support over NB-IoT.
- The default EPS bearer is used for both IMS signalling and voice data transmission.
- Bearer modification procedure for the QoS update or resource reservation is skipped or pre-initiated before the call setup in case that voice call would be setup over NB-IoT NTN via GEO satellite.
Alex逐条为团队解读：
-
“UE与MME协商其在NB-IoT上支持语音通话的能力。” 这呼应了我们在KI#1中讨论的“能力协商”挑战。当科学家Evelyn的“地理链接一号”开机附着网络时，它必须通过NAS信令明确告知MME：“我具备卫星语音能力。” 这是启动所有特殊处理流程的“敲门砖”。
-
“默认EPS承载被同时用于IMS信令和语音数据传输。” 这是Solution 1的核心灵魂。它选择了一条最简单的路：只使用一个承载，即UE附着时为IMS APN建立的那个默认承载，来传输所有东西——无论是SIP信令包还是RTP语音包。这是一个“All-in-One”的方案。优点是流程简单，不需要建立额外的专用承载，节省了信令开销。但缺点也显而易见：信令和语音被混杂在同一条管道里，如何保证它们的QoS？ 这为后续的讨论埋下了巨大的伏笔。
-
“用于QoS更新或资源预留的承载修改流程被跳过或在呼叫建立前预先发起。” 这是一个针对GEO高时延的关键优化。在标准的VoLTE中，当呼叫建立时，网络会触发一次“承载修改”流程来建立专用的GBR承载。这个流程本身就需要多次信令交互，在地面网络尚可接受，但在GEO链路上，一来一回的延迟将是灾难性的。因此，Solution 1提出两种策略：
- 跳过 (skipped): 干脆不做实时的承载修改，就用现有的默认承载，接受其“尽力而为”的QoS。
- 预先发起 (pre-initiated): 如果确实需要对默认承载的QoS参数进行一些优化（比如提升优先级），那么这个修改动作应该在用户拨打电话之前，例如在IMS注册成功后，就提前完成。这样就把耗时的操作从关键的呼叫路径上移除了。
2.2 方案详述：6.1.1 Description
本节对方案的核心思想进行了进一步的阐述。
In this proposal, it is assumed to provide IMS voice services via the default EPS bearer. i.e. IMS signalling and IMS voice data are served via the default EPS bearer, which can be updated its non-GBR QoS characteristics if required. Such QoS update is performed before IMS call setup procedure if UE is attached and IMS registered by NB-IoT(GEO).
这段话重申并细化了高层原则：
- 我们就在默认EPS承载上跑IMS语音。
- 这个默认承载是一个non-GBR承载。
- 如果需要，我们可以“更新”它的non-GBR QoS特性。这意味着，虽然我们不能把它变成一个有带宽保证的GBR承载，但我们或许可以调整它的一些参数，比如ARP（Allocation and Retention Priority，分配和保持优先级），使其在网络资源竞争中获得一些优势。
- 这种QoS更新，必须在呼叫建立前完成，以避免增加呼叫时延。
Editor’s note: Overhead analysis for this approach is to be updated.
Alex指着这条编辑注说：“看，连规范的作者都在提醒我们，这个方案的效率（开销分析）当时还是一个待研究（to be updated）的问题。这暗示了将语音和信令混跑可能带来的性能不确定性。”
2.3 流程剖析：6.1.2 Procedures
本节将上述思想分解为具体的流程步骤，是理解方案如何落地的关键。
2.3.1 附着/TAU流程：协商语音能力 (6.1.2.1)
On camping NB-IoT(GEO), UE who wants to use voice call service over the NB-IoT(GEO), negotiate its capability of voice call support over NB-IoT. Moreover, UE to use voice call service over the NB-IoT(GEO) needs to include the IE “Voice domain preference and UE’s usage setting” as the voice domain preference = “IMS PS Voice only” and UE’s usage setting = voice-centric.
这里给出了能力协商的具体实现方式。UE（地理链接一号）需要在 Attach Request 或 TAU Request 中，设置一个标准的信息元素 Voice domain preference and UE's usage setting。
voice domain preference设置为IMS PS Voice only：明确告诉网络，对于语音业务，我只使用IMS PS域（分组交换），不要试图让我回落到CS域（电路交换）。UE's usage setting设置为voice-centric：表明这个设备的主要用途是语音。这可以作为一个重要的输入，影响网络后续的资源分配和寻呼策略。
通过重用这两个已有的IE，Solution 1巧妙地避免了引入新的信令参数，体现了“最小化改动”的原则。
2.3.2 承载使用：默认承载的QoS困境 (6.1.2.2)
For IMS service, we assume the default EPS bearer is used for both IMS signalling and voice data. Editor’s note: It is FFS whether or how to differentiate QoS/priority between IMS signalling and voice data.
规范在这里一针见血地指出了本方案的最大软肋，并通过一个编辑注（Editor’s note）加以强调：当IMS信令和语音数据都在同一个默认承载里时，到底该如何区分它们的QoS和优先级？ 这个问题悬而未决（FFS - For Further Study）。
Alex打了个比方：“这就像你只有一条单车道，上面既要跑需要绝对可靠、偶尔通行的救护车队（SIP信令），又要跑需要持续、稳定速度的VIP车队（RTP语音流）。当两者在路上相遇时，谁给谁让路？如果为了保证救护车（信令）不被堵，你频繁地让VIP车队（语音）停车等待，那么通话就会变得卡顿。如果为了保证VIP车队（语音）的流畅，救护车（信令）被堵在了后面，那么关键的呼叫控制消息（如挂机）就可能无法及时送达。这是一个根本性的矛盾。”
P-CSCF requests the resource reservation for voice call traffic(i.e. GBR traffic) over NB-IoT(GEO) to PCRF, but P-GW considers as it does not allocate dedicated & GBR bearer for the voice call traffic(i.e. skip the resource reservation) or, if required, performs bearer modification procedure for the default EPS bearer to upgrade its QoS even as a non-GBR bearer.
这段描述了网络侧的“无奈”和“变通”。
- P-CSCF的“常规操作”: IMS的P-CSCF不知道接入网是NB-IoT NTN，它仍然会按照标准流程，向PCRF（策略和计费规则功能）请求为语音流分配一个GBR资源。
- P-GW的“智能变通”: 这个请求最终会到达P-GW。P-GW作为核心网与接入网之间的网关，它知道这是一个特殊的NB-IoT GEO连接。此时，P-GW必须“智能地”做出反应：
- 选项一 (忽略): 直接忽略掉这个建立GBR承载的请求，因为NB-IoT根本不支持。
- 选项二 (变通): 将这个GBR请求“翻译”成一个“升级现有non-GBR默认承载QoS”的操作。例如，通过承载修改流程，提升该承载的ARP优先级。
这个过程，要求P-GW具备新的、感知接入类型的策略执行能力。
2.4 影响分析：6.1.3 Impacts on Services, Entities and Interfaces
本节总结了Solution 1对各个网络实体带来的改动要求。
UE:
- Support capability of voice call support over NB-IoT.
- Set “Voice domain preference and UE’s usage setting” when camping on NB-IoT(GEO).
- Use default EPS bearer for both IMS signalling and IMS voice data over NB-IoT(GEO) access.
- UE (地理链接一号): 必须支持新的能力上报，并知道将所有IMS相关的包（信令和语音）都塞进默认承载。
MME:
- Support capability of voice call support over NB-IoT.
- Initiate bearer modification procedure for resource reservation/QoS update for the default EPS bearer before IMS call setup.
- MME: 必须能“听懂”UE的能力上报，并可能需要支持在呼叫前就触发对默认承载的QoS更新流程。
P-GW:
- allocate IMS signalling and voice mapped to the default EPS bearer.
- ignore the GBR characteristics of IMS voice call data traffic for UE if provided(i.e. skip the bearer modification procedure), or instead perform bearer modification procedure for QoS update for non-GBR characteristics if required
- initiate bearer modification procedure for resource reservation/QoS update for non-GBR characteristics of the default EPS bearer before IMS call setup.
- P-GW: 这是改动最大的网元。它需要：
- 将IMS信令和语音流都映射到同一个默认承载。
- 核心逻辑：学会如何处理来自PCRF的GBR请求——要么“忽略”，要么“翻译”成对non-GBR承载的修改。
- 支持在IMS呼叫前，就对默认承载发起QoS更新。
3. 结论：简单之路，荆棘丛生
Alex最后总结道：“Solution 1为我们展示了一条最简单、最直接的解决路径。它试图用最小的改动，在现有的默认承载模型上，硬生生地挤出语音业务的空间。它的优点在于简单性和对承载模型改动小。但它的缺点也是致命的，规范用一个关键的‘Editor’s note’明确指出了它的‘阿喀琉斯之踵’——无法有效地区分和保障在同一承载中混跑的IMS信令和语音数据的QoS。”
“这个方案，就像是试图让一条乡间土路同时承担国道和高速公路的功能，却又没有提供有效的交通管理机制。它虽然把路修通了，但路上的交通状况可能是混乱和不可预测的。这也为我们接下来研究Solution 2等更复杂的方案，提供了充分的理由。它们正是为了解决Solution 1留下的这个核心难题而设计的。”
FAQ
Q1：Solution 1的核心思想是什么？为什么说它“最符合直觉”？ A1：Solution 1的核心思想是**“All-in-One”，即仅使用一个单一的、默认的EPS承载来传输IMS业务的所有流量，包括SIP信令和RTP语音流**。说它“最符合直觉”是因为它最大限度地重用了最基础的网络连接模型，避免了为语音业务建立额外的、复杂的专用承载，流程上最为简化，对现有承载模型的改动最小。
Q2：Solution 1面临的最大技术挑战是什么？规范是如何指出这一点的？
A2：最大的技术挑战是无法有效地区分和保障在同一个non-GBR承载上传输的IMS信令（要求高可靠性）和RTP语音流（要求低时延、低抖动）的服务质量（QoS）。规范通过一个关键的编辑注 Editor's note: It is FFS whether or how to differentiate QoS/priority between IMS signalling and voice data. 明确指出了这个问题是一个悬而未决（For Further Study）的难题，是该方案的根本性缺陷。
Q3：什么是“承载修改流程被跳过或预先发起”？为什么这个优化在GEO卫星场景下至关重要？ A3：“承载修改”是在通话建立时为语音创建或修改承载QoS的标准流程，它本身需要多次信令往返。在GEO卫星场景下，物理传播时延极高（往返超过540ms），任何额外的信令交互都会极大地延长呼叫建立时间。因此，该优化提出：要么“跳过”此流程，接受默认QoS；要么“预先发起”，即在用户拨号前的空闲时间（如IMS注册后）就完成承载修改，将这个耗时的操作移出对用户体验至关重要的呼叫建立主路径，从而最大限度地缩短用户按键后到听到回铃音的时间。
Q4：在Solution 1中，P-GW扮演了什么关键角色？它需要哪些新的“智能”？ A4：P-GW是该方案中需要最大逻辑改动的核心网网元。它扮演了“策略转换器”和“智能执行点”的关键角色。它的新“智能”主要体现在：当收到来自上游（PCRF）为语音通话建立GBR承载的标准化指令时，P-GW需要知道当前的接入网络是NB-IoT NTN且不支持GBR。此时，它不能像往常一样执行指令，而是需要做出变通：要么直接“忽略”该指令，要么将其“翻译”成一个它能够执行的操作，即对现有的non-GBR默认承载发起一次QoS参数（如优先级）的修改。这种感知接入类型并进行策略转换的能力是P-GW必须具备的新功能。
Q5：Solution 1中UE通过设置“UE’s usage setting = voice-centric”来声明能力，这在网络侧有什么实际作用？ A5：将UE的使用模式设置为“voice-centric”（以语音为中心）可以为网络提供重要的优化线索。例如：1) 寻呼策略： 对于“voice-centric”的设备，网络在寻呼（Paging）它以接收来电时，可能会采用更频繁、更鲁棒的寻呼策略，以确保UE能被及时唤醒，降低来电接通时延。2) 资源保持策略： 网络可能会为这类设备采用更长的无线资源非活动定时器，避免在一次通话的短暂静默期间就释放其RRC连接，从而减少因RRC重建带来的额外时延。3) 节能策略： 相反，如果设备不处于通话中，网络可以知道它对数据的实时性要求不高，从而允许其进入更深度的节能模式（如eDRX或PSM）。