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

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

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

新增RRC IE：

修改的RRC消息：

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

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

关键信令流程：

图表 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 listIE扩展了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）子集：

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以支持新兴业务场景：

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

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 RequestIE允许SMF请求UPF执行以下监控任务：

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-Callbackheader中的固定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）据此进行智能路由决策。支持的路由策略类型包括：

4.2 NF Service Discovery增强

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

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中声明支持的传输协议：

{
  "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分钟）不再适用。

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

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操作包括：

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

7.1 新增GTP-U Extension Header

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

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 关键协议变化对照表

九、部署建议与迁移考量

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 等场景全覆盖。