好的，我们继续进行深度拆解。这是本系列的第十四篇文章，将深入剖析一个针对IDLE态用户呼叫建立速度进行专项优化的方案——Solution #9。
深度解析 3GPP TR 23.700-19：6.9 Solution #9: IDLE态UE的IMS语音呼叫发起优化
本文技术原理深度参考了3GPP TR 23.700-19 V1.0.0 (2O25-09) Release 20规范。在我们已经探讨了多种关注承载模型和协议效率的解决方案之后，本文将聚焦于一个非常具体但至关重要的性能瓶颈——IDLE态（空闲态）用户的呼叫建立时延。我们将深入解读 6.9 Solution #9，这是一个极具创意的“抢跑”方案，它巧妙地将IDLE态唤醒流程与IMS呼叫发起流程合二为一，试图在GEO卫星的高时延环境下，为节省宝贵的几秒钟而进行的一次精妙流程再造。
引言：从“先起床，再出门”到“穿着衣服睡觉”
让我们再次回到科学家Evelyn博士的场景。她的“地理链接一号”为了省电，大部分时间都处于IDLE（空闲）或睡眠模式。这意味着它的RRC（无线资源控制）连接已经断开，核心网侧也释放了它的S1连接。当她需要紧急拨打电话时，设备需要经历一个标准的两步过程：
- 第一步：唤醒 (Service Request Procedure)。 设备需要先向网络发送一个“服务请求”，重建RRC和S1连接，从IDLE态转换到CONNECTED（连接）态。这个过程本身在高时延的GEO链路上就需要一次完整的信令往返，耗时可能超过1秒。
- 第二步：呼叫 (IMS Call Setup)。 在网络确认其“醒来”之后，设备才能开始发送SIP
INVITE消息，启动漫长的IMS呼叫建立流程。
“这个‘先起床，再出门’的模式在地面网络没什么问题，但在GEO卫星上，每一秒都无比珍贵。” Alex在一次性能优化专题会上说道，“Solution 9的工程师们就在思考：我们能不能让Evelyn博士‘穿着衣服睡觉’？当闹钟（拨号动作）一响，不是先起床，而是直接‘破门而出’（发起呼叫）？”
这个生动的比喻，恰恰揭示了Solution 9的核心思想：将Service Request信令与SIP INVITE信令“捆绑”在一起发送，实现IDLE态唤醒和IMS呼叫发起的“一步到位”。
1. 方案总纲：6.9.0 High-level solution Principles (高层解决方案原则)
本节用四个原则，概括了Solution 9的“抢跑”策略。
- The UE and Network Support both CP CIoT EPS optimisation and S1-U data transfer.
- The UE uses IMS user plane for IMS signalling and voice when the UE is in ECM-CONNECTED.
- The UE indicates active flag in Control Plane Service Request and also includes SIP INVITE in ESM message container when UE the initiate voice call in ECM-IDLE. This activates S1-U bearer and user plane radio bearers for IMS PDN connection.
- The rest of IMS procedure continues with user plane.
Alex为团队逐一解析这些原则：
-
“UE和网络同时支持CP CIoT优化和S1-U数据传输。”
- 这表明方案的适用环境与Solution 7类似，是一个支持CP/UP双模能力的系统。UE和网络需要能够理解并处理这两种不同的数据传输模式。
-
“当UE处于ECM-CONNECTED态时，它使用用户面进行IMS信令和语音传输。”
- 这定义了常规状态下的行为。如果Evelyn博士的设备本来就是醒着的（连接态），那么她打电话时，就走标准的“用户面”（UP）路径。这可能是基于Solution 2的双承载模型，也可能是其他UP方案。Solution 9并不关心连接态下的具体实现。
-
“当UE在ECM-IDLE态发起语音呼叫时，它在Control Plane Service Request中置起active flag，并同时在ESM消息容器中包含SIP INVITE。这将激活S1-U承载和用户面无线承载。”
- 这是Solution 9的核心灵魂，定义了IDLE态下的特殊行为。让我们分解这个复杂的句子：
- 触发条件:
UE in ECM-IDLE initiate voice call。本方案只在UE从空闲态发起呼叫时被触发。 - 所用信令: UE发送的是一个增强的
Control Plane Service Request消息。这是UE从IDLE态唤醒的标准信令。 - 关键操作1:
includes SIP INVITE in ESM message container。这是“抢跑”的关键。UE没有等待网络响应Service Request，而是直接把IMS呼叫的“第一枪”——SIPINVITE消息，作为一个“包裹”（封装在ESM message container中），塞进了这个唤醒信令里，一起发了出去。 - 关键操作2:
indicates active flag。为了让网络知道这次唤醒非同寻常，UE同时在Service Request中置起了一个特殊的active flag。这个标志告诉MME：“我这次醒来，不是要发普通数据，而是要立刻激活我的用户面连接，有紧急业务！” - 网络动作: MME收到这个“捆绑”了
INVITE并带有active flag的特殊请求后，会立即明白UE的意图。它不会仅仅是恢复S1连接，而是会一步到位地激活完整的用户面路径，包括S1-U承载和空口的DRB（数据无线承载）。
- 触发条件:
- 这是Solution 9的核心灵魂，定义了IDLE态下的特殊行为。让我们分解这个复杂的句子：
-
“后续的IMS流程继续在用户面上进行。”
- 一旦用户面被这次特殊的Service Request激活，后续所有的IMS信令（如183, PRACK, 200 OK等）和RTP语音流，都将在刚刚建立的用户面上传输。控制面在这里只扮演了一个“点火”的角色。
“所以，Solution 9的流程，” Alex总结道，“就像一次‘特种作战突袭’。它利用控制面Service Request这条‘秘密通道’，将‘先头部队’（SIP INVITE）直接投送到‘敌方腹地’（核心网），同时发信号让‘大部队’（用户面）立即跟进。相比‘常规作战’，它节省了‘集结部队’（等待Service Request响应）的时间，理论上至少可以节省一次GEO链路的往返时延，也就是超过半秒的宝贵时间。”
2. 方案详述：6.9.1 Description
本节进一步阐明了方案的设计动机和边界。
The UE triggering IMS voice call over CP have advantage of saving call setup time because Control Plane Service Request message can contain the INVITE message… To support QoS of IMS voice data, dedicated GBR bearer is needed over NB-IoT RAT. Editor’s note: It is FFS whether using GBR bearers provides any benefit for NB-IoT NTN RAT.
- 设计动机: 明确指出，在CP Service Request中携带
INVITE消息，是为了节省呼叫建立时间。 - QoS假设: 方案假设为了保障后续用户面语音的QoS，需要在NB-IoT上支持GBR专用承载。一个编辑注对此提出了疑问，这表明GBR在NB-IoT NTN上的必要性和可行性仍是一个开放性问题。
Basically, the UE uses user plane default bearer for IMS signalling and dedicated bearer for IMS voice when the UE is in ECM-CONNECTED. But when the UE is in ECM-IDLE, the UE use the Control Plan Service Request to send SIP INVITE message…
这段话清晰地界定了方案的作用域：它是一个针对IDLE态MO-Call（主叫）的专项优化，与CONNECTED态下的行为正交，可以与其他用户面方案（如Solution #2）结合使用。
NOTE 2: …for MT voice call case, when the UE is idle, the UE performs Network Triggered Service Request procedure… to use user plane for IMS voice and signalling.
对于被叫（MT-Call），该方案不适用。当IDLE态的UE被叫时，它还是需要执行标准的网络触发服务请求流程（寻呼 → Service Request），恢复连接后，再接收INVITE。
3. 流程剖析：6.9.2 Procedures - “抢跑”的信令细节
规范的 “Figure 6.9.3-1: High-level procedure for IMS voice over NB-IoT (GEO)” (图号似有误，应为6.9.2-1) 展示了详细的信令流程。
-
步骤 1-3: 正常操作与进入IDLE
- UE附着网络，建立IMS PDN连接，并完成IMS注册。此时UE处于CONNECTED态。
- 由于没有业务，一段时间后，eNB释放RRC和S1连接，UE进入IDLE态。
-
步骤 4: “抢跑”开始！
- Evelyn博士拨打电话。
- UE构建一个
Control Plane Service Request消息。 - 关键动作: UE将完整的SIP
INVITE消息封装成ESM DATA TRANSPORT，再放入ESM message container，作为“包裹”塞入Service Request中。同时，置起active flag。 - 这个“超级信令”通过空口发送给MME。
-
步骤 5-7: MME的“三连动”
- MME收到这个特殊的Service Request，解析出
INVITE和active flag。 - 动作1: MME不等待，立即通过S11-U接口，将解封装出来的SIP
INVITE消息转发给SGW/PGW，送往IMS网络。IMS呼叫流程已经提前开始了！ - 动作2: 由于
active flag的存在，MME同时向SGW发送Modify Bearer Request，请求激活用户面路径。 - 动作3: MME向SGW发送
Release Access Bearers Request，通知SGW关闭旧的、经由MME的S11-U数据路径（因为后续数据将走S1-U）。
- MME收到这个特殊的Service Request，解析出
-
步骤 8-11: 用户面的建立
- MME向eNB发送
Initial Context Setup Request，请求为UE激活用户面无线承载（DRBs for IMS signalling and voice）。 - eNB通过RRC信令配置UE。
- UE和eNB完成RRC连接重建和DRB建立。
- MME收到eNB的响应后，向SGW发送
Modify Bearer Request，将S1-U的隧道信息（eNB的地址和TEID）更新给SGW。
- MME向eNB发送
-
步骤 12-后续: 回归正常的用户面流程
- 此时，完整的用户面路径
UE <-> eNB <-> SGW已经建立完毕。 - 后续所有的IMS信令（如从网络侧返回的
100 Trying,183 Progress等）和语音媒体流，都将在这条新建立的用户面上传输。
- 此时，完整的用户面路径
4. 影响分析：6.9.3 Impacts on Services, Entities and Interfaces
Solution 9的改动非常精准，主要集中在UE和MME。
- UE:
- 核心改动: 需要具备在IDLE态发起呼叫时，构造并发送“捆绑了SIP INVITE的特殊Service Request”的能力。
- 需要支持
active flag。
- eNB:
- 需要支持为NB-IoT GEO接入建立GBR专用承载（如果QoS假设成立）。
- MME:
- 核心改动: 需要能够解析这种特殊的Service Request，并能执行“三连动”：立即转发
INVITE、触发UP激活、释放旧的CP路径。这是对MME状态机和流程处理能力的一个重要增强。
- 核心改动: 需要能够解析这种特殊的Service Request，并能执行“三连动”：立即转发
5. 结论：精妙的时间魔术，有限的适用场景
Alex最后对Solution 9进行了精辟的总结：“Solution 9是一个精巧的‘时间魔术’。它通过打破常规的流程顺序，用‘并行处理’替代了‘串行处理’，成功地从高时延的GEO链路中‘偷’回了宝贵的一两秒钟。对于提升IDLE态用户的呼叫体验，这是一个极具价值的优化。”
“它的优点非常明确：”
- “显著降低IDLE态主叫时延： 这是它唯一的、但也是极具吸引力的优点。对于卫星电话这种可能长期处于待机状态的设备，这个优化能带来可感知的体验提升。”
- “兼容性好： 它可以作为一个‘插件’，与各种用户面承载方案（如Solution #2）结合使用，只在IDLE态这一个特定场景下生效，不影响常规流程。”
“然而，它的局限性也同样清晰：”
- “适用场景单一： 它只对IDLE态的MO-Call（主叫）有效，对MT-Call（被叫）和CONNECTED态的呼叫没有任何优化效果。”
- “增加了MME和UE的复杂性： 需要UE和MME支持一套全新的、非标准的信令交互逻辑，对协议栈的修改和测试都带来了额外的工作量。”
- “依赖CP/UP双模能力： 方案的成立，有赖于UE和网络都支持CP Service Request和S1-U用户面，对系统能力有一定要求。”
“总而言之，Solution 9不像之前的方案那样试图构建一个全新的承载体系，它更像一个‘性能补丁’。它以增加少量系统复杂性为代价，精准地解决了IDLE态呼叫启动慢这个痛点。在卫星通信这种‘时间就是一切’的场景下，这种针对性的优化，往往具有非常高的实用价值。”
FAQ
Q1：Solution 9的核心创新是什么？它解决了什么具体问题？
A1：Solution 9的核心创新是将IDLE态唤醒流程（Service Request）与IMS呼叫发起流程（发送SIP INVITE）合二为一。它解决了IDLE态（空闲态）用户发起主叫（MO-Call）时，因需要先恢复无线连接再发起呼叫而导致的额外时延问题。通过在Service Request信令中直接“塞入”SIP INVITE消息，它将两个串行的步骤变成了并行处理，从而显著缩短了呼叫建立时间。
Q2：方案中提到的“ESM message container”和“active flag”各自扮演什么角色？ A2：它们是实现“抢跑”流程的两个关键工具。
ESM message container扮演了**“包裹”**的角色。它是一个标准的NAS信令容器，原本用于在UE和P-GW之间透明传输会话管理（ESM）信息。Solution 9巧妙地借用它，将一个上层应用信令（SIPINVITE）打包成一个NAS层的“货物”，塞进了底层的Service Request信令中。active flag扮演了**“加急标签”**的角色。它是一个在Service Request中设置的特殊标志，用于告知MME，这次唤醒请求不是普通的恢复连接，而是需要立即激活用户面（UP）数据路径的紧急请求。这个标签是触发MME后续一系列快速用户面建立动作的关键。
Q3：为什么这个方案只对IDLE态的主叫（MO-Call）有效，而对被叫（MT-Call）无效？
A3：因为主叫和被叫的流程发起方不同。在**主叫（MO-Call）场景，是UE主动发起所有动作，因此UE可以在发起唤醒请求的同时，主动地将INVITE消息包含进去。而在被叫（MT-Call）**场景，是网络侧先收到了一个指向该UE的呼叫。此时UE处于IDLE态，网络无法直接向其发送INVITE。网络必须先通过寻呼（Paging）流程找到并唤醒UE，UE被唤醒后，再执行Service Request流程恢复连接。只有在连接恢复后，网络才能将INVITE消息下发给UE。这个流程顺序是固定的，无法“抢跑”。
Q4：MME在收到这种特殊的Service Request后，执行的“三连动”是什么？为什么需要这样做？ A4：“三连动”是指MME需要并行处理三个关键动作：
- 立即转发INVITE： 将从Service Request中解出的SIP
INVITE，立即通过S11-U接口发往SGW，让IMS呼叫流程尽早开始。 - 激活用户面路径： 由于
active flag的指示，立即向SGW和eNB发起建立和激活S1-U用户面承载的流程。 - 释放旧的CP路径： 通知SGW关闭经由MME的S11-U数据转发路径，因为后续数据将全部切换到新的S1-U路径上。 这样做是为了最大限度地并行化处理，缩短时间。它确保了在用户面路径建立的同时，IMS信令已经在核心网中开始传递，实现了时间和流程上的无缝衔接。
Q5：这个方案与Solution #7（动态CP/UP切换方案）有何关联和区别？ A5：两者有一定的关联，都利用了系统支持CP和UP双模传输的能力，但解决的问题和机制完全不同。
- 关联： 都体现了在CP和UP之间进行切换或协同的思想。
- 区别：
- 目标不同： Solution 7旨在解决通话过程中从低效的CP媒体传输切换到高效的UP媒体传输的问题，是一个通话中的优化。Solution 9旨在解决IDLE态呼叫发起时的初始时延问题，是一个通话前的优化。
- 机制不同： Solution 7的切换是由UE在CONNECTED态下，通过
Control Plane Service Request（携带active flag）来触发的，是从CP路径切换到UP路径。Solution 9是在IDLE态下，利用Control Plane Service Request（携带INVITE和active flag）来同时完成唤醒和UP路径的首次激活，它不是一个“切换”，而是一个“加速建立”过程。两者虽然可能用到相似的信令，但所处的状态和实现的目标完全不同。