eSRVCC语音连续性信令全链拆解：从注册锚定到接入域转移

一、为什么需要eSRVCC：单射频终端的语音域转移难题

VoLTE/VoNR建立在IMS分组域之上，语音承载是PS bearer。但现实网络中，LTE/NR覆盖并不能100%连续，尤其是室内、郊区、高速移动场景下，终端会回落到仅有2G/3G电路域（CS）覆盖的区域。此时终端（UE）只有一个射频（Single Radio），无法同时驻留PS和CS——通话要么断，要么把IMS会话"搬运"到CS域。SRVCC（Single Radio Voice Call Continuity）就是为解决这一问题而设计的接入域转移（Access Transfer）机制，由 3GPP TS 23.216 在R8阶段定义。

但R8/R9的原始SRVCC存在致命缺陷：会话转移信令必须一路回到归属网的 SCC AS（Serving Call Control AS）来切换媒体锚点。当用户处于漫游或远离归属网时，这条信令往返路径很长，导致语音中断时延经常超过300ms甚至更糟，严重影响通话体验。为此，3GPP在 R10（TS 23.216 + TS 23.237）引入了 eSRVCC（Enhanced SRVCC），核心思想是：在拜访网靠近UE的位置增加 ATCF（Access Transfer Control Function） 和 ATGW（Access Transfer Gateway） 作为信令与媒体的"近端锚点"，把接入域转移的信令路径和媒体切换都截短到ATGW附近，从而把切换时延压到目标值（业界实测可做到百毫秒级）。R12又引入了 vSRVCC（video SRVCC） 和 mid-call等增强。

本文聚焦 eSRVCC的PS-to-CS接入域转移 这一个具体机制，依据 TS 23.216（架构与流程）、TS 23.237/24.237（IMS Service Continuity，信令层）、TS 29.280（Sv接口）逐层拆解。

二、SRVCC vs eSRVCC：锚点位置的本质区别

理解eSRVCC，关键是理解"锚点（anchor）"概念。一次IMS通话有三条逻辑leg：access leg（UE到锚点）、remote leg（锚点到远端用户）。域转移的本质是：保留remote leg不变，只把access leg从PS接入换到CS接入。

graph LR
    subgraph 原始SRVCC
        UE1[UE] -->|PS access| P1[P-CSCF]
        P1 --> S1[S-CSCF]
        S1 --> SCC1[SCC AS 锚点<br/>归属网]
    end
    subgraph eSRVCC
        UE2[UE] -->|PS access| ATCF2[ATCF 信令锚点<br/>拜访网]
        ATCF2 -.更新.-> SCC2[SCC AS]
        UE2 -.媒体.-> ATGW2[ATGW 媒体锚点<br/>拜访网]
    end
    style SCC1 fill:#f96
    style ATCF2 fill:#9f9
    style ATGW2 fill:#9cf

三、关键功能实体与参考点

graph TB
    UE[UE Single Radio] -->|S1-U/N3 媒体| ENB[en/gNB]
    ENB -->|S1-MME/N2|MME[MME/AMF]
    MME <-. Sv .-> MSC[MSC Server<br/>enhanced for SRVCC]
    MSC <-->|Mc| MGW[IM-MGW]
    MGCF[MGCF<br/>常与MSC合一] -->|Mg SIP INVITE| ATCF
    ATCF <-->|Mn/Mp H.248| ATGW[ATGW<br/>媒体锚点]
    ATCF -->|ISC SIP| SCCAS[SCC AS]
    ATCF -->|via SBC/P-CSCF| UE
    SCCAS <-. Sh/Cx .-> HSS[HSS/UDM]
    HSS -->|Insert Subscriber Data STN-SR| MME
    UE -->|Gm| PCSCF[P-CSCF/SBC]
    PCSCF --> ATCF
    style ATCF fill:#9f9
    style ATGW fill:#9cf
    style MSC fill:#fc9

