OmniUPF 操作指南

概述

OmniUPF（基于 eBPF 的用户平面功能）是一种高性能的 5G/LTE 用户平面功能，提供运营商级的数据包转发、QoS 强制执行和移动网络的流量管理。基于 Linux eBPF（扩展伯克利包过滤器）技术构建，并增强了全面的管理能力，OmniUPF 提供了 5G SA、5G NSA 和 LTE 网络所需的核心数据包处理基础设施。

什么是用户平面功能？

用户平面功能（UPF）是 3GPP 标准化的网络元素，负责 5G 和 LTE 网络中的数据包处理和转发。它提供：

高速数据包转发：在移动设备和数据网络之间
服务质量（QoS）：对不同流量类型的强制执行
基于数据包过滤器和规则的流量检测和路由
使用报告：用于计��和分析
数据包缓冲：用于移动性和会话管理场景
合法拦截：支持合规性

OmniUPF 实现了 3GPP TS 23.501（5G）和 TS 23.401（LTE）中定义的完整 UPF 功能，提供了一个完整的、生产就绪的用户平面解决方案，使用 Linux 内核 eBPF 技术以实现最大性能。

OmniUPF 关键能力

数据包处理：

完全符合 3GPP 标准的用户平面数据包处理
基于 eBPF 的数据路径，提供内核级性能
GTP-U（通用分组无线服务隧道协议）封装和解封装
支持 IPv4 和 IPv6 的接入和数据网络
XDP（快速数据路径）用于超低延迟处理
多线程数据包处理

QoS 和流量管理：

带宽管理的 QoS 强制执行规则（QER）
流量分类的包检测规则（PDR）
路由决策的转发动作规则（FAR）
针对特定应用的服务数据流（SDF）过滤
用于流量跟踪和计费的使用报告规则（URR）

控制和管理：

PFCP（数据包转发控制协议）接口与 SMF/PGW-C
用于监控和诊断的 RESTful API
实时统计和指标
eBPF 映射容量监控
基于 Web 的控制面板

性能特性：

通过 eBPF 实现零拷贝数据包处理
内核级数据包转发（无用户空间开销）
多核可扩展性
支持硬件加速的卸��能力
针对云原生部署进行了优化

有关详细的控制面板使用，请参见 Web UI 操作。

理解用户平面架构

OmniUPF 是一个统一的用户平面解决方案，为 5G 独立（SA）、5G 非独立（NSA）和 4G LTE/EPC 网络提供运营商级的数据包转发。OmniUPF 是一个单一产品，可以同时作为：

UPF（用户平面功能） - 5G/NSA 用户平面（通过 N4/PFCP 由 OmniSMF 控制）
PGW-U（PDN 网关用户平面） - 4G EPC 网关到外部网络（通过 Sxc/PFCP 由 OmniPGW-C 控制）
SGW-U（服务网关用户平面） - 4G EPC 服务网关（通过 Sxb/PFCP 由 OmniSGW-C 控制）

OmniUPF 可以在 任何组合 模式下运行：

仅 UPF：纯 5G 部署
PGW-U + SGW-U：组合 4G 网关（典型 EPC 部署）
UPF + PGW-U + SGW-U：同时支持 4G 和 5G（迁移场景）

所有模式使用相同的基于 eBPF 的数据包处理引擎和 PFCP 协议，无论作为 UPF、PGW-U、SGW-U，还是同时作为三者，均提供一致的高性能。

5G 网络架构（SA 模式）

OmniUPF 解决方案位于 5G 网络的数据平面，提供连接移动设备与数据网络和服务的高速数据包转发层。

4G LTE/EPC 网络架构

OmniUPF 还支持 4G LTE 和 EPC（演进分组核心）部署，视网络架构的不同，作为 OmniPGW-U 或 OmniSGW-U 运行。

组合 PGW-U/SGW-U 模式（典型 4G 部署）

在此模式下，OmniUPF 同时作为 SGW-U 和 PGW-U，由不同的控制平面功能控制。

分离的 SGW-U 和 PGW-U 模式（漫游/多站点）

在漫游或多站点部署中，可以部署两个独立的 OmniUPF 实例 - 一个作为 SGW-U，另一个作为 PGW-U。

N9 循环回路模式（单实例 SGWU+PGWU）

对于简化的部署，OmniUPF 可以在 单个实例上运行 SGWU 和 PGWU 角色，并在 eBPF 中完全处理 N9 循环回路。

关键特性：

✅ 亚微秒 N9 延迟 - 完全在 eBPF 中处理，从不触及网络
✅ 40-50% CPU 减少 - 单次 XDP 处理与两个独立实例相比
✅ 简化部署 - 一个实例，一个配置文件
✅ 自动检测 - 当 n3_address = n9_address 时，启用循环回路
✅ 完全符合 3GPP 标准 - 标准 PFCP 和 GTP-U 协议

配置：

# OmniUPF config.yml
interface_name: [eth0]
n3_address: "10.0.1.10"      # S1-U 接口 IP
n9_address: "10.0.1.10"      # 相同 IP 启用 N9 循环回路
pfcp_address: ":8805"         # SGWU-C 和 PGWU-C 都在此连接

何时使用：

边缘计算部署（最小化延迟）
成本受限的环境（单台服务器）
实验室/测试（简化设置）
小型到中型部署（< 100K 订阅者）

