A Holistic Approach to Non-Terrestrial 5G Networking with LEO Satellites: Algorithms, Experiments, and Insights

第一次正式读 CoNEXT 的文章, 听老师说这一篇内容很不错, 虽然创新性就那样. 对于一个想要快速补充 NTN-LEO 背景知识的researcher来说, 这是一份很好的上手材料. 🚀

看起来CoNEXT的文章比较长, 系统实现的要求比较低, 偏算法. 有点 INFOCOM 那味了. 😄

简单概括一下本文, 笔者的重点在于 NTN RAN Architecture:

背景: NTN + 5G

挑战: 简单的将地面蜂窝网络架构(如gNB)搬到卫星上会失效, 主要原因是: 基础设施的高移动性

现有方案缺陷: 盲目应用地面范式会导致

• 频繁且昂贵的 Handover
• 由于核心网信令导致的延迟增加
• 网络资源利用率低

解决办法:

• 架构层面
  1. 功能切分 (基于O-RAN):
     • CU + DU: 地面网关 (GW)
     • DU + RU: 卫星上
  2. 技术特点:
     • 将昂贵的 "interCU"切换, 变成轻量化的 "interDU"切换
     • 主动预切换: 利用 TLE, 提前建立隧道
• 算法层面: ...

---

Introduction 核心内容

1. 背景:
   1. 宽带卫星网络 (Starlink, Kuiper, OneWeb) 已成现实, NTN 将 5G 扩展到卫星是合乎逻辑的下一步
   2. 目前 5G NTN 已被纳入 3GPP 标准, 商业上也有 Direct-to-Cell 的进展, 但关于无线接入网(RAN)各层如何具体映射到卫星网络的细节仍然很少
2. 现有方法的局限性:
   • 简单地将地面蜂窝系统(如将基站部署在网关/卫星上)移植到 NTN 会失败
     1. 后果1: 昂贵的切换(延迟高达 4 倍), 严重影响用户体验(QoE)
     2. 后果2: 网络效率低下, 利用率低于总容量的 50%
3. 核心问题:
   • TN 与 NTN 的根本区别在于"基础设施的移动性": TN 中移动的是用户, 而 NTN 中承载连接的基础设施(卫星)是高度移动的
4. 解决思路/方案: HARMONI 框架
   • 解决思路: 利用固定地球小区(Fixed-earth cells)和卫星网关的稳定性, 来抽象和屏蔽 RAN 内部卫星的移动性
   • 方案:
     • 利用 O-RAN 框架将基站功能解耦: 在卫星网关部署 CU-DU, 在卫星上部署 DU-RU, 并通过 IAB 接口连接
     • 采用时空分层的会话编排算法: "粗时间尺度"做负载均衡; "细时间粒度"各网关独立编排会话迁移
5. 评估与贡献: ...

---

Need for a Holistic NTN Approach 核心内容

这一部分主要阐述了当前 NTN 面临的架构选择难题以及多目标编排的困境:

(1) RAN 架构的选择与挑战

这一小节探讨了将地面网络架构移植到卫星网络时的不同方案及其对用户体验(QoE)的影响

• 三种主流架构选项:

  • 透明转发 (Transparent): 整个基站(gNB)位于地面网关, 卫星仅作信号转发, 无星上处理能力 (3GPP R17)
  • 整体式基站 (Monolithic gNB): 整个 gNB 部署在卫星上, 支持ISLs (3GPP R19)
  • CU/DU 分离 (Split CU/DU): HARMONI 采用的架构, 将 CU+DU 部署在地面网关, DU+RU 部署在卫星上

• 整体式基站架构的缺陷:

  • 虽然解决了 ISL 问题, 但当用户切换卫星时, 必须同时切换 gNB-CU
  • 这种 跨 CU 切换 (Inter-CU HO) 非常昂贵, 因为它需要与核心网的AMF(on ground)进行消息交换
  • 在逻辑上, 仅因为基础设施(卫星)移动而让核心网处理切换是不合理的

• CU/DU 分离架构的优势:

  • 卫星切换 触发的是跨 DU 切换 (Inter-DU HO), 这种切换在逻辑基站内部完成, 无需核心网参与
  • 尽管涉及的消息数量略多, 但由于不需要 AMF 更新, 整体切换耗时更短, 能显著减少对用户瞬时吞吐量的影响

(2) 编排难题: 多 KPI 的权衡

这一小节讨论了在卫星高速移动的背景下, 如何管理用户, 卫星与网关之间的连接(即会话编排), 并指出了现有单一目标策略的局限性.

