51学通信

深度解析TS 29.244：5.5 & 5.6 F-TEID分配与释放及PFCP会话处理 (F-TEID Allocation & Release and PFCP Session Handling)

25分钟阅读

深度解析TS 29.244：5.5 & 5.6 F-TEID分配与释放及PFCP会话处理 (F-TEID Allocation & Release and PFCP Session Handling)

本文技术原理深度参考了3GPP TS 29.244 V18.9.0 (2025-03) Release 18规范中，关于“5.5 F-TEID Allocation and Release”和“5.6 PFCP Session Handling”的核心章节，旨在为读者提供一个关于PFCP会话标识符与核心管理流程的全景视图。

引言

在本系列的前几篇文章中，我们已经深入剖析了策略与计费控制（PCC）架构下丰富多样的策略执行机制。我们了解了网络如何通过PDR识别业务、通过QER保障质量、通过URR进行计量，并通过FAR指挥流量的走向。然而，所有这些精细化的规则（PDR, FAR, QER, URR）并非凭空存在，它们必须被妥善地组织和管理在一个逻辑容器中。这个容器，就是PFCP会话（PFCP Session）。

一个PFCP会话，通常对应着用户的一次PDU会话（或EPC中的PDN连接）。它是SMF与UPF之间就某一个特定用户连接进行所有控制面交互的上下文。要精确地管理数以亿计的PFCP会话，并为每个会话中的用户数据流建立正确的转发路径，网络依赖于一套至关重要的标识符体系。

本篇文章将聚焦于这套标识符体系的核心，以及PFCP会话本身的管理机制。我们将深入探讨两大关键标识符：F-TEID（全限定隧道端点标识符），它是用户面数据隧道的“门牌号”；以及F-SEID（全限定会话端点标识符），它是控制面PFCP会话的“身份证号”。

为了将这些概念具象化，让我们跟随5G用户“小明”的一天。清晨，小明打开了他的5G手机，手机自动发起了当天的第一次PDU会话建立流程，准备接入互联网。我们将跟随这个从无到有的过程，揭示一个PFCP会话是如何被创建的，其中的F-TEID和F-SEID是如何被智慧地协商和分配的，以及当小明开始使用不同应用时，这个会话是如何被动态、高效地修改的。

1. F-TEID的分配与释放 (5.5 F-TEID Allocation and Release)

F-TEID（Fully Qualified Tunnel Endpoint Identifier）是GTP-U隧道端点的唯一标识，它由一个IP地址和一个TEID（Tunnel Endpoint Identifier）组成。在5G核心网中，无论是连接基站的N3接口，还是连接其他UPF的N9接口，用户数据都承载在GTP-U隧道中。因此，F-TEID的正确分配与管理是建立用户面路径的根本。

1.1 通用原则：UPF主导的分配模式 (5.5.1 General)

与传统架构不同，5G的CU分离架构（Control and User Plane Separation）在F-TEID的分配上确立了一个核心原则：由使用者（用户面功能）来分配。

For EPC and 5GC, F-TEID shall be only allocated by the UP function, see clause 5.8.2.3 of 3GPP TS 23.501. The UP function shall set the FTUP feature flag in the UP Function Features IE (see clause 8.2.25) and the CP function shall request the UP function to allocate the F-TEID.

规范明确指出，F-TEID应且仅应由UP功能（UP function）分配。这意味着，控制面功能（CP function, 如SMF）不再为UPF硬性指定一个TEID值，而是向UPF发起一个“分配请求”。UPF会从自己的资源池中选择一个可用的TEID和IP地址，组合成F-TEID，然后告知SMF。

这种模式的好处是显而易见的：它将资源管理的权责下放给了资源的所有者，实现了更好的解耦。UPF最了解自身的IP地址、TEID资源池的使用情况，由它来主导分配可以避免冲突，简化管理，也更符合微服务和云化部署的理念。UPF通过在其UP Function Features IE中设置**FTUP (F-TEID allocation in the UP function)**标志位，来向SMF宣告自己支持并要求遵循这一模式。

场景代入：小明开机，SMF准备建立N3隧道

小明手机开机后，通过NAS信令向AMF/SMF请求建立一个PDU会话。SMF在选择了为小明服务的UPF后，需要建立一条从UPF到基站（gNB）的N3用户面隧道。此时，SMF知道，它不能自己随便为UPF编一个“门牌号”（F-TEID），而是必须向该UPF发出请求：“请为小明这个PDU会话的N3隧道，分配一个你的F-TEID”。

1.2 空白章节说明 (5.5.2 Void)

在继续深入之前，需要说明的是，规范中的5.5.2章节被明确标记为“Void”。这意味着该章节在当前版本中没有内容，是空白或已废弃的。我们在解读时将直接跳过此节。

1.3 UP功能中的F-TEID分配机制 (5.5.3 F-TEID allocation in the UP function)

