51学通信

深度解析 3GPP TS 23.380：5.3 & 5.4 P-CSCF故障恢复 (Part 2 - UE自救与HSS的远程指挥)

22分钟阅读

深度解析 3GPP TS 23.380：5.3 & 5.4 P-CSCF故障恢复 (Part 2 - UE自救与HSS的远程指挥)

本文技术原理深度参考了3GPP TS 23.380 V18.1.0 (2024-09) Release 18规范中，关于“5.3 Network recovery information flow – UE uses keep alive mechanism”和“5.4 HSS-based P-CSCF restoration for 3GPP access”的核心章节。本文是P-CSCF故障恢复系列的第二部分，将探讨两种更高级、更智能的恢复机制，揭示当网络监控失效时，UE如何“自救”，以及IMS核心网如何通过HSS进行“远程指挥”，实现跨网元的精妙协同。

1. 故事新篇章：当网络的“哨兵”失灵

在上一篇文章中，我们的主角小张在高铁上遭遇P-CSCF故障，但幸运的是，网络的“哨兵”——PGW（PDN网关）及时发现了问题，并主动通过PCO更新，为她的手机指引了新的IMS“门户”，快速恢复了业务。

然而，凡事皆有例外。如果PGW的监控机制因为配置问题、网络抖动或自身负荷过高而未能及时发现P-CSCF的故障呢？或者，在某些网络架构中，PGW根本就不承担监控P-CSCF的职责。在这些情况下，小张的手机将会“坐以待毙”，IMS业务将陷入长时间的中断。

为了应对这种“哨兵失灵”的场景，3GPP规范演进出了更加丰富的恢复手段。今天的解读，我们将面临两种全新的挑战：

  1. UE的自我觉醒：在网络毫无反应的情况下，小张的手机能否依靠自身的力量，发现“门户”已塌，并主动寻找出路？
  2. 核心网的终极手段：当一个重要的来电即将因为P-CSCF故障而失败时，IMS的“最高司令部”——HSS，能否在千钧一发之际，远程指挥接入网（MME），强制小张的手机“重启连接”，从而挽救这次关键通信？

这两种场景，分别对应了本篇要深度解析的UE Keep-alive机制和HSS-based恢复机制。

2. UE的“自救”：心跳检测与主动重连 (解析 5.3 Network recovery information flow – UE uses keep alive mechanism)

这个机制的哲学思想发生了根本性的转变：与其被动等待网络的救援，不如自己主动监控“门户”的健康。责任的主体，从网络侧的PGW，转移到了用户侧的UE（终端）。

2.1 机制核心思想

UE在成功注册到IMS网络后，并不会静默等待。它会像一个尽职的保安，定期向其所连接的P-CSCF发送“心跳”探测包，以确认P-CSCF是否“还活着”。一旦“心跳”无应答，UE就立即判定P-CSCF故障，并主动发起恢复流程。

  1. If registration is successful, the UE monitors the P-CSCF health according to IETF RFC 6223
  2. When a failure is detected, the UE acquires new P-CSCF addresses (if needed) and performs an initial registration.

规范的描述简洁而清晰，它直接引用了IETF RFC 6223《Indication of Support for Keep-Alive》作为该机制的技术基础。这个RFC详细定义了SIP实体间如何通过OPTIONS请求等方式进行心跳保活。

2.2 恢复流程深度解析

我们通过解析“Figure 5.3a: P-CSCF failure detected by UE”这张流程图，来理解UE的“自救”过程。

  1. 步骤1 (初始注册)：小张的手机开机后，通过PCO或DHCP获取P-CSCF地址列表，选择pcscf1.operator.com并发起SIP REGISTER请求。
  2. 步骤2 (注册成功，启动监控)：注册成功，收到200 OK。从这一刻起，手机的IMS客户端启动了Keep-alive监控。它会按照预设的频率（例如每60秒），向pcscf1.operator.com发送一个SIP OPTIONS请求（俗称“探活包”）。只要P-CSCF-1正常，就会回复一个200 OK。
  3. 步骤3 (故障发现与自救行动)：
    • 故障发现：突然，手机连续发送了几个OPTIONS请求，都石沉大海，或者收到了网络错误的响应。手机的IMS客户端判定：P-CSCF-1已经Failure（故障）。
    • 自救行动：此时，UE会立即执行两个动作：
      1. 获取新地址：它会尝试重新获取一份P-CSCF地址列表。获取方式取决于最初的方式，如果是PCO，它可能会触发一次承载修改来请求新的PCO；如果是DHCP，它会重新发起DHCP请求。在许多实现中，UE可能还会使用其在初始注册时获得的P-CSCF地址列表中的备用地址。
      2. 发起初始注册：从新的地址列表中选择一个可用的P-CSCF（如pcscf2.operator.com），并发起一次全新的IMS初始注册。

