51学通信

深度解析 3GPP TR 23.700-19：6.13 Solution #13 AS作为B2BUA的无前置条件呼叫流程

22分钟阅读

好的，我们继续进行深度拆解。这是本系列的第十八篇文章，将聚焦于另一个在B2BUA思想上进行演进的方案——Solution #13。

深度解析 3GPP TR 23.700-19：6.13 Solution #13: AS作为B2BUA的无前置条件呼叫流程

本文技术原理深度参考了3GPP TR 23.700-19 V1.0.0 (2025-09) Release 20规范。在深入剖析了Solution #12——一个将P-CSCF打造为“智能秘书”（B2BUA）的精巧方案之后，本文将探讨一个在B2BUA角色扮演者上提出不同思路的 6.13 Solution #13。这个方案的核心思想是，将B2BUA的重任从网络入口的P-CSCF，转移到IMS核心网深处的应用服务器（AS），并同样以**禁用前置条件（Precondition）**作为优化呼叫时延的主要手段。

引言：从“门口的秘书”到“办公室的专家助理”

Alex的团队对Solution 12的P-CSCF B2BUA方案进行了热烈的讨论。团队的IMS架构师提出了一个担忧：“让P-CSCF扮演如此重角色的B2BUA，是不是有点‘杀鸡用牛刀’，而且风险过于集中？P-CSCF作为所有IMS流量的入口，其核心职责应该是安全、路由和接入控制，我们不应该让它背负过多复杂的业务逻辑。有没有可能，让更专业的‘人’来干这个‘翻译’和‘适配’的活？”

这个思路，与Solution 13不谋而合。Solution 13认为，处理卫星接入这种特殊的、需要编解码转换和复杂信令适配的业务，更适合交由一个专门的**应用服务器（AS）**来处理。这就像，与其让公司前台的秘书去处理所有专业的技术文档翻译，不如将这个任务交给CEO办公室里精通多语种和专业知识的“专家助理”。

This solution is to address Key Issue #2: IMS enhancement for GEO NB-IoT NTN access. This solution is to realize IMS call setup without pre-condition for MO/MT UE connected via GEO…

规范明确指出，这是一个针对KI#2的IMS增强方案，其核心手段与Solution 12一样，都是围绕禁用前置条件来简化流程、缩短时延。但实现这一目标的“主刀医生”，从P-CSCF换成了AS。

1. 方案总纲：6.13.0 High-level solution Principles

Solution 13没有像其他方案那样单独列出高层原则，但其核心思想贯穿于整个描述（6.13.1 Description）之中。我们可以将其总结为以下几点：

  1. 核心手段 - 禁用前置条件 (No Pre-condition):

    • 与Solution 12一样，通过在GEO卫星接入的UE发起的呼叫中，不使用耗时的Precondition信令协商流程，来直接地、有效地缩短呼叫建立时间。

  2. 核心角色 - AS作为B2BUA:

    • IMS网络中的一个特定应用服务器 (AS)，而不是P-CSCF，将扮演B2BUA的角色。
    • 这个AS负责终结来自GEO UE的“无前置条件”呼叫，并代表它向对端发起一个标准的、“有前置条件”的呼叫，从而在两种流程之间进行无缝转换。

  3. 触发机制 - 基于iFC的智能路由:

    • S-CSCF会根据HSS下发的iFC（Initial Filter Criteria，初始过滤规则），智能地判断何时需要将一个呼叫路由到这个专门的AS。例如，当一个呼叫的主叫或被叫被识别为“GEO卫星用户”时，iFC就会被触发。

  4. 媒体面适配 - 编解码转换 (Transcoding):

    • 由于GEO链路的极端带宽限制，卫星UE可能会使用一种特殊的超低比特率编解码器（ULBC）。这个作为B2BUA的AS，通常会与一个媒体资源功能（MRF）紧密配合，负责将这种特殊的编解码器与地面网络常用的标准编解码器（如EVS, AMR）进行转换。

