<!-- title: 5G-Advanced R19协议栈深度重构解析 -->
<!-- domain: protocols -->

# 5G-Advanced Release 19 协议栈深度重构：NAS/PFCP/SBI/RRC信令全景解析

3GPP Release 19于2025年12月完成Stage 3冻结，作为5G-Advanced的第二个标准版本，协议栈各层经历了自Rel-15以来最为深刻的重构。与Rel-18侧重引入新特性框架不同，Rel-19在NAS、PFCP、SBI、RRC等核心协议上进行了大量增量增强——Conditional L1/L2 Triggered Mobility（CLTM）重新定义了移动性信令交互范式，Ambient IoT催生了极简NAS流程，SBI接口引入了新的Callback机制与HTTP/3预备性优化。本文将从协议信令视角，逐层拆解Rel-19的关键变化。

---

## 一、Conditional L1/L2 Triggered Mobility（CLTM）：移动性信令的范式变革

### 1.1 从LTM到CLTM的演进

Rel-18首次引入了L1/L2 Triggered Mobility（LTM），允许UE在MAC层通过L1信令快速切换波束或小区，无需传统RRC Handover流程，将切换中断时间从数十毫秒降至接近零。但Rel-18 LTM存在一个关键限制：UE在收到LTM命令后必须立即执行切换，无法进行条件评估。

Rel-19在此基础上引入了**Conditional LTM（CLTM）**，其核心思想与Rel-16引入的Conditional Handover（CHO）一脉相承——网络预先配置候选目标小区及执行条件，UE在满足条件时自主触发切换，但切换本身仍通过L1/L2信令完成。


![图表1](images/telecom-3gpp-r3-2314-mermaid-0.png)

> *图表 1*


### 1.2 RRC信令变化（TS 38.331 V19.x）

CLTM的引入对RRC协议产生了深远影响。TS 38.331在Rel-19中新增和修改了以下关键信息元素：

**新增RRC IE：**

| IE名称 | 所属消息 | 功能描述 |
|---------|---------|---------|
| `CLTM-Config` | RRCReconfiguration | CLTM主配置容器，包含候选小区列表和触发条件 |
| `CLTM-CandidateCellInfo` | CLTM-Config | 单个候选小区的配置，包含PCI、SSB索引、波束信息 |
| `CLTM-ExecutionCondition` | CLTM-Config | 触发条件，基于RSRP/RSRQ/SINR阈值的布尔表达式 |
| `CLTM-ResourceConfig` | CLTM-Config | LTM切换所需的随机接入资源配置 |
| `CLTM-RACH-ConfigDedicated` | CLTM-ResourceConfig | 候选小区的专用RACH配置 |

**修改的RRC消息：**

`RRCReconfiguration`消息中新增了`cltm-Config`字段（条件可选），位于`measConfig`或`secondaryCellGroupConfig`的同级位置。当网络需要配置CLTM时，通过该字段下发完整配置。

`RRCReconfigurationComplete`消息新增了`cltm-Result`字段，UE通过该字段向网络汇报CLTM执行结果。

**关键信令流程：**


![图表2](images/telecom-3gpp-r3-2314-mermaid-1.png)

> *图表 2*


### 1.3 NAS层面的配合变化（TS 24.501 V19.x）

虽然CLTM主要在L1/L2和RRC层操作，但NAS协议也需要配合调整：

**注册流程增强：** TS 24.501 V19在`REGISTRATION REQUEST`消息中新增了`CLTM capability`指示（作为5GMM capability的扩展比特位），UE在初始注册和移动性注册更新时需上报CLTM支持能力。AMF据此决定是否在后续切换中允许使用CLTM。

**移动性限制信息扩展：** 在`REGISTRATION ACCEPT`中，`Mobility restriction list`IE扩展了`serving PLMN CLTM policy`字段，用于控制CLTM在特定PLMN下的启用策略。

**服务请求流程适配：** 当UE处于CM-IDLE状态被寻呼后发起Service Request，若AMF判断UE处于CLTM候选区域，可在`CONFIGURATION UPDATE COMMAND`中预配置CLTM参数，避免UE进入CM-CONNECTED后再进行RRC重配置的额外时延。

