UPF假活：PFCP心跳排查战

概述：5G SA核心网割接后的深夜，PDU会话建立成功率突然跳水，网元看起来“活着”，用户却大面积上不了网。本文以一次脱敏复盘案例为主线，拆解SMF与UPF之间的N4/PFCP心跳机制，完整还原“告警收敛→信令统计→双端抓包→传输比对”的四步排查法，最终实锤根因：防火墙漏放行PFCP回程报文。文章同步给出PFCP关键参数表、修复前后的配置对比，以及一套可直接落地的核心网抓包工具链与变更军规。所有协议细节锚定3GPP TS 29.244与Wireshark官方文档，案例数字为脱敏量级还原。

目录

• 一、深夜惊魂：会话成功率跳水的时间线
• 二、先补课：PFCP——SMF与UPF之间的心跳线
• 三、排查四步法：从告警面打到抓包面
• 四、根因实锤：一条没放行的回程路
• 五、修复与验证：参数怎么调，监控怎么补
• 六、经验沉淀：核心网运维的抓包工具链与四条军规
• 参考来源

一、深夜惊魂：会话成功率跳水的时间线

先交代背景。这是某省运营商5G SA核心网的一次夜间传输割接：按等保整改要求，要在SMF与UPF之间插入两台防火墙做安全域隔离。割接窗口选在凌晨零点，话务低谷，方案评审都过了，一切看起来很 routine。

以下案例为笔者亲历项目的复盘改写，局点、网元型号与数据均已脱敏，数字保留量级以还原现场。

这个案例最有教学价值的地方在于它的“迷惑性”：UPF进程活着、告警平台上它在线、KPI只跌不崩——典型的“假活”。老用户已建立的会话大部分不受影响，掉的是新建会话；而新建会话失败会触发终端反复重试，表现为用户“刷不出网页、打不开App”，投诉在半小时后才姗姗来迟。如果只盯网元告警，你会在错误的方向上耗一整夜。

二、先补课：PFCP——SMF与UPF之间的心跳线

要看懂这个案子，得先理解N4接口上的PFCP协议。

5G核心网把“控制”与“转发”分离（CUPS思想），SMF管脑子，UPF管手脚。两者之间的控制通道就是N4接口，跑的协议叫PFCP（Packet Forwarding Control Protocol，包转发控制协议）。它的标准化载体是3GPP TS 29.244，标题就叫《Interface between the Control Plane and the User Plane nodes》，2016年9月随Rel-14立项（对应CUPS工作项），由CT4工作组负责，2026年6月的CT#112会议上刚更新了Rel-20的20.0.0版本——一个快十岁、仍在活跃演进的老兵。

PFCP有几个关键设计，直接决定了后面排查的走向：

第一，它跑在UDP上，注册端口8805。 UDP无连接、无内建保活，协议层自己设计了心跳机制来维持"PFCP Association"（PFCP关联）。

第二，心跳机制是生命线。 SMF与UPF周期互发Heartbeat Request/Response，每条消息携带24比特的Sequence Number（序号）用于请求响应匹配，同时携带Recovery Time Stamp（恢复时间戳）——对端重启后时间戳会变，本端据此发现“对方重启过”，删除旧会话并重建关联。如果连续多次心跳Request等不到Response，本端就判定关联失效，极端情况下会触发会话级清理。这正是“假活”的机关：只要心跳丢得够多，SMF眼中的UPF就是“死了”，哪怕UPF进程其实活得好好的。

第三，除了心跳，PFCP还内建了负荷与过载控制。 Wireshark的PFCP字段参考里能直接看到pfcp.cp_function_features.load（LOAD，负荷控制）和pfcp.cp_function_features.ovrl（OVRL，过载控制）等特性标志；还定义了User Plane Path Failure Report（用户面路径故障上报），让UPF能主动把GTP-U路径质量问题报告给SMF。这套设计意味着：路径劣化本来是有"吹哨人"机制的，前提是报文能通。

第四，会话用F-SEID标识。 SMF在建会话时分配F-SEID（含IP地址+会话ID），UPF据此把每一条PFCP会话与用户面对应起来。排查时按F-SEID过滤信令跟踪，是最快的定位手段之一。

下面这张参数表，建议存进运维手册：

心跳周期设多长是个平衡术：设短了，传输抖一下就误判；设长了，真故障发现变慢。常见工程配置在10秒量级，但具体取值以各厂家官方文档为准。

三、排查四步法：从告警面打到抓包面

复盘整个过程，可以提炼成一张排查流程图，核心思想是：告警面圈范围→信令面定接口→抓包面看报文→传输面找凶手，每一层都为下一层缩小包围圈。