Alex总结道：“Solution 13的逻辑链非常清晰。当一个与卫星相关的呼叫进入IMS核心网时，S-CSCF就像一个‘分诊台’，通过iFC规则识别出这个‘特殊病患’，然后将它引导至‘卫星通信专家门诊’——也就是我们的AS B2BUA。这位‘专家’不仅会处理特殊的信令流程（无前置条件），还会处理特殊的媒体格式（超低速率编解码器）。”

2. 方案详述：6.13.1 Description - “专家助理”的工作细节

本节详细描述了AS作为B2BUA的优势以及呼叫时延的估算。

  1. Capability of Optimized voice is negotiated during IMS REGISTER. … it needs to support Codec for GEO voice … and processing SIP INVITE with no pre-condition.
  2. SigComp capability negotiation during IMS REGISTER.
  • 能力协商: 与Solution 12类似，UE支持GEO专用编解码器、无前置条件流程、以及可能的SigComp压缩能力，都是在IMS注册时与网络进行协商的。网络侧会将这些能力记录在HSS中。
  1. B2BUA (B2B User Agent) can be used to support the interaction with normal MO/MT UEs. HSS provisions iFC to S-CSCF based on RAT type (GEO access) and UE’s Optimized voice capability for involving AS acting as B2BUA…
  • 触发逻辑: 这里明确了HSS的角色。HSS会根据用户的签约信息（如支持优化语音）和注册时上报的接入类型（RAT Type = GEO），生成特定的iFC。当S-CSCF处理该用户的呼叫时，就会根据iFC将呼叫路由给AS B2BUA。

呼叫时延估算 (Call setup time estimation)

SIP INVITE: 1.4Kbyte; 200 OK: 0.8KByte. …considering “SigComp”… 0.5*SIP message size is the estimated SIP size after compression. … The total E2E latency for call setup time is: GEO_UE-to-TN_UE = (2.976.7s) + (2.174.3s) + 1s + 2s = 8.14 ~16s

这部分内容非常珍贵，它为我们提供了一个在无前置条件流程下，GEO NTN呼叫建立时间的量化估算。其计算逻辑大致如下：

  • INVITE (带SDP Offer) 消息，经过SigComp压缩后约0.7KB。
  • 200 OK (带SDP Answer) 消息，经过SigComp压缩后约0.4KB。
  • 在1-3kbps的NB-IoT链路上，光传输这两个核心消息的时间，加上GEO链路固有的1.1秒PDB（分组延迟预算），就构成了主要的空口时延。
  • INVITE传输时延: (0.7 * 1024 * 8) / (1k~3k) + 1.1s ≈ 2.97s ~ 6.7s
  • 200 OK传输时延: (0.4 * 1024 * 8) / (1k~3k) + 1.1s ≈ 2.17s ~ 4.3s
  • 再加上IMS核心网内部处理时延（估算1s）和对端地面网络处理时延（估算2s）。
  • 总计端到端呼叫建立时间（从发INVITE到收到最终200 OK）约为 8到16秒。

“这个数字非常关键，” Alex强调，“它让我们对GEO NB-IoT上的语音呼叫建立时间有了一个数量级的概念。虽然十几秒的等待在今天看来很漫长，但在几年前，这在卫星电话上是不可想象的速度。这证明了‘无前置条件’+‘信令压缩’这条优化路径的巨大潜力。”

3. 流程剖析：6.13.2 Procedures - 两种B2BUA部署选项

本节提出了两种不同的B2BUA部署选项，并给出了详细的信令流程。

