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

这是系列文章的第二篇，我们将聚焦于规范的第一、二、三章：Scope, References, Definitions and abbreviations。这一部分为整个IMS（IP多媒体子系统）呼叫模型和会话处理奠定了基础，清晰地定义了规范的管辖边界、技术依赖以及一套高度专业的术语体系。

---

深度解析 3GPP TS 23.218：第一至三章 IMS会话处理的“基石”

本文技术原理深度参考了3GPP TS 23.218 V18.0.0 (2024-03) Release 18规范中，作为规范开篇的第一、二、三章。本文旨在为读者系统性地构建一个关于IMS会话处理的坚实地基，我们将深入解读其技术范围、核心依赖以及贯穿全文的“行话”，为后续深入复杂的业务触发流程做好准备。

引言：为“智能通话”立法

在上一篇概览中，我们通过用户美美拨打VoNR视频电话的场景，了解了TS 23.218的核心使命——定义IMS业务的“中央调度宪章”。我们知道了，S-CSCF和iFC是这场“智能通话”大戏的两位核心主角。

现在，在我们深入分析这场大戏的每一幕（即具体的信令流程）之前，我们必须先仔细阅读它的“剧本大纲”——这就是规范的第一、二、三章。它为这场复杂的演出，提供了最基本的舞台设定和角色介绍。

今天，我们将扮演这场演出的“剧本编审”，逐一审视这份开篇文件，看看它是如何定义这场演出的主题与边界（Scope）、确认有哪些重要的**“合作伙伴”（References），并为所有“演员”（网络实体）和“观众”（工程师）提供一本通用的“角色与术语词典”（Definitions and abbreviations）**的。

---

1. 第一章 Scope (范围)：划定IMS会话处理的边界

The present document specifies the IP Multimedia (IM) Call Model for handling of an IP multimedia session origination and termination for an IP Multimedia subscriber.

• 核心使命: 规范的开篇直截了当，它的核心使命是定义**“IP多媒体呼叫模型（IM Call Model）”。这个模型，就是一套用于处理IMS用户发起（origination）和接收（termination）**多媒体会话的标准化流程。
  • “Call Model”: 这意味着本规范关注的是控制面的信令逻辑，即一个呼叫是如何被建立、修改和拆除的，以及在这个过程中，业务逻辑是如何被触发的。它不关心用户面的媒体流本身如何传输。

The present document includes interactions between an Application Server and IP multimedia sessions.

• 核心交互: 规范明确指出，其内容的核心之一，就是定义应用服务器（AS）与IP多媒体会话之间的交互。这正是IMS的“智能”所在。与传统的电路交换不同，IMS呼叫流程不再是一个简单的端到端连接过程，而是一个可以被AS随时“介入”、“干预”和“增强”的动态过程。

The IP Multimedia (IM) Subsystem stage 2 is specified in 3GPP TS 23.228.

• 架构基础: 规范清晰地指出了它的“根基”——TS 23.228 “IP multimedia subsystem; Stage 2”。TS 23.228是IMS的“总架构图”，定义了所有IMS实体（P/I/S-CSCF, HSS, AS, MRF等）和接口。而TS 23.218，则是在这个总体架构之上，专门深入阐述S-CSCF和AS如何协同进行会话处理的“专题深化”规范。可以认为，TS 23.228画出了“城市地图”，而TS 23.218则详细编写了这座城市“交通系统”的运行规则。

---

2. 第二章 References (参考文献)：IMS业务逻辑的“技术生态”

本章的引用列表，揭示了TS 23.218是构建在一系列3GPP核心网、IMS协议以及IETF互联网标准之上的“集大成者”。

