<!-- title: UL CL注入与MEC边缘分流信令拆解 -->
<!-- domain: slicing-mec -->

# 5G UL CL上行分类器注入与MEC边缘分流信令深度拆解

## 一、背景与动机

5G网络面向垂直行业的典型场景之一是**MEC（Multi-access Edge Computing）边缘计算**。当终端靠近边缘数据中心时，需要将特定业务流量（如AR/VR渲染、工业控制、视频分析）从中心UPF（PDU Session Anchor, PSA）**本地分流**至边缘UPF（L-PSA），以降低端到端时延、减少回传带宽消耗。

3GPP在TS 23.502 Section 4.3.6中定义了**AF影响流量路由（AF Influence on Traffic Routing）**机制，SMF基于AF/PCF的策略指示，动态插入**UL CL（Uplink Classifier）**和**Branching Point（BP）**至用户面路径中，实现精细化流量分类与本地分流。本文将聚焦TS 23.502 Section 4.3.6.2中**UL CL插入**的完整信令流程，逐步拆解每条消息的关键IE。

---

## 二、核心概念与架构

### 2.1 UL CL vs Branching Point

| 特性 | UL CL（上行分类器） | BP（分支点） |
|------|---------------------|--------------|
| 定义来源 | TS 23.501 Section 5.8.2 | TS 23.501 Section 5.8.2 |
| 功能 | 基于过滤规则对上行流量分类并转发至不同PSA | 同时具备UL CL和下行流量合并功能 |
| 上行处理 | 根据Filter Rules匹配后分发到对应PSA | 同UL CL |
| 下行处理 | 无（下行由各PSA直接发至RAN） | 合并来自多个PSA的下行流量后统一发至RAN |
| 部署位置 | I-UPF（Intermediate UPF） | I-UPF |
| 典型场景 | 仅需上行分流（如数据采集上报） | 需双向本地业务交互（如AR/VR） |

### 2.2 UPF角色模型

在UL CL架构中，一次PDU会话可能涉及多个UPF，分别扮演不同角色：

| UPF角色 | 缩写 | 功能 |
|---------|------|------|
| PDU Session Anchor | PSA | 终结N6接口，连接DN（Data Network） |
| Intermediate UPF | I-UPF | 携带UL CL/BP功能，在RAN与PSA之间转发 |
| Local PSA | L-PSA | 部署在边缘的PSA，连接本地DN（MEC平台） |
| Central PSA | C-PSA | 部署在中心机房的PSA，连接中心DN/Internet |

### 2.3 DNAI与边缘计算拓扑

**DNAI（Data Network Access Identifier）**是3GPP定义的标识边缘计算接入点的关键参数（TS 23.501 Section 5.6.7）。每个DNAI标识一个UPF到特定DN的拓扑锚点。AF通过DNAI告知网络"用户应该从哪个边缘节点接入服务"。

---

## 三、完整信令流程：AF触发的UL CL插入

本流程基于TS 23.502 Section 4.3.6.2（UL CL/BP insertion triggered by AF request），展示从AF发起流量路由影响到最终用户面路径建立的完整过程。

### 3.1 信令时序图

