CCRSat: A Collaborative Computation Reuse Framework for Satellite Edge Computing Networks

Computation reuse strategies are widely implemented for various computation-intensive processes [21, 8]. For instance, the authors in [10, 9] use computation reuse techniques to mitigate redundant computations in mobile applications and local device caches in nearby servers. Bellal et al. introduces a parsing model that integrates computation reuse with task offloading [22]. Drolia et al. proposed a system that uses a caching model to adaptively balance the load between the edge and the cloud by leveraging the spatiotemporal locality of requests, offline analysis of applications, and online estimation of network conditions [23]. Meng et al. utilized the similarity of background environment (BE) frames to reduce the bandwidth required for prefetching BE frames from the server by caching and reusing similar frames [24]. Mastorakis et al. and Al et al. leveraged computation reuse within NDNs, devising an information center network framework and a Reservoir network framework to enhance edge reuse, respectively [11, 12]. Existing work mainly focuses on computation reuse at the edge nodes, which are mainly deployed on resource-abundant devices like multi-access edge computing (MEC) servers at the ground. It is essential to design a computation reuse framework applicable to resource-constraint satellite networks.

Satellite communication is expected to provide global coverage to the remote computing services. Transmitting various data via satellites facilitates the sharing of computing resources across diverse geographic areas and the provision of efficient computing services in remote or rural areas without sufficient terrestrial network infrastructure [25, 26]. Tang et al. proposed a caching strategy between satellites and the ground stations, which utilizes a ridge regression-based regional feature prediction model to divide the LEO satellite coverage area into multiple cooperative areas. A game theory-based cooperative caching algorithm is employed to achieve distributed caching decisions [27]. Chen et al. proposed a content caching and content distribution method for satellite content delivery networks (CDNs) to solve the problem of rationally deploying CDNs in highly dynamic satellite environments [28]. Hao et al. proposed a regional cooperative caching and distribution strategy to solve the problem of limited satellite resources and the need for a caching strategy to achieve efficient content delivery with less cache redundancy, which divides the network topology into multiple areas and utilizes similar areas to remove redundant content [29]. Although the previous studies concentrate on satellite-ground and satellite-satellite caching strategies to mitigate communication delays, it is significant to integrate computation reuse with data caching for satellite on-board data processing. In this paper, we design a computation reuse framework aiming at saving computation resource usage and data processing time for both individual satellite computing and inter-satellite computing scenarios.

In summary, the application of computation reuse techniques to collaborative satellite data processing remains a largely unexplored research area. Investigating this domain can further enhance satellite resource utilization, accelerate data processing speeds, and improve the overall quality of satellite services.

In this paper, we assume a satellite edge computing network composed of multiple orbits as shown in Figure 1. The network consists of $N_{o}$ satellite orbits, each orbit containing $N_{s}$ satellites, represented as $\mathcal{S}=\{S_{1},...,S_{N_{s}}\}$. Satellites in different orbits are identified by superscripts, i.e., the $n^{th}$ satellite on the $x^{th}$ layer is $S_{n}^{x}$. Satellites move in the specified direction, with overlapping coverage areas existing between satellites in adjacent orbits as well as those in the same orbit. Additionally, each satellite is equipped with data caching and in-orbit data processing capabilities.

For each satellite, a satellite computation reuse table (SCRT) is used to cache reusable records. The SCRT for satellite $S_{n}^{x}$ can be denoted as $SCRT_{S_{n}^{x}}$. We assume that each satellite has the same cache size $C^{\textit{stg}}$. For data on the processing of the arriving tasks $\Gamma^{s}$ collected by satellite $S_{n}^{x}$, we partition it into subtasks $t\in\Gamma^{s}$. We assume that the satellite server receives and executes the tasks following Little’s Law $M$/$M$/1 queuing system. Then, the reuse record for subtask $t$ can be defined as:

where $D_{t}$ is defined as the input data for executing the target task, $P_{t}$ is the type of target task to be processed, $R_{t}$ is the output data after successfully executing the task with the given input, and $N_{t}$ is the number of times the record has been reused.

