跳转至

THE SPACE RTC FRAMEWORK

We present SPACE RTC, a satellite-cloud cooperative framework that enhances wide-area RTC services.

SPACE RTC Overview

SpaceRTC 的架构由三个主要部分组成，分别是云段、空间段和控制器：

Architecture

1) 云段（Cloud Segment）

  • 包含由地面云服务提供商（如 Amazon AWS 和 Microsoft Azure）支持的分布式云站点
  • 云服务提供商还部署了与其云平台紧密集成的地面站服务（Ground-Station-as-a-Service, GsaaS），使得云和卫星之间可以进行通信

2) 空间段（Space Segment）

  • 基于新兴的 LEO 卫星星座（如 Starlink 和 Kuiper）
  • 卫星之间通过通信链路互联，形成一个动态网络
  • 每颗卫星具有类似云计算的能力，可以处理并转发 RTC 流量。此外，这些卫星通过地面站与云段连接，支持卫星-云协作

3) SpaceRTC 控制器

  • 控制器负责：
    • 链路建立
    • 中继服务器选择
    • RTC 流量的分配
  • 它根据 LEO 卫星的轨迹和可用云站点的位置，动态构建卫星-云拓扑
  • 控制器通过控制信道（如 TDRS 系统）与卫星通信，并调用算法来优化流量路径

Step

在运行时，假设多个地理分布的用户需要建立 RTC 会话，SpaceRTC 的控制器会执行以下步骤：

  1. 接收用户的 RTC 请求
  2. 调用中继选择算法，选择合适的中继服务器（可以是地面云数据中心或 LEO 卫星）
  3. 调用低延迟流量分配算法，为用户之间分配低延迟路径，并将 RTC 流量分配到这些路径上

SPACE RTC System Model

系统模型定义了架构中的关键元素及其数学描述：

1) 云和空间段

  • 云站点集合：用 \(C = \{C_1, C_2, ..., C_M\}\)表示，其中 \(M\) 是总数
  • LEO 卫星集合：用 \(S = \{S_1, S_2, ..., S_N\}\)表示，其中 \(N\) 是总数
  • 用户集合：用 \(U\) 表示所有用户，每个会话 \(e\) 包含一组用户 \(U^e = \{u_1^{(e)}, u_2^{(e)}, ..., u_{P_e}^{(e)}\}\)

2) 链路类型及建立

在 SpaceRTC 的空间-地面环境中，有五种链路类型：

  1. 卫星间链路（ISL）：连接两颗卫星，例如 \(ISL(x, y), x, y \in S\)
  2. 云到卫星链路（CSL）：连接云站点和卫星，例如 \(CSL(x, y), x \in C, y \in S\)
  3. 用户到卫星链路（USL）：连接用户和卫星，例如 \(USL(x, y), x \in U, y \in S\)
  4. 云到云链路（ICL）：连接两个云站点，例如 \(ICL(x, y), x, y \in C\)
  5. 用户到云链路（UCL）：连接用户和云，例如 \(UCL(x, y), x \in U, y \in C\)
Note
  • ISL: inter-satellite link
  • CSL: cloud-satellite link (~其他论文中提到的GSL)
  • USL: user-satellite link
  • ICL: inter-cloud link
  • UCL: user-cloud link

链路能否建立取决于节点之间是否存在可见性，用二值函数 \(Vis(x, y)\) 表示。如果两个节点可见，则 \(Vis(x, y) = 1\)

每条链路有带宽限制：

  • 链路从节点 \(x\) 到节点 \(y\) 的最大带宽容量记为 \(Cap(x, y)\)，反向带宽为 \(Cap(y, x)\)
  • 用户的上下行带宽需求分别记为 \(B_u^{up} / B_u^{down}\)

3) 用户感知通信延迟

\[ \text{Latency}_{u,i,j} = L_{xy} \cdot (\alpha_{xy} + \beta_{ij}^{xy}) \]

其中：

  • \(L_{xy}\)：节点 \(x\) 和 \(y\) 间的延迟
  • \(\alpha_{xy} = 1\)：表示节点 \(x, y\) 被选为中继服务器，并且有链路建立
  • \(\beta_{ij}^{xy} = 1\)：表示从节点 \(i \to j\) 的流量通过链路 \((x,y)\)

