51学通信

深度解析 3GPP TR 33.937：Annex A Usability and Business Aspects (可用性与商业考量)

20分钟阅读

好的，这是系列文章的第十四篇。我们已经完成了对PUCI核心技术架构的解读，现在，我们将深入探讨那些决定一项技术最终成败的“软实力”——可用性与商业考量。

深度解析 3GPP TR 33.937：Annex A Usability and Business Aspects (可用性与商业考量)

本文技术原理深度参考了3GPP TR 33.937 V18.0.0 (2024-03) Release 18规范中，关于“Annex A (informative): Usability and Business Aspects”的核心章节，旨在为读者揭示一个技术上完美的PUCI解决方案，为何可能在现实世界中，因糟糕的用户体验或不切实际的设备假设而最终失败。

引言：当“完美蓝图”遭遇“灵魂拷问”

在前面的长篇探索中，我们的总工程师李雷，已经成功绘制了一幅堪称完美的PUCI系统“施工蓝图”。这幅蓝图融合了补充业务的稳健、IMR+CI的智能以及未来强认证的前瞻，在技术层面无懈可击。他满怀信心地将这份蓝图，提交给了公司的产品和用户体验（UX）部门。

然而，他迎来的并非预想中的掌声，而是一连串尖锐的“灵魂拷问”：

  • 产品经理：“李雷，你的系统每次都弹出一个‘骚扰风险提示框’，用户会不会觉得烦，没几天就把它关了？”
  • UX设计师：“你这个举报流程，在最新的旗舰手机上很炫酷，但在我们那几百万老年用户使用的功能机上能用吗？”
  • 市场总监：“你的方案要求用户做这么多选择，学习成本太高了。我们怎么向市场推广一个‘很安全但很难用’的功能？”

这些问题，让李雷猛然惊醒。他意识到，一个产品的成功，技术只占一半，另一半，甚至更重要的一半，在于人——用户是否愿意用、是否会用、是否用得爽。他设计的“完美”系统，如果忽略了对人性和现实商业环境的洞察，最终可能只会成为一个无人问津的“屠龙之技”。

这正是TR 33.937在正文之外，特意加入附录A Usability and Business Aspects 的深意所在。它像一面镜子，照见了技术理想与用户现实之间的鸿沟。今天，我们就将跟随李雷，直面这些“灵魂拷问”，深入探讨决定PUCI成败的“最后一公里”。

1. 用户提示的“双刃剑” (A.1.1 User Prompting)

PUCI系统中一个非常常见的设计，就是当检测到可疑来电时，向用户弹出一个提示框，让用户来做最终决定。这种做法，看似是将“选择权”交给了用户，但在附录A看来，这是一把需要被极其谨慎使用的“双刃剑”。

User prompting is a very popular method to shift the security decision responsibility to the user. Often it is assumed that the user decisions are

  • well-educated i.e. all the users know what they are doing
  • consistent i.e. the user makes the same decision in same circumstances
  • without error i.e. the user makes no mistakes From practical experience it is known, that those assumptions do not hold in many cases.

深度解析：

这段话无情地戳破了许多工程师心中对“理想用户”的幻想。我们常常假设用户是理性的、专注的、不出错的。但现实是，用户是忙碌的、易疲劳的、凭感觉的。

1.1 “提示疲劳”与“惯性点击”

Excessive user prompting may result in a “click through” behavior of the user and makes potential attacks (e.g. phishing attacks, installation of malicious software or acceptance of a security risk) much easier. Also, excessive user prompting is a known to impact the user experience severely (i.e. annoy the user).

  • 李雷的“失败设计”： 李雷的初版设计是：每当一个UC分数介于60-90分的“中风险”来电，手机屏幕就会弹出一个对话框：“来电号码XXX，骚扰概率75%，是否接听？[接听] [挂断] [转语音信箱]”。
  • 用户的真实反应：
    • 第一天：李雷兴致勃勃，对每一个弹窗都认真分析，做出审慎的决策。
    • 一周后：他每天要处理十几次这样的弹窗。当他正在开车、开会、或者急着接一个重要电话时，这些弹窗就成了极其碍事的“拦路虎”。他不再细看内容，只想尽快让它消失，于是开始下意识地、惯性地点击“接听”。
    • 危险降临：某一天，一个经过精心伪装的网络钓鱼（Vishing）电话打来，PUCI系统准确地给出了“80%风险”的提示。但处于“提示疲劳（prompt fatigue）”状态的李雷，毫不犹豫地进行了“惯性点击（click through）”，接听了电话，最终一步步落入了骗子的圈套。