各实体职责（TS 23.216 §5.3）：

• MME（或5G场景下的AMF经interworking）：识别语音承载，决定触发PS-to-CS，经 Sv接口 向MSC Server发起请求。Sv由 TS 29.280 定义（基于GTPv2-C）。
• MSC Server（enhanced for SRVCC）：负责CS侧资源准备，并通过其内置或关联的 MGCF 用SIP向ATCF发起会话转移。
• ATCF：拜访网IMS功能，常与P-CSCF合设；作为信令锚点，接收域转移INVITE，更新ATGW并向SCC AS发起access transfer。
• ATGW：受ATCF经H.248控制的媒体网关，作为媒体锚点，域转移前后IP/Port不变，仅切换access leg方向。
• SCC AS：服务连续性应用服务器，仍是最终的会话控制点，但不再位于热路径上。
• HSS/UDM：存储STN-SR、用户SRVCC能力。

四、注册阶段：锚定的预先准备（设计意图）

eSRVCC能"快"的前提是：通话建立前就已经完成锚定。也就是说，UE每次IMS注册时，ATCF就把STN-SR、ATU-STI等关键标识预先铺好，切换发生时直接复用，不必临时协商。这是一次典型的"用注册期开销换切换期时延"的工程取舍。

sequenceDiagram
    participant UE
    participant PCSCF as P-CSCF/SBC
    participant ATCF
    participant SCSCF as S-CSCF
    participant SCCAS as SCC AS
    participant HSS
    participant MME

    UE->>PCSCF: REGISTER
    Note over PCSCF,ATCF: P-CSCF将ATCF插入Path
    PCSCF->>ATCF: REGISTER (Path)
    Note right of ATCF: ATCF分配 STN-SR<br/>置入 g.3gpp.atcf
    ATCF->>SCSCF: REGISTER<br/>Feature-Caps: g.3gpp.atcf,atcf-mgmt-uri,atcf-path
    SCSCF->>SCCAS: Third-Party REGISTER (isc)
    SCCAS->>HSS: 查询SRVCC能力 (Cx/Ud)
    SCCAS->>HSS: 更新STN-SR
    HSS->>MME: Insert Subscriber Data (STN-SR, SRVCC-allowed)
    SCCAS->>ATCF: SIP MESSAGE (ATU-STI, C-MSISDN, ATCF-Path-URI)<br/>TS 24.237 step.19
    Note right of ATCF: ATCF保存ATU-STI/C-MSISDN<br/>供域转移时寻址SCC AS

注册阶段ATCF相关Feature-Capability（TS 24.237 §5.10），是抓包识别eSRVCC部署的第一线索：

设计意图：把所有"切换时才需要、但切换时没时间去协商"的标识，前置到注册流程。其中 g.3gpp.atcf 的值就是STN-SR，是MGCF寻址ATCF的号码；ATU-STI（Access Transfer Update Session Transfer Identifier）由SCC AS配置，用来让ATCF在收到MGCF的域转移INVITE后，能反向发起一个新的INVITE到SCC AS以触发remote leg更新——这是eSRVCC信令精妙之处：域转移信令分两段，MGCF→ATCF用STN-SR，ATCF→SCC AS用ATU-STI，互不干扰。

值得注意一个实现细节：SCC AS向ATCF发送这条SIP MESSAGE（携带ATU-STI/C-MSISDN）时，通常跳过S-CSCF（可经I-CSCF），因此S-CSCF上不会保存C-MSISDN。后续ATCF发往SCC AS的域转移INVITE同样可以不经过S-CSCF，直接用ATU-STI路由。

五、PS-to-CS eSRVCC 完整信令时序

下面是通话进行中、UE从LTE/NR移出覆盖、回落到3G CS域的完整信令流（TS 23.216 §6.2.2.2 PS-to-CS eSRVCC，TS 24.237 §5.14）。

