Providing Local Cloud Services to Mobile Devices with ... - IEEE Xplore

17th IEEE Mediterranean Electrotechnical Conference, Beirut, Lebanon, 13-16 April 2014.

Providing Local Cloud Services to Mobile Devices with Inter-cloudlet Communication JeanMarc Rawadi, Hassan Artail, and Haidar Safa* Electrical and Computer Engineering Department *Computer Science Department

American University of Beirut, Beirut, Lebanon {jrr02, hartail, hs33} @ aub.edu.lb Abstract—The importance of mobility has influenced the emergence of several mobile computing frameworks, one of which is cloud computing. In this paper, we propose a design for a system that allows mobile users to access discoverable cloudlet servers which can provide them with services and resources on demand. The system involves a cloudlet root server that acts as a directory with which cloudlets register their presence and offered resources, and to which users may direct their requests for mobile services. Cloudlets communicate in order to service the user’s requests, by either delegating these requests or by breaking requests into tasks and working on them cooperatively. We provide an experimental evaluation for measuring the delay of user requests and the load on the cloudlets under different scenarios. The results are promising. Index Terms— Cloud computing; computing; mobile computing

cloudlets;

service

I. INTRODUCTION

C

omputational offloading led to the emergence of mobile cloud computing that allows users to tap into the cloud infrastructure and use its resources on-demand to carry out their resource intensive applications. Mobile user requests are normally sent to the user’s mobile network operator, and then delivered to the cloud via the Internet. This process requires a WAN which can hinder the performance of cloud computing relying on distant clouds due to WAN-induced latencies, and hence the initiative behind cloudlets. Like clouds, cloudlets provide services such as storage, software, data, infrastructure, and other services that may be added when they are developed. They are typically connected to Local Area Networks (LANs) or even to Wireless LANs, and therefore they provide a better user experience in terms of interactive response [12]. Cloudlets differ from clouds in that they can be transient (i.e., can go online or offline without much restriction) and do not have to be built upon high performance computer hardware, to the same extent as cloud servers. They are located in the mobile users’ environment, like coffee shops, on business premises, or in malls. Users can connect to a cloudlet via a hotspot or through their mobile network provider. Connecting cloud computing systems, known as Cloud

978-1-4799-2337-3/14/$31.00 ©2014 IEEE

Federation, has received noticeable research interest. Cloud federation cannot be wholly mapped to cloudlet federation due to two main reasons. The first being that cloudlets (usually) are relatively less in resources and hence may depend on each other to execute a certain task, and second, cloudlets could go offline. Hence, the list of active cloudlets is in dynamic change, and special techniques are therefore required to interconnect cloudlets. To our knowledge, no such techniques have been proposed so far. Motivated by this, we propose a cooperative architecture for inter-cloudlet communication. II. RELATED WORK Our work is closely related to cloud federation, which was defined as a concept of service aggregation characterized by interoperability features, which addresses the economic problems of vendor lock-in and provider integration [7]. It was acknowledged in [8] that cloud federation enables automatic provisioning and seamless resource access across cloud providers, while it was recognized in [1] that applications like social media, Web, and eCommerce demand the truly global coverage provided by cloud federation. To enable this, a crossplatform Cloud API was proposed in [11] with a common set of interfaces for all provisioning levels. In [3], a three-phase model was devised for allowing a cloud to establish the federation with other clouds: selecting discovered clouds that fit as much as possible its requirements, and establishing a trust context with the selected clouds. Finally, a model was presented in [6] that helps providers in making decisions related to exploiting the federation through outsourcing resources to other providers, renting free resources to other providers, or shutting down unused nodes to save power. Concerning extending the computational ability of mobile devices, few solutions were proposed. In the CloneCloud framework [4], a mobile device migrates threads onto device clones found on clouds. Based on a cost–benefit analysis, the methods to be migrated are selected based on factors like the energy and time needed for execution. Another solution is the MAUI architecture [5] that involves the remote execution of code, chosen at runtime. The system creates two versions of the application to run on the mobile and the infrastructure, and then identifies the program states that are needed by the remote methods. Next, it calculates the costs of offloading the

134