何时不使用：

需要地理冗余（SGWU 和 PGWU 在不同位置）
法规要求分离网关
大规模（> 1M 订阅者）

有关完整的详细信息、配置示例、故障排除和性能指标，请参见 N9 ��环回路操作指南。

用户平面功能在网络中的工作原理

用户平面功能（OmniUPF、OmniPGW-U 或 OmniSGW-U）作为转发平面，由相应的控制平面控制：

会话建立
- 5G：OmniSMF 通过 N4 接口与 OmniUPF 建立 PFCP 关联
- 4G：OmniPGW-C 或 OmniSGW-C 通过 Sxb/Sxc 与 OmniPGW-U/OmniSGW-U 建立 PFCP 关联
- 控制平面为每个 UE PDU 会话（5G）或 PDP 上下文（4G）创建 PFCP 会话
- 用户平面通过 PFCP 接收 PDR、FAR、QER 和 URR 规则
- eBPF 映射填充转发规则
上行数据包处理（UE → 数据网络）
- 5G：数据包通过 N3 接口从 gNB 到达，带有 GTP-U 封装
- 4G：数据包通过 S1-U 接口（SGW-U）或 S5/S8 接口（PGW-U）从 eNodeB 到达，带有 GTP-U 封装
- 用户平面根据 TEID 匹配上行数据包与 PDR
- eBPF 程序应用 QER（速率限制、标记）
- FAR 确定转发动作（转发、丢弃、缓冲、重复）
- 移除 GTP-U 隧道，数据包转发到 N6（5G）或 SGi（4G）接口
- URR 跟踪数据包和字节计数以进行计费
下行数据包处理（数据网络 → UE）
- 5G：数据包通过 N6 接口作为原生 IP 到达
- 4G：数据包通过 SGi 接口作为原生 IP 到达
- 用户平面根据 UE IP 地址匹配下行数据包与 PDR
- SDF 过滤器可能进一步根据端口、协议或应用程序分类流量
- FAR 确定 GTP-U 隧道和转发参数
- 使用适当的 TEID 添加 GTP-U 封装
- 5G：数据包转发到 N3 接口朝向 gNB
- 4G：数据包转发到 S1-U（SGW-U）或 S5/S8（PGW-U）朝向 eNodeB
移动性和切换
- 5G：在切换场景中，OmniSMF 更新 PDR/FAR 规则
- 4G：OmniSGW-C/OmniPGW-C 在 eNodeB 之间切换或 TAU（跟踪区域更新）期间更新规则
- 用户平面在路径切换期间可能缓冲数据包
- 在基站之间无缝过渡，无数据包丢失

与控制平面的集成（4G 和 5G）

OmniUPF 通过标准的 3GPP 接口与 5G 和 4G 控制平面功能集成：

5G 接口

接口	从 → 到	目的	3GPP 规范
N4	OmniSMF ↔ OmniUPF	PFCP 会话建立、修改、删除	TS 29.244
N3	gNB → OmniUPF	来自 RAN 的用户平面流量（GTP-U）	TS 29.281
N6	OmniUPF → 数据网络	到 DN 的用户平面流量（原生 IP）	TS 23.501
N9	OmniUPF ↔ OmniUPF	漫游/边缘的 UPF 之间通信	TS 23.501

4G/EPC 接口

接口	从 → 到	目的	3GPP 规范
Sxb	OmniSGW-C ↔ OmniUPF（SGW-U 模式）	服务网关的 PFCP 会话控制	TS 29.244
Sxc	OmniPGW-C ↔ OmniUPF（PGW-U 模式）	PDN 网关的 PFCP 会话控制	TS 29.244
S1-U	eNodeB → OmniUPF（SGW-U 模式）	来自 RAN 的用户平面流量（GTP-U）	TS 29.281
S5/S8	OmniUPF（SGW-U）↔ OmniUPF（PGW-U）	网关之间的用户平面（GTP-U）	TS 29.281
SGi	OmniUPF（PGW-U 模式）→ PDN	到数据网络的用户平面流量（原生 IP）	TS 23.401

注意：所有 PFCP 接口（N4、Sxb、Sxc）使用 TS 29.244 中定义的相同 PFCP 协议。接口名称不同，但协议和消息格式是相同的。

UPF 组件

eBPF 数据路径

eBPF 数据路径是运行在 Linux 内核中的核心数据包处理引擎，以实现最大性能。

核心功能：

GTP-U 处理：GTP-U 隧道的封装和解封装
数据包分类：根据 TEID、UE IP 或 SDF 过滤器匹配数据包
QoS 强制执行：根据 QER 规则应用速率限制和数据包标记
转发决策：执行 FAR 动作（转发、丢弃、缓冲、重复、通知）
使用跟踪：为基于流量的计费递增 URR 计数器

eBPF 映射：数据路径使用 eBPF 映射（内核内存中��哈希表）进行规则存储：