During network operation, each satellite collects the data processing tasks corresponding to their respective assigned areas based on the real-world scenario. After receiving the task, the satellite starts in-orbit processing. To minimize resource waste resulting from repetitive computations on highly similar data, each satellite can perform satellite local computation reuse by utilizing the similarity of previously processed data. Furthermore, satellite collaborative computation reuse is employed to further enhance the quality of task processing.

Due to the restrictions imposed by communication distances, each satellite can only transmit tasks to its adjacent satellites through ISL [30]. Assuming the unobstructed line of sight by the Earth, the maximum data rate between satellite $S_{k}$ and $S_{i}$ is:

where $B_{s}$ is the channel bandwidth, ${SNR}(S_{k},S_{i})$ is the signal to noise ratio, which can be calculated by the following equation [31]:

where $Pow_{t}$ is the power of transmitter, $G_{S_{k}}(S_{i})$ is the average antenna gain of satellite $S_{k}$ towards satellite $S_{i}$ and $G_{S_{i}}(S_{k})$ is the average antenna gain of satellite $S_{i}$ towards satellite $S_{k}$. $L(S_{k},S_{i})$ is the free space path loss calculated by:

where $f_{c}$ is the carrier frequency, $dist(S_{k},S_{i})$ is the Euclidean distance between satellite $S_{k}$ and $S_{i}$, and $c$ is the speed of the light. $N_{0}$ is the noise power spectral density calculated by:

where $k_{B}$ is the Boltzmann constant, $T$ is the receiver noise temperature.

Satellite communication consumption primarily stems from inter-satellite collaboration (the sharing of SCRT records among satellites). The size of shared records is primarily determined by their input data $D_{t}$ and output data $R_{t}$. When specific conditions are met, the data source satellite $S_{i}$ distributes high-value records to all satellites in its current collaboration area $\mathcal{S}_{co}=\{S_{1},...,S_{co}\}$. More details can be found in the descriptions of the proposed SCCR algorithm in Section IV.

Therefore, the total communication cost for satellite $S_{i}$ to complete the arriving task $\Gamma^{s}$ is:

where $\tau$ represents the amount of records shared per time.

When implementing computation reuse, the satellite first finds the nearest neighbor within the locality sensitive hashing (LSH) table. It then evaluates the similarity between the current task’s input and this neighbor to determine whether to reuse the processing results. We assume that the subtask operates under two schemes: execution from scratch on a satellite server, or computation reuse. Let $x_{t}$ represent a binary variable for computation reuse, where $x_{t}=0$ indicates processing the subtask from scratch, and $x_{t}=1$ denotes the use of computation reuse. The details of these two schemes are as follows:

• •

  Computation from scratch: this operation is defined as:

  $$\chi_{t}^{\text{compute}}=(1-x_{t})\cdot(W+\frac{F_{t}}{C^{\textit{comp}}})$$

  (6)

  where $W$ denotes the lookup cost (finding the nearest neighbor). When the input data $D_{t}$ of the current subtask locates its nearest neighbor in the LSH table and their similarity (structural or cosine similarity) exceeds a predefined threshold, $x_{t}=1$; otherwise, $x_{t}=0$. All subtasks except the first two undergo a lookup operation. Here, $F_{t}$ represents the computational resource required to execute subtask $t$, and $C^{\textit{comp}}$ is the satellite’s computational capability.

• •

  Computation with reuse: In this case, if the input data of the subtask is sufficiently similar to the input data of the cached record, the output data of the cached record can be reused, without the need to perform the computation. Instead, only a lookup operation is required as:

  $$\chi_{t}^{\textit{reuse}}=x_{t}\cdot W$$

  (7)

For a complete task $\Gamma^{s}$, the computation cost $\chi$ is calculated as follows:

The cost required to complete the entire task is defined as:

where $\alpha$ is a binary parameter for balancing communication consumption with computational consumption.

