## 7 Numerical Results  
In this section, we numerically evaluate how a strategy to jointly place processing and route information within a satellite constellation dedicated to EO can lower the energy consumption on GS due to data processing. The proposed performance investigation is related to the evaluation of the ground station energy saving, defined as the saved energy consumption percentage of the proposed solution with respect to the case in which all of the tasks are processed in the GS. The amount of services processed in orbit depends on the resource allocation and processing placement strategy applied. In particular, we first evaluate the energy saving obtained by means of an optimal strategy, and we compare it to the one obtained by leveraging the GESEH algorithm. In fact, it would be impractical to solve the optimization problem in a real orbital scenario, thus, we first validate the GESEH algorithm with respect to the optimal solution in a simpler, but not trivial, scenario, in such a way that we can then leverage the heuristic to evaluate the effectiveness of the proposed solution in a real orbital case. In this latter case study, the performance is compared to two benchmarks, the first stipulating that processing always happens on ground (Always Ground solution, AG), the second stipulating that processing can happen either on the source satellite or on ground (Always First or Ground solution, FoG) [18]. In particular, in the FoG solution, all satellites have processing capacity on board, but they can leverage it only to process images they acquired when flying over a region of interest. In other words, satellites cannot offload processing of images they acquired by another satellite, and if they do not have enough resources to process data, they shall offload it to the GS. In our solution, instead, service processing can be carried out by any satellite of the constellation, even different from the one originating it, or by a GS (i.e., if a satellite does not have enough resources to accomplish the task processing, it can offload it to another satellite with more resources, or, in the worst case, to the GS). The following parameters will be the same for all the analysis. The time-cycle duration will be set to \(\tau=10\) min, as a compromise value between the granularity of the dynamic topology representation and the complexity of running the algorithm. In concordance with what happens on Sentinel-2, we consider all services to have a pre-processing size [1] equal to  
\[f_{0}^{h}=\bar{f_{0}}=160\;\mathrm{Mb},\;\forall h\in[0,\ldots,N_{T}-1] \tag{33}\]  
Although the proposed model for EO services allows tasks to have different post-processing sizes--and a parametric analysis has already been carried out in [29]--in this paper we assume a uniform post-processing size for all tasks, set to:  
\[f_{1}^{h}=\bar{f_{1}}=16\mathrm{Mb},\;\forall h\in[0,\ldots,N_{T}-1] \tag{34}\]  
The number of CPU cycles to process a service will be considered to be \(n_{cyc}=737.5\) cycles/bit, regardless of the service and processing node [18]. On GSs, since we assume that data centers have enough processing capacity to process EO data, we will consider unlimited processing capacity, thanks to an unlimited number of CPUs, each having a clock frequency \(v_{GS}=4.5\) GHz (a common value for CPUs operating in ground computers), while we first assume that only one CPU is available on board satellites (due to limitations on available space on-board), each with a clock frequency:  
\[v_{Sat}=\alpha\cdot\hat{v}_{Sat} \tag{35}\]  
where:  
\[\hat{v}_{Sat}=\bar{f_{0}}\cdot n_{cyc}/\tau \tag{36}\]  
stands for the frequency needed on board of satellites to process a task during a time cycle. Thus, by setting \(\alpha\), we set the maximum number of services which can be completely processed by a satellite in a time cycle.