```mermaid
sequenceDiagram
    participant AF as AF
    participant PCF as PCF
    participant SMF as SMF
    participant UDM as UDM
    participant I_UPF as I-UPF<br/>(UL CL)
    participant PSA1 as PSA1<br/>(Central)
    participant PSA2 as PSA2<br/>(Local/Edge)
    participant AMF as AMF
    participant RAN as gNB
    participant UE as UE

    Note over UE,AF: Phase 1: AF Traffic Influence Request
    AF->>PCF: Npcf_PolicyAuthorization<br/>Create (AF Session)
    Note right of AF: AF Session with:<br/>- App ID<br/>- DNAI(target edge)<br/>- Traffic Desc<br/>- UE Identity

    PCF->>PCF: 绑定到PDU Session<br/>查询SMF地址
    PCF->>SMF: Nsmf_EventExposure<br/>Notify (Traffic Influence)

    Note over UE,AF: Phase 2: SMF Decision & UPF Selection
    SMF->>SMF: 评估现有PDU Session<br/>决定插入UL CL
    SMF->>UDM: Nudm_SDM_Get<br/>(获取UE订阅数据)
    UDM-->>SMF: UE Subscription Data<br/>(含Allowed DNAI)

    SMF->>SMF: 选择I-UPF(UL CL)<br/>和PSA2(L-PSA)
    Note right of SMF: UPF选择依据:<br/>1. DNAI拓扑匹配<br/>2. UE位置<br/>3. S-NSSAI/DNN<br/>4. UPF负载/能力

    Note over UE,AF: Phase 3: N4 Session Establishment
    SMF->>PSA2: N4 Session Establishment<br/>(L-PSA)
    Note right of PSA2: N4 Rule:<br/>- FAR: DL→UL CL<br/>- PDR: UL/DL detection<br/>- QER: QoS enforcement
    PSA2-->>SMF: N4 Session Establishment Resp

    SMF->>I_UPF: N4 Session Modification<br/>(注入UL CL规则)
    Note right of I_UPF: 新增N4 Rule:<br/>- UL CL PDR<br/>  (match: app traffic)<br/>- FAR: match→PSA2<br/>- MAR: 备用路径
    I_UPF-->>SMF: N4 Session Modification Resp

    Note over UE,AF: Phase 4: N2/N1 Signaling (Optional)
    SMF->>AMF: Namf_Communication<br/>N1N2MessageTransfer
    AMF->>RAN: N2 PDU Session<br/>Resource Modify
    RAN->>UE: RRC Reconfiguration

    Note over UE,AF: Phase 5: Confirmation
    SMF->>PCF: Npcf_SMPolicyControl<br/>Update (确认DNAI变更)
    PCF->>AF: Npcf_PolicyAuthorization<br/>Notify (路由就绪)
```

### 3.2 Phase 1详解：AF流量影响请求

#### 3.2.1 AF → PCF：Npcf_PolicyAuthorization_Create

AF（如MEC平台管理器）通过SBI接口向PCF发起策略授权请求，核心参数定义在TS 29.514 Section 6.1.6：

| IE名称 | 类型 | 说明 |
|---------|------|------|
| `afAppId` | string | 应用标识符，标识需要边缘分流的业务 |
| `afChargingId` | string | AF侧计费标识 |
| `ueIpv4Addr/ueIpv6Prefix` | Address | 目标UE的IP地址 |
| `dnn` | DNN | 数据网络名称 |
| `snssai` | S-NSSAI | 网络切片标识 |
| `trafficFilters` | array | 流量过滤规则（五元组） |
| `tempValidities` | array | 有效时间窗口 |
| `validGeoZoneIds` | array | 有效地理区域 |
| `evSubsc` | object | 事件订阅（DNAI变更通知） |
| `tsnBridgeManCont` | object | TSN桥管理容器 |
| `ipDomain` | string | IP域名（多IP场景） |

**关键设计意图**：AF不直接指示UPF选择，而是通过描述业务需求（哪个应用的流量、目标DNAI、哪些UE），由PCF翻译为PCC规则后指导SMF决策。这种解耦设计使应用层无需感知网络拓扑。

#### 3.2.2 PCF策略决策

PCF收到AF请求后执行以下逻辑（TS 29.525 Section 4.2.2）：

1. **PDU Session绑定**：根据`ueIpv4Addr`/`dnn`/`snssai`匹配到UE当前活跃的PDU Session
2. **PCC规则生成**：将AF的流量描述转化为PCC Rule，其中包含：
   - `trafficControlPolicy`：`STEER`（允许分流）/ `PROHIBIT`（禁止分流）
   - `routeToLocs`：目标DNAI列表（优先级排序）
   - `sessionContinuousPolicy`：会话连续性要求（SSC mode）
3. **下发至SMF**：通过`Nsmf_EventExposure_Notify`或`Npcf_SMPolicyControl_Update`触发SMF

### 3.3 Phase 2详解：SMF决策与UPF选择

#### 3.3.1 SMF内部决策逻辑

SMF收到PCF的策略更新后（TS 23.502 Section 4.3.6.2 Step 4-7），执行：

```
SMF Decision Logic:
1. 检查当前PDU Session是否已有UL CL → 如果是，执行UL CL Modification
2. 检查SSC Mode → SSC Mode 3需要先建新PSA再删旧PSA
3. 查询UDM获取UE的Allowed DNAI列表
4. 根据UE当前位置（TAI/Cell ID）匹配DNAI
5. 选择I-UPF和L-PSA
```

