在工业4.0、智慧港口、智能矿山、AGV协同、PLC间通信等专网场景中,传统公网"终端↔互联网"的星型通信模型并不能满足需求。AGV之间需要直接互访、PLC与上位机需要二层广播、视频回传终端需要组播分发——这些本质上都是局域网(LAN)行为:终端之间彼此可见,而不是各自经互联网绕一圈。
如果用传统公网5G来实现,每两个终端的通信都要"上行到DN(数据网络)再折返",不仅时延翻倍,还要占用两份N6带宽,更无法承载ARP、广播、组播等二层协议。3GPP正是为了解决这个问题,在Release 17引入了 5G LAN-type service(5G局域网型服务),并在Release 18/19持续增强。
本文聚焦其两个核心信令机制:
理解这两个机制,是做5G专网(NPN)、工业5G、边缘本地互通的协议开发与排错的基础。
5G LAN-type服务的核心抽象是5G VN Group(5G虚拟网络组)——一组被配置为支持局域网型通信的UE集合。整个机制在TS 23.501 §5.29中分四节定义:
| 子节 | 标题 | 解决的问题 |
|---|---|---|
| §5.29.1 | General | 5G LAN-type服务总体定义、通信模型 |
| §5.29.2 | 5G VN group management | 组的创建/修改/删除、组数据存储 |
| §5.29.3 | PDU Session management | 组成员如何建立会话、加入组 |
| §5.29.4 | User Plane handling | UPF如何转发组内流量(三态) |
5G VN组支持两类PDU Session类型:IP type 与 Ethernet type。Ethernet type是真正实现"二层局域网替代"的关键——它允许MAC层广播、ARP、非IP工业协议(如Profinet、EtherCAT承载)透传。
组内通信支持三种业务形态: - One-to-One(一对一):等价于LAN中两台主机互访; - One-to-Many(一对多):等价于组播/多播; - One-to-All(一对全部):等价于广播。
下图给出5G LAN-type的参考架构,重点标注N19这一专属于5G VN组的新参考点:
flowchart LR
subgraph Access["接入侧"]
UE1["UE1<br/>(AGV)"]
UE2["UE2<br/>(PLC)"]
UE3["UE3<br/>(上位机)"]
end
subgraph UP1["用户面 - PSA UPF #1"]
UPFA["UPF-A<br/>5G VN Internal Forwarder"]
end
subgraph UP2["用户面 - PSA UPF #2"]
UPFB["UPF-B<br/>5G VN Internal Forwarder"]
end
DN["DN<br/>(企业数据网络)"]
UE1 -.N3.-> UPFA
UE2 -.N3.-> UPFA
UE3 -.N3.-> UPFB
UPFA <==>"N19<br/>(GTP-U 隧道)"<==> UPFB
UPFA -.N6.-> DN
UPFB -.N6.-> DN
note1["Local Switch: UE1↔UE2 在 UPF-A 内部直接交换"]
note2["N19-based: UE1↔UE3 经 N19 隧道跨 UPF 转发"]
note3["N6-based: 经 DN 路由返回"]
UPFA -.-> note1
UPFA -.-> note2
UPFA -.-> note3
注意:图中UE1与UE2挂在同一PSA UPF-A下,走Local Switch;UE3挂在另一PSA UPF-B下,跨UPF通信走N19隧道;若企业用DN侧路由器完成互通,则走N6-based。三种方式可同时存在,由SMF按组策略选择。
| NF | 在5G VN组管理中的职责 |
|---|---|
| AF | 应用功能,发起组创建/修改/删除请求(经NEF或直连) |
| NEF | 对外暴露能力,完成External Group ID → Internal Group ID映射、鉴权 |
| UDM | 分配Internal Group ID,存储5G VN Group Data |
| UDR | 持久化组数据(订阅数据仓库) |
| PCF | 接收组级策略,生成组级PCC Rule,下发给SMF |
| SMF | 在成员PDU Session建立时拉取组数据,编排UPF转发规则 |
| UPF | 执行转发(Local Switch / N19 / N6) |
下面时序图严格对应TS 23.502 §4.4.5"5G VN Group Management"流程,并融合TS 23.501 §5.29.2的组数据模型:
sequenceDiagram
autonumber
participant AF as AF (管理方)
participant NEF as NEF
participant UDM as UDM
participant UDR as UDR
participant PCF as PCF
participant SMF as SMF
participant UPF as UPF
Note over AF,UPF: 阶段A — 组的创建与数据落库
AF->>NEF: Nnef_5gVNGroupProvision (创建组)<br/>ExtGroupId, 成员列表, DNN, S-NSSAI, PDU类型(IP/Eth), 通信策略
NEF->>NEF: 鉴权 + ExtGroupId有效性校验
NEF->>UDM: Nudm_5gVNGroup (创建)<br/>映射为 Internal Group ID
UDM->>UDR: Nudr_DataRepository (PUT 组数据)
UDR-->>UDM: 200 OK
UDM-->>NEF: Internal Group ID + 组配置回执
NEF-->>AF: 创建成功 (Internal Group ID)
Note over AF,UPF: 阶段B — 组级策略生成
UDM->>PCF: 组数据变更通知 (如策略相关)
PCF->>PCF: 生成组级 PCC Rule / QoS 决策
Note over AF,UPF: 阶段C — 成员加入(随PDU Session建立触发)
Note right of SMF: UE发起PDU Session建立(见第四节)
SMF->>UDM: Nudm_SDM (获取5G VN Group Data)<br/>按 SUPI 查询所属组
UDM-->>SMF: 组ID/DNN/转发模式/对端组成员F-TEID参考
SMF->>PCF: Npcf_SMPolicyControl (取组级策略)
PCF-->>SMF: 组级 PCC Rule
SMF->>UPF: N4 Session Establishment<br/>含 5G VN Group Information + 转发规则
UPF-->>SMF: N4 响应 (N19 F-TEID 等)
组创建消息(Nnef_5gVNGroupProvision / Nudm_5gVNGroup)中承载的5G VN Group Data是整个机制的"灵魂",其结构如下:
| IE名称 | 含义 | 取值示例 |
|---|---|---|
| External Group Identifier | 外部组标识,AF可读 | [email protected] |
| Internal Group Identifier | UDM分配的内部组ID | groupid-abc123 |
| DNN | 该组绑定的数据网络名 | internet.corporate.lan |
| S-NSSAI | 切片标识 | SST=1, SD=0x010203 |
| PDU Session Type(s) | 支持的会话类型 | IPv4 / Ethernet |
| Group Members | 组成员SUPI/ GPSI列表 | SUPI集合 |
| AF App ID / 通信策略 | 是否允许组内互访、广播 | one-to-one / one-to-many |
| 5G VN Group Charging | 计费标识 | 按组计费键 |
设计意图有四点值得深读:
成员UE加入组并非走独立信令,而是复用标准PDU Session Establishment流程(TS 23.502 §4.3.2.2.1),差异全部藏在SMF的处理逻辑里:
这一步的精妙之处在于:UE完全无感知5G LAN的存在,它只是一个普通的PDU Session;所有的"组"语义在SMF/UPF之间完成。这对终端兼容性极友好——任何5G终端都可作为5G LAN成员,无需特殊改造。
这是5G LAN最具技术含量的部分。同一5G VN组内的流量,根据组成员的UPF分布,可走三种完全不同的用户面路径。规范原文(TS 23.501 §5.29.4)明确:
There are three types of traffic forwarding methods allowed for 5G VN communication: N6-based ... Local switch ... N19-based ...
| 维度 | Local Switch(本地交换) | N6-based(经DN路由) | N19-based(UPF间隧道) |
|---|---|---|---|
| 适用拓扑 | 所有组成员共享同一PSA UPF | 组成员可分布在不同UPF,依赖DN侧路由器 | 组成员分布在不同PSA UPF,不依赖DN |
| 转发实体 | 单一UPF内部交换矩阵 | DN中的路由器/L3网关 | 各PSA UPF(5G VN Internal Forwarder) |
| 关键参考点 | UPF内部 | N6(双倍) | N19(UPF↔UPF,GTP-U) |
| 时延 | 最低(单跳) | 最高(绕DN一程) | 中等(跨UPF一跳) |
| 是否经DN | 否 | 是 | 否 |
| N4下发要点 | 同一UPF内FAR直连 | FAR指向N6接口 | FAR含对端UPF的N19 F-TEID |
| 典型场景 | 园区内集中部署、单UPF专网 | 与已有企业LAN融合、需DN侧安全审计 | 大规模分布式专网、MEC多站点互通 |
N19是5G LAN引入的新参考点,本质是PSA UPF之间的GTP-U隧道。当组成员UE1(挂UPF-A)要与UE3(挂UPF-B)通信时:
N19与N9(普通跨UPF转发)的根本区别在于:N9承载的是同一个PDU Session在不同UPF间中继,而N19承载的是不同PDU Session(不同UE)之间的"横向"组通信。N9是"接力棒",N19是"内部总机交换"。
为支持N19,每个相关UPF需扮演 5G VN Internal Forwarder 角色——它在N4会话建立时被SMF告知"你是这个组的转发节点",并维护一张组转发表(组成员MAC/IP → 对端UPF N19 F-TEID)。
SMF通过N4(PFCP协议)向UPF编程转发行为。5G LAN在标准PFCP规则基础上引入了专门的IE。下图是一个典型5G VN组PDU Session的N4规则树:
flowchart TD
N4["N4 Session Establishment Request<br/>(TS 29.244 §7.4.4)"] --> PDR["Create PDR (分组检测规则)"]
N4 --> FAR["Create FAR (转发动作规则)"]
N4 --> QER["Create QER (QoS执行规则)"]
N4 --> VN["5G VN Group Information IE<br/>(5G LAN专属)"]
PDR --> PDR1["PDI: Source Interface = Access side<br/>UE IP/MAC, TEID(N3)"]
PDR --> PDR2["PDI: Source Interface = N6 / N19<br/>用于入向检测"]
FAR --> FAR_FWD["Forwarding Parameters"]
FAR_FWD --> DI["Destination Interface<br/>(Access / N6 / N19-LAN)"]
FAR_FWD --> TEID["Outer Header Creation<br/>= 对端UPF N19 F-TEID"]
FAR_FWD --> NI["Network Instance (DNN)"]
VN --> VN1["5G VN Group ID"]
VN --> VN2["PDU Session Type: IP / Ethernet"]
VN --> VN3["组成员列表/转发模式指示"]
关键IE解析:
从组本身看,其生命周期可建模为如下状态机(综合TS 23.502 §4.4.5的创建/修改/删除流程):
stateDiagram-v2
[*] --> 不存在
不存在 --> 创建中: AF创建请求 (Nnef_5gVNGroupProvision)
创建中 --> 活跃: UDM分配Internal Group ID + UDR落库成功
创建中 --> 不存在: 创建失败 (鉴权失败/超限)
活跃 --> 修改中: 成员增删/策略变更
修改中 --> 活跃: UDM更新 + 相关SMF/UPF规则刷新
活跃 --> 空闲: 最后一个成员PDU Session释放
空闲 --> 活跃: 成员重新建立PDU Session
活跃 --> 删除中: AF删除请求
空闲 --> 删除中: AF删除请求
删除中 --> 不存在: UDR清除组数据 + UPF组上下文释放
注意"空闲"态:组成员全部离线时,组数据仍保留在UDR,组本身不消失,待成员重新接入即可恢复——这是5G LAN"群组持久化"设计,避免反复重建。
| 抓包位置 | 协议层 | 识别5G VN的特征 |
|---|---|---|
| N4(SMF↔UPF) | PFCP | Create FAR中Outer Header Creation的目标IP是另一UPF(非N3 gNB、非N6 DN);含5G VN Group Information IE |
| N19(UPF↔UPF) | GTP-U | 内层是UE↔UE的IP/Eth包,外层两端IP都是5GC内部UPF地址;TEID对应N19 F-TEID |
| N6(UPF↔DN) | IP/Eth | N6-based时可见组流量往返DN;Ethernet type会带VLAN或裸MAC帧 |
| N1(UE↔SMF) | NAS | PDU Session Establishment的DNI/DNN为组专用DNN;UE无5G LAN特定字段 |
Q1:5G LAN的N19和普通5G的N9接口有什么本质区别? A:N9是同一PDU Session在两个UPF间的中继传输(纵向接力),两端是"同一条会话的两个段落";N19是不同UE的PDU Session之间的横向组通信转发(横向交换),两端是"两个独立会话的互通点"。N9像快递中转站接力,N19像企业内线总机互转。
Q2:为什么有了N6-based(经DN路由),还要专门设计N19? A:N6-based要求流量绕经DN侧路由器往返,时延高、占用双倍N6带宽、且依赖企业DN具备组内路由与安全策略;N19让流量在5GC内部UPF间直达,时延更低、不依赖DN、且组内通信完全不离开运营商域,安全性与性能更优。N19是为大规模、低时延、多UPF分布式专网量身定制。
Q3:5G LAN必须是Ethernet type才能用吗? A:不是。IP type同样支持,可实现三层组内互通(如UE间IP互访)。Ethernet type是为彻底替代有线LAN、承载二层广播/ARP/工业二层协议而设计的。两类会话可属于同一5G VN组,但互通时需注意二层与三层的转发规则差异。
Q4:组成员动态增删时,已建立的PDU Session如何感知? A:UDM更新组数据后,会通过订阅通知(Nudm_SDM Notification)告知相关SMF;SMF据此触发N4 Session Modification,更新UPF的组转发表(增删对端F-TEID)。无需UE重接,对终端透明。
Q5:5G LAN与5G专网(NPN SNPN/PNI-NPN)是什么关系? A:NPN是"网络部署形态"(独立或公网集成专网),5G LAN是"专网内的通信服务能力"。5G LAN是NPN最常启用的服务之一——尤其在SNPN(独立非公共网络)中,5G LAN几乎是工业组网的标准配置。
本文由「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 等场景全覆盖。
