51学通信

深度解析 3GPP TR 33.896：6 Solutions (Part 1 - 天地对话：NTN场景下用户同意的获取与撤销)

18分钟阅读

好的，这是系列文章的第六篇。我们已经全面剖析了四大关键问题，现在，我们将深入第六章，看看3GPP的专家们是如何针对这些难题，提出具体、可行的解决方案。本文将首先聚焦于为NTN场景量身定制的Solution 1和2。

深度解析 3GPP TR 33.896：6 Solutions (Part 1 - 天地对话：NTN场景下用户同意的获取与撤销)

本文技术原理深度参考了3GPP TR 33.896 V18.0.1 (2023-06) Release 18规范中，关于“Chapter 6.1 Solution #1”和“Chapter 6.2 Solution #2”的核心章节，旨在为读者深度剖析在非地面网络（NTN）这一特殊场景下，5G系统如何巧妙地设计信令流程，将“用户同意”的权威指令，从核心网安全地传递到无线接入网，并确保其状态能够被动态、可靠地更新。

引言：美美的“卫星SOS”——当同意需要跨越星辰

在之前的探索中，我们的主角美美在邮轮上接入NTN（卫星通信）时，遇到了一个核心难题：卫星基站（NTN-RAN）为了更好地为她服务，需要获取她的精确位置，但这个过程却缺少了“用户同意”的检查环节。这正是KI#2所揭示的架构“缺陷”。

现在，美美将化身为一名“流程设计师”，与3GPP的专家们一起，为这场需要跨越星辰大海的“天地对话”，设计一套完整、安全、闭环的信令流程。她需要回答两个核心问题：

  1. “同意”如何“下凡”？ 当美美的手机第一次接入NTN网络时，存储在核心网UDM中的“同意/不同意获取位置”的指令，是如何一步步传递到天上的卫星基站的？
  2. “撤销”如何“上达天听”？ 当美美在航行途中，决定不再允许卫星网络获取她的位置时，这个“撤销”的意愿，又是如何从她的手机，逆向传递回UDM，并确保天上的卫星能“令行禁止”的？

这两个问题，正是Solution #1 (同意的获取) 和 Solution #2 (同意的撤销) 所要给出的答案。今天，我们将深入这两个解决方案，通过对信令流程图的逐一拆解，理解这套精妙的“天地对话”机制。

0. 准备工作：解决方案与关键问题的“匹配” (6.1 Mapping of solutions to key issues)

在进入具体方案前，6.1节的Table 6.1-1首先为我们提供了一张“解决方案导航图”，清晰地展示了本章提出的各个解决方案，分别对应了第五章的哪个关键问题。

SolutionsKI#1 (Roaming)KI#2 (NTN)KI#3 (Unified)KI#4 (Guidance)
Solution #1: User consent obtained by the NTN-RANX
Solution #2: User consent revocation obtained by the NTN-RANX
…

这张表一目了然地告诉我们，Solution 1和2是专门为KI#2 (NTN) 设计的“靶向药”。

本方案旨在解决KI#2的第一个需求：如何在UE接入时，让NTN-RAN能够获取到用户的同意状态。

1.1 核心思想：AMF作为“中枢信使”

…it is proposed that the user consent information is provisioned by the UDM at the earliest possibility to the AMF, i.e. during Registration procedure… The AMF can store the received user consent preference in the UE context, which further provisions the user consent preference to the NTN-RAN.

深度解析：

方案的核心思想，是确立AMF（接入和移动性管理功能）作为这场“天地对话”的核心中继和地面总控。

  • 最早的时机：在UE发起网络**注册（Registration）**的初始阶段，就完成同意状态的传递。
  • 关键路径：UDM -> AMF -> NTN-RAN。
    1. UDM是“最高指令源”，存储着用户的原始同意配置（例如，在一个专门的“UE NTN隐私配置文件”中）。
    2. AMF是“地面总控”，它在UE注册时，从UDM“领取”这份指令，并将其缓存在UE的上下文中。
    3. NTN-RAN是“前线执行者”，AMF再通过N2接口，将这份指令“下发”给NTN-RAN。

1.2 流程详解：Figure 6.1.2-1 的一步步拆解

