51学通信

深度解析 3GPP TR 23.700-19：6.14 Solution #14 针对VoGoN的呼叫建立流程优化

19分钟阅读

好的，我们继续进行深度拆解。这是本系列的第十九篇文章，将聚焦于又一个针对呼叫建立流程进行优化的方案——Solution #14。

深度解析 3GPP TR 23.700-19：6.14 Solution #14: 针对VoGoN的呼叫建立流程优化

本文技术原理深度参考了3GPP TR 23.700-19 V1.0.0 (2025-09) Release 20规范。在我们探讨了多种通过B2BUA架构禁用前置条件（Precondition）来优化呼叫流程的方案之后，本文将深入解读 6.14 Solution #14。这个方案继承了“无前置条件”的核心思想，但引入了一个新的概念——VoGoN (Voice over GEO over NB-IoT)，并围绕终端是否支持VoGoN这一能力，设计了一套更为精细和智能的B2BUA决策机制。它试图在标准流程和简化流程之间，找到一个更具适应性的“动态切换阀”。

引言：从“一刀切”到“看人下菜”

在之前的Solution 12和13中，优化的触发条件相对“粗放”：只要识别到用户是通过GEO NB-IoT接入的，网络（无论是P-CSCF还是AS）就启动B2BUA，执行“无前置条件”的简化流程。这种“一刀切”的模式虽然有效，但缺乏灵活性。

Alex的团队在讨论时，一位年轻的工程师小李提出了一个场景：“如果Evelyn博士的‘地理链接一号’是最新款，它的软件已经升级，能够支持一种更快的、基于180 Ringing（而不是183 Progress）携带SDP的简化呼叫流程。但她呼叫的对端，可能是一个老旧的地面终端，它只认识标准的、基于183的复杂流程。反过来，如果一个地面终端呼叫Evelyn博士，它发起的也是标准流程。我们的网络能不能更智能一些，根据通话双方的‘能力’，来动态决定是走端到端的简化流程，还是只在卫星这一侧进行简化？”

这个问题，正是Solution 14试图回答的。它不再是简单地看接入类型，而是进一步看终端是否具备一种被称为VoGoN的“新技能”。

This solution proposes to use as baseline the short call setup procedure without preconditions… VoGoN (Voice over GEO over NB-IoT)

方案的核心，就是将一种更激进的、基于180 Ringing (SDP answer)的简化呼叫流程（在TS 23.228 5.7a节中定义）作为VoGoN终端的默认行为，并通过P-CSCF B2BUA来处理与非VoGoN终端的互通问题。

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

本节的一句话原则，清晰地概括了Solution 14的设计哲学。

This solution proposes to use as baseline the short call setup procedure without preconditions, but introduces safeguards to ensure the media starts to flow only when bearer is set up by the UE connecting to the network using 3GPP-NB-IoT(GEO). The solution also takes into account whether one of the parties does not support the proposed simplified call setup procedure.

Alex为团队解读这段话的深层含义：

  • “use as baseline the short call setup procedure without preconditions”: 明确了方案的“理想模型”是一种比之前方案更激进的简化流程。这个流程是 INVITE (SDP offer) -> 180 Ringing (SDP answer) -> PRACK -> 200 OK for PRACK...。它将SDP Answer的载体从183 Progress消息提前到了180 Ringing消息，理论上可以更快地完成媒体协商。
  • “introduces safeguards to ensure the media starts to flow only when bearer is set up”: 引入了“安全保障机制”。这是一个关键点。因为简化流程可能会导致媒体协商完成得非常早，但此时底层的无线承载（bearer）可能还没有建立好。方案必须有一种机制，确保媒体流（RTP包）不会在承载就绪前就开始发送，避免数据丢失。
  • “takes into account whether one of the parties does not support”: 明确了方案的适应性。它考虑到了通话双方能力不匹配的情况（即一方支持VoGoN，另一方不支持），并为此设计了互通方案。

“所以，Solution 14的设计思路，” Alex总结道，“就像是为我们的通信系统安装了一个‘智能变速箱’。如果通话双方都是‘新式赛车’（都支持VoGoN），那么系统就挂上‘极速档’，走端到端的超简化流程。如果一方是‘赛车’，另一方是‘老爷车’（不支持VoGoN），那么系统就在‘赛车’这一侧的‘入口’（P-CSCF）启动一个‘变速适配器’（B2BUA），确保‘赛车’在自己这边跑得飞快，同时又能与‘老爷车’平稳对接。”

2. 方案详述：6.14.1 Description - VoGoN能力的引入

本节详细阐述了VoGoN的概念以及方案需要处理的两种核心场景。

It is assumed that a UE capable of supporting IMS voice over GEO over NB-IoT GEO as IP-CAN (VoGoN) can support this simplified call setup procedure as default…

  • VoGoN能力的定义: 支持VoGoN的UE，默认就能理解和使用180 Ringing(SDP)这种简化流程。当它作为主叫时，它发送的INVITE将不包含Precondition头；当它作为被叫时，它能够直接在180 Ringing消息中返回SDP Answer。