code based on its size and the available connectivity in order to minimize the burden of offloading. Related to this, a system architecture was proposed in [12] for using virtual machines to instantiate service software on nearby cloudlets, and using the service over wireless LAN. The authors foresee that the cloudlet infrastructure would be distributed the same way WiFi access points are today. Cloudlets must be discovered and their use is negotiated, after which the user sends a private VM overlay that is applied to an already existing base VM overlay to derive the launch VM. The latter is executed and driven with the user's interaction. Once the results are obtained, the VM residue is created on the cloudlet and sent to the user, after which the VM is discarded. Consistent with the objectives in [12], we suggest a mechanism for the discovery of cloudlets and the interaction between them. Mobile applications discover cloudlets with the help of a root server that acts as a directory of cloudlets that maintains information about their load and resource levels. Cloudlets interact to delegate parts of or entire user jobs to other cloudlets when their resources have become low. III. SYSTEM ARCHITECHTURE Figure 1 depicts a typical cloudlet topology. Every cloudlet is assumed to be connected to the root server via the internet, and can communicate with another cloudlet normally via a LAN. Mobile devices can connect to cloudlets and consume their resources, directly or via a multihop connection. If a cloudlet cannot meet the requirements of a user, it may make use of another cloudlet’s resources, and hence, it must be able to find one or more cloudlets that are willing and able to provide the needed resources. This, in addition to other requirements necessitates a cloudlet collaboration protocol.

IV. SYSTEM DESIGN In this section we detail the components of the proposed and the interactions between them, and also define packet contents and the services offered by cloudlets. A. Resource Definition and Cloudlet Presence Announcement Nowadays, workstations and servers are equipped with multicore CPUs and can be connected through gigabit links to internal computing equipment and storage systems [13]. If the enterprise, person, or Internet Service Provider that owns such machines decides to make the extra resources available to mobile devices in the area, it can register these resources as one or more cloudlets. When the cloudlet is made available to lend its resources, it must announce its online presence and resources to the Root Server, a key element in our proposed system. The provider defines the set of resources available for rent, including storage, software, data, and infrastructure. The attributes of these services are depicted in Table 1. 1) Registration with root server After the provider defines the resources, it sends the Root Server a registration packet containing a cloudlet identifier assigned by the administrator, the operation times, the cloudlet location, and the resources it offers with their attributes. The cloudlet also includes an indicator of the availability of each resource at that time (Very high, High, Medium, Low, and Not Available), as illustrated in Table 2. TABLE1: ATTRIBUTES OF SERVICE OFFERED BY CLOUDLETS Service

Attribute Tprovider

StaaS

Sm Tt Cs Sa

SaaS

Cp De Tinfra

IaaS

Ti Ci DT

DaaS

Dc Cd

Figure 1: General Network Topology

In this regard, the authors in [1] state that a centralized approach might be desired, where cloudlets establish connectivity and collaborate among themselves. While centralized approaches are efficient, [14] argues that such an approach fails when the system is extended to a large scale. We claim that scalability is not an issue for our architecture, since the root server is restricted to keeping information about a handful of cloudlets, like in a mall or even at a university.

Definition times of connection to the network

Type strings (time format)

maximum storage /user maximum storage time /user cost per storage unit available software

double (Mb) double (days) double ($/Mb) array of strings

cost per application per hour short description of software times of availability of infrastructure

doubles ($/hr) string strings (time format)

types of virtual instances cost of instance per hour types of data cloudlet offers maximum data capacity /user cost per data unit

array of strings doubles ($/hr) strings double (Mb) double ($/Mb)

Service

TABLE 2: SERVICE AVAILABILITY: CRITERIA AND LEVEL VH H M Criteria

StaaS

% of maximum capacity remaining

SaaS IaaS DaaS

135

CPU usage, memory, storage, network traffic, plus other conditions % of total instances available % of storage capacity allocated to DaaS

L

NA

90

70

50

30

10

90

70

50

30

10

90

70

50

30

10

90

70

50

30

10


After defining the resources, a cloudlet sends a registration packet to the Root Server, which stores the cloudlet’s ID, its location, the available times, and offered resources with their attributes and availability. The server acts as a directory for cloudlet presence and resource availability information, and is contacted by users in search of potential cloudlets.

user wants a list of all cloudlets that satisfy the desired resources. TABLE 3: ATTRIBUTES OF SERVICE REQUESTED BY USER Service

Attribute Tuser

2) Availability: Updating the root server Given the dynamic nature of the resources of a cloudlet, regular updates must be issued to reflect presence and resource availability. The updates will occur in three different cases: when the cloudlet replies to the root server in response to a user request, when there is a significant change in the status of the cloudlet’s resources causing it to shift from one level to another, and when the timer passes some interval before receiving any requests and before a significant change occurs.

