在5G ToB（面向行业）与5G LAN-type service场景中，工厂车间里的AGV、产线上的PLC、园区内的视频回传终端，它们彼此之间要像处于同一个二层/三层局域网里一样通信。如果每两个终端之间的报文都要绕行互联网侧的N6接口，往返时延、骨干带宽、N6路由器压力都将不可接受。3GPP从Rel-17引入、在Rel-18/Rel-19持续增强的 5G VN组（5G Virtual Network Group）通信机制（TS 23.501 clause 5.29、TS 23.502 clause 4.13.8），正是为了解决"同组UE之间如何不绕行DN直接互通"这一核心问题。
本文聚焦其中最具工程价值、也最容易被误解的机制——用户面三模式转发（Local Switch / N19 / N6）+ 两步检测转发的"5G VN internal"内部接口 + group-level N4 Session，逐条拆解其N4规则（PDR/FAR）配置、信令触发与抓包识别要点。所有引用均来自3GPP Rel-18规范文本。
依据 TS 23.501 clause 5.29.1 与术语表：
5G VN Group: A set of UEs using private communication for 5G LAN-type service. 5G LAN-Virtual Network: A virtual network over the 5G system capable of supporting 5G LAN-type service.
一个5G VN组就是一组"要互相私网通信的UE"的逻辑集合。它不是切片（切片是 S-NSSAI 维度），而是一个比切片更细的、面向成员集合的通信域。在Rel-18中，一个5G VN组与一对 (DNN, S-NSSAI) 是 1:1 映射（clause 5.29.2 NOTE / 末段："only a 1:1 mapping between (DNN, S-NSSAI) combination and 5G VN group is supported"）。
5G VN组由三类信息刻画：组标识、组成员、组数据。其完整字段如下表所示（来源 TS 23.501 clause 5.29.2）。
表1：5G VN group data 关键字段
| 字段类别 | 字段名 | 说明 | 是否可修改 |
|---|---|---|---|
| 组标识 | External Group ID | AF/NEF侧使用的外部组ID | 是（AF管理） |
| 组标识 | Internal Group ID | UDM映射出的内部组ID，需符合TS 23.003格式 | 由UDM分配 |
| 组成员 | GPSI列表 | 每个成员用GPSI唯一标识 | 是（动态增删） |
| 组数据 | PDU Session Type | IP 或 Ethernet | 初始配置后锁定 |
| 组数据 | DNN + S-NSSAI | 标识该5G VN组，1:1绑定 | 不可修改 |
| 组数据 | Application Descriptor | 应用描述 | 是 |
| 组数据 | VN group communication indication | 指示该组启用VN组通信 | 是 |
| 组数据 | 二次认证/授权信息 | 如DN-AAA地址、UE IP由DN-AAA分配 | 是 |
| 组数据 | Maximum Group Data Rate | 组级最大速率，由PCF做组级策略控制 | 是 |
一个关键设计意图：组数据中的"是否启用VN组通信"指示位，决定了SMF在建立PDU Session时是否走本地交换/N19路径。若该指示未置位，即便UE使用了该DNN/S-NSSAI，也只会按普通PDU Session走N6，组内成员之间并不互通。这是排错时第一个要核对的点。
组配置可由OAM下发，也可由AF经NEF动态管理。动态路径（TS 23.502 clause 4.15.6.2 + clause 4.13.8.1）为：
AF → NEF → UDM → UDR，NEF提供External Group ID，UDM完成External→Internal Group ID映射，并将组成员的Internal Group ID-list写回各UE的签约数据，组数据本身写入UDR的Group Subscription。当UE注册或建立PDU Session时，UDM从UDR取出5G VN group data，下发给AMF/SMF（clause 5.29.2："UDM retrieves UE subscription data and corresponding 5G VN group data from UDR and provides the AMF and SMF with UE subscription data with 5G VN group data included"）。
PCF则从UDR订阅5G VN group data变化（Nudr_DM_Notify），并据此生成 URSP规则，通过UE配置更新流程下发给UE，使UE知道该用哪个(DNN, S-NSSAI)建立PDU Session来访问该5G VN组（clause 5.29.2 末段）。
TS 23.501 clause 5.29.4 明确定义了5G VN通信允许的 三种流量转发方法，这是整个机制的用户面核心：
N19是核心新增参考点。TS 23.501 clause 4.4.6.2 定义：
N19: Reference point between two UPFs for direct routing of traffic between different PDU Sessions without using N6. It has a per 5G VN group granularity.
注意三个关键词：UPF之间（不经DN）、不使用N6、每个5G VN组粒度（一个组一条共享隧道，而非每PDU Session一条）。clause 8.3.5进一步说明："The N19 is based on a shared User Plane tunnel connecting two PSA UPFs of a single 5G VN group."
graph TB
subgraph SAME["场景A：同一PSA UPF（Local Switch）"]
A1[UE-1] -->|N3 GTP-U| UPA["PSA UPF（共同锚点）"]
A2[UE-2] -->|N3 GTP-U| UPA
UPA -.->|5G VN internal 内部交换| UPA
end
subgraph DIFF["场景B：不同PSA UPF（N19隧道）"]
B1[UE-1] -->|N3| UP1["PSA UPF-1"]
B2[UE-2] -->|N3| UP2["PSA UPF-2"]
UP1 <==>|N19 共享隧道 per VN group| UP2
end
subgraph N6S["场景C：经DN（N6）"]
C1[UE-1] -->|N3| UP3["PSA UPF"]
C2[UE-2] -->|N3| UP3
UP3 -->|N6| DN[(DN / 路由器)]
DN -->|N6| UP3
end
表2：三种转发模式对比
| 维度 | Local Switch | N19-based | N6-based |
|---|---|---|---|
| 适用拓扑 | 同组PDU Session同一PSA UPF | 同组PDU Session在不同PSA UPF | 所有场景兜底 |
| 是否经DN | 否 | 否 | 是 |
| 隧道类型 | 无（UPF内部） | 共享GTP-U隧道（per组） | DN路由 |
| 是否需group-level N4 Session | 否（仅per-PDU N4） | 是 | 否 |
| 时延 | 最低 | 低（UPF间直连） | 高（绕行DN） |
| 跨SMF Set支持 | N/A | 需OAM配置UPF间隧道 | 天然支持 |
| SSC模式 | — | — | SSC1/2/3 |
设计意图非常清晰：优先本地交换 > 次优N19直连 > 最后N6兜底。clause 5.29.4 明确："The SMF instance(s) may prefer to select a single PSA UPF for as many PDU sessions (targeting the same 5G VN group) as possible, in order to implement local switch on the UPF." 即SMF在选择UPF时会刻意把同组PDU Session往同一个UPF上"聚拢"，以触发本地交换、规避N19隧道的建立开销。
这是整个5G VN组机制最精妙、也最难理解的部分，定义于 TS 23.501 clause 5.8.2.13。
传统PDU Session里，UPF收到一个下行包，靠目的地址匹配一个DL PDR，然后FAR转发出去，一步到位。但5G VN组要支持"一个UE的包可能发给组内任意成员"，且成员可能在不同UPF、也可能在DN侧。于是3GPP设计了两步检测转发：
"Traffic forwarding within the 5G VN group is realized by using a UPF internal interface ('5G VN internal') and a two-step detection and forwarding process."
flowchart TD
SRC[源: UE PDU Session / N6 / N19] -->|"第1步: 入向PDR(Source=Access/Core)检测"| INT
INT[5G VN internal 内部接口] -->|"第2步: 出向PDR(Source=5G VN internal)\n按目的地址精确匹配"| ROUTE{目的在哪?}
ROUTE -->|本UPF另一UE| LOCAL[Local Switch → 目的UE PDU Session]
ROUTE -->|其他UPF的UE| N19F[N19隧道 → 对端UPF]
ROUTE -->|DN侧设备| N6F[N6 → DN]
clause 5.8.2.13 对Local Switch的描述：
"The incoming traffic for one PDU Session will match the corresponding N4 Session's PDR(s) of the source PDU Session (based on GTP-U header information). The traffic is then sent back to classification in that UPF (via the internal interface) and will match another N4 Session corresponding to the destination PDU Session (based on destination address in the PDU). The PDU is then forwarded to the target UE."
也就是说，UE-1发给UE-2的包：① 先按GTP-U头（N3 F-TEID）匹配到UE-1那条PDU Session的入向PDR；② FAR把它丢进内部接口；③ 内部接口上"目的地址=UE-2地址"的PDR命中（这条PDR属于UE-2的PDU Session对应的N4 Session）；④ FAR加N3外层头送到UE-2。全程不出UPF、不建N19隧道、不需要group-level N4 Session。
clause 5.8.2.13.1 给出了SMF必须下发给UPF的完整N4规则集。这是工程师最该背下来的部分。
表3：5G VN组通信的N4规则配置矩阵（TS 23.501 clause 5.8.2.13.1）
| 规则位置 | 检测PDR（Source Interface + 匹配项） | 转发FAR（Destination Interface + 外层头） | 所属N4 Session |
|---|---|---|---|
| 入向（来自本UE） | Access side + CN Tunnel=N3/N9 F-TEID | 5G VN internal | 每成员per-PDU |
| 发往本UE（DL） | 5G VN internal + 目的地址=本UE IP/MAC | Access side + Outer Header Creation=N3/N9 | 每成员per-PDU |
| 来自N19隧道 | Core side + CN Tunnel=N19 F-TEID | 5G VN internal | group-level |
| 经N19发往对端UPF的UE | 5G VN internal + 目的地址=对端UE地址段 | Core side + Outer Header Creation=N19 tunnel | group-level |
| 来自N6的组成员 | Core side + 源地址=组成员IP/MAC | 5G VN internal | group-level |
| 经N6发往DN设备 | 5G VN internal + 目的地址=DN设备 | Core side | group-level |
| 未知目的兜底 | 5G VN internal + match-all + 最低优先级 | （按策略丢弃或广播） | group-level |
关键认知：凡是涉及N6转发和N19转发的PDR/FAR，都挂在 group-level N4 Session 上；而纯本地交换的PDR/FAR挂在每个成员自己的per-PDU N4 Session上。这就是为什么clause 5.8.2.13 末段强调："In the case of N19-based forwarding is not applied for a 5G VN group, group level N4 session is not required."
当一个PLMN里有多个5G VN组共存时，所有组的内部接口都叫"5G VN internal"，如何防止组A的包被误转发到组B？clause 5.8.2.13 给出答案：在内部接口相关的FAR/PDR上携带 Network Instance IE，取值为该5G VN组的标识。即：
这样第二步检测时，只有"组X + 目的地址=UE-Y"同时命中，包才会被正确转发，组间流量在检测转发过程中天然隔离。SMF确定Network Instance的依据是(DNN, S-NSSAI)（clause 5.8.2："The SMF may determine the Network Instance for N19 interface taking into account the (DNN, S-NSSAI) identifying a 5G VN group"）。
N19隧道不是凭空出现的，它的建立/维护/释放全部封装在 group-level N4 Session 的管理流程里（TS 23.502 clause 4.13.8.2.2）。这是把"用户面隧道"和"N4控制面会话"绑定的精巧设计。
clause 4.13.8.2.2 明确：
下图展示UE-2建立PDU Session加入一个已有UE-1（锚定在UPF-1）的5G VN组、SMF选择UPF-2并建立UPF-1↔UPF-2 N19隧道的完整时序。
sequenceDiagram
participant UE2 as UE-2
participant RAN
participant AMF
participant SMF
participant UDM
participant PCF
participant UP1 as UPF-1(已有UE-1)
participant UP2 as UPF-2(新选)
UE2->>AMF: PDU SESSION ESTABLISHMENT REQUEST<br/>(DNN, S-NSSAI of 5G VN组)
AMF->>SMF: Nsmf_PDUSession_CreateSMContext<br/>(DNN, S-NSSAI, SUPI)
SMF->>UDM: Nudm_SDM_Get(SM数据 + 5G VN group data)
Note over SMF: 检查 VN group communication indication = TRUE<br/>发现该组已有成员, 决定N19转发
SMF->>PCF: 建立 SM Policy Association(N7)
SMF->>SMF: 选择 UPF-2 作为 UE-2 的 PSA
SMF->>UP2: N4 Session Establishment(UE-2 per-PDU)<br/>Access侧PDR(N3 F-TEID) + FAR→5G VN internal<br/>+ DL PDR(目的=UE-2地址)+FAR→Access
UP2-->>SMF: N4响应(分配UE-2的N3 F-TEID)
Note over SMF: 该组在UPF-1已有group-level N4 Session<br/>现需把UPF-2接入N19网状/星型隧道
SMF->>UP2: N4 Session Establishment(group-level)<br/>分配 N19 F-TEID@UPF2<br/>下发N19收:PDR(Core,N19 TEID)+FAR→5G VN internal<br/>下发N19发:PDR(5G VN internal,目的=UE-1段)+FAR(→core,N19头)
UP2-->>SMF: N4响应(返回UPF-2的N19 F-TEID)
SMF->>UP1: N4 Session Modification(group-level)<br/>更新对端UPF-2的 N19 F-TEID<br/>新增PDR(5G VN internal,目的=UE-2地址)+FAR(→core,封装UPF-2 N19头)
UP1-->>SMF: N4响应
SMF-->>AMF: Nsmf_PDUSession_CreateSMContext Response<br/>(N2 SM: CN Tunnel Info)
AMF->>RAN: N2 PDU Session Resource Setup
RAN-->>UE2: RRC Reconfiguration
Note over UP1,UP2: UE-1↔UE-2 用户面打通:<br/>UPF-1 内部接口 → N19隧道 → UPF-2 内部接口
VN group communication indication。这是决定后续是否走本地交换/N19的总开关。值得注意的是，N19隧道是两个PSA UPF之间的共享隧道。当一个5G VN组跨多个SMF Set时（广域部署），不同SMF Set控制的UPF之间的N6/N19连通，规范明确交由 OAM配置（clause 5.29.3、5.8.2.13），具体可以是GTP-U隧道或IETF VPN，由部署决定，超出Stage 2规范范围。这意味着跨SMF Set的N19并非信令自动协商，而是预配置——这是大型园区组网时的一个硬约束。
此外，clause 5.8.2.13 明确："Local switching without SMF involvement is not specified for a 5G-VN when different PDU Sessions related with this 5G VN group may be served by different PSA(s) connected over N19." 即：只要涉及N19跨UPF，本地交换就不能脱离SMF的group-level N4 Session管控，否则会出现转发回环。
工业场景大量使用Ethernet PDU Session（二层透传）。此时目的地址是MAC而非IP，SMF有两种方式把DL包送到正确UE（clause 5.8.2.13）：
Ethernet PDU Session Information indication，由UPF自行学习MAC转发表，适用于"全组同PSA或PSA间无N19"的场景。clause 5.8.2.13 的NOTE专门指出方案1的可扩展性陷阱：每检测到一个新MAC就触发一次N4信令，对于"大量设备+大量MAC"的大VN组会产生 N4信令风暴。这是大组场景选型时的关键风险点。VLAN标签的增删则在N6/N19/内部接口上按clause 5.6.10.2处理。
在N4（PFCP）抓包中，5G VN组通信的"指纹"非常明确：
Destination Interface = 5G VN internal（Source Interface取值同理）；用户面N19与N9同样走GTP-U，区分要点：N19的两端都是PSA UPF（core侧到core侧），且一个5G VN组的所有跨UPF流量复用同一条共享隧道；而N9是SMF间PDU Session的中继隧道，通常per-PDU-Session粒度。抓包时结合N4的F-TEID归属即可判定。
| 现象 | 可能根因 | 排查方向 |
|---|---|---|
| 组内UE互不通，但都能上网 | VN group communication indication 未置位 | 查UDM下发的5G VN group data |
| 同UPF成员通，跨UPF不通 | N19隧道未建/F-TEID未更新 | 查SMF是否发了group-level N4 Modification |
| 组A流量串到组B | Network Instance未配/配错 | 查内部接口PDR/FAR的Network Instance IE |
| 大组N4信令爆增 | 启用了MAC显式上报方案 | 评估切换为UPF本地MAC学习 |
| 新UE加入后旧成员收到回环包 | 跨N19做了无SMF参与的local switch | 核实group-level N4 Session是否覆盖所有相关UPF |
Q1：Local Switch和N19能否在一个5G VN组里同时存在？ A：可以，而且这是常态。clause 5.8.2.13 明确"depending on the destination address, some packet flows may be forwarded locally, while other packet flows are forwarded via N19 and other packet flows are forwarded to N6"。一个组里，锚定在同一UPF的成员对走本地交换，跨UPF的成员对走N19，访问DN设备的走N6，三类规则在同一UPF上并存。
Q2：N19隧道是每条PDU Session一条，还是每5G VN组一条？ A：每5G VN组一条共享隧道（clause 8.3.5："a shared User Plane tunnel"）。这正是N19区别于N9的关键——N9通常是per-PDU-Session的中继隧道，N19是per-VN-group的共享隧道，组内所有跨UPF流量复用同一条隧道。
Q3：为什么需要"两步检测转发"，不能一步到位？ A：因为5G VN组成员的目的地是动态且多样的（可能是同UPF另一UE、另一UPF的UE、或DN设备）。一步检测需要入向PDR就精确匹配所有可能目的，规则爆炸。两步法用"5G VN internal"内部接口做中转：第一步只判断"这是组内包"，第二步按目的地址在统一的内部接口上精确路由，规则正交、易于维护和扩展（尤其支持组播/广播）。
Q4：启用N19必须二次认证吗？
A：不必。二次认证（secondary authentication，clause 5.6.6）是5G VN group data里的可选项，用于DN-AAA授权或由DN-AAA分配UE IP。它与是否走N19无依赖关系。N19的启用仅取决于 VN group communication indication 以及"是否存在跨UPF的组内通信需求"。
Q5：5G VN组和网络切片是什么关系？ A：二者是不同维度的概念，但协同工作。切片由 S-NSSAI 标识，是网络资源/服务的逻辑划分；5G VN组是"一组UE的私网通信域"，靠 (DNN, S-NSSAI) 标识且1:1绑定。一个5G VN组通常部署在某个切片内，借助切片的资源隔离获得QoS保障，但其组通信机制（本地交换/N19）本身独立于切片机制。
本文由「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 等场景全覆盖。