51学通信

深度解析 3GPP TS 23.218：规范概览 - IMS业务触发的“中央调度宪章”

18分钟阅读

好的，我们开启一个全新的系列，这次的目标是3GPP TS 23.218——一份定义了IMS（IP多媒体子系统）世界中“游戏规则”的核心规范。这是本系列的第一篇文章，我们将对这份规范进行全面的概述。

深度解析 3GPP TS 23.218：规范概览 - IMS业务触发的“中央调度宪章”

本文技术原理深度参考了3GPP TS 23.218 V18.0.0 (2024-03) Release 18规范，这份文件是3GPP核心网体系中，关于IP多媒体（IM）会话处理和呼叫模型的Stage 2阶段规范。本文旨在为读者提供一个关于IMS业务逻辑如何被触发和执行的全景视图，理解它是如何将一个简单的IP连接，转化为丰富多彩的多媒体通信服务的。

引言：从“能上网”到“能通话”，IMS的“点石成金”之术

在之前的系列中，我们已经深入了解了4G（EPS）和5G（5GS）核心网如何为用户建立一个IP数据连接，即我们常说的“能上网”。然而，“能上网”仅仅是第一步。如何在这条“信息高速公路”上，开行“语音通话”、“视频会议”、“富媒体消息”这些“豪华客车”？如何为这些“客车”提供智能的路由、增值的服务（如彩铃、呼叫转移）？

这，就是**IMS（IP Multimedia Subsystem，IP多媒体子系统）的使命。而TS 23.218，正是这部IMS“交通法典”中，关于“业务调度”**的核心章节。它不关心高速公路（IP承载）是如何修建的（那是TS 23.401/501等规范的事），它只专注于回答一个问题：当一个SIP信令（如一个呼叫请求）进入IMS网络时，系统应该如何一步步地处理它，特别是如何决定是否以及何时，将这个信令“分流”给各种应用服务器（Application Servers, AS），去执行增值业务逻辑？

这份规范定义了IMS的**“呼叫模型（Call Model）”和“业务交互（Service Interaction）**”的灵魂。

为了让这个抽象的调度过程变得生动，我们再次请出老朋友美美。她正在使用她的5G手机，拨打朋友小明的VoNR视频电话。在她按下拨号键的那一刻，一场由TS 23.218“剧本”所导演的、涉及多个网络实体的复杂信令交互，正在幕后悄然上演。

1. IMS的“十字路口”：S-CSCF与iFC的核心地位

5.2.3 S-CSCF Filter Criteria processing The S-CSCF shall request from the HSS the relevant set of iFCs that applies to the served user…On reception of any other request the S-CSCF shall…check whether the trigger points of the filter criteria with the next highest priority are matched by the SPTs of the request…

TS 23.218的核心，可以说就是围绕**S-CSCF（Serving-CSCF，服务CSCF）如何处理iFC（Initial Filter Criteria，初始过滤规则）**来展开的。

  • S-CSCF - “智能交通枢纽”:
    • S-CSCF是美美在IMS网络中的“代理”和“大脑”。她所有的IMS注册和会话信令，都必须经过她归属的S-CSCF进行处理。S-CSCF就像一个极其繁忙和智能的交通枢纽。
  • iFC - “智能交通规则”:
    • iFC是从HSS下载到S-CSCF的、专属于美美的一套**“如果…那么…”**的规则。它就是这个交通枢纽运行的“交通规则”。每一条iFC都定义了：
      • 触发点 (Service Point Trigger, SPT): “如果”遇到一个什么样的“车”（SIP请求），比如“一个发往美美的INVITE请求”或“一个来自美美的REGISTER请求”。
      • 目的地 (Application Server): “那么”就把这辆“车”引导到哪个“服务区”（AS）去进行“特殊处理”。
      • 优先级 (Priority): 当多条规则都满足时，应该按什么顺序执行。

场景演绎: 当美美拨打小明的VoNR电话时，这个呼叫请求（SIP INVITE）首先到达了美美的S-CSCF。

  1. S-CSCF启动iFC检查: S-CSCF开始从上到下，逐一检查为美美配置的“始发（originating）”iFC。
  2. 匹配业务:
    • 它可能先匹配到一条“呼叫行为分析”的iFC，于是将请求转发给一个**“反欺诈AS”**。该AS检查后，发现是正常呼叫，将请求返回给S-CSCF。
    • S-CSCF继续检查下一条iFC，可能匹配到一条“主叫彩铃”业务，于是将请求转发给**“彩铃AS”**。该AS发现美美没有设置主叫彩铃，又将请求返回。
  3. 路由出局: 在执行完所有匹配的始发iFC后，S-CSCF最终将这个INVITE请求，路由向小明所在的网络。