StaaS

SaaS

Sm Tt Cs Cp Me Cu

IaaS

Sm Tinfra Ci Dc

DaaS

Cd DT

Figure 2: User requesting service

B. Requesting Cloudlet Services The interactions among the system entities are illustrated in the diagram of Figure 2. A mobile user in need of a certain computing resource sends a request packet containing the desired resources, their attributes, and his GPS coordinates. The user must specify the attributes for every service needed as defined in Table 3. The request also includes a variable Re which defines the filters that the user would like to apply to the list of possible candidate cloudlets that the root server forms. Every type of service has its own Re value. A user interested in more than one service can specify more than one Re value. An Re for a StaaS can take one of the following values “Storage Capacity”, “Storage Time”, “Storage Cost”, “Software Cost”. While the value for the Re can have the values “Infra Type” or “Infra Cost” for IaaS. Similarly, Re value can be “Data Size”, “Data Cost”, or “Data Type” for a DaaS. The value “All” means no restriction, meaning that the

Definition Timing at which storage is required Storage capacity Total storage time Maximum storage cost willing to pay cost per application per hour Amount of memory needed The number of compute units Storage capacity Times during which user will use infrastructure Maximum rate per hour willing to pay maximum data capacity required Maximum cost per data unit willing to pay types of data required

Type strings (time format) double (Mb) double (days) double ($/Mb) doubles ($/hr) array of strings doubles ($/hr) double (Mb) strings (time format) double ($/Mb) double (Mb) double ($/Mb) strings

C. Finding Cloudlets that Satisfy the Request When the root server receives a request from a user, it examines several criteria in order to form a list of potential cloudlets. It first searches for the cloudlets that are online and can offer the services needed. The server looks for cloudlets that offer the service(s) needed and match the user requested attribute. It then checks the availability of the resources (i.e., based on the scale in Table 2), and eliminates cloudlets that are currently loaded and unable to provide services. Moreover, if it anticipates an increase in demand based on what it learns from the user requests, it eliminates cloudlets that may be in the low or very low regions of availability. If the server cannot find a cloudlet that meets all desired services, it resorts to creating up to N candidate lists pertaining to the N services needed. When the server is able to build a non-empty list of cloudlets, it checks the value of Re in the request, and if empty, it chooses the cloudlet that satisfies the largest number of conditions and builds a reply containing contact information and required services. It also appends the list of cloudlets, the resources they offer, and their URLs for reasons that will be explained later. On the other hand, if the Re field is not empty, the server filters the list accordingly. It then adds the IDs, resources offered, and URLs of these cloudlets to a sorted candidate list Lc for each service. D. Replying to the User’s request There are two cases to consider when describing how cloudlets reply to users: when the user has chosen to obtain a list of qualified cloudlets, and when he has delegated to the Root Server the job of choosing the most suitable cloudlet. In the first scenario, the server replies with the following for each cloudlet in Lc: ID and URL, offered resources, and attributes of each resource. When the user receives the reply from the server containing Lc, he selects one of these cloudlets

136


according to some criteria (e.g., past experience), and builds a service packet (using an API) containing the user ID, desired service(s) and associated attributes, location, along with the list of candidate cloudlets (Lc), and sends it to the selected cloudlet. The concerned cloudlet checks if it can meet the requirements, and if it can, it sends the user a reply, prompting for the method of payment. In the second scenario, if the root server finds Re is empty, it chooses from Lc the cloudlet that matches the user’s need the most. If this maps to several cloudlets, the one that is physically closest to the user will be selected. Next, the server forwards the user’s request to the cloudlet along with the user’s credentials so that the cloudlet can contact the user directly, and also include in the message the list Lc. E. Inter-cloudlet protocol In case the “primary” cloudlet has received a request for services for which it does not meet some or all the requested attributes, it resorts to other cloudlets to help fulfill the user’s request. The primary cloudlet contacts cloudlets that are in Lc by first checking the desired attributes specified in the request against those of the services it offers. It makes a list of the services with attributes that it cannot meet, and then, based on Lc, it filters the cloudlets that can offer these services. We suggest a protocol that resembles the network DHCP protocol, with the same messages: discover, offer, request, and acknowledge, though the content and destination differ. The primary cloudlet then sends to these cloudlets, termed secondary cloudlets, UDP discover messages that contain the attributes of the requested services. A contacted secondary cloudlet checks the availability of the services needed by the primary cloudlet, if it is able to help, it reserves the resources needed and sends back an offer packet. It also starts a timer which, when times out, will cause it to withdraw its offer and return the resources to the pool of available resources. When the primary cloudlet receives several offer messages, it chooses first the cloudlet that can offer the largest number of needed services, then another one that can offer the most number of services from among those that are left, and so on.

