eSRVCC 语音连续性信令全链拆解：从 Sv 接口到 ATCF 会话转移

一、为什么需要 eSRVCC：基础 SRVCC 的时延瓶颈

VoLTE 商用初期，运营商面临一个致命的体验问题：当终端在通话过程中从 LTE 覆盖区移动到仅有 2G/3G CS 覆盖的边缘地带时，IP 语音会话需要无缝迁移到电路域承载，否则通话中断。3GPP 在 Rel‑8 引入的 基础 SRVCC（Single Radio Voice Call Continuity） 解决了"如何切"的问题，但留下了一个性能痛点——语音中断时间过长。

基础 SRVCC 的会话转移（Session Transfer）必须一路路由回归属网络的 SCC AS（Service Centralization and Continuity Application Server）。MSC Server 收到 Sv 消息后，构造一个 SIP INVITE，其请求 URI 为从 HSS 取回的 STN‑SR，该号码指向归属网的 SCC AS。当用户处于漫游场景或归属网远端时，这段 IMS 信令往返会显著拉长切换时延，实测往往接近甚至超过 500ms，无法满足运营商对"用户无感知切换"的严苛诉求。

为此，3GPP 在 Rel‑10 通过 TS 23.216 clause 5.3、TS 23.237 clause 6.3 定义了 eSRVCC（Enhanced SRVCC）：在拜访/服务网络引入 ATCF（Access Transfer Control Function） 与 ATGW（Access Transfer Gateway） 作为会话与媒体锚点，把会话转移信令"就近终结"，将语音中断时间压到 300ms 以内。本文聚焦 eSRVCC 这一条具体机制，完整拆解从空口测量到 ATCF 会话转移的全链路信令。

二、eSRVCC 架构与关键网元

eSRVCC 在基础 SRVCC 架构之上新增两个功能实体，二者改变了会话锚点的位置：

• ATCF：信令锚点。通常与拜访网络的 I‑CSCF、P‑CSCF 或 MGCF 共部署，作为 B2BUA（背靠背用户代理）插入到 SIP 信令路径中。它在 UE IMS 注册阶段即插入到 access leg（UE 到 ATCF 的会话腿），并分配指向自己的 eSTN‑SR。
• ATGW：媒体锚点。通常与 IMS‑AGW 或 SBC 共部署，由 ATCF 通过 H.248/Megaco 控制，承载语音 RTP 媒体的转接与切换。
• SCC AS：业务集中与连续性应用服务器。在 eSRVCC 中退化为"业务控制锚点"——只负责补充业务（如呼叫保持、多方通话）的连续性，不再承担会话转移路由职责。
• MSC Server（增强型）：充当跨域协调者，一侧通过 Sv（TS 29.280，GTPv2‑C）与 MME 交互，另一侧作为 SIP UA 向 ATCF 发起会话转移 INVITE。

flowchart TD
    UE[UE/VoLTE终端] -->|RRC/NAS| eNB[eNodeB]
    eNB -->|S1-AP HO Required\nSRVCC指示| MME[MME]
    MME -->|Sv PS-to-CS Request\nIMSI,STN-SR,C-MSISDN| MSS[MSC Server\n增强型]
    MSS -->|SIP INVITE\nto eSTN-SR| ATCF[ATCF\n信令锚点]
    ATCF -->|H.248控制| ATGW[ATGW\n媒体锚点]
    ATCF -->|S-CSCF| SCCAS[SCC AS\n业务控制]
    ATGW -.RTP媒体.-> 远端[远端UE/MGCF]
    MSS -->|CS切换准备| BSS[目标BSS/RNS\n2G/3G]
    HSS[(HSS)] -.订阅数据\nSTN-SR,C-MSISDN.-> MME

三、核心信息元素：STN‑SR 的演进与注册期锚定

eSRVCC 的"快"，根植于一个看似微小的设计：STN‑SR 在注册阶段就被改造成指向 ATCF 的本地号码。

STN‑SR（Session Transfer Number for SRVCC）是一个可路由的 E.164 号码。在基础 SRVCC 中，它由 SCC AS 在 HSS 中登记，指向归属网 SCC AS。eSRVCC 的改造机制如下：

