51学通信

深度解析TS 29.244：5.7 & 5.8 合法监听支持与PFCP关联 (Support of LI & PFCP Association)

23分钟阅读

深度解析TS 29.244：5.7 & 5.8 合法监听支持与PFCP关联 (Support of LI & PFCP Association)

本文技术原理深度参考了3GPP TS 29.244 V18.9.0 (2025-03) Release 18规范中，关于“5.7 Support of Lawful Interception”和“5.8 PFCP Association”的核心章节，旨在为读者提供一个关于合法监听（LI）在N4接口上的实现机制，以及控制面（CP）与用户面（UP）节点间基础关系——PFCP关联的全面视图。

引言

在本系列的前几篇文章中，我们已经深入探讨了PCC策略执行的丰富细节，以及PFCP会话作为策略容器的核心管理流程。我们已经知道，所有针对特定用户数据流的精细化规则（PDR、FAR、QER、URR），都被承载在一个与用户PDU会话一一对应的PFCP会话中，并通过F-SEID和F-TEID等标识符进行精确管理。

然而，在单个PFCP会话之上，还存在着更为宏观和基础的交互平面。首先，移动通信网络作为国家关键基础设施，必须支持**合法监听（Lawful Interception, LI）**这一基本能力，以满足国家安全和执法需求。PFCP协议如何将监听指令转化为用户面上的实际流量复制动作，是保障这一功能实现的关键。

其次，在任何PFCP会话能够建立之前，控制面节点（如SMF）和用户面节点（如UPF）之间必须先建立起一个稳定、互信的“关系”。这个先于所有会话的基础握手，被称为PFCP关联（PFCP Association）。它是两个网络功能（NF）之间所有后续控制面交互的基石。

本篇文章将聚焦于这两大主题。我们将首先通过一个网络安全运营的场景，揭示合法监听在EPC架构下是如何通过N4接口实现的，并阐明其与5GC架构的显著区别。随后，我们将切换到网络运维的视角，模拟一位网络工程师将一台新的UPF设备投入运营的过程，详细解析PFCP关联是如何从零开始建立，以及双方在此基础上如何维持其“伙伴关系”的。

1. 合法监听支持 (5.7 Support of Lawful Interception)

合法监听（LI）是电信网络必须具备的一项法定功能，它允许执法机构（Law Enforcement Agencies, LEA）在获得合法授权后，对特定目标的通信内容和信令信息进行拦截。TS 29.244规范描述了在CU分离架构下，如何通过PFCP协议来执行用户面流量的拦截与复制。

1.1 通用原则 (5.7.1 General)

This clause specifies lawful interception with PFCP in EPC.

规范在本节开头明确了范围，本章内容主要描述的是PFCP协议在EPC架构下对合法监听的支持。这一点非常重要，因为它暗示了5GC架构下LI的实现方式有所不同。

1.2 EPC中的合法监听 (5.7.2 Lawful Interception in EPC)

在EPC的CU分离架构下，当需要对某个用户的流量进行监听时，CP功能（如PGW-C）负责接收来自LI管理系统的指令，并将其翻译成PFCP规则，下发给UP功能（如PGW-U）执行。

Requirements for support of Lawful Interception with a split SGW or PGW are specified in clauses 12.9 and 20.4 of 3GPP TS 33.107. User plane packets shall be forwarded from the UP function to the SX3LIF (or LMISF for S8HR) by encapsulating the user plane packets using GTP-U encapsulation (see 3GPP TS 29.281).

规范指出，被拦截的用户面数据包，需要从UP功能（如PGW-U）通过GTP-U隧道转发到专门的LI功能实体，这个实体在不同的架构下有不同的名称，例如SX3LIF或LMISF（用于S8归属路由场景）。这些实体负责进一步处理和交付被拦截的数据，是LI架构中的关键部分。

那么，CP功能是如何指挥UP功能完成这个复制和转发的动作呢？答案在于FAR（转发行为规则） 的一个特殊能力——复制（Duplicate）。

The CP function shall instruct the UP function to duplicate the packets to be intercepted and to forward them to the SX3LIF (or to the LMISF for S8HR) as specified in clause 5.2.3. For forwarding data from the UP function to the SX3LIF (or LMISF for S8HR), the CP function shall set the DUPL flag in the Apply Action and set the Duplicating Parameters in the FAR, associated to the PDRs of the traffic to be intercepted, with the Destination Interface “LI Function” and set to perform GTP-U encapsulation and to forward the packets to a GTP-u F-TEID uniquely assigned in the SX3LIF (or LMISF for S8HR) for the traffic to be intercepted. The SX3LIF (or LMISF for S8HR) shall then identify the intercepted traffic by the F-TEID in the header of the encapsulating GTP-U packet.

