深度解析 3GPP TR 23.700-28：6.19 AF的情报 (应用层赋能的网络覆盖感知)

本文技术原理深度参考了3GPP TR 23.700-28 V18.1.0 (2023-03) Release 18规范中, 关于“第六章 Solutions”的 6.19 节 “Solution #19: AMF/MME awareness of coverage times based on AF parameter provisioning” 的核心章节, 旨在为读者深度剖析当应用层（AF）自身即为“情报专家”时, 它如何从一个被动的“需求方”, 华丽转身为主动的“赋能者”, 将其掌握的精准覆盖情报, “反哺”给核心网, 从而实现一场由外而内、颠覆传统的高级协同。

在前一篇的博弈中, 我们见证了Solution 18如何扮演“铁面法官”, 坚定地拒绝了来自应用层（AF）的、可能破坏NTN网络稳定性的Maximum Latency请求。这场裁决虽然维护了网络的秩序, 却也留下了一个悬念：AF的合理业务需求, 真的就只能在网络的“特殊法案”面前, 无奈地“一票否决”吗？

如果, 这位AF不再是一个对网络环境一无所知的、只会提“通用需求”的“门外汉”, 而是摇身一变, 成为了一位比核心网AMF更懂UE未来处境的“情报专家”呢？

这, 正是Solution 19所描绘的一场精彩的“角色反转”。它不再让AF去提一个模糊的“要求”（如2小时延迟）, 而是赋予AF一个全新的能力——提交一份详尽的“情报”。这份情报, 不再是“我想要什么”, 而是“我知道会发生什么, 请据此行动”。它将彻底改变AF与核心网的互动模式, 从“需求与供给”的博弈, 升级为“情报共享与协同执行”的伙伴关系。

为了演绎这场由“外部大脑”赋能的智能协同, 我们那艘执行自主科考任务的深海潜航器“海神号”（Poseidon-1）及其背后的“数字孪生”控制中心（AF）将再次登场。在Solution 18中, 它的“2小时唤醒”请求被无情驳回。但这一次, 这位AF将携带着一份从商业卫星情报公司购买的、高精度的覆盖预测数据, 向3GPP核心网发起一次前所未有的、充满智慧的“对话”。

---

1. 核心哲学：从“需求方”到“情报源”的角色反转 (解读 6.19.1 Description)

Solution 19的哲学根基, 在于打破了“网络内部信息自洽”的传统思维定式, 承认并利用了“外部专家”（AF）在特定领域可能拥有的信息优势。

6.19.1 Description

This solution applies to KI#1 and KI#2. The AF can currently provide information targeting a UE… The AF can e.g. provide UE behaviour information, including expected UE moving trajectory… If the AF is aware of the satellite constellation information the AF can adjust these values based on the in-coverage and out-of-coverage times for the UE.

这段描述为AF的角色反转, 奠定了理论基础。它指出, AF本来就具备向网络提供UE行为信息（如移动轨迹）的能力。本方案的核心思想, 就是将这种能力再向前推进一步：如果AF不仅知道UE要去哪, 还“顺便”把那里的“天气”（卫星覆盖情况）也预报了, 岂不美哉？

In this solution the NEF parameter provision service is enhanced to allow the AF to provide coverage information as a list of {time, coverage in/out} pairs based in its awareness of UE location, UE trajectory and satellite coverage information.

这就是“角色反转”的具体实现机制。它对Solution 18中提到的Nnef_ParameterProvision服务, 进行了一次意义重大的**“功能增强”**。

• 旧功能： AF只能提交Maximum Latency这样的“需求参数”。
• 新功能： AF现在可以提交一份结构化的、内容丰富的“情报参数”——一个list of {time, coverage in/out} pairs（时间与进出覆盖状态的键值对列表）。

“海神号”的场景： “海神号”的“数字孪生”控制中心（AF）, 作为一个高度专业化的应用, 它集成了：

