51学通信

深度解析 3GPP TR 23.700-01：4.3 卫星非连续覆盖接入 (Satellite access with discontinuous coverage)

25分钟阅读

好的，我们继续前进，深入探讨下一个关键问题。

深度解析 3GPP TR 23.700-01：4.3 卫星非连续覆盖接入 (Satellite access with discontinuous coverage)

本文技术原理深度参考了3GPP TR 23.700-01 V19.0.0 (2024-09) Release 19规范中，关于“4.3 Key issue #3: Satellite access with discontinuous coverage”的核心章节，旨在为读者揭示5G系统如何将卫星网络“断开连接”这一固有挑战，转化为一种可预测、可管理的“应用层新特性”。

前言：从“永远在线”的幻觉到“计划离线”的智慧

在上一章的讨论中，我们探索了卫星边缘计算（KI#2）的宏伟蓝图，它通过将计算力推向太空，试图从根本上绕过星地链路的延迟与带宽瓶颈。这解决了“连接慢”和“连接贵”的问题。然而，在广袤的物联网（IoT）世界，尤其是在使用低功れい轨（LEO）卫星星座为海量、低功耗设备提供连接时，我们面临一个更基础、更致命的挑战——“无法连接”。

与我们习以为常的、追求“永远在线”的地面蜂窝网络不同，一个稀疏的LEO卫星星座对于地面上的某个静止设备而言，其服务本质上是“脉冲式”的——一天之中，可能只有寥寥数次、每次仅持续几分钟的“黄金连接窗口”，而在其余漫长的时间里，设备都处于网络的“阴影”之下。

这就是3GPP SA6研究的第三个关键问题（KI#3）——非连续覆盖（Discontinuous Coverage）。这个问题，对于阿里斯博士部署在亚马逊雨林深处的数百个依靠电池供电的环境传感器“盖亚之眼-节点（Gaia-Node）”来说，是关乎生死存亡的“能源危机”。一个“愚笨”的节点，如果在网络阴影期徒劳地尝试连接，将在短短数周内耗尽设计寿命长达数年的电池。

KI#3的研究，就是要赋予5G网络一种全新的智慧：将随机的、不可控的“掉线”，转变为可预测、可规划的“计划性离线”。

1. “脉冲式”连接的现实 (4.3.1 Description)

要解决问题，首先要精准地定义问题。规范在4.3.1节中，通过文字和图示，为我们清晰地描绘了非连续覆盖的现实图景。

In a network with satellite access, a UE may experience a situation of discontinuous coverage, due to e.g., a sparse NGSO satellite constellation deployment. An illustration of a discontinuous coverage pattern for a given UE location and a single example LEO satellite at a nominal 600 km altitude is represented in Figure 4.3.2-1 (reproduced from R2-2107453).

深度解析：

规范开门见山地指出，非连续覆盖是稀疏NGSO（非对地静止轨道，主要是LEO和MEO）星座部署下的常态。为了让读者有具象化的感知，规范引用了RAN工作组的一份文档中的“Figure 4.3.1-1: Flyovers and duration of visibility…”。

我们虽然不直接重绘该图，但必须深入解读它所传达的关键信息：

  • 横轴（X-axis）：时间，以“天”为单位。
  • 纵轴（Y-axis）：可见时长，以“分钟”为单位。
  • 图中的散点：每一个点，代表卫星的一次“过境（flyover）”，即从地平线一端升起，划过天空，再到另一端落下的过程。
  • 关键洞察：从图中可以清晰地看到：
    1. 连接是短暂的：绝大多数过境窗口的持续时间都在几分钟到十几分钟之间（例如，中位数为3.6分钟）。
    2. 断开是漫长的：两次过境之间的间隔时间非常长，平均长达近12个小时。

阿里斯博士的“盖亚之眼-节点”能源危机：

阿里斯博士部署的“盖亚之眼-节点073”是一个测量土壤温湿度的低功耗传感器。它的工作模式本应是每小时测量一次数据，然后上报。

  • “愚笨”的工作模式：节点073不知道卫星何时会来。它每小时准时唤醒，尝试连接网络。在长达11个多小时的“网络阴影期”，它每次唤醒都会经历“搜索信号 → 连接失败 → 重试 → 超时放弃 → 休眠”的完整失败流程。这个过程中的射频功耗是巨大的。
  • 灾难性后果：原本设计能工作5年的电池，在这种模式下，可能不到5个月就会被彻底耗尽。数百个传感器变成“砖头”，整个科研项目宣告失败。

