# 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。 ```mermaid 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 事件。 | 信息元素 | 含义 | 存储位置 | 触发更新时机 | |---------|------|---------|-------------| | STN‑SR（eSTN‑SR） | 会话转移号码，eSRVCC 中指向 ATCF | HSS 订阅数据 + MME 上下文 | UE IMS 第三方注册时由 ATCF 写入 | | C‑MSISDN | 关联 MSISDN，用于 CS 呼叫关联 | HSS + MME + MSC Server | 附着时下发，随 Sv 传递 | | g.3gpp.atcf | ATCF 分配的 STN‑SR（SIP 头携带） | REGISTER 第三方注册消息 | 注册期生成 | | ATCF Path | ATCF 是否插入到 access leg | S‑CSCF 会话状态 | 注册期决策 | ## 四、完整信令时序图：从测量报告到 CS 接管 下图给出 eSRVCC 从 E‑UTRAN 到 GERAN/UTRAN 的完整信令时序（对应 TS 23.216 clause 5.2.2.2 与 TS 24.237 clause 5 的会话转移流程）： ```mermaid 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 如下表： | IE | TS 29.280 参考 | 作用 | |----|---------------|------| | IMSI | clause 8.4 | UE 永久标识，CS 域寻址 | | Target ID | clause 8.x | 目标 CS 小区/控制器标识 | | STN‑SR | clause 8.x | 会话转移号码（eSRVCC 中=ATCF 地址） | | C‑MSISDN | clause 8.x | CS 呼叫关联号码 | | MM Context | clause 8.x | CS 域安全上下文（Kc 等，由 E‑UTRAN 密钥派生，TS 33.401） | | Source to Target Transparent Container | — | 空口透明容器，透传给目标 BSS/RNS | | SRVCC Indication | — | 标识 eSRVCC 能力（含 ATCF 锚定） | ### 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 呼叫已激活，用户侧仅感知到极短的语音中断。 ## 六、状态转换与会话锚点迁移 ```mermaid 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 ``` ## 七、抓包识别与实战排错 ### 抓包识别要点 | 接口 | 协议 | 识别特征 | Wireshark 过滤器 | |------|------|---------|-----------------| | S1‑MME | S1‑AP | `HandoverRequired` 含 `srvcc‑HO‑Indication` | `s1ap.procedureCode == 4 && s1ap.criticality.diagnostics` | | Sv | GTPv2 | Message Type = `SRVCC PS‑to‑CS Request`(21) | `gtpv2.msg_type == 21` | | Mw/Mg | SIP | INVITE 的 `Request‑URI` = eSTN‑SR（非用户号码） | `sip.Request‑URI contains "stn"` | | Gm | SIP | 原始会话 leg 出现 `UPDATE`（ATCF 发起） | `sip.Method == "UPDATE"` | **实战识别技巧**：在 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 对比 | 维度 | 基础 SRVCC | eSRVCC | |------|-----------|--------| | 会话转移锚点 | 归属网 SCC AS | 拜访/服务网 ATCF | | 媒体锚点 | 远端 / SCC AS 侧 | 本地 ATGW | | STN‑SR 指向 | SCC AS | ATCF（eSTN‑SR） | | 典型语音中断时延 | ~400–500ms | <300ms | | 漫游场景表现 | 时延显著劣化 | 时延稳定 | | 规范来源 | TS 23.216 Rel‑8 | TS 23.216 clause 5.3 + TS 23.237 clause 6.3（Rel‑10） | | 信令路径 | 跨域到归属 | 就近终结 | ## 九、从 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](https://www.3gpp.org/dynareport/23216.htm) — 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](https://www.3gpp.org/dynareport/24237.htm) — clause 5 信令流程、ATCF 会话转移 SIP 消息定义 3. [3GPP TS 29.280 — Sv interface (MME to MSC Server) for SRVCC](https://www.3gpp.org/dynareport/29280.htm) — clause 7 消息、clause 8 信息元素（PS‑to‑CS Request/Response） 4. [3GPP TS 23.237 — IMS Service Continuity; Stage 2](https://www.3gpp.org/dynareport/23237.htm) — clause 6.3 ATCF 功能描述 5. [Oracle Help Center — SRVCC PS‑CS Access Transfer（ATCF/STN‑SR 处理）](https://docs.oracle.com/en/industries/communications/session-border-controller/8.4.0/configuration/srvcc-ps-cs-access-transfer.html) 与 [博客园·VoLTE 中 eSRVCC 相关知识点](https://www.cnblogs.com/bjtime/p/18641689) — 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 等场景全覆盖。