Soldiers in battle or emergency workers responding to a disaster often find themselves in environments with limited computing resources, rapidly-changing mission requirements, high levels of stress, and limited connectivity, which are often referred to as "tactical edge environments." These types of scenarios make it hard to use mobile software applications that would be of value to a soldier or emergency personnel, including speech and image recognition, natural language processing, and situational awareness, since these computation-intensive tasks take a heavy toll on a mobile device's battery power and computing resources. As part of the Advanced Mobile Systems Initiative at the Carnegie Mellon University Software Engineering Institute (SEI), my research has focused on cyber foraging, which uses discoverable, forward-deployed servers to extend the capabilities of mobile devices by offloading expensive (battery draining) computations to more powerful resources that can be accessed in the cloud, or for staging data particular to a mission. This blog post is the latest installment in a series on how my research uses tactical cloudlets as a strategy for providing infrastructure to support computation offload and data staging at the tactical edge.

Cloudlet-Based Cyber Foraging

Our research--in addition to myself, the team of research includes Sebastian Echeverria, Soumya Simanta, Ben Bradshaw, and James Root--focuses on cloudlet-based cyber foraging. Cloudlets, a concept created by Mahadev Satyanarayanan (Satya) of Carnegie Mellon University's School of Computer Science, are discoverable, generic, stateless servers located in single-hop proximity of mobile devices. Cloudlets can operate in disconnected mode, which means that communication with the central core is only needed for provisioning. They are also virtual-machine (VM) based, which means that they promote flexibility and mobility, a perfect match for edge environments.

Cyber foraging involves dynamically augmenting the computing resources of resource-limited mobile devices by exploiting a fixed computing infrastructure in close proximity. Cyber-foraging allows mobile users to offload computationally-expensive processing (such as face recognition, language translation, speech and image recognition) from a mobile device onto more powerful servers, thereby preserving device battery power and enabling more powerful computing. These capabilities are valuable for soldiers or emergency workers who often operate in tactical edge environments where these resource-intensive applications must be deployed reliably and quickly.

As described in our paper that we recently presented at MilCom2014 (We will update the link when it becomes available), Tactical Cloudlets: Moving Cloud Computing to the Edge, we created the following five different ways of doing cloudlet provisioning:

• In optimized VM synthesis--described in our first blog post in this series, Cloud Computing for the Battlefield--the cloudlet is provisioned from the mobile device at runtime. VM synthesis involves large application overlay files, which can be costly to transfer in terms of battery and network bandwidth consumption in mobile and edge environments. The application overlay is built offline and corresponds to the binary difference between a base VM and that VM after the server portion of an application is installed. After the VM overlay has been transferred, it is applied to the base VM. The result is a complete VM that is running the server portion of the application that is executed from a client running on a mobile device. Due to the large size of the application overlay files, the battery and network bandwidth consumption proved too expensive for mobile and edge environments. As an alternative, we started looking at application virtualization as a possible solution to this problem.
• In Application Virtualization--described in our second blog post, Application Virtualization for Cloudlet-Based Cyber Foraging at the Edge--the cloudlet is also provisioned from the mobile device at runtime. Application virtualization uses an approach similar to operating system (OS) virtualization, by tricking the software into interacting with a virtual rather than the actual environment. A runtime component intercepts all system calls from an application and redirects these to resources inside the virtualized application. The virtualized application that is sent from the mobile device to the cloudlet at runtime is much smaller than an application overlay, but still large for transfer in edge environments.
• In Cached VM, the cloudlet is pre-provisioned with service VMs that correspond to mission-specific capabilities that match the client apps on the mobile device. Each service VM has a unique service identifier.
• In Cloudlet Push, the cloudlet is not only pre-provisioned with service VMs for mission-specific capabilities, but also the corresponding mobile client apps. At runtime, the cloudlet client obtains a list of available applications on the cloudlet, similar to accessing an app store. It then checks if the selected application exists for the mobile device's OS. If so, the cloudlet client receives the app and installs it on the mobile device while the cloudlet server starts the corresponding service VM.
• In On-Demand VM Provisioning, a commercial cloud provisioning tool is used to assemble a service VM at runtime. In this case the cloudlet has access to all the elements for putting together a service VM based on a provisioning script. The experimental prototype uses Puppet, and the provisioning script is a manifest that is written in Puppet's declarative language.

Over the last year, we ran several experiments to help us make a better decision on what we believe is the best cloudlet provisioning mechanism for the edge. We ultimately determined that Cached VM combined with Cloudlet Push, would be the most effective cloudlet provisioning mechanism because using both mechanisms

• enabled lower energy consumption on the mobile device
• placed less requirements on the mobile devices
• simplified provisioning in tactical environments

An added advantage of combining Cached VM and Cloudlet Push is that if the mobile device already has the client app, it can simply invoke the matching service VM; if not, it can obtain the client app from the cloudlet (similar to accessing an app store) and then invoke the matching service VM.

The tradeoff of this approach is that it relies on cloudlets that are pre-provisioned with server capabilities that might be needed for a particular mission. Another tradeoff is that the cloudlet is connected to the enterprise, even if just at deployment time, to obtain the capabilities. To understand how we reached this conclusion, it is important to examine the results of our experiments, which relied on three computation-intensive applications that are often relied upon by soldiers and emergency workers in tactical edge environments:

• facial recognition (FACE)
• speech recognition (SPEECH)
• object recognition (OBJECT)

We used a Galaxy Nexus with Android 4.3 as a mobile device and a Core i7-3960x based server with 32 GB of RAM running Ubuntu 12.04 as the cloudlet. We created a self-contained wireless network (using Wi-Fi 802.11n at 2.4 GHz, 65 Mbps) to be able to isolate network traffic effects. Energy was measured using a power monitor from Monsoon Solutions.

The results of our experiments are shown in Table I below. The first column under each mechanism is the size of the payload in MB that is sent from the mobile device to the cloudlet for provisioning. The second column is application-ready time, measured as the time in seconds from the start of the provisioning process until the cloudlet responds that it is ready. The third column in the energy consumed on the mobile device during application ready time.

To understand how we reached the conclusion that a combination of cached VM and cloudlet push would be the best at tactical cloudlet provisioning, it is important to trace our logic, as well as the steps taken to reach our conclusion.

As Column 1 in the table above illustrates, the problem with VM synthesis is the payload (referred to as the cargo of a data transmission) size, which is large. The payload size is large because the mobile device carries the computation that is going to be offloaded, which proved to be a problem for tactical edge environments.

As many other researchers have noted--and as can be seen in Column 3 under VM synthesis--energy consumption has a linear correlation with the payload size. Communication typically consumes the most battery energy on a mobile device.

From VM Synthesis we turned to Application Virtualization in the hopes that we could address the large payload size problem, which led us to ask, Could we package applications in such a way as to reduce the size of what is transferred from the mobile device to the cloudlet?

Even though Application Virtualization significantly reduced the payload size (from 332 megabytes to 29 megabytes in object recognition) those payloads are still too large to be effective for soldiers in a hostile environment with limited resources and precious few seconds to spare. Under these types of constraints, it is important to ensure that the packaging is done correctly. If not, the application is not going to work.

We took a step back and asked, In edge environments, with the soldiers and first responders that we are targeting, is it always the case that to offload computations, they have to carry the offloadable computation with them? To answer this question, our team of researchers next considered the Cached VM approach. As part of our experiments we pre-previsioned cloudlets with computations that might be expected for a particular mission. This configuration would enable a soldier or first responder to inquire for cloudlets that already have the needed capabilities.

While Cached VM significantly reduced the payload size (almost to zero) as well as application ready time and energy consumption, the approach still presents a problem if a soldier or emergency responder is not able to access a needed application as a result of a changing mission or circumstance. We next experimented with Cloudlet Push. In doing so, we decided to not only pre-provision the cloudlet with service VMs that are needed for a particular mission, but also provision it with the corresponding software client applications for the mobile device, similar to an app store. With cloudlet push, the question asked by the soldier changes from

Do you have this computation?

to

How can you help me? What computation do you have?

Next, we considered On-Demand Provisioning. To use this mechanism, we used a commercial cloud provisioning tool to assemble a service VM at runtime. In this case, the cloudlet has access to all of the elements to put together a service VM based on a provisioning script. Our implementation relied on Puppet and the provisioning script is a manifest that is written in Puppet's declarative language.

The benefits of On-Demand Provisioning include a small payload size, as well as a service VM that can be assembled at runtime. The drawbacks of this mechanism include a longer application-ready time. Also, the cloudlet needs to have all of the required server code components, or access to the components from enterprise repositories or code distribution sites. Overcoming these drawbacks led us to combine Cached VM and Cloudlet Push, which together consume less energy because the payload size is smaller, which in turn leads to shorter and more consistent application-ready times.

Tactical Cloudlets: Future Research

The next quality attribute that we will focus on in our research is trust, in particular trusted identities. For example

As a mobile device, is what I discovered really a friendly cloudlet?

As a cloudlet, did that offloading request really come from a friendly mobile device?

Our current cloudlet implementation relies on the security provided by the network; that is, a mobile device is allowed to interact with a cloudlet according to network policies and permissions. This means that the cloudlet implementation is as secure as the network. While this may be acceptable in many domains, it is likely not enough for tactical environments.

A key aspect of cloudlets is that they are discoverable. The cloudlet client that is installed on a cloudlet-enabled mobile device uses multicast DNS to query for cloudlets (set up as cloudlet services by the discovery service that runs on the cloudlet). Multicast DNS protocols are known to be insecure. However, securing the discovery process is not the problem because port scans or other probing methods can easily bypass discovery.

A common solution for establishing trust between two nodes is to use a third-party, online trusted authority that validates the credentials of the requester or a certificate repository. The characteristics of tactical edge environments do not consistently provide access to that third-party authority or certificate repository, however, because they are disconnected, intermittent, limited (DIL) environments.

Our future research will explore solutions for establishing trusted identities in disconnected environments. Even though the motivation comes from cloudlets, the goal is for the results to be applied to any form of trusted communication between two or more computing nodes. A review of related work shows that this is indeed a challenge, and there are many relevant and interesting ideas, but not very many concrete solutions.

We welcome your feedback on our research. Please leave feedback in the comments section below.

Additional Resources

My previous research in this field focused on cloudlets provisioned using VM synthesis, which was described in the SEI technical note Cloud Computing at the Tactical Edge. To read this technical note, please visit
https://resources.sei.cmu.edu/library/asset-view.cfm?assetID=28021.