# 5G-Advanced Rel-19信令协议全栈增强解析：从NAS到PFCP的跨层演进 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跨层改动总览 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 | ## 二、NAS层变革：TS 24.501在Rel-19中的核心演进 ### 2.1 Ambient IoT催生的简化NAS流程 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能力，支持简化安全模式 ### 2.2 NTN移动性管理的NAS适配 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秒 | ### 2.3 Multi-USIM增强 Rel-19在NAS层进一步完善了Multi-USIM设备支持。当一个终端配备多个USIM卡时，可能同时收到来自不同网络的Paging消息，导致冲突。Rel-19引入的增强包括： - **Paging Collision Indication**：UE通过NAS消息通知网络侧存在Paging冲突，网络可延迟 Paging重发 - **多注册状态管理**：允许UE在不同PLMN中维持不同的注册状态（RM-REGISTERED/CM-IDLE vs RM-DEREGISTERED），AMF侧需要理解UE可能"暂时不可达" ## 三、PFCP协议演进：TS 29.244 V19.3.0深度解读 ### 3.1 Rel-19 PFCP架构增强全景 PFCP（Packet Forwarding Control Protocol）作为SMF与UPF之间的N4接口协议，在Rel-19中迎来了自Rel-16以来最大的改动。TS 29.244已更新至V19.3.0版本，新增了大量IE和流程支持。  > *图表 3* ### 3.2 NTN传播时延感知的PFCP机制 这是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流程： 1. SMF从AMF获取NTN能力指示（通过N2信息） 2. SMF根据卫星星历计算当前服务链路时延 3. SMF在PFCP Session Establishment Request中携带`NTN Service Link Delay` IE 4. UPF设置相应的缓冲定时器和QoS门控 5. 当卫星切换导致时延变化超过阈值时，UPF上报PFCP Session Report 6. SMF可能触发PFCP Session Modification调整转发规则 ### 3.3 增强计费（Enhanced Charging）的PFCP支持 Rel-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用于增强计费**： - **Event Volume Report**：按事件类型统计的用量报告 - **Enhanced Charging ID**：支持跨UPF关联计费记录 - **Service Data Flow Description**：细粒度的SDF过滤与计费 ### 3.4 QoS Monitoring Enhancement Rel-19对PFCP的QoS监控做了显著增强，特别是为了支持确定性通信（TSC，Time Sensitive Communications）场景。 SMF可通过PFCP Session Modification Request指示UPF执行端到端时延测量。UPF在数据包中插入时间戳，下游节点返回测量结果。 **新增PFCP Node Report**：UPF可以向SMF报告节点级别的QoS统计信息，包括： - 平均包转发时延 - 丢包率 - 抖动统计 - 缓存利用率 ## 四、SBI服务化接口：Rel-19的API级演进 ### 4.1 NWDAF服务扩展 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* ### 4.2 AIoTF——全新的SBI服务接口 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 | 数据采集上报 | ### 4.3 SBI安全增强 Rel-19在TS 29.500中引入了多项SBI安全增强： - **OAuth 2.0增强**：支持更细粒度的scope控制，每个NF服务操作可以有独立的授权范围 - **mTLS双向认证强化**：要求NF之间的服务调用必须携带完整的证书链 - **API Rate Limiting标准化**：定义了统一的速率限制HTTP Header（`3gpp-ratelimit`），替代各厂商私有实现 - **审计日志增强**：所有SBI调用必须携带`3gpp-correlation-id`用于端到端追踪 ## 五、GTP-U用户面协议：TS 29.281的Rel-19适配 ### 5.1 NTN传播时延的用户面处理 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选择最优的下行路径 - 端到端时延计算更加精确 ### 5.2 确定性通信的GTP-U支持 Rel-19增强了对Time Sensitive Networking（TSN）和确定性通信的支持。GTP-U层面引入了： - **时间感知调度标记**：GTP-U Header中的DSCP字段可以携带5G TSN Translator的调度优先级 - **Hold and Forward机制**：UPF可以按PFCP下发的调度时间表缓存和转发数据包，实现确定性时延 ### 5.3 GTP-U Echo增强 Rel-19的GTP-U Echo Request/Response消息新增了以下信息元素： | IE | 说明 | |----|------| | Node Capability | 报告UPF的NTN支持能力 | | Load Information | 报告当前负载情况 | | Supported Features | 位图标识支持的Rel-19特性 | ## 六、RRC层改动：TS 38.331 V19.0.0的关键变化 ### 6.1 NTN RRC信令增强 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预测切换时机的星历数据 ### 6.2 Ambient IoT的RRC处理 Ambient IoT Class 1设备不支持RRC信令（仅反向散射通信），但Class 2/3设备需要简化的RRC支持。Rel-19引入了： - **Reduced Capability RRC**：精简版的RRC消息集，减少必选字段数量 - **Early Data Transmission**：在RRC连接建立前就发送少量数据（类似Rel-15的EDT但针对A-IoT优化） ### 6.3 NR-DC（Dual Connectivity）增强 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切换 ## 七、实战部署考量 ### 7.1 现网升级路径 对于运营商而言，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平台集成 | ### 7.2 协议兼容性注意事项 1. **PFCP IE前向兼容**：Rel-19 UPF必须能忽略不认识的IE（TS 29.244 Section 8.1.2的"forward compatible"原则），确保与Rel-18 SMF的互操作 2. **GTP-U Extension Header协商**：通过GTP-U Echo能力协商确定对端是否支持Rel-19扩展头 3. **NAS向后兼容**：Rel-19 UE回落到Rel-18网络时，Ambient IoT指示等新IE被忽略，但不影响基本注册 4. **SBI API版本管理**：OpenAPI定义需遵循TS 29.501的API版本演进规则，新特性通过`SupportedFeatures`位图协商 ### 7.3 信令开销分析 Rel-19引入的新IE和流程增加了信令开销，但在大多数场景下增量可控： | 场景 | 信令开销增加 | 说明 | |------|------------|------| | 标准NAS注册（无NTN） | ~0% | 无变化 | | NTN NAS注册 | +15-20% | 新增NTN相关IE | | Ambient IoT注册 | -60%（对比标准注册） | 简化流程，总消息数大幅减少 | | PFCP Session（NTN场景） | +10-15% | 新增时延相关IE | | SBI联邦学习训练 | 额外周期性开销 | 与训练迭代次数成正比 | ## 八、Rel-18 vs Rel-19协议层对比总结 | 维度 | 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 等场景全覆盖。