eSRVCC语音域切换信令全链拆解：ATCF/ATGW锚点与SCC AS域转移机制

本文聚焦 3GPP TS 23.216（SRVCC架构与流程）、TS 23.237（IMS Service Continuity，SCC AS会话锚定与Domain Transfer）以及 TS 29.280（Sv接口PS-to-CS信令）三份核心规范，逐条拆解 eSRVCC（Enhanced Single Radio Voice Call Continuity）从切换触发、Sv接口PS-to-CS请求、ATCF本地域转移到SCC AS远端腿更新与原PS会话释放的完整信令链路。这是VoLTE/VoNR语音连续性体系中最具跨域协同复杂度的机制之一。

一、机制定位：为什么需要 eSRVCC 而不是基础 SRVCC

在 LTE/5G 网络部署初期，运营商通常存在大量只有 CS（电路交换）语音覆盖的 2G/3G 区域。当用户正在进行 VoLTE/VoNR 通话、并从纯 PS 覆盖区移动到只有 CS 覆盖的区域时，由于单射频终端（Single Radio UE）同一时刻只能驻留一个无线接入，必须把正在进行的 IMS 语音会话从 PS 域"转移"到 CS 域，这就是 SRVCC 解决的核心问题。

基础 SRVCC（Rel-8/9 引入，TS 23.216）的会话转移锚点放在归属网络（Home）的 SCC AS。这意味着每当发生切换，MSC Server 都要把 Session Transfer 的 INVITE 一路送到归属 SCC AS，由 SCC AS 完成"关联已有会话→更新远端腿→释放原接入腿"的整个 Domain Transfer。当用户处于漫游或归属网络较远时，这段跨网往返的 RTT 往往超过 300ms，导致可感知的语音中断（Voice Gap），无法满足 ITU-T P.1011 对语音连续性的要求。

eSRVCC（Rel-10 引入） 的关键设计在于：把信令锚点和媒体锚点前移到服务（Visited/Serving）网络——引入 ATCF（Access Transfer Control Function） 作为信令锚点、ATGW（Access Transfer Gateway） 作为媒体锚点。这样域转移时，MSC Server 只需把 INVITE 送到本地 ATCF，ATCF 直接控制 ATGW 切换媒体腿，无需跨归属网往返，从而把切换时延压到 300ms 以内。

设计意图一句话总结：SRVCC 解决"能不能转移"，eSRVCC 解决"转移够不够快"。锚点位置从归属网下移到服务网，是 eSRVCC 的全部精髓。

二、eSRVCC 架构与锚点拓扑

eSRVCC 在 IMS Service Continuity 架构（TS 23.237 §5）基础上新增 ATCF/ATGW，形成"双层锚点"：服务网络的 ATCF/ATGW + 归属网络的 SCC AS。

flowchart TD
    UE["UE(单射频)"] -->|"VoLTE/VoNR 通话中"| eNB["源 eNB / gNB"]
    eNB --> MME["源 MME / AMF"]
    MME -->|"Sv 接口 (GTPv2)"| MSC["增强型 MSC Server"]
    MSC -->|"CS 域信令/媒体"| BSS["目标 BSS / RNS<br/>(CS小区)"]
    MSC -.->|"① INVITE<br/>Session Transfer<br/>(Req-URI = STN-SR)"| ATCF
    subgraph SV["服务网络锚点 (本地/快速)"]
      ATCF["ATCF<br/>信令锚点"] --- ATGW["ATGW<br/>媒体锚点"]
    end
    ATCF -->|"② 更新接入腿"| SCSCF["S-CSCF"]
    SCSCF --> SCC["SCC AS<br/>归属锚点"]
    ATGW -->|"RTP 通话媒体"| REMOTE["远端对端 / MGW"]
    classDef anchor fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px;
    class ATCF,ATGW,SCC anchor;

图中三个锚点的分工是理解后续信令的前提：

