好的,我们继续第四篇文章的深度拆解。这一章是规范的精华部分,内容较长,我们将按照规划,首先聚焦于 4.1 架构性问题

深度解析 3GPP TR 33.937:4.1 Architectural Issues (架构性问题)

本文技术原理深度参考了3GPP TR 33.937 V18.0.0 (2024-03) Release 18规范中,关于“Chapter 4.1 Architectural Issues”的核心章节,旨在为读者深入剖析构建IMS网络反骚扰体系(PUCI)时,必须面对的核心架构抉择与挑战。

引言:从“是什么”到“怎么建”,李雷的架构师之问

在前几章的学习中,我们的工程师李雷已经成功掌握了PUCI的“基础语言”。他清楚地知道了PUCI要对抗的敌人是“非请所求通信(UC)”,也了解了这项研究背后的知识体系。现在,他不再满足于仅仅理解概念,而是开始以一名“系统架构师”的视角来思考一个更深层次的问题:

“如果我是运营商,要为千千万万像我一样的用户构建一个强大的PUCI防护系统,我该从何入手?这个系统应该是什么样子的?它的‘大脑’应该放在哪里?它的‘哨兵’应该如何部署?它又该如何与友军(其他运营商)协同作战?”

这正是3GPP TR 33.937第四章System Environment for PUCI所要回答的核心问题。本篇文章,我们将聚焦于4.1节Architectural Issues,跟随李雷的探索,一步步揭开PUCI系统设计的神秘面纱,理解其中最重要的架构模型与设计权衡。

1. 宏伟蓝图:UC防护金字塔模型

规范在4.1.1节的引言中,首先抛出了一个极具洞察力的模型,它为整个UC防护体系的建设提供了宏观指导。

This clause tries to give an overview about UC prevention techniques, tries to classify them and to discuss the architectural impacts on IMS. Figure 4.1-1 shows seven levels of UC prevention, ordered by complexity and impact on IMS from the base to the top of the pyramid.

深度解析:

这段引言的核心是通过分类和分层的方式,来梳理UC的防护技术。规范原文中的“Figure 4.1-1: UC Prevention ordered by complexity and impact on IMS”清晰地展示了这个被称为“UC防护金字塔”的模型。它告诉我们,一个有效的PUCI体系,绝非单一技术的堆砌,而是一个多层次、多维度、从社会到个人、从非技术到技术的纵深防御体系。

让我们跟随李雷的视角,自下而上地攀登这座金字塔:

  • 第1层:法律法规 (Legislation):这是金字塔的基石。国家立法,明确定义什么是骚扰通信,并对发送者施以惩罚。这是最根本的威慑。
  • 第2层:运营商控制的环境 (Operator controlled environment):李雷与运营商签订的服务合同、运营商的服务策略(Policies)和服务等级协议(SLAs),都构成了这一层。运营商可以通过合同条款,禁止其网内用户发送骚扰信息。
  • 第3层:重用DoS防护机制 (Re-use of DoS protection mechanisms):在网络边界,可以通过限制单个用户的并发呼叫数或呼叫建立速率,来初步遏制大规模的骚擾呼叫,这类似于网络安全中的拒绝服务攻击(DoS)防护。
  • 第4层:网络支持的用户自我保护 (Network supported user self protection):这是李雷最熟悉的。他通过手机App或运营商门户设置的黑白名单 (black-/white listing),就属于这一层。网络提供了这个能力,由用户自己来配置。
  • 第5层:用户到网络的反馈 (UC feedback user-to-network):当李雷接到一个骚扰电话后,通过按键或App上的按钮,向运营商举报“这是骚扰!”。这个反馈机制是构建更智能系统的关键输入。
  • 第6层:网络到用户的UC评分 (UC score network-to-user):金字塔的高级阶段。网络侧通过大数据分析和机器学习(基于第5层的用户反馈等),对每一通来电进行智能评分。当一个可疑电话打给李雷时,他的手机屏幕上可能会显示“提醒:85%可能为骚扰电话”。
  • 第7层:自动化防护 (Automated UC protection):这是金字塔的顶端,也是最理想的状态。网络根据极高的骚扰评分(比如超过99%),在骚扰电话到达李雷手机之前,就自动将其拦截或转入语音信箱,实现了“无感”防护。

