# 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。
```mermaid
flowchart TD
UE["UE(单射频)"] -->|"VoLTE/VoNR 通话中"| eNB["源 eNB / gNB"]
eNB --> MME["源 MME / AMF"]
MME -->|"Sv 接口 (GTPv2)"| MSC["增强型 MSC Server"]
MSC -->|"CS 域信令/媒体"| BSS["目标 BSS / RNS
(CS小区)"]
MSC -.->|"① INVITE
Session Transfer
(Req-URI = STN-SR)"| ATCF
subgraph SV["服务网络锚点 (本地/快速)"]
ATCF["ATCF
信令锚点"] --- ATGW["ATGW
媒体锚点"]
end
ATCF -->|"② 更新接入腿"| SCSCF["S-CSCF"]
SCSCF --> SCC["SCC AS
归属锚点"]
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 中定义。
```mermaid
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,
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）四个平面，是理解整个机制的灵魂。
```mermaid
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
(STN-SR, C-MSISDN, IMSI,
MM Context, Target ID)
MSC->>BSS: Prepare HO / Relocation (CS 资源准备)
BSS-->>MSC: Prepare HO Response (资源就绪)
MSC->>ATCF: INVITE (Session Transfer)
Req-URI = STN-SR, From = C-MSISDN
Note over ATCF: 关联已锚定会话,
指示 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 承载:
转发到目标 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 都承担明确的跨域职责。下表逐项说明：
| IE 名称 | 必选(M)/可选(O) | 作用说明 | 缺失/异常影响 |
|---|---|---|---|
| **STN-SR** | M | 会话转移号码，路由到 ATCF/SCC AS | 无则 MSC 无法发起 Session Transfer，切换失败 |
| **MSISDN (C-MSISDN)** | M | 跨域关联用户的 MSISDN | ATCF/SCC AS 无法关联已锚定会话 |
| **IMSI** | M | 用户永久标识 | CS 鉴权/计费无主键 |
| **Target ID** | M | 目标 CS 小区（RNC ID / CGI / SAI / Target BSS ID） | MSC 不知在哪建 CS 资源 |
| **MM Context** | M | CS 域鉴权矢量与安全上下文 | MSC 无法在 CS 侧快速鉴权 UE |
| **MME/SGSN Number** | M | 源节点地址，用于响应回送 | Response 无目的地 |
| **SRVCC Indication** | M | 标识本次为 SRVCC 过程 | 被当作普通 PS HO 处理 |
| **Session Restart Indicator** | O | SCC AS/ATCF 重启场景指示 | 重启后锚点丢失，需特殊处理 |
| **CS-to-PS SRVCC Indication** | O | 反向（CS→PS）场景标识 | 仅 vSRVCC/反向场景 |
> **设计巧思**：`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 维护的三方会话模型如下：
```mermaid
flowchart LR
subgraph 切换前
A1["PS 接入腿
(UE-eNB-ATGW)"] --> SCC1["SCC AS"]
SCC1 --> R1["远端腿
(对端)"]
end
subgraph 切换后
A2["CS 接入腿
(UE-BSS-MSC-MGW-ATGW)"] --> SCC2["SCC AS"]
SCC2 --> R2["远端腿
(对端,不变)"]
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 对比
| 维度 | 基础 SRVCC | eSRVCC（Enhanced） |
|---|---|---|
| **标准引入** | Rel-8/9（TS 23.216） | Rel-10（TS 23.216/23.237 扩展） |
| **信令锚点** | 归属 SCC AS | 服务网络 ATCF |
| **媒体锚点** | 无本地锚点，回源 SCC AS 侧 | ATGW 本地锚定 |
| **STN-SR 指向** | SCC AS（HSS 静态） | ATCF（注册时动态指派） |
| **Session Transfer 路径** | 跨归属网往返 | 本地 ATCF 处理 |
| **典型切换时延** | >300ms，可能有语音中断 | <300ms，满足 ITU-T P.1011 |
| **漫游场景表现** | 差（跨拜访-归属往返） | 好（本地完成） |
| **适用** | 早期 VoLTE | 现代 VoLTE/VoNR 主流 |
---
## 八、实战连接：抓包识别与故障排查
### 抓包如何识别一条 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](https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=816) — §6.2.2 eSRVCC PS→CS 流程、§5.3.3a 非语音承载处理
2. [3GPP TS 29.280 — Sv interface (3GPP), SRVCC PS to CS Request](https://itecspec.com/3gpp/29.280/s/5.2.2) — §5.2.2 消息定义与 IE
3. [3GPP TS 23.237 — IMS Service Continuity](https://itecspec.com/spec/3gpp-23-237-5-architecture-model-and-reference-points/) — §5 架构与参考点、§6.2 Domain Transfer
4. [3gpp-explorer — ATCF (Access Transfer Control Function)](https://3gpp-explorer.com/glossary/atcf/) — ATCF/ATGW/SCC AS 角色释义
5. [腾讯云开发者社区 — VoLTE信令系列: SRVCC/eSRVCC 切换流程详解](https://cloud.tencent.com/developer/article/1500076) — 中文流程分步图解
---
> 本文由「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 等场景全覆盖。