映射名称	目的	键	值
`uplink_pdr_map`	上行 PDR	TEID（32 位）	PDR 信息（FAR ID、QER ID、URR IDs）
`downlink_pdr_map`	下行 PDR（IPv4）	UE IP 地址	PDR 信息
`downlink_pdr_map_ip6`	下行 PDR（IPv6）	UE IPv6 地址	PDR 信息
`far_map`	转发规则	FAR ID	转发参数（动作、隧道信息）
`qer_map`	QoS 规则	QER ID	QoS 参数（MBR、GBR、标记）
`urr_map`	使用跟踪	URR ID	流量计数器（上行、下行、总计）
`sdf_filter_map`	SDF 过滤器	PDR ID	应用过滤器（端口、协议）

性能特性：

零拷贝：数据包完全在内核空间处理
XDP 支持：在网络驱动程序级别附加以实现亚微秒延迟
多核：在 CPU 核心之间扩展，支持每 CPU 映射
容量：在 eBPF 映射中可容纳数百万个 PDR/FAR（受限于内核内存）

有关容量监控，请参见容量管理。

PFCP 接口处理程序

PFCP 接口实现 3GPP TS 29.244，用于与 SMF 或 PGW-C 的通信。

核心功能：

关联管理：PFCP 心跳和关联设置/释放
会话生命周期：创建、修改和删除 PFCP 会话
规则安装：将 PFCP 信息元素转换为 eBPF 映射条目
事件报告：通知 SMF 使用阈值、错误或会话事件

支持的 PFCP 消息：

消息类型	方向	目的
关联设置	SMF → UPF	建立 PFCP 控制关联
关联释放	SMF → UPF	拆除 PFCP 关联
心跳	双向	保持关联活跃
会话建立	SMF → UPF	创建新 PDU 会话，包含 PDR/FAR/QER/URR
会话修改	SMF → UPF	更新移动性、QoS 变更的规则
会话删除	SMF → UPF	移除会话及所有关联规则
会话报告	UPF → SMF	报告使用情况、错误或事件

支持的信息元素（IE）：

创建 PDR、FAR、QER、URR
更新 PDR、FAR、QER、URR
移除 PDR、FAR、QER、URR
数据包检测信息（UE IP、F-TEID、SDF 过滤器）
转发参数（网络实例、外部头创建）
QoS 参数（MBR、GBR、QFI）
使用报告触发器（流量阈值、时间阈值）

REST API 服务器

REST API 提供对 UPF 状态和操作的编程访问。

核心功能：

会话监控：查询活动的 PFCP 会话和关联
规则检查：查看 PDR、FAR、QER、URR 配置
统计信息：检索数据包计数器、路由统计、XDP ��计
缓冲管理：查看和控制数据包缓冲
映射信息：监控 eBPF 映射的使用情况和容量

API 端点：（共 34 个端点）

类别	端点	描述
健康	`/health`	健康检查和状态
配置	`/config`	UPF 配置
会话	`/pfcp_sessions`, `/pfcp_associations`	PFCP 会话/关联数据
PDRs	`/uplink_pdr_map`, `/downlink_pdr_map`, `/downlink_pdr_map_ip6`, `/uplink_pdr_map_ip6`	数据包检测规则
FARs	`/far_map`	转发动作规则
QERs	`/qer_map`	QoS 强制执行规则
URRs	`/urr_map`	使用报告规则
缓冲	`/buffer`	数据包缓冲状态和控制
统计	`/packet_stats`, `/route_stats`, `/xdp_stats`, `/n3n6_stats`	性能指标
容量	`/map_info`	eBPF 映射容量和使用情况
数据平面	`/dataplane_config`	N3/N9 接口地址

有关 API 详细信息和使用，请参见 监控指南。

Web 控制面板

Web 控制面板提供 UPF 监控和管理的实时仪表板。

特性：

会话视图：浏览活动 PFCP 会话，显示 UE IP、TEID 和规则计数
规则管理：查看和管理所有会话中的 PDR、FAR、QER 和 URR
缓冲监控：跟踪缓冲的数据包并根据 FAR 控制缓冲
统计仪表板：实时数据包、路由、XDP 和 N3/N6 接口统计
容量监控：eBPF 映射使用情况，带有颜色编码的容量指示器
配置视图：显示 UPF 配置和数据平面地址
日志查看器：实时日志流以进行故障排除

有关详细的 UI 操作，请参见 Web UI 操作指南。

PFCP 协议与 SMF 集成

PFCP 关联

在会话创建之前，SMF 必须与 UPF 建立 PFCP 关联。

关联生命周期：

关键点：

每个 SMF 与 UPF 建立一个关联
UPF 通过节点 ID（FQDN 或 IP 地址）跟踪关联
心跳消息保持关联的活跃性
如果释放关联，则删除该关联下的所有会话

有关查看关联的信息，请参见 ��话视图。

SMF 重启检测和孤立会话清理

OmniUPF 自动检测 SMF 重启并根据 3GPP TS 29.244 规范清理孤立会话。

工作原理：

当 SMF 建立 PFCP 关联时，它提供一个 恢复时间戳，指示其启动时间。OmniUPF 为每个关联存储此时间戳。如果 SMF 重启：

SMF 丢失内存中的所有会话状态
SMF 重新与 UPF 建立 PFCP 关联
SMF 发送 新的恢复时间戳（与之前不同）
UPF 检测到时间戳变化 = SMF 重启
UPF 自动删除 所有孤立会话，来自旧的 SMF 实例
SMF 为活动用户创建新的会话

重启检测流程：

日志示例：

当 SMF 重启时，您会看到：