1. UE 完成主注册（first‑party REGISTER）后，S‑CSCF 触发第三方注册（third‑party REGISTER）到 ATCF（通过 iFC 触发，iFC 中指向 ATCF 的 AS）。
2. ATCF 收到第三方注册后，判断是否需要为自己分配 eSTN‑SR。若分配，ATCF 生成一个指向自己的 routable number。
3. ATCF 通过 S‑CSCF → I‑CSCF → Cx（Cx‑Put/Cx‑Update）将新的 STN‑R 写入 HSS 的用户订阅数据。
4. MME 在 UE 附着/更新时，通过 S6a（Update Location Answer）从 HSS 取回 STN‑SR 与 C‑MSISDN（用于 CS 域关联）。

此外，SIP 第三方注册消息中携带 g.3gpp.atcf 与 g.3gpp.atcf‑mgmt‑uri 等 P‑Associated‑URI 相关扩展：前者就是 ATCF 分配的 STN‑SR，后者是 ATCF 的管理 URI，便于 SCC AS 后续识别 access transfer 事件。

四、完整信令时序图：从测量报告到 CS 接管

下图给出 eSRVCC 从 E‑UTRAN 到 GERAN/UTRAN 的完整信令时序（对应 TS 23.216 clause 5.2.2.2 与 TS 24.237 clause 5 的会话转移流程）：

sequenceDiagram
    autonumber
    participant UE
    participant eNB as eNodeB
    participant MME
    participant MSS as MSC Server
    participant ATCF
    participant ATGW
    participant SCC as SCC AS
    participant BSS as 目标BSS/RNS

    UE->>eNB: Measurement Report(邻区2G/3G信号)
    eNB->>MME: S1-AP: HO Required(SRVCC-HO指示,Target ID)
    Note over MME: 拆分承载:语音承载→CS,数据承载→PS HO
    MME->>MSS: Sv: PS-to-CS Request(IMSI,STN-SR,C-MSISDN,MM Context,Source2Target容器)
    par CS域资源准备
        MSS->>BSS: Relocation/Handover Resource Allocation
        BSS-->>MSS: 资源就绪
    and IMS会话转移(关键路径)
        MSS->>ATCF: SIP INVITE(Request-URI=eSTN-SR,SDP=CS媒体)
        ATCF->>ATGW: H.248:修改终端(媒体锚定到CS侧)
        ATCF->>SCC: UPDATE/INVITE(通知access transfer,SDP不变)
        SCC-->>ATCF: 200 OK
        ATCF-->>MSS: SIP 200 OK(Contact=MGW媒体地址)
    end
    MSS-->>MME: Sv: PS-to-CS Response(CS HO Command)
    MME-->>eNB: S1-AP: HO Command(MobilityControlInfo)
    eNB-->>UE: RRC: MobilityFromEUTRACommand
    UE->>BSS: 切换到2G/3G CS小区,建立无线承载
    BSS-->>MSS: HO Detect/Complete
    MSS-->>MME: Sv: PS-to-CS Complete Notification
    Note over UE: 用户感知语音中断<300ms
    MSS->>MSS: CS呼叫激活,释放原PS语音承载

五、关键信令消息逐步解析

1. S1‑AP Handover Required（TS 36.413 clause 8.7）

eNodeB 通过测量报告判断需要切换到 2G/3G，向 MME 发送 HANDOVER REQUIRED。决定性 IE 是 SRVCC‑HO‑Indication（取值 ps‑and‑cs 或 cs），它告诉 MME"这是一次 SRVCC 切换，请走 PS‑to‑CS 流程"。同时携带 Source‑to‑Target Transparent Container、目标 Target ID（CGI/SAI 或 RNC ID）。如果该 IE 缺失或取值为 cs‑only 而 UE 不支持，MME 会按普通 PS HO 处理，语音承载不会被转移。

2. MME 承载拆分与 Sv PS‑to‑CS Request（TS 29.280 clause 7.2）

这是 eSRVCC 跨域协调的起点。MME 做两件事：

第一，承载拆分。MME 遍历该 UE 的所有 EPS 承载，将 QCI=1（会话语音）等标记为 SRVCC 承载的 GBR 语音承载，纳入 PS‑to‑CS 流程；非 SRVCC 承载（如数据承载）若目标 RAT 支持则走 PS HO，否则挂起。

