51学通信

深度解析 3GPP TS 23.218：第六章(上) S-CSCF的“左右互搏术”与核心会话处理

16分钟阅读

好的，我们继续对TS 23.218的深度拆解。

这是系列文章的第四篇，我们将深入规范的第六章：服务CSCF与转接功能的功能需求 (Functional requirements of serving CSCF and Transit Function)。由于本章内容极其详尽，是整部规范的核心，我们将分多篇进行解读。本篇将聚焦于6.1至6.5节，深入剖析S-CSCF的核心功能模型以及它如何处理最关键的注册和主叫/被叫流程。

深度解析 3GPP TS 23.218：第六章(上) S-CSCF的“左右互搏术”与核心会话处理

本文技术原理深度参考了3GPP TS 23.218 V18.0.0 (2024-03) Release 18规范中，关于“6.1 Modes of operation of the S-CSCF…”, “6.3 S-CSCF handling of SIP registration”, “6.4 S-CSCF handling of UE-originating requests”及“6.5 S-CSCF handling of UE-terminating requests”的核心章节。本文旨在为读者揭示S-CSCF作为IMS“大脑”的内部运作机制，我们将通过其功能模型，理解它是如何同时扮演“来话处理器”和“去话处理器”的双重角色，并详细拆解其处理用户注册、主叫和被叫这三大核心场景的信令逻辑。

引言：揭秘IMS“大脑”的“思维过程”

在上一篇中，我们已经了解了IMS业务调度的“引擎”——由iFC和SPT构成的过滤与触发机制。我们知道，S-CSCF会根据这套“规则引擎”来决定是否以及如何将信令转发给应用服务器（AS）。

现在，我们要更进一步，深入到S-CSCF这个“大脑”的**“神经元”层面**。第六章，正是这份详细的“大脑思维过程”说明书。它不再满足于“如果…那么…”的高层逻辑，而是用精确的模型和流程，定义了S-CSCF在面对不同信令刺激时，其内部的状态机是如何运转的。

本章的核心，在于理解S-CSCF的一种**“左右互搏”**的工作模式。对于任何一个SIP会话，S-CSCF都将其视为由两个独立的“腿（Leg）”——来话腿（Incoming Leg）和去话腿（Outgoing Leg）——所构成。S-CSCF能够在这两个腿上，独立地应用不同的业务逻辑。

今天，我们将扮演“神经科学家”的角色，首先解剖S-CSCF的功能模型，然后通过注册、主叫、被叫这三个最经典的“神经反射”实验，来观察S-CSCF的“思维”是如何运作的。

1. 6.1 & 6.2 功能模型与接口：S-CSCF的“内部器官”

1.1 6.1.1 S-CSCF功能模型

Figure 6.1.1.1: S-CSCF functional model with incoming leg control and outgoing leg control

这张图是理解S-CSCF内部构造的“解剖图”。它将S-CSCF模型化为几个核心的功能组件：

  • ILCM (Incoming Leg Control Model): 来话腿控制模型。负责处理所有从用户或上一个网络节点到达S-CSCF的信令。
  • OLCM (Outgoing Leg Control Model): 去话腿控制模型。负责处理所有从S-CSCF发往下一个网络节点或用户的信令。
  • ILSM/OLSM (Incoming/Outgoing Leg State Model): 腿状态模型，用于存储每个腿的会话状态。
  • Registrar and Notifier: 注册器与通知器。专门负责处理REGISTER请求，并管理对注册状态的订阅与通知。
  • 与外部的连接:
    • HSS (Cx接口): 获取用户签约数据（iFC）。
    • Application Server(s) (ISC接口): 业务逻辑的执行者。
    • Incoming/Outgoing Leg: 连接上下游SIP节点的信令链路。

核心思想：“左右互搏”: 一个从美美发往小明的呼叫，在美美的S-CSCF中，会被这样处理：

  1. INVITE从Incoming Leg（来自美美的P-CSCF）进入ILCM。
  2. ILCM执行始发侧（originating）的iFC，可能会将请求通过ISC接口发往一个或多个AS。
  3. 当所有始发业务处理完毕，请求被交到OLCM。
  4. OLCM负责将请求从Outgoing Leg发往小明所在的网络。 这种将呼叫处理分解为“入”和“出”两个独立阶段的模式，使得S-CSCF可以极其灵活地在呼叫的两端应用不同的业务逻辑，是其强大能力的根源。