WARN: 与 NodeID: smf-1 和地址: 192.168.1.10 的关联已存在
WARN: SMF 恢复时间戳已更改（旧：2025-01-15T10:00:00Z，新：2025-01-15T10:30:15Z） - SMF 重启，删除 245 个孤立会话
INFO: 删除孤立会话 2（LocalSEID）由于 SMF 重启
INFO: 删除孤立会话 3（LocalSEID）由于 SMF 重启
...
INFO: 删除孤立会话 246（LocalSEID）由于 SMF 重启

重要说明：

隔离：仅删除重启的 SMF 的会话。其他 SMF 关联及其会话 不受影响。
时间戳比较：如果恢复时间戳相同，则会话保留（SMF 重新连接而未重启）。
3GPP 合规性：此行为由 3GPP TS 29.244 第 5.22.2 节规定：

“如果 CP 功能的恢复时间戳自上次关联设置以来发生变化，UP 功能应认为 CP 功能已重启，并应删除与该 CP 功能关联的所有 PFCP 会话。”

有关故障排除孤立��话的信息，请参见孤立会话检测。

GTP-U 错误指示处理

OmniUPF 根据 3GPP TS 29.281 规范处理来自下游对等方（PGW-U、SGW-U、eNodeB、gNodeB）的 GTP-U 错误指示消息。

什么是错误指示：

当 OmniUPF 将 GTP-U 数据包转发到远程对等方（例如，SGW-U 部署中的 PGW-U）时，如果对等方不识别 TEID（隧道端点标识符），则可能会发送 错误指示。这表示：

远程对等方已重启并丢失隧道状态
远程端未曾创建隧道（配置不匹配）
远程端已删除隧道

工作原理：

UPF 转发数据包 → 发送带有 TEID X 的 GTP-U 数据包到远程对等方（端口 2152）
远程对等方不识别 TEID X → 在其隧道表中查找 TEID，未找到
远程对等方发送错误指示 → GTP-U 消息类型 26，包含错误 TEID 的 IE
UPF 接收错误指示 → 解析消息以提取 TEID X
UPF 查找受影响的会话 → 搜索所有会话以查找转发到 TEID X 的 FAR
UPF 删除会话 → 从 eBPF 映射和 PFCP 状态中移除会话
UPF 更新指标 → 为监控递增 Prometheus 计数器

错误指示流程：

数据包格式（3GPP TS 29.281 第 7.3.1 节）：

GTP-U 错误指示：
┌─────────────────────────────────────────┐
│ GTP-U 头部（12 字节）                   │
├──────────────────────────────────��──────┤
│ 版本、PT、标志         │ 0x32        │
│ 消息类型              │ 26 (0x1A)   │
│ 长度                  │ 9 字节      │
│ TEID                  │ 0 (始终)    │
│ 序列号                │ 变化        │
│ N-PDU 编号            │ 0           │
│ 下一个扩展头部       │ 0           │
├─────────────────────────────────────────┤
│ IE: TEID 数据 I（5 字节）               │
├─────────────────────────────────────────┤
│ 类型                  │ 16 (0x10)   │
│ 错误 TEID             │ 4 字节      │
└─────────────────────────────────────────┘

何时重要：

场景 1：PGW-U 在 S5/S8 GTP 架构中重启

SGW-U（OmniUPF）将 S5/S8 流量转发到 PGW-U
PGW-U 重启并丢失所有 S5/S8 隧道状态
SGW-U 继续转发到旧 TEID
PGW-U 发送错误指示
SGW-U 自动停止使用死隧道

场景 2：对等 UPF 在 N9 架构中重启

UPF-1（OmniUPF）将 N9 流量转发到 UPF-2
UPF-2 重启
UPF-1 接收错误指示
UPF-1 清理会话

日志示例：

当接收到错误指示时：

WARN: 从 192.168.50.10:2152 接收到 GTP-U 错误指示，TEID 0x12345678 - 远程对等方不识别此 TEID
WARN: 找到会话 LocalSEID=42，FAR GlobalId=1 转发到错误 TEID 0x12345678，来自对等方 192.168.50.10
INFO: 删除会话 LocalSEID=42，因来自 192.168.50.10 的 TEID 0x12345678 的 GTP-U 错误指示
WARN: 删除 1 个会话，因来自 192.168.50.10 的 TEID 0x12345678 的 GTP-U 错误指示

Prometheus 指标：

监控错误指示活动，按对等方和节点粒度：

# 从对等方接收到的错误指示总数
upf_buffer_listener_error_indications_received_total{node_id="pgw-u-1",peer_address="192.168.50.10"}

# 由于错误指示删除的会话
upf_buffer_listener_error_indication_sessions_deleted_total{node_id="pgw-u-1",peer_address="192.168.50.10"}

# 发送的错误指示（对于未知的传入 TEID）
upf_buffer_listener_error_indications_sent_total{node_id="enodeb-1",peer_address="10.60.0.1"}

指标标签：

node_id：来自关联的 PFCP 节点 ID（或在没有关联时为“未知”）
peer_address：远程对等方的 IP 地址

这些指标有助于识别有问题的对等方并跟踪每个控制平面节点的错误指示模式。

重要说明：

