跳转至

A Case for Stateless Mobile Core Network Functions in Space

yuanjie 老师的颠覆性神作, 值得逐帧学习

这篇文章最重要的意义是:

  1. 指出当前有状态移动核心设计, 在卫星的极端移动性和太空环境中, 存在可扩展性、性能和安全性等问题
    • 信令风暴
    • 对故障/攻击的脆弱性
  2. 提出 SpaceCore "无状态"移动核心的解决方案
    • 将状态与轨道核心功能解耦, 利用地理空间寻址简化位置状态
    • 以device-as-repo实现状态检索本地化, 显著减少信令开销并增强对故障和攻击的弹性

Abstract 重点:

  1. 探讨了将 5G CoreNet 功能推送到 LEO 的可行性和价值
  2. 主要挑战在于当今有状态的移动核心网络
    • 在卫星极端移动性中产生信令风暴
    • 在外太空出现间歇性故障
    • 在暴露于不受信任的外国地点时, 易受攻击
  3. 提出了在太空中部署 stateless 移动核心网络的方案: SpaceCore
    • 将状态与轨道核心功能解耦
    • 通过地理空间寻址来简化位置状态
    • 通过 "转向地理空间服务区域", 消除卫星移动中不必要的状态迁移
    • 通过 "device-as-repo", 执行本地化状态检索

通过使用运营卫星和 5G 数据集进行的评估显示, SpaceCore 实现了比现有解决方案信令减少 17.5 倍, 并且对故障和攻击具有弹性

采用的方案乍一看会不知所云, 读完整篇文章才能概括

建议读完整篇文章/本篇Blog之后, 再自行对照一下 👍

(1) 将状态与轨道核心解耦，通过地理空间寻址简化位置状态

机制 SpaceCore (无状态) 传统核心网 (有状态)
核心理念 状态与功能解耦。S2 归 Sat_IP, S1345 归 UE 状态与功能紧密耦合，核心网络功能（如 AMF, SMF, UPF）必须维护用户会话所需的五大类状态（S1-S5：标识符、位置、QoS、计费、安全）
位置状态 (S2) 管理 简化位置状态：通过地理空间寻址重新定义用户的 IP 地址，将地理位置坐标嵌入其中。用户地址是固定的，只有当用户实际跨越大的地理空间区域时才会改变 复杂位置状态：用户的位置状态（S2）由逻辑上的 Cell ID + Tracking Area ID + IP 组成，这些 ID 绑定到特定的功能节点（基站/AMF）
效果对比 减轻卫星负担和安全风险：卫星本身不需要存储或管理敏感的用户状态，降低了在不可信外太空存储敏感信息（如安全密钥）的风险 负担重且易受攻击：在 LEO 卫星上维护这些状态，使得卫星易受攻击，可能导致敏感状态泄露

(2) 通过转向地理空间服务区域，消除了卫星移动中不必要的状态迁移

机制 SpaceCore (地理空间区域) 传统核心网 (逻辑服务区域)
服务区域定义 地理空间服务区域 (Geospatial Service Areas)：服务区域（小区/跟踪区域）被定义为地球上固定的、稳定的地理坐标区域，与上空快速移动的 LEO 卫星解耦 逻辑服务区域：服务区域被定义为与提供服务的功能节点（例如 LEO 卫星上的 AMF 或基站）紧密耦合的逻辑区域
状态迁移原因 仅当 UE 物理移动：只有当 UE 实际跨越 SpaceCore 定义的大块地理区域时，才需要进行移动性注册更新或状态迁移. 这个的概率很低很低 由基础设施移动触发: 由于 LEO 卫星以极快的速度（高达 7.6 km/s）在轨道上运行，即使地面上的用户是静止的，其逻辑服务区域也会不断移动. 这导致用户必须频繁地重复执行移动性注册
效果对比 消除信令风暴: 消除了由于卫星移动导致的针对静止用户的不必要的状态迁移和重复注册，从而避免了大规模信令风暴 引发信令风暴：频繁的状态迁移操作（如移动性注册更新和切换）会产生巨大的信令开销. 耗尽卫星硬件资源并延迟服务

(3) 基于 device-as-the-repository 来实现状态的本地化检索