This solution examines two scenarios:

  • Case 1: UE A supports VoGoN and is accessing network via 3GPP-NB-IoT(GEO) while UE B does not support VoGoN;
  • Case 2: UE B supports VoGoN and is accessing network via 3GPP-NB-IoT(GEO) while UE A does not support VoGoN.

方案的核心，就是分析和解决这两种能力不匹配的场景。

…this solution proposes that the P-CSCF A acts as a B2B UA to perform simplified call setup procedure towards the UE A and normal call setup with the UE B.

  • 解决方案的核心: 在能力不匹配时，由卫星侧用户的P-CSCF扮演B2BUA，进行协议转换。这与Solution 12的思路一致，但触发B2BUA的条件更精细。

3. 流程剖析：6.14.2 Procedures - “智能变速箱”的运作

3.1 案例一：主叫是VoGoN卫星终端 (UE A)，被叫是普通终端 (UE B)

6.14.2.1 Case 1: UE A Supports VoGoN and is Accessing the Network via 3GPP-NB-IoT(GEO)

这是P-CSCF A必须启动B2BUA的场景。规范的 “Figure 6.14.2.1-1: Call procedure for Case1” 详细描绘了这一流程。

  1. UE A → P-CSCF A: Evelyn博士的“地理链接一号”（支持VoGoN）发起呼叫，发送一个不带precondition支持的INVITE。
  2. P-CSCF A (B2BUA) → IMS Core:
    • P-CSCF A识别出这是一个VoGoN UE。它启动B2BUA模式。
    • 它修改收到的INVITE，添加上precondition支持的头域，将其变成一个标准的INVITE。
    • 这个标准INVITE被发往被叫方UE B。
  3. UE B → P-CSCF A (B2BUA): 普通终端UE B不认识180(SDP)流程，它按照标准流程，返回一个183 Progress (SDP Answer)。
  4. P-CSCF A (B2BUA) → UE A:
    • P-CSCF A收到183后，不会将其直接转发给UE A。
    • 它会根据收到的SDP Answer，生成一个180 Ringing (SDP Answer)消息，发给UE A。
  5. 后续流程:
    • P-CSCF A作为中间人，分别与UE A进行PRACK(for 180)的交互，与UE B进行PRACK(for 183)的交互，并处理后续的UPDATE等标准流程。

通过这种方式，P-CSCF A这个“变速适配器”成功地让UE A（赛车）在自己这边跑着“极速档”（180(SDP)流程），同时又让UE B（老爷车）在另一边跑着“标准档”（183(SDP)流程）。

Editor’s note: It is for further study how P-CSCF B determines that UE A is accessing the network via 3GPP-NB-IoT(GEO)

这个编辑注提出了一个重要问题：被叫侧的P-CSCF B如何知道主叫A是卫星用户？这对于一些高级业务（如正确的计费、CAT等）很重要。这通常需要P-CSCF A在转发的INVITE中，通过P-Access-Network-Info头域来传递这一信息。

3.2 案例二：主叫是普通终端 (UE A)，被叫是VoGoN卫星终端 (UE B)

6.14.2.2 Case2: UE A does not support VoGoN; UE B supports VoGoN and is accessing network via 3GPP-NB-IoT(GEO)

这是可以实现端到端简化流程的理想场景。规范的 “Figure 6.14.2.2-1: Call procedure for Case2” 描绘了这一流程。

  1. UE A → UE B: 主叫UE A发起一个标准的INVITE（可能带precondition）。
  2. UE B (VoGoN) 响应: 被叫UE B（地理链接一号）是一个VoGoN终端，它能够生成并返回一个180 Ringing (SDP Answer)。
  3. 端到端简化流程: 接下来，整个流程就可以按照 180(SDP) -> PRACK -> 200 OK 这种简化的路径端到端地进行，无需任何B2BUA的介入。

In this case the simplified call setup procedure can be performed end to end because UE B is capable of sending 180 Ringing with SDP answer.

这个案例完美地展示了VoGoN能力的价值：当通话的“瓶颈”侧（被叫）具备了简化流程的能力时，整个通话的效率都能得到提升。

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

Solution 14的改动是精细的，主要体现在UE和P-CSCF的智能决策上。

  • Originating UE (主叫终端):
    • 如果支持VoGoN，发起呼叫时不应包含Precondition支持。
    • 需要能够处理180 Ringing中携带的SDP Answer，并据此发送PRACK。
  • Terminating UE (被叫终端):
    • 核心能力: 如果支持VoGoN，在收到INVITE后，需要能够生成并发送**180 Ringing (SDP Answer)**。
  • Originating IMS (主叫侧网络，主要是P-CSCF):
    • 需要能够在转发的INVITE中，向对端网络指示主叫UE的接入类型是3GPP-NB-IoT(GEO)。
    • 核心逻辑: 在Case 1场景下，需要扮演B2BUA，将在183中收到的SDP Answer，“翻译”成在180 Ringing中的SDP Answer发给主叫UE。