3.1 选项一：服务侧IMS网络作为B2BUA (Option 1: The IMS serving the GEO UE access acts as B2BUA)

  • 场景: 只要呼叫中有一方（主叫或被叫）是GEO UE，那么该GEO UE所在的服务网络中的AS就扮演B2BUA。

  • MO呼叫流程 (Figure 6.13.3.2-1 - IMS Call Setup-MO):

    1. UE → P-CSCF → S-CSCF: GEO UE（主叫）发送一个无前置条件的INVITE。
    2. S-CSCF → AS (B2BUA): S-CSCF根据iFC，将呼叫路由给AS。
    3. AS的“变形”操作:
      • AS终结这个无前置条件的INVITE。
      • AS向回程（被叫侧）发起一个全新的、带有前置条件的INVITE。它在SIP头中加入了Require: precondition等字段，并可能在SDP中加入a=curr:qos local none等前置条件属性。
      • 这个新的INVITE通过S-CSCF发往被叫方。
    4. 媒体协商: AS会作为一个“中间人”，分别与被叫方进行标准的、带前置条件的媒体协商，与主叫方进行简化的、无前置条件的媒体协商，并在两者之间完成媒体流的适配和可能的编解码转换。
    5. 最终，当收到被叫方的200 OK后，AS会向主叫GEO UE回一个简化的200 OK，完成呼叫。

  • MT呼叫流程 (Figure 6.13.3.2-2 - IMS Call Setup-MT): 流程相反，但逻辑类似。

    • 一个来自地面网络的、带前置条件的INVITE呼叫到达被叫GEO UE所在的S-CSCF。
    • S-CSCF将其路由给AS B2BUA。
    • AS终结这个呼叫，然后向GEO UE发起一个全新的、无前置条件的INVITE。

3.2 选项二：仅被叫侧SCC AS作为B2BUA (Option 2: Only the MT SCC AS acting as B2BUA for pre-condition)

  • 场景: 这种选项更为精细化和高效。它认为，无论主叫是什么网络，B2BUA的适配功能都应该由被叫侧的SCC AS来完成。
  • 优势:
    • 逻辑清晰: 适配的责任永远在“服务方”（被叫侧网络）。
    • 避免不必要的B2BUA: 如果主叫是GEO UE，被叫也是GEO UE，那么主叫侧网络就不需要做任何B2BUA转换，可以直接将无前置条件的INVITE一路传送到被叫侧的SCC AS，由它来做最终的判断。这减少了信令处理的节点和时延。

规范在6.13.3.3节中，用三张图（Figure 6.13.3.3-1/2/3）详细展示了在双方都是GEO、仅主叫是GEO、仅被叫是GEO这三种情况下，被叫侧SCC AS是如何智能地进行B2BUA适配的。其核心逻辑是：被叫侧SCC AS会检查主叫和被叫双方的接入类型，只有当一方需要前置条件，而另一方不需要时，它才会启动B2BUA流程；如果双方都不需要（都是GEO），则直接透传无前置条件的信令。

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

Solution 13的改动主要集中在IMS核心网。

  • UE:
    • 需要支持无前置条件的呼叫流程。
    • 需要支持GEO专用编解码器和可能的SigComp。
  • P-CSCF:
    • 影响较小，主要作为透明的代理转发信令。相比Solution #12，P-CSCF被“解放”了。
  • S-CSCF:
    • 需要支持基于iFC将呼叫路由到AS。这是其标准功能。
  • AS (Application Server) / SCC AS (改动最大):
    • 核心改动: 必须实现为一个功能强大的B2BUA，能够处理无前置条件与有前置条件之间的信令转换。
    • 需要具备媒体控制能力，能够指示MRF进行编解码转换。
  • HSS:
    • 需要能够存储用户的“GEO语音优化”能力，并据此生成iFC。
  • AGW/MRF:
    • 需要支持GEO专用的超低比特率编解码器，并具备与标准编解码器进行转码的能力。

5. 结论：专业的任务，交给专业的“人”

Alex最后对Solution 13进行了总结：“Solution 13为我们展示了一条与Solution 12殊途同归但实现路径截然不同的B2BUA优化路线。它主张将专业而复杂的适配任务，从‘网络大门’（P-CSCF）后移到‘核心办公室’（AS），让最合适的角色来承担这份重任。”

“它的优点在于：”

  • “职责清晰，架构解耦： P-CSCF回归其接入和安全代理的核心职责，而AS则专注于业务逻辑的适配。这使得网络架构更加清晰，符合功能分离的设计原则。”
  • “更强的业务灵活性： AS作为IMS网络中的‘瑞士军刀’，天然就适合进行各种复杂的业务处理。将B2BUA功能放在AS，未来可以更容易地与录音、会议、呼叫中心等其他增值业务进行集成。”
  • “部署更灵活： 运营商可以只为需要支持卫星业务的用户部署这个专门的AS，而无需升级全网所有的P-CSCF。”