SMF是如何向UPF发起这个“分配请求”的呢？答案在于PFCP消息中的一个特殊标志位。

The CP function shall request the UP function to allocate the F-TEID by setting the CHOOSE flag in the Local F-TEID IE of the PDR IE (see Table 7.5.2.2-1). The Source Interface IE indicates for which interface the F-TEID is to be assigned.

规范清晰地指出了具体机制：SMF在创建PDR时，在其包含的Local F-TEID信息单元中，将CHOOSE (CH)标志位设置为“1”。这个“CHOOSE”的动作，就是SMF在对UPF说：“由你来选择（Choose）一个F-TEID”。同时，PDR中的Source Interface IE会指明这个F-TEID是用于哪个接口的，例如是用于接收来自“Access”（接入侧，即N3接口）的上行流量。

场景代入：SMF下发PFCP请求

为了建立小明PDU会话的上行路径，SMF向UPF发送一条PFCP Session Establishment Request消息。该消息中包含一条Create PDR IE，这条PDR用于匹配从基站发往UPF的上行数据。在这条PDR的PDI（包检测信息）中：

  • Source Interface被设置为“Access”。
  • 包含一个Local F-TEID IE，其CH标志位被设置为“1”。
  • Local F-TEID IE中的V4或V6标志位也被设置，以表明需要分配IPv4还是IPv6的隧道端点。

UPF收到这条指令后，就明白需要为N3接口分配一个自己的F-TEID。

1.3.1 多个PDR共享同一F-TEID

在某些情况下，多个不同的业务流（对应不同的PDR）可能会共享同一个GTP-U隧道。例如，默认的互联网访问和IMS信令可能都通过默认承载传输。为了避免为每个PDR都分配一个独立的F-TEID，PFCP提供了CHOOSE ID机制。

The CP function may request the UP function to allocate the same F-TEID to several PDRs to be created within one single PFCP Session Establishment Request or PFCP Session Modification Request by:

  • …
  • setting the CHOOSE ID field of the Local F-TEID IE, for each PDR to be created with the same F-TEID, with the same CHOOSE ID value;

当SMF希望多个PDR共享一个F-TEID时，它可以在下发这些PDR的Local F-TEID IE时，除了设置CHOOSE标志位，还为它们设置一个相同的CHOOSE ID值。UPF看到相同的CHOOSE ID，就会为这些PDR分配同一个F-TEID，从而实现了隧道资源的共享。

1.3.2 结合PDI优化（Traffic Endpoint）

一种更现代、更高效的方式是利用PDI优化特性。

or, if the UP function indicated support of the PDI optimization (see clause 8.2.25), by:

  • including the Local F-TEID IE only in the Create Traffic Endpoint IE and by setting the CHOOSE flag in the Local F-TEID IE of this IE; and
  • including the Traffic Endpoint ID in all the PDRs to be created with the same F-TEID.

如果UPF支持PDI优化，SMF可以先创建一个Traffic Endpoint（流量端点），并请求UPF为这个端点分配一个F-TEID。然后，在创建多个PDR时，只需在它们的PDI中引用这个Traffic Endpoint的ID即可。所有引用同一个Traffic Endpoint的PDR，自然就共享了为其分配的那个F-TEID。

1.3.3 UPF的响应与F-TEID的释放

UPF在成功分配F-TEID后，需要将结果告知SMF。

If the PDR(s) is created successfully, the UP function shall return the F-TEID(s) it has assigned to the PDR(s) or to the Traffic Endpoint(s) in the PFCP Session Establishment Response or PFCP Session Modification Response.

UPF会在响应消息（如PFCP Session Establishment Response）的Created PDR或Created Traffic Endpoint IE中，包含其分配好的完整的F-TEID信息。SMF收到后，就获得了UPF侧N3隧道的准确“地址”，然后它就可以通过N2接口将这个F-TEID告知给基站（gNB），从而完成上行用户面路径的建立。

F-TEID的生命周期与使用它的规则绑定。

Upon receiving a request to remove a PDR or a Traffic Endpoint, or to delete a PFCP session, the UP function shall free the F-TEID(s) that was assigned to the PDR if there is no more PDR with the same F-TEID, to the Traffic Endpoint or to the PFCP Session.

当SMF请求删除一个PDR、Traffic Endpoint或整个PFCP会话时，UPF会自动检查与这些被删除规则关联的F-TEID。如果一个F-TEID不再被任何PDR使用，UPF就会将其资源（TEID值）回收，以便后续重用。

2. PFCP会话处理 (5.6 PFCP Session Handling)

我们已经了解了用户面隧道的端点（F-TEID）是如何建立的。现在，我们将视角拉高一层，来探讨承载所有这些规则和端点的容器——PFCP会话，以及标识这个会话本身的“身份证号”——F-SEID。