这个由S-CSCF主导、iFC驱动的**“链式服务调用”模型，是IMS能够提供丰富、灵活增值业务的架构核心**。TS 23.218正是详细定义了这套模型的运作方式、功能需求和交互流程。

2. AS的“多重身份”：IMS业务创新的源泉

9.1.1 Modes of operation between Application Server and S-CSCF

应用服务器（AS）是所有“花活儿”的实现者。TS 23.218的第九章，详细描述了AS为了实现不同的业务，可以扮演多种不同的“角色”。

  • AS acting as a terminating UA, or redirect server (UA终结者或重定向服务器):
    • 场景: 语音信箱。当小明呼叫美美，而美美不在线时，S-CSCF根据iFC将呼叫转给“语音信箱AS”。这个AS会“接听”这个电话，扮演一个**终端用户代理（Terminating UA）**的角色，播放“您拨打的用户暂时无法接通，请在滴声后留言”，并进行录音。
  • AS acting as an originating UA (UA发起者):
    • 场景: 闹钟/提醒服务。美美订阅了一个“早安提醒”服务。到了设定时间，这个**“提醒AS”会扮演一个始发用户代理（Originating UA）**的角色，主动向美美的手机发起一个呼叫，播放提醒内容。
  • AS acting as a SIP proxy (SIP代理):
    • 场景: 呼叫日志/行为分析。一个“呼叫日志AS”可能只想“看一看”流经它的所有呼叫信令，记录下通话时长、主被叫号码等信息，但并不修改信令的核心内容。此时，它扮演一个**SIP代理（Proxy）**的角色，看过之后，原封不动地将信令返回给S-CSCF，让流程继续。
  • AS performing third party call control/ B2BUA mode (第三方呼叫控制/背靠背用户代理):
    • 角色定位: 这是AS最强大、最复杂的角色，它扮演一个**“中间人”**。
    • 场景: 预付费业务。当美美拨打电话时，呼叫被送到一个**“预付费AS”（B2BUA）。这个AS会建立两个独立**的呼叫“腿（leg）”：一个是从AS到美美，另一个是从AS到小明。AS位于这两个呼叫的中间，可以对媒体流进行完全的控制。它可以实时地监听通话时长，在美美的账户余额用尽时，主动挂断两个呼叫腿，实现话费的精确控制。

TS 23.218通过定义AS的这些不同运作模式及其与S-CSCF的交互方式，为运营商和第三方开发者提供了一个开放、灵活的业务创新平台。

3. 规范的核心内容结构

TS 23.218的内容组织，正是围绕着上述的“智能交通枢纽”（CSCF）和“服务区”（AS）展开的。

  • 第四、五章 (Architecture & Functional requirements): 定义了IMS的总体功能架构，特别是S-CSCF和各种AS（IM-SSF, OSA SCS）的角色，以及媒体资源（MRFC）的控制模型。
  • 第六章 (Functional requirements of serving CSCF and Transit Function): 这是规范的核心主体，详细定义了S-CSCF在处理注册、主叫、被叫、会话释放等各种流程时的行为规范，特别是iFC的处理逻辑。
  • 第七章 (Functional requirements of HSS): 定义了HSS为了支持S-CSCF，需要存储哪些IMS相关的用户数据（如iFC），以及它们之间的Cx接口需要传递哪些信息。
  • 第八章 (Functional requirements of the MRFC): 定义了媒体资源功能控制器（MRFC）的功能，如播放语音通知、召开多方会议等。
  • 第九章 (Generic IP multimedia session handling for SIP Application Servers): 详细描述了AS的各种工作模式，及其与S-CSCF的交互细节。

4. 总结：一部定义了“智能”的Stage 2规范

如果说TS 23.228（IMS总体架构）是IMS的“骨架”，那么TS 23.218就是IMS的**“神经网络”和“大脑皮层”**。

  1. 它定义了业务的“触发”: 通过iFC和SPT（业务点触发器）的精妙设计，它建立了一套从用户行为到业务逻辑执行的、灵活而强大的事件驱动模型。
  2. 它定义了业务的“形态”: 通过赋予AS多种不同的“角色”（UA, Proxy, B2BUA），它为实现从简单的呼叫转移到复杂的多方通话、预付费等各种增值业务，提供了标准化的架构模式。
  3. 它连接了数据与行为: 它清晰地定义了S-CSCF与HSS之间的数据依赖关系，将TS 23.008中定义的那些静态的IMS用户数据（如iFC），与S-CSCF在处理会话时动态的行为，紧密地联系在一起。