1.1 黑暗中的曙光：可预测性

就在问题看似无解时，规范抛出了力挽狂澜的关键信息：

This sort of discontinuous coverage pattern between the UE and a satellite can be predicted ahead of time for periods of days or even a few weeks with good accuracy (e.g. time errors of a few tens of seconds in estimating the starting time of the satellite pass…) by means of orbit propagation models and satellite ephemeris information…

深度解析：

这句原文是整个KI#3的“题眼”。它告诉我们，非连续覆盖虽然是一种“中断”，但它不是随机的，而是可预测的（predictable）。天体的运行遵循精确的物理定律。只要我们知道卫星的轨道参数（即星历“ephemeris”），我们就能通过轨道传播模型（如TLE/SGP4），在未来数天甚至数周内，以秒级的精度，预测出卫星何时会出现在天空的哪个位置。

这意味着，我们可以提前拿到一份精确的“卫星过境时间表”。

1.2 从网络问题到应用挑战

有了“可预测”这个前提，问题就从“如何应对随机掉线”转变成了“如何利用这份时间表”。规范接着指出，尽管RAN和核心网层面已经做了一些工作来适应这种可预测性（比如在系统信息里广播一些辅助参数），但最终的挑战落在了应用层。

However, regardless of these enhancements at the network level, the discontinuous coverage nature of the service link results into an intermittent connectivity pattern between the UE and the Application Server (AS)/Application Function (AF) that has also a direct impact on the behaviour of the application.

Supplying information on the discontinuous coverage pattern or related services to the application layer will help applications to design themselves for handling discontinuity accordingly.

深度解析：

底层网络的优化，好比是高速公路公司提前公布了“前方路段每日下午2点至2点15分开放”的通知。但这并不能解决问题，最终还需要“司机”（即应用）看到这份通知，并据此调整自己的出行计划。

“智能”的“盖亚之眼-节点”应该如何工作？

  1. 获取“时间表”：节点073不再盲目唤醒。它从5G网络那里，获取到了一份未来24小时的“连接窗口时间表”。
  2. 计划性休眠：它看到下一个窗口在遥远的9个小时之后。于是，它设置了一个长达8小时55分钟的深度睡眠定时器，将功耗降到最低。
  3. 精准唤醒与数据打包：在连接窗口到来前5分钟，它被唤醒。在这5分钟里，它不急于连接，而是将过去9个小时积累的所有测量数据进行打包、压缩，做好发送准备。
  4. 高效传输：下午2点整，卫星准时出现在头顶。节点073立刻发起连接，在短短几分钟的“黄金窗口”内，将打包好的数据一次性高效地发送出去。
  5. 再次休眠：发送完毕，它查询“时间表”，看到下下个窗口在11个小时后，于是再次进入长周期深度睡眠。

通过这种“计划离线”的智慧，电池寿命将得到指数级的延长，阿斯博士的项目得以顺利进行。而实现这一切的关键，就在于如何建立一条从网络到应用的“时间表”传递通道。这便是KI#3的开放性问题所要探讨的核心。

2. 传递“时间表”的两大技术难题 (4.3.2 Open issues)

如何设计一套标准化的、高效的、安全的机制，来向应用层传递这份宝贵的“卫星过境时间表”？规范提出了两个必须解决的开放性问题。

2.1 开放问题一：如何定义和暴露覆盖信息？

  • Whether and how the information on discontinuous satellite coverage needs to be exposed to the application layer (e.g. semantics, service-based interfaces, etc.) on the AS/AF side.

深度解析：