这个金字塔模型不仅展示了防护手段的多样性,其垂直轴的“复杂度/对IMS的影响”和水平轴的“非技术/技术措施”划分,更是揭示了深刻的工程哲学:越是底层的、非技术的手段,覆盖面越广,是体系的根基;越是顶层的、智能化的技术,效果越好,但实现也越复杂,对现有网络的影响也越大。

2. 系统的核心:识别(I)与评分(S)

在理解了宏观模型后,规范进一步将技术系统内部的核心功能抽象为两个部分:

In the following discussions UC score delivering equipment is regarded to be composed of two parts:

  1. A UC Identification part (I) that gathers and provides UC relevant information, necessary to estimate a UC score
  2. A UC Scoring part (S) that processes the information, gathered by the Identification part, according to a UC algorithm and delivers as result a UC score to be provided to the terminating user

深度解析:

这里将一个PUCI技术实体,比作一个“侦探审判”系统:

  • 识别模块 (Identification, I):扮演“侦探”的角色。它的任务是收集线索,例如:主叫号码、来电频率、用户举报历史、呼叫行为模式等所有与判断是否为骚扰相关的信息。
  • 评分模块 (Scoring, S):扮演“法官”的角色。它接收“侦探”收集来的所有线索,然后依据一套“法律”(即评分算法),对这次通信进行审判,最终给出一个量化的“判决结果”——UC分数。

这个I/S模型是后续所有架构讨论的基础。PUCI系统的所有架构差异,本质上都可以归结为:“侦探”和“法官”应该由谁来当?他们应该驻扎在哪里?他们是应该各自为政,还是应该统一指挥?

3. 哨兵的部署:源端 vs. 终端网络?(4.1.2)

第一个核心的架构抉择是:PUCI的分析(即I和S模块)应该部署在骚扰发起的源网络(Originating Network),还是接收骚扰的终端网络(Terminating Network)

This section discusses whether UC scoring should be located in the UC originating network or in the UC terminating network.

深度解析:

这个问题至关重要,它直接关系到PUCI系统的有效性和可靠性。规范通过“Figure 4.1-2: Originating/Terminating UC functionality”生动地展示了不同场景下的优劣。

让我们用李雷的经历来分析:

  • 场景一:骚扰源在李雷自己的运营商网络内(源端评分)

    • 优点:这是最理想的情况。运营商可以百分之百确认骚扰者的真实身份(因为是网内用户),并且可以获取最全面的信令、媒体和行为信息。此时,“侦探(I)”掌握的线索最充分,“法官(S)”的判决自然最准确。运营商还可以直接通过合同对骚扰者进行处罚。
    • 结论:在源网络进行UC识别和评分,最有效、最可靠
  • 场景二:骚扰源来自一个外部不受信任的VoIP网络(终端评分)

    • 挑战:这是最现实、也是最棘手的挑战。当这个骚扰电话跨过网络边界到达李雷的运营商网络时,李雷的运营商面临着巨大难题:
      1. 身份不可信:主叫号码极有可能是**伪造(Spoofed)**的。一个来自美国的诈骗电话,可能伪装成一个本地号码。
      2. 信息不完整:终端网络无法获取骚扰者在源网络的行为历史,线索严重不足。
    • 危险:如果在这种情况下,终端网络强行基于不可信的号码进行评分和建立信誉库,会产生灾难性后果。攻击者可以通过伪造无辜用户的号码来发送骚扰,导致这些无辜用户的号码被错误地打上“骚扰”标签,正常通信受到影响。这被称为“信誉攻击”。
    • 结论:在终端网络进行UC识别和评分,困难重重,且风险极高