1. 任务规划模块： 精确规划了“海神号”在未来48小时内, 何时需要上浮到近水面进行通信。
2. 商业情报模块： 购买了第三方商业卫星情报服务, 拥有比移动运营商更精准（甚至不同维度）的覆盖预测数据。

综合这两份信息, AF的“大脑”中, 生成了一份关于“海神号”未来48小时的、无比清晰的“通信窗口”时间表： { [14:00 UTC, Coverage IN], [14:25 UTC, Coverage OUT] } { [22:15 UTC, Coverage IN], [22:40 UTC, Coverage OUT] } { ... }

在Solution 19的框架下, AF不再是去提一个会被拒绝的“2小时”请求, 而是将这份详尽的“情报”, 主动“分享”给了核心网。

---

2. 操作流程：一份“专家情报”的旅行 (解读 6.19.2 Procedures)

Figure 6.19.2-1 为我们展示了这份来自AF的“专家情报”, 是如何通过一条安全、标准的路径, 最终抵达“前线指挥官”AMF手中, 并转化为对UE的具体行动指令的。

场景复现：“数字孪生”中心的一次智能赋能

• 步骤 0: AF的“情报生成”

  0. The AF determines suitable UE behaviour parameters, e.g. UE trajectory information, UE coverage information. “数字孪生”中心（AF）完成了对“海神号”未来通信窗口的计算, 生成了那份{time, in/out}列表。

• 步骤 1: AF的“情报提交”

  1. The AF invokes Nnef_ParameterProvision to provision the Expected UE behaviour and the Network Configuration related parameters… This information can also include information related to when the UE is expected to have coverage and when the UE is expected to be out of coverage. AF通过NEF, 调用Nnef_ParameterProvision服务, 但这次提交的, 不再是简单的Maximum Latency, 而是那份结构化的“覆盖时间表”。

• 步骤 2 & 3: 情报在核心网内部的“安全传递”

  2. The NEF invokes Nudm_ParameterProvision to provide the parameters to UDM… 3. The NEF replies to the AF NEF作为“安全网关”, 将这份情报转发给核心网的“中央数据库”UDM进行存储。

• 步骤 4: UDM的“情报分发”

  4. The UDM notifies all AMFs that have subscribed to subscription data updates. UDM检测到“海神号”的签约数据发生了重要更新, 于是立即向当前正在为“海神号”提供服务的AMF, 推送了这条“紧急情报”。

• 步骤 5: AMF的“恍然大悟”

  5. The AMF uses the information received from UDM to determine suitable timer values, and to determine when the UE is expected to be in- or out-of-coverage. 这是流程的转折点！ AMF收到了这份来自AF的、详尽的“覆盖时间表”。它不再需要自己去猜测、去依赖RAN的有限信息。它现在拥有了一份关于“海神号”未来的、权威的“行动剧本”。AMF的决策逻辑变得异常简单和精准：

  • 设置定时器： 在14:25 UTC“海神号”失联后, AMF会为其设置一个周期性注册定时器, 时长恰好是22:15 - 14:25（约7小时50分钟）, 确保它在下一次覆盖窗口前准时醒来。
  • 优化寻呼： AMF清楚地知道, 在14:25到22:15之间, 对“海神号”的任何寻呼都是无效的, 从而主动抑制, 节省网络资源。

• 步骤 6 & 7: AMF的“精准执行”

  6a. For 5GS, the AMF provides NAS timers (e.g. periodic timer, Active Time etc) to the UE using existing procedures, e.g. during registration or UCU. 7. RAN may release the AS connection when the UE loses coverage… AMF利用这份“情报”, 通过标准的NAS流程（如UE Configuration Update）, 为“海神号”下发了与AF“剧本”完美同步的定时器参数。当14:25 UTC到来, “海神号”在AMF的“指导”下, 安心地进入了长达近8小时的深度休眠。

