51学通信

深度解析 3GPP TR 23.700-28：6.18 优先级的博弈 (AF业务需求与NTN网络策略的冲突与解决)

22分钟阅读

深度解析 3GPP TR 23.700-28：6.18 优先级的博弈 (AF业务需求与NTN网络策略的冲突与解决)

本文技术原理深度参考了3GPP TR 23.700-28 V18.1.0 (2023-03) Release 18规范中, 关于“第六章 Solutions”的 6.18 节 “Solution #18: Response to Nnef_ParameterProvision request containing Maximum Latency” 的核心章节, 旨在为读者深度剖析当来自应用层（AF）的业务需求, 与网络为NTN场景精心设计的底层移动性策略发生冲突时, 3GPP如何通过建立清晰的“指挥链”, 来解决这场“优先级的博弈”。

在前一篇的探索中, 我们见证了Solution 17如何通过“事件列表”的革命性理念, 将覆盖信息服务提升到了“个性化剧本”的高度。这使得UE能够基于精准的未来预测, 主动规划自身的行为。然而, 在5G这个庞大而复杂的生态系统中, 拥有“规划权”的, 远不止UE和核心网。在遥远的云端, 那些驱动着最终业务的应用功能（AF）, 同样怀揣着自己的“时间表”和“紧迫感”。

当AF的“时间表”与网络的“时间表”发生冲突时, 谁应退让？这便是Solution 18所要裁决的一场深刻的“优先级的博弈”。它不再是关于技术“有/无”的讨论, 而是关于策略“高/低”的权衡。

为了演绎这场博弈, 我们将引入一位新的主角——“海神号”（Poseidon-1），一艘在太平洋深处执行长期自主科考任务的5G NTN深海潜航器。它的“大脑”, 是部署在地面控制中心的一套复杂的应用服务器（AF）。根据科考任务的设计, 控制中心（AF）需要至少每2小时唤醒一次“海神号”, 下发微调指令并接收一次简短的数据回传。因此, AF向核心网提出了一个明确的业务需求：“请确保‘海神号’的下行数据最大延迟不超过2小时”。

然而, “海神号”所在的深海区域, 卫星覆盖极差, 每天只有一个长达8小时的连续覆盖空窗期。为了保护潜航器的宝贵电量, 网络运营商（MME/AMF）已经为该区域的所有NTN设备, 配置了一套“深度休眠”策略, 要求它们的周期性“报到”间隔必须大于8小时。

于是, 冲突爆发了：AF的**2小时“唤醒”需求, 与网络的8小时“休眠”**策略, 如同两股迎面而来的巨浪, 猛烈地撞击在一起。谁该为谁让路？Solution 18将为我们提供一份清晰的“交战规则”。

1. 核心哲学：特殊策略优先于通用请求 (The Clash of Two Worlds)

Solution 18的核心, 是要厘清两种不同层级的网络管理机制之间的优先级关系。

1.1 机制一：网络的“特别行政区”法案 (Special NTN Configuration)

Clause 4.3.5.2 of TS 23.401 contains the following text: Tracking Area or RAT specific MME configuration can be used to support UEs using a RAN that provides discontinuous coverage… NOTE 1: For example, if a satellite system… the maximum time before a satellite passes… is 10 hours, the MME could configure the periodic TAU timer… to be greater than 10 hours.

这是网络为应对NTN非连续覆盖, 所设立的一套“特别管理法案”。

  • 管理者： MME/AMF (核心网)。
  • 管理对象： 特定区域（TAI-based）或特定接入类型（RAT-based）的UE。
  • 核心内容： AMF/MME可以无视常规的定时器配置, 强制为这些“特别行政区”内的UE, 设置超长的周期性注册定时器（如10小时）, 以匹配可预见的、漫长的覆盖空窗期。
  • 目的： 生存优先。确保UE不会在漫长的“黑夜”中, 因为频繁的无效唤醒而耗尽电量, 也避免了网络侧因UE“失联”而过早地将其上下文清除。
  • “海神号”的处境： 它所在的深海区域, 正是这样一个“特别行政区”, 被网络强制执行了“8小时休眠”法案。

