51学通信

深度解析TS 29.244：6. Procedures - PFCP协议的“操作手册”

19分钟阅读

非常好，我们继续深入这场关于3GPP TS 29.244规范的技术探索之旅。

在前面的系列文章中，我们已经全面剖析了PFCP协议的“功能蓝图”，即第五章（General description）所定义的各项原理，涵盖了从基本的PCC策略执行到支撑URLLC、ATSSS、IPTV、TSN等高级业务的复杂机制。我们知道了网络能做什么。然而，协议的生命力不仅在于其定义了什么功能，更在于其规定了如何通过具体的消息交互来实现这些功能。

本篇文章，我们将从“是什么”迈向“怎么办”，深入TS 29.244规范的核心——第六章：Procedures（程序）。这一章是PFCP协议的“操作手册”，它详细定义了控制面（CP）功能和用户面（UP）功能之间进行所有交互的标准化流程。我们将揭示，SMF和UPF这对核心网的“将帅组合”，是如何通过一系列严谨的“外交礼节”（节点级程序）和“作战指令”（会话级程序）来协同工作的。

我们将跟随网络运维工程师老王的一天。今天，他接到了一个重要任务：为即将到来的大型体育赛事扩容，将一台全新的UPF设备投入现网运营，并承载第一批用户的业务。我们将跟随老王的操作，从UPF的首次上电开始，全程见证：

  1. 节点间“建交”：新UPF如何与SMF“互相认识”并建立起稳固的PFCP关联。
  2. 生命体征监测：SMF如何通过心跳程序持续确认UPF的“健康状况”。
  3. 首位用户的接入：当用户小明连接到网络时，SMF如何在UPF上为其“开户”，即建立PFCP会话。
  4. 业务的动态调整：随着小明使用不同应用，SMF如何下发指令修改会话中的策略规则。
  5. 用户面的主动汇报：UPF如何向SMF报告业务使用情况或检测到的事件。
  6. 用户离网与资源回收：小明关闭数据连接后，SMF如何指示UPF“销户”，即删除PFCP会话。

通过这个完整的生命周期，我们将为您呈现一个动态、立体的PFCP程序全景。

深度解析TS 29.244：6. Procedures - PFCP协议的“操作手册”

在处理任何具体的用户业务之前，CP功能和UP功能这两个网络节点必须首先建立起彼此的信任和通信上下文。节点相关程序处理的是节点间的关系，独立于任何特定的PFCP会话。

1.1 PFCP关联建立程序 (6.2.6 PFCP Association Setup Procedure) - “初次握手”

这是两个节点间的第一个，也是最重要的程序。它使得CP功能可以将一个UP功能的资源纳入其管辖范围。

流程概述： 该程序可以由CP功能发起，也可以由UP功能发起。以CP功能发起为例：

  1. 发现与请求：SMF（CP功能）通过DNS、NRF或本地配置发现新上线的UPF的IP地址。随后，SMF向UPF发送一条 PFCP Association Setup Request 消息。
  2. 核心请求内容：
    • Node ID：SMF自己的唯一标识（如FQDN或IP地址）。
    • Recovery Time Stamp：SMF的启动时间戳，用于网络恢复。
    • CP Function Features：SMF宣告自己支持的可选功能列表，例如是否支持负载控制（LOAD）、过载控制（OVRL）、增强的关联释放（EPFAR）等。
  3. UPF响应：UPF收到请求后，如果接受关联，便会回复一条 PFCP Association Setup Response 消息。
  4. 核心响应内容：
    • Cause：值为“Request accepted”，表示成功。
    • Node ID：UPF自己的唯一标识。
    • Recovery Time Stamp：UPF的启动时间戳。
    • UP Function Features：UPF宣告自己支持的完整功能列表，这是SMF后续能否使用高级功能的依据，例如是否支持ATSSS（MPTCP/MPQUIC/ATSSS-LL）、URLLC（QFQM/GPQM）、IPTV、TSN等。

一旦SMF收到成功的响应，一个PFCP关联就正式建立了。从此，这两个节点就可以开始进行会话级的交互。

1.2 心跳程序 (6.2.2 Heartbeat Procedure) - “保持联系”

建立了关联之后，双方需要一种机制来确认彼此是否仍然“在线”。心跳程序就是这种保活（Keep-alive）机制。

  • 流程：任何一方都可以随时向对端发送 Heartbeat Request 消息。接收方必须立即回复一个 Heartbeat Response。
  • 作用：发送方会为每个请求启动一个定时器。如果在超时前没有收到响应，经过若干次重试后，发送方就可以判定对端节点或两者间的路径已发生故障，从而触发恢复流程（例如，SMF可以将用户会话迁移到其他可用的UPF上）。

