51学通信

深度解析TS 29.244：5.9-5.11 厂商特定IE、错误处理与用户面不活跃检测

26分钟阅读

深度解析TS 29.244：5.9-5.11 厂商特定IE、错误处理与用户面不活跃检测

本文技术原理深度参考了3GPP TS 29.244 V18.9.0 (2025-03) Release 18规范中，关于“5.9 Usage of Vendor-specific IE”、“5.10 Error Indication Handling”、“5.10A User Plane Path Failure or Recovery Handling”以及“5.11 User plane inactivity detection and reporting”的核心章节，旨在为读者提供一个关于PFCP协议中异常处理、扩展性与资源优化机制的全景视图。

引言

在本系列的前几篇文章中，我们已经深入探索了PFCP协议如何构建起SMF与UPF之间稳固的关联，并在此基础上，通过建立和管理PFCP会话来执行丰富多样的策略与计费控制。我们已经熟悉了网络在“理想状态”下的工作流程。然而，一个健壮的通信协议，不仅要能处理常规业务，更要能优雅地应对各种异常、故障和特殊需求。

本篇文章将我们的视角从常规流程转向异常处理、扩展性与资源优化。我们将探讨三大关键主题：

  1. 扩展性：当标准规范无法满足特定厂商的创新需求时，网络如何提供一个“后门”以支持私有功能的扩展？这就是**厂商特定IE（Vendor-specific IE）**的用武之地。
  2. 异常处理：当用户面的数据转发路径出现问题时，无论是单个隧道出错还是整条物理链路故障，UPF如何将这些底层故障信息准确地“上报”给控制面的大脑（SMF）？我们将分别解析错误指示处理和用户面路径故障处理这两种机制。
  3. 资源优化：当用户长时间不使用数据业务时，网络如何智能地“感知”到这种不活跃状态，并据此释放宝贵的无线侧和用户面资源，以实现节能和增效？用户面不活跃检测与上报机制为此提供了完美的解决方案。

为了让这些概念更加生动，我们将继续跟随我们的老朋友“小明”。今天，小明的5G体验将不再一帆风顺。他将乘坐一列高速行驶的列车，经历一次不完美的网络切换；他所连接的UPF将遭遇一次短暂的链路中断；而在他工作间隙，手机长时间闲置时，网络也将悄悄地为他进行资源优化。通过这些“小插曲”，我们将深入理解PFCP协议在保障网络韧性和效率方面的智慧设计。

1. 厂商特定IE的使用 (5.9 Usage of Vendor-specific IE)

3GPP规范为全球通信网络提供了标准化的基石，但同时也为厂商的创新和差异化留下了空间。厂商特定IE（Vendor-specific Information Element）就是这样一种机制，它允许设备商（如华为、爱立信、中兴等）在标准的PFCP消息中携带其私有的参数，以实现非标准化的增强功能。

Vendor-specific IEs are defined to cover requirements and features not specified by 3GPP. In a network with Vendor specific enhancements, unrecognized vendor specific IEs shall be handled as unknown optional IEs.

规范指出，厂商特定IE的存在是为了满足3GPP未定义的特殊需求和特性。为了保证互联互通，规范同时要求，如果一个PFCP实体收到了一个它不认识的厂商特定IE，它必须将其当作一个“未知的可选IE”来处理，即静默地丢弃该IE并继续处理消息的其他部分。这确保了不同厂商设备间的混合组网不会因为私有功能的引入而导致通信中断。

厂商特定IE可以出现在任何PFCP消息中，其应用场景非常灵活。

NOTE 2: The PFCP entities can use Vendor-specific IE(s) in the PFCP message relevant to the PFCP Association Setup procedure to learn which vendor specific enhancements are supported by the peer.

一个典型的应用场景是在PFCP关联建立过程中。当一个SMF和UPF首次“握手”时，它们可以通过在PFCP Association Setup消息中携带各自的厂商特定IE，来互相宣告自己支持哪些私有功能。如果双方都来自同一厂商且支持某项私有增强特性，它们就可以在后续的会话管理中启用该功能。

场景代入：运营商的“秘密武器”

小明所使用的运营商网络，其核心网的SMF和UPF均由“VendorX”公司提供。“VendorX”开发了一项名为“智能抖动抑制”的私有技术，能够在UPF上对实时视频流进行更精细的优化，但这需要SMF下发一些非标准的调度参数。

  1. 能力协商：在SMF与UPF建立PFCP关联时，双方在PFCP Association Setup Request/Response消息中，都携带了一个Vendor-specific IE，其Enterprise ID被设置为“VendorX”的唯一标识。IE的内容则是一个内部定义的标志位，表明自己支持“智能抖动抑制”功能。
  2. 功能激活：后续，当小明开始观看高清视频时，SMF在下发用于视频流的Create QER消息中，除了标准的GBR/MBR参数外，还会额外携带一个“VendorX”的厂商特定IE，其中包含了“智能抖动抑制”算法所需的私有调度参数。
  3. 增强体验：UPF收到后，识别出这个私有IE，并启用其增强的抖动抑制功能，为小明提供了超越标准能力的、更佳的视频观看体验。

