In-Orbit Processing or Not? Sunlight-Aware Task Scheduling for Energy-Efficient Space Edge Computing Networks

On-board hardware evolution in aerospace industry. On-board network and computation capabilities have increased significantly over the past decade. The high-speed inter-satellite and ground-satellite links (i.e., ISLs and GSLs) have been successfully deployed on satellite platforms, which can offer Gbps-level data transmission for satellite communication [13, 14] and facilitate the inter-networking of a large number of satellites. Besides, on-board processing capability has also been promoted via low-power commercial off-the-shelf (COTS) hardware accelerators, e.g., graphics processing unit (GPU) [8], vision processing unit (VPU) [15], and field programmable gate array (FPGA) [16]. In 2020, European Space Agency (ESA) launched the $\Phi$-sat-1 sensing satellite equipped with Intel Movidius Myriad 2 to verify the on-board performance of deep neural network (DNN) and achieved great success [17].

Space edge computing (SEC) enables in-orbit intelligence. With such space hardware evolution above, recently we have witnessed a new intelligent computation paradigm: space edge computing (SEC). SEC exploits edge-like computing capabilities on satellites and within satellite networks to process data in orbits. SEC can be used in many innovative space applications such as autonomous remote decisions, in-orbit detection for disaster discovery, climate monitoring and maritime rescue [18, 19, 20]. SEC enables faster data processing, reduced latency, and improved efficiency by handling data in orbit rather than sending all data back to the ground.

Satellite power supplement. Satellites orbit around the earth, and during a portion of their orbit, they enter the earth’s shadow, causing an eclipse. Fig. 1 plots a typical architecture of existing SEC power systems (SPS). During the sunlight phase, solar panels generate energy from the received photons, and SPS distributes power to other subsystems of the satellite. On-board rechargeable batteries store excess power generated by solar panels when the satellite is in sunlight, and the stored energy is used to power the satellite during eclipse periods. Typically, among all subsystems the communication and computation modules can contribute copious energy consumption [7].

Depth of discharge (DoD) and battery lifetime. The lifetime of a battery (as well as the satellite itself) is tightly affected by its power usage during the charging-discharging cycles of the battery. In particular, DoD characterizes the percentage of discharged energy relative to the maximum capacity. DoD is equal to 0 if the battery is full and 100% if the battery is empty. As the battery is used, the maximum capacity of the battery will gradually decay. Typically, when the maximum battery capacity falls below 80% of its initial volume, the battery should be retired, which is defined as its lifetime [21, 22]. Previous works [23, 24] have uncovered that if we regularly discharge a battery at a higher DoD, its lifetime will be shorter (e.g., about 20% DoD increase can reduce the lifetime by half). Fig. 2 shows how DoD affects the total number of available charging-discharging cycles and the lifetime of two kinds of Lithium batteries. Considering that battery usage can jointly affect task performance and satellite lifespan, optimizing the battery energy consumption and accomplishing energy-efficient in-orbit task processing is important for futuristic SEC networks.

Architecture. Fig. 5 shows the system overview of Phoenix, which combines: (i) a swarm of computational space edges constructing an SEC network, and (ii) terrestrial infrastructures such as geo-distributed ground stations and a mission control center. Each satellite is equipped with high-speed ISLs and GSLs for inter-satellite and ground-satellite communication. In addition, an on-board intelligent processor is deployed on each satellite for in-orbit computing. Based on this baseline SEC architecture, Phoenix accomplishes energy-efficient SEC task scheduling by incorporating two new components as follows.

• •

  Centralized mission center controller. The controller is a centralized coordinator, which consists of three modules: task publisher, sunlight predictor and orbit assignment manager. The task publisher distributes the tasks to satellites. The sunlight predictor predicts the sunlight states of satellites based on their trajectories and distributes the sunlight information to satellites for offloading decisions. The orbit assignment manager pre-allocates alternative orbit sets for satellites to avoid resource competition between orbits.

• •

  Distributed on-board task manager. The manager on each satellite consists of two modules: local processing manager and offloading manager. The offloading manager decides where to process the task based on the pre-allocated orbit set. The local processing manager arranges the task execution time if a task is decided to be processed locally.

Workflow. SEC tasks are scheduled by the following steps:

• •

  Task publication and orbit assignment. The mission center receives tasks from customers, such as requirements of using SEC for disaster discovery, climate monitoring, maritime search and rescue. The common feature of these tasks is that they all require a constellation of satellites persistently capture information (e.g., high-resolution images) of a certain region of interest (RoI). Then, the mission center predicts the sunlight states of satellites and publishes the RoI along with sunlight information to all satellites. Based on the sunlight and task information, the mission center pre-assigns an orbit subset for each orbit and distributes the assignment decision.

• •

  Task offloading. When a satellite flys over RoI, it captures images and selects offloading destination for each task, either a ground station or a satellite (including itself, i.e., local processing). The satellite first checks whether the task can be offloaded to a ground station before deadline. If not, it tries to arrange the task locally and judges whether it can finish the task under sunlight phase as well as before deadline. If both of the above conditions can not be satisfied, it offloads the task to other satellite.

• •

  Processing time arrangement. The final destination satellite arranges the task processing time (the ground station can process the task immediately after offloading) and sends the result back to the mission center when the task is finished.

SEC network topology. Assume that time is slotted with each timeslot $\Delta T$ and the time set is denoted as $\mathcal{T}=\{1,2,\dots,T_{max}\}$. Denote $G_{t}=(V,E_{t})$ as the satellite network topology. $V$ is the node set and $E_{t}$ is the edge set at timeslot $t$. There are two types of nodes, i.e., satellites and ground stations. Assume that the total number of orbits is $M$ and the satellite set in orbit $i$ can be denoted as $ORB_{i}$. Thus, the satellite of the whole constellation can be represented by $SAT=\cup_{1\leq i\leq M}ORB_{i}$. The number of ground stations is $N$ and the ground station set is denoted as $GS=\{g_{1},g_{2},\dots,g_{N}\}$. Then the node set can be described by $V=SAT\cup GS$. As satellites orbit around the earth, the visibility between nodes changes over time. Let binary variable $Vis_{i,j}^{t}$ denote the visibility between node $i$ and node $j$. If $i$ and $j$ are visible at time $t$, then $Vis_{i,j}^{t}=1$ and they can establish a link $(i,j)$. Therefore, we can check whether a satellite $s$ can connect to any ground station at time $t$ by a binary value $l_{s,t}$:

Denote $\lambda$ as the number of ISLs in each satellite. Typically, there are four ISLs and one GSL for each satellite [26]. The link capacity of $(i,j)$ is denoted as $Cap(i,j)$ and we set $Cap(i,i)=\infty$, meaning that if a task is processed locally, the transmission can be finished in situ instantly.

Task scheduling. Assume that the task set is $TASK$ and a task $k$ can be represented by a tuple $(src_{k},z_{k},T_{arv}^{k},T_{cp}^{k},T_{ddl}^{k})$, indicating the source satellite creating the task, the task size, the task arrival time, the computing time required to process the task for satellite, and the deadline respectively. A task can be offloaded to ground stations, processed locally or offloaded to another satellite. Let $dst_{k}$ denote the node where task $k$ is processed. If $dst_{k}\in GS$, task $k$ is downloaded by ground stations directly; if $dst_{k}=src_{k}$, task $k$ is processed locally; otherwise, task $k$ is offloaded to another satellite. Then, the tasks that select node $s$ as the processing destination can be represented by $\mathcal{K}_{s}=\{k|dst_{k}=s,k\in TASK\}$. Let $T_{of}^{k}$ be the point of time when task $k$ finishes offloading. The task offloading time is decided by the bottleneck of path from $src_{k}$ to $dst_{k}$. Given a routing path $R(i,j,t)$ from node $i$ to node $j$ at timeslot $t$, the offloading path can be denoted as $R(src_{k},dst_{k},t)$. We use a binary variable $r_{i,j}^{k,t}$ to indicate whether the offloading flow of $k$ goes through link $(i,j)$ at $t$:

Assume that all flows on the same link share the link capacity fairly. Then, the bandwidth that each flow can obtain on link $(i,j)$ at timeslot $t$ is $Cap(i,j)/\sum_{k\in TASK}r_{i,j}^{k,t}$. Denote $sz_{k,t}$ as the data size of task $k$ transmitted at timeslot $t$. The data size that can be transmitted in each timeslot is limited by the minimum bandwidth on the offloading path:

When the amount of sent data reaches the task size, the offloading is finished and the time to finish offloading is:

After the task is offloaded, the receiver should decide when to process the task. Let $T_{bcp}^{k}$ denote the time to begin processing and the time to complete processing can be represented by $T_{bcp}^{k}+T_{cp}^{k}-1$. We use a binary variable $x_{k,t}$ to indicate whether the task $k$ is being processed at time $t$:

Thus, we denote the task processing matrix as $\mathcal{X}=\{x_{k,t}|k\in TASK,t\in\mathcal{T}\}$. For any satellite $s$, the number of tasks under processing at timeslot $t$ can be calculated by $\sum_{k\in\mathcal{K}_{s}}x_{k,t}$.

Energy Consumption. As mentioned in § II-B, the electronic components in satellites consist of solar panels, communication terminals, processing units, battery and other basic modules (e.g., sensors). For satellite $s$, we denote the power generated by its solar panels under sunlight phase as $P_{solar}^{s}$. As satellites enter eclipse phase and sunlight phase alternately, we use binary variable $sun_{s,t}$ to indicate whether satellite $s$ is illuminated at time $t$. Thus, the power generated by solar panels at timeslot $t$ is $sun_{s,t}\cdot P_{solar}^{s}$. We use $P_{ISL}^{s}$ and $P_{GSL}^{s}$ to describe the transmit power of ISL and GSL respectively. Therefore, the power consumed by ISL and GSL at timeslot $t$ are $\lambda\cdot P_{ISL}^{s}$ and $l_{s,t}\cdot P_{GSL}^{s}$ respectively. Denote the power of processing units as $P_{cp}^{s}$. Thus, the power consumed by processing units at timeslot $t$ is $P_{cp}^{s}\cdot\sum_{k\in\mathcal{K}}x_{k,t}$. The power consumed by other basic modules is denoted as $P_{basic}^{s}$. Let $B_{vol}^{s}$ be the volume of battery and $B_{s,t}$ be the rest battery energy of $s$ at time $t$, which is decided by $\mathcal{K}_{s}$ and $\mathcal{X}$. In the beginning, the battery is full, i.e., $B_{s,0}=B_{vol}^{s}$. As time goes by, the rest battery energy changes according to the energy produced by solar panels and the energy consumed by electronic devices:

Therefore, the DoD of satellite $s$ at timeslot $t$ can be represented by $1-B_{s,t}/B_{vol}^{s}$.

SEC Battery Energy Optimization (SBEO) problem formulation. Given the following inputs: (i) time set $\mathcal{T}$ and timeslot duration $\Delta T$; (ii) node set $V$ and visibility $Vis_{i,j}^{t}$ between nodes; (iii) link capacity $Cap(i,j)$; (iv) task set $TASK$ and routes between nodes $R(i,j,t)$; (v) power of electronic devices $P_{solar}^{s}$, $P_{basic}^{s}$, $P_{ISL}^{s}$, $P_{GSL}^{s}$ and $P_{cp}^{s}$; (vi) battery volume $B_{vol}^{s}$ and sunlight indicator $sun_{s,t}$, we aim to provide the processing task set $\mathcal{K}_{s}$ for all satellites and the processing matrix $\mathcal{X}$ such that the maximum DoD among all satellites is minimized, prolonging the lifetime of satellites as illustrated in § II-B:

Constraints:

(i) A satellite can only process a task at each timeslot:

(ii) Task processing should be scheduled after offloading finish:

(iii) Task processing should be completed before deadline:

Complexity analysis. To analyze the complexity, we simplify the SBEO problem to an easier case where ground stations are not considered and there is no transmission cost. Then, a task $k$ can be divided into $T_{cp}^{k}$ slots and a satellite $s$ can be divided into $T_{max}$ slots. There are two types of satellite slots according to the sunlight state, i.e., sunlight slots and eclipse slots. If a task slot is assigned to a eclipse slot of a satellite, the cost is 1 while there is no cost when assigned to a sunlight slot. Then, the problem can be transformed into a generalized assignment problem, which assigns the task slots to satellite slots, aiming to minimize the cost. The generalized assignment problem has been proven to be NP-hard [27]. Thus, the simplistic problem as well as the SBEO problem are NP-hard.

