Cloudrone: Micro Clouds in the Sky

Arjuna Sathiaseelan1, Adisorn Lertsinsrubtavee1, Adarsh Jagan S2, Prakash Baskaran2,Jon Crowcroft1

1University of Cambridge,2National Institute of Technology, Trichy

as2330@cam.ac.uk, al773@cam.ac.uk, jac22@cam.ac.uk

ABSTRACTRecent years have witnessed several initiatives on enablingInternet access to the next three billion people. Access to theInternet necessarily translates to access to its services. Thismeans that the goal of providing Internet access requires ac-cess to its critical service infrastructure, which are currentlyhosted in the cloud. However, recent works have pointed outthat the current cloud centric nature of the Internet is a fun-damental barrier for Internet access in rural/remote areas aswell as in developing regions. It is important to explore (lowcost) solutions such as micro cloud infrastructures that canprovide services at the edge of the network (potentially ondemand), right near the users.

In this paper, we present Cloudrone- a preliminary ideaof deploying a lightweight micro cloud infrastructure in thesky using indigenously built low cost drones, single boardcomputers and lightweight Operating System virtualizationtechnologies. Our paper lays out the preliminary ideas onsuch a system that can be instantaneously deployed on de-mand. We describe an initial design of the Cloudrone andprovide a preliminary evaluation of the proposed systemmainly focussed on the scalability issues of supporting mul-tiple services and users.

1. INTRODUCTIONRecent years have witnessed several initiatives on enabling

Internet access to the next three billion people. It is widelyrecognized by all the stakeholders involved in the game ofuniversal service provisioning, that providing access to theInternet has no one size fits all solution for enabling wideruniversal Internet access but requires exploring a variety ofsolutions. This is evident from organizations like Facebookand Google who are on a (noble) mission to connect thenext three billion through novel ways utilizing high altitudeplatforms such as drones, balloons and satellites.

Access to the Internet necessarily translates to access toits services. This means that the goal of providing Internetaccess requires access to its critical service infrastructure,which are currently hosted in the cloud. However, recentworks have pointed out that the current cloud centric natureof the Internet is a fundamental barrier for Internet accessin rural/remote areas as well as in developing regions.

Taking Africa as an example, we recently conducted astudy mapping the African web ecosystem [3]. Our studyhighlighted that majority of the African web infrastructureis placed outside the continent. This has direct impact onaspects of DNS resolution times as well as HTTP page loadtimes causing users to experience higher latencies for down-

loading the webpages and poor quality of experience. Ourpaper concluded that there is a need for localised serviceinfrastructures.

Access to services are also extremely important (even po-tentially life saving) during humanitarian crisis where accessto services are challenged - due to intermittent connectivity,heavy interference and congestion leading to increased la-tencies to global servers or in most cases no access to them.Hence its not rocket science to understand that access tolocalized service infrastructures is of paramount importanceto solve the global access problem.

Recent work on mobile edge computing [9] aims to pushcomputation right at the edge of mobile networks, enablingcomputations at the edge improving latencies and perfor-mance. The recent work on infrastructure mobility [4] illus-trates the interesting concept of making the access infras-tructure mobile thus providing better and much more effi-cient coverage based on the need/demand from the users.So an obvious question or follow up to this exciting idea israther than making the access infrastructure mobile, whycannot build on such work to make the service infrastruc-ture mobile i.e. rather than expecting the users to access thecloud services, why cannot we directly provision the cloudservice infrastructure to the user on demand even in the ab-sence of a terrestrial infrastructure e.g. rural/remote areasor disaster zones?

In this paper, we present Cloudrone- a preliminary ideaof deploying a lightweight micro cloud infrastructure in thesky using indigenously built low cost drones, single boardcomputers and lightweight Operating System virtualizationtechnologies such as unikernels/dockers [7]. Our paper laysout the preliminary ideas on such a system that can be in-stantaneously deployed on demand.

2. CLOUDRONE DESIGNTo enable a lightweight micro cloud infrastructure in the

