Local Infrastructure

By far the most common approach to using local infrastructure as a solution to mobile cloud computing comes in the form of Cloudlets, proposed by Satya-narayanan et al [117]. This solution involves placing self-managing cloud in-frastructure in locations near where the user is likely to access cloud services from the mobile device, for example, near the Wi-Fi access point in a coffee shop. The Cloudlet could be integrated with a wireless access point. Not intended to replace large cloud infrastructure in large data centres, the local infrastructure would be minimal. The hardware runs virtualisation software intended to run virtual machines owned by a small number of users. The Cloudlet possesses a "base-VM", which can be modified into a full VM, using what is known as an overlay-VM, by a process known as dynamic VM syn-thesis. The base VM stores the base operating system such as Microsoft Win-dows, and the overlay contains the users applications, profile, and settings.

The overlay is stored on the mobile device, and amounts to roughly 100MB in size. When the mobile user enters the vicinity of the cloudlet, the overlay is sent to the base VM on the cloudlet, to create the full VM. The Cloudlet

per-forms some work for the user, while more complex work (presumably with no real-time requirement), is forwarded to a remote cloud data center.

Cloudlets aim to solve the latency issue in mobile cloud computing. As the Cloudlet should typically be located only one Wi-Fi hop away from the mobile device, the latency would be negligible. Real time applications could then run on the Cloudlet with results received at the mobile device quickly. They also bring in a level of personalisation, allowing the users to have their own custom applications and data stored in the VM-overlay. Drawbacks to this approach include Cloudlets not being available near the vicinity of the mobile device at all times. Additionally, tests show that the time to fully synthesise the VM on the Cloudlet takes roughly between fifty and sixty seconds. However this performance is expected to improve in the future with advances in WLAN bandwidth, and further optimisations to the dynamic VM synthesis process.

Bandwidth may also pose an issue when multiple users are using the same network to access the Cloudlet, especially, as described in the paper, if the Cloudlet is co-located with an ordinary Wi-Fi access point. This approach also faces other significant mobility issues; graceful disconnection, and saving of session state if a user moves away from the Cloudlet, are not discussed.

An OpenStack based implementation of Cloudlets, known as OpenStack++

(OpenStack plus extensions for mobile cloud), has been proposed by Satya-narayanan et al [118], and implemented by Ha and SatyaSatya-narayanan [48]. The OpenStack++ cloud deployed in the remote cloud data center, receiving the complex work offloaded from the Cloudlets, would work with services already deployed in the cloud, but the same mobility concerns remain in terms of mo-bile device access to the local Cloudlets.

Results have shown that optimisations of the Cloudlet approach have been somewhat successful. Verbelen et al [141] modified the definition of the Cloudlet, and developed a minimal dynamic Cloudlet architecture that makes use of any device (such as smartphone or laptop) on a WLAN with avail-able resources, by breaking an application up into several components and distributing these components to the devices. Here several devices in close proximity form the Cloudlet. They communicate via a Node Agent running on each device. The node agent manages Execution Environments running on the devices, which manages the executions of the application components. A Cloudlet Agent, which typically runs on the device with the most available resources in the Cloudlet, manages the Cloudlet and communicates with the

Figure 2.1: Cloudlet Model. Mobile devices are located one Wi-Fi hop away from the Cloudlet, which may be co-located with an access point or router in a public area such as an airport or cafe. A user’s custom VM-overlay on his/her mobile device is combined with a base VM on the Cloudlet to form a full VM.

Complex computation is forwarded to remote cloud infrastructure.

Node Agent running in each device to distribute components. With this ap-proach, timing performance has been shown in some cases to be better than running an entire application on one VM, in certain configurations. The com-ponents can even have specified constraints such as time for completion of processing in individual components. The Cloudlet Agent can then deploy components to devices in the Cloudlet depending on how likely a device with its available resources is able to complete the components work within the constraint.

The use-case carried out in this work for testing was an augmented reality ap-plication. While this approach generated some improvements in performance for some applications where the constraints were met, other aspects of the use-case saw performance degradation where the constraint was not met, and per-formance difference was negligible in other measurements. The augmented re-ality application was developed specifically for this Cloudlet component based architecture, and so other existing applications may also have to be modified for optimal performance on this Cloudlet based architecture as well. R-OSGI

was used to develop the application as a collection of components. The ap-proach is very similar to that of Giurgiu et al [45], which is discussed in section 2.3.2. An issue exists here in the case of the user allowing their device on the WLAN to be part of the Cloudlet. The user of the smartphone with limited battery power, who may not be making the same use of the Cloudlet for tasks as other users, may not want their device to use up battery power for tasks from other people, if it is barely enough for the device’s own resources and tasks. Users need to be incentivised to participate.

A common feature exists in the Cloudlet approach with those highlighted in [124] and [24]. This is the use of virtual machines. The benefits of a local Cloudlet infrastructure here are consistent with [124] in recognising the need for cloud infrastructure to be near the mobile device to minimise latency from RTT. It can be concluded that Cloudlets can be a very viable solution to the net-work latency problem, becoming an enabler of real time applications. How-ever, the overhead of a VM based solution is a large price to pay for simple applications. For example, as shown by experiments conducted by Clinch et al [20], the distance, and resulting RTT and latency between cloud infrastructure and many mobile applications, has little impact on the performance of these applications. As such, the complexity of a Cloudlet approach may not be nec-essary in many cases. In more recent work by Flores et al [37], it was concluded that that few mobile cloud applications exist that are as resource heavy as aug-mented reality applications, again drawing the conclusion that this approach will result in large overhead for most mobile cloud applications. Virtual ma-chines running in the cloud are also not suitable to utilise context information from the mobile device.