2.1 会话端点标识符（SEID）处理 (5.6.2 Session Endpoint Identifier Handling)

如果说F-TEID是用户面的地址，那么F-SEID就是控制面的地址。

The SEID uniquely identifies a PFCP session at an IP address of a PFCP entity. The F-SEID is the Fully Qualified SEID and it contains the SEID and IP address. The PFCP endpoint locally assigns the SEID value the peer PFCP side has to use when transmitting message. The SEID values are exchanged between PFCP endpoints using PFCP messages.

规范的这段描述揭示了SEID的几个关键特性：

  • 作用：SEID（Session Endpoint Identifier）用于在一个PFCP节点（如一个SMF或一个UPF）上唯一标识一个PFCP会话。
  • F-SEID：F-SEID（Fully Qualified SEID）是SEID和该节点IP地址的组合，构成了全局唯一的会话标识。
  • 双向分配：SEID的分配是双向的。SMF为会话分配一个SEID，并告知UPF；UPF在后续发往SMF的该会话的消息中，必须携带这个SEID。同样，UPF也为会话分配一个SEID，并告知SMF；SMF在后续发往UPF的该会话的消息中，也必须携带UPF分配的这个SEID。

场景代入：为小明的PFCP会话交换“名片”

这个过程就像SMF和UPF在初次为小明建立会话时，互相交换了一张写有联系方式的“名片”。

  1. SMF的名片：在SMF发送给UPF的第一条消息PFCP Session Establishment Request中，它包含了一个CP F-SEID IE。这个IE里有：
    • SMF的IP地址。
    • SMF为小明这个会话生成的一个SEID值，我们称之为SEID_SMF。
  2. UPF的名片：UPF收到请求并成功创建会话上下文后，在其回复的PFCP Session Establishment Response消息中，包含了一个UP F-SEID IE。这个IE里有：
    • UPF的IP地址。
    • UPF为小明这个会话生成的另一个SEID值，我们称之为SEID_UPF。
  3. 后续通信：此后，这对“名片”就成了双方就小明这个PDU会话进行通信的凭据。
    • 当SMF要给UPF发送关于小明会话的任何消息（如修改规则）时，它会在PFCP消息头的SEID字段填入SEID_UPF。UPF收到消息后，一看SEID，就知道这是针对小明会话的操作。
    • 当UPF要向SMF发送关于小明会话的报告（如用量上报）时，它会在PFCP消息头的SEID字段填入SEID_SMF。SMF收到后，也就能准确地将报告与小明的会话上下文关联起来。

这个双向SEID机制，确保了在海量的PFCP会话中，控制面信令能够被精确地路由和处理。与F-TEID一样，F-SEID的生命周期也与PFCP会话绑定，会话删除时，双方都会释放对应的SEID。

2.2 修改现有PFCP会话的规则 (5.6.3 Modifying the Rules of an Existing PFCP Session)

PFCP会话的一个核心特性是其动态性。用户的业务行为是不断变化的，网络策略也需要随之调整。PFCP会话的修改机制为此提供了高效的实现方式。其核心原则是增量更新（Delta Update）。

When modifying an existing PFCP session, the CP function shall only provide in the PFCP Request message the requested changes compared to what was previously provisioned in the UP function for this PFCP session…

规范强调，当SMF需要修改一个已存在的PFCP会话时，它仅需在PFCP Session Modification Request消息中提供发生变化的部分，而无需重新发送整个会话的所有规则。

场景代入：小明从浏览网页切换到观看视频

  1. 初始状态：小明开机后只是在浏览网页，其PFCP会话中只有几条用于普通上网的PDR/FAR/QER/URR。
  2. 行为变化：小明打开视频APP，开始观看高清视频。
  3. 策略调整：PCF检测到这一行为，下发新的PCC规则给SMF，要求为视频流提供GBR保障。
  4. 增量更新：SMF向UPF发送一条PFCP Session Modification Request消息。这条消息的内容非常精简，它不包含之前用于网页浏览的那些规则，而只包含：
    • Create PDR IE：用于识别视频流的新PDR。
    • Create QER IE：用于保障视频QoS的新QER。
    • Create URR IE：用于单独计量视频流量的新URR。
    • Create FAR IE：用于转发视频流的新FAR（可能与旧FAR相同）。
  5. UPF执行：UPF收到该消息后，并不会清空旧规则，而是在小明会话的现有规则集基础上，追加上这些新规则。

2.2.1 规则的移除

同样，当业务结束时，SMF也只需下发移除指令。

The CP function shall remove IEs which needs to be removed by either:

  • removing the entire Rule if no other parameter of that rule needs to remain provisioned in the UP function, e.g. by including the Remove URR IE in the PFCP Session Modification Request; or
  • updating the Rule including the IEs to be removed with a null length…

规范定义了移除规则的两种方式：

  • 整体移除：当小明关闭视频APP后，SMF会发送一条PFCP Session Modification Request，其中包含Remove PDR、Remove URR、Remove QER等IE，并指定要移除规则的ID。UPF收到后，便将这些规则从会话上下文中彻底删除。
  • 参数移除/解关联：如果只是想修改PDR的行为，比如不再对其进行特殊的QoS控制，但PDR本身还要保留，SMF可以发送一条Update PDR消息。在这条消息中，它可以通过包含一个长度为0的QER ID IE，来指示UPF将该PDR与之前关联的QER解绑。

这种增量、精确的修改机制，使得PFCP信令交互极为高效，能够快速响应用户业务的变化，实现真正的动态策略控制。

总结

在本篇文章中，我们通过小明手机开机并建立PDU会话的场景，深入剖析了PFCP协议中会话管理的两个基本层面：标识符体系和会话修改流程。

  • F-TEID分配与释放 (5.5)：我们了解到，5G网络遵循UPF主导的F-TEID分配原则。SMF通过在PDR的Local F-TEID IE中设置CHOOSE标志位来请求分配，UPF分配后在响应中返回结果。这一机制体现了CU分离架构下资源管理权责下放的设计思想。
  • PFCP会话处理 (5.6)：我们区分了用户面标识符（F-TEID）和控制面标识符（F-SEID）。F-SEID作为PFCP会话的“身份证号”，通过双向分配和交换的机制，确保了控制面信令的精确寻址。
  • 会话修改机制：我们重点学习了PFCP会话修改的增量更新原则。无论是添加、删除还是修改规则，SMF都只向UPF发送变化的“增量”，而非全部规则，这使得网络能够以极低的信令开销，快速、动态地调整用户面策略。

这些基础而核心的机制，共同构成了PFCP协议稳定、高效运行的基石。它们确保了成千上万的策略规则能够被有序地组织在各自的会话容器中，并能够随着用户需求的变化而灵活演进。在接下来的文章中，我们将继续探讨PFCP协议中的其他重要功能，如合法监听和PFCP关联管理等。

FAQ

Q1：F-SEID和F-TEID是PFCP协议中两个非常重要的标识符，请简述它们的核心区别和作用？ A1：核心区别在于它们作用的平面不同。F-SEID（全限定会话端点标识符） 作用于控制面，是SMF与UPF之间用于唯一标识一个PFCP会话的“身份证号”。它由IP地址和SEID组成，并且是双向分配的，确保双方的PFCP消息能准确找到对应的会话上下文。而F-TEID（全限定隧道端点标识符） 作用于用户面，是GTP-U隧道的“门牌号”，由IP地址和TEID组成，用于实际的用户数据包转发。

Q2：在5G核心网中，N3接口（UPF到基站）的F-TEID是由谁分配的？为什么采用这种分配方式？ A2：是由UPF（用户面功能） 分配的。SMF（控制面功能）通过在PFCP Session Establishment/Modification Request消息的Create PDR IE中，设置Local F-TEID IE的CHOOSE标志位为“1”，来请求UPF进行分配。这种“请求-分配”模式是CU（控制面与用户面）分离架构的核心体现，它将用户面资源（如隧道端点）的管理权交给了UPF自己，使得UPF可以更有效地管理自身资源，增强了系统的可扩展性和灵活性。

Q3：当SMF需要为一个已经建立的PDU会话增加一个新的业务流策略时（例如，用户开始看视频），它需要如何操作？ A3：SMF会向UPF发送一条PFCP Session Modification Request消息。根据增量更新的原则，这条消息中只包含为新业务流创建的规则，例如Create PDR、Create QER、Create URR和Create FAR等IEs。UPF收到后，会将这些新规则添加到该PDU会话已有的规则集中，而不会影响原有的规则。

Q4：SMF指示UPF删除一条PDR规则后，与这条PDR关联的F-TEID会发生什么？ A4：UPF会检查这个F-TEID是否还被会话中的其他PDR所使用。如果没有任何其他PDR关联这个F-TEID，那么UPF就会释放（free）该F-TEID，将其资源（主要是TEID值）回收，以供后续新的隧道建立时使用。如果还有其他PDR在使用这个F-TEID，那么该F-TEID会保持不变，继续为那些PDR服务。

Q5：PFCP消息头中的SEID字段应该填入哪个值？是SMF分配的还是UPF分配的？ A5：这取决于消息的方向。SEID的使用是“交叉”的：SMF发送给UPF的消息，其消息头中的SEID字段应填入由UPF分配并告知给SMF的SEID_UPF；反之，UPF发送给SMF的消息，其消息头中的SEID字段应填入由SMF分配并告知给UPF的SEID_SMF。这就像写信时，在信封上填写的是收件人的地址，而不是发件人自己的地址。😊

关系图谱