# 5G IMS 被叫域选择 T-ADS 机制与 SCC-AS 锚定信令全链拆解 ## 一、为什么需要 T-ADS：一个被叫"在哪里、用什么域接听"的问题 在 IMS 语音（VoLTE/VoNR）网络里，当一个呼叫到达被叫侧时，网络面临的第一个问题不是"怎么编解码协商"，而是更朴素的：**这个被叫用户现在到底能通过哪个域被叫通？** 一个签约了 VoNR/VoLTE 的用户，理论上同时可能处于三种状态之一： 1. **IMS 注册在分组域（PS）**：UE 通过 5G IMS 注册成功，IMS 用户可达，理论上可做 VoNR； 2. **仅电路域（CS）注册**：UE 落在 2G/3G，只有 CS 语音可达； 3. **多接入同时注册**：UE 既有 PS 又有 CS 注册（典型如 EPS + CSFB 场景）。 更要命的是，即便 UE 在 PS 域 IMS 注册成功，也**不等于**当前小区/跟踪区真的能发起 VoNR 语音承载——NR 覆盖边缘、运营商策略关闭、或该 TA 暂不支持 IMS voice over PS 时，强行从 PS 域下发 INVITE 会直接失败。于是网络必须在**把 INVITE 往下送之前**先问一句：被叫这个接入，PS 域到底支持不支持 IMS voice？ 回答这个问题的网元就是 **SCC-AS（Service Centralization and Continuity Application Server）** 里的 **T-ADS（Terminating Access Domain Selection，被叫接入域选择）** 功能。它由 TS 23.292（IMS Centralized Services，Stage 2）定义，在 TS 24.292 §9.4.1 给出 Stage 3 的 SIP 行为，再借助 TS 29.328 的 Sh 接口向 HSS/UDM 取数来完成判定。 > **设计意图一句话总结**：T-ADS 把"被叫域选择"这个决策从分散的网元里抽出来，统一收敛到一个始终处于 SIP 信令路径上的应用服务器（SCC-AS）来做，使得无论后续发生 SRVCC、域间切换还是补充业务触发，被叫侧始终有一个"锚点"掌握会话控制权。 ## 二、SCC-AS 与 T-ADS 的架构定位 SCC-AS 是一个 SIP AS，通过 ISC 接口挂在 S-CSCF 上。它在架构上有两重身份： - **业务集中化（Centralization）**：把 CS 域、PS 域的语音都"收编"到 IMS 业务框架下，补充业务（MMTEL 的 OIP/OIR/CDIV 等）无论用户在哪个域都能一致触发； - **业务连续性（Continuity）**：在会话进行中发生接入变更（如 PS→CS 的 SRVCC）时，把旧的接入腿（access leg）换成新的，保证对端"远端腿"（remote leg）无感知。 T-ADS 是 SCC-AS 内部面向**被叫**的一个子功能，与 SCC-AS 的锚定（Anchoring）能力紧密绑定——只有在 SCC-AS 被插入被叫 SIP 路径后，T-ADS 才有机会在 INVITE 续接前插入一次域选择判定。 下面这张图把 SCC-AS/T-ADS 在 5G IMS 架构中的位置与外部接口画清楚： ```mermaid graph TD UE[UE / VoNR终端] -->|SIP over 5QI=5 信令承载| PCSCF[P-CSCF] PCSCF --> ICSCF[I-CSCF] ICSCF -->|查询服务S-CSCF| SCSCF[被叫侧 S-CSCF] SCSCF -->|iFC 被叫触发点匹配
ISC接口| SCCAS["SCC-AS
(含 T-ADS)"] SCCAS <-->|Sh 接口
Sh-UDR/Sh-Pull| HSS[(HSS / UDM)] SCCAS -->|CS域选时| MGCF[MGCF] MGCF -->|ISUP IAM| CS[GMSC / VMSC
电路域寻呼] SCCAS -->|PS域选时续接| SCSCF ``` 需要强调：在 5G SA 下，IMS 仍然通过 **Sh 接口**向 **UDM**（融合 HSS）取数，UDM 同时承担 IMS 的 HSS 角色。这点和 4G 没有本质区别，差异只在"指示从哪里来"——下文第五节会展开。 ## 三、锚定（Anchoring）：让 SCC-AS 永远"在路上" T-ADS 能否被执行，前提是 SCC-AS 必须出现在被叫 SIP 路径上。这就是**锚定**。它的实现靠的是 **iFC（Initial Filter Criteria，初始过滤准则）**。 被叫用户的业务档案（Service Profile）里配置了一条**被叫方向的 iFC**：当 S-CSCF 收到指向该用户的 INVITE，匹配到这条 iFC 的触发点（Trigger Point，通常是 `Method = INVITE`），就按 iFC 指定的优先级把 INVITE 转发给 SCC-AS。SCC-AS 收到后即完成"被锚定"——此后这个会话的所有 SIP 消息（183、PRACK、200 OK、BYE）都会路过 SCC-AS，它因此同时持有： - **远端腿（Remote Leg）**：通往主叫/对端的那条 SIP 对话； - **接入腿（Access Leg）**：通往被叫 UE 的那条 SIP 对话。 锚定是后续一切（T-ADS 域选、SRVCC 接入迁移、会话转移）的物理基础。一个常见误区是以为锚定只在 SRVCC 时才发生——其实**每次被叫会话建立时 SCC-AS 都会被锚定**，目的正是"以防万一"：万一通话中途要切域，SCC-AS 已经在路径上，可以直接做接入腿替换。 锚定动作本身还会做一件关键事：把 T-ADS 的判定**卡在 INVITE 续接给被叫之前**。也就是说，SCC-AS 收到 INVITE 后，先不急着往下发，先跑一遍 T-ADS，决定这通呼叫到底从哪条腿往下接。 ## 四、T-ADS 判定算法：三问定乾坤 T-ADS 的判定逻辑在 TS 23.292 的过程章节中给出，可归纳为"三连问"。判定前，SCC-AS 必须先通过 Sh 接口从 HSS/UDM 取回一组关键数据： | 判定输入 | 含义 | 来源 | |---------|------|------| | 注册接入集合 | UE 当前注册在哪些域（CS / PS / IMS） | HSS/UDM 中存的 Registration State | | **IMS Voice over PS Session Supported 指示** | 被叫当前 PS 接入是否支持 IMS voice over PS 承载 | MME/AMF 计算后上报，存于 HSS/UDM | | Last UE Activity Time | UE 最近一次活动时间，用于判断是否"陈旧注册" | HSS/UDM 维护 | | 用户当前位置（可选） | 必要时触发定位，确认可达性 | HSS/UDM / GMLC | 取回数据后，判定遵循以下决策树（对应 TS 23.292 过程描述）： ```mermaid flowchart TD S([SCC-AS 收到被叫会话 INVITE]) --> Q1{UE 是否已 IMS 注册?} Q1 -->|是| Q2{"IMS Voice over PS
Session Supported?"} Q2 -->|SUPPORTED| PS[选择 PS/IMS 域
VoNR/VoLTE 续接 INVITE] Q2 -->|NOT_SUPPORTED| Q3{是否同时 CS 注册?} Q1 -->|否| Q3 Q3 -->|是| CS[选择 CS 域
经 MGCF / CSRN 路由至电路域] Q3 -->|否| Q4{是否需要定位/可达性确认?} Q4 -->|是,触发定位| LOC[执行定位/重试] Q4 -->|否| FAIL[不可达: 按 4xx/5xx 失败处理] PS --> END([会话锚定完成,继续 SIP 接续]) CS --> END LOC --> Q1 ``` 把这个决策树读成一句话规则，便于现场记忆： - **IMS 注册 + PS 域支持 voice → 走 PS（VoNR/VoLTE）**； - **IMS 注册但 PS 域不支持 voice，且有 CS 注册 → 走 CS**； - **没 IMS 注册，但有 CS 注册 → 走 CS**； - **两者都没有 → 触发定位/重判，或失败**。 这正是 §一开篇那个"在哪里、用什么域接听"问题的标准答案。值得注意的是判定里隐含的**优先级**：在语音业务上，只要 PS 域真的支持 voice，就优先 PS（IMS），这是 VoNR/VoLTE 网络的本意；只有当 PS 不可用或不支持时才回退 CS。 ## 五、"IMS Voice over PS Session Supported 指示"的来源链路 整个 T-ADS 机制里，**最关键、也最容易出问题的单一数据**，就是那个 "IMS Voice over PS Session Supported 指示"。它从哪里来、由谁算、怎么传到 UDM/HSS，决定了 T-ADS 判定的正确性。 ### 5.1 谁来计算这个指示 这个指示**不是 UE 上报的，而是接入网移动性管理网元算出来的**： - **EPS（4G）**：由 **MME** 计算（TS 23.401）。MME 根据 TA 级配置、E-UTRAN 是否支持 voice、UE 的 voice domain preference / UE usage setting 综合判断。 - **5GS（5G）**：由 **AMF** 计算（TS 23.501 §5.16.3）。AMF 根据 NG-RAN 是否在当前注册区支持 voice over PS、自身策略、是否允许回退等判断。 指示取值通常有三个态：`SUPPORTED`、`NOT_SUPPORTED`、`UNKNOWN`（MME/AMF 暂时无法确定时）。其中 `UNKNOWN` 是个隐藏的坑——T-ADS 拿到 `UNKNOWN` 时策略取决于运营商，可能保守地回退 CS。 ### 5.2 指示如何到达 UDM/HSS MME/AMF 算出指示后，必须在注册/更新流程里把它**写回** UDM/HSS，SCC-AS 后续才能查到： ```mermaid sequenceDiagram participant UE as UE participant AMF as AMF / MME participant NR as NG-RAN / E-UTRAN participant UDM as UDM / HSS UE->>AMF: Registration Request / Attach AMF->>NR: 获取 TA / 小区语音支持能力 AMF->>AMF: 计算 IMS Voice over PS
Session Supported 指示 AMF->>UDM: Nudm_UECM_Registration
(imsVoiceOverPS = Supported) Note over UDM: 按 access 存储 per-access 指示 UDM-->>AMF: 确认 AMF-->>UE: Registration Accept
(隐式: 已具备 VoNR 能力) Note over UDM,SCCAS: 后续 SCC-AS 经 Sh 即可读到该指示 ``` 值得注意：**当 UE 移动到不支持 voice 的小区**，AMF 会通过移动性更新把指示刷成 `NOT_SUPPORTED`，UDM 随之更新。T-ADS 下次查询就能反映新状态。但这条更新链路的时延，正是"指示陈旧"故障的根源（见 §八）。 ### 5.3 EPS 与 5G 的链路对比 | 维度 | EPS（VoLTE） | 5GS（VoNR） | |------|-------------|-------------| | 计算网元 | MME | AMF | | 规范出处 | TS 23.401 | TS 23.501 §5.16.3 | | 上报 HSS/UDM 的接口 | Update Location（S6a，Diameter）/ Insert Subscriber Data | Nudm_UECM_Registration（SBI，TS 29.503） | | SCC-AS 取数接口 | Sh（Diameter，TS 29.328） | **仍是 Sh**（UDM 融合 HSS） | | 指示陈旧风险区 | SRVCC/TAU 时延 | NR 覆盖边缘、TAU/切换时延 | | 不支持 voice 时的被叫结果 | 域选到 CS（CSFB 思路） | NR-only 区域无 CS，触发 EPS Fallback / 不可达 | 表里有个常被忽略的事实：**5G 下 SCC-AS 仍走 Diameter Sh 接口**，并没有换成 SBI。这是因为 IMS 应用层与 5GC 的解耦——IMS 业务面（CSCF/AS）依然以 Diameter 体系的 HSS 为锚，UDM 在此承担 HSS 角色。所以"5G 全 SBI 化"在 IMS 这块并不成立。 ## 六、完整信令时序：一次被叫 VoNR 的 T-ADS 域选 把前面所有环节串起来，下面是被叫侧从 INVITE 到达、T-ADS 判定、再到按域续接的完整时序： ```mermaid sequenceDiagram autonumber participant A as 主叫 UE-A / MGCF participant SCSCF as 被叫侧 S-CSCF participant SCCAS as SCC-AS（T-ADS） participant HSS as HSS / UDM participant PCSCF as P-CSCF participant UE as 被叫 UE-B participant MGCF as MGCF（CS 路径用） A->>SCSCF: INVITE（被叫 IMPU / MSISDN） Note over SCSCF: 评估被叫 iFC，命中 SCC-AS 触发点 SCSCF->>SCCAS: INVITE（已锚定，远端腿建立） Note over SCCAS: 进入 T-ADS 判定 SCCAS->>HSS: Sh-UDR（Sh-Pull）
Data-Reference = IMS User State
查询注册状态 + VoPS 指示 HSS-->>SCCAS: 注册接入=PS；IMS VoPS=SUPPORTED；
LastActivity=近期 alt PS/IMS 域选中（VoNR） SCCAS->>SCSCF: INVITE 续接（接入腿续建） SCSCF->>PCSCF: INVITE PCSCF->>UE: INVITE（经 5QI=5 信令承载） UE-->>PCSCF: 183 Session Progress PCSCF-->>SCSCF: 183 SCSCF-->>SCCAS: 183（锚定后回传） SCCAS-->>A: 183 else CS 域选中（VoPS 不支持 + 有 CS 注册） SCCAS->>MGCF: INVITE（Request-URI 指向 CS） MGCF->>HSS: SRI（Send Routing Information，取 MSRN） HSS-->>MGCF: MSRN MGCF->>UE: ISUP IAM → VMSC → CS 域寻呼 Page end ``` 逐条消息的关键 IE 解读： - **消息① INVITE**：Request-URI 携带被叫 IMPU（如 `sip:user@ims.mnc.mcc.3gppnetwork.org`）或 tel URI 形式的 MSISDN。S-CSCF 据此匹配业务档案。 - **消息② iFC 触发转发**：S-CSCF 在 ISC 接口转发 INVITE 给 SCC-AS，此时远端腿对话已建。注意 iFC 的**优先级**：MMTEL 类 AS 通常先于 SCC-AS 触发，SCC-AS 往往是最后一个被叫触发点，确保域选在所有被叫业务处理之后进行。 - **消息③ Sh-UDR（Sh-Pull）**：这是 T-ADS 的"取数"核心。SCC-AS 发 Diameter Sh-UDR，`Data-Reference` 设为 IMS User State（及关联的 VoPS 指示），`User-Identity` 设为被叫 IMPU。一次查询即可拿到注册接入集合与 VoPS 指示。 - **消息④ HSS 应答**：UDA（User Data Answer）回送注册状态与指示。**这是 T-ADS 唯一的数据来源**——SCC-AS 自己不掌握 UE 的接入状态。 - **消息⑤ 续接**：若选 PS，SCC-AS 把 INVITE 经 S-CSCF→P-CSCF 送给 UE，全程走 5QI=5 的 IMS 信令专用 QoS 流；后续 183/PRACK/200 OK 都过 SCC-AS（已锚定）。 - **CS 分支**：若选 CS，SCC-AS 路由到 MGCF，MGCF 发 ISUP IAM，GMSC 经 SRI 向 HLR/HSS 取 MSRN，最终 VMSC 在 CS 域寻呼 UE。这条路径里 SCC-AS 仍持远端腿，会话始终锚定在 IMS。 ## 七、Sh 接口操作与关键 IE（TS 29.328） T-ADS 的取数完全依赖 Sh 接口。下表梳理 SCC-AS 在域选时用到的 Diameter 操作与 IE： | Sh 操作 / IE | 方向 | 作用 | |-------------|------|------| | Sh-UDR（User Data Request，即 Sh-Pull） | SCC-AS→HSS | 主动拉取用户数据，T-ADS 取数用此命令 | | `Data-Reference` = IMS User State | 请求 | 指明要取"用户状态"（含 per-access 注册态） | | `User-Identity`（IMPU/MSISDN） | 请求 | 标识被叫，决定查谁的注册信息 | | `Requested-Domain` | 请求 | 指定查询域（CS/PS/IMS），域选通常查全部 | | UDA（User Data Answer） | HSS→SCC-AS | 返回注册接入集合、VoPS 指示、Last Activity Time | | `User-State` | 应答 | per-access 的注册/未注册/未定 | | IMS Voice over PS Session Supported 指示 | 应答 | 决定 PS 域能否承担语音（T-ADS 核心判据） | | Sh-Subscriptions-Notifications | 双向 | SCC-AS 可订阅 UE 状态变化，避免每次都主动查 | 一个工程优化点：**SCC-AS 不必每次呼叫都发 Sh-UDR**。它可以通过 Sh 订阅（Sh-Subscriptions-Notifications）让 HSS 在 UE 注册/域变更时主动通知，本地缓存一份注册态。现网很多厂商用"注册时三方交互（S-CSCF 第三方注册触发 SCC-AS）+ 订阅通知"的组合，把 T-ADS 取数从"每呼叫一次 Sh"降到"状态变化时刷新"，大幅降低 Sh 接口压力。 ## 八、实战连接：抓包识别与故障排查 ### 8.1 抓包怎么认出这个流程 T-ADS 流程横跨 ISC（SIP）和 Sh（Diameter）两个接口，排查时通常要**同时挂这两个接口的抓包**： - **ISC 侧（SIP）**：在 S-CSCF↔SCC-AS 之间抓包，看 INVITE 是否被转发给 SCC-AS（确认 iFC 锚定生效），再看 SCC-AS 收到 INVITE 后**是否立即暂停续接**（说明在等 Sh 应答）。 - **Sh 侧（Diameter）**：抓 Sh-UDR/UDA。看到 `Data-Reference = User State`、`User-Identity = 被叫 IMPU` 的请求，且紧接着 UDA 回了 VoPS 指示——这就是 T-ADS 在动作。 - **关键判读**：对比 UDA 里的 `IMS Voice over PS Session Supported` 取值与最终 SIP 续接方向是否一致。`SUPPORTED` 却走了 CS、或 `NOT_SUPPORTED` 却强行走 PS，都是异常。 ### 8.2 三类高频故障 | 故障现象 | 典型根因 | 排查方向 | |---------|---------|---------| | 被叫 VoNR 不通，被错误域选到 CS 或失败 | **指示陈旧**：UE 已移出 VoNR 区，AMF 更新指示的时延 > SCC-AS 查询时刻 | 查 AMF→UDM 更新时序；看 UDA 返回的 VoPS 是否与 NG-RAN 实际能力一致 | | 被叫时延大（>1s 才振铃） | SCC-AS 每呼叫都发 Sh-UDR，Sh 接口拥塞或 HSS 响应慢 | 检查是否启用订阅通知+缓存；Sh 响应时延 | | `UNKNOWN` 态被误判 | MME/AMF 暂时算不出指示，SCC-AS 未定义 UNKNOWN 策略 | 核对 T-ADS 对 UNKNOWN 的处理规则（保守回退 CS 还是重试） | | iFC 未触发 SCC-AS | 被叫业务档案缺被叫触发点或优先级错 | 在 S-CSCF 侧看 iFC 评估日志，确认 SCC-AS 触发 | ## 九、5G/VoNR 演进：T-ADS 还要不要"选域"？ 一个自然疑问：5G SA 下没有 CS 域，T-ADS 还有意义吗？答案是**有，但语义变了**。 - **纯 NR-only 区域**：无 CS 注册可达，T-ADS 退化为"PS 域是否支持 voice"的单点判断。若 `SUPPORTED` → VoNR 续接；若 `NOT_SUPPORTED` → 当前 5G 不可达，被叫侧一般会配合 **EPS Fallback** 机制（这已超出 SCC-AS 范畴，由 AMF/NG-RAN 在主叫侧决定），被叫则可能直接失败或等 UE 回落到 EPS。 - **5G + EPS 双注册/互操作场景**：UE 可能同时注册 5G 与 EPS，T-ADS 重新具有"多接入域选择"的完整意义——在 VoNR-PS 与 VoLTE-PS（甚至 CS）之间选优。 - **R18/R19 趋势**：随着 Voice over NR 成熟与 CS 退网，T-ADS 的判定空间在收窄，但作为"被叫可达性 + 接入域一致性"的锚点，它的架构位置（SCC-AS）依然稳固，规范未将其移除。 换言之，T-ADS 在 5G 时代从"CS/PS 二选一"演变为"多 PS 接入选优 + 可达性闸门"，机制本身没被废弃，只是输入数据从"有没有 CS"变成了"哪个 PS 接入真的能做 voice"。 ## 常见问题 **Q1：T-ADS 和 SCC-AS 是什么关系？** A：T-ADS 是 SCC-AS 内部的一个**功能**，专门做被叫接入域选择。SCC-AS 是承载它的**网元**，同时还负责锚定、业务集中化、SRVCC 接入迁移等。可以理解为：SCC-AS 是房子，T-ADS 是房子里专门管"该走哪个门接客"的那个房间。 **Q2：为什么 SCC-AS 在 5G 下还用 Diameter Sh 接口，而不是 SBI？** A：因为 IMS 业务层（CSCF/AS）与 5GC 是解耦的。IMS 仍以 Diameter 体系的 HSS 为数据锚，UDM 融合了 HSS 角色对外提供 Sh。把 SCC-AS 改成 SBI 需要重构整个 IMS 数据面，标准化未走这条路，故 5G IMS 仍保留 Sh。 **Q3：被叫 VoNR 一直不通，但 UE 明明有信号，最可能是什么？** A：优先怀疑**指示陈旧**——AMF 算出的 VoPS 指示没及时同步到 UDM，或 NG-RAN 该 TA 暂不支持 voice。抓 Sh UDA 看 `IMS Voice over PS Session Supported` 取值，再与 NG-RAN 实际 voice 能力比对，基本能定位。 **Q4：T-ADS 选 CS 后，主叫侧会感知到吗？** A：不会。SCC-AS 持有远端腿，CS 路径（MGCF→ISUP）对主叫侧是完全透明的，主叫看到的仍是一条到 IMS 的 SIP 对话。这正是锚定+业务连续性设计的目标——对端无感知。 **Q5：UE 的 IMS 注册成功，就等于 VoNR 可用吗？** A：不等。IMS 注册只说明 SIP 信令可达（5QI=5 通），但**语音媒体承载（5QI=1）能否建立**取决于当前 TA 是否支持 voice over PS。T-ADS 正是用来在 INVITE 下发前查这一点的——IMS 注册是必要条件，VoPS 指示才是充分条件。 ## 参考来源 1. [3GPP TS 23.292 V19.0.0 — IMS Centralized Services (Stage 2)](https://www.etsi.org/deliver/etsi_ts/123200_123299/123292/19.00.00_60/ts_123292v190000p.pdf) — T-ADS 被叫接入域选择过程定义、SCC-AS 取数规则 2. [3GPP TS 24.292 §9.4.1 — Terminating Access domain selection](https://itecspec.com/3gpp/24.292/s/9.4.1) — SCC-AS 被叫域选的 Stage 3 SIP 行为 3. [3GPP TS 23.237 — IMS Service Continuity (Stage 2)](https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=819) — SCC-AS 锚定、接入迁移、SRVCC 架构 4. [Cisco — Implement T-ADS Functionality Support in StarOS as MME](https://www.cisco.com/c/en/us/support/docs/wireless/mme-mobility-management-entity/222940-implement-t-ads-functionality-support.pdf) — MME 侧 VoPS 指示计算与上报实现 5. [3GPP Explorer Glossary — Terminating Access Domain Selection (T-ADS)](https://3gpp-explorer.com/glossary/t-ads/) — T-ADS 概念与判定要素综述 --- > 本文由「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 等场景全覆盖。