结论： 规范明确指出，过度的用户提示，不仅会严重骚扰用户，更会训练出用户的“惯性忽略”行为，从而让真正的安全威胁，在用户的“亲手许可”下长驱直入。一个本想增强安全的机制，最终反而打开了安全的大门。

1.2 设计原则：克制与智能

Therefore, user prompting should be a method to be used in quite moderate dose. The terminal and the network can support the user to protect himself from UC.

李雷的反思与优化： 他重新审视了自己的设计，决定遵循“克制与智能”的原则：

  1. 提高提示阈值：只对那些系统高度不确定（例如，分数在70-80分之间），且潜在危害巨大的（例如，疑似金融诈骗）的极少数情况，才进行弹窗提示。
  2. 提供智能默认选项：对于大部分中风险来电，不再打扰用户，而是自动执行一个更安全的默认操作，比如直接转入语音信箱，并给用户发送一条事后通知：“一个疑似骚扰来电已被转接，您可以稍后在语音信箱中收听”。
  3. 网络与终端协同：让网络（AS）承担更多的自动化决策，让终端（UE）的交互界面尽可能简洁、无打扰。

2. 用户与终端的“鸿沟” (A.1.2 User vs UE)

另一个致命的设计陷阱，是将“用户”和他的“设备”想当然地等同起来，忽略了现实世界中设备形态的巨大差异。

In this technical report the term user and UE are often regarded as one entity. … It should be taken into consideration, that the input and output means of devices varies widely. High end devices might be able to provide the user with full configuration means, but other devices may not offer such means.

深度解析：

工程师在设计功能时，脑海中浮现的往往是自己手中那台最新款的、拥有巨大高清触摸屏的旗舰智能手机（High end devices）。但现实是，全球数十亿用户，使用的设备千差万别。

2.1 “鸿沟”的体现

  • 李雷的“想当然”： 他设计了一个功能丰富的PUCI设置界面，用户可以在App里通过拖动滑块，来精细化地设定不同风险等级的拦截策略，还可以查看详细的骚扰来电分析报告。这个设计在最新的iPhone上运行得非常流畅。
  • 现实的挑战：
    1. 低成本设备 (Low-cost range)：市场上存在大量的低成本安卓手机，它们的屏幕小、性能弱，运行李雷这个复杂的设置App会非常卡顿，甚至无法安装。
    2. 功能机/老年机：这些设备根本没有智能操作系统，只有物理按键和小尺寸的非触摸屏。它们无法安装App，也无法显示复杂的图形界面。
    3. 物联网设备 (IoT Devices)：李雷未来的PUCI系统还需要保护家里的智能音箱、车载电话等。智能音箱没有屏幕，车载电话的交互则必须遵循“安全第一”的极简原则。

这条从“旗舰机”到“功能机”再到“物联网设备”的巨大鸿沟，如果不能被有效跨越，那么PUCI的保护能力将是支离破碎、无法普及的。

2.2 设计原则：化繁为简与网络赋能

Still the user should be protected hence other complementing approaches need to be found then direct user interaction.

李雷的反思与优化： 他意识到，不能将所有配置和交互的复杂性都推给终端。PUCI的设计必须“化繁为简”，并更多地依赖网络侧的智能。

  1. 简化终端交互：对于举报功能，除了App内点击，还应该支持更普适的方式，例如，在通话结束后，让用户可以通过拨打一个简单的USSD码（如*#...#）来举报刚才的来电。
  2. 网络侧用户画像：运营商可以在网络侧，基于用户的通话习惯、举报历史、签约套餐等信息，为用户建立一个用户画像，并据此自动配置一套合理的、个性化的默认防护策略。大部分用户甚至无需进行任何手动设置，就能获得“开箱即用”的良好防护。
  3. 分层体验：为不同类型的设备，提供不同层级的交互体验。旗舰机用户可以享受功能丰富的App；而功能机用户，则可以通过短信或USSD码，完成最核心的黑名单设置和举报操作。

3. 总结：从“技术思维”到“产品思维”的升华

附录A虽然简短，却给李雷，也给我们带来了极其深刻的教益。它标志着一次从纯粹的“技术思维”到真正的“产品思维”的升华。

  • 技术思维追求的是功能的强大与正确：“我的算法识别率达到了99.9%！”
  • 产品思维追求的是用户的价值与体验：“我的功能用户愿意用、喜欢用，并真切地感受到了它带来的安全感。”