Orbit assignment in mission center. The key ideas are summarized as follows: (i) To fairly assign the orbit subsets, the energy capability of each subset should match the task amount. Therefore, we use sunlight duration in a period to represent the energy capability and select the orbit subsets which satisfy the following properties: the subsets for orbits generating tasks are disjoint and the energy capability proportion of each subset is close to the task proportion. (ii) To reduce the complexity of searching suitable subsets, we set up a target capability for each subset according to task amount and transfer the problem to a knapsack problem, which finds an orbit subset that minimizes the gap to target capability.

Offloading selection in each satellite. Based on the alternative subset assigned by Algorithm 1, the orbit-based offloading algorithm adopts the following ideas: (i) As the connection of GSLs can be predicted, we first check whether tasks can be offloaded to ground stations before deadline to save on-board computation resources. (ii) For satellite offloading, we maintain a task counter for orbits in the alternative subset and try to keep the task amount conforming to their energy capability.

Processing arrangement in each satellite. To arrange the processing time, we apply the deadline first scheme and search for the delay to exploit as less eclipse timeslots. The details of processing arrangement algorithm are shown in Algorithm 3. First, we sort the tasks according to their deadlines in ascending order. Then, we calculate the latest time of task $k$ to start processing (denoted as $T_{latest}^{k}$), which guarantees the deadline requirement (line 3-3). Next, we calculate the earliest time of task $k$ to start processing (denoted as $T_{earliest}^{k}$). The indicator $flag\_sun$ is initialized to 1 and the earliest time of the first task is initialized to current time $t$. Then, we search for the next sunlit time $T_{sunlit}^{k}$ (line 3). If the next sunlit time is before the latest task processing time, we arrange the task to be processed from $T_{sunlit}^{k}$ to save battery energy (line 3). Otherwise, we arrange the task to be processed from $T_{latest}^{k}$ to guarantee the deadline requirement (line 3) and set $flag\_sun$ to 0 (line 3). At the end of each loop, we update the earliest processing time of next task (line 3).

Prototype implementation. We build a data-driven hardware-in-the-loop SEC testbed based on StarryNet [28], a recent container-based satellite network emulator. The SEC environment is deployed on a Dell Precision 7920 Tower Workstation connected with a Jetson AGX Orin Developer Kit as shown in Fig. 6. The Developer Kit works as an SEC node, running machine learning models to evaluate the task completion time and energy consumption. Based on the +Grid [26] structure and the trajectory of the satellite simulated by the Developer Kit, it establishes virtual links with its adjacent satellites and ground facilities dynamically.

LEO constellation settings. We conduct extensive simulation driven by real-world information, including two kinds of LEO constellations: inclined orbit constellation (Starlink [29]) and polar constellation (OneWeb [30]). Following [12], we use the ground station locations collected by SatNOGS [31]. For computation, we adjust the power level of Jetson AGX Orin Developer Kit to 30W/50W/60W, providing different computation capabilities. Based on the existing hardwares [32, 33], we set the power of GSL/ISL to 16W/10W respectively. Following [7], we set the basic power to 4W. And we set the power generated by solar panels to 120W and the battery volume to 60Wh, which can offer sufficient energy. For transmission, we set the capacity of GSL/ISL to 100Mbps/1Gbps respectively.

SEC tasks and datasets. We select ship detection [1, 19] and wildfire segmentation [34] as the SEC tasks. For ship detection, we apply YOLO [35] to dataset [36] and select Atlantic Ocean as the RoI. Satellites continuously capture images every second, with the resolution of $10K\times 10K$ pixels [8]. Each image is expected to be processed within 5 minutes [37]. Based on our measurement, the processing time of an image for ship detection is 10s/5s/3s under 30W/50W/60W respectively. For wildfire segmentation, we apply U-Net [38] to dataset [39] and select Amazon Rainforest as the RoI. The imaging interval is set to 5 seconds and the processing time of an image is 120s/67s/51s under 30W/50W/60W respectively. Other parameters are the same as ship detection task.

Comparison objects and metrics. We implement three state-of-the-art offloading schemes for comparison: (i) OEC [7], which processes the tasks with an intra-orbit pipeline; (ii) MHSPO [9], an energy-efficient satellite peer offloading scheme, and (iii) L2D2 [12], which offloads tasks to geo-distributed ground stations. We regard L2D2 as the baseline because it doesn’t consume any computation energy, and thus has the lowest energy consumption. We use DoD, battery lifetime and task finish time as metrics to present the effectiveness of Phoenix.