• ATGW（媒体锚点）：从主叫/被叫会话建立阶段就被插入到媒体路径中。域转移时，ATGW 只需把"朝向源 PS 接入腿"的 RTP 流切换到"朝向 CS/MGW 的新腿"，远端媒体完全不动——这是时延可控的根本原因。
• ATCF（信令锚点）：位于 REGISTER 信令路径上，登记并维护当前活跃会话的上下文。收到 MSC 的 Session Transfer INVITE 后，用它本地保存的会话信息关联到正在进行的会话。
• SCC AS（归属锚点）：通过 S-CSCF 第三方注册（3rd-Party REGISTER）锚定所有会话，承载业务集中化（如前转、保持、会议）并执行 Domain Transfer 逻辑；eSRVCC 中它仍被告知新接入腿，但不再是性能关键路径。

三、准备阶段：注册时如何把 ATCF 钉进信令路径

eSRVCC 不是"切换那一刻"才开始工作的。它依赖一次提前埋锚点的注册过程。ATCF 必须在 UE 的 IMS 注册信令路径上，否则切换时无锚可转。这段流程在 TS 23.237 §5 与 TS 23.216 §5.2 中定义。

sequenceDiagram
    autonumber
    participant UE
    participant PCSCF as P-CSCF
    participant ATCF
    participant SCSCF as S-CSCF
    participant HSS
    participant SCC as SCC AS

    UE->>PCSCF: REGISTER (初始/重注册)
    PCSCF->>ATCF: REGISTER (ATCF 位于信令路径)
    ATCF->>SCSCF: REGISTER
    SCSCF->>HSS: Cx: SAR/UAR (取用户数据)
    HSS-->>SCSCF: 用户数据 (含 STN-SR 占位/能力)
    SCSCF->>SCC: 第三方 REGISTER (iFC 触发 SCC AS)
    Note over SCC,ATCF: SCC AS 下发 STN-SR 给 ATCF,<br/>ATCF 保存并分配本次注册的 STN-SR
    SCC-->>SCSCF: 200 OK (回带 ATCF 的 STN-SR)
    SCSCF-->>ATCF: 200 OK
    ATCF-->>PCSCF: 200 OK
    PCSCF-->>UE: 200 OK (注册成功)
    Note over ATCF,SCC: 此后每次会话建立,ATCF 强制 ATGW 锚定媒体

关键设计点：

1. STN-SR（Session Transfer Number for SRVCC）的归属变化。在基础 SRVCC 中，STN-SR 是存于 HSS 的一个 E.164 号码，指向 SCC AS；在 eSRVCC 中，STN-SR 被动态指派为指向 ATCF。SCC AS 在第三方注册时把这个动态 STN-SR 回送给 S-CSCF，后续写回 HSS（TS 23.237 §5.3.2a 的 C-MSISDN/STN-SR 更新流程）。这样切换时 MSC 用 STN-SR 路由，第一跳就到本地 ATCF。
2. C-MSISDN：ATCF/SCC AS 用 C-MSISDN 关联用户，与 CS 域的 MSISDN 对齐，是跨域关联的"主键"。
3. 会话级锚定：注册只钉了信令锚点；真正保证媒体快速切换的是"每次会话都让 ATGW 锚进媒体路径"。ATCF 通过在 INVITE/183 的 SDP 协商中插入 ATGW 来实现。

排错提示：如果抓包看到切换走了基础 SRVCC 路径（INVITE 直送 SCC AS 而非 ATCF），第一个怀疑点就是注册阶段 ATCF 没有成功进入信令路径或 STN-SR 没有被更新为 ATCF 的号码。常见根因是 P-CSCF/IBCF 的 DNS/路由配置未把 ATCF 插入 REGISTER 路径，或 SCC AS 的 eSRVCC 能力开关未启用。

四、eSRVCC 完整信令时序（TS 23.216 §6.2.2）

下面是 eSRVCC PS→CS 的核心信令流程。它同时跨越无线（HO准备）、PS核心网（MME/Sv）、CS核心网（MSC/CS资源）、IMS域（ATCF/SCC AS）四个平面，是理解整个机制的灵魂。