整个PFCP控制流程可以分解为以下几步：

  1. 识别目标流量：CP功能创建一条或多条PDR，用于精确匹配需要被监听的用户流量。
  2. 设置复制动作：CP功能创建或修改一条FAR，并将其与上述PDR关联。这条FAR的配置是实现LI的关键：
    • 在其Apply Action IE中，DUPL（Duplicate） 标志位被设置为“1”。这个标志位告诉UPF：“匹配到PDR的数据包，除了正常处理外，还需要复制一份”。
    • 同时，FAR中还会包含一个Duplicating Parameters（复制参数）IE。这个IE定义了复制出来的包该如何处理，其中包含：
      • Destination Interface：被设置为一个特殊值“LI Function”。
      • Outer Header Creation：包含一个GTP-U隧道的F-TEID，这个F-TEID正是通往LI功能实体（SX3LIF/LMISF）的“门牌号”。
  3. UPF执行：当UPF收到一个匹配该PDR的数据包时，它会执行双重动作：
    • 正常转发：根据FAR中的Forwarding Parameters，对原始数据包进行正常处理（例如，发往基站或互联网）。
    • 复制并转发至LI实体：创建一个数据包的副本，然后根据Duplicating Parameters的指令，将副本封装到一个新的GTP-U隧道中，发往SX3LIF/LMISF。

场景代入：执行对特定用户的流量监听任务

假设执法机构向运营商提供了一份合法授权，要求对用户“张三”的所有互联网流量进行监听。

  1. 任务下发：运营商的LI管理系统将该任务下发给网络中的PGW-C。
  2. 定位PFCP会话：PGW-C根据“张三”的身份信息（如IMSI），找到他当前活动的PDN连接对应的PFCP会话。
  3. 生成PFCP修改指令：PGW-C向为“张三”服务的PGW-U发送一条PFCP Session Modification Request消息。
  4. 修改FAR：该消息中包含一条Update FAR IE。假设“张三”的上网流量由FAR-1处理，PGW-C会更新这条FAR：
    • 在Apply Action中，将DUPL标志位置为“1”。
    • 添加Duplicating Parameters IE，其中Destination Interface设置为“LI Function”，Outer Header Creation则指向LI系统的接收F-TEID。
  5. 监听生效：PGW-U收到并应用该更新后，所有流经它的、“张三”的上下行数据包，在被正常转发的同时，都会被复制一份并发送到指定的LI功能实体，从而实现了无感知的流量监听。

1.3 5GC中的合法监听 (5.7.3 Lawful Interception in 5GC)

Requirements for support of Lawful Interception with SMF and UPF are specified in clause 6.2.3 of 3GPP TS 33.127. The PFCP protocol is not used for Lawful Interception in 5GC.

这是一个至关重要的结论。规范明确指出，PFCP协议在5GC中不用于合法监听。这是5GC相对于EPC的一个重大架构演进。在5GC中，LI功能更多地采用了服务化架构（SBA）的理念。LI的控制不再通过SMF经由N4接口下发，而是由LI功能实体（如ADMF）通过服务化接口（Nupf_EventExposure服务）直接向UPF订阅事件或请求内容。UPF在收到订阅后，会根据订阅内容直接将相关流量复制并发送给LI交付功能实体（LDF），整个过程绕开了SMF和N4接口。

2. PFCP关联 (5.8 PFCP Association)

如果说PFCP会话是SMF和UPF之间就“某个用户”进行沟通的上下文，那么PFCP关联就是SMF和UPF这两个“网络节点”之间建立长期伙伴关系的基础。在处理任何用户会话之前，它们必须先互相认识并建立关联。

2.1 通用原则 (5.8.1 General)

A PFCP Association shall be set up between the CP function and the UP function prior to establishing PFCP sessions on that UP function. Only one PFCP association shall be setup between a given pair of CP and UP functions, even if the CP and/or UP function exposes multiple IP addresses.

规范确立了“先关联，后会话”的基本原则。SMF和UPF之间的一对节点，有且仅有一条PFCP关联，即使它们各自拥有多个IP地址用于信令交互。

