51学通信

深度解析 3GPP TR 23.700-19：6.4 Solution #4 基于NIDD和I1协议的IMS通话支持

21分钟阅读

好的，我们继续进行深度拆解。这是本系列的第九篇文章，将深入剖析一个极具前瞻性和全面性的重量级方案——Solution #4。

深度解析 3GPP TR 23.700-19：6.4 Solution #4: 基于NIDD和I1协议的IMS通话支持

本文技术原理深度参考了3GPP TR 23.700-19 V1.0.0 (2025-09) Release 20规范。在探索了前三个主要关注承载管理的解决方案之后，我们迎来了一个堪称“集大成者”的 6.4 Solution #4。这个方案不仅延续了Solution 3中NIDD（非IP数据交付）的极致效率思想，更进一步地引入了 I1协议 来替代传统的SIP信令，试图从根本上重塑UE与网络之间的信令交互方式。更重要的是，它首次将研究范围扩展到了KI#2(IMS增强)、KI#3(紧急呼叫)和KI#4(位置服务)，旨在提供一个端到端的、全面的星地融合语音解决方案。

引言：从“协议优化”到“协议革命”

在前述方案中，Alex的团队一直在为科学家Evelyn博士的“地理链接一号”寻找最佳的通信方案。他们尝试了“混合交通”（Solution #1）、“分道行驶”（Solution #2），甚至为语音包“脱掉了厚重的IP外套”（Solution #3）。然而，一个根本性的问题依然存在：无论怎么优化，承载IMS信令的SIP协议，其本身作为一种文本协议，依然显得过于“臃肿”和“啰嗦”。

“我们一直在优化‘路’和‘车’，” Alex在一次头脑风暴中说道，“但我们有没有想过，是不是‘导航系统’（信令协议）本身就用错了？SIP就像一本厚重的纸质地图，每次出门都要翻半天。在GEO卫星这种分秒必争的环境里，我们需不需要一个更简洁、更高效的‘电子导航’？”

这个“电子导航”，就是Solution 4给出的答案——I1协议。Solution 4不再满足于在SIP协议上“缝缝补补”，而是大胆地提出在UE和网络之间，用一种更轻量级的二进制协议来完成IMS会话的建立和控制。这是一场从“协议优化”到“协议革命”的跃迁。

This solution addresses KI#1, KI#2, KI#3, and KI#4.

规范开宗明-义地指出，这是一个“一揽子”解决方案，其雄心可见一斑。

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

本节用三个核心原则，奠定了Solution 4的架构基石。

  • The mechanism for separate default DRBs for Signalling and Media.
  • User Plane NIDD.
  • SCC-AS architecture in TS 23.292 and I1 protocol for IMS session setup.

Alex为团队逐一解读这三大支柱：

  1. “分离的默认DRB用于信令和媒体。”
    • 双承载模型: 与Solution 2和3一脉相承，本方案依然坚持“分道行驶”的原则，为信令和媒体建立独立的无线承载（DRB）。值得注意的是，这里提到了default DRBs（复数），暗示可能通过建立两个独立的PDN连接或在一个PDN连接内建立两个默认承载来实现，灵活性更高。
  2. “用户面NIDD (User Plane NIDD)。”
    • 极致效率: 方案明确采纳了Solution 3的核心思想，在媒体（语音）承载上使用NIDD传输，以消除IP/UDP头部开销，最大限度地节省空口带宽。
  3. “TS 23.292中的SCC-AS架构和用于IMS会话建立的I1协议。”
    • 协议革命: 这是Solution 4的核心灵魂。它不再使用UE到P-CSCF之间的标准SIP（Gm接口），而是引入了一套全新的架构：
      • I1协议: UE使用I1协议来发起和控制IMS会话。I1协议源于IMS Centralized Services (ICS)，是一种为CS（电路域）网络接入IMS而设计的轻量级二进制信令协议。它天生就比SIP更紧凑、更高效。
      • SCC-AS架构: UE的I1信令不再发送给P-CSCF，而是直接发送给一个特殊的IMS应用服务器——SCC-AS (Service Centralization and Continuity Application Server)。这个SCC-AS扮演了“协议转换网关”的角色，它负责终结来自UE的I1信令，并将其转换成标准的SIP信令，再转发给IMS核心网的其他节点（如S-CSCF）。