结果：在小张的高铁旅途中，即使PGW的监控系统“打了个盹”，她的手机也能在几分钟内通过自己的心跳机制发现P-CSCF的异常，并悄无声息地在后台完成了向新P-CSCF的切换和重注册。对她而言，可能只是某一次尝试拨打电话时短暂失败，但很快业务就恢复了正常。这种“自救”能力，极大地提升了IMS业务的鲁棒性。

3. HSS的“远程指挥”：为拯救来电而发动的精妙协同 (解析 5.4 HSS-based P-CSCF restoration for 3GPP access)

UE Keep-alive机制解决了UE在发起业务前发现P-CSCF故障的问题。但如果P-CSCF在一个非常微妙的时刻——恰好有一个重要来电正在路上时——突然发生故障，UE的Keep-alive可能还没来得及触发，这个来电就会失败。

HSS-based机制，正是为了应对这种由被叫流程触发的P-CSCF故障恢复而设计的终极预案。它是一场由IMS核心网的“最高司令部”HSS发起，跨越核心网（S-CSCF）、用户数据库（HSS）和接入网（MME/SGSN）的“三军协同作战”。

3.1 机制运行的前提与时机 (5.4.1 Introduction)

When supported, this mechanism shall be executed when a terminating request cannot be serviced due to a P-CSCF failure, as long as there are no other registration flows for this terminating UE using an available P-CSCF.

这个机制的触发时机非常苛刻：

  1. 必须是被叫请求：一个发往用户的呼叫（terminating request）正在处理中。
  2. 必须是P-CSCF故障导致：呼叫失败的直接原因是S-CSCF无法联系到用户注册时所用的P-CSCF。
  3. 必须是唯一的注册路径：如果用户有多台设备通过不同的、健康的P-CSCF注册，S-CSCF会选择其他路径，不会触发此机制。只有当通往该用户的所有路径都因为这个P-CSCF故障而中断时，此机制才会启动。

3.2 恢复流程深度解析 (5.4.2 Description & Figure 5.4.2.1-1)

这是整个规范中最精妙、最复杂的流程之一。让我们跟随小张的同事打给她的那个关键电话，一步步拆解这场“协同作战”。