• 编排的核心问题:

  • 由于大型星座中同一地点可见多颗卫星, 网络需要决定: 卫星服务哪个区域? 用户连接哪颗卫星? 卫星通过哪个网关回传流量?
  • NTN 需要同时满足四个关键 KPI: 覆盖范围, 低延迟, 高稳定性(减少切换), 以及公平满足用户需求.

• 现有策略的局限性:

  • Local Schemes:
    • 贪婪算法 (greedy): 用户和卫星 总是连接最近的节点, 通过最短路径降低延迟
      • 缺点是会导致极其频繁的切换, 严重影响稳定性
    • 保持策略 (sticky): 尽可能长地保持连接以提高稳定性
    • 共同缺陷: 这类基于本地决策的方案会导致严重的负载不均衡. 大部分流量会汇聚到少数卫星和网关, 导致拥塞, 网络容量利用率低于 50%
  • Global Optimization:
    • 尝试通过中心化计算实现全局最优连接, 以最大化网络利用率
    • 缺陷: 这是一个 NP-Hard 问题, 无法扩展. 在大型星座场景下, 计算耗时过长(>20秒), 无法适应卫星的快速动态变化

• 结论:

  • 盲目复用地面网络的范式会导致在某个 KPI 上表现尚可, 但在其他关键维度上不可接受
  • 需要一个新的框架(即 HARMONI)来兼顾可扩展性, 并同时平衡容量, 延迟和稳定性

---

HARMONI Design 核心内容

实体映射与架构解析:

• RAN 实体的映射与重组:

  • HARMONI 将 RAN 实体(UE, Area, BS)映射到卫星网络组件(GW, 馈电卫星, 服务卫星)上
  • "服务卫星"与"馈电卫星"的区别纯粹是逻辑上的, 同一颗物理卫星可以利用不同的射频链路同时行使这两种职能.
  • 系统假设使用"固定地球小区"(fixed-earth cells)来模拟静态的地面蜂窝小区.

• 基于 IAB 的分离式架构(Split RAN):

  • HARMONI 将基站功能进行切分: 在每个地面网关(GW)部署完整的 CU/DU, 而在卫星上部署 DU/RU.
  • 卫星与网关之间以及卫星与卫星(ISL)之间的连接, 均通过 IAB(集成接入与回传) 接口执行.
  • 这种架构通过 将昂贵的"跨 CU 切换"转化为低延迟的"跨 DU 切换"来提升系统稳定性, 并将每个用户锚定在单一的 GW-CU 上.

• 轨迹感知的"主动"切换(Trajectory Aware HO):

  • 利用 TLE 数据库追踪可预测的卫星轨迹, 系统能计算何时需要切换, 并主动发起跨 DU 切换程序.
  • HARMONI 会在实际切换发生前, 预先建立从网关到目标卫星 DU 的必要承载/会话隧道.
  • 这种预先操作消除了信令交互对用户体验(QoE)的影响, 实现了极低的切换延迟.

• 通过 IAB 实现高效路由:

  • IAB 网络内部的路由由回传自适应协议(BAP)管理, 该协议替代 IP 来管理逐跳寻址.
  • HARMONI 利用 IAB 抽象了底层的 ISL 路由细节, 从而专注于上层决策: 即为每个会话选择最佳的"服务卫星-馈电卫星"对.

---

实验环境如何部署? 对 StarryNet 做了哪些扩展?

通过 StarryNet 仿真平台与 HARMONI 控制逻辑（Python 实现）相结合的方式进行部署:

1. StarryNet 生成 Cell demands 和 Trajectories, 并将这些数据发送给 HARMONI 组件

2. HARMONI（使用 Python 实现）执行会话编排算法，计算出慢速（粗时间尺度）和精细时间尺度的分配方案，并将结果反馈给 StarryNet

3. StarryNet 根据分配方案计算星座内的 ISL 路由

对 StarryNet 的扩展:

(1) 修改了节点实体，以便将特定的 NTN RAN 架构（如星上 gNB 或 CU/DU 分离架构）映射到这些节点上

Additionally, we modify both the GroundNode and Satellite entities such that we can map particular NTN RAN architectures onto them, e.g. gNB-on-board, CU/DU split.

(2) 在 StarryNet 原有的 Satellite 和 GroundNode 基础上，增加了区分 UE（用户设备）和 GW（网关）节点的功能

In StarryNet, all nodes are either Satellites or GroundNodes. In order to emulate NTNs, we add the functionality needed to represent the different capabilities of UE and GW nodes.