TOWARDS MOBILE DEVICE CLOUD Mikko Raatikainen1 , Varvana Myll¨arniemi, Subhamoy Ghosh, Jari P¨aa¨ kk¨o, Tomi M¨annist¨o, Mikko Ylikangas, Olli Korjus, Eero Uusitalo {firstname.lastname}@aalto.fi Aalto University, Finland Niko M¨akitalo, Heikki Peltola, Tommi Mikkonen {firstname.lastname}@tut.fi Tampere University of Technology, Finland Tapani Lepp¨anen, Timo Aaltonen {tapani.leppanen, timo.ta.aaltonen}@nokia.com Nokia Research Center, Finland
Abstract Although cloud computing has established itself as a novel paradigm, mobile devices have unique characteristics and capabilities that are not inherently made part of a cloud. This paper presents the notion of a mobile device cloud: mobile devices become active members in the cloud, sharing content, resources, and services with each other. We discuss how the concepts of cloud computing can be applied to mobile device clouds. Further, a prototype implementation of some key components in a mobile device cloud is presented. Finally, management aspects of mobile device cloud by a means of self-management capabilities are outlined. Keywords: Cloud, Software, Mobile Device.
1
Introduction
A cloud is a term that refers to recent advancement of computing. Various characteristics, such as elasticity of resources [5], or on-demand services [2], are considered central aspects to a cloud. Recently, more synthesized definitions have been provided such as cloud as ”a large pool of easily usable and accessible virtualized resources (such as hardware or development platform and/or services)” [17]; or listing central characteristics to be on-demand self-service, broad network access, resource pooling, rapid elasticity, and measured service [12]. Compared to the traditional server-based model, in cloud computing the resources and services are acquired from a pool termed ”cloud”. The cloud represents and hides the actual servers. The resources and services in a cloud are often associated with high computing power, scalable computing, and large volumes of storage capacity. Much of the research and practice has focused on abilities of the server side, and the client side is treated as an afterthought. Often, the cloud is utilized either by dedicated clients or by browser based simple clients; this kind of client role is convenient for desktop computers. Another recent trend is to provide synchronization or backup services for mobile devices either by device vendors such as in Apple’s iCloud or dedicated service providers for mobile backup. Nevertheless, desktop computing paradigm is becoming outdated; today computers are being more and more replaced by various mobile devices. Despite this, cloud computing treats mobile devices 1
Corresponding author:
[email protected], Aalto University, P.O. Box 19210, FI-00076 Aalto, Finland
Figure 1. How are cloud computing concepts affected when the cloud consists of mobile devices?
as simple PC-like clients or browsers, and scarcely addresses the unique characteristics and capabilities of mobile devices. For example, mobile devices are more and more used to create and share data, such as photos and videos. Also, mobile devices have certain constraints, such as battery usage, that affect their ability to utilize cloud. For example, synchronization services between all content in all devices may not be feasible in mobile context. Similarly, users form communities where they share their content. Further, mobile devices provide computing resources and services drastically different from cloud servers and desktop computers, for example, sensor of ambient light and motion, and location services. Consequently, all the capabilities of mobile devices are not made part of a cloud. That is, although a cloud can basically provide similar resources more flexible and powerful manner as a desktop computer, considering the characteristics and capabilities mobile devices inherently provide, the cloud servers cannot replace them. This paper discusses mobile device clouds, or mobile devices in a cloud in a more active role rather than only utilizing a pool of servers. Section 2 extends the definition of the cloud to incorporate mobile devices. Section 3 describes a prototype mechanism and implementation of storage in a mobile device cloud. Section 4 discusses self-healing challenges peculiar to mobile devices in a cloud. Finally, conclusions and future work directions are outlined in Section 5. 2
Extending the Definition of a Cloud
The essence of cloud computing is delivering computing services over the Internet. However, there are several flavors how this might happen. For example, Software-as-a-Service (SaaS) offers applications and user-accessible services via cloud. Alternatively, infrastructure, such as virtualized computers, storage, and computing power, could also be provided as a service (IaaS). Because of this variety, there have been attempts to classify cloud software; left-hand side of Figure 1 shows one of such ontology [19]. In brief, cloud infrastructure is classified into IaaS, which comprise of computing services; DaaS, which offers data and storage; and CaaS, which is focused on QoS of communications. Further, cloud computing can offer software environments (PaaS), as well as hardware and firmware (HaaS). In this paper, the focus is on mobile device clouds (right-hand side in Figure 1). The devices participating in a mobile device cloud act simultaneously in the client and the server role: the devices share their services and resources among other members in the mobile device cloud. As an example, instead of uploading content to a cloud server, the devices can store the content locally and share it from there. Thus, content is provided as a service similarly as any other resource, such as computing or sensors, can be provided. Another central characteristic is that a mobile device cloud is not necessarily based on location and proximity, like is the case with ad-hoc mobile
networks, but devices subscribe to the cloud on a longer term. Although the ontology shown in Figure 1 is established for traditional cloud computing, it is yet unestablished how it applies to mobile device clouds. In the following, we discuss some constraints in a mobile device cloud. Firstly, mobile devices have certain constraints on network usage, since high-frequency network communication drains battery. In addition, mobile devices are increasingly used for user-generated content (UGC) creation, e.g., photos and video. Hence, traditional model of DaaS, i.e. storing data on a remote server and frequently accessing or synchronizing it from there, does not work so well in multi device environement, since this would require huge amount of network communication. Hence, in a mobile device cloud, an approach that makes sense is to store the content locally on the device, and transfer only small-sized metadata to the server; the actual content can then be retrieved on request. The rationale and model of providing storage is different from DaaS: rather than relying on large and elastic storage capability in the cloud, mobile devices themselves offer storage for content and share content. This aspect is covered in Section 3. In addition to mere content, such as photos, any resource including various sensor data of the device could be utilized as a part of cloud software infrastructure. Secondly, mobile devices may fall in and out of network coverage. Also, devices may run out of battery unexpectedly, or be turned off by the user. Hence, need for various self-management capabilities originating from service oriented computing [15] emerge. Thus service compositions that are built on top of mobile device clouds require self-healing abilities from the cloud software environment (second layer in left-hand side of Figure 1). This aspect is discussed in Section 4. Thirdly, due to the special constraints of mobile device clouds, elasticity becomes a key point. In a mobile device cloud, elasticity is not about scaling up computing but about whether to carry out computing in the mobile device or in the cloud servers. The choice depends on various aspects, such as latency, network bandwidth, and battery usage. The choice needs to be made often dynamically. 3
MIST and VisualREST: Prototype for Sharing Content in a Mobile Device Cloud
Data and storage can be offered via cloud as a service, as discussed in Section 2. Already now there are quite a few alternatives of free DaaS available, such as Amazon Simple Storage Service, Microsoft SkyDrive, and ADrive [1]. However, for mobile devices, there are several limitations, such as availability of the service, replication of content, security of user-data, and resources of the mobile devices. Our approach focuses on developing a Data-as-a-Service and content sharing mechanism for mobile device clouds. The content of a user will reside in the mobile device that created the content, but will be readily available for user’s other devices and even to other users. This mechanism takes into account inherent constraints and properties of the mobile devices. The minimum amount of network traffic shall take place. Nevertheless, the contents residing in a remote device appear to be locally available in the operating device, irrespective of their location in the network. Thus devices in the mobile device cloud become active members, sharing user-created content. An overview of the approach is shown in Figure 2. The design involves a transparent content management system (CMS) that keeps track of the user’s devices and will ensure the availability of the content irrespective of the location in the device cloud. In order to form a device cloud, all devices are required to be registered with the CMS. CMS uses meta-information of content to track the content and also to make content available to other devices. This meta-information includes, for example, content name, type, size, thumbnail,
Figure 2. Members in the mobile device cloud share user-created content via a transparent content management system (CMS) and dedicated middleware (MIST).
date of creation, and date of last modification. Thus, CMS uses the meta-information of the content rather than actual content. The result is that as little data is transferred to and from mobile devices as possible and actual content is transferred only upon request. This is a design decision to focus on mobile device cloud; CMS can be used also to backup or cache content. The CMS will communicate with devices through a middleware, residing in each device of the user. The CMS provides also a generic interface to accessible by web browser or some other means so that design is not dependent on the specific client middleware. The middleware will be responsible for managing all communications between the device and the CMS. For example, the middleware transparently, without user intervention, extracts and pushes all meta-information of a piece of content to the CMS. Respectively, the middleware queries for content located in other devices. The middleware provides a transparent cloud-connection to the otherwise standalone applications in the mobile devices. A content is virtualized on mobile devices, so that irrespective of the actual location of storage, the content is available to a user or other users from different devices. All contents of a user are thus uniformly available over the Internet, irrespective of the physical location of the content in the network. The approach shown in Figure 2 can be used to share content both among several devices owned by one user, as well as among different users. Therefore, the user can set access rights to mark content as personal, that is, available only to the creator; shared, that is, available to a selected group of users in the CMS; or public, meaning available to any user in the CMS. For example, when a user takes photos when the setting is ”personal”, the photos will be accessible only to the user from any of her own device. But if the user writes ”shared” meeting minutes, a specified group of users can access the minutes. The middleware hence allows a controlled access to the content. The implementation of the approach shown in Figure 2 consists of two major components. The first component is VisualREST 2 [11], which is the transparent content management system (CMS). The other component is the middleware named MIST 3 [7] that is deployed in the user’s device. They are discussed in the following. 2 3
Available under MIT license: https://github.com/hpeltola/VisualREST Available under BSD license: http://www.soberit.hut.fi/cloudsoftware
3.1
VisualREST: Transparent CMS Server
VisualREST [11] implements the transparent content management system (CMS) illustrated in Figure 2. VisualREST manages the meta-information of the content, but the actual content resides on the devices. For convenience, content can also be cached to VisualREST. VisualREST categorizes the meta-information into a hierarchy of attributes, that is, into a hierarchy of (name, value) pairs. For each user VisualREST maintains the username as a root element with all her devices as child elements. The meta-information of the contents in each device is represented as child elements of the respective device elements. Such a hierarchy helps to efficiently query and retrieve content for any user. VisualREST provides an interface where a user is first required to register with a unique username and password. A unique device identifier is created for each device. On creating content in the device, the client middleware MIST extracts meta-information from the content and pushes it to VisualREST. VisualREST then places the set of information in the hierarchy as meta-type and meta-value pairs. In response to a user’s query from a mobile device, VisualREST formats the query result following the ATOM Syndication Format [16] and sends it back to MIST as an HTTP response message. The ATOM syndication format is an XML language used for web feed allowing software programs to create and update web resources. The feed contains entries including content related information, web URI to the actual content, user’s permission to access the content, etc. VisualREST has been designed to follow the REST architectural style [3]. REST describes a set of constraints for the software architecture, such as layered client-server style, the uniform interface for all the resources, and the possibility to negotiate a suitable representation for each resource. VisualREST has been deployed on Amazon Elastic Compute Cloud [18]. The hypervized infrastructure provides scalable computing power for VisualREST. The infrastructure also ensures that VisualREST is nearly always available to the user. Thus, CMS in this design will not end up becoming a single point of failure. 3.2
MIST: Device Middleware Component
MIST is the cloud middleware component that resides in a user’s device (see Figure 2). MIST plays multiple roles in the device. Firstly, MIST hides the network activity of the device cloud from the user, and presents a uniform user experience while operating on local as well as remote content. Secondly, MIST identifies and authenticates each mobile device to VisualREST. Thirdly, when user creates content, MIST extracts and pushes all content-related meta-information to VisualREST. Fourthly, MIST enables searching of content from the device cloud: it sends a search query to VisualREST, and receives the search results, that is, meta-information of the content, as a syndication feed. Finally, MIST creates a file-view of content based on the syndication feed received from VisualREST. MIST can operate with known content types, represented as a MIME type [4]. When user creates new content in her device, MIST automatically extracts the meta-information, such as file size, file type, date of last modification, and thumbnails. MIST also adds the access rights of a piece of content into its meta-information. By default the access rights are set to personal, but the user can set the access rights as shared or public. Irrespective of the location, MIST shows all content as files to the user and to the applications. For this purpose, the approach is built on top of FUSE (Filesystem in User SpacE) [6]. A file view, which is basically a file system abstraction through FUSE, is created using the meta-information of
Figure 3. Bubble Browser enables user-centric browsing of content in the mobile device cloud.
the content in VisualREST. That is, for a query of content, VisualREST returns an HTTP response that contains an ATOM Syndication of the list of contents meta-information. On receiving the list of meta-information, MIST presents the contents as a file view through FUSE. That is, MIST operates on meta-information until the file is actually opened. As the user selects any preview of a content, the default application for that content type requests for a file handle similarly to other local contents; the middleware then requests for the actual content from the host location and provides a generic buffer as an abstract file handle to the application; and the application then uses the file handle to display the actual content. The file view using FUSE abstracts away all network activity, including location, and presents the content previews for the user similarly to other local content. Further, the file view allows the default applications in the device to access the content as files, thus enabling them to operate uniformly on both local and remote contents. Thus, even the legacy applications can operate with contents similarly as local contents. As an example scenario, a user can query all photos from all of her devices. The photos are represented using meta-information using FUSE until she uses photo viewer application to see a specific photo. When user wishes to open the content, MIST sends an HTTP GET request to VisualREST. VisualREST forwards the URI of the content as an XMPP notification to the device hosting the content. The MIST running in host device returns an HTTP Response to VisualREST with the content as a multipart/form-data. VisualREST forwards the content to the MIST in the user’s device. MIST then provides content in a temporary buffer to the viewer application. FUSE also provides a means to represent content temporarily; nothing is downloaded permanently unless explicitly specified but rather content in FUSE disappers once FUSE is unmounted. In our implementation the content sharing mechanism by default only pushes the meta-information to the CMS while the actual content resides in the device. However a user can sometimes cache to the CMS a set of contents that are frequently accessed by many users. This will improve the response time and optimize the use of bandwidth and battery life for the host device. Again a user might temporarily disconnect her device from the Internet; the cached contents will still be accessible to the users even though the host device is disconnected. MIST consist of two key subsystems. The Uploader subsystem is responsible for extracting metainformation of the created content and uploading the extracted meta-information to VisualREST. Current implementation watches a specific folder in the file system and whenever new content is added to the folder, the meta-data is extracted and uploaded to VisualREST using the defined access rights. The MaemoFuse subsystem takes care of fetching the information of specified contents from the VisualRest server as an Atom feed. This information is then used to mount the specified context in the local file system as a directory, where the files of the context are available. MaemoFuse uses FUSE file view to show the content.
3.3
Bubble Browser: Browsing Content in the Device Cloud
With the approach described above, several users can easily share content from multiple mobile devices. However, as users create more and more content and the volume of shared content increases, it becomes a burden for the user to find relevant content. For this purpose, we have implemented accessory to complement MIST and VisualREST. The accessory is a user-centric browser interface, named Bubble Browser, which classifies the content along archetypes that are intuitive for the user (see Figure 3). It should be noted that Bubble Browser implements browsing paradigm rather than search paradigm. We consider browse and search paradigm somewhat separate but complementing each other so that both are needed. However, search paradigm is out of the scope of this work and reader is advised to see other related work such as [10]. We identified four generic archetypes to classify content: People, Places, Dates, and Events. We believe that content shared in a mobile device cloud can be associated into some or even all of these archetypes. Using these intuitive archetypes, it is easier for the users to find for a piece of content, rather than using only text-based searches based on, for example, content names or such similar content meta-information. Bubble Browser clusters the content along with these four archetypes; each cluster, or bubble, represents a unique query with distinct query parameters. The VisualREST information hierarchy can easily cluster appropriate meta-information to be used by Bubble Browser. To ease browsing, we designed a touch-only interface, requiring no text input from the user. Four archetypes arrange the content meta-information as bubbles. In Figure 3, the first screen shows the different archetypes as mentioned above; a user can always converge the search space by selecting one of them. The second screen in Figure 3 classifies content as individual bubbles, or clusters of related meta-information. The most relevant bubble is shown in the center of the screen; the bubbles also show as much preview of most relevant content as possible so that zooming a bubble reveals more information. When the user selects one of the bubbles, the third screen in Figure 3 shows previews of the contents within that cluster. Thereafter, the desired content can be fetched using the mechanism explained earlier in Section 3.2. 4
Self-Healing Compositions: Cloud Software Environment for Mobile Device Clouds
While the previous section described a prototype implementation for sharing content in a mobile device cloud, this section outlines further challenges related to mobile device clouds and proposes solutions for these challenges based on research in autonomic computing and service-oriented computing. As discussed in Section 2, mobile device clouds emphasize certain aspects differently than traditional desktop computers and cloud servers. For instance, mobile devices can provide storage, sensors and other computing resources as services in the device cloud, giving rise to complex composite applications. Consequently, concepts identified in service-oriented computing management [14] become important in a mobile device cloud. The environment consisting of mobile devices is very dynamic by its nature. In other words, the mobile devices move in and out of the environment posing challenges to the availability of services provided by the devices. In addition, mobile devices have limited battery life and other resource constraints that pose additional challenges for a device cloud. These challenges, thus, complicate the management of service compositions in a device cloud. Quite soon, the management of such an environment exceeds human capabilities [8]. In order to overcome these challenges, the device cloud can employ self-management concepts first
introduced in autonomic computing [8] and later also identified as a research challenge in serviceoriented computing [15]. The basic idea of self-management is that systems manage themselves given high-level objectives, thus, relieving administrators from the burden of having to manage the systems [8]. Self-management properties in service-oriented computing include self-healing, self-optimization, self-configuration, self-adaptation and self-protection [15]. In a mobile device cloud, self-management of service compositions falls into the Cloud Software Environment category (second layer from top in Figure 1). This is because self-management techniques provide support and APIs for service developers and service composers alike. The provision of self-management capabilities by the device cloud can help to improve, e.g., the quality of service and reliability of the services provided by the devices. For instance, self-healing provides a means for automatically discovering, diagnosing and recovering from faults, e.g., by replacing services and resources that are not available or do not fulfill the agreed quality of service requirements [13]. Self-optimizing services, on the other hand, can optimize the use of resources automatically in order to improve the performance and efficiency of the provided services. Self-healing service compositions in the device cloud is described in [13]. The main contribution is a software architecture that can be used to design and create systems for supporting self-healing service compositions. The software architecture describes how machine intelligence can be used to support the validity of existing service compositions. Firstly, the architecture employs modelbased diagnosis for the diagnosis of faulty service compositions. Secondly, the architecture uses concepts from configurable software product families together with recommendation techniques in order to derive new valid service composition configurations. Furthermore, due to special characteristics and constraints of mobile devices, elasticity in a device cloud becomes an essential research area. In traditional cloud computing, elasticity is, e.g., about scaling computing power according to the load or needs. However, in a device cloud, elasticity is concerned with whether to carry out the computation in the mobile device itself or in the cloud servers. Various constraints affect the decision including latency, network bandwidth, and battery usage but also quality of computing. For example, servers of cloud can provide better quality answers to computing problems because of better algorithms besides providing more computing power. Therefore, despite being similar, elasticity in mobile device cloud differs from, e.g., cyber foraging [9], being relatively multifaceted problem. Elasticity is closely related to self-management, since the services need to use intelligent means to derive a decision about where to perform the computation. For instance, self-optimization in autonomic computing is also concerned with automatically tuning the resources in order to use the available resources as efficiently as possible [8, 15]. Therefore, research on elasticity can draw from ideas on self-optimizing systems research. The idea is not to include the logic for managing contingencies and making decisions necessary for self-management in the services and applications themselves, but rather to provide selfmanagement capabilities as a part of the device cloud. This requires the creation of models that can be used for inferring about the behavior of services as well as guidelines for how to create services that can be self-managed by the device cloud. Finally, self-management capabilities may affect mobile device cloud infrastructure as whole. For example, CMS server (see Figure 2) can take an active role in providing feedback to the user about whether a resource is available, reason for unavailability, and estimated time to availability. In addition, since mobile devices have limited resources, the servers can be active in providing the actual self-management functionality to the devices.
5
Conclusions and Future Work
In this paper, we have discussed cloud software in the context of mobile devices. In particular, we presented the notion of a mobile device cloud: instead of being mere clients providing an access point to cloud servers, mobile devices become active members of the mobile device cloud. Further, we discussed the peculiar characteristics and constraints that mobile devices within a cloud have. As first steps towards a mobile device cloud, we have presented an approach how mobile devices can seamlessly be made members of the cloud. The approach is based on architectural principles, such as not requiring any content be transferred away from the device, hiding the cloud access details from the legacy applications running in the device, and building the user’s view to the cloud from the perspective of user exprience rather than that of technical implementation. We concretized the approach by presenting several implementations as the basic components of a mobile device cloud. We discussed implementation of MIST as a content sharing mechanism and Data-as-aService for mobile device clouds, along with a user-centric browsing application for mobile device cloud content, named Bubble Browser. Beyond the basic implementation, we also discussed selfmanagement and self-healing of service compositions in the mobile device cloud. However, there are several areas that require further research. A mobile device cloud is ultimately intended to be a massive constellation of devices and content. As the first steps towards the larger scale, Bubble Browser incorporates means for supporting the user conception of the cloud as something different from a local file system. However, many inherent characteristics of the large scale, such as issues with availability and latency, still require additional research effort. Similarly, the extension from content to other resources of devices, e.g., camera and microphone, and elasticity of computation should be studied further. Dealing with this complexity requires more advanced self-management capabilities of the service compositions, thus continuing research from the selfhealing proposed in this paper. References 1. Cachin, C., Keidar, I., and Shraer, A. Trusting the Cloud. SIGACT News 40, 2 (2009), 81–86. 2. de Haaff, B. Cloud Computing - The Jargon is Back! Cloud Computing Journal (2008). 3. Fielding, R. T. REST: Architectural Styles and the Design of Network-based Software Architectures. PhD thesis, University of California, Irvine, 2000. 4. Freed, N. Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types. Tech. rep., Internet Assigned Numbers Authority (IANA), 1996. 5. Geelan, J. Twenty-One Experts Define Cloud Computing. Virtualization (2008). 6. Ghosh, S. An Approach to Seamlessly Cloudify User-Generated Content from Mobile Devices. Master’s thesis, Aalto University, 2011. 7. Ghosh, S., Savolainen, J., Raatikainen, M., and M¨annist¨o, T. Cloudifying User-Created Content for Existing Applications in Mobile Devices. In Proceedings of the IEEE 35th Annual Computer Software and Applications Conference (2011), vol. 1, IEEE, pp. 510–515. 8. Kephart, J. O., and Chess, D. M. The Vision of Autonomic Computing. Computer 36, 1 (2003), 41–50. 9. Kristensen, M. D., and Bouvin, N. O. Scheduling and development support in the scavenger cyber foraging system. Pervasive Mob. Comput. 6 (December 2010), 677–692. 10. Lagerspetz, E., Tarkoma, S., and Lindholm, T. Dessy: Demonstrating mobile search and synchronization. In Proceedings of the 2010 Eleventh International Conference on Mobile Data Management (Washington, DC, USA, 2010), MDM ’10, IEEE Computer Society, pp. 284– 286.
11. M¨akitalo, N., Peltola, H., Salo, J., and Turto, T. VisualREST: A Content Management System for Cloud Computing Environment. In Proceedings of the 37th Euromicro Conference on Software Engineering and Advanced Applications (2011). 12. Mell, P., and Grance, T. The NIST definition of cloud computing. National Institute of Standards and Technology 53, 6 (2009). 13. P¨aa¨ kk¨o, J. A Software Architecture for Supporting Self-Healing Service Compositions. Master’s thesis, Aalto University, 2011. 14. Papazoglou, M., and Georgakopoulos, D. Service-Oriented Computing. Communications of the ACM 46, 10 (2003), 25–28. 15. Papazoglou, M., Traverso, P., Dustdar, S., and Leymann, F. Service-Oriented Computing: A Research Roadmap. International Journal of Cooperative Information Systems 17, 2 (2008), 223–255. 16. Sayre, R. Atom: The Standard in Syndication. IEEE Internet Computing 9, 4 (2005), 71–78. 17. Vaquero, L. M., Rodero-Merino, L., Caceres, J., and Lindner, M. A Break in the Clouds: Towards a Cloud Definition. SIGCOMM Comput. Commun. Rev. 39, 1 (2009), 50–55. 18. Walker, E. Benchmarking Amazon EC2 for High-Performance Scientific Computing. USENIX Login 33, 5 (2008), 18–23. 19. Youseff, L., Butrico, M., and Da Silva, D. Towards a Unified Ontology of Cloud Computing. In Grid Computing Environments Workshop (2008).
