Get 20M+ Full-Text Papers For Less Than $1.50/day. Start a 7-Day Trial for You or Your Team.

Learn More →

Towards a Computing Platform for the LEO Edge

Towards a Computing Platform for the LEO Edge Tobias Pfandzelter Jonathan Hasenburg David Bermbach TU Berlin & ECDF TU Berlin & ECDF TU Berlin & ECDF Mobile Cloud Computing Mobile Cloud Computing Mobile Cloud Computing Berlin, Germany Berlin, Germany Berlin, Germany [email protected] [email protected] [email protected] ABSTRACT satellite access networks can be a viable option for connecting all kinds of edge devices, even if terrestrial access is readily available. The new space race is heating up as private companies such as High-bandwidth, low-latency connections to client ground stations SpaceX and Amazon are building large satellite constellations in and via inter-satellite links (ISL) enable direct low-latency routing low-earth orbit (LEO) to provide global broadband internet access. between any two ground stations; thus, many argue that satellite As the number of subscribers connected to this access network Internet will see broad adoption in the future [5, 7, 12]. grows, it becomes necessary to investigate if and how edge com- Still, sending data from all end devices to a centralized location puting concepts can be applied to LEO satellite networks. for processing can put a substantial strain on the satellite network. In this paper, we discuss the unique characteristics of the LEO Especially for applications that transfer large amounts of data or edge and analyze the suitability of three organization paradigms for require low latency event processing, this can quickly become a applications considering developer requirements. We conclude that problem [25]. The same issue applies to terrestrial networks for the serverless approach is the most promising solution, opening up which edge computing, a computing paradigm that uses compute the field for future research. resources at the edge of the network in direct proximity to end users and devices, has been proposed as a promising solution [3, 9]. CCS CONCEPTS Applications can use these resources through edge platforms that • Computer systems organization→ Heterogeneous (hybrid) abstract from the geo-distributed server deployment and resource systems; Distributed architectures; • Networks→ Cloud comput- heterogeneity. These platforms are based on different organiza- ing. tion paradigms for applications (OPA), e.g., VMs, containers, or serverless functions. KEYWORDS Only recently, it has been proposed to also use computing re- satellite internet, LEO constellations, edge computing sources at the LEO edge to facilitate novel applications serving a global user base [6]. To realize this vision, however, edge platforms ACM Reference Format: Tobias Pfandzelter, Jonathan Hasenburg, and David Bermbach. 2021. To- must consider the unique characteristics of the LEO edge while still wards a Computing Platform for the LEO Edge. In 4th International Work- satisfying general requirements of application developers. As a first shop on Edge Systems, Analytics and Networking (EdgeSys ’21), April 26, step towards this goal, we must consider the core of such a platform, 2021, Online, United Kingdom. ACM, New York, NY, USA, 6 pages. https: the OPA, and analyze different options in light of the challenges at //doi.org/10.1145/3434770.3459736 the LEO edge. We therefore make the following contributions: (1) We discuss the unique characteristics of the LEO edge (Sec- 1 INTRODUCTION tion 3). Private Internet and aerospace companies are currently building (2) We derive requirements for building LEO edge applications the largest satellite constellations in existence: SpaceX, Amazon, from a developer perspective (Section 4). and Telesat – the so-called “New Space” companies – are deploy- (3) We analyze the suitability of three OPAs with regards to how ing or planning to launch tens of thousands of satellites into low they might satisfy developer requirements considering LEO Earth orbit (LEO) to provide global high-speed Internet access from edge characteristics (Section 5). space [28]. SpaceX’s Starlink constellation has already entered a public beta phase for subscribers in North America and the United 2 BACKGROUND & RELATED WORK Kingdom with more than 1,500 satellites in use [32]. In this section, we briefly introduce and describe the state of the art Beyond enabling Internet access for underserved regions such for large LEO satellite communication networks, edge computing, as rural areas, planes, or cargo and passenger ships, these new and OPAs. Furthermore, we also provide an overview of existing Permission to make digital or hard copies of all or part of this work for personal or LEO edge computing research. classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than the 2.1 LEO Communication Networks author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or Satellite-backed Internet access has been available for decades with republish, to post on servers or to redistribute to lists, requires prior specific permission and /or a fee. Request permissions from [email protected]. geostationary satellites at altitudes of 35,000km. The high altitude EdgeSys ’21, April 26, 2021, Online, United Kingdom combined with the requirement to orbit above the equator, however, © 2021 Copyright held by the owner/author(s). Publication rights licensed to ACM. result in high access latency for consumers which renders satellite ACM ISBN 978-1-4503-8291-5/21/04. . . $15.00 https://doi.org/10.1145/3434770.3459736 Internet inviable for many use cases [10, 17]. arXiv:2104.02396v1 [cs.DC] 6 Apr 2021 EdgeSys ’21, April 26, 2021, Online, United Kingdom Tobias Pfandzelter, Jonathan Hasenburg, and David Bermbach app app app app app app app runtime runtime runtime runtime runtime runtime OS OS OS OS OS VM VM H/W H/W H/W H/W (1) no sharing (2) virtual machines (3) containers (4) serverless Figure 2: OPAs by levels of abstraction [16]: while less ab- straction offers more freedom and flexibility, more abstrac- tion simplifies writing applications and shifts execution control to the platform which often increases efficiency. between ground stations and satellites. These factors mean that any change to the constellations requires a substantial lead time [5, 31]. Figure 1: Overview of a LEO satellite constellation compris- ing different shells. Shown here is the proposed first phase 2.2 Edge Computing of the Starlink deployment with five shells of 1,584 satellites The demand for processing data close to its origin led to an in- at 550km, 1,600 at 1110km, 400 at 1130km, 375 at 1275km, creased popularity of the edge computing paradigm in research and 450 at 1325km altitude [20]. and industry [3, 9]. The main idea behind edge computing is to embed computing resources into the edge of the network, i.e., close to clients. Compared to cloud computing, resources are thus avail- able with low latency and bandwidth costs. Preventing data from Now, a new generation of Internet satellites is being developed being transmitted to the cloud can also reduce privacy and security by companies such as SpaceX, Amazon, and Telesat. Thousands of risks [24]. these satellites are being deployed in large constellations at altitudes Typically, edge computing infrastructures comprise a multitude of below 600km, i.e., in the LEO. Thus, satellites continuously orbit of geo-distributed nodes with different compute, storage, and net- the globe and cover large ground distances in short periods of time. work capabilities. Using such a heterogeneous infrastructure is Each satellite is equipped with radio transmitters and receivers to significantly more difficult than the ease-of-adoption developers connect to ground stations. As ground station equipment is small are used to from the cloud: Applications need to consider geo- enough for use in family homes or airplanes, each satellite serves distribution, horizontal scalability, and network availability for fully many user terminals concurrently [5, 7, 12, 13]. leveraging edge resources. To remedy this, a number of edge com- A complete LEO satellite constellation comprises different shells puting platforms have been proposed to abstract from the underly- of satellites. Each shell is a collection of orbital planes with the ing infrastructure. To this end, they employ service offloading tech- same orbital parameters equally distributed across the earth, with niques, data geo-replication, or resource sharing [3, 14, 15, 27, 29]. each plane comprising a number of equally spaced satellites. We Edge computing platforms are usually developed around a spe- show such a constellation in Figure 1. cific OPA. In Figure 2, we show that the three main paradigms Given the low altitude, a single satellite has a relatively small that have initially evolved in the context of cloud computing offer cone of coverage yet it must be connected to some form of uplink different levels of abstractions. to provide Internet access. If no ground station uplink is available, e.g., because a satellite currently crosses an ocean, satellites may Virtual Machines. Virtual machines (VM) are virtualized servers connect to adjacent satellites via ISLs. This way, satellites can ac- that run operating systems which have often been slightly modified quire Internet access even if no ground station is within their field for VM usage to increase performance. Multiple virtual machines of view. Satellites also use ISLs for providing low latency broadband can share a common physical machine, hence a single server can access since light propagates faster in a vacuum than in fiber. This be made to look like many smaller machines. VMs can be used just makes satellite based Internet an attractive alternative for many like regular servers and host long-running applications, often with Internet subscribers [5, 11, 21]. multiple connected services sharing a virtual host [9]. A main driver of the “new space race” are decreasing satellite launch cost due to the development of reusable rockets such as Containers. Containers encapsulate individual processes instead SpaceX’s Falcon 9 launch vehicle [19]. Yet building a LEO satellite of full servers. Each service can be packaged into a container im- constellation from scratch still requires large upfront investments. age together with its dependencies and deployed alongside other Furthermore, regulatory challenges prove to be another market containers on a common host. Containers have the benefit that no entry barrier. Despite its size, LEO is a scarce resource as satellite entire operating system has to be managed by application devel- collisions have to be averted. To this end, satellites are also equipped opers but rather only the actual service and its dependencies. This with the capability to dodge obstacles. Additionally, companies must also reduces the application footprint, making container migra- also register the usage of radio frequencies for the communication tion easier than VM migration. Containers do not change the way Towards a Computing Platform for the LEO Edge EdgeSys ’21, April 26, 2021, Online, United Kingdom processes are executed, so they can also be used for long-running As a prerequisite, however, we first have to analyze different OPAs applications [23]. with regard to their suitability for the LEO edge. Serverless Functions. With serverless functions, only the actual 3 LEO EDGE CHARACTERISTICS code is deployed while the runtime is provided by the platform. In this section, we discuss the unique characteristics of the LEO edge. Serverless functions are short-lived, i.e., they exist only for a single At the time of writing, LEO satellites can only be used to connect to invocation. As such, they cannot maintain state yet provide scal- the Internet. Computing infrastructure, e.g., in the form of servers ability as additional, parallel function instances can be launched located at each individual satellite [6, 8], is not yet available to the to distribute requests. Conversely, function instances only con- general public. Thus, this discussion makes likely assumptions in sume resources during their execution [27]. Nevertheless, even some parts, especially concerning hardware capabilities. serverless applications must maintain state somehow; to that end, serverless databases, often following the NoSQL paradigm, are em- C1: Mobile Server Infrastructure. The first thing to keep in mind ployed [14, 15]. with servers attached to satellites in a LEO constellation is that these satellites orbit the earth at high speeds. For example, a satellite at an The distinction between these paradigms is not always clear in altitude of 550km must maintain a speed of 27,000km/h to maintain their implementation. For example, a serverless function platform its orbit [7]. Consequently, the servers also move at this speed. may use containers as runtimes for their functions [27]. Similarly, For the static ground station equipment this means that they must a container orchestrator can run containers on virtual machines. frequently change their communication partner. A fourth paradigm, the unikernel, is currently on the rise. As with C2: Same-model Servers. Then, satellites in a constellation are containers, unikernels package applications and their runtimes, yet mostly the same model. The reason for this is that satellites orbit they also add a library operating system that obviates the need for the earth continuously while the earth revolves beneath the satellite a shared OS [22]. We do not consider them separately in this paper constellation. Thus, each satellite eventually covers each part of as they combine concepts of virtual machines and containers. the earth which means that using different kinds of satellites for different regions is not possible. Subsequently, the servers must 2.3 Related Work also be of the same model. It can be possible to upgrade server The highly dynamic nature of satellite constellations and their capabilities over time as satellites reach the end of their lifetime, limited capacity for computational power means that existing edge yet developing different versions can have a negative impact on computing platforms are not yet ready for being applied to the development and production costs. Hence, we believe that it is likely LEO edge. Based on this premise, Bhosale et al. [8] propose Krios, a that hardware capabilities will be comparable across satellites until new platform based on Kubernetes that manages stateless as well a new generation of satellites (then with again improved hardware) as stateful services within the LEO edge. Through ground station is launched. We believe that it is unlikely that more than two or servers that calculate satellite orbital positions, Krios is able to three hardware versions will be deployed in parallel. predict when a service has to be spawned in a different satellite in C3: Homogeneously Distributed Servers. Due to their non-geosta- a “just-ahead-of-time” manner. Krios is therefore able to provide tionary nature, satellites are also homogeneously distributed across services without downtime from a client perspective. While this the globe, with satellites evenly spaced across an orbit. This means is an important first proposal, the authors decision for containers that each ground station has access to more or less the same amount seems somewhat arbitrary as they skip the evaluation of different of equally equipped satellites at all times. paradigms, as we do in this paper. The feasibility study conducted by Bhattacherjee et al. [6] ana- C4: Heterogeneous Demand. Nevertheless, demand is of course lyzes possible use cases and hand-off strategies, and explores the not homogenous across earth. Urban areas have a higher client viability of establishing computing resources in space. The authors density which increases resource demand compared to rural areas specifically mention content delivery networks, a use case we have or oceans with a smaller client population. also investigated in more detail in a previous study [26], augmented reality, “Tactile Internet” applications, multi-user interaction, and C5: Limited Compute Capabilities. As a consequence of being deployed in space, satellite servers’ capabilities must be limited. space-native data processing as possible use-cases. While such ap- The reason for this is that energy consumption and heat generation plications are also supported by terrestrial edge computing, the must be kept low for economical reasons. Larger heat dissipation authors note that adding compute capabilities to LEO satellites can mechanisms, batteries, or solar arrays lead to higher weight and, help to bridge the digital divide by bringing them to underserved subsequently, higher launch costs [6]. areas as well. The presented hand-off strategy is based on the con- cept of “virtual stationarity” to abstract from the dynamic nature C6: No Physical Access. Another effect of placing servers on satel- of the satellites and make the server appear as a single entity to lites in LEO is that those servers cannot be accessed for maintenance. the clients. For this, a heuristic picks a satellite server from a set Consequently, if a satellite or server fails, it remains failed and can of options with a near-optimal latency that is also visible to the only be de-orbited. client for the longest time, thus reducing the amount of required hand-offs. The next logical step beyond this initial feasibility study C7: Fixed Server Capabilities. Not being able to access individual and effective server selection strategy is to build a platform that servers directly also means that they cannot be upgraded. Over enables real application to take advantage of LEO edge computing. the lifetime of a satellite, typically about 5 years [30], the server EdgeSys ’21, April 26, 2021, Online, United Kingdom Tobias Pfandzelter, Jonathan Hasenburg, and David Bermbach capabilities and, with it, the total capability of the constellation of model will likely increase adoption of a LEO edge platform. Devel- servers, remain fixed. opers want the flexibility to create new applications and remove deprecated services while being charged only for the infrastructure C8: Fixed Number of Servers. Horizontal scalability is also limited, they use [2, 3]. as we can place servers only on satellites that are part of the con- stellation and the size of the constellation cannot be changed easily. R6: Elastic Scalability. Another important feature of cloud com- Launching and deploying additional satellites requires approval by puting is elastic scalability, i.e., that services can take advantage of governmental agencies and competing space Internet companies additional infrastructure if demand increases and release infrastruc- may lobby to limit constellation sizes, especially as LEO is a limited ture if it decreases [4]. To this end, the cloud provides the illusion resource [5, 31]. of infinite resources. A LEO edge platform should provide a similar illusion and provide the same level of scalability so that services do 4 LEO EDGE APPLICATION REQUIREMENTS not fail when demand increases. We note that in edge computing or at the LEO edge this is especially difficult given that the distributed In this section we derive requirements for building applications underlying infrastructure cannot as easily benefit from resource using a LEO edge platform from the perspective of a developer pooling [23, 27]. that is used to developing cloud applications. Some of the listed requirements are not particular to the LEO edge but also apply 5 SUITABILITY OF OPA OPTIONS TO LEO to, for example, edge platforms that are designed for terrestrial networks. EDGE SCENARIOS In this section, we analyze how different organization paradigms for R1: Deployment Close to Clients. The main advantage of edge applications (OPAs) can be used for building a LEO edge platform over cloud computing is that the services of an application can be that satisfies the requirements presented in Section 4 considering deployed close to their users. As such, if an application is deployed the unique characteristics of the LEO edge as discussed in Section 3. on a LEO edge platform, the platform should take care that individ- For this analysis, we consider the following OPAs: virtual machines, ual services are placed on the parts of the infrastructure that are in containers, and serverless functions. proximity to their clients [3, 9]. R1: Deployment Close to Clients. To deploy a service close to R2: High Availability. As with cloud computing, developers ex- clients, two steps are necessary: First, client locations have to be pect their application to be highly available in a LEO edge en- identified, either upfront in a static manner or dynamically at run- vironment as well. Consequently, a LEO edge platform needs to time. Second, infrastructure in proximity has to be identified and abstract from the widely distributed and heterogeneous underlying allocated so that the service can be deployed. infrastructure to provide fault-tolerance [3, 23]. On the LEO edge, two factors make this a particularly difficult R3: Isolation. A single LEO edge platform can be used to host a problem. First, the LEO edge, by design, provides global coverage, number of services from different developers. Ideally, this multi- so global clients have to be considered, whereas on the terrestrial tenancy should be hidden from developers, as other services should edge a platform only covers a specific country or area. Scheduling not interfere with each other. This comprises two dimensions: se- thus has to happen in a distributed manner rather than with a curity and performance isolation. From a security perspective, a central server, as a centralized scheduler, whether static or dynamic, service must neither be able to identify what other services are can easily become a bottleneck given the large amount of global using the platform, nor should it be able to read other services’ clients. Additionally, the combination of homogeneously deployed data [23, 29]. The performance of a service must also not be im- satellite servers (C3) and heterogeneous client demand (C4) must pacted by other services, i.e., no colocated service should degrade be taken into account. This scheduling component is an orthogonal performance on the same machine for other services. Performance platform design question compared to choosing the right OPA, yet degradation could, for example, occur when two such services share we note that the traditional centralized cluster orchestrator in use common hardware without sufficient measures to limit resource by container orchestration tools such as Kubernetes is a hindrance utilization [18]. in this context. Second, satellites are mobile (C1). Ground stations connect to R4: Familiar, Open Technology Stack. To simplify the transforma- their nearest satellite and expect their service to be available at tion of cloud-client applications to cloud-edge-client applications, that satellite. As satellites orbit the earth, ground stations recon- developers should be able to develop services for LEO edge plat- nect and applications have to either move across the LEO edge forms using a familiar technology stack, i.e., one that can also be infrastructure to remain stationary in relation to the clients or be applied in the cloud. This encompasses processor architectures (e.g., deployed across the entire infrastructure so that it is always acces- x86, x64, arm), operating systems (e.g., Linux, Windows), and pro- sible. Virtual machines, containers, and serverless functions can gramming languages (e.g., Java, Go, Python). The need for using all be moved between servers as required to provide this virtual novel technologies may hinder the adoption of the platform given stationarity, albeit with different complexity. Both virtual machines a steep learning curve and larger upfront investments [23, 29]. and containerized services can be migrated live without downtime, R5: Flexible Deployment. Cloud computing’s “pay-as-you-go” mod- yet the larger footprint of a virtual machine leads to a higher migra- el has been a major factor in its success as it enables flexible service tion overhead. For stateful applications, the overhead can quickly deployment without long term commitments. A similar deployment become significant when migrations occur frequently, e.g., as it is Towards a Computing Platform for the LEO Edge EdgeSys ’21, April 26, 2021, Online, United Kingdom the case for large satellite constellations and fast-moving satellites. consider that some of the decisions made regarding the infrastruc- Stateless serverless functions, on the other hand, benefit from their ture of satellite servers may “leak” through the layers of abstraction. inherent concurrency. Static function code can be preemptively For example, if a novel “space-ready” processor architecture should propagated to nearby satellite servers and new instances can al- be employed to support the unique LEO environment (C5), devel- ready be instantiated Alternatively, functions could simultaneously opers would be unable to deploy a VM with an operating system be deployed on all satellite servers concurrently given the small that does not support this architecture. Containers provide a higher footprint of function code. They would not necessarily also have level of abstraction, so just the chosen language runtime needs to to be instantiated at all times but could rather start once the first support this architecture. Serverless functions provide the highest request arrives (cold start). The overhead of frequent cold starts level of abstraction since the platform also provides the language may, on the other hand, be remedied by providing hints [1] about runtime. client location in regards to the mobile satellites since their move- On the other hand, lower levels of abstraction, i.e., virtual ma- ment is highly predictable. To manage state in a stateless serverless chines, also offer more freedom when it comes to bringing one’s environment, additional stateful services such as database systems own technology stack, so that it is easier to transfer familiar tech- are needed. Here, a shared serverless database infrastructure may nologies from terrestrial edge and cloud to the LEO edge. be provided where techniques similar to VM and container migra- R5: Flexible Deployment. Shipping new VM and container images tion can be employed, albeit with a smaller data footprint as only or serverless function code to satellite servers is simple. All three application state has to be transferred [14, 15]. OPAs also provide the flexibility to quickly start and stop services. Flexible deployment, however, also requires proper resource al- R2: High Availability. To provide high availability in the presence location. As the servers’ capabilities are limited (C7 ) and scaling of server or satellite failure, services need to be migrated to nearby services arbitrarily far up or out to meet a growing demand is not an servers since servers cannot easily be repaired or replaced (C5). option (C8), merely the illusion of infinite resource can be provided. This is problematic for stateful VMs and containers, as only a single To that end, a market-based approach where the limited resources instance can be live at one time and this instance needs to be are provisioned for the highest bidder could be an option [2]. In reinstantiated on a new satellite to offload the service. In case of combination with a pay-as-you-go model based on resources used satellite failures, a replicated live backup instance may even be in a specific time span, profit can be maximized. The efficacy of this required so no state is lost. This increases service overhead, which approaches improves with lower granularity of allocated resources, is problematic on limited satellite servers (C6). In case of stateless i.e., serverless functions are more efficient than containers and VMs. VMs or containers, this is still possible but suffers from the same Of course, offloading as proposed for the availability requirement migration costs discussed above. The serverless OPA is a better fit (R3) above is also an option to some extent. in this case as backup functions can be deployed on nearby satellites or across the entire constellation without state conflicts. If state is R6: Elastic Scalability. Given the heterogeneous service demand managed by a shared serverless database, correct data backups or (C4) in combination with a fixed amount ( C8) of homogeneously replication can be efficiently provided to the application. distributed satellite servers (C3) that cannot be upgraded (C7 ), off- loading is required if the demand for one service exceeds the limited R3: Isolation. All OPAs provide some level of security isolation capabilities of a single server (C5). Individual service requests or depending on their implementation, so performance isolation is a even full services may need to be offloaded. Request offloading is far more pressing issue on the limited hardware of a satellite server not possible given that only one copy of a stateful VM or container (C5). For each OPA, the available resources can be provisioned can be instantiated at a time, so the entire service may need to safely, i.e., that only the actually available resources are allocated. be moved to a nearby satellite server with enough capacity. For On the other hand, over-provisioning has an economical benefit as stateless container or VM implementations, offloading of requests not every service uses its allocated resources at all times. is possible yet results in high resource costs. In contrast to service A VM’s resource allocation is static for its entire lifetime and migrations due to satellite mobility, changes in demand can also since it hosts an entire operating system, its required resources not be predicted as easily. Additionally, containers and especially are comparatively large. This coarsely grained resource allocation VMs incur a large migration overhead. On the other hand, the low is less efficient than the alternatives. For containers, which host latency ISLs make forwarding requests to nearby satellites easier. individual processes, resources do not have to be allocated but can In the case of serverless functions, this can be used to offload indi- rather be limited to prevent leaking into other services. These limits vidual requests in case the local server has no more capacity. can also be adapted over the lifetime of a container. Depending on the implementation of the serverless execution environment, Overall, the three OPAs we analyzed use different levels of ab- resources for serverless function instances may also be limited straction, from VMs to serverless functions. Our analysis shows or statically allocated, although function lifetime is considerably that more abstraction gives greater control to the LEO edge comput- shorter than that of containers or VMs. Resource allocation can ing platform, which is important to satisfy developer requirements thus be maximized at all times without degrading service quality. in light of the unique characteristics of LEO edge infrastructure. Especially mobility of servers is a characteristics that goes beyond R4: Familiar, Open Technology Stack. All three OPAs are widely what terrestrial edge computing platforms must usually support in used in the context of cloud computing and can thus be considered practice. We thus conclude that a high level of abstraction benefits to reflect familiar technology stacks. Nevertheless, we must also upcoming LEO edge platforms and that the serverless paradigm EdgeSys ’21, April 26, 2021, Online, United Kingdom Tobias Pfandzelter, Jonathan Hasenburg, and David Bermbach will be the best choice for future work in this field. Of course, all [7] Debopam Bhattacherjee and Ankit Singla. 2019. Network topology des. at 27,000 km/hour. In Proc. 15th Int. Conf. Emerg. Netw. Experiments And Technologies. ACM, OPAs can be used, yet at different cost levels. 341–354. [8] Vaibhav Bhosale, Ketan Bhardwaj, and Ada Gavrilovska. 2020. Toward Loosely 6 CONCLUSION & FUTURE WORK Coupled Orchestration for the LEO Satell. Edge. In 3rd USENIX Workshop Hot Topics in Edge Comput. (HotEdge 20). USENIX. In this paper, we analyzed the suitability of three OPAs for upcom- [9] Abhishek Chandra, Jon Weissman, and Benjamin Heintz. 2013. Decentralized Edge Clouds. IEEE Internet Comput. 17, 5 (2013), 70–73. ing LEO edge platforms. For this, we discussed the unique char- [10] Arthur C Clarke. 1945. Exta-Terrestrial Relays - Can Rocket Stations Give World- acteristics of the LEO edge and derived requirements for building wide Radio Coverage? Wireless World LI, 10 (1945), 305–308. applications using such a platform from the perspective of a devel- [11] Elon Musk @elonmusk. 2021. All sats launched next year will have laser links. Only our polar sats have lasers this year & are v0.9. https://twitter.com/elonmusk/ oper that is used to developing cloud applications. We found that status/1353574169288396800. Accessed: 2021-1-25. low performance overheads, flexible reconfiguration and mobility [12] Mark Handley. 2018. Delay is Not an Option: Low Latency Routing in Space. In of application components, and strong support for multi-tenancy Proc. 17th ACM Workshop Hot Topics in Networks. ACM, 85–91. [13] Mark Handley. 2019. Using ground relays for low-latency wide-area routing in are essential for a LEO edge platform. Based on this, we conclude megaconstellations. In Proc. 18th ACM Workshop Hot Topics in Networks. ACM, that the serverless OPA is the best fit to fulfill these needs, as indi- 125–132. vidual functions can provide efficient resource allocation even in [14] Jonathan Hasenburg, Martin Grambow, and David Bermbach. 2019. FBase: A Replication Service for Data-Intensive Fog Applications. Technical Report. TU constrained environments such as LEO satellite servers – still the Berlin & ECDF, Mobile Cloud Computing Research Group. other OPAs can also be used but have additional costs and limita- [15] Jonathan Hasenburg, Martin Grambow, and David Bermbach. 2020. Towards A Replication Service for Data-Intensive Fog Applications. In Proc. 35th ACM Symp. tions. Finally, functions provide concurrency out of the box, which Appl. Computing, Posters Track (SAC 2020). ACM, 267–270. simplifies mobility and flexible deployment; also multi-tenancy is [16] Scott Hendrickson, Stephen Sturdevant, Tyler Harter, Venkateshwaran Venkatara- possible through the high degree of resource sharing. In future mani, Andrea C Arpaci-Dusseau, and Remzi H Arpaci-Dusseau. 2016. Serverless computation with openLambda. In 8th USENIX Workshop Hot Topics in Cloud work, we plan to design and evaluate such a serverless platform for Comput. (HotCloud 16). USENIX, 33–39. the LEO edge. [17] Takashi Iida. 2000. Satellite Communications: System and Its Des. Technology. IOS Press. This paper should be seen as a foundation for new research on [18] Vimalkumar Jeyakumar, Mohammad Alizadeh, David Mazières, Balaji Prabhakar, LEO edge platforms, as a range of open research questions arises Albert Greenberg, and Changhoon Kim. 2013. EyeQ: Practical Network Perfor- from it: For example, while virtual stationarity can be provided by mance Isolation at the Edge. In 10th USENIX Symposium on Networked Systems Design and Implementation (NSDI 13). USENIX, 297–311. anticipating satellite and earth movement, the concept of “stationar- [19] Harry Jones. 2018. The recent large reduction in space launch cost. In Proc. 48th ity” should be further explored since it can be achieved on a ground Internat. Conf. Environmental Systems. station, city, or even country level. In this regard, the efficiency of [20] Simon Kassing, Debopam Bhattacherjee, André Baptista Águas, Jens Eirik Saethre, and Ankit Singla. 2020. Exploring the“ Internet from space” with Hypatia. In different hand-off models should be investigated as well. Handing Proc. ACM Internet Meas. Conference. ACM, 214–229. off to the satellite that is closest to a specific ground station leads [21] Farooq Khan. 2015. Mobile Internet from the Heavens. arXiv preprint arXiv:1508.02383 (2015). to the best access latency yet increases overhead. More efficient [22] Anil Madhavapeddy, Richard Mortier, Charalampos Rotsos, David Scott, Balraj techniques such as employed in [6] should be evaluated in realistic Singh, Thomas Gazagnaire, Steven Smith, Steven Hand, and Jon Crowcroft. 2013. environments. Another question is how LEO edge-based platforms Unikernels: library operating systems for the cloud. SIGARCH Comput. Archit. News 41, 1 (2013), 461–472. can integrate with existing terrestrial cloud/edge/fog infrastruc- [23] Roberto Morabito, Vittorio Cozzolino, Aaron Yi Ding, Nicklas Beijar, and Jorg ture – can LEO edge platforms benefit from them? Finally, testing Ott. 2018. Consolidate IoT Edge Computing with Lightweight Virtualization. and benchmarking LEO edge platforms is hard without access to IEEE Netw. 32, 1 (2018), 102–111. [24] Frank Pallas, Philip Raschke, and David Bermbach. 2020. Fog Computing as the corresponding infrastructure. To that end, we also propose to Privacy Enabler. IEEE Internet Comput. 24, 4 (2020), 15–21. design testbeds for emulation or simulation of LEO edge platforms. [25] Tobias Pfandzelter and David Bermbach. 2019. IoT Data Process. in the Fog: Functions, Streams, or Batch Processing?. In Proc. 1st Workshop Efficient Data Movement in Fog Comput. (DaMove 2019). 201–206. ACKNOWLEDGMENTS [26] Tobias Pfandzelter and David Bermbach. 2020. Edge (of the Earth) Replication: Funded by the Deutsche Forschungsgemeinschaft (DFG, German Optimizing Content Del. in Large LEO Satell. Communication Networks. arXiv preprint arXiv:2012.08979 (2020). Research Foundation) – 415899119. [27] Tobias Pfandzelter and David Bermbach. 2020. tinyFaaS: A Lightweight FaaS Platform for Edge Environments. In 2020 IEEE Int. Conf. Fog Comput. (ICFC). IEEE, REFERENCES 17–24. [28] Tereza Pultarova. 2015. Telecommunications - Space tycoons go head to head [1] David Bermbach, Ahmet-Serdar Karakaya, and Simon Buchholz. 2020. Using over mega satell. netw. [News Briefing]. Engineering Technology 10, 2 (2015), Application Knowledge to Reduce Cold Starts in FaaS Services. In Proceedings of 20–20. the 35th ACM Symposium on Applied Computing (SAC 2020). ACM. [29] Mahadev Satyanarayanan, Victor Bahl, Ramón Caceres, and Nigel Davies. 2009. [2] David Bermbach, Setareh Maghsudi, Jonathan Hasenburg, and Tobias Pfandzelter. The Case for VM-Based Cloudlets in Mobile Computing. IEEE Pervasive Comput. 2020. Towards Auction-Based Function Placement in Serverless Fog Platforms. 8, 4 (2009), 14–23. In 2020 IEEE Int. Conf. Fog Comput. (ICFC). IEEE, 25–31. [30] Michael Sheetz. 2019. SpaceX launches another 60 Starlink satellites while set- [3] David Bermbach, Frank Pallas, David García Pérez, Pierluigi Plebani, Maya An- ting two rocket reuse records. https://www.cnbc.com/2019/11/11/watch- spacex- derson, Ronen Kat, and Stefan Tai. 2018. A Res. Perspective on Fog Computing. livestream- launching- second- starlink- internet- mission.html. Accessed: 2021-2- In 2nd Workshop IoT Syst. Provisioning & Manage. for Context-Aware Smart Cities (ISYCC). Springer, 198–210. [31] Michael Sheetz. 2021. Elon Musk blasts Jeff Bezos’ Amazon, alleging effort to ‘ham- [4] David Bermbach, Erik Wittern, and Stefan Tai. 2017. Cloud Service Benchmarking: string’ SpaceX’s Starlink satellite internet. https://www.cnbc.com/2021/01/26/ Measuring Quality of Cloud Services from a Client Perspective. Springer. elon- musk- blasts- jeff- bezos- amazon- competitor- to- spacexs- starlink- .html. Ac- [5] Debopam Bhattacherjee, Waqar Aqeel, Ilker Nadi Bozkurt, Anthony Aguirre, cessed: 2021-2-24. Balakrishnan Chandrasekaran, P Brighten Godfrey, Gregory Laughlin, Bruce [32] Michael Sheetz. 2021. SpaceX expands public beta test of Starlink satell. internet to Maggs, and Ankit Singla. 2018. Gearing up for the 21st century space race. In Canada and the UK. https://www.cnbc.com/2021/01/20/spacex- expands- starlink- Proc. 17th ACM Workshop Hot Topics in Networks. ACM, 113–119. public- beta- test- to- canada- united- kingdom.html. Accessed: 2021-1-25. [6] Debopam Bhattacherjee, Simon Kassing, Melissa Licciardello, and Ankit Singla. 2020. In-orbit Computing: An Outlandish thought Experiment?. In Proc. 19th ACM Workshop Hot Topics in Networks. ACM, 197–204. http://www.deepdyve.com/assets/images/DeepDyve-Logo-lg.png Computing Research Repository arXiv (Cornell University)