sky using drones, we bring together a couple of fascinatingrecent innovations in computing: single board computerssuch as the Raspberry PIs (PI) and lightweightOS virtuali-sation technologies such as Dockers1and integrate them withlightweight quadcopters. There were two possibilities for usto build the cloudrone: integrate the PI with an off the shelfready made quadcopter or design and build an entire quad-copter from scratch with the PI powering both the drone aswell as acting as a micro cloud server. We decide to go forthe latter since we wanted to have the drone as lightweightand low cost as possible.

1www.docker.com

arX

iv:1

604.

0824

3v1

[cs

.NI]

27

Apr

201

6

2.1 Building a low cost drone

2.1.1 Designing the droneThere are two main challenges in building a low cost quad-

copter. It has to be light weight yet robust and it has to beeconomical. The cost cannot be controlled on componentssuch as the motors, Electronic Speed Controllers (ESCs) andthe battery. So the focus was on the other two major areas toreduce the cost. The frame and the RC controller. For build-ing the frame, some materials like carbon fiber are light andstrong but they are expensive compared to other materialslike aluminium shafts or high quality reinforced plastic. Theframe of the quadcopter consists of carbon infused plastic,the landing gear is made of light-weight square aluminiumsections fitted with high quality foam sponge balls to with-stand crashes. Four brushless DC motors (1400KV, 800gmsthrust) connected with carbon fibre propellers (8x4.5”) drivethe drone.

The speed of the motors is controlled by four ElectronicSpeed Controllers (Peak Current 30A) with in-built bat-tery eliminator circuits that provide 5V, 2A for poweringup other circuits like the KK2 flight controller board andthe PI. These ESCs are instructed by control signals thatare generated by the output pins of the KK2 flight con-troller board. The KK2 board has a variety of modes tocontrol different UAVs like tricopters, quadcopters, hexa-copters and octocopters easily. So any extension to thecurrent quadcopter design can be easily accommodated andrealised quickly. The KK2 has input pins which are gener-ally connected to RC receivers. But RC transmitters andreceivers tend to be quite expensive and make up a largeportion of the entire cost.

A good quality 4 channel RC transmitter costs more than£200. To build a low cost quadcopter that can act as amicro cloud server, we eliminated the RC transmitter andreceiver entirely and replaced it with the PI. The PI has twoimportant functions i.e., controlling the drone’s movementsand to run micro services. Since controlling the quadcopteris now being done by the PI, it can be programmed to flyautonomously along with manual override. We used the PI2 model B equipped with quad-core ARMv7 CPU 900 MHz.The RAM memory is 1024 MB. It requires power feed about800 mA. The PI runs an ARM version of Ubuntu 14.04. Weused a Edimax WiFi dongle (EW-7811Un) for providing theWiFi interface.

2.1.2 Controlling the droneThe PI generates a portable Wi-Fi Access Point to which

the laptop is connected. A gaming joystick is connected tothe laptop to control the drone manually. By using a pythonmodule called Pygame 2, the joystick emulates an RC trans-mitter with different buttons and 2-axis joysticks, acting ascontrols for roll, pitch, yaw and throttle. A graphical userinterface was also created to monitor the orientation, alti-tude, battery level, GPS co-ordinates.

The PI and the base laptop are connected by a softwareframework called ROS (Robot Operating System) 3 whichsimplifies sending and receiving data with the concepts ofpublishing and subscribing data. Data which may be origi-nating from a controller or from a sensor is published onto a

2http://www.pygame.org/3http://www.ros.org/

“topic”, from which any other component of the entire sys-tem can access it by subscribing to that topic.

In our design, the joystick values are published to a topicwhich is subscribed by the PI. The PI then uses that datato send Pulse Width Modulated control signals to the KK2board. The program that runs on the PI has been designedto give signals exactly as an RC receiver would. So, for theKK2 board the signals appear to be coming from an RCreceiver.

Based on the signal it receives, the KK2 board sends corre-sponding signals to the ESCs, which in turn send the Brush-less DC (BLDC) motors the appropriate currents to changetheir speeds. All the electronics, motors and ESCs are pow-ered using a Lithium Polymer battery (4200mAh 3S 35C).

In order to maintain stability the KK2 implements P-I(Proportional-Integral) controller. The user has to manuallyset values to constants that govern the flight control. In theKK2 board, there are two important constants: P-gain, andI-gain for roll, pitch and yaw. These constant values will bethe same for both roll and pitch owing to symmetry.

