简介面向5G核心网研发与工业互联网技术评估的这份文档围绕以太网Ethernet类型5G局域网5G LAN的用户面功能UPF转发模型展开从工业现场级网络对二层局域网的需求出发解决传统IP转发无法直接支撑以太网通信的组网问题。文档以传统交换机组网拓扑为参考系统梳理了基本转发、多交换节点级联、广播域隔离与链路冗余四种核心转发模型涵盖单播、广播、组播报文处理N19接口跨厂区互通VN组广播域划分以及链路冗余防环等设计要点同时进一步剖析了UPF转发过程中的GTP-U隧道收发机制、针对PDU会话粒度的转发处理、PDR的PDI匹配与QoS/转发/计费动作执行并讨论了多PDU会话与最多64个PDR关联等实现细节。在此基础上基于开源软件完成以太网类型5G LAN的基本转发功能验证给出实验结果和软件架构设计思路为5G LAN技术研究和实际部署提供工程参考。资源为1个docx文档大小541KB图文结合展示组网拓扑、转发流程与验证过程目前已有605人浏览学习适合需要深入理解5G局域网转发原理及UPF实现细节的读者阅读。1. 5G LAN 不是“5G局域网”的简单叠加UPF 转发模型到底要重构什么做工业现场网络的人对这套说辞应该不陌生5G 专网带宽够、时延低但到了工厂园区要替代那根网线时发现现场设备根本不认 IP 三层那一套——PLC、IO 模块、老式传感器全靠二层广播、组播协同工作MAC 地址表才是它们的“通讯录”。这就把压力全推给了 5G 用户面里的 UPF它能不能像一台二层交换机一样把 UE 和 DN 侧设备拉进同一个广播域答案是传统只支持 IP 类型 PDU 会话的 UPF 做不了得靠 3GPP R16 引入的 5G LAN 能力而落地的关键就是 UPF 的转发模型怎么设计。这篇文档正是围绕这个问题展开的先拿交换机拓扑对应出转发需求再分解 UPF 的 GTP-U 收发、锚点转发、PDU 处理三个环节最后用 Free5gc 和 UERANSIM 改出来的环境做功能验证。适合正在做 5G 专网用户面方案、或者想评估开源核心网能不能撑起 5G LAN 场景的从业者。2. 从交换机拓扑到 UPF 转发模型四大需求如何变成表项和接口5G LAN 的转发需求不是凭空发明的文档里把所有需求都映射到了传统二层交换机的组网拓扑上。这个分析思路很重要因为 UPF 设计者面对的问题从来不是“怎么转”而是“转发需求到底长什么样”。2.1 基本转发单播、广播、组播分别走哪条路一台普通二层交换机的基本转发就三件事单播报文按目的 MAC 从接收端口转发到另一个端口广播报文转发到同广播域所有端口组播报文根据订阅关系转发到指定端口集合。把图里的 P0~P3 类比成 5G 网络里的 UE 和 DN 设备需求就变成了 UE 之间、UE 与 DN 侧设备之间要有 L2 层的单播、组播、广播互通。这里文档给出了两个转发路径的定义一个是 Local Switch 方式报文在 UPF 内部直接从一个 PDU 会话转到另一个 PDU 会话不上行到 DN另一个是基于 N6 接口的转发报文先到锚点 UPF 进 DN 网络再通过 DN 侧的二层设备转回去。两种路径对应着不同的 PDR/FAR 配置方式。Local Switch 方式更省时延但要求 SMF 在建立会话时就把 UE 之间的转发规则下发清楚N6 方式更接近传统组网但对 DN 侧的二层网络依赖更大。实际配置时要注意Local Switch 并不是默认开启的SMF 需要为每个 UE 的 PDU 会话额外生成指向对端 UE 的 FAR而且这个 FAR 的目标 F-TEID 必须在对端会话建立完成后才拿得到所以两个 UE 的会话建立时序会影响转发规则的下发顺序。2.2 多交换节点级联N19 接口的粒度是 VN 组现场部署不会总是一台 UPF 覆盖所有终端两个厂区距离远、接入点分散时需要多台交换机级联。对应到 5G LAN 场景就是两个 UPF 下沉到两个厂区UPF 之间通过 N19 接口互通。N19 和 N3、N9 最大的区别在于隧道粒度。N3/N9 的 TEID 是 PDU 会话粒度的一个 UE 一个会话对应一个 TEID而 N19 的 TEID 是 VN 组粒度的也就是说一条 N19 隧道承载的是同一 VN 组内所有 UE 的跨 UPF 流量。这意味着在 UPF 内部N19 隧道的查找不能靠 PDU 会话索引要靠 VN 组 ID 来关联。跨 UPF 转发时还有一个隐藏问题报文的 MAC 地址学习如何同步。如果 UE1 在 UPF-AUE2 在 UPF-BUE1 发广播报文到 UE2UPF-A 需要知道“目的 MAC 在 N19 隧道那侧”这个信息要么靠控制面 SMF 下发的静态规则要么靠 UPF 之间的 MAC 学习机制。文档把快速 MAC 地址学习和核心网集中控制的矛盾列为待研究点实际做方案时务必先确认是静态配置还是动态学习否则跨 UPF 的二层通信会非常脆弱。2.3 广播域隔离VN 组和 DNNS-NSSAI 的 1:1 绑定限制传统交换机靠 VLAN 隔离广播域5G LAN 里对应的概念是 VN 组。划入同一个 VN 组的终端相当于处在同一个广播域内不同 VN 组之间天然隔离。但这里有个文档明确点出的限制3GPP R16 里VN 组仅支持与 DNNS-NSSAI 做 1:1 映射关联。这意味着什么如果你想让同一厂区里不同车间的终端分属不同广播域你得为每个广播域单独规划 DNN 和切片组合而不能像 VLAN 那样在同一个接入侧动态划分。这在实际项目里是非常大的约束尤其当终端数量多、业务分类细的时候DNN 和切片的规划会变得非常笨重。文档说这是“不够灵活”从工程角度讲这基本宣告了 R16 版本的 5G LAN 只适合 VN 组数量少、隔离粒度粗的场景。锚点转发时增加 VN 组对应的逻辑隔离域是 UPF 实现广播域隔离的核心手段。相当于在 UPF 的交换模块里为每个 VN 组建一张独立的 MAC 表转发时先按 VN 组限定查找范围。2.4 链路冗余生成树协议在 UPF 上不好使的深层原因传统交换机做链路冗余靠生成树协议阻塞部分端口来断环但文档指出这个方案搬到 5G LAN 里有两个具体问题。第一个问题VN 组内的 UE 数量可以远远高于交换机的端口数如果 UPF 直接启动生成树协议BPDU 的计算负载会高到影响倒换性能。交换机端口数撑死几十上百UE 数量动辄上千生成树的状态机要维护的节点数量完全不是一个量级。第二个问题更隐蔽如果 UPF 不启动断环协议选择透传 CPE 或者 DN 侧交换机的 BPDU 报文一旦网络拓扑倒换产生广播风暴5G 网络大量丢包时会无差别丢掉 BPDU断环协议自己先趴窝了环网更解不开。这是一个典型的“透传也不对、终结也不对”的两难。我一般会建议的方案是在 UPF 侧终结并代理生成树协议但只对 VN 组对应的虚拟端口做轻量级计算同时把 BPDU 报文标记为高优先级 QoS 流确保拥塞时不丢。文档把这列为当前 5G LAN 项目的讨论热点说明还没有标准答案做方案时要有自己兜底的准备。3. 拆开 UPF 的转发黑匣子GTP-U 收发、锚点交换、PDU 处理三件事UPF 的转发过程看起来复杂文档把它梳理成了三个核心环节GTP-U 隧道收发、锚点路由/交换、PDR 匹配和动作执行。理解这三个环节的边界和职责是看懂后续软件架构的前提。3.1 GTP-U 收发为什么 PDU 会话索引只能靠 F-TEIDGTP-U 报文由外层以太网头、IP 头、UDP 头、GTP-U 头和 T-PDU 组成。UPF 从 N3 收到报文后第一步是判断这个报文属于哪个 PDU 会话。文档详细分析了哪些字段能用作索引、哪些不能源 MAC / 目的 MAC作用范围在 L2 广播域内基站到 UPF 要跨承载网不适合源 IP / 源 UDP 端口UE 移动切换基站时会变不稳定目的 UDP 端口固定 2152没有区分度T-PDU 里的内容能索引到 UE但 Ethernet 类型会话里 UE 用出厂 MAC 地址不由 5GC 分配有局限剩下适合做索引的只有 GTP-U 报文的目的 IP 和 TEID合起来就是 F-TEID。TEID 由 UPF 在会话建立时分配可以设备内全局唯一也可以在每个监听 IP 上唯一。全局唯一的做法查找最快收到报文直接用 TEID 哈希就能命中 PDU 会话按监听 IP 唯一的做法需要先查目的 IP 再查 TEID多一级索引但扩展性更好。文档里有一句话容易被忽略N19 隧道的 TEID 对应的是 VN 组粒度不是 PDU 会话粒度。这意味着 UPF 处理 N19 报文的索引逻辑和处理 N3/N9 报文不同。我在验证环境里就踩过这个坑拿 N3 的会话索引逻辑去查 N19 的报文结果查不到后面单独列一张 VN 组到 N19 隧道的映射表才解决。3.2 锚点功能UPF 在 IP 场景是路由器在 Ethernet 场景是交换机锚点 UPF 之所以叫锚点是因为关联到指定 DN 的 UE 无论怎么移动用户面数据流都在这个位置进出 DN 网络。文档把 UE 的每个 PDU 会话类比成传统网络里终端的一个网口N3/空口类比成网线这个类比很直观。IP 类型会话的锚点 UPF 要具备路由器功能根据 PDU 会话的 IP 地址池和 DN 网络路由拓扑生成路由表Ethernet 类型会话的锚点 UPF 要具备交换机功能根据 MAC 地址查询对应的网络端口每个 PDU 会话是一个逻辑端口。这里文档特别提了一个运营层面的细节2C 商用网络里UE 用户主要是访问 DN 服务器的业务为了避免用户之间互访的安全风险通常关闭 UE 互通权限防止端口扫描和流量泛洪。而 2B 垂直行业恰恰相反终端互访是刚需5G LAN 的目的就是提供类 LAN 互通。所以 UPF 的转发方案里锚点的路由/交换模块要支持按 VN 组创建逻辑隔离域域内 UE 互通域间隔离——这和交换机上 VLAN 的隔离思路一脉相承。3.3 PDR 匹配与动作执行PDU 会话里的 ACL 机制每个 PDU 会话最多包含 64 个 PDR每个 PDR 定义一类用户面报文是 QoS、转发、计费处理的最小粒度单元。文档的类比很到位PDR 类似于传统数通设备里的 ACL 机制。PDR 的 PDI 做包检测匹配命中后执行关联的 FAR转发动作、QERQoS 执行、URR计费统计。这里要注意UPF 收到 GTP-U 报文并检索到 PDU 会话后还要继续做 PDR 匹配不是查完会话就直接转发。PDR 可以精确控制到报文流级别所以同一 VN 组内 UE 通信时可以通过 PDR/FAR 直接转发不一定要上到锚点的路由/交换模块。这意味着 UPF 内部存在“快路径直接转发”和“上锚点转发”两条路具体走哪条取决于 SMF 下发的 FAR。文档用表 1 列出了主要转发场景这里我整理成接口对照表Case接收接口转出接口是否经过锚点典型场景Case0N3N3可选UE1 上行直接转 UE2I-UPF 或合设 UPFCase4N3N6是UE 上行业务到 DN 服务器Case5/Case6N3/N6N3/N6否PDR/FAR 直接指定转发对端Case7/Case9N3/N6N3/N6是上行到锚点再交换到对端 UECase12N6N6是DN 侧设备与 UE 之间双向流量表格里值得琢磨的是同样的 N3 到 N3 转发处理过程可能完全不同。如果 UPF 是 I-UPF 且 SMF 下发了明确的转发 FAR报文走 GTP-U 收包、PDU 处理、GTP-U 发包的短路径如果 UPF 是 I-UPF 和 PSA 合设但没有明确转发规则流量要上行到锚点交换模块走 GTP-U 收包、PDU 处理、锚点路由/交换、PDU 处理、GTP-U 发包的长路径。两种路径的时延和资源占用差很多排查转发异常时首先要确认走的是哪条路径。4. 把转发模型落成软件架构用户态管逻辑内核态管快路径转发模型分析清楚之后文档给出了一个具体的软件架构设计。这个架构的划分方式直接影响了验证代码怎么写、性能瓶颈在哪值得仔细拆解。4.1 用户态与内核态的分工慢路径和快路径如何配合软件架构分用户态和内核态。用户态由 UPF 业务模块、SDK 适配层、SDK 三部分组成。UPF 业务模块维护核心数据和业务逻辑包含 N4 消息处理单元、用户报文处理单元、日志管理和 OAM 模块。其中用户报文处理单元是数据转发的“慢路径”处理快路径里的未知报文、DPI 和其他增强功能。内核态是实际的用户报文转发模块包含与用户态的接口、转发规则表、GTP-U 隧道、用户面报文处理、锚点虚拟网卡、简易交换路由模块。这个分工的逻辑很清晰控制面N4 消息处理和异常路径慢路径在用户态转发热点GTP-U 收发、PDR 匹配、锚点交换在内核态。SDK 适配层是架构里承上启下的关键它屏蔽了底层不同转发方案的差异。文档明确提到了内核模块转发、DPDK、xdp/eBPF 三种方案SDK 适配层定义抽象接口让上层业务逻辑不依赖具体实现。这一点在做性能选型时非常有用功能验证用内核模块性能压测换 DPDK上层代码不用大改。锚点虚拟网卡是一个值得注意的设计。UPF 做锚点转发时报文要进入“路由/交换”阶段虚拟网卡充当了 UPF 内部通往 DN 逻辑的二层入口配合简易交换路由模块实现按 VN 组的隔离和转发。这个设计和传统数通设备里 VRF 的思路类似但换成了虚拟网卡实现。4.2 基于 Free5gc 和 UERANSIM 的开源验证环境功能验证选了两个开源项目Free5gc 是开源 5G 核心网实现了 AMF、SMF、UDM、UDR、NSSF、PCF、AUSF、NRF、UPFUERANSIM 是开源的 UE 和 GNB 模拟软件。但这两个项目基于 3GPP R15只支持 IPv4 类型的 PDU 会话要验证 5G LAN 必须自己改造。文档列了三项改造修改 UE 会话建立流程、添加虚拟网卡类型支持 Ethernet 类型的 PDU 会话修改 AMF 和 SMF 等控制面网元支持 Ethernet 类型按软件架构设计实现支持 IP 和 Ethernet 类型、具备 5G LAN 转发功能的 UPF。控制面的改造尤其繁琐因为 SMF 要能识别 Ethernet 类型 PDU 会话并生成对应的 PDR/FAR还要处理 Local Switch 场景下的对端 F-TEID 获取。环境部署上文档采用了虚机和容器混合方式UE、GNB、UPF、DN 走虚机方便装虚拟网卡和内核模块Mongo 数据库和 5GC 控制面走容器。这个部署选择很务实因为 UPF 要装内核模块虚机比容器更好操作。实际搭建验证环境时典型的操作步骤会涉及# 为 UE 虚机添加 Ethernet 类型会话所需的虚拟网卡 ip tuntap add dev veth0 mode tap ip link set veth0 up ip addr add 192.168.50.2/24 dev veth0 # 检查 UPF 内核模块是否加载成功 lsmod | grep upf dmesg | tail -50 # 启动 UERANSIM 的 gNB 和 UE观察会话建立日志 ./nr-gnb -c gnb.yaml ./nr-ue -c ue.yaml逻辑说明ip tuntap创建的是 UE 侧模拟的物理网卡Ethernet 类型会话里 UE 设备使用硬件 MAC 地址所以这张虚拟网卡不用配 IP 也能参与二层转发lsmod用于确认 UPF 的快路径内核模块已加载模块没加载时所有报文都会走慢路径转发性能和功能表现都会异常UERANSIM 的 UE 进程启动时会模拟完整的注册和 PDU 会话建立流程控制面是否支持 Ethernet 类型在这里就能初步看出来。参数说明tap mode选择 tap 而不是 tun是因为 Ethernet 类型会话需要在虚拟网卡上承载完整以太网帧tun 只处理 IP 报文不满足验证需求。4.3 验证结果和边界条件文档给出的结论是改进后的 UPF 配合改造后的 ue、gnb 和 5gc 控制面实现了 IP 类型和 Ethernet 类型的 PDU 会话并支持 5G LAN 的基本转发功能。这个结论有几个边界条件要注意。一是验证范围是“基本转发”也就是单播、广播、组播在同一 VN 组内的正确转发二是验证环境是极边缘小型化 UPF 场景文档明确说选择了 Linux 内核模块转发方案性能上限受内核协议栈限制三是 N19 级联转发是否完整验证、链路冗余场景是否覆盖文档没有展开说明这两个方向在验证层面还有空白。这给我们自己复现时的预期管理提供了依据能验证的是转发功能不是转发性能能验证的是单 UPF 和基本组网不是复杂的跨 UPF 环网拓扑。5. 避坑与排查从 TEID 索引到开源改造五条实测踩坑记录这一章把我在拆解这套文档、复现转发模型过程中遇到的高频问题按“现象 → 原因 → 解决”整理一下。这些问题在文档里要么只是一句话带过要么属于“讨论热点”实际做方案时全都会变成拦路虎。5.1 Ethernet 类型 PDU 会话建立失败报 PDU 类型不支持现象UERANSIM 发起 PDU 会话建立请求5GC 返回错误信令里提示 PDU 会话类型不支持。原因Free5gc 的 SMF 基于 R15 实现默认只接受 IPv4 类型同时 AMF 在 NAS 消息里对 PDU 会话类型的编解码也只支持 IPv4Ethernet 类型字段在 R16 才引入。控制面网元有一处不支持会话就建立不起来。解决先改 AMF 的 NAS 编解码让 Ethernet 类型能正确透传再改 SMF 的会话管理逻辑使其能处理 Ethernet 类型的 PDR/FAR 创建。UE 侧 UERANSIM 也要改否则 UE 自己不会发起 Ethernet 类型的会话请求。三层改动缺一不可。5.2 TEID 全局唯一时转发正常改为监听 IP 唯一后查不到 PDU 会话现象UPF 收到的 GTP-U 报文找不到对应 PDU 会话报文被丢到慢路径或者直接丢弃。原因文档明确说 TEID 可以在设备内全局唯一也可以在每个监听 IP 上唯一。全局唯一时只查 TEID 就能命中按监听 IP 唯一时必须先匹配目的 IP再用 TEID 做二次查找。UPF 实现如果只支持全局唯一的查表逻辑部署时改了 TEID 分配策略就会失效。解决确认 UPF 的 PDU 会话索引表结构。实现上建议一张哈希表以 F-TEIDIPTEID作为 key无论哪种分配策略都能覆盖如果 UPF 只支持 TEID 单键索引就把配置固定为全局唯一模式。5.3 同一 VN 组内跨 UPF 转发不通但同 UPF 内互通正常现象UE1 和 UE2 挂在同一个 VN 组但分别接入 UPF-A 和 UPF-B。同 UPF 内的 UE 互通没问题跨 UPF 的报文到不了对端。原因N19 隧道没有建立或没有正确关联到 VN 组。N19 的 TEID 是 VN 组粒度的需要在 SMF 为两个 UPF 配置 N19 对端 F-TEID如果配置成了 PDU 会话粒度或者 VN 组到 N19 隧道的映射缺失跨 UPF 报文就没有转发出口。解决核对两个 UPF 的 N19 隧道配置确认对端 F-TEID 是指向对端 UPF 的监听地址VN 组 TEID。在 UPF 侧打印 VN 组到 N19 隧道的映射表排查映射是否存在、报文的 GTP-U 目的 TEID 是否匹配该映射。5.4 广播域出现广播风暴BPDU 报文在拥塞时先被丢现象组网中有物理环路时广播报文无限循环5G 网络在大量丢包时风暴反而加剧断环协议无法收敛。原因文档里分析得很清楚——UPF 透传 CPE/DN 侧交换机的 BPDU但拥塞丢包是无差别的BPDU 优先级没被特殊保护先于业务报文被丢掉断环协议收不到 BPDU无法阻塞端口。解决在 UPF 的 QoS 策略里为 BPDU 单独配置高优先级队列。Ethernet 帧通过目的 MAC如 01:80:C2:00:00:00 开头的组播地址识别 BPDU映射到高优先级 5QI 或 QFI确保拥塞时 BPDU 不丢。如果 UPF 支持协议终结可以在 UPF 内终结生成树协议只对 VN 组的虚拟端口做轻量计算。5.5 Ethernet 类型会话里 UE 用出厂 MAC控制面无法预知 MAC 地址现象SMF 下发的 PDR 里无法预填 UE 的 MAC 地址Local Switch 场景下报文匹配不到 PDR。原因IP 类型会话里 UE 地址由 5GC 分配控制面能预知Ethernet 类型会话里 UE 使用硬件出厂 MAC 地址5GC 不分配也不提前知道。PDR 的 PDI 若配置了源 MAC 匹配UE 没上线时 SMF 拿不到这个值。解决PDR 创建时把 PDI 的源 MAC 留空通过 UE 上报或 UPF 首次收包后的 MAC 学习来填充转发表项。UPF 的简易交换模块需要支持动态 MAC 学习或者 SMF 在会话建立后的更新流程里回填 UE 上报的 MAC。设计时要预留这个“先转发、后学习”的窗口。6. 验证收尾把基本转发跑通后下一步该看什么在复现这套转发模型时我习惯在拿到“功能验证通过”结论后额外做一轮针对性的检查确认验证结果不是靠运气。最直接的做法是搭一个最小拓扑一台改进后的 Free5gc一个 UERANSIM 模拟的 UE 和一个 gNB一台 UPF 虚机一台 DN 侧设备虚机。通过ping测试 IP 类型会话互通再用自定义的以太网帧工具测试 Ethernet 类型会话的广播和单播转发观察 UPF 日志里 PDR 的匹配计数和 FAR 的转发动作是否和预期一致。# 在 UPF 虚机查看 PDR 命中统计和转发动作 cat /proc/upf/pdr_stats # 输出示例PDR_ID1 matched1024 far_actionforward teid0x12345 # 在 DN 侧设备抓 Ethernet 类型会话的广播帧 tcpdump -i veth0 -e ether[0] 1 1 -c 100逻辑说明pdr_stats是每 PDR 的命中计数器匹配数和发送数若不一致说明 FAR 执行有问题或 N19 隧道转发失败tcpdump的-e选项显示以太网头ether[0] 1 1过滤目的 MAC 最低位为 1 的广播/组播帧用于确认广播域内转发是否生效。参数说明-c 100限制抓包数量避免广播风暴场景下抓包文件无限膨胀如果你改过 PDR 的 PDI还可以按 PDR ID 过滤统计精确到某个 UE 的转发情况。验证通过后下一步我会优先看两个方向。第一是性能扩展路径文档里提到高性能场景可以换 DPDK、xdp/eBPF 或硬件加速卡并且 GTP-U 收包、PDR 转发、锚点转发三个阶段可以合并用 N 元组匹配提高性能。这意味着当前基于内核模块的实现是“跑通功能”的基线不是性能基线。第二是文档列为待研究的难题链路冗余和环网抑制、快速 MAC 地址学习与核心网集中控制的矛盾、5G LAN 与工业现场总线及确定性网络的融合。这些不是边角料是决定 5G LAN 能否真正替代工厂那根网线的关键。说到替代那根网线我自己的教训是验证 5G LAN 转发功能一定要先确认 SMF 下发的 PDR/FAR 和你以为的路径一致。项目里曾经出现过一次“广播转发验证通过”的结论后来查日志发现报文根本没走锚点交换而是走了 PDR 直接转发的快路径覆盖不到真正的广播域处理逻辑。从那以后我每次验证基本转发都会强制走一遍“PDR 匹配 → FAR 动作 → 实际转发路径”的三段核对确认报文的每一步都落在预期的处理环节上。希望帮到你。本文还有配套的精品资源点击获取