51学通信

深度解析 3GPP TR 23.700-19：6.15 Solution #15 针对速率和呼叫建立时间约束的IMS增强方案

19分钟阅读

好的，我们继续进行深度拆解。这是本系列的第二十篇文章，将聚焦于又一个纯信令优化方案——Solution #15。

深度解析 3GPP TR 23.700-19：6.15 Solution #15: 针对速率和呼叫建立时间约束的IMS增强方案

本文技术原理深度参考了3GPP TR 23.700-19 V1.0.0 (2025-09) Release 20规范。在我们探讨了多种通过B2BUA架构进行流程优化的方案之后，本文将深入解读 6.15 Solution #15。这个方案可以看作是Solution 12思想的一次深化和细化，它同样聚焦于 Key Issue #2 (IMS增强)，但其目标更为明确和量化：在GEO NB-IoT NTN的极端速率（1-3kbps）和呼叫建立时间约束下，提出一套更为极致的SIP信令“瘦身”和流程简化方案。

引言：从“减肥”到“抽脂”

在之前的Solution 12中，Alex的团队已经学习了如何通过P-CSCF B2BUA的“秘书”模式，为SIP信令进行“减肥”。然而，面对GEO NB-IoT那近乎严苛的1-3kbps带宽，以及动辄十几秒的呼叫建立时间，单纯的“减肥”似乎还不够。

“我们需要的是‘抽脂’手术，” Alex在一次性能攻坚会上说道，“我们需要像外科医生一样，精准地审视SIP消息的每一个字节，流程的每一个步骤，将所有非绝对必要的‘脂肪’都剔除掉。Solution 15就是这样一份详尽的‘手术方案’，它告诉我们，为了在极限条件下生存，SIP信令究竟可以被压缩到何种程度。”

Solution 15没有引入新的架构，而是沿着Solution 12的P-CSCF B2BUA路径，进行了一次“显微镜”级别的优化探索，其手段之细致、量化之深入，在整个TR中都堪称典范。

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

本节用四个原则，概括了Solution 15的极致优化思路。

  1. Fixed fields in SIP messages from the UE to the P-CSCF may be omitted, and completed by the P-CSCF.
  2. SIP messages from the P-CSCF to the UE include only necessary SIP headers; other headers are removed.
  3. The UE does not support pre-condition…
  4. The MO and MT call setup procedures involve only the exchange of essential information.

Alex为团队解读这些原则：

  1. “从UE到P-CSCF的SIP消息中的固定字段可以被省略，并由P-CSCF补全。”
    • 这是Solution #12“上下文感知信息重用”思想的进一步强化。它强调了那些在一次注册周期内固定不变的字段（如Call-ID, From-tag, Via中的部分参数等）都可以被大胆省略。
  2. “从P-CSCF到UE的SIP消息只包含必要的SIP头；其他头被移除。”
    • 这强调了下行消息的“瘦身”。P-CSCF在向UE转发消息时，要扮演一个严格的“过滤器”，将所有UE不需要或可以自行推断的信息全部滤除。
  3. “UE不支持前置条件（pre-condition）…”
    • 再次确认了禁用Precondition是所有GEO NTN信令优化的“标准动作”。
  4. “主叫和被叫呼叫建立流程只涉及基本信息的交换。”
    • 这是对整个优化目标的总结，即追求信息交换的“最小完备集”。

“可以看到，Solution 15的原则与Solution 12高度一致，” Alex总结道，“但它的魔鬼，藏在细节里。接下来，我们将看到它是如何将这些原则，细化到每一个SIP消息、每一个头域、甚至每一个SDP字段的。”

2. 方案详述：6.15.1 Description - 极致“瘦身”三板斧

本节将优化手段分为了三大类。

2.1 第一板斧：SIP信令尺寸缩减 (6.15.1.1 SIP signalling size reduction)

这是方案的核心，规范以前所未有的粒度，详细罗列了在注册和呼叫建立消息中，哪些头域可以被省略或简化。

上行注册消息 (Uplink REGISTER - Table 6.15.1.1.1-1)

HeaderPresenceCompleted by P-CSCF?Note
Call-IDM/可简化 (can be simplified)
From-tag/to-tagM/可简化
ContactCYes (complete Cap)P-CSCF补充完整的feature-cap
ViaM/可简化 (branch can be simplified)
SupportedOYes (if not incl.)P-CSCF可以代为添加，UE无需发送
ExpiresOYes (if not incl.)P-CSCF可以使用默认值，UE无需发送

“看这些‘Yes’，” Alex指着表格，“Supported, Allow, Max-Forwards, Expires这些可选头域，UE统统可以不发送，全部由P-CSCF根据配置或默认值来补全。甚至像Call-ID, tag这些强制字段，方案也提出可以‘简化’，例如使用更短的字符串。这就是‘抽脂’手术的精准所在。”

上行呼叫建立消息 (Uplink Call Setup - Table 6.15.1.1.3-1)