1.2 机制二：应用的“跨界影响力”法案 (AF Influence via Max Latency)

Clause 4.15.6.3a of TS 23.502 contains the following text: Maximum Latency Identifies maximum delay acceptable for downlink data transfers… The UDM shall use the minimum value of Maximum Latency(s) to derive the subscribed periodic registration timer…

这是5G赋予AF的一种强大的“跨界影响力”。

  • 发起者： AF (应用服务器)。
  • 传达路径： AF → NEF → UDM。
  • 核心内容： AF可以通过Nnef_ParameterProvision服务, 向核心网的“中央数据库”UDM, 声明其业务对某个UE的“最大可容忍延迟”（Maximum Latency）。UDM收到后, 会将这个时间, 转化为对该UE周期性注册定时器的上限约束。
  • 目的： 任务优先。确保网络为UE配置的“休眠”周期, 不会过长, 以免耽误AF的业务。
  • “海神号”的处境： 它的“大脑”——地面控制中心（AF）, 正试图援引这条法案, 强制要求网络的“休眠”周期不得超过2小时。

1.3 问题的症结：法案冲突与规则真空

Currently it’s not clear whether or not the subscribed periodic registration timer that AF influences overwrites a periodic registration timer that is contained in the above-mentioned AMF configuration for discontinuous coverage…

问题的症结在于, 当UDM收到AF的Maximum Latency请求时, 它应该听谁的？

  • 听AF的： 将UE的周期性注册定时器改为2小时。后果： “海神号”在8小时的覆盖空窗期内, 会被强制唤醒至少3次。每一次唤醒, 都是一次耗电巨大且注定失败的寻网尝试。AF的“任务”意图得到了满足（理论上）, 但UE的“生存”基础却被动摇了。
  • 听AMF的： 维持8小时的定时器不变。后果： “海神号”的电量得到了保护, 但AF的“2小时”业务需求则完全无法满足。

这个“规则真空”, 正是Solution 18要填补的。

The proposed way forward is to prevent such situation from happening, i.e. if UE uses the AMF configuration for discontinuous coverage, Nnef_ParameterProvision request containing Maximum Latency is to be rejected.

解决方案的裁决清晰而坚定：“特别法”优于“普通法”。当一个UE已经处于网络为NTN场景精心设计的“特别管理”之下时, 任何来自AF的、可能破坏这种特殊管理的“通用请求”, 都应被明确拒绝。

2. 操作流程：UDM的“守门员”职责 (解读 6.18.2 Procedures)

为了执行这一“裁决”, 方案设计了一套精巧的“信息标记与拦截”流程。Figure 6.18.2-1: A procedure of the solution 详细描绘了UDM是如何扮演“守门员”角色的。

场景复现：“海神号”的请求被“礼貌地回绝”

  1. 步骤 1 & 2: AMF的“特殊标记”

    1. AMF contains an indication of use of configuration for discontinuous coverage in Nudm_UECM_Registration request… 2. UDM stores the AMF registration information containing the indication in UDR. “海神号”通过卫星网络, 成功在AMF处注册。AMF识别出这是一个处于NTN“特别行政区”的UE, 正在执行“8小时休眠”策略。于是, 在向UDM同步该UE的注册信息（Nudm_UECM_Registration）时, AMF附上了一个特殊的“标记”（indication）：“注意, 此UE正在接受特殊的NTN不连续覆盖管理。” UDM收到后, 将这个“标记”与“海神号”的档案一同存入数据库（UDR）。

  2. 步骤 3 & 4: AF的“跨界请求”

    3. AF sends Nnef_ParameterProvision_Create request containing Maximum Latency to NEF. 4. NEF sends Nudm_ParameterProvision_Create request containing Maximum Latency to UDM. 地面控制中心（AF）通过NEF, 向UDM发起了它的“2小时最大延迟”请求。

  3. 步骤 5 & 6: UDM的“档案审查”

    5.6. When Nudm_ParameterProvision_Create request contains Maximum Latency, UDM retrieves the above-mentioned indication (or AMF registration information) as well as the subscription data of the targeted user from UDR. UDM收到了这份请求。作为严谨的“档案管理员”, 它在处理请求前, 首先调出了“海神号”的完整档案。在档案的页眉, 它一眼就看到了AMF留下的那个醒目的“特殊标记”。

  4. 步骤 7: “守门员”的拦截

    7. UDM determines that if the above-mentioned indication exists, the request is to be rejected. “守门员”UDM的规则引擎启动。规则很简单：“凡带有‘特殊标记’者, 其收到的Maximum Latency请求, 一律拒绝。”

  5. 步骤 8 - 11: 拒绝信息的逐级返回

    10. UDM sends Nudm_ParameterProvision_Create response indicating rejection of the request. 11. NEF sends Nudm_ParameterProvision_Create response indicating rejection of the request. UDM生成一份“拒绝”响应, 并沿着请求的原路返回：UDM → NEF → AF。最终, 地面控制中心（AF）的屏幕上, 弹出了一条清晰的提示：“请求被拒绝。原因：目标设备当前正处于网络侧特殊功耗管理策略下。”