sequenceDiagram
    autonumber
    participant UE
    participant ENB as e/gNB
    participant MME
    participant MSC as MSC Server<br/>(+MGCF)
    participant MGW as IM-MGW
    participant ATCF
    participant ATGW
    participant SCCAS as SCC AS
    participant TRAN as 目标CS RAN<br/>(RNC/BSC)

    Note over UE: 通话进行中(PS access leg锚定在ATGW)
    UE->>ENB: Measurement Report(LTE变差,有3G)
    ENB->>MME: S1/N2 Handover Required<br/>SRVCC HO Indication
    Note over MME: 拆分承载:语音→CS,非语音→PS HO
    MME->>MSC: Sv: SRVCC PS-to-CS Request<br/>(STN-SR, MSISDN, TargetID)
    MSC->>MSC: MGCF发起会话转移
    MSC->>ATCF: SIP INVITE<br/>Request-URI=STN-SR<br/>P-Asserted-Identity=C-MSISDN
    ATCF->>ATGW: H.248 Modify<br/>(切换access leg远端到MGW)
    ATCF->>SCCAS: SIP INVITE<br/>Request-URI=ATU-STI<br/>Target-Dialog/Replaces
    Note over SCCAS: 触发Access Transfer Update<br/>remote leg不变,释放旧PS access leg
    SCCAS-->>ATCF: 200 OK
    ATCF-->>MSC: 200 OK (Contact即原PS leg的Contact)
    MSC->>TRAN: Prepare Handover/Relocation<br/>(CS资源分配)
    TRAN-->>MSC: HO Ack(资源就绪)
    MSC-->>MME: Sv: SRVCC PS-to-CS Response<br/>(CS HO info)
    MME->>ENB: HO Command
    ENB->>UE: HO Command(切到CS)
    UE->>TRAN: 接入目标CS小区
    TRAN->>MSC: HO Detect
    MSC->>MME: Sv: SRVCC PS-to-CS Complete Notify
    Note over MSC,MME: 语音PS承载释放;非语音PS HO独立处理
    Note over SCCAS: 旧access leg的Dialog到期后SCC AS发BYE释放

关键消息IE逐条解析

Step 2 — Handover Required（S1-AP / NG-AP，TS 36.413） 携带 SRVCC Operation Possible / SRVCC HO Indication IE，告知MME这是SRVCC切换；Target ID 指向UTRAN/GERAN小区。MME据此做承载分割（Bearer Splitting）：把QCI=1的GBR语音承载导向CS域，其余PS承载做普通PS切换（如支持DTF/DTM则并发）。

Step 4 — SRVCC PS-to-CS Request（Sv, TS 29.280）

Step 5 — MGCF→ATCF INVITE 这是eSRVCC与SRVCC分水岭。MSC Server通过其MGCF，用SIP发起会话转移：Request-URI = STN-SR（如 tel:+8613800138000），P-Asserted-Identity = C-MSISDN（主叫号码）。注意：MGCF发往ATCF的INVITE，与ATCF发往SCC AS的INVITE，Call-ID可能相同。

Step 7 — ATCF→SCC AS INVITE ATCF用 ATU-STI 作为Request-URI，向SCC AS发起转移INVITE。SCC AS凭借ATU-STI识别"这是SRVCC接入域转移请求"，对ICS UE场景还会校验 Target-Dialog 头域来关联既有会话（TS 24.237 §5.7.x）。SCC AS执行Access Transfer Update：保留remote leg，更新access leg指向，随后对旧PS access leg的Dialog发起释放（或等session timer到期发BYE）。

Step 6 vs media：ATCF同步经H.248 Modify 指令更新ATGW，把access leg的远端RTP从UE的IP/Port改为IM-MGW的IP/Port。ATGW对外的RTP IP/Port在整个域转移过程中保持不变——这正是远端用户完全无感知的根源。

六、媒体面切换原理：ATGW锚定的"原地换腿"