“所以，Solution 4的架构可以总结为，” Alex在白板上画出新的架构图，“在UE和SCC-AS之间，我们构建了一条全新的‘高速公路’。在这条路上，信令跑的是轻快高效的‘I1摩托’，语音跑的是‘裸运’的NIDD卡车。而SCC-AS则像一个繁忙的‘海关和换装中心’，负责将这些非标准格式的信令和数据，转换成能在中国际IMS网络中流通的标准格式。”

2. 方案详述：6.4.1 Description - 深入“换装中心”

本节详细阐述了方案的各个组成部分是如何协同工作的。

2.1 DRB与NIDD的协同 (6.4.1.2)

To maximize transmission efficiency over these narrowband links, it is proposed to use User Plane Non-IP Data Delivery (UP NIDD) for both call control (e.g. call setup…) signalling and voice media.

这里提出了一个更为激进的想法：不仅语音媒体流使用NIDD，连I1信令本身，也承载在NIDD之上！

Table 6.4.1.2-1: Data Delivery Overhead Comparisons (数据交付开销对比)

BytesRTPUDPIPPDCPRRCNASRLCMACBSRTotal
IPv412820121246
IP with RoHC312129
UP NIDD11125
CP NIDD21121218

这张表格极具说服力。它量化了不同方案的总协议开销（L2及以上）。可以看到：

  • 标准的IPv4方案，开销高达46字节。
  • 使用ROHC压缩IP头后，开销显著降低到9字节。
  • 而本方案采用的用户面NIDD（UP NIDD），总开销仅为5字节！ 相比标准方案，效率提升了近10倍。

这为在极窄带宽的NB-IoT链路上同时承载信令和媒体提供了理论上的可行性。

2.2 SCC-AS架构的核心作用 (6.4.1.3)

It is proposed to use IMS Service Centralization and Continuity architecture… I1 protocol… is designed specifically for this scenario where the bearer path is CS or the transport used for IMS call control is bandwidth constrained…

规范中的 “Figure 6.4.1.3-1: Overall Architecture for IMS Voice Call over NB-IoT NTN” 展示了SCC-AS如何作为核心网关，桥接NIDD/I1域和标准IMS域。

  • IWF (Interworking Function, 互通功能): SCC-AS在本方案中扮演了IWF的角色。
  • 信令平面: UE发出的I1信令，通过NIDD承载到达P-GW，P-GW将其转发给SCC-AS。SCC-AS将I1消息（如I1 INVITE）翻译成标准的SIP INVITE消息，然后发给S-CSCF。反之亦然。
  • 媒体平面: UE发出的NIDD语音包，到达P-GW，P-GW将其转发给一个与SCC-AS关联的媒体网关 (Media Gateway)。这个媒体网关负责为“裸奔”的语音包“穿上”RTP/UDP/IP外套，并可能进行必要的编解码转换 (transcoding)，然后再发往远端的媒体终点。

The media parameters included in the I1 message allow the Media Gateway within the IWF to determine whether transcoding is required. By resolving codec mismatches internally, the system avoids traditional end-to-end codec negotiation, significantly reducing call setup latency…

这是一个关键的优化点。传统的SIP呼叫需要通过SDP的Offer/Answer模型进行端到端的编解码协商，这个过程在高时延链路上非常耗时。而在本方案中，UE直接在I1 INVITE消息中告诉SCC-AS自己支持的（卫星专用）编解码器。SCC-AS（及其关联的媒体网关）作为“中间人”，直接决定使用哪种编解码器与UE通信，并在网络侧完成与对端编解码器的转换。这就将多步的端到端协商，简化为了两段独立的内部处理，极大地缩短了呼叫建立时间。

2.3 QoS支持 (6.4.1.4)

