Abstract
With the integration of mobile computing and cloud computing, more diverse services can be provided to the users, supporting the mobility feature of mobile computing along with the power of cloud computing. This new paradigm still faces challenges, especially in terms of performance. When it comes to multimedia data communication, thin clients (such as smart phones and tablets) suffer because of performance and power constraints. Previously done studies have trivially addressed this problem. Therefore, in our paper, we present a framework in which thick clients (laptop or desktop computers) are incorporated into mobile cloud paradigm with attention paid to user mobility. Its objective is to optimize the distribution of multimedia content between the cloud and the thin clients. Our work comes up with both numerical analysis and simulation to justify the validity and the effectiveness of the proposal approach.
1. Introduction
In the recent times, handheld devices, like smartphones and tablets, have increased rapidly. Users nowadays prefer using lightweight, easy to carry small devices, instead of using laptops or desktop computers. Gartner Inc. report [1] that smartphone and tablet sale has already surpassed PC sale in the last couple of years. Soon they would be users’ preferred devices for Internet access [2]. To adapt to the changing and more demanding mobile environment, computing services have been going through innovation. Now with the advent of cloud computing (CC) [3, 4], mobile users can upload their data and outsource tasks to the cloud for further processing. The emerging trend is known as mobile cloud computing (MCC) [5], in which cloud computing and mobile computing come together to provide data intensive and more powerful computing services, along with mobility.
Being different from static computing, MCC faces many challenges, specially related to processing capabilities, constraints of wireless networks, and expensive cloud access, mobility. Particularly, user mobility might severely degrade Quality of Service (QoS) [6, 7]. A lot of solutions have been discussed already, but performance could not be enhanced. For example, in [8], the authors present a framework for creating virtual MCC providers, through nearby thin clients to receive multimedia data from Internet. But the limited capacity and bandwidth are still a hurdle in cloud access [9, 10]. To improve thin clients’ service, it is comprehensive that thin clients should be coupled with thick clients which come with more generous hardware resources and high speed Internet connection (DSL, Fibre, etc.). Keeping this in mind, we introduce thin-thick collaboration architecture, in which thin clients and thick clients can communicate with each other in order to optimize data distribution, specially multimedia content [11, 12], between cloud customers and cloud providers. In so doing, expected QoS requirements can be met. Moreover, our main concern is effective and efficient delivery of data from individual customers to the cloud network, keeping in view mobility of customers. Extensive evaluation shows that our approach improves data distribution efficiency and performs better than the existing approaches.
We divide our paper into following sections: Section 2 gives literature review on existing research work that relates to ours; Section 3 details the motivation scenario which explains why we have come up with the proposed approach; Section 4 specifies the framework architecture and algorithms; Section 5 shows the implementation of our ideas along with performance evaluation; the last section concludes the paper and suggests the future work.
2. Related Work
Research literature has seen efforts in trying to solve the above mentioned problems. In [13], authors propose a new approach for efficient cloud-based synchronization of a number of distributed file system hierarchies. They use a master-slave architecture for propagation of data to reduce traffic. In [14], researchers demonstrate that some resource scheduling techniques can be effective in mitigating the impacts that negatively influence application response time and system utilization. Ross [15] and Kumar and Lu [16] introduce the impact of the data transfer delay on the performance but they do not reckon to use bandwidth efficiently. Similar to our approach, many also tried integrating mobile devices and CC. In [17], Luo suggests a new idea of using cloud to improve mobile device’s ability to face the performance challenges for low latency and high throughput of media data processing [12, 18]. Delgado et al. [19] innovate Hyrax that encourages using mobile devices as resource providers in CC platform; yet experiment is not integrated. In [20], the authors just concentrate on using partition policies to hold the effect of application on mobile devices, but they do not solve any other matter related to user mobility [21]. Kim et al. [22] propose an adaptive scheme that optimizes run-time data distribution and collection services for hiding the data transfer time; user mobility is not either. Therefore, in this paper, we try to solve the above shortage by introducing a thin-thick client collaboration to optimize the multimedia data distribution between cloud network and mobile thin clients with attention paid to user mobility.
3. Motivating Scenario
The scenario shown as in Figure 1 exemplifies the utilization of thin-thick client collaboration.
A student wants to watch online movies with her smartphone while she is walking in her university campus. We assume that she is moving at the same speed and cannot use her mobile internet data (as it is slow and has limited capacity). Thus, she has to access her university wireless network. Once connected, her mobile phone (thin client) can send a request (e.g., movie streaming) to the broker which manages several thick clients to serve this request. Each of the chosen thick clients will establish a connection to the corresponding cloud provider which thin client desires to access. Requests are sent to cloud; processed and returned data are delivered to thick clients before gathering at broker and being dispatched to requesting thin clients. It is worth noting that data between cloud and thick client can be delivered in a relatively short time with presumably high-speed Internet connection of these thick clients.
The above situation indicates the possible profit of applying the cooperation between thin clients and thick clients in a classic MCC environment. Such collaboration encouragingly increases the chance of utilizing resources efficiently. However, when mobile users move out of a broker’s domain (i.e., no access point connected to the broker is found), all running sessions (called “state”) made between clients and cloud providers might be terminated, which leads to service degradation. To sustain the service continuation in this scenario and also to balance the requested workload, it claims the need of using multiple brokers, which means when the mobile clients move to a different domain, the associated broker should be able to follow them by migrating its “state” to the next available broker at the newly visited domain and restore previous session with little impact on service quality. With that in mind, we design our system architecture to deal with the following concerns:(i)distributing data from cloud providers to thick clients;(ii)finding the most appropriate broker to minimize the migration time of “state” from the current broker.
4. System Architecture
The following section gives an insight of our system architecture proposed to address issues discussed in the above scenario.
Different from other approaches that follow a model which states that one thin client is served by one server through multiple paths, our system can be viewed as a model. It expresses that, from a cloud provider (1), chunks of data are sent to multiple thick clients which will then transfer these data to multiple brokers in the scenario. The broker works as the heart of the middle layer, combining and delivering the received data to the intended end user(s) . For ease of presentation, our system can be divided into the following two layers as shown in Figure 2.
4.1. Layer 1
In this layer we consider the following: splitting and distributing data from cloud providers to processors (thick clients) with different capacities according to bandwidth of Internet connection. For clarity, we give the important definition and assumption for our system. First, split each block of data into chunks with different sizes depending on bandwidth. is the size of a chunk . is bandwidth from a virtual machine (VM) on a cloud to a processor. Therefore, time spent for the transferring a chunk from VMs to a processor is . For parallelization, the time to transfer chunks to processors should be equal:
According to this value, we can determine the size of each chunk to adapt with bandwidth of each connection. Next step is to sort the processors depending on their capacities. The processor which has higher capacity will receive big chunks and the processor which has lower capacity will receive small chunks.
4.2. Layer 2
The second layer involves combining the data at brokers and/or overlay services between brokers then transferring it to a thin client. The issue here is how to find the location of the most appropriate broker between the nearby ones to minimize the migration time of “state” from the current broker where a user moves.
Basically, we consider the network topology as the three-tier architecture [23], which consists of core switch (CS), aggregation switch (AgS), and access switch (AcS) as in Figure 3. The number fan-out of CS is denoted by and represents transmission delay from CS to corresponding AgSs. The number fan-out and the transmission delay from AgS to AcS are denoted by and , respectively. In the initial state, the transmission delay on each edge between AgS and CS is set equally (i.e., ).
Similarly, the transmission delay on each edge between AcS and AgS is also set equally (i.e., ). Let present the number of fan-out of AcS, and is the transmission delay between AcS and its brokers. In practical network, it is obvious that transmission delay on an edge of tree is directly proportional to the amount of simultaneously transmitted data “state” on that edge. Hence, the communication cost between brokers depends not only on the number of hop counts but also on the transmission delay which is defined as follows: where is the transmission delay from broker to broker and and are the bandwidth and the individual load of edge connecting broker to broker (i.e., belongs to path ), respectively.
Let denote the number of hop counts from broker to broker , and is the weighted mean function or the tradeoff number of hop counts and transmission delay between two brokers. Finally, we specify the communication cost from broker to broker as follows: Therefore,
In addition, we define resource demand matrix as a matrix representing the traffic demand between pairs of brokers . Traffic demand comes from the weight of each “state” we want to migrate. Evidently, in order to perfect the system, the pair of brokers which has heavy resource demand should be as close as possible to each other. Thus, the sum of all multiplication of every resource demand and its corresponding communication cost have to be kept minimum. Thence, the objective function can be formulated as follows:
Our purpose is to minimize this function to find the balance between the lowest cost and the heaviest resource demand between brokers ; is the set of brokers. It can be understood that the pair of brokers with the lowest communication cost will migrate the heaviest “state” to each other. Hence, we need an efficient algorithm like Algorithm 1 to find the position of destination broker to store the “state” of the current broker to achieve the optimal solution of problem (5).
| ||||||||||||||||||||||||||||||||||||||||||||||
5. Implementation and Analysis
In this section, we use numerical simulations and compare our approach’s performance with others’ to evaluate the efficiency of the method. All the parameters in the simulations are different number of thick clients, number of brokers, traffic demand, network topology, and some big media files for the above method. The simulations are conducted in Java with JDK-7u7-i586 and Netbeans-7.2. We consider 2 cases: with and without user mobility. The implementation result in Figure 4 proves that, without user mobility, related to the processing time of transferring big media data from a cloud provider to a thin client, our approach leads to a better performance than the one which has one processor receiving data.
In addition, suppose that users move at the same speed; we examine the migration time of “state” data distribution from a current broker to a destination broker for thin clients. The results reflected in Figures 5 and 6 indicate that our method has worse objective value than Greedy, but better than Random method. In the meantime, the execution time of our approach is better than Greedy but worse than Random. After all, when we sum the time of data distribution from cloud provider to brokers and from brokers to thin clients, the total execution time of our proposal is still more efficiency.
6. Conclusion
In this paper, for efficient delivery of data, we present an architecture of thin-thick client collaboration. Our objective is to optimize data distribution between cloud customers and providers. With the user being mobile, expected QoS can be achieved. Furthermore, we conducted simulations to evaluate our method. Through the simulation results, it has been seen that our system performance is better than the existing ones. The future work includes advancing the research proposal into real-world implementation, firstly in testbed environments before expanding it into larger-scale production deployment. With the planned implementation, hopefully we can thoroughly observe the real-world operation and work out any rising problems or shortcomings should they be occurring. Moreover, we will focus more on improving the quality of service in order to bring better cloud service experience.
Conflict of Interests
The authors declare that there is no conflict of interests regarding the publication of this paper.
Acknowledgment
This research was supported by the MSIP (Ministry of Science, ICT & Future Planning), Korea, under the ITRC (Information Technology Research Center) support program (NIPA-2014 (H0301-14-1020)) supervised by the NIPA (National IT Industry Promotion Agency).