# 5G VN组通信转发机制拆解：从组管理到Group-level N4的全链信令解析 > 本文聚焦 3GPP **TS 23.501 §5.29**（Support for 5G LAN-type service）与 **TS 23.502 §4.13.8**（Support of 5G LAN-type service）所定义的 **5G VN（Virtual Network）组通信**机制。这是 5G 在企业专网、工业内网（如工厂 AGV 协同）场景下，把一组 UE 当作"二层/三层局域网成员"来组织、转发与编排的核心能力。我们将沿着"组是怎么建出来的 → 成员 PDU 会话是怎么建立的 → 组内报文是怎么转发的 → N4 是如何按组来管理的"四条主线，逐步拆解每一条信令与关键 IE。 --- ## 一、为什么需要 5G VN 组：设计意图与场景边界 传统的 5G PDU 会话是**点对点**的——一个 UE 到一个 DN（数据网络），用户面建立的是 UE↔PSA UPF↔DN 的单一管道。但工业现场（TSN、AGV、PLC 互联）和企业 LAN 有一个共同需求：**组内成员之间需要彼此直接通信**，并且这种通信最好不绕出 DN、不被公网路由影响、时延极低。 5G LAN-type service（TS 22.261 §6.26 定义服务需求）正是为此而生：它把一组 UE 划入同一个 **5G VN Group**，让这组 UE 像接在同一个交换机/子网里一样互相收发，同时享受 5G 的高性能、广覆盖、移动性与安全。关键技术约束是：**组成员归属同一个 UDM Group ID**（当前 Release 要求 VN 组成员归属网相同），且 **(DNN, S-NSSAI) 与 VN 组是 1:1 映射**——也就是说，一个 VN 组绑定唯一的 DNN 和切片组合，这是后续所有转发决策的基础锚点。 整个机制由四个子模块组成，分别对应 TS 23.501 的四个子条款： | 子条款 | 主题 | 解决的问题 | |--------|------|-----------| | §5.29.1 | General | 概念定义与整体框架 | | §5.29.2 | 5G VN group management | 组怎么创建、成员怎么管 | | §5.29.3 | PDU Session management | 成员的 PDU 会话如何带组属性 | | §5.29.4 | User Plane handling | 组内报文的三种转发方式 | --- ## 二、核心标识体系：一个 VN 组由哪些参数"定义" 理解信令之前，必须先理清 **5G VN Group 的标识与数据模型**。这是 TS 23.501 §5.29.2 的核心，所有后续信令消息都围绕这套标识展开。 5G VN 组的"身份证"分两层：**外部标识**给 AF（应用功能）用，**内部标识**给 5GC 网元用；成员用 GPSI 唯一标识；组数据则定义了这个组的"网络画像"。整理如下表： ### 表 1：5G VN Group 标识与数据参数（TS 23.501 §5.29.2） | 参数 | 作用域 | 说明 | 创建后是否可修改 | |------|--------|------|------------------| | External Group ID | AF ↔ NEF | AF 侧对 VN 组的标识 | 可（AF 可更新成员） | | Internal Group ID | 5GC 内部 | UDM 映射出的内部标识，须符合 TS 23.003 格式 | 由 UDM 确定 | | GPSI | 成员 | 唯一标识每个组成员 UE | 可（增/删/改） | | DNN / S-NSSAI | 组关联网络 | 组绑定的 DNN 与切片（1:1 映射） | **创建后不可改** | | PDU Session Type | 组数据 | IPv4 / IPv6 / Ethernet | 不可改 | | Application Descriptor | 组数据 | 应用描述符 | 可 | | 5G VN group communication 指示 | 组数据 | 指明该组关联 VN 组通信 | — | | Max Group Data Rate | 组数据 | 组级最大速率，触发组级策略（TS 23.503） | 可 | | User Plane Security Policy | 组数据 | 组级用户面安全策略（TS 33.501） | **创建后不可改** | | 二次认证/授权信息 | 组数据 | DN-AAA 地址等，用于 UE IP 由 DN-AAA 分配 | 可 | **设计意图解析：** 注意表中标红的"DNN/S-NSSAI/User Plane Security Policy 不可修改"。规范明确：一旦 VN 组初始 provisioning 完成，这三个核心参数就被锁死（`Nudm_ParameterProvision_Update` 和 `Nudr_DM_Update` 对它们不再生效）。原因在于——它们是 **(DNN, S-NSSAI) → VN 组**映射的基石。如果运行中改了 DNN/S-NSSAI，等于把组的"门牌号"换了，会导致已建立的成员 PDU 会话与组数据失配、转发规则全部作废。锁死这三个参数，是用"不可变性"换取系统一致性，这是协议层面对一致性的典型妥协设计。 --- ## 三、机制一：VN 组的动态创建信令流（AF → NEF → UDM → UDR） VN 组可以通过 OA&M 静态配置，也可以由 **AF 动态管理**。后者是更值得拆解的链路，对应 TS 23.502 §4.15.6.2（NEF 服务操作信息流）与 §4.13.8.1。完整信令时序如下： ```mermaid sequenceDiagram participant AF participant NEF participant UDM participant UDR participant PCF participant AMF Note over AF,UDM: ① 创建/更新 VN 组 AF->>NEF: Nnef_ParameterProvision_Create
(External Group ID, 成员GPSI列表, 组数据:
DNN, S-NSSAI, PDU类型, VN组通信指示,
Max Group Data Rate, UPSec) NEF->>UDM: Nudm_ParameterProvision_Update
(External Group ID, 成员, 组数据) UDM->>UDR: Nudr_DM_Update (Group Identifier translation:
Internal Group ID ↔ External Group ID ↔ 成员列表) UDM->>UDR: Nudr_DM_Update (5G VN group data:
DNN/S-NSSAI/App descriptor/MGDR/UPSec) Note over UDR: DNN/S-NSSAI/UPSec 写入后锁定不可改 Note over UDR,PCF: ② 组数据变更通知 + URSP 生成 UDR-->>PCF: Nudr_DM_Notify (5G VN group data 变更)
[PCF 已订阅组数据变更] PCF->>PCF: 基于 group data 生成 URSP 规则 Note over AMF: ③ 成员 UE 后续注册/UCU 时下发 AMF-->>PCF: UE Policy 关联建立时携带 Internal Group ID 列表 PCF-->>AMF: Namf_Communication_N1N2MessageTransfer (URSP) AMF-->>UE: DL NAS TRANSPORT (URSP 规则) ``` ### 关键 IE 逐条解析 1. **AF → NEF：`Nnef_ParameterProvision_Create`** 这是组的"出生证明"。AF 用 **External Group ID** 作为业务侧标识，并提供完整的成员 GPSI 列表与组数据。注意它不会也不需要知道 Internal Group ID——那是 5GC 内部的事。 2. **NEF → UDM：`Nudm_ParameterProvision_Update`** NEF 作为对外暴露的边界网关，把 AF 的外部数据翻译并下推给 UDM。NEF 还负责鉴权 AF 的请求（哪些 External Group ID、哪些成员 GPSI 是 AF 有权操作的）。 3. **UDM → UDR：两次 `Nudr_DM_Update`** - 第一次写 **Group Identifier translation**：建立 `Internal Group ID ↔ External Group ID ↔ 成员列表` 的翻译表，并把对应 UE 的订阅数据里的 Internal-Group-ID-list 更新（如果成员有变化）。 - 第二次写 **5G VN group data**：把 DNN、S-NSSAI、App descriptor、Max Group Data Rate、UPSec 等存入 UDR 的组订阅数据。 UDM 还可通过 `Nudm_SDM_Get (External Group ID, Group Identifier translation)` 把 External Group ID 翻译成 Internal Group ID 反查。 4. **UDR → PCF：`Nudr_DM_Notify`** PCF（通过 TS 29.505 订阅了组数据变更）收到通知后，**基于 5G VN group data 生成 URSP 规则**。这是把"组数据"翻译成"UE 路由策略"的关键一步——URSP 规则告诉 UE：哪些应用流量要路由到这个 VN 组对应的 (DNN, S-NSSAI)。 5. **URSP 下发** 成员 UE 在通用注册流程（TS 23.502 §4.2.2.2.2）后，AMF 发起 **UE Policy 关联建立**（§4.16.11），把 UE 的 Internal Group ID 列表与 UE Policy Container 传给 PCF；PCF 通过 `Namf_Communication_N1N2MessageTransfer` 把 URSP 经 **DL NAS TRANSPORT** 透传给 UE（§4.2.4.3）。UE 据此知道"我这个应用流量，该去建那个 VN 组的 PDU 会话"。 --- ## 四、机制二：成员 PDU 会话建立——SMF 如何"认出"组成员 VN 组建好后，真正的通信要靠每个成员各自建立一个 **目标为该 (DNN, S-NSSAI) 的 PDU 会话**。这里的核心是：SMF 如何感知"这个 PDU 会话属于某个 VN 组"，并据此做特殊处理（TS 23.501 §5.29.3）。 ```mermaid sequenceDiagram participant UE participant RAN as (R)AN participant AMF participant SMF participant UDM participant PCF participant UPF as PSA UPF UE->>AMF: NAS PDU Session Establishment Request
(DNN + S-NSSAI 指向 VN 组) AMF->>SMF: Nsmf_PDUSession_CreateSMContext
(SUPI, DNN, S-NSSAI) SMF->>UDM: Nudm_SDM_Get (SUPI, 会话管理订阅数据) UDM-->>SMF: 返回 5G VN group data
(Internal Group ID + VN组通信指示) Note over SMF: 关键决策:识别为 VN组成员 SMF->>SMF: 优先选择本组已有 common PSA UPF
(尽量让多成员锚定同一UPF → Local Switch) SMF->>UPF: N4 Session Establishment (UE级)
+ 若组未建Group-level N4: N4 Session Est (Group级) SMF->>PCF: Npcf_SMPolicyControl_Create (Internal Group ID) PCF-->>SMF: SM策略 (可能含 traffic correlation指示 / DNAI) SMF->>UPF: N4 Session Modification
(安装组转发规则, 配置 N19对端信息) SMF-->>AMF: N1 SM: PDU Session Establishment Accept AMF-->>UE: 转发 Accept ``` ### 关键判断点：SMF 的"组感知" - **何时判定为 VN 组会话？** 当 UDM 返回的会话管理订阅数据中包含 **5G VN group data**，且该数据带 **"5G VN group communication 指示"**时，SMF 就按 §5.29.3 / §5.29.4 的组逻辑处理（TS 23.501 §5.29.2 末段）。否则它就是一个普通 PDU 会话。 - **为什么优先选 common PSA UPF？** TS 23.501 §5.29.4 明确：同一个 SMF Set 服务的多个 PDU 会话，SMF 实例会**尽量为同一 VN 组的多个会话选择同一个 PSA UPF**，目的是直接在 UPF 内部完成 Local Switch（本地交换），获得最低时延。这是"控制面偏好"直接驱动用户面拓扑的典型设计。 - **traffic correlation（流量相关）指示：** 当 AF 希望组成员的流量在用户面被同一 DNAI 关联汇聚时（N6 转发场景，§5.29.4），PCF 会下发带 traffic correlation 指示的策略，SMF 据此为这些 PDU 会话重选**共同的 DNAI**，把组流量导向同一边缘点。 --- ## 五、机制三：三种用户面转发方式——本文最核心的拆解 TS 23.501 §5.29.4 与 TS 23.502 §4.13.8.2 定义了 VN 组通信的**三种转发方式**。这是整个机制最有技术含量、也最常被混淆的部分。一个组实际用哪种，取决于"组成员的 PDU 会话锚定在哪里"。 ```mermaid graph TB subgraph LS["① Local Switch 本地交换（同一 PSA UPF）"] UEA1(UE-A) --> UPFLS((PSA UPF 1)) UEB1(UE-B) --> UPFLS UPFLS -. UPF内部交换 .-> UPFLS end subgraph N19T["② N19-based 转发（同 SMF Set，不同 PSA UPF）"] UEA2(UE-A) --> UPF1((PSA UPF 1)) UEB2(UE-B) --> UPF2((PSA UPF 2)) UPF1 <== N19 共享隧道 组级 ==> UPF2 end subgraph N6T["③ N6-based 转发（跨 SMF Set / 经 DN）"] UEA3(UE-A) --> UPF3((PSA UPF 1)) UEB3(UE-B) --> UPF4((PSA UPF 2)) UPF3 -->|N6| DN((DN / 5G VN internal)) DN -->|N6| UPF4 end ``` ### 表 2：三种转发方式对比（TS 23.501 §5.29.4） | 维度 | ① Local Switch | ② N19-based | ③ N6-based | |------|----------------|-------------|------------| | **触发条件** | 组成员 PDU 会话锚定在**同一** PSA UPF | 同一 SMF Set 服务、但锚定在**不同** PSA UPF | **跨 SMF Set**，或需经 DN 转发 | | **转发路径** | 单个 UPF 内部交换 | PSA UPF 之间经共享用户面隧道 | 经 DN（UPF 内部 "5G VN internal" 接口） | | **隧道类型** | 无（内部接口） | GTP-U 或 IETF VPN | N6（可选 L2TP，见 §5.8.2.16） | | **控制面边界** | 单 SMF Set 内 | 单 SMF Set 内 | 跨 SMF Set | | **时延** | 最低（不经任何外部隧道） | 较低（取决于 UPF 间链路） | 较高（经 DN 往返） | | **典型场景** | 园区集中部署、成员同锚点 | 分布式 UPF、同控制面 | 跨地域 / 多控制面部署 | | **以太网处理** | UPF 内 VLAN 收发 | N19 上 VLAN 处理 | N6 上基于 VLAN tag/MAC 转发 | ### 三种方式的设计意图 - **Local Switch 是"最优解但前提苛刻"。** 只有当 SMF 成功把多个成员锚定到同一个 PSA UPF 时才成立。它的时延最低，因为报文根本不出 UPF。规范让 SMF **主动偏袒**这种拓扑（§5.29.4），本质上是在用"控制面 UPF 选择算法"换"用户面零跳转发"。 - **N19-based 是"分布式 UPF 的折中"。** 当成员分布在不同 UPF（仍由同一 SMF Set 控制）时，N19 提供一条**专属于该 VN 组的共享用户面隧道**连接各 PSA UPF（TS 23.501 §8.3.5 给出其用户面协议栈）。注意 N19 是**组级共享**的——不是每对 UPF 一条，而是整组共用一条隧道，这降低了隧道数量爆炸。 - **N6-based 是"兜底与跨域"方案。** 当 UPF 分属不同 SMF Set 时，控制面已无法统一编排，只好借道 DN（或 N6 上的隧道）。此时 IP 流量靠路由协议/预配置 IP 前缀转发；以太网流量靠在隧道上**学习 MAC 地址**转发。 ### Ethernet 类型会话的特殊处理 对于 Ethernet PDU 会话，SMF 会指示 UPF **基于 VLAN tag 分类帧**，并在 N6/N19/内部接口上**增删 VLAN tag**（§5.6.10.2）。这让 5G VN 组可以无缝对接企业现有的 VLAN 划分，是工业现场能用的关键能力。 --- ## 六、机制四：Group-level N4 Session——按"组"而非按"会话"管转发 这是 TS 23.502 §4.13.8.2.2（group-level N4 session management procedures）最具特色的设计。传统 N4 是**每 PDU 会话一条**（UE-level），但 VN 组通信需要 UPF 知道"整组的转发拓扑"（比如 N19 对端有哪些 UPF、广播/组播要复制到哪些成员）。为此引入了 **Group-level N4 Session**。 ### 表 3：UE-level N4 vs Group-level N4 | 维度 | UE-level N4 Session | Group-level N4 Session | |------|---------------------|------------------------| | **管理对象** | 单个 UE 的 PDU 会话 | 整个 5G VN 组 | | **生命周期** | 随 PDU 会话建立/释放 | 组内**首个**成员建立时创建，**最后**一个成员离开时释放 | | **关键 IE** | F-TEID、PDR/FAR/QER | 组转发规则、N19 对端 F-TEID、广播/组播复制规则 | | **作用** | 个体会话的上下行转发 | 组内/跨 UPF 的转发编排（Local Switch/N19 路径） | **工作机制：** SMF 为该组在 PSA UPF 上维护一个 Group-level N4 会话。每当组成员的 PDU 会话锚定到不同 UPF（需 N19）或同一 UPF（需 Local Switch）时，SMF 通过 group-level N4 会话下发/更新转发规则。当**同一 VN 组的 PDU 会话锚定在不同 UPF**时，SMF 需要在它们之间配置 N19（§4.13.8.2.1）。这样，组成员动态增减时，只有组级 N4 的转发规则变化，而不必逐个改动每条会话的 N4——这是"组"这个抽象带来的编排效率。 --- ## 七、实战连接：抓包识别与故障排查 ### 如何在 Wireshark/抓包中识别这条流程 1. **NEF Provisioning（组创建）：** 过滤 `Nnef_ParameterProvision` 相关 HTTP/2（SBI）消息，观察 Request Body 中是否含 `External Group ID`、`gpsis` 列表与 `5gVnGroupData`（含 `dnn`/`snssai`/`pduSessionTypes`）。 2. **组数据下发：** `Nudr_DM_Notify`（订阅通知）或 `Nudm_SDM_Get` 返回中含 `5gVnGroupData` 与 `internalGroupId`，即 VN 组被 SMF/PCF 感知。 3. **N4 group-level 会话：** 在 PFCP（N4）抓包中，`PFCP Session Establishment Request` 内若携带组级转发规则 / N19 对端 F-TEID，且无对应单 UE PDR，可判定为 Group-level N4 会话。 4. **N19 隧道：** N19 在用户面表现为 PSA UPF 之间的 **GTP-U**（或 IETF VPN），TEID 属于"组共享隧道"，目标 IP 为对端 PSA UPF，而非 gNB/DN。 5. **Local Switch：** 表现为组内成员的上下行流量在**同一个 UPF 内部**完成交换，**不出现** N6/N3 之间的二次转发报文。 ### 表 4：常见故障点与排查思路 | 故障现象 | 可能原因 | 排查方向 | |---------|---------|---------| | 组成员无法互通 | UDR 未正确存组数据 / PCF 未生成 URSP | 查 `Nudr_DM_Update` 是否成功、PCF 是否订阅了组数据变更 | | 流量绕经 DN（时延高） | 未选到 common PSA UPF，退化成 N6 | 查 SMF 的 UPF 选择是否考虑了组偏好；查是否配置 traffic correlation | | N19 转发不通 | 组级 N4 会话未建 / N19 对端 F-TEID 缺失 | 查 group-level N4 Session Establishment 是否下发；查 N19 隧道连通性 | | Ethernet 帧丢 VLAN | UPF 未按 §5.6.10.2 处理 VLAN tag | 查 N4 下发的 VLAN tag 处理规则 | | 新成员加入组不生效 | Internal-Group-ID-list 未更新到 UDR | 查 AF→NEF→UDM 的成员更新链路；查 UE 是否收到新 URSP | ## 八、常见问题 **Q1: Local Switch、N19、N6 三者会同时启用吗？** A: 同一个 VN 组在不同成员组合下会触发不同方式。当若干成员锚定在同一 PSA UPF 时走 Local Switch，分布在不同 UPF（同 SMF Set）时走 N19，跨 SMF Set 时走 N6。一个组可同时存在这三种子拓扑，SMF 按成员当前锚点动态选择转发规则。 **Q2: 为什么 DNN/S-NSSAI/UPSec 创建后不可改？** A: 因为 (DNN, S-NSSAI) 是 VN 组与 PDU 会话的映射锚点，UPSec 关系整组用户面安全。运行中修改会破坏已建会话与组数据的一致性，导致转发规则失效。规范用"锁死"换取一致性，需要变更时只能新建组。 **Q3: Group-level N4 会话何时建立、何时释放？** A: 组内**第一个**成员 PDU 会话锚定到某 PSA UPF 时建立该 UPF 上的 Group-level N4 会话；**最后一个**成员离开时释放。生命周期与组绑定，独立于单个成员会话的来去。 **Q4: 5G VN 组与普通网络切片有什么区别？** A: 切片（Slicing）是网络级的资源隔离与拓扑划分；VN 组是**组通信**能力——让一组 UE 彼此直接通信并支持组级转发/策略。一个 VN 组绑定一个 (DNN, S-NSSAI)，可以视为切片内承载特定组通信业务的一种"组级服务"。两者正交：切片做隔离，VN 组做组内互通。 **Q5: 非 Ethernet（IP 类型）VN 组如何跨 UPF 转发？** A: 对 IP 流量，跨 SMF Set 的 N6/N19 转发可基于**路由协议或预配置 IP 地址前缀**（对应不同 SMF Set）来路由；对 Ethernet 流量，则基于**在用户面隧道上学习到的 MAC 地址**转发（§5.29.4 NOTE）。 --- ## 参考来源 1. [3GPP TS 23.501 (System architecture for the 5G System) — §5.29 Support for 5G LAN-type service, §5.29.2/5.29.3/5.29.4](https://www.3gpp.org/dynareport/23501.htm) — VN 组管理与用户面三种转发方式的权威定义 2. [3GPP TS 23.502 (Procedures for the 5G System) — §4.13.8 Support of 5G LAN-type service, §4.15.6.2 NEF provisioning](https://www.3gpp.org/dynareport/23502.htm) — VN 组通信流程与 group-level N4 session 管理流程 3. [free5GC — 5G LAN-type service Introduction](https://free5gc.org/blog/20250122/20250122/) — 开源实现视角的 VN 组创建与三种通信方式解读 4. [iTechSpec — TS 23.501 §5.29.2 5G VN group management / §5.29.4 User Plane handling](https://itecspec.com/3gpp/23.501/s/5.29.2) — 在线规范条款逐段对照 5. [3GPP — 5G LAN Charging](https://www.3gpp.org/technologies/lan-charging) — VN 组通信的计费架构与组级计费要点 --- > 本文由「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 等场景全覆盖。