The conclusion of the discussions above is that UC identification and scoring would be most effective and reliable in the UC originating network. But terminating networks can’t rely on that, if connected to potentially un-trusted networks.

最终的结论形成了一个两难的困境:最理想的评分地点在源端,但终端无法信任来自源端(尤其是不可信网络)的评分结果。这个根本性的矛盾,是PUCI乃至整个通信安全领域需要不断努力解决的核心问题之一。

4. 权力之争:中央集权 vs. 地方自治?(4.1.3)

接下来的问题是,PUCI的功能实体(I和S模块)在网络中应该如何部署?是每个运营商都部署一套完整的、自给自足的系统,还是应该有一个跨运营商的中央权威机构?

4.1.3.1 分布式识别与评分 (Distributed UC Identification and Distributed UC Scoring)

a largely distributed UC prevention approach is shown in ETSI TR 187 009… This approach assumes that every scoring entity communicates their scores to the entities further down the communication path.

深度解析:

这是“地方自治”模型。每个运营商网络(甚至网络中的不同节点)都部署自己的I和S模块。当一个呼叫跨网传递时,每一级都会进行自己的评分,并将分数传递下去。

  • 场景模拟:一个骚扰电话从运营商A发出(评分为30),经过中转运营商B(B根据自己的算法,重新评分为50),最终到达李雷所在的运营商C(C再评分为80)。
  • 问题:“Figure 4.1-3”和“Figure 4.1-4”展示了这种模式的弊端:
    1. 成本高昂:需要在多个位置部署PUCI设备。
    2. 评分不一致:由于各厂商的算法不同,同一个呼叫在不同网络会得到不同的分数,让最终的策略执行变得混乱。李雷的手机到底该相信哪个分数?
    3. 信令复杂:需要在SIP信令中设计复杂的机制来传递和协商这些可能相互冲突的评分。

4.1.3.2 分布式识别与中央评分 (Distributed UC Identification and Central UC Scoring)

A possibility to overcome one of the main disadvantages of a distributed approach is to centralize the scoring part… operated by a neutral organization.

深度解析:

这是“中央集权”或“最高法院”模型。

  • 工作模式:每个运营商网络只部署“侦探(I)”模块,负责收集线索。然后,所有运营商都将收集到的线索信息,上报给一个中立的、跨运营商的中央评分中心。这个中心拥有唯一的“法官(S)”模块,它综合所有线索,给出一个权威的、唯一的UC分数。
  • 优点
    1. 评分一致:由于只有一个“法官”,判决结果自然是统一的,解决了分布式评分不一致的问题。
    2. 潜在成本较低:评分算法和数据库只需维护一份。
  • 挑战
    1. 法律与隐私问题:运营商将其用户的通信数据上报给一个第三方中立机构,会面临极其严格的法律、监管和用户隐私挑战。
    2. 商业模式:谁来运营这个中立机构?如何保证其公正性?运营成本如何分摊?这是复杂的商业问题。
    3. 额外流量:上报线索会产生额外的网络信令开销。

5. 算法之辩:标准化 vs. 厂商私有 (4.1.4)

最后一个架构问题,与评分算法(即“法官”的“法典”)有关。评分算法应该是全球统一标准,还是可以由各设备厂商自由发挥?

Another question is whether the scoring algorithms are standardized or whether they can differ, depending on the vendor of the UC equipment.