Firstly considering only one axis, say roll, setting I-gainto zero, P-gain is increased until the quadcopter producesoscillations periodically. If P-gain is too low, the reaction toroll left or right will be sluggish. If the P-gain is too highthe quadcopter produces high frequency oscillations. Basedon observations, the P-gain is set to an appropriate value.I-gain is then increased to ensure that the quadcopter doesnot drift from the set-point. If I-gain is too high, there willbe a lot of overshoot from the set point and if it is too lowthere will be a lot of drift. The quadcopter will not reachthe set point forever. In order to tune the roll axis, thequadcopter is tied along the pitch axis to two parallel cotswhich act as a stable test rig.

The accelerometers and gyroscopes in the KK2 board arethen calibrated. We place the quadcopter on a tested per-fectly flat surface and run this calibration on the KK2 boardto make sure that the pitch and roll angles are zero whilehovering. The ESCs are then calibrated to start at the sametime. This is done by pressing the Back and Enter buttonssimultaneously while switching on the KK2 board with allthe ESCs connected. The joystick connected to the laptop isset to 100% throttle. The ESCs beep to indicate that theyhave been calibrated.

Propellers, even the high quality ones may have someweight discrepancies which affect the quadcopter’s flightwhen the motors spin at 14,000 RPM. So with a simple bal-ancing test, we find out which side of the propeller is lighterthan the other. To make the weights of both sides of thepropeller equal, we stick cellophane tape on the lighter side.

Similarly to reduce the vibrations generated by the BLDCmotors we first measure the vibrations using an android appand stick cellophane tapes accordingly to all four motors andminimize these vibrations as they can corrupt the values ofthe accelerometer and gyroscope in the KK2 board.

2.1.3 Benchmarking the droneThe quadcopter’s final weight is approximately 1.5 kgs.

The maximum altitude to which it was flown was 50 feet.With the current setup it can fly up to 100 feet theoretically.The effectiveness of the landing gear was also tested. Thequad copter was dropped from a 2-storey building (45 feethigh free fall) and no components were damaged.

The quadcopter’s flight time has been measured in two

(a) Quadcopter components (b) Quadcopter fully assembled (c) Tuning the quadcopter using cot beds

Figure 1: Cloudrone Prototype

different case scenarios. First with a 2200mAh battery with60C discharge rating and then with a 4200mAh 35C battery.The flight duration and the throttle levels vary noticeablyin these two scenarios. When we use the 2200mAh batterythe payload of the quadcopter was bout 50 gms higher thanwhen the 4200mAh battery was used. These are the obser-vations:

• The quadcopter in the first scenario lifts only at 70%throttle level and the flight time is very poor owing tothe smaller capacity of the battery and slightly heavierload. The estimated and realised flight times are onlyaround 2-3 minutes.

• On redesigning certain aspects of the quadcopter tocompensate for the heavier 4200mAh battery, the over-all weight of the quadcopter was reduced by 50 gms.The quadcopter now lifts at 55% throttle and was ableto have sustained flight for over 8 minutes. If a smallerbattery is used in the lighter quadcopter, the perfor-mance is still not as good as using a bigger and highercapacity battery.

• By using a higher mAh rated battery, the flight timecan be further increased to an estimated 15 minutes.

The quadcopter’s CPU consumption was measured dur-ing the flight operation by using sysstat tools. On averageour quadcopter consumes 30% for the flight control of thequadcopter leaving 70% for other processes.

To measure the WiFi coverage of the quadcopter while itwas in the air, we measured the signal strength from var-ious distances (with clear line of sight) using Wigle4. Weobserved signal strengths varying from -65 dBm to -78 dBmwithin the distances 10 to 50 meters north, east and west ofthe direction of the WiFi dongle. South being the directionaway from the dongle had relatively poor coverage (between-75 dBm to -89 dBm). WiFi coverage can be enhanced byusing additional portable lightweight WiFi hotspots that canprovide wider coverage (such as the TP-Link MR3040).

2.2 Integrating the micro cloud with thedrone

