A Novel Model for Competition and CooperationAmong Cloud Providers

Tram Truong-Huu, Member, IEEE , and Chen-Khong Tham, Member, IEEE

Abstract—Having received significant attention in the industry, the cloud market is nowadays fiercely competitive with many cloudproviders. On one hand, cloud providers compete against each other for both existing and new cloud users. To keep existing usersand attract newcomers, it is crucial for each provider to offer an optimal price policy which maximizes the final revenue and improvesthe competitive advantage. The competition among providers leads to the evolution of the market and dynamic resource prices overtime. On the other hand, cloud providers may cooperate with each other to improve their final revenue. Based on a Service LevelAgreement, a provider can outsource its users’ resource requests to its partner to reduce the operation cost and thereby improve thefinal revenue. This leads to the problem of determining the cooperating parties in a cooperative environment. This paper tackles thesetwo issues of the current cloud market. First, we solve the problem of competition among providers and propose a dynamic price policy.We employ a discrete choice model to describe the user’s choice behavior based on his obtained benefit value. The choice model isused to derive the probability of a user choosing to be served by a certain provider. The competition among providers is formulated asa non-cooperative stochastic game where the players are providers who act by proposing the price policy simultaneously. The gameis modelled as a Markov Decision Process whose solution is a Markov Perfect Equilibrium. Then, we address the cooperation amongproviders by presenting a novel algorithm for determining a cooperation strategy that tells providers whether to satisfy users’ resourcerequests locally or outsource them to a certain provider. The algorithm yields the optimal cooperation structure from which no providerunilaterally deviates to gain more revenue. Numerical simulations are carried out to evaluate the performance of the proposed models.

Index Terms—Cloud computing, dynamic pricing, cooperation, Markov Decision Process, Markov Perfect Equilibrium, game theory

F

1 INTRODUCTIONDuring the past few years, cloud computing has re-ceived significant investments in the industry. Manycloud providers are participating in the market, forminga competitive environment which is referred to as multi-user and multi-provider cloud market. Hereafter, we willuse the terms “providers” and “users” to refer to thecloud actors. Since the amount of resources in a user’srequest is much smaller than the capacity of a provider,the user’s request can be satisfied by any provider. A ra-tional user will choose the provider whose resources bestsatisfy his computational needs, and the resource usagecost does not exceed his budgetary constraint. The user’ssatisfaction can be evaluated through a utility measurewhich depends not only on the resource properties butalso on the user’s preference to choose certain providers,i.e., two providers with the same resource capacities andusage price may be considered different for a user due tothe user’s choice behavior and loyalty. Furthermore, thetask of optimally pricing cloud resources to attract usersand improve revenue is very challenging [1]. They needto take into account a wide range of factors includingthe preferences of users, resource capacities and potentialcompetition from other providers. A provider naturallywishes to set a higher price to get a higher revenue;however, in doing so, it also bears the risk of discourag-ing demand in the future. On the other hand, they alsolook for the means to cooperate with other providers toreduce the operation cost and therefore improve theirfinal revenue. In this paper, we study both problems of

• The authors are with the Department of Electrical & Computer Engineer-ing, National University of Singapore. Postal address: Block E4, Level 6,Room 12, Engineering Drive 3, Singapore 117583.E-mail: eletht,eletck@nus.edu.sg

the current cloud market: competition and cooperationamong providers.

The competition among providers leads to the dynam-ics of cloud resource pricing. Modelling this competitioninvolves the description of the user’s choice behaviourand the formulation of the dynamic pricing strategies ofproviders to adapt to the market state. To describe theuser’s choice behavior, we employ a widely used discretechoice model, the multi-nomial logit model [2], which isdefined as a utility function whose value is obtained byusing resources requested from providers. From the util-ity function, we derive the probability of a user choosingto be served by a certain provider. The choice probabilityis then used by providers to determine the optimalprice policy. The fundamental question is how to de-termine the optimal price policy. When a provider joinsthe market, it implicitly participates in a competitivegame established by existing providers. Thus, optimallyplaying this game helps providers to not only survivein the market, but also improve their revenues. To giveproviders a means to solve this problem, we formulatethe competition as a non-cooperative stochastic game [3].The game is modelled as a Markov Decision Process(MDP) [4] whose state space is finite and computedby the distribution of users among providers. At eachstep of the game, providers simultaneously propose newprice policies with respect to the current policies of othercompetitors such that their revenues are maximized.Based on those price policies, users will decide whichprovider they will select to request resources. This alsodetermines whether the market will move to a new stateor not. The solution of the game is a Markov PerfectEquilibrium (MPE) such that none of providers canimprove their revenues by unilaterally deviating fromthe equilibrium in the long run.

IEEE TRANSACTIONS ON CLOUD COMPUTING VOL:PP NO:99 YEAR 2014

Fig. 1: Overall architecture of a Cloud-of-Clouds system.

On the second problem, the cooperation based on afinancial option allows providers to enhance revenueand acquire the needed resources at any given time [5].The revenue depends on the total operation cost whichincludes a cost to satisfy users’ resource requests (i.e.,cost for active resources) and another cost for maintain-ing data center services (i.e., cost for idle resources). Weaddress the problem of cooperation among providersby first employing the learning curve [6] to model theoperation cost of providers and then introducing a novelalgorithm that determines the cooperation structure. Thecooperation decision algorithm uses the operation costcomputed based on the learning curve model and pricepolicies obtained from the competition part as parame-ters to calculate the final revenue when outsourcing orlocally satisfying users’ resource requests. The coopera-tion among providers makes the cloud market becomea united cloud environment, called Cloud-of-Clouds envi-ronment as illustrated in Fig. 1. In this architecture, theCloud-of-Clouds Broker is responsible for coordinatingthe cooperation among providers, receiving users’ re-source requests and also doing accounting management.

The rest of this paper is organized as follows. Afterdiscussing related work in Section 2, we introduce in Sec-tion 3 our assumption and the relevant models for users’resource requests, providers’ operation costs and rev-enues. We describe in Section 4 the game formulation forcompetition among providers. In Section 5, we presentthe method for solving the stochastic game which resultsin the MPE. Section 6 presents the model and algorithmfor cooperation among providers. Section 7 presents thenumerical simulations and analysis of results that assessthe validity of the proposed model. Finally, we concludethe paper in Section 8.

2 RELATED WORK2.1 Dynamic pricing and competitionDynamic pricing in the cloud has gained considerable at-tention from both industry and academia. Amazon EC2has introduced a “spot pricing” feature for its resourceinstances where the spot price is dynamically adjustedto reflect the equilibrium prices that arises from resourcedemand and supply. Analogously, a statistical modelof spot instance prices in public cloud environmentshas been presented in [7], which fits Amazons spotinstances prices well with a good degree of accuracy.

To capture the realistic value of the cloud resources,the authors of [8] employ a financial option theoryand treat the cloud resources as real assets. The cloudresources are then priced by solving the finance model.Also based on financial option theory, in [5], a cloudresource pricing model has been proposed to addressthe resource trading among members of a federatedcloud environment. The model allows providers to avoidthe resource over-provisioning and under-provisioningproblems. But there is an underlying assumption is thatthere are always providers willing to sell call options.

In [9] and [10], the authors presented their researchresults on dynamic pricing for cloud resources. While[9] studied the case of a single provider operating anIaaS cloud with a fixed capacity, [10] focussed on thecase of an oligopoly market with multiple providers.However, both [9] and [10] make the assumption that theuser’s resource request is a concave function with respectto resource prices. The amount of resources requestedwill decrease when prices increase. This assumption isnot practical when users have a processing deadline orarchitectural requirements for their execution platform.Users therefore have to request the required amount ofresources no matter what the prices are. In [11] and [12],the authors presented auction-based mechanisms to de-termine optimal resource prices, taking into account theuser’s budgetary and deadline constraints. However,they considered the pricing model of only one provider.In contrast, we consider the realistic case of the currentcloud market with multiple providers. In addition, usersmay have their preferences in choosing to be served byparticular providers.

2.2 Game theory in utility computingGame theory has been widely applied in economicstudies for dynamic pricing competition [13], [14], [15].In utility computing, game theory has been appliedto study different issues: scheduling and resource al-location [16], [17], dynamic pricing [18] and revenueoptimization [19]. In [16], a game-theoretic resource al-location algorithm has been proposed to minimize theenergy consumption while guaranteeing the processingdeadline and architectural requirement. In [17], a user-oriented job allocation scheme has been formulated asa non-cooperative game to minimize the expected costof executing users’ tasks. The solution is a Nash equilib-rium which is obtained using a distributed algorithm.However, none of these works considered the user’schoice behavior, although some of them assume thatresources are owned by different resource owners.

2.3 Cooperation among providersCooperation among providers in cloud computing hasbeen extensively studied with two research approaches:cloud federation and coalitional formation based oncoalitional game theory.

The idea of federating systems was originally pre-sented for grid computing. For instance, in [20] and [21],the authors used the federation approach to get morecomputing resources to execute large scale applications

in a distributed grid environment. The application of thefederation approach in the cloud was initially proposedwithin the RESERVOIR project [22]. Nevertheless, theaforementioned works focused only on aggregating asmuch resources as possible to satisfy users’ resourcerequests. They did not consider the economic issuewhich is one of the intrinsic characteristics of cloudcomputing. In [23], the authors presented an economicmodel along with a federated scheduler which allow aprovider, operating in a federated cloud, to increase thefinal revenue by saving capital and operation costs.