1.2 6.2 核心接口定义

本节重申了S-CSCF赖以工作的几个核心接口：

  • Mw (S-CSCF – CSCF): 用于在不同CSCF之间传递SIP信令。
  • ISC (S-CSCF – Application Server): 业务控制接口，核心中的核心。
  • Cx (S-CSCF – HSS): 用户签约数据下载接口。
  • Mr (S-CSCF – MRF): 媒体资源控制接口。

2. 6.3 S-CSCF handling of SIP registration (注册流程)

这是用户接入IMS网络的“敲门砖”，也是S-CSCF为用户建立“会话档案”的过程。

Upon receiving the initial registration request …, the S-CSCF shall authenticate the served user and … request the HSS to send the relevant service profile(s)…

  • 核心流程:
    1. 认证: S-CSCF收到来自I-CSCF转发的REGISTER请求后，第一件事就是认证用户。它会向HSS请求认证向量，并与UE进行一次完整的AKA质询-响应流程，以确认用户的合法性。
    2. 下载档案: 认证成功后，S-CSCF shall ... download from the HSS all the implicitly registered public user identities associated with the registered public user identity. S-CSCF会从HSS下载该用户完整的业务档案，这包括：
      • 所有归属于该用户的IMPU（公共身份）列表。
      • 针对这些IMPU的**iFC（初始过滤规则）**集合。
    3. 第三方注册: ...if the registration request ... matches a trigger, the S-CSCF performs a third party registration to the application servers... S-CSCF会立即检查下载下来的iFC，看是否有针对REGISTER事件的触发器。如果发现某条iFC规定“当用户注册时，需要通知AS-A（如语音信箱服务器）”，S-CSCF就会构造一个新的REGISTER请求（所谓的第三方注册），将用户的注册信息（如联系地址）发送给AS-A。
    4. 建立档案: S-CSCF在本地为用户建立一个完整的上下文，包括其所有IMPU的注册状态、联系地址、以及下载的iFC。
    5. 返回成功: S-CSCF向UE返回200 OK，注册完成。

图示解读 (Figure 6.3.1: S-CSCF handling registration): 这张图清晰地展示了第三方注册流程。UserA的注册（1），触发了S-CSCF与HSS的交互（2, Cx接口）。S-CSCF进行Filter Checking（4）后，向Application Server发起了第三方SIP REGISTER（5）。

3. 6.4 S-CSCF handling of UE-originating requests (主叫流程)

当已注册的美美拨打视频电话时，她的S-CSCF是如何处理这个始发请求的。

6.4.1 S-CSCF handling of UE-originating requests, registered user When such a request comes in, the S-CSCF shall first check whether this is an UE-originating request or a UE-terminating request in order to perform the matching procedure with SPTs within initial filter criteria.

  • 核心流程:
    1. 确定身份: S-CSCF收到INVITE后，首先要确定**“服务用户（Served User）”**是谁。通常是通过P-Asserted-Identity头域来识别出发起方（美美）。
    2. 鉴权: 检查该请求是否来自一个合法的、经过认证的源。
    3. 执行iFC: 这是核心步骤。S-CSCF会加载与美美相关的始发侧iFC（originating iFCs），并执行我们在第五章学习的“过滤与触发循环”：
      • 从最高优先级的iFC开始匹配。
      • 如果匹配，则将请求转发给对应的AS。
      • 当请求从AS返回后，继续匹配下一条低优先级的iFC。
      • …
    4. 最终路由: 当所有匹配的始发iFC都执行完毕后，S-CSCF会对最终（可能已被多个AS修改过）的INVITE请求进行路由决策，即通过查询DNS或ENUM，找到被叫方（小明）的归属网络，并将请求发往该网络的I-CSCF。

6.4.2 S-CSCF handling of UE-originating requests, unregistered user

  • 未注册用户处理: 如果一个未注册的用户（例如，一个只能打紧急电话的手机）发起呼叫，S-CSCF同样会为其加载一组特殊的、为**“未注册状态”**配置的iFC，并执行过滤。这使得运营商可以为未注册用户，提供有限的服务（如呼叫引导、播放提示音等）。

4. 6.5 S-CSCF handling of UE-terminating requests (被叫流程)

当一个呼叫发往美美时，她的S-CSCF是如何处理这个终止请求的。

