# 5G VN 组通信与本地交换信令全链拆解：从 AF 组管理到 N4 流量规则 ## 一、为什么需要 5G LAN-type 服务 在 5G 服务垂直行业（工业 4.0、智慧园区、车联网）的过程中，运营商和设备商发现一个反复出现的需求：**一组 UE 之间需要像局域网（LAN）一样通信**——它们要能互相发送广播/多播报文，要能二层数据帧直接互通（Ethernet 类型），要能享受"局域网内通信不出公网"的低时延与隔离性，还要像传统 VLAN 一样灵活分组。 4G 时代，这类需求靠 APN+VPN 或 EPC 本地 IP 流（LIPA/SIPTO）勉强支撑，但存在分组僵化、二层数据不通、组管理无标准化接口等问题。3GPP 在 **Release 16** 正式引入 **5G LAN-type service**（5G 局域网类服务），并在 **TS 23.501 Section 5.29** 给出了完整的架构定义，在 **TS 23.502 Section 4.4.6/4.4.7** 给出了组管理与组通信的信令流程，在 **TS 23.503 Section 5.41** 给出了 5G VN 组数据的策略框架。 其核心抽象是 **5G Virtual Network (5G VN) group**——一组共享同一私有通信空间的 UE 集合。一个 5G VN 组用 **External Group Identifier** 标识，绑定一个 DNN/S-NSSAI 组合，并定义通信类型（单播、广播/多播）、PDU 会话类型（IP 或 Ethernet）等属性。组内成员之间的报文，不再走传统"UE→UPF→DN（互联网/企业网）→UPF→UE"的迂回路径，而是由 5GC 在用户面就近完成交换。 理解 5G LAN-type 的关键，是把它拆成**三件事**来看： 1. **组怎么建**（5G VN group management）——AF 通过 NEF/UDM 创建组、配置成员与策略； 2. **会话怎么建**（5G LAN-type PDU Session）——UE 发起带 5G VN DNN 的 PDU 会话，SMF 识别组并下发组通信规则； 3. **报文怎么转**（5G VN group communication）——UPF 在 SMF 的 N4 规则下完成 local switch / N19 / N6 三种模式的转发。 下面逐一拆解每一步的信令链与关键 IE。 ## 二、5G VN 组管理信令流：AF → NEF → UDM ### 2.1 设计意图 5G LAN-type 把"组"提升为一等公民的网络资源。组数据（成员列表、DNN、S-NSSAI、QoS、服务区域、通信类型）必须可被 **AF（应用功能）动态创建和修改**，且要在会话建立前就下发到 **UDM**（统一数据管理，存储签约与组数据）和 **PCF**（策略控制）。这就是为什么组管理走 **AF → (NEF) → UDM/PCF** 的北向接口，而不是走 UE 触发的 NAS 流程——组是企业/运营商侧的资源，与单个 UE 的移动性无关。 ### 2.2 完整时序图 ```mermaid sequenceDiagram participant AF as AF
(企业应用) participant NEF as NEF participant UDM as UDM participant UDR as UDR participant PCF as PCF participant SMF as SMF Note over AF,SMF: 阶段一：5G VN 组创建 AF->>NEF: Nnef_5gVnGroupConfiguration Create
(External Group ID, DNN, S-NSSAI,
members, PDU session type, comm type) NEF->>NEF: 鉴权 + External→Internal Group ID 映射 NEF->>UDM: Nudm_5gVnGroupConfiguration Create UDM->>UDR: Nudr_DataRepository POST
(5gVnGroupData) UDR-->>UDM: 201 Created UDM-->>NEF: Internal Group ID NEF-->>AF: 201 Created (Group ID) Note over AF,SMF: 阶段二：组数据变更通知 UDM->>PCF: Nudm_SDM_Notification
(5G VN group data changed) PCF->>SMF: Npcf_SMPolicyControl_Update
(下发组通信策略) Note over SMF: SMF 缓存组策略,
等待成员 UE 建立 PDU 会话 ``` ### 2.3 关键 IE：5G VN group data TS 23.501 §5.29.2 明确规定了 5G VN group data 包含的字段。下表逐一说明这些字段的含义与作用： | 字段（IE） | 含义 | 取值示例 | 影响 | |-----------|------|---------|------| | **External Group Identifier** | 外部组标识（AF 侧可读） | `vip-group-01@enterprise.com` | AF 用来引用组，NEF 映射成 Internal Group ID | | **Internal Group Identifier** | 5GC 内部组标识 | `groupid-12345678` | UDM/PCF/SMF 内部使用，唯一标识该 VN 组 | | **DNN** | 组绑定的数据网络名 | `internet-vn` | UE 发起 PDU 会话时必须匹配此 DNN | | **S-NSSAI** | 组绑定的切片 | `SST=100, SD=0x123` | 与 DNN 共同定位组成员的 PDU 会话 | | **PDU Session Type** | 会话类型 | `IPv4` / `IPv6` / `Ethernet` | Ethernet 类型支持二层数据帧（工业场景关键） | | **5G VN group communication type** | 组通信类型 | `Unicast` / `Broadcast` / `Multicast` / 组合 | 决定 SMF 下发的 N4 转发规则形态 | | **Application Descriptor** | 应用描述符 | App-layer 标识 | 用于匹配组内业务流（R17 增强） | | **组成员列表** | External UE IDs | SUPI/External UE ID 列表 | 决定哪些 UE 能建立属于该组的 PDU 会话 | | **Service Area / QoS** | 服务区域与 QoS | TA 列表 + 5QI | 限制组的地理范围与带宽保障 | ### 2.4 设计精妙之处 注意一个细节：**5G VN 组数据存储在 UDR，由 UDM 通过 Nudr 访问**，这与签约数据（Subscription Data）走同一条数据仓储路径。这意味着运营商可以像管理用户套餐一样管理 VN 组——批量导入、计费关联、生命周期管理。组数据变更后，UDM 通过 **Nudm_SDM Notification** 主动通知已订阅该组数据的 PCF/SMF，触发组通信策略的动态更新。这是一种典型的"控制面订阅-通知"模式，避免了 SMF 每次建立会话时都去 UDM 拉取完整组数据。 ## 三、5G LAN-type PDU 会话建立信令流 当组的成员 UE 上线并发起带 5G VN DNN 的 PDU 会话时，核心网才真正进入"组通信准备"阶段。这一流程基于通用的 **UE Requested PDU Session Establishment（TS 23.502 §4.3.2.2）**，但在 SMF 内部增加了 5G VN 专属处理逻辑（TS 23.502 §4.4.6 中对 5G LAN-type 的增强）。 ### 3.1 完整时序图 ```mermaid sequenceDiagram participant UE as UE
(组成员) participant RAN as (R)AN participant AMF as AMF participant SMF as SMF participant UDM as UDM participant PCF as PCF participant UPF as UPF(PSA) UE->>AMF: NAS: PDU Session Est. Request
(DNN=vn, S-NSSAI, PDU sess type) AMF->>SMF: Nsmf_PDUSession_CreateSMContext
(DNN, S-NSSAI, SUPI) SMF->>UDM: Nudm_SDM_Get
(5G VN group data, membership) UDM-->>SMF: 组数据 + 确认该 UE 是组成员 SMF->>PCF: Npcf_SMPolicyControl_Create
(请求组通信策略) PCF-->>SMF: PCC Rule + 5G VN group policy
(通信模式、QoS、转发策略) Note over SMF: SMF 决策通信模式:
local switch / N19 / N6
并生成 N4 转发规则 SMF->>UPF: N4 Session Establishment/Modification
(PDR/FAR/QER + 组转发规则) UPF-->>SMF: N4 响应 (F-TEID) SMF-->>AMF: Nsmf response (N2 SM info) AMF->>RAN: N2 PDU Session Resource Setup RAN->>UE: RRC Reconfig + NAS Accept UE-->>RAN: 上行数据 (本地交换/转发就绪) ``` ### 3.2 SMF 的关键决策点 整个流程中，**SMF 是 5G LAN-type 的智能中枢**。它在拿到 UDM 的组数据与 PCF 的策略后，必须做出一个核心决策：**这个组成员的报文，按哪种模式转发？** SMF 的决策逻辑（TS 23.502 §4.4.6 + §4.4.7）可归纳为： ```mermaid flowchart TD A[SMF 收到成员 UE 的
PDU 会话建立请求] --> B{该组所有成员的
PDU 会话是否都锚定在
同一个 PSA UPF?} B -- 是 --> C[模式一: Local Switch
UPF 内本地交换] B -- 否 --> D{是否支持 N19 接口
且运营商配置了 N19?} D -- 是 --> E[模式二: N19-based
UPF 间隧道转发] D -- 否 --> F[模式三: N6-based
经外部 DN/LAN 转发] C --> G[SMF 下发 N4 FAR:
同 UPF 内 PDU 会话间
直接转发] E --> H[SMF 下发 N4 FAR:
封装到 N19 隧道,
目标对端 PSA UPF] F --> I[SMF 下发 N4 FAR:
转发到 N6 DN,
由外部 LAN 完成交换] ``` ### 3.3 关键信令消息中的 IE **消息①：UE → AMF 的 NAS PDU Session Establishment Request** - `DNN`：必须是 5G VN 组绑定的 DNN（如 `vn-dnn`）； - `S-NSSAI`：组绑定的切片； - `PDU session type`：IP 或 Ethernet，必须与组定义一致（否则 SMF 拒绝）； - `5G VN group related`：UE 通常不显式带组 ID（UE 不感知组），组归属由 DNN+S-NSSAI 隐式定位。 **消息②：AMF → SMF 的 Nsmf_PDUSession_CreateSMContext** - 关键 IE 与通用 PDU 会话一致，但 SMF 在解析 DNN 后会触发"是否为 5G VN DNN"的判断，若是，则后续向 UDM 请求 5G VN group data。 **消息③：SMF → UDM 的 Nudm_SDM_Get（5G VN group data）** - 这是 5G LAN-type 区别于普通会话的**第一个独有步骤**。SMF 请求两类信息：①5G VN group data（组配置）；②该 UE 的 group membership（确认是否组成员）。非组成员即使使用相同 DNN 也会被拒绝。 **消息④：PCF → SMF 的 PCC Rule** - PCF 从 UDM 订阅的组数据中获取通信策略，生成 **5G VN group policy**，包括：是否允许广播、是否允许组外通信、QoS 流模板等。 **消息⑤：SMF → UPF 的 N4 Session（PFCP）** - 这是 5G LAN-type 的**技术核心**。SMF 下发的 PFCP 规则中，FAR（Forwarding Action Rule）会被配置成"组通信转发规则"——详见下一节。 ## 四、三种组通信模式与 N4 规则的深度映射 5G VN 组通信之所以能省去外部网络迂回，全靠 UPF 在 N4 规则驱动下的智能转发。TS 23.501 §5.29.3 定义了三种模式，它们在用户面路径与 N4 规则形态上完全不同。 ### 4.1 模式一：Local Switch（本地交换） **适用场景**：组内通信的双方成员都锚定到**同一个 PSA UPF**。 **用户面路径**：报文进入该 UPF 的 N3 接口后，UPF 直接根据 FAR 将报文从对方成员的 N3 接口送出，**完全不经过 N6/N9**。 **N4 规则形态**： - SMF 在该 UPF 上为每个组成员 PDU 会话建立 PDR（Packet Detection Rule）； - FAR 中配置 `Forward` 动作，目标接口指向**同 UPF 内另一个组成员的 PDU 会话对应的接口**； - 关键是 UPF 内部维护一张"组成员 ↔ 接口/F-TEID"的转发表，由 SMF 通过 N4 维护更新。 这是延迟最低的模式（纯本地交换，无跨网元传输），也是园区/工厂内同 UPF 覆盖场景的首选。 ### 4.2 模式二：N19-based（N19 隧道转发） **适用场景**：组内成员锚定到**不同 PSA UPF**，但运营商在 UPF 之间配置了 **N19 接口**。 **用户面路径**：源 UPF 把组播/单播报文封装进 **N19 隧道**（N19 是一个共享的 GTP-U 用户面隧道，专门连接同一个 5G VN 组的所有 PSA UPF），目标 UPF 解封装后转发给本地组成员。 **N4 规则形态**： - FAR 中配置 `Outer Header Creation`，封装目标为对端 PSA UPF 的 N19 F-TEID； - 所有相关 UPF 都需在 N19 隧道上监听； - 对广播/多播报文，源 UPF 将报文复制到 N19 隧道，各 PSA UPF 再本地分发。 ### 4.3 模式三：N6-based（经外部 DN/LAN） **适用场景**：组内成员分散、或需与外部 LAN 互通。 **用户面路径**：报文经 PSA UPF 的 **N6 接口**送达外部数据网络（如企业 LAN），由外部网络的交换机/路由器完成组成员间的转发。这与普通 PDU 会话的 N6 转发无异，但 5G LAN-type 可配合 5G VN 组的 DNN 将组内流量隔离到特定 N6 子网。 ### 4.4 三种模式对比 | 维度 | Local Switch | N19-based | N6-based | |------|-------------|-----------|----------| | **转发节点** | 单一 PSA UPF 内部 | 多个 PSA UPF 经 N19 隧道 | 外部 DN/LAN | | **时延** | 最低（无跨网元） | 中（UPF 间隧道） | 高（外部网络） | | **二层数据（Ethernet）** | ✅ 完整支持 | ✅ 支持 | 取决于外部网络 | | **N4 FAR 关键配置** | 同 UPF 内会话间转发 | Outer Header Creation → N19 TEID | 转发到 N6 接口 | | **适用场景** | 园区/车间同 UPF | 跨 UPF 大型组 | 与企业现网融合 | | **运营商控制力** | 完全在 5G 内 | 5G 内 + N19 隧道 | 依赖外部网络 | ## 五、组通信的"状态机"：SMF 侧的会话状态转换 5G LAN-type 引入了组成员 PDU 会话的动态加入/离开机制，SMF 侧需要维护组级状态。下图刻画了 SMF 对一个组成员会话的状态管理： ```mermaid stateDiagram-v2 [*] --> 非组成员: UE 未签约该 VN 组 非组成员 --> 组成员_活跃: UE 建立 VN PDU 会话
N4 下发组转发规则 组成员_活跃 --> 组成员_挂起: UE 进入空闲/挂起
N4 规则保留但暂停转发 组成员_挂起 --> 组成员_活跃: UE 恢复(Service Request)
N4 规则重新激活 组成员_活跃 --> 非组成员: AF 删除成员
或 PDU 会话释放 组成员_挂起 --> 非组成员: 组删除/成员移除 note right of 组成员_活跃 SMF 监听组数据变更: 成员增减/通信模式变更 → 动态更新 N4 规则 end note ``` 值得注意的是，当一个新成员加入组（AF 增删成员触发 UDM 通知），**已活跃成员所在的 SMF 会收到组数据变更通知，进而动态更新其 UPF 上的 N4 转发规则**——例如在 Local Switch 模式下把新成员的接口加入转发表。这种"组策略驱动 N4 动态变更"是 5G LAN-type 区别于传统静态会话的根本特征。 ## 六、抓包识别与实战排错 ### 6.1 抓包如何识别 5G LAN-type 流程 在 5GC 内部抓包（如 free5GC/open5GS 测试床）时，可按以下特征定位： 1. **Nsmf 接口**：AMF→SMF 的 `Nsmf_PDUSession_CreateSMContext` 中携带特定 DNN（如配置为 `internet` 之外的 VN 专用 DNN）； 2. **Nudm 接口**：SMF→UDM 出现 `Nudm_SDM_Get` 且 resource 指向 `5gVnGroupData` 或包含 `internalGroupIds`； 3. **Nudm_SDM_Notification**：UDM 主动向 PCF/SMF 推送组数据变更（标志动态组管理）； 4. **N4 (PFCP)**：UPF 收到的 `Session Establishment Request` 中，FAR 的 `Forwarding Parameters` 出现 N19 Outer Header Creation，或指向同 UPF 内其他 PDU 会话的转发指示； 5. **用户面**：组成员间的报文在 UPF 抓包中可见 N3 双向流量，但**N6 方向无对应报文**（Local Switch 模式下），这是识别本地交换最直观的证据。 ### 6.2 常见故障点 | 故障现象 | 可能原因 | 排错思路 | |---------|---------|---------| | UE 用 VN DNN 建会话被拒 | UE 非组成员；DNN/S-NSSAI 与组不匹配 | 检查 UDM 中该 UE 的 group membership 与 DNN 签约 | | 组内成员互不通 | SMF 未下发组转发规则；N4 规则 FAR 配置错误 | 抓 N4 报文确认 FAR 动作；检查 SMF 日志的通信模式决策 | | 跨 UPF 组播丢失 | N19 隧道未建立；Outer Header Creation TEID 缺失 | 确认两 PSA UPF 间 N19 配置；检查 SMF 是否选择了 N19 模式 | | 组成员动态增减不生效 | SMF 未订阅 UDM 组数据通知 | 检查 SMF→UDM 的 SDM 订阅是否覆盖 5G VN group data | | Ethernet 类型 PDU 失败 | UPF 不支持 Ethernet 类型 / 组定义类型不匹配 | 确认组 PDU session type 与 UE 请求一致；验证 UPF 能力 | ## 七、与其他专网方案的对比 | 方案 | 5G VN 组（5G LAN-type） | 5G TSN（时间敏感网络） | 5G Multicast/Broadcast（5MBS） | 传统 APN+VPN | |------|------------------------|----------------------|------------------------------|-------------| | **核心目标** | 组内 LAN 式互通 | 有界时延 + 时间同步 | 单点到多点广播 | 隔离与远端互通 | | **关键技术** | Local Switch/N19/N6 | gPTP、TSN 网桥、时间敏感流 | MB-SFN、PTM 无线传输 | IPSec/GRE 隧道 | | **组管理接口** | AF→NEF→UDM 标准化 | TSN AF/CUC 配置 | MBSF/MBSTF 管理 | 静态配置 | | **二层数据** | ✅ Ethernet 类型原生 | ✅ | 取决于实现 | ❌ 多为三层 | | **引入版本** | R16 | R16/R17 | R17 | R8 起 | | **典型场景** | 智慧园区、工业组网 | 工业自动化运动控制 | 大型场馆直播 | 通用企业接入 | ## 常见问题 **Q1：5G LAN-type 与网络切片是什么关系？** A：切片解决的是"资源隔离与按需网络（按 S-NSSAI 切分）"，而 5G LAN-type 解决的是"组内成员 LAN 式互通"。两者正交但常组合使用——5G VN 组绑定一个 S-NSSAI，意味着这个专网组运行在专属切片上，既获得资源隔离又获得组通信能力。一个切片内可以有多个 5G VN 组。 **Q2：Local Switch 和 UL CL（Uplink Classifier）本地分流有什么区别？** A：UL CL（已在前序专题拆解）是**同一个 UE** 的流量按业务分流到不同 PSA UPF/N6，强调"本地出口"；而 Local Switch 是**不同 UE** 之间的报文在 UPF 内交换，强调"组内互通"。UL CL 的分流对象是 DN 方向，Local Switch 的交换对象是另一个组成员的 N3。两者可在同一 UPF 共存。 **Q3：UE 是否感知自己属于某个 5G VN 组？** A：基本不感知。UE 只知道自己用某个 DNN/S-NSSAI 建立了 PDU 会话，组归属、通信模式、转发规则全部由 5GC（SMF/UPF）在控制面决策。这正是 5G LAN-type 的设计优雅之处——对 UE 透明，组逻辑完全在网络侧。 **Q4：N19 隧道为什么需要单独定义，不能复用 N9？** A：N9 是点对点的 UPF 间用户面接口（用于同一会话跨 UPF 的 PSA-IUPF 链路），按 PDU 会话粒度建隧道。而 N19 是**组粒度**的共享隧道——一个 5G VN 组的所有 PSA UPF 共享一条 N19 隧道来承载组内广播/多播流量，避免为每个成员对单独建 N9。N19 的引入正是为了高效支持组播。 **Q5：5G LAN-type 如何计费？** A：3GPP 在 TS 32.255 中定义了 5G LAN 计费框架。由于组通信可能在 5G 内部完成（Local Switch 不经 N6），计费基于**组成员 PDU 会话的用户面流量统计**（CHF 经 SMF 上报），并支持按组（Internal Group ID）维度聚合计费，便于企业按"组"而非按"个人"结算。 ## 参考来源 1. [3GPP TS 23.501 V18.x — System architecture for the 5G System, Section 5.29 (Support of LAN-type service), §5.29.2/5.29.3](https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3144) — 5G VN 组管理与组通信架构定义 2. [3GPP TS 23.502 V18.10.0 — Procedures for the 5G System, Section 4.4.6/4.4.7](https://www.3gpp.org/dynareport/23502.htm) — 5G VN group configuration 与 5G LAN-type PDU 会话信令流程 3. [3GPP TS 23.503 — Policy and Charging Control framework, Section 5.41](https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3334) — 5G VN group data 的策略框架 4. [free5GC — 5G LAN-type service Introduction](https://free5gc.org/blog/20250122/20250122/) — Local Switch / N19 / N6 三种通信模式的工程实现解读 5. [3GPP — 5G for Industry 4.0: TSN & 5G LAN-type service](https://www.3gpp.org/news-events/3gpp-news/tsn-v-lan) — 5G VN 组识别、成员管理与垂直行业应用背景 6. [3GPP — 5G LAN Charging](https://www.3gpp.org/technologies/lan-charging) — 5G 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 等场景全覆盖。