第二，向 MSC Server 发送 SRVCC PS‑to‑CS Request（GTPv2‑C 消息）。其关键 IE 如下表：

3. MSC Server 并行操作：CS 资源准备 + 会话转移

MSS 收到 Sv 请求后，并行执行两条路径（这是时延优化的关键）：

• CS 域资源准备：向目标 BSS/RNS 发起资源分配（GERAN 走 BSSMAP Handover Resource Allocation，UTRAN 走 RANAP Relocation Resource Allocation）。
• IMS 会话转移：MSS 构造 SIP INVITE，Request‑URI 设为 STN‑SR（即 eSTN‑SR，路由到 ATCF），From/To 用 C‑MSISDN，SDP offer 描述 CS 侧媒体编解码（如 AMR）与 MGW 的 IP 端口。

4. ATCF 会话转移处理（TS 24.237 clause 5、TS 23.237 clause 6.3）

这是 eSRVCC 与基础 SRVCC 的根本区别点。 ATCF 收到 INVITE 后识别出这是一次 access transfer（因为 URI 指向自己且匹配已注册的 access leg），遂：

1. 作为 B2BUA，将新的 CS 侧 access leg 与原 remote leg 关联。
2. 通过 H.248 命令修改 ATGW 的终端，将媒体锚点从 LTE 侧 PGW 切换到 CS 侧 MGW——但远端媒体路径不变，远端用户无感知。
3. 向 SCC AS 发送 UPDATE 或 re‑INVITE，仅通知"接入域已转移"，触发补充业务的连续性处理（如更新业务触发点）。
4. 回复 MSS 200 OK，Contact 为 ATGW 的媒体地址。

由于 ATCF 就在拜访网络，这段信令不再跨大区回溯到归属 SCC AS，路径缩短带来的就是时延下降。

5. 切换命令下发与 CS 接管

MSS 向 MME 回 SRVCC PS‑to‑CS Response（携带 CS 侧 HO Command 透明容器），MME 经 S1‑AP HO Command、RRC MobilityFromEUTRACommand（TS 24.301）下发到 UE。UE 切换到 2G/3G 小区，BSS/RNS 上报 HO Complete，MSS 通过 Sv PS‑to‑CS Complete Notification 通知 MME，MME 随后释放原 LTE 语音承载（数据承载按 PS HO 结果处理）。此时 CS 呼叫已激活，用户侧仅感知到极短的语音中断。

六、状态转换与会话锚点迁移

stateDiagram-v2
    [*] --> VoLTE激活: VoIP语音承载(QCI=1)建立
    VoLTE激活 --> 切换决策: 邻区CS信号优于LTE
    切换决策 --> 承载拆分: MME识别SRVCC承载
    承载拆分 --> 会话转移中: Sv PS-to-CS Request
    会话转移中 --> ATCF锚定: INVITE路由到ATCF
    ATCF锚定 --> 媒体迁移: ATGW切换媒体锚点
    媒体迁移 --> CS接管: 200 OK + HO Command
    CS接管 --> VoCS激活: BSS HO Complete
    VoCS激活 --> [*]: 通话正常结束
    note right of ATCF锚定
      基础SRVCC:锚点=归属SCC AS
      eSRVCC:锚点=本地ATCF(路径短)
    end note

七、抓包识别与实战排错

抓包识别要点

实战识别技巧：在 Sv 接口抓到 PS‑to‑CS Request 后，立即去 IMS 侧（Mw/Mg）找紧随其后、From 为 C‑MSISDN 的 INVITE——若其下一跳落在本网 ATCF（而非跨域到归属 SCC AS），即可判定为 eSRVCC。

常见故障点