Based on the above derivation, our goal is to minimize the satellite’s task completion time. The optimization problem is defined as follows:

The above optimization objective must satisfy the following constraints: the size of the SCRT stored by each satellite should not exceed the size of its storage space $C^{\textit{stg}}$, the total number of tasks handled by each satellite should be less than its computational power $C^{\textit{comp}}$, and the total amount of recorded data transmitted by each satellite when it collaborates should not exceed its communication bandwidth $B_{s}$.

In this section, we present two algorithms based on CCRSat: the satellite local computation reuse algorithm (SLCR) and the satellite collaborative computation reuse algorithm (SCCR). The SLCR algorithm elaborates on the entire process of local computation reuse within a satellite, while the SCCR algorithm extends this concept by incorporating satellite collaboration to enhance computation reuse efficiency across the satellite network.

To measure the current reuse status of a satellite, we propose the Satellite Reuse Status (SRS) metric. A higher SRS value signifies greater benefit derived from the computation reuse mechanism. Specifically, the SRS is determined by two parameters: the satellite’s current reuse rate and CPU occupancy. Specifically, SRS is directly proportional to the reuse rate and inversely proportional to CPU occupancy. Conversely, high CPU occupancy reflects lower reuse gain, as it indicates reliance on pre-trained models for task processing, reducing the efficiency of computation reuse. When executing the SLCR algorithm locally, each satellite updates its SRS after each computation reuse operation. The SRS of satellite $S$ is defined as:

where $\text{rr}_{S}$ denotes the reuse rate of $S$, and ${C}_{S}$ denotes the CPU occupancy of $S$. $\beta$ is the weight parameters.

To assess whether a satellite has a favorable reuse status, we define the threshold $th_{co}$. When a satellite’s SRS drops below $th_{co}$, it indicates that its reuse status is critical, necessitating a request for cooperation from other satellites. Furthermore, it cannot act as a data source satellite ($S_{src}$) for collaborating with other satellites.

Figure 2 provides the overview of the collaborative computation reuse process among satellites. This figure shows an example of a satellite requesting cooperation and receiving assistance within the initial collaboration area in a 5$\times$5. The satellite herein is referred to as the requesting satellite ($S_{req}$). The whole process can be divided into four steps (See the arrows in Figure 2):

Step 1: When a satellite finds that its SRS falls below the threshold $th_{co}$, it initiates the collaborative computation reuse process to request support from other satellites within the initial collaboration area.

Step 2: $S_{req}$ retrieves the SRS values of all satellites within its initial collaboration area to identify the satellites with SRS values exceeding $th_{co}$ . If such a satellite is identified, the one with the highest SRS value is designated as the $S_{src}$ for the collaboration area. If no suitable satellite is found, the collaboration area will be expanded. The details of the collaboration area expansion methodology are discussed below:

The initial collaboration area is constructed by $S_{src}$ and its surrounding satellites. The expanded collaboration area is formed by including the surrounding satellites of all satellites within the initial area.

Step 3: $S_{src}$ broadcasts its top $\tau$ records with the highest reuse count throughout the collaboration area.

Step 4: Each satellite updates its SCRT based on the received records. If a satellite has already cached the records sent by $S_{src}$, no update is needed. When updating, the reuse count is reset to zero to avoid being influenced by the reuse count from $S_{src}$.

Algorithm 1 describes the details of our proposed SLCR algorithm. For the current sub-task $t$, the inputs are the original input data $D_{t}$ and $P_{t}$. This algorithm first pre-processes $D_{t}$ to obtain $PD_{t}$ (pre-processed input data), which involves resizing, spreading, normalization, and data type conversion for subsequent image processing and model input (line 1). Next, it determines SCRT based on $P_{t}$ and hash $PD_{t}$ into the corresponding bucket of the SCRT. Then it finds the nearest neighbors of $PD_{t}$ in the bucket (line 2). If no candidate can be found, this sub-task cannot be reused. In this case, we use $P_{t}$ to select the appropriate pre-trained model to process $PD_{t}$, and then form a new record in the SCRT based on $D_{t}$, $P_{t}$, $R_{t}$, and $N_{t}$ (initially set to 0) (lines 3-6).