Our vision to build a micro cloud infrastructure in theair is to use a swarm of PIs on drones acting as microcloud servers running Dockers enabling us to run severallightweight containers. The lightweight nature of dockercontainers significantly reduce the size of image comparedto the heavyweight VMs [6]. For instance, we can build a

4https://wigle.net

minimal static web server with only 2MB size. This canbe further reduced with new lightweight OS virtualisationtechnologies such as IncludeOS5.

To interconnect the PIs as a swarm/mesh, each of thesedevices also act as mobile routers operating in two WiFicommunication modes: one operates in the WiFi ad-hocmode to allow Optimised Link State Routing (OLSR) pro-tocol, constructing a Mobile Ad hoc Network (MANET) [2];the other operates in the Access Point (AP) mode to allowuser devices to connect with DHCP. The benefit of usingOLSR protocol compared to other MANET routing proto-cols is it uses a special mechanism called Multi-Point Relay(MPR) to reduce the number of flooded messages. Only afew devices that are located in strategically better spatialpositions are chosen to relay (i.e., re-transmit) messages inthe path from a source device to a destination device. TheMPR mechanism helps reduce overall energy consumption.

To create a swarm of micro cloud servers, we use theDocker swarm technology that allows us to create a cluster ofmultiple docker hosts (PI running Docker) and migrate theservice containers across the cluster. Specifically, there aretwo types of nodes classified in the swarm. 1. Swarm man-ager - who manages overall resources (e.g., swarm members,number of running containers) and decides where to placethe service containers. 2. Swarm agent - nodes registeredwith the swarm manager. When the swarm manager andagents are created, they have to register with the discoverybackend as members of the swarm. The discovery backendmaintains an up-to-date list of swarm members and updatesthat list with the swarm manager. The swarm manager usesthis list to assign tasks and schedule the service containersto the agents. To determine where to place the new con-tainer in the swarm, the swarm manager uses either spreador bin packing strategy to compute the rank regarding node’savailable CPU, RAM and the number of running containers.With the spread strategy, the swarm manager gives a prior-ity to the node who has the largest available memory or hasthe minimum number of running containers. On the otherhand, the bin packing strategy tries to pack as many con-tainers to a node until reaching its maximum capacity (e.g.,RAM, CPU). In this sense, a swarm can optimise the numberof nodes running the containers and leave room for futureassignment which may require large space of resources.

2.3 Deploying the CloudroneCloudrone targets to provide localised service infrastruc-

5http://www.includeos.org

ture in challenged network environments. Such scenariosrefer to the emergency and post-disaster situations whereintraditional communication services are completely inopera-ble. An example of Cloudrone’s deployment is illustrated inFigure 2.

A base camp command center with backhaul Internet con-nectivity (e.g., satellite link) is set up close to the affectedarea. A cluster of drones can fly to cover the target area(and could also land), forming a mesh network and providelocalised services to the users (immigrants or post-disastervictims) on the ground via WiFi. A variety of (crucial)services (lightweight docker containers) can be either pre-loaded onto the PI or on demand from the ground. TheMANET of drones, facilitates the swarm manager to com-municate and control the cluster remotely from the basecamp through the long haul link. The swarm manager canupdate the necessary services from the Internet and dissem-inate throughout the cluster.

Figure 2: An example of Cloudrone’s operation

In some operations, the cluster can be out of contact withthe swarm manager (i.e., the target area is far away fromthe command center). To deal with any interruption of ser-vice, we can create a primary swarm manager operating asthe main point of contact and multiple replicas to be thebackup swarm managers. Using this feature, the replicascan seamlessly take over the functionalities from the primaryswarm manager when it fails. If the cluster fails to contactthe primary swarm manager, the most powerful replica au-tomatically takes over the control.

Battery life time is one of the major challenges in ourdeployment, since the flight time is limited to 15 minutes.To mitigate this problem, we envision that the drone caneither fly or land to provide service access. In case, thebattery is low, our drone can decide to land on the groundto save the battery while the docker containers and WiFiaccess point are still operating to provide service access.

3. PRELIMINARY BENCHMARKINGThe preliminary benchmarking presented in this paper fo-

