# IMS注销（Deregistration）信令全链拆解：UE发起与网络发起两条路径的协议级解析 注册（Registration）是 IMS 用户获得业务可达性的前提，而**注销（De-registration）**则是这条可达性链路被主动或被动切断的过程。与注册相比，注销在现网中更容易被忽视，但它直接决定了"用户为何突然收不到呼叫""会话为何被网络强制拆链""AS 业务状态为何不一致"等高频疑难问题。本文以 3GPP TS 23.228（Stage 2）的注销流程为主线，结合 TS 24.229（SIP/SDP 协议）、TS 29.228/29.229（Cx/Dx 接口）的具体机制，对 **UE 发起**与**网络发起**两条完整信令链路进行逐消息、逐 IE 的拆解。 --- ## 一、注销的两条本质路径 IMS 注销在 TS 23.228 第 5.3 节中明确定义为两大类： - **5.3.1 移动台/UE 发起的注销**：UE 主动发送 `REGISTER`（`Expires=0`），常见于关机、拔卡、用户手动退出 IMS、应用层触发去注册。 - **5.3.2 网络发起的注销**：由 HSS（5.3.2.2.1）或业务平台 AS（5.3.2.2.2）触发，S-CSCF 向下逐节点清理绑定。常见于订阅撤销、运维清退、注册定时器超时、S-CSCF 重指派。 两者的关键差异在于**触发源**与**信令方向**：UE 发起是自下而上的请求-响应，网络发起是自上而下的通知-执行。但二者最终都汇聚到同一个动作——**S-CSCF 删除 Contact 绑定 + HSS 置位 `NOT_REGISTERED` + AS 同步状态**。 ```mermaid flowchart TD A[注销触发] --> B{触发源?} B -->|UE 主动| C[5.3.1 UE发起路径] B -->|HSS/AS/定时器| D[5.3.2 网络发起路径] C --> E[S-CSCF 删绑定] D --> E E --> F[HSS 置 NOT_REGISTERED] F --> G[第三方 REGISTER 通知 AS] G --> H[reg-event NOTIFY 通知订阅者] H --> I[可选: BYE 拆除活动会话] ``` --- ## 二、UE 发起注销：`REGISTER(Expires=0)` 全链时序 UE 发起注销在协议上非常巧妙——它**复用了注册消息**，仅通过把 `Expires` 置零来表达"注销"语义。这意味着整条 Gm/Mw/Cx 链路上的鉴权、路由、拓扑隐藏机制与注册完全一致，差异仅在"绑定失效"这一动作上。 ### 完整信令时序 ```mermaid sequenceDiagram participant UE participant PCSCF as P-CSCF participant ICSCF as I-CSCF participant SCSCF as S-CSCF participant HSS participant AS UE->>PCSCF: REGISTER (Expires:0, Contact:*, Authorization, Security-Verify, P-Access-Network-Info) Note over PCSCF: 验证IPsec安全关联
移除 Security-Server PCSCF->>ICSCF: REGISTER (Via追加, P-Visited-Network-ID) ICSCF->>HSS: Cx-Location-Info-Request (LIR) HSS-->>ICSCF: LIA (S-CSCF Name) ICSCF->>SCSCF: REGISTER (转发) Note over SCSCF: 校验鉴权响应
将 Contact 绑定 expires 置 0 SCSCF->>HSS: Cx-Put / SAR (Server-Assignment-Type=去注册) HSS-->>SCSCF: SAA (registration state=NOT_REGISTERED) SCSCF->>AS: 第三方 REGISTER (Expires:0) [ISC] AS-->>SCSCF: 200 OK SCSCF-->>ICSCF: 200 OK ICSCF-->>PCSCF: 200 OK Note over PCSCF: 删除 UE 绑定 PCSCF-->>UE: 200 OK SCSCF->>PCSCF: NOTIFY (reg-event, state=terminated) PCSCF-->>UE: NOTIFY (state=terminated) ``` ### 关键 IE 与设计意图 | 头域 / IE | 取值 | 协议层作用 | 设计意图 | |-----------|------|-----------|---------| | `Expires` | `0` | 顶层头，对整个 REGISTER 生效 | 复用注册消息表达注销，无需新增方法（TS 24.229） | | `Contact` | `*` 或具体 Contact | `*` 为通配符，注销该用户下所有绑定 | 支持一次性清理多设备/多接入注册 | | `Authorization` | 携带 RES 鉴权响应 | IPsec 完整性保护下校验 | 注销同样需鉴权，防止伪造注销攻击（TS 33.203） | | `Security-Verify` | 与注册时一致 | 关联已建立的 IPsec SA | 确保注销请求来自合法已注册 UE | | `P-Access-Network-Info` | 接入类型/小区 | 辅助 S-CSCF/AS 记录 | 注销审计、计费关联 | | `P-Visited-Network-ID` | 拜访网络标识 | P-CSCF 注入，漫游拓扑 | 漫游场景识别拜访域 | > **设计精要**：`Contact: *` 是注销中的"清场开关"。若 UE 只想注销某一个设备而保留其他设备的注册，应使用具体 `Contact` 而非通配符。而 `Expires` 顶层头与 `Contact` 内的 `;expires=0` 是两种等价写法，现网抓包中两者常并存。 --- ## 三、网络发起注销：RTR 驱动的自上而下清理 网络发起注销的**信号源是 HSS 或 AS**，它通过 Cx 接口的 **`Registration-Termination-Request/Answer`（RTR/RTA）** 命令把"必须注销"的指令推给 S-CSCF，再由 S-CSCF 向下逐跳发送 `REGISTER(Expires=0)` 完成 UE 侧清理。这是 IMS 中少有的"网络侧主动推"信令，理解它对排查"用户被静默踢下线"至关重要。 ### 完整信令时序（HSS 触发） ```mermaid sequenceDiagram participant HSS participant SCSCF as S-CSCF participant PCSCF as P-CSCF participant UE participant AS Note over HSS: 触发: 订阅撤销/运维清退/定时器超时 HSS->>SCSCF: Cx-Deregistration: RTR (User-Identity, Deregistration-Reason) Note over SCSCF: 解析 Reason-Code
确定受影响 Contact 集合 SCSCF->>PCSCF: REGISTER (Expires:0, Contact) [Mw] PCSCF->>UE: REGISTER (Expires:0) UE-->>PCSCF: 200 OK Note over PCSCF: 删除绑定 PCSCF-->>SCSCF: 200 OK SCSCF->>AS: 第三方 REGISTER (Expires:0) [ISC] AS-->>SCSCF: 200 OK Note over SCSCF: 若存在活动会话 SCSCF->>PCSCF: BYE (按 Dialog) PCSCF->>UE: BYE UE-->>SCSCF: 200 OK SCSCF-->>HSS: RTA (结果确认) ``` ### RTR 的 Deregistration-Reason 与 Reason-Code（TS 29.228） Cx 接口的 RTR 通过 `Deregistration-Reason` AVP 携带 `Reason-Code`，决定了 S-CSCF 的后续处理策略： | Reason-Code | 名称 | 含义 | S-CSCF 典型动作 | |-------------|------|------|----------------| | 0 | `PERMANENT_TERMINATION` | 用户被永久终止（订阅撤销） | 清理全部绑定 + 拆除活动会话 + RTA | | 1 | `NEW_SERVER_ASSIGNED` | HSS 为该用户新指派了 S-CSCF | 清理后等待新 S-CSCF 接管，触发重注册 | | 2 | `SERVER_CHANGE` | S-CSCF 发生变更 | 通知 UE 重新发起注册以获得新 S-CSCF | | 3 | `REMOVE_CSR` | Contact 状态被移除 | 仅移除指定 Contact 绑定，保留其余 | > **注意**：`PERMANENT_TERMINATION`（值 0）下，S-CSCF 会向 HSS 确认它将不再服务于该用户；而 `NEW_SERVER_ASSIGNED`/`SERVER_CHANGE` 则意味着 S-CSCF 拓扑调整，UE 随后必须重新走完整注册流程才能恢复业务——这就是用户偶尔遇到"被踢下线后必须重启 VoNR 开关"的底层原因。 --- ## 四、注册状态机：S-CSCF 视角 把两条路径统一到 S-CSCF 的状态视角，注销就是从 `REGISTERED` 迁回 `NOT_REGISTERED` 的过程。状态机也解释了定时器超时为何等价于网络发起注销： ```mermaid stateDiagram-v2 [*] --> NOT_REGISTERED NOT_REGISTERED --> REGISTERED: REGISTER (鉴权通过, SAR/REGISTRATION) REGISTERED --> REGISTERED: re-REGISTER (定时器内续期) REGISTERED --> PENDING_DEREG: 收到 REGISTER(Expires=0) 或 RTR 或 定时器超时 PENDING_DEREG --> NOT_REGISTERED: 绑定删除 + HSS置位 + 通知AS NOT_REGISTERED --> [*] ``` 其中 `REGISTERED → PENDING_DEREG` 的三个等价触发条件，恰好对应 UE 发起、HSS/AS 发起、定时器超时三种入口。S-CSCF 的注册定时器（默认 3600s，部分部署用更长的 `600000s` 级别）一旦在窗口内未收到 re-REGISTER，S-CSCF 内部即等价触发注销，这是"用户长时间飞行模式后回来收不到呼叫"的典型成因。 --- ## 五、隐式注册集与活动会话的连带效应 两个容易被忽略的协议细节，是现网排错的高频考点： 1. **隐式注册集（Implicit Registration Set）**：若多个 Public Identity 属于同一隐式注册集，注销其中任意一个（`PERMANENT_TERMINATION`）会连带注销集内全部身份（TS 23.228 隐式注册机制）。这就是"只注销了一个号码，结果同 IMSI 下所有号都不可达"的根源。 2. **注销 ≠ 自动拆会话**：协议上，`REGISTER(Expires=0)` 只删除"注册绑定"，**不会自动释放已建立的 SIP Dialog**。已建立的呼叫理论上仍可继续直到 BYE。但在 `PERMANENT_TERMINATION`/订阅撤销等强注销场景，S-CSCF 会**额外发送 BYE** 强制拆除活动会话。排错时若发现"注册没了但电话还在"，需重点核查 S-CSCF 是否补发了 BYE。 --- ## 六、抓包识别与故障排查 ### 抓包识别要点（Gm/Mw/Cx 三接口） - **Gm 接口（UE↔P-CSCF）**：搜索 `REGISTER` 且 `Expires: 0`，即可定位 UE 发起注销；若该 `REGISTER` 的 Via/Record-Route 表明来自网络侧，则为网络发起下发。 - **Mw 接口（CSCF 间）**：`REGISTER(Expires=0)` 的方向决定了路径——上行（P-CSCF→I-CSCF/S-CSCF）为 UE 发起，下行（S-CSCF→P-CSCF）为网络发起。 - **Cx 接口（S-CSCF↔HSS）**：Diameter 命令码为 **RTR(303)/RTA(304)**（命令码 303），是网络发起注销的确定性证据；UE 发起注销则表现为 **SAR/SAA** 且 `Server-Assignment-Type` 指示去注册。 ### 常见故障与排错思路 | 现象 | 可能根因 | 排错切入点 | |------|---------|-----------| | 用户收不到 MT 呼叫 | 注册被静默注销，HSS 已置 `NOT_REGISTERED` | 查 Cx 是否有 RTR；查 S-CSCF 注册定时器窗口 | | 注销后 AS 业务状态不一致 | 第三方 REGISTER(Expires=0) 未送达 AS | 查 ISC 接口 iFC 触发链路；查 AS 是否处理 reg-event | | 多号码同时不可达 | 隐式注册集连带注销 | 查 HSS IRS 配置；查 RTR 的 Associated-Identities | | 用户反复重注册 | `NEW_SERVER_ASSIGNED`/`SERVER_CHANGE` | 查 S-CSCF 容量/拓扑调整日志；查 DNS/I-CSCF 选择策略 | | 注册没了但呼叫仍在 | 强注销未补发 BYE | 查 S-CSCF 是否对活动 Dialog 发送 BYE | ## 常见问题 **Q: UE 发起注销为什么不用一个新方法（如 DEREGISTER），而要复用 `REGISTER(Expires=0)`？** A: 这是 SIP/IMS 的设计哲学——尽量复用已有方法。`REGISTER` 本身就承担"绑定管理"，`Expires=0` 是表达"绑定生存期归零"的最小语义扩展。复用可继承全部鉴权、路由、安全机制，避免新增方法带来的兼容性与安全开销。 **Q: `Expires: 0` 写在顶层头和写在 `Contact;expires=0` 有什么区别？** A: 顶层 `Expires` 对 REGISTER 内所有 Contact 生效；`Contact;expires=0` 只对该条 Contact 生效。配合 `Contact: *` 通配符可一次性清理全部绑定；想精确注销单个设备则用具体 Contact 加 `;expires=0`。 **Q: 网络发起注销时，活动中的通话一定会被立刻切断吗？** A: 不一定。协议上 `REGISTER(Expires=0)` 只删注册绑定，不自动释放 Dialog。但 `PERMANENT_TERMINATION` 等强场景下 S-CSCF 通常会额外补发 BYE 拆链。若只做注册迁移类注销，会话可保留至自然结束。 **Q: RTR 的 `NEW_SERVER_ASSIGNED` 和 `SERVER_CHANGE` 有何实质区别？** A: `NEW_SERVER_ASSIGNED` 表示 HSS 为用户指派了新的 S-CSCF（容量/能力重选），旧 S-CSCF 清理后由新 S-CSCF 接管，UE 需重新注册；`SERVER_CHANGE` 更侧重拓扑变更（如 S-CSCF 节点替换），同样需要 UE 重注册以获得正确服务节点。两者都表现为"用户被踢后需重新注册"。 **Q: 抓包如何快速区分是 UE 主动关机注销还是网络踢人？** A: 看 `REGISTER(Expires=0)` 在 Mw 接口的方向：UE 主动时为上行（P-CSCF→I/S-CSCF），网络发起时为下行（S-CSCF→P-CSCF）；进一步在 Cx 接口确认有无 RTR(303) 命令，有则铁定为网络发起。 --- ## 参考来源 1. [3GPP TS 23.228 V18.10.0 — IP Multimedia Subsystem (IMS) Stage 2, Section 5.3.1/5.3.2](https://www.etsi.org/deliver/etsi_ts/123200_123299/123228/18.10.00_60/ts_123228v181000p.pdf) — UE 发起与网络发起注销流程定义 2. [TS 23.228 Section 5.3.2 — Network initiated de-registration | iTecSpec](https://itecspec.com/3gpp/23.228/s/5.3.2) — 网络发起注销场景逐条解析 3. [3GPP TS 29.228 / TS 29.229 — Cx and Dx interfaces](https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=1681) — RTR/RTA 命令与 Deregistration-Reason/Reason-Code AVP 定义 4. [Diameter and SIP: Registration-Termination-Request/Answer](https://nickvsnetworking.com/diameter-and-sip-registration-termination-request-answer/) — RTR/RTA 与 SIP REGISTER 的端到端映射实战 5. [3GPP TS 24.229 — IMS Call Control Protocol based on SIP and SDP](https://www.3gpp.org/ftp/Specs/archive/24_series/24.229/) — 注销 SIP 消息处理与头域规范 --- > 本文由「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 等场景全覆盖。