# Priority-Based Cloud Computing Architecture for Multimedia-Enabled Heterogeneous Vehicular Users

Authors: Amjad Ali; Hongwu Liu; Ali Kashif Bashir; Shaker El-Sappagh; Farman Ali; Adeel Baig; Daeyoung Park; Kyung Sup Kwak
Journal: Journal of Advanced Transportation
 (2018)

---

## Abstract

In recent days, vehicles have been equipped with smart devices that offer various multimedia-related applications and services, such as smart driving assistance, traffic congestions, weather forecasting, road safety alarms, and many entertainment and comfort applications. Thus, these smart vehicles produce a large amount of multimedia-related data that require fast and real-time processing. However, due to constrained computing and storage capacities, such huge amounts of multimedia-related data cannot be processed in on-board standalone devices. Thus, multimedia cloud computing (MCC) has emerged as an economical and scalable computing technology that can process multimedia-related data efficiently while providing improved Quality of Service (QoS) to vehicular users from anywhere, at any time and on any device, at reduced costs. However, there are certain challenges, such as fast service response time and resource cost optimization, that can severely affect the performance of the MCC. Therefore, to tackle these issues, in this paper, we propose a dynamic priority-based architecture for the MCC. In the proposed scheme, we divide multimedia processing into four different subphases, while computing resources to each computing server are assigned dynamically, according to the workload, in order to process multimedia tasks according to the multimedia user Quality of Experience (QoE) requirements. The performance of the proposed scheme is evaluated in terms of service response time and resource cost optimization using the CloudSim simulator.


---

## Body

## 1. Introduction

Recent advancements in wireless access technology and the automobile industry have made Internet access a basic need for vehicles moving on roads. These days, vehicles are equipped with several sensors, cameras, and other smart devices, and passengers enjoy a range of applications for comfort, safety, entertainment, and commercial services. In a Vehicular Ad hoc Network (VANET), vehicles communicate with each other using roadside infrastructure to share information (e.g., road map images, road safety, and traffic congestion information for safe driving). Vehicles also exchange a lot of other information, such as security alerts, distance, and collision warnings, cooperative cruise control and driving, driver assistance, global positioning syste locations, automatic parking assistance, Internet access, and dissemination of road information [1, 2]. Moreover, these days, the automobile industry and academia all around the globe are focusing on driverless or autonomous vehicles and such smart vehicles record videos and take high-resolution images, and sensors record other data for successful and smooth driving [3]. Thus, overall, vehicles are producing a huge amount of critical information and delay-sensitive multimedia data for processing, such as surveillance videos, traffic-congestion images, and other entertainment data. However, due to limited computational and storage capacities, standalone on-board devices have insufficient processing power for such a huge amount of data to ensure on-time delivery of required contents to maintain the desired or guaranteed Quality of Experience (QoE) to the end user. Moreover, vehicles have some other unique features (i.e., lack of bandwidth, short-range radio communications, high mobility, and intermittent connectivity), which make multimedia content distribution in VANETs more challenging.The emergence of cloud computing brings a revolution in the computing industry because of its unique properties, such as elimination of hardware installation at the user’s end and provision of various computing functionalities as a service to end users [4–6]. Cloud computing is more attractive for multimedia-related processing because of the intensive computation and storage requirements that are not offered on standalone devices [7–10]. However, the conventional cloud computing architecture is not well suited to multimedia services and applications because of the time-critical and delay-sensitive computational nature of the applications. Moreover, heterogeneity in end users makes it even more challenging. Therefore, a novel computing paradigm known as multimedia cloud computing (MCC) is emerging to deal with such time-critical and delay-sensitive multimedia applications and services [11].The MCC has installed high-speed Graphic Processing Units (GPUs), CPUs, and storage units to deal with multimedia-related processing, as shown in Figure1. Thus, the one big advantage of MCC is that, while exploiting the MCC infrastructure for multimedia-related computation, multimedia end users do not need to pay for costly computing and storage resources, and instead, they only need to pay for the time for which they use the MCC resources. However, in the MCC, on-time processing of multimedia applications and services-related tasks and forwarding them to the intended end user while maintaining a guaranteed QoE at end users is a challenging issue that can severely affect the performance of delay-sensitive and time-critical multimedia processing. Moreover, another critical and challenging issue for cloud service providers is how they allocate computing resources in order to minimize the computing resources’ costs while providing the desired QoE. For example, in a vehicular-based MCC scenario, the MCC may need to process and propagate the desired information about an accident that happened on the highway due to bad weather conditions (e.g., fog) and if such information is not processed and disseminated to other oncoming vehicles in time, then more accidents can happen, with the possible loss of more lives and assets. Thus, theservice response time (that is, a measure of the total time, or latency, of a multimedia task starting when MCC receives the multimedia request at the scheduler until transmitting the processed results back to the intended end user) is a significantly important factor for measuring the QoE performance of MCC from the multimedia end users’ perspective [7]. Table 1 provides the acronyms and symbols used in this paper.Table 1
List of acronyms and symbols.
Abbreviation Name MCC Multimedia Cloud Computing QoE Quality of Experience LBM Load Balancer Module CC Computing Cluster MC Multimedia Cloud DC Dynamic Conversion DE Dynamic Extraction DM Dynamic Matching DR Dynamic Reconstruction TM Transmission Module SS Scheduling Server C Total computational resources μ Scheduling rate λ Multimedia request arrival rate N Number of priority queues Ri Average result size ϵ Upper bound of service time ξ Transmission rate Fi Multimedia task of priority-classiFigure 1
General architecture of multimedia cloud computing.To overcome the aforementioned issues, in this paper, we propose a priority-based dynamic resource allocation scheme for MCC where the prime objective is to ensure efficient processing and on-time fulfillment of multimedia-related tasks while minimizing the computing costs. Thus, in our proposed scheme, we divided the MCC architecture into four special-purpose and dedicated computing clusters. Similarly, we divided multimedia task processing into four different subphases. The computing resources for each computing cluster are assigned based on workload estimation information. Moreover, resource allocation is periodically updated (e.g., additions and removals) to minimize the computing resource costs and to guarantee QoE for end user. In our proposed scheme, multimedia processing requests are first filed in arequest queue that is part of Load Balancer Module (LBM). TheLBM analyzes the nature of the received multimedia requests and assigns them to an appropriate computing cluster that processes the assigned tasks and sends them to the next computing cluster, or to atransmission unit based on the nature of the processing required. Finally, the transmission unit forwards the processed multimedia request to the intended end user. The proposed scheme further handles the priority or urgency of multimedia users with the help ofjob queues. In the proposed scheme, each computing cluster (including the transmission unit) contains N job or transmission queues.The rest of the paper is organized as follows: Section2 discusses the state of the art related to multimedia-related processing. Section 3 presents our proposed priority-based dynamic resource allocation scheme for the multimedia cloud architecture. Section 4 deals with performance analysis. Finally, Section 5 concludes the paper.


