3GPP Release 19作为5G-Advanced的第二个版本，在协议层面的改动远超表面上的Feature List。Ambient IoT的引入催生了全新的NAS简化注册流程，NTN的深度集成要求PFCP/GTP-U适配卫星时延特征，NWDAF的AI/ML能力渗透到SBI的每一个服务接口。本文从TS 24.501（NAS）、TS 29.244（PFCP）、TS 29.500/29.501（SBI）、TS 29.281（GTP-U）、TS 38.331（RRC）五个核心协议规范出发，逐层解析Rel-19的信令协议变化。
Rel-19并非在单一协议层做文章，而是由多个新业务场景（Ambient IoT、NTN增强、AI/ML集成、增强确定性通信）驱动，从接入层RRC到应用层SBI形成全栈联动。
图表 1
| 协议规范 | TS编号 | Rel-18基线版本 | Rel-19最新版本 | 核心改动Work Item |
|---|---|---|---|---|
| NAS for 5GS | TS 24.501 | V18.x | V19.x | Ambient IoT、NTN增强、Multi-USIM |
| PFCP | TS 29.244 | V18.6.0 | V19.3.0 | NTN UPF适配、增强计费、QoS监控 |
| GTP-U | TS 29.281 | V18.x | V19.x | NTN时延、确定性通信 |
| SBI技术实现 | TS 29.500 | V18.x | V19.x | NWDAF新服务、AIoTF接口 |
| SBI原则指南 | TS 29.501 | V18.x | V19.x | API设计增强、安全改进 |
| NR RRC | TS 38.331 | V18.x | V19.0.0 | NTN信令、A-IoT配置、NR-DC |
Ambient IoT（环境物联网）是Rel-19最具标志性的新特性之一。这类设备通过能量收集供电，计算能力和存储极度受限，无法执行标准5G NAS完整流程。3GPP为此在TS 24.501中引入了全新的受限注册（Restricted Registration）机制。
传统5G NAS注册需要5步以上消息交互（Registration Request → Authentication → Security Mode → Registration Accept），对Ambient IoT设备而言过于复杂。Rel-19引入的简化流程将注册压缩为单步或两步完成。
图表 2
关键IE变化：
| IE名称 | 新增/修改 | 方向 | 说明 |
|---|---|---|---|
| Ambient IoT Indication | 新增 | UE→AMF | 标识设备为Ambient IoT类型 |
| Restricted Registration Type | 新增 | UE→AMF | 区分完全受限/部分受限注册 |
| Simplified Authentication Flag | 新增 | AMF内部 | 跳过EAP-AKA'认证的指示标志 |
| Device Class Indicator | 新增 | UE→AMF | 标识A-IoT设备能力等级（Class 1-3） |
Ambient IoT设备分为三个等级： - Class 1：无发射能力，仅通过反向散射通信，不支持NAS信令 - Class 2：有限发射能力，支持简化NAS注册，不支持完整安全流程 - Class 3：具备基本5G能力，支持简化安全模式
Rel-19将NTN从Rel-17/18的"附加特性"提升为基础架构能力，NAS层相应引入了新的移动性管理参数。
TS 24.501 Rel-19新增了以下关键内容：
卫星切换期间的Registration Area管理：传统TA（Tracking Area）基于地面基站覆盖定义，但卫星覆盖区域随轨道运动持续变化。Rel-19引入了动态TA映射机制——AMF根据卫星星历（ephemeris）数据预计算TA边界变化，通过NAS Registration Accept消息下发TA变化时间窗口。
NAS定时器适配：卫星通信的RTT可达数十至数百毫秒（LEO约20-40ms，GEO约540ms），远超地面5G的~1ms。Rel-19为以下定时器增加了NTN适配值：
| 定时器 | 默认值（地面） | NTN适配值（LEO） | NTN适配值（GEO） |
|---|---|---|---|
| T3510（注册完成） | 6秒 | 10秒 | 20秒 |
| T3502（重注册回退） | 60秒 | 120秒 | 300秒 |
| T3512（周期注册） | 54分钟 | 180分钟 | 360分钟 |
| T3540（去附着等待） | 6秒 | 10秒 | 20秒 |
Rel-19在NAS层进一步完善了Multi-USIM设备支持。当一个终端配备多个USIM卡时，可能同时收到来自不同网络的Paging消息，导致冲突。Rel-19引入的增强包括：
PFCP（Packet Forwarding Control Protocol）作为SMF与UPF之间的N4接口协议，在Rel-19中迎来了自Rel-16以来最大的改动。TS 29.244已更新至V19.3.0版本，新增了大量IE和流程支持。
图表 3
这是Rel-19 PFCP最核心的改动之一。卫星链路的传播时延不仅大，而且动态变化（LEO卫星过境时延从~4ms变到~40ms）。UPF需要知道这些时延特征才能正确设置QoS定时器和缓存策略。
新增IE：Propagation Delay Information
在PFCP Session Establishment Request中，SMF可以携带以下新增IE：
| IE名称 | 类型 | 长度 | 说明 |
|---|---|---|---|
| Propagation Delay Threshold | Grouped | 可变 | 传播时延阈值，超过时UPF上报 |
| NTN Service Link Delay | Unsigned32 | 4字节 | 服务链路单向时延（微秒） |
| Satellite Orbit Type | Enumerated | 1字节 | LEO/MEO/GEO/GEO-equatorial |
| Delay Variation Rate | Integer32 | 4字节 | 时延变化率（μs/s） |
PFCP Session Report增强：UPF通过PFCP Session Report Request新增的NTN Delay Report IE向SMF上报当前传播时延。SMF根据报告调整QoS参数或触发UPF重选。
典型的NTN PFCP Session Establishment流程：
NTN Service Link Delay IERel-19引入了多维度计费能力，PFCP的URR（Usage Reporting Rule）在以下方面进行了增强：
新增URR触发条件：
| 觋发条件 | Rel-18 | Rel-19 | 说明 |
|---|---|---|---|
| Volume Threshold | ✓ | ✓ | 流量阈值 |
| Time Threshold | ✓ | ✓ | 时间阈值 |
| Event Threshold | - | ✓（新增） | 基于事件数量的阈值 |
| QoS Change | - | ✓（新增） | QoS变更触发报告 |
| Location Change | - | ✓（新增） | 位置变化触发报告（NTN场景） |
| Multiple URR Correlation | - | ✓（新增） | 多URR联合触发 |
新增的PFCP IE用于增强计费：
Rel-19对PFCP的QoS监控做了显著增强，特别是为了支持确定性通信（TSC，Time Sensitive Communications）场景。
SMF可通过PFCP Session Modification Request指示UPF执行端到端时延测量。UPF在数据包中插入时间戳，下游节点返回测量结果。
新增PFCP Node Report：UPF可以向SMF报告节点级别的QoS统计信息，包括： - 平均包转发时延 - 丢包率 - 抖动统计 - 缓存利用率
Rel-19中NWDAF（Network Data Analytics Function）从"数据分析功能"演进为"AI/ML推理与训练平台"。TS 29.500/29.501中定义的SBI原则为此引入了新的服务化接口。
| NWDAF服务 | Rel-18 | Rel-19新增 | 说明 |
|---|---|---|---|
| Nnwdaf_AnalyticsSubscription | ✓ | - | 订阅分析事件 |
| Nnwdaf_AnalyticsInfo | ✓ | - | 查询分析结果 |
| Nnwdaf_MLModelProvision | ✓（基础） | ✓（增强） | ML模型管理 |
| Nnwdaf_DataManagement | - | ✓（新增） | 训练数据采集与管理 |
| Nnwdaf_FederatedLearning | - | ✓（新增） | 联邦学习协调 |
Nnwdaf_FederatedLearning是Rel-19最值得关注的新服务。它允许NWDAF协调多个分布式ML Agent（可部署在不同NF或边缘节点上）执行联邦学习训练，无需集中化原始数据。
图表 4
Ambient IoT引入了一个全新的网络功能AIoTF（Ambient IoT Function）。AIoTF负责： - 管理Ambient IoT设备的标识和上下文 - 与UDM交互获取设备签约信息 - 与AMF交互处理简化注册 - 与NEF/SCEF交互暴露能力给第三方
AIoTF的SBI服务接口定义在TS 29.501的扩展章节中，主要API包括：
| API名称 | HTTP方法 | 说明 |
|---|---|---|
| Naiotf_Device_Register | POST | 设备注册 |
| Naiotf_Device_Deregister | DELETE | 设备注销 |
| Naiotf_Device_Update | PUT | 更新设备上下文 |
| Naiotf_Location_Report | POST | 位置报告 |
| Naiotf_Data_Collection | POST | 数据采集上报 |
Rel-19在TS 29.500中引入了多项SBI安全增强：
3gpp-ratelimit），替代各厂商私有实现3gpp-correlation-id用于端到端追踪GTP-U在Rel-19中进行了NTN相关的关键适配。TS 29.281新增了扩展Header Type用于携带NTN时延信息：
新增GTP-U Extension Header：NTN Timing Information
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extension Header Type (新定义) | Length (4字节) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Propagation Delay (μs) | Delay Variation Rate (μs/s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Satellite ID | Next Extension Header Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
这个扩展头的引入使得： - 中间UPF可以根据时延信息调整缓冲策略 - 边缘UPF可以根据卫星ID选择最优的下行路径 - 端到端时延计算更加精确
Rel-19增强了对Time Sensitive Networking（TSN）和确定性通信的支持。GTP-U层面引入了：
Rel-19的GTP-U Echo Request/Response消息新增了以下信息元素：
| IE | 说明 |
|---|---|
| Node Capability | 报告UPF的NTN支持能力 |
| Load Information | 报告当前负载情况 |
| Supported Features | 位图标识支持的Rel-19特性 |
NR RRC在Rel-19中为NTN做了大量适配。TS 38.331 V19.0.0新增和修改的关键内容包括：
SIB增强：新增SIB类型（SIB24-NTN）用于广播卫星特定信息： - 卫星星历参数 - 参考位置和时间 - NTN TA偏移值 - 切换触发条件
RRC连接重配置：为卫星间切换新增了以下字段：
- ntn-HO-Config：卫星切换配置
- satellite-Info：目标卫星信息
- ephemeris-Info：用于UE预测切换时机的星历数据
Ambient IoT Class 1设备不支持RRC信令（仅反向散射通信），但Class 2/3设备需要简化的RRC支持。Rel-19引入了：
Rel-19增强了NR-DC信令，特别是在NTN与地面网络双连接场景：
图表 5
NR-DC增强中的RRC变化：
- Split Bearer RRC配置：RRCReconfiguration消息中新增ntn-SplitBearer-Config，允许数据在地面和卫星链路间分流
- 快速SN变更：卫星移动导致的SN变更通过条件切换（CHO）机制实现，RRC消息携带候选SN列表
- SCG Failure Handling：NTN链路质量波动导致的SCG失败处理优化，减少不必要的MN切换
对于运营商而言，Rel-19的协议层改动意味着多方面的升级：
| 升级目标 | 影响面 | 升级策略 |
|---|---|---|
| AMF | NAS协议栈、NTN定时器、AIoTF交互 | 软件升级，需支持新NAS IE |
| SMF | PFCP客户端、NTN感知逻辑 | 软件升级 + PFCP IE扩展 |
| UPF | PFCP服务端、GTP-U扩展头、NTN报告 | 软件升级 + 性能监控增强 |
| NRF | SBI服务发现（AIoTF注册） | 服务配置更新 |
| gNB | RRC协议栈、NTN信令、NR-DC | 基带软件升级 |
| NWDAF | 新SBI服务API、联邦学习 | 架构扩展 + ML平台集成 |
SupportedFeatures位图协商Rel-19引入的新IE和流程增加了信令开销，但在大多数场景下增量可控：
| 场景 | 信令开销增加 | 说明 |
|---|---|---|
| 标准NAS注册（无NTN） | ~0% | 无变化 |
| NTN NAS注册 | +15-20% | 新增NTN相关IE |
| Ambient IoT注册 | -60%（对比标准注册） | 简化流程，总消息数大幅减少 |
| PFCP Session（NTN场景） | +10-15% | 新增时延相关IE |
| SBI联邦学习训练 | 额外周期性开销 | 与训练迭代次数成正比 |
| 维度 | Rel-18 | Rel-19 |
|---|---|---|
| NAS认证 | 完整EAP-AKA'/5G-AKA | 新增Ambient IoT简化认证 |
| NAS定时器 | 固定值 | NTN动态适配值 |
| PFCP QoS监控 | 基础包时延测量 | 增强端到端监控+节点级报告 |
| PFCP计费 | Volume/Time/Event | 新增QoS Change/Location Change触发 |
| GTP-U扩展头 | 标准定义 | 新增NTN Timing Information |
| SBI NWDAF | 基础分析+ML模型管理 | 联邦学习+数据管理+增强分析 |
| SBI新NF | 无 | AIoTF（Ambient IoT Function） |
| RRC NTN | 基础支持（Rel-17引入） | NR-DC+NTN、CHO增强 |
| Multi-USIM | 基础支持 | Paging冲突指示+状态管理 |
Q: Ambient IoT的简化NAS注册是否降低了网络安全性？
A: 3GPP在设计时做了仔细的权衡。Ambient IoT Class 1设备完全不走NAS信令，安全由物理层和链路层保证。Class 2设备虽然跳过了EAP-AKA'完整认证，但仍通过设备标识的加密传输和AIoTF的身份验证来保证基本安全。网络侧为Ambient IoT设备分配的是受限服务权限（Restricted Service），不能访问完整5G服务。此外，AIoTF会基于设备上下文实施策略控制。
Q: 现网UPF如何平滑升级到支持Rel-19 PFCP？
A: 建议分三个阶段：（1）先升级SMF支持新的PFCP IE编码/解码，UPF侧利用forward compatible机制忽略未知IE，确保基本互操作；（2）逐步在UPF上启用NTN时延报告功能，先在实验室环境验证；（3）部署增强URR计费特性，与计费系统联调。关键是要确保PFCP Association Setup中的UP Function Features位图正确声明UPF支持的Rel-19特性。
Q: Rel-19的SBI联邦学习对网络带宽有什么影响？
A: 联邦学习传输的是模型参数（梯度或权重更新），而非原始数据，因此带宽开销远小于集中式数据采集。一次FL迭代的典型数据量取决于模型大小：对于NWDAF常用的负载预测模型，约10-100KB/迭代。通常需要几十到几百次迭代收敛，总带宽消耗在MB级别。但需要注意的是FL训练期间的SBI调用频率较高，NRF的服务发现压力会增大。
Q: NTN场景下PFCP和GTP-U的定时器应该怎么配置？
A: 核心原则是"定时器值 ≥ 最大传播时延 × 2 + 处理时延"。对于LEO场景（单向~20ms），PFCP重传定时器建议设为100-200ms；GTP-U路径管理定时器建议设为500ms-1s。对于GEO场景（单向~270ms），PFCP重传定时器建议设为1-2s。同时建议启用Rel-19新增的Propagation Delay Threshold IE，让UPF在时延超阈值时主动上报，避免SMF频繁轮询。
Q: AIoTF是否必须作为独立NF部署？
A: TS 23.501允许AIoTF作为独立NF部署，也可以与AMF合设。对于小规模Ambient IoT部署（设备数<100万），建议与AMF合设以减少SBI交互开销。对于大规模部署（设备数>1000万），独立部署AIoTF有利于水平扩展和独立升级。AIoTF与AMF之间的接口是标准化的Naiotf服务，无论哪种部署方式都不影响接口行为。
本文由「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 等场景全覆盖。
