好的，这是系列文章的第十三篇。我们将进入第九章，将前面所有的理论分析和方案评估，最终凝聚成一幅可实施的、具体的PUCI系统架构蓝图。

深度解析 3GPP TR 33.937：9 Potential PUCI Architecture (潜在PUCI架构)

本文技术原理深度参考了3GPP TR 33.937 V18.0.0 (2024-03) Release 18规范中，关于“Chapter 9 Potential PUCI Architecture”的核心章节，旨在为读者将前面章节中碎片化的概念、需求与方案，整合为一幅清晰、具体的IMS网络PUCI功能部署架构图，理解PUCI的“大脑”和“感官”在网络中的最佳位置。

引言：李雷的“施工蓝图”

经过了漫长而深入的研究，从威胁分析到方案评估，我们的工程师李雷，如今已经胸有成竹。他不再是那个面对骚扰电话束手无策的用户，也不再是那个在各种技术方案间迷茫的架构师。他现在是一位手握“施工蓝图”的总工程师，准备将PUCI从一个抽象的概念，真正地“建造”到IMS网络中去。

李雷面前的这张“施工蓝图”，就是TR 33.937的第九章 Potential PUCI Architecture。这一章的核心任务，不再是“为什么”和“是什么”，而是“在哪里”和“如何做”。它系统性地回答了PUCI功能在复杂的IMS网络中，应该如何部署、如何分工、以及如何协同工作的核心工程问题。

今天，我们将跟随李雷，一砖一瓦地解读这张蓝图。我们将看到PUCI的功能实体是如何映射到IMS的网元上的，并深入探讨关于“中央集权 vs. 地方自治”、“源端防御 vs. 终端拦截”等最终的、决定性的架构抉择。

1. 宏观架构：PUCI功能在IMS网络中的“安家落户” (9.1 High-level architecture)

第九章开篇，就通过一幅极其重要的架构图，直观地展示了PUCI功能（PUCIF）在IMS网络中的几种可能的部署方式。

In this section we outline a high-level PUCI architecture to describe how PUCI functionality can be mapped to the IMS architecture. This high-level architecture is illustrated in Figure 9.1-1.

深度解析：

规范原文中的“Figure 9.1-1: Mapping of PUCI functionality to IMS architecture”是本章的灵魂。它清晰地描绘了PUCI的“大脑”——PUCIF (PUCI Functionality)——可以在IMS网络中“安家落户”的几个关键位置。

让我们把IMS网络想象成一个国家的“通信管理体系”，那么PUCIF就是新成立的“反骚扰总局”。现在的问题是，这个总局的办公楼应该建在哪里？

• 方案A：作为独立的应用服务器 (Separate AS)

  • 架构描述：PUCIF作为一个独立的、专门的应用服务器（AS）存在，通过标准的ISC接口与S-CSCF（服务-呼叫会话控制功能）进行交互。
  • 工作流程：当一个呼叫到达S-CSCF时，S-CSCF根据用户的签约信息（iFC - initial Filter Criteria），将该呼叫路由到这个PUCI AS。PUCI AS对呼叫进行分析、评分，然后将带有UC指示（如UC Score）的呼叫返回给S-CSCF，由S-CSCF继续后续处理。
  • 优点：逻辑清晰，功能独立，易于升级和维护。PUCI的功能内聚性高，对其他业务AS的影响最小。

• 方案B：与补充业务AS集成 (Integrated with SS AS)

  • 架构描述：PUCIF的功能，被集成到已经提供补充业务（如黑白名单、呼叫转移）的应用服务器（SS AS）中。
  • 工作流程：S-CSCF将呼叫路由到这个“增强型”的SS AS。该AS在执行传统的黑白名单逻辑的同时，也执行更智能的PUCI分析。
  • 优点：可以充分复用现有的补充业务逻辑和用户数据，实现平滑演进。对运营商来说，可能只是对现有AS的一次软件升级，部署成本较低。

• 方案C：在CSCF中实现 (Realized in a CSCF)

  • 架构描述（图中以虚线框表示）：将PUCIF的核心功能，直接内置到S-CSCF中。
  • 优点：处理效率最高。因为S-CSCF是呼叫控制的核心，将PUCI功能内置可以减少一次ISC接口的外部路由，降低延迟。
  • 缺点：这是最不推荐的做法。S-CSCF作为IMS的“中央交换机”，其核心使命是保持稳定、高效的路由。在其中加入复杂、频繁变动的应用逻辑（如PUCI算法），会严重影响其性能和稳定性，并且升级维护极其困难。

李雷的选择： 作为总工程师，李雷很快就做出了判断。方案C风险太高，首先排除。方案A和B各有千秋：方案A更适合从零开始建设一个强大、独立的PUCI系统；方案B则更适合在现有补充业务平台的基础上，进行渐进式的智能化升级。运营商可以根据自己的现状和战略进行选择。