1. STN‑SR 未更新为 eSTN‑SR：ATCF 未正确写入 HSS，或 MME 缓存了旧值。表现：会话转移 INVITE 路由到归属 SCC AS，时延劣化（基础 SRVCC 行为）。排查：核对 HSS 订阅数据与 MME 上下文中的 STN‑SR。
2. iFC 未配置 ATCF 第三方注册触发：注册期 ATCF 未被激活，access leg 缺少 ATCF 锚点。表现：eSRVCC 退化为基础 SRVCC。
3. 承载未标记 SRVCC：语音承载 QCI=1 但 MME 未识别为 SRVCC 承载，导致切换时语音被当数据承载处理而中断。排查：检查 MME 的 SRVCC 承载映射表与签约 SRVCC 标志。
4. 媒体锚点未同步迁移：ATCF 收到 INVITE 但 ATGW 的 H.248 修改失败，导致单通（媒体仍走旧 PGW 路径）。排查：抓 H.248（Mc 接口）与 RTP，比对 RTP 流方向是否切换。
5. 密钥派生失败：MM Context 中 Kc 未正确派生，CS 域鉴权失败，HO 后掉话。排查：对照 TS 33.401 检查 K'asme→Kc 派生与 MSS 侧校验。

八、eSRVCC 与基础 SRVCC 对比

九、从 eSRVCC 到 5G 语音连续性

值得指出的是，eSRVCC 的"就近锚点 + 媒体本地化"思想在 5G 时代被进一步延伸。当 VoNR 终端从 5GS 回落至 EPS 时（EPS Fallback 已建立 VoLTE），后续若继续向 CS 域切换，依然复用 eSRVCC 机制；而 5GS 内的 RAT 间语音连续性（5G‑to‑EPS handover for voice）则借鉴了 ATCF 思路，通过 SCC AS/IMS 锚定实现。理解 eSRVCC 的 ATCF 锚点模型，是理解后续 Voice Call Continuity 演进的钥匙。

常见问题

Q1：eSRVCC 和基础 SRVCC 在 Sv 接口消息上有什么区别？ A：Sv 接口消息本身（PS‑to‑CS Request/Response）结构基本一致，差异在于 STN‑SR 的取值与 SRVCC Indication 中是否携带 eSRVCC/ATCF 锚定能力。本质区别发生在 IMS 侧：INVITE 的路由目标（SCC AS vs ATCF）不同。

Q2：为什么 eSRVCC 必须在注册阶段就插入 ATCF？ A：因为会话转移发生时，切换窗口只有几百毫秒，来不及临时建立 ATCF 锚定。注册期通过第三方注册把 ATCF 固化到 access leg 并分配 eSTN‑SR，才能保证切换瞬间 INVITE 就能就近命中 ATCF。

Q3：eSRVCC 切换后，数据业务会怎样？ A：MME 会做承载拆分。语音承载走 PS‑to‑CS 转移；数据承载若目标 RAT（如 UTRAN HSPA）支持，则并行做 PS HO 维持数据连接；若目标为仅 CS 的 GERAN，数据承载被挂起或去激活。

Q4：媒体锚点（ATGW）切换会不会导致短暂单通？ A：会有极短媒体路径切换中断，但因 ATGW 就近部署，远端 RTP 路径不变，仅本地段切换，中断时间通常被控制在数十毫秒级，叠加切换总中断 <300ms，用户基本无感。

Q5：eSRVCC 失败如何回退？ A：若 Sv 阶段或会话转移失败，MSS 回 PS‑to‑CS Response 带失败原因，MME 可选择中止切换、保持 LTE 语音（短暂维持，待覆盖恢复）或降级为普通 PS HO（语音可能中断）。运营商可配置回退策略。

参考来源

1. 3GPP TS 23.216 — Single Radio Voice Call Continuity (SRVCC); Stage 2 — clause 5.2.2.2（E‑UTRAN 到 GERAN/UTRAN SRVCC 流程）、clause 5.3（eSRVCC 过程）
2. 3GPP TS 24.237 — IP Multimedia Subsystem (IMS) Service Continuity; Stage 3 — clause 5 信令流程、ATCF 会话转移 SIP 消息定义
3. 3GPP TS 29.280 — Sv interface (MME to MSC Server) for SRVCC — clause 7 消息、clause 8 信息元素（PS‑to‑CS Request/Response）
4. 3GPP TS 23.237 — IMS Service Continuity; Stage 2 — clause 6.3 ATCF 功能描述
5. Oracle Help Center — SRVCC PS‑CS Access Transfer（ATCF/STN‑SR 处理） 与 博客园·VoLTE 中 eSRVCC 相关知识点 — g.3gpp.atcf 扩展与 STN‑SR 实战解读

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