5G LAN-type Service是3GPP Release 16引入的关键特性,其核心目标是让5G网络具备与传统局域网相同的二层通信能力——终端之间无需经过外部数据网络(DN),即可通过5G核心网用户面直接互通。这一能力对于工业4.0、智慧园区、车联网等场景至关重要。
传统5G PDU会话的设计假设是"终端→UPF→DN"的单臂模型,所有流量都通过N6接口走向外部网络。但5G LAN打破了这一假设:同一5G VN Group内的UE之间可以直接在UPF层面完成报文转发,无需绕行外部网络。这要求SMF和UPF协同完成一套全新的组级会话管理和转发规则注入机制。
3GPP为此定义了三种转发模式,其复杂度递增:
| 转发模式 | 适用条件 | 参考点 | 信令复杂度 |
|---|---|---|---|
| Local Switch | 同一UPF服务源和目的UE | UPF内部 | 低 |
| N19转发(同SMF) | 不同UPF服务,但同一SMF管辖 | N19(UPF间) | 中 |
| N19转发(跨SMF) | 不同UPF且不同SMF管辖 | N19 + N16(SMF间) | 高 |
下文将逐一拆解三种模式的完整信令流程和PFCP规则结构。
5G VN Group是一个逻辑概念,由AF(Application Function)或NEF创建和管理。其核心数据结构定义在TS 23.501 Section 5.32.2中:
classDiagram
class VNGroup {
+ExternalGroupId
+GroupId
+DNN
+S_NSSAI
+PduSessionType : Ethernet
+AppLayerGroupId
+Members[] : SUPI列表
+DefaultCommunication
}
class UDM {
+GroupIdentificationData
+SubscriberDataManagement
}
class AF {
+GroupCreation
+MemberAddition
+MemberRemoval
+GroupDeletion
}
class NEF {
+Authorization
+Mapping_External_to_Internal
}
AF --> NEF : Nnef_GroupManagement
NEF --> UDM : Nudm_GroupManagement
UDM --> VNGroup : 存储/检索
关键设计要点: - PDU Session Type必须为Ethernet(TS 23.501 Section 5.32.3),这是5G LAN与传统IP PDU会话的本质区别——UPF工作在二层桥接模式 - DNN + S-NSSAI唯一标识一个5G VN Group,SMF通过这对组合查找VN Group成员列表 - GroupId由UDM内部分配,ExternalGroupId由AF使用,NEF负责两者映射
sequenceDiagram
participant AF
participant NEF
participant UDM
participant UDR
participant PCF
AF->>NEF: Nnef_GroupManagement_Create Request<br/>ExternalGroupId, DNN, S-NSSAI, Members[]
NEF->>NEF: 授权检查(TS 23.502 4.13.8.1)
NEF->>UDM: Nudm_GroupManagement_Create<br/>GroupId, DNN, S-NSSAI, Members[SUPI]
UDM->>UDR: Nudr_DataRepository_Create<br/>写入GroupData
UDR-->>UDM: 201 Created
UDM-->>NEF: GroupId, 成员确认
NEF-->>AF: ExternalGroupId, 创建确认
Note over PCF: 可选:AF通过NEF触发<br/>PCF策略更新
AF->>NEF: Nnef_PolicyAuthorization<br/>VN Group QoS策略
NEF->>PCF: Npcf_PolicyAuthorization
PCF->>PCF: 生成PCC规则含5G VN参数
设计意图:将VN Group管理与PDU会话管理解耦。Group的创建/修改独立于任何PDU会话,这意味着成员变更不会触发所有PDU会话重建——SMF会在下次PDU会话修改或服务请求时获取最新成员列表。
当UE发起一个Ethernet类型的PDU会话,其DNN + S-NSSAI对应某个5G VN Group时,SMF需要执行特殊的处理逻辑。
sequenceDiagram
participant UE
participant RAN as gNB
participant AMF
participant SMF
participant UDM
participant PCF
participant UPF1 as PSA UPF1
participant UPF2 as PSA UPF2
UE->>AMF: NAS PDU Session Establishment Request<br/>DNN=vn-group1, S-NSSAI, PDU Type=Ethernet
AMF->>SMF: Nsmf_PDUSession_CreateSMContext Request<br/>DNN, S-NSSAI, SUPI
SMF->>UDM: Nudm_SDM_Get<br/>获取SM Subscription Data
UDM-->>SMF: 5G VN Group信息<br/>GroupId, MemberList[], DefaultCommunication
SMF->>SMF: 检查UE是否为VN Group成员<br/>查询VN Group Membership
alt UE不是VN Group成员
SMF-->>AMF: 拒绝PDU会话建立
else UE是成员
SMF->>PCF: Npcf_SMPolicyControl_Create<br/>含VN Group ID
PCF-->>SMF: PCC Rules + VN Group策略
SMF->>SMF: UPF选择决策<br/>检查VN Group现有PDU会话分布
alt 存在同UPF的其他组成员
SMF->>UPF1: N4 Session Establishment<br/>PDR + FAR (Local Switch规则)
UPF1-->>SMF: N4 Session Response
else 需要N19连接
SMF->>UPF1: N4 Session Establishment<br/>PDR + FAR (N19转发规则)
SMF->>UPF2: Group-level N4 Session<br/>建立N19隧道端点
UPF2-->>SMF: N4 Session Response
end
SMF-->>AMF: Nsmf_PDUSession_CreateSMContext Response<br/>含N2 SM Info (AN Tunnel Info)
AMF->>RAN: N2 PDU Session Resource Setup
RAN->>UE: RRC Reconfiguration<br/>DRB配置
RAN-->>AMF: N2 PDU Session Resource Setup Response
AMF->>SMF: Nsmf_PDUSession_UpdateSMContext<br/>AN Tunnel Info
SMF->>UPF1: N4 Session Modification<br/>激活下行FAR
end
| IE名称 | 所在消息 | 关键参数 | 规范章节 |
|---|---|---|---|
| DNN | PDU Session Establishment Request | 标识5G VN Group对应的DNN | TS 24.501 9.11.2.1 |
| S-NSSAI | PDU Session Establishment Request | 与DNN组合标识VN Group | TS 24.501 9.11.2.8 |
| PDU Session Type | PDU Session Establishment Request | 必须为Ethernet (值=2) | TS 24.501 9.11.2.11 |
| 5G VN Group Membership | UDM Subscription Data | GroupId, 成员状态 | TS 23.501 5.32.2 |
| PFCP PDR | N4 Session Establishment | 匹配源/目的MAC地址、VLAN Tag | TS 29.244 5.23 |
| PFCP FAR | N4 Session Establishment | 转发动作:Local/N19/Multicast | TS 29.244 5.23.2 |
SMF选择UPF的关键决策逻辑(TS 23.501 Section 6.3.3.2): 1. 检查同一VN Group已有PDU会话的UPF分布 2. 如果已有成员在UPF1,优先选择UPF1作为PSA,以最大化Local Switch概率 3. 如果无已有会话,则按常规UPF选择逻辑(拓扑、负载等) 4. 如果选择新UPF,需要建立Group-level N4会话和N19隧道
这是最简单也最高效的模式。当源UE和目的UE的PDU会话都锚定在同一个PSA UPF时,UPF在本地完成二层帧转发。
graph LR
subgraph UPF["PSA UPF"]
PDR1["PDR1<br/>UE-A PDU Session"]
PDR2["PDR2<br/>UE-B PDU Session"]
FAR1["FAR1<br/>Forward to UE-B"]
FAR2["FAR2<br/>Forward to UE-A"]
BUF["Bridge Function<br/>二层学习/转发"]
end
UE1["UE-A<br/>MAC: AA:BB"] --> PDR1
PDR1 --> BUF
BUF --> FAR1
FAR1 --> UE2["UE-B<br/>MAC: CC:DD"]
UE2 --> PDR2
PDR2 --> BUF
BUF --> FAR2
FAR2 --> UE1
style UPF fill:#e1f5fe
style BUF fill:#fff3e0
PFCP规则结构(基于TS 29.244 Section 5.23.2):
Create PDR(UE-A上行):
PDR ID: 1
Precedence: 100
PDI:
Source Interface: ACCESS (UL)
F-TEID: UE-A的N3 F-TEID
Ethernet Filter:
Source MAC: UE-A MAC
Outer Header Removal: Yes (GTP-U)
FAR ID: 1 → 关联FAR1
Create FAR(转发到UE-B):
FAR ID: 1
Apply Action: FORW
Forwarding Parameters:
Destination Interface: ACCESS (DL)
Network Instance: [ VN Group DNN ]
Outer Header Creation: GTP-U with UE-B的N3 F-TEID
5G VN Group Info:
Local Switching: true
UPF二层学习机制:UPF维护一张MAC地址转发表,从上行数据帧的Source MAC学习UE的位置(关联到具体PDR/N3 Tunnel)。当收到目的MAC为已知UE的数据帧时,直接查表转发到对应的下行N3 Tunnel。这完全模拟了传统交换机的行为。
当同一SMF管辖的VN Group成员分布在两个PSA UPF时,SMF需要在两个UPF之间建立N19隧道。
sequenceDiagram
participant SMF
participant UPF1 as PSA UPF1
participant UPF2 as PSA UPF2
Note over SMF: 检测到VN Group成员<br/>分布在两个UPF
SMF->>UPF1: PFCP Session Establishment Request<br/>Group-level N4会话<br/>Create PDR + FAR (N19)
Note right of UPF1: FAR配置:<br/>Destination=N19<br/>Tunnel Endpoint=UPF2 N19 TEID
UPF1-->>SMF: PFCP Session Establishment Response<br/>N19 F-TEID
SMF->>UPF2: PFCP Session Establishment Request<br/>Group-level N4会话<br/>Create PDR + FAR (N19)
Note right of UPF2: FAR配置:<br/>Destination=N19<br/>Tunnel Endpoint=UPF1 N19 TEID
UPF2-->>SMF: PFCP Session Establishment Response<br/>N19 F-TEID
SMF->>UPF1: PFCP Session Modification<br/>更新FAR中UPF2的N19 TEID
SMF->>UPF2: PFCP Session Modification<br/>更新FAR中UPF1的N19 TEID
Note over UPF1,UPF2: N19隧道建立完成<br/>双向转发就绪
Group-level N4会话是关键概念(TS 23.502 Section 4.13.8.2.2): - 这不是任何单个PDU会话的N4会话,而是专门为VN Group创建的 - 用于在UPF上建立N19隧道端点和组级转发规则 - 当VN Group成员变更时,SMF修改Group-level N4会话即可影响所有组成员
N19隧道封装:N19使用GTP-U隧道,与N9接口相同的数据面封装格式。区别在于N19承载的是VN Group内部通信流量,隧道端点由SMF通过Group-level N4会话配置。
当VN Group成员由不同SMF服务时,需要SMF间通过N16接口协调N19隧道建立。
sequenceDiagram
participant SMF1
participant SMF2
participant UPF1 as PSA UPF1<br/>(SMF1管辖)
participant UPF2 as PSA UPF2<br/>(SMF2管辖)
Note over SMF1: 新UE建立PDU会话<br/>发现VN Group成员在SMF2
SMF1->>SMF2: Nsmf_PDUSession_N19Info<br/>Request: 请求N19隧道建立<br/>GroupId, UPF1 N19能力
SMF2->>SMF2: 验证VN Group成员关系<br/>查询Group-level N4会话状态
SMF2->>UPF2: PFCP Session Modification<br/>Group-level N4会话<br/>添加到UPF1的N19 FAR
UPF2-->>SMF2: N19 F-TEID (UPF2侧)
SMF2-->>SMF1: Nsmf_PDUSession_N19Info<br/>Response: UPF2 N19 TEID
SMF1->>UPF1: PFCP Session Establishment/Modification<br/>Group-level N4会话<br/>配置到UPF2的N19 FAR
Note right of UPF1: FAR: Forward to N19<br/>Remote TEID = UPF2 N19 TEID
UPF1-->>SMF1: N19 F-TEID (UPF1侧)
SMF1->>SMF2: Nsmf_PDUSession_N19Info<br/>Notification: UPF1 N19 TEID
SMF2->>UPF2: PFCP Session Modification<br/>更新FAR中UPF1 N19 TEID
Note over UPF1,UPF2: N19隧道双向就绪
N16参考点上的N19信息交换(TS 23.502 Section 4.13.8.2.3): - SMF1向SMF2提供UPF1的N19 F-TEID和传输层地址 - SMF2将此信息注入UPF2的FAR,实现双向隧道 - 当组成员PDU会话释放时,SMF需要判断是否还需要维护N19隧道——如果该UPF下已无其他组成员,则触发N19隧道释放
| PFCP IE | Local Switch | N19(同SMF) | N19(跨SMF) |
|---|---|---|---|
| PDR Source Interface | ACCESS | ACCESS | ACCESS |
| FAR Apply Action | FORW | FORW | FORW |
| FAR Destination Interface | ACCESS | ACCESS (N19) | ACCESS (N19) |
| FAR Outer Header | UE N3 TEID | N19 GTP-U TEID | N19 GTP-U TEID |
| N4会话类型 | PDU会话级 | Group-level | Group-level |
| MAR (Multicast) | 可选 | 可选 | 可选 |
| SMF间协调 | 不需要 | 不需要 | N16必需 |
| Ethernet Filter | MAC/VLAN | MAC/VLAN | MAC/VLAN |
| 转发时延 | <1ms (本地) | 2-5ms (跨UPF) | 2-5ms (跨UPF) |
5G VN Group不仅支持单播(UE→UE),还支持组播和广播。UPF通过MAR(Multicast Augmented Rule)实现报文复制。
graph TD
subgraph PFCP规则架构
PDR["PDR: 匹配组播帧<br/>Destination MAC = 组播地址"]
MAR["MAR: 组播复制规则"]
FAR1["FAR1: → UE-A<br/>Local Switch"]
FAR2["FAR2: → UE-B<br/>Local Switch"]
FAR3["FAR3: → UPF2<br/>N19隧道"]
end
PDR --> MAR
MAR --> FAR1
MAR --> FAR2
MAR --> FAR3
style MAR fill:#ffecb3
style PDR fill:#e1f5fe
MAR(TS 29.244 Section 7.5.2.7)关键字段:
| 字段 | 说明 |
|---|---|
| MAR ID | 唯一标识组播复制规则 |
| Steer Mode | 复制到所有关联FAR |
| Rule ID List | 关联的FAR ID列表 |
| Combine Param | 可选的组合参数 |
SMF通过一条MAR关联多个FAR,UPF收到匹配PDR的数据帧后,按照MAR的指示复制到所有关联FAR对应的路径上——无论是本地交换的UE还是N19隧道远端的UPF。
当UPF收到目的MAC地址不在转发表中的帧时: - Broadcast:目的MAC为广播地址(FF:FF:FF:FF:FF:FF)→ 复制到VN Group所有成员 - Unknown Unicast:目的MAC未知 → 复制到所有成员(泛洪),同时学习源MAC - Multicast:目的MAC为组播地址 → 仅复制到组播组成员
UPF通过BAR(Buffering Action Rule)处理需要泛洪的帧,确保不因MAC地址未学习而丢包。
成员动态加入/离开是5G LAN的关键运维场景。
sequenceDiagram
participant AF
participant NEF
participant UDM
participant SMF
participant UPF
AF->>NEF: Nnef_GroupManagement_Update<br/>添加新成员SUPI
NEF->>UDM: Nudm_GroupManagement_Update<br/>MemberList += 新SUPI
UDM-->>NEF: 更新确认
UDM->>SMF: Nudm_SDM_Notification<br/>VN Group成员变更通知
SMF->>SMF: 更新本地VN Group成员缓存
Note over SMF: 当新成员建立PDU会话时<br/>SMF已有最新成员列表
SMF->>UPF: PFCP Session Modification<br/>更新现有PDR/FAR的<br/>转发目标列表
设计精妙之处:SMF并非在收到UDM通知后立即修改所有UPF规则,而是在新成员PDU会话建立时才注入相关规则。这种"按需更新"策略避免了大规模组变更时的信令风暴。
成员离开触发两种清理: 1. PDU会话释放:常规PDU会话释放流程,SMF移除该UE的PDR/FAR 2. VN Group规则清理:SMF检查该UPF下是否还有其他组成员。若无,则释放Group-level N4会话和N19隧道
| 接口 | 识别特征 | 过滤条件 |
|---|---|---|
| N4 (PFCP) | Group-level Session的PDR包含Ethernet Filter IE;FAR中Destination Interface字段值为"N19"或"Access"且有5G VN Group Information | pfcp && pfcp.group_level_session |
| N3 (GTP-U) | 内层以太网帧(非IP),Source/Destination MAC为UE MAC地址 | gtp && eth.addr |
| N19 (GTP-U) | 目标端口仍为2152,但TEID为Group-level N4会话分配的N19 TEID | 需比对N4会话中的N19 F-TEID |
| N1 (NAS) | PDU Session Type = Ethernet (值=2) | nas-5gs.pdu_session_type == 2 |
| N16 | Nsmf_PDUSession_N19Info消息 | nsmf.n19_info |
故障1:UE间无法通信但PDU会话正常
排查思路: 1. 检查SMF是否正确识别VN Group Membership——查看UDM返回的SM Subscription Data中是否包含5G VN Group信息 2. 检查UPF上的PDR/FAR是否正确注入——通过PFCP Session Report验证 3. 检查UPF的MAC转发表是否正常学习——某些UPF实现需要显式配置二层学习开关
故障2:跨UPF通信失败
排查思路: 1. 检查N19隧道是否建立——查找PFCP Session Establishment中的N19 F-TEID 2. 检查N19传输层连通性——N19使用与N9相同的GTP-U格式,需确保UPF间IP可达 3. 若为跨SMF场景,检查N16上的N19Info交换是否完成
故障3:组播/广播不通
排查思路: 1. 检查SMF是否正确创建了MAR规则——MAR是R16新增的PFCP IE 2. 检查UPF是否支持MAR(部分旧版本UPF不支持5G LAN特性) 3. 检查FAR列表中是否包含所有组成员的转发路径
| 维度 | 5G LAN (VN Group) | 传统VPN | ProSe直连 | MBS多播广播 |
|---|---|---|---|---|
| 通信类型 | 二层(Ethernet) | 三层(IP) | 空口直连 | 一点对多点 |
| 转发锚点 | UPF | VPN网关 | 无(PC5) | UPF/BM-SC |
| QoS保障 | 5QI + GBR | Best Effort/DSCP | PC5 QoS | 专用QoS Flow |
| 组成员管理 | UDM集中管理 | 手动配置 | ProSe Function | AF/NEF |
| 时延 | 1-5ms | 10-50ms | <1ms | 取决于架构 |
| 覆盖范围 | 5G网络覆盖范围 | 跨网络 | 近距离 | 5G网络覆盖 |
| 规范 | TS 23.501/502 | TS 23.501 N6 | TS 23.303 | TS 23.247 |
stateDiagram-v2
[*] --> VNGroup_Created: AF/NEF创建VN Group
VNGroup_Created --> Active: 首个成员PDU会话建立
Active --> Active: 成员加入/离开
Active --> Active: N19隧道建立/释放
Active --> Active: PFCP规则更新
Active --> Idle: 最后一个成员PDU会话释放
Idle --> Active: 新成员PDU会话建立
Idle --> VNGroup_Deleted: AF/NEF删除VN Group
VNGroup_Deleted --> [*]
state Active {
[*] --> NoSession
NoSession --> SingleUPF: 1个UPF有成员
SingleUPF --> MultiUPF: 新UPF有成员加入
MultiUPF --> SingleUPF: 某UPF最后成员离开
SingleUPF --> NoSession: 最后成员释放
}
3GPP在Release 18和Release 19中持续增强5G LAN能力:
| 增强特性 | Release | TS章节 | 说明 |
|---|---|---|---|
| 多播/广播会话与VN Group融合 | Rel-17 | TS 23.247 | MBS与5G LAN联合提供高效组播 |
| VN Group计费 | Rel-17 | TS 28.822 | 基于Group ID的计费关联 |
| TSN集成(5G Bridge) | Rel-16/17 | TS 23.501 5.27 | TSN流映射到VN Group |
| Enhanced VN Group管理 | Rel-18 | TS 23.501 5.32 | 支持子组(Sub-group) |
| 多接入VN Group | Rel-19 | TS 23.501 5.32 | ATSSS与VN Group结合 |
Q1: 5G LAN的PDU会话类型为什么必须是Ethernet而不是IP?
A: Ethernet PDU会话工作在二层,UPF可以看到并学习MAC地址,实现基于MAC的桥接转发。如果使用IP类型,UPF需要执行三层路由,这与LAN的"透明桥接"设计理念矛盾。二层模式还保留了VLAN Tag等二层信息,满足工业网络对L2透传的需求。
Q2: N19和N9接口有什么区别?
A: 两者都使用GTP-U封装,端口均为2152。区别在于用途:N9用于不同UPF之间的PDU会话数据面隧道(标准PDU会话流量),而N19专门用于5G VN Group成员间的通信转发。N19隧道通过Group-level N4会话管理,而非单个PDU会话的N4会话。在传输层,某些厂商复用N9的传输资源承载N19流量。
Q3: Local Switch模式下UPF如何处理未知单播帧?
A: UPF维护一张MAC地址转发表。当收到目的MAC不在表中的帧时,UPF将其泛洪(复制到VN Group所有成员的下行路径)。同时从帧的Source MAC学习上行方向对应的PDR。这完全模拟了传统交换机的自学习行为。如果长时间未学习到某MAC,对应条目会老化删除。
Q4: 跨SMF场景下N19隧道如何维护?
A: 当SMF1检测到本SMF下有新成员加入VN Group,且VN Group在SMF2下也有成员时,SMF1通过N16接口向SMF2发起N19隧道协商。双方SMF各自在管辖的UPF上建立Group-level N4会话,交换N19 F-TEID。当某SMF下的最后一个组成员释放PDU会话时,该SMF通知对端SMF释放对应的N19隧道段。
Q5: 5G LAN与Network Slicing是什么关系?
A: 两者是互补关系。Network Slicing通过S-NSSAI提供网络级的资源隔离(不同切片有不同的SMF/UPF集合),而5G LAN通过VN Group提供应用级的通信域隔离(同一VN Group内UE可直接通信)。一个切片内可以承载多个VN Group,一个VN Group也可以跨切片(但DNN+S-NSSAI通常唯一标识一个VN Group)。
本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵爱卫生(微信ID: gprshome201101)维护,聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。 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 等场景全覆盖。