• 3GPP内部依赖:
  • TS 23.228: IMS的总体架构，是本规范的“母体”。
  • TS 23.008: 用户数据规范。本规范中所有与用户签约相关的业务逻辑（如iFC），其数据模型和存储位置，都由TS 23.008来定义。
  • TS 29.228 & TS 29.229: Cx接口的Stage 3协议规范。定义了S-CSCF与HSS之间，具体是如何通过Diameter协议来下载用户业务档案（iFC）的。
  • TS 24.229: IMS的SIP协议Stage 3规范。本规范中描述的所有信令交互，其最终在空口和网络中的具体SIP消息格式、头域和编码，都由TS 24.229来定义。
  • TS 23.278 (CAMEL-IMS Interworking): 定义了如何将传统的智能网（CAMEL）业务，与现代的IMS业务进行互通，IM-SSF是其关键。
• IETF外部依赖:
  • RFC 3261 “SIP: Session Initiation Protocol”: SIP协议的根本大法。整个IMS的会话控制，都是基于SIP的。
  • RFC 3264 “An Offer/Answer Model with Session Description Protocol”: 定义了如何通过SDP在SIP信令中进行媒体协商，是建立音视频通话的基础。

这个引用列表告诉我们，要完全掌握TS 23.218，不仅需要理解IMS的宏观架构，还需要对底层的用户数据模型、具体的SIP/Diameter协议以及相关的智能网技术有深入的了解。

---

3. 第三章 Definitions and abbreviations (定义与缩略语)：IMS业务触发的“行话”

第三章是整部规范的“语言基础”，它定义了数量繁多、极其专业的IMS业务触发术语。掌握这些术语，是读懂后续所有流程图的必备前提。

3.1 核心定义 (Definitions)

Initial Filter Criteria (iFC): filter criteria that are stored in the HSS as part of the user profile and are downloaded to the S-CSCF upon user registration. They represent a provisioned subscription of a user to an application.

• 解读: 初始过滤规则（iFC）。这是整个规范的“灵魂”。它是在HSS中为用户预先配置好的、一组有序的业务触发规则。当用户注册时，S-CSCF会下载这份“规则集”。后续该用户的所有初始SIP请求，都会经过这个规则集的“过滤”。

Service Point Trigger (SPT): the points in the SIP signalling that may cause the S-CSCF to send/proxy the SIP message to an SIP AS… The subset of all possible SPTs which are relevant to a particular application are defined by means of Filter Criteria.

• 解读: 业务点触发器（SPT）。这是一个条件。iFC的核心，就是由一个或多个SPT通过逻辑组合（AND, OR, NOT）构成的。SPT定义了需要检查SIP信令的哪些“点”。例如：
  • any initial known or unknown SIP method: 检查SIP方法（如INVITE, REGISTER, MESSAGE）。
  • presence or absence of any known or unknown header field: 检查是否存在某个特定的头域。
  • content of any known or unknown header field or of the Request-URI: 检查某个头域或请求URI的内容。

Application Server (AS): An element offering applications that require the control of IP bearer resources.

• 解读: 应用服务器（AS）。所有增值业务的逻辑载体。iFC的最终目的，就是将匹配SPT条件的信令，导向一个指定的AS。

3.2 核心缩略语 (Abbreviations)

除了我们在之前系列中已经熟知的CSCF, HSS, SIP, SDP等，本规范还引入了一些与业务逻辑模型相关的缩略语：

• AS-ILCM / AS-OLCM: Application Server Incoming/Outgoing Leg Control Model (AS的入/出呼叫腿控制模型)。
• ILCM / OLCM: Incoming/Outgoing Leg Control Model (S-CSCF的入/出呼叫腿控制模型)。
• iFC / sFC: Initial/Subsequent Filter Criteria (初始/后续过滤规则)。

术语串联: 我们可以用这些“行话”来重新描述业务触发的过程： 当一个初始SIP请求到达S-CSCF后，S-CSCF的ILCM（或OLCM）会启动处理。它会用请求中包含的SPT，去匹配从HSS下载的用户iFC列表。如果匹配成功，S-CSCF会将请求通过ISC接口，转发给iFC中指定的AS。AS的AS-ILCM（或AS-OLCM）接收到请求，执行业务逻辑，然后可能将修改后的请求返回给S-CSCF，S-CSCF再继续后续的处理。

---

FAQ环节

