51学通信

深度解析 3GPP TR 33.896：5 Key issues (Part 2 - 统一框架与执法指南：寻求“用户同意”的终极之道)

18分钟阅读

好的，这是系列文章的第五篇。在前两个关键问题的基础上，我们将探讨一个更具普适性、旨在从根本上解决“用户同意”管理难题的KI#3和提供策略指导的KI#4。

深度解析 3GPP TR 33.896：5 Key issues (Part 2 - 统一框架与执法指南：寻求“用户同意”的终极之道)

本文技术原理深度参考了3GPP TR 33.896 V18.0.1 (2023-06) Release 18规范中，关于“Chapter 5.3 Key Issue #3”和“Chapter 5.4 Key Issue #4”的核心章节，旨在为读者深度剖析当前5G“用户同意”机制在管理上的“碎片化”困境，以及3GPP如何探索构建一个统一、集中的同意管理框架，并为运营商提供策略制定的指导原则。

引言：美美的“管理噩梦”

在上一篇文章中，我们的主角美美，通过她在漫游和NTN场景下的经历，揭示了“用户同意”在跨越地域和架构边界时的执行难题。现在，随着她的5G生活日益丰富，一个新的、更深层次的问题开始困扰着她。

她发现，自己手机里有数十个应用和服务，都在以各种方式使用着她的网络数据。有的用于智能推荐，有的用于网络优化，有的用于广告推送。她在不同的时间，为这些服务分别点击过“同意”。但现在，她陷入了一场“管理噩梦”：

  • 她不记得自己到底同意了什么：哪个App有权访问她的位置？哪个服务可以分析她的通话习惯？她完全没有一个统一的视图。
  • 她不知道如何精准地撤销：她想关闭A应用的广告推荐，但不想影响它的核心功能。她想撤销对B服务的授权，但她不确定这个服务的背后，到底关联了哪些网络功能（NF）和应用功能（AF）。
  • 她不相信撤销是彻底的：即使她在一个App里点击了“撤销”，她也无法确信，那些已经获取了她数据的、隐藏在网络深处的无数个“数据消费者”，是否真的都收到了指令并停止了处理。

美美的这场“管理噩梦”，正是Key Issue #3 (统一框架) 所要解决的核心痛点。而她对于“哪些服务到底需不需要我同意”的困惑，则是Key Issue #4 (执法指南) 试图解答的策略性难题。

KI#3将视角从特定的场景（漫游、NTN），提升到了一个通用的、体系性的高度。它直指当前用户同意管理机制的根本性缺陷——碎片化与不可追溯。

1.1 问题的核心：一场“各自为政”的管理混乱 (5.3.1 Key issue details)

User consent is stored in the UDM/UDR. All NFs/AFs need to retrieve the consent flag from the UDM… However, not all NFs/AFs do contact UDM before collecting data. …the same consent checking is necessary at multiple places/NFs. Furthermore, keeping track of revocation and which NF has received which UE-related user consent details seems to become tedious. TS 33.501 clause V.2 states that user consent revocation service is not provided by UDM.

这段话一针见血地指出了三大痛点：

  1. 查询的“多点开花”：理论上，每个需要数据的NF/AF都应该自己去UDM查询用户同意。这导致了重复的信令开销和在网络中多处重复的检查逻辑。更糟糕的是，规范承认，并非所有NF/AF都会真的去查，这就留下了巨大的安全隐患。
  2. 撤销的“通知黑洞”：这是最致命的缺陷。UDM作为“同意”的存储者，却不提供“撤销通知”服务（revocation service is not provided by UDM）。它就像一个只存钱不提供取款通知的银行。这意味着，当美美在UDM中更新了她的同意状态（例如，从“同意”变为“不同意”）时，那些之前已经查询过并获得了“同意”状态的NF/AF，完全不知情。
  3. 追踪的“不可能任务”：由于缺乏统一的管理，网络无法**追踪（keeping track）**到底有哪些NF/AF已经获取了美美的数据授权。这使得“撤销”操作，变成了一场“大海捞针”——你根本不知道需要去通知谁。

