51学通信

深度解析 3GPP TR 33.896：5 Key issues (Part 1 - 漫游与NTN：跨越边界的同意难题)

19分钟阅读

好的，这是系列文章的第四篇。我们将进入规范的核心——对四大关键问题（Key Issues）的深度剖析。由于内容较多，我们将首先聚焦于前两个，也是最具场景性的KI#1和KI#2。

深度解析 3GPP TR 33.896：5 Key issues (Part 1 - 漫游与NTN：跨越边界的同意难题)

本文技术原理深度参考了3GPP TR 33.896 V18.0.1 (2023-06) Release 18规范中，关于“Chapter 5.1 Key Issue #1”和“Chapter 5.2 Key Issue #2”的核心章节，旨在为读者深度剖析在5G漫游和非地面网络（NTN）这两种“跨越边界”的场景下，“用户同意”机制所面临的独特安全威胁与核心挑战。

引言：美美的“同意”去哪儿了？

在之前的文章中，我们的主角美美的全球5G之旅，为我们引出了“用户同意”在复杂场景下的诸多难题。现在，作为一名严谨的研究者，美美决定将她的亲身经历，转化为两个清晰、具体的技术问题，向3GPP的专家们“提问”。

问题一 (漫游)：“当我在B国漫游时，我的数据在我的归属运营商（HPLMN）和当地运营商（VPLMN）之间传来传去。我当初在HPLMN点击的‘同意’，在这条跨越国境和法律边界的数据链条上，是如何被传递、被验证、被执行的？如果我撤销了同意，远在B国的VPLMN能及时知道吗？”

问题二 (NTN)：“当我在茫茫大海上使用卫星通信（NTN）时，卫星基站为了对准我而要求获取我的精确位置。这个请求，是否需要我的同意？这个同意，又是如何从遥远的核心网‘飞’到天上的卫星，并由它来执行的？”

美美的这两个“灵魂拷问”，正是TR 33.896第五章中，Key Issue #1 (漫游) 和 Key Issue #2 (NTN) 所要探讨的核心。今天，我们将跟随美美，深入剖析这两道难题，理解“跨越边界”给用户同意带来的颠覆性挑战。

1. 概览：在开始之前 (4 Overview)

在进入具体的Key Issues之前，第四章Overview为我们提供了一些重要的背景信息，定下了整个第五章的基调。

In TS 33.501, The framework includes storage requirements for the UDM as well as generic services for user consent check and revocation. For any such feature, the framework requires the identification, in the standards, of a special NF called the user consent enforcement entity. However, the case that the enforcement entity and UDM belong to different legal domains … has not been considered so far.

深度解析：

这段话点出了Phase 2研究的核心出发点：

  1. 已有基础：我们已经有了一个基础框架——“同意”存在UDM里，由一个指定的“同意执行点（user consent enforcement entity）”来负责检查。
  2. 核心空白：但这个框架，一直以来都隐含地假设：“执行点”和UDM都属于同一个运营商，在同一个法律管辖区内。
  3. 本次挑战：TR 33.896要研究的，正是当“执行点”和“UDM”分属**不同法律域（different legal domains）**时，这个框架该如何工作。这正是漫游场景的核心矛盾。

KI#1聚焦于漫游场景下的网络自动化（eNA），其本质是HPLMN与VPLMN之间的跨网数据交换。

2.1 问题的核心 (5.1.1 Key issue details)

As depicted in key issue #3 in TR 23.700-81, “In roaming scenario, the HPLMN/VPLMN may need to collect data or consume analytics from the VPLMN/HPLMN.” In this case, the user data may be exchanged between different entity, i.e. VPLMN and HPLMN, that may be subject to different regulations with respect to user consent.

规范定义了两种主要的数据交换场景：

  1. HPLMN从VPLMN“取”数据：HPLMN（美美的归属运营商）的某个应用（H-Consumer NF），想要获取美美在VPLMN（B国运营商）网络中的数据或分析结果。
  2. VPLMN从HPLMN“取”数据：反之，VPLMN的某个应用，需要从HPLMN获取关于美美的数据。

美美的困境： 在这两种场景下，数据的收集方、处理方和最终消费方，分属于两个不同的国家，它们受不同的隐私法规约束。这就构成了一场复杂的“数据罗生门”。

In order to cover these scenarios, it is important to assess the current user consent framework in Annex V in TS 33.501, and decides who will perform the role of enforcement point.

核心问题：在这样的跨域场景下，那个神圣的“同意执行点（enforcement point）”到底应该是谁？ 是HPLMN的某个NF，还是VPLMN的某个NF？