Based on coalitional game theory, [24] studied theproblem of motivating self-interested providers to joina determined horizontal dynamic cloud federation plat-form and the problem of deciding the amount of re-sources to be allocated to the federation. The authorsof [19] used the coalitional game approach to formcloud federations and share the obtained revenue amongcoalition members fairly. However, this work did notconsider the operation cost of providers which is animportant factor in the economic model. In this paper,we consider the realistic case of the current cloud marketwhere providers may have different operation costs.Cooperation among providers may reduce the operationcost and therefore improve the final revenue.

3 SYSTEM FORMULATION3.1 AssumptionsIn this paper, we consider providers which offer Infras-tructure as a Service (IaaS) from which users can requesta number of cloud resource instances and deploy theirown platform for executing their applications. Table 1presents all the notations used throughout this paper.

There are a total of N providers on the cloud market.These providers offer a number of resource types de-noted by M , e.g., Amazon EC2 offers 4 types of resourcescalled VM instances: small, medium, large and extralarge1. Depending on the capacity of each resource type,providers define a per unit price to charge users forresource usage. We denote vector pi = (pi1, pi2, . . . , piM )as the price vector of provider i where pij with j ∈[1, . . . ,M ] is the per unit price of resource type j(US$/hour). For each resource type of each provider, weadditionally define the per unit benefit λij , i.e., per unitbenefit of resource type j offered by provider i, to reflectthe relative capacity of the resource in satisfying theuser’s computational needs. A higher benefit resourcemay be more expensive than a lower benefit one.

3.2 Users’ resource requestsWe assume that, in total, K users distribute their re-source requests among N providers. User k places arequest for a bundle of resources rather than for in-dividual items which is the usual case in the cloudenvironment. Therefore, the resource request of userk is represented by a vector rk = (rk1, rk2, . . . , rkM )where rkj with j ∈ [1, . . . ,M ] is the required number ofinstances of resource type j. For user k, we additionally

1. Amazon EC2 Instances: http://aws.amazon.com/ec2/pricing

TABLE 1: Mathematical notations

Notation DescriptionN Number of providers on the cloud marketM Number of resource types of each providerK Number of users on the cloud marketi Index of cloud providersj Index of resource typesk Index of cloud usersbk Budgetary constraint of user kϕi Learning factor of provider i

ψijMaximum number of instances of resource typej offered by provider i

λijPer unit benefit of resource type j offered byprovider i

pijPer unit price of resource type j charged byprovider i

coijOperation cost of the first active instance ofresource type j owned by provider i

coijOperation cost of the first idle instance of re-source type j owned by provider i

Ω State space of stochastic game/the cloud marketω State of the market (ω ∈ Ω)βi Individual state of provider iγ Discount factor of moneyηki Preference of user k to provider i

rkjNumber of instances of resource type j re-quested by user k

ckiCost that user k needs to pay when requestingresources from provider i

Uki Utility of user k being served by provider iPki Probability of user k choosing provider iCo

i Operation cost of provider i for active resources

C oi Operation cost of provider i for idle resources

Ci Total operation cost of provider i

Coutsourceii′

Outsourcing cost of provider i when outsourc-ing to provider i′

Rlocali

Revenue of provider i when satisfying all users’resource requests locally

Routsourceii′

Revenue of provider i when outsourcing allusers’ resource requests to provider i′

Rhostingi

Revenue of provider i when hosting users’ re-source requests from other providers

Vi Discounted sum of future revenue of provider i

define bk as his budgetary constraint. Given the pricepolicies of all providers, the cost that user k needs topay for using resources offerred by provider i is definedas cki =

∑Mj=1 rkjpij , subject to cki 6 bk,∀i ∈ [1, . . . , N ],

and ∀k ∈ [1, . . . ,K].

3.3 Market stateThe state of the market is given by ω = (ω1, ω2, . . . , ωK)where ωk ∈ 1, . . . , N is the identification/index of theprovider to which user k sends his resource request, i.e.,user k chooses to be served by provider ωk. Let Ω denotethe state space which is the set of possible states of themarket. We define a function δ : Ω×1, . . . , N → 0, 1Kto convert the market state to the individual state ofa specific provider. Let βi be the individual state ofprovider i corresponding to the market state ω, we have

βi = δ(ω, i) = (βi1, βi2, . . . , βiK), βik =

1 if ωk = i,

0 otherwise.(1)

3.4 Providers’ operation costs

In the current cloud market, providers may have dif-ferent resource capacities and operation managementprocesses. This leads to different operation costs amongproviders. The learning curve model [6] assumes thatas the number of production units are doubled, themarginal cost of production decreases by a fixed factor.One minus this factor is called learning factor. Theprovider with a higher learning factor has to pay ahigher operation cost than that of the provider with alower learning factor when running the same numberof production units. Mathematically, given the individ-ual state βi of provider i, we denote vector ai =(ai1, ai2, . . . , aiM ) as the list of numbers of active in-stances of each resource type operated by provider i, i.e.,these instances are in production for satisfying users’ re-source requests. Hence, aij is computed as

∑Kk=1 βikrkj .

The total cost of operating active instances is then

Coi (βi) =

MXj=1

coija1+log2 ϕiij

1 + log2 ϕi(2)

where coij is the operation cost of the first active instanceof resource type j operated by provider i, and ϕi is thelearning factor of provider i. It is to be noted that thelearning factor is the same for all resource types operatedby the same provider.

In addition to active resource instances, providers alsoneed to maintain the basic services for idle resourceinstances. Let vector ψi = (ψi1, ψi2, . . . , ψiM ) denote theresource capacities of provider i, where ψij is maxi-mum number of instances of resource type j offeredby provider i, the number of idle instances of eachresource type is represented by vector (ψi1 − ai1, ψi2 −ai2, . . . , ψiM−aiM ). The total operation cost for these idleresource instances is therefore

C oi (βi) =M∑j=1

coij(ψij − aij)1+log2 ϕi

1 + log2 ϕi(3)

where coij is the operation cost of the first idle instanceof resource type j operated by provider i.

The total operation cost of provider i is therefore

Ci(βi) = Coi (βi) + C o

i (βi)

=

MXj=1

coija1+log2 ϕiij

1 + log2 ϕi+

MXj=1

coij (ψij − aij)1+log2 ϕi

1 + log2 ϕi.

(4)

3.5 Providers’ final revenues

Given the price policy pi = (pi1, pi2, . . . , piM ) and theindividual state βi of provider i, the total gross revenueof provider i is defined as follows:

Rgrossi (βi,pi) = R

grossi (δ(ω, i),pi)

=

KXk=1

βikcki =

KXk=1

βik

MXj=1

rkjpij

!.

(5)

Combining the gross revenue with the total operationcost, we obtain the final revenue of provider i as follows:

Ri(βi,pi) = Rgrossi (βi,pi)− Ci(βi) =

KXk=1

βikcki

−MX

j=1

coija1+log2 ϕiij

1 + log2 ϕi−

MXj=1

coij (ψij − aij)1+log2 ϕi

1 + log2 ϕi.

(6)

4 DYNAMIC RESOURCE PRICING AND COMPE-TITION AMONG PROVIDERS4.1 Stochastic game formulation for competitionWe formulate the competition among providers as astochastic game [25]. The game is then modelled as aMarkov Decision Process (MDP) which is defined bya four-tuple (Ω,A, R, P ). Ω is the state space of themarket. At any time, the state of the market is givenby ω = (ω1, . . . , ωK) where ωk ∈ 1, . . . , N is theidentification or index of the provider by which userk chooses to be served. The size of state space Ω is|Ω| = NK . A is the action space. Providers are theplayers of the game who act by proposing the pricepolicy simultaneously. R is the reward function whichis the total final revenue of each provider and P is thetransition probability. For instance, P (ω′|ω,p1, . . . ,pN )is the probability of transitioning to state ω′ given thatthe market is at state ω and providers propose pricepolicies (p1, . . . ,pN ). More precisely, at state ω ∈ Ω,provider i proposes a price policy pi = (pi1, . . . , piM ) toattract users sending resource requests to it in the nextperiod. The objective of each provider is therefore to findan optimal price policy pi = (pi1, . . . , piM ) at all states ωthat maximizes the discounted sum of future revenue:

Vi(ω, p1, . . . , pN ) =

∞Xt=0

γtEˆRt

i|p1, . . . , pN ,ω0 = ω˜, (7)

where Rti is the revenue received at period t as definedin (6). The game proceeds as follows:Step 1. Assuming that the game is currently at the end

of period t − 1. The state of the market is ω inwhich the individual state of provider i is βi andstate of all providers other than i is β−i. β−i isobservable to provider i.

Step 2. Given this information, all providers in the mar-ket simultaneously propose a new price policy.They can increase or decrease the price to in-crease the chance that users will send resourcerequests to them in the next period t.

Step 3. Depending on the providers’ price policies, usersthen decide which provider they will be servedby. The market moves to state ω′ at period t.

Step 4. In the period t, provider i will receive a totalrevenue of Rti as defined in (6). The game thenrepeats again from Step 1 to Step 4.

Solving this game results in the optimal price policiesfor all providers. The optimal solution is an MPE whichassures the stability of the solution: no provider canachieve a better revenue by deviating unilaterally fromhis or her Markov strategy as long as the other providerscontinue to use their Markov strategies [4]. It is well-known that the use of Markov strategies in a non-cooperative game may prevent the attainment of efficient

outcomes which are the Pareto Optima [26]. However,since providers pursue their own self-interest, they donot have incentives to play according to Pareto Optimain a non-cooperative game. For more discussion on MPEand Pareto Optima, we refer the reader to [27]. Yet, whena new provider joins the market, the game changes inthe number of players and providers have to changetheir price policies to take into account the potentialcompetitive advantage of the new provider. Thus, thegame needs to be re-solved once the market changes.