## 2. Related Work

This section summarizes the state of the art related to multimedia cloud computing, particularly in the context of delay-sensitive, time-critical, and QoE demands in multimedia data processing.Liu et al. proposed a relay-selective multihop scheme, in which a vehicular network is integrated with cloud computing to provide media services, e.g., weather forecasting, traffic congestion reports, and road safety alarms [12]. In this scheme, Road Side Units (RSUs) communicate through the cloud via a road-side fixed communications sources. The proposed scheme is efficient at making transportation decisions in severe weather and under controlled traffic problems. Similarly, in [13], Joshi et al. discussed vehicular challenges, such as road safety messages, navigational data, and different conditions of vehicular mobility, and then, they proposed an integrated framework for a VANET and cloud computing services, known as “Traffic Management as a Service (TMaaS).” The TMaaS provides different real-time applications (e.g., tracking a vehicle’s location, accident alarms, and traffic situation reports). Moreover, TMaaS also support vehicles’ intracommunications mechanisms to forward, store, and process data in the centralized cloud for making decisions. Moreover, to tackle the processing of huge amounts of vehicular data, Gong et al. proposed a mobile content distribution scheme with the help of roadside parked vehicles [14]. This scheme mainly consists of two types of cloud: (i) mobile cloud and (ii) Roadside Parking Cloud (RPC), where an RPC is formed by a group of parked vehicles on the roadside and a mobile cloud is formed by a group of cooperative and moving vehicles having the same type of characteristics. Thus, in this scheme, moving vehicles get connected with the RPC and use their requested services, but if the vehicle is moving out of range from one RPC, then the first RPC forwards that vehicle’s request to the next neighboring RPC.Meneguette et al. in [15] addressed the benefits of an Intelligent Transportation System (ITS) in which vehicles provide streamlined services for managing traffic loads, and different automobile operations and to help stakeholders by providing various other useful information regarding safety. With these advantages in mind, a new vehicular cloud architecture was proposed to help manage an ITS in big city areas. Moreover, a framework was proposed that provides services that include information access and storage management to citizens, commercial vehicles, and emergency services (i.e., ambulances). It also provides the integration of VANETs with other networks for efficient monitoring and controlling of the ITS. With the evolution of VANETs, transportation systems are improving, with different enhanced features of safety, security, navigation, and road condition reports. But due to different research challenges regarding security and privacy, VANETs do not fulfill users’ expectations. Thus, to address these challenges, a communications paradigm stack for VANETs based on the cloud was proposed [16]. This framework divides VANETs into three categories: (1) a vehicular cloud, (2) vehicles using the cloud, and (3) a hybrid vehicular cloud. In this scheme, the cloud provides information to moving vehicles, and consequently, the moving vehicles provide information about roads to the cloud. The result of this mutual communication is that the cloud provides all current and near-future locations for efficient decision-making. These days, the advancements in vehicular communications have become the motivation for forming a vehicular cloud, which provides different storage, processing, and media services. But providing high-quality communications services for moving vehicles with limited resources is a challenging problem that was addressed in [17]. Those authors proposed a cloud-based Communications-as-a-Service (CaaS) scheme that guarantees continuing transmissions and manages vehicular resources while the vehicle is moving outside the range of a roadside unit. In this scheme, the vehicular cloud is further divided into three layers: (1) a vehicular cloudlet that forms a tree topology of connected vehicles in a VANETs, (2) a roadside cloudlet that is locally established by RSUs, and (3) a central cloud that is a group of servers accessed via the Internet.In order to provide the key services for smooth driving, a priority-based RSA scheme was introduced [18]. This scheme replaces the roadside unit with a dynamic cloud for managing overhead on the network and to maintain QoS to the users. The dynamic cloud collects and provides all required information to the vehicles in its range and forwards the information to a centralized controller, so (in case of emergency) a call is routed to the nearest police station and medical emergency response team to overcome the problem. However, the integration of VANETs with cloud computing has became a new research challenge due to scalability and reliability issues, because of the huge amounts of navigational data and safety messages along with event-location information. Thus, to tackle such issues, a cloud-based vehicle monitoring system for VANETs was proposed [19]. In this scheme, moving vehicles act as surveillance nodes that gather all information, including capturing video or images of a particular location, of road conditions, and capturing accident data from events on the roads. These data are forwarded to the central cloud through vehicular cloud formed by a group of vehicles. The main goal of this proposed scheme is tracking vehicles to handle emergency situations. Moreover, the extension of vehicular services, including multimedia applications, is dependent on integration of the cloud with VANETs. Keeping this view in mind, Jelassi et al. [20] proposed a new video streaming mechanism to provide efficient services to moving and parked vehicles. The proposed streaming framework comprises a vehicular cloud, roadside cloudlets, and a central cloud. In the proposed scheme, when any vehicle wants to see a video, the request is forwarded to any cloud component based on the availability of the requested video, and a scheduling mechanism is also generated in the cloud. During this process, a roadside cloudlet is responsible for maintaining the session during movement by the vehicle.The emergence of the ITS leads to maximum usage of vehicular data by roadside users. To deal with this, cloud computing is best suited for a vehicular network, but security for the flow of data between the cloud and roadside units is a challenge. Thus, secure vehicle traffic data dissemination and analysis for cloud-based VANETs were proposed [21]. The proposed scheme applies privacy to the identification of a vehicle and its data flow through a pseudonym mechanism. This scheme also ensures authorization through secret credentials and authentication through identification-based signatures. Hence, the verification of a user’s information and identification of intruding vehicles are done through batch verification and a pseudonym block list, respectively. Moreover, the requirement for accessing information related to transportation has become a basic need for smart vehicles in VANETs. By providing complex information, such as location services, real-time functionality, and storage services, vehicular applications are considered more complex than other conventional applications [22]. Thus, Aloqaily et al. discussed on-demand functionality of a vehicular cloud and proposed a new distributed scheme [22]. In the proposed scheme, the Vehicular Trusted Third Party (VTTP) concept is exploited for efficient traffic service management. This scheme also facilitates the drivers to switch between different trusted third parties to access their desired services and to reduce latency in communications. The Vehicluar-cloud (V-cloud) is an emerging and significant computing paradigm that has great impact on managing transportation issues and other roadside safety mechanisms. The V-cloud enables VANETs to offer multiple low-cost services, including advertisements and multimedia. Garai et al. [23] presented a QoS-aware three-layer V-cloud architecture that provides a tree-based connection to vehicles in a network. They also proposed authentication and privacy mechanisms via certification for secure communications which exploits public key certificates with zone-based vehicular groups to prevent malicious attacks.Hossain et al. [24] presented a resource allocation scheme for cloud-based surveillance video computing. The proposed scheme focuses on the optimization of virtual machine resources to fulfill the various user services provided by a media cloud. A single service is not effective for user requests but composite services can be more efficient and optimal. This scheme was a composition of two mechanisms: (1) a linear programming model and (2) a heuristic approach that can dynamically allocate resources in a media cloud. Similarly, Cicco et al. [25] introduced a resource allocation controller for streaming video over multimedia cloud computing. The aim was to provide high-quality streaming video to users and minimize distribution cost. A power saving-based scheme for multimedia streaming services for embedded systems in MCC was introduced [26]. That scheme uses digital signal processor to deliver a high-quality media service in the cloud and save power for mobile devices. Similarly, Song et al. [27] presented a two-stage scheme for task and resource management in MCC. The proposed approach focuses on resource management to define the ways to assign virtual machines to actual servers, and for task management, where virtual machines are assigned the tasks. Moreover, Wen et al. [28] highlighted the key challenges that can affect the performance of cloud computing while assigning an accurate amount of cloud resources in a short period of time to compute multimedia applications. Thus, to cope with such issues an efficient load balancing scheme called “cloud based multimedia load balancing” for cloud-based processing was proposed [29]. Furthermore, the concept of a hierarchical media cloud system that consists of a resource manager, cluster heads, and server clusters was introduced [30]. In this technique, user requests arrive at a resource manager that transfers the requests to a content server and a cluster head for further processing. The main focus of this technique is how to optimally distribute the workload in the system so that it does not affect the performance of a multimedia system.Some more work related to efficient resource allocation in MCC was presented [7, 11, 31–34]. In [7], a priority-based optimal resource allocation technique for MCC was presented. In this scheme, the users’ requests are treated as multiple priority-classes and are processed according to their priority values. A media-edge cloud design architecture for MCC was presented [11]. In the proposed architecture, the authors discussed parallel and distributed cloud processing and QoS. They further divided the media cloud into three clusters: (1) CPU, (2) storage, and (3) GPU. Media graphics processes are executed on GPU clusters, while CPU clusters perform general media process computation and storage was managed by storage clusters. In [7], a queuing-based resource allocation scheme to minimize response time while allocating cloud resources was presented. In [31], a dynamic resource allocation scheme for MCC was introduced. The prime objective of that proposed scheme was to enhance system efficiency while finding the exact amount of resources to be allocated to a media cloud. Li et al. [32] proposed QoS-based resource allocation for MCC. For performance enhancement, the authors considered QoS factors, such as completion time, cost, and energy consumption. Hong et al. [33] proposed efficient resource allocation based on media-task QoS for MCC and a cost-effective and QoS-aware resource allocation scheme for MCC-based e-health systems was proposed [34].