这张表与注册消息类似，进一步提出：

  • P-Preferred-Identity: UE无需发送，P-CSCF可以从From头中提取。
  • Route/Record-Route: UE在初始INVITE中无需发送，这些由P-CSCF和核心网来管理。

下行消息 (Downlink Messages - Table 6.15.1.1.2-1 & 4-1)

对于P-CSCF发给UE的下行消息，优化的思路是移除和简化：

  • Via: 如果开启了拓扑隐藏，P-CSCF只返回一个简化的Via头。
  • Contact: 移除所有不必要的参数。
  • Content-Length, Supported, Allow等：都可以被省略或简化。

SDP协商的“瘦身” (6.15.1.1.5 & 6.15.1.1.6)

优化的手术刀甚至伸向了SDP：

  • 上行SDP (Uplink):
    • o-line, s-line: IP地址和会话名可以简化为1.1.1.1和-这样的占位符。
    • a=sendrecv, precondition parameters: 直接不包含。
  • 下行SDP (Downlink):
    • 删除重复的c-line和b-line。
    • 删除a=sendrecv和precondition参数。

2.2 第二板斧：减少SIP消息数量 (6.15.1.2 Reducing the number of required SIP messages)

The default bearer … and dedicated bearer … are pre-established during PDN connection establishment procedure, and the IMS call setup procedure is conducted without the pre-condition. The SIP signalling exchange between the UE and the P-CSCF comprises the following messages: SIP INVITE, 180 ringing, 200 OK, and ACK.

这一段是方案流程的核心：

  1. 承载预建立: 方案假设承载IMS信令和语音的承载（无论是CP还是UP）都已经预先建立好了。这消除了通话过程中的承载建立时延。
  2. 无前置条件: 再次强调禁用Precondition。
  3. 最小消息集: 通过以上两个前提，一次完整的呼叫建立（从UE发起直到可以通话），在UE和P-CSCF之间，最少只需要四个核心消息的交互：
    • UE → P-CSCF: INVITE
    • P-CSCF → UE: 180 Ringing
    • P-CSCF → UE: 200 OK
    • UE → P-CSCF: ACK

相比标准流程中可能多达十几次的消息交互，这是一个巨大的简化。

2.3 第三板斧：性能评估与量化 (6.15.1.3 Evaluation)

这是Solution 15最有价值的部分，它量化了上述优化带来的巨大收益。

Table 6.15.1.3.1-1 (MO call) 和 Table 6.15.1.3.2-1 (MT call) 对比了优化前后的总信令尺寸：

  • MO呼叫 (到振铃前):
    • 原始尺寸 (INVITE + 180): 2927 字节
    • 简化后尺寸: 1359 字节 (减少了 53.6%)
  • MT呼叫 (到振铃前):
    • 原始尺寸 (INVITE + 180): 2689 字节
    • 简化后尺寸: 1547 字节 (减少了 42.5%)

呼叫建立时间估算 (Estimation of call setup time before ringing)

基于简化后的信令尺寸，方案给出了在1-3kbps带宽下的呼叫建立时间估算：

  • MO呼叫: 1359 * 8 / (1k~3k) + propagation delay ≈ 4.7s ~ 11.9s
  • MT呼叫: 1547 * 8 / (1k~3k) + propagation delay ≈ 5.2s ~ 13.5s

“这些数字，就是我们‘抽脂’手术的成果报告！” Alex兴奋地对团队说，“它清晰地告诉我们，通过在信令层进行极致的优化，我们可以将GEO NB-IoT上的呼叫建立时间，稳定地控制在十几秒的量级。这在用户体验上，是一个巨大的飞跃。”

3. 流程剖析：6.15.2 Procedures - “瘦身”后的世界

本节通过流程图，展示了经过极致优化后的注册和呼叫流程。

  • SIP注册 (Figure 6.15.2.1-1): 流程与标准类似，但UE发送和接收的都是“简化版”的REGISTER和200 OK消息。
  • MO呼叫 (Figure 6.15.2.2-1):
    1. UE发送“简化版”INVITE。
    2. P-CSCF将其“补全”并发往核心网。
    3. P-CSCF作为B2BUA，在内部处理了100 Trying, 183, PRACK等信令，这些信令对UE完全不可见。
    4. P-CSCF收到180 Ringing和200 OK后，将其“简化”并发给UE。
    5. UE发送“简化版”ACK。

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

Solution 15的影响与Solution 12类似，高度集中于UE和P-CSCF。

  • UE:
    • 需要支持传输和接收高度简化的SIP信令。
    • 需要支持无前置条件和早媒体（early-media）。
    • 需要支持指示资源预留状态（因为承载是预建立的）。
  • P-CSCF:
    • 需要支持对简化SIP信令的双向补全和简化。
    • 需要扮演B2BUA角色。
    • 需要处理无前置条件的信令流程。

5. 结论：细节是魔鬼，量化是答案