1.3 PFCP关联更新与释放程序 (6.2.7 & 6.2.8) - “关系维护与终止”

  • 关联更新 (PFCP Association Update)：在关联的生命周期中，任何一方都可以通过 PFCP Association Update Request/Response 流程来更新自己的状态，例如，UPF可以更新自己支持的功能列表，或者向CP功能请求优雅地释放关联（例如，在计划内停机维护前）。
  • 关联释放 (PFCP Association Release)：当需要明确终止关联时（例如，由运维人员发起），CP功能会发起 PFCP Association Release Request/Response 流程。UPF收到请求后，会删除与该CP功能相关的所有PFCP会话和关联信息，并回复确认。

在节点关联的基础上，所有针对具体用户PDU会话的控制都是通过会话相关程序来完成的。

2.1 PFCP会话建立程序 (6.3.2 PFCP Session Establishment Procedure) - “开户”

当一个新用户的PDU会话需要建立时，SMF通过此程序在UPF上创建一个对应的PFCP会话上下文。

  1. SMF发起请求：SMF向UPF发送一条 PFCP Session Establishment Request 消息。
  2. 核心请求内容：这是一条非常复杂的消息，它携带了为该用户建立初始用户面所需的所有规则：
    • CP F-SEID：SMF为该会话分配的唯一标识，要求UPF在后续与自己通信时使用。
    • Create PDR：一条或多条数据包检测规则，定义了如何识别该用户的上行或下行流量（例如，基于F-TEID、UE IP地址等）。
    • Create FAR：一条或多条转发行为规则，定义了匹配PDR的流量该如何处理（转发、丢弃、缓冲等）以及转发到哪里。
    • Create URR/Create QER：可选地，创建用量上报规则和QoS执行规则。
  3. UPF处理与响应：UPF收到请求后，会尝试应用所有这些规则。
    • 完全成功：如果所有规则都成功应用，UPF会为该会话分配自己的**UP F-SEID**，并回复一条Cause为“Request accepted”的 PFCP Session Establishment Response 消息，其中包含了UP F-SEID。
    • 部分成功：如果UPF和SMF都支持PSUCC特性，即使部分规则（如一个未知的预定义规则）无法应用，UPF也可以接受请求，并在响应中通过Cause“Request partially accepted”和Partial Failure Information IE告知SMF哪些规则失败了。
    • 完全失败：如果关键规则无法应用，或不支持PSUCC，UPF会拒绝整个请求，并回复相应的错误Cause。

2.2 PFCP会话修改程序 (6.3.3 PFCP Session Modification Procedure) - “业务变更”

这是最常用的程序，用于在会话生命周期中动态调整策略。

  1. SMF发起请求：当用户业务发生变化（如开始看视频、发起VoNR通话）或策略需要更新时，SMF向UPF发送 PFCP Session Modification Request 消息。
  2. 核心原则——增量更新：该消息只包含发生变化的部分。例如：
    • 要新增一条视频流规则，消息中就包含Create PDR、Create QER等。
    • 要更新一条现有FAR的转发目标（如切换时），消息中就包含Update FAR。
    • 要删除一条不再需要的URR，消息中就包含Remove URR。
  3. UPF处理与响应：UPF根据指令，在现有会话上下文的基础上进行增、删、改操作，并回复 PFCP Session Modification Response，告知操作结果。

2.3 PFCP会话报告程序 (6.3.5 PFCP Session Report Procedure) - “主动汇报”

此程序由UPF主动发起，用于向SMF报告在用户面上检测到的事件。

  1. UPF发起报告：当一个预设的报告触发器被满足时（例如，URR中的流量阈值到达、不活跃定时器超时、检测到错误指示等），UPF向SMF发送 PFCP Session Report Request 消息。
  2. 核心报告内容：
    • Report Type：指明报告的类型，如USAR（用量报告）、DLDR（下行数据报告）、ERIR（错误指示报告）等。
    • Usage Report：如果类型是USAR，此IE会包含具体的用量信息和触发原因。
  3. SMF响应：SMF收到报告后，进行相应的策略决策，并回复 PFCP Session Report Response 确认收到。SMF甚至可以在响应中直接包含Update BAR IE来调整缓冲策略，实现快速闭环控制。

2.4 PFCP会话删除程序 (6.3.4 PFCP Session Deletion Procedure) - “销户”

当PDU会话终止时，通过此程序来释放UPF上的所有相关资源。

  1. SMF发起请求：SMF向UPF发送 PFCP Session Deletion Request。
  2. UPF处理与响应：UPF收到请求后，删除该PFCP会话的所有上下文和规则。在回复的 PFCP Session Deletion Response 消息中，如果存在任何未上报的用量，UPF会附上最后的Usage Report。