flowchart TD
  A["凌晨告警：PDU会话建立成功率跳水"] --> B["第一步：圈定故障面"]
  B --> B1["受影响UPF清单与时间窗"]
  A --> C["第二步：网管信令跟踪"]
  C --> C1["N4接口统计：会话建立超时为主"]
  C1 --> D["第三步：SMF与UPF双端镜像抓包"]
  D --> D1["SMF侧：Request重传无Response"]
  D --> D2["UPF侧：Response已正常发出"]
  D1 --> E["第四步：比对防火墙drop日志"]
  D2 --> E
  E --> F{"回程报文是否被丢"}
  F -->|是| G["根因：策略漏放行8805回程"]
  F -->|否| H["根因：链路丢包或哈希震荡"]
  G --> I["修复：补放行策略"]
  H --> J["修复：换光模块并调心跳参数"]
  I --> K["验证：拨测恢复与长曲线观察"]
  J --> K

第一步：圈定故障面，别急着重启。 拨测系统0:12告警后，先做的是把“哪些UPF、哪些SMF、哪个时间窗”三要素圈出来。结论是只有割接涉及的两组SMF-UPF对受影响，同池其他网元正常——这就把“全网性故障”排除了，矛头直指变更。凌晨排查的铁律：故障范围与最近变更加交集，命中就先回退再深究。但当时评估回退防火墙需要重新变更审批，耗时比定位还长，于是选择继续往下打。

第二步：网管信令跟踪，定接口。 在网管上对失败呼叫做信令回放，按失败原因分类：N4会话建立超时占了绝对大头，而不是N11（SMF-AMF）或N7（SMF-PCF）接口报错。接口定位到N4，就锁定了SMF与UPF之间的通道。这里有个细节：信令跟踪显示SMF发出了PFCP Session Establishment Request，但迟迟等不到Response，与拨测失败时间点吻合。

第三步：双端抓包，看报文。 单端抓包会骗人，双端抓包才见真相。在SMF和UPF侧同时镜像抓包，用Wireshark分析——它对PFCP的支持很完善，官方字段参考里pfcp.recovery_time_stamp、pfcp.sequence_number、pfcp.cause、pfcp.response_time等字段一应俱全（PFCP解析能力从Wireshark 2.6版本就开始提供）。两侧包一对比，结论非常清晰：

• SMF侧：Heartbeat Request与Session Establishment Request按Sequence Number重传了多次，无任何Response；
• UPF侧：Response报文明明白白发出来了，序号与请求一一对应。

sequenceDiagram
  participant S as SMF
  participant F as 防火墙与传输
  participant U as UPF
  S->>F: Heartbeat Request 序号N
  F->>U: 去程放行 正常转发
  U-->>F: Heartbeat Response 序号N
  F-->>S: 回程未放行 静默丢弃
  Note over S: 连续多次无响应 判关联失效
  S->>U: 会话清理 触发批量告警

第四步：传输面比对，找凶手。 “两侧都发了、中间收不到”，凶手只能在传输路径上。调取防火墙会话日志与drop日志，按源目IP和端口8805过滤——drop记录与丢包时间点严丝合缝地吻合。同时复盘还发现第二处隐患：ECMP等价路径中的一条链路光模块收光功率劣化，存在0.1%量级的持续丢包，叠加当时较紧的心跳判死阈值，偶发心跳抖动被放大成关联震荡。一处配置错、一处硬件病，撞在同一个夜里。

四、根因实锤：一条没放行的回程路

把根因摊开讲透。

直接根因：防火墙安全策略漏放行PFCP回程报文。 割接方案里，防火墙策略按“安全域互访矩阵”配置，写策略的同事按TCP业务思维配了显式放行，但PFCP是UDP 8805，且只配了SMF侧发起的方向，UPF侧的Response回程没有显式条目，被默认deny静默丢弃。UDP防火墙处理有个特性：会话表项依赖首包方向建立，去程放通、回程无策略的流，会被直接丢弃。于是形成完美陷阱——去程通、回程断、无拒绝响应（静默丢包），SMF只能靠超时与重传慢慢“感觉到不对”。

为什么KPI只跌不崩？ 因为关联失效的判定需要连续多次心跳超时，会话清理与重建有窗口期；部分时段心跳恰好靠最后重传续上命，就表现为成功率“抽风式”抖动而非断崖。这种介于“好”与“坏”之间的灰色状态，是夜间故障最难缠的形态。