5. 结论：从“一刀切”到“智能化”的演进

Alex最后对Solution 14进行了高度评价：“Solution 14是B2BUA优化思想的一次重要演进。它不再是‘一刀切’地对所有卫星呼叫都进行协议转换，而是引入了VoGoN这个‘能力标签’，实现了一种‘看人下菜’的智能化适配。”

“它的优点在于其灵活性和高效性：”

  • “最大化端到端优化： 当通话双方（或至少被叫方）都支持VoGoN时，方案能够实现真正的端到端简化流程，获得最佳的呼叫建立性能。”
  • “优雅的向后兼容： 当一方不支持VoGoN时，方案又能通过P-CSCF B2BUA进行平滑的协议转换，保证了与存量终端的互通性。”

“其挑战则在于对终端和网络智能性的要求：”

  • “终端需要升级： UE需要真正实现180 Ringing(SDP)这一高级功能，这对终端协议栈的实现提出了要求。”
  • “P-CSCF的决策逻辑更复杂： P-CSCF不再是简单地根据接入类型来决定是否启动B2BUA，它还需要在呼叫过程中，根据对端返回的消息类型（是180还是183）来动态决策其行为，这对P-CSCF的状态机设计提出了更高的要求。”

“总而言之，Solution 14为我们展示了通往高效卫星语音通信的演进路径：从最初的简单禁用Precondition，到引入更智能的、基于能力的动态适配。它体现了3GPP在标准制定中，不断追求性能、兼容性和灵活性的平衡。这个方案提出的‘按需启动B2BUA’的思想，极具借鉴意义。”

FAQ

Q1：Solution 14的核心思想是什么？它与Solution 13有何不同？ A1：Solution 14的核心思想是引入VoGoN能力，并基于通话双方是否支持VoGoN，来动态决定是采用端到端的简化呼叫流程，还是由P-CSCF作为B2BUA进行协议转换。它与Solution 13的主要不同在于B2BUA的触发机制：Solution 13更倾向于只要是卫星接入就“一刀切”地启动B2BUA；而Solution 14则更加“智能”，它会先尝试进行端到端简化流程，只有在发现对端不支持（能力不匹配）时，才由卫星侧的P-CSCF启动B2BUA来进行适配。

Q2：什么是VoGoN (Voice over GEO over NB-IoT)？支持VoGoN的终端有什么特殊能力？ A2：VoGoN是本方案为了描述一种具备特定能力的UE而提出的一个概念标签。支持VoGoN的终端，其最核心的特殊能力是，它支持在TS 23.228 5.7a节中定义的“简化呼叫建立流程”，具体表现为：

  • 作为主叫时，它发出的INVITE不要求对端支持precondition。
  • 作为被叫时，它能够在**180 Ringing**消息中携带SDP Answer，而不是像标准流程那样在183 Session Progress中携带。

Q3：为什么在180 Ringing中携带SDP比在183 Progress中携带能更快地建立呼叫？ A3：180 Ringing通常意味着被叫终端已经开始向用户振铃，是呼叫流程中一个比较靠后的状态。而183 Session Progress则是一个更早期的临时响应，表示呼叫正在处理中。将SDP Answer提前到180 Ringing中，可以与振铃状态同步，省去了183以及后续可能围绕183进行的PRACK/200 OK交互，从而减少了信令的往返次数。这在GEO高时延环境下，每一次往返的节省都意味着超过半秒的时间优化。

Q4：方案中提到的“安全保障机制 (safeguards)”指的是什么？为什么需要它？ A4：“安全保障机制”是指必须确保底层的EPS承载（特别是用于媒体的专用承载）在媒体流（RTP包）开始传输之前已经完全建立就绪。需要它的原因是，180(SDP)简化流程会使得SIP层的媒体协商完成得非常早，此时IMS应用层可能已经认为可以开始发送媒体了。但底层的承载建立流程可能还没有跑完（尤其是在需要动态建立承载的方案中）。如果没有一个“安全阀”机制（例如，应用层需要等待来自底层“承载已就绪”的明确指示），就可能出现应用层过早发送RTP包，而底层链路不通，导致通话初期的语音包丢失，用户体验下降。

Q5：在Case 1中，P-CSCF A是如何知道UE B不支持VoGoN，从而决定启动B2BUA的？ A5：P-CSCF A是通过观察来自UE B的响应消息类型来做出判断的。P-CSCF A向UE B转发了一个标准的（带有precondition的）INVITE后，它会等待响应。如果UE B返回的是183 Progress (SDP)，P-CSCF A就知道UE B走的是标准流程，不支持VoGoN的简化流程。此时，P-CSCF A就必须启动B2BUA，将这个183消息“翻译”成UE A所期望的180 Ringing (SDP)消息。反之，如果UE B直接返回了180 Ringing (SDP)，P-CSCF A就知道双方能力匹配，可以直接透传该消息，无需启动B2BUA。

关系图谱