Q1：这份TS 23.218（Stage 2）规范和IMS的总架构规范TS 23.228（Stage 2）是什么关系？为什么需要两份Stage 2规范？ A1：它们是**“总体设计”与“详细设计”**的关系，都是Stage 2层面，但侧重点不同。

• TS 23.228: 是IMS的**“总体架构规范”**。它定义了IMS的全套网络实体、所有参考点（接口），以及最高层级的、端到端的信令流程（如注册、呼叫建立）。它回答了“IMS系统由什么组成”和“宏观上如何工作”。
• TS 23.218: 是IMS的**“会话处理与业务触发详细规范”。它聚焦于IMS最核心的两个节点——S-CSCF和AS，详细地、深入地规定了它们内部的呼叫模型**、处理iFC的详细逻辑、以及AS的多种工作模式。它回答了“IMS的‘智能’到底是如何实现的”。 可以认为，TS 23.228是“城市规划图”，而TS 23.218是这座城市“中心交通枢纽（S-CSCF）的详细设计和运行手册”。

Q2：iFC（初始过滤规则）中的“初始（Initial）”是什么意思？难道还有“非初始”的过滤规则吗？ A2：是的。3GPP设计了一套两级过滤机制：

• iFC (Initial Filter Criteria): 是静态的，由运营商在HSS中为用户预先配置好。它在用户注册时一次性下载，并在整个注册周期内有效。它定义了用户签约的业务。
• sFC (Subsequent Filter Criteria): 是动态的。一个AS在处理一个请求后，可以在返回给S-CSCF的响应中，动态地为这个会话“注入”一些新的过滤规则（sFC）。这些规则只对当前这个会话的后续请求有效。
  • 例子: 一个“会议控制”AS，在建立一个多方通话后，可以向S-CSCF注入一个sFC：“对于这个通话的所有后续信令（如挂机BYE, 静音re-INVITE），都请先通知我”。这使得AS能够对一个已经建立的会话，进行持续的、动态的控制。 （注：正如规范6.9.2.0中所述，sFC在当前版本的IMS中并未被广泛使用，iFC是绝对的主流。）

Q3：SPT（业务点触发器）看起来非常灵活，它能做到多精细的触发？ A3：SPT的触发可以非常精细，几乎可以检查SIP消息的任何部分。例如，可以定义一个SPT，它的条件是：“当收到一个INVITE请求，并且这个请求的Request-URI中包含user=phone参数，并且Accept-Language头域中包含fr（法语）时，才触发”。这种强大的表达能力，使得运营商可以设计出极其复杂和个性化的业务逻辑。

Q4：为什么规范中要定义AS-ILCM/OLCM和S-CSCF的ILCM/OLCM这些“呼叫腿模型”？ A4：这些模型是为了将一个复杂的**B2BUA（背靠背用户代理）或Proxy（代理）的行为，进行清晰的、标准化的建模。一个SIP会话，从主叫到被叫，可以被看作由多个“腿（Leg）”**拼接而成。

• Incoming Leg: 从上一个节点到达当前节点的这一段。
• Outgoing Leg: 从当前节点发往下一个节点的这一段。 通过定义每个节点（S-CSCF或AS）的入腿控制模型（ILCM）和出腿控制模型（OLCM），规范可以精确地描述一个SIP消息在节点内部，是如何从“入”到“出”进行处理、转换和转发的。这对于定义复杂的第三方呼叫控制等场景至关重要。

Q5：学习完这三章，我应该对这份规范形成一个怎样的宏观印象？ A5：你应该形成这样一个印象：TS 23.218是IMS的**“大脑中枢神经系统”的说明书。它的核心，是围绕S-CSCF这个“中枢处理器”如何解析和执行来自HSS的iFC“指令集”，并将信令流精确地派发给不同的AS“功能模块”**来展开的。整个系统是一个高度可编程的、事件驱动的、基于优先级的服务链处理模型。这份规范的复杂性，正源于它所要支撑的业务逻辑的无限灵活性和可扩展性。