…assign an existing or newly defined QCI to voice traffic over these links… …configure separate APNs for signalling and media traffic, each using its own default EPS NIDD UP bearer.

本方案的QoS思路与Solution 2类似，但更进一步。它建议：

  1. 定义新的QCI: 为承载NIDD信令和媒体的承载定义新的、适用于卫星场景的QCI。
  2. APN分离: 甚至可以为信令和媒体配置不同的APN，从而建立两个完全独立的PDN连接。这可以实现更彻底的资源隔离和策略控制，例如，为媒体PDN选择一个路径更优、时延更低的P-GW。

2.4 对紧急呼叫和位置服务的扩展支持

Solution 4的全面性体现在它对KI3和KI4的考量上。

The solution also addresses KI#3 and KI#4 by proposing reusing E-CSCF in clause 6.4.2.3 where it is further proposed that existing location services can be used…

  • 紧急呼叫 (KI#3): 当SCC-AS从I1信令中识别出这是一个紧急呼叫时（例如，通过被叫号码），它会像一个标准的IMS节点一样，将翻译后的SIP INVITE消息，路由到 E-CSCF (Emergency CSCF)。后续流程就并入了标准的IMS紧急呼叫处理体系。
  • 位置服务 (KI#4): 方案建议，可以利用现有的位置服务架构。例如，在紧急呼叫建立过程中，网络可以触发一个标准的定位流程，从UE获取其GNSS位置，并通过SCC-AS将其承载在SIP信令中，最终传递给PSAP。

3. 流程剖析：6.4.2 Procedures

本节通过详细的信令流程图，展示了从注册到MO/MT呼叫的完整过程。

  • 注册 (Figure 6.4.2.1-1 - MO call, Steps 0-4):
    • UE发起Attach Request，请求建立Non-IP类型的PDN连接。
    • 附着成功后，MME会通过SGs接口，向一个MSC Server/VLR（集成在IWF/SCC-AS中）发起一次类似CS域的Location Update。这使得UE在IMS网络中被“看到”。
    • SCC-AS随后会代理UE，向IMS核心网发起一次标准的SIP REGISTER流程。
  • MO呼叫 (Figure 6.4.2.1-1):
    • Evelyn博士拨号，UE向SCC-AS发送I1 INVITE消息。
    • SCC-AS作为B2BUA，终结I1呼叫，并向S-CSCF发起一个新的SIP INVITE呼叫。
    • 同时，网络为语音媒体建立第二个NIDD承载。
    • 媒体流通过媒体网关进行协议转换和可能的编解码转换。
  • MT呼叫 (Figure 6.4.2.2-1):
    • SIP INVITE到达SCC-AS。
    • SCC-AS执行T-ADS（终结接入域选择），发现UE在NB-IoT NTN上，因此决定使用I1协议与UE交互。
    • SCC-AS向UE发送I1 INVITE消息。后续流程与MO呼叫类似。

4. 结论：全面而复杂的“未来战舰”

Alex最后总结道：“Solution 4无疑是目前我们研究过的最强大、最全面的一个方案。它像一艘装备精良的‘未来战舰’，试图用一套组合拳，一次性解决我们在GEO NB-IoT NTN上遇到的所有核心问题。”

“它的优点是压倒性的：”

  • “极致的效率： 通过‘双NIDD’（信令和媒体）+ I1协议，将空口开销降到了理论上的最低值。”
  • “更快的呼叫建立： 通过SCC-AS内部化编解码协商，避免了耗时的端到端SDP Offer/Answer流程。”
  • “全面的功能： 它是第一个系统性地考虑了紧急呼叫和位置服务的方案，提供了一个完整的解决方案闭环。”
  • “良好的隔离性： 通过SCC-AS作为互通网关，所有卫星接入的复杂性都被‘封装’了起来，对IMS核心网的冲击很小。”

“然而，它的复杂性和改动成本也是巨大的：”

  • “引入了全新的网元和协议： 运营商需要在其IMS网络中部署和集成功能强大的SCC-AS/IWF，并需要支持全新的I1协议。这对网络架构和运维都提出了新的挑战。”
  • “UE侧的深度定制： UE需要支持完整的I1协议栈，这比之前方案中对传输层的简单修改要复杂得多。”

“总而言之，Solution 4为我们展示了一条通往高性能星地融合语音通信的、清晰但陡峭的道路。它代表了用‘边缘的智能和复杂性’来换取‘极致的用户体验和系统效率’的设计哲学。这个方案是否会被最终采纳，将取决于行业对性能、成本和标准化复杂度的最终权衡。”

FAQ

Q1：Solution 4的核心创新是什么？它与Solution 3的NIDD方案有何本质不同？ A1：Solution 4的核心创新在于引入了I1协议替代SIP作为UE与网络间的IMS会话控制信令，并构建了以SCC-AS为核心的互通架构。它与Solution 3的本质不同在于：Solution 3仅仅优化了媒体流的传输（用NIDD），其信令流依然是标准的SIP协议；而Solution 4则对信令和媒体进行了双重革命——媒体使用NIDD，信令使用I1协议，从而实现了端到端的极致优化。

Q2：I1协议是什么？为什么它比SIP更适合卫星场景？ A2：I1是3GPP为ICS（IMS Centralized Services）定义的信令协议，最初用于让传统的CS（电路域）终端能够接入和使用IMS服务。它比SIP更适合卫星场景，主要因为：1) 二进制编码： I1是二进制协议，其消息结构紧凑，没有文本协议的冗余信息，消息体积远小于同等功能的SIP消息。2) 为受限网络设计： 它在设计之初就考虑了带宽受限和传输不可靠的网络环境，其流程和消息都经过了高度优化，更为轻量级。