cusses on understanding the scalability issues of lightweightOS virtualisation technology such as Docker on a PI. We fo-cus on two main questions 1) how many Docker containerscan a single PI support? 2) how many user requests can asingle container running on a PI support?

3.1 Scaling up the number of deployed con-tainers within a PI

The first evaluation is to explore the maximum number ofcontainers that could be operated concurrently over a singlePI. To scale up the containers, the docker image could beprepared as small as possible to minimize memory footprint.Consequently, the memory allocation for kernel to handle aweb server process can be optimized. For this, we use anano web server image6 developed in assembly code (size isless than 90 KB (included index.html and a small jpg file)).To benchmark the capability of a PI (PI 2), we base ourevaluation on memory consumption, CPU utilisation andthe creation time (time taken to create a container) by us-ing sysstat, a collection of performance monitoring tools forLinux . In our first attempt, we were able to spin up only 37containers, even though the memory usage and CPU utili-sation were only 40% and 18% respectively. We then hackedthe Docker daemon, to scale up the deployed containers to2408. The procedures that we used is summarised below:

• Tweak docker command: We disabled some docker op-tions that are unnecessary for running a web server.Especially, running with a dedicated IP stack per con-tainer involve a huge resource usage, so we run eachcontainer with net = host. We also disabled log driver(log − driver = none) to let docker use less resources.

• Unlock docker limit: Linux distributions use systemdto start the Docker daemon. We customised some pa-rameters to unlock the limitation of maximum numberof running containers. The number of processes (Lim-itNPROC) and number of queued signals (LimitSIG-PENDING) were set to infinity.

• Tweak docker configuration:With the default configu-ration, docker daemon is run with many options whichis not required for a simple web server such as IPv6,proxies, IP forwarding, log-driver. We disabled allthese options to reduce the memory usage of dockerdaemon.

The results for our optimised docker are depicted in Fig-ure 3 where we were able to scale up the number deployedcontainers to 2408. Specifically, memory usage is a key fac-tor that limits the capability of running the containers ona PI. As shown in Figure 3a, the memory usage increasesgradually when a container is added. The initial memoryusage before creating the first container was about 98 KB(9.89%). We hit the limit of 2408 containers where there isno space for available memory.

Figure 3b shows the average utilisation of the quad-coreCPU of the PI. Over the first thousand of deployed contain-ers, the average CPU usage is very low (about 0.2%) with afew spikes. However as expected, the CPU usage increasessignificantly in the high load state (when the number of con-tainers is larger than 2000). As mentioned in Section 2.1.3,the quadcopter consumes about 30% of CPU resources. Theavailable space can be around 70% which is sufficient to pro-vide multiple services with Docker containers. Hence whenthe quadcopter is flying, we will not be able to have 2408containers running in parallel. However, a Cloudrone canstill support a large number of concurrent containers.

Figure 3c depicts the results of creation time where eachpoint denotes the time it took for the nth container to startup. The creation time for each container varies from 0.62 s

6https://github.com/hypriot/rpi-nano-httpd

0 500 1000 1500 2000 2500

2040

6080

100

Number of containers

Mem

ory

usag

e (%

)

(a) Memory usage

0 500 1000 1500 2000 2500

020

4060

Number of containers

Ave

rage

CP

U u

sage

(%

)

Available CPU (~70%)

(b) CPU usage

0 500 1000 1500 2000 2500

010

2030

Number of containers

Cre

atio

n tim

e (s

)

(c) Creation time

0 500 1000 1500 2000 2500

010

0020

0030

0040

0050

0060

00

Number of containers

Cum

ulat

ive

crea

tion

time

(s)

(d) Cumulative creation time

Figure 3: Number of web servers on a single PI

10 50 100 500 5000

0.0

0.2

0.4

0.6

0.8

1.0

Response time (ms)

CD

F

10 Users50 Users100 Users150 Users200 Users250 Users

(a) CDF response time

10 50 100 150 200 250

Number of users

Ave

rage

CP

U u

sage

(%

)

020

4060

80Available CPU (~70%)

(b) CPU utilization

10 50 100 150 200 250

Number of users

Ave

rage

CP

U lo

ad

0.0

0.2

0.4

0.6

0.8

1.0

