51学通信

深度解析 3GPP TS 23.380：5.1 & 5.2 P-CSCF故障恢复 (Part 1 - 4G核心网的应对之道)

23分钟阅读

深度解析 3GPP TS 23.380：5.1 & 5.2 P-CSCF故障恢复 (Part 1 - 4G核心网的应对之道)

本文技术原理深度参考了3GPP TS 23.380 V18.1.0 (2024-09) Release 18规范中，关于“5.1 Update PDP context/Bearer at P-CSCF failure”和“5.2 Inform UE about P-CSCF failure”的核心章节。本文是P-CSCF故障恢复系列的第一部分，将聚焦于4G/EPC时代，网络如何主动应对P-CSCF故障，确保用户业务的快速恢复。

0. 前言：从“大脑”到“门户”的挑战

在前两篇文章中，我们深入探讨了IMS的“会话大脑”——S-CSCF发生故障时的恢复机制。S-CSCF的故障影响的是会话状态和路由逻辑，其恢复依赖于HSS这一中央数据备份。然而，IMS网络中还存在另一个同样至关重要的角色——P-CSCF（Proxy-CSCF）。

如果说S-CSCF是处理业务的“大脑”，那么P-CSCF就是用户接入IMS网络的“门户”和“安检员”。所有用户的SIP信令都必须经过P-CSCF，它负责用户的认证、安全、消息压缩以及作为IMS网络的出入口。一旦这个“门户”坍塌，用户将彻底与IMS世界失联。

因此，P-CSCF的故障恢复机制，与S-CSCF的恢复机制在理念和实现上都有着本质的不同。它不再是核心网内部的数据重建，而是边缘网络如何快速为用户指引一个新的、可用的“门户”。

0.1 故事场景：高铁上的关键时刻

我们的主角，商务精英小张，正在一列高速行驶的列车上。她正在通过她的5G手机，与公司“智行一号”自动驾驶项目组进行一次至关重要的VoNR视频会议。屏幕上，实时回传的车辆测试数据和项目经理的面容都清晰可见。

突然，视频画面卡死，声音中断，通话在几秒后异常掉线。小张看了一眼手机，代表高清语音的VoNR图标依然亮着，但她已经无法回拨电话。她所连接的IMS网络的“门户”——P-CSCF，刚刚因为某个机房的瞬时网络中断而发生了服务中断。

对于身处高速移动环境、且即将进行关键汇报的小张来说，通信的快速恢复至关重要。现在，让我们潜入网络深处，看看3GPP规范是如何为她解决这个棘手问题的。

1. 恢复机制总览 (Chapter 5.0 General)

TS 23.380的第五章，全面阐述了P-CSCF服务中断后的恢复流程。与S-CSCF不同，P-CSCF通常是无状态的（或轻状态的），它不保存复杂的会话上下文。因此，它的恢复核心思想不是“数据重建”，而是“快速重选与重定向”。

本章节涵盖了多种机制，包括4G/EPC时代的PCO更新、DHCP通知机制，以及后续演进出的HSS/PCRF/UDM/PCF参与的更复杂的信令流程，还有UE自身通过Keep-alive机制检测故障等。

本文作为系列的第一部分，我们首先聚焦在4G/EPC网络架构下，由网络侧主动发现故障并通知UE的两种经典机制：

  • 5.1 通过PCO更新PDP上下文/承载
  • 5.2 通过DHCP通知UE P-CSCF故障

这两种机制，是理解P-CSCF恢复演进的基石。

2. PCO机制：网络主动为UE“更新门锁” (解析 5.1 Update PDP context/Bearer at P-CSCF failure)

这种机制的核心思想是：当网络发现P-CSCF故障后，直接给UE推送一个全新的、可用的P-CSCF地址列表，就像是物业发现小区的门禁坏了，直接给每户业主发了一把新门禁卡的配置信息。

2.1 机制运行的前提 (5.1.1 General requirements)

要启用这套机制，网络和终端需要满足一些先决条件。

  1. P-CSCF discovery is performed by requesting and provisioning P-CSCF address(es) within Protocol Configuration Options (PCO), as specified in 3GPP TS 29.061, clause 13a.2.1
  2. The UE supports PCO IE, as specified in 3GPP TS 24.008, clause 10.5.6.3.

简单来说，这意味着：

  1. P-CSCF地址通过PCO下发：在小张的手机最初建立IMS PDN连接（或EPS承载）时，P-CSCF的地址列表就是通过PCO（协议配置选项）这个信息单元，由PGW/GGSN下发给她的。UE需要支持解析PCO中的P-CSCF地址。
  2. UE支持PCO信息单元：手机的协议栈必须能够正确处理和解析PCO IE。