4.2 User utility function and choice probability

In the current cloud market, users can easily compareresource prices of all providers and calculate the ob-tained utility before deciding to be served by a cer-tain provider. Understanding the user’s choice behav-ior can help providers to strengthen their competitiveadvantage. Discrete choice models have been widelyused to describe the user’s choice behavior and de-rive the choice probability from the principle of utility-maximization [15]. In this paper, we employ the multi-nomial logit (MNL) model based on its broad adop-tion [2]. For more discussion on the MNL model used inmarketing science literature, we refer the reader to [28].

Naturally, with the same amount of resources re-quested from a provider, the user’s utility is inverselyproportional to the cost he pays to the provider. Wedefine the utility function Uki of user k to provider ias follows:

Uki = αki − cki + ηki = vki + ηki, (8)

where αki =∑Mj=1 rkjλij is the total benefit received by

using resources of provider i, cki =∑Mj=1 rkjpij is the

cost that user k pays to provider i, and ηki is the pref-erence of user k to provider i. For ease of presentation,we define an additional variable vki = αki − cki.

As shown in (8), the user’s utility is decomposed intotwo parts: the first part, labeled as vki, that is observableby providers, and the second part denoted by ηki whichis the user’s preference to a provider to whom it isunknown. This unknown part is therefore treated asrandom variable. We assume that random variable ηki isan i.i.d extreme value, i.e., the distribution is also calledthe Gumbel distribution and type I extreme value [29].The probability density of ηki is f(ηki) = e−ηkie−e

−ηki ,and the cumulative distribution is F (ηki) = e−e

−ηki .We can now derive the logit choice probability, de-

noted as Pki, that user k chooses to be served by provideri as follows:

Pki = Prob(Uki > Uki′ ,∀i′ 6= i)= Prob(vki + ηki > vki′ + ηki′ ,∀i′ 6= i)= Prob(ηki′ < ηki + vki − vki′ ,∀i′ 6= i).

(9)

Based on the density function and the cumulative dis-tribution, some algebraic manipulation of Eq. (9) resultsin a succinct, closed-form expression:

Pki =evki∑i′ e

vki′, (10)

which is the probability of user k choosing provider ito request resources. For the detailed algebra that leadsto (10), we refer the reader to [2] (chapter 3).

4.3 State transition probabilityGiven the choice probability of user k choosing to beserved by provider i, Pki = evki/

∑i′ e

vki′ , the probabilityof user k not choosing provider i is then 1− Pki. Giventhe current state of the market, ω, we now compute theprobability of a transition from state ω to ω′. Accordingto Eq. (1), the corresponding current individual state ofprovider i is βi = δ(ω, i), and the future individual stateis β′i = δ(ω′, i). The weighted probability of a transitionfrom the current state βi to the future state β′i of provideri is defined as follows:

qi(β′i|βi,pi) = σi(βi|β′i)

KYk=1

