As mentioned in subsections 6.3.3 and 7.2.2, different options for selecting a list of routes exist for CGR and were implemented in the course of the presented evaluation. A set of options is, e.g., provided and discussed by Fraire et al. in [Fra+18].
For use in the simulation study, two basic approaches were considered:
1. Yen’s algorithm, a well-known graph algorithm allowing to derive a set of K shortest paths for a given graph, and
2. A series of Dijkstra searches, whereas before each search a specific limiting
contactis excluded.
For the latter, two variants were implemented, one setting the limiting contact to the earliest-ending contact, and another one using the contact with the smallest volume (the earliest-depleted contact) from the previous route. The maximum number of routes K determined by Yen’s algorithm was assumed as a configurable parameter and is always provided in the following plots and discussions.
Two scenarios were evaluated with two different traffic configurations. Both scenar- ios were randomly generated Ring Road networks consisting of the same number of satellites and ground stations. The satellites were selected randomly from the set of CubeSats currently in orbit, and the ground stations were placed randomly on the surface area of the Earth. The scenario duration was set to three days. The first scenario (3g3s) uses three ground stations and three satellites, whereas the second scenario (5g5s) consists of five ground stations and five satellites. The contact plan for scenario 3g3s contains 164 unidirectional contacts, the one for scenario 5g5s 722 unidirectional contacts.
The traffic load configurations were determined as described in subsection 7.7.1, with one minor difference: For low load, the bundle size was set to 2 MiB as in the case of the high load configuration. Ten simulation runs were executed for every algorithm in any scenario. No predictions were performed, i.e., all algorithms were provided with accurate contact plans.
The delivery probabilities measured for the comparison are plotted in figure B.8. By inspecting the figure, it becomes clear that a particularly large setting is needed for the parameter K of Yen’s algorithm to achieve a high delivery probability, especially in the larger scenario under high load. This can be explained by the huge number of alternative routes that can be calculated because of the number of contacts and the property of Ring Road networks to offer many alternative paths. In the
5g5sscenario, even a K value of 20000 is not sufficient to deliver all bundles. The
approaches using a limiting contact achieve a delivery probability of 100 % in all scenarios. In their case, no limit to the number of alternative routes is applied as the search terminates much faster.
Figure B.8: Route determination test: Bundle delivery probability
The bundle delivery delays shown in figure B.9 are comparable for all CGR instances, as long as the K parameter for Yen’s algorithm has been set to a sufficiently high value. If this is not the case, only the K fastest routes are provided and, when these are fully booked, scheduling fails, i.e., bundles are dropped. Lower delays reported in some cases are explained by dropped bundles not being part of that statistic.
Figure B.9: Route determination test: Average bundle delivery delay
The most important statistic in this comparison, however, is depicted in figure B.10. The run-time, i.e., the duration of a simulator run, is shown with a logarithmic scale. With an increasing parameter K, the run-time massively increases, preventing any meaningful application of the CGR implementation with Yen’s algorithm to larger scenarios.
The documented issues might be implementation-specific. Though, due to manual tests generating sample routes in scenario 3g3s using a preview version (preview3) of ION 4.0.0, which also uses Yen’s algorithm for CGR, it is suspected that this is a general problem with Yen’s algorithm, possibly bound to the class of scenario. The generation of sample routes resulted in run-times of several seconds for the ION CGR implementation, whereas a complete simulation run performing over 150 bundle transmissions using CGR-limit-ending in the Python-based aiodtnsim implementation terminated in less than one second (scenario 3g3s+high).
Figure B.10: Route determination test: Average simulation run-time (logarithmic scale)
Due to the extremely increased run-times and non-noticeable benefits regarding delivery probability and delays in the analyzed test scenarios, the limiting con- tact approach was used in the evaluation, excluding the earliest-ending contact. Compared to excluding the earliest-depleted contact, this configuration showed reduced delays in analyzed example cases.
C Further Performance Results
In this appendix, additional plots of performance results are provided. These plots are not essential for deriving the findings and conclusions of this thesis, but are included as they might be of interest for some readers. The plots show arithmetic means and 95 % intervals if not specified otherwise.C.1 Metric Distribution Performance
Figure C.1 depicts the node buffer utilization by distributed metric bundles. The overall impact of metric distribution is discussed in section 7.6.
Figure C.1: /E3/: Average buffer utilization by metric bundles (logarithmic scale, with 80 % intervals)