自动清理：无需操作员干预 - 会话会自动删除
TEID 匹配：仅删除转发到确切错误 TEID 的会话
每对等方隔离：来自一个对等方的错误指示仅影响转发到该对等方的会话
多个会话：如果多个会话转发到同一死 TEID，所有会话都会被删除
与恢复时间戳互补：
- 恢复时间戳检测 = 主动（在关联设置期间检测重启）
- 错误指示处理 = 被动（在流量流动时检测死隧道）
格式错误的数据包处理：无效的错误指示被记录并忽略（不删除会话）

有关故障排除错误指示的信息，请参见 GTP-U 错误指示调试。

PFCP 会话创建

当 UE 建立 PDU 会话（5G）或 PDP 上下文（LTE）时，SMF 在 UPF 上创建 PFCP 会话。

会话建立流程：

典型会话内容：

上行 PDR：匹配 N3 TEID，通过 FAR 转发到 N6
下行 PDR：匹配 UE IP 地址，通过 FAR 转发到 N3，带有 GTP-U 封装
FAR：转发参数（外部头创建、网络实例）
QER：QoS 限制（MBR、GBR）和数据包标记（QFI）
URR：用于计费的流量报告（可选）

PFCP 会话修改

SMF 可以修改会话以应对移动事件（切换）、QoS 变化或服务更新。

常见修改场景：

切换（基于 N2）
- 使用新的 gNB 隧道端点（F-TEID）更新上行 FAR
- 可选地在路径切换期间缓冲数据包
- 在准备就绪时刷新缓冲区
QoS 变更
- 使用新的 MBR/GBR 值更新 QER
- 可在 PDR 中添加/删除 SDF 过滤器以实现特定应用的 QoS
服务更新
- 为额外流量流添加新的 PDR
- 修改 FAR 以进行路由更改

会话修改流程：

有关规则管理的信息，请参见规则管理指南。

PFCP 会话删除

当 PDU 会话被释放时，SMF 删除 UPF 上的 PFCP 会话。

会话删除流程：

执行的清理：

移除所有 PDR（上行和下行）
移除所有 FAR、QER、URR
清除数据包缓冲
发送最终使用报告给 SMF 以进行计费

常见操作

OmniUPF 通过其基于 Web 的控制面板和 REST API 提供全面的操作能力。本节涵盖常见操作任务及其重要性。

会话监控

理解 PFCP 会话：

PFCP 会话代表活动的 UE PDU 会话（5G）或 PDP 上下文（LTE）。每个会话包含：

本地和远程 SEID（会话端点标识符）
用于数据包分类的 PDR
用于转发决策的 FAR
QoS 强制执行的 QER（可选）
用于使用跟踪的 URR（可选）

关键会话操作：

查看所有会话，显示 UE IP 地址、TEID 和规则计数
按 IP 地址或 TEID 过滤会话
检查会话详细信息，包括完整的 PDR/FAR/QER/URR 配置
监控每个 PFCP 关联的会话计数

有关详细的会话程序，请参见会话视图。

规则管理

数据包检测规则（PDR）：

PDR 确定哪些数据包匹配特定的流量流。操作员可以：

查看上行 PDR，以 N3 接口的 TEID 为键
查看下行 PDR，以 UE IP 地址（IPv4 和 IPv6）为键
检查 SDF 过滤器以进行特定应用的分类
监控 PDR 计数和容量使用情况

转发动作规则（FAR）：

FAR 定义对匹配数据包的处理。操作员可以：

查看 FAR 动作（转发、丢弃、缓冲、重复、通知）
检查转发参数（外部头创建、目标）
监控每个 FAR 的缓冲状态
在故障排除期间切换缓冲特定 FAR

QoS 强制执行规则（QER）：

QER 应用带宽限制和数据包标记。操作员可以：

查看 QoS 参数（MBR、GBR、数据包延迟预算）
监控每个会话的活动 QER
检查 QFI 标记以进行 5G QoS 流

使用报告规则（URR）：

URR 跟踪计费的流量。操作员可以：

查看流量计数器（上行、下行、总字节）
监控使用阈值和报告触发器
检查所有会话中的活动 URR

有关规则操作的信息，请参见规则管理指南。

数据包缓冲

为什么缓冲对 UPF 至关重要

数据包缓冲是 UPF 最重要的功能之一，因为它防止在移动事件和会话重新配置期间发生数据包丢失。如果没有缓冲，用户在移动基站之间或网络条件变化时会经历掉线、下载中断和实时通信失败。

问题：移动期间的数据包丢失

在移动网络中，用户不断移动。当设备从一个基站移动到另一个基站时（切换），或者当��络需要重新配置数据路径时，会有一个关键窗口，在此窗口中，数据包正在传输，但新路径尚未准备好：

没有缓冲：在此关键窗口期间到达的 ~40ms 的数据包（可能是数千个）将被丢弃，导致：

TCP 连接停滞或重置（网页浏览、下载中断）
视频通话冻结或掉线（Zoom、Teams、WhatsApp 通话失败）
游戏会话断开（在线游戏、实时应用失败）
VoIP 通话出现间隙或完全掉线（电话通话中断）
下载失败并需要重新开始

有缓冲：OmniUPF 暂时保存数据包，直到新路径建立，然后无缝转发。用户体验到 零中断。

缓冲发生的时间

OmniUPF 在以下关键场景中缓冲数据包：