Average delay (seconds)

100% 80% 60% 40% 20%

0.16

0.12

90% 70% 50% 30% 10%

Average delay (seconds)

0.16

0.2

0.12

0.08

0.08

0.04

0.04

0 0 20 40 60 80 100 10 20 30 40 50 60 Percent Hit Rate 1 request per x minutes Figure 3: Average delay versus request rate (left) and versus hit rate (right) 0

0

V. EXPERIMENTAL EVALUATION We modeled our system using the OPNET Modeler [10] to evaluate and analyze the protocol discussed earlier. To observe the main features pertaining to the performance of our protocol, we devised a network in which the behaviors of the components and protocols mimic those portrayed by our protocol or closely match them. A. The network Test-bed In our experiments we used a network topology composed of 4 100BaseT LANs and 3 server nodes, where each LAN includes 100 clients. The LANs are interconnected using 4 switches. Each server node is connected to a different switch, and represents a cloudlet, which forwards client requests to other cloudlets when it is unable to satisfy them partially or fully. To implement this in OPNET, we used a cache-server model. The client applications are http applications that allow users to request 4KB objects from randomly selected servers. The ability to randomly select a server can be set in OPNET, whereas forwarding can be simulated based on the cache hit ratio of the server. When the requested object is found on the server, the latter sends the object to the client, but when there is a miss, the server randomly chooses one of the other servers that offer this application, and retrieves the object to send it to the client. One of the servers in the network will have its cache-hit ratio to be 100% to ensure that consecutive misses at some servers will ultimately end up as it a hit, and therefore users will always receive the requested object. Several experiments were conducted. The first was to test the effect of the client request rate on the load at the server side in addition to another parameter which is the end-to-end delay representing the time between sending a request and receiving the object of the request at the client side. Using the network described above, the request rate was varied starting from a maximum of one request per minute down to a minimum of one request per hour. For each request rate, the cache hit ratio was varied from 10% to 100% in increments of 10%. The delay and load curves were plotted and the average delay and average load were calculated. A 10% hit ratio signifies that 90% of the requests directed to that server will be forwarded to another server. As can be seen in the left graph of Figure 3, for a fixed hit rate, the average delay has a general descending trend with decreasing request rate. The maximum delay can be observed with a request rate of 1 per minute, and gradually decreases as the request rate decreases to 1 per hour. All average delays are below 200ms. Moreover, we can see that the delay curve shifts downward with increasing hit rate. That is, the lowest delay is naturally experienced when the hit rate is 100% and the request of a user can be fully met at the server with no need for forwarding and additional delays. For a hit rate of 10% percent, the highest delay is observed due to the fact that the server will forward the request in 90% of the cases to other servers, therefore increasing the end-to-end response time. Other servers with hit rate of 10% receiving that request have a 90% chance to again forward the request increasing the delay even more. The average delay behavior as a function of the hit rate is illustrated in the right graph of Figure 3.

137


Next, we studied the effect of the number of cloudlets on the load and delay by adding cache server nodes to the network. A request rate of one request per 5 minutes was chosen and a cache server hit rate of 60% was selected to emphasize the effect of forwarding. In this case 40% of the requests will be forwarded at each server, and hence the probability that a request will be forwarded twice would be 16%. The load on 3 randomly selected servers was observed, and these servers are the same in the 5 simulated cases so as to compare the results. As shown in the right graph of Figure 4, the load decreases as the number of cloudlets increases because with an increasing number of cloudlets, whenever the server needs to forward a request, the number of potential cloudlets it can pick is larger. For instance, when three servers are involved, the probability a server will be chosen to forward to by another server is 50%. When 5 servers are involved, the probability becomes 25%. Hence for a given server, there is a 75% chance of not being picked. Figure 5 shows how the delay increases with increasing the number of cloudlets. This is due to the increasing probability that the request will be forwarded several times, thus increasing the time the client has to wait for a response. 5500 100% 80% 60% 40% 20%

10000

1000

100

90% 70% 50% 30% 10%

Average Server Load (bytes/sec)

Average Server Load (Bytes/sec)

100000

5000 4500