sequenceDiagram
    autonumber
    participant UE
    participant eNB as 源 eNB
    participant MME as 源 MME
    participant MSC as 增强型 MSC Server
    participant BSS as 目标 CS (BSS/RNS)
    participant ATCF
    participant SCC as SCC AS
    participant REMOTE as 远端 UE/对端

    Note over UE,REMOTE: 通话进行中,UE 移向 CS-only 覆盖区
    eNB->>MME: HO Required (SRVCC HO 触发)
    MME->>MSC: Sv: SRVCC PS to CS Request<br/>(STN-SR, C-MSISDN, IMSI,<br/>MM Context, Target ID)
    MSC->>BSS: Prepare HO / Relocation (CS 资源准备)
    BSS-->>MSC: Prepare HO Response (资源就绪)
    MSC->>ATCF: INVITE (Session Transfer)<br/>Req-URI = STN-SR, From = C-MSISDN
    Note over ATCF: 关联已锚定会话,<br/>指示 ATGW 切媒体腿到 CS 侧
    ATCF->>SCC: 更新接入腿 (UPDATE / re-INVITE)
    SCC->>REMOTE: (远端腿通常无需改)
    SCC-->>ATCF: 200 OK
    ATCF-->>MSC: 200 OK (SDP = CS 媒体描述)
    MSC-->>MME: Sv: SRVCC PS to CS Response (含HO信息)
    MME->>eNB: HO Command
    eNB->>UE: HO Command (切到 CS 小区)
    UE->>BSS: 切换并接入 CS 小区
    Note over UE,BSS: CS 切换完成,语音在 CS 域延续
    MME->>MSC: Forward Relocation Complete Notif.
    ATCF->>SCC: 释放原 PS 接入腿 (BYE)
    Note over MME,BSS: 非 voice 的 PS 承载:<br/>转发到目标 SGSN 或挂起/释放

逐步解析关键步骤与 IE：

步骤②（HO Required）：源 eNB（或 gNB）依据测量报告判定 UE 将进入无 PS 语音、仅有 CS 的覆盖区，向 MME 上报 HO Required，并携带 SRVCC HO Indication，告诉核心网"这次切换是 PS→CS 的 SRVCC 类型"。MME 据此区分普通 PS 切换与 SRVCC。

步骤③（Sv: SRVCC PS to CS Request，TS 29.280 §5.2.2）：这是跨平面最关键的一条消息。MME 选定一个 SRVCC 增强型 MSC Server，通过 Sv 接口（基于 GTPv2）发送请求。MSC 靠这条消息同时拿到"去哪建 CS 资源"和"如何把会话转移回 IMS"所需的全部信息。

步骤④-⑤（CS 资源准备）：MSC 在目标 CS 侧执行 Relocation/HO 准备，为目标 UE 分配 CS 无线与传输资源。如果 MSC 与目标 BSS/RNS 之间还需经目标 MSC 中转，会有相应 MAP/Relocation 流程。

步骤⑥（Session Transfer INVITE）：MSC Server 以 STN-SR 作为 Request-URI、C-MSISDN 作为 From/关联字段，向 IMS 发起 INVITE。这是"把 CS 腿接到已锚定会话"的触发点。在 eSRVCC 中，STN-SR 指向 ATCF，所以 INVITE 第一站就是本地 ATCF；基础 SRVCC 则直达 SCC AS。

步骤⑦（ATCF 本地域转移）：ATCF 用 C-MSISDN/会话标识关联到当前锚定的活跃会话，指示 ATGW 把媒体腿从原 PS 接入侧切换到新的 CS 侧（朝向 MSC/MGW）。由于 ATGW 本就锚在媒体路径上，远端媒体流无需改动，这就是 eSRVCC 的提速核心。

步骤⑧-⑩（SCC AS 域转移更新）：ATCF 向 SCC AS 发 UPDATE/re-INVITE 告知"接入腿已换成 CS 腿"。SCC AS 执行 Domain Transfer 逻辑——更新会话状态、维护业务连续性（如保持的会议、前转状态），并在必要时更新远端腿（多数情况下远端媒体不变）。SCC AS 回 200 OK。