#### 3.3.2 UPF选择要素

SMF选择UPF时综合考虑以下因素（TS 23.501 Section 6.3.3.2）：

| 选择因素 | 来源 | 说明 |
|---------|------|------|
| DNAI拓扑 | UDR/NRF | UPF是否服务于目标DNAI |
| S-NSSAI | Subscription | UPF是否支持该切片 |
| DNN | Subscription | UPF是否连接目标DN |
| UE位置 | AMF | UPF服务区域是否覆盖UE当前TA |
| UPF能力 | NRF | 是否支持UL CL功能 |
| 负载状态 | NRF/SMF | UPF当前负载和可用容量 |
| UE IP地址 | SMF | UPF的IP地址池是否匹配UE已分配IP |

### 3.4 Phase 3详解：N4会话建立/修改

这是整个流程中最核心的信令阶段，涉及多条N4消息的交互。

#### 3.4.1 SMF → PSA2（L-PSA）：N4 Session Establishment

SMF为新选择的边缘PSA2建立N4会话，下发关键规则：

**PDR（Packet Detection Rule）**：

| PDR字段 | 值 | 说明 |
|---------|-----|------|
| PDR ID | 101 | 规则标识 |
| Precedence | 100 | 优先级 |
| PDI: Source Interface | CORE | 下行方向 |
| PDI: UE IP Address | x.x.x.x | 目标UE |
| PDI: FQDN/Application ID | app.example.com | 匹配边缘应用 |
| FAR ID | 1 | 关联转发动作 |
| QER ID | 1 | 关联QoS |
| Outer Header Removal | GTP-U/UDP/IPv4 | 剥离GTP头 |
| FAR Action | FORW | 转发 |
| FAR: Destination Interface | ACCESS | 朝向RAN方向 |
| FAR: N3 Tunnel Info | {TEID, IP} | 发往UL CL的N3隧道 |

**MAR（Missing Forwarding Action Rule）** — NR R16新增：

MAR用于处理UL CL尚未收到完整下行数据时的备用路径。当L-PSA收到下行数据但I-UPF的UL CL尚未就绪时，MAR指示L-PSA如何处理：

| MAR字段 | 说明 |
|---------|------|
| MAR ID | 唯一标识 |
| First FAR | 主路径（→UL CL → RAN） |
| Second FAR | 备用路径（→C-PSA兜底转发或缓冲） |
| Status | Active/Standby |

#### 3.4.2 SMF → I-UPF：N4 Session Modification（注入UL CL规则）

SMF修改I-UPF的N4会话，新增UL CL相关规则：

**UL CL PDR**：

| PDR字段 | 值 | 说明 |
|---------|-----|------|
| PDR ID | 201 | UL CL规则标识 |
| Precedence | 50 | 高优先级匹配 |
| PDI: Source Interface | ACCESS | 上行方向 |
| PDI: UE IP Address | x.x.x.x | 匹配UE |
| PDI: SDF Filter | tcp dst port 8080<br/>and dst ip in {edge CIDR} | 匹配边缘应用流量 |
| FAR ID | 2 | 关联转发→PSA2 |
| FAR Action | FORW + CPYY | 转发+复制 |
| FAR: Destination | PSA2 N3 TEID/IP | 边缘PSA隧道 |

**默认PDR**（未被UL CL匹配的流量）：

| PDR字段 | 值 | 说明 |
|---------|-----|------|
| PDR ID | 202 | 默认规则 |
| Precedence | 255 | 最低优先级 |
| FAR Action | FORW | 继续转发至C-PSA |

### 3.5 Phase 4详解：N2/N1信令（条件触发）

在以下场景中，SMF需要通过N2/N1信令更新无线侧资源：

| 场景 | 是否需要N2信令 | 原因 |
|------|---------------|------|
| UL CL插入（同I-UPF） | 可能不需要 | 若N3隧道终点未变 |
| UL CL插入（新I-UPF） | 需要 | N3隧道终点变化，需更新RAN侧 |
| PSA Relocation | 需要 | 需要更新QoS Flow到DRB映射 |
| SSC Mode 3 | 需要 | 需要建立新的用户面路径 |

当需要N2信令时，SMF通过`Namf_Communication_N1N2MessageTransfer`发送：

**N2 SM Info**：