3. 可靠性保障：PFCP消息的可靠传递 (6.4 Reliable Delivery of PFCP Messages)

所有上述程序都依赖于一个可靠的底层消息传递机制。PFCP基于UDP，本身是不可靠的，因此协议自身定义了一套简单的重传机制。

  • 机制：发送方每发送一个Request消息，都会启动一个定时器T1并为其分配一个唯一的序列号。如果在T1超时前没有收到具有相同序列号的Response消息，发送方就会重传该请求，最多重试N1次。如果最终仍未收到响应，则认为对端不可达，并通知上层应用。

总结

第六章“Procedures”是TS 29.244规范的“执行篇”，它将第五章定义的各种功能原理，落实为一套具体、严谨的信令交互流程。通过本篇文章的梳理，我们了解到：

  • 节点级程序 (6.2) 是基础，通过关联建立、心跳维持、关联释放等流程，构建和维护了CP与UP功能之间的稳定关系。
  • 会话级程序 (6.3) 是核心，通过建立、修改、报告、删除这四大程序，完整地覆盖了一个用户PDU会话从生到死的全生命周期管理。
  • 增量更新和UPF主动上报的设计思想贯穿始终，确保了信令交互的高效和动态。
  • 底层的可靠传递机制 (6.4) 则为所有上层程序的正确执行提供了“安全网”。

掌握了这些程序，就等于掌握了N4接口的“语言”和“语法”。它们共同构成了5G核心网控制面与用户面之间协同工作的交响乐，将网络策略的宏伟构想，精准地转化为对每一个数据包的精细化处理动作。

FAQ

Q1：PFCP关联程序（Association Procedure）和会话程序（Session Procedure）有什么根本区别？ A1：根本区别在于作用的层面不同。关联程序是节点级的，处理的是一个CP功能（如SMF）和一个UP功能（如UPF）这两个网络设备之间的关系，一个CP-UP对之间只有一个关联。它的目的是让双方“认识”并交换能力，是所有后续交互的前提。而会话程序是用户级的，处理的是单个用户的PDU会话在UPF上的上下文，每个PDU会话对应一个PFCP会话。可以理解为，关联是“建交”，会话是处理每一笔具体的“业务”。

Q2：PFCP消息头中的序列号（Sequence Number）是做什么用的？ A2：序列号是实现PFCP可靠传递机制的关键。每当一个PFCP实体发送一个**请求（Request）消息时，它都会在消息头中放入一个唯一的序列号。当它收到一个响应（Response）**消息时，会通过响应消息头中相同的序列号来匹配是哪个请求得到了回复。这个机制使得发送方可以管理多个并发的请求，并通过超时重传来处理请求或响应消息丢失的情况。

Q3：如果SMF和UPF之间的PFCP关联因为网络故障中断了，UPF上已建立的PFCP会话会怎么样？ A3：这取决于故障的发现方式和恢复机制。如果只是心跳超时，SMF会认为UPF不可达，并可能触发恢复流程，尝试在其他UPF上重建用户的PDU会话。原UPF上的PFCP会话上下文可能会因为后续的清理机制或超时而被删除。如果UPF重启，它会丢失所有会话信息。当它与SMF重新建立关联时，SMF会发现UPF的Recovery Time Stamp发生了变化，从而知道UPF已经重启。SMF随后会逐一为受影响的用户重新发送PFCP Session Establishment Request来恢复这些会话。

Q4：为什么PFCP会话修改程序（Modification Procedure）只发送变化的部分，而不是全部规则？ A4：这是为了提升信令效率。一个PDU会话可能包含数十条复杂的PDR/FAR/QER/URR规则。如果每次微小的策略调整（例如，只是修改一个QER的速率限制）都需要重新下发所有规则，将会产生巨大的信令开销，并增加UPF的处理负担。采用增量更新的方式，SMF只发送变化的“diff”，使得信令消息非常轻量，能够快速响应用户业务的变化，这是实现5G网络动态策略控制的关键设计。

Q5：PFCP Session Report是由谁发起的？通常在什么情况下会触发？ A5：PFCP Session Report是由UPF主动发起的。它在多种由SMF预先设定的事件发生时被触发。最常见的触发条件包括：

  • 用量报告：URR中设定的流量/时长/事件阈值或配额到达。
  • 下行数据到达：当UE处于非连接状态时，第一个下行数据包到达UPF并被缓冲。
  • 用户面不活跃：在指定时间内没有任何上下行数据。
  • 错误指示：收到来自下游节点（如RAN）的GTP-U错误指示。
  • QoS监控：测量的时延等指标超过阈值。

关系图谱