New priorities for Mobile cloud computing – but all the choices are still painful
Mon 2 Nov 2015
Establishing viable models and solutions for Mobile Cloud Computing (MCC) is like trying to paint a sunset in a car wash. The environment, variables, requirements, capabilities…even the imperative motivations, all change so often as to make the field amongst the most ductile of academic and technological areas of cloud research.
In spite of this a new paper, Analysis of the Energy-Performance Tradeoff for Delayed Mobile Offloading [PDF] emerges from the Institute for Computer Science at the University of Berlin, freshening up a subject that was so comprehensively addressed in the occasionally updated Mobile cloud computing: A survey, [PDF] by Niroshinie Fernando et al. at Australia’s La Trobe University.
The Berlin paper reiterates the problem and the prognosis: there is demand to run more CPU-intensive applications on mobile devices without depleting the battery charge with all the extra compute cycles that the device has to run, or in general exceeding the capabilities of a ‘slimline’ mobile CPU array.
So much for the corporate IT department trying to facilitate remote procedure calls to a 4-gig database in a private cloud, the scientists on a field trip, the land surveyors and the hippy CGI artists who want to work under a tree.
From the point of view of device manufacturers, the proposition is one of off-loading to the cloud a large proportion of the activity already happening in the mobile and small form-factor space in order for battery life to receive a massive improvement, with devices supplying the same functionality as practically dumb terminals, ‘simply’ for an increase in traffic.
Regarding any one country’s particular infrastructural restrictions and parameters (such as network coverage and the various protocols by which it is provided), any currently-offered potential solutions for widespread Mobile Cloud Computing scenarios would inevitably be too ‘bespoke’ for global tech players to consider serious investment. Therefore the Berlin researchers restrict themselves to the most basic of problems – the way in which MCC-enabled apps and services make choices between local and cloud-based computing cycles – whether the applications in question have actually been rewritten for MCC or are existing apps deployed within on-the-fly global/remote VMs.
The ‘impatient queue’ in the MCC scenario
The Berlin paper uses queuing theory to model systems capable of offloading tasks arbitrarily via a new metric called Energy-Response time Weighted Product (ERWP), which calculates the mean network response time against mean energy consumption for the task required, trading off power consumption against latency as necessary, and using ‘impatience timers’ as deciding factors in whether a cycle will be run locally or in the cloud.
‘When in the slow phase, jobs become impatient. A reneging [deadline] is associated with each job in this phase. That is, each job, upon arrival, activates an individual ‘impatience timer’, exponentially distributed with an reneging rate…If the system does not change its environment from the slow phase to the fast phase before the deadline expires, the job will be removed from the Offload Queue and is assumed to be executed locally on the mobile device rather than offloaded to the cloud.’
The research considers a ‘partial offloading model’ for MCC tasks along with a ‘full offloading model’ based on WiFi network availability – the most dependable possible network likely to be available to the device, and the one with an average latency that’s responsive enough to ensure against excessive ‘defaulting to local resources’.
The researchers’ partial offloading model is suited to tasks which can be anticipated based on current user activity, since its cycles are not immediately required, but its low energy consumption footprint comes at the cost of latency. The paper concludes ‘in general one can say that the partial offloading policy is faster, while the full policy uses less energy.’
Three (almost) equally bad network entries for mobile cloud computing
The efforts of various MCC research groups in recent years have been split between the three primary likely available network resources to which high-end ‘thin’ mobile apps might push tasks to the cloud. By far the most popular is WiFi, which has a lower energy consumption rate than 3G and considerably wider range than Bluetooth. Notwithstanding that WiFi is the least ‘mobile’ and available of the three likely network entry points, MCC projects which presume upon it include Cuckoo, which uses Java to push cycles from smartphones to remote cloud resources such as EC2 compute instances, but which also has implementations for Bluetooth and 3G.
3G itself has the advantage of almost ubiquitous coverage, but suffers from poor performance, high energy consumption, limited bandwidth and efficiency-killing round-trip times. Nonetheless Microsoft’s MAUI [PDF] MCC architecture utilises 3G as well as WiFi.
Bluetooth is the golden boy of possible MCC network entry points, with the lowest power consumption and mature diffusion in comparison to other protocols. Unfortunately its 10-metre range makes it more suitable to hooking up to ‘cloudlets’ (local access points, in effect proxies for better connection methods than Bluetooth) or to ‘virtual resource clouds’ composed of local devices which have agreed to share information with other local devices, therefore daisy-chaining a series of low-reach Bluetooth connections. In April MMPI, a ‘message passing interface for the mobile environment’ was proposed, for an economic MCC utilisation of Bluetooth’s limited skill-set.
VM Migration – the future of mobile cloud computing?
Fernando identifies three viable models for MCC offloading, but they all have their problems. The client-server communication model, which takes in frameworks such as Cuckoo, Hyrax and Spectra, is stable but reliant on continuous network connection. The ‘mobile agents’ model, essentially cyber foraging applications which utilise locally found resources such as cooperative smartphones, has significant security implications to overcome.
The third model, Virtualisation, seems to be the practical future of mobile cloud computing, since it obviates all need for MCC-specific code rewrites and therefore provides absolute transparency of use – and the virtual machine’s boundaries protect the host server. Negatively, VM synthesis can be time-consuming as a truly ‘on-the-fly’ operation, and there remain compatibility issues between VM overlays. But it seems – at least at the moment – that the shortest route to effective and global models for mobile cloud computing are via the VM route.
Which still begs the question, ‘Where can I connect..?’