## 3. Proposed Dynamic Priority-Based Efficient Resource Allocation Scheme for Multimedia Cloud

In this section, we discuss the proposed dynamic priority-based efficient resource allocation scheme for the multimedia cloud (MC). The proposed scheme is mainly divided into three parts: (1) the MC processing architecture, (2) the MC queuing model, and (3) the MC resource allocation strategy. Furthermore, the proposed scheme divides each multimedia task into four subphases: (1) conversion, (2) extraction, (3) matching, and (4) reconstruction. This method is similar to the one presented [11]. However, in our proposed architecture, these four subphases for multimedia processing are performed by four different, separate, and dedicated computing clusters, rather than a single computing cluster. In our proposed scheme, each subphase of multimedia processing can be performed individually or related to other subphases depending on user requirements. In order to efficiently compute multimedia tasks, each media computing cluster assigns computing resources dynamically.In order to process multimedia-related tasks (e.g., images and videos), the processing architecture is mainly divided into three parts. The first is the LBM, which is designed to collect multimedia processing requests from heterogeneous multimedia users. There is a request queue in the LBM to store user requests. The objective of the LBM is to schedule user requests for processing and to estimate the received workload at any time that further helps in allocating computing resources to each media cluster. The second part is the media clusters for multimedia processing. In our proposed scheme, there are four media clusters: (1) the Dynamic Conversion (DC) cluster, (2) the Dynamic Extraction (DE) cluster, (3) the Dynamic Matching (DM) cluster, and (4) the Dynamic Reconstruction (DR) cluster, as shown in Figure2. Each media cluster name is based on its functionality of computing a pacific multimedia subphase, such as conversion, extraction, matching, and reconstruction. There are N job queues in every media cluster to store and process multimedia tasks according to users’ priorities.Figure 2
Multimedia cloud computing architecture.In this paper, we assume that priority for each multimedia task is already assigned according to the type and nature of the task. For example, the more important and critical multimedia user’s requests are assigned a higher priority and, similarly, the least important requests are assigned the lowest priority. A higher priority user’s tasks are placed in a higher priority queue to meet its processing deadlines or QoE. Moreover, each subphase of multimedia processing can be performed individually or collectively, based on user processing requirements. The last module is the transmission unit (TU), which is responsible for storing and forwarding the processed multimedia users’ tasks. The TU contains two components: (1) the priority-based transmissions queues that contain user processed tasks according to their priority and (2) the transmission server that forwards processed users’ jobs according to display device heterogeneity. It also adjusts the quality of transmissions according to the QoS requirements of the receiver.