2. 错误指示处理 (5.10 Error Indication Handling)

网络并非总是可靠的。当用户面的GTP-U隧道出现问题时，需要有一种机制能够将这个故障快速地通知到控制面，以便做出响应。Error Indication就是这样一种用户面消息，它通常由GTP-U隧道的接收端（如下游的基站或上游的SGW-U）在发现无法处理收到的GTP-U包时（例如，因为找不到对应的隧道上下文）发送给GTP-U隧道的发送端（如UPF）。

Upon receipt of a GTP-U Error Indication message, the UP function:

  • shall identify the related PFCP session for which the message is received; and
  • shall initiate a PFCP Session Report procedure, towards the CP function controlling this PFCP session, to send an Error Indication Report including the remote F-TEID signalled in the GTP-U Peer Address IE and the Tunnel Endpoint Identifier Data I IE of the GTP-U Error Indication (see clause 7.3.1 of 3GPP TS 29.281).

当UPF收到一个GTP-U Error Indication消息时，它必须将这个用户面的故障事件“翻译”成一个PFCP控制面消息，上报给SMF。这个过程分为两步：

  1. 定位会话：UPF首先需要根据Error Indication消息中的信息（通常是出错隧道的TEID），找到这个隧道属于哪个用户的哪个PFCP会话。
  2. 上报事件：然后，UPF向SMF发起一个PFCP Session Report流程，发送PFCP Session Report Request消息。该消息中包含一个Report Type IE，其**ERIR（Error Indication Report）**标志位被设置为“1”，同时附上一个Error Indication Report IE，其中包含了从GTP-U Error Indication消息中提取出的、出错的远端F-TEID信息。

SMF收到这个报告后，就能知道哪个用户的哪条用户面路径出了问题，并可以采取相应的恢复措施。

场景代入：小明乘坐高铁时的网络切换

小明正乘坐高铁，手机上的视频通话正在进行中。列车高速驶过两个基站的交界处，网络需要进行一次切换（Handover）。在切换过程中，由于信令延迟或竞争，旧基站可能已经释放了与UPF之间的N3隧道，但UPF仍然有少量数据包发往了旧基站的F-TEID。

  1. 用户面错误：旧基站收到了这些迟到的数据包，但发现对应的隧道上下文已经不存在，于是向UPF的源IP地址和端口发送一个GTP-U Error Indication消息，消息中包含了它自己的、已经失效的F-TEID。
  2. UPF“翻译”与上报：
    • 小明的UPF收到了这个GTP-U Error Indication。
    • UPF根据消息中指示的TEID，识别出这是属于小明PDU会话的N3下行隧道。
    • UPF立即构造一条PFCP Session Report Request消息发往SMF。
    • 该消息的Report Type IE中，ERIR位置“1”。
    • 消息中包含Error Indication Report IE，其中的Remote F-TEID IE就填入了从旧基站收到的那个F-TEID。
  3. SMF决策：SMF收到报告后，结合它所管理的切换流程上下文，明白了这是切换过程中的一个正常“尾部效应”。它知道此时新的N3隧道已经建立，因此无需采取激烈动作，只需确认旧路径已失效即可。但在某些其他场景下（例如，非切换场景下的隧道异常丢失），SMF可能会触发路径重建、数据缓存等更为复杂的恢复流程。

3. 用户面路径故障或恢复处理 (5.10A User Plane Path Failure or Recovery Handling)

与5.10节处理单个隧道（会话级）的错误不同，5.10A节处理的是更为宏观的、节点级的路径故障。例如，UPF与某个远端GTP-U对端（如另一个UPF或一组基站）之间的物理链路或IP路由中断，导致所有通往该对端的隧道都失效了。

Upon detection of user plane path failure or recovery, the UP function shall initiate PFCP Node Report procedure, towards the CP function controlling the affected PFCP sessions, to send a User Plane Path Failure Report or a User Plane Path Recovery Report including the IP address of the remote GTP-U peer towards which a user plane path failure or recovery has been detected.