1. 基于 N2 的切换（5G）/基于 X2 的切换（4G）

当 UE 在基站之间移动时：

时间线：

T+0ms：旧路径仍然有效
T+10ms：SMF 告诉 UPF 缓冲（旧路径关闭，新路径尚未准备好）
T+10-50ms：关键缓冲窗口 - 数据包到达但无法转发
T+50ms：新路径��备就绪，SMF 告诉 UPF 转发
T+50ms+：UPF 将缓冲的数据包刷新到新路径，然后立即转发新数据包

没有缓冲：~40ms 的数据包（可能是数千个）将被丢弃。 有缓冲：零数据包丢失，无缝切换。

2. 会话修改（QoS 变更、路径更新）

当网络需要更改会话参数时：

QoS 升级/降级：用户从 4G 移动到 5G 覆盖（NSA 模式）
策略变更：企业用户进入公司校园（流量引导变化）
网络优化：核心网络将流量重新路由到更靠近的 UPF（ULCL 更新）

在修改期间，控制平面可能需要原子地更新多个规则。缓冲确保数据包不会在部分/不一致的规则集下转发。

3. 下行数据通知（空闲模式恢复）

当 UE 处于空闲模式（屏幕关闭、节省电池）并且下行数据到达时：

没有缓冲：触发通知的初始数据包将被丢弃，要求发送方重新传输（增加延迟）。 有缓冲：唤醒 UE 时立即交付触发 UE 的数据包。

4. 跨 RAT 切换（4G ↔ 5G）

当 UE 在 4G 和 5G 覆盖之间移动时：

架构变化（eNodeB ↔ gNB）
隧道端点变化（不同的 TEID 分配）
缓冲确保在 RAT 类型之间平滑过渡

OmniUPF 中的缓冲工作原理

技术机制：

OmniUPF 使用 两阶段缓冲架构：

eBPF 阶段（内核）：根据 FAR 动作标志检测需要缓冲的数据包
用户空间阶段：在内存中存储和管理缓冲的数据包

缓冲过程：

关键细节：

缓冲端口：UDP 端口 22152（数据包从 eBPF 发送到用户空间）
封装：数据包以 GTP-U 封装，FAR ID 作为 TEID
存储：每个 FAR 的内存中存储缓冲，带有元数据（时间戳、方向、数据包大小）
限制：
- 每个 FAR 限制：10,000 个数据包（默认）
- 全局限制：所有 FAR 的总计 100,000 个数据包
- TTL：30 秒（默认） - 超过 TTL 的数据包将被丢弃
清理：后台进程每 60 秒删除过期数据包

缓冲生命周期：

缓冲启用：SMF 通过 PFCP 会话修改设置 FAR 动作 BUFF=1（第 2 位）
数据包缓冲：eBPF 检测 BUFF 标志，封装数据包，发送到端口 22152
用户空间存储：缓冲管理器使用 FAR ID、时间戳、方向存储数据包
缓冲禁用：SMF 通过新转发参数设置 FAR 动作 FORW=1，BUFF=0
刷新缓冲：用户空间重放缓冲的数据包，使用新 FAR 规则（新隧道端点）
恢复正常：新数据包立即通过新路径转发

这对用户体验的重要性

现实世界影响：

场景	没有缓冲	有缓冲
切换期间的视频通话	通话冻结 1-2 秒，可能掉线	无缝，未中断
基站边缘的文件下载	下载失败，必须重新开始	下载持续不中断
移动中的在线游戏	连接掉线，游戏被踢	平稳游戏，无断开
汽车中的 VoIP 通话	通话在每次切换时掉线	清晰无缝，无掉线
火车上的视频流	视频缓冲，质量下降	平稳播放
笔记本电脑的移动热点	SSH 会话掉线，视频通话失败	所有连接保持

网络运营商的好处：

降低通话掉线率（CDR）：关键 KPI
提高客户满意度：用户不会注意到切换
降低支持成本：减少关于掉线的投诉
竞争优势：营销“最佳覆盖网络”

缓冲管理操作

操作员可以��过 Web UI 和 API 监控和控制缓冲：

监控：

查看每个 FAR ID 的缓冲数据包（计数、字节、年龄）
跟踪缓冲使用情况与限制（每个 FAR、全局）
对缓冲溢出发出警报或缓冲持续时间过长
识别卡住的缓冲（数据包缓冲 > TTL 阈值）

控制操作：

刷新缓冲：手动触发缓冲重放（故障排除）
清除缓冲：丢弃缓冲的数据包（清理卡住的缓冲）
调整 TTL：更改数据包过期时间
修改限制：增加每个 FAR 或全局缓冲容量

故障排除：

缓冲未刷新：检查 SMF 是否发送了 FAR 更新以禁用缓冲
缓冲溢出：增加限制或调查为何缓冲持续时间过长
缓冲中的旧数据包：TTL 可能太高，或 FAR 更新延迟
过度缓冲：可能表明移动性问题或 SMF 问题

有关缓冲操作的详细信息，请参见缓冲管理指南。

缓冲配置

在 config.yml 中配置缓冲行为：

# 缓冲设置
buffer_port: 22152                # 缓冲数据包的 UDP 端口（默认）
buffer_max_packets: 10000         # 每个 FAR 的最大数据包（防止内存耗尽）
buffer_max_total: 100000          # 所有 FAR 的最大总数据包
buffer_packet_ttl: 30             # TTL（秒）（丢弃旧数据包）
buffer_cleanup_interval: 60       # 清理间隔（秒）

