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 同步状态。

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 链路上的鉴权、路由、拓扑隐藏机制与注册完全一致，差异仅在"绑定失效"这一动作上。

完整信令时序

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安全关联<br/>移除 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: 校验鉴权响应<br/>将 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 与设计意图

设计精要：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 触发）

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<br/>确定受影响 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 的后续处理策略：

注意：PERMANENT_TERMINATION（值 0）下，S-CSCF 会向 HSS 确认它将不再服务于该用户；而 NEW_SERVER_ASSIGNED/SERVER_CHANGE 则意味着 S-CSCF 拓扑调整，UE 随后必须重新走完整注册流程才能恢复业务——这就是用户偶尔遇到"被踢下线后必须重启 VoNR 开关"的底层原因。

四、注册状态机：S-CSCF 视角

把两条路径统一到 S-CSCF 的状态视角，注销就是从 REGISTERED 迁回 NOT_REGISTERED 的过程。状态机也解释了定时器超时为何等价于网络发起注销：

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 指示去注册。

常见故障与排错思路

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 — UE 发起与网络发起注销流程定义
2. TS 23.228 Section 5.3.2 — Network initiated de-registration | iTecSpec — 网络发起注销场景逐条解析
3. 3GPP TS 29.228 / TS 29.229 — Cx and Dx interfaces — RTR/RTA 命令与 Deregistration-Reason/Reason-Code AVP 定义
4. 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 — 注销 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 等场景全覆盖。