On the other hand, if the nearest neighbor is found, the algorithm calculates the structural similarity (SSIM) between $PD_{t}$ and the selected neighbor. SSIM is a metric that quantifies the similarity between two images on a scale from -1 to 1. A value of 1 signifies identical images, 0 indicates no similarity, and negative values denote inverse correlation. The SSIM can be obtained by:

where $x$ and $y$ represent $PD_{t}$ and the selected nearest neighbor.

To enhance computation reuse rate, we set a threshold $th_{sim}$ to measure the similarity of the two inputs. Reuse occurs only when $ssim>th_{sim}$. At this point, the algorithm finds the nearest neighbor record and takes its output result as the reuse result $R_{t}$ for the current calculation, and then increments its reuse count $N_{t}$ by 1 (lines 7-11). If $ssim>th_{sim}$ is not satisfied, it processes $PD_{t}$ using the pre-trained model, forms a record, and updates it’s SCRT accordingly (lines 12-17).

The previous Algorithm 1 focuses on computation reuse within a single satellite. However, in a multi-satellite edge computing network, the data processed by these satellites often exhibit significant similarity. Based on this observation, we propose SCCR, an inter-satellite computation reuse algorithm, as outlined in Algorithm 2.

When the SRS of satellite (Equation 11) falls below $th_{co}$, it triggers SCCR algorithm and acts as the collaboration request satellite $S_{req}$. SCCR algorithm takes $S_{req}$ and the network scale $N$ as inputs. First, the location information of $S_{req}$ is retrieved. Based on the obtained information and $N$, the initial collaboration area CoArea is constructed using GetCoArea(), which consists of $S_{req}$ and its surrounding satellites. Within this area, the satellite with the highest SRS (i.e., the satellite that exhibits the best reuse status in the current collaboration area) is identified, referred to as $S_{max}$ (lines 1-3).

Next, SCCR algorithm assess whether $S_{max}$ qualifies as the data source satellite, $S_{src}$. If $S_{max}.SRS>th_{co}$, $S_{max}$ is selected as $S_{src}$ (lines 4-5), otherwise, the collaboration area is expanded to improve the likelihood of finding a suitable satellite. The expanded collaboration area can be constructed using GetExpandedCoArea(), which includes all satellites within the initial area, along with their surrounding satellites incorporated into the collaboration scope. Then a search is conducted within this expanded area to find a satellite that satisfies $S_{max}.SRS>th_{co}$. If such a satellite is found, it is designated as $S_{src}$ (lines 6-10). If no suitable satellite is found, the algorithm terminates, concluding the collaboration (lines 11-13). Finally, the algorithm outputs the data source satellite $S_{src}$ and the collaboration area $CoArea$ (lines 14-15). Based on $S_{src}$ and $CoArea$, the top $\tau$ reuse records of $S_{src}$ are shared across the entire collaboration area.

Regarding the complexity analysis of the proposed algorithm, assuming the network scale is $N\times N$, the time complexity for obtaining both the initial collaboration area and the expanded collaboration area is $O(N^{2})$, and the operation of finding the maximum SRS is linear with a complexity of $O(N^{2})$. Therefore, the overall time complexity is $O(N^{2})$. The space complexity is mainly determined by the size of the collaboration area CoArea, which in the worst case is $O(N^{2})$.

