IMS S-CSCF 选择与会话定位信令全链拆解：Cx 接口 UAR/SAR/LIR 三套机制的精确边界

一、为什么 S-CSCF 是 IMS 控制面的"心脏锚点"

在 IMS（IP Multimedia Subsystem，IP 多媒体子系统）架构中，三个 CSCF 各司其职：P-CSCF（Proxy-CSCF） 是 UE 接入 IMS 的代理，与 UE 之间建立 IPsec 安全联盟；I-CSCF（Interrogating-CSCF，问询 CSCF） 是归属网络的"问询台"，负责通过 Cx 接口查询 HSS 来确定由谁服务用户；S-CSCF（Serving-CSCF，服务 CSCF） 则是真正承载会话逻辑的核心节点——它执行 iFC（initial Filter Criteria，初始过滤规则）触发业务、维护注册状态、执行 SIP 路由、作为用户在 IMS 域的"锚点"。

关键认知：S-CSCF 不是网络拓扑中的固定节点，而是为每个注册用户动态分配的逻辑锚点。 一个用户的全部 IMS 业务（注册、主叫、被叫、补充业务触发）都必须最终落到"服务于他的那一个 S-CSCF"上。

这就引出了本文的核心问题：I-CSCF 凭什么知道该把信令送到哪个 S-CSCF？ 答案就藏在 Cx 接口的三套 Diameter 信令机制里：

• 注册阶段的选择（UAR/UAA + SAR/SAA）：I-CSCF 根据 HSS 返回的"能力要求"在多个 S-CSCF 候选中挑一个，并完成"服务器分配 + 用户档案下载"。
• 会话阶段的定位（LIR/LIA）：用户已注册后，被叫侧 I-CSCF 通过 HSS 查到已经分配好的 S-CSCF 名字。

这三套机制在 TS 23.228（Stage 2）、TS 29.228（Cx/Dx 数据模型）、TS 29.229（Cx/Dx 流程与命令）中定义，是 IMS 信令工程师必须吃透的"地基"。一个常见的工程误区是把会话路由时的 I-CSCF 查询笼统称为"选 S-CSCF"——实际上，真正意义的选择只发生在注册时，会话时只是"查找已分配的服务器"。本文即围绕这一精确边界展开。

二、Cx 接口全景：六对 Diameter 命令的职责划分

Cx 接口位于 I-CSCF / S-CSCF 与 HSS 之间（当存在 SLF——Subscription Locator Function——时，I-CSCF 先经 Dx 接口查 SLF 定位具体 HSS，再走 Cx）。它基于 Diameter 协议（RFC 6733），应用 ID 为 16777216。下表给出与本文相关的六对核心命令：

表 1：Cx 接口核心 Diameter 命令职责对比

一句话区分：UAR/SAR 是"建立"锚点（注册时），LIR 是"找"锚点（会话时），RTR 是"拆"锚点（注销时）。

三、注册阶段：S-CSCF 选择与分配的完整信令流

注册流程定义在 TS 23.228 Section 5.3.2（"Registration flows"），其中 S-CSCF 选择逻辑集中在 5.4.1.2（I-CSCF 关于 S-CSCF 选择的操作）。下图给出初始注册时（含 IMS-AKA）S-CSCF 选择与分配的完整时序：

sequenceDiagram
    participant UE
    participant PCSCF as P-CSCF
    participant ICSCF as I-CSCF
    participant HSS
    participant SCSCF as S-CSCF

    Note over UE,SCSCF: 第①段：选择阶段 (UAR/UAA)
    UE->>PCSCF: REGISTER (IMPU, IMPI)
    PCSCF->>ICSCF: REGISTER (+Path: P-CSCF地址)
    ICSCF->>HSS: Cx-Query / UAR (Auth-Type=REGISTRATION)
    HSS-->>ICSCF: Cx-Query Resp / UAA (Server-Capabilities: Mandatory/Optional)
    Note over ICSCF: 按能力匹配算法选出一个 S-CSCF
    ICSCF->>SCSCF: REGISTER (转发至被选中的 S-CSCF)

    Note over UE,SCSCF: 第②段：鉴权向量下载 (MAR/MAA)
    SCSCF->>HSS: Cx-Auth-Data-Get / MAR (索取鉴权向量)
    HSS-->>SCSCF: Cx-Auth-Data / MAA (RAND,AUTN,XRES,IK,CK)
    SCSCF-->>UE: 401 Unauthorized (WWW-Authenticate: RAND,AUTN)
    Note over SCSCF,PCSCF: IK/CK 通过私有头域单独发送给 P-CSCF,不下发UE

    Note over UE,SCSCF: 第③段：鉴权响应与正式分配 (SAR/SAA)
    UE->>PCSCF: REGISTER (Authorization: RES响应)
    PCSCF->>ICSCF: REGISTER
    ICSCF->>HSS: UAR (再次查询,验证鉴权通过)
    HSS-->>ICSCF: UAA (S-CSCF-Name: 已选中)
    ICSCF->>SCSCF: REGISTER
    SCSCF->>HSS: Cx-Put/Select-Pull / SAR (Server-Assignment-Type=REGISTRATION)
    HSS-->>SCSCF: SAA (User-Profile: 含 iFC + 公共/私有标识)
    Note over HSS: HSS 记录: 该用户由本 S-CSCF 服务

    Note over UE,SCSCF: 第④段：第三方注册 + 成功响应
    SCSCF->>SCSCF: 评估 iFC, 匹配注册触发点则向 AS 发起第三方 REGISTER
    SCSCF-->>PCSCF: 200 OK (Service-Route: S-CSCF地址)
    PCSCF-->>UE: 200 OK (保存 Service-Route 供后续会话)