---

## 二、Ambient IoT协议极简设计：NAS/RRC的减法哲学

### 2.1 Ambient IoT的协议挑战

Rel-19引入的Ambient IoT（A-IoT）代表了一类极端低功耗设备——无电池或仅靠环境能量收集供电，计算和存储资源极其有限。传统的5G NAS/RRC协议栈对这些设备来说过于复杂，3GPP不得不进行协议"减法"——设计精简的信令流程。

TS 24.501 V19中为A-IoT设备定义了**简化5GS移动性管理（Simplified 5GMM）**子集：

| 传统NAS流程 | A-IoT简化流程 | 关键差异 |
|-------------|-------------|---------|
| Registration | Simplified Registration | 不支持移动性注册更新，仅支持初始注册 |
| Deregistration | 不支持 | A-IoT设备无需显式去注册 |
| Service Request | 不支持 | A-IoT设备始终通过小数据传输发送 |
| Identity Request/Response | 简化 | 使用缩短的UE标识 |
| Security Mode Command | 简化或跳过 | 根据部署场景可选择性执行 |

### 2.2 A-IoT NAS消息精简设计

A-IoT设备的NAS消息定义在TS 24.501 V19的新增章节中，其核心设计原则是**最小化空口信令开销**：

**简化的REGISTRATION REQUEST消息结构：**

```
Simplified Registration Request (A-IoT)
├── Protocol Discriminator (4 bits, 固定值)
├── Security Header Type (4 bits)
├── Message Type (简化编码，1 byte)
├── Simplified UE Identity (缩短的5G-S-TMSI或A-IoT ID)
├── A-IoT Capability (1 byte, bitmap)
└── Selected PLMN (3 bytes)
```

对比传统`REGISTRATION REQUEST`消息通常需要20-50 byte，A-IoT简化版本控制在**10 byte以内**。

**关键设计考量：**

1. **无需NAS Security Context**：A-IoT设备计算能力不足以完成完整的安全上下文建立，Rel-19允许在特定部署场景下（如受控工业环境）跳过NAS安全模式流程
2. **固定TAI列表**：A-IoT设备不支持TAU流程，AMF在Registration Accept中不下发TAI List
3. **无PDU Session建立**：A-IoT数据传输通过CP data（NAS消息携带用户数据）完成，不建立完整PDU Session

### 2.3 RRC层适配

TS 38.331 V19为A-IoT设备定义了**最小化RRC配置**：

- 不支持RRC Connected态的完整过程（如Measurement Report、Handover）
- 仅使用RRC Idle/Inactive态的小数据传输（SDT）或直接在RRC Idle下通过随机接入过程传输数据
- SIB1中新增`aiot-AccessCategory`字段，用于A-IoT设备的接入控制

---

## 三、PFCP协议增强（TS 29.244 V19.x）：面向NTN与边缘计算的用户面控制

### 3.1 Rel-19 PFCP新增关键IE

TS 29.244在Rel-19中新增了多个Information Element以支持新兴业务场景：

| 新增IE | IE Type ID | 功能描述 | 应用场景 |
|--------|-----------|---------|---------|
| NTN Delay Budget | 新分配 | 携带NTN链路传播时延预算信息 | 卫星通信场景下QoS计时器适配 |
| Edge Computing Indication | 新分配 | 指示会话需要边缘计算处理 | MEC本地业务分流 |
| A-IoT Data Packet Info | 新分配 | A-IoT数据包元信息（设备类型、能量状态） | A-IoT小数据传输 |
| Enhanced QoS Monitoring Request | 新分配 | 请求UPF进行增强型QoS监控（时延、抖动、丢包） | URLLC确定性通信 |
| Multicast MBS Session Info | 新分配 | 多播/广播会话关联信息 | 5G MBS增强 |
| Redundant Transmission Mode | 新分配 | 冗余传输模式指示（PRB级别或PDU级别） | 高可靠性场景 |

### 3.2 NTN场景下的PFCP适配