Q3：SCC-AS在这个方案中扮演了什么角色？它和P-CSCF有什么区别？ A3：SCC-AS（Service Centralization and Continuity Application Server）在本方案中扮演了**“协议转换网关”和“业务控制核心”**的双重角色。它终结来自UE的“私有”协议（I1 over NIDD），并将其转换为IMS网络通用的“官方语言”（SIP over IP）。而P-CSCF是标准IMS架构中UE接入的第一个IMS节点（Proxy），它只处理标准的SIP协议。在Solution 4中，UE的信令实际上绕过了P-CSCF，直接到达了功能更强大的SCC-AS。

Q4：方案中提到的“内部化编解码协商”是如何缩短呼叫建立时间的？ A4：在传统SIP呼叫中，编解码器的选择需要通过SDP Offer/Answer机制，在主叫方和被叫方之间进行一次完整的端到端协商，这个过程在高时延的GEO链路上耗时很长。而在Solution 4中，这个协商过程被“内部化”了：1) 主叫UE（例如，卫星终端）在I1 INVITE中直接告诉SCC-AS它支持的卫星专用编解码器。2) SCC-AS立即在其关联的媒体网关上选定该编解码器，并同时向被叫方（例如，地面终端）发起一个使用标准编解码器（如AMR）的SIP呼叫。3) 编解码的转换完全在网络侧的媒体网关完成。这就将一个耗时的“端到端串行协商”，变成了两个并行的、由网络侧主导的“本地协商”，从而显著缩短了整体的呼叫建立时延。

Q5：Solution 4的架构如此复杂，它在现实世界中的部署前景如何？ A5：Solution 4代表了一种高性能但高成本的“顶配”方案。它的部署前景取决于市场的具体需求和技术演进。在某些对性能要求极高、且运营商愿意进行深度网络改造的场景（如国防、公共安全、航空等专业领域），这种方案可能具有吸引力。然而，对于大规模、低成本的民用市场，其较高的复杂性和对网络、终端的侵入式改动，可能会成为推广的阻力。更有可能的情况是，最终的标准化方案会吸收Solution 4的部分思想（如SCC-AS互通、简化协商），但可能会采用一种更折衷、更易于部署的协议（例如，二进制编码的SIP，而非完全替代的I1）。

关系图谱