此外，图中还展示了**内容检测（Content Inspection）**功能，它可以部署在媒体路径上（由MRF - Media Resource Function承载），用于检测恶意媒体内容，这是对信令层面PUCI的有力补充。

2. 部署模式之辩：再次聚焦“中央 vs. 分布” (9.2 Centralized/Distributed PUCI AS)

在确定了PUCIF的基本部署位置后，规范再次回到了我们在4.1.3节中已经深入探讨过的核心架构抉择：PUCI的智能分析能力（即识别和评分），应该是“中央集权”还是“地方自治”？

From these the ‘centralized per operator’ approach is favored for IMR-based UC prevention in IMS. The reasons for this recommendation are…

深度解析：

在第八章的评估之后，第九章在这里给出了一个明确的、结论性的建议：对于基于IMR的PUCI防护，推荐采用“按运营商集中（centralized per operator）”的模式。

这意味着：

• 否定了“完全分布式”：那种在接入网、传输网等所有环节都进行评分的模式被否定了。因为它成本高、评分不一致，且很多非SIP感知的网络节点根本不具备此能力。
• 否定了“跨运营商的中央中心”：那种由一个中立的第三方机构来运营一个全球评分中心的理想化模式，也因为其巨大的法律、隐私和商业障碍而被认为在现实中不可行。
• 肯定了“运营商内部的中央大脑”：最佳实践是，每个运营商在自己的网络内部，部署一个（或逻辑上统一的）中央PUCI AS。这个AS负责处理本网内所有用户的PUCI逻辑。当需要与其他运营商交互评分信息时，再通过运营商之间的接口进行。

李雷的蓝图： 这张蓝图现在更加清晰了。他决定为自己的运营商设计一个逻辑上统一的PUCI平台。所有用户的骚扰举报都汇集到这里，所有来电的智能评分都在这里计算，所有用户的个性化防护策略都在这里存储和执行。这是一个属于运营商自己的“反骚扰数据和智能中心”。

3. 战场选择：源端 vs. 终端 (9.4 Originating/Terminating UC identification and prevention)

这是PUCI架构的另一个终极抉择，我们在4.1.2节中也曾探讨过。现在，规范基于更全面的分析，给出了更具体的建议。

Another important issue in this TR is whether UC identification and prevention will be done in the originating or in the terminating network. For this issue it is important to differentiate between UC identification and UC prevention:

规范在这里做了一个非常精妙的区分，它将PUCI拆分为了“识别”和“预防”两个不同的动作，并为它们分别推荐了最佳的执行地点。

3.1 UC识别 (UC Identification)：最佳地点在源端

For technical UC identification the originating network can extract advantages from the fact that it is able to authenticate its users, to take measures against forged sender identities… As a consequence the originating network is best suited for technical UC detection and is therefore clearly recommended.

• 结论：技术性的UC识别（即判断一个呼叫是否为骚扰），最理想的执行地点是发起呼叫的源网络。
• 理由：源网络拥有无可比拟的“情报优势”。它知道主叫的真实身份、历史行为、套餐信息… 所有这些都是进行精准识别的关键输入。
• 但书：规范也承认，终端网络不能无条件信任来自源网络（尤其是不受信任网络）的识别结果。因此，终端网络也需要具备自己的识别能力，但有一个绝对的前提——至少源网络的身份必须是可被可靠认证的。否则，终端网络的识别就如同建立在流沙之上，极易受到信誉攻击。

3.2 UC预防 (UC Prevention)：最佳地点在终端

UC prevention in the terminating network may be very useful. The reasons are:

• Whether a call can be rated as UC or not depends largely on the user perception which is by nature individual.
• Another important reason for terminating UC prevention is of legal nature. … The callee has to give explicit consent for that.

• 结论：UC预防（即根据识别结果，决定是拦截、转接还是放行），最理想的执行地点是接收呼叫的终端网络。
• 理由：
  1. 用户个性化：“骚扰”的定义是高度主观和个人化的。对A来说是骚扰的推销电话，对B来说可能正是他需要的信息。只有在最靠近用户的终端网络，才能最好地执行用户自己定义的、个性化的拦截策略。
  2. 法律授权（Consent）：根据大多数国家的法律，拦截一个用户的来电，是需要得到该用户（被叫方）的明确同意的。将“预防”动作放在被叫方归属的终端网络，最容易获取和证明这种法律授权。

李雷的最终架构： 李雷的“施工蓝图”最终成型了。这是一个分工明确、协同作战的体系：

• 全球协同识别：理想情况下，呼叫在离开源网络时，就应该已经被初步识别和标记。
• 终端自主决策：呼叫到达终端网络后，终端网络可以结合源网络的标记、自身的识别结果、以及用户的个人设置，最终做出预防（拦截/放行）决策。