NTN（非地面网络）是Rel-19的重点增强方向之一。卫星链路的传播时延（GEO卫星约540ms RTT，LEO卫星约20-40ms RTT）对PFCP会话管理提出了全新挑战。

**关键问题：** 传统PFCP Session Establishment/Modification采用请求-响应模式，在NTN场景下，SMF到UPF的PFCP信令往返时延加上卫星传播时延，可能导致PDU Session建立时延过大。

**Rel-19解决方案：**


![图表3](images/telecom-3gpp-r3-2314-mermaid-2.png)

> *图表 3*


Rel-19允许UPF在NTN场景下采用**预激活（Pre-activation）模式**：SMF在PFCP Session Establishment Request中携带`NTN Pre-activation Indication`标志，UPF收到后立即按照请求参数建立转发规则，无需等待响应阶段再激活。这种方式将用户面数据通路的建立时延从两倍地面回程降低到单程。

**NTN Delay Budget IE详解：**

该IE由SMF在PFCP Session Modification Request中下发给UPF，结构如下：

```
NTN Delay Budget IE:
├── IE Type (2 octets)
├── IE Length (2 octets)
├── UL Delay Budget (4 octets, 单位: 0.1ms)
├── DL Delay Budget (4 octets, 单位: 0.1ms)
├── Delay Variation Tolerance (2 octets, 单位: 0.1ms)
└── NTN Link Type (1 octet): 
    ├── 0: GEO
    ├── 1: MEO
    ├── 2: LEO
    └── 3: HAPS
```

UPF利用该IE调整其内部QoS监控计时器、GTP-U序列号重排序窗口等参数，以适应NTN链路的大时延和时延抖动特性。

### 3.3 Enhanced QoS Monitoring

Rel-19增强了UPF的QoS监控能力。新增的`Enhanced QoS Monitoring Request`IE允许SMF请求UPF执行以下监控任务：

| 监控类型 | 描述 | 上报触发条件 |
|---------|------|-------------|
| End-to-end Delay | 端到端数据包时延测量 | 超过阈值或周期性 |
| Jitter | 数据包时延抖动 | 超过阈值 |
| Packet Loss Rate | 丢包率统计 | 周期性 |
| Out-of-Order Rate | 乱序包率 | 超过阈值 |

SMF通过`PFCP Session Report Request`向UPF下发监控配置，UPF通过`PFCP Session Report Response`上报监控结果。这一增强使得5GC可以精确感知用户面传输质量，为URLLC业务提供更精细的SLA保障。

---

## 四、SBI接口演进（TS 29.500/29.501 V19.x）：从HTTP/2到智能路由

### 4.1 Callback机制的增强

TS 29.500 V19对SBI Callback机制进行了重要增强。在Rel-18及之前，SBI Callback主要用于NF（如SMF向AMF）的通知回调，其路由依赖于`3gpp-Sbi-Callback`header中的固定URI。

Rel-19引入了**Callback路由策略（Callback Routing Policy）**概念：

```
新增HTTP Header:
3gpp-Sbi-Callback-Policy: 
  {"policy-type": "geo-proximity", 
   "scope": "plmn-local",
   "fallback": "default-nrf-discovery"}
```

该Header允许NF在发送Callback请求时指定路由策略，SCP（Service Communication Proxy）据此进行智能路由决策。支持的路由策略类型包括：

| 策略类型 | 说明 |
|---------|------|
| `geo-proximity` | 优先路由到地理位置最近的目标NF实例 |
| `load-balancing` | 基于目标NF实例的负载进行均衡 |
| `affinity` | 保持与之前请求相同的目标NF实例亲和性 |
| `priority-based` | 按预配置的优先级列表选择 |
| `default-nrf-discovery` | 传统NRF发现（默认） |

### 4.2 NF Service Discovery增强

TS 29.510（NRF）在Rel-19中增强了NF Profile的数据模型，新增了以下关键字段：