建议：

高移动性网络（高速公路、火车）：将 buffer_max_packets 增加到 20,000+
密集城市地区（频繁切换）：将 buffer_packet_ttl 减少到 15 秒
低延迟应用：将 buffer_packet_ttl 设置为 10 秒以防止过时数据
物联网网络：减少限制（物联网设备在切换期间产生的流量较少）

有关完整的配置选项，请参见配置指南。

统计和监控

数据包统计：

实时数据包处理指标，包括：

接收数据包：来自所有接口的总接收量
发送数据包：发送到所有接口的总量
丢弃数据包：因错误或策略丢弃的数据包
GTP-U 数据包：隧道数据包计数

路由统计：

每条路由的转发指标：

路由命中：每条路由匹配的数据包
转发计数：每个目标的成功/失败
错误计数：无效 TEID、未知 UE IP

XDP 统计：

快速数据路径性能指标：

XDP 处理：在 XDP 层处理的数据包
XDP 通过：发送到网络栈的数据包
XDP 丢弃：在 XDP 层丢弃的数据包
XDP 中止：处��错误

N3/N6 接口统计：

每个接口的流量计数器：

N3 RX/TX：来自 RAN（gNB/eNodeB）的流量
N6 RX/TX：来自数据网络的流量
总数据包计数：汇总接口统计信息

有关监控详细信息，请参见监控指南。

容量管理

eBPF 映射容量监控：

UPF 性能取决于 eBPF 映射容量。操作员可以：

实时监控映射使用情况，显示百分比指示器
查看每个 eBPF 映射的容量限制
颜色编码警报：
- 绿色（<50%）：正常
- 黄色（50-70%）：注意
- 琥珀色（70-90%）：警告
- 红色（>90%）：危急

需要监控的关键映射：

uplink_pdr_map：上行流量分类
downlink_pdr_map：下行 IPv4 流量分类
far_map：转发规则
qer_map：QoS 规则
urr_map：使用跟踪

容量规划：

每个 PDR 消耗一个映射条目（键大小 + 值大小）
映射容量在 UPF 启动时配置（内核内存限制）
超过容量将导致会话建立失败

有关容量监控，请参见容量管理。

配置管理

UPF 配置：

查看和验证 UPF 操作参数：

N3 接口：与 RAN 连接的 IP 地址（GTP-U）
N6 接口：与数据网络连接的 IP 地址
N9 接口：用于 UPF 之间通信的 IP 地址（可选）
PFCP 接口：与 SMF 连接的 IP 地址
API 端口：REST API 监听端口
指标端点：Prometheus 指标端口

数据平面配置：

活动的 eBPF 数据路径参数：

活动 N3 地址：运行时 N3 接口绑定
活动 N9 地址：运行时 N9 接口绑定（如果启用）

有关配置查看的信息，请参见配置视图。

故障排除

本节涵盖常见操作问题及其解决策略。

会话建立失败

症状：PFCP 会话无法创建，UE 无法建立数据连接

常见根本原因：

PFCP 关联未建立
- 验证 SMF 是否可以访问 UPF PFCP 接口（端口 8805）
- 检查会话视图中的 PFCP 关联状态
- 验证节点 ID 配置在 SMF 和 UPF 之间是否匹配
eBPF 映射容量耗尽
- 检查容量视图是否显示红色（>90%）映射使用情况
- 增加 UPF 配置中的 eBPF 映射大小
- 删除过时会话以释放映射空间
无效的 PDR/FAR 配置
- 验证 UE IP 地址是否唯一且有效
- 检查 TEID 分配是否存在冲突
- 确保 FAR 引用有效的网络实例
接口配置问题
- 验证 N3 接口 IP 是否��以从 gNB 访问
- 检查路由表以确保 N6 与数据网络的连接
- 确认 GTP-U 流量未被防火墙阻止

有关详细故障排除的信息，请参见故障排除指南。

数据包丢失或转发问题

症状：UE 有连接但经历数据包丢失或没有流量

常见根本原因：

PDR 配置错误
- 验证上行 PDR TEID 是否与 gNB 分配的 TEID 匹配
- 检查下行 PDR UE IP 是否与分配的 IP 匹配
- 检查 SDF 过滤器是否过于严格
FAR 动作问题
- 验证 FAR 动作是否为转发（而不是丢弃或缓冲）
- 检查外部头创建参数是否正确
- 确保目标端点正确
QoS 限制超出
- 检查 QER MBR（最大比特率）设置
- 验证 GBR（保证比特率）分配
- 监控因速率限制导致的数据包丢失
接口 MTU 问题
- 验证 GTP-U 开销（40-50 字节）是否导致分片
- 检查 N3/N6 接口的 MTU 配置
- 监控 ICMP 分片所需消息

缓冲相关问题

症状：数据包无限期缓冲，缓冲溢出

常见根本原因：

