子域聚焦：切片与边缘计算（slicing-mec）｜规范基线：3GPP TS 23.501 V18.x / TS 23.502 V18.x / TS 22.261 / TS 23.247（5MBS）
切片（Slicing）解决了"网络资源的逻辑隔离"，但工业4.0、智慧园区、AGV协同、电网差动保护等垂直场景里，运营商和企业的真正诉求往往不是"我和别人隔离"，而是"我这一组设备之间要像在一个局域网（LAN）里那样直接互通"。传统的N6回源方式（组内UE之间通信要绕道DN里的交换机/路由器）会引入额外的往返时延，而且打破了二层（Layer-2）的组网模型，对那些依赖以太网帧、组播（如ARP、PTP、IGMP/MLD、工业PROFINET/OPC-UA组播）的存量应用极不友好。
为此，3GPP在TS 22.261 第6.26节"5G LAN-type service"提出了服务需求，并在TS 23.501 第4.4.6节（参考点定义）与第5.29节"Support for 5G LAN-type service"给出了完整的系统架构与机制定义。这就是本文的主角——5G LAN型服务（5G LAN-type Service）与5G虚拟网络组（5G VN Group）通信。
它的核心价值可以一句话概括：让5G系统在5G核心网用户面（UPF）内部，按"组"完成成员间数据的本地交换或受控组播，使一组UE的行为等价于接入同一台局域网交换机。 这正是它被归入"slicing-mec（切片与边缘计算）"子域的根本原因——它既是切片的"应用面"（每个组绑定独立的DNN+S-NSSAI），又是MEC/边缘计算的"使能面"（数据在靠近UE的UPF本地分流，不出园区骨干）。
先厘清三个经常被混用的术语（TS 23.501 5.29.1）：
| 概念 | 定义 | 类比 |
|---|---|---|
| 5G LAN型服务 | 一种提供类似LAN/VPN能力、但叠加5G高性能/远距离接入/移动性/安全性的服务 | "5G版的局域网" |
| 5G LAN-VN（虚拟网络） | 一个能够支撑5G LAN型服务的虚拟网络 | "一个虚拟交换机域" |
| 5G VN组（5G VN Group） | 使用私有通信进行5G LAN型通信的一组UE | "VLAN里的一个成员组" |
一个5G VN组绑定一个特定的DNN + S-NSSAI，组内成员都建立到该DNN/S-NSSAI的PDU会话，从而获得互通能力。支持IPv4、IPv6、以太网（Ethernet）三种PDU会话类型——其中以太网类型对承载二层工业协议至关重要。
架构上新增/扩展的关键参考点（TS 23.501 4.4.6.2）：
5G VN组的管理（创建/修改/删除/成员增减）是整个机制的"控制面入口"。它通过NEF对外开放的服务完成，最终数据沉淀在UDM/UDR中，并在UE注册后以UE策略（URSP）的形式下发到UE。对应的规范信令分布在 TS 23.502 第4.2.2.2.2（通用注册）、4.2.4.3（用于透明UE策略传递的UCU）、4.15.6.2（NEF业务信息流）、4.16.11（UE策略关联建立）。
一个5G VN组在UDM中由以下信息完整刻画（TS 23.501 5.29.2）：
flowchart TD
G["5G VN Group 配置 (TS 23.501 5.29.2)"]
G --> ID["① 组标识 Identities"]
G --> MEM["② 组成员 Membership"]
G --> DATA["③ 组数据 Group Data"]
ID --> EXT["External Group ID —— AF可见的外部标识"]
ID --> INT["Internal Group ID —— UDM分配的内部标识"]
MEM --> GPSI["GPSI列表 —— 唯一标识每个成员UE"]
DATA --> DNN["DNN —— VN专用数据网络名"]
DATA --> SNS["S-NSSAI —— 网络切片"]
DATA --> PST["PDU Session Type —— IPv4/IPv6/Ethernet"]
DATA --> AD["Application Descriptor —— 触发URSP路由匹配"]
DATA --> SA["二次认证信息 —— DN-AAA可分配UE IP"]
设计意图很清晰：External/Internal Group ID的双层映射让AF只持有业务语义的外部组号，运营商侧的SUPI/GPSI等隐私信息不暴露给第三方；GPSI作为成员标识则与计费、外部标识体系打通。
下面这条时序图把"组创建"与"组成员注册后获得组策略"两段串成完整信令流：
sequenceDiagram
participant AF as AF（应用功能）
participant NEF as NEF
participant UDM as UDM
participant UDR as UDR
participant UE as UE（组成员）
participant AMF as AMF
participant PCF as PCF
Note over AF,UDR: 阶段一：5G VN 组创建/配置（TS 23.502 4.15.6.2）
AF->>NEF: Nnef_5GVNGroup Create<br/>(External Group ID, GPSI, DNN, S-NSSAI)
NEF->>UDM: Nudm_5GVNGroup<br/>(External Group ID, 5G VN group data)
UDM->>UDR: Nudr_DM_Create<br/>(Internal Group ID映射, 5G VN Group Configuration)
UDM-->>NEF: Internal Group ID
NEF-->>AF: Create响应 (Internal Group ID)
Note over UE,PCF: 阶段二：成员注册并获取5G VN策略（TS 23.502 4.2.2.2.2 / 4.16.11）
UE->>AMF: Registration Request
AMF->>UDM: Nudm_SDM_Get(SUPI)<br/>返回 Internal-Group-ID-list
AMF-->>UE: Registration Accept
AMF->>PCF: Npcf_UEPolicyControl Create<br/>(Internal-Group-ID-list, UE Policy Container)
PCF->>UDR: Nudr_DM_Query(Internal-Group-Id,<br/>5G VN Group Configuration)
UDR-->>PCF: 5G VN group data + 成员关系
Note over PCF: PCF据此生成URSP规则<br/>(RouteSelectionDescriptor→VN专用DNN/S-NSSAI)
PCF->>AMF: Namf_Communication_N1N2MessageTransfer<br/>(SUPI, UE Policy Container)
AMF->>UE: DL NAS TRANSPORT (UE Policy Container: URSP)
关键IE逐步解析：
Nnef_5GVNGroup Create：AF通过NEF提交的是业务级元数据——外部组号、成员GPSI清单、VN的DNN/S-NSSAI、PDU类型、应用描述符。NEF在此做鉴权与映射（External→Internal）。Internal Group ID：UDM为新组分配的内部唯一标识，后续PCF/SMF都用它去UDR取组配置。Internal-Group-ID-list：注册过程中，AMF从UDM取回该UE所属的全部内部组号，并在UE策略关联建立时透传给PCF。这是"该UE属于哪些VN组"的唯一来源。Nudr_DM_Query(…, 5G VN Group Configuration)：PCF凭Internal-Group-ID到UDR拉取组数据，从而知道"该组用哪个DNN/S-NSSAI、应用描述符是什么"，进而合成URSP规则。RouteSelectionDescriptor会把"匹配某应用描述符的业务流量"强制路由到"该VN组的DNN+S-NSSAI PDU会话"。没有它，UE的APP流量会走默认会话，永远进不了组。DL NAS TRANSPORT：UE策略通过NAS直通容器下发（TS 23.502 4.2.4.3），与业务面解耦。设计意图：组配置是"网络侧权威数据"，UE策略是"UE侧执行依据"，二者通过注册流程在PCF处汇合并由PCF统一编排，避免了UE自行猜测应走哪个会话。
当组内UE都建立起到VN-DNN/S-NSSAI的PDU会话后，SMF会根据每个成员的PDU会话锚点（PSA UPF）分布情况，选择三种转发方式之一来承载组内流量（TS 23.501 5.29.3）。这是整个机制最具技术含量、也最值得抓包验证的部分。
flowchart LR
UE1(("UE-1<br/>成员A"))
UE2(("UE-2<br/>成员B"))
UE3(("UE-3<br/>成员C"))
PSA1["PSA UPF-1<br/>(园区东侧)"]
PSA2["PSA UPF-2<br/>(园区西侧)"]
UE1 -->|N3 PDU会话| PSA1
UE2 -->|N3 PDU会话| PSA1
UE3 -->|N3 PDU会话| PSA2
PSA1 -.M1:本地交换<br/>UPF内部接口<br/>(UE1↔UE2).- PSA1
PSA1 <==>|"M2:N19共享隧道<br/>跨PSA组通信<br/>(UE1/2↔UE3)"| PSA2
PSA1 -->|M3:N6回源| DN[("DN<br/>组播路由器/交换机")]
DN --> PSA2
方式一：本地交换（Local Switch） 当多个组内成员的PDU会话共享同一个PSA UPF时，该UPF通过其内部的"5G VN internal interface"在成员的N4会话之间直接转发流量，数据完全不出该UPF。这是时延最低、最省隧道资源的方式，是MEC本地分流的理想形态。
方式二：N19-based转发 当组成员的PDU会话分散在不同PSA UPF（例如不同园区、不同边缘节点）时，组内通信通过N19完成。N19是一条连接同一个5G VN组所有PSA UPF的"共享用户面隧道"（shared User Plane tunnel）。SMF在PDU会话建立时为该组配置/加入这条N19隧道，组内任意成员的上行数据进入自己PSA后，经N19复制分发到其他成员的PSA，再下行到目的UE。
方式三：N6-based转发 当组通信需要借助DN里的交换机/路由器/组播服务器（例如存量企业组播网络）时，流量走N6回到DN，由DN设备完成组内分发。这种方式兼容性最好，但引入了DN的往返时延，常用于和现网二层/三层设备对接的过渡场景。
| 维度 | 本地交换 Local Switch | N19-based | N6-based |
|---|---|---|---|
| 适用拓扑 | 组成员同锚点（单PSA） | 组成员跨锚点（多PSA） | 需借助DN/组播服务器 |
| 数据是否出UPF | 否（UPF内部转发） | 否（UPF↔UPF隧道） | 是（绕道DN） |
| 时延 | 最低 | 中（受N19跳数影响） | 最高（DN往返） |
| 隧道资源 | 无额外隧道 | 每组一条共享N19 GTP-U隧道 | 无额外5GC隧道 |
| 二层（Ethernet）支持 | 原生支持 | 原生支持 | 取决于DN设备 |
| 组播/广播承载 | UPF内部复制 | N19复制分发 | DN组播协议（IGMP/MLD） |
| 典型场景 | 单园区AGV协同 | 跨厂区/跨边缘节点组网 | 对接存量企业LAN |
| SMF/N4配置复杂度 | 低 | 中（需管理N19隧道生命周期） | 低 |
设计意图：把"是否本地"这件事交给PDU会话锚点（PSA）的地理分布自动决定，而不是强制全网统一一种方式——这就是SSC（会话与业务连续性）思想在组通信上的延伸：成员移动、PSA重选后，SMF可动态切换转发方式，组通信不中断。
值得单独强调的是，UE建立到VN组DNN/S-NSSAI的PDU会话时，SMF的决策逻辑（TS 23.501 5.29.3 + 通用PDU会话建立 TS 23.502 4.3.2.2.1）：
简化的成员加入与互通时序如下：
sequenceDiagram
participant UE as UE-A（新成员）
participant AMF as AMF
participant SMF as SMF
participant UDM as UDM
participant PSA as PSA UPF（组锚点）
UE->>AMF: PDU Session Establishment Req<br/>(VN-DNN, VN S-NSSAI)
AMF->>SMF: Nsmf_PDUSession_CreateSMContext
SMF->>UDM: Nudm_SDM_Get/Subscribe<br/>(5G VN组成员关系/组数据)
UDM-->>SMF: 成员确认 + Group Data
Note over SMF: 校验成员身份，选择PSA，<br/>决定转发方式(本地交换/N19/N6)
SMF->>PSA: N4 Session Establishment<br/>(关联5G VN Group ID, 配置转发策略)
Note over PSA: 若需N19:挂接共享隧道;<br/>若本地交换:配置UPF内部接口
PSA-->>SMF: N4会话建立确认
SMF-->>AMF: Nsmf响应(N2 SM info)
AMF-->>UE: PDU Session Establishment Accept
Note over UE,PSA: 成员上线，组内可互通
5G VN组通信天然包含一对多（groupcast/broadcast）需求——例如AGV广播同步帧、PLC向多执行器下发控制组播。规范提供了两条技术路径：
设计意图：小规模、低时延的工业组播优先用N19本地复制（贴近边缘）；面向大量终端的媒体/广播类业务则走5MBS复用空口组播。两者通过5G VN组的DNN/S-NSSAI统一编排，体现了"按场景选数据面"的灵活性。
| 协议层 | 抓包特征 | 说明 |
|---|---|---|
| NAS（UE↔AMF） | DL NAS TRANSPORT 携带 UE policy container，内含URSP |
组策略下发标志 |
| Npcf（SMF↔PCF） | SM Policy含5G VN Group相关参数、Internal-Group-ID |
SMF获知组上下文 |
| Nudm（SMF↔UDM） | 5G VN Group Configuration订阅/查询 |
成员身份与组数据 |
| N4（SMF↔UPF） | N4会话带5G VN Group关联、N19隧道ID | 转发方式配置 |
| 用户面GTP-U | 两个UPF IP之间的GTP-U隧道（即N19） | 跨PSA组通信 |
| N6 | 组内流量进出DN | N6-based方式 |
Application Descriptor不匹配→检查PCF是否在Nudr_DM_Query成功取到组数据、DL NAS TRANSPORT是否下发、UE是否安装了URSP。5G VN Group Configuration与Internal-Group-ID-list。| 机制 | 与5G VN组通信的关系 |
|---|---|
| 网络切片（S-NSSAI） | 每个5G VN组绑定切片，是组的"资源面" |
| MEC/UL CL本地分流 | 本地交换是UL CL在"组"维度的极致形式，数据更彻底地留在边缘 |
| SSC模式 | PSA重选（SSC mode 3）会动态改变转发方式，组通信需配合保持连续性 |
| 5MBS（TS 23.247） | 为组通信提供大规模空口组播能力 |
| 二次认证（DN-AAA） | 组数据可携带二次认证信息，由DN-AAA为成员分配IP |
Q1：5G VN组通信和普通PDU会话到同一DNN有什么本质区别？ A：普通会话里，UE到UE通信一般要绕道DN；5G VN组通信通过UPF内部接口（本地交换）或N19共享隧道，在5GC用户面内部完成组内转发，不经DN、时延更低，并原生支持以太网二层互通和组播。
Q2：N19和N9都是UPF之间的隧道，区别在哪？ A：N9是通用PDU会话用户面隧道（跨UPF转发单个会话流量，面向"会话"）；N19是专属于一个5G VN组的共享隧道，连接该组所有PSA UPF，用于组内多播分发，面向"组"。同一对UPF上可能同时存在N9（普通业务）和N19（组通信）。
Q3：本地交换、N19、N6是"三选一"还是可以共存？ A：对组内某对成员的某次通信，由SMF根据其PSA分布选定一种；但同一个组整体上可能同时存在多种方式（同锚点的成员走本地交换，跨锚点的走N19，需要对接DN组播的走N6），SMF统一编排。
Q4：以太网PDU类型为什么对5G LAN特别重要？ A：大量工业协议（PROFINET、EtherCAT、OPC-UA二层模式、PTP）依赖以太网帧和组播。以太网PDU类型让UPF具备MAC学习和二层转发能力，使5G VN组真正"像一台交换机"，这是IPv4/IPv6类型做不到的。
Q5：组播为什么有时用N19、有时用5MBS？ A：小规模、低时延、成员集中的工业组播，N19本地复制最简、最贴近边缘；面向海量终端、要省空口频谱的广播/组播，则用5MBS的TMGI+NG-RAN空口组播（PTM）。两者按场景由SMF/AF选择。
本文由「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 等场景全覆盖。