| NF Profile字段 | 类型 | 说明 |
|---------------|------|------|
| `ntnCapability` | array | 支持的NTN类型（GEO/MEO/LEO/HAPS） |
| `aiotSupport` | boolean | 是否支持A-IoT设备管理 |
| `edgeZoneId` | string | 所在边缘计算区域标识 |
| `sbiVersions` | array | 支持的SBI API版本列表 |
| `loadMetricHistory` | array | 负载度量历史数据（用于预测性负载均衡） |
| `serviceExperienceInfo` | object | 服务体验统计信息 |

NRF的`NFDiscovery`服务也相应扩展了查询参数：

```
GET /nnrf-disc/v1/nf-instances?
    service-names=Nsmf_PDUSession&
    target-plmn-list=460,00&
    edge-zone-id=zone-bj-01&          ← 新增
    ntn-capability=LEO&               ← 新增
    preferred-sbi-version=v2          ← 新增
```

### 4.3 HTTP/3预备性优化

虽然Rel-19的SBI仍基于HTTP/2，但规范已经为HTTP/3（QUIC）迁移做了预备性设计。TS 29.500 V19新增了**SBI Transport Capability Negotiation**机制：

NF在注册到NRF时，可在NF Profile中声明支持的传输协议：

```json
{
  "transportInfo": {
    "supportedVersions": [
      {"protocol": "HTTP/2", "port": 8443},
      {"protocol": "HTTP/3-QUIC", "port": 8444, "status": "experimental"}
    ]
  }
}
```

SCP在路由请求时，若源NF和目标NF都支持HTTP/3，可以协商使用QUIC传输。这一机制为Rel-20全面引入HTTP/3奠定了基础。

### 4.4 SBI安全增强

TS 29.500 V19在安全方面新增了以下要求：

1. **mTLS增强**：NF间通信支持双向TLS证书校验，证书中携带NF Type和NF Instance ID扩展字段
2. **OAuth 2.0 Token Scope细化**：新增细粒度的scope定义，如`Nsmf_PDUSession:Create:NtnOnly`表示仅用于NTN场景的PDU Session创建
3. **API Rate Limiting标准化**：通过HTTP Header `3gpp-Sbi-RateLimit`实现NF服务调用的限流控制

---

## 五、NTN NAS定时器适配（TS 24.501 V19.x）

### 5.1 扩展定时器值

Rel-19针对NTN场景大幅扩展了NAS定时器的取值范围。卫星链路的长传播时延使得传统NAS定时器（如T3512周期性TAU定时器默认54分钟）不再适用。

| 定时器 | Rel-18最大值 | Rel-19 NTB扩展值 | 说明 |
|--------|-------------|-----------------|------|
| T3512 (Periodic Registration) | 54h | **400h** | GEO卫星场景下UE移动性低，延长周期 |
| T3502 (Attach retry) | 4h | **24h** | 适应卫星覆盖间歇性 |
| T3540 (Service Request retry) | 12s | **600s** | 卫星RTT可达540ms |
| T3580 (PDU Session retry) | 12s | **600s** | 同上 |
| T3585 (Deregistration guard) | 12s | **600s** | 同上 |
| T3511 (Registration retry) | 16s | **600s** | 同上 |

### 5.2 NTN特定的NAS流程变化

**Registration Type扩展：** Rel-19在TS 24.501中为NTN场景新增了`Satellite initial registration`类型（Registration Type值=7），AMF据此区分地面接入和卫星接入的注册请求，采用不同的策略处理。

**Slicing Selection适配：** 在NTN场景下，卫星gNB可能同时覆盖多个追踪区域，不同TA可能属于不同网络切片。Rel-19允许AMF在`REGISTRATION ACCEPT`消息中为NTN接入的UE下发**扩展TAI List**（包含卫星覆盖下的所有TA），避免UE在卫星覆盖区域内频繁触发移动性注册更新。

**移动性限制增强：** `Forbidden TAI for tracking area`列表新增了**条件性禁止**语义——当UE通过NTN接入时某些TA被禁止，但通过地面网络接入时允许，反之亦然。这一机制通过在5GMM消息中新增`NTN-conditional TAI list`实现。

---

