STAR FRONT OVERVIEW

To tackle the above challenges, we present STAR FRONT, a cooperative content distribution framework that leverages a number of cache servers hosted upon LEO satellites and globally distributed cloud data centers to construct pervasive, low-latency CDNs in a cost-effective manner.

为了应对上述挑战，我们提出了 STAR FRONT，这是一种协作内容分发框架，它利用托管在 LEO 卫星上的多个缓存服务器和全球分布的云数据中心以经济高效的方式构建普遍的低延迟 CDN。

A. STAR FRONT Architecture

Figure 5 plots the overview of STAR FRONT, which consists of two core components: a STAR FRONT cache set and a STAR FRONT controller. Specifically, the STAR FRONT cache set incorporates a cloud segment which is built upon geo-distributed cloud cache servers offered by public cloud providers (e.g., Amazon AWS, MS Azure), together with a satellite segment built upon emerging mega-constellations managed by satellite operators like SpaceX or OneWeb. Cloud cache servers communicate with each other via terrestrial networks. Satellites equipped with inter-satellite links (ISLs) can forward data to other satellites through space paths constructed by space routing algorithms (e.g., [34], [48]). Moreover, leading cloud providers are also actively deploying ground-stationas-a-service (GSaaS) [5], [20] which can enable pay-as-you-go ground communications to inter-connect clouds and satellites. Through GSaaS infrastructures, terrestrial clouds are able to communicate with a satellite on-demand if the satellite moves into their LoS.

图 5 绘制了 STAR FRONT 的概览，它由两个核心组件组成：STAR FRONT 缓存集和 STAR FRONT 控制器。

具体来说，STAR FRONT 缓存集包含一个云段，该云段构建在公共云提供商（例如，Amazon AWS、MS Azure）提供的地理分布式云缓存服务器之上，以及一个卫星段，该卫星段构建在新兴的、由像 SpaceX 或 OneWeb 这样的卫星运营商管理的巨型星座之上。

云缓存服务器通过地面网络相互通信。配备星间链路（ISL）的卫星可以通过空间路由算法构建的空间路径将数据转发到其他卫星。此外，主要的云提供商也在积极部署 地面站即服务 (GSaaS) ，它可以实现按需付费的地面通信，以互连云和卫星。通过 GSaaS 基础设施，如果卫星移动到它们的 LoS 中，地面云能够按需与卫星通信。

In particular, the STAR FRONT framework performs two basic operations: (i) content delivery and placement operation, by which contents are pushed from the source server to a collection of selected cache servers via inter-cloud or intersatellite paths; and (ii) request assignment operation, which at runtime redirects user requests from geo-distributed regions to a proper cache server to obtain low access latency. Both operations involve fees according to the dedicated pricing policy of cloud and satellite operators, as distributing source contents to cache servers and serve user requests may consume storage and bandwidth resources in corresponding cloud or satellite platforms. If a cache server is full, there are two viable approaches to prepare room for new contents. In particular, a content provider can either purchase more storage from the cache service provider (e.g., [3]), or run specific cache update algorithms such as Least Recently Used (LRU) to make room for new contents.

特别是，STAR FRONT 框架执行两个基本操作：

(i) 内容传递和放置操作，通过该操作，内容 通过云间或卫星间路径从源服务器推送到一系列选定的缓存服务器 ；

(ii) 请求分配操作，该操作在运行时 将来自地理分布区域的用户请求重定向到适当的缓存服务器 ，以获得低访问延迟。

根据云和卫星运营商的专用定价策略，这两种操作都涉及费用，因为将源内容分发到缓存服务器并为用户请求提供服务可能会消耗相应云或卫星平台中的存储和带宽资源。如果缓存服务器已满，则有两种可行的方法可以为新内容腾出空间。特别是，内容提供商可以从缓存服务提供商处购买更多存储空间，或者运行特定的缓存更新算法（例如，最近最少使用 (LRU)）以为新内容腾出空间。

STAR FRONT enables several forms of request assignment with different network performance and corresponding costs. First, like traditional cloud-based CDNs, STAR FRONT allows users to request contents directly from a nearby cloud cache server (e.g., ⃝ 1 in Figure 5), if the cloud performance can satisfy the application requirement. Second, if the access latency from a user to the closest cloud cache server is high (e.g., due to the insufficient deployment of cloud sites, very-long communication distance or meandering terrestrial route), STAR FRONT allows users to accelerate the content access via free-space satellite paths (e.g., ⃝ 2 in Figure 5). Satellites forward traffic between users and the corresponding cloud cache servers, and do not need to cache replicas on the satellite. Third, requests can also be directly assigned to a satellite cache (e.g., ⃝ 3 in Figure 5) when the closest available cloud is still too far away. The above three forms of assignment strategies lead to different storage and bandwidth cost in practice, since space resources are likely to be more scarce than that in terrestrial cloud servers. In particular, the first form only consumes terrestrial storage and bandwidth, the second form uses terrestrial storage and satellite bandwidth, while the last form consumes more expensive storage and bandwidth in space.