这是“从哪里来，到哪里去”的原则。既然地址最初是通过PCO下发的，那么更新地址最自然的方式，也是通过PCO。

2.2 恢复流程深度解析 (5.1.2 Network recovery information flow - Update PDP context / Bearer)

规范中的“Figure 5.1.2a: P-CSCF failure (new list of P-CSCFs in PCO)”清晰地展示了整个流程。让我们结合小张的场景，一步步拆解这张图。

故障发生前 (图5.1.2a, 步骤 1-10):

  1. 步骤1-2 (建立连接)：小张的手机发起Create PDP Context Request / Create Session Request，请求建立一个用于IMS业务的数据连接。PGW/GGSN在响应中，通过PCO IE下发了一个P-CSCF地址列表，例如 [pcscf1.operator.com, pcscf2.operator.com]。
  2. 步骤3-4 (策略申请)：PGW/GGSN向PCRF请求该IMS会话的PCC策略。
  3. 步骤5 (IMS注册)：小张的手机从PCO收到的列表中选择一个P-CSCF（例如pcscf1.operator.com），并发起SIP REGISTER。
  4. 步骤6-9 (地址上报与监控)：P-CSCF-1会将自己的地址通过Rx接口上报给PCRF，PCRF再通过Gx接口将这个“当前被选中的P-CSCF地址”通知给PGW/GGSN。
  1. The GGSN/PDN-GW stores this address for the UE and sends Gx Push Rsp. Also, the GGSN/PDN-GW starts monitoring the health of the P-CSCF if not already done. 这个步骤至关重要。PGW/GGSN在得知小张当前正在使用P-CSCF-1后，它便承担起了监控P-CSCF-1健康状况的责任。这个监控可以通过ICMP Ping、路径探测、BFD等多种机制实现。
  1. 步骤10 (注册成功)：P-CSCF-1返回200 OK，小张的手机IMS注册成功，VoNR视频会议正常进行。

P-CSCF故障与恢复 (图5.1.2a, 步骤 11-13):

  • 步骤11 (故障检测与网络响应)：
  1. A failure in P-CSCF is detected via Gi/sGi by the GGSN/PDN-GW. The GGSN/PDN-GW sends a new PCO IE with a new list of P-CSCF addresses (which does not include the failed P-CSCF) to all UEs associated to the failed P-CSCF address. 这是整个恢复流程的核心。PGW/GGSN的监控机制发现pcscf1.operator.com失联了（Failure detected）。它立刻采取行动： 1. 它会筛选出所有正在使用P-CSCF-1的用户（包括小张）。 2. 它会生成一个新的P-CSCF地址列表，这个新列表中不包含已故障的P-CSCF-1，例如 [pcscf2.operator.com, pcscf3.operator.com]。 3. 它会为每一个受影响的用户，发起一个网络侧触发的PDP上下文修改/承载修改流程 (Update PDP Context Request / Update Bearer Request)。在这个流程中，它将包含新P-CSCF列表的PCO IE推送给UE。
  • 步骤12 (UE确认)：小张的手机收到这个承载修改请求后，会进行确认。
  • 步骤13 (UE的行动)：
  1. Upon receiving the new list of P-CSCFs, if the P-CSCF in use is missing, each UE performs an initial registration towards a new P-CSCF. 小张的手机解析收到的新PCO，发现里面只有pcscf2和pcscf3，而自己当前正在使用的pcscf1不见了。它立刻明白P-CSCF-1已经失效。于是，它会从新列表中选择一个可用的P-CSCF（如pcscf2.operator.com），并立即发起一次全新的IMS初始注册。

结果：在小张看来，她的视频会议断了。但几秒钟后，手机自动完成了后台的承载修改和IMS重注册。她再次点击拨号，电话顺利接通，与项目组恢复了联系。虽然通话被中断，但业务能力在极短时间内自动恢复了。

2.3 PMIP场景下的变体 (5.1.3 Network recovery information flow with S5 PMIP)

规范还考虑了S5/S8接口使用PMIPv6（Proxy Mobile IP）的场景。GTP是基于隧道的用户面协议，而PMIP是基于网络侧的移动性管理协议。协议的不同导致核心网内部的信令流程有所差异，但对UE侧的行为没有影响。

在“Figure 5.1.3: P-CSCF failure with S5 PMIP”中，关键区别在于步骤11和12：

  • 步骤11: PGW在检测到P-CSCF故障后，不再发送GTP消息，而是向SGW发送一个PMIP的UPN（Update Notification）消息，这个消息中携带了包含新P-CSCF列表的PCO。
  • 步骤12: SGW收到UPN后，再触发对MME/SGSN的承载修改流程，最终将PCO信息送达UE。