附录A的核心启示是：

  1. 尊重用户的认知负荷：不要用过度的提示去打扰用户，更不要高估用户在安全决策上的专业性和耐心。让系统更智能，让用户更省心。
  2. 尊重设备的多样性：不要用旗舰机的标准去要求所有设备。一个好的设计，必须具备普适性和包容性，能够在最受限的硬件条件下，依然提供核心的保护价值。

在完成了对附录A的学习后，李雷的“施工蓝图”上，又增添了浓墨重彩的一笔。这一笔，不再是冷冰冰的技术框图，而是充满了对人性洞察和现实关怀的、温暖的“用户体验地图”。

FAQ 环节

Q1：什么是“提示疲劳 (prompt fatigue)”，它在日常生活中有哪些例子？ A1：“提示疲劳”是指用户在长期、反复地收到同类提示信息后，逐渐对其变得麻木、忽略甚至厌烦，从而在不做深入思考的情况下，习惯性地执行某个默认操作（如点击“同意”或“关闭”）。日常生活中的例子比比皆是：

  • 软件权限申请：安装App时，面对一长串的权限申请，很多人会不看内容直接“全部同意”。
  • 网站Cookie同意：几乎所有网站都会弹出Cookie使用声明，绝大多数用户会直接点击“接受”以消除弹窗。
  • Windows用户账户控制(UAC)：在早期版本的Windows中，频繁的UAC弹窗导致大量用户选择直接关闭该功能。

Q2：既然不应过度提示用户，那PUCI系统该如何获取用户的反馈来优化自身呢？ A2：关键在于将“主动骚扰”变为“被动征求”和“事后确认”。

  • 被动征求：不打断用户当前任务。例如，系统可以在用户挂断一个可疑电话后，发送一条非打扰性的通知（如闪信或状态栏通知）：“您刚才接听的XXX号码疑似骚扰，是否需要举报或加入黑名单？”
  • 事后确认：系统可以定期（如每周）向用户推送一份“反骚扰周报”，其中列出本周拦截的骚扰电话列表，并询问用户“我们的拦截是否准确？”，用户可以进行简单的“是/否”反馈。
  • 简化操作：提供极其简单的反馈方式，如在通话记录中长按某个号码，即可弹出“举报”选项。

Q3：附录A提到的“User vs UE”问题，对5G时代的物联网（IoT）安全有什么启示？ A3：启示巨大。物联网设备（UE）的数量将是人（User）的数十倍甚至上百倍，且绝大多数物联网设备都是“无界面”的（没有屏幕和键盘）。因此，为这些设备设计安全方案，几乎完全不能依赖“用户交互”。其安全必须是内生的、自动化的、由网络侧集中管控的。例如，一个共享单车的智能锁，其通信行为模式是高度可预测的。网络一旦发现它试图访问一个非法的服务器，或者其流量异常，就应该立即将其隔离，而不是“提示”用户。

Q4：一个好的PUCI产品，在“可用性”上应该具备哪些特质？ A4：应该具备以下特质：

  1. 默认开启且有效：用户在开通服务时，就应该能获得一个合理的、基于大数据分析的默认防护，而不是需要用户自己去摸索和配置。
  2. 无扰体验：尽可能在用户无感知的情况下，在网络侧完成骚扰的拦截。
  3. 可信透明：当系统进行拦截或提示时，应以简洁明了的方式告知用户原因（如“根据超1万用户举报”），建立用户对系统的信任。
  4. 易于干预：当用户需要时（如发现误拦），必须提供一个极其简单、直观的渠道，让用户可以修正系统的行为（如“一键信任此号码”）。
  5. 普适兼容：无论用户使用何种终端，都能享受到核心的防护能力和反馈渠道。

Q5：为什么一份技术报告（TR）要去讨论“商业考量（Business Aspects）”？ A5：因为技术的最终目的是要服务于商业和社會，创造价值。一项技术如果无法形成可持续的商业模式，或者其部署成本远超其带来的收益，那么它就很难被产业界所采纳，最终只会被束之高阁。3GPP作为一个产业联盟，其制定的标准必须具备商业上的可行性。在TR阶段就对商业考量进行探讨，可以帮助技术方案在早期就规避掉那些“叫好不叫座”的路径，确保最终形成的TS（技术规范）是能够被市场接受和大规模部署的。

关系图谱