---

3. 系统影响分析：一次职责的重新划分 (解读 6.19.3 Impacts)

Solution 19对系统各实体的影响, 本质上是一次**“情报”职责的重新划分**。

AF:

• Determine Maximum Latency… and in/out coverage times etc. based on awareness of satellite coverage information…

AF的影响： 从**“需求提出者”升级为“情报生产者”**。它需要具备获取和分析覆盖信息, 并将其格式化为标准数据结构的能力。

NEF & UDM/HSS:

• Extend Nnef Parameter Provision to include in/out coverage time information
• Extend Parameter Provision and subscription data to include in/out coverage time information

NEF & UDM的影响： 成为**“情报的管道与仓库”**。它们的API和数据库需要进行升级, 以支持这种新的、结构化的“覆盖时间表”数据。

AMF/MME:

• Receive coverage time information for a UE… from UDM/HSS
• Configure the power saving parameters and other NAS timers based on the coverage time information…

AMF/MME的影响： 从一个需要自己进行部分预测的**“决策者”, 变为一个更纯粹的“情报消费者”和“指令执行者”**。它不再需要问“为什么”, 只需要根据收到的精准情报, 高效地执行即可。

UE:

• Trigger the Tracking Area Update procedure when it is about to lose network coverage.

UE的影响： 在这个特定的流程中, UE的角色相对被动, 更像一个**“指令的最终执行者”**。它只需响应AMF下发的定时器更新即可。

---

4. 方案评估：生态协同的典范 (解读 6.19.4 Solution evaluation)

6.19.4 Solution evaluation

The solution re-uses existing NFs and services. The solution assumes that the AMF/MME receives time information about when the UE is expected to be in-coverage and out-of-coverage for satellite access from AF (via UDM/HSS). There is no need for AMF/MME to calculate coverage based on ephemeris data or coverage maps.

评估部分高度肯定了本方案的架构优势和解耦思想。

• 优点：

  1. 重用现有框架： 它没有引入新的网络功能实体, 而是巧妙地“增强”了现有的Nnef_ParameterProvision服务, 影响最小化。
  2. 职责清晰, 专业分工： 它将“覆盖预测”这一极其专业的任务, 交给了最擅长做这件事的实体——高度专业化的AF。这使得AMF/MME可以从复杂的计算中解脱出来, 专注于其核心的移动性和会话管理职能。这是一种非常健康的“关注点分离”架构设计。
  3. 解决了Solution 18的僵局： 它为AF提供了一条绕过“一刀切”拒绝策略的“VIP通道”。AF不再是提一个模糊的需求, 而是提供一份详实的“解决方案”, 网络的态度自然从“拒绝”变为了“欢迎”。

• 核心假设： 整个方案的成功, 建立在一个核心假设之上——AF确实拥有比网络更精准、更及时的覆盖情报。这个假设在许多B2B垂直行业应用中是完全成立的。

总结：当应用成为网络的“眼睛”

Solution 19以其独特的“角色反转”设计, 为我们展示了5G网络生态系统走向“深度协同”的迷人前景。它不再是一个由运营商单向控制的封闭系统, 而是向一个能够吸纳和利用“外部智慧”的开放平台演进。

“海神号”的故事, 正是这场演进的生动缩影。它的“大脑”（AF）, 通过成为核心网的“眼睛”和“情报官”, 成功地将自身的业务节拍, 与网络的底层律动, 谱写成了一曲和谐的交响乐。这不仅解决了AF自身的业务痛点, 更极大地提升了整个网络资源（包括UE的电量）的利用效率。

这场“AF的情报战”, 是一场没有输家的博弈。AF实现了其业务目标, 网络获得了精准的调度依据, UE则享受到了最优的功耗管理。