这个问题探讨的是“传递什么”和“如何传递”。

  1. “传递什么” (Semantics - 语义): 网络不能只给应用一个模糊的“有信号/没信号”状态。信息必须是结构化的、机器可读的。语义的定义是第一步。可能的形式包括：

    • 不可用时段列表 (List of Unavailability Periods): 这是最直接的方式。例如，一个JSON数组，每个元素包含{ "startTime": "YYYY-MM-DDTHH:mm:ssZ", "duration": 32400 }（秒）。
    • 可用窗口列表 (List of Availability Windows): 与上面相反，告知可用的时间段。
    • 地理覆盖图 (Geographical Coverage Map): 对于移动的UE（比如一个远洋货轮上的终端），网络可以提供一个动态的、随时间和位置变化的覆盖预测图。
    • 服务等级预测 (Service Level Prediction): 更高级的信息，不仅告知“有/无”覆盖，还预测覆盖窗口内的服务质量，例如{ "startTime": "...", "duration": 300, "expectedBandwidth": "5 Mbps", "expectedLatency": "80ms" }。

  2. “如何传递” (Service-based Interfaces): 这指的是技术实现方式，即API的设计。解决方案的核心，是利用像SEAL这样的应用使能平台。

    • AS/AF侧的接口：阿里斯博士的总部应用服务器（AS）需要一个标准化的API，让它可以向SEAL服务器查询。例如，发起一个HTTP请求：GET /seal/v1/ntn-coverage?ueId=gaia-node-073&predictionWindow=7d。SEAL服务器在经过鉴权后，会返回一个包含未来7天不可用时段列表的JSON响应。
    • UE侧的接口：网络也可以通过SEAL的配置管理服务，将这份“时间表”主动推送到UE上的SEAL客户端。UE上的应用（如“盖亚之眼-节点”的固件）就可以通过本地API从SEAL客户端读取这份配置。

场景模拟： 阿里斯博士的总部服务器（AS）需要向所有100个“盖亚之眼-节点”下发一个新的固件更新包。

  1. AS首先调用SEAL的API，获取所有节点未来一周的“可用窗口列表”。
  2. AS的后台调度系统，根据这份列表，为每个节点智能地规划出最优的下发时间，并将更新任务放入一个时间优先队列中。
  3. 当某个节点的“黄金窗口”到来时，调度系统才触发对该节点的固件推送。这就避免了在“网络阴影期”的无效尝试，极大地提升了大规模设备管理的效率和成功率。

2.2 开放问题二：如何管控信息的暴露？

  • Whether and how the application enabler enforces policies (e.g., based on the time of the day, the UE location, etc.) on the discontinuous coverage information exposure towards the vertical applications.

深度解析：

“卫星过境时间表”是一份非常宝贵的网络资源信息。运营商不可能、也不应该无条件地将它暴露给所有应用。因此，必须有一套灵活的策略管控（Policy Enforcement） 机制。

这个问题的核心是回答：谁可以看？能看什么？在什么条件下能看？

  1. 谁可以看 (Authorization):

    • 只有经过运营商认证和授权的应用服务器，才有权限调用覆盖预测API。
    • 不同的应用，根据其订阅等级或业务类型，可能获得不同级别的访问权限。

  2. 能看什么 (Granularity):

    • 付费高级应用：也许可以获取未来一个月的、秒级精度的、包含QoS预测的详细覆盖报告。
    • 免费或低优先级应用：可能只能查询未来24小时的、分钟级精度的、仅包含“可用/不可用”状态的简要信息。

  3. 在什么条件下能看 (Context-awareness): 策略的执行可以是动态和上下文感知的。

    • 基于UE位置：应用只能查询其所服务的、位于特定地理区域内的UE的覆盖信息。
    • 基于时间：在网络繁忙时段，API的调用频率可能受到限制。
    • 基于安全策略：在某些敏感区域或特定情况下，网络可能会拒绝提供任何预测信息。

阿里斯博士项目中的策略实例： 运营商为阿里斯博士的项目配置了如下策略：

  • 策略1（针对“盖亚之眼”关键业务）：凡是服务ID为gaia-node-critical的应用，允许其查询名下所有传感器未来30天的、秒级精度的覆盖信息，且API调用不受频率限制。这是因为这些传感器的数据对科研至关重要，且需要长期的能源规划。
  • 策略2（针对访客临时应用）：项目访客使用的、服务ID为guest-app的非关键应用，只允许查询当前位置未来12小时的覆盖信息，且API调用频率限制为每小时一次。

通过这套策略引擎，应用使能平台（SEAL）就从一个单纯的“信息管道”，变成了一个智能的“信息门卫”，确保了网络资源信息在开放的同时，兼顾了安全、公平和商业利益。

3. 总结：化“天堑”为“节拍器”