缓冲在切换后未禁用
- 检查 FAR 缓冲标志（第 2 位）
- 验证 SMF 是否发送会话修改以禁用缓冲
- 如果卡住，手动通过控制面板禁用缓冲
缓冲 TTL 到期
- 检查缓冲视图中的数据包年龄
- 验证缓冲 TTL 配置（默认可能过长）
- 手动清除过期缓冲
缓冲容量耗尽
- 监控总缓冲使用情况和每个 FAR 的限制
- 检查是否存在导致过度缓冲的错误配置规则
- 调整 max_per_far 和 max_total 缓冲限制

有关缓冲故障排除的信息，请参见缓冲操作。

统计异常

症状：意外的数据包计数，缺失的统计信息

常见根本原因：

计数器溢出
- eBPF 映射使用 64 位计数器（不应溢出）
- 检查日志中的计数器重置事件
- 验证 URR 报告是否正常工作
路由统计未更新
- 验证 eBPF 程序是否附加到接口
- 检查内核版本是否支持所需的 eBPF 特性
- 查看 XDP 统计信息以查找处理错误
接口统计不匹配
- 将 N3/N6 统计信息与内核接口计数器进行比较
- 检查流量是否绕过 eBPF（例如，本地路由）
- 验证所有流量是否通过 XDP 钩子

性能下降

症状：高延迟、低吞吐量、CPU 饱和

诊断：

监控 XDP 统计：检查 XDP 丢弃或中止
检查 eBPF 映射访问时间：��希查找应为亚微秒
查看 CPU 利用率：eBPF 应在核心之间分配
分析网络接口：验证 NIC 是否支持 XDP 卸载

可扩展性考虑：

XDP 性能：每个核心 10M+ 数据包每秒
PDR 容量：数百万个 PDR 仅受限于内核内存
会话计数：每个 UPF 实例数千个并发会话
吞吐量：在适当的 NIC 卸载下实现多千兆吞吐量

有关性能调整的信息，请参见架构指南。

附加文档

组件特定操作指南

有关每个 UPF 组件的详细操作和故障排除：

配置指南

完整的配置参考，包括：

配置参数（YAML、环境变量、CLI）
操作模式（UPF/PGW-U/SGW-U）
XDP 附加模式概述
虚拟化兼容性（Proxmox、VMware、KVM、Hyper-V、VirtualBox）
NIC 兼容性和 XDP 驱动程序支持
不同场景的配置示例
映射大小和容量规划

XDP 模式指南

详细的 XDP 配置和优化，包括：

XDP 附加模式说明（通用/本地/卸载）
性能比较和基准测试
Proxmox VE 本地 XDP 设置的逐步指南
多队列配置以实现最佳性能
VMware ESXi、KVM 和 Hyper-V 的 XDP 设置

目录​

概述​

什么是用户平面功能？​

OmniUPF 关键能力​

理解用户平面架构​

5G 网络架构（SA 模式）​

4G LTE/EPC 网络架构​

组合 PGW-U/SGW-U 模式（典型 4G 部署）​

分离的 SGW-U 和 PGW-U 模式（漫游/多站点）​

N9 循环回路模式（单实例 SGWU+PGWU）​

用户平面功能在网络中的工作原理​

与控制平面的集成（4G 和 5G）​

5G 接口​

4G/EPC 接口​

UPF 组件​

eBPF 数据路径​

PFCP 接口处理程序​

REST API 服务器​

Web 控制面板​

PFCP 协议与 SMF 集成​

PFCP 关联​

SMF 重启检测和孤立会话清理​

GTP-U 错误指示处理​

PFCP 会话创建​

PFCP 会话修改​

PFCP 会话删除​

常见操作​

会话监控​

规则管理​

数据包缓冲​

为什么缓冲对 UPF 至关重要​

问题：移动期间的数据包丢失​

缓冲发生的时间​

OmniUPF 中的缓冲工作原理​

这对用户体验的重要性​

缓冲管理操作​

缓冲配置​

统计和监控​

容量管理​

配置管理​

故障排除​

会话建立失败​

数据包丢失或转发问题​

缓冲相关问题​

统计异常​

性能下降​

附加文档​

组件特定操作指南​

配置指南​

XDP 模式指南​

目录

概述

什么是用户平面功能？

OmniUPF 关键能力

理解用户平面架构

5G 网络架构（SA 模式）

4G LTE/EPC 网络架构

组合 PGW-U/SGW-U 模式（典型 4G 部署）

分离的 SGW-U 和 PGW-U 模式（漫游/多站点）

N9 循环回路模式（单实例 SGWU+PGWU）

用户平面功能在网络中的工作原理

与控制平面的集成（4G 和 5G）

5G 接口

4G/EPC 接口

UPF 组件

eBPF 数据路径

PFCP 接口处理程序

REST API 服务器

Web 控制面板

PFCP 协议与 SMF 集成

PFCP 关联

SMF 重启检测和孤立会话清理

GTP-U 错误指示处理

PFCP 会话创建

PFCP 会话修改

PFCP 会话删除

常见操作

会话监控

规则管理

数据包缓冲

为什么缓冲对 UPF 至关重要

问题：移动期间的数据包丢失

缓冲发生的时间

OmniUPF 中的缓冲工作原理

这对用户体验的重要性

缓冲管理操作

缓冲配置

统计和监控

容量管理

配置管理

故障排除

会话建立失败

数据包丢失或转发问题

缓冲相关问题

统计异常

性能下降

附加文档

组件特定操作指南

配置指南

XDP 模式指南