## 六、Personal IoT Network（PIN）的信令支持

### 6.1 PIN架构概述

Personal IoT Network是Rel-19引入的新概念，允许用户创建和管理个人IoT网络，通过PIN Element（PIN内的设备）和PIN Server实现本地通信和与5GS的互联。

PIN架构引入了以下新的网络功能和参考点：


![图表4](images/telecom-3gpp-r3-2314-mermaid-3.png)

> *图表 4*


### 6.2 PIN NAS信令流程

TS 24.501 V19为PIN引入了新的NAS信令流程：

**PIN Registration：** 当PIN Gateway（由UE承担）需要为PIN网络进行注册时，在`REGISTRATION REQUEST`消息中携带`PIN Network ID`。AMF根据该ID关联PIN Subscription，执行PIN特定的策略控制。

**PIN Session Management：** PIN设备的通信通过PIN Gateway建立的PDU Session承载。SMF在PFCP Session Establishment中向UPF下发`PIN Traffic Steering Policy`，指示UPF将PIN设备的数据流量路由到PIN Server。

**PINAF接口（TS 29.583）：** 这是Rel-19新增的SBI接口，定义在TS 29.583中，用于PIN Application Function与5GC的交互。关键API操作包括：

| API操作 | HTTP Method | URI路径 | 功能 |
|---------|------------|---------|------|
| `Npinaf_PinManagement_Create` | POST | `/npinaf/v1/pins` | 创建PIN |
| `Npinaf_PinManagement_Update` | PUT | `/npinaf/v1/pins/{pinId}` | 更新PIN配置 |
| `Npinaf_PinManagement_Delete` | DELETE | `/npinaf/v1/pins/{pinId}` | 删除PIN |
| `Npinaf_PinManagement_Get` | GET | `/npinaf/v1/pins/{pinId}` | 查询PIN信息 |
| `Npinaf_PinEvent_Notify` | POST (Callback) | （由订阅决定） | PIN事件通知 |

---

## 七、GTP-U增强（TS 29.281 V19.x）

### 7.1 新增GTP-U Extension Header

Rel-19在TS 29.281中为GTP-U协议新增了以下Extension Header类型：

| Extension Header Type | 说明 |
|----------------------|------|
| NTN Timestamp | 携带卫星转发时间戳，用于NTN链路的时延测量 |
| QoS Monitoring Report | 携带UPF生成的QoS监控报告数据 |
| A-IoT Metadata | 携带A-IoT设备的元信息（设备类型、能量级别） |
| Edge Computing Routing | 指示数据包在边缘计算节点的路由信息 |

**NTN Timestamp Extension Header详解：**

```
GTP-U Header + Extension:
├── GTP-U Base Header (8 octets)
│   ├── Version: 1
│   ├── Protocol Type: 1 (GTP)
│   ├── Extension Header Flag: 1
│   ├── Sequence Number Flag: 1
│   ├── N-PDU Number Flag: 0
│   ├── Message Type: 255 (G-PDU)
│   ├── Length: variable
│   └── TEID: assigned by UPF
├── Extension Header:
│   ├── Extension Header Type: 0xCx (NTN Timestamp, 新分配)
│   ├── Extension Header Length: 3 (12 octets)
│   ├── Satellite Timestamp (8 octets): NTP格式
│   ├── Forwarding Hop Count (1 octet)
│   └── Next Extension Header Type: 0x00
└── Payload (IP Packet)
```

UPF在发送端打上卫星时间戳，接收端UPF据此计算实际端到端时延，将结果上报给SMF。

---

## 八、协议版本对比总览

### Rel-18 vs Rel-19 关键协议变化对照表