Alex最后对Solution 15进行了总结：“Solution 15是信令优化领域的一次‘精雕细琢’。它没有提出颠覆性的新架构，而是在B2BUA这条已被证明可行的道路上，用‘工匠精神’打磨了每一个细节，并最终用令人信服的量化数据，证明了这条路的巨大价值。”

“它的优点在于其深度和务实性：”

  • “极致的优化粒度： 方案的分析深入到了每一个SIP头域和SDP字段，为实现最大程度的信令压缩提供了切实可行的‘操作手册’。”
  • “明确的性能预期： 它通过详细的计算，为GEO NB-IoT上的呼叫建立时间提供了一个清晰的、可预期的性能基线（约10-15秒），这对评估业务可行性至关重要。”

“其挑战，依然是对P-CSCF和UE实现复杂性的要求：”

  • “实现如此精细的信令‘补全’和‘过滤’逻辑，对P-CSCF的开发和测试工作量提出了很高的要求。UE侧同样需要实现一套高度定制的SIP客户端。”

“总而言之，Solution 15像一位严谨的科学家，用详实的数据和细致的分析，为我们证明了‘在应用层精耕细作，同样能获得巨大收益’。它与底层承载方案（如NIDD）的结合，将可能为卫星语音通信带来接近地面体验的性能。它告诉我们，在系统优化中，宏大的架构创新和精细的局部雕琢，同等重要。”

FAQ

Q1：Solution 15与Solution 12的核心区别是什么？ A1：Solution 15可以看作是Solution 12的**“量化和深化版”**。两者都采用了P-CSCF作为B2BUA来简化信令的核心思想。其主要区别在于：1) 粒度更细： Solution 15以前所未有的细节，逐一分析了SIP注册和呼叫流程中几乎所有头域和SDP字段的简化/省略可能性，提供了一份详尽的“优化清单”。2) 结果量化： Solution 15通过计算优化前后的信令尺寸，并结合GEO链路模型，给出了呼叫建立时间的具体量化预期（约10-15秒）。可以说，如果Solution 12提出了“是什么”（What），那么Solution 15则深入回答了“怎么做”（How）和“效果如何”（How much）。

Q2：方案中提到的“简化 (simplified)”Call-ID和tags是什么意思？ A2：在标准的SIP协议中，Call-ID是一个全局唯一的随机字符串，From-tag和To-tag也是用于标识对话的随机字符串，它们通常比较长以保证唯一性。但在UE和P-CSCF这样一个点对点的、受控的环境中，唯一性的要求可以被放宽。例如，P-CSCF可以为每个UE的每个通话，只使用一个很短的内部序号来作为Call-ID和tag的替代品，然后在将消息发往核心网时，再将其替换为全局唯一的长字符串。通过这种方式，可以在空口上节省大量的字节。

Q3：为什么说禁用Precondition和预建立承载是实现“最小消息集”（4个消息）的前提？ A3：因为这两个操作消除了呼叫过程中几乎所有额外的信令交互。

  • 禁用Precondition： 省去了用于QoS资源协商的UPDATE和PRACK等消息。
  • 预建立承载： 省去了在通话过程中，由核心网触发的Create/Modify Dedicated Bearer相关的NAS/RRC信令流程。 在这两个前提下，一次呼叫建立的核心逻辑就被简化为了最纯粹的四步：我请求（INVITE），对方振铃（180 Ringing），对方接听（200 OK），我确认（ACK）。

Q4：方案估算的10-15秒呼叫建立时间，在实际应用中是什么水平？用户能接受吗？ A4：这个时间处于“可用但有明显延迟”的水平。作为对比，地面4G VoLTE的呼叫建立时间通常在2-4秒。10-15秒的等待，用户会有明显的感知，但它远优于早期卫星电话动辄30秒甚至1分钟的接续时间。考虑到这是在没有地面信号的极端环境下的“生命线”通信，这个性能在很大程度上是可以接受的。更重要的是，这个时间是指到“振铃前”的时间，用户在几秒钟后可能已经听到了回铃音，实际的主观等待感受可能会更好一些。

Q5：这个方案与Solution #11（NIDD+协议转换）相比，哪个更优？ A5：这是一个典型的“应用层优化”与“传输层优化”的对比，两者各有千秋，且可以互补。

  • Solution #15（本方案）: 优点是对底层网络无要求，改动只在UE和P-CSCF，易于叠加在任何承载方案上。缺点是优化的上限受限于SIP协议本身，无法消除IP/UDP头部的固定开销。
  • Solution #11: 优点是优化更彻底，通过NIDD消除了IP/UDP开销，效率更高。缺点是对P-GW改动巨大，实现复杂。 最佳方案很可能是两者的结合：在一个支持NIDD传输的承载上（如Solution 11的架构），运行经过Solution 15极致简化的SIP信令。这样，既消除了底层IP/UDP的开销，又减少了上层SIP消息本身的体积，从而实现“双重压缩”，达到理论上的最优性能。

关系图谱