在 IMS 语音(VoLTE/VoNR)网络里,当一个呼叫到达被叫侧时,网络面临的第一个问题不是"怎么编解码协商",而是更朴素的:这个被叫用户现在到底能通过哪个域被叫通?
一个签约了 VoNR/VoLTE 的用户,理论上同时可能处于三种状态之一:
更要命的是,即便 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 是一个 SIP AS,通过 ISC 接口挂在 S-CSCF 上。它在架构上有两重身份:
T-ADS 是 SCC-AS 内部面向被叫的一个子功能,与 SCC-AS 的锚定(Anchoring)能力紧密绑定——只有在 SCC-AS 被插入被叫 SIP 路径后,T-ADS 才有机会在 INVITE 续接前插入一次域选择判定。
下面这张图把 SCC-AS/T-ADS 在 5G IMS 架构中的位置与外部接口画清楚:
graph TD
UE[UE / VoNR终端] -->|SIP over 5QI=5 信令承载| PCSCF[P-CSCF]
PCSCF --> ICSCF[I-CSCF]
ICSCF -->|查询服务S-CSCF| SCSCF[被叫侧 S-CSCF]
SCSCF -->|iFC 被叫触发点匹配<br/>ISC接口| SCCAS["SCC-AS<br/>(含 T-ADS)"]
SCCAS <-->|Sh 接口<br/>Sh-UDR/Sh-Pull| HSS[(HSS / UDM)]
SCCAS -->|CS域选时| MGCF[MGCF]
MGCF -->|ISUP IAM| CS[GMSC / VMSC<br/>电路域寻呼]
SCCAS -->|PS域选时续接| SCSCF
需要强调:在 5G SA 下,IMS 仍然通过 Sh 接口向 UDM(融合 HSS)取数,UDM 同时承担 IMS 的 HSS 角色。这点和 4G 没有本质区别,差异只在"指示从哪里来"——下文第五节会展开。
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,它因此同时持有:
锚定是后续一切(T-ADS 域选、SRVCC 接入迁移、会话转移)的物理基础。一个常见误区是以为锚定只在 SRVCC 时才发生——其实每次被叫会话建立时 SCC-AS 都会被锚定,目的正是"以防万一":万一通话中途要切域,SCC-AS 已经在路径上,可以直接做接入腿替换。
锚定动作本身还会做一件关键事:把 T-ADS 的判定卡在 INVITE 续接给被叫之前。也就是说,SCC-AS 收到 INVITE 后,先不急着往下发,先跑一遍 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 过程描述):
flowchart TD
S([SCC-AS 收到被叫会话 INVITE]) --> Q1{UE 是否已 IMS 注册?}
Q1 -->|是| Q2{"IMS Voice over PS<br/>Session Supported?"}
Q2 -->|SUPPORTED| PS[选择 PS/IMS 域<br/>VoNR/VoLTE 续接 INVITE]
Q2 -->|NOT_SUPPORTED| Q3{是否同时 CS 注册?}
Q1 -->|否| Q3
Q3 -->|是| CS[选择 CS 域<br/>经 MGCF / CSRN 路由至电路域]
Q3 -->|否| Q4{是否需要定位/可达性确认?}
Q4 -->|是,触发定位| LOC[执行定位/重试]
Q4 -->|否| FAIL[不可达: 按 4xx/5xx 失败处理]
PS --> END([会话锚定完成,继续 SIP 接续])
CS --> END
LOC --> Q1
把这个决策树读成一句话规则,便于现场记忆:
这正是 §一开篇那个"在哪里、用什么域接听"问题的标准答案。值得注意的是判定里隐含的优先级:在语音业务上,只要 PS 域真的支持 voice,就优先 PS(IMS),这是 VoNR/VoLTE 网络的本意;只有当 PS 不可用或不支持时才回退 CS。
整个 T-ADS 机制里,最关键、也最容易出问题的单一数据,就是那个 "IMS Voice over PS Session Supported 指示"。它从哪里来、由谁算、怎么传到 UDM/HSS,决定了 T-ADS 判定的正确性。
这个指示不是 UE 上报的,而是接入网移动性管理网元算出来的:
指示取值通常有三个态:SUPPORTED、NOT_SUPPORTED、UNKNOWN(MME/AMF 暂时无法确定时)。其中 UNKNOWN 是个隐藏的坑——T-ADS 拿到 UNKNOWN 时策略取决于运营商,可能保守地回退 CS。
MME/AMF 算出指示后,必须在注册/更新流程里把它写回 UDM/HSS,SCC-AS 后续才能查到:
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<br/>Session Supported 指示
AMF->>UDM: Nudm_UECM_Registration<br/>(imsVoiceOverPS = Supported)
Note over UDM: 按 access 存储 per-access 指示
UDM-->>AMF: 确认
AMF-->>UE: Registration Accept<br/>(隐式: 已具备 VoNR 能力)
Note over UDM,SCCAS: 后续 SCC-AS 经 Sh 即可读到该指示
值得注意:当 UE 移动到不支持 voice 的小区,AMF 会通过移动性更新把指示刷成 NOT_SUPPORTED,UDM 随之更新。T-ADS 下次查询就能反映新状态。但这条更新链路的时延,正是"指示陈旧"故障的根源(见 §八)。
| 维度 | 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 这块并不成立。
把前面所有环节串起来,下面是被叫侧从 INVITE 到达、T-ADS 判定、再到按域续接的完整时序:
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)<br/>Data-Reference = IMS User State<br/>查询注册状态 + VoPS 指示
HSS-->>SCCAS: 注册接入=PS;IMS VoPS=SUPPORTED;<br/>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 解读:
sip:[email protected])或 tel URI 形式的 MSISDN。S-CSCF 据此匹配业务档案。Data-Reference 设为 IMS User State(及关联的 VoPS 指示),User-Identity 设为被叫 IMPU。一次查询即可拿到注册接入集合与 VoPS 指示。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 接口压力。
T-ADS 流程横跨 ISC(SIP)和 Sh(Diameter)两个接口,排查时通常要同时挂这两个接口的抓包:
Data-Reference = User State、User-Identity = 被叫 IMPU 的请求,且紧接着 UDA 回了 VoPS 指示——这就是 T-ADS 在动作。IMS Voice over PS Session Supported 取值与最终 SIP 续接方向是否一致。SUPPORTED 却走了 CS、或 NOT_SUPPORTED 却强行走 PS,都是异常。| 故障现象 | 典型根因 | 排查方向 |
|---|---|---|
| 被叫 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 还有意义吗?答案是有,但语义变了。
SUPPORTED → VoNR 续接;若 NOT_SUPPORTED → 当前 5G 不可达,被叫侧一般会配合 EPS Fallback 机制(这已超出 SCC-AS 范畴,由 AMF/NG-RAN 在主叫侧决定),被叫则可能直接失败或等 UE 回落到 EPS。换言之,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 指示才是充分条件。
本文由「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 等场景全覆盖。