机制 SpaceCore (本地化检索) 传统核心网 (远程状态检索)
状态存储位置 设备作为存储库：在完成初始注册后，UE 本地存储了由地面核心网（Home Network）加密和授权的会话状态副本
UE 本身成为了一个可扩展、分布式、有弹性且安全的状态存储库		 基础设施存储：状态存储在地面（Home Network）或卫星网络中的特定基础设施功能节点（如 UDM、AMF/SMF）中
状态检索过程 本地检索：当 UE 想要激活会话或发生卫星切换时，它将本地存储的状态副本附带在信令消息中（piggybacks）发送给它当前服务的 LEO 卫星
该卫星（运行无状态核心功能）随后可以解密并本地安装这些状态，立即为用户提供服务		 远程检索：如果 UE 由一个新的卫星服务（特别是当核心功能分散在地面或不同卫星时），该新卫星必须通过复杂的信令交换，远程从地面锚点网关或核心网功能节点（如 UDM）获取会话状态
效果对比 高性能和弹性：本地化检索消除了对远程锚点网关的单点瓶颈依赖。状态操作无需通过冗长的、跨越不可靠卫星链路和天地链路的多跳迁移，大大加快了会话建立速度，并在卫星故障或链路中断时更具弹性 瓶颈和延迟：远程状态获取导致空间-地面不对称瓶颈。这会导致会话建立延迟过高

Introduction 重点:

alt text

  1. 移动网络的现状与挑战
    • 覆盖范围限制
    • 服务扩展限制: 固定的部署限制了区域运营商扩展到国际服务
    • 基础设施脆弱性
  2. 将移动网络推向太空的潜力
    • 早期的移动卫星 (GEO) 是独立、透明的物理管道，覆盖广但性能低 [fig 1a]
    • 当前，运营商和基础设施供应商开始尝试将 LEO 卫星用作 5G 无线电接入和核心网功能 [fig 1b]
  3. 将 stateful核心网 推向太空的争议
    • LEO 卫星的极端移动性会导致信令风暴 (每颗卫星 104 信令/秒, 每个地面站 105 信令/秒)
    • 即使是静止的用户，也需要重复进行移动性注册 (165.8 秒/次)
    • 在太空故障中容易导致服务中断 (starlink 3%)
    • 卫星不可避免地暴露在不受信任的外国地点，容易受到攻击和敏感状态泄露的威胁
  4. 问题根源: 状态管理!
    • 问题源于当今的 "stateful移动核心网", 它必须在 UE 移动时迁移状态 (流量传输/移动性/QoS/计费/安全状态) 以维持连续服务
    • 这种设计对于 LEO卫星移动性 导致的 静态UE状态迁移 来说成本过高且脆弱
  5. 解决方案: SpaceCore
    • 在太空中部署无状态移动核心网, 将核心功能与状态解耦. 以减轻卫星上过度的状态迁移、故障和攻击
    • 主要挑战: 在解耦后, 如何能继续维持运营商级的服务 (流量传输/移动性/QoS/计费...)
    • 解决方案: 基于 "本地UE 天然地 构成了一个可扩展、有弹性、安全的分布式状态存储库" 关键洞察
      • 将状态与轨道核心解耦, 通过地理空间寻址简化位置状态
      • 通过转向地理空间服务区域, 消除了卫星移动中不必要的状态迁移
      • 利用 device-as-a-repo 来实现状态的本地化检索

Motivation 重点:

  1. Terrestrial Mobile Networks:
    • 核心网: 在基站之间中继流量，并运行各种功能以提供运营商级服务
      • 例如: 用户配置文件管理、认证、移动性控制、会话管理、策略控制、流量转发和 anchor alt text
    • 现有的 “服务区域跟踪” 方案:
      • 通过 两级服务区域 来跟踪 UE 的位置和服务
      • 细粒度: 小区 (cells). 由每个基站运行, 用于处理 UE 移动时的切换
      • 粗粒度: 跟踪区域 (tracking areas). 由多个基站组成, 当 UE 跨越跟踪区域时需要通过 "mobility registration update" 通知核心网
  2. 移动卫星的现状与局限性:
    • 默认模式-transparent: 卫星仅在地面节点之间 "中继" 物理无线电信号
      • 空间-地面不对称性 (space-terrestrial asymmetry): 所有数据和信令都重定向到遥远的地面站进行处理, 地面站成为单点瓶颈. 这导致注册延迟极高 alt text
    • 卫星运行无线电基站功能: 减轻 BS 瓶颈, 允许手机直接访问
      • 这并不能解决 "space-terrestrial asymmetry"
      • link-layer radio access 没法路由数据, 还是得转发到 remote terrestrial home
      • 将 RAN 与 CoreNet 分隔开, 会导致超级信令风暴
  3. CoreNet 新趋势: 将 5G 移动性(AMF) / 会话管理(SMF) / 用户平面(UPF) 等核心功能也整合到 LEO 卫星
    • 现在卫星上同时拥有 RAN 和 CoreNet Functions

Stateful Mobile Core in Space 重点:

(1) "functions" 上星的程度 [四个选项]:

alt text

  1. 如果卫星中没有移动性功能 (6a-6b), 信令风暴源于 stateful session establishment
  2. 如果卫星中添加了移动性功能 (6c), 尽管减轻了上述缺陷, 但由于 LEO 卫星的极端移动性, 会引发针对静止用户的更多信令风暴

🌟我们将在(5)专门总结一下这四种options🌟