6.5.1 S-CSCF handling of UE-terminating requests, registered user

  • 核心流程:
    1. 确定身份: S-CSCF收到一个INVITE请求（来自I-CSCF）。它会分析Request-URI，确定被叫方是谁（美美）。
    2. 执行iFC: 核心步骤。这次，S-CSCF会加载与美美相关的终止侧iFC（terminating iFCs），并执行同样的“过滤与触发循环”。
      • 场景: 在这个阶段，可能会触发视频彩铃AS、呼叫筛选AS、未接来电提醒AS等一系列被叫业务。
    3. 最终路由: 当所有终止iFC执行完毕后，S-CSCF会查询它在注册时保存的、美美的当前联系地址（Contact Address）。
    4. 发往UE: S-CSCF将最终的INVITE请求，通过P-CSCF，发往美美的手机。手机开始响铃。

6.5.2 S-CSCF handling of UE-terminating requests, unregistered user

  • 未注册用户处理: 如果呼叫到达时，美美不在线（UNREGISTERED状态），S-CSCF同样会加载一组为“未注册状态”配置的终止iFC。
    • 场景: 这正是触发语音信箱或**呼叫前转（无人接听时）**等业务的经典场景。iFC会将这个呼叫，直接转发给“语音信箱AS”，而根本不会去尝试联系美美的手机。

FAQ环节

Q1：S-CSCF的ILCM（来话腿模型）和OLCM（去话腿模型）在处理一个简单的A→B的呼叫时，是如何分工的？ A1：在主叫方A的S-CSCF-A中：

  • ILCM负责处理从A的UE接收到的INVITE请求，并执行A的始发iFC。
  • OLCM负责将经过始发iFC处理后的INVITE，发往被叫方B的网络。 在被叫方B的S-CSCF-B中：
  • ILCM负责处理从A的网络接收到的INVITE请求，并执行B的终止iFC。
  • OLCM负责将经过终止iFC处理后的INVITE，发往B的UE。 这种清晰的“入-出”分离模型，是S-CSCF能够处理复杂业务逻辑的基础。

Q2：什么是“第三方注册（third party registration）”？它和用户自己的注册有什么不同？ A2：

  • 用户注册: 是UE为了证明自己在线并获取服务而发起的。它包含了用户的安全凭证。
  • 第三方注册: 是S-CSCF代表UE，向AS发起的一种**“通知性”注册**。它不包含用户的安全凭证，其核心目的是告诉AS：“你的一个客户上线了，他的联系地址是xxx，注册有效期是yyy”。这使得AS能够维护用户的在线状态，以便在需要时（如语音信箱有新留言）能够主动联系用户。

Q3：iFC的触发，是在主叫的S-CSCF执行，还是在被叫的S-CSCF执行？ A3：**两者都会执行！**这是一个非常关键的概念。

  • 在主叫的S-CSCF，会执行主叫用户的始发侧iFC (originating iFC)，用于触发主叫增值业务（如预付费计费、主叫彩铃）。
  • 在被叫的S-CSCF，会执行被叫用户的终止侧iFC (terminating iFC)，用于触发被叫增值业务（如被叫彩铃、语音信箱、呼叫筛选）。 一个完整的端到端呼叫，其信令路径上可能会经过两套完全不同的iFC服务链的“洗礼”。

Q4：如果S-CSCF在执行iFC时，联系一个AS失败了，会怎么样？ A4：这取决于该条iFC中Default handling参数的配置。

  • 如果配置为**“继续（continue）”**，S-CSCF会忽略这次失败，并继续尝试匹配下一条低优先级的iFC。
  • 如果配置为**“终止（terminate）”**，S-CSCF会立即停止后续的所有处理，并向呼叫发起方返回一个错误响应（如500 Server Internal Error）。 这个容错机制，使得核心网可以根据业务的重要性，来决定单个AS的故障是否应该影响整个呼叫的成败。

Q5：S-CSCF的这些复杂流程，是否意味着它的实现非常困难？ A5：是的，S-CSCF是IMS核心网中最复杂、状态最多的网元之一。它的实现，需要一个高性能、高可靠的SIP协议栈，一个强大的、可灵活配置的规则引擎（用于处理iFC），以及一个能够管理数百万用户注册和会话状态的海量内存数据库。它需要与HSS, AS, CSCF等多个外部实体进行复杂的信令交互。因此，S-CSCF的开发和测试，是所有IMS设备商面临的核心挑战。

关系图谱