2.1.1 节点标识（Node ID）

为了唯一标识一个网络节点，PFCP引入了Node ID的概念。

In PFCP signaling, a CP function or a UP function shall be identified by a unique Node ID. A Node ID may be set to an FQDN or to an IP address (either IPv4 or IPv6, see clause 8.2.38).

Node ID是每个CP或UP功能的唯一身份标识，可以是一个完全限定域名（FQDN）或一个IP地址。在整个关联的生命周期中，双方都使用这个Node ID来指代对方。

2.1.2 关联建立流程

Prior to establishing a PFCP Association, the function responsible for establishing the PFCP Association (e.g. CP function) shall look up a peer function (e.g. UP function), e.g. using DNS procedures (see 3GPP TS 29.303), NRF procedures (see 3GPP TS 29.510) or local configuration.

关联的建立可以由CP功能发起，也可以由UP功能发起。发起方首先需要找到对方的IP地址，这可以通过DNS查询（使用对方的FQDN）、向NRF（网络功能仓库功能）查询，或通过本地配置来完成。找到地址后，便可以发送PFCP Association Setup Request消息来启动关联建立流程。

场景代入：新UPF上线，与SMF“建立外交关系”

假设网络工程师在数据中心部署了一台新的UPF。

  1. 配置：工程师在新UPF的配置中，指定了它需要服务的SMF的Node ID（例如，smf01.operator.com）。
  2. 发现：UPF启动后，读取配置，并向DNS服务器查询smf01.operator.com的IP地址。
  3. 发起关联：UPF向解析到的SMF IP地址发送一条PFCP Association Setup Request消息。该消息的核心内容是：
    • UPF自己的Node ID（例如，upf-dc2-rack5.operator.com）。
    • UPF支持的功能列表（UP Function Features IE），例如是否支持流量疏导、合法监听的复制功能等。
  4. SMF响应：SMF收到请求后，如果接受关联，就会回复一条PFCP Association Setup Response消息，其中包含：
    • SMF自己的Node ID。
    • SMF支持的功能列表（CP Function Features IE）。
    • 表示成功的Cause值。
  5. 关联建立：双方都收到对方的成功响应和Node ID后，PFCP关联正式建立。从此，这台新UPF就可以接收来自该SMF的PFCP会话建立请求，开始处理用户流量了。

2.2 已建立关联下的行为 (5.8.2 Behaviour with an Established PFCP Association)

关联建立后，双方进入了一个稳定的工作状态，并遵循一系列“行为准则”。

When a PFCP Association is established with a UP function, the CP function:

  • shall provision node related parameters (i.e. parameters that apply to all PFCP sessions) in the UP function, if any, e.g. PFDs;
  • …
  • shall check the responsiveness of the UP function using the Heartbeat procedure …
  • may establish PFCP sessions on that UP function;
  • shall refrain from attempting to establish new PFCP sessions on the UP function, if the UP function has indicated it will shut down gracefully.

CP功能的责任：

  • 下发节点级参数：例如，下发PFD（包流描述），这些是全局性的应用识别规则，对所有会话都有效。
  • 心跳检测：定期发送Heartbeat Request消息来确认UPF是否“存活”。
  • 建立会话：开始在UPF上创建、修改、删除PFCP会话。
  • 配合优雅下线：如果UPF通过PFCP Association Update Request消息告知自己即将下线，SMF应停止在该UPF上创建新的PFCP会话。

When a PFCP Association is established with a CP function, the UP function:

  • shall update the CP function with the list of features it supports;
  • shall update the CP function with its load and/or overload control information…
  • shall check the responsiveness of the CP function using the Heartbeat procedure…
  • shall indicate to the CP function if it will shut down within a graceful period…

UP功能的责任：

  • 上报自身能力：通过关联更新流程，告知CP功能自己支持的特性列表。
  • 上报负载/过载信息：如果支持，主动向CP功能上报自身的负载情况，以便CP功能进行负载均衡。
  • 心跳检测：同样，定期向CP功能发送心跳以确认其存活。
  • 通知下线/故障：在计划下线或发生故障时，主动通知CP功能。

2.3 未建立关联下的行为 (5.8.3 Behaviour without an Established PFCP Association)

