<!-- title: 5G LAN三模式转发与VN组通信信令拆解 -->
<!-- domain: slicing-mec -->

# 5G LAN三模式转发与VN组通信信令拆解

## 一、5G LAN-type Service的定位与核心问题

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管理体系

### 2.1 VN Group数据模型

5G VN Group是一个逻辑概念，由AF（Application Function）或NEF创建和管理。其核心数据结构定义在TS 23.501 Section 5.32.2中：

```mermaid
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负责两者映射

### 2.2 VN Group创建信令流

```mermaid
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会话修改或服务请求时获取最新成员列表。

## 三、PDU会话建立与VN Group关联

当UE发起一个Ethernet类型的PDU会话，其DNN + S-NSSAI对应某个5G VN Group时，SMF需要执行特殊的处理逻辑。

### 3.1 VN Group感知的PDU会话建立流程

```mermaid
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
```

### 3.2 关键Information Element解析

| 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隧道

## 四、三种转发模式的PFCP规则深度拆解

### 4.1 模式一：Local Switch（同UPF本地交换）

这是最简单也最高效的模式。当源UE和目的UE的PDU会话都锚定在同一个PSA UPF时，UPF在本地完成二层帧转发。

```mermaid
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。这完全模拟了传统交换机的行为。

### 4.2 模式二：N19转发（同SMF，不同UPF）

当同一SMF管辖的VN Group成员分布在两个PSA UPF时，SMF需要在两个UPF之间建立N19隧道。

```mermaid
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会话配置。

### 4.3 模式三：N19转发（跨SMF，最复杂）

当VN Group成员由不同SMF服务时，需要SMF间通过N16接口协调N19隧道建立。

```mermaid
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隧道释放

### 4.4 三种模式PFCP规则对比

| 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）实现报文复制。

### 5.1 组播转发的PFCP规则结构

```mermaid
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。

### 5.2 广播与未知单播处理

当UPF收到目的MAC地址不在转发表中的帧时：
- **Broadcast**：目的MAC为广播地址（FF:FF:FF:FF:FF:FF）→ 复制到VN Group所有成员
- **Unknown Unicast**：目的MAC未知 → 复制到所有成员（泛洪），同时学习源MAC
- **Multicast**：目的MAC为组播地址 → 仅复制到组播组成员

UPF通过BAR（Buffering Action Rule）处理需要泛洪的帧，确保不因MAC地址未学习而丢包。

## 六、VN Group成员变更信令流

成员动态加入/离开是5G LAN的关键运维场景。

### 6.1 成员加入

```mermaid
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会话建立时才注入相关规则。这种"按需更新"策略避免了大规模组变更时的信令风暴。

### 6.2 成员离开

成员离开触发两种清理：
1. **PDU会话释放**：常规PDU会话释放流程，SMF移除该UE的PDR/FAR
2. **VN Group规则清理**：SMF检查该UPF下是否还有其他组成员。若无，则释放Group-level N4会话和N19隧道

## 七、抓包识别与故障排查

### 7.1 抓包特征

| 接口 | 识别特征 | 过滤条件 |
|------|---------|---------|
| **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` |

### 7.2 常见故障点

**故障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与相关技术的对比

| 维度 | 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 |

## 九、状态转换与生命周期管理

```mermaid
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: 最后成员释放
    }
```

## 十、Release 18/19增强

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）。

## 参考来源

1. [3GPP TS 23.501 V18.10.0](https://www.3gpp.org/DynaReport/23501.htm) — Section 5.32: 5G LAN-type Service架构定义
2. [3GPP TS 23.502 V18.10.0](https://www.3gpp.org/DynaReport/23502.htm) — Section 4.13.8: Support of 5G LAN-type Service信令流程
3. [3GPP TS 29.244 V18.7.0](https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3111) — Section 5.23: PFCP 5G VN Group Communication规则
4. [free5GC: 5G LAN-type service Introduction](https://free5gc.org/blog/20250122/20250122/) — 开源5GC实现中的5G LAN技术解析
5. [IEEE: Demonstration of LAN-type Communication for Industrial 5G Network](https://ieeexplore.ieee.org/abstract/document/10225780) — 5G LAN工业应用实证研究
6. [3GPP: 5G for Industry 4.0 - TSN vs LAN](https://www.3gpp.org/news-events/3gpp-news/tsn-v-lan) — 5G LAN与TSN在工业场景的对比

---
> 本文由「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 等场景全覆盖。

![51学通信知识星球海报-扫码加入](https://wiki.500nian.com/images/zhixingqiu_qrcode.png)