最终，UE的行为与GTP场景完全一致：收到新PCO，发现旧P-CSCF消失，然后向新P-CSCF发起重注册。

3. DHCP机制：网络发送“门户停用”通知 (解析 5.2 Inform UE about P-CSCF failure)

第二种机制在理念上有所不同。网络不再直接给UE一个新的地址列表，而是只告诉UE：“你现在用的那个P-CSCF坏了，你自己想办法再去找一个新的吧”。UE收到通知后，会使用DHCP协议去重新请求一个P-CSCF地址。

3.1 机制运行的前提 (5.2.1 General requirements)

  1. P-CSCF discovery is performed by requesting P-CSCF address(es) via DHCP method, as specified in 3GPP TS 29.061, clause 13a.2.1

此机制的核心前提是，UE最初获取P-CSCF地址的方式就是通过DHCP。这在一些固网接入或特定的无线场景下比较常见。

3.2 恢复流程深度解析 (5.2.2 Network recovery information flow – Inform UE at P-CSCF failure)

我们通过解析“Figure 5.2.2a: P-CSCF failure for DHCP based scenarios”来理解这个流程。

故障发生前 (图5.2.2a, 步骤 1-11):

  1. 步骤1-3 (建立连接与DHCP请求)：小张的手机建立数据连接后，会发起一个DHCP请求来获取IP地址和P-CSCF地址。PGW/GGSN（或其控制下的DHCP服务器）在DHCP响应中返回P-CSCF地址。
  2. 后续步骤 (4-11)：与PCO机制类似，PGW/GGSN同样会上报并监控UE当前使用的P-CSCF（pcscf1.operator.com），UE完成IMS注册，一切正常。

P-CSCF故障与恢复 (图5.2.2a, 步骤 12-15):

  • 步骤12 (故障检测与通知)：
  1. A failure in P-CSCF is detected via Gi/sGi by the GGSN/PDN-GW. The GGSN/PDN-GW informs to all UEs associated to the failed P-CSCF address that the P-CSCF is not available. PGW/GGSN的监控机制发现pcscf1.operator.com失联了。它的行动与PCO机制不同： 1. 它同样会筛选出所有使用P-CSCF-1的用户。 2. 它会发起一个网络侧的承载修改流程，但在PCO（或ePCO）中，它不再包含一个新的地址列表，而是包含一个特殊的指示——“P-CSCF failure indication”（P-CSCF故障指示）。这个指示就像一个布尔标志，只传递“失败”这一个信息。
  • 步骤13 (UE确认)：UE确认承载修改。
  • 步骤14 (UE的行动)：
  1. The UE requests P-CSCF addresses (if needed) via new DHCP request. 小张的手机收到这个“故障指示”后，明白了自己当前的P-CSCF已不可用。由于它最初就是通过DHCP获取地址的，所以它会再次发起一次新的DHCP请求，以期获得一个可用的P-CSCF地址。
  • 步骤15 (发现新门户并重注册)：
  1. The UE selects a new P-CSCF and initiates an initial IMS registration. DHCP服务器（由PGW/GGSN控制）在响应中返回一个新的、可用的P-CSCF地址列表。小张的手机从中选择一个，并发起全新的IMS初始注册。

结果：与PCO机制类似，小张的通话中断，但业务能力在后台自动恢复。不同的是，恢复过程变成了“网络通知 → UE主动请求”的两阶段模式。

4. PCO vs. DHCP：两种机制的对比与思考

这两种由网络核心（PGW/GGSN）发起的恢复机制，代表了两种不同的设计哲学。

  • PCO机制（推模式，Push）：

    • 优点：对UE来说更简单直接。网络一步到位，直接将“解决方案”（新的地址列表）推送给UE。UE只需解析并执行即可。
    • 缺点：网络侧（PGW/GGSN）需要维护和管理P-CSCF的地址池，并在故障时智能地生成新的列表。
    • 适用场景：在P-CSCF地址本身就通过PCO进行管理的3GPP移动网络中最为常用。

  • DHCP机制（拉模式，Pull）：

    • 优点：职责更清晰。PGW/GGSN只负责“发告警”，而P-CSCF地址的管理和分配则完全交给DHCP服务器。这符合“关注点分离”的设计原则。
    • 缺点：恢复过程多了一个交互步骤（UE需要再次发起DHCP请求），理论上延迟可能会略高一点。
    • 适用场景：在P-CSCF地址通过DHCP管理的网络环境中是标准做法。