`β′ikPki + (1− β′ik)(1− Pki)

´, (11)

where σi(βi|β′i) = exp

(−∑Kk=1(βik − β′ik)2

)is a weight-

ing factor that is small when the sum of squared distancebetween state βi and β′i is large. The weighted proba-bility of the market to transit from state ω to state ω′ is

q(ω′|ω,p1, . . . ,pN ) =

NYi=1

qi(β′i|βi,pi), (12)

where βi = δ(ω, i) and β′i = δ(ω′, i). We now have thenormalized state transition probability:

P (ω′|ω,p1, . . . ,pN ) =q(ω′|ω,p1, . . . ,pN )X

θ∈Ω

q(θ|ω,p1, . . . ,pN ). (13)

5 SOLVING THE STOCHASTIC GAME

We now present the algorithm for solving the game. Thealgorithm’s output is the optimal price policies of allproviders. We also analyze a limitation of the algorithmand introduce a method to overcome this limitation.

5.1 Algorithm for finding optimal price policies p

Since the game modelled as an MDP satisfies Bellman’sPrinciple of Optimality which indicates that “an optimalpolicy has the property that whatever the initial state andinitial action are, the remaining actions must constitutean optimal policy with regard to the state resulting fromthe first action”, it can be solved via dynamic program-ming. The algorithm is based on the Bellman equationwhich is derived by summarizing the rewards of thecurrent period and that of all future periods associatedwith a discount factor [30]. At the end of period t − 1,when the market is at state ω, the corresponding Bellmanequation is

Vi(ω) = maxpi∈RM+

nRi(δ(ω, i),pi) + γEω′

hVi(ω

′)|ω,pi,p−i

io, (14)

where pi is the price policy of provider i at stateω, p−i is the price policies of providers other than i,Ri(δ(ω, i),pi) is the final revenue of provider i receivedat state ω with price policy pi as defined in (6), and

γEω′

[Vi(ω′)|ω,pi,p−i

]is the discounted expected fu-

ture revenue of provider i where the expectation istaken over the successor state ω′. Solving (14) resultsin the maximal revenue and the optimal price policy ofprovider i at state ω as follows

pi(ω) = arg maxpi∈RM+

nRi(δ(ω, i),pi) + γEω′

hVi(ω

′)|ω,pi,p−i

io.

(15)By making explicit the expectation operator in (14)

and (15), we can derive a new formula for the expectedrevenue in (16) and the optimal price policy in (17).

Vi(ω) = maxpi∈RM+

Ri(δ(ω, i),pi) + γ

Xω′∈Ω

P (ω′|ω,pi,p−i)Vi(ω′)

ff(16)

pi(ω) = arg maxpi∈RM+

Ri(δ(ω, i),pi) + γ

Xω′∈Ω

P (ω′|ω,pi,p−i)Vi(ω′)

ff(17)

V ti (ω) = max

pi∈RM+

Rt

i(δ(ω, i),pti)+γ

Xω′∈Ω

P (ω′|ω,pti,p

t−1−i )V t−1

i (ω′)

ff(18)

pti(ω) = arg max

pi∈RM+

Rt

i(δ(ω, i),pti)+γ

Xω′∈Ω

P (ω′|ω,pti,p

t−1−i )V t−1

i (ω′)

ff(19)

Each provider has its own version of Eqs. (16) and (17).This implies that for each provider and for each initialstate, maximization is performed with respect to a non-linear equation with M variables pij , with ∀i = 1, . . . , Nand ∀j = 1, . . . ,M . In total, there are N×|Ω| = N×NK =NK+1 non-linear equations, where N is the number ofproviders, K is the number of users and NK is the sizeof state space. The best response of all these non-linearequations must satisfy the users’ budgetary constraints,i.e., cki 6 bk,∀i ∈ [1, . . . , N ], and ∀k ∈ [1, . . . ,K].

Two well-known algorithms to solve the maximizationof systems of non-linear equations are Gauss-Jacobi andGauss-Seidel [31], [32] which are both iterative-basedmethods. The main difference between them is the wayto update the value and price policy in each iteration.We refer the reader to [33] for a more detailed discussionon both methods. In this paper, we advocate the Gauss-Seidel method as it has the advantage that information isused as soon as it becomes available. The full algorithmis shown in Algorithm 1. It is noted that, during theexecution of the while loop (lines 4–12) whenever newvalues V ti (ω) and pti(ω) are available, they are imme-diately used to replace the old values V t−1

i (ω), pt−1i (ω)

within the same iteration. In lines 6 and 7, the cc variableis defined as the convergence criterion; it is compared toa small number ε for stopping the algorithm.

5.2 Avoiding the curse of dimensionalityThe key difficulty of the model is computing the expec-tation over all successor states in (16) and (17). As thesize of the state space is NK where N is the number ofproviders and K is the number of users, it will increaseexponentially when N or K increases. Thus, the number

Algorithm 1 Finding optimal price policies p

Input: Users’ resource requests and budgetary con-straints: rk and bk, k = 1, . . . ,K. Information aboutall providers: ϕi, ψij , λij , coij and coij , i = 1, . . . , N, j =1, . . . ,M . Discount factor: γ.

Output: Optimal price policies: p1: Make initial guesses for the value function V 0

i (ω) ∈R and the price policy p0

i (ω) ∈ RM+ for each provideri = 1, . . . , N in each state ω ∈ Ω. Pick a random stateto be the initial state of the market;

2: stop← 0; /*stop condition*/; t← 0 /*iteration*/3: while stop 6= 1 do4: Update the value function V ti (ω) and the price

policy pti(ω) for all providers according toEqs. (18) and (19), respectively. In (18) and (19),pt−1−i refers to the price policies of providers other

than provider i at iteration t− 1;5: cc← maxω∈Ω

∣∣∣(V t(ω)− V t−1(ω)/(

1 + V t(ω)∣∣∣;

6: if cc < ε then /*satisfied by all providers*/7: stop← 1;8: else9: Compute the next state of the market;

10: t← t+ 1;11: end if12: end while

2222

2212

2122

2221

1222

Fig. 2: Generation of successor states: the current stateis 2222, which means all users choose to be served byProvider 2, there will be 5 successor states in which userscan stay unchanged or switch to Provider 1.

of successor states also increases. The problem becomesvery severe when applying this model to today’s cloudmarket with many thousands of users. To cope with theexplosion in the number of successor states, we assumethat the changes in the providers’ price policies cause thestate transitions that are restricted to going one level up,one level down or staying the same, i.e., provider willgain, lose one user or stay with the same set of users.Thus, the number of successor states is only K+ 1. Witha total of N providers, the total number of successorstates is N(K + 1). Fig. 2 shows an example of the newset of successor states generated from a current state inthe market with 2 providers and 4 users.

Applying this method to Algorithm 1, the while loopneeds to be slightly modified such that from the currentstate ω ∈ Ω, the algorithm first generates the new setof successor states and then uses this set to update thevalue function V ti (ω) and the price policy pti(ω) for eachprovider according to Eqs. (18) and (19), respectively.

6 COOPERATION AMONG PROVIDERSIn this section, we first present an overview on a Cloud-of-Clouds system. Then, we describe the cooperation

method among providers based on the mathematical for-mulations of the operation cost and revenue. Finally, wepresent the algorithm for making cooperation decisions.

6.1 Overview of Cloud-of-Clouds system

Increasing resource demands with different require-ments from users raise new challenges which a singleprovider may not be able to satisfy, given that theresilience of cloud services and the availability of datastored in the cloud are the most important issues. Scal-ing up the infrastructure might be a solution for eachprovider, but it costs a lot to do so, and the infrastructuremay be under-utilized when demand is low. A multiplecloud approach, which is referred to as Cloud-of-Clouds,is a promising solution in which several providers coop-erate to build up a Cloud-of-Clouds system for allocatingresources to users. The Cloud-of-Clouds system canfacilitate expense reduction (i.e., savings on the operationcost), avoiding adverse business impacts and offeringcooperative or portable cloud services to users [34]. Thearchitecture of a Cloud-of-Clouds system is depictedin Fig. 1 in which a dedicated broker is responsiblefor coordinating the cooperation among providers. Thebroker has all information about the resource capacitiesand price policies of all providers. Based on the users’resource requests, the broker will run a cooperationdecision algorithm to decide with whom a particularprovider should cooperate. The broker can be clonedon each provider’s infrastructure and the cooperationdecision algorithm will be executed when required byits owner. However, since price policies and resourcecapacities of providers change over time [8], keeping theconsistency of this information for each version of thebroker may not be easy. Therefore, we consider the caseof a centralized algorithm run on the centralized Cloud-of-Clouds Broker to yield a global optimal solution.

The focused cooperation problem is the agreementamong providers for outsourcing users’ resource re-quests. Although providers are competing to attractusers and improve their revenues, between any twoproviders, an outsourcing agreement may be establishedsuch that one provider can outsource its users’ resourcerequests to its cooperator (or helper), i.e., satisfyingusers’ resource requests by using the cooperator’s in-frastructure. However, how is the outsourcing cost cal-culated? Since providers are rational, the cooperationshould result in a win-win situation where the providerwho outsources its users’ resource requests may pay alower cost than satisfying them locally, and the providerwho hosts outsourcing requests will receive the finalrevenue at least as much as that without cooperation.

It is to be noted that under the Cloud-of-Cloudsmodel, many intertwined issues need to be consideredbefore the system can operate efficiently. First, interoper-ability is one of the major issues. Every provider has itsown way on how users or applications interact with thecloud infrastructure, leading to cloud API propagation [35].This prevents the growth of the cloud ecosystem andlimits cloud choice because of provider lock-in, lack ofportability and the inability to use the services offered

by multiple providers. An interoperability standard istherefore needed to enable users’ applications on theCloud-of-Clouds to be interoperable. Second, coopera-tion among providers requires a common Service LevelAgreement (SLA) governing expected quality of service,resource usage and operation cost. Defining a “goodfaith” SLA allows the Cloud-of-Clouds to minimize con-flicts which may occur during the negotiation amongproviders. One reason for the occurrence of these con-flicts is that each provider must agree with the resourcescontributed by other providers against a set of its ownpolicies. Another reason is the incurrence of high coop-eration costs (e.g., network establishment, informationtransmission, capital flow) by the providers as they donot know with whom they should cooperate [34]. Lastbut not least, the network latency among providers’infrastructures also needs to be taken into account. Itcan be added as a constraint in the cooperation model toguarantee the service availability and satisfy the specialrequirements of users, and thus, may affect the optimalcooperation structure. In this paper, we only focus onthe cooperation agreement among providers, and leavethe study of the other issues mentioned above for futurework. Hereafter, the term “hosting” provider is used torefer to the provider who satisfies its own users’ requests(i.e., “stays local”) and accepts outsourcing requests fromother providers, and the term “outsourcing” provider isused to refer to the provider who outsources its users’resource requests to another provider and becomes idle.

6.2 Assumptions for the cooperation method

Several assumptions are needed to make our modelsimple but still reflect the real behaviors of providers.First, we assume that a provider can outsource its users’resource requests to only one provider at one time. All itsusers’ resource requests will be satisfied by the selectedprovider and its local resources become idle. Satisfyinga partial number of users’ resource requests at the localsite or sending to multiple providers may not be thebest choice since the overhead of the operation cost atthe local site plus the cooperation costs at the partners’sites may increase.

Second, a provider can accept as many as outsourc-ing requests without facing the limitation of resourcecapacities. This reflects our aforementioned assumptionthat a provider has enough resource capacity to satisfyall users’ resource requests since supply is much higherthan demand in the current cloud market. Additionally,with the quasi-unlimited capacities, the order of ac-cepting outsourcing requests becomes unimportant. Thisassumption reflects the case of Amazon EC2 which hasquasi-unlimited capacities and wants to have as manyresource requests as possible to gain higher revenue [36].

Finally, a provider can refuse outsourcing requests ifits total final revenue when hosting resource requestsfrom others is less than that when outsourcing its ownusers’ resource requests to another provider. In thiscase, outsourcing providers will choose the next highestprovider if it exists. If not, they have to satisfy their users’resource requests locally.

6.3 Outsourcing cost and final revenue of providers

We now present the mathematical models for the out-sourcing cost and the final revenue of both outsourcingprovider and hosting provider. Recall that the final rev-enue of provider i satisfying its users’ resource requestslocally is defined as

Rlocali (βi,pi) =

KXk=1

βikcki −MX

j=1

coija1+log2 ϕiij

1 + log2 ϕi

−MX

j=1

coij (ψij − aij)1+log2 ϕi

1 + log2 ϕi

(20)

where the first term is the gross revenue received fromusers. The second and third terms are the total operationcosts for active and idle resources, respectively.

When two providers cooperate, the resource usagecost, that a provider has to pay when outsourcing to theother, is cheaper than that paid by users for the samerequests. We define the outsourcing cost of provider iwhich outsources its users’ resource requests to provideri′ as the difference in the operation cost when the amountof resources of provider i′ allocated to provider i is activeand idle. Mathematically, this cost is defined as follows:

Coutsourceii′ (βi, i

′) =MX

j=1

coi′ja

1+log2 ϕi′ij

1 + log2 ϕi′−

MXj=1

coi′ja

1+log2 ϕi′ij

1 + log2 ϕi′

=

MXj=1

“coi′j − c

oi′j

”a

1+log2 ϕi′ij

1 + log2 ϕi′

(21)

where aij is the number of instances of resource typej defined as aij =

∑Kk=1 βikrkj , that are outsourced to

provider i′, and ϕi′ is the learning factor of provideri′. The final revenue of provider i when outsourcing itsusers’ resource requests to provider i′ is then

Routsourceii′ (βi,pi, i

′) =KX

k=1

βikcki −MX

j=1

coijψ1+log2 ϕiij

1 + log2 ϕi

−MX

j=1

“coi′j − c

oi′j

”a

1+log2 ϕi′ij

1 + log2 ϕi′

(22)

where the first term is the gross revenue that provideri receives from users, the second term is the operationcost for all local idle resources and the third term is theoutsourcing cost that provider i pays to provider i′.

Finally, the total final revenue of provider i′, whichstays local to satisfy its own users’ resource requests andaccept outsourcing requests from other providers, can beformulated by combining Eqs. (4), (5) and (21). In detail,Let Li′ denote the set of all providers which outsourcetheir users’ resource requests to provider i′. We extendEq. (4) to formulate the operation cost of provider i′:

Ci′ (βi′ ,Li′ ) =MX

j=1

coi′j

“ai′j +

Xl∈Li′

alj

”1+log2 ϕi′

1 + log2 ϕi′

+

MXj=1

coi′j

“ψi′j − ai′j −

Xl∈Li′

alj

”1+log2 ϕi′

1 + log2 ϕi′.

(23)

The final revenue of provider i′ when accepting out-sourcing requests is then

Rhostingi′ (βi′ ,pi′ ,Li′ ) = R

grossi′ (βi′ ,pi′ ) +

Xl∈Li′

Coutsourceli′ (βl, i

′)

− Ci′ (βi′ ,Li′ )

(24)

where the first term is defined in (5), the second term isdefined in (21) and the third term is defined in (23).

Provider i outsources its users’ resource requests toprovider i′ if the final revenue of provider i whenoutsourcing is greater than that when satisfying allusers’ resource requests locally, i.e., Routsource

ii′ (βi,pi, i′) >Rlocali (βi,pi). Provider i′ accepts outsourcing requests

from other providers if it does not have a higher gainwhen outsourcing its own users’ resource requests.

6.4 Algorithm for making cooperation decisionsIn this section, we present an algorithm for determiningthe cooperation structure among providers. Since the fullalgorithm is quite long and complex, we first providean overview of the algorithm in Algorithm 2 and thenpresent a detailed analysis of the algorithm.

The algorithm starts by computing the final rev-enue of each provider when outsourcing its users’resource requests to each of the other N − 1providers, Routsource

ii′ (βi,pi, i′),∀i, defined in (22). TheseRoutsourceii′ (βi,pi, i′) values are used later on in the algo-

rithm to determine the best provider i′ for provider ito outsource to, and also to compare with the sum ofrevenues when hosting local users’ resource requests,i.e., “staying local”, and when hosting users’ resourcerequests from other provider’s users, Rhosting

i′ (βi′ ,pi′ ,Li′)defined in (24). This procedure is presented in lines 2–8.

The critical part of the algorithm is in the while loop,lines 10–38, where it has to make the decision for aprovider who wants to outsource its users’ resourcerequests, but may also have outsourcing requests fromother providers, or its best provider to outsource to hasnot decided to become a hosting provider yet. The whileloop stops when there is no more provider which can bea hosting provider, i.e., it has outsourcing requests fromother providers. The stop flag is used to exit the whileloop. In each iteration, a provider will be removed fromP, the set of all providers. This provider may be put intoP1, the set of all hosting providers, or P2, the set of alloutsourcing providers.

In the for loop, lines 12–17, the algorithm deter-mines Li′ , the set of providers who maximize their rev-enues when outsourcing their users’ resource requests toprovider i′, by evaluating Routsource

ii′ (βi,pi, i′). Provideri belongs to Li′ if the condition Routsource

ii′ (βi,pi, i′) >Routsourceii′′ (βi,pi, i′′),∀i′′ 6= i′ holds. For example, Provider

1 can outsource its users’ resource requests to Provider2 or Provider 3 if the revenues when outsourcingto Provider 2 or 3 are higher than that when stay-ing local, i.e., Routsource

12 (β1,p1, 2) > Rlocal1 (β1,p1) and

Routsource13 (β1,p1, 3) > Rlocal

1 (β1,p1). Depending on thevalues of Routsource

12 (β1,p1, 2) and Routsource13 (β1,p1, 3),

Provider 1 will belong to the set L2 or L3. IfRoutsource

12 (β1,p1, 2) > Routsource13 (β1,p1, 3), then Provider

Algorithm 2 Determination of the cooperation structure

Input: Users’ resource requests: rk, k = 1, . . . ,K. In-formation about all providers: ϕi, ψij , coij and coij ,i = 1, . . . , N, j = 1, . . . ,M . Price policies of allproviders p.

Output: Cooperation structure.1: P← 1, 2, . . . , N; /*set of all providers*/2: for i = 1→ N do3: for i′ = 1→ N do4: if i 6= i′ then5: Compute Routsource

ii′ (βi,pi, i′) based on (22);6: end if7: end for8: end for9: P1 ← ∅; P2 ← ∅; stop← FALSE;

10: while stop 6= TRUE do11: stop← TRUE;12: for i′ ∈ P \ P1 ∪ P2 do13: Find Li′ ; /*set of providers outsourcing to i′*/14: if Li′ 6= ∅ then15: stop← FALSE;16: end if17: end for18: i∗ ← 0; i∗

′ ← 0;maxval← −realmax;19: for i′ ∈ P \ P1 ∪ P2 and Li′ 6= ∅ do20: Compute Rhosting

i′ (βi′ ,pi′ ,Li′) defined in (24);21: Determine the best provider i′′ for provider i′

to outsource to by evaluating Routsourcei′,i′′ ;

22: if i′′ 6= 0 then23: Rdiff

i′ ← Rhostingi′ −Routsource

i′,i′′ ;24: else25: Rdiff

i′ ← Rhostingi′ ;

26: end if27: if maxval < Rdiff

i′ then28: maxval← Rdiff

i′ ; i∗ ← i′; i∗′ ← i′′;

29: end if30: end for31: if i∗ 6= 0 then32: if maxval > 0 or i∗

′/∈ P1 then

33: P1 ← P1 ∪ i∗; /*hosting provider*/34: else35: P2 ← P2 ∪ i∗; /*outsourcing provider*/36: end if37: end if38: end while39: if P \ P1 ∪ P2 6= ∅ then40: for i ∈ P \ P1 ∪ P2 do41: Determine the best provider i′ for provider i

to outsource to;42: if i′ 6= 0 and i′ ∈ P1 then43: P2 ← P2 ∪ i; /*outsourcing provider*/44: else45: P1 ← P1 ∪ i; /*stay local*/46: end if47: end for48: end if

1 belongs to set L2 since Provider 1 gains better revenuewhen outsourcing its users’ resource requests to Provider2 rather than Provider 3. Otherwise, Provider 1 be-longs to set L3. If Rlocal

i (βi,pi) > Routsourceii′ (βi,pi, i′),∀i′,

provider i will not belong to any Li′ . Set Li′ is updatedin each iteration of the while loop as the best provider i′for provider i to outsource to may decide to become anoutsourcing provider rather than a hosting provider. Inthis case, provider i will choose the next highest provideri′ by re-evaluating Routsource

ii′ (βi,pi, i′).Lines 18–30 determine the next provider who will

make a decision. For provider i′ which has not yetdecided and which may have several outsourcing re-quests from providers in Li′ , the algorithm computesits total revenue when staying local and acceptingall outsourcing requests from all providers in Li′ ,R

hostingi′ (βi′ ,pi′ ,Li′), defined in (24). The algorithm also

determines the best provider i′′ to which provider i′ canoutsource its own users’ resource requests by evaluatingRoutsourcei′,i′′ . Let Rdiff

i′ denote the difference in the revenueof provider i′ between staying local and accepting out-sourcing requests from other providers in Li′ , versusoutsourcing its own users’ resource requests to its bestprovider i′′, Rdiff

i′ = Rhostingi′ −Routsource

i′,i′′ . If provider i′ gainsthe highest revenue when staying local even withouthosting outsourcing requests, i.e., there is no provider i′′

for provider i′ to outsource to, Rdiffi′ is set to Rhosting

i′ . Theprovider which has the highest value of Rdiff

i′ and its besthosting provider are marked by i∗ and i∗

′, respectively.

Provider i∗ is selected to make the final decision byexecuting lines 31–37. If maxval (i.e., Rdiff

i∗ ) is greaterthan or equal to 0, i.e., provider i∗ gains a higherrevenue when accepting outsourcing requests from otherproviders than that when it outsources its own users’resource requests to provider i∗

′, the final decision of

provider i∗ is to stay local and to accept outsourcingrequests. Provider i∗ is put into set P1 as a hostingprovider. If maxval is negative, provider i∗ prefers tooutsource its users’ resource requests to its best provideri∗′. The final decision of provider i∗ depends on the

decision of provider i∗′. Two cases can happen. First,

if provider i∗′

is a hosting provider, the decision ofprovider i∗ is to outsource its users’ resource requests toprovider i∗

′. When that happens, provider i∗ is put into

set P2. Second, if provider i∗′

has not made its decisionyet, then provider i∗ must stay local and satisfy its users’resource requests using local resources. This is the finaldecision of provider i∗ since provider i∗

′later on will

also become an outsourcing provider as Rdiffi∗′

< Rdiffi∗ < 0.

When that happens, provider i∗ is put into set P1.After exiting the while loop, all providers which can be

a hosting provider have been processed. For the remain-ing providers in set P, which have not yet made a de-cision, each will become either an outsourcing providerif its best provider to outsource to is a hosting provider(i.e., in set P1), this provider enters set P2. Or, it will staylocal to satisfy only its own users’ resource requests, thisprovider enters set P1 (lines 39–48).

It is noted that during the execution of the while loop,it can happen that provider i wants to outsource to

provider i′ and provider i′ also wants to outsource toprovider i (i.e., “cyclic cooperation”). By choosing theprovider which has the maximum value of Rdiff

i , wegive the privilege to the provider, who best improvesthe final revenue, to make the cooperation decision firstand thereby solve the cyclic cooperation problem.

It is also worth noting that once providers are placedin set P1 or P2, they will not change the decisionanymore. Indeed, if providers are in set P1, their finalrevenue when being a hosting provider and acceptingoutsourcing requests is higher than that when outsourc-ing its own users’ resource requests. Hence, they will notchange to become an outsourcing provider. Furthermore,if there is any outsourcing request from the others, theproviders in set P1 will accept and gain even higherrevenue according to the second assumption presentedin Section 6.2. Similarly, a provider in set P2 does nothave any outsourcing request from other providers andthe revenue when outsourcing its own users’ resourcerequests is higher than that when staying local. Thematching process of provider i outsourcing its users’resource requests to its best hosting provider i′ is donewhen provider i is put into set P2 (lines 35 and 43).

6.5 Optimality of the algorithm

With the assumptions presented in Section 6.2, we claimthat the proposed algorithm yields the optimal coop-eration structure in which the cooperation decision re-sults in the highest revenue for each provider. Thus, noprovider can unilaterally deviate to gain more revenue.

Proposition 6.1. The cooperation structure found by theproposed algorithm is the optimal solution for all providersin the Cloud-of-Clouds based on the assumptions presented inSection 6.2.

Proof: The proof of the above proposition is self-explanatory from the principle of revenue maximization.Indeed, as explained in Section 6.4, once provider imakes the decision which is its best solution based on theprinciple of revenue maximization, it will not change itsdecision anymore. The decision made by other providerslater on will not change the decision of provider i as itgains more revenue when it is a hosting provider, or itgains nothing when it is an outsourcing provider. Dueto the limit of space, we refer the reader to [37] for anexample illustrating the optimality of the algorithm.

It is worth noting that without the assumptions pre-sented in Section 6.2, the problem will be more com-plex and require a more advanced formulation that issolved, e.g., by a combinatorial optimization method.For instance, the first assumption is said that a providercan outsource to only one provider, and when it decidesto outsource, all its users’ resource requests will besatisfied by the hosting provider. Without this assump-tion, outsourcing providers have to solve the problemof determining which user’s resource request will beoutsourced to which hosting provider. Furthermore, ifwe ignore the second assumption which relates to quasi-unlimited capacities of providers, then hosting providershave to determine which outsourcing requests will be

accepted to maximize the revenue. They also have toconsider the arrival order of outsourcing requests sinceit has an impact on their final revenues.

7 NUMERICAL SIMULATIONS AND RESULTS7.1 Parameter settings of simulationsFor all simulations, we set the discount factor γ = 0.95which corresponds to a 5% interest rate, the convergenceconstraint ε = 1e−4. The users’ preferences which followthe Gumbel distribution are generated with the locationparameter µ = 3 and the scale parameter β = 4. We setthe number of resource types offered by each providerM = 4 which is similar to that offered by Amazon EC2.We also use the per unit prices charged by Amazon tocalculate the budgetary constraint for all users. The ini-tial value for price policies of all providers is set to zero.Users’ resource requests are classified into three classes:small, medium and high demand classes which requirea tuple of resources rj = (6, 5, 4, 2), rj = (25, 20, 15, 8)and rj = (60, 50, 40, 20), respectively. This reflects thereal user behavior that a user in the small class oftenrequests a few number of resource instances for testingand experimental purpose while a user in the highdemand class needs more resources for running theirapplication on the production level. The number of usersis set to 1024, except when explicitly indicated.

In the first group of simulations performed for validat-ing the dynamic pricing and competition approach, thenumber of providers is set to N = 2 whose resourcesgenerate per unit benefit λ1 = (0.1, 0.3, 0.4, 0.8) andλ2 = (0.15, 0.25, 0.5, 0.7), respectively. By choosing N =2, we simplify the simulation without loss of generalityand retaining the competitive characteristics of the cloudmarket. Three simulations were examined:

1) The objective of the first simulation is to show thedifference between the monopoly market with a soleprovider and the oligopoly market with 2 providers;

2) The second simulation is to illustrate the evolutionof the market to the equilibrium state; and

3) The last simulation is to show the convergence ofthe price policies and revenue of providers, and toassess the performance of the algorithm.

In the second group of simulations for validatingthe cooperation approach, we performed a large-scalesimulation to illustrate the step-by-step execution of thecooperation decision algorithm.

Finally, we performed an intensive simulation to showthe scalability of our model to a realistic market size andmeasured the running time of the proposed algorithms.

7.2 Analysis of results on dynamic resource pricingand competition7.2.1 Monopoly versus oligopolyWith the same number of users and the same resourcerequests, it is expected that the revenue of the soleprovider in a monopoly market is much higher thanthat in an oligopoly market since users do not haveany choice. However, when there is competition in themarket, users’ resource requests are distributed among

TABLE 2: Price policies and total revenue of providerswhen market is a monopoly and oligopoly

Price policies TotalType 1 Type 2 Type 3 Type 4 Revenue

Monopoly 0.32 0.40 0.48 0.77 30087.68

Oligopoly 0.32 0.40 0.47 0.78 09395.200.32 0.39 0.47 0.77 20695.04

TABLE 3: Users’ resource requests, budgetary constraintsand their preferences to cloud providers

User Request Budget User’s preference (ηki) toindex class constraint Provider 1 Provider 2

1 small 6.82 6.0570 1.72102 small 8.24 0.9966 1.09703 medium 28.21 8.5080 −0.93364 medium 31.73 10.7100 5.08105 high 100.60 3.4213 3.39106 small 8.49 0.2286 7.98607 medium 39.53 8.2780 4.31908 medium 27.09 2.4630 3.1840

the providers. Thus, the final revenues of providersdecrease. In any case, the price policies are optimalsince Algorithm 1 finds the price policies that maximizethe revenue of providers while still assuring that usagecosts do not exceed the users’ budgetary constraints. Aswe can observe in Table 2, the sum of revenues of allproviders in the oligopoly market is almost equal to therevenue of the sole provider in the monopoly market.However, depending on the users’ resource requests,price policies are set accordingly. For instance, from Ta-ble 2, it can be observed that in the Monopoly simulation,the first three resource types (Types 1–3) are slightlymore expensive than in the Oligopoly simulation whilethe fourth resource type (Type 4) is slightly cheaper.

7.2.2 Evolution of the market to the equilibriumWe performed this simulation with K = 8 users. Thisallows us to depict the evolution of the market asshown in Fig. 3. The users’ resource requests and theirpreferences to providers are presented in Table 3. Theresults show that there always exists a unique MPE nomatter what initial state is set. Indeed, we pick ran-domly any initial state among the 256 states in the statespace, the game always converges to the equilibriumstate ω = (2, 2, 1, 1, 2, 2, 1, 1) as illustrated in Fig. 3.At the equilibrium state, the optimal price policies ofthe two providers are p1 = (0.27, 0.35, 0.46, 0.82) andp2 = (0.29, 0.31, 0.48, 0.82) with the optimal revenuesR1 = $88.09 and R2 = $108.94, respectively. As illus-trated by dotted arrows in Fig. 3, from the equilibriumstate, providers have no incentive to unilaterally deviatefrom their optimal price policies to improve the revenue.

This simulation also shows that if users are indifferentto providers, they will be sensitive to prices. As shownin Table 3, User 5 slightly prefers Provider 1 to Provider2, i.e., the preference of User 5 is 3.4213 to Provider 1versus 3.3910 to Provider 2. However, the price policy ofProvider 2 makes the utility of User 5 attain the maximalvalue. Thus, User 5 changes his provider to Provider 2instead of Provider 1 at the equilibrium state. Yet, thissimulation shows that although providers do not knowthe users’ preferences and have to treat these variables as

1R : $82.16

11111222 p1 p2

2R : $78.07

1p =(0.13, 0.12, 0.65, 0.81)

2p =(0.95, 0.19, 0.13, 0.66)

p1 p2

p1 p2

p1 p2

1p =(0.27, 0.35, 0.46, 0.82)

2p =(0.29, 0.31, 0.48, 0.82)

1R : $88.092R : $108.94

1p =(0.59, 0.21, 0.58, 0.84)

2p =(0.07, 0.72, 0.20, 0.42)

1R : $85.742R : $107.60

21112122

22112211

22221111

Fig. 3: Market’s evolution with 2 providers and 8 users.

random, the logit discrete choice model allows providersto derive the accurate probability of being chosen byusers. Adjusting price policies can increase or decreasethe providers’ chances of being chosen. Except for userswho may be confused among providers and have tochange their providers (i.e., User 5), all users are moresatisfied with their preferred provider than with others.

7.2.3 Convergence of price policies and revenueWe present the convergence of the price policy ofProvider 1 in Fig. 4a, and for Provider 2 in Fig. 4b,respectively. Fig. 4c shows the convergence of the dis-counted sum of future revenue of both providers. Bycomparing the prices of the same resource type offeredby the two providers, it is expected that the price of re-source types with higher benefit will be more expensive.In this simulation, all resource types 1, 2 and 3 followsthis affirmation. However, if users are more familiarwith the provider having the lower benefit resource, thisprovider can increase the price of this resource type toimprove his revenue. In this simulation, resource type 4of Provider 1 has a higher benefit than resource type 1of Provider 2, i.e., λ14 = 0.8 versus λ24 = 0.7, but it ischeaper, i.e., p14 = 0.80 versus p24 = 0.82.

As shown in Figs. 4a and 4b, the price policies quicklyconverge to the equilibrium after 10 iterations. The num-ber of iterations depends on the speed of convergenceof the optimization solver used for solving the problem.However, our intensive simulations show that the algo-rithm always converges to the optimal solution. Further-more, to avoid the convergence to the local optimum,we use the stopping condition which is based on thediscounted sum of future revenue as depicted in Fig. 4c.

7.3 Analysis of results on cooperationIn this section, we present an evaluation of the coopera-tion model. We consider a Cloud-of-Clouds with N = 8providers since it is large enough for a provider tochoose its cooperation partner. The number of users’ re-source requests is set to K = 512. With the large numberof users’ resource requests submitted to a provider, theoperation cost and revenue will be highly affected whenthe provider outsources its users’ resource requests toits partner. We first present a simulation to illustrate theexecution of the algorithm step-by-step and then analyzethe dynamic changes of the cooperation decisions.

7.3.1 Algorithm validationWith the large number of users, we will not presentall details of their resource requests. For providers, we

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

0 2 4 6 8 10

Pric

e of

eac

h re

sour

ce ty

pe

Iteration index

Type 1Type 2Type 3Type 4

(a) Resource prices of Provider 1.

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

0 2 4 6 8 10

Pric

e of

eac

h re

sour

ce ty

pe

Iteration index

Type 1Type 2Type 3Type 4

(b) Resource prices of Provider 2.

0

5000

10000

15000

20000

25000

0 2 4 6 8 10

Dis

coun

ted

sum

of f

utur

e re

venu

e

Iteration index

Provider 1Provider 2

(c) Discounted sum of future revenues.

Fig. 4: Convergence of price policies and discounted sum of future revenues of all providers.

TABLE 4: Simulation input data for illustrating the cooperation decision algorithm: infrastructure size and operationcost of the first active and idle instance of each resource type provided by each provider: the index is that of providers

Inde

x Infrastructure size Operation cost of Operation cost of

Lear

ning

fact

orthe first active instance the first idle instance

Type 1 Type 2 Type 3 Type 4 Type 1 Type 2 Type 3 Type 4 Type 1 Type 2 Type 3 Type 4

1 2408 2479 2211 2340 0.06 0.07 0.09 0.10 0.03 0.03 0.05 0.05 0.792 2453 2483 2458 2379 0.06 0.07 0.08 0.10 0.02 0.03 0.04 0.05 0.753 2063 2078 2396 2372 0.07 0.08 0.08 0.10 0.02 0.04 0.04 0.05 0.764 2457 2486 2480 2196 0.07 0.07 0.08 0.09 0.03 0.03 0.05 0.06 0.885 2316 2479 2328 2328 0.07 0.07 0.08 0.09 0.02 0.03 0.04 0.05 0.866 2048 2243 2017 2085 0.07 0.07 0.08 0.10 0.02 0.04 0.05 0.05 0.807 2139 2400 2425 2353 0.07 0.08 0.08 0.09 0.02 0.03 0.04 0.05 0.908 2273 2071 2467 2015 0.06 0.07 0.09 0.09 0.02 0.04 0.04 0.05 0.75

TABLE 5: Price policies, users distributions and finalrevenues after competition

Prov

ider

Inde

x Price policies#Users

Tota

lR

even

ue

Type 1 Type 2 Type 3 Type 4

1 0.17 0.28 0.53 1.05 27 837.902 0.18 0.26 0.56 1.05 32 1105.803 0.17 0.29 0.53 1.06 47 1592.104 0.12 0.27 0.54 1.11 69 2197.405 0.16 0.24 0.57 1.07 55 1761.806 0.17 0.28 0.53 1.05 81 2737.207 0.13 0.25 0.56 1.11 95 3180.808 0.12 0.27 0.54 1.11 106 3830.80

present in Table 4 the infrastructure size which is themaximum number of resource instances offered by eachprovider, operation costs for the first active and idle re-source instance, and the learning factor. With these inputdata, after running Algorithm 1 described in Section 5,we obtained the price policies and the distribution ofusers among providers as shown in Table 5.

Following the first part of Algorithm 2 (lines 2–8), the algorithm computes the final revenue of eachprovider when it outsources its users’ resource requeststo each of the other 7 providers. The values of Routsource

i,i′

are shown in Table 6 where row provider representsi and column provider represents i′. When i = i′,Routsourcei,i′ , which is shown in bold text, is the revenue

of provider i when satisfying users’ resource requests lo-cally. Routsource

i,i′ , which is in italics, is the higher revenue ofprovider i when outsourcing its users’ resource requeststo provider i′ compared to the revenue when stayinglocal. It is observed that Providers 4, 5 and 7 improvethe final revenue when outsourcing to Providers 1, 2 and

3 since they have the higher learning factor which leadsto the higher operation cost. Similarly, Provider 6 alsoimproves the revenue when outsourcing to Provider 1.However, Providers 1, 2 and 3 also want to outsourcetheir users’ resource requests to their preferred provider.

In the first iteration of the while loop, the algorithmfirst determines the set of outsourcing providers foreach provider by evaluating Routsource

i,i′ . Based on Table 6,we can see that the best provider for Providers 2, 3,4, 5, 6 and 7 to outsource to is Provider 1. Thus,L1 = 2, . . . , 7. Without outsourcing requests from otherproviders, Provider 1 may want to outsource to Provider2. Thus, L2 = 1. For Providers 4, 5 and 7, though theycan outsource to Provider 2 or 3, the best provider towhich they can outsource and gain the highest revenueis Provider 1. Provider 8 does not belong to any set asit does not gain a higher revenue when outsourcing.Thus, we will have L3 = . . . = L8 = ∅. The algorithmthen executes lines 18–30 to determine which providerwill make its decision first, i.e., choosing one provideramong the providers who have outsourcing requestsfrom the others. There are only Providers 1 and 2 whichhave outsourcing requests. The algorithm computes thetotal revenue of Provider 1 when hosting all outsourcingrequests from providers in set L1 and does similarly forProvider 2. The total hosting revenue of Providers 1 and2 is compared to their revenue when outsourcing. Inthis case, Provider 1 prefers to outsources to Provider 2and Provider 2 wants to outsource to Provider 1. Table 7presents the Rdiff

1 and Rdiff2 values. As Provider 1 has the

best improvement, i.e., Rdiff1 = 60.36 versus Rdiff

2 = 2.05,Provider 1 is selected to make the decision. It is then putinto set P1 as a hosting provider (lines 31–37).

TABLE 6: Outsourcing revenue of each provider to other providers in the market: the index is that of providers

Index 1 2 3 4 5 6 7 81 837.9 850.0 839.2 812.4 786.7 771.8 735.7 726.02 1107.9 1105.8 1095.5 1063.4 1032.8 1015.4 971.9 960.83 1595.3 1581.4 1592.1 1538.6 1498.3 1476.3 1417.6 1404.04 2244.5 2227.2 2208.0 2197.4 2154.2 2125.9 2045.4 2028.55 1797.4 1782.3 1765.7 1717.8 1761.8 1693.7 1627.6 1612.96 2749.5 2730.3 2709.0 2642.0 2580.1 2737.2 2486.4 2467.77 3268.3 3247.1 3223.4 3146.6 3076.0 3040.2 3180.8 3019.68 3822.1 3799.2 3773.7 3688.3 3610.2 3571.1 3450.9 3830.8

TABLE 7: Hosting revenue versus outsourcing revenue

Provider (i) Rhostingi Routsource

i,i′ Rdiffi

1 910.36 850.00 (i′ = 2) 60.362 1109.95 1107.90 (i′ = 1) 2.05

TABLE 8: Competition and cooperation revenue andimprovement percentage: the index is that of providers

Index Competition Cooperation Improvementrevenue revenue percentage

1 850.00 910.36 (hosting) 7.10%2 1105.80 1107.90 (i∗ = 1) 0.19%3 1592.10 1595.33 (i∗ = 1) 0.20%4 2197.42 2244.52 (i∗ = 1) 2.14%5 1761.84 1797.44 (i∗ = 1) 2.02%6 2737.21 2749.53 (i∗ = 1) 0.45%7 3180.81 3268.29 (i∗ = 1) 2.75%8 3830.80 3830.80 (locally) 0%

Starting the second iteration of the while loop, thealgorithm updates the set of outsourcing providers.Only L2 is updated since Provider 1 has decided tobe a hosting provider. L2 is then an empty set. As allProviders 2–8 do not have outsourcing requests, i.e.,L2 = · · · = L8 = ∅, the algorithm exits the while loopand executes lines 39–48. For Providers 2–7, their bestprovider to outsource to is Provider 1 which is in setP1. Hence, their cooperation decision is to outsourcetheir users’ resource requests to Provider 1 and becomeidle. Since Provider 8 does not gain a higher revenuewhen outsourcing, it decides to stay local to satisfy itsown users’ resource requests without any outsourcingrequest from other providers. The optimal cooperationdecision and revenue’s improvement of each providerare presented in Table 8. The revenue improvement isup to 7.10% due to cooperation, except for Provider 8.

7.3.2 Dynamic decision for cooperationDepending on the market situation where users’ re-source requests and price policies of providers changedynamically, the cooperation decision will be adjustedaccordingly. Since the cooperation model depends onmany parameters, we could not perform simulations todetermine the main parameter affecting the cooperationdecision of providers, and to show different cooperationdecisions in different market states. However, it canbe expected that the providers, which have low users’demands, high operation cost and learning factor, tendto outsource their users’ resource requests to a providerwhich has a lower operation cost and learning factor.This reflects the case from real life where a person canuse his car or bus to travel. If he uses the bus, he will payfor the bus ticket and also the car park cost. If he uses

his own car, he will pay for petrol but have a lower carpark cost. Hence, the final decision depends on the routedistance that he has to travel, per unit cost of petrol,car park cost and the bus ticket price. Comparing thetotal cost of travelling by bus and that of using his owncar will give the final decision. Therefore, Algorithm 2should be executed once the market state changes.

7.4 Scalability of the modelThe proposed model is able to scale to a realistic sizeof the market within an acceptable time limit. On a DellOptiplex 780 with 2 processors Core 2 Duo running at3.16GHz with 4GB RAM, we run the simulation with 8providers which corresponds to the number of biggestpublic providers in the current market. We exponentiallyincrease the number of users up to 1024. For eachvalue of the number of users, we execute the algorithm10 times with different users’ preferences and resourcerequests. It is expected that the execution time of thealgorithm increases when the number of users increases.Despite the exponential increase of the state space size ofthe market, the proposed method of avoiding the curseof dimensionality reduces significantly the number ofsuccessor states that the algorithm has to compute the ex-pectation. At the highest number of users, the improvedalgorithm generates the results after 1306.534 ± 222.657seconds, while the simulation could not even run withthe original algorithm. The standard deviation of the exe-cution time is relatively high due to the convergence timeof the Bellman equation. The scalability of our modelwould be even better if Algorithm 1 is implemented as aparallel program where each execution thread processesthe expressions for each provider in the game.

8 CONCLUSIONIn the current fiercely competitive cloud market, manyproviders are facing two major challenges: finding theoptimal prices for resources to attract a common poolof potential users while maximizing their revenue in thepresence of other competitors, and deciding whether tocooperate with their competitors to gain higher revenueafter receiving their own users’ resource requests. Wepresented a game-theoretic approach to address the for-mer challenge. We integrated the discrete choice model,which describes the user’s choice behavior based on theuser’s utility, to allow providers to derive the probabilityof being chosen by a user. By modelling the stochasticgame as an MDP, our numerical results prove the exis-tence of an MPE from which providers cannot unilater-ally deviate to improve their revenue. Our algorithm,

which computes the equilibrium prices, is shown toconverge quickly. Next, we introduced a novel approachfor the cooperation among providers. The cooperationalgorithm results in a win-win situation where bothcooperation partners can improve their final revenue.The cooperation structure found by the algorithm is theoptimal one for each provider. Thus, no provider has anyincentive to unilaterally deviate to gain more revenue.The simulation results show that our approach is scalableand can be adopted by actual cloud providers.

REFERENCES

[1] H. Xu and B. Li, “Dynamic Cloud Pricing for Revenue Maximiza-tion,” IEEE Trans. Cloud Comput., vol. 1, no. 2, pp. 158–171, 2013.

[2] K. E. Train, “Discrete Choice Methods with Simulation,” Identity,vol. 18, no. 3, pp. 273–383, 2003.

[3] M. J. Osborne, An Introduction to Game Theory. Oxford UniversityPress, 2004.

[4] R. Bellman, “A Markovian Decision Process,” Indiana Univ. Math.J., vol. 6, no. 4, pp. 679–684, 1957.

[5] A. N. Toosi, R. K. Thulasiram, and R. Buyya, “Financial OptionMarket Model for Federated Cloud Environments,” in UCC 2012,Chicago, Illinois, USA, Dec. 2012, pp. 3–12.

[6] A. Gera and C. H. Xia, “Learning Curves and Stochastic Modelsfor Pricing and Provisioning Cloud Computing Services,” ServiceScience, vol. 3, no. 1, pp. 99–109, Mar. 2011.

[7] B. Javadi, R. K. Thulasiram, and R. Buyya, “Characterizing spotprice dynamics in public cloud environments,” Future GenerationComputer Systems, vol. 29, no. 4, pp. 988–999, Jun. 2013.

[8] B. Sharma, R. K. Thulasiram, P. Thulasiraman, S. K. Garg, andR. Buyya, “Pricing Cloud Compute Commodities: A Novel Fi-nancial Economic Model,” in CCGrid 2012, Ottawa, Canada, May2012, pp. 451–457.

[9] D. Niu, C. Feng, and B. Li, “Pricing Cloud Bandwidth Reserva-tions under Demand Uncertainty,” in SIGMETRICS’12, London,UK, June 2012, pp. 151–162.

[10] H. Xu and B. Li, “Maximizing Revenue with Dynamic CloudPricing: The Infinite Horizon Case,” in IEEE ICC 2012, Ottawa,Canada, June 2012, pp. 2929–2933.

[11] F. Teng and F. Magoules, “Resource Pricing and EquilibriumAllocation Policy in Cloud Computing,” in CIT 2010, Bradford,UK, June 2010, pp. 195–202.

[12] M. Mihailescu and Y. M. Teo, “On Economic and Computational-Efficient Resource Pricing in Large Distributed Systems,” in CC-Grid 2010, Melbourne, Australia, May 2010, pp. 838–843.

[13] G. Allon and I. Gurvich, “Pricing and Dimensioning CompetingLarge-Scale Service Providers,” Manufacturing Service OperationsManagement, vol. 12, no. 3, pp. 449–469, 2010.

[14] D. Bergemann and J. Valimaki, “Dynamic price competition,”Journal of Economic Theory, vol. 127, no. 1, pp. 232–263, 2006.

[15] K. Y. Lin and S. Y. Sibdari, “Dynamic price competition with dis-crete customer choices,” European Journal Of Operational Research,vol. 197, no. 3, pp. 969–980, 2009.

[16] S. U. Khan and I. Ahmad, “A Cooperative Game TheoreticalTechnique for Joint Optimization of Energy Consumption andResponse Time in Computational Grids,” IEEE Transactions onParallel and Distributed Systems, vol. 20, no. 3, pp. 346–360, 2009.

[17] S. Penmatsa and A. T. Chronopoulos, “Price-based User-optimalJob Allocation Scheme for Grid Systems,” in IEEE IPDPS 2006,Rhodes Island, Greece, April 2006, pp. 336–343.

[18] Z. Kong, B. Tuffin, Y.-K. Kwok, and J. Wang, “Analysis of DuopolyPrice Competition Between WLAN Providers,” in IEEE ICC 2009,Dresden, Germany, June 2009, pp. 1–5.

[19] D. Niyato, A. V. Vasilakos, and Z. Kun, “Resource and RevenueSharing with Coalition Formation of Cloud Providers: GameTheoretic Approach,” in CCGrid 2011, Newport Beach, USA, May2011, pp. 215–224.

[20] B. Boghosian, P. Coveney, S. Dong, L. Finn, S. Jha, G. Karniadakis,and N. Karonis, “NEKTAR, SPICE and Vortonics: using federatedgrids for large scale scientific applications,” Cluster Computing,vol. 10, no. 3, pp. 351–364, 2007.

[21] M. Sobolewski and R. M. Kolonay, “Federated grid computingwith interactive service-oriented programing,” Concurrent Engi-neering, vol. 14, no. 1, pp. 55–66, 2006.

[22] B. Rochwerger, D. Breitgand, E. Levy, A. Galis, K. Nagin, I. M.Llorente, R. Montero, Y. Wolfsthal, E. Elmroth, J. Caceres, M. Ben-Yehuda, W. Emmerich, and F. Galan, “The RESERVOIR Modeland Architecture for Open Federated Cloud Computing,” IBM JRes Dev, vol. 53, no. 4, pp. 535–545, 2009.

[23] I. Goiri, J. Guitart, and J. Torres, “Economic model of a Cloudprovider operating in a federated Cloud,” Information SystemsFrontiers, vol. 14, no. 4, pp. 827–843, Sept. 2011.

[24] M. M. Hassan, M. S. Houssan, A. M. J. Sarkar, and E.-n. Huh,“Cooperative game-based distributed resource allocation in hor-izontal dynamic cloud federation platform,” Information SystemsFrontiers, pp. 1–20, June 2012.

[25] J. Filar and K. Vrieze, Competitive Markov Decision Processes.Springer-Verlag New York, Inc., 1996.

[26] P. Dubey, “Inefficiency of Nash Equilibria,” Mathematics of Opera-tions Research, vol. 11, no. 1, pp. 1–8, 1986.

[27] G. Martın-Herran and J. Rincon-Zapatero, “Efficient Markov per-fect Nash equilibria: theory and application to dynamic fisherygames,” J. Econ. Dynam. Control, vol. 29, no. 6, 2005.

[28] G. L. Lilien, P. Kotler, and K. S. Moorthy, Marketing Models.Prentice Hall, 1992.

[29] E. J. Gumbel, “Multivariate extremal distributions,” Bull. Inst.Internat. Statist., vol. 39, no. 2, pp. 471–475, 1962.

[30] R. A. Howard, Dynamic Programming and Markov Processes. TheMIT Press, 1960.

[31] U. Doraszelski and K. L. Judd, “Avoiding the curse of dimension-ality in dynamic stochastic games,” Quantitative Economics, vol. 3,no. 1, pp. 53–93, 2012.

[32] U. Doraszelski and A. Pakes, “A Framework for Applied DynamicAnalysis in IO,” in Handbook of Industrial Organization, ser. Hand-books in Economics, M. Armstrong and R. Porter, Eds. Elsevier,2007, ch. 30, pp. 1887–1966.

[33] K. L. Judd, Numerical Methods in Economics. The MIT Press, 1998.[34] M. Hassan, B. Song, and E.-N. Huh, “A market-oriented dynamic

collaborative cloud services platform,” Ann. Telecommun., vol. 65,no. 11-12, pp. 669–688, 2010.

[35] A. V. Parameswaran and A. Chaddha, “Cloud Interoperabilityand Standardization,” SETLabs Briefings, vol. 7, no. 7, 2009.

[36] J. Vargas and C. Sherwood, “Cloud Computing Capacity Plan-ning: Maximizing Cloud Value,” IBM, Tech. Rep., Nov. 2010.

[37] T. Truong-Huu and C.-K. Tham, “Competition and CooperationAmong Providers in a Cloud-of-Clouds Environment,” NationalUniversity of Singapore, Tech. Rep., Jan. 2014. [Online]. Available:http://137.132.153.61/techreport.pdf

Tram Truong-Huu received the MS from theFrancophone Institute for Computer Science,Hanoi, Vietnam and the PhD degree in com-puter science from the University of Nice SophiaAntipolis, France in Oct. 2007 and Dec. 2010,respectively. He held a postdoctoral fellowshipat the French National Center for Scientific Re-search (CNRS) from Jan. 2011 to Jun. 2012.From Jul. 2012, he is a research fellow at theDepartment of Electrical & Computer Engineer-ing (ECE) of the National University of Singa-

pore (NUS). His research interests include scientific workflow, grid,cloud and mobile cloud computing involving resource management, andcompetition and cooperation among cloud providers. He won the BestPresentation Recognition at IEEE/ACM UCC 2013.

Chen-Khong Tham received the MA and PhDdegrees in electrical and information sciencesengineering from the University of Cambridge,United Kingdom. He is an associate professor atthe Department of Electrical & Computer Engi-neering (ECE) of the National University of Sin-gapore (NUS). His current research focuses oncyberphysical systems involving wireless sensornetworks and cloud computing, and cooperativeand coordinated networks and distributed sys-tems. His co-authors and he won the Best Paper

awards at IEEE ICUWB 2008 and ACM MSWiM 2007. From 2007 to2010, he was on secondment at the Institute for Infocomm Research(I2R) Singapore and served as principal scientist and department headof the Networking Protocols Dept and programme manager of thePersonalization, Optimization & Intelligence through Services (POISe)Programme. He held a 2004/2005 Edward Clarence Dyason UniversityFellowship at the University of Melbourne, Australia. He is in the EditorialBoard of the IEEE Internet of Things Journal and the InternationalJournal of Network Management, and is/was the general chairman ofIEEE SECON 2014, IEEE AINA 2011 and IEEE APSCC 2009.