| IE | 说明 |
|----|------|
| PDU Session ID | 目标会话 |
| QoS Flow Add/Modify | 新增/修改的QoS Flow参数 |
| UL NG-U UP TNL Info | 新I-UPF的N3隧道地址 |
| PDU Session Type | IPv4/IPv6/IPv4v6 |

### 3.6 数据面转发路径

UL CL注入成功后，用户面形成双路径分流：

```mermaid
graph LR
    UE[UE] -->|N3 UL| RAN[gNB]
    RAN -->|N3| IUPF[I-UPF<br/>UL CL]

    IUPF -->|匹配边缘规则<br/>N9/CL Tunnel| PSA2[L-PSA<br/>Edge PSA]
    IUPF -->|默认规则<br/>N9 Tunnel| PSA1[C-PSA<br/>Central PSA]

    PSA2 -->|N6 Local| EDN[边缘DN<br/>MEC Platform]
    PSA1 -->|N6| CDN[中心DN<br/>Internet]

    EDN -->|下行响应| PSA2
    PSA2 -->|N9 DL| IUPF
    PSA1 -->|N9 DL| IUPF
    IUPF -->|N3 DL 合并| RAN
    RAN -->|N3 DL| UE

    style IUPF fill:#f9f,stroke:#333
    style PSA2 fill:#ff9,stroke:#333
```

---

## 四、DNAI变更与PSA重定位

### 4.1 DNAI变更场景

当UE移动导致最优边缘节点变化时，SMF需要执行**PSA Relocation**（TS 23.502 Section 4.3.6.3），将L-PSA从PSA2迁移到PSA3。此时DNAI发生变更。

### 4.2 会话连续性模式与DNAI变更策略

| SSC Mode | DNAI变更行为 | 数据面中断 | 适用场景 |
|----------|-------------|-----------|---------|
| SSC Mode 1 | 不变更PSA | 无中断 | 静态业务 |
| SSC Mode 2 | 先拆旧PSA再建新PSA | 有中断（秒级） | 可容忍短暂中断 |
| SSC Mode 3 | 先建新PSA，双锚共存，再拆旧 | 无中断（平滑） | 实时业务 |

### 4.3 SSC Mode 3下的PSA重定位状态机

```mermaid
stateDiagram-v2
    [*] --> SinglePSA: PDU Session建立
    SinglePSA --> ULCL_Inserted: AF触发/SMF决策<br/>插入UL CL
    ULCL_Inserted --> DualAnchor: DNAI变更触发<br/>新增PSA3(L-PSA2)
    DualAnchor --> DualAnchor_Reallocating: UE IP地址不变<br/>双锚点并存
    DualAnchor_Reallocating --> ULCL_Modified: 旧PSA2释放<br/>流量切换至PSA3
    ULCL_Modified --> ULCL_Inserted: 再次DNAI变更
    ULCL_Inserted --> SinglePSA: UL CL移除<br/>回归单锚点
    SinglePSA --> [*]
```

### 4.4 AF通知机制

当DNAI发生变更时，SMF必须通知AF（如果AF在初始请求中订阅了`evSubsc`事件）：

| 通知参数 | 说明 |
|---------|------|
| `event` | `AF_SESSION_TERMINATION` 或 `UP_PATH_CHANGE` |
| `dnaiChgType` | `EARLY` / `EARLY_LATE` / `LATE` |
| `sourceDnai` | 原DNAI |
| `targetDnai` | 目标DNAI |
| `ueIpv4Addr` | UE IP（可能因SSC Mode 2而变化） |
| `gpsi` | UE的GPSI标识 |

**通知时机**（TS 23.502 Section 4.3.6.3）：

| dnaiChgType | SMF通知AF的时刻 | 用途 |
|-------------|----------------|------|
| EARLY | 用户面路径变更**之前** | AF提前准备边缘应用迁移 |
| LATE | 用户面路径变更**之后** | AF事后感知 |
| EARLY_LATE | 变更前后各通知一次 | AF完整跟踪迁移过程 |

---

## 五、N4规则注入深度分析

### 5.1 UL CL PDR匹配逻辑

I-UPF上的UL CL匹配遵循严格的优先级规则（TS 29.244 Section 7.5.2.3）：