To evaluate the performance of our proposed CCRSat, we conduct the experiments within a simulated satellite computing environment. The experimental setup utilizes a PC with an Intel Core i7-10875H processor and 16GB of RAM, operating on Ubuntu 18.04. CCRSat utilizes the FALCONN library for LSH operations¹¹1https://github.com/FALCONN-LIB/FALCONN, specifically using hyperplane hashing. We adopt the UC Merced Land Use dataset [32], which is a well-established dataset that includs remote sensing image scenes for land-use classification. We further adjust this dataset to align with the application scenarios of CCRSat. Specifically, we assume that each satellite cluster processes the same total task volume (625 images with a total size of 12,817 MB), evenly distributed among satellites. The pre-trained model used in the experiments is GoogleNet22 [33]. The main experimental parameters are summarized in Table I.

We use the following criteria to evaluate the performance of CCRSat in the experiments:

1. 1.

   Task Completion Time is the total time taken for all satellites within the network to process the respective tasks and obtain results. This encompasses both task execution from scratch and instances where computation reuse (either local or collaborative) is applied;

2. 2.

   Reuse Rate is the average proportion of reused tasks relative to the total number of tasks when (collaborative) computation reuse is implemented within the satellite network;

3. 3.

   CPU Occupancy is the average CPU occupancy of satellites from task receipt to task completion;

4. 4.

   Reuse Accuracy is the ratio of correctly reused tasks to total reused tasks;

5. 5.

   Data Transfer Volume is the total data transfer volume of all satellites in the entire network.

To ensure reproducibility and generalizability, all experiments are conducted across satellite networks on two different scales. The experimental scenarios comprised the following categories:

• •

  w/o CR does not apply computation reuse, i.e., satellites process each task from scratch.

• •

  SRS Priority searches for satellites with optimal SRS values within the entire satellite network and collaborates, the broadcast area is also the entire satellite network.

• •

  SLCR only applies local computation reuse, i.e., each satellite reuses computations locally (Algorithm 1 in Section IV).

• •

  SCCR-INIT is an initial version of our proposed satellite collaborative computation reuse algorithm that does not include expansion of the collaboration area.

• •

  SCCR is our proposed satellite collaborative computation reuse algorithm (Algorithm 2 in Section IV).

Furthermore, a sensitivity analysis is performed on critical parameters that could have a substantial impact on the experimental results. These parameters include:

• •

  $\tau$ is the number of locality-sensitive hashing records that the source satellite broadcasts.

• •

  $th_{co}$ is a threshold used to determine the necessity of collaboration (See line 4 in Algorithm 2); if the value of SRS is below this threshold, it means that local reuse is suboptimal or remains suboptimal even after collaborative computation reuse.

Table II summarizes the reuse accuracy achieved by different scenarios. As observed in the table, the reuse accuracy of SCCR-INIT and SCCR is lower compared to SLCR, primarily due to the following two key factors:

• •

  Data correlation: In smaller collaboration areas, satellites process highly correlated data. As the area expands to encompass satellites from diverse orbits and tasks, the heterogeneity of data grows, resulting in a rise in reuse errors among satellites.

• •

  Accumulated errors: In small-scale satellite networks, errors tend to remain confined to specific areas. However, in large-scale networks, computation results propagate across multiple areas, leading to error amplification and decline in accuracy.

To mitigate the impact of local computation reuse errors on collaborative computation reuse accuracy, it is crucial to fine-tuning the parameter $th_{sim}$ (line 9 in Algorithm 1). Based on our extensive evaluation, we choose $th_{sim}=0.7$ because it allows SLCR to consistently achieve 100% reuse accuracy across all network scales at this threshold value. For this reason, despite the decline in reuse accuracy, the achieved reuse accuracy of SCCR remains satisfactory and surpasses that of SRS Priority, which searches for satellites with optimal SRS values across the network.

Figure 3 shows the task processing performance obtained by different scenarios in terms of task completion time, reuse rate, and CPU occupancy. The results indicate that the proposed SCCR consistently outperforms other scenarios across all criteria and network scales. In smaller networks, each satellite handles a larger workload, leading to higher data redundancy and reuse rates. The reuse rates for SLCR across three network sizes are $0.544$, $0.39$, and $0.27$, respectively. This indicates that smaller networks achieve higher reuse rates, reducing task completion time.