这种情况下，如果为每个受影响的PFCP会话都发送一个PFCP Session Report，将会引发一场信令风暴。因此，规范定义了一种更高效的节点级上报机制：PFCP Node Report。

  • 触发：UPF通过内部机制（如BFD、ICMP等）检测到与某个远端GTP-U对端IP地址之间的路径故障或恢复。
  • 上报：UPF向所有与之有关联的CP功能（SMF）发送PFCP Node Report Request消息。
  • 内容：该消息中包含Node Report Type IE，其**UPFR（User Plane Path Failure Report）或UPRR（User Plane Path Recovery Report）**标志位被设置为“1”。同时，消息体中会附上User Plane Path Failure/Recovery Report IE，其中包含了发生故障或已恢复的远端GTP-U对端的IP地址。

一个PFCP Node Report消息，就可以让SMF了解到影响成百上千个会话的底层网络问题，从而可以进行批量的、宏观的策略调整，如触发UPF重选、路由切换等。

4. 用户面不活跃检测与上报 (5.11 User plane inactivity detection and reporting)

为了优化网络资源，特别是昂贵的无线资源，网络需要能够识别出那些“占着茅坑不拉屎”的PDU会话——即长时间没有数据传输但仍然保持着用户面连接的会话。用户面不活跃检测机制就是为此而生。

4.1 PDU会话/PDN连接级的不活跃检测 (5.11.2)

这是最基本的不活跃检测，针对整个PDU会话。

The CP function may request the UP function to detect and report when no user plane packets are received for a PFCP session, by provisioning the User Plane Inactivity Timer IE in the PFCP Session Establishment Request or PFCP Session Modification Request.

控制流程：

  1. SMF下发指令：SMF在建立或修改一个PFCP会话时，可以在请求消息中包含一个User Plane Inactivity Timer IE，其中设置了一个超时时长（例如，900秒）。

  2. UPF执行监控：UPF收到该指令后，启动一个定时器，并监控该PFCP会话的所有上下行流量。每当有数据包通过，就重置该定时器。

  3. 超时与上报：如果该会话在900秒内没有任何数据包通过，定时器超时。UPF立即向SMF发送一条PFCP Session Report Request消息。

  4. 报告内容：该报告消息的Report Type IE中，**UPIR（User Plane Inactivity Report）**标志位被设置为“1”。

  5. 后续行为：

    After sending the User Plane Inactivity Report, the UP function shall stop monitoring the user plane activity of the PFCP session (i.e. the UPF shall behave as if the User Plane Inactivity Timer has not been provisioned)…

    一个关键点是，UPF在发送完不活跃报告后，就停止了对该会话的 inactivity 监控（定时器不再运行），就好像这个指令从未下发过一样。它会继续按照已有的PDR/FAR规则处理后续可能到达的数据包，直到收到SMF的进一步指令。

场景代入：小明午休，手机“睡着了”

小明吃完午饭，把手机放在桌上，自己去午睡了。

  1. 策略配置：在小明的PDU会话建立之初，SMF就在PFCP Session Establishment Request中为该会话配置了一个User Plane Inactivity Timer，值为1800秒（30分钟）。
  2. UPF监控：UPF启动了针对小明会话的30分钟倒计时。期间小明手机后台可能会有少量心跳包，每次都会重置这个倒计时。
  3. 触发上报：30分钟过去了，小明的手机没有任何数据收发。UPF的定时器超时，于是向SMF发送了一条PFCP Session Report Request，报告类型为UPIR。
  4. SMF资源优化：SMF收到报告后，了解到小明的会话处于深度不活跃状态。为了节省无线资源，SMF决定释放小明的用户面连接。它会向AMF发起AN Release流程，最终导致基站释放了与小明手机之间的RRC连接和N3隧道。但PDU会话本身（在核心网侧）仍然存在，处于“CM-IDLE”状态。当小明午睡醒来，拿起手机时，手机会发起Service Request流程，快速重建用户面连接，恢复上网。

4.2 PDR级的不活跃检测 (5.11.3)

除了对整个会话进行监控，PFCP还支持更细粒度的、针对特定PDR的不活跃检测。这在一些需要监控特定业务流是否中断的场景中非常有用。

When both the CP function and the UP function support the UPIDP feature (see clause 8.2.25), the CP function may request the UP function to detect and report when no user plane packets are received for one or more PDRs, by provisioning a URR including the User Plane Inactivity Timer IE and by associating this URR with the PDR(s) …

控制流程：

  1. 能力协商：该功能为可选，需要CP和UP功能都支持**UPIDP（User Plane Inactivity Detection per PDR）**特性。
  2. SMF下发指令：SMF创建一个URR，其中包含User Plane Inactivity Timer IE，然后将这个URR与一个或多个需要监控的PDR关联起来。
  3. UPF执行监控：UPF监控所有与该URR关联的PDR。只要其中任意一个PDR有流量通过，就重置定时器。
  4. 超时与上报：如果所有与该URR关联的PDR在指定时间内都没有流量，定时器超时。UPF向SMF发送PFCP Session Report Request。
  5. 报告内容：该报告消息的Report Type为USAR（Usage Report），Usage Report Trigger则被设置为UPINT（User Plane Inactivity Timer）。