```
收到上行PDU:
  遍历所有PDR（按Precedence升序）
    PDR 201 (Precedence=50):
      匹配条件: UE_IP=x.x.x.x AND SDF=edge_app_filter
      → 匹配成功 → 应用FAR 2 → 转发至PSA2
    （不继续匹配低优先级PDR）

  若PDR 201不匹配:
    PDR 202 (Precedence=255):
      匹配条件: UE_IP=x.x.x.x （无SDF限制）
      → 匹配成功 → 应用FAR 3 → 转发至PSA1
```

### 5.2 关键N4 IE参数表

| N4 IE | 方向 | 说明 |
|-------|------|------|
| Create PDR | SMF→UPF | 创建包检测规则 |
| Create FAR | SMF→UPF | 创建转发动作规则 |
| Create QER | SMF→UPF | 创建QoS执行规则 |
| Create BAR | SMF→UPF | 创建缓冲动作规则（DL缓存） |
| Create MAR | SMF→UPF | 创建Missing备用路径（R16+） |
| Update PDR | SMF→UPF | 修改现有PDR（如更新SDF Filter） |
| Remove PDR | SMF→UPF | 删除PDR（释放UL CL规则） |
| Query URR | SMF→UPF | 查询使用量报告 |
| Session Report | UPF→SMF | 上报数据量/DL Data Notification |

### 5.3 UL CL注入前后N4会话对比

| 阶段 | I-UPF N4会话内容 | PSA数量 |
|------|------------------|---------|
| 初始建立 | 1组PDR/FAR（UL/DL→PSA1） | 1个（C-PSA） |
| UL CL注入后 | 2组PDR/FAR + UL CL规则 | 2个（C-PSA + L-PSA） |
| PSA重定位中 | 3组PDR/FAR（SSC Mode 3） | 3个（临时双锚） |
| UL CL移除 | 回归1组PDR/FAR | 1个 |

---

## 六、实战分析

### 6.1 抓包识别UL CL注入

**关键识别点**：在N4接口上，UL CL注入的特征是SMF向同一I-UPF发送**N4 Session Modification**而非Establishment，且新增的PDR中包含**SDF Filter**（而非全匹配）和多个FAR指向不同PSA。

```
# N4 Session Modification (UL CL注入)
PFCP Session Modification Request:
  SEID: 0x1234567890ABCDEF
  Create New PDR:
    PDR ID: 201
    Precedence: 50
    PDI:
      Source Interface: ACCESS (UL)
      UE IP Address: 10.1.2.3
      SDF Filter: permit out tcp from 10.1.2.3 to 172.16.0.0/12 8080
    FAR ID: 2
  Create New FAR:
    FAR ID: 2
    Apply Action: FORW
    Forwarding Parameters:
      Destination Interface: CORE
      Outer Header Creation:
        TEID: 0xABCDEF01
        IP: 192.168.100.5  ← PSA2(L-PSA)地址
```

### 6.2 常见故障点与排错

| 故障现象 | 可能原因 | 排错方法 |
|---------|---------|---------|
| UL CL插入后边缘业务不通 | N4 SDF Filter规则配置错误 | 检查PDR中的SDF Filter是否与业务五元组匹配 |
| 边缘业务通但中心业务中断 | 默认PDR被UL CL规则覆盖 | 检查Precedence值，确保UL CL规则优先级高于默认规则 |
| UL CL插入失败 | I-UPF不支持UL CL能力 | 查询NRF中UPF的`upfInfo.smfSUpFList`能力声明 |
| DNAI变更后AF未收到通知 | AF未订阅`evSubsc`事件 | 检查初始AF请求中的`evSubsc`字段 |
| 丢包/乱序 | N3/N9隧道未建立先下发规则 | 确认N4 Modification Response返回后才能激活规则 |
| SSC Mode 3重定位后IP变化 | SMF配置错误使用SSC Mode 2 | 检查SMF中SSC Mode选择逻辑和DNN配置 |
## 七、与LTE本地分流方案的对比

| 特性 | 5G UL CL | LTE LBO/SIPTO |
|------|---------|---------------|
| 规范 | TS 23.502 4.3.6 | TS 23.401 5.3.4 |
| 分流粒度 | 五元组+应用ID+FQDN | 仅APN粒度 |
| 动态性 | 会话建立后可动态插入/移除 | 仅在建立时选择 |
| 会话连续性 | SSC Mode 1/2/3三种 | 无（断开后重建） |
| 边缘计算集成 | DNAI+EASDF完整框架 | 无原生支持 |
| AF交互 | SBI接口实时影响路由 | 无（需静态配置） |
| 多锚点 | 支持单会话多PSA | 不支持 |