### 3.1. Priority-Based Queuing Model for Multimedia Computation

In this subsection, we describe our priority-based queuing model. As shown in Figure3, there are three different types of queues: (1) scheduling queue, (2) computing queues, and (3) transmission queues. In this paper, we assume N priority-classes of multimedia requests. Therefore, each multimedia request corresponds to a single priority-class at a time. Smaller priority numbers represent a higher priority-class. For example, the priority 1 multimedia request class has a higher priority than priority 2 multimedia request class. Furthermore, any priority-class i multimedia requests are classified with the help of four parameters: (1) average task size, T, which specifies the total number of instructions, (2) average arrival rate, λi, of priority-class i multimedia requests, which denotes the number of requests per second, (3) average result size, Ri, which is measured in bits, and (4) the upper bound of service response time, ϵi, which is measured in seconds. Moreover, in our scenario, each multimedia task is further divided into four subtasks (the subphases discussed previously). The priority of each multimedia request is assigned based on its criticality or importance; however, we will not discuss this factor in detail in this work.Figure 3
Priority-based queuing model for multimedia cloud computing architecture.The Scheduling Server (SS) schedules multimedia requests at scheduling rateμ for processing according to assigned or allocated priority-classes. For this purpose, each computing cluster (CC) contains N priority queues, as shown in Figure 3. Similarly, N transmission queues store the processed data or results to forward to the intended end users at transmission rate ξ. Multimedia requests of priority-class i arrivals are modeled by using a Poisson distribution with the λi arrival rate. Thus, the average arrival rate of all priority-class multimedia requests computed based on the Poisson process composition property is given as follows:(1)λ=∑i=1NλiThe SS schedules the multimedia requests with the highest priority first. Hence, the scheduling queue is modeled as preemptive priority M/M/1 with mean service rate η of the SS. Tisch is the mean service response time for scheduling priority-class i multimedia requests given in [35] as follows:(2)Tisch=1/μ1-σi-1sch+∑j=1iλj/μ21-σi-1sch1-σisch,∀i=1,2,…,Nwhere μ is the scheduling rate and σisch is given as follows:(3)σisch=∑j=1iλjμ,In order to stabilize the scheduling queue, the following condition should be satisfied:(4)σNsch=∑j=1Nλjμ<1Due to the same service rate for all priority-class multimedia requests, the total response time is the same as the M/M/1 queue. Hence, the mean service response time for scheduling all priority-class multimedia requests is computed as follows:(5)Tsch=1/μ1-λ/μIn our scenario, each multimedia task of priority-class i, Fi, is divided into four subtasks, or subphases denoted by Fik where k=1,2,3,4, and each subtask represents a unique computational phase. The highest priority multimedia tasks are computed first in a preemptive priority manner. The service time for multimedia requests of priority-class i is assumed to be exponentially distributed with mean time, Fik/Ck. Ck represents the total computational resources allocated to computing subphase k. Hence, the mean service response time for multimedia tasks of priority-class i in computational phase k is given in [36] as follows:(6)Ticomk=Fi/Ck1-σi-1comk+∑j=1iλjFj2/Ck21-σi-1comk1-σicomk,∀i=1,…,Nwhere σicomk is given as(7)σicomk=∑j=1iλjFjCk.Similar to the above, the following stabilizing condition is also applied to the computing queue:(8)σNcomk=∑j=1NλjFjCk<1.We assume very high-speed communications links within the computing clusters; therefore, the latency of moving multimedia subtasks from one computing cluster to another computing cluster is almost negligible. Thus, the mean service response time for multimedia tasks of priority-class i for all four computing subphases is given as follows:(9)Ticom=∑k=14TicomkFinally, the mean service time for computing of all types of multimedia priority-classes under unequal service rate distribution is computed as follows:(10)Tcom=∑i=1NλiTicomλMultimedia tasks processed through scheduling and computing queues are finally sent to the transmission queue at transmission rate ξ, where N priority queues store processed results of size Ri before forwarding them to the intended priority-class i end users. However, the fraction Ri/ξ represents the mean transmission time of exponentially distributed priority-class i results. Eventually, the mean service response time for transmitting/forwarding the results of priority-class i multimedia users is given as(11)Titra=Ri/ξ1-σi-1tra+∑j=1iλjRi2/ξ21-σi-1tra1-σitra∀i=1,…,Nwhere σitra is computed as(12)σitra=∑j=1iλjRiξ,and to ensure the stability of the transmission queue, the following condition must also hold:(13)σNcomk=∑j=1NλjFjCk<1.Finally, the service response time for transmitting all priority-class multimedia results is computed as given below:(14)Ttra=∑i=1NλiTitraλHowever, the factor Titra is computed in (11) above. Thus, based on the above queuing analysis, we find the total delay or latency of priority-class i multimedia tasks given as follows:(15)Titot=Tisch+Ticom+TitraThus, by using (2), (9), and (11), Titot can be represented as follows:(16)Titot=1/μ1-σi-1sch+∑j=1iλj/μ21-σi-1sch1-σisch+∑k=14Ticomk+Ri/ξ1-σi-1tra+∑j=1iλjRi2/ξ21-σi-1tra1-σitra∀i=1,…,NThus, by substituting the values of σi-1sch and σitra into (16), we get(17)Titot=1/μ1-∑j=1i-1λj/μ+∑j=1iλj/μ21-∑j=1i-1λj/μ1-∑j=1iλj/μ+∑k=14Ticomk+Ri/ξ1-∑j=1i-1λjRi/ξ+∑j=1iλjRi2/ξ21-∑j=1i-1λjRi/ξ1-∑j=1iλjRi/ξ∀i=1,…,NFinally, substituting the values of Ticomk and σicomk into (17), we get(18)Titot=1/μ1-∑j=1i-1λj/μ+∑j=1iλj/μ21-∑j=1i-1λj/μ1-∑j=1iλj/μ+∑k=14Fi/Ck1-∑j=1i-1λjFj/Ck+∑j=1iλjFj2/Ck21-∑j=1i-1λjFj/Ck1-∑j=1iλjFj/Ck+Ri/ξ1-∑j=1i-1λjRi/ξ+∑j=1iλjRi2/ξ21-∑j=1i-1λjRi/ξ1-∑j=1iλjRi/ξ∀i=1,…,NFurthermore, the total service response time for all types of priority-classes can be computed as(19)Ttot=Tsch+Tcom+Ttraby substituting the values of Tsch,Tcom, and Ttra into the above equation, we get(20)Ttot=1/μ1-λ/μ+∑i=1NλiTicomλ+∑i=1NλiTitraλAfter substituting the values of Ticom and Titra into (20), we get(21)Ttot=1/μ1-λ/μ+∑k=14∑i=1Nλi∑j=1iλjFj2/Ck2λ1-∑j=1i-1λjFj/Ck1-∑j=1iλjFj/Ck+∑i=1NλiFi/Ckλ1-∑j=1i-1λjFj/Ck+∑i=1NλiRi/ξλ1-∑j=1i-1λjRi/ξ+∑i=1Nλi∑j=1iλjRi2/ξ2λ1-∑j=1i-1λjRi/ξ1-∑j=1iλjRi/ξThus, the end user experiences satisfactory QoE if end-to-end latency (e.g., latency from scheduling till transmission) of multimedia requests of priority-class i is less than its predefined threshold (i.e., the upper bound of service time, ϵi). This QoE constraint is defined as follows:(22)Titot<ϵiSimilarly, MCC is considered to be efficient if it holds to the following conditions for all multimedia users of priority-class N:(23)Ttot<ϵHowever, if the MCC does not meet the above two conditions, more resources are added to meet the QoE conditions.