(2) 信令风暴 (Exhaustive signaling storms):

  1. 图6中的所有option都会引发信令风暴
  2. 由于空间-地面不对称性，地面站的开销比卫星高出一个数量级
  3. 信令风暴会消耗卫星硬件资源、堵塞地面站，并延迟用户服务 [fig.7 + fig.8] alt text

(3) 会话建立中的缺陷:

这里给出 TN-5G 的 "注册" 和 "会话建立" 步骤:

alt text

可以看出: AMF/SMF 作为这一环节的“控制中心”, UPF是数据出入口

  • AMF authenticates the UE
  • SMF selects a UPF as the anchor gateway to form a session
  • UE first establishes a radio connection with the base station
  • base station sends a service request to AMF, which copies the session states to the base station for QoS

(3.1) stateful session 定义:

为了提供运营商级服务, 移动网络在 UE 和固定锚点网关之间建立会话, 并维护五类状态 (S1-S5): 标识符、位置、QoS、计费、安全

5G CoreNet 中的 S-1,2,3,4,5
  • S1: UE的uuid
  • S2: UE位置信息 (Cell - TrackingArea - IP)
  • S3: QoS and Rules
  • S4: Billing
  • S5: Security

(3.2) space-terrestrial asymmetry 导致的瓶颈:

  • data-plane: 每个会话都耦合到一个远程的地面锚点网关. 全球用户的流量都会重定向到这个网关, 使其成为单点瓶颈
  • ctrl-plane: 如 LEO 只具有无线电或会话功能(fig. 6a-6b), 它们需要从地面站获取会话状态. space-terrestrial asymmetry和卫星路由下, 导致信令开销在卫星链路和地面站聚集

(4) 基础设施移动性带来的缺陷:

这里给出 TN-5G 的 "handover" 和 "mobility registration update" 步骤:

alt text

  • 细粒度: 还是由同一个CoreNet管辖, migration核心过程只需要 BS-1, BS-2, AMF 参与即可
  • 粗粒度: 隶属于不同的CoreNet了! migration核心过程需要 AMF-1 和 AMF-2 等共同参与

(4.1) 冲突核心: 传统移动网络的设计前提是基础设施（Base Station / AMF）是固定锚点

(4.2) “移动的服务区域快速切换” 带来的问题

如果将移动性功能（如 AMF）推送到 LEO 卫星，该卫星作为逻辑基站或 AMF，将导致快速移动的“小区”和“跟踪区域”

alt text

因此: 用户被动地跟着需要快速切换

由于 LEO 卫星对地面用户只有短暂的覆盖(Starlink: 165.8s), 这些静止用户必须频繁触发 "Handover" 和 "Mobility registration update", 导致卫星和地面站产生过高的信令开销

(5) Resiliency in Harsh Foreign Space:

地面核心网的弹性假设: 地面网络依赖于基础设施是可信、未被篡改且可靠的前提

但这在LEO中根本不成立:

  1. 卫星的故障问题: 卫星故障 / 无线间歇性重连接
  2. 卫星不可避免地暴露在外国地点

alt text

(6) 这一节信息量很大, 简单梳理一下逻辑:

  1. 传统模式下的会话建立瓶颈 (6a, 6b)
    • 当前做法: LEO 卫星只运行无线电接入功能(Opt1) 或 加上数据会话功能(UPF, Opt2); 但缺乏核心控制功能, 特别是移动性管理功能(AMF)
    • 问题核心: 要建立data session, UE 必须首先与基础设施建立会话: 如果 LEO 卫星没有这些核心控制功能, 它们就必须通过复杂的信令交换从 遥远的Terrestrial HomeNet 获取 session state alt text
    • 结果: 信令开销在卫星链路和地面站处聚集，从而形成信令风暴
    • 根本原因: 源于stateful的会话建立过程中对远程状态的依赖和获取 (三角路由 + 单点拥塞)
  2. 添加移动性功能后的缓解 (6c, 6d)
    • 做法: 将移动性管理功能 (AMF) 和会话管理功能 (SMF) 整合到 LEO 卫星上
    • 动机: 当 AMF/SMF 位于卫星上时, 在静态场景下(用户或基础设施没有移动), 卫星可以本地化信令处理
    • 结果: 消除了 session establishment 中对远程地面站进行 状态获取 和 信令交换 的依赖
  3. 新的缺陷出现 (弊大于利!!!)
    • 设施高速移动: 当 AMF/SMF 被推送到快速移动的 LEO 卫星上时，这些卫星成为了逻辑上的快速移动的“小区”和“跟踪区域”
    • 用户切换被迫发生: 即使地面用户是静止的，他们也必须频繁地触发 "handover" / "mobility registration update" 程序 alt text
    • 结果: 这种由基础设施移动性引起的移动性注册信令风暴会进一步耗尽卫星的 CPU并延迟用户服务 alt text
