One of the key issues encountered in a mobile cloud is the design of intelligent mobility management techniques that support user mobility while providing a seamless service. Although research has been done in location management in wireless networks [51], here, we focus on the methods followed to manage and support mobility in mobile cloud computing systems. Determining a device’s current location is helpful to assess its potential to move away from or towards the active mobile cloud. Work on localization primarily falls into either infrastructure based techniques, or peer-based techniques. Infrastructure based methods use technologies such as GSM, WIFi, ultra-sound with RF, GPS, RFID, and IR. Among these, current GPS very rarely works indoors, and the more accurate techniques need additional infrastructure and need dense deployment of access points as well. Furthermore, these methods are energy consuming and hardly suit the conservative needs of mobile cloud devices. In contrast peer-based techniques are better suited to manage the mobility of participating devices, considering that relative location information is adequate, and most can be implemented with short range low power protocols such as Bluetooth.
Peer based techniques for determining the position of a mobile device. In ‘Escort’ [52], a human localization system using Mobile Phones is presented. Without using GPS or WiFi, the position of a person is inferred using social encounters between users via audio signaling, and monitoring the walking traits of different individuals via phone compasses and accelerometers. Their experiments in parking lots and university premises show that a user can be brought to within 8 m of their target using this technique. Each user’s movement is captured by his/her mobile phone by using its compass and accelerometer, and when it encounters another phone, the encounter is recorded in along with the timestamp. These movement traces are then used to construct a global view of users positions and paths. For example, if A wants to locate B, ‘Escort’ creates a route composed of various encounters. If A had met C recently, and C had met B, the route is first calculated to the point where A met C, then to the place where C met B. Of course, since there could be many possible paths, the ‘Escort’ server will select the optimal one. Although this system deals exclusively with electronic escorting, with the existence of a dedicated ‘Escort server’, the idea behind this localization method can be used to determine the position of a participating mobile node in the mobile cloud. For example, in the case where a delegating device is about to assign work to a worker device, or if it is waiting for results from a worker device, it will be beneficial to know if the aforementioned worker is moving away, i.e., about to disconnect. Not using GPS or WiFi, which are both battery draining methods, is especially useful as well. In the case of ‘Escort’, fixed beacon transmitters placed at random locations are used to correct errors in routing, since they deal with fairly long distance paths. However, for the purpose of mobile cloud, where devices operate in relatively close range, such error correction methods will not be needed.
In ‘Virtual Compass’ [53], short range protocols such as Bluetooth and WiFi are used to construct a two dimensional representation of nearby devices. Peer-to-peer messaging is used to estimate the distance via signal strength, and to pass information about each device’s neighbors and their distances. The latter information makes it possible for devices to gain knowledge about nodes that are beyond the immediate range. In the context of the mobile cloud, this is beneficial to assess the potential of new devices about to join or previous nodes returning to the cloud environment. Furthermore, since communication in the mobile cloud is most likely to happen via short range protocols such as Bluetooth and WiFi (since it uses nearby devices as resource providers), passing information related to this techniques will not necessarily add an extra burden. In fact, localization data can piggy-back on the general cloud communication messages. One challenge in mobile cloud is to trade off between the possibility of energy drain with continuous scanning, opposed to missing out on encountering potential resources without. A solution exists in the method followed in ‘Virtual Compass’, where it employs a self-adaptive scanning technique that regulates its scanning intervals by keeping track of changes in its neighbor graph. This regulation makes use of a central server however, where ideally a decentralized solution is preferable in the context of mobile cloud.
One such decentralized implementation is ‘Friends Radar’ [54], which employs location updates in peer-to-peer fashion using XMPP. Friends Radar differs from the previously discussed systems in that only ‘known’ contacts, or friends’ locations are visible, and that it uses GPS. In a situation where the mobile cloud is comprised opportunistically with random unfamiliar devices, and conducted indoors, this method will fail. However, in cases where all participating devices are pre-known and trusted, such as work sharing among a group of friends for example, and the computation is being done outdoors, this can be viable solution. However, using only known contacts can also be a plus point in terms of privacy and security. As the authors have mentioned, this work would be more applicable in terms of mobile cloud, if it is extended for indoor use using signal strength techniques instead of GPS only.
Similar peer-based localization methods such as NearMe [55], and Beep Beep [56] also exist, but these do not work for more than two nodes. DOLPHIN [57] needs to have special ultrasound hardware, that cannot be expected to exist on a normal phone.
Managing mobility via fault tolerance methods. In [12], the location and the number of surrogate devices are important since the cloud’s objective is to provide support for users with similar goals. They argue that users in similar locations tend to share similar goals. Hence, a context manager tracks potential and existing surrogates corresponding to people moving in groups. Also, the number of devices in the vicinity is needed in the scaling of applications. Using an ad hoc discovery mechanism, a p2p component monitors the resource pool, and notifies the context manager if a change occurs; i.e. new devices come in, or existing ones leave. The authors mention that they hope to use mobility traces to establish ‘communities’ moving together that are stable environments for task distribution. Furthermore, mobility tracking is an important part of fault tolerance. If an unstable node could be identified beforehand, the system could take precautions by promoting task redundancy.
Mobility is one reason in mobile clouds for disconnectivity, and disconnection, similar to hardware failure in a distributed system. In Hyrax [14] disconnectivity arising from the mobile nature of devices is handled through the fault tolerance mechanisms of Hadoop. As given in [40], one of the main assumptions of Hadoop and the HDFS architecture is that ‘hardware failure is common’.
In [58], the availability of a mobile device as a resource provider is determined by its mobility. Hence, devices/users with a high degree of mobility are termed as less reliable due to them being prone to disconnection. To predict the ‘availability status’, recordings of changes in mobile resources over time are used with a Markov chain model. For example, users are classified into three groups: low mobility users, middle mobility users, and high mobility users, and this is used to calculate the probability of mobility. Although this is sound in a contained environment such as a workplace or university, where information about user mobility patterns is known, for a mobile cloud operating in a public area with little or no prior information, this method will not be viable.
Supporting mobility via component and proxy migration. MoCA (Mobile Collaboration Architecture) [59], is a middleware for collaboration on context-aware mobile devices. MoCA currently works with 802.11 and follows the client–server model with a framework for implementing application proxies and basic services for collaborative applications. The servers and proxies run on static networks, while clients run on mobile devices. A proxy acts as the intermediary between the client and server. Here, user mobility is supported by monitoring the locations of the users and switching to an application proxy more suited to the new location. Mobile clients query the service—which contains registered information on available application server proxies—and discover the means to access a collaborative service at their closest proxy. The ‘closest proxy’ is determined by the location of the mobile device which is inferred using its radio frequency signal pattern as done in project RADAR [60]. Measurements gained at predefined reference points are used for comparisons.
Hydra [61] facilitates developing distributed mobile applications in a pervasive environment by the construction of a virtual computer through the participation of a networked set of pervasive computers so that the application satisfies a mobile user’s requirement changes based on location, current tasks and number of people. User mobility is supported by moving the mobile agent based software components to other servers situated along users movement. In cases when components are dependent on each other and the moving of one may affect another, this component migration is carried out by way of ‘hooks’, which dictate two types of policies; either a component will be able to ‘follow’ another, or replicate itself and make the replicate follow. In the second policy, the clone becomes independent of the source component. Which of the two policies to follow is decided on by the component itself. Using RFID, spatial regions such as parts of a room or a building can be identified within a meter. The positions of objects (mobile devices) are identified by identifying these spatial regions that contain them.
In [62], a mobile service cloud based on an overlay-based distributed infrastructure is presented. This is an extension of previous work in Service Clouds [63] where an overlay-based network supports dynamic and on demand prototyping and deployment of services. Here, mobile devices connect to overlay hosts who implement services on the wireless edge. User mobility is handled by migrating the proxy service to different locations following the user. This proxy migration is done to maintain quality of service, minimize resource consumption, and ISP policy which may not allow mobile devices connecting to access points belonging to another provider.
Discussion. A majority of mobile clouds support mobility through component and proxy migration. Although this works for mobile devices connecting to remote servers, it is not a viable mechanism in the following cases; where mobile devices are resource providers themselves and are moving in ad-hoc manner, and where the mobile device offloads tasks to a local resource provider such as a cloudlet. A potential solution for the cloudlet model is to use the same technique as in ‘Follow Me’ [64], a localized and decentralized location sharing system using PlugComputers as Bluetooth scanners. As mentioned in [12] keeping track of other mobile resources moving together with the client to form ‘communities’ is the only solution proposed so far in a mobile cloud of this type, and even that has not yet been fully implemented.