1.2

1.4

(c) CPU load

Figure 4: Stress test with multiple requests

to 38.37 s depending on the current CPU load and memoryusage. In addition, we also plot the cumulative creation timeof the 2408 containers (Figure 3d). The PI spent approxi-mately 1 Hr and 50 minutes to spin out 2408 containers. Onaverage each container requires about 2.79 s to start up theweb server.

Key takeaway message: A single PI (PI 2 model B) cansupport significant amount of concurrent lightweight ser-vices.

3.2 Scaling up the number of users accessinga single service

In order to investigate the feasibility of using lightweightcontainers as a platform for the Cloudrone, we aim to eval-uate the scalability of each of these containers running ona single PI while serving a large number of requests. Wedeploy a minimal static web server using httpd docker baseimage using a similar configuration as the experiments in theprevious section. The benchmarking scenario represents theCloudrone’s operation where users on the ground can accessthe services provided by the Cloudrone through a wirelessinterface. Using the Ab - Apache HTTP server benchmark-ing tool7, we conduct stress tests on the Cloudrone whilescaling the number of concurrent users from 10 to 250. Thetotal number of request was set as 10000 transactions per ex-periment. For instance, in case of 10 users, 1000 of requestswere sent by each user. The measured RTT via ping testswith a clear line of sight at 50 feet was between 8ms-10ms.

Figure 4a illustrates the CDF of response time from the

7https://httpd.apache.org/docs/current/programs/ab.html

web container running on PI while varying the number ofsimultaneous users accessing the service. As shown in thefigure, a single deployed docker container is capable of serv-ing a large number of concurrent users. As expected, theaverage response time increases when the number of con-current users is scaled up. Figure 4b and 4c plot the CPUutilisation and CPU load of the PI using sysstat tools. TheCPU utilisation increases almost 20% when the number ofusers increase from 10 to 250. This increases the responsetime for the processes. Even though the utilization has notreached the capacity of CPU, processes still run slower asthe CPU load increases. Figure 4c shows the average CPUload of the PI (sampled in one min intervals). As the arrivalrate of user requests increases, the amount of computationalwork need to process also increases. This has impact on theresponse of time(Figure 4a).

Key takeaway message: A Docker container running on asingle PI (PI 2 model B) can support significant amount ofconcurrent users.

4. DISCUSSION

4.1 Scalability ChallengesOur preliminary benchmarking demonstrates that the

PI is capable of functioning as a great micro cloud plat-form. Our benchmarking was carried out using a lightweightweb server serving a lightweight webpage. It is importantthat the scalability of the Cloudrone should also be testedwith heavier web servers serving applications such as Open-streetmaps. Each application will have different memory

and CPU requirements and hence the number of containersthat can be instantiated will vary depending on the typeof applications which directly influences the size of the con-tainer (e.g., packages, data, library).

Another scalability challenge is to support a larger numberof users within an area. Increasing the number of userscauses an adverse influence on the response time which willcause service degradation. We envision, the different serviceswill be provided by a swarm of drones and hence appropriateload balancing using techniques such as application layeranycast [10] could be used.

4.2 Service RetrievalCloudrones have two main challenges in terms of provid-

ing a reliable service. First, mobility poses a critical chal-lenge. During mobility, ongoing sessions may break andsessions need to be reestablished. Second, considering thedistributed nature of the services across a mesh of drones,identifying the location of the service across a mobile ad-hoc network is challenging. To solve the latter, techniquessuch as Multicast DNS (mDNS) [1] or application layer any-cast could be used [10]. Another potential way to mitigatethe problem of mobility and service discovery is to explorenew architectures that utilise Information Centric Network-ing) [5]. ICN architectures such as Named Data Network-ing (NDN) [5] or SCANDEX [8] decouple the content fromthe location thus removing the need for the current end-to-end client server model such that the service and/or con-tent can be served directly by any host that currently hasthe service/content. ICN thus integrates the provisioning ofcontent with the locationless notion of information deliveryin ICN allowing different flavours of caching, from on-pathcaching to edge caching through a farm of surrogate microservers running on the Cloudrones that can be quickly in-tegrated into the overall (ICN) routing fabric without theneed for DNS redirection or other solutions of the currentInternet. This inherently addresses the issues of mobilityand reliability. As ongoing work, we are in the process ofdeveloping an ICN architecture for Cloudrones via the EUUMOBILE project 8.

