深度解析 3GPP TR 23.700-28：6.15 数字气象员 (为UE提供覆盖数据的解决方案)
本文技术原理深度参考了3GPP TR 23.700-28 V18.1.0 (2023-03) Release 18规范中, 关于“第六章 Solutions”的 6.15 节 “Solution #15: Solution to support Provision of Coverage Data to a UE” 的核心章节, 旨在为读者深度剖析5G NTN如何从“授人以鱼”的原始星历广播, 进化到“授人以渔”的智能覆盖地图服务, 揭示三种将“数字天气预报”精准送达终端的创新路径。
在前几期的探索中, 我们已经检阅了琳琅满目的移动性与功耗节省“战术”。无论是网络中心的运筹帷幄, 还是终端侧的自主决策, 亦或是双方协同的智能共舞, 它们中的绝大多数都建立在一个不言而喻的、却又至关重要的基石之上：UE或网络, 必须以某种方式, 掌握着关于未来卫星覆盖的“情报”。
我们一直在提及“UE解析星历”、“AMF查询覆盖数据库”等概念, 但这些“情报”本身的面貌, 以及获取它们的渠道, 至今仍笼罩在一层神秘的面纱之后。这些情报是晦涩难懂的原始轨道参数, 还是直观易懂的“天气图”？终端和网络又该如何安全、高效地获取这份关乎其生存与行动的“战略地图”？
今天, 我们将深入探讨的Solution #15, 正是为揭开这层面纱而生。它不再是一个“战术”方案, 而是一个**“战略赋能”方案, 是支撑起众多上层应用的“信息基础设施”。它所扮演的角色, 如同一个精准的“数字气象员”**, 其唯一使命, 就是为在茫茫“数字海洋”中航行的终端, 提供一份可靠的、关于未来“信号风雨”的精准预报。
为了演绎这场“信息赋能”的重要性, 伊芙琳博士的“雨林守护者”计划将迎来一次重大升级。她将部署一支由数十架无人机组成的“仿生蜂群”（Bio-Scanner Drone Swarm）。这支蜂群需要在起飞之前, 就为未来24小时的任务, 规划出一条最优的飞行与数据回传路径——它们必须在有卫星覆盖的区域执行数据密集型扫描, 在信号空窗期则进入节能巡航模式。这份“任务规划书”的制定, 完全依赖于一份详尽、精准的“卫星覆盖地图”。Solution 15将为我们展示, 这份地图是如何被绘制、分发和获取的。
1. 核心哲学：从“原始数据”到“智能预报” (解读 6.15.1 Description)
Rel-17的方法, 类似于气象站向大众公布原始的大气压、湿度、风速等数据。用户（UE）需要自己成为气象学家, 通过复杂的计算, 去预测未来是否会下雨（有覆盖）。这种方式不仅对UE的“专业能力”（计算能力）要求高, 而且由于信息不完整（只广播少数几颗卫星的星历）, 预测结果往往不甚准确。
Solution 15则提出了一场革命：由专业的“气象中心”（网络或第三方服务器）, 将所有原始数据进行处理, 直接生成一份用户友好的“天气图”（Coverage Map）, 并通过多种渠道分发给用户。
6.15.1 Description
The content of coverage data can include a coverage map which shows the expected coverage by one or more satellite RATs at one or more locations and for a particular time in the future. A set of coverage maps can then be provided for each of a sequence of times…
这段描述定义了“智能预报”的核心——覆盖地图 (Coverage Map)。Figure 6.15.1-1: Coverage Data Map for a set of Grid Point Locations 直观地展示了它的形态：
- 形态： 这是一个时空四维的数据结构。它将地理空间划分为一个个网格点（Grid Points）, 并为每一个网格点, 在未来的一系列时间点（sequence of times）上, 标注一个简单的二进制值：
1代表“有覆盖”,0代表“无覆盖”。 - 价值： UE不再需要进行任何复杂的轨道计算。它只需知道自己当前的经纬度和时间, 就像在地图上查坐标一样, 就能立即知道自己是否有信号, 以及下一次信号何时到来。
The size of a coverage map may be reduced by using a lower resolution… or by compressing any sequence of repeated binary ones or repeated binary zeros
方案还贴心地考虑到了传输效率, 提出了多种“压缩”地图数据的方法, 如降低分辨率（增大网格间距）或使用行程编码等压缩算法, 这对于数据量敏感的物联网设备至关重要。
1.1 三条通往“真理”的道路
这份宝贵的“覆盖地图”该如何送达UE？Solution 15设计了三条截然不同的路径, 以适应不同的终端能力和网络架构。
A coverage map… can be provided to a UE by a server via user plane or SMS or by an MME or AMF using NAS. Three alternative solutions can be used for this part. The first solution is based on an HTTPS or SMS query from a UE to a server. The second solution is based on a simple NAS request/response… With the third solution, the DCAF/AF functionality and architecture… could be extended to expose network data analytics to a UE.
- 路径A：“授权查询” (User Plane - HTTPS/SMS): UE通过用户面, 向一个专门的外部服务器查询地图。
- 路径B：“官方渠道” (Control Plane - NAS): UE通过控制面信令, 直接向核心网AMF/MME索取地图。
- 路径C：“智能API” (Control Plane - DCAF/NWDAF): UE通过5G新增的数据分析曝露框架, 从网络获取地图。
2. 操作流程：三条路径的详细勘探 (解读 6.15.2 Procedures)
接下来, 我们将详细勘探这三条“信息高速公路”的构建方式和运作流程。
2.1 路径A：“授权查询”——两步走的Web服务模式 (6.15.2.1)
这种模式借鉴了我们非常熟悉的Web服务思想, 其核心是“先拿凭证, 再办业务”。
第一步：向网络申请“凭证”
Figure 6.15.2.1-1: Procedure to Request Authorization Data 展示了UE如何从核心网获取访问外部服务器的“授权凭证”。
- UE发起请求： “仿生蜂群”中的一架无人机, 在起飞前的网络注册过程中, 在
Registration Request消息中增加了一个“请求”：“我需要覆盖数据, 偏好使用HTTPS方式获取。” - AMF处理并生成凭证： AMF收到请求后, 会验证该无人机的签约是否包含这项服务。验证通过后, AMF会生成一份“授权凭证”。这份凭证可能是一个加密的URI字符串, 里面包含了UE的临时ID、请求的区域和时间、服务器地址等信息。
- AMF下发凭证： AMF在
Registration Accept消息中, 将这份URI“凭证”下发给无人机。
第二步：凭“凭证”向服务器获取地图
Figure 6.15.2.1-2: Procedure to Request Coverage Data from a Server 展示了UE如何使用这份“凭证”。
- UE发起查询： 无人机通过其数据连接（用户面）, 向“凭证”URI所指向的外部服务器, 发起一个标准的HTTPS GET请求。
- 服务器验证并提供地图： 外部服务器（可能由卫星公司运营）收到请求后, 解密并验证URI的有效性。验证通过后, 服务器将无人机所请求区域的“覆盖地图”数据, 作为HTTPS响应的主体, 返回给无人机。
优点： 核心网与数据服务器职责分离, 架构清晰；数据通过用户面传输, 灵活性高。 缺点： 流程分两步, 稍显复杂；要求UE必须具备IP通信能力。
2.2 路径B：“官方渠道”——简洁高效的NAS信令模式 (6.15.2.2)
这种模式最为直接, 将所有交互都限定在了UE与核心网AMF/MME之间。
Figure 6.15.2.2-1: Procedure to obtain coverage data using NAS 展示了其简洁的流程。
- UE发起请求： 无人机同样在
Registration Request中, 包含一个“请求”：“我需要覆盖数据。” - AMF处理并直接提供地图： AMF收到请求后, 验证签约。验证通过后, AMF自己负责去获取或生成这份“覆盖地图”。它可能是从预配置的本地数据库中读取, 也可能是转身向另一个内部服务器（如卫星运营商的服务器）查询。
- AMF下发地图： AMF将获取到的“覆盖地图”数据, 直接打包在
Registration Accept消息中, 通过控制面信令, 下发给无人机。
优点： 流程一步到位, 非常简洁；对UE来说, 只需与AMF交互, 无需关心数据源；不要求UE具备IP能力, 纯NAS信令即可完成。 缺点： 对AMF的压力较大, AMF需要承担数据获取、缓存和分发的角色, 增加了核心网的负荷和复杂度。
2.3 路径C：“智能API”——面向未来的服务化模式 (6.15.2.3)
这种模式是5G服务化架构（SBA）思想的延伸, 最具前瞻性。它将“提供覆盖数据”视为一种标准的“网络分析服务”。
Figure 6.15.2.3-1: UE requested data exposure procedure 展示了一套复杂但强大的服务调用流程。
- UE发起请求： 无人机上的应用客户端, 通过一个特殊的应用层接口（由DCAF定义）, 发起一个“分析请求”：“我需要ID为‘NTN Coverage Map’的分析结果。”
- DCAF作为“中介”： DCAF（Data Collection AF）是一个网络功能, 扮演着应用与网络分析引擎之间的“安全中介”。它收到请求后, 会去服务发现系统（NRF）中, 寻找能够提供这项“NTN Coverage Map”分析服务的NWDAF实例。
- DCAF向NWDAF“订阅”： DCAF代表UE, 向找到的NWDAF发起一次服务订阅。
- NWDAF“生产”数据： NWDAF作为网络的“大脑”, 会收集来自O&M、AF、甚至其他NF的各种数据（包括完整的卫星星座信息）, 进行复杂的分析和计算, 最终“生产”出无人机所需要的、高度精准的“覆盖地图”。
- 数据回传： NWDAF将结果（地图数据）返回给DCAF, DCAF再通过应用层信道, 将其安全地传递给无人机上的应用客户端。
优点： 架构最先进, 将“覆盖地图”的提供, 纳入了5G统一的网络数据分析框架, 可扩展性极强。未来还可以通过这个接口, 获取更多类型的网络分析数据。 缺点： 流程最为复杂, 依赖于DCAF、NWDAF等5G高级网络功能的部署。
3. 系统影响分析：不同路径, 不同权责 (解读 6.15.3 Impacts)
这三种路径, 对系统各实体的影响截然不同。
| 实体 | 路径A (HTTPS/SMS) | 路径B (NAS) | 路径C (DCAF/NWDAF) |
|---|---|---|---|
| UE | 需要IP/SMS栈；处理两步流程 | 仅需NAS栈；流程简单 | 需要DCAF客户端；处理应用层API |
| AMF | 仅负责生成和下发“凭证”, 角色轻量 | 负责获取、缓存、下发地图, 角色重 | 作为DCAF/NWDAF流程的触发和承载节点 |
| Server | 负责验证凭证和提供数据 | 不直接与UE交互 | N/A |
| DCAF | N/A | N/A | 核心角色, 扮演安全中介和请求代理 |
| NWDAF | N/A | N/A | 核心角色, 扮演数据分析和生产者 |
4. 方案评估：一场“信息赋能”的革命 (解读 6.15.4 Solution evaluation)
6.15.4 Solution evaluation
A coverage map as defined in clause 6.15.1 has several advantages compared to provision of satellite orbital data using a SIB…
- A UE is not required to perform any complex satellite orbital calculations…
- The coverage data can be prepared in advance (e.g. by a satellite operator) with complete and accurate knowledge… and can thus be more accurate and reliable…
- The coverage data can be provided for an arbitrary period… for multiple satellite RATs… more complete…
评估部分旗帜鲜明地阐述了“覆盖地图”相比于传统“广播星历”的压倒性优势：
- 为UE减负： 将复杂的计算任务从资源受限的终端, 转移到了云端强大的服务器上。
- 更准确、更可靠： 地图由掌握全局信息的专业方（如卫星运营商）制作, 考虑了波束规划、运营限制等UE无法获知的“内部信息”。
- 更完整、更灵活： 可以提供更长时间、跨多个RAT、更完整的覆盖信息, 不再受限于SIB的容量。
这不仅仅是一次技术上的优化, 而是一场**“信息赋能”的革命**。它将决定5G NTN体验上限的关键信息, 以一种前所未有的、系统化的方式, 提供给了最需要它的UE和应用。
总结：从“航海士”到“GPS”的进化
Solution 15的诞生, 标志着5G NTN终端在进行“导航”时, 迎来了一次从“古代航海士”到“现代GPS”的伟大进化。
在过去（Rel-17）, 终端如同古代的航海士, 需要自己抬头仰望星空（接收星历）, 使用复杂的六分仪（计算模块）, 去推算自己的航路。这个过程耗时耗力, 且极易出错。
而Solution #15, 则为每一艘在“数字海洋”中航行的船只（UE）, 都配备了一台精准的“GPS导航仪”。它直接在屏幕上（数据结构中）, 为船只清晰地标示出了“航道”（有覆盖的区域）和“浅滩”（无覆盖的区域）。船长（UE协议栈）只需查阅这份地图, 就能轻松地规划出最安全、最高效的航线。
伊芙琳博士的“仿生蜂群”, 正是借助这份精准的“GPS地图”, 才得以在起飞前就规划好未来24小时的“作战计划”, 实现了真正意义上的自主、智能运行。
然而, “知道”了未来的不可用, 只是第一步。如何将这份“知道”, 转化为一个网络可以理解、并能为之提供特殊服务（如数据缓存）的“正式状态”？换言之, 当UE通过覆盖地图, 预知了自己将有一次长达4小时的“休假”时, 它该如何向网络“请假”, 并让网络为这次“请假”做好万全的准备？
这, 正是我们将要在下一篇文章中探讨的, Solution #16——“UE触发的广义不可用周期”。一场关于“主动请假”的流程, 即将拉开帷幕。
FAQ
Q1：为什么“覆盖地图”会比UE自己用星历计算更准确？ A1：因为卫星运营商在制作“覆盖地图”时, 除了考虑卫星的物理轨道（星历）, 还会考虑许多UE无法获知的运营层面因素。例如：1) 波束规划：卫星的波束可能不会一直开启, 或不会覆盖其理论上能照射到的所有区域。2) 法规限制：在飞越某些国家或地区时, 由于没有获得运营许可, 运营商会主动关闭该区域的服务。3) 负载均衡：运营商可能会根据网络负载, 动态调整某些区域的波束功率或可用资源。这些“内部信息”都会被包含在最终的覆盖地图中, 使其远比UE基于纯物理轨道的计算更贴近“服务现实”。
Q2：这三种获取地图的路径, 未来哪一种会成为主流？ A2：很可能是路径B（NAS）和路径C（DCAF/NWDAF）的结合。路径B最为直接, 对于简单的覆盖信息查询, 效率最高。路径C则代表了5G的演进方向, 它不仅仅是为获取地图, 而是建立了一个通用的“应用-网络”数据分析接口, 可扩展性最强。路径A（HTTPS/SMS）作为一种补充, 在某些特定场景下（如需要与非3GPP的服务器直接交互）仍有其价值。一个成熟的网络可能会同时支持这三种方式, 由UE根据自身能力和业务需求来选择。
Q3：获取这份“覆盖地图”会消耗很多流量吗？对物联网设备是否友好？ A3：这是一个关键问题。原始的、高分辨率的地图数据量可能很大。但Solution 15明确提出了压缩机制。对于物联网设备, 网络可以为其提供一份低分辨率、经过高度压缩的地图, 比如只包含未来24小时内, 在其驻留区域的几个关键时间点的覆盖状态。这份数据的量可以被控制在非常小的范围内（可能只有几百字节到几千字节）, 完全可以通过一次NAS信令或一条SMS来承载, 对物联网设备是友好的。
Q4：DCAF和NWDAF到底是什么？为什么需要这么复杂的架构来获取一份地图？ A4：DCAF（数据收集应用功能）和NWDAF（网络数据分析功能）是5G服务化架构中的“明星”网元。NWDAF是网络的“大脑”, 负责收集和分析全网数据, 输出智能洞察。DCAF则是这个“大脑”面向应用的一个“安全窗口”。使用这套架构, 不仅仅是为了获取一份地图, 而是为了建立一个统一、安全、可扩展的框架。今天, UE通过它获取覆盖地图；明天, 它就可以通过同样的接口, 获取网络拥塞预测、移动性模式分析等更高级的数据。这是一种面向未来的、一劳永逸的架构投资。
Q5：这份“覆盖地图”是免费的吗？ A5：这取决于商业模式。运营商可以将其作为一项基础服务, 免费提供给所有NTN用户, 以提升网络体验。也可以将其作为一项增值服务, 对有高级需求的用户（如需要高精度、长周期地图的“仿生蜂群”项目）进行收费。特别是通过路径C（DCAF/NWDAF）提供的、经过深度分析的定制化地图服务, 极有可能成为运营商在B2B市场的一个新的收费点。