This key issue looks into the benefits of a unified framework such as a central function or a service for coordinating and keeping track of user consent retrieval, notification, and revocation.

核心问题：我们是否应该引入一个统一的、中心化的框架，来专门负责协调和追踪所有与用户同意相关的检索、通知和撤销？

1.2 安全威胁：“僵尸授权”的持续侵害 (5.3.2 Security threats)

When user consent needs to get revoked, all NFs/AFs that have asked for user data beforehand need to revoke them. Otherwise, there is the danger that some NFs/AFs are not tracked and thus not informed… This can result in accessing user-related data by NFs/AFs even after revocation by the user.

  • 威胁：僵尸授权 (Zombie Authorization)
    • 场景：美美撤销了对某个智能推荐服务的授权。但由于缺乏通知机制，该服务关联的某个AF，因为没有被追踪到（not tracked），所以没有被通知（not informed）。
    • 后果：这个AF如同一个持有“过期授权”的“僵尸”，仍在持续地访问和处理美美的用户数据，用户的撤销权形同虚设，隐私侵害仍在发生。

1.3 安全需求：“一个都不能少”的通知义务 (5.3.3 Potential security requirements)

The 5GS shall ensure that all NFs/AFs that collected user consent related data are notified.

  • 需求：5G系统**必须（shall）**确保，所有曾经收集过用户同意相关数据的NF/AF，在同意状态发生变更时，都能被通知到。

这个需求，为后续的Solution #5（引入中心化的UCA NF）提供了最直接的“军令状”。它要求系统必须具备状态追踪和主动推送的能力，从根本上解决“通知黑洞”的问题。

如果说KI#3探讨的是“如何管理同意”，那么KI#4则回到了一个更本源、更具哲学性的问题：“何时需要同意”。

2.1 问题的核心：缺乏指导原则的“灰色地带” (5.4.1 Key issue details)

As depicted in Annex V.1.1 in TS 33.501, “user consent can be required for 3GPP features depending on local regulations.” It means that user consent … is conditional and configurable based on operator’s local policy… However, there is no guidance to determine for what information user consent is required and for what information user consent is not required, or how to enforce user consent…

  • 现状的模糊性：现有的规则非常“模糊”和“有弹性”。它只是说，“是否需要同意，取决于当地法规和运营商策略”。
  • 缺乏指导（no guidance）：对于一个运营商来说，当3GPP发布一个新的网络功能时，它很难判断：这个功能收集的数据，是否达到了需要用户明确同意的“阈值”？在法律的灰色地带，该如何做出既合规又有利于业务发展的决策？

美美的困惑：

  • “网络为了优化我的通话质量而收集无线信号数据，需要我同意吗？”
  • “网络为了预测网络拥塞而分析我的上网习惯，需要我同意吗？”
  • “这些问题的答案，在A国和B国是一样的吗？”

…it may be helpful to provide some general principles for these purposes.

核心问题：我们是否能提供一些通用的指导原则（general principles），来帮助运营商更好地、更一致地决定何时以及如何去执行用户同意？

2.2 安全威胁与需求 (5.4.2 & 5.4.3)

Not applicable.

  • 深度解析：有趣的是，规范在这两节明确写下了“不适用”。这说明KI#4本质上不是一个会直接导致“安全漏洞”的技术问题，而是一个策略性、合规性的问题。它的目标不是修复一个漏洞，而是提供一个“决策框架”，来避免未来可能出现的法律风险和用户信任危机。因此，它没有直接对应的“安全威胁”，其“安全需求”本身，就是“提供指导原则”这一诉求。

3. 总结：从“战术修补”到“顶层设计”的升华

通过对KI#3和KI#4的深度剖析，美美，以及我们，都看到了3GPP在“用户同意”这个课题上思考的升华。

  • KI#1和#2，更像是“战术层面的修补”。它们针对漫游、NTN等具体场景，对现有框架进行“打补丁”，解决的是“如何执行”的问题。
  • KI#3和#4，则进入了“战略和顶层设计”的层面。
    • KI#3 (统一框架)，试图从架构上，彻底重构“用户同意”的管理模式，解决的是“如何高效、可靠地管理”的问题。它追求的是体系的健壮性。
    • KI#4 (执法指南)，试图从策略上，为“用户同意”的适用范围提供指导，解决的是“何时应该启动管理”的问题。它追求的是决策的一致性与合规性。

