跳转至

Workflow

最近会把与D2C文章对应的“实验环境部署”单独整理一遍

(1) “用户-卫星-地面站”三端的物理原型：

逻辑组件 物理实现 rule
地面UE UERANSIM 模拟一个或多个5G用户设备，负责发起信令请求
SpaceCore卫星 Raspberry Pi 4 (HW)

SpaceCore逻辑修改/优化的open5gs (SW)		 运行SpaceCore的核心功能，作为UE和地面站之间的中继和处理节点
地面HomeNet (CoreNet) ThinkStation P910

完整、标准、未经修改的Open5GS (SW)		 运行全功能的5G协议栈核心网，是信令的最终“归宿”和权威来源

物理连接关系 (Physical Connections):

  • UE <-> 卫星: UERANSIM（UE）通过模拟的无线链路将信令发送到树莓派（卫星）
  • 卫星 <-> Home: 树莓派（卫星）通过物理网络连接（以太网）与ThinkStation（HomeNet）通信，模拟“星地链路”

(2) 通过触发三个核心流程，来对比SpaceCore与传统方案的数据流路径和性能：

Workflow 1: Initial Registration

  • SpaceCore的数据流:
    1. UE (UERANSIM) 发起“初始注册”请求
    2. 请求 → 卫星 (Pi)
    3. 卫星 (Pi) 将请求转发 → 地面Home (ThinkStation)
    4. 地面Home (ThinkStation) 进行鉴权和处理
    5. response: HomeNet → 卫星 (Pi) → UE (UERANSIM)
  • 流程特点:
    • 这是一个必须与地面Home站交互的“长路径”流程
    • SpaceCore在此处遵循5G标准，延迟合理

Workflow 2: Session Establishment

这是UE在注册后，发起数据（如上网）连接的流程

  • SpaceCore的数据流:
    1. UE (UERANSIM) 发起“会话建立”请求，并附带上之前存储的“状态”
    2. 请求 → 卫星 (Pi)
    3. 卫星 (Pi) 接收请求，利用UE提供的状态在轨（本地）完成状态迁移和处理，无需转发给地面站
    4. response: 卫星 (Pi) → UE (UERANSIM)
  • 流程特点:
    • 这是一个被本地化 Localized 的“短路径”流程
    • dataflow仅在“UE-卫星”之间，因此延迟最低，且卫星CPU开销很轻（只做轻量化处理）

Workflow 3: Mobility Registration

这是UE跨越不同卫星服务区（Service Area）时发生的切换流程

  • SpaceCore的数据流:
    • 无信令流程 (No Signaling Flow)
  • 流程特点:
    • SpaceCore的 "地理空间移动性管理" + "无状态" 设计彻底避免了这一流程
    • UE在跨越卫星时不需要执行任何注册信令，因此延迟和CPU消耗几乎为零

(3) LEO 的高速动态性是如何加入当前prototype的？

控制器扮演着“上帝”的角色: 根据卫星的“虚拟位置”，动态地、强制地触发UE（UERANSIM）在不同卫星（树莓派）之间进行切换

用 Software Emulation 来驱动 Hardware Prototype

仿真控制器如何做:

  1. 加载前置信息:
    • 加载真实的LEO星座轨道数据
    • 加载全球UE密度数据
    • 加载地面站分布
  2. 初始化. 移动性注册:
    • T=0 时刻，仿真器计算出 UE - Sat Instance - GS Instance
    • 自动配置网络
  3. 触发“切换”
    • 仿真器根据轨道数据更新位置: \(Sat_1\) 已经飞走，现在 \(Sat_2\) 正在飞来
    • 仿真器感知到这个拓扑变化
    • 它向 \(UE_A\) (UERANSIM) 发出一个模拟的信令，强制触发 Handover 事件
    • \(UE_A\) 现在必须断开与 \(Sat_1\) 的连接，转而尝试连接到 \(Sat_2\)

这里就可以体现出一个非常明显的弊端! 就是我只能单个模拟设备的行为, 而 不能给整个星座进行群体画像