2.2 安全威胁：被忽视的“同意” (5.1.2 Security threats)

如果这个问题处理不好，将直接导致严重的安全威胁。

If the HPLMN/VPLMN is not aware to check user consent for roaming case for eNA… [it] may expose user privacy information… If the HPLMN/VPLMN is not aware to revoke user consent… [it] may continue to process user privacy information…

  1. 威胁一：无视同意，非法暴露：
    • 场景：HPLMN向VPLMN请求数据，但VPLMN的网元没有意识到（is not aware）或者没有能力去检查美美在HPLMN的UDM中是否同意了此事，就直接将数据给了HPLMN。
    • 后果：用户的隐私数据在未经同意的情况下被跨境传输，造成隐私泄露。
  2. 威胁二：无视撤销，非法处理：
    • 场景：美美通过HPLMN的App撤销了她的同意。但由于缺乏有效的通知机制，远在B国的VPLMN没有意识到这个变化，仍在继续收集和处理美美的数据。
    • 后果：用户的撤销权被架空，隐私侵害仍在持续。

2.3 安全需求：跨越PLMN的“检查”与“撤销” (5.1.3 Potential security requirements)

为了应对这些威胁，KI#1提出了两大必须满足的安全需求：

The 5GS shall provide the means for a HPLMN/VPLMN to check of user consent for the roaming scenario in eNA. The 5GS shall provide the means for HPLMN/VPLMN to revoke of user consent for the roaming scenario in eNA.

  1. 需求一：5G系统必须（shall）提供一种机制，让HPLMN和VPLMN能够检查漫游场景下的用户同意。
  2. 需求二：5G系统必须（shall）提供一种机制，让HPLMN和VPLMN能够撤销漫游场景下的用户同意。

这两个需求，为后续的解决方案（如Solution #3, #4）指明了方向：必须设计一套跨PLMN的、标准化的信令流程，来安全地传递和同步“用户同意”的状态。

KI#2将我们的视线从横跨国境的地面网络，拉向了垂直贯穿天地的卫星网络。

3.1 问题的核心 (5.2.1 Key issue details)

…the NG-RAN in NTN may require UE’s location information for selecting the AMF. …after AS security is activated, the NG-RAN in NTN can request the UE to report its accurate location or coarse location. However, for both types of location reports obtaining, user consent aspect is missing.

  • 核心场景：在NTN中，NG-RAN（卫星基站）为了进行AMF选择、波束赋形等操作，需要获取UE（美美的手机）的高精度或粗略的位置信息。
  • 核心矛盾：现有的流程允许NG-RAN去请求这个位置，但整个流程中，**缺少（missing）**了对“用户同意”的检查环节。这是一个架构上的“设计缺陷”。

This key issue is intended to study whether there is any need to enhance the current user consent framework specified in Annex V in TS 33.501 in order to support the NTN feature.

核心问题：我们是否需要**增强（enhance）**现有的用户同意框架，来专门支持NTN这个特性？具体来说，如何将存储在CN侧UDM中的“用户同意”，安全地传递给远在RAN侧的“执行点”——NTN-RAN？

3.2 安全威胁：RAN侧的“隐私黑洞” (5.2.2 Security threats)

If the NG-RAN in NTN is not aware of user consent status, then the NG-RAN in NTN may collect user’s location information without consent… If the NG-RAN in NTN is not aware that user consent for NTN use case has been revoked, then the NG-RAN in NTN may continue to collect user’s location information…

威胁模型与KI#1高度相似，但发生的地点从“VPLMN”转移到了“NG-RAN”。

  1. 威胁一：无视同意，非法收集：如果NG-RAN不知道用户的同意状态，它可能会在用户不同意的情况下，擅自向UE发起位置信息请求。
  2. 威胁二：无视撤销，非法持续收集：如果用户撤销了位置授权，但NG-RAN没有及时得到通知，它可能会继续要求UE上报位置。

3.3 安全需求：将“用户同意”注入网络 (5.2.3 Potential security requirements)

The network should take into account the user consent for NTN usage when user subscribes to NTN services considering NTN regulatory requirements.

  • 需求：网络**应该（should）**在用户签约和使用NTN服务时，**考虑到（take into account）**用户的同意，并遵守NTN相关的法规。

这个需求，为后续的解决方案（如Solution #1, #2）指明了方向：必须设计一套从CN到RAN的信令流程，在UE初始接入或移动时，就将“用户同意”的状态，像“注入剂”一样，注入到AMF，再由AMF注入到NG-RAN的UE上下文中。

4. 总结：边界的突破，挑战的升级