**设计演进意图**：5G UL CL相比LTE SIPTO实现了从"APN级粗粒度分流"到"流级精细分流"的质变。核心驱动是MEC场景需要按应用（而非按APN）动态调度流量，且UE移动时需要保持会话连续性。

---

## 常见问题

**Q: UL CL和BP的部署选择依据是什么？**

A: 核心区别在于**下行流量处理**。如果边缘业务仅需要上行数据（如IoT数据采集上报），选择UL CL即可，下行由各PSA直接经N3发往RAN。如果边缘业务需要双向交互（如AR/VR、云游戏），下行响应需要经过I-UPF合并后再统一发往RAN，此时需要BP。BP实现更复杂，但避免了RAN侧需要接收来自多个PSA的下行GTP隧道。

**Q: SSC Mode 3下的PSA重定位如何保证零丢包？**

A: SSC Mode 3的关键是"先建后拆"。SMF先建立新L-PSA的N4会话和N9隧道，此时I-UPF上存在两条转发路径（旧PSA和新PSA并存）。SMF更新UL CL的FAR，将匹配规则从旧PSA切换到新PSA。在切换瞬间，可能有少量在途数据包走旧路径，这些包通过旧PSA的缓冲机制或I-UPF的MAR备用规则兜底。确认新路径稳定后再删除旧PSA。

**Q: AF如何知道应该请求哪个DNAI？**

A: AF通常通过以下途径获取DNAI信息：(1) NEF暴露的网络能力API（如`Nnef_AnalyticsExposure`获取UE位置信息）；(2) MEC平台的APP信息（ETSI MEC API）；(3) 静态配置（运营商预配置应用与DNAI的映射关系）。在R17+中，EASDF（Edge Application Server Discovery Function）帮助UE通过DNS查询发现最近的边缘应用服务器，AF可根据DNS解析结果推断最优DNAI。

**Q: UL CL方案对时延有多大改善？**

A: 取决于拓扑。典型场景下，中心UPF到边缘UPF的RTT约10-30ms（取决于传输距离）。UL CL将边缘业务流量在本地PSA分流后，可节省这段回传时延，即单向节省5-15ms。对URLLC业务（目标1ms空口+5ms端到端），这个改善是决定性的。

**Q: 一个PDU Session能插入多少个UL CL？**

A: TS 23.501没有明确限制数量，但实际受限于I-UPF的规则容量和N4会话复杂度。典型实现中，单个PDU Session最多支持1个UL CL + 2-3个PSA（1个中心PSA + 1-2个边缘PSA）。每增加一个PSA都需要完整的N4规则集（PDR+FAR+QER），占用UPF处理资源。

---

## 参考来源

1. [3GPP TS 23.502 V18.10.0](https://www.etsi.org/deliver/etsi_ts/123500_123599/123502/18.10.00_60/ts_123502v181000p.pdf) — Section 4.3.6: UE Policy; Section 4.3.6.2: UL CL/BP Insertion
2. [3GPP TS 23.501 V18.8.0](https://www.etsi.org/deliver/etsi_ts/123500_123599/123501/18.08.00_60/ts_123501v180800p.pdf) — Section 5.8.2: UL CL and BP; Section 6.3.3.2: UPF Selection
3. [3GPP TS 29.244 V18.6.0](https://www.3gpp.org/DynaReport/29244.htm) — Section 7.5: PFCP Session Establishment/Modification; N4 Rule definitions
4. [3GPP TS 29.514 V18.5.0](https://www.3gpp.org/DynaReport/29514.htm) — Section 6.1: Npcf_PolicyAuthorization Service; AF Request parameters
5. [3GPP TS 23.548 V17.3.0](https://www.etsi.org/deliver/etsi_ts/123500_123599/123548/17.03.00_60/ts_123548v170300p.pdf) — Section 6.3: Edge Relocation procedures
6. [free5GC Traffic Influence Guide](https://free5gc.org/guide/8-traffic-influence/) — AF influence traffic routing实践参考
7. [3glteinfo: 5G RLC ARQ Procedures](https://www.3glteinfo.com/5g/protocols/rlc/arq-procedures/) — N4 Session管理参考

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

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