3. 系统影响分析：一次轻量级的“流程加固” (解读 6.18.3 Impacts)

AMF:

  • Add an indication (of use of configuration for discontinuous coverage) in Nudm_UECM_Registration request.

AMF的影响： 成为**“标记官”**。软件需要升级, 能够识别出处于特殊NTN策略下的UE, 并在向UDM同步注册信息时, 附加上这个新的“标记”。

UDM:

  • Query AMF registration information when receiving Nudm_ParameterProvision_Create request containing Maximum Latency.
  • Consider the indication to determine whether to accept Nudm_ParameterProvision_Create request…

UDM的影响： 成为**“规则执行者”**。软件需要升级, 能够在处理AF请求时, 增加一步“档案审查”逻辑, 并根据“特殊标记”来执行“拒绝”策略。

这次增强, 没有引入新的网络功能或复杂的流程, 只是在现有的实体和流程上, 增加了一次“信息标记”和一次“逻辑判断”, 是一次非常轻量级、但效果显著的“流程加固”。

4. 方案评估：清晰压倒灵活, 稳定胜于一切

Solution 18是一个典型的**“规则导向”而非“协商导向”的方案。它的核心价值在于消除歧义, 保证稳定**。

  • 优点：

    1. 解决了规则冲突： 它为“AF影响”与“NTN特殊配置”的冲突, 提供了一个清晰、明确、无歧义的裁决, 避免了网络行为的不确定性。
    2. 保护了网络策略的完整性： 它捍卫了运营商为NTN场景精心设计的“深度休眠”策略的权威性, 防止其被来自外部的、可能“无知”的AF请求所破坏。
    3. 保障了UE的生存： 最终, 它保护了像“海神号”这样的远程设备, 不会因为不恰当的业务需求, 而陷入电量耗尽的危险境地。

  • 缺点/权衡：

    1. 缺乏灵活性： 这是一个“一刀切”的拒绝策略。它没有为AF提供任何表达“业务紧迫性”的升级通道。在“海神号”的例子中, 如果AF的2小时指令, 是为了规避一次海底火山爆发, 那么网络的这种僵硬拒绝, 可能会带来灾难性后果。
    2. AF体验不佳： AF的合理需求被简单拒绝, 可能会导致应用层面的业务逻辑失败。AF需要具备处理这种“拒绝”响应的能力, 并可能需要通过其他带外（out-of-band）方式, 与运营商协商更高级的业务保障方案。

总结：在冲突中建立秩序

Solution 18以其清晰、果断的“裁决”, 为我们展示了在复杂的5G生态系统中, 如何通过建立明确的优先级规则, 来解决不同利益方（AF与网络运营商）之间的策略冲突。它像一位铁面无私的法官, 在AF的“任务需求”与网络的“生存策略”之间, 坚定地站在了后者一边。