逐步关键 IE 解析

第①段（UAR/UAA）：I-CSCF 收到 P-CSCF 转发的 REGISTER 后，向 HSS 发送 UAR。UAR 中最关键的 AVP（Attribute-Value Pair）是：

• Public-Identity（IMPU，如 sip:[email protected]）
• User-Name（IMPI，私有用户标识）
• Server-Assignment-Type / Authorization：标记本次是 REGISTRATION 还是 DE_REGISTRATION、是已鉴权还是未鉴权请求

HSS 在 UAA 中通过 Server-Capabilities AVP 返回能力要求，内含两组整数集合： - Mandatory-Capability：候选 S-CSCF 必须全部支持的强制能力（如能力号 1 代表支持某种业务引擎、2 代表支持特定 AS 互通等，编号由运营商自定义）。 - Optional-Capability：可选能力，用于在多个合格候选间择优。

设计意图：把"谁能服务该用户"的策略集中在 HSS 的用户档案里定义，而把"实际从一组同质 S-CSCF 中负载分担"的决策权交给 I-CSCF。这样运营商可在 HSS 里按用户/套餐配置能力要求（例如 IMS 集群电话用户只分配支持其专网能力的 S-CSCF），而 I-CSCF 仍可在合格集合内做轮询/负载均衡，实现策略集中 + 调度分散。

第②段（MAR/MAA）：选中 S-CSCF 后，S-CSCF 向 HSS 下载鉴权向量，启动 IMS-AKA。注意 P-CSCF 会在 401 中剥离发给 UE 的 IK/CK（IP 安全密钥），仅保留 RAND/AUTN 给 UE，因为 IK/CK 是给 P-CSCF 用于建立与 UE 间 IPsec SA 的，绝不能泄露给 UE 之外的设备。

第③段（SAR/SAA）：鉴权成功后，S-CSCF 发送 SAR（Server-Assignment-Type = REGISTRATION）做正式"服务器分配"。HSS 在 SAA 的 User-Data AVP 中返回完整的 Service-Profile，包括： - 该私有标识下的所有公共标识（IMPU 列表、隐式注册集） - iFC（initial Filter Criteria）——后续业务触发的核心规则集 - 计费、计费信息、Core Network Service Authorization 等

同时，HSS 把"本用户当前由该 S-CSCF 服务"记录下来——这正是会话阶段 LIR 能查到该 S-CSCF 的数据基础。

第④段：S-CSCF 评估 iFC，若某个 iFC 的触发点匹配"REGISTER 方法"，则向对应 AS 发起第三方注册（Third-Party Registration）——即 S-CSCF 代表用户向 AS 发一个 REGISTER，使 AS 得知用户已上线（这是 Presence、补充业务等 AS 初始化的逻辑前提）。最后 200 OK 中携带 Service-Route 头域，其值为本 S-CSCF 的 SIP URI；UE/P-CSCF 保存它，用于后续所有会话请求的寻址。

四、能力匹配算法：I-CSCF 如何从候选集里选出唯一 S-CSCF

S-CSCF 选择算法定义在 TS 23.228 Section 5.4.1.2。其本质是一个"约束满足 + 负载分担"的两段式决策，下图给出决策流程：

flowchart TD
    A[I-CSCF 收到 REGISTER] --> B[发 UAR 给 HSS]
    B --> C{UAA 返回内容?}
    C -->|Server-Name 已指定| D[直接用该 S-CSCF<br/>重注册/已有分配场景]
    C -->|Server-Capabilities 能力集| E[读取强制/可选能力]
    D --> Z[转发 REGISTER 到目标 S-CSCF]
    E --> F[过滤:必须满足全部 Mandatory-Capability]
    F --> G{合格候选数}
    G -->|0个| H[回退: 用运营商默认<br/>或按本地策略选一个]
    G -->|1个| I[选该 S-CSCF]
    G -->|多个| J[在合格集中择优:<br/>优先满足 Optional-Capability<br/>再用轮询/最少负载分担]
    H --> Z
    I --> Z
    J --> Z