步骤⑪-⑭（切换执行）：MSC 回 PS to CS Response 给 MME，MME 经 eNB 下发 HO Command，UE 切到 CS 小区。此后语音在 CS 域延续。

步骤⑯（释放原 PS 接入腿）：ATCF/SCC AS 触发对原 PS 会话接入腿的 BYE，清理 PS 侧资源。非语音的 PS 承载（如数据业务）按 TS 23.216 §5.3.3a 处理：若目标支持 PS HO 则转发到目标 SGSN，否则挂起或释放。

五、Sv 接口 SRVCC PS to CS Request 关键 IE 拆解（TS 29.280）

Sv 接口是 PS 域与 CS 域之间的"翻译层"，消息里每一个 IE 都承担明确的跨域职责。下表逐项说明：

设计巧思：MM Context 把 CS 域的安全上下文随路带给 MSC，使 MSC 不必让 UE 走完整的 CS 附着流程就能完成鉴权并切入 CS 小区——这是 SRVCC 能在极短时间内完成 CS 接入的关键之一。

六、SCC AS 的 Domain Transfer：会话腿如何"换骨不换皮"

TS 23.237 把 eSRVCC 的核心抽象为 Access Transfer / Domain Transfer：把一个会话的"接入腿（Access Leg）"从 PS 域换成 CS 域，而"远端腿（Remote Leg）"保持不变。SCC AS 维护的三方会话模型如下：

flowchart LR
    subgraph 切换前
      A1["PS 接入腿<br/>(UE-eNB-ATGW)"] --> SCC1["SCC AS"]
      SCC1 --> R1["远端腿<br/>(对端)"]
    end
    subgraph 切换后
      A2["CS 接入腿<br/>(UE-BSS-MSC-MGW-ATGW)"] --> SCC2["SCC AS"]
      SCC2 --> R2["远端腿<br/>(对端,不变)"]
    end
    A1 -.->|"Domain Transfer"| A2

Domain Transfer 的关键判定（TS 23.237 §6.2）：

1. 关联（Correlation）：SCC AS/ATCF 用 C-MSISDN + STN-SR 把新到达的 CS 腿与现有锚定会话对应起来。
2. 远端腿更新策略：eSRVCC 下媒体锚在 ATGW，远端腿通常不需要发 re-INVITE/UPDATE（媒体描述不变），进一步省时；基础 SRVCC 因媒体回源，往往需要对远端发更新。
3. 原接入腿释放：完成切换后必须释放原 PS 接入腿，避免"两腿并存"导致的媒体回环或计费重复。
4. mid-call / alerting 场景：Rel-11 的 mid-call 与 aSRVCC（alerting 阶段）扩展，使通话处于保持、多方、或振铃阶段时也能转移，SCC AS 在这些场景需额外维护会话状态机。

七、SRVCC vs eSRVCC 对比

八、实战连接：抓包识别与故障排查

抓包如何识别一条 eSRVCC

1. Sv 接口（GTPv2）：过滤 gtpv2 message type == SRVCC PS to CS Request（消息类型值见 TS 29.280 §7），看 STN-SR/C-MSISDN/Target ID 是否齐全。
2. SIP 接口（Mg/Mw）：寻找一条 Request-URI 为 STN-SR 号码、From 为 C-MSISDN 的 INVITE——这就是 Session Transfer INVITE；它的下一跳是 ATCF（eSRVCC）还是直奔 SCC AS（基础 SRVCC）一目了然。
3. 媒体面：观察切换时刻 RTP 流的 目的 IP 是否从源 PS 承载侧改为 CS/MGW 侧，且源 IP（ATGW）保持不变——这是 ATGW 媒体锚定的指纹。

常见故障点