In 5$\times$5 satellite network, SCCR reduces task completion time by 62.1% compared to w/o CR (Figure 3) and decreases CPU utilization by 28.8%. Compared to SLCR, SCCR improves the reuse rate by 37.3% (Figure 3). This improvement stems from increased task similarity across satellites. SLCR relies solely on local computation history, limiting its ability to leverage similar tasks processed by neighboring satellites. By introducing collaboration and using SRS to assess reuse status, SCCR enables controlled cooperation. This allows satellites with higher reuse potential to share their results efficiently, improving overall reuse rates. Meanwhile, SCCR outperforms SCCR-INIT due to its gradual expansion of the collaboration area and on-demand collaboration requests. These strategies reduce redundant cooperation, preventing unnecessary delays and excessive data transfer. Naturally, expanding the collaboration area increases total data transmission. As summarized in Table III, SCCR-INIT results in 889.98 MB of data transfer, whereas SCCR increases this volume by 18.44%. In contrast, SRS Priority lacks a gradual expansion mechanism, leading source satellites to share records across the entire network. As a result, it performs poorly in terms of task completion time, CPU utilization, and data transfer, with its data transfer volume being 7.7 times higher than that of SCCR. In 7$\times$7 network, its task completion time exceeds w/o CR by 41.1%.

Regarding the results of CPU utilization across different network sizes, Figure 3 shows the trends consistent with task completion time. Since w/o CR does not leverage computation reuse, it has the highest CPU occupancy. SCCR achieves the best performance by maximizing reuse across the network, reducing overall computational workload. Through reuse, resource-intensive tasks are replaced by previously computed results, transforming execution from costly computation to efficient lookup and similarity assessment.

For larger-scale satellite networks, such as 7$\times$7 and 9$\times$9, the performance trends align with those observed in 5$\times$5 configuration, i.e., SCCR outperforms other comparative scenarios. Specifically, in 7$\times$7 network, SCCR increases data transfer by just 11.14 MB compared to SCCR-INIT, while reducing task completion time by 4.8%, highlighting its scalability.

To assess the impact of key parameters on the performance of SCCR, we conduct a sensitivity analysis focusing on two critical parameters $\tau$ and $th_{co}$ within 5$\times$5 network:

1. 1.

   Impact of $\tau$: It is a parameter that regulates the number of shared records. Figure 4 illustrates the impact of $\tau$ on task completion time. The task completion time of the SCCR algorithm decreases as $\tau$ increases in both the non-extended and extended collaboration area. It stabilizes when $\tau=11$. A larger $\tau$ allows high-value records to propagate and converge more quickly across the collaboration area. This improves the satellite reuse rate within the network. The results eventually stabilize due to the limited storage capacity of the satellites. Once the SCRT’s storage limit is reached, increasing $\tau$ further provides no additional benefits. Compared to SCCR-INIT, SCCR achieves better performance. The extended collaboration area enables collaboration when the surrounding satellites cannot support the current satellite.

2. 2.

   Impact of threshold $th_{co}$: As shown in Figure 5, SCCR-INIT and SCCR exhibit similar trends. Task completion time initially decreases as $th_{co}$ increases but then increases as $th_{co}$ continues to grow. Both algorithms achieve optimal performance at $th_{co}=0.5$. A very small $th_{co}$ restricts collaboration requests among satellites. Conversely, an excessively large $th_{co}$ leads to unnecessary cooperation. This imposes a heavy communication burden on satellites. When $th_{co}>0.8$, excessive collaboration overhead causes SCCR to perform worse than SLCR.

The proposed SCCR scenario effectively enhances task processing efficiency in satellite networks by leveraging satellite collaborative computation reuse. Compared to existing scenarios, it achieves significant reductions in task completion time and CPU utilization while maintaining a high reuse rate. The progressive expansion strategy minimizes redundant cooperation and balances performance with data transfer volume. Experimental results confirm that SCCR scales well with increasing network size, making it a promising solution for computation reuse in large-scale satellite networks.