### 3.2. Step-by-Step Procedure of Multimedia Processing in MCC

The step-by-step working procedure of the proposed MCC framework shown in Figure4 is as follows.Figure 4
Working flow of MCC.Step 1.
The LBM receives the multimedia processing requests from different multimedia users and assigns the priority to each multimedia task based on its importance and criticality (e.g., delay) and places them into a request queue.Step 2.
The LBM periodically performs a queue analysis after everyt time interval to estimate the workload.Step 3.
The LBM assigns computing resources to each computing cluster (i.e., DC, DE, DM, and DR) based on the estimated workload to meet the QoE of each multimedia user.Step 4.
The LBM assigns multimedia processing tasks to appropriate media clusters (i.e., DC, DE, DM, and DR) according to the nature of processing task. Furthermore, the LBM places each multimedia task into the appropriate queue of each computing cluster based on their priorities.Step 5.
If the processed multimedia task requires further processing, which is decided based on the nature of multimedia task, the task is placed into the appropriate priority queues of the next computing cluster; otherwise, they are sent to respective queue of transmission units for further processing.Step 6.
The transmission unit processes the multimedia tasks (e.g., conversion and forwarding) to meet the QoE at the intended receivers.


## 3.1. Priority-Based Queuing Model for Multimedia Computation

In this subsection, we describe our priority-based queuing model. As shown in Figure3, there are three different types of queues: (1) scheduling queue, (2) computing queues, and (3) transmission queues. In this paper, we assume N priority-classes of multimedia requests. Therefore, each multimedia request corresponds to a single priority-class at a time. Smaller priority numbers represent a higher priority-class. For example, the priority 1 multimedia request class has a higher priority than priority 2 multimedia request class. Furthermore, any priority-class i multimedia requests are classified with the help of four parameters: (1) average task size, T, which specifies the total number of instructions, (2) average arrival rate, λi, of priority-class i multimedia requests, which denotes the number of requests per second, (3) average result size, Ri, which is measured in bits, and (4) the upper bound of service response time, ϵi, which is measured in seconds. Moreover, in our scenario, each multimedia task is further divided into four subtasks (the subphases discussed previously). The priority of each multimedia request is assigned based on its criticality or importance; however, we will not discuss this factor in detail in this work.Figure 3
Priority-based queuing model for multimedia cloud computing architecture.The Scheduling Server (SS) schedules multimedia requests at scheduling rateμ for processing according to assigned or allocated priority-classes. For this purpose, each computing cluster (CC) contains N priority queues, as shown in Figure 3. Similarly, N transmission queues store the processed data or results to forward to the intended end users at transmission rate ξ. Multimedia requests of priority-class i arrivals are modeled by using a Poisson distribution with the λi arrival rate. Thus, the average arrival rate of all priority-class multimedia requests computed based on the Poisson process composition property is given as follows:(1)λ=∑i=1NλiThe SS schedules the multimedia requests with the highest priority first. Hence, the scheduling queue is modeled as preemptive priority M/M/1 with mean service rate η of the SS. Tisch is the mean service response time for scheduling priority-class i multimedia requests given in [35] as follows:(2)Tisch=1/μ1-σi-1sch+∑j=1iλj/μ21-σi-1sch1-σisch,∀i=1,2,…,Nwhere μ is the scheduling rate and σisch is given as follows:(3)σisch=∑j=1iλjμ,In order to stabilize the scheduling queue, the following condition should be satisfied:(4)σNsch=∑j=1Nλjμ<1Due to the same service rate for all priority-class multimedia requests, the total response time is the same as the M/M/1 queue. Hence, the mean service response time for scheduling all priority-class multimedia requests is computed as follows:(5)Tsch=1/μ1-λ/μIn our scenario, each multimedia task of priority-class i, Fi, is divided into four subtasks, or subphases denoted by Fik where k=1,2,3,4, and each subtask represents a unique computational phase. The highest priority multimedia tasks are computed first in a preemptive priority manner. The service time for multimedia requests of priority-class i is assumed to be exponentially distributed with mean time, Fik/Ck. Ck represents the total computational resources allocated to computing subphase k. Hence, the mean service response time for multimedia tasks of priority-class i in computational phase k is given in [36] as follows:(6)Ticomk=Fi/Ck1-σi-1comk+∑j=1iλjFj2/Ck21-σi-1comk1-σicomk,∀i=1,…,Nwhere σicomk is given as(7)σicomk=∑j=1iλjFjCk.Similar to the above, the following stabilizing condition is also applied to the computing queue:(8)σNcomk=∑j=1NλjFjCk<1.We assume very high-speed communications links within the computing clusters; therefore, the latency of moving multimedia subtasks from one computing cluster to another computing cluster is almost negligible. Thus, the mean service response time for multimedia tasks of priority-class i for all four computing subphases is given as follows:(9)Ticom=∑k=14TicomkFinally, the mean service time for computing of all types of multimedia priority-classes under unequal service rate distribution is computed as follows:(10)Tcom=∑i=1NλiTicomλMultimedia tasks processed through scheduling and computing queues are finally sent to the transmission queue at transmission rate ξ, where N priority queues store processed results of size Ri before forwarding them to the intended priority-class i end users. However, the fraction Ri/ξ represents the mean transmission time of exponentially distributed priority-class i results. Eventually, the mean service response time for transmitting/forwarding the results of priority-class i multimedia users is given as(11)Titra=Ri/ξ1-σi-1tra+∑j=1iλjRi2/ξ21-σi-1tra1-σitra∀i=1,…,Nwhere σitra is computed as(12)σitra=∑j=1iλjRiξ,and to ensure the stability of the transmission queue, the following condition must also hold:(13)σNcomk=∑j=1NλjFjCk<1.Finally, the service response time for transmitting all priority-class multimedia results is computed as given below:(14)Ttra=∑i=1NλiTitraλHowever, the factor Titra is computed in (11) above. Thus, based on the above queuing analysis, we find the total delay or latency of priority-class i multimedia tasks given as follows:(15)Titot=Tisch+Ticom+TitraThus, by using (2), (9), and (11), Titot can be represented as follows:(16)Titot=1/μ1-σi-1sch+∑j=1iλj/μ21-σi-1sch1-σisch+∑k=14Ticomk+Ri/ξ1-σi-1tra+∑j=1iλjRi2/ξ21-σi-1tra1-σitra∀i=1,…,NThus, by substituting the values of σi-1sch and σitra into (16), we get(17)Titot=1/μ1-∑j=1i-1λj/μ+∑j=1iλj/μ21-∑j=1i-1λj/μ1-∑j=1iλj/μ+∑k=14Ticomk+Ri/ξ1-∑j=1i-1λjRi/ξ+∑j=1iλjRi2/ξ21-∑j=1i-1λjRi/ξ1-∑j=1iλjRi/ξ∀i=1,…,NFinally, substituting the values of Ticomk and σicomk into (17), we get(18)Titot=1/μ1-∑j=1i-1λj/μ+∑j=1iλj/μ21-∑j=1i-1λj/μ1-∑j=1iλj/μ+∑k=14Fi/Ck1-∑j=1i-1λjFj/Ck+∑j=1iλjFj2/Ck21-∑j=1i-1λjFj/Ck1-∑j=1iλjFj/Ck+Ri/ξ1-∑j=1i-1λjRi/ξ+∑j=1iλjRi2/ξ21-∑j=1i-1λjRi/ξ1-∑j=1iλjRi/ξ∀i=1,…,NFurthermore, the total service response time for all types of priority-classes can be computed as(19)Ttot=Tsch+Tcom+Ttraby substituting the values of Tsch,Tcom, and Ttra into the above equation, we get(20)Ttot=1/μ1-λ/μ+∑i=1NλiTicomλ+∑i=1NλiTitraλAfter substituting the values of Ticom and Titra into (20), we get(21)Ttot=1/μ1-λ/μ+∑k=14∑i=1Nλi∑j=1iλjFj2/Ck2λ1-∑j=1i-1λjFj/Ck1-∑j=1iλjFj/Ck+∑i=1NλiFi/Ckλ1-∑j=1i-1λjFj/Ck+∑i=1NλiRi/ξλ1-∑j=1i-1λjRi/ξ+∑i=1Nλi∑j=1iλjRi2/ξ2λ1-∑j=1i-1λjRi/ξ1-∑j=1iλjRi/ξThus, the end user experiences satisfactory QoE if end-to-end latency (e.g., latency from scheduling till transmission) of multimedia requests of priority-class i is less than its predefined threshold (i.e., the upper bound of service time, ϵi). This QoE constraint is defined as follows:(22)Titot<ϵiSimilarly, MCC is considered to be efficient if it holds to the following conditions for all multimedia users of priority-class N:(23)Ttot<ϵHowever, if the MCC does not meet the above two conditions, more resources are added to meet the QoE conditions.