“关键问题#3”直面了卫星物联网（尤其是基于稀疏LEO星座的）最核心的挑战——非连续覆盖。3GPP的研究给出的答案，不是如何去“对抗”这种中断，而是如何去“拥抱”和“利用”它。

其核心思想是，利用卫星轨道的可预测性，将不确定的网络中断，转化为应用层可以感知的、确定性的“工作节拍”。网络通过一个标准化的、受策略管控的应用使能接口，将这份“节拍表”（即覆盖时间表）交给应用。

获得了这份“节拍表”的应用，就如同得到了一位指挥家的指挥棒，能够：

  • 在休止符时（网络阴影期），进入深度休眠，保存宝贵的能源。
  • 在强音符前（黄金窗口期），提前准备，将数据打包，以求在最短时间内爆发出最高效的传输。

这种从“被动响应”到“主动规划”的模式转变，是实现大规模、长寿命、低成本卫星物联网的关键。它不仅解决了阿里斯博士的“能源危机”，更为未来万物互联延伸至地球的每一个角落，提供了坚实而智慧的技术基石。

FAQ环节

Q1：非连续覆盖问题只存在于LEO卫星吗？GEO和MEO卫星有没有类似问题？ A1：非连续覆盖主要是稀疏LEO星座的典型特征。GEO（地球静止轨道）卫星相对地面是静止的，一旦你在其覆盖范围内，理论上是24/7连续覆盖的，不存在“过境”窗口。MEO（中地球轨道）卫星介于两者之间，它也在移动，但轨道更高、覆盖范围更大，因此通常需要比LEO更少的卫星来形成连续覆盖，但稀疏部署的MEO星座也同样会产生非连续覆盖问题。所以，这个问题主要针对NGSO（非静止轨道）卫星，在稀疏LEO场景下表现得最为突出。

Q2：如果UE是移动的，比如一艘远洋货轮，这个“卫星过境时间表”还准吗？ A2：非常准，但这需要更高级的交互。对于移动的UE，简单的“静态时间表”不再适用。此时，UE需要将其未来的航线规划（planned route） 或预测轨迹上报给网络。应用使能平台（如SEAL）会结合卫星的轨道信息和UE的移动轨迹，进行动态计算，生成一份为这艘货轮“量身定制”的、随时间地点变化的动态覆盖预测。这是该技术更高级、更智能的应用形态。

Q3：这个功能与3GPP的“Store & Forward（存储转发，S&F）”是什么关系？ A3：它们是解决非连续覆盖问题的两种不同层面、但紧密相关的技术。S&F是一种网络层能力：当UE发送数据时若无端到端链路，网络（卫星或地面节点）可以先把数据存起来，等链路恢复后再转发。而KI#3讨论的是一种应用使能能力：网络将“何时有链路”这个预测信息告诉给“应用层”。两者可以协同工作：应用根据KI#3的预测，决定在“黄金窗口”发送数据；如果此时恰好馈线链路不通，网络则启动S&F机制。应用还可以利用S&F事件信息（这是KI#7要讨论的），进一步优化自己的行为。

Q4：为什么不让UE自己装个App来计算卫星轨道和过境时间呢？ A4：这是一个很好的问题，涉及到“职责划分”。让UE自己计算有几大弊端：1) 功耗和计算开销：对于低功耗的IoT设备，运行复杂的轨道模型计算本身就是一种巨大的能源负担。2) 信息不完整：UE只知道公开的星历，但不知道运营商网络的实时状态，比如哪个卫星波束的负载更低、哪个馈线链路正在维护等。3. 更新和维护困难：卫星星座在不断调整和更新，让数以亿计的终端去同步和维护这些信息是不现实的。因此，由网络侧作为权威的“信息中心”，进行统一计算和发布，是最高效、最可靠的架构。

Q5：这些覆盖预测信息，是属于控制面信令还是用户面数据？ A5：这些信息属于控制面信令的范畴。它不属于用户的业务数据（如视频流、网页内容），而是网络提供给应用的一种“元数据”或“服务信息”。它通常会通过专门的控制面路径进行传输，例如通过SEAL的配置管理接口，或者通过5G核心网的Nnef（网络能力开放功能）接口暴露给可信的第三方应用服务器。这确保了它与用户数据平面的分离，便于进行独立的策略控制和安全管理。

关系图谱