深度解析:

  • 标准化算法

    • 优点:在分布式模型下,如果算法是标准的,那么不同厂商设备给出的评分结果将是(理论上)一致的。
    • 缺点:骚扰技术日新月异,标准化的算法更新周期长,难以灵活应对新的攻击手段。同时,这也会扼杀厂商在算法上的技术创新。
  • 厂商私有算法

    • 优点:厂商可以快速迭代自己的算法,保持对新型骚扰的识别能力,形成差异化竞争优势。
    • 缺点:在分布式部署模型下,这会直接导致前述的“评分不一致”问题。如“Figure 4.1-6”所示,一个SIP消息在网络中穿行,可能会被贴上各种不同厂商给出的、含义不明的评分标签(high, med, low…),最终让接收方无所适从。

总结:没有银弹,唯有权衡

通过对4.1节“架构性问题”的深度探索,李雷终于明白了,构建一个PUCI系统远非想象中那么简单。它不是一个纯粹的技术问题,而是一系列复杂的战略抉择。运营商必须在以下几个维度之间做出艰难的权衡:

  • 信任与效率:如何在依赖源端高效评分与应对终端身份不可信的矛盾中找到平衡?
  • 集中与分布:如何在追求评分一致性(中央模式)与保护数据主权/隐私(分布模式)之间做出选择?
  • 标准与创新:如何在确保互操作性(标准化算法)与鼓励技术快速迭代(私有算法)之间找到最佳结合点?

这些问题没有唯一的正确答案,TR 33.937的作用正是将这些“选择题”清晰地摆在业界所有玩家的面前。它为我们描绘了PUCI战场的复杂地形,并指出了通往胜利的几条可能路径,以及每条路径上的机遇与陷阱。


FAQ 环节

Q1:UC防护金字塔模型对我们有什么实际的启发? A1:它最大的启发在于强调了“纵深防御”的系统思想。它告诉我们,不能将所有希望寄托于单一的技术解决方案。一个健康的通信环境需要法律的威慑、运营商的有效管理、网络的基础防护能力、以及用户便捷的反馈工具和智能的自动化系统共同作用。对于个人用户,这意味着除了依赖运营商,自己养成良好的举报习惯也非常重要。

Q2:源端评分和终端评分的矛盾,在现实中有解决方案吗? A2:有,这正是业界努力的方向。一个典型的成功案例是北美的STIR/SHAKEN框架。它并非一个评分系统,而是一个主叫号码身份认证系统。它通过密码学技术,让源网络可以对主叫号码进行数字签名,终端网络则可以验证这个签名,从而确认号码的真实性,极大地解决了“身份伪造”这个核心痛点。STIR/SHAKEN可以看作是实现可信评分的前提和基石。

Q3:中央评分中心听起来很理想,为什么现实中很难看到? A3:主要障碍在于非技术层面。首先是法律和隐私,跨运营商共享用户通信元数据在许多国家(尤其是欧盟GDPR法规下)都面临着巨大的法律合规障碍。其次是商业信任,各大运营商是竞争关系,要让他们将核心数据交由一个第三方机构处理,需要建立极高的商业信任,并解决复杂的成本分摊和责任界定问题。

Q4:既然分布式评分存在不一致的问题,那它还有意义吗? A4:仍然有巨大意义。在无法建立中央评分中心的情况下,分布式评分是唯一可行的技术路径。虽然跨网评分存在不一致,但在单个运营商网络内部,其评分体系可以做到一致和有效。运营商可以主要依赖自己网络内的信息(如网内用户的行为、用户对所有来电的举报)来构建自己的PUCI能力,这已经能解决很大一部分问题。对于跨网来话,即使评分不一致,也可以作为一种参考,或者通过双边协议来约定评分的语义。

Q5:厂商私有算法和标准化,未来会如何发展? A5:很可能会走向一种混合模式。即,对传递评分的“信令格式”和“评分语义”进行标准化,而对评分的“生成算法”保持开放。例如,标准可以定义一个0-100的分数区间,并规定90-100分为“高可信骚扰”,0-10分为“高可信正常通话”。这样,所有设备都能理解分数的含义。至于这个分数具体是如何计算出来的(是基于机器学习还是规则引擎),则可以由各厂商作为其核心竞争力自由发挥。