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 角色,N9 回环处理完全在 eBPF 中进行。
关键特性:
- ✅ 亚微秒 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: 因 SMF 重启删除孤立会话 2(LocalSEID)
INFO: 因 SMF 重启删除孤立会话 3(LocalSEID)
...
INFO: 因 SMF 重启删除孤立会话 246(LocalSEID)
重要说明:
-
隔离:仅删除重启 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 的信息元素
- 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: 因 GTP-U 错误指示删除会话 LocalSEID=42,TEID 0x12345678,来自 192.168.50.10
WARN: 因 GTP-U 错误指示删除 1 个会话,TEID 0x12345678,来自对等方 192.168.50.10
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,以 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 最重要的功能之一,因为它防止在移动事件和会话重新配置期间丢失分组。如果没有缓冲,移动用户在每次移动基站或网络条件变化时都会经历连接中断、下载中断和实时通信失败。
问题:移动期间的分组丢失
在移动网络中,用户不断移动。当设备在一个基站和另一个基站之间移动时(切换),或者当网络需要重新配置数据路径时,会出现一个关键窗口,在此窗口中,分组正在传输,但新路径尚未准备好:
没有缓冲:在这个关键窗口中到达的分组将被 丢弃,导致:
- 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 ID 的内存中缓冲,带有元数据(时间戳、方向、数据包大小)
- 限制:
- 每个 FAR 限制:10,000 个数据包(默认)
- 全局限制:100,000 个数据包,跨所有 FAR
- 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 秒以防止过时数据 - 物联网网络:减少限制(物联网设备在切换期间产生的流量较少)
有关完整的配置选项,请参见 配置指南。
统计和监控
分组统计:
实时分组处理指标,包括:
- 接收的 RX 数据包:来自所有接口的总接收量
- 发送的 TX 数据包:发送到所有接口的总量
- 丢弃的数据包:由于错误或策略丢弃的分组
- 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 限制
- 检查是否存在错误配置的规则导致过度缓冲
- 调整最大每 FAR 和全局缓冲限制
有关缓冲故障排除的信息,请参见 缓冲操作。
统计异常
症状:意外的数据包计数,缺失统计信息
常见根本原因:
-
计数器溢出
- 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 设置
- XDP 验证和故障排除
- 硬件选择以获得 XDP 性能
架构指南
深入的技术探讨,包括:
- eBPF 技术基础和程序生命周期
- XDP 数据包处理管道与尾调用
- PFCP 协议实现
- 缓冲架构(GTP