故事背景：小张的手机通过pcscf1.operator.com注册在IMS网络。就在她的同事发起VoNR呼叫的瞬间，pcscf1.operator.com突发故障。

  1. 步骤1-3 (S-CSCF发现前线失联)：

    • 呼叫请求（SIP INVITE）到达S-CSCF。
    • S-CSCF从内存中查到，小张是通过P-CSCF-1注册的，于是它将INVITE转发给P-CSCF-1。
    • 请求超时，S-CSCF在重试几次后，确认P-CSCF-1不可达。

  2. 步骤4 (S-CSCF向HSS“求援”):

  1. The S-CSCF shall … unregister this Public User Identity by sending a Cx SAR to the HSS, including a P-CSCF Restoration indication. S-CSCF没有直接拒绝呼叫。它做出了一个关键决策：向HSS发送一个SAR（Server-Assignment-Request）消息。这个消息有两个目的： 1. 临时注销用户：它会请求将小张的公共身份暂时设置为“未注册”。这是为了防止在恢复期间，更多的来电涌向这条已知的失败路径。 2. 激活终极预案：它在这个SAR消息中，加入了一个至关重要的信令——“P-CSCF Restoration indication”（P-CSCF恢复指示）。这就像是前线指挥官（S-CSCF）向最高司令部（HSS）发出的一个加密电报：“目标P-CSCF失联，请求启动远程强制重连协议！”
  1. 步骤5 (HSS的远程指挥):
  1. The HSS shall … send a P-CSCF restoration indication to the supporting serving node(s) where the IMSI associated to the received Private Identity is registered, i.e. SGSN and/or MME… HSS收到这个带有特殊指示的请求后，立即采取行动： * 它查询数据库，得知小张当前正由哪个MME（Mobility Management Entity）提供服务。 * 它通过S6a接口，向该MME发送一个IDR（Insert-Subscriber-Data Request）消息，这个消息中也携带了那个“P-CSCF Restoration indication”。这相当于HSS向MME下达了一个指令：“你负责的那个用户（小张），她的IMS连接需要被强制重置”。

  1. 步骤6 (S-CSCF安抚主叫方)： 在等待恢复的同时，S-CSCF会给主叫方返回一个临时的SIP错误响应，例如480 Temporarily Unavailable，并可能附加一个Retry-After头域，暗示主叫方稍后可以重试。

  2. 步骤7 (MME执行强制重连):

  1. …the MME/SGSN … shall release the UE’s IMS PDN connection towards the UE by initiating a PDN disconnection procedure with the NAS cause “reactivation requested”. 这是整个流程在接入网侧的执行核心。MME收到HSS的指令后，它会发起一个针对小张手机的PDN连接断开流程。但这个断开流程非常特殊，它携带的NAS（Non-Access Stratum）原因是“reactivation requested”（请求重激活）。 * 深度解析：这个原因码不是一个简单的“断线”通知。它是一个明确的指令，告诉小张手机的底层协议栈（Modem）：“你的IMS专用数据通道（IMS PDN Connection）已被网络侧强制拆除，请你立即重新建立一个同类型的通道。”
  1. 步骤8 (UE的响应与恢复):
  1. As a result of the release of the IMS PDN connection, the UE shall activate the IMS PDN connection, select an available P-CSCF and perform a new initial IMS registration… 小张的手机收到这个NAS指令后，会立即： 1. 重新建立IMS PDN连接：这个过程会触发UE重新进行P-CSCF发现（通过PCO或DHCP）。由于网络已经知道P-CSCF-1故障，PGW此时会在PCO中提供一个不含P-CSCF-1的、全新的地址列表。 2. 选择新P-CSCF并注册：手机从新列表中选择pcscf2.operator.com，并发起一次全新的IMS初始注册。

最终结果：小张的同事在电话提示暂时无法接通后，稍等了片刻，再次拨打了她的号码。这一次，因为小张的手机已经在后台被网络“指挥”着切换到了健康的P-CSCF-2并完成了重注册，所以呼叫顺利接通。一场可能因P-CSCF故障而错失的关键通话，被这套精妙的跨网元协同机制成功挽救。

4. 机制对比与演进思考

对比本篇讨论的两种机制，我们可以看到IMS高可用性设计的演进思路：

  • UE Keep-alive (5.3)：代表了终端智能化的趋势。它将故障检测的责任下放到离用户最近的地方，实现了更快速、更主动的故障发现，尤其适用于UE发起业务的场景。它的优点是及时性，缺点是会增加终端的功耗和信令开销。
  • HSS-based (5.4)：代表了网络协同与编排的极致。它是一个被动触发的、但极为强大的“最后防线”，专门用于挽救即将失败的被叫业务。它展示了IMS核心网如何与移动接入网（EPC）深度联动，实现跨域的故障处理。它的优点是强大而可靠，缺点是流程复杂、时延长，且仅适用于被叫场景。

这两种机制与前一篇讨论的PGW监控机制（5.1, 5.2）并非互相替代，而是一个互为补充、层层递进的防御体系。一个健壮的IMS网络，可能会同时部署多种机制，以应对不同场景下的P-CSCF故障，确保用户业务的连续性。

5. 总结

本文通过解析UE Keep-alive和HSS-based两种高级P-CSCF恢复机制，我们再次领略了3GPP规范设计的深度与智慧。

  • UE Keep-alive机制，赋予了终端“自救”的能力，通过主动的心跳检测，将故障发现的权力下放，实现了快速响应。
  • HSS-based机制，则上演了一场由HSS作为“最高指挥官”的远程协同作战。它通过向MME下达指令，以一种“外科手术式”的方式，强制UE重置其IMS连接，从而在被叫失败的边缘挽救了业务。