Towards a Computing Platform for the LEO Edge

Download PDF
6 pages

Loading next page...
 
/lp/arxiv-cornell-university/towards-a-computing-platform-for-the-leo-edge-g9FQ0yt18a

References

References for this paper are not available at this time. We will be adding them shortly, thank you for your patience.

eISSN
ARCH-3344
DOI
10.1145/3434770.3459736
Publisher site
See Article on Publisher Site

Abstract

Tobias Pfandzelter Jonathan Hasenburg David Bermbach TU Berlin & ECDF TU Berlin & ECDF TU Berlin & ECDF Mobile Cloud Computing Mobile Cloud Computing Mobile Cloud Computing Berlin, Germany Berlin, Germany Berlin, Germany [email protected] [email protected] [email protected] ABSTRACT satellite access networks can be a viable option for connecting all kinds of edge devices, even if terrestrial access is readily available. The new space race is heating up as private companies such as High-bandwidth, low-latency connections to client ground stations SpaceX and Amazon are building large satellite constellations in and via inter-satellite links (ISL) enable direct low-latency routing low-earth orbit (LEO) to provide global broadband internet access. between any two ground stations; thus, many argue that satellite As the number of subscribers connected to this access network Internet will see broad adoption in the future [5, 7, 12]. grows, it becomes necessary to investigate if and how edge com- Still, sending data from all end devices to a centralized location puting concepts can be applied to LEO satellite networks. for processing can put a substantial strain on the satellite network. In this paper, we discuss the unique characteristics of the LEO Especially for applications that transfer large amounts of data or edge and analyze the suitability of three organization paradigms for require low latency event processing, this can quickly become a applications considering developer requirements. We conclude that problem [25]. The same issue applies to terrestrial networks for the serverless approach is the most promising solution, opening up which edge computing, a computing paradigm that uses compute the field for future research. resources at the edge of the network in direct proximity to end users and devices, has been proposed as a promising solution [3, 9]. CCS CONCEPTS Applications can use these resources through edge platforms that • Computer systems organization→ Heterogeneous (hybrid) abstract from the geo-distributed server deployment and resource systems; Distributed architectures; • Networks→ Cloud comput- heterogeneity. These platforms are based on different organiza- ing. tion paradigms for applications (OPA), e.g., VMs, containers, or serverless functions. KEYWORDS Only recently, it has been proposed to also use computing re- satellite internet, LEO constellations, edge computing sources at the LEO edge to facilitate novel applications serving a global user base [6]. To realize this vision, however, edge platforms ACM Reference Format: Tobias Pfandzelter, Jonathan Hasenburg, and David Bermbach. 2021. To- must consider the unique characteristics of the LEO edge while still wards a Computing Platform for the LEO Edge. In 4th International Work- satisfying general requirements of application developers. As a first shop on Edge Systems, Analytics and Networking (EdgeSys ’21), April 26, step towards this goal, we must consider the core of such a platform, 2021, Online, United Kingdom. ACM, New York, NY, USA, 6 pages. https: the OPA, and analyze different options in light of the challenges at //doi.org/10.1145/3434770.3459736 the LEO edge. We therefore make the following contributions: (1) We discuss the unique characteristics of the LEO edge (Sec- 1 INTRODUCTION tion 3). Private Internet and aerospace companies are currently building (2) We derive requirements for building LEO edge applications the largest satellite constellations in existence: SpaceX, Amazon, from a developer perspective (Section 4). and Telesat – the so-called “New Space” companies – are deploy- (3) We analyze the suitability of three OPAs with regards to how ing or planning to launch tens of thousands of satellites into low they might satisfy developer requirements considering LEO Earth orbit (LEO) to provide global high-speed Internet access from edge characteristics (Section 5). space [28]. SpaceX’s Starlink constellation has already entered a public beta phase for subscribers in North America and the United 2 BACKGROUND & RELATED WORK Kingdom with more than 1,500 satellites in use [32]. In this section, we briefly introduce and describe the state of the art Beyond enabling Internet access for underserved regions such for large LEO satellite communication networks, edge computing, as rural areas, planes, or cargo and passenger ships, these new and OPAs. Furthermore, we also provide an overview of existing Permission to make digital or hard copies of all or part of this work for personal or LEO edge computing research. classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than the 2.1 LEO Communication Networks author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or Satellite-backed Internet access has been available for decades with republish, to post on servers or to redistribute to lists, requires prior specific permission and /or a fee. Request permissions from [email protected]. geostationary satellites at altitudes of 35,000km. The high altitude EdgeSys ’21, April 26, 2021, Online, United Kingdom combined with the requirement to orbit above the equator, however, © 2021 Copyright held by the owner/author(s). Publication rights licensed to ACM. result in high access latency for consumers which renders satellite ACM ISBN 978-1-4503-8291-5/21/04. . . $15.00 https://doi.org/10.1145/3434770.3459736 Internet inviable for many use cases [10, 17]. arXiv:2104.02396v1 [cs.DC] 6 Apr 2021 EdgeSys ’21, April 26, 2021, Online, United Kingdom Tobias Pfandzelter, Jonathan Hasenburg, and David Bermbach app app app app app app app runtime runtime runtime runtime runtime runtime OS OS OS OS OS VM VM H/W H/W H/W H/W (1) no sharing (2) virtual machines (3) containers (4) serverless Figure 2: OPAs by levels of abstraction [16]: while less ab- straction offers more freedom and flexibility, more abstrac- tion simplifies writing applications and shifts execution control to the platform which often increases efficiency. between ground stations and satellites. These factors mean that any change to the constellations requires a substantial lead time [5, 31]. Figure 1: Overview of a LEO satellite constellation compris- ing different shells. Shown here is the proposed first phase 2.2 Edge Computing of the Starlink deployment with five shells of 1,584 satellites The demand for processing data close to its origin led to an in- at 550km, 1,600 at 1110km, 400 at 1130km, 375 at 1275km, creased popularity of the edge computing paradigm in research and 450 at 1325km altitude [20]. and industry [3, 9]. The main idea behind edge computing is to embed computing resources into the edge of the network, i.e., close to clients. Compared to cloud computing, resources are thus avail- able with low latency and bandwidth costs. Preventing data from Now, a new generation of Internet satellites is being developed being transmitted to the cloud can also reduce privacy and security by companies such as SpaceX, Amazon, and Telesat. Thousands of risks [24]. these satellites are being deployed in large constellations at altitudes Typically, edge computing infrastructures comprise a multitude of below 600km, i.e., in the LEO. Thus, satellites continuously orbit of geo-distributed nodes with different compute, storage, and net- the globe and cover large ground distances in short periods of time. work capabilities. Using such a heterogeneous infrastructure is Each satellite is equipped with radio transmitters and receivers to significantly more difficult than the ease-of-adoption developers connect to ground stations. As ground station equipment is small are used to from the cloud: Applications need to consider geo- enough for use in family homes or airplanes, each satellite serves distribution, horizontal scalability, and network availability for fully many user terminals concurrently [5, 7, 12, 13]. leveraging edge resources. To remedy this, a number of edge com- A complete LEO satellite constellation comprises different shells puting platforms have been proposed to abstract from the underly- of satellites. Each shell is a collection of orbital planes with the ing infrastructure. To this end, they employ service offloading tech- same orbital parameters equally distributed across the earth, with niques, data geo-replication, or resource sharing [3, 14, 15, 27, 29]. each plane comprising a number of equally spaced satellites. We Edge computing platforms are usually developed around a spe- show such a constellation in Figure 1. cific OPA. In Figure 2, we show that the three main paradigms Given the low altitude, a single satellite has a relatively small that have initially evolved in the context of cloud computing offer cone of coverage yet it must be connected to some form of uplink different levels of abstractions. to provide Internet access. If no ground station uplink is available, e.g., because a satellite currently crosses an ocean, satellites may Virtual Machines. Virtual machines (VM) are virtualized servers connect to adjacent satellites via ISLs. This way, satellites can ac- that run operating systems which have often been slightly modified quire Internet access even if no ground station is within their field for VM usage to increase performance. Multiple virtual machines of view. Satellites also use ISLs for providing low latency broadband can share a common physical machine, hence a single server can access since light propagates faster in a vacuum than in fiber. This be made to look like many smaller machines. VMs can be used just makes satellite based Internet an attractive alternative for many like regular servers and host long-running applications, often with Internet subscribers [5, 11, 21]. multiple connected services sharing a virtual host [9]. A main driver of the “new space race” are decreasing satellite launch cost due to the development of reusable rockets such as Containers. Containers encapsulate individual processes instead SpaceX’s Falcon 9 launch vehicle [19]. Yet building a LEO satellite of full servers. Each service can be packaged into a container im- constellation from scratch still requires large upfront investments. age together with its dependencies and deployed alongside other Furthermore, regulatory challenges prove to be another market containers on a common host. Containers have the benefit that no entry barrier. Despite its size, LEO is a scarce resource as satellite entire operating system has to be managed by application devel- collisions have to be averted. To this end, satellites are also equipped opers but rather only the actual service and its dependencies. This with the capability to dodge obstacles. Additionally, companies must also reduces the application footprint, making container migra- also register the usage of radio frequencies for the communication tion easier than VM migration. Containers do not change the way Towards a Computing Platform for the LEO Edge EdgeSys ’21, April 26, 2021, Online, United Kingdom processes are executed, so they can also be used for long-running As a prerequisite, however, we first have to analyze different OPAs applications [23]. with regard to their suitability for the LEO edge. Serverless Functions. With serverless functions, only the actual 3 LEO EDGE CHARACTERISTICS code is deployed while the runtime is provided by the platform. In this section, we discuss the unique characteristics of the LEO edge. Serverless functions are short-lived, i.e., they exist only for a single At the time of writing, LEO satellites can only be used to connect to invocation. As such, they cannot maintain state yet provide scal- the Internet. Computing infrastructure, e.g., in the form of servers ability as additional, parallel function instances can be launched located at each individual satellite [6, 8], is not yet available to the to distribute requests. Conversely, function instances only con- general public. Thus, this discussion makes likely assumptions in sume resources during their execution [27]. Nevertheless, even some parts, especially concerning hardware capabilities. serverless applications must maintain state somehow; to that end, serverless databases, often following the NoSQL paradigm, are em- C1: Mobile Server Infrastructure. The first thing to keep in mind ployed [14, 15]. with servers attached to satellites in a LEO constellation is that these satellites orbit the earth at high speeds. For example, a satellite at an The distinction between these paradigms is not always clear in altitude of 550km must maintain a speed of 27,000km/h to maintain their implementation. For example, a serverless function platform its orbit [7]. Consequently, the servers also move at this speed. may use containers as runtimes for their functions [27]. Similarly, For the static ground station equipment this means that they must a container orchestrator can run containers on virtual machines. frequently change their communication partner. A fourth paradigm, the unikernel, is currently on the rise. As with C2: Same-model Servers. Then, satellites in a constellation are containers, unikernels package applications and their runtimes, yet mostly the same model. The reason for this is that satellites orbit they also add a library operating system that obviates the need for the earth continuously while the earth revolves beneath the satellite a shared OS [22]. We do not consider them separately in this paper constellation. Thus, each satellite eventually covers each part of as they combine concepts of virtual machines and containers. the earth which means that using different kinds of satellites for different regions is not possible. Subsequently, the servers must 2.3 Related Work also be of the same model. It can be possible to upgrade server The highly dynamic nature of satellite constellations and their capabilities over time as satellites reach the end of their lifetime, limited capacity for computational power means that existing edge yet developing different versions can have a negative impact on computing platforms are not yet ready for being applied to the development and production costs. Hence, we believe that it is likely LEO edge. Based on this premise, Bhosale et al. [8] propose Krios, a that hardware capabilities will be comparable across satellites until new platform based on Kubernetes that manages stateless as well a new generation of satellites (then with again improved hardware) as stateful services within the LEO edge. Through ground station is launched. We believe that it is unlikely that more than two or servers that calculate satellite orbital positions, Krios is able to three hardware versions will be deployed in parallel. predict when a service has to be spawned in a different satellite in C3: Homogeneously Distributed Servers. Due to their non-geosta- a “just-ahead-of-time” manner. Krios is therefore able to provide tionary nature, satellites are also homogeneously distributed across services without downtime from a client perspective. While this the globe, with satellites evenly spaced across an orbit. This means is an important first proposal, the authors decision for containers that each ground station has access to more or less the same amount seems somewhat arbitrary as they skip the evaluation of different of equally equipped satellites at all times. paradigms, as we do in this paper. The feasibility study conducted by Bhattacherjee et al. [6] ana- C4: Heterogeneous Demand. Nevertheless, demand is of course lyzes possible use cases and hand-off strategies, and explores the not homogenous across earth. Urban areas have a higher client viability of establishing computing resources in space. The authors density which increases resource demand compared to rural areas specifically mention content delivery networks, a use case we have or oceans with a smaller client population. also investigated in more detail in a previous study [26], augmented reality, “Tactile Internet” applications, multi-user interaction, and C5: Limited Compute Capabilities. As a consequence of being deployed in space, satellite servers’ capabilities must be limited. space-native data processing as possible use-cases. While such ap- The reason for this is that energy consumption and heat generation plications are also supported by terrestrial edge computing, the must be kept low for economical reasons. Larger heat dissipation authors note that adding compute capabilities to LEO satellites can mechanisms, batteries, or solar arrays lead to higher weight and, help to bridge the digital divide by bringing them to underserved subsequently, higher launch costs [6]. areas as well. The presented hand-off strategy is based on the con- cept of “virtual stationarity” to abstract from the dynamic nature C6: No Physical Access. Another effect of placing servers on satel- of the satellites and make the server appear as a single entity to lites in LEO is that those servers cannot be accessed for maintenance. the clients. For this, a heuristic picks a satellite server from a set Consequently, if a satellite or server fails, it remains failed and can of options with a near-optimal latency that is also visible to the only be de-orbited. client for the longest time, thus reducing the amount of required hand-offs. The next logical step beyond this initial feasibility study C7: Fixed Server Capabilities. Not being able to access individual and effective server selection strategy is to build a platform that servers directly also means that they cannot be upgraded. Over enables real application to take advantage of LEO edge computing. the lifetime of a satellite, typically about 5 years [30], the server EdgeSys ’21, April 26, 2021, Online, United Kingdom Tobias Pfandzelter, Jonathan Hasenburg, and David Bermbach capabilities and, with it, the total capability of the constellation of model will likely increase adoption of a LEO edge platform. Devel- servers, remain fixed. opers want the flexibility to create new applications and remove deprecated services while being charged only for the infrastructure C8: Fixed Number of Servers. Horizontal scalability is also limited, they use [2, 3]. as we can place servers only on satellites that are part of the con- stellation and the size of the constellation cannot be changed easily. R6: Elastic Scalability. Another important feature of cloud com- Launching and deploying additional satellites requires approval by puting is elastic scalability, i.e., that services can take advantage of governmental agencies and competing space Internet companies additional infrastructure if demand increases and release infrastruc- may lobby to limit constellation sizes, especially as LEO is a limited ture if it decreases [4]. To this end, the cloud provides the illusion resource [5, 31]. of infinite resources. A LEO edge platform should provide a similar illusion and provide the same level of scalability so that services do 4 LEO EDGE APPLICATION REQUIREMENTS not fail when demand increases. We note that in edge computing or at the LEO edge this is especially difficult given that the distributed In this section we derive requirements for building applications underlying infrastructure cannot as easily benefit from resource using a LEO edge platform from the perspective of a developer pooling [23, 27]. that is used to developing cloud applications. Some of the listed requirements are not particular to the LEO edge but also apply 5 SUITABILITY OF OPA OPTIONS TO LEO to, for example, edge platforms that are designed for terrestrial networks. EDGE SCENARIOS In this section, we analyze how different organization paradigms for R1: Deployment Close to Clients. The main advantage of edge applications (OPAs) can be used for building a LEO edge platform over cloud computing is that the services of an application can be that satisfies the requirements presented in Section 4 considering deployed close to their users. As such, if an application is deployed the unique characteristics of the LEO edge as discussed in Section 3. on a LEO edge platform, the platform should take care that individ- For this analysis, we consider the following OPAs: virtual machines, ual services are placed on the parts of the infrastructure that are in containers, and serverless functions. proximity to their clients [3, 9]. R1: Deployment Close to Clients. To deploy a service close to R2: High Availability. As with cloud computing, developers ex- clients, two steps are necessary: First, client locations have to be pect their application to be highly available in a LEO edge en- identified, either upfront in a static manner or dynamically at run- vironment as well. Consequently, a LEO edge platform needs to time. Second, infrastructure in proximity has to be identified and abstract from the widely distributed and heterogeneous underlying allocated so that the service can be deployed. infrastructure to provide fault-tolerance [3, 23]. On the LEO edge, two factors make this a particularly difficult R3: Isolation. A single LEO edge platform can be used to host a problem. First, the LEO edge, by design, provides global coverage, number of services from different developers. Ideally, this multi- so global clients have to be considered, whereas on the terrestrial tenancy should be hidden from developers, as other services should edge a platform only covers a specific country or area. Scheduling not interfere with each other. This comprises two dimensions: se- thus has to happen in a distributed manner rather than with a curity and performance isolation. From a security perspective, a central server, as a centralized scheduler, whether static or dynamic, service must neither be able to identify what other services are can easily become a bottleneck given the large amount of global using the platform, nor should it be able to read other services’ clients. Additionally, the combination of homogeneously deployed data [23, 29]. The performance of a service must also not be im- satellite servers (C3) and heterogeneous client demand (C4) must pacted by other services, i.e., no colocated service should degrade be taken into account. This scheduling component is an orthogonal performance on the same machine for other services. Performance platform design question compared to choosing the right OPA, yet degradation could, for example, occur when two such services share we note that the traditional centralized cluster orchestrator in use common hardware without sufficient measures to limit resource by container orchestration tools such as Kubernetes is a hindrance utilization [18]. in this context. Second, satellites are mobile (C1). Ground stations connect to R4: Familiar, Open Technology Stack. To simplify the transforma- their nearest satellite and expect their service to be available at tion of cloud-client applications to cloud-edge-client applications, that satellite. As satellites orbit the earth, ground stations recon- developers should be able to develop services for LEO edge plat- nect and applications have to either move across the LEO edge forms using a familiar technology stack, i.e., one that can also be infrastructure to remain stationary in relation to the clients or be applied in the cloud. This encompasses processor architectures (e.g., deployed across the entire infrastructure so that it is always acces- x86, x64, arm), operating systems (e.g., Linux, Windows), and pro- sible. Virtual machines, containers, and serverless functions can gramming languages (e.g., Java, Go, Python). The need for using all be moved between servers as required to provide this virtual novel technologies may hinder the adoption of the platform given stationarity, albeit with different complexity. Both virtual machines a steep learning curve and larger upfront investments [23, 29]. and containerized services can be migrated live without downtime, R5: Flexible Deployment. Cloud computing’s “pay-as-you-go” mod- yet the larger footprint of a virtual machine leads to a higher migra- el has been a major factor in its success as it enables flexible service tion overhead. For stateful applications, the overhead can quickly deployment without long term commitments. A similar deployment become significant when migrations occur frequently, e.g., as it is Towards a Computing Platform for the LEO Edge EdgeSys ’21, April 26, 2021, Online, United Kingdom the case for large satellite constellations and fast-moving satellites. consider that some of the decisions made regarding the infrastruc- Stateless serverless functions, on the other hand, benefit from their ture of satellite servers may “leak” through the layers of abstraction. inherent concurrency. Static function code can be preemptively For example, if a novel “space-ready” processor architecture should propagated to nearby satellite servers and new instances can al- be employed to support the unique LEO environment (C5), devel- ready be instantiated Alternatively, functions could simultaneously opers would be unable to deploy a VM with an operating system be deployed on all satellite servers concurrently given the small that does not support this architecture. Containers provide a higher footprint of function code. They would not necessarily also have level of abstraction, so just the chosen language runtime needs to to be instantiated at all times but could rather start once the first support this architecture. Serverless functions provide the highest request arrives (cold start). The overhead of frequent cold starts level of abstraction since the platform also provides the language may, on the other hand, be remedied by providing hints [1] about runtime. client location in regards to the mobile satellites since their move- On the other hand, lower levels of abstraction, i.e., virtual ma- ment is highly predictable. To manage state in a stateless serverless chines, also offer more freedom when it comes to bringing one’s environment, additional stateful services such as database systems own technology stack, so that it is easier to transfer familiar tech- are needed. Here, a shared serverless database infrastructure may nologies from terrestrial edge and cloud to the LEO edge. be provided where techniques similar to VM and container migra- R5: Flexible Deployment. Shipping new VM and container images tion can be employed, albeit with a smaller data footprint as only or serverless function code to satellite servers is simple. All three application state has to be transferred [14, 15]. OPAs also provide the flexibility to quickly start and stop services. Flexible deployment, however, also requires proper resource al- R2: High Availability. To provide high availability in the presence location. As the servers’ capabilities are limited (C7 ) and scaling of server or satellite failure, services need to be migrated to nearby services arbitrarily far up or out to meet a growing demand is not an servers since servers cannot easily be repaired or replaced (C5). option (C8), merely the illusion of infinite resource can be provided. This is problematic for stateful VMs and containers, as only a single To that end, a market-based approach where the limited resources instance can be live at one time and this instance needs to be are provisioned for the highest bidder could be an option [2]. In reinstantiated on a new satellite to offload the service. In case of combination with a pay-as-you-go model based on resources used satellite failures, a replicated live backup instance may even be in a specific time span, profit can be maximized. The efficacy of this required so no state is lost. This increases service overhead, which approaches improves with lower granularity of allocated resources, is problematic on limited satellite servers (C6). In case of stateless i.e., serverless functions are more efficient than containers and VMs. VMs or containers, this is still possible but suffers from the same Of course, offloading as proposed for the availability requirement migration costs discussed above. The serverless OPA is a better fit (R3) above is also an option to some extent. in this case as backup functions can be deployed on nearby satellites or across the entire constellation without state conflicts. If state is R6: Elastic Scalability. Given the heterogeneous service demand managed by a shared serverless database, correct data backups or (C4) in combination with a fixed amount ( C8) of homogeneously replication can be efficiently provided to the application. distributed satellite servers (C3) that cannot be upgraded (C7 ), off- loading is required if the demand for one service exceeds the limited R3: Isolation. All OPAs provide some level of security isolation capabilities of a single server (C5). Individual service requests or depending on their implementation, so performance isolation is a even full services may need to be offloaded. Request offloading is far more pressing issue on the limited hardware of a satellite server not possible given that only one copy of a stateful VM or container (C5). For each OPA, the available resources can be provisioned can be instantiated at a time, so the entire service may need to safely, i.e., that only the actually available resources are allocated. be moved to a nearby satellite server with enough capacity. For On the other hand, over-provisioning has an economical benefit as stateless container or VM implementations, offloading of requests not every service uses its allocated resources at all times. is possible yet results in high resource costs. In contrast to service A VM’s resource allocation is static for its entire lifetime and migrations due to satellite mobility, changes in demand can also since it hosts an entire operating system, its required resources not be predicted as easily. Additionally, containers and especially are comparatively large. This coarsely grained resource allocation VMs incur a large migration overhead. On the other hand, the low is less efficient than the alternatives. For containers, which host latency ISLs make forwarding requests to nearby satellites easier. individual processes, resources do not have to be allocated but can In the case of serverless functions, this can be used to offload indi- rather be limited to prevent leaking into other services. These limits vidual requests in case the local server has no more capacity. can also be adapted over the lifetime of a container. Depending on the implementation of the serverless execution environment, Overall, the three OPAs we analyzed use different levels of ab- resources for serverless function instances may also be limited straction, from VMs to serverless functions. Our analysis shows or statically allocated, although function lifetime is considerably that more abstraction gives greater control to the LEO edge comput- shorter than that of containers or VMs. Resource allocation can ing platform, which is important to satisfy developer requirements thus be maximized at all times without degrading service quality. in light of the unique characteristics of LEO edge infrastructure. Especially mobility of servers is a characteristics that goes beyond R4: Familiar, Open Technology Stack. All three OPAs are widely what terrestrial edge computing platforms must usually support in used in the context of cloud computing and can thus be considered practice. We thus conclude that a high level of abstraction benefits to reflect familiar technology stacks. Nevertheless, we must also upcoming LEO edge platforms and that the serverless paradigm EdgeSys ’21, April 26, 2021, Online, United Kingdom Tobias Pfandzelter, Jonathan Hasenburg, and David Bermbach will be the best choice for future work in this field. Of course, all [7] Debopam Bhattacherjee and Ankit Singla. 2019. Network topology des. at 27,000 km/hour. In Proc. 15th Int. Conf. Emerg. Netw. Experiments And Technologies. ACM, OPAs can be used, yet at different cost levels. 341–354. [8] Vaibhav Bhosale, Ketan Bhardwaj, and Ada Gavrilovska. 2020. Toward Loosely 6 CONCLUSION & FUTURE WORK Coupled Orchestration for the LEO Satell. Edge. In 3rd USENIX Workshop Hot Topics in Edge Comput. (HotEdge 20). USENIX. In this paper, we analyzed the suitability of three OPAs for upcom- [9] Abhishek Chandra, Jon Weissman, and Benjamin Heintz. 2013. Decentralized Edge Clouds. IEEE Internet Comput. 17, 5 (2013), 70–73. ing LEO edge platforms. For this, we discussed the unique char- [10] Arthur C Clarke. 1945. Exta-Terrestrial Relays - Can Rocket Stations Give World- acteristics of the LEO edge and derived requirements for building wide Radio Coverage? Wireless World LI, 10 (1945), 305–308. applications using such a platform from the perspective of a devel- [11] Elon Musk @elonmusk. 2021. All sats launched next year will have laser links. Only our polar sats have lasers this year & are v0.9. https://twitter.com/elonmusk/ oper that is used to developing cloud applications. We found that status/1353574169288396800. Accessed: 2021-1-25. low performance overheads, flexible reconfiguration and mobility [12] Mark Handley. 2018. Delay is Not an Option: Low Latency Routing in Space. In of application components, and strong support for multi-tenancy Proc. 17th ACM Workshop Hot Topics in Networks. ACM, 85–91. [13] Mark Handley. 2019. Using ground relays for low-latency wide-area routing in are essential for a LEO edge platform. Based on this, we conclude megaconstellations. In Proc. 18th ACM Workshop Hot Topics in Networks. ACM, that the serverless OPA is the best fit to fulfill these needs, as indi- 125–132. vidual functions can provide efficient resource allocation even in [14] Jonathan Hasenburg, Martin Grambow, and David Bermbach. 2019. FBase: A Replication Service for Data-Intensive Fog Applications. Technical Report. TU constrained environments such as LEO satellite servers – still the Berlin & ECDF, Mobile Cloud Computing Research Group. other OPAs can also be used but have additional costs and limita- [15] Jonathan Hasenburg, Martin Grambow, and David Bermbach. 2020. Towards A Replication Service for Data-Intensive Fog Applications. In Proc. 35th ACM Symp. tions. Finally, functions provide concurrency out of the box, which Appl. Computing, Posters Track (SAC 2020). ACM, 267–270. simplifies mobility and flexible deployment; also multi-tenancy is [16] Scott Hendrickson, Stephen Sturdevant, Tyler Harter, Venkateshwaran Venkatara- possible through the high degree of resource sharing. In future mani, Andrea C Arpaci-Dusseau, and Remzi H Arpaci-Dusseau. 2016. Serverless computation with openLambda. In 8th USENIX Workshop Hot Topics in Cloud work, we plan to design and evaluate such a serverless platform for Comput. (HotCloud 16). USENIX, 33–39. the LEO edge. [17] Takashi Iida. 2000. Satellite Communications: System and Its Des. Technology. IOS Press. This paper should be seen as a foundation for new research on [18] Vimalkumar Jeyakumar, Mohammad Alizadeh, David Mazières, Balaji Prabhakar, LEO edge platforms, as a range of open research questions arises Albert Greenberg, and Changhoon Kim. 2013. EyeQ: Practical Network Perfor- from it: For example, while virtual stationarity can be provided by mance Isolation at the Edge. In 10th USENIX Symposium on Networked Systems Design and Implementation (NSDI 13). USENIX, 297–311. anticipating satellite and earth movement, the concept of “stationar- [19] Harry Jones. 2018. The recent large reduction in space launch cost. In Proc. 48th ity” should be further explored since it can be achieved on a ground Internat. Conf. Environmental Systems. station, city, or even country level. In this regard, the efficiency of [20] Simon Kassing, Debopam Bhattacherjee, André Baptista Águas, Jens Eirik Saethre, and Ankit Singla. 2020. Exploring the“ Internet from space” with Hypatia. In different hand-off models should be investigated as well. Handing Proc. ACM Internet Meas. Conference. ACM, 214–229. off to the satellite that is closest to a specific ground station leads [21] Farooq Khan. 2015. Mobile Internet from the Heavens. arXiv preprint arXiv:1508.02383 (2015). to the best access latency yet increases overhead. More efficient [22] Anil Madhavapeddy, Richard Mortier, Charalampos Rotsos, David Scott, Balraj techniques such as employed in [6] should be evaluated in realistic Singh, Thomas Gazagnaire, Steven Smith, Steven Hand, and Jon Crowcroft. 2013. environments. Another question is how LEO edge-based platforms Unikernels: library operating systems for the cloud. SIGARCH Comput. Archit. News 41, 1 (2013), 461–472. can integrate with existing terrestrial cloud/edge/fog infrastruc- [23] Roberto Morabito, Vittorio Cozzolino, Aaron Yi Ding, Nicklas Beijar, and Jorg ture – can LEO edge platforms benefit from them? Finally, testing Ott. 2018. Consolidate IoT Edge Computing with Lightweight Virtualization. and benchmarking LEO edge platforms is hard without access to IEEE Netw. 32, 1 (2018), 102–111. [24] Frank Pallas, Philip Raschke, and David Bermbach. 2020. Fog Computing as the corresponding infrastructure. To that end, we also propose to Privacy Enabler. IEEE Internet Comput. 24, 4 (2020), 15–21. design testbeds for emulation or simulation of LEO edge platforms. [25] Tobias Pfandzelter and David Bermbach. 2019. IoT Data Process. in the Fog: Functions, Streams, or Batch Processing?. In Proc. 1st Workshop Efficient Data Movement in Fog Comput. (DaMove 2019). 201–206. ACKNOWLEDGMENTS [26] Tobias Pfandzelter and David Bermbach. 2020. Edge (of the Earth) Replication: Funded by the Deutsche Forschungsgemeinschaft (DFG, German Optimizing Content Del. in Large LEO Satell. Communication Networks. arXiv preprint arXiv:2012.08979 (2020). Research Foundation) – 415899119. [27] Tobias Pfandzelter and David Bermbach. 2020. tinyFaaS: A Lightweight FaaS Platform for Edge Environments. In 2020 IEEE Int. Conf. Fog Comput. (ICFC). IEEE, REFERENCES 17–24. [28] Tereza Pultarova. 2015. Telecommunications - Space tycoons go head to head [1] David Bermbach, Ahmet-Serdar Karakaya, and Simon Buchholz. 2020. Using over mega satell. netw. [News Briefing]. Engineering Technology 10, 2 (2015), Application Knowledge to Reduce Cold Starts in FaaS Services. In Proceedings of 20–20. the 35th ACM Symposium on Applied Computing (SAC 2020). ACM. [29] Mahadev Satyanarayanan, Victor Bahl, Ramón Caceres, and Nigel Davies. 2009. [2] David Bermbach, Setareh Maghsudi, Jonathan Hasenburg, and Tobias Pfandzelter. The Case for VM-Based Cloudlets in Mobile Computing. IEEE Pervasive Comput. 2020. Towards Auction-Based Function Placement in Serverless Fog Platforms. 8, 4 (2009), 14–23. In 2020 IEEE Int. Conf. Fog Comput. (ICFC). IEEE, 25–31. [30] Michael Sheetz. 2019. SpaceX launches another 60 Starlink satellites while set- [3] David Bermbach, Frank Pallas, David García Pérez, Pierluigi Plebani, Maya An- ting two rocket reuse records. https://www.cnbc.com/2019/11/11/watch- spacex- derson, Ronen Kat, and Stefan Tai. 2018. A Res. Perspective on Fog Computing. livestream- launching- second- starlink- internet- mission.html. Accessed: 2021-2- In 2nd Workshop IoT Syst. Provisioning & Manage. for Context-Aware Smart Cities (ISYCC). Springer, 198–210. [31] Michael Sheetz. 2021. Elon Musk blasts Jeff Bezos’ Amazon, alleging effort to ‘ham- [4] David Bermbach, Erik Wittern, and Stefan Tai. 2017. Cloud Service Benchmarking: string’ SpaceX’s Starlink satellite internet. https://www.cnbc.com/2021/01/26/ Measuring Quality of Cloud Services from a Client Perspective. Springer. elon- musk- blasts- jeff- bezos- amazon- competitor- to- spacexs- starlink- .html. Ac- [5] Debopam Bhattacherjee, Waqar Aqeel, Ilker Nadi Bozkurt, Anthony Aguirre, cessed: 2021-2-24. Balakrishnan Chandrasekaran, P Brighten Godfrey, Gregory Laughlin, Bruce [32] Michael Sheetz. 2021. SpaceX expands public beta test of Starlink satell. internet to Maggs, and Ankit Singla. 2018. Gearing up for the 21st century space race. In Canada and the UK. https://www.cnbc.com/2021/01/20/spacex- expands- starlink- Proc. 17th ACM Workshop Hot Topics in Networks. ACM, 113–119. public- beta- test- to- canada- united- kingdom.html. Accessed: 2021-1-25. [6] Debopam Bhattacherjee, Simon Kassing, Melissa Licciardello, and Ankit Singla. 2020. In-orbit Computing: An Outlandish thought Experiment?. In Proc. 19th ACM Workshop Hot Topics in Networks. ACM, 197–204.

Journal

Computing Research Repository – arXiv (Cornell University)

Published: Apr 6, 2021

There are no references for this article.