## 3.2. Step-by-Step Procedure of Multimedia Processing in MCC

The step-by-step working procedure of the proposed MCC framework shown in Figure4 is as follows.Figure 4
Working flow of MCC.Step 1.
The LBM receives the multimedia processing requests from different multimedia users and assigns the priority to each multimedia task based on its importance and criticality (e.g., delay) and places them into a request queue.Step 2.
The LBM periodically performs a queue analysis after everyt time interval to estimate the workload.Step 3.
The LBM assigns computing resources to each computing cluster (i.e., DC, DE, DM, and DR) based on the estimated workload to meet the QoE of each multimedia user.Step 4.
The LBM assigns multimedia processing tasks to appropriate media clusters (i.e., DC, DE, DM, and DR) according to the nature of processing task. Furthermore, the LBM places each multimedia task into the appropriate queue of each computing cluster based on their priorities.Step 5.
If the processed multimedia task requires further processing, which is decided based on the nature of multimedia task, the task is placed into the appropriate priority queues of the next computing cluster; otherwise, they are sent to respective queue of transmission units for further processing.Step 6.
The transmission unit processes the multimedia tasks (e.g., conversion and forwarding) to meet the QoE at the intended receivers.


## 4. Performance Analysis

In this section, we first discuss the experimental setup. Secondly, we describe performance evaluation schemes and performance evaluation criteria, and finally, we present the simulation results.