通过对KI#1和KI#2的深度剖析，美美，以及我们，都深刻地理解了“跨越边界”给用户同意带来的颠覆性挑战。

  • KI#1（漫游），挑战的是“法律边界”。它要求我们在两个平等的、分属不同主权的PLMN之间，建立一套可信的数据交换和同意同步机制。这里的核心是互信和合规。
  • KI#2（NTN），挑战的是“架构边界”。它要求我们在核心网（CN）和无线接入网（RAN）这两个不同的架构层级之间，建立一条安全的、自上而下的授权指令通道。这里的核心是协同和执行。

这两个关键问题，共同将“用户同意”的研究，从一个静态的、核心网内部的配置问题，推向了一个动态的、跨域的、端到端的流程管理问题。它们迫使我们去思考，在一个日益融合、无远弗届的5G世界里，“用户同意”这份数字时代的“授权书”，如何才能真正具备普遍、持久且可追溯的效力。

FAQ 环节

Q1：在漫游场景下，为什么“同意执行点”的角色难以确定？ A1：因为数据流和法律管辖权是交织在一起的。

  • 如果HPLMN作为执行点：它最了解用户的原始同意，但它不了解VPLMN当地的法规，也无法直接控制VPLMN的数据收集行为。
  • 如果VPLMN作为执行点：它最了解本地的法规，可以直接控制本地的数据收集，但它无法直接、可信地访问HPLMN的UDM来获取用户的原始同意。 因此，解决方案往往需要一个协作机制，例如，由VPLMN作为最终的执行点，但它在做决策前，必须通过标准化的接口，向HPLMN发起一个“用户同意检查”请求。

Q2：对于NTN场景，为什么不能让UE在响应RAN的位置请求时，自己先检查一下用户的同意呢？ A2：这是一个很好的问题，涉及到“策略执行点应该在哪”的设计哲学。让UE自己来执行，有几个弊端：

  1. UE不可信：从网络管理的角度看，UE是不可信的。一个被破解或恶意的UE，可能会伪造同意状态，绕过网络控制。
  2. 管理复杂：运营商难以集中管理和审计数以亿计的UE上的策略。
  3. 用户体验：每次RAN请求位置，都可能需要在UE上弹窗，骚扰用户。 将执行点放在网络侧（RAN），由CN进行集中授权，更符合电信网络“集中控制、可信管理”的设计原则。UE的角色，更多是安全地存储和上报其在UDM中配置的“同意”决策。

Q3：KI#1的需求是“shall”（必须），而KI#2的需求是“should”（应该），这有什么深意吗？ A3：这通常反映了3GPP在制定需求时的严谨性。

  • “shall” 通常用于定义一个强制性的、没有商量余地的基本安全要求。跨PLMN的数据交换，涉及到法律和主权问题，其风险极高，因此必须建立检查和撤销机制。
  • “should” 则通常用于一个强烈的建议，但在某些特殊情况下，可能允许有替代方案。NTN作为一个仍在快速演进的新特性，在制定需求时可能会留有一定的灵活性。但从实际效果来看，两者都指明了必须解决的方向。

Q4：这两个KI都提到了“撤销（revoke）”，为什么“撤销”比“检查”更难实现？ A4：“检查”是一个一次性的、请求-响应式的操作，流程相对简单。而“撤销”是一个状态同步的问题，它要求系统具备“记忆”和“通知”的能力。

  • 记忆：系统需要记住，当初有哪些NF或AF，基于用户的“同意”，获取了数据。
  • 通知：当用户撤销同意时，系统必须能够找到所有这些“记忆”中的实体，并向它们主动推送一个“撤销”通知。 在分布式、跨域的环境下，可靠地实现这个“记忆”和“通知”的链条，技术挑战非常大。这正是KI#3试图用一个“统一框架”来解决的核心难题。

Q5：这些Key Issues的研究，最终会如何改变我的漫游和卫星通话体验？ A5：最终，它将为你带来更安全、更透明的体验。

  • 更清晰的授权：未来你在开通漫游数据分析或NTN服务时，可能会看到更具体、更清晰的隐私授权条款，明确告知你哪些数据将被用于何种目的。
  • 更可靠的控制：你的“同意”或“拒绝”将被更可靠地执行。当你拒绝VPLMN收集你的数据时，你将更有信心这个指令会被遵守。
  • 更便捷的撤销：当你撤销一项授权时，你将能确信所有相关方都会停止使用你的数据。 这一切，都是为了确保在技术为你带来“无界连接”的同时，你对个人数据的“主权”边界，依然清晰和牢固。

关系图谱