graph LR
    subgraph 切换前
        UEa[UE] -->|"RTP"| ATGWa[ATGW]
        ATGWa -->|"RTP 远端不变"| REMa[远端用户]
    end
    subgraph 切换后
        UEb[UE→CS] -->|"TDM/A-law"| MGWb[IM-MGW]
        MGWb -->|"RTP 新access leg"| ATGWb[ATGW 同IP同Port]
        ATGWb -->|"RTP 远端不变"| REMb[远端用户]
    end
    style ATGWa fill:#9cf
    style ATGWb fill:#9cf

设计精髓：媒体锚点（ATGW）和远端leg都不动，只有access leg的"靠近ATGW那一端"从PS换成CS。由于ATGW对外IP/Port不变，远端用户的RTP流路由、SDP协商全部无需刷新——这把媒体面切换代价降到最低，是时延下降的物理原因。对比原始SRVCC，媒体要一直回到归属SCC AS关联的MGW，漫游时这段路径可能跨大洲。

七、关键标识体系（IE结构图）

graph TD
    A[ATCF锚定标识体系] --> A1[STN-SR<br/>会话转移号码<br/>由ATCF分配]
    A --> A2[ATU-STI<br/>接入域更新转移标识<br/>由SCC AS配置]
    A --> A3[C-MSISDN<br/>CS主叫号码<br/>承载用户MSISDN]
    A --> A4[ATCF-Path-URI<br/>注册路径标识]
    A1 -.置于.-> A5[g.3gpp.atcf<br/>Feature-Cap]
    A4 -.回填.-> A6[SRVCC-info XML]
    A2 -.携带于.-> A7[SCC AS→ATCF MESSAGE<br/>TS24.237 step19]

八、状态与场景：通话各阶段的连续性

stateDiagram-v2
    [*] --> 注册锚定: IMS REGISTER完成<br/>ATCF/ATGW就位
    注册锚定 --> 通话态: 媒体锚定ATGW
    通话态 --> 振铃前: 主叫未接通<br/>ps2cs-srvcc-orig-pre-alerting
    通话态 --> 振铃态: 被叫振铃<br/>srvcc-alerting
    通话态 --> 接入域转移: LTE/NR弱覆盖<br/>触发PS-to-CS
    振铃前 --> 接入域转移: 支持时
    振铃态 --> 接入域转移: 支持时
    接入域转移 --> 通话态CS: CS leg建立<br/>remote leg保留
    通话态CS --> [*]: 正常挂机

不同阶段的连续性由不同feature-capability开关控制。无 g.3gpp.mid-call 支持时，只保证通话态转移；振铃态、早振铃态需要对应能力。这对网络规划是硬约束——部署eSRVCC必须确认ATCF/SCC AS统一支持所需能力集，否则会出现"通话中能切、振铃中不能切"的体验断层。

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

如何在pcap中识别eSRVCC域转移

1. S1-AP/NG-AP层：Handover Required 中出现 SRVCC HO Indication = ps-cs。
2. Sv接口（GTPv2-C, port 2123类）：出现 SRVCC PS-to-CS Request 消息，IE中含 STN-SR。这是最确凿的标志。
3. SIP层：MGCF→ATCF的INVITE，Request-URI 为tel URI（STN-SR），From/PAI为C-MSISDN；紧随其后ATCF→SCC AS一个以ATU-STI为Request-URI的INVITE。
4. 媒体层：ATGW侧RTP流在切换瞬间，对端IP从UE变成IM-MGW，但ATGW对外IP/Port不变。

常见故障点