无论哪种机制，其核心逻辑是相通的：由PGW/GGSN作为故障的发现者和恢复流程的发起者，通过底层的承载控制信道，将P-CSCF的变动信息通知给UE，并最终由UE发起向新P-CSCF的重注册来完成业务恢复。

5. 总结

本文通过小张在高铁上的遭遇，深度剖析了4G/EPC时代网络应对“门户”P-CSCF故障的两种核心主动恢复机制。我们看到，IMS的健壮性不仅体现在核心网元S-CSCF的数据备份与恢复，也体现在边缘网关P-CSCF发生故障时，接入网关（PGW/GGSN）能够承担起监控和恢复的“哨兵”职责。

无论是通过PCO直接推送“新门锁配置”，还是通过故障指示触发UE使用DHCP去领“新钥匙”，其最终目的都是确保用户在最短时间内能够找到一个新的可用“门户”，重新接入IMS世界。

然而，这些机制都依赖于网络的“主动作为”。如果网络没有及时发现故障怎么办？或者在某些网络架构下，PGW不负责监控P-CSCF呢？在下一篇文章中，我们将探讨更多样的恢复策略，包括由UE自己主动发现P-CSCF故障的机制，以及HSS/PCRF等更高级的角色如何参与到这场“门户保卫战”中。

FAQ环节

Q1：在这些流程中，究竟是谁、通过什么方法来检测P-CSCF故障的？ A1：在本文讨论的5.1和5.2机制中，故障的检测者是GGSN/PDN-GW（PGW）。规范原文明确指出“A failure in P-CSCF is detected via Gi/sGi by the GGSN/PDN-GW”。PGW可以通过多种方式来监控P-CSCF的健康状况，例如：

  • Keep-alive机制：定期向其管理的P-CSCF发送心跳包。
  • 网关探测：使用ICMP Ping等工具检查P-CSCF服务器的IP可达性。
  • 路径可用性检测：例如使用双向转发检测（BFD）等协议来监控与P-CSCF之间的路由是否健康。 一旦监控失败，PGW就会认定P-CSCF故障，并触发恢复流程。

Q2：这些恢复机制能保证正在进行的VoNR通话不中断吗？ A2：不能。本文讨论的PCO和DHCP恢复机制，其目标是恢复业务能力，而非保障会话连续性。当P-CSCF故障时，所有经过它的SIP信令（如通话中的会话刷新UPDATE或re-INVITE消息）都会丢失，这会导致S-CSCF侧的会话最终超时而释放。虽然底层的媒体流（RTP包）可能因为不经过P-CSCF而继续传输一小段时间，但信令层面的会话已经中断，通话最终会掉线。用户需要重新拨号才能建立新的通话。

Q3：为什么UE在得知新的P-CSCF地址后，必须发起一次“初始注册（initial registration）”？ A3：因为更换P-CSCF不仅仅是换一个IP地址那么简单。一次初始注册包含了多个关键过程：

  1. 建立安全关联：UE需要与新的P-CSCF之间通过IPsec等机制建立新的安全通道。
  2. S-CSCF重新学习路径：通过新的注册，S-CSCF才能学习到指向UE的新路径（经过了新的P-CSCF）。
  3. 刷新会话状态：在新的P-CSCF和S-CSCF上建立干净、初始的会话状态，避免从旧的、可能已损坏的状态中恢复。 所以，重注册是确保切换到新P-CSCF后，整个IMS会话链路（UE-P-CSCF-S-CSCF）都处于一个一致、安全和正确的状态所必需的权威步骤。

Q4：如果PGW检测到P-CSCF-1故障，并向UE推送了新的地址列表，但此时P-CSCF-1又奇迹般地恢复了，会发生什么？ A4：这不会造成问题。一旦PGW发起了恢复流程，UE就会被强制向新的P-CSCF（例如P-CSCF-2）进行注册。即使P-CSCF-1恢复了，UE也已经“移情别恋”了。PGW的监控机制也会在后续发现P-CSCF-1恢复正常，并可能在未来的P-CSCF地址分配中重新启用它。IMS网络的设计能够容忍这种状态的短暂不一致，最终会通过注册流程达到新的稳定状态。

Q5：在现实网络部署中，PCO和DHCP这两种P-CSCF恢复机制哪一种更常见？ A5：在**3GPP移动网络（如LTE/EPC, 5G NSA）**中，PCO机制是绝对的主流。因为UE的IMS PDN连接建立过程天然就使用PCO来传递各种网络配置参数，P-CSCF地址只是其中之一。在这样的体系下，使用承载修改流程来更新PCO是最顺理成章、集成度最高的方式。DHCP机制则更多见于一些非3GPP接入（如固网宽带、Wi-Fi Offloading的早期实现）或特定历史时期的IMS部署方案中。

关系图谱