让我们跟随美美的手机接入卫星网络的过程，来一步步走完这张信令图：

  • Step 1-2: UE发起注册，RAN请求“政审”

    • 美美的手机（UE）向卫星基站（NTN-RAN）发送Registration Request。
    • NTN-RAN在向AMF转发这个请求时，会额外捎带一个信息：UE Context Request for user consent preference。这相当于RAN在对AMF说：“这是个NTN用户，请帮我查一下她的‘政审’材料（用户同意状态）”。

  • Step 3-7: AMF执行“政审”，从UDM调取档案

    • Step 3: AMF收到请求，识别出这是一个NTN接入场景。它首先检查自己的本地缓存（UE context）里，是否已经有美美的同意信息。
    • Step 4-6: 如果没有，或者信息已过期，AMF就会启动“调档”程序。它向UDM发送Nudm_SDM_Get Request，请求获取美美的“NTN隐私配置文件”。UDM查询后，通过Get Response将同意参数（例如，“允许获取粗略位置”）返回给AMF。
    • Step 7: AMF将从UDM获取的这份“权威档案”存储到自己的UE上下文中。

  • Step 8-9: AMF“下发”指令，RAN领命

    • Step 8: AMF向NTN-RAN发送N2 Message (e.g. Initial Context Setup Request)，其中除了常规的注册接受信息，还包含了关键的user consent preference。
    • Step 9: NTN-RAN收到这份“尚方宝剑”后，将其存储在自己的UE上下文中，并清楚地知道了：“对于美美这个用户，我有权（或无权）获取她的位置信息”。

  • Step 10-15: RAN“依法”办事

    • 现在，NTN-RAN可以“依法”行事了。
    • 如果收到的指令是“同意”，那么NTN-RAN就可以在后续流程中，通过RRCReconfiguration（Step 10）或UEInformationRequest（Step 14）等方式，名正言顺地向UE请求位置信息。
    • 如果收到的指令是“不同意”，那么NTN-RAN就不会发送任何请求位置的配置或信令。

美美的安心：她看到，通过这套严密的流程，她对自己位置信息的控制权，从遥远的UDM，被一环不扣地传递到了天上的卫星。她的“同意”，成为了卫星能否“看见”她的唯一凭证。

本方案旨在解决KI#2的第二个需求：当用户撤销同意时，如何确保NTN-RAN能够及时停止相关操作。

2.1 核心思想：AMF作为“订阅者”与“通知者”

…this solution proposes that the AMF subscribes to the UDM for user consent parameter change notification or revocation notification, which then informs the NTN-RAN at which the UE is camped.

深度解析：

这个方案巧妙地利用了5G服务化架构中的“订阅-通知”机制，来解决KI#3中提到的“通知黑洞”问题。

  • AMF的角色升级：AMF不再仅仅是一个被动的查询者，它升级为了一个主动的“订阅者”。它会向UDM“订阅”关于美美同意状态的变更通知。
  • UDM的职责增强：UDM具备了“发布者”的能力。一旦美美的同意状态发生改变，UDM就会主动向所有订阅了此服务的NF（这里是AMF）推送一条通知。
  • 关键路径：UE/Portal -> UDM -> AMF -> NTN-RAN。

2.2 流程详解：Figure 6.2.2-1 的一步步拆解

让我们想象美美在邮轮的甲板上，通过手机App撤销了位置授权：

  • Step 1-2: AMF提前“订阅”，用户发起“撤销”

    • Step 1: 在美美注册或移动更新时，AMF就已经通过Nudm_SDM_Subscribe服务，向UDM订阅了美美的用户同意变更通知。
    • Step 2: 美美通过App或运营商门户，发起了“撤销同意”的操作。这个操作最终会导致UDM中存储的美美“NTN隐私配置文件”被更新（从“允许”变为“禁止”）。

  • Step 3-4: UDM“广而告之”，AMF收到“警报”

    • Step 3: UDM检测到数据变更，立即触发Nudm_SDM_Notification服务，向之前订阅过的AMF，发送一条“警报”：“用户美美的同意状态已更新！”
    • Step 4: AMF收到通知后，立即更新其本地缓存的UE上下文。

  • Step 5-6: AMF“火速传令”，RAN更新状态

    • Step 5: AMF立即向美美当前所在的NTN-RAN，发送一条N2 message (UE Context Modification Request)，其中包含了更新后的用户同意参数。
    • Step 6: NTN-RAN收到这份“紧急军令”后，更新其本地的UE上下文。

  • Step 7-10: RAN“令行禁止”，停止收集

    • NTN-RAN根据更新后的“禁止”指令，立即采取行动。
    • 如果之前是通过RRCReconfiguration让UE周期性上报位置的，它会立即发送一条新的、不包含位置上报配置的RRCReconfiguration消息（Step 7），UE收到后就会停止上报（Step 8）。
    • 如果之前是通过UEInformationRequest来请求位置的，它会在下一次请求时不再包含相关请求。