“然而，这种方案也引入了新的考量：”

  • “增加了核心网的信令路径和时延： 呼叫信令需要额外经过一次AS，这在理论上会增加核心网内部的处理时延和信令跳数。”
  • “对AS的性能要求高： AS B2BUA不仅要处理信令，还要控制媒体，它将成为通话路径上的一个关键节点，其性能和可靠性至关重要。”

“总而言之，Solution 12和Solution 13代表了B2BUA部署位置的两种不同哲学——‘前置处理’ vs ‘后置处理’。选择哪一种，更多地取决于运营商对其网络架构演进的整体规划。但它们共同证明了，通过B2BUA在应用层进行智能适配，是解决GEO卫星接入下IMS信令效率问题的一条非常有效和可行的道路。”

FAQ

Q1：Solution 13与Solution 12的核心区别是什么？ A1：核心区别在于扮演B2BUA角色的网络实体不同。在Solution 12中，B2BUA是位于网络入口的P-CSCF；而在Solution 13中，B2BUA是位于IMS核心网内部的应用服务器（AS）或SCC AS。这个角色的转移，导致了网络信令路径、各网元职责划分以及部署策略上的根本不同。

Q2：什么是iFC（Initial Filter Criteria）？它在这个方案中是如何工作的？ A2：iFC是IMS核心网中的一套智能路由规则，存储在HSS中，并在用户注册时下发给S-CSCF。它告诉S-CSCF，当处理某个用户的呼叫时，如果满足某些条件（如主叫/被叫号码、SIP消息类型等），就应该将该呼叫“触发”或“转发”给一个或多个指定的应用服务器（AS）。在这个方案中，HSS会为GEO卫星用户生成特殊的iFC，其触发条件就是“该用户正在发起或接收一个呼叫”。当S-CSCF匹配到这条iFC时，就会将呼叫信令转发给方案中定义的那个扮演B2BUA角色的AS。

Q3：为什么这个方案需要进行编解码转换（Transcoding）？ A3：因为GEO卫星链路的带宽极其有限（NB-IoT只有几十kbps），卫星终端（如“地理链接一号”）可能会使用一种经过特殊优化的超低比特率编解码器（ULBC），以在极低的带宽下提供可懂的语音。然而，地面上的普通手机和固话网络并不支持这种特殊的编解码器，它们使用的是AMR、EVS等标准编解码器。因此，当卫星用户和地面用户通话时，必须在网络中有一个节点（通常是MRF，由AS控制）进行实时的“翻译”，将ULBC编码的语音流转换为AMR，反之亦然，这个过程就是编解码转换。

Q4：方案中对呼叫建立时间的估算（8-16秒）是否意味着卫星电话的体验很差？ A4：这个时间需要客观看待。首先，这个估算是在最差的NB-IoT（1-3kbps）和最高的GEO时延下做出的，可以说是“性能下限”。其次，这个时间是技术上的信令交互时间，不完全等同于用户的实际感受。例如，网络可以在收到183 Session Progress后就立刻给主叫播放回铃音，此时用户已经听到了等待音，虽然技术上呼叫还在建立中。最重要的是，在没有地面信号的极端环境下，能够以十几秒的时间建立起一条救命的语音通道，这本身就是技术的巨大进步。相比完全失联，这是一个从0到1的飞跃。

Q5：Option 2中提到的“仅被叫侧SCC AS作为B2BUA”相比Option 1有什么优势？ A5：Option 2（仅被叫侧B2BUA）的主要优势在于更高效和更智能。在Option 1中，只要有GEO用户参与，无论主叫被叫，其所在网络的AS都会启动B2BUA，这可能导致不必要的转换。例如，当一个GEO用户呼叫另一个GEO用户时，主叫侧AS会把“无前置条件”的呼叫转换成“有前置条件”的，发到核心网，然后被叫侧AS又要把它转换回“无前置条件”的，造成了冗余处理。而在Option 2中，适配的责任始终由被叫侧的SCC AS承担。它会先检查双方的能力，只有在确实存在“不匹配”（如一方需要前置条件，另一方不需要）时，才启动B2BUA。如果双方能力匹配（如都是GEO用户），它就直接透传信令，避免了不必要的转换，从而降低了端到端的信令时延。

关系图谱