options 分析

AMF在地面: stateful的会话建立过程, 对远程状态存在依赖和获取

-> 三角路由 + 单点故障

AMF上卫星: stateful的细/粗切换过程, 对远程状态存在依赖和获取

-> 星地连接切换过于频繁!

A Case for Stateless Orbital Core 重点:

🚀在太空部署无状态、去中心化、轻量级的移动核心网功能🚀

(1) 核心架构

alt text

  • Key Insight:
    • UE 天然地构成了卫星核心功能的分布式状态存储库
  • WorkFlow:
    • UE 在初始注册后已复制并存储了会话状态
    • SpaceCore 利用这一现成特征，将状态与轨道核心解耦
    • 避免了远程多跳状态迁移、基础设施移动带来的不必要过程调用，以及状态泄露
  • Components:
    • UEs
    • Stateless && Decentralized satellites
    • Terrestrial Home

(2) 核心机制

alt text

  1. 放弃 "两级服务区域提供位置服务", 直接采用地球坐标系
    • 现有 "2-level位置查询", 会绑定到逻辑区域, 即: 快速移动的卫星
    • 放弃它!
    • 将 cell/area 重定义为: 地球上固定的地理空间区域
    • 这样确保了服务区域的稳定, 消除了卫星移动带来的无数状态迁移
  2. 简化位置状态表示 (S2)
    • 由于地理空间单元与卫星解耦, 快速移动的 LEO 卫星不再需要跟踪 UE 的逻辑位置
    • SpaceCore 只保留 UE 的 IP 地址作为其位置状态. IP 地址包含地理空间 ID
    • UE 的地址大多数都能保持固定, 除非它移动到新的地理空间单元 (这很少发生, 因为地理单元尺寸很大)
  3. 其他状态表示 (S1 S3 S4 S5) 都放在 UE 处
    • UE 作为分布式地理空间本地状态存储库，使其状态不受 状态迁移 或 泄露 的影响

(3) UE 辅助的本地化状态管理

SpaceCore 利用 UE 上的 state replica 来本地化管理会话建立、移动性和安全性

alt text

  1. 本地化 session establishment
    • 上行会话建立
      1. UE 在无线连接建立时, 将 state replica 附加(piggybacks) 到服务卫星
      2. 如果卫星被授权(通过安全验证), 它可以本地解密并安装这些状态, 立即提供服务
      3. 从而避免了 "三角路由 + 单点故障"
    • 下行会话建立
      1. 采用无状态地理空间数据转发
      2. 卫星根据目的 UE IP 地址中嵌入的地理空间单元信息和卫星的运行时坐标, 选择物理上最近的下一跳卫星进行转发. 直到数据到达覆盖目标 UE 的卫星
        C++
        1
2
3
4
        if (sat_contain_UE() == true)
    sat_UE_establishment();
else
    send_to_neighbors();
  2. 地理空间移动性管理
    • 减少不必要的registration: 消除了 由于LEO卫星移动 导致的 针对静止UE的跟踪区域更新 (移动性注册)
    • 优化handover:
      • 原有: migrating the old satellite’s states to the new satellite, which suffers from multi-hop delivery
      • 现在: 对于有活动连接的 UE, 当其切换到新卫星时, UE 可以将 state replica 附加在切换确认消息中发送给新卫星, 实现等效但更短的状态迁移路径
  3. 归属网络控制的状态更新与安全

Implementation 重点:

组件 硬件 软件 / 库
卫星 (Satellites) 1. 树莓派4 (Raspberry Pi 4)
2. Precision 7920 工作站 (CPU: Xeon E5-2630, 20核, 2.2GHz)		 open5gs [45]
用户设备 (UEs) 未明确指定, 原型中为模拟 UERANSIM (用于原型化本地状态代理)
地面家庭网络 (Terrestrial Home) ThinkStation P910 工作站 open5gs [45] 协议栈
状态更新实现 不适用 OpenABE [104] 加密库

Related Work 重点:

  • 地面网络的研究现状:
    • 提到了基于 O-RAN/C-RAN 的无线接入研究，以及针对物联网(IoT)、无人机(UAV)等优化的核心网研究
  • 太空网络功能的初步探索:
    • 提到了近年来才开始有公司 (Lockheed Martin, Lynk, AST ...) 尝试将移动网络功能（包括核心网功能）部署到单个 LEO 卫星上
  • SpaceCore 的定位:
    • SpaceCore 的工作是在现有基础上更进一步，探索在 LEO 网络化巨型星座中实现可扩展、高性能和有弹性的移动核心网功能
    • RAN 和 CoreNet 都上天!
  • LEO 与其他平台的区别:
    • 强调了 LEO 卫星面临的恶劣环境和安全问题，这推动了 SpaceCore 采用无状态设计