这就像一个现代化的多级导弹防御系统：远程雷达（源网络）进行早期预警和目标识别，近程指挥中心（终端网络）则根据本地的防空策略和最高指令，最终决定是否发射拦截弹。

4. 实时性与标准化 (9.5 & 9.6)

最后，规范还对实时性和标准化问题给出了结论性的指导。

• 实时性 (Real-time / non-real-time)：
  • UC识别，如果只是用于运营商内部的数据分析，可以非实时进行。
  • 但只要涉及到UC预防，则必须实时进行。因为预防动作必须在被叫用户的电话响铃之前完成，否则骚扰已经造成，预防就失去了意义。
• 标准化 (Standardized versus Vendor specific)：
  • 评分算法本身，无需标准化，这可以留给厂商进行创新和竞争。
  • 但用于传递评分或上下文信息的信令机制，则需要标准化，以保证不同厂商、不同运营商设备之间的互操作性。

5. 总结：一幅清晰、务实且具有前瞻性的PUCI架构蓝图

第九章，作为整篇TR的收官之章，成功地将前面所有的分析、评估和权衡，收敛到了一幅清晰、务实且具有前瞻性的PUCI架构蓝图上。

• 部署位置：PUCI的核心功能（PUCIF）应作为AS部署，独立或与SS集成。
• 部署模式：推荐采用“按运营商集中”的模式，构建运营商自己的PUCI大脑。
• 功能分工：源端网络是识别的最佳地点，终端网络是预防的最佳地点。
• 执行要求：预防动作必须实时完成，传递UC指示的信令需要标准化。

这张蓝图，为像李雷这样的工程师，提供了将PUCI从概念付诸实践的权威指南。它平衡了理想与现实，在追求极致安全的同时，充分考虑了成本、兼容性和法律风险，体现了3GPP作为世界顶级标准组织的深厚工程智慧。

---

FAQ 环节

Q1：为什么规范强烈不推荐在S-CSCF中实现PUCI功能？ A1：S-CSCF是IMS网络的“路由心脏”，其核心职责是根据用户的签约数据（iFC）进行稳定、高效、可预测的SIP信令路由。它的设计目标是“高可靠、高性能、低复杂度”。PUCI功能，特别是基于IMR的智能分析，其逻辑复杂多变，算法需要频繁更新以应对新的威胁，这与S-CSCF的设计哲学背道而驰。将PUCI放入S-CSCF，会严重污染其核心功能，增加故障风险，并使得升级维护变得极其困难。

Q2：“按运营商集中”的部署模式，如何解决跨运营商的骚扰问题？ A2：这种模式下，跨运营商骚扰的防治依赖于运营商之间的协作和信息共享。例如，运营商A和运营商B可以通过双边协议，约定相互交换关于可疑号码的“上下文信息”（CI）。当一个来自A网的呼叫到达B网时，A网可以在信令中附带一个由A网生成的CI标签（如Identity-Strength: strong）。B网的PUCI系统在做决策时，可以将这个来自“友军”的情报作为重要的参考。这种模式虽然不如“全球中央中心”那样统一，但它更灵活，也更容易在现实的商业环境中落地。

Q3：将“识别”放在源端，“预防”放在终端，这个分工在技术上如何实现？ A3：这需要一个标准化的信令机制来传递“识别”的结果。具体来说，源网络的PUCI AS在识别出一个呼叫有骚扰嫌疑后，会在发出的SIP INVITE消息中插入一个特殊的头域，例如 P-Asserted-UC-Indication: score=85; type=spam。这个INVITE消息穿越互联网，到达终端网络。终端网络的PUCI AS或S-CSCF解析出这个头域，获取到“骚扰分数为85”这个信息，然后结合被叫用户的个人设置（例如“拦截所有分数高于80的电话”），最终做出拦截（预防）的决定。

Q4：既然UC预防必须实时，这对PUCI AS的性能提出了什么要求？ A4：极高的要求。PUCI AS必须在极短的时间内（通常是几十到几百毫秒）完成对一个呼叫的完整分析和评分。这意味着它需要：1. 高性能的硬件。2. 高效的算法，不能进行过于耗时的计算。3. 高速的缓存和数据库访问，用于实时查询号码的信誉、行为历史等信息。4. 高可用性和可扩展性，能够处理全网每秒成千上万次呼叫的并发分析请求。

Q5：这份架构蓝图提出后，后续的标准化工作会是什么？ A5：这份蓝图会直接催生一系列具体的标准化工作立项（Work Item）。例如：1. 信令扩展：标准化用于携带CI或UC Score的SIP头域。2. 接口协议：如果PUCI AS需要与外部信誉数据库等实体交互，需要标准化相关的接口协议（如Diameter或HTTP/RESTful）。3. 补充业务增强：可能需要对现有的通信限制（CB）等补充业务的规范进行修订，使其能够理解和利用新的UC指示信息。这些后续的TS（技术规范），才是工程师们在开发产品时直接参考的“法律文本”。