• STN-SR未正确下发：注册时ATCF未把STN-SR写入HSS，或HSS未Insert Subscriber Data给MME，导致MME在Sv Request里带空STN-SR，MGCF无法寻址ATCF。排查：核对注册期Feature-Caps与HSS/MME订阅数据。
• ATU-STI/C-MSISDN缺失：SCC AS→ATCF的MESSAGE（TS 24.237 step19）丢失或被I-CSCF错误路由，ATCF无ATU-STI，无法向SCC AS发起转移INVITE。排查：检查SCC AS是否正确配置SRVCC info、I-CSCF路由。
• 时延超标（>300ms）：常见于SCC AS仍位于归属网且路径绕行，或ATCF/ATGW未真正就近部署（实际仍是远端锚点，"伪eSRVCC"）。排查：抓包比对MGCF→ATCF与ATCF→SCC AS两段时延，定位热路径。
• 承载分割失败：MME未正确识别QCI=1承载，或终端/网络不支持非语音PS并发（无DTM），导致非语音承载被丢弃。
• 振铃态切不动：缺失 g.3gpp.srvcc-alerting 能力协商。

十、与5G的关系

5G NSA/SA下VoNR语音，在NR覆盖不足回落EPS时，语音连续性走 EPS Fallback / RAT Fallback 或 5G SRVCC（向3G CS）。其ATCF/ATGW锚定机制与EPS eSRVCC一致，差异主要在触发源（gNB/AMF vs eNB/MME）和N2接口信令。理解了EPS eSRVCC，5G语音连续性即可平滑迁移。

常见问题

Q1: eSRVCC和SRVCC到底差在哪一句话上？ A: 一句话——媒体锚点位置。SRVCC的锚点是归属网的SCC AS关联MGW，eSRVCC把锚点搬到拜访网靠近UE的ATGW；ATGW对外RTP不变，远端leg和媒体路径全程不刷新，这是时延下降的根本。

Q2: 为什么需要ATU-STI，STN-SR不够吗？ A: STN-SR只解决"MGCF如何找到ATCF"。找到ATCF后，ATCF还要反向找SCC AS触发remote leg更新——这第二跳的寻址用ATU-STI。两段信令（MGCF→ATCF用STN-SR，ATCF→SCC AS用ATU-STI）解耦，是eSRVCC信令分层的关键。

Q3: 切换时远端用户会感觉到吗？ A: 正常情况下完全无感。远端leg的SDP、RTP对端（ATGW的IP/Port）不变，媒体面"原地换腿"，只有信令面在ATCF/SCC AS内部更新access leg。可能的瞬态是几十毫秒媒体中断。

Q4: vSRVCC和普通eSRVCC区别？ A: vSRVCC（video SRVCC, R12）针对视频通话，从VoLTE video+voice转到CS时只能保留voice（CS不支持视频），video承载被释放；普通eSRVCC只处理语音。Sv请求中用对应indication区分。

Q5: 没有IMS注册，能做eSRVCC吗？ A: 不能。ATCF锚定、STN-SR/ATU-STI的铺路都在IMS注册期完成。没有有效注册就没有锚点信息，eSRVCC无从触发——这也是为何注册成功是eSRVCC的前置条件。

参考来源

1. 3GPP TS 23.216 — Single Radio Voice Call Continuity (SRVCC); Stage 2 — §5.3功能架构、§6.2.2.2 PS-to-CS eSRVCC流程
2. 3GPP TS 24.237 — IP Multimedia (IMS) Service Continuity; Stage 3 — §5.10 Feature-Capability、§5.14接入域转移信令、step.19 SCC AS→ATCF MESSAGE
3. 3GPP TS 23.237 — IP Multimedia (IMS) Service Continuity; Stage 2 — IMS会话连续性架构
4. 3GPP TS 29.280 — 3GPP Sv interface (SRVCC) — MME↔MSC Server的Sv信令与IE
5. VoLTE信令系列--SRVCC/eSRVCC（腾讯云开发者社区） — ATCF/ATGW信令流程与媒体路径中文详解
6. VOLTE中eSRVCC相关的一些知识点（博客园 bjtime） — Feature-Capability、STN-SR、ATU-STI、C-MSISDN实现细节

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