When a PFCP Association is not established with a UP function, the CP function:

  • shall reject any incoming PFCP Session related messages from that UP function, with a cause indicating that no PFCP association exists with the peer entity.

规则非常简单：如果一个节点收到来自一个陌生节点（即没有建立关联的节点）的任何会话相关的消息，它必须拒绝该消息，并回复一个原因为“不存在PFCP关联”的错误。这确保了所有的会话操作都必须在已建立的、受控的关联框架内进行，保障了网络的安全性和稳定性。

总结

在本篇文章中，我们从节点管理的宏观视角，探讨了PFCP协议中两个至关重要的支撑机制：

  • 合法监听支持 (5.7)：我们了解到，在EPC架构下，LI的用户面流量复制是通过在FAR中设置DUPL（复制）标志位和配置指向LI功能实体的Duplicating Parameters来实现的。这是一个由CP功能（PGW-C）通过N4接口主动控制的过程。与之形成鲜明对比的是，在5GC中，PFCP协议不再用于LI，其实现转由服务化接口直接控制。
  • PFCP关联 (5.8)：PFCP关联是CP功能和UP功能之间在处理任何用户会话之前的基础握手。它通过PFCP Association Setup流程建立，双方交换Node ID和功能特性列表。关联一旦建立，双方通过心跳（Heartbeat）机制维持活性检测，并通过关联更新流程进行状态同步（如负载上报、优雅下线通知）。任何试图在未建立关联的节点间进行会话操作的行为都将被拒绝。

理解了PFCP关联，我们才真正把握了SMF与UPF这对核心网“将帅”之间关系的本质。它不仅是后续所有精细化策略执行的前提，更是保障核心网控制面与用户面协同工作时稳定、可靠、可扩展的基石。

FAQ

Q1：在N4接口上，合法监听（LI）在EPC和5GC中的实现方式有什么核心区别？ A1：核心区别在于PFCP协议是否参与。在EPC中，LI是由CP功能（如PGW-C）通过PFCP协议控制的。它通过修改FAR规则，指示UPF（PGW-U）复制（DUPL）目标流量并将其转发到LI功能实体（SX3LIF）。而在5GC中，规范明确指出PFCP协议不用于合法监听。5GC的LI采用服务化架构，由LI功能实体通过服务化接口直接向UPF订阅和获取数据，绕过了SMF和N4接口。

Q2：PFCP关联（Association）和PFCP会话（Session）之间是什么关系？ A2：PFCP关联是节点之间的关系，它是CP功能（如一个SMF）和UP功能（如一个UPF）这两个网络实体建立的、长期的控制面连接，是所有后续交互的基础。而PFCP会话是针对单个用户连接的上下文，通常与一个PDU会话或PDN连接对应，包含了该用户连接的所有策略和转发规则。可以理解为，关联是两个公司（SMF和UPF）建立的战略合作关系，而会话是这次合作中处理的每一笔具体业务（每个用户）。

Q3：什么是Node ID？它在建立PFCP关联时起什么作用？ A3：Node ID是CP功能或UP功能在PFCP信令中的唯一标识符，可以是一个FQDN（完全限定域名）或一个IP地址。在PFCP关联建立过程中，双方通过PFCP Association Setup Request/Response消息交换各自的Node ID。这个Node ID成为此后双方识别对方节点的凭据，用于所有后续的节点级管理流程，如心跳检测、关联更新和释放等。

Q4：PFCP关联建立后，心跳（Heartbeat）程序的作用是什么？ A4：心跳程序是PFCP关联建立后的一种保活（Keep-alive）和故障检测机制。CP功能和UP功能都会定期向对方发送Heartbeat Request消息，并期望收到Heartbeat Response。如果在一个预设的时间内没有收到对方的心跳响应，节点就可以判断对方可能已经发生故障或网络路径中断，从而触发相应的恢复或倒换流程，例如，UPF可以尝试联系SMF Set中的其他SMF。

Q5：如果一个SMF在没有与UPF建立PFCP关联的情况下，就向该UPF发送PFCP Session Establishment Request消息，会发生什么？ A5：UPF会拒绝这个请求。根据规范5.8.3节，当一个节点收到来自一个没有建立PFCP关联的对端节点的会话相关消息时，它必须拒绝该消息，并在响应中返回一个值为“No established PFCP Association”（不存在已建立的PFCP关联）的Cause。这强制要求所有会话操作都必须在已建立的关联框架下进行。😊

关系图谱