services on mobile devices, and developing a corresponding service model that accounts for the limitations and characteristics of mobile devices, including mobility. One of the services suitable for such a platform is Network as a Service (NaaS) to exploit the capability of some mobile devices to lend Internet connectivity to other non-subscribing devices. 0.15 Average delay (seconds)

The average server load is also plotted for varying request rates and cache hit ratio as seen in left of Figure 4. The plot is logarithmic, and shows that the average server load decreases with decreasing request rate. The highest load is witnessed when the request rate is one per one minute but drops around one and a half orders of magnitude when the request rate reaches one request per 60 minutes. This is justified, as fewer requests directed towards a server result in a drop in the load on the server in terms of sent and received data. Moreover, the plot also illustrates the effect of varying the cache hit ratio while fixing the request rate. When the hit rate decreases from 100% to 10% for any request rate, the load on the server decreases. This is logical, as a high hit rate would remove the burden of sending requests to other servers and receiving responses as well as replying to the requests of other servers.

[1] [2] [3] [4] [5]

[11] [12]

0

[13]

VI. CONCLUSION

15

REFERENCES

2500 2000

7 9 11 13 Number of cloudlets in LAN

ACKNOWLEDGEMENT

[10]

10 20 30 40 50 60 3 5 7 9 11 13 15 1 request per x minutes Number of cloudlets Figure 4: Average load versus the request rate and number of cloudlets

5

This work was supported by a generous grant from the Lebanese National Council on Scientific Research (LNCSR) under grant #4194

[9]

3000

0.11

Figure 5: Effect of the number of cloudlets on delay

[8]

3500

0.12

3

[7]

4000

0.13

0.1

[6] Server 1 Server 2 Server 3

0.14

[14]

We presented a design for a distributed cloudlets system and associated interactions protocol that allows mobile users to consume cloudlet resources on demand. In ongoing work, we are designing a framework for hosting “mini-cloud”

138

D. Bredahl, "Federation is the Future of the Cloud", Posted in Data Center Knowledge, September 17, 2012. D. Bernstein and D. Vij. “Intercloud Directory and Exchange Protocol Detail using XMPP and RDF”, Proc. IEEE 6th World Congress on Services, 2010. A. Celesti, F. Tusa, M. Villari, and A. Puliafito, "How to Enhance Cloud Architectures to Enable Cross-Federation", IEEE Intl. Conf. Cloud Computing, 2010. B. Chun, S. Ihm, P. Maniatis, M. Naik, and A. Patti, CloneCloud: elastic execution between mobile device and cloud, Proc. 6th conference on Computer systems (EuroSys), 2011. E. Cuervo, A. Balasubramanian, D. Cho, A. Wolman, S. Saroiu, R. Chandra, and P. Bahl, “MAUI: Making Smartphones Last Longer with Code Offload,” Proc. 8th ACM MobiSys, 2010. I. Goiri, J. Guitart, and J. Torres, "Characterizing Cloud Federation for Enhancing Providers’ Profit", IEEE Intl. Conf. Cloud Computing, 2010. T. Kurze, M. Klems, D. Bermbach, A. Lenk, S. Tai, and M. Kunze, "Cloud Federation", In 2nd Intl. Conf. Cloud Computing, GRIDs, and Virtualization, pp. 32–38, 2011. N. Mehrotra and N. Dangwal, "Interoperate in Cloud with Federation", Infosys Technical Report, August 2011. Microsoft TechNet online Library, Capacity Planning (Chapter 4), available at http://technet.microsoft.com/en-us/library/bb742409.aspx OPNET Technologies Inc., OPNET Modeler, [available online] http://www.opnet.com/solutions/network_rd/modeler.html D. Petcu, C. Craciun, M. Rak, “Towards a Cross Platform Cloud API. Components for cloud federation”, In Proc. CLOSER 2011, pp. 166– 169, 2011. M. Satyanarayanan, P. Bahl, R. Caceres, and N. Davies. “The Case for VM-based Cloudlets in Mobile Computing”, IEEE Pervasive Computing, v. 8, n. 4, 2009. M. Satyanarayanan, “Mobile computing: the next decade”, Proc. 1st ACM Workshop on Mobile Cloud Computing & Services: Social Networks and Beyond (MCS ’10), 2010. Sotiriadis, S. Bessis, N. Kuonen, P., "Advancing Inter-cloud Resource Discovery Based on Past Service Experiences of Transient Resource Clustering," Third International Conference on Emerging Intelligent Data and Web Technologies (EIDWT), pp.38,45, Sep. 2012.