“海神号”的故事告诉我们, 在严酷的非连续覆盖环境下, 保障终端的生存（功耗）和网络的稳定, 是压倒一切的最高优先级。AF的业务需求固然重要, 但它必须在不破坏这个根本前提的框架内, 去寻求实现。

这份“铁面无私”的裁决, 虽然牺牲了一定的灵活性, 但它换来的是整个NTN系统行为的确定性和可预测性。在工程的世界里, 这往往比无法管理的“灵活”更为宝贵。

然而, 博弈并未就此结束。如果AF能够更“聪明”一些呢？如果它不仅知道自己的业务延迟需求, 还对UE的覆盖情况有所了解, 它是否能提出一个更“合情合理”的请求, 从而避免被UDM的“守门员”一票否决？

这, 正是我们将要在下一篇文章中探讨的, Solution #19——“基于AF参数提供的AMF/MME覆盖时间感知”。一场由AF这位“外部玩家”, 主动为网络提供“情报”的、更高级的协同博弈, 即将上演。

FAQ

Q1：为什么不让网络（UDM）更智能一些, 比如在AF的请求和AMF的策略之间, 取一个折中值？ A1：这是一个很好的问题, 涉及到“简单规则”与“复杂协商”的权衡。取一个“折中值”听起来更灵活, 但会引入巨大的复杂性。例如, 是取平均值, 还是加权平均？权重如何确定？这种复杂的协商机制, 会让网络行为变得难以预测, 也给标准制定和厂商实现带来巨大挑战。Solution 18选择了“简单规则”的道路, 是因为它认为, NTN的特殊配置是基于物理覆盖规律的“硬约束”, 破坏它的后果（UE电量耗尽）远比暂时无法满足AF业务需求的后果更严重。

Q2：AF的请求被拒绝后, 它该怎么办？ A2：AF的软件需要有能力处理这种“拒绝”响应。它可以采取多种策略：1) 等待：AF可以继续订阅UE的可达性事件, 等到UE上线后再尝试下发数据。2) 调整业务逻辑：如果该业务允许, AF可以将“2小时”的周期, 调整为与网络策略相匹配的“8小时”。3) 升级通道：在商业层面, AF的运营方（如地面控制中心）可以通过与网络运营商的客服或技术支持渠道沟通, 申请将“海神号”加入“白名单”, 为其配置特殊的、不受“8小时休眠”法案约束的策略。

Q3：这个“特殊标记”是专门为Solution 18设计的吗？ A3：是的, indication of use of configuration for discontinuous coverage 这个概念, 是Solution 18为了解决其核心冲突而提出的一个关键机制。它是在现有的AMF-UDM接口（Nudm_UECM服务）上, 增加的一个新的信息元素, 目的就是为了在UDM侧, 建立一个关于UE是否处于“特殊管理状态”的“知识库”。

Q4：这个方案主要解决了Key Issue #1（移动性管理）, 它和Key Issue #2（功耗节省）有什么关系？ A4：它是一个典型的、通过优化移动性管理策略, 来间接保护功耗节省成果的方案。它本身不直接参与UE的功-耗节省行为, 但它的“拒绝”裁决, 阻止了AF的请求去破坏一个由网络精心设计的、旨在节省功耗的“深度休眠”配置。因此, 它的作用是为现有的功耗节省机制（如Solution #1, #5, #9）, 建立起一道坚实的“防火墙”。

Q5：如果一个UE同时处于可预测的移动轨迹上（如Solution #2）, 网络是否还会拒绝AF的请求？ A5：这取决于网络策略的精细化程度。在Solution 18的框架下, 只要AMF认为UE正在执行一个为NTN设计的、优先于常规业务的特殊移动性/功耗策略, 它就会打上那个“特殊标记”。这个特殊策略可能是一个简单的“8小时休眠”（针对固定UE）, 也可能是一个更复杂的、与UE协同的动态策略。只要这个标记存在, UDM的“守门员”就会启动, 拒绝AF的请求。因此, 即使UE是移动的, 只要它被纳入了“特别管理”的范畴, 结果依然是被拒绝。

关系图谱