从PGW的集中监控，到UE的主动探测，再到HSS的远程指挥，P-CSCF的恢复机制构成了一个立体的、多维度的保障网络。正是这些“看不见”的复杂流程，在默默守护着我们每一次清晰流畅的VoLTE/VoNR通话。在下一篇中，我们将继续探索PCRF、5G核心网（5GC）等更现代的元素是如何参与到这场“门户保卫战”中的。

FAQ环节

Q1：UE Keep-alive机制会不会很耗电？运营商会普遍开启这个功能吗？ A1：是的，Keep-alive机制确实会增加终端的功耗，因为它需要定期唤醒无线模块来发送信令。因此，心跳的频率是一个关键的权衡点：频率太高，耗电快；频率太低，故障发现慢。运营商和终端制造商通常会根据网络状况和设备能力，选择一个折中的值（例如几分钟一次）。是否普遍开启取决于运营商的策略，一些对业务质量要求极高的运营商可能会推荐或默认开启，而另一些则可能将其作为可选项，由用户或特定业务（如企业级应用）触发。

Q2：HSS-based机制流程那么长，等它恢复完，主叫方是不是早就挂机了？ A2：确实，HSS-based机制的端到端恢复时延可能达到数秒甚至更长。但它的设计目标不是“无缝恢复”，而是“可恢复性”。

  1. S-CSCF会向主叫方返回一个带Retry-After头域的临时失败响应，这会提示对端的网络或终端“请稍后重试”，而不是立即彻底失败。
  2. 很多智能终端或网络应用在收到这类临时失败码后，会自动在几秒后发起重呼。 所以，虽然第一次呼叫尝试失败了，但这个机制为第二次或第三次尝试成功创造了条件。对于一次重要的来电，相比于永远无法接通，这种“稍后可达”的体验是完全可以接受的。

Q3：在HSS-based流程中，为什么不由HSS直接通知UE P-CSCF故障了，而要绕道MME去断开PDN连接？ A3：因为HSS和UE之间没有直接的信令通路。HSS是核心网深处的控制面网元，而UE位于网络的边缘。MME/SGSN是移动性管理和会话管理的核心，是核心网与UE之间NAS（非接入层）信令的“法定”管道。HSS指挥MME，MME再通过成熟的NAS信令与UE通信，这是最符合3GPP整体架构设计、最可靠的路径。直接断开并请求重建PDN连接，是一种釜底抽薪但极为有效的手段，因为它强制UE必须重新走一遍包括P-CSCF发现在内的完整接入流程，从而保证了状态的彻底刷新。

Q4：如果S-CSCF检测到P-CSCF故障，但它发现HSS或MME不支持HSS-based恢复机制，会发生什么？ A4：这是一个很好的问题，体现了网元能力协商的重要性。在步骤5中，MME/SGSN在向HSS注册时（Update Location Request），就会上报自己是否支持P-CSCF Restoration这个特性。HSS会记录下来。当S-CSCF向HSS求援时，如果HSS发现对应的MME不支持该功能，它会向S-CSCF返回一个错误响应。S-CSCF收到错误后，就知道这个“终极预案”无法执行，它将放弃恢复，并向主叫方返回一个最终的失败响应（如487 Request Terminated），本次呼叫彻底失败。

Q5：UE Keep-alive和HSS-based这两种机制，哪一个在实际网络中更重要？ A5：两者都非常重要，但解决的问题域不同。

  • UE Keep-alive 更侧重于保障主叫业务和维持注册状态的有效性。它能确保UE在发起呼叫前，其IMS注册是健康的。这对于提升用户发起呼叫的成功率至关重要。
  • HSS-based 更侧重于保障被叫业务的送达率。它是在被动接收呼叫时，发现路径不通后的一种“抢救”措施。 可以说，前者是“日常保健”，后者是“急诊抢救”，在一个完善的IMS网络中，两者都不可或缺。

关系图谱