放大因素：心跳判死阈值偏紧。 该局点当时配置的判死次数偏保守（2次），对0.1%量级的链路丢包几乎没有容错。传输抖一下，误判就发生一次；误判一次，SMF与UPF间的会话状态就震荡一轮。协议层面标准允许各实现自行设定心跳周期与判死门限，具体行为以各厂家官方文档为准——但无论哪家，“紧心跳+劣链路”的组合都是定时炸弹。

为什么常规告警没第一时间抓到？ 因为告警规则是“每次心跳失败即上报告警”，0点后零星的抖动告警被淹没在夜班的例行噪音里，直到拨测成功率告警才把事情顶到台面。告警治本的教训在上一篇讲过：要盯状态变迁，不要盯单次失败——这个原则在N4接口上同样成立。

五、修复与验证：参数怎么调，监控怎么补

应急处置只用了两步：防火墙双向显式放行UDP 8805；受影响SMF-UPF对逐对触发关联重建。02:30成功率回到99.5%基线。但真正有价值的是复盘后的长效整改：

验证阶段做了三件事：一是恢复后连续72小时观察pfcp.response_time维度的长曲线，确认无周期性毛刺；二是人为制造一次防火墙策略回退演练（维护窗口内），验证新告警规则能在判死瞬间准确上报告警；三是把本次的抓包文件归档为“基线包”，供下次变更比对——健康状态的PFCP长什么样，必须先有标本，出事才知差异。

六、经验沉淀：核心网运维的抓包工具链与四条军规

这个案子出在5G SA的N4接口上，但方法论适用于整张核心网。沉淀成可复用的资产，是复盘的最终目的。

工具链分四层：

1. 采集层：网元侧镜像口+专业抓包设备（支持长时间滚存），关键接口（N4/N2/N11/S1-MME/GTP-U）平时就布好采集点，故障时“开箱即抓”；
2. 分析层：Wireshark做单包深挖（PFCP、NGAP、NAS、GTP-U解析成熟），配合tshark脚本做批量统计——比如一条命令统计所有无响应的PFCP请求；
3. 信令层：网管信令跟踪按用户号码/IMSI/F-SEID回放全流程，负责“快”，Wireshark负责“深”，两者互为补充；
4. 验证层：自动化拨测（PDU会话建立、注册、PDU释放三板斧）+ KQI长曲线，负责“事后看得见”。

四条军规，建议写进变更检查单：

军规一：涉传输变更，核心网必抓基线包。 任何在核心网之间插设备、调策略、动路由的割接，割接前后各抓一份对照包。本次故障如果00:12就有基线对比，00:20就能锁死防火墙，省一小时。

军规二：UDP控制面协议纳入防火墙策略核对清单。 PFCP（8805）、GTP-U（2152）、SBI相关UDP面、Diameter……逐协议列端口、逐方向确认放行，并明确要求“禁用静默丢弃、drop必须留日志”。静默丢包是排查天敌——它不给任何反馈，全靠超时猜。

军规三：心跳类参数遵循“松紧适度、整体一致”。 判死阈值过紧，传输毛刺放大成业务震荡；过松，真故障雪崩式蔓延。调整后必须做一次主动注入式演练（人为断链验证判死时效），确认参数与预案匹配。

军规四：告警只报状态变迁，不报单次失败。 心跳失败是症状，关联失效才是事件。告警规则按“状态机迁移”设计，配合拨测KQI兜底，让夜班先看到“真问题”，再看细节。

最后说点感悟。5G核心网服务化之后，大家的注意力都被SBA、HTTP/2、NRF服务发现吸走了，容易忘了N4上还跑着一个UDP时代的“老古董”。但恰恰是PFCP这种无连接、静默丢包、靠心跳续命的协议，对传输层的 sins（丢包、不对称、策略遗漏）最敏感。核心网排障二十年，我的一条底层经验始终没变：当两个网元都说自己发了，答案永远在中间的路上。 抓包，双端抓，别猜。

参考来源

1. 3GPP TS 29.244 «Interface between the Control Plane and the User Plane nodes» — PFCP协议的官方规范主页：Rel-14于2016年立项、CT4工作组负责、CUPS工作项背景，2026年6月CT#112发布Rel-20 20.0.0版本（本文协议机制、心跳与序号设计均以此为锚）
2. Wireshark Display Filter Reference: PFCP — Wireshark官方PFCP字段参考：recovery_time_stamp、sequence_number、response_time、LOAD/OVRL特性标志、User Plane Path Failure Report等字段均出自此页，佐证Wireshark自2.6版本起原生解析PFCP
3. IANA Service Name and Transport Protocol Port Number Registry — PFCP注册端口8805/UDP的官方登记处

本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵爱卫生（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。

[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。