STAR FRONT 支持几种具有不同网络性能和相应成本的请求分配形式:

首先，像传统的基于云的 CDN 一样，如果云性能可以满足应用程序要求，STAR FRONT 允许用户直接从附近的云缓存服务器请求内容 （例如，图 5 中的 1）。

其次，如果用户到最近的云缓存服务器的访问延迟很高（例如，由于云站点的部署不足、通信距离很长或地面路由迂回），STAR FRONT 允许用户通过自由空间卫星路径加速内容访问（例如，图 5 中的 2）。卫星在用户和相应的云缓存服务器之间转发流量，而无需在卫星上缓存副本。

第三，当最近的可用云仍然太远时，请求也可以 直接分配给卫星缓存（例如，图 5 中的 3）。

上述三种分配策略在实践中会导致不同的存储和带宽成本，因为空间资源可能比地面云服务器中的资源更稀缺。特别是，第一种形式仅消耗地面存储和带宽，第二种形式使用地面存储和卫星带宽，而最后一种形式消耗太空中更昂贵的存储和带宽。

B. STAR FRONT Workflow

To utilize the low-latency potential of emerging megaconstellations while not incurring high operating overhead for content providers, the STAR FRONT controller judiciously calculates the placement and assignment decision in a cost-effective manner, i.e., deciding (1) how to select a set of cache servers from all available clouds and satellites to build the content distribution network? and (2) how to assign requests from different geo-distributed regions to a proper cache server while not exceeding the cost budget of content providers? To deal with the high dynamicity of satellite constellation, the STAR FRONT controller exploits the periodicity and predictability of satellite movements to perform the following operations to accomplish the goal of cost-effective distribution.

为了利用新兴巨型星座的低延迟潜力，同时不给内容提供商带来高昂的运营开销，STAR FRONT 控制器以 具有成本效益的方式明智地计算放置和分配决策 ，即决定

(1) 如何从所有可用云和卫星中选择一组缓存服务器来构建内容分发网络？

(2) 如何将来自不同地理分布区域的请求分配给适当的缓存服务器，同时不超过内容提供商的成本预算？

为了应对卫星星座的高度动态性，STAR FRONT 控制器利用卫星运动的周期性和可预测性来执行以下操作，以实现具有成本效益的分发目标。

(1) STAR FRONT divides time into a sequence of successive operation periods. At the beginning of each period, STAR FRONT constructs a dynamic satellite-cloud topology to model the time-varying cache availability, network performance, and cost of distributing contents to cloud and satellite caches. The model is built based on cloud and user distributions, constellation architecture and pricing policies from cloud and satellite providers.

(2) Once the satellite-cloud topology is obtained, STAR FRONT invokes the judicious replica placement and request assignment algorithm. Following the decision, STAR FRONT pushes and places contents on all selected cache servers, and then configures the region ↔ server assignment.

(3) During each period, STAR FRONT redirects user requests to a proper cache server, based on the region ↔ server assignment. Intuitively, Figure 6 summarizes the design space of request assignment in the STAR FRONT framework. STAR FRONT may: (a) assign requests to a nearby cloud cache server via terrestrial networks (e.g., Figure 6a) for users in developed areas (e.g., metropolis) where low-latency cloud platforms are well-provisioned; (b) issue requests to a cloud server via a single-hop satellite relay or a multi-hop satellite route (e.g., Figure 6b and Figure 6c); or (c) directly issue requests to an available satellite cache server (e.g., Figure 6d and 6e), especially for those users in remote or rural areas where terrestrial networks and clouds are quite limited.

(1) STAR FRONT 将时间划分为一系列连续的操作周期。在每个周期的开始，STAR FRONT 构建一个动态卫星-云拓扑，以模拟随时间变化的缓存可用性、网络性能以及将内容分发到云和卫星缓存的成本。该模型基于云和用户分布、星座架构以及云和卫星提供商的定价策略构建。

(2) 一旦获得卫星-云拓扑，STAR FRONT 就会调用明智的副本放置和请求分配算法。根据该决策，STAR FRONT 将内容推送并放置在所有选定的缓存服务器上，然后配置区域 ↔ 服务器分配。

(3) 在每个周期内，STAR FRONT 根据区域 ↔ 服务器分配将用户请求重定向到适当的缓存服务器。直观地，图 6 总结了 STAR FRONT 框架中请求分配的设计空间。

STAR FRONT 可以：

(a) 通过地面网络 将请求分配给附近的云缓存服务器（例如，图 6a），适用于低延迟云平台配置良好的发达地区（例如，大都市）中的用户；

(b) 通过 单跳卫星中继或多跳卫星 路由将请求发送到云服务器（例如，图 6b 和图 6c）；

(c) 直接将请求发送到可用的 卫星缓存服务器 （例如，图 6d 和 6e），特别是对于地面网络和云非常有限的偏远或农村地区中的用户。