表 2：Server-Capabilities 相关 AVP 说明

算法的三个边界情况（实战易错点）

1. 合格候选为零：当所有 S-CSCF 都不满足强制能力时，标准未规定硬性错误，运营商通常配置默认 S-CSCF 兜底或返回注册失败。抓包时应重点看 UAA 中 Server-Capabilities 是否合理、I-CSCF 本地能力表是否同步。
2. HSS 直接返回 Server-Name：重注册、或 HSS 已知用户先前分配的 S-CSCF 时，UAA 直接给名字，I-CSCF 不再做能力匹配——这保证了"用户一旦锁定某个 S-CSCF，整个注册生命周期内保持粘性"，避免会话和注册状态在不同 S-CSCF 间漂移。
3. 能力编号是运营商私有约定：强制/可选能力号没有全网统一含义，跨厂商对接时必须对齐能力字典，否则会出现"A 厂 I-CSCF 认为某 S-CSCF 不合格而 B 厂 HSS 认为合格"的诡异不一致。

五、Service-Route 与 Path：注册如何"绑定"后续会话路由

S-CSCF 选择完成后，还有一个常被忽略却至关重要的机制：注册时建立的两条"路由绑定"，决定了会话时信令往哪走。

• Service-Route（注册响应 → P-CSCF）：S-CSCF 在注册 200 OK 中下发，P-CSCF 保存。之后用户发起任何会话请求（INVITE/MESSAGE 等），P-CSCF 会用 Service-Route 预装载 Route 头域，直接把请求送到服务该用户的 S-CSCF——主叫侧会话通常不经过 I-CSCF、不发 Cx。
• Path（注册请求 → S-CSCF）：P-CSCF 在 REGISTER 中插入 Path 头域，记录自己的地址。S-CSCF 保存。这样被叫到达 S-CSCF 后，它能沿 Path 找到服务被叫的 P-CSCF，再送达 UE。

sequenceDiagram
    participant UE
    participant PCSCF as P-CSCF
    participant ICSCF_T as I-CSCF(被叫侧)
    participant HSS
    participant SCSCF_T as S-CSCF(被叫侧)
    participant OSCSCF as 主叫 S-CSCF

    Note over OSCSCF,UE: 主叫侧: 由 Service-Route 直接定路由
    UE->>PCSCF: INVITE (Route取自Service-Route)
    PCSCF->>OSCSCF: INVITE (直达服务S-CSCF,不查Cx)

    Note over OSCSCF,SCSCF_T: 被叫侧: ENUM/DNS 找到被叫归属域 I-CSCF
    OSCSCF->>ICSCF_T: INVITE (经DNS/ENUM解析到被叫域)
    Note over ICSCF_T: 会话阶段定位: 这是 LIR 而非 UAR!
    ICSCF_T->>HSS: Cx-Location-Info / LIR (查被叫的S-CSCF)
    HSS-->>ICSCF_T: LIA (S-CSCF-Name: 服务被叫的S-CSCF)
    ICSCF_T->>SCSCF_T: INVITE
    Note over SCSCF_T: S-CSCF 评估 iFC 触发业务<br/>沿注册时保存的 Path 找到被叫 P-CSCF
    SCSCF_T->>PCSCF: INVITE
    PCSCF->>UE: INVITE

设计精髓：注册时建立的 Service-Route/Path，把"动态分配的 S-CSCF"与"后续会话路由"解耦成两层——主叫靠 P-CSCF 缓存的 Service-Route 直接命中，被叫靠被叫域 I-CSCF 的 LIR 查询命中。注册开销只付一次，会话路由变得轻量。

六、会话阶段：LIR/LIA 是"定位"而非"选择"

这是全文最容易被混淆、也最该讲清的边界。当被叫侧 I-CSCF 收到来自主叫网络的 INVITE 时（主叫 S-CSCF 已通过 DNS/ENUM 把 tel URI 解析为被叫归属域的 SIP URI，再 DNS 查到该域的 I-CSCF），它发送的是 LIR（Location-Info-Request，Cx 命令码 302），而非 UAR。

• LIR 的输入：被叫的公共用户标识（IMPU）。
• LIA 的输出：HSS 返回当前服务该用户的 S-CSCF 名字（S-CSCF-Name AVP）。
• 若被叫未注册：根据运营商策略，LIA 可能返回 S-CSCF 能力集，由 I-CSCF 选一个 S-CSCF 做"未注册用户"处理（如转发到 voicemail AS），或直接 4xx 拒绝。