Cloudlets, or similar server infrastructures, are said to be network edge solu-tions. This is because the infrastructure is located at the edge of the network closer to host devices such as mobiles, rather than existing in the network core closer to data-centres. The European Telecommunications Standards Institute (ETSI) have proposed the Mobile Edge Computing (MEC) initiative [34], a standard in which mobile edge computing infrastructure will host and pro-vide services that can be utilised by mobile devices. The motivations behind the standard are the same as the goals of the local infrastructure approaches - low latency, high-bandwidth connectivity between the mobile device and the mobile edge infrastructure. The work is considered to be a driver of 5G network connectivity, and if implemented and widely deployed, could avoid the overheads and shortcomings identified with existing local infrastructure

works.

One work which also benefits from local infrastructure, which directly tackles the disconnection problems unlike Cloudlets, is the M2C2 framework by Mi-tra et al [89]. M2C2 is described as a mobility management system. As the mobile user moves through different networks, such as Wi-Fi and 3G, and ad-ditionally, between different basestations while on a cellular network, the user naturally experiences small periods of disconnection. The M2C2 system deter-mines two different choices; one, the choice of best network access interface, based on network conditions, and secondly, the best cloud to use, based also on network conditions, and further cloud VM metrics such as CPU utilisation (ideally, looking for a VM with low CPU load, for example). As the user moves through heterogeneous access networks (HANs), the system uses a probing technique, making calls to RESTful APIs, to determine the quality of each net-work interface. After the interface has been decided, it probes different clouds running the user application (the evaluation experiments were performed with an augmented reality application, which receives location and activity context information from the mobile device), and determines, based on the VM met-rics, which cloud is most likely to meet specified Quality of Service (QoS) guar-antees, and chooses that cloud. The work supports local clouds on the same access network, and public clouds (such as Amazon EC2). Their results point to the same guiding principle of the Cloudlet approach, that clouds near the user are essential for applications with low-latency requirements. Finally, the solution also tackles the disconnection problem by supporting multi-homing, where a device can be connected to two access networks at once; this is for a short time only, while the mobile is moving to a new network, and has cloud connectivity restored to the new access network. The authors measure of suc-cess in this regard is minimal packet loss, which does not have any bearing on the performance of the augmented reality application, as it runs during a han-dover (and the mobile is connected to two networks at once). However, this application works by making hundreds (or thousands as in one experiment) of sequential RESTful API calls, which would be considered a very costly op-eration in mobile cloud computing. No analysis is performed to determine if the benefits of low latency, and choice of low utilisation clouds, has any benefit over the cost of running this algorithm.

Nishio et al [92] take the approach of defining mobile devices in the vicinity, as part of a cloud, similar to the work by Verbelen et al. Here, the authors refer to a cloud of mobile devices as a "local cloud", managed by one elected mobile

node, known as the local resource coordinator (LRC). Mobile devices wishing to complete work (which is defined here as a task requiring resources, which are communications and computation services), request these resources from the local resource coordinator, who then decides which mobile devices in the local cloud can provide these resources as services. These mobile devices then communicate directly. Devices can request resources from others (through the LRC), and share their own as services. This brings again the question of in-centives for mobile devices to share their constrained resources. This work mathematically models the costs for communication and computation shar-ing, as well as optimisation models for task executions. This work is one of few which aims to settle the question of incentives, by means of a fairness measure. Resource usage is modelled as service latency, a time based measure, from when a task starts, to when it is finished. The more a device contributes its resources (depending on if it has resources to spare, which is also considered by the model), the task latency is reduced, and the greater a device is rewarded under the model. How fairness and rewards are defined is not made explic-itly clear, except to assume that a device that shares resources can also share execution of its own tasks with other devices.

Some approaches have attempted to relieve some devices from having to use WLAN or remote cloud infrastructure, and instead use information from other devices in close proximity, one of which may have an active Internet connec-tion to access cloud resources. This formaconnec-tion would be similar to a multi-hop ad-hoc network (MANET). These devices can create an ad-hoc mobile cloud.

One such approach is by Huerta-Canepa and Lee [56]. They call this a "Vir-tual Cloud Provider". The idea behind this approach is that users who share the same environment may be interested in performing the same tasks. The example given was that of users attempting to translate a Korean text descrip-tion of a museum piece. Due to roaming charges, the user does not want to access cloud services, but he/she can obtain the same information from an-other mobile device in close proximity, who already has this information. An ad-hoc network is created between the devices to obtain the information. The implementation involves intercepting application calls to cloud infrastructure, and modifying them to use the virtual cloud provider. It also determines if devices nearby are stable (not moving away out of the vicinity), and resource availability to determine if a task needs to be offloaded to another device. The current implementation yielded results that were slightly slower for tasks than when carrying out the entire task locally without any offloading, although the

majority of the taken time was in the process of processing the tasks to be sent to the virtual cloud providers.

For this approach to work, a device needs to be close to other devices doing the same kind of work. In many cases this is feasible such as in the example given, but in other areas it may not be so. This approach again also brings in the uncertainty as to a user willing to sacrifice some of their own battery power for the tasks of another user in the vicinity. Not only does another device nearby have to be available at the same time, but for the approach to be mutually fair, devices have to be working on the same task with the same information, at the same time.

To summarise, the use of local infrastructure is an approach to mobile cloud computing, where a mobile device uses computing devices nearby to complete work. This can include the Cloudlet approach, with a nearby server, or the modified Cloudlet, which is made up of several devices in the WLAN. This is ideal for applications with real-time, low latency requirements, which will be required for the user experience in terms of performance perception, but the infrastructure is costly for applications not as resource intensive as the com-mon use-case of augmented reality. Bandwidth and mobility concerns remain, as do incentives for user participation when utilising the devices of other users.

As such, Cloudlets at the present time, cannot be considered as a solution for an integrated user experience.