TS 23.218是任何想要深入理解VoLTE/VoNR如何工作、IMS增值业务如何开发的工程师，都绕不开的一本核心技术“圣经”。它所定义的这套业务触发与控制框架，至今仍在5G和未来的通信网络中，继续扮演着“中央调度系统”的关键角色。

FAQ环节

Q1：iFC（初始过滤规则）和我们在防火墙里配置的规则有什么区别？ A1：它们在思想上有相似之处（都是“if-then”规则），但应用层面和复杂性完全不同。

  • 防火墙规则: 通常工作在IP层（三/四层），主要基于IP地址、端口、协议等进行“允许”或“拒绝”的动作。
  • iFC: 工作在SIP应用层（七层），它的触发点（SPT）可以极其丰富和精细，例如“SIP方法是INVITE”、“请求的URI中包含特定参数”、“某个特定的Header存在”等等。它的动作，也远不止于拒绝，而是复杂的“将信令转发给某个AS进行处理”。可以说，iFC是专门为SIP信令流程编排而设计的一种高级“脚本语言”。

Q2：S-CSCF和AS（应用服务器）的区别是什么？为什么需要两者？ A2：S-CSCF是**“通用平台”，AS是“专业应用”**。

  • S-CSCF: 负责所有用户通用的会话控制功能，如用户注册、认证、状态管理、路由。它的功能是固定的、标准化的。
  • AS: 负责实现特定的、增值的业务逻辑，如彩铃、语音信箱、多方通话等。AS的功能是多样化的、可快速迭代和创新的。 这种“平台+应用”的解耦架构，是IMS成功的关键。它使得核心网（S-CSCF）可以保持稳定，而运营商和第三方开发者，则可以在AS上，像开发App一样，快速地开发和部署新的通信服务，而无需改动核心网络。

Q3：规范中提到了S-CSCF, P-CSCF, I-CSCF，它们三个有什么区别？ A3：它们是IMS核心网中负责会话控制的三种不同角色的CSCF。

  • P-CSCF (Proxy-CSCF): 代理CSCF，是UE接入IMS网络的第一站。它负责安全、压缩、以及将UE的请求路由到归属网络。
  • I-CSCF (Interrogating-CSCF): 查询CSCF，是归属网络的“看门人”。它负责查询HSS，找到当前为用户服务的S-CSCF的地址，并将信令转发过去。
  • S-CSCF (Serving-CSCF): 服务CSCF，是用户的“管家”。一旦用户注册成功，所有的会话信令都将由它处理，负责执行iFC、触发业务、控制会话。TS 23.218的核心，就是围绕S-CSCF展开的。

Q4：为什么AS需要有B2BUA（背靠背用户代理）这么复杂的模式？ A4：B2BUA模式赋予了AS对通信会话的最高控制权。在Proxy（代理）模式下，AS只能“窥探”和“轻微修改”流经它的信令，但媒体流（语音、视频）仍然是在两个终端之间直接建立的。而在B2BUA模式下，AS终结了来自主叫方的呼叫，并独立地向被叫方发起一个全新的呼叫。它成为了两个呼叫的“中间人”，所有的信令和媒体流都必须经过它。这使得AS可以：

  • 控制媒体: 进行录音、混音（会议）、转码等操作。
  • 精确计费: 实时监控通话时长，用于预付费业务。
  • 隐藏拓扑: 向一方隐藏另一方的网络信息。 虽然复杂，但B2BUA是实现许多高级通信业务不可或缺的强大工具。

Q5：这份Stage 2规范，与Stage 3的协议规范（如TS 24.229）是什么关系？ A5：TS 23.218（Stage 2）是**“做什么”和“怎么做（逻辑上）”，而TS 24.229（Stage 3）是“怎么说（具体编码）”**。

  • TS 23.218: 定义了S-CSCF在收到INVITE后，需要检查iFC，如果匹配，需要向AS转发请求。
  • TS 24.229: 会详细定义，这个转发的SIP请求，其Route头应该如何填写，需要携带哪些3GPP特有的私有头（如P-Asserted-Identity），以及各个头字段的具体ABNF语法是什么。 Stage 2是架构和流程设计师看的，Stage 3是协议栈编码工程师看的。

关系图谱