控制器根据这些参数优化路径，从而最小化用户间的一对一延迟

RTC Latency Minimization (RLM) Problem

问题定义

目标是通过优化混合卫星-云网络中的资源分配，最小化实时通信（RTC）会话的端到端平均延迟。

输入

  1. 可用节点集合：
    • 云站点集合\(C\)
    • 低轨道卫星集合\(S\)
  2. RTC会话集合\(\mathcal{E}\)：每个会话包含一组用户\(U^e\)，这些用户通过多媒体流相互交互
  3. 卫星传输单元数量\(\lambda\)：每颗卫星能支持的最大链路数
  4. 链路容量$ Cap(x, y)$：每条链路的带宽限制
  5. 用户带宽需求
  6. 可见性矩阵\(Vis(x, y)\)：表示节点\(x\)和\(y\)是否可见（即是否可以建立链路）

输出

  1. 每个会话\(e\)的控制单元\(R^{(e)}\)（可以是云站点或卫星）
  2. 二进制变量\(\alpha_{xy}\)：表示是否在节点\(x\)和\(y\)之间建立链路
  3. 二进制变量\(\beta_{ij}^{xy}\)：表示流量如何分配到可用链路上

目标函数

最小化所有会话的平均端到端延迟：

\[ \min \sum_{e \in \mathcal{E}} \frac{\sum_{x, y \in \{C \cup S \cup U^e\}} L_{xy} \cdot \alpha_{xy} \cdot (\beta_{ij}^{xy} + \beta_{i, R^{(e)}}^{xy})}{P \cdot 2 \cdot {P^e \choose 2}} \]
  • \(L_{xy}\)：节点之间的通信延迟
  • 分母部分表示所有用户对之间的可能交互对数，用于计算平均值

约束条件

  1. 卫星链路限制：每颗卫星建立的链路数不能超过其传输单元数量

    \[ \sum_{y \in S} \alpha_{xy} \leq \lambda, ~\forall x \in S \]

  2. 可见性与链路激活条件：只有在两个节点可见时，才能建立链路

    \[ \beta_{ij}^{xy} + \beta_{ji}^{xy} \leq \alpha_{xy} \cdot Vis(x, y) \]

  3. 流量平衡条件：每个用户与控制单元之间必须有上下行流量平衡

    • 上行流量：

      \[ \sum_w (\beta_{uw}^{xy}) - \sum_v (\beta_{vu}^{xy}) = \begin{cases} 1 & u = R^{(e)} \\ -1 & u = R^{(e)} \\ 0 & 其他 \end{cases} \]

    • 下行流量类似

  4. 带宽限制：每条链路上的总流量不能超过其容量

    \[ B_u^{up} + B_u^{down} + ... ~\leq Cap(x, y) \]

Algorithm Design

论文提出了两种算法来解决上述问题：

协作中继选择算法

该算法分为两个阶段：

  1. 初始化阶段：
    • 更新可见性矩阵\(Vis(x, y)\)
    • 构建图\(G\)，其中边表示可见性
    • 选择地理中心性较高的节点作为控制单元 \(R_t^{(e)}\)，以降低通信延迟
  2. 更新阶段：
    • 针对新加入的用户，重新分配流量并更新控制单元

通过将时间划分为多个时隙，每个时隙内将网络拓扑视为静态快照，动态调整控制单元和流量分配，以应对低轨道卫星快速变化的可见性和拓扑

低延迟流量分配算法

该算法用于在给定路径上分配流量，目标是同时满足以下三个条件：

  1. 从用户到控制单元的路径跳数最少
  2. 在所有备选路径中，选择覆盖已激活链路最多的一条
  3. 确保路径上所有链路的剩余带宽足够承载流量

具体步骤

  • 搜索所有可能路径
  • 检查路径上的带宽是否足够
  • 激活路径上的链路，并更新流量分配

优化策略

  • 使用 LEO 卫星轨道的可预测性预计算最短路径 ，减少计算开销
  • 优先选择跳数少、激活链路多的路径 以优化性能