4.3 Deployment IssuesAlthough Cloudrones demonstrate excellent potential for

deploying localised service infrastructures in areas where ac-cess to services are crucial but are beyond reach - there arestill major challenges that need to be surmounted.

Drones such as quadcopters have reduced flight times dueto battery life. We envision this situation will change in thenear future with better innovations in battery design andproduction or innovations in alternate sources of power e.g.hydrogen powered drones have flight times upto two hours 9.Cloudrones also need not be in the air for their entire flightduration to provide access to its services. We envision thatCloudrones can be flown to an area and then can provideit’s localised services from the ground (ideally powered byan energy source on the ground).

There are tight regulations in flying drones such as quad-copters. These rules have been laid out by Civil AviationAuthority (in the case of UK)10. Hence these rules should

8http://www.umobile-project.eu/9http://www.bbc.co.uk/news/technology-35890486

10https://www.caa.co.uk/drones/

be adhered to and in some cases may be restrictive e.g. landor fly in a congested area. However, we believe, Cloudronedeployments will fall under the commercial aerial work, andhence special permission from the aviation authority will berequired to fly.

5. CONCLUSIONSIn this paper, we present Cloudrone- a preliminary idea

of deploying a lightweight micro cloud infrastructure in thesky using indigenously built low cost drones, single boardcomputers and lightweight Operating System virtualizationtechnologies. We describe an initial design of the Cloudroneand provide a preliminary evaluation of the proposed sys-tem mainly focussed on the scalability issues of supportingmultiple services and users. As part of future work, we planto conduct large scale evaluation trials benchmarking theCloudrone performance while in the air (in terms of through-put, latencies and energy) across a wide set of scenarios. Weare also in the process of integrating Docker with NDN andperformance benchmarks will be carried out. Finally, thecurrent Cloudrone design does not fly autonomously andhence is strictly limited in terms of distance it can coverwithout manual intervention. As part of future work, weintend to build autonomous flying capabilities.

6. REFERENCES[1] S. Cheshire and M. Krochmal. Multicast DNS.

Internet Engineering Task Force RFC 6762, Feb. 2013.[2] S. Corson and J. Macker. Mobile ad hoc networking

(MANET): routing protocol performance issues andevaluation considerations. Internet Engineering TaskForce RFC 2501, Jan. 1999.

[3] R. Fanou, G. Tyson, P. Francois, and A. Sathiaseelan.Pushing the frontier: Exploring the african webecosystem. In WWW, 2016.

[4] M Gowda, N Roy, and R Choudhury. Infrastructuremobility: A what-if analysis. In HotNets-XIII, 2014.

[5] V. Jacobson, D. Smetters, J. Thornton, M. Plass, N.Briggs, and R. Braynard. Networking named content.In CoNEXT ?09, 2009.

[6] L. Li, T. Tang, and W. Chou. A rest serviceframework for fine-grained resource management incontainer-based cloud. In IEEE CLOUD, June 2015.

[7] A. Madhavapeddy, R. Mortier, C. Rotsos, D. Scott, B.Singh, T. Gazagnaire, S. Smith, S. Hand, and J.Crowcroft. Unikernels: Library operating systems forthe cloud. SIGPLAN Not.,, 48(4):461?472, March2013.

[8] A. Sathiaseelan, L. Wang, A. Aucinas, G. Tyson, andJ. Crowcroft. Scandex: Service centric networking forchallenged decentralised networks. In MobisysDIYNetworking, 2015.

[9] M. Satyanarayanan, P. Bahl, R. Caceres, and N.Davies. The case for vm-based cloudlets in mobilecomputing. IEEE Pervasive Computing, 8(4):14?23,Oct 2009.

[10] E. Zegura, M. Ammar, Z Fei, and S Bhattacharjee.Application-layer anycasting: A server selectionarchitecture and use in a replicated web service.IEEE/ACM Transactions on Networking, vol. 8, no. 4,pp. 455-466, Aug 2000.