### 4.1. Experimental Setup

In this subsection, we describe our experimental setup. The performance of the proposed scheme is evaluated by using the CloudSim [30] simulator. It is a Java-based library model that is used worldwide for cloud-based simulations [37]. The Cloudsim model cloud-based content distribution service, which sets the corresponding application complexity according to the calculation requests of the service, ensures the validity of the simulation. We designed and modeled the cloud into three main components: (I)the LBM, (II) the CC unit, and (III) the TU unit. We perform simulations on multimedia images and for this purpose, we changed the characteristics of the cloudlet class and modeled it according to our requirements. The arrival of multimedia requests follows a Poisson distribution with t time intervals. We evaluate the performance of the proposed scheme with other schemes and hardware (i.e., RAM, Million Instruction Per Second (MIPS), and the number of CPUs), as presented in Table 2.Table 2
Simulation settings.
RAM MIPS CPUs 4096 4200 2


### 4.2. Performance Evaluation Scheme and Criteria

In this subsection, we discuss the performance evaluation schemes and evaluation criteria. For simulation study, we evaluate and compare the proposed scheme’s static resource allocation and baseline single cluster schemes. In the static resource-allocation scheme, computing resources for each computing cluster are allocated at initialization time and computing resources are not periodically updated. However, in the baseline single cluster scheme, all four subphases are collectively computed on a single cluster. Our performance evaluation criteria are as follows.Computing Cost. Minimizing the computing resources costs while providing better QoE is a challenging task for any cloud service provider. In our case, computing resources costs are also directly proportional to the number of virtual machines reserved for computing multimedia tasks. The more computing resources deployed, the higher the computing costs and similarly, lesser or minimum computing resources means minimum costs.Response Time. The response time, or end-to-end delay, is the time measured from when the multimedia request is received at the LBM until the requesting user receives the required response. However, in our case, QoE is directly proportional to the value of the response time. For example, if a particular multimedia user does not receive the required response in time, then that user experiences low QoE, and similarly, if a multimedia user receives the required response in time, that user experiences better QoE.


### 4.3. Simulation Results

This subsection discusses the simulation results of the proposed scheme, compared with the baseline single cluster allocation and static allocation schemes. Figure5 presents the performance evaluation results of the proposed scheme with the static resource allocation scheme in terms of response time under the configuration settings, such as a virtual machine with processing speed of 4200 MIPS, two CPUs, and 4 GB of RAM, as given in Table 2. We can see from the figure that the static scheme performs better when the number of tasks or cloudlets is fewer, but as the cloudlets increase in number, the response time also increases, so that consequently reduces the QoE experienced at the end terminal (i.e., the receiver). However, the resources in the proposed scheme are periodically updated according to total workload information. Therefore, it performs better even with more tasks and provides guaranteed QoE to multimedia users.Figure 5
Proposed scheme vs. the static resource allocation scheme.Figure6 presents the simulation results of the proposed scheme compared with the baseline single cluster allocation scheme in terms of response time under the simulation settings presented in Table 2. In the single cluster computing scheme, the response time increases as the cloudlets increase. This happens because, in the baseline single cluster-based computing scheme, a single cluster is responsible for performing all four subphases of multimedia-related tasks. But, in the proposed scheme, image or multimedia-task processing is distributed over four different and dedicated computing clusters. Hence, it is clear from Figure 6 that the proposed scheme performs better than the single cluster-based computing scheme and provides the guaranteed QoE to multimedia users.Figure 6
Proposed scheme vs. the single cluster allocation scheme.Figure7 shows simulation results of the proposed scheme compared with the static resource allocation scheme in terms of the amount of computing resources (i.e., the number of virtual machines allocated to computing the supplied multimedia tasks). Thus, Figure 7 clearly shows that, with an increase in the number of cloudlets (i.e., multimedia tasks), the number of virtual machines also increases. However, the amount of computing resources in the static resource allocation scheme is constant. This is because the proposed scheme aims at maintaining a minimum response time and providing better QoE to multimedia users.Figure 7
Proposed scheme vs. static resource allocation scheme.