这两个关键问题，共同将TR 33.896的研究，从解决具体的技术难题，推向了构建一个高内聚、低耦合、权责清晰、策略透明的、面向未来的“用户同意治理体系”的宏大目标。它们旨在为美美这样的用户，提供一个不仅功能强大，而且真正可信、可控、可理解的5G数字生活。

FAQ 环节

Q1：KI#3提出的“统一框架”是不是意味着要引入一个全新的网元？ A1：是的，这是最主要的可能性之一。后续的Solution 5就明确提出了引入一个UCA NF (User Consent Authorization NF) 的想法。这个UCA NF将作为全网的“用户同意服务中心”，所有其他NF/AF不再直接与UDM交互，而是向UCA NF请求“用户同意令牌”，并向UCA NF订阅“撤销通知”。这虽然增加了新网元，但极大地简化了其他所有NF/AF的逻辑，实现了“高内聚、低耦合”的优秀架构设计。

Q2：为什么UDM自己不提供“撤销通知”服务？ A2：这涉及到网元设计的“职责单一原则”。UDM的核心职责是作为一个高可靠、高性能的“数据库”，负责安全地存储和响应用户数据的查询/更新请求。而“撤销通知”则需要一个复杂的**“发布-订阅”机制**，需要追踪和管理大量的订阅者（NF/AF），并主动推送通知。将这两种不同性质的功能耦合在一个网元中，会大大增加UDM的复杂性和风险。因此，将“通知”功能剥离出来，由一个专门的网元（如KI#3设想的中心化服务）或由NF/AF自己订阅来实现，是更合理的架构选择。

Q3：KI#4想提供的“指导原则”可能会是什么样子的？ A3：这些原则可能会基于数据的敏感度和使用目的来进行分级。例如：

  • 原则一（强烈建议同意）：凡是涉及用户高敏感个人身份信息（如精确位置、身份ID）的收集，或涉及跨境数据传输的，都应强制要求用户明确同意。
  • 原则二（建议同意）：凡是涉及对用户个人行为进行画像的分析（如上网习惯、移动模式），建议要求用户同意。
  • 原则三（可不要求同意）：凡是只使用完全匿名化、聚合化的网络统计数据，用于提升网络服务质量的，可以不要求用户明确同意，但在隐私政策中应予以告知。 这些原则，将为运营商在面对模糊的法律条文时，提供一个可参考的“行业最佳实践”。

Q4：这些Key Issues都是在Rel-18的TR 33.896中提出的，它们在后续的标准化中有没有得到解决？ A4：是的，这些研究正在逐步转化为实际的标准。例如，针对KI#3中提出的撤销通知问题，后续的3GPP版本（如Rel-18及以后）中，对UDM的服务（Nudm）和相关流程进行了增强，引入了订阅变更通知的机制，使得NF/AF可以订阅用户数据的变更（包括同意状态的变更），从而部分解决了“通知黑洞”的问题。这体现了TR（研究）向TS（规范）的转化过程。

Q5：这些Key Issues的研究，对我作为应用开发者（AF开发者）有什么影响？ A5：影响深远，它预示着您未来与运营商网络打交道的方式将更加规范和可控。

  1. 统一的入口：未来您可能不再需要关心数据到底存在哪个NF，而是只需要与一个统一的“用户同意中心”（如UCA NF）打交道，来获取数据访问授权。
  2. 强制的通知：您的应用必须能够处理来自网络的“同意撤销”通知。一旦收到通知，必须立即停止对相关用户数据的处理和存储，否则将面临合规风险。
  3. 清晰的规则：KI#4的研究，将使得运营商对于“哪些API调用需要用户同意”的规则更加清晰和一致，减少了您在开发过程中的不确定性。

关系图谱