然而, 至今为止我们讨论的寻呼优化, 无论是Solution 4的“精准制导”, 还是本方案中AMF基于精准情报的“寻呼抑制”, 都还停留在“在哪个TA里寻呼”或“在哪个时间段不寻呼”的宏观层面。在一个广达数万平方公里的卫星波束（TA）内, 是否还有进一步“精雕细琢”的空间？我们能否为每一个UE, 都量身定制一个动态的、更小的“专属寻呼区”, 从而将寻呼的精度, 从“城市级”提升到“街道级”？

这, 正是我们将要在下一篇文章中探索的, 一个极具想象力的方案——Solution #20, “UE专属的动态跟踪区”（UE-specific Dynamic Tracking Areas）。一场关于“个性化地理围栏”的革命, 即将到来。

---

FAQ

Q1：为什么AF会比移动核心网（AMF）更了解卫星覆盖情况？这听起来有点反直觉。 A1：这在B2B垂直行业中非常常见。原因有三：1) 专业化：AF可能是由一个专门从事空间数据分析的公司运营, 它会购买和融合来自多个卫星运营商、商业气象服务、地理信息系统的数据, 其模型的复杂度和精度可能远超移动运营商的通用平台。2) 业务耦合：AF知道UE的任务计划。例如, “数字孪生”中心知道“海神号”计划在何时何地上浮, 这是移动网络无法获知的信息。AF可以将这个“意图”信息, 与覆盖信息相结合, 做出更精准的判断。3) 商业驱动：AF的业务成功, 直接依赖于这种精准调度, 因此它有更强的商业动机, 去投资于最高精度的预测服务。

Q2：这个方案和Solution #17（事件列表）有什么相似和不同？ A2：相似之处在于, 两者都将覆盖信息从“UE自己算”转移到了“由专家提供”。根本不同在于**“专家”的身份和信息的流向**。在Solution 17中, “专家”是网络内部新增的CMNF, 信息流是UE -> AMF -> CMNF -> AMF -> UE。而在Solution 19中, “专家”是网络外部的AF, 信息流是AF -> NEF -> UDM -> AMF。可以说, Solution 17是网络的“内部改良”, 而Solution 19是引入“外部智慧”。

Q3：这个方案对UE的功耗节省有什么直接好处？ A3：直接好处巨大。由于AMF获得了关于UE未来覆盖窗口的“上帝视角”般的精准情报, 它可以为UE配置一个最优化的PSM或MICO周期。例如, 如果AF告知网络, UE的下一个可用窗口在7小时50分钟之后, AMF就可以为UE设置一个恰好为7小时50分钟的周期性注册定时器。这避免了任何形式的“猜测”或“冗余”, 使得UE的每一次休眠, 都是“恰到好处”的, 功耗节省效率达到了理论上的最大化。

Q4：如果AF提供的情报是错误的, 会发生什么？ A4：网络会“忠实地”执行这份错误的情报, 从而可能导致问题。例如, 如果AF告知网络, UE在14:25会失联, 但实际上信号持续到了14:30, 那么网络可能会在14:25就认为UE不可达, 从而错误地拒绝一个本可以成功的寻呼。反之, 如果AF的情报过于乐观, 网络可能会在没有信号的时候去寻呼UE。这凸显了本方案的一个关键点：AF必须为其提供的情报的准确性负责。在商业合同中, 很可能会有关于“情报准确率”的服务等级协议（SLA）。

Q5：这个方案是否意味着未来的5G网络, 会变得越来越依赖于外部应用（AF）？ A5：是的, 这正是5G网络架构演进的一个核心方向, 即**“网络能力曝露”和“生态协同”**。4G网络更像一个封闭的“黑盒”, 而5G则旨在成为一个开放的“平台”。通过像NEF这样的接口, 5G网络不仅可以向AF“输出”能力, 也可以像Solution 19这样, 从AF那里“输入”智能。这种双向的、深度的协同, 将使得网络能够更好地适应千行百业的差异化需求, 从而释放出远超“连接”本身的巨大价值。