| 协议层 | 规范编号 | Rel-18关键特性 | Rel-19新增/增强 |
|--------|---------|--------------|----------------|
| NAS-MM | TS 24.501 | 基本LTM支持、NTN初步 | CLTM能力上报、A-IoT简化注册、PIN注册、扩展定时器 |
| NAS-SM | TS 24.501 | ATSSS、PDU Session增强 | PIN Session、A-IoT CP数据传输、NTN QoS适配 |
| RRC | TS 38.331 | LTM配置、NTN基本RRC | CLTM配置、A-IoT最小RRC、XR DRX增强 |
| PFCP | TS 29.244 | MBS基本支持、QoS监控 | NTN Delay Budget、Enhanced QoS Monitoring、A-IoT IE |
| GTP-U | TS 29.281 | RAN容器增强 | NTN Timestamp、QoS Report、Edge Routing |
| SBI | TS 29.500 | SCP Model D、HTTP/2 | Callback Routing Policy、HTTP/3预备、mTLS增强 |
| NRF | TS 29.510 | 基本NF发现 | NTN/A-IoT/Edge查询参数、负载历史 |
| PINAF | TS 29.583 | 不存在 | 新增PIN管理接口 |

---

## 九、部署建议与迁移考量

### 9.1 现网升级路径

**AMF升级：** 需要支持CLTM能力存储和策略下发、A-IoT简化NAS解析、PIN Registration处理、NTN扩展定时器。建议优先级为CLTM > NTN Timer > A-IoT > PIN。

**SMF/UPF升级：** PFCP新IE的编解码是最小改动，但UPF的NTN Pre-activation模式和Enhanced QoS Monitoring需要内部架构调整。建议分阶段实施：Phase 1实现新IE透传，Phase 2实现监控逻辑。

**SCP/NRF升级：** SBI Callback Routing Policy需要SCP支持新的路由算法，NRF需要扩展NF Profile数据模型。建议与HTTP/3迁移统筹规划。

### 9.2 互联互通注意事项

Rel-19引入的大量新IE和流程均为**条件可选（Conditional Optional）**，这意味着：

- Rel-18 UE可以正常接入Rel-19网络，网络需正确处理不支持CLTM/A-IoT的UE
- Rel-19 UE接入Rel-18网络时，应能优雅降级（如CLTM回退到传统HO）
- PFCP新IE在Rel-18 SMF/UPF上应被安全忽略（Forward Compatibility设计）

---

## 常见问题

**Q: CLTM和CHO（Conditional Handover）有什么本质区别？**

A: CLTM在L1/L2层执行切换，不涉及RRC层重配置，切换中断时间接近零（亚毫秒级）；CHO在RRC层执行，需要RRC Reconfiguration流程，中断时间通常在10-50ms。CLTM更适合高速移动、密集部署场景下的小区间切换，而CHO更适合大规模覆盖切换。Rel-19允许两者共存，网络可根据场景选择。

**Q: Ambient IoT设备的NAS安全如何保障？**

A: Rel-19采用了分级安全策略。对于计算资源极度受限的设备（如无源backscatter设备），允许在受控部署环境下跳过完整NAS安全流程，依赖物理层安全或应用层加密。对于有一定计算能力的半无源设备，支持简化的安全模式流程，使用轻量级算法。网络通过AMF策略控制安全等级。

**Q: PFCP NTN Pre-activation模式是否会导致资源浪费？**

A: 确实存在UPF预分配资源后UE实际未使用的情况。Rel-19定义了Pre-activation超时机制——若在配置的时间内未检测到数据流量，UPF自动释放预分配资源并通过PFCP Session Report通知SMF。SMF也可主动下发PFCP Session Deactivation命令。

**Q: SBI Callback Routing Policy对现网SCP有什么影响？**

A: 现网SCP需要升级路由引擎以支持新的策略类型。`geo-proximity`策略需要NF上报地理位置信息，`load-balancing`策略需要实时采集NF负载数据。对于尚不支持新策略的SCP，应回退到默认的NRF发现模式。建议SCP升级时保持对无策略Header的请求的兼容处理。

**Q: PINAF接口是否意味着5GC需要新增NF？**

A: PIN Application Function（PINAF）可以是一个独立的NF，也可以作为NEF或AF的功能扩展。Rel-19规范允许两种部署模式。对于运营商自有PIN服务，建议将PINAF功能集成到现有NEF中以减少运维复杂度；对于第三方PIN服务，建议部署独立PINAF。

---

> 本文由「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)