# 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接入。 | 对比维度 | 原始SRVCC (R8/9) | eSRVCC (R10+) | |---------|------------------|---------------| | 信令锚点 | SCC AS（归属网） | ATCF（拜访网，靠近UE） | | 媒体锚点 | SCC AS关联的MGW/远端 | ATGW（拜访网，靠近UE） | | 会话转移触发 | MSC Server直接经I2/Mg向SCC AS发起 | MSC Server(MGCF)向ATCF发起，ATCF再向SCC AS | | 切换时延 | >300ms，漫游场景更差 | 目标<300ms，典型百毫秒级 | | 远端媒体路径变化 | 媒体回到归属MGW | 远端RTP路径不变，仅access leg换 | | 关键新增IE | STN-SR(由SCC AS分配) | STN-SR(由ATCF分配)、ATU-STI、C-MSISDN | | 漫游优化 | 无 | 显著 | ```mermaid graph LR subgraph 原始SRVCC UE1[UE] -->|PS access| P1[P-CSCF] P1 --> S1[S-CSCF] S1 --> SCC1[SCC AS 锚点
归属网] end subgraph eSRVCC UE2[UE] -->|PS access| ATCF2[ATCF 信令锚点
拜访网] ATCF2 -.更新.-> SCC2[SCC AS] UE2 -.媒体.-> ATGW2[ATGW 媒体锚点
拜访网] end style SCC1 fill:#f96 style ATCF2 fill:#9f9 style ATGW2 fill:#9cf ``` ## 三、关键功能实体与参考点 ```mermaid graph TB UE[UE Single Radio] -->|S1-U/N3 媒体| ENB[en/gNB] ENB -->|S1-MME/N2|MME[MME/AMF] MME <-. Sv .-> MSC[MSC Server
enhanced for SRVCC] MSC <-->|Mc| MGW[IM-MGW] MGCF[MGCF
常与MSC合一] -->|Mg SIP INVITE| ATCF ATCF <-->|Mn/Mp H.248| ATGW[ATGW
媒体锚点] 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等关键标识预先铺好，切换发生时直接复用，不必临时协商。这是一次典型的"用注册期开销换切换期时延"的工程取舍。 ```mermaid 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
置入 g.3gpp.atcf ATCF->>SCSCF: REGISTER
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)
TS 24.237 step.19 Note right of ATCF: ATCF保存ATU-STI/C-MSISDN
供域转移时寻址SCC AS ``` 注册阶段ATCF相关Feature-Capability（TS 24.237 §5.10），是抓包识别eSRVCC部署的第一线索： | Feature-Capability | 含义 | 关键作用 | |--------------------|------|----------| | `g.3gpp.atcf` | 其值即ATCF分配的STN-SR（tel:+...） | MSC/MGCF据此寻址ATCF | | `g.3gpp.atcf-mgmt-uri` | ATCF管理URI | SCC AS用此URI作Request-URI发送含SRVCC信息的MESSAGE | | `g.3gpp.atcf-path` | 终结请求的ATCF URI | 标识注册路径，回填SRVCC-info的ATCF-Path-URI | | `g.3gpp.srvcc-alerting` | 支持振铃态SRVCC | 允许pre-alerting/alerting阶段转移 | | `g.3gpp.ps2cs-srvcc-orig-pre-alerting` | 主叫早前振铃支持 | 主叫未接通前的连续性 | | `g.3gpp.mid-call` | 中途通话支持 | 允许通话中转移及mid-call业务携带 | **设计意图**：把所有"切换时才需要、但切换时没时间去协商"的标识，前置到注册流程。其中 `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）。 ```text sequenceDiagram autonumber participant UE participant ENB as e/gNB participant MME participant MSC as MSC Server
(+MGCF) participant MGW as IM-MGW participant ATCF participant ATGW participant SCCAS as SCC AS participant TRAN as 目标CS RAN
(RNC/BSC) Note over UE: 通话进行中(PS access leg锚定在ATGW) UE->>ENB: Measurement Report(LTE变差,有3G) ENB->>MME: S1/N2 Handover Required
SRVCC HO Indication Note over MME: 拆分承载:语音→CS,非语音→PS HO MME->>MSC: Sv: SRVCC PS-to-CS Request
(STN-SR, MSISDN, TargetID) MSC->>MSC: MGCF发起会话转移 MSC->>ATCF: SIP INVITE
Request-URI=STN-SR
P-Asserted-Identity=C-MSISDN ATCF->>ATGW: H.248 Modify
(切换access leg远端到MGW) ATCF->>SCCAS: SIP INVITE
Request-URI=ATU-STI
Target-Dialog/Replaces Note over SCCAS: 触发Access Transfer Update
remote leg不变,释放旧PS access leg SCCAS-->>ATCF: 200 OK ATCF-->>MSC: 200 OK (Contact即原PS leg的Contact) MSC->>TRAN: Prepare Handover/Relocation
(CS资源分配) TRAN-->>MSC: HO Ack(资源就绪) MSC-->>MME: Sv: SRVCC PS-to-CS Response
(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）** | IE | 说明 | |----|------| | STN-SR | 会话转移号码，由ATCF分配，寻址ATCF | | MSISDN / IMSI | 用户标识 | | Target RNC ID / CGI / LAC | 目标CS小区 | |_SRVCC Indication | 区分voice-only / vSRVCC | | C-MSISDN | 用于CS侧主叫号码 | | MM Context / Security context | CS安全上下文（用于CS鉴权与加密继承） | **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锚定的"原地换腿" ```mermaid 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结构图） ```mermaid graph TD A[ATCF锚定标识体系] --> A1[STN-SR
会话转移号码
由ATCF分配] A --> A2[ATU-STI
接入域更新转移标识
由SCC AS配置] A --> A3[C-MSISDN
CS主叫号码
承载用户MSISDN] A --> A4[ATCF-Path-URI
注册路径标识] A1 -.置于.-> A5[g.3gpp.atcf
Feature-Cap] A4 -.回填.-> A6[SRVCC-info XML] A2 -.携带于.-> A7[SCC AS→ATCF MESSAGE
TS24.237 step19] ``` | 标识 | 由谁分配/配置 | 携带在哪 | 用途 | |------|--------------|----------|------| | STN-SR | ATCF | g.3gpp.atcf → HSS → MME → Sv | MGCF寻址ATCF | | ATU-STI | SCC AS | SCC AS→ATCF MESSAGE | ATCF反向发起转移INVITE到SCC AS | | C-MSISDN | HSS订阅数据 | SCC AS→ATCF MESSAGE; MGCF INVITE的PAI | CS侧主叫号、被叫侧关联 | | ATCF-Path-URI | ATCF | REGISTER Path; SRVCC-info | 标识注册路径，跨多注册场景 | ## 八、状态与场景：通话各阶段的连续性 ```mermaid stateDiagram-v2 [*] --> 注册锚定: IMS REGISTER完成
ATCF/ATGW就位 注册锚定 --> 通话态: 媒体锚定ATGW 通话态 --> 振铃前: 主叫未接通
ps2cs-srvcc-orig-pre-alerting 通话态 --> 振铃态: 被叫振铃
srvcc-alerting 通话态 --> 接入域转移: LTE/NR弱覆盖
触发PS-to-CS 振铃前 --> 接入域转移: 支持时 振铃态 --> 接入域转移: 支持时 接入域转移 --> 通话态CS: CS leg建立
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](https://www.3gpp.org/dynareport/23216.htm) — §5.3功能架构、§6.2.2.2 PS-to-CS eSRVCC流程 2. [3GPP TS 24.237 — IP Multimedia (IMS) Service Continuity; Stage 3](https://www.3gpp.org/dynareport/24237.htm) — §5.10 Feature-Capability、§5.14接入域转移信令、step.19 SCC AS→ATCF MESSAGE 3. [3GPP TS 23.237 — IP Multimedia (IMS) Service Continuity; Stage 2](https://www.3gpp.org/dynareport/23237.htm) — IMS会话连续性架构 4. [3GPP TS 29.280 — 3GPP Sv interface (SRVCC)](https://www.3gpp.org/dynareport/29280.htm) — MME↔MSC Server的Sv信令与IE 5. [VoLTE信令系列--SRVCC/eSRVCC（腾讯云开发者社区）](https://cloud.tencent.com/developer/article/1500076) — ATCF/ATGW信令流程与媒体路径中文详解 6. [VOLTE中eSRVCC相关的一些知识点（博客园 bjtime）](https://www.cnblogs.com/bjtime/p/18641689) — 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 等场景全覆盖。