## 4.1. Experimental Setup

In this subsection, we describe our experimental setup. The performance of the proposed scheme is evaluated by using the CloudSim [30] simulator. It is a Java-based library model that is used worldwide for cloud-based simulations [37]. The Cloudsim model cloud-based content distribution service, which sets the corresponding application complexity according to the calculation requests of the service, ensures the validity of the simulation. We designed and modeled the cloud into three main components: (I)the LBM, (II) the CC unit, and (III) the TU unit. We perform simulations on multimedia images and for this purpose, we changed the characteristics of the cloudlet class and modeled it according to our requirements. The arrival of multimedia requests follows a Poisson distribution with t time intervals. We evaluate the performance of the proposed scheme with other schemes and hardware (i.e., RAM, Million Instruction Per Second (MIPS), and the number of CPUs), as presented in Table 2.Table 2
Simulation settings.
RAM MIPS CPUs 4096 4200 2


## 4.2. Performance Evaluation Scheme and Criteria

In this subsection, we discuss the performance evaluation schemes and evaluation criteria. For simulation study, we evaluate and compare the proposed scheme’s static resource allocation and baseline single cluster schemes. In the static resource-allocation scheme, computing resources for each computing cluster are allocated at initialization time and computing resources are not periodically updated. However, in the baseline single cluster scheme, all four subphases are collectively computed on a single cluster. Our performance evaluation criteria are as follows.Computing Cost. Minimizing the computing resources costs while providing better QoE is a challenging task for any cloud service provider. In our case, computing resources costs are also directly proportional to the number of virtual machines reserved for computing multimedia tasks. The more computing resources deployed, the higher the computing costs and similarly, lesser or minimum computing resources means minimum costs.Response Time. The response time, or end-to-end delay, is the time measured from when the multimedia request is received at the LBM until the requesting user receives the required response. However, in our case, QoE is directly proportional to the value of the response time. For example, if a particular multimedia user does not receive the required response in time, then that user experiences low QoE, and similarly, if a multimedia user receives the required response in time, that user experiences better QoE.


## 4.3. Simulation Results

This subsection discusses the simulation results of the proposed scheme, compared with the baseline single cluster allocation and static allocation schemes. Figure5 presents the performance evaluation results of the proposed scheme with the static resource allocation scheme in terms of response time under the configuration settings, such as a virtual machine with processing speed of 4200 MIPS, two CPUs, and 4 GB of RAM, as given in Table 2. We can see from the figure that the static scheme performs better when the number of tasks or cloudlets is fewer, but as the cloudlets increase in number, the response time also increases, so that consequently reduces the QoE experienced at the end terminal (i.e., the receiver). However, the resources in the proposed scheme are periodically updated according to total workload information. Therefore, it performs better even with more tasks and provides guaranteed QoE to multimedia users.Figure 5
Proposed scheme vs. the static resource allocation scheme.Figure6 presents the simulation results of the proposed scheme compared with the baseline single cluster allocation scheme in terms of response time under the simulation settings presented in Table 2. In the single cluster computing scheme, the response time increases as the cloudlets increase. This happens because, in the baseline single cluster-based computing scheme, a single cluster is responsible for performing all four subphases of multimedia-related tasks. But, in the proposed scheme, image or multimedia-task processing is distributed over four different and dedicated computing clusters. Hence, it is clear from Figure 6 that the proposed scheme performs better than the single cluster-based computing scheme and provides the guaranteed QoE to multimedia users.Figure 6
Proposed scheme vs. the single cluster allocation scheme.Figure7 shows simulation results of the proposed scheme compared with the static resource allocation scheme in terms of the amount of computing resources (i.e., the number of virtual machines allocated to computing the supplied multimedia tasks). Thus, Figure 7 clearly shows that, with an increase in the number of cloudlets (i.e., multimedia tasks), the number of virtual machines also increases. However, the amount of computing resources in the static resource allocation scheme is constant. This is because the proposed scheme aims at maintaining a minimum response time and providing better QoE to multimedia users.Figure 7
Proposed scheme vs. static resource allocation scheme.


## 5. Conclusion

In this paper, we proposed a dynamic priority-based efficient resource allocation scheme for multimedia-enabled vehicular users in order to address challenges like fast response times, guaranteed Quality of Experience, and minimum computing resources costs. In the proposed scheme, every multimedia-related task is divided into four subphases and each subphase is computed by a dedicated computing cluster. Priority queues are used to ensure on-time response delivery to different multimedia end users with different priorities. Moreover, in the proposed scheme, the computing resources are dynamically updated based on workload information estimated by a load manager. The performance of the proposed scheme is evaluated in terms of response time and computing costs using the CloudSim Simulator against the static resource allocation scheme and the baseline single cluster-based computing scheme. The simulation results show that the proposed scheme outperforms the static resource allocation scheme and the baseline single cluster-based computing technique.



---

*Source: 6235379-2018-09-27.xml*