• 故障 A：切换回退为基础 SRVCC，时延过大。根因：注册阶段 ATCF 未进信令路径，或 STN-SR 未更新为 ATCF 号码。排查 iFC、SCC AS 能力标签（如 g.3gpp.atcf-path 特征标签）、HSS 中 STN-SR 取值。
• 故障 B：Session Transfer INVITE 发出但 200 OK 迟迟不回。根因：ATCF/SCC AS 关联失败（C-MSISDN 不匹配、锚定会话已超时释放），或 ATGW 媒体腿切换失败。检查关联主键与 ATGW 状态。
• 故障 C：切换成功但出现短暂单通/双通。根因：原 PS 接入腿未及时 BYE，导致双腿并存；或 Domain Transfer 时序与无线 HO 执行错位。
• 故障 D：MSC 拒绝 PS to CS Request。根因：MM Context 缺失/损坏、Target ID 无效、或目标侧 CS 资源不足。
• 故障 E：非语音 PS 承载丢失。根因：目标侧不支持 PS HO，数据承载被挂起或释放（属预期但需评估业务影响）。

九、演进：5G-SRVCC 与 vSRVCC

• 5G-SRVCC（Rel-16+）：把语音连续性从 NR（VoNR）延伸到 UTRAN/GERAN CS，AMF 承担类似 MME 的角色，经类似 Sv 的接口触发增强 MSC Server，IMS 侧仍由 SCC AS/ATCF 完成 Domain Transfer。在 2026 年的语境下，由于大量运营商已退网 3G，5G-SRVCC 的目标更多指向残存的 GERAN。
• vSRVCC：支持视频+语音的逆向/双向连续性，会话转移时需同时协商视频媒体，ATGW 需具备视频媒体处理能力。
• mid-call / aSRVCC（Rel-11）：扩展到通话保持、多方、以及振铃/预振铃阶段的转移，SCC AS 状态机更复杂。

常见问题

Q1：eSRVCC 与基础 SRVCC 最本质的区别是什么？ A：锚点位置。基础 SRVCC 的会话转移锚点在归属网 SCC AS，切换要跨网往返；eSRVCC 把信令锚点（ATCF）和媒体锚点（ATGW）下移到服务网络，域转移本地完成，时延从 >300ms 压到 <300ms。STN-SR 也因此从指向 SCC AS 变为指向 ATCF。

Q2：为什么需要 MM Context 这条 IE？ A：它把 CS 域的鉴权矢量与安全上下文随路带给 MSC Server，使 MSC 无需让 UE 走完整 CS 附着就能完成鉴权并切入 CS 小区。这是 CS 接入能极快完成的关键，缺失则 MSC 无法鉴权，切换失败。

Q3：ATGW 媒体锚定是如何在会话建立时就插入的？ A：在主叫/被叫会话的 INVITE/183 SDP 协商阶段，ATCF 指示 ATGW 介入媒体路径（替换 SDP 中的连接信息）。一旦锚定，后续域转移时 ATGW 只需改"朝向接入侧"的 RTP 目的地址，远端媒体不动，这是提速的根本。

Q4：eSRVCC 是否要求 UE 支持双射频？ A：不需要。SRVCC/eSRVCC 正是为单射频（Single Radio）UE 设计的——UE 同一时刻只驻留一个接入，切换时先断 PS 再接 CS。双射频终端走的是更宽松的"双待"连续性，不依赖本机制。

Q5：切换后非语音的数据业务会怎样？ A：按 TS 23.216 §5.3.3a 处理：若目标 CS 区域有 PS 能力且支持 PS HO，非语音 PS 承载转发到目标 SGSN；否则挂起或释放。这是为什么 eSRVCC 后用户可能感觉到数据中断但语音不断的原因。

参考来源

1. 3GPP TS 23.216 — Voice Call Continuity (VCC) / SRVCC architecture — §6.2.2 eSRVCC PS→CS 流程、§5.3.3a 非语音承载处理
2. 3GPP TS 29.280 — Sv interface (3GPP), SRVCC PS to CS Request — §5.2.2 消息定义与 IE
3. 3GPP TS 23.237 — IMS Service Continuity — §5 架构与参考点、§6.2 Domain Transfer
4. 3gpp-explorer — ATCF (Access Transfer Control Function) — ATCF/ATGW/SCC AS 角色释义
5. 腾讯云开发者社区 — VoLTE信令系列: SRVCC/eSRVCC 切换流程详解 — 中文流程分步图解

本文由「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 等场景全覆盖。