Edge Computing Enabled by Unmanned Autonomous Vehicles
aa r X i v : . [ c s . D C ] D ec Edge Computing Enabled by Unmanned AutonomousVehicles
Mohan Liyanage a , Farooq Dar a , Rajesh Sharma a , Huber Flores a a Institute of Computer Science,University of Tartu, Estonia,fi[email protected]
Abstract
Pervasive applications are revolutionizing the perception that users havetowards the environment. Indeed, pervasive applications perform resource-intensive computations over large amounts of stream sensor data collectedfrom multiple sources. This allows applications to provide richer and deep in-sights into the natural characteristics that govern everything that surroundsus. A key limitation of these applications is that they have high energyfootprints, which in turn hampers the quality of experience of users. Whilecloud and edge computing solutions can be applied to alleviate the problem,these solutions are hard to adopt in existing architecture and far from be-come ubiquitous. Fortunately, cloudlets are becoming portable enough, suchthat they can be transported and integrated into any environment easilyand dynamically. In this article, we investigate how cloudlets can be trans-ported by unmanned autonomous vehicles (UAV)s to provide computationsupport on the edge. Based on our study, we develop GEESE, a novel UAV-based system that enables the dynamic deployment of an edge computinginfrastructure through the cooperation of multiple UAVs carrying cloudlets.By using GEESE, we conduct rigorous experiments to analyze the effort todeliver cloudlets using aerial, ground, and underwater UAVs. Our results in-dicate that UAVs can work in a cooperative manner to enable edge computingin the wild.
Keywords:
Email addresses: [email protected] (Mohan Liyanage ), [email protected] (Farooq Dar ), [email protected] (Rajesh Sharma ), [email protected] (HuberFlores )
Preprint submitted: June 1, 2020 ulti-Devices, Unmanned Autonomous Vehicles, Adaptive Placement,Edge Intelligence, Collaborative Computing, Cloudlets, Resource allocation,Aerial, Ground and Underwater Drones
1. Introduction
Pervasive sensing is emerging as a fundamental field of study that is trans-forming the perception that users have towards their environment. Thanksto the proliferation of embedded sensors, wearable, and IoT devices, alongwith the increasing computing capabilities of smartphones, it is possible toenable a new type of mobile applications that can provide richer and deeperinsights about the natural characteristics that govern everything that sur-rounds us. Examples of this include, analyzing the properties of liquids withcameras [1], understanding the quality of food with WiFi signals [2], identifi-cation of unlabeled medicine with infrared optical sensors [3], spotting hiddencameras with thermal footprints [4] and pedestrian detection for navigationof autonomous cars [5]. One key limitation of this type of applications is thatthey require analyzing long streams of sensing data, which leads to high en-ergy consumption that drains the battery of end-devices. This is problematicas it hampers the quality of experience (QoE) of users with applications sig-nificantly [6]. To overcome this problem, smartphone applications can offloadheavy computations to the cloud and edge servers [7], such that devices canreduce energy consumption [8]. Unfortunately, cloud and edge computingsolutions are not well suited to offload long streams of sensing data. Cloudcomputing is difficult to use due to oscillating communication latency to re-mote servers, which can induce additional energy overheads and slow downthe performance of applications. Likewise, edge computing is not available inan ubiquitous manner. Indeed, edge deployments are scarce and not denseenough to provide stable services. Nevertheless, edge computing solutionsare preferable over cloud computing ones as edge computing can analyzelong streams of sensor data with consistent performance, and without induc-ing high energy overheads in end-devices caused by moving sensor data toofar from its source [9].To overcome the scarcity of edge computing deployments, most of the ex-isting work has focused on exploring two prominent perspectives. The firstone explores the formation of underlying computing infrastructure from re-sources of devices located densely in the environment, e.g., personal comput-ers, smart and IoT devices, such that edge services can be executed on top oft [10]. The other perspective consists in identifying the optimal placement ofstatic edge servers [11], such that the coverage of the edge computing supportcan be ensured in a particular area (see Section 2 to obtain detailed descrip-tion). While these solutions can partially alleviate the ubiquitous access toedge computing resources, they do not tackle the problem of scalability ofedge computing. Indeed, unlike cloud computing that is elastic, which meansthat computational resources can be added or removed dynamically to han-dle the dynamic workload of users [12] (a number of concurrent users), edgecomputing completely lacks the properties of elasticity. Consequently, edgeresources have limited capacity and are unable to handle dynamic workloads.For instance, consider a large crowd of people that gather spontaneously ina location, e.g., flash mobs [13]. If a single edge server is available to processstreams of sensing data for the crowd, then the server can easily be over-loaded by such a group, and instead of improving the QoE of users, it canend up degrading the overall performance of all the devices in the crowd. For-tunately, cloudlets [14] are becoming portable and they are the fundamentalsource for providing computing support on the edge. Cloudlets can be easilycreated from devices that have small sizes and low weights. For instance, ithas been demonstrated that smartphones can be used as cloudlets [15, 10].Thanks to this portability, it is possible then to envision cloudlets that canbe transported and integrated into any environment dynamically. Recent ad-vancements in unmanned autonomous vehicles (UAV), which are also knownas drones, can provide transportation means to carry cloudlets to the edge.In this paper, we contribute by developing GEESE , a novel UAV-basedsystem that enables the dynamic deployment of an edge computing infras-tructure though cooperation of multiple UAVs carrying cloudlets. Since dif-ferent UAV transportation modalities can be used to transport cloudlets, westudy the transportation of cloudlets using aerial, ground, and underwaterUAVs (Here thereafter we will refer to any drone modality as UAV). To thisend, we explore the requirements to be fulfilled for equipping different typesof UAVs with cloudlets, and the effort required by UAVs to move cloudletsof different sizes and weights between locations. In addition, we also analyzethe cooperation between UAVs to form an edge computing infrastructure viacollaborative processing. To scale up cloudlets on the edge, we also explore a GEESE refers to a group of social birds that are adapted to ground, water and aerialenvironments. esource delivery model that enables us to optimally estimate the amount ofUAVs and cloudlets required to handle a workload of users on the edge. Ourresults with GEESE demonstrate that by working in a collaborative manner,UAVs can transport cloudlets to enable the dynamic deployment of an edgecomputing infrastructure close to users.The contributions of the paper are summarized as follows:•
New insights about using UAVs to enable edge computing de-ployments with cloudlets:
We quantify the performance of UAVs totransport cloudlets to the edge. We show that weight and the encasingof the cloudlet are critical factors to equip different types of UAVs withcloudlets.•
Improved and scalable edge computing deployments:
We demon-strate that an edge computing infrastructure can be formed through thecooperation of multiple types of UAVs via collaborative processing.•
New method to transport and place cloudlets on the edgedynamically:
We develop an edge delivery model that estimates theamount of UAVs and capabilities of cloudlets required to satisfy a work-load from a crowd of users. In addition, we also demonstrate that UAVscan be easily used to reallocate edge computing resources based on thecharacteristics of users’ mobility.
2. Background and related work
In this section, we discuss existing work and highlight how our contribu-tions advance the state of the art.
Cloudlets:
A Cloudlet is a resourceful and trusted piece of computing in-frastructure located close to end users [14]. Cloudlets are among the firstarchitectural models that emerged for providing computing support on theedge, e.g., cyber-foraging [16]. Cloudlets can exploit proximal and staticinfrastructure, such as hotspots and base stations, in an opportunistic man-ner to push computing services into networks that are accessible by devicesof end-users through low and consistent latency. The main problem withcloudlets is that it requires the deployment of dedicated infrastructure, e.g.,servers, which is difficult to maintain and deploy permanently in a location.In addition, as cloudlets are accessed through proximity-based communica-tions e.g., WiFi-Direct and Bluetooth, the computing support coverage ofloudlets in an area is limited to a few hundred meters or less as it dependson the characteristics of the environment where the cloudlet is deployed,e.g., indoor building, outdoor park. As a result, the success – or failure– ofa cloudlet deployment depends on a dense distribution of a high number ofcloudlets in a location. Dense deployment of cloudlets in the wild is criticalfor applications, such that they can operate transparently, without interrup-tions nor degradation in the quality of service (QoS). Unlike previous work,we do not focus on the static deployment of cloudlets, but instead, we focuson the dynamic deployment of cloudlets using UAVs.
Mobile, transient and opportunistic computing infrastructures:
Toovercome the scarce distribution of cloudlets, smart devices have been in-vestigated to form a mobile infrastructure to provide computing supporton the edge, for instance, a cluster of smartphones [17]. Indeed, since thecomputational capabilities of smart devices have increased dramatically, itis possible to provision cloudlets through smart devices [15, 10]. Moreover,smart devices can exploit the characteristics of human mobility to move be-tween locations in a transient manner – similar concept has been adopted byMicrosoft Data Box Edge. Thanks to this mobility, multiple devices also canbe co-located opportunistically in a proximal communication range of eachother [18]. As a result, collaborating computing scenarios between devices(mobile crowd) can be envisioned to form an aggregated mobile computinginfrastructure [19, 20]. This also includes IoT devices that are distributedacross the environment [21, 22]. In this type of infrastructure, multiple de-vices merge their individual and constrained computing resources into a sin-gle pool that has higher computing capabilities. A mobile infrastructure canprovision (cloudlet) services on its own or augment static edge and fog de-ployments [23, 24]. While mobile infrastructures are feasible, in practice, itraises many privacy concerns from users’ perspective [19]. To use a mobileinfrastructure, several frameworks to distribute computational tasks amongmultiple devices have been proposed over the years [25, 26, 27]. For in-stance, frameworks for collaborative sensing and computing have been pro-posed [28, 29, 30], as well as frameworks to distribute machine and deeplearning tasks among multiple devices to achieve edge intelligence [10, 31].Unlike other work, we focus on transporting cloudlets with UAVs. Thesecloudlets can be then used to form a mobile infrastructure (micro-data cen-tres) through collaborative processing among UAVs.
Edge computing placement:
Edge computing deployments that are closerto end-devices are emerging with the promise to provide better QoS and QoEor end applications. Edge computing enables the processing of big datarapidly without moving it too far from its source, which in turn improves theperformance of end-devices and applications. Unfortunately, the deploymentof permanent and specialized hardware, e.g., servers, is required to providesuch computing support on the edge. Since the deployment and maintenanceof edge infrastructure has a cost and its capacity to handle computing work-load is limited (a number of concurrent users), its deployment optimizationand resource allocation is an important issue to solve for cloud and mo-bile operator vendors [32, 33]. Consequently, the placement of edge servershas been explored, taking into consideration multiple optimization trade-offs [11, 34]. The allocation of cloudlets as edge servers has been analyzedgiven a budget constraint [35]. Trade-offs between the number of servers anddeployment cost while providing efficient QoS and QoE also have been in-vestigated [36, 37, 38]. Other trade-offs maximize the deployment of serversin a geographical area to ensure edge service coverage [39, 40]. Several otherworks focus on minimizing latency to edge servers while handling differentdynamic workloads of users [39]. The placement of edge servers to reducethe energy consumption of devices also has been studied [41]. Unlike otherworks that focus on optimizing static deployments, we focus on equippingUAVs with cloudlets to transport computation support to the edge dynami-cally. In this manner, edge computing resources can be placed temporally ina location based on the demand of users and then re-allocated easily basedon the characteristic of users’ mobility.
Delivery and cooperation of UAVs:
Applications for UAVs (also knownas drones) are broad and range from autonomous explorations to area map-ping and monitoring [42, 43]. The idea of using UAVs for the delivery ofgoods and services have been explored from commercial [44] and scientific [44]perspectives. Among goods and services delivered by aerial drones, the de-livery of sensitive information [45], networking resources to form a networkin emergency situations [46], and a single micro-cloud [47] have been studied.Several centralized and decentralized architectures for UAVs have been pro-posed over the years [48, 49]. Optimization of trajectories and autonomousnavigation has been explored in detail using different UAV transportationmodalities [50], including ground [51], aerial [52, 53] and underwater [54]modalities. In terms of cooperation between UAVs, models have been de-signed to achieve common goals through cooperation [55, 56], this includesswarm [57], clustering [58] and social [59] cooperation models. Localiza-tion systems for UAVs to achieve cooperative behavior also have been pro-osed [60], e.g., sampling grids [61]. Unlike previous works, we focus onequipping different UAV modalities with cloudlets. We envision cooperationbetween multiple UAVs to create dynamic edge computing infrastructure.We also focus on the delivery and re-allocation of computing resources onthe edge based and on the workload demand of mobile users.
Summary and differences to previous work:
To summarize, pushingcloudlets to the edge to provision services have been explored. Cloudlets instatic infrastructure, e.g., hotspots, have been envisioned in traditional ar-chitectures, and many strategies to place static servers have been developed.Smart and IoT devices to form mobile infrastructures to deploy cloudlets alsohave been investigated. UAVs to deliver cloudlets have been just exploredfor aerial UAVs. In this work, we explore the transportation performanceof computing resources to the edge using aerial, ground, and underwatermodalities. We explore the necessary encasing that needs to be consideredfor each modality. We also explore the cooperation between multiple UAVsto form a computing infrastructure on the edge (micro-data center). In ad-dition, we also study the deployment of edge computing resources to handlethe dynamic workload and its re-allocation based on the mobility demand ofusers.
3. Portable cloudlets: Feasibility analysis
The focus of our work is to investigate the usage of UAVs to transportcloudlets to the edge. Before detailing our methodology, we investigate a fun-damental question to equip UAVs with cloudlets. We examine the feasibilityof using smart and IoT devices as cloudlets. While previous work has demon-strated that these devices have enough resources to execute cloudlet servicessmoothly [15, 10], we analyze further the capacity of smart and IoT devicesto handle the different workload of users when acting as cloudlets. This in-formation is critical to determine whether portable cloudlets can provisioncomputing services to a large number of users. In addition, since the typeof application that is executed by the cloudlet also plays a significant rolein the provisioning of services, we also analyze the performance of differenttypes of applications when running in portable cloudlets.
Since UAVs need to carry a cloudlet from a source location to a targetdestination, it is critical to minimize payload weight and size, while at theame time maximizing the amount of computation capacity that is deliv-ered. Increased computational capabilities and reduced sizes of smart andIoT devices make them suitable candidates to create cloudlets that can beembedded in UAVs. To thoroughly characterize the computational capacityof smart and IoT devices, we conduct rigorous benchmarks that evaluatethe influence of the increasing workload of users on the throughput of thedevices. Moreover, we also analyze the influence of constant workload onthe battery of the resources of devices acting as cloudlets. In our experi-ments, we analyze the computational capacity to handle the workload of twodifferent devices, a Samsung Galaxy S5 (S5) and a Raspberry Pi 4 ModelB (RP4). These devices are selected as the former generalizes computingresources that can be found in common smartphones, whereas the latter isused widely in most IoT prototype solutions. We transform these devices intocloudlets that provide services that can be requested by other users followinga client/server architecture. As a task running by the service, we design acomputing task that provides a constant and uniform response time and alsodepicts resource-intensive processing. By controlling these properties of thetask, we ensured that the benchmark is not influenced by non-deterministiccomputing behavior. The selected task consists of detecting prime numberswithin a list of available numbers. In this context, a client sends a request tothe cloudlet service. As part of the request, the client sends a list of inte-ger numbers, which are within the range of − . The cloudletservice takes the request and identifies the prime numbers in the list, andsends the result back to the client. To analyze multiple clients sending re-quests to the service, we use JMeter to simulate different workloads of users.We use an increasing workload from to users to analyze the capacityof the cloudlets to handle the workload.Figure 1 shows the results of the experiment for both cloudlet S5, andcloudlet RP4. In both cases, we can observe that the response time of therequests increases with an increase in the number of concurrent requests. Inaddition, we also note that S5 provides more constant response time whenhandling the same workload when compared with RP4. We can observethis as the interquartile range of RP4 has a slightly higher slope than S5.In terms of a concurrent number of users, we can observe that Figure 1aindicates that S5 can handle workloads up to concurrent users, while https://jmeter.apache.org/ R e s pon s e ti m e [ i n m illi s ec ond s ] Number of concurrent users (a) Performance of S5 to handle workloads. R e s pon s e ti m e [ i n m illi s ec ond s ] Number of concurrent users (b) Performance of RP4 to handle workloads. B a tt e r y l e v e l [ % ] Number of hours
No serving clientsServing clients (c) Energy consumption of S5 B a tt e r y l e v e l [ % ] Number of hours
No serving clientsServing clients (d) Energy consumption of RP4
Figure 1: Capacity of cloudlets powered by smart and IoT devices. a) Number of concur-rent users handled by a Samsung S5, b) Number of concurrent users handled by a RP4.Battery drain of devices when facing a fixed workload of concurrent users, c) Batterydrain for S5, d) Battery drain for RP4. still providing response time in the range of milliseconds. Similarly, we canobserve Figure 1b, it can be noted that RP4 can handle workloads up to concurrent users with better average response time than S5. In both cases,we can appreciate a reduction in throughput as load increases, which alsoimpacts the overall response time of requests. For instance, we can observethat the response time increases ≈ times when workload increases from to concurrent requests (response time ms and ms respectively)for S5. Similarly, we can observe that response time increases ≈ . timeswhen the workload is increased for RP4 (from to concurrent users).Additionally, since the battery resources of smart and IoT devices arelimited, we analyze how long these resources last when experiencing a fixedorkload of users. We select a fixed workload of concurrent users forthis experiment as for both cases, this is the maximum number of users thatcan be handled by the cloudlets, while still keeping the response time inmilliseconds. With this workload, all the sent requests were completed andcloudlets did not crash due to over load. Figure 1 also shows the result ofthe energy drain for both devices. From the results, we can observe that thebattery of S5 can handle a workload of users for hours (Figure 1c),while RP4 can handle the same workload during just four hours (Figure 1d). Insights:
Our results demonstrate that smart and IoT devices can be usedas cloudlets to provide computing services to users in the wild. The resultsindicate that a single device unit can handle up to concurrent users forat least four hours in the minimum case. This suggests that small and lowweight devices can be integrated dynamically into any environment to over-come the scarcity of edge infrastructure when required. Naturally, the type ofapplication is critical when using portable cloudlets as underlying computinginfrastructure. Computing power is exploited differently based on applica-tion type. In this use case, web services rely on CPU for processing, however,other applications, such as image processing, can exploit GPU hardware ac-celeration to improve performance (See Section 6 for further details aboutrunning image processing in portable cloudlets).
As demonstrated previously, portable cloudlets made from smart and IoTdevices can provide services to a large group of users on the edge. However,another concern in doing this, it’s the quality of service and perception thatusers have towards using the applications run by the cloudlets. Indeed, dif-ferent applications have different computational requirements for providinghigh levels of responsiveness and performance. For instance, the amountof computing resources required by deep learning applications are higherwhen compared with applications that implement simple linear regressionroutines [31]. Thus, cloudlets also have to be selected based on the pro-cessing requirements of applications. On the other hand, to overcome thelimitations of individual cloudlets, it is possible to rely on collaborative pro-cessing dynamically [62, 10, 30]. In this case, the execution of an applicationis distributed among multiple devices. Resource fragmentation plays a majorrole when relying on distributed devices. While it is possible to improve per-formance by aggregating computing resources dynamically [28], computingresources whose processing capabilities differ significantly can easily become bottleneck for applications. This mismatch in processing capabilities cancause applications to slow down their performance and ultimately make themnot usable. S u cce ss r a t e [ % ] Number of concurrent users
YOLOAeneasPocketSphinx (a) Sucess rate A v e r a g e C P U u s a g e [ % ] Number of concurrent users
YoloAeneasPocketSphinx (b) Average CPU usage A v e r a g e M e m o r y u s a g e [ G B ] Number of concurrent users
YoloAeneasPocketSphinx (c) Average memory usage
Figure 2: Benchmark analysis of applications run on RP4
To estimate the processing requirements of applications, a general so-lution is to rely on computing benchmarks [63, 64]. Thus, to analyze theperformance of applications run by portable cloudlets, we conduct furtherexperiments using the DeFog [64] platform. DeFog provides a set of appli-cations to benchmark edge computing deployments, and provides a diversityof applications to measure performance. We analyze the performance ofdifferent types of applications when running in our RP4 cloudlet. As ap-plications, we relied on YOLO (Deep learning for object classification app),PocketSphinx (Speech to text conversion app) and Aeneas (Text and au-dio synchronization app). Figure 2 shows the results, we can observe thatresource intensive applications limit the amount of requests from multipleusers. For instance, the success rate of uses requesting YOLO is lower when igure 3: Classification of applications running on distributed computing resources. compared with Aeneas. In addition, we can also observe that the successrate for handling multiple requests starts to drop as the computing resourcesof RP4 start to become over utilized. This clearly suggests that type of ap-plication also plays an essential role when relying on portable cloudlets. Wecan also appreciate this when analyzing other performance metrics, such asaverage CPU and memory usage (Figure 2b and Figure 2c respectively).
Insights:
To model the performance of the application when executed in adistributed manner, we extrapolate the individual application performance ofour benchmark from single to multiple devices. To do this, we model applica-tion execution depending on the level of resource fragmentation. The level offragmentation is low when devices share similar processing resources (Tight- all devices are the same), and becomes high when resources are too differ-ent (Loose). Our use case of collaborative processing presented in Section 6shows that aggregated processing resources improves overall performance. Inparallel to this, applications experience fewer bottlenecks when resource frag-mentation is low. Thus, the service quality of the application is better whenexecuted on tight resources instead of loose ones. Figure 3 provides an overallview of how resource fragmentation and service quality have to be consid-ered when running different types of applications in portable cloudlets. Forinstance, deep learning applications, e.g., real-time face recognition, requiretight resources to provide a high quality of service (Quadrant II). Likewise,when processing requirements are low, e..g, cache data, and response times not critical (it is asynchronous), resource fragmentation can be then loose(Quadrant IV). Taken together, our results provide insights on how to selectunderlying computing resources to run different types of applications.
4. GEESE design and development
In the previous section, we demonstrate that portable smart and IoTdevices have enough computing capabilities and energy resources to handleheavy computational workloads in the wild. Thus, it is possible to use themas cloudlets. In this section, we introduce GEESE, a novel UAV-based solu-tion to enable the adaptive transportation and placement of edge computinginfrastructure. GEESE delivers cloudlets on demand to any environment toprovide edge computing services to end-applications. These services includeprocessing resource augmentation, data analytics and computational offload-ing. In the following, we first reflect on the limitations of existing architec-tures, and how GEESE can help to overcome the existing issues. Next, wegive an overview of the design of GEESE, where we describe all of its compo-nents. In addition, we also provide implementation details of our proposedsystem.
Existing architectures can rely on cloud and edge based solutions to over-come the issues of big data and resource intensive processing in constraineddevices. However, these solutions have several limitations, which are relatedto dynamic users’ mobility, oscillating communication latency and availabil-ity of deployments. We highlight these limitations in Figure 4. In the figure,we can observe a large group of users moving together (aka mobile crowd),which is a normal and common situation that can be found in everydaylife. For instance, protests and open markets can gather crowds of differentsizes [65]. With social media, and a number of pervasive apps available to sup-port and inform about the activities of the crowd, e.g., material recognitionand air quality monitoring apps [66], it is necessary to support these deviceswith external computing services, such that applications can run smoothlywhile at the same time battery life of devices is preserved. To achieve this, itis possible to rely on cloud and edge computing services while being subjectto several drawbacks.Figure 4a shows that users can connect to the cloud through the cel-lular network, however, the transmission performance may be uncertain as a) Cloud access (b) Edge access(c) UAVs access
Figure 4: A large group of users looking for computation support on the move, a) Usingcellular network to reach remote cloud resources, b) Using Wi-Fi/Bluetooth to accessconstrained edge server in proximity, c) Using the cloudlet support provided by UAVs inproximity. emote communication suffers from oscillating changes of latency. For in-stance, 3G can change drastically from to milliseconds delay [19].Moreover, the communication base station where the group is connected cansuffer from congestion caused by the large number of users connecting to it.Alternatively, edge computing services can be provided to the group as shownin Figure 4b. These services are deployed close to users, e.g., hotspots, suchthat they can connect to it directly using low range communication technolo-gies, e.g., WiFi-Direct and Bluetooth. While this approach provides a moreconsistent quality of service and does not suffer from oscillating latency, it isinstead very difficult to find in the wild. Indeed, the availability of edge de-ployments is not dense enough to be ubiquitous. In addition, edge computingservices cannot scale seamlessly due to their limited resources. As a result,edge services can support a partial amount of users in the group as long asthey are within the communication range. To overcome these issues, UAVscan be used instead to transport cloudlets to the edge. Figure 4c shows theoverall solution. We can observe that the group connects in direct proximityto cloudlets carried by UAVs. Moreover, UAVs can be scheduled or replacedto support the group continuously, and UAVs can also be re-allocated easilyas the group moves. In addition, there is no maintenance and neither de-ployment cost associated with having fixed servers in a location. In the restof this section, we describe the design of GEESE to transport cloudlets tothe edge. Figure 5 describes the overall system design of GEESE. The core compo-nents of GEESE consists of commercial-off-the-shelf UAVs, which are aug-mented with cloudlets. These cloudlets are encased into specially designedcontainers that allow them to be easily transported and protected from ex-ternal damage, e.g., water. We rely on off-the-shelf components to ensure aflexible replacement of components, and to enable rapid prototyping of ap-plications. Off-the-shelf components are essential for large-scale adoption ofUAVs transporting cloudlets. We next describe the cloudlet component thataugments UAVs.
Cloudlet container:
Cloudlet encasing of computing resources is selectedbased on the transportation modality of each UAV. Containers allow UAVs toaugment and replace their computing resources easily just by attaching/de-taching them. For aerial UAVs, we developed a lightweight and shockproofencasing made of carton filled with air pillow bags to reduce impact in case ofn emergency landing. Similarly, ground UAVs also rely on plastic encasingfilled with airbags to fix and protect cloudlets from unexpected turbulence.In the case of underwater UAVs, existing off-the-shelf UAVs solutions in-clude internally, a limited amount of computing resources that are sealed,e.g., PowerVision PowerRay, BlueRobotics ROVs . More advanced solutionsdesigned for marine explorations rely on specialized vessels to accommo-date lightweight payloads. These vessels are also sealed to protect internalresources from water damage. As an example, eFolaga [67] is a torpedo-like underwater UAV that is designed to carry computing resources that aidits navigation and coordination operations. Similarly, other solutions relyon sealed vessels to carry high computing resources that can execute deeplearning underwater [68]. Unlike other work, for underwater UAVs, we usewaterproof containers made of glass to resist water pressure. The reason forusing glass containers is that besides computing resources, we envisioned un-derwater UAVs to augment its functionalities with other resources, such asoptical sensing and communications. Optical-based functionality can easilywork through glass without degrading its performance [69]. Otherwise, it isnecessary to develop new components to handle those functionalities in dif-ferent containers. We also equipped glass containers with an internal cargo(additional weight) to counter the upward force (upthrust/buoyant force)caused due to internal air residing inside the glass container. By doing this,underwater UAVs can navigate submerged. For all the different UAV modal-ities, materials of containers were selected in such a way that they do notinterfere with the wireless communication technologies embedded in smartand IoT devices. At the same time, the selected encasing was chosen to pro-tect cloudlets from adverse conditions of the environment, while minimizingencasing weight as much as possible. Cloudlet computing:
Off-the-shelf UAVs tend to have limited computingcapabilities. For instance, basic hardware is available in UAVs to execute sim-ple routines to avoid burdening their battery resources, e.g., return to homeand navigation tracking. To overcome this limitation, GEESE augmentsprocessing capabilities of UAVs with cloudlets made from smart and IoT de-vices [10]. As described previously, these cloudlets are encased into containersthat act as a separate component to support computing operations, e.g., im-age processing, machine and deep learning operations. Multiple devices can https://bluerobotics.com/igure 5: GEESE System Overview be located inside a container to create a resourceful computing infrastructurevia collaborative processing [30]. While there is a maximum amount of com-puting resources that can be attached to individual UAVs without impactingtheir navigation and battery resources, multiple UAVs can also cooperateby interconnecting their individual computing resources to form an edge-likecomputing infrastructure with higher computing capabilities. Cloudlet communications:
The communication component is also fun-damental to reduce the operational computing burden of individual UAVs.By relying on cyber-foraging techniques that exploit communications [7],underwater UAVs can augment their individual processing resources and ex-tend their battery life by performing collaborative processing among them.GEESE uses off-the-shelf wireless communications to allow devices in prox-imity accessing cloudlet infrastructure carried by UAVs, and maintaining con-tact with remote operators. In addition, computing resources of individualUAVs are also interconnected via wireless to augment the pool of process-ing resources elastically. While GEESE uses wireless effectively to provideprocessing services on the edge, communications with underwater UAVs caninfluence the processing performance of cloudlets. Indeed, underwater UAVscannot rely on standard wireless interfaces when UAVs are submerged toodeep as the wireless signal is absorbed by water (See results in Section 6).Wireless communication can be used in short distance to enable submergedcomponents to intercommunicate, but not for long-range intercommunicationbetween multiple underwater UAVs that are submerged. Instead, UAVs canrely on wireless effectively just when underwater UAVs are floating on theurface. To counter the limitation of communication when underwater UAVsare submerged, GEESE requires to implement additional long-range commu-nication underwater using solutions that can work robustly in underwaterenvironments, such as audio, acoustic, optic or electromagnetic communica-tions [70]. While several works have demonstrated the feasibility of usingthese technologies for long-range underwater communication, there are nooff-the-shelf solutions yet that are mature enough to enable other types ofcommunications underwater. Thus, currently GEESE relies solely on stan-dard wireless technologies.
GEESE is build on top of commercial off-the-shelf UAVs technologies.Our prototype uses PowerRay, PowerEye, Phantom 3, and DFRobot RomeoV2 UAVs. Each of them is a reasonably priced solution (between − euros for PowerRay and PowerEye; and − euros for Phantom 3and DFRobot Romeo V2) to transport cloudlets at low cost. We also usedsmartphones and micro-controllers as processing units for the cloudlets. Inaddition, we rely on the embedded WiFi interfaces of these devices to providecommunication support (See 5 for a detailed description of the apparatusused in our testbed).
5. Experimental setup
We next demonstrate the feasibility of transporting cloudlets to the edgeusing UAVs. In our experimental testbeds (Figure 6), we quantify the batteryconsumption required by UAVs to transport cloudlets, and the performanceof collaborative processing between UAVs carrying cloudlets.
Edge computing infrastructure in the proximity of users is important toimprove the performance of applications and release constrained devices fromprocessing and battery limitations. Existing solutions to overcome theseissues do not provide ubiquitous solutions that fulfill the requirements ofusers’ mobility. As a result, resource-constrained devices have difficultiesoperating in the wild for longer periods and provide good quality of serviceto users. In this experiment, we focus on transporting cloudlets using UAVs,such that it is possible to introduce computing support for devices to anyenvironment dynamically and with ease. Unlike static deployments thatequire continuous maintenance and costly operations, UAVs can foster theadoption of dynamic deployments based on demand and utility cost (pay-as-you-go).
Apparatus:
For aerial UAVs, we rely on measurements obtained from twodifferent drones. We consider a PowerVision PowerEye ( gm), andPhantom-3 drones ( gm). We use PowerVision PowerRay ( gm) asan underwater UAV. Likewise, for our ground UAV, we rely on a DFRobotRomeo V2 ( gm).
Experiments:
We estimate the influence of weight in the operational timeof UAVs. To achieve this, we measure the effort induced in UAV battery con-sumption when UAVs transport cloudlets of different weights. These weightswere encased in their respective container depending on each UAV modality.
Cloudlet weights:
We rely on fixed weights from gm to gm tobenchmark each UAV. We used the same weights in each drone to make ourresults comparable between different modalities. For aerial UAVs, we locatedthe different weights in the shockproof casing made of carton and proceedto lift them from the ground (see Figure 6a). We ensured that the encasedweight was located in the most central region at the bottom of the droneto avoid harming its flying stability. We used weights up to gm in ourtestbed. We did not consider heavier weights as those started to induce prob-lems of stability in the drones, which could lead them to crash and damagethe equipment seriously. In the case of the underwater UAV, we encased eachweight into waterproof containers made of glass (see Figure 7a). We focuson analyzing only transportation underwater, not floating on the water sur-face. Thus, we first neutralize the buoyant force of the waterproof encasingfor cloudlets by adding gm to the glass container. This extra weight isrequired to eliminate the floating caused due to the upthrust force that takesthe glass container to the surface. Existing marine vessels are also designedto compensate this upthrust force. Without this, the underwater UAV drainsenergy three times faster just for sinking the container and keeping it under-water. Once the floating force was neutralized, we then measure the effort ofthe underwater drone to carry waterproof cloudlets from gm to gm(see Figure 6b). Similarly, we encased the same weights ( gm to gm)in protective plastic containers, and located them in our ground UAV (seeFigure 6c). etup:
To take battery drain measurements, we rely on the Vision+ andDJI GO applications for PowerVision, and Phantom drones, respectively.We install the applications on a mobile phone and configure them to connectto the drones via their base stations. Each application provides real-timeinformation about the resources of the drone, e.g., battery, camera. Forunderwater UAVs, we measure the energy consumption of the Power Raydrone with the same Vision+ application that we use for the PowerEye drone.The application has a separate interface for the Power Ray drone, whichcan provide real-time information about the drone’s battery status. Witheach application, we record the battery consumption of each drone whilecarrying different weights. We record energy drain intervals that depict 10%of energy consumption. To do this, we monitor how long the UAV canoperate while carrying the weight in that battery interval. We consider onlyintervals above 50% of energy. For instance, 80% to 70%, 90% to 80%. Wedid not consider other intervals as drones have minimal energy policies tooperate and to avoid emergency landing due to fast energy drained causedby weight. In the case of the ground UAV, there is no available app to takedirect measurements. Thus, to measure energy consumption, we use our ownrechargeable battery pack (7000mAh, 6v). First, we charge the battery packfully with help from the PeakTech Digital Multimeter that is connectedserially to the charging circuit and logged the current flow every second.When the Multimeter shows that there is no current flow in the circuit, itmeans that the battery pack is charged up to its maximum capacity. Thenwe connect the battery pack to the ground UAV, attached 100gm of weight(cloudlet weight), and start running on the ground until the battery drainscompletely. Meanwhile, we measure the operational time also. We repeatthe same experiment for different cloudlet weights from 100gm to 400gm andmeasure the time accordingly. We extract from these measurements, thecorespondent operational time that is possible in a 10% energy consumptioninterval for different weights. https://support.eu.powervision.me/support/home/ a) Aerial UAV cloudlet (b) Underwater UAV cloudlet (c) Ground UAV cloudlet Figure 6: UAVs with cloudlets and different cloudlet encasing for each UAV modality.
A key limitation of edge computing is that it does not scale. Indeed,edge computing resources cannot be augmented dynamically, like its cloudcomputing counterpart. While we have demonstrated that UAVs can trans-port cloudlets to the edge, individual UAVs are still constrained to a staticamount of computing resources. As a result, collaborative approaches tomerge computing resources from different UAVs are critical to augment theamount of computing resources on the edge dynamically. In this experiment,we analyze the performance of collaborative processing to form a dynamicedge computing infrastructure through the cooperation of different types ofUAVs, including aerial, underwater, and ground.
Experiments:
We measure the success rate of job completion from a com-putational task that is executed in a cooperative manner between multipleUAVs. We analyze the processing performance degradation that can occurwhen cloudlets intercommunicate in different environments. While underwa-ter UAVs are envisioned to provide connectivity to the cloudlet by floatingon the water surface, we analyze different underwater situations that caninfluence the collaborative processing between UAVs.
Baseline:
As baseline in our experiments, we rely on MobileNet models [71].We also compared our results with other benchmarks that use MobileNet forcollaborative processing with smart devices [10].
Prototype:
We implemented a proof-of-concept prototype that follows amaster/worker topology, where a worker is an idle device, and the master is aninitiator device that triggers the execution. In our prototype (see Figure 6c),a single device is elected as a master, while the other remaining devices act asorkers. The master is in charge of initiating the task and divide it into jobsbased on the number of available devices. Each job is then sent by the masterto the workers in a round-robin fashion. Jobs are independent of each other.Thus, the success of the application is measured by the rate of completedjobs. Each worker then processes the job, and returns the task promptly tothe master once the task is finished. The master collects the results from theworkers, and merges the processed contributions into a single result. Ourprototype application is developed in Android version 5.0.1 and implementsa Convolutional Neural Network (CNN) model to recognize objects withinimages.
Task:
As the experimental task, we consider object recognition from a video-feed. This task was selected as one single device cannot provide suitableresponse time when processing it. Thus, cooperation among multiple devicesis required to improve the response time. We consider a set of 50 images ina resolution of x , which are collected from the ImageNet . For recog-nizing objects in the images, we rely on a deep learning implementation thatuses TensorFlow with a pre-trained and quantized mobilenet_v1_1.0_224model. To run our application, we rely on LG Nexus 5 devices. Setup:
We evaluate the performance of collaborative processing betweenfour devices acting as cloudlets, where one cloudlet is elected as master, andthe other three are workers. Since wireless signal communication does notpropagate well through water, we analyze the influence of water when per-forming collaborative processing. This means that we analyze when under-water UAVs engage in cooperative processing with aerial and ground UAVs.To this end, we evaluate two scenarios, 1) the master device is underwater,and workers are above the water surface, and 2) workers are underwater,and the master is above the water surface. For both scenarios, we evaluatedifferent underwater depths.
6. ResultsSummary of results • We equipped off-the-shelf UAVs with portable cloudlets encased in special-ized containers. We then measured the energy effort required by UAVs totransport cloudlets to the edge. We found that transporting cloudlets to http://image-net.org/ a) Waterproof encasing (b) Cloudlet cooperation Figure 7: Collaborative processing testbed edge is more energy costly for aerial, followed by underwater, and is leastcostly for ground UAVs.• Our results also indicate that weight is not a representative factor to definethe capacity of computing resources. Indeed, as long as the right combi-nation of aggregated resources is in place, a cloudlet of gm can havebetter processing capabilities when compared with a cloudlet of gm.• We found that a single off-the-shelf UAV can transport a cloudlet of weightup to gm to the edge. This cloudlet can handle the computationalworkload of around concurrent users, and provide an average responsetime of two seconds when processing 10 images in a resolution of x .• We conduct collaborative processing between different types of UAVs car-rying cloudlets. Our results indicate that collaborative processing is evenfeasible with underwater UAVs. Specifically, we found that underwaterUAVs have to be on the surface or at least in a depth no longer than cm, such that the collaborative processing is stable and without disrup-tions. Figure 8 shows the results of delivery performance for aerial, underwater,and ground UAVs. From the figure, we can observe that the flying timeof UAVs decreases as the cloudlet weight increases for both aerial drones.We can observe a significant difference between cloudlets weights of gmand gm. In these cases, the flying time reduces ≈
30% for PowerEye( s to s), and Phantom ( s to s), respectively. Similarly, whenconsidering the operational time of the PowerRay underwater drone, we can T i m e [ i n s ec ond s ] Weight [in grams]
PowerVision PowerEye DronePhatom 3 Drone (a) Aerial UAV T i m e [ i n s ec ond s ] Weight [in grams]
PowerVision PowerRay Drone (b) Underwater UAV T i m e [ i n s ec ond s ] Weight [in grams]
DFRobot Romeo ground V2 (c) Ground UAV
Figure 8: Operational cost in terms of battery consumption for aerial, underwater, andground UAVs when equipped with cloudlets of different weights. bserve that it decreases as the cloudlet weight increases. For instance, whenthe cloudlet weight is gm and gm, the operation time is s and s, respectively. However, the time is significantly high when comparedwith the aerial drones. This indicates that transporting cloudlets to edgeusing underwater UAVs is more energy-costlier than aerial UAVs. In thecase of underwater UAVs carrying cloudlets, it is also important to highlightthat too low or high weight is counterproductive. We find that an emptywaterproof encasing itself reduces the navigation time underwater by .This is because the UAV needs extra effort to keep the empty waterproofencasing underwater. Conversely, the waterproof cloudlet aids the UAV tosave energy when it is on the surface, as it provides extra floating support.In terms of computing capacity and processing performance, while thebattery of UAVs suffers due to the weight attached to the drone, this iscompensated by the actual amount of computing resources that can be trans-ported to the edge. To illustrate this, Table 1 shows the actual weight, whichis translated into the processing capabilities of potential portable cloudlets.From the table, we can observe the weight carried by the drone (Cloudletweight), the amount of resources that match that weight (Encased resources),a quantifiable description of the cloudlet resources (Quantifiable description),and the performance of the computing resources that are transported to theedge (Processing performance). We measure the processing performance byanalyzing the average response time to process a fixed computing task (av-erage response time when processing images). Similarly, we measure thecapacity performance by analyzing the number of concurrent users that canconnect to the resources (No. of concurrent users). From the table, we canobserve that a gm cloudlet can provide computing support to process10 images in . s. In contrast, a gm cloudlet can provide computingsupport to process the same 10 images in s. Naturally, edge comput-ing support powered by cloudlets can be divided into multiple UAVs. Forinstance, two UAVs that are carrying individually a gm cloudlet, canmatch the processing capabilities of a single UAV carrying gm. In addi-tion, we also present a detail description about the computing specificationsof devices used as portable cloudlets in Table 2. Figure 9 shows the performance results of collaborative processing. Weinclude the results of our baseline for comparison purposes. From these re-sults, we can observe that when the number of available devices increases, loudlet weight Encased resources Quantifiable description Processing performanceTime to process No. of10 images concurrent users
Category-1100 gm Type 1 Samsung Active 2 Smart Watches (42gmx2=84gm)
50 seconds 36 to 40Category-2200 gm Type 1 LG g4 + Smart Watch (155gm+42gm=197gm) (160gm) (48gm+113g=161gm)
58 seconds 280 to 300Category-3300 gm Type 1 Samsung Galaxy S5 (140gmx2=280gm)
19 seconds 300 to 320Type 2 Sony Xperia +Samsung Galaxy S5 (160gm+140gm=300gm) (48gmx2+113gm=209gm)
29 seconds 580 to 600Category-4400 gm Type 1 Sony Xperia (160gmx2=320gm) (130gmx3=390gm) (48gmx3+113gmx2=370gm)
Table 1: Estimation of computational power in the form of portable cloudlets that can bedelivered by UAVs the processing time gets shorter. This pattern has been reported by otherworks [10]. Thus, it validates the correctness of our testbed. We also includethe results of the baseline when the smart devices are encased into water-proof containers (encased). As we can observe, the containers (glass) do notsignificantly influence the communication between devices for collaborativeprocessing. For both, baseline and encased setup (with no water), the suc-cess rate of job completion is 100%. In contrast, when the waterproof setupis taken to underwater, the success rate of job completion starts to reduceas the distance between the cloudlets increases. Figure 10 shows the perfor-mance results of collaborative processing underwater at different underwater evice CPU GPU RAM
Samsung Galaxy Active 2Smart Watch Dual-core 1.15 GHz Cortex-A53 Mali-T720 1.5GBLG g4mobile phone Hexa-core (4x1.4 GHz Cortex-A53 & 2x1.8 GHz Cortex-A57) Adreno 418 3GBSony Xperia XZ1 Compactmobile phone Octa-core (4x2.45 GHz Kryo & 4x1.9 GHz Kryo) Adreno 540 4GBRaspberry Pi 4B BCM2711, Quad core Cortex-A72 (ARM v8) 1.5GHz BCM VideoCore VI 4GBSamsung Galaxy S5mobile phone Quad-core 2.5 GHz Krait 400 Adreno 330 2GBLG Nexus 5mobile phone Quad-core 2.3 GHz Krait 400 Adreno 330 2GB
Table 2: Computing specifications of devices used as portable cloudlets that are deliveredby UAVs. depths. The first depth considers distances below the water surface between − cm. Similarly, depth-2 considers distances below the water surface be-tween − cm. We did not consider deeper distances as the collaborativeprocessing degrade to unacceptable levels. Figure 10a shows the results ofsetup, when the master is above the surface, and the workers are underwater.We also included the encased baseline results for comparison purposes. Fromthese results, we can observe that the response time degrades significantlywhen changing from depth-1 to depth-2. Indeed, while the response time indepth-1 degraded, the success rate of job completion achieved 100%. Con-versely, the success rate decays about % at depth-2. Similarly, Figure 10bshows the results of the setup when the workers are above the water surface,and the master in underwater. We can observe that when the master is un-derwater, the setup suffers more from water impact. From the results, wecan observe that when the master is at depth-1, the response time degrades,and also the success rate of job completion decays about %. Moreover,when the master is taken to depth-2, the success rate decays largely about %, and the response time degrades 3x times.
7. Edge delivery model
Since deciding the amount of UAVs that need to be used for cloudlet de-livery is important to use GEESE optimally, in this section, we introduce anedge delivery model that allows GEESE to schedule the delivery of comput-ing resources to the edge. In the following section, we describe the modeland its implementation. We rely on the results from the previous section, toanalyze the transportation of cloudlets in different situations. R e s pon s e ti m e [ i n m illi s ec ond s ] Numbers of workers [in units]
Baseline Encased
Figure 9: Baseline for collaborative processing R e s pon s e ti m e [ i n m illi s ec ond s ] Numbers of workers [in units]
Depth−1 Depth−2 Encased (a) R e s pon s e ti m e [ i n m illi s ec ond s ] Numbers of workers [in units]
Depth−1 Depth−2 Encased (b)
Figure 10: Collaborative processing results, (a) Master device above the water surface andworker devices underwater at different depths, (b) Worker devices device above the watersurface and master device underwater at different depths
Consider a job which is requested for a specific workload ( W ) and averageresponse time ( τ ), the objective of the model is to minimize the allocation ofthe number of UAVs ( U AV ) to satisfy the request. The amount of UAVs isestimated using Linear Programming model [72], which includes the followingparameters:1. ( W ): Workload is defined by the number of users a particular requesthas asked for.2. ( τ ): Defines the minimum response time that needs to be provided fora particular workload.3. C : Represents the set of available cloudlets that can be placed on anAV. An Instance of a particular cloudlet could be two smartwatches ofSamsung used as a cloudlet phones (see Table 1, row 1). Each cloudlethas three characteristics, i) weight of the cloudlet, ii) the amount ofworkload it can satisfy, and iii) the response time it can provide for aspecific workload.4. ⊤ r signify the round trip time that a particular request would need.For example, if a request has been made to the service provider firstfor a location l and later for l , then ⊤ r is the amount of time a UAVshould last for starting its journey from the source location to l , thento l , and finally coming back to the source location. ⊤ r also includesthe time needed for a UAV to stay at locations l and l .To optimize the number of UAVs to be deployed, we need to allocatevarious cloudlets across multiple UAVs such that the overall cloudlets areable to provide at least response time τ for a particular workload W . Themodel tries to minimize the cost by selecting different types of UAVs andthe cloudlets in such a way that it satisfies the requested job. The objectivefunction is defined as the sum of costs associated across all the selected UAVsand cloudlets. M in n X i =1 α i U i + m X j =1 β j C j ! (1)The model consists of the following constraints: m X j =1 C j w j ≥ W r (2)The workload constraint states that the sum of all the workloads acrossall the cloudlets C j ∈ C must be enough to satisfy the workload W r , theworkload requested for a particular job. U n X i =1 U i τ ≤ τ min (3)The response time constraint states that the average sum of all thecloudlets places across all the UAVs must be enough to satisfy the mini-mum response time requested for τ min , where U represents the set of UAVsbeing deployed for a specific job.n addition, each UAV should be able to reach back to the source lo-cation before the consumption of the complete battery. This constraint isrepresented using the total round trip time for each U i ∈ U, and is repre-sented as the follows: l X k =1 U i ⊤ i ≤ ⊤ req , ∀ U i ∈ U (4)The round trip time constraint states that for a particular U i ∈ U , thebatteries of this UAV should be able to travel to multiple locations if requiredand serve the workloads at specific locations and then able to return thesource back before the consumption of the battery of UAV and the totalround trip time required to serve the requests be ⊤ req Implementation:
Our model is implemented in R framework using the lp-SolveAPI package. The overall model contains ≈
100 LoC and can be easilyexecuted by constrained devices without inducing resource-intensive process-ing. GEESE model is the interface for interaction between UAVs and opera-tors that assemble the cloudlet payload of UAVs, such that drones can deliverthe computing resources on the edge. While it is possible to envision a com-plete autonomous end-to-end process, our current GEESE system providesthe first step towards it.
Use case:
To test our model, we consider a simple use case of a mobilecrowd that moves between two different locations. The use case is represen-tative of a common protest that has a start and end points. The situation ispresented in Figure 11. From the figure, we can observe the two locations Aand B. The mobile crowd consists of around users. Initially, the mobilecrowd will gather at location A, and after an hour, the mobile crowd willmove to location B, where it will dissolve after two hours. To support theactivities of end applications in the two locations, it is necessary to deployedge computing infrastructure. In our use case, a remote operator decidesusing GEESE delivery model, the amount of UAVs that are required to trans-port an edge computing infrastructure that can handle the workloads of thelocations. Thus, the remote operator is the one that feds the parametersof the delivery model based on visual inspections of the locations using aremote interface. These types of approaches have been widely adopted by igure 11: Transportation of cloudlets to the edge to handle the workload other systems [73], and can become autonomous simply by integrating crowdcounting approaches, e.g., camera counting [74].
Setup:
As cloudlets that can be transported to the edge. We consider thecloudlets described in Table 1 in Section 6. From the table, we can ob-serve four different categories of cloudlets based on weight. For instance,Category-1 = cloudlets of gm, Category-2 = cloudlets of gm andso on. Each category has different computing resource types that can beencased. For instance, Category-2 has three types. Each type has specificcomputing capabilities and capacity to handle the workload. For example,Category-2, type 1 cloudlet is capable of handling up to 170 users concur-rently. Similarly, Category-2, type 2 cloudlet is capable to handle up to 230users concurrently. We also assigned weights to each UAV modality to depictthat the cost of transporting a cloudlet by each modality is different. Fromour results, we know that aerial UAVs are the costlier, whereas ground UAVsare the cheapest. In addition, we also assume that the remote operator makesthe following considerations for each location. For location A, it is possibleto use any of the three modalities. In contrast, for location B, it is possibleto rely only on aerial and ground UAVs. Lastly, the computing infrastructureto be transported to the edge should handle a minimum workload userswith a maximum response time of two seconds.
Results:
After our delivery model is fed with all the required parameters,e found that for location A, the optimal amount of cloudlets to be deliv-ered includes two ground UAVs of Category-3 type3, and one underwaterUAV Category-2 type2. Similarly, for location B, the required amount ofcloudlets to be transported included, two ground UAVs Category-3 type 2,and one ground UAV Category-4 type2. We also evaluate the transportationof cloudlets when locations are combined. This means that cloudlets arefirst transported to location A, and then re-allocated to location B. In thissituation, our model recommends to relying solely on ground UAVs. Morespecifically, cloudlets to be delivered, include, four ground UAVs in total, twoCategory-3 type2, and two Category-4 type1. It is interesting to notice thataerial UAVs are not selected as the operational cost is very high when com-pared with other UAV modalities. Naturally, there are situations where onlyaerial UAVs can be used. Thus, these results are just tied to this particularcase.
8. Discussion
Naturally, there is room for further work and improvements. We discussa few points here.
Implications for edge computing deployments:
Existing edge com-puting deployments are scarce and far to be dense in the wild. Thus, edgecomputing is not ubiquitous, and applications cannot rely on it in a contin-uous manner. While existing works have explored the placement of physicaledge servers in the wild to cover highly populated areas under many con-straints, e.g., budget and cost, these deployments are powered by cloud andcellular vendors. Thus, end users do not have any control nor can managethe placement of edge servers. Moreover, third party companies that want toprovide services on the edge, they can lease these deployments just to pushsoftware services into the edge, such that these services can be provisioned tousers. In this context, the implications of our work are multiple. First, UAVscan be used to improve the coverage of edge computing deployments in areaswhere currently there is no infrastructure. Second, UAVs can complementcurrent edge deployments and help them to manage the dynamic workloadof users. Third, UAVs can allow third parties to have physical edge infras-tructure without constraints. For instance, an app development companythat has popular app games can schedule UAVs to certain crowded areasto improve the quality of experience of players. Lastly, UAVs can integrateomputing resources to any environment, and even in adverse contexts, e.g.,underwater, jungle.
UAV delivery:
While we are aware that more resourceful UAVs exist fordelivering goods and services, e.g., Amazon Prime Air, and Starship, amongothers, we develop our system with off-the-shelf technologies to enable fasterprototyping. Moreover, off-the-shelf technologies are key to enable solutionsthat can be build based on demand dynamically. In addition, off-the-shelfcomponents are important to facilitate deployments at large-scale. Natu-rally, our results can be easily extrapolated and generalized to other types ofdelivery drones.
Room for improvement:
In our work, we explored the encasing of cloudlets,such that these can be embedded to UAVs. While we rely on encasing materi-als to protect the cloudlets, e.g., waterproof glass containers, other materialscould also be considered. We are interested in exploring new encasing mate-rials that not just allow the transportation of computational resources, butalso allows transportation of other resources, such as sensing resources. Nat-urally, the selection of proper encasing requires further evaluations and totake into consideration new requirements. For instance, the material to en-case sensors does not have to degrade the sensing performance of the sensors.We are also interested in exploring new materials which are lightweight, suchthat the transportation of resources to the edge can be maximized. Lastly,we are also interested in exploring further other approaches to counter theupthrust force for underwater containers. Additional cargo to make underwa-ter containers stable and lightweight are critical points to design off-the-shelfcomponents for underwater UAVs.
Other factors:
We demonstrate in our work that UAVs can be equippedwith cloudlets to deliver computational resources on the edge. While wetook into consideration critical issues about performance, resource allocation,cloudlet weight, and computational capacity of cloudlets, several other factorscan influence the adoption of UAVs in the wild. For instance, operational reg-ulations for UAVs are based on restricted areas and protected regions definedby governmental and military institutions from different countries. Anotherissue is the integration of UAVs with existing legacy technologies, and userinterfaces to manage and schedule easily the delivery operations of UAVs.Moreover, from a user point of view, an additional factor is the perception ofusers towards UAVs operating autonomously and invading public areas forlanding and anchoring.
Edge workload and UAV assistance:
We demonstrate that it is possibleo estimate the amount of UAVs needed to handle a particular workload ofusers on the edge. While edge workload information is easy to extrapolatefrom cellular operator traces and crowdsensing apps, we can also rely onthe cameras integrated within UAVs to perform crowd counting. By doingthis, it is possible to request UAVs when there is a high arrival rate of usersin a location. Thus, besides the UAVs that deliver cloudlets, we envisionadditional UAVs that can assist in the process of estimating and monitoringdifferent properties of the edge workload, e.g., group mobility and number ofusers; such that new UAVs can be scheduled, reallocated or replaced basedon demand.
On cloudlet transportation optimization:
While we present an adap-tive model to transport cloudlets to the edge, several other factors can beconsidered to optimize further the transportation and placement of UAVs.For instance, in our model, we do not take into consideration transportationtrajectories and events that can prevent drones from delivering cloudlets,e.g., close and alternative routes. Another factor that can influence thetransportation of cloudlets is weather conditions. The transportation timeof cloudlets can differ significantly or become unpractical, e.g., storms, snow-falls, and floodings.
Recycling opportunities for e-waste:
Electronic waste from smart de-vices is a global concern as it pollutes natural ecosystems and fosters climatechange. In our work, we demonstrate that UAVs can carry cloudlets madefrom smart and IoT devices. We envision that computing resources from oldphones can be recycled to create portable computing racks, which then canbe transported or deployed on the edge to provide public services to users.For instance, a video streaming service for tourists about the sightseeingplaces in a city.
Composition of computing resources:
While it is possible to collect per-formance metrics about the execution of applications in different underlyinghardware (using computing benchmarks), it is difficult to generalize a solu-tion to obtain an optimal composition of multiple computing resources. De-spite the availability of several methods for optimization, e.g., heuristics [75],the rapid increase of processing capabilities of smart and IoT devices, makesit difficult to explore all possible combinations of devices and available mod-els. In our work, we relied on a computing benchmark to demonstrate thatit is possible to execute different types of applications in portable cloudlets.The optimal composition of those taking into consideration all the differenthardware properties is out of the scope of this work. atural hazards and malfunctions:
Invading natural ecosystems withtechnology that is unknown to wildlife has led to numerous attacks and de-struction towards UAV deployments. One way to overcome this problemis to pre-analyze the predominant species in the target area of the deploy-ment and adapt the UAV behavior accordingly to avoid interrupting wildliferoutines. For instance, drones can be turned off during the night to avoidcolliding with species that hunt during that period. Another solution is toapply camouflage techniques to transform the visual appearance of UAVs toblend with the environment. For instance, UAVs can be designed with fishor bird appearance to become (almost) unnoticeable to others.
Towards autonomous fog:
One important insight that is demonstratedin our work is that computing resources are not just descending to the edgeto be in proximity of users, but it is also possible to grant mobility capa-bilities to the edge through UAVs, such that it can adapt to users mobilitycharacteristics. In this manner, UAVs can adapt the provisioning on edgecomputing resources, such that the quality of experience and service that isperceived by users is consistent. As a result, our work provides a further stepto achieve a computing infrastructure on the edge with fog-like properties.
9. Summary and Conclusions
In this paper, we contribute by designing GEESE, a novel UAV-basedsystem that can transport cloudlets to the edge using different UAV modali-ties. We analyze the effort required by UAVs to deliver cloudlets of differentweights and sizes. We also analyze the challenges of using aerial, groundand underwater UAVs for cloudlet transporation. In addition, we performrigorous resource allocation experiments to estimate the amount of UAVsrequired to handle a dynamic workload of users on the edge. Our resultsindicate the UAVs provide more flexibility and consistency to provision edgecomputing services when compared to other work that focus on static edgeserver placement. Indeed, we demonstrate that UAVs can be easily reallo-cated, replaced, and aggregated on-demand based on workload requirements.We also present the implications of our work for edge server deployments andhighlight the importance of UAVs to achieve scalable services on the edge.
10. References10. References