美美的掌控感：她看到，她的“撤销”意愿，通过一套自动化的、环环相扣的“订阅-通知-下发”链条，被迅速而可靠地执行了。她真正实现了对自己隐私的“动态掌控”。

3. 总结：一套优雅的“CN-RAN协同”范本

Solution 1和2共同为我们展示了一套极其优雅的、在CN和RAN之间进行敏感信息授权与状态同步的设计范本。

  • 权责清晰：UDM是唯一的“立法者”（存储最终策略），AMF是核心的“司法解释与命令传达者”（获取、缓存并下发策略），NTN-RAN是忠实的“一线执法者”（执行策略）。
  • 流程闭环：通过注册时的“拉取（Pull）”（Solution #1）和变更时的“推送（Push）”（Solution #2），形成了一个完整的、从授权获取到动态撤销的生命周期管理闭环。
  • 影响最小：该方案巧妙地复用了现有的注册流程和上下文修改流程，以及Nudm的订阅/通知服务，对5G系统的整体架构改动最小，具有极强的工程可行性。

这套为NTN量身定制的方案，其设计思想，对于解决未来更多需要“将核心网策略下沉到无线侧执行”的场景（如AI/ML for NG-RAN），都具有极其重要的参考价值和借鉴意义。

FAQ 环节

Q1：为什么在NTN场景下，AMF是最佳的“中枢信使”？ A1：因为AMF在5G架构中的角色定位，决定了它具备得天独厚的优势。AMF（接入和移动性管理功能）是UE与核心网之间的第一个接触点，它负责管理UE的注册、连接和移动性。这意味着：

  1. 必然经过：所有UE的信令都必须经过AMF。
  2. 上下文管理：AMF是UE在核心网中最主要上下文的“管家”。
  3. 与RAN的直接接口：AMF通过N2接口与NG-RAN直接相连。 因此，由AMF来承担“从UDM获取同意，并传递给RAN”的职责，路径最短，逻辑最顺。

Q2：Solution 1中，如果AMF的本地缓存中已经有了用户的同意信息，为什么还需要一个“有效期”检查？ A2：这是为了确保数据的新鲜度和鲁棒性。

  • 新鲜度：用户的同意状态可能会在任何时候改变。设置一个有效期（validity timer），可以强制AMF定期去UDM重新同步最新的数据，避免因为长时间使用缓存而导致策略过时。
  • 鲁棒性：如果在Solution 2的“通知”机制因为某种原因（如网络故障）失败时，定期的“拉取”可以作为一种兜底机制，最终修正不一致的状态。

Q3：Solution 2中，AMF如何知道该通知哪个NTN-RAN？ A3：AMF作为移动性管理的“管家”，它始终知道UE当前所在的跟踪区域（Tracking Area），以及正在为UE提供服务的具体的RAN节点。在Figure 6.2.2-1的Step 5中，AMF正是利用了其掌握的UE上下文中的这个动态信息，来精准地将UE Context Modification Request发送给正确的NTN-RAN。

Q4：如果用户通过手机上的“飞行模式”开关，快速地断网再重连，这套同意获取和撤销机制会如何工作？ A4：这套机制在这种场景下依然是健壮的。

  • 重连（触发注册）：当用户关闭飞行模式，手机会重新发起**注册（Registration）**流程。这将再次触发Solution 1的完整流程，AMF会从UDM获取最新的同意状态，并下发给新的RAN节点。
  • 撤销（离线更新）：如果用户在飞行模式下，通过某个离线方式修改了同意设置（虽然可能性不大，但理论上存在），这个变更会在下一次手机联网并与UDM同步时生效。一旦UDM数据更新，Solution 2的通知机制就会被触发。

Q5：这套为NTN设计的方案，是否可以直接用于解决漫游场景（KI#1）的问题？ A5：不完全可以，但思想可以借鉴。漫游场景的核心矛盾是跨法律域，即VPLMN的AMF通常无权直接访问HPLMN的UDM。因此，不能简单地照搬“AMF→UDM”的流程。但是，其“在边界节点进行策略检查和执行”的思想是相通的。漫游场景的解决方案（我们将在下一篇讨论）的核心，就是要在VPLMN和HPLMN之间，建立一个类似AMF角色的“边境联络官”（如V-Central NF），由它来负责跨越PLMN边界的“同意”信息查询和同步。

关系图谱