抓包关键：会话阶段在 I-CSCF 上看到的 Cx 查询命令码是 302（LIR）；如果你在 INVITE 流程里抓到 300（UAR），那基本是抓错了或流程异常——UAR 只属于注册。

七、S-CSCF 选择机制与其他域"锚点选择"的对比

理解一个机制最好的方式是对比。IMS 的 S-CSCF 选择、4G EPC 的 MME 选择、5G 的 AMF/SMF 选择，本质上都是"为用户在控制面选定一个服务锚点"，但实现哲学迥异：

表 3：IMS S-CSCF 选择 vs 5G AMF/SMF 选择 vs 4G MME 选择

可以看到，IMS 把"能力匹配"放在 Cx 接口显式建模，是其与 5G SBA（能力发现散落在 NRF 的 NF Profile）最显著的设计差异。这也解释了为什么 IMS 时代 S-CSCF 选择是确定性的、可审计的——每一步都有 Diameter 消息为证。

八、实战连接：抓包识别与故障排错

1. 抓包如何识别 S-CSCF 选择流程

用 Wireshark 过滤 diameter.cmd.code == 300 || diameter.cmd.code == 301 || diameter.cmd.code == 302，按时间排序即可看到注册/会话的 Cx 交互。关键判读：

• 注册时：UAR(300) → UAA →（选完）SAR(301, Type=REGISTRATION) → SAA(含 User-Data)。若 UAA 里只有 Server-Capabilities 而无 Server-Name，说明是初次注册走了完整能力匹配。
• 会话被叫时：INVITE 触发 LIR(302) → LIA(含 S-CSCF-Name)。如果 LIA 返回能力集而非 Server-Name，往往意味着被叫未注册——这是被叫不通的常见根因。

2. 常见故障点与排错思路

Q1：UAR 和 LIR 都向 HSS 查询 S-CSCF，到底有什么本质区别？ A：UAR（命令码 300）只在注册时使用，目的可能是"选一个 S-CSCF"（返回能力集）或"确认已选的 S-CSCF"（返回 Server-Name）；LIR（命令码 302）只在会话时使用，目的纯粹是"查已分配的 S-CSCF"，不涉及选择。简言之：UAR = 选/确认，LIR = 查找。

Q2：为什么主叫会话通常不经过 I-CSCF，而被叫必须经过？ A：因为注册时 S-CSCF 通过 Service-Route 把自己的地址告诉了 P-CSCF，主叫 P-CSCF 可直达该 S-CSCF，省去一次 Cx 查询；而被叫请求来自外部网络，其归属域入口只能是 I-CSCF，必须靠 I-CSCF 的 LIR 才能定位到服务被叫的具体 S-CSCF。

Q3：强制能力（Mandatory-Capability）和可选能力（Optional-Capability）的编号是谁定义的？ A：由运营商在 I-CSCF 本地能力表与 HSS 用户档案中私有约定，3GPP 不规定具体含义。跨厂商对接时必须人工对齐能力字典，否则能力匹配会失真。

Q4：用户在注册生命周期内会换 S-CSCF 吗？ A：正常情况下不会——重注册时 HSS 在 UAA 里直接返回原 Server-Name，保持粘性。只有在注销（RTR/SAR Type=USER_DEREGISTRATION）后重新注册，或 S-CSCF 故障（HSS 标记用户为"未分配"）时，才会重新走完整能力匹配并可能换到新的 S-CSCF。

Q5：SAR 下载的 User-Data 里最重要的内容是什么？ A：是 iFC（initial Filter Criteria）。它定义了 S-CSCF 在会话/注册信令上何时、按什么优先级、向哪个 AS 触发业务，是 IMS 补充业务、Presence、彩铃等所有 AS 业务的入口规则。没有 iFC，S-CSCF 就退化为一个纯 SIP 路由器。

参考来源

1. 3GPP TS 23.228 — IP Multimedia Subsystem (IMS) Stage 2 — Section 5.3.2 注册流程、5.4.1 S-CSCF 分配、5.5 主叫会话、5.7 被叫会话
2. 3GPP TS 29.228 — Cx and Dx interfaces; signalling flows and message contents — Cx/Dx 数据模型与 AVP 定义（Server-Capabilities、User-Data 等）
3. 3GPP TS 29.229 — Cx and Dx interfaces based on Diameter — UAR/UAA、SAR/SAA、LIR/LIA 命令定义与流程
4. APT Software — How an IMS network assigns and maintains an S-CSCF for a user — S-CSCF 选择与维护的工程化解读
5. Oracle Communications — S-CSCF Selection Based on Capabilities — 能力匹配（Mandatory/Optional）在产品中的实现说明

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