这种机制常用于管理临时的、有生命周期的转发路径，例如切换过程中的数据转发隧道。

总结

在本篇文章中，我们深入探讨了PFCP协议中处理异常、扩展和优化的几项关键机制：

  • 厂商特定IE (5.9)：为厂商实现标准化之外的私有功能提供了灵活的扩展机制，通过在关联建立时进行能力协商，可以实现差异化的增强服务。
  • 错误指示处理 (5.10)：定义了UPF在收到用户面GTP-U Error Indication后，如何通过会话级的PFCP Session Report向SMF上报单个隧道故障的流程，实现了用户面故障向控制面的快速传导。
  • 用户面路径故障处理 (5.10A)：定义了UPF在检测到与远端对等体之间的路径故障或恢复时，如何通过节点级的PFCP Node Report进行批量上报，避免了信令风暴，适用于处理影响多个会话的宏观网络问题。
  • 用户面不活跃检测 (5.11)：提供了两种粒度的监控方式。会话级不活跃检测通过在会话层面配置User Plane Inactivity Timer，使网络能够识别并释放长时间空闲的用户面连接，从而优化资源利用。PDR级不活跃检测则通过在URR中配置定时器并关联至特定PDR，实现了对特定业务流或临时路径的精细化生命周期管理。

这些机制共同构成了PFCP协议的“容错与自愈”系统，使得5G核心网不仅能够高效地执行策略，更能智能地应对网络世界的种种不确定性，保障了网络的健壮性、高效性和可演进性。

FAQ

Q1：厂商特定IE（Vendor-specific IE）的存在是否会破坏网络设备的互联互通性？ A1：不会。根据规范要求，任何PFCP实体在收到一个它无法识别的厂商特定IE时，必须将其视为一个“未知的可选IE”，即静默丢弃该IE并继续正常处理消息的其余部分。这种前向兼容的设计确保了即使网络中部署了来自不同厂商、支持不同私有功能的设备，它们之间标准的PFCP交互依然能够正常进行，不会因为私有扩展而导致通信失败。

Q2：GTP-U错误指示（Error Indication）和用户面路径故障（User Plane Path Failure）有什么本质区别？它们分别通过哪种PFCP消息上报？ A2：本质区别在于故障的粒度和上报机制。GTP-U错误指示是会话级的，通常由GTP-U对端（如基站）因找不到某个特定隧道的上下文而触发，表明单个用户的某条隧道出了问题。UPF通过PFCP Session Report Request（会话报告请求）上报此事件。而用户面路径故障是节点级的，由UPF自身检测到与某个远端IP地址之间的连接中断，影响所有经过该路径的会话。UPF通过PFCP Node Report Request（节点报告请求）上报此事件，一条消息即可通告所有受影响的CP功能。

Q3：当SMF收到UPF上报的“用户面不活跃报告”（UPIR）后，PDU会话会被立即删除吗？ A3：通常不会。收到UPIR报告表示用户在一段时间内没有数据收发，但这不等于用户要终止会话。SMF的标准做法是触发AN Release流程，释放用户面连接（如N3隧道和无线RRC连接）以节省无线侧资源，同时PDU会话本身在核心网（SMF、UPF）中仍然保持激活状态（即CM-IDLE状态）。这样，当用户再次需要使用数据时，可以通过一个快速的Service Request流程重新激活用户面，而无需经历完整的PDU会话重建过程。

Q4：会话级和PDR级的不活跃检测在PFCP实现上有什么不同？ A4：实现机制不同。会话级不活跃检测是通过在PFCP Session Establishment/Modification Request消息的顶层直接携带一个User Plane Inactivity Timer IE来实现的，其作用域是整个PFCP会话。而PDR级不活跃检测则是通过创建一个URR（用量上报规则），在URR内部包含User Plane Inactivity Timer IE，然后将这个URR与一个或多个PDR关联起来实现的，其作用域仅限于被关联的PDR。

Q5：一个URR可以同时用于流量统计和PDR级不活跃检测吗？ A5：可以。URR的设计非常灵活，它的行为由Reporting Triggers IE定义。一个URR可以同时设置多种触发器，例如，可以同时设置VOLTH（流量阈值）和UPINT（用户面不活跃定时器）。这样，这个URR既可以用于常规的流量统计（当达到阈值时上报），也可以在关联的PDR上没有流量时触发不活跃报告，实现了多种监控目的的统一配置。😊

关系图谱