# 5G去注册三径信令解码与定时器博弈 ## 一、引言：被忽视的"退出机制" 在5G协议栈中，Registration流程被无数次解读，而其镜像过程——Deregistration（去注册）——却很少获得同等关注。然而，正是这个"退出机制"决定了运营商网络资源的回收效率、用户体验的连续性，以及合规框架下的数据留存边界。本文基于3GPP TS 24.501 Section 5.4.4和TS 23.502 Section 4.2.2.3，对UE发起去注册、网络发起去注册、隐式去注册三条路径进行全链路信令拆解，并深入分析T3512→Mobile Reachable Timer→Implicit Deregistration Timer三级定时器联动机制对运营商成本与用户体验的博弈影响。 --- ## 二、去注册的三条路径全景 5G系统中的Deregistration并非单一流程，而是根据触发源和场景分化为三条完全不同的执行路径： | 维度 | UE发起去注册 | 网络发起去注册 | 隐式去注册 | |------|-------------|---------------|-----------| | **协议定义** | TS 24.501 §5.4.4.1 | TS 24.501 §5.4.4.2 | TS 24.501 §5.3.7 | | **信令方向** | UE→AMF→网元联动 | AMF→UE→网元联动 | AMF内部执行 | | **NAS消息** | DEREGISTRATION REQUEST/ACCEPT | DEREGISTRATION REQUEST/ACCEPT | 无NAS信令 | | **UE是否感知** | 是（主动发起） | 是（被动接受） | 否（完全无感） | | **典型场景** | 关机、飞行模式、RAT切换 | O&M运维、签约变更、AMF过载 | 长期不可达、欠费静默清理 | | **定时器依赖** | 无 | 无 | T3512 + MR Timer + Implicit Timer |  > *图表 1* --- ## 三、路径一：UE发起去注册信令流全链路拆解 ### 3.1 完整时序图 基于TS 23.502 Section 4.2.2.3.2的UE-initiated Deregistration流程：  > *图表 2* ### 3.2 关键IE深度解析 DEREGISTRATION REQUEST（UE Originating）消息结构定义于TS 24.501 Section 8.2.9： | IE名称 | 长度 | 取值范围 | 含义与实战意义 | |--------|------|----------|---------------| | **Extended Protocol Discriminator** | 1字节 | 0x7E | 固定值，标识5GMM消息 | | **Security Header Type** | 1字节 | 0x00/0x01/0x02/0x03 | 0x00=无保护，0x02=完整性保护，0x03=加密+完整性保护 | | **Deregistration type** | 1字节 | 见下表编码 | 决定去注册后行为 | | **5G-GUTI** | 变长 | TS 24.501 §9.11.3.4 | UE标识，AMF据此查找上下文 | | **Access type** | 1字节 | 0x01/0x02/0x03 | 0x01=3GPP, 0x02=Non-3GPP, 0x03=Both | **Deregistration Type编码**（TS 24.501 §9.11.3.14）： | Bit 2 | Bit 1 | 含义 | 典型场景 | |-------|-------|------|----------| | 0 | 0 | Re-registration required | 切片重选、AMF迁移 | | 0 | 1 | Not re-registration required | 正常关机、飞行模式 | | 1 | 0 | Switch-off | 立即关机，不等ACCEPT | | 1 | 1 | Reserved | — | ### 3.3 设计意图分析 **为什么Switch-off类型不需要ACCEPT？** 这是5G相比4G的一个重要优化。在TS 24.501 §5.4.4.1中明确规定，当Deregistration type为switch-off时，AMF不需要发送DEREGISTRATION ACCEPT，UE也不等待直接断电。设计意图是减少关机时的空口延迟——用户按下关机键后，UE发出一条"遗言"消息即可立即断电，网络侧异步完成清理。 **为什么需要Re-registration required类型？** 这个类型构成了5G"去注册-重注册"原子操作的基础。当AMF发生改变、切片配置变更或策略更新时，网络可以通过先去注册再重注册的方式，确保UE获得最新的网络配置，而无需经历完整的首注册流程（无需再次鉴权和安全模式控制）。 --- ## 四、路径二：网络发起去注册——策略驱动的强制下线 ### 4.1 完整时序图 基于TS 23.502 Section 4.2.2.3.1和TS 24.501 Section 5.4.4.2：  > *图表 3* ### 4.2 网络发起去注册的Cause Value映射 网络发起的DEREGISTRATION REQUEST中不直接携带5GMM Cause值，而是通过Deregistration type间接传达意图。但触发原因多种多样，在实际抓包中需要结合SBI接口消息来还原完整因果链： | 触发源 | SBI接口 | 触发条件 | Deregistration Type选择 | |--------|---------|----------|------------------------| | UDM签约变更 | Nudm_SDM_Notification | 用户签约数据中5GS subscription status变更 | Re-registration required | | UDM注销通知 | Nudm_UECM_DeregistrationNotification | 欠费、销户、管理操作 | Not re-registration required | | AMF过载 | 内部策略 | AMF负载超过阈值 | Re-registration required | | O&M操作 | 管理接口 | 运维人员主动操作 | 取决于操作意图 | | 切片重选 | 内部策略 | UE当前切片不再可用 | Re-registration required | ### 4.3 CM-IDLE状态下的寻呼博弈 网络发起去注册在UE处于CM-IDLE状态时面临一个关键问题：必须先寻呼UE使其回到CM-CONNECTED，才能传递NAS DEREGISTRATION REQUEST。这产生了一个微妙的设计权衡—— - **寻呼成本**：全网寻呼消耗RAN侧无线资源和AMF处理能力 - **可靠性**：如果UE不可达（如地下车库、飞行模式），寻呼将失败 - **回退策略**：如果寻呼超时，AMF会等待UE下次可达时再发送，或直接触发隐式去注册 这一设计在TS 24.501 §5.4.4.2.2中描述：如果UE不可达，AMF应标记UE为"deregistered pending"状态，在UE下次发起任何NAS信令时执行去注册。 --- ## 五、路径三：隐式去注册——无声的资源回收 ### 5.1 三级定时器联动机制 隐式去注册是5G系统中最具运营商博弈色彩的设计。它不产生任何空口信令，完全在AMF内部执行，但背后是一套精密的三级定时器联动：  > *图表 4* **定时器参数详解**（TS 24.501 §5.3.7和TS 23.502 §4.2.2.3.2）： | 定时器 | 定义位置 | 默认值 | 运行条件 | 超时动作 | |--------|----------|--------|----------|----------| | **T3512** | TS 24.501 §5.3.7 | 54分钟（可配） | UE进入CM-IDLE后启动 | UE发起Periodic Registration Update | | **Mobile Reachable Timer** | TS 24.501 §5.3.7 | T3512 + 4分钟 | UE进入CM-IDLE后AMF侧启动 | 标记UE为"不可达"，启动Implicit Timer | | **Implicit Deregistration Timer** | TS 23.502 §4.2.2.3 | 4分钟（建议） | MR Timer超时后启动 | AMF执行隐式去注册 | ### 5.2 定时器博弈：运营商的调优困局 三级定时器的参数配置直接影响运营商的两个核心指标：**资源占用效率**和**用户可达性**。 **缩短T3512的代价**： 如果运营商将T3512从默认的54分钟缩短到12分钟，周期性注册更新的信令负载将增加约4.5倍。对于拥有千万级用户的网络，这意味着每分钟数十万次额外的NAS信令交互。但收益是更快发现不可达UE，加速资源回收。 **延长T3512的风险**： 将T3512延长到6小时，虽然信令负载大幅下降，但不可达UE的PDU Session、QoS Flow和N4 Session将在AMF/SMF/UPF上长时间占用资源。对于IoT场景（数亿设备），这种资源浪费可能是灾难性的。 | T3512配置 | 周期注册频率 | 资源回收速度 | 信令负载 | 适用场景 | |-----------|-------------|-------------|---------|---------| | 6分钟 | 10次/小时 | 极快（~10分钟） | 极高 | URLLC/IoT关键业务 | | 24分钟 | 2.5次/小时 | 快（~28分钟） | 中高 | 普通手机用户 | | 54分钟（默认） | ~1.1次/小时 | 中等（~58分钟） | 中等 | 通用场景 | | 180分钟 | 0.33次/小时 | 慢（~184分钟） | 低 | 大量IoT设备 | | 360分钟 | 0.17次/小时 | 极慢（~364分钟） | 极低 | 低价值IoT | ### 5.3 隐式去注册的完整执行流程 基于TS 23.502 Section 4.2.2.3.2和TS 29.503 Section 5.3.2.2： 1. **Implicit Deregistration Timer超时** → AMF将UE状态标记为5GMM-DEREGISTERED 2. **AMF→SMF**：通过`Nsmf_PDUSession_ReleaseSMContext`释放所有非紧急PDU Session 3. **SMF→UPF**：通过N4接口释放用户面资源 4. **SMF→PCF**：通过`Npcf_SMPolicyControl_Delete`删除会话策略关联 5. **AMF→UDM**：通过`Nudm_UECM_Deregistration`通知UDM，携带`PurgeFlag`指示UE已不可达 6. **UDM处理**：将UE的注册状态标记为DEREGISTERED，但**保留签约数据**以备UE下次注册 7. **AMF→RAN**（如果N2连接存在）：发起`N2 UE Context Release` --- ## 六、去注册与PDU Session的联动——紧急会话的特殊保护 TS 24.501 Section 5.4.4明确规定了一个关键约束：**所有类型的去注册都必须保留紧急PDU Session**。这意味着：  > *图表 5* 这一设计的法规背景源于各国通信监管要求——如FCC（美国）、BEREC（欧盟）、MIIT（中国）均要求运营商提供紧急呼叫能力，即使用户欠费或未签约。TS 23.502 Section 4.2.2.3通过保留紧急PDU Session的方式，在协议层面落实了这一监管要求。 --- ## 七、实战抓包识别指南 ### 7.1 Wireshark过滤规则 | 场景 | Wireshark过滤表达式 | |------|---------------------| | UE发起去注册请求 | `nas-5gs.message_type == 0x41` | | 网络发起去注册请求 | `nas-5gs.message_type == 0x41 && nas-5gs.direction == 1` | | 去注册接受 | `nas-5gs.message_type == 0x42` | | SBI Deregistration通知 | `http2.path contains "nudm-uecm/v1/*/dereg-notify"` | | PDU Session释放 | `ngap.procedureCode == 42 && ngap.cause == 0` | ### 7.2 常见故障场景 **故障场景1：去注册后立即重注册循环** 现象：UE反复发送DEREGISTRATION REQUEST（re-registration required）→ DEREGISTRATION ACCEPT → Registration Request循环。 根因分析：AMF在处理去注册后，由于切片配置不兼容或GUTI分配冲突，UE被迫再次发起注册，但新注册结果与前一次相同，形成死循环。 排查步骤： 1. 检查Registration Accept中的Allowed NSSAI是否与UE请求的S-NSSAI匹配 2. 确认AMF Set ID和GUTI分配是否正确 3. 检查PCF策略是否导致反复重定向 **故障场景2：隐式去注册后UE假在线** 现象：UE认为仍在线，但网络侧已清理上下文，导致上行数据发送失败。 根因：T3512配置过长 + UE未正确执行周期注册更新（如省电模式过于激进）。 排查步骤： 1. 检查AMF的MR Timer和Implicit Timer配置 2. 对比UE侧T3512值与AMF侧MR Timer值 3. 检查是否存在UE与网络T3512值不一致的情况（通常因Registration Accept中未正确下发） **故障场景3：紧急会话被误释放** 现象：执行去注册后，正在进行中的紧急呼叫中断。 根因：SMF实现未正确区分紧急PDU Session和普通PDU Session，在收到`Nsmf_PDUSession_ReleaseSMContext`时无条件释放。 排查步骤： 1. 检查SMF是否检查PDU Session Type IE中的Emergency指示 2. 确认SMF在收到Release请求时是否跳过紧急会话 3. 检查AMF下发给SMF的Release消息中是否包含明确的Session列表过滤 --- ## 九、隐式去注册的合规考量 从监管角度看，隐式去注册涉及两个合规维度： **数据留存义务**：各国电信法规要求运营商保留用户通信记录一定期限。隐式去注册清理UE上下文时，AMF必须确保已将相关计费数据、位置信息等转存至持久化存储（如CHF、UDR）。TS 32.240规定的CHF交互必须在AMF清理上下文之前完成。 **紧急服务可达性**：如前所述，隐式去注册不能释放紧急PDU Session。运营商在配置隐式去注册策略时，必须确保SMF具备紧急会话识别能力。这一要求在中国MIIT的《电信用户申诉处理管理办法》和欧盟的Universal Service Directive中都有明确体现。 **物联网设备管理**：对于海量IoT设备，运营商需要在"快速资源回收"和"设备可达性"之间取得平衡。GSMA的NG.116指南建议，对于低移动性IoT设备，T3512可以配置为24小时甚至更长，但必须配合MO-only数据传输策略来避免不必要的周期注册。 --- ## 十、常见问题 **Q1: Deregistration和4G的Detach有什么核心区别？** A: 5G Deregistration相比4G Detach有三个关键演进：(1) 支持Partial Deregistration——可以仅对3GPP或Non-3GPP接入单独去注册，而不影响另一接入的注册状态；(2) 引入Re-registration required类型——支持"去注册+重注册"的原子操作，减少了完整注册流程的开销；(3) 与网络切片深度耦合——去注册可以由切片重选触发，重注册时可能选择不同的AMF/S-NSSAI组合。 **Q2: 隐式去注册后UE再次发起注册，网络如何知道这是"重新注册"而非"首次注册"？** A: UDM中保留了UE的签约数据和注册历史。即使AMF通过Purge操作清理了本地5GMM上下文，UDM仍然保有Subscription Data。当UE再次注册时，新AMF会通过`Nudm_SDM_Get`从UDM获取签约数据，通过`Nudm_UECM_Registration`更新注册信息。如果隐式去注册时间未超过UDM的保留期限，部分上下文可以被恢复。 **Q3: 运营商为什么需要配置不同的T3512值？** A: 核心原因是不同业务场景对"可达性"和"信令负载"的权衡完全不同。手机用户需要快速发现不可达（短T3512），IoT传感器需要极低信令开销（长T3512），URLLC工业设备需要毫秒级故障检测（极短T3512）。TS 23.501 Section 5.3.5允许AMF在Registration Accept中为不同UE下发不同的T3512值，运营商据此实现差异化定时器策略。 **Q4: 网络发起去注册时，如果UE处于CM-IDLE且不可达，AMF应该怎么做？** A: 按TS 24.501 §5.4.4.2.2的规定，AMF有两种策略可选：(1) 先发起Paging，如果UE响应则正常完成去注册流程；(2) 如果Paging超时，AMF可以标记UE为"deregistration pending"状态，等待UE下次发起任何NAS信令时执行去注册。部分厂商实现中，如果网络侧已决定强制去注册，会直接跳过Paging进入隐式去注册流程，以加速资源回收。 **Q5: 去注册过程中，如果某个SMF的PDU Session释放失败，AMF是否继续执行？** A: TS 23.502 §4.2.2.3规定，去注册流程不应因为单个PDU Session释放失败而中断。AMF会记录失败的Session，继续执行后续流程（通知UDM、释放N2连接等）。失败的PDU Session会在后续通过SMF自身的超时机制异步释放。这种"尽力而为"的设计确保了去注册流程的鲁棒性。 --- ## 参考来源 1. [3GPP TS 24.501 V18.9.0](https://www.3gpp.org/DynaReport/24501.htm) — Section 5.4.4 (Deregistration procedures), Section 5.3.7 (Periodic Registration Update timer handling), Section 8.2.9 (DEREGISTRATION REQUEST message) 2. [3GPP TS 23.502 V18.10.0](https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3145) — Section 4.2.2.3 (Deregistration procedures), Section 4.2.2.3.1 (Network-initiated), Section 4.2.2.3.2 (UE-initiated) 3. [3GPP TS 29.503](https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3342) — Section 5.3.2.2 (Nudm_UECM_DeregistrationNotification), Section 5.3.2.3 (Purge UE) 4. [3glteinfo - 5G Deregistration Procedure Call Flow](https://www.3glteinfo.com/call-flows/5g-deregistration-procedure/) — 完整去注册信令流参考 5. [华为云社区 - 5G信令流程MM定时器](https://bbs.huaweicloud.com/blogs/291573) — T3512/MR Timer/Implicit Timer联动机制分析 --- > 本文由「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 等场景全覆盖。