Socially Trusted Collaborative Edge Computing in Ultra Dense Networks
aa r X i v : . [ c s . G T ] M a y Socially Trusted Collaborative Edge Computingin Ultra Dense Networks
Lixing Chen,
Student Member, IEEE,
Jie Xu,
Member, IEEE
Abstract
Small cell base stations (SBSs) endowed with cloud-like computing capabilities are considered asa key enabler of edge computing (EC), which provides ultra-low latency and location-awareness fora variety of emerging mobile applications and the Internet of Things. However, due to the limitedcomputation resources of an individual SBS, providing computation services of high quality to its usersfaces significant challenges when it is overloaded with an excessive amount of computation workload.In this paper, we propose collaborative edge computing among SBSs by forming SBS coalitions toshare computation resources with each other, thereby accommodating more computation workload inthe edge system and reducing reliance on the remote cloud. A novel SBS coalition formation algorithmis developed based on the coalitional game theory to cope with various new challenges in small-cell-based edge systems, including the co-provisioning of radio access and computing services, cooperationincentives, and potential security risks. To address these challenges, the proposed method (1) allowscollaboration at both the user-SBS association stage and the SBS peer offloading stage by exploiting theultra dense deployment of SBSs, (2) develops a payment-based incentive mechanism that implementsproportionally fair utility division to form stable SBS coalitions, and (3) builds a social trust network formanaging security risks among SBSs due to collaboration. Systematic simulations in practical scenariosare carried out to evaluate the efficacy and performance of the proposed method, which shows thattremendous edge computing performance improvement can be achieved.
I. I
NTRODUCTION
Pervasive mobile computing and the Internet of Things are driving the development of manynew applications that are both compute-demanding and latency-sensitive, such as cognitive
L. Chen and J. Xu are with the Department of Electrical and Computer Engineering, University of Miami, USA. Email:[email protected], [email protected]. i n c e n t i v e s SBS merge ? SBS coalition p ee r o ff l o a d i n g r i s k cloud server Fig. 1. Illustration of socially trusted collaborative EC assistance, mobile gaming and augmented reality. Although cloud computing enables convenientaccess to a centralized pool of configurable and powerful computing resources, it often cannotmeet the stringent requirements of latency-sensitive applications due to the often unpredictablenetwork latency and expensive bandwidth [1], [2]. The growing amount of distributed datafurther makes it impractical or resource-prohibitive to transport all the data over today’s already-congested backbone networks to the remote cloud [3]. As a remedy to these limitations, EdgeComputing (EC) [4] emerges as a new computing paradigm to push the frontier of computingapplications, data, and services away from centralized cloud computing infrastructures to thelogical extremes of a network thereby enabling analytics and knowledge generation to occur atthe data source.Considered as a key enabler of EC, small cell base stations (SBSs), such as femtocellsand picocells, endowed with cloud-like computing and storage capability can serve end-users’computation requests as a substitute of the cloud while providing LTE connectivity to the Internet,especially for indoor premises. Such migration between computation and wireless communicationservice provisioning at the network edge was envisioned in the TROPIC project [5]. Nonetheless,compared with mega-scale data centers, SBS will be limited in computing resources. Therefore,computation workload exceeding the SBS’s computing capacity still has to be sent to the cloud,resulting in a hierarchical offloading structure among end-users, SBSs, and the cloud. Althoughthere have been a few works [6], [7] studying the optimization of the offloading strategy inthis hierarchical structure, relying on a single SBS significantly limits the EC performance.
Fortunately, the ultra dense deployment of SBSs in the next generation (5G) mobile networks[8] creates an opportunity for nearby SBSs to collaboratively form a computation resource pool.Such a collaborative EC infrastructure, also known as Femto-Cloud [9], improves the efficiencyof system resource utilization by exploiting the spatial diversity of workload patterns, therebysignificantly enhancing EC performance. For instance, a cluster of SBSs can coordinate amongthemselves to serve computation requests by transferring workload from overloaded SBSs tonearby SBSs with a light workload.The idea of balancing computation workload among nearby SBSs is similar to geographicalload balancing [10], [11] in data center networks, which has been extensively studied. However,edge computing in ultra dense networks faces many new challenges of forming an effectivecollaborative network. First, whereas conventional clouds manage only the computing resource,moving the computing resource to the network edge leads to the co-provisioning of radioaccess and computing services by the SBSs, thus mandating a new model for understandingthe interdependency between the management of the two resources. Unlike cloud computingthat is agnostic to user location, the physical association between the SBSs and the end usersbecomes a critical design aspect that has a significant impact on the computing performance.Second, a distinct feature of SBSs is that they are often owned and deployed by individual users(e.g. home/enterprise owners). Unlike macro base stations that are deployed by the networkoperator, the operator has only minimum control over SBSs. Without proper incentives, SBSswill be reluctant to participate in the collaborative edge computing process. Therefore, incentivesmust be devised and incorporated into the load balancing scheme. Of particular importance isthe design of a trust management module that takes into account the social trust relationshipbetween the SBSs to minimize the security and privacy risks in collaboration.In this paper, we design a socially trusted collaborative edge computing platform for ultradense networks (see Figure 1 for illustration). (1) We use payment as the incentive mechanismfor individual SBSs to collaborate. Specifically, overloaded SBSs can pay nearby SBSs withspare computing resources to process their workload instead of offloading it to the remotecloud. The collaborative network formation and the associated payment scheme are designedunder the coalitional game theoretic framework and we prove that our proposed scheme resultsin the optimal stable coalition among the SBSs. (2) When forming the coalition among SBSs,in addition to workload balancing at the SBS level, we allow end-users to directly switch their association to neighboring SBSs by exploiting the ultra dense deployment of SBSs, therebyavoiding transmission energy and latency incurred in the workload transfer between SBSs. Thismixed workload balancing scheme is in stark contrast with geographical load balancing indata center networks or collaborative Femto-Cloud [9] that does not consider the ultra densedeployment. (3) The proposed platform has a dedicated trust management component thatmanages the trust between any two SBSs to enable security-aware collaboration. Apart from thephysical network of SBSs, we construct a social trust network that characterizes the trust betweenSBSs, which can be used to determine the security measure to be put on the processing/offloadingof computation workload from/to neighbor SBSs, thereby reducing security and privacy leakagerisks. (4) We conduct extensive systematic simulation studies to evaluate our proposed scheme inpractical settings and understand how different SBS coalitions are formed and when collaborativeEC is the most useful. Our results show that the proposed collaborative EC method can reducethe system cost by more than 40% compared to standalone EC systems without collaboration.The rest of this paper is organized as follows. Section II presents the system model. SectionIII develops a coalitional game for cooperative SBS network. Section IV proposes a merge-splitframework for distributed coalition formation. Simulations are carried out in Section V. SectionVI reviews related works, followed by the conclusion in Section VII.II. S
YSTEM M ODEL
We consider N SBSs, indexed by N = { , , ..., N } , endowed with heterogeneous computingcapabilities. SBSs are located in separate rooms, possibly on different floors, in a multi-storybuilding. These SBSs have Internet access and therefore can offload computation tasks to theremote cloud when its own computational capacity cannot accommodate the demand. Let M = { , , ..., M } denote the set of all mobile user equipments (MUEs) in the building. Each SBShas a set of authorized MUEs, denoted by M i ⊆ M . For instance, MUEs (e.g. mobile phones,laptops etc.) of employees in a business are authorized to access the communication/computingservice of the SBS deployed by the business. MUEs of family members can also access itshome SBS. However, due to the ultra dense deployment of SBSs in the building, an MUE is inthe radio coverage of multiple SBSs and hence, there is a potential for SBSs to collaborativelybalance the workload via direct MUE-SBS association.We consider a time-slotted system. In each time slot, each MUE has a certain amount of computationally intensive tasks that need be offloaded to either the SBSs or the cloud forprocessing. We will focus on the problem in one time slot. There are two types of computationtasks: private tasks and normal tasks. Private tasks of an MUE must be processed by its ownSBS or the cloud (which is assumed to be secure). They cannot be processed by other SBSs dueto privacy concerns since SBSs are deployed by individual home/business owners which maynot be fully trusted and less protected than the cloud. Normal tasks are less security-sensitiveand hence, they can be processed by either its own SBS, the secure cloud or other nearby SBSs.Therefore, the task requests from MUE m ∈ M in a time slot are described by a tuple ( λ am , τ m ) where λ am is rate of task arrival in the current time slot (assuming a Poisson arrival process) and τ m ∈ [0 , is the fraction of private tasks. Without SBS collaboration, the total task arrival rateto SBS i from all its authorized MUEs is thus: λ si = X m ∈M i λ am (1)Due to the limited computational capacity of SBS i , there is a maximum task arrival rate ω max i that SBS i can handle. We define α i , ω max i − λ si as the computing resource surplus (or deficit)of SBS i . If α i ≥ , then SBS i has spare computing resources that it can share with otherSBSs. If α i < , then SBS i needs to acquire additional computing resource from either thecloud or other peer SBSs to meet its demand. Therefore, there is a potential computing resourceexchange market among the SBSs. We call SBSs with α ≥ potential “sellers” and those with α < potential “buyers”. A. Overview of Collaborative Edge Computing
Buyer SBSs have the following two options to acquire additional computing resources:
SBS-to-Cloud offloading : The SBS can further offload the unsatisfied computation tasks tothe remote cloud. However, there will be extra transmission delay costs due to the large round-trip time to the remote cloud. Moreover, the cloud will also charge the SBS service fees forusing the cloud computing resources.
SBS coalitions : Instead of relying on the remote cloud, SBSs can collaborate with each otherby forming edge computing coalitions, in order to reduce the number of computation tasksoffloaded to the cloud, thereby improving the delay performance and cutting their expenses onusing the cloud service. Specifically, there are two ways to collaborate: • SBS peer offloading : a buyer SBS first receives the computation tasks from its authorizedMUEs and then further transmits via the wireless link some of the received tasks to nearbyseller SBSs for processing. • MUE-SBS association : if an authorized MUE is also in the coverage of the seller SBS, abuyer SBS can associate this MUE to the seller SBS and directly offload its computationtasks to that seller SBS. This method exploits the dense deployment of SBSs and furthersaves the task transmission delay and energy cost.Clearly, load balancing via MUE-SBS association is preferred due to the reduced overheadcost. Therefore, in SBS coalitions, MUE-SBS association is adopted with a higher priority.When load balancing cannot be realized via MUE-SBS association, SBS peer offloading is thenexecuted. Typically, these two methods are used at the same time since MUEs are distributed inthe network and not all MUEs are covered by seller SBSs. payment surplus/deficit edge orchestration assign SBS load balancing (MUE-SBS assoc.) payment (SBS peer offloading)
MUEs SBS network Cloud server t i m e signaling Fig. 2. Operating time sequence diagram of collaborative edge computing
Different coalitions (i.e. seller-buyer matchings) lead to different edge computing performance.Since SBSs are self-interested and do not provide computing services to other SBSs for free, akey issue that this paper will address is how to design payment mechanisms to provide sellerSBSs with incentives to cooperate and form the optimal stable coalitions. Before we designthe coalition mechanism, we first show a time sequence diagram in Figure 2 to illustrate the operation of the collaborative edge computing system. At the beginning of each operational slot,a signaling phase is introduced in which MUEs report task requests. Based on these requests,SBSs form edge computing coalitions by playing a distributed coalitional game, taking intoconsideration of the local processing cost, cloud offloading cost, SBS peer offloading cost andcollaboration risk. Buyer SBSs make payments to seller SBSs for using their computing services.An edge orchestrator, which is a trusted third party, is introduced to facilitate the payment process.Specifically, the buyer SBSs first send payments to the edge orchestrator, which then distributesthe payments to the seller SBSs. The time slot ends with returning computation results to theMUEs.Next, we model the various costs involved in the collaborative edge computing system. Foreach SBS, its total cost comprises two main parts: operational cost and risk management cost.These costs form the basis of the coalition formation game.
B. Operational Cost
We first model the operational cost of the edge computing coalitions incurred in differentstages of the system.
Stage I: MUE-SBS association . We consider that an SBS absorbs the association cost (i.e.MUE-to-SBS transmission delay and energy consumption) of its authorized MUEs as part of itsoperational cost. Let M ij ⊆ M i ( ∀ j ∈ N , j = i ) denote the set of authorized MUEs of SBS i that are associated to SBS j . The achievable transmission rate r ami between MUE m and SBS i is given by the Shannon capacity r ami = W log (cid:18) p ami H mi σ + I (cid:19) (2)where W is the channel bandwidth, H mi is the channel gain between SBS i and user m , σ isthe noise power and I is the interference from other SBSs. Given a target transmission rate r ami ,the transmission power is thus p ami = (2 ramiW − σ + I ) H − mi (3)To simplify the notations, we assume that the expected data size of each task is a unit size.Therefore, the expected transmission delay and energy consumption of each task are d ami = 1 /r ami and e ami = p ami /r ami , respectively. The MUE-SBS association cost of SBS i is therefore C ai = X m ∈ M ii λ am ( d ami + γe ami )+ X j ∈N X m ∈M ij (1 − τ m ) λ am ( d amj + γe amj ) (4) + X j ∈N X m ∈M ij τ m λ am ( d ami + γe ami ) where γ is a normalization coefficient for delay cost and energy cost. The first term on theright-hand side is the association cost of authorized MUEs of SBS i that only associate withSBS i . The second and third terms are the costs due to authorized MUEs of SBS i associatingwith other SBSs j = i . However, for each MUE m , its private tasks must be sent to its ownSBS i . Note that for a seller SBS i , we must have M ij = ∅ , ∀ j since it has enough computingresources to accommodate all task requests from its own authorized MUEs. Stage II: SBS peer offloading . In this stage, the cost of SBSs is mainly caused by taskmigration between SBSs due to transmission delay and energy consumption. Let β ij denote theamount of tasks sent from SBS i to SBS j . The transmission rate from SBS i to SBS j and theassociated transmission power are denoted by r ij and p ij , respectively, which can be derived ina similar way as in Stage I. Therefore, the transmission delay and energy consumption for eachtask is d s,txij = 1 /r ij and e s,txij = p ij /r ij . The transmission cost incurred to SBS i due to peeroffloading is therefore: C s,txi = X j ∈N ,j = i β ij (cid:0) d txij + γe txij (cid:1) (5) Stage III: SBS computing . We then model the cost for processing computation tasks locallyat SBSs. For each task, we assume that the required number of CPU cycles is an exponentialrandom variable with mean ρ . The computational capability of SBS i is measured by its CPUspeed (i.e. CPU cycles per second), denoted by f i . We model the computing delay using theM/M/1 queuing system. Thus the average computation delay (including task waiting time andprocessing time) for each task, can be obtained as d s,ci ( ω i ) = 1 f i /ρ − ω i (6)where ω i is the workload processed at SBS i , which is the outcome of SBS coalition andload balancing and will be discussed shortly. The computation energy consumption for each task processed at SBS i is proportional to the square of the CPU speed ( f i ) , presented as e s,ci = κ ( f i ) , where κ is a constant depending on the CPU architecture [1]. Therefore, thecomputation cost of SBS i is C s,ci = ω i ( d s,ci ( ω i ) + γe s,ci ) (7)Notice that although here we use specific functions for computing delay and energy consumption,other functions can also be adopted. In practice, an SBS may maintain a lookup table for theexpected delay and energy consumption under different workload inputs. Stage IV: SBS-to-Cloud offloading . SBSs may still have to offload some computation tasksto the cloud. Let β i be the number of computation tasks offloaded to the cloud by SBS i . Dueto the large round-trip time to the remote cloud and the transmission energy consumption, theSBS-to-Cloud offloading cost of SBS i is C c,txi ( β i ) = β i ( d c,txi + γe c,txi ) (8)where d c,txi is the total expected delay (due to both transmission and computation on the cloud)from SBS i to the cloud, and e c,txi is the transmission energy consumed by SBS i for each task.In addition, the cloud charges SBSs w $/task for using the cloud service. Therefore, SBS i willalso incur an monetary cost M i = w β i (9)To sum up, the total operational cost of SBS i is: C i = w c ( C ai + C s,txi + C s,ci + C c,txi ) + M i (10)where w c converts the delay and energy cost into a value comparable to the monetary cost. Keepin mind that this cost depends on how the SBSs form the coalition and balance the workloadamong themselves. C. SBS Social Trust Model
Since SBSs are operated by individual owners, there are higher security and privacy risks forSBSs to offload their tasks to other SBSs than processing locally or offloading to the securecloud. Therefore, when forming SBS coalitions, trust between SBSs must be taken into account. Apart from the physical network of SBSs, we define a social trust network that describes thetrust relationships between SBSs. Let T ij ∈ [0 , denote the trust value that SBS i assigns toSBS j . T ij = 0 indicates that SBS i completely distrusts SBS j and T ij = 1 indicates that SBS i completely trusts SBS j . However, even if two SBSs are neighbors in the physical network,they may not have an established trust relationship between each other. For instance, a new SBSmay have just been set up or two SBSs have not interacted with each other for a long time.As illustrated in Figure 3, although SBS i and SBS j are physical neighbors and hence canpotentially form a coalition, the values of T ij and T ji are unknown since they do not have asocial relationship. SBS i SBS j SBS l SBS k T ik T kl T lj ? ? (a) Physical network One-hop Neighborhood Two-hop Neighborhood Three-hop Neighborhood i k l T ik T kl T lj j (b) Social trust networkFig. 3. Physical and social network. In such cases, trust between the SBSs will be derived using the social trust network. If SBS i can reach SBS j via certain other SBSs in the social network, then the trust between SBS i and SBS j is computed by propagating trust along the path that connects them. Let Λ( i, j ) bethe shortest path between SBS i and SBS j , then trust T ij is computed as T ij = Y ( k,l ) ∈ Λ( i,j ) T kl (11)We note that the above is just one common way to evaluate trust using the social trust network.There are many other ways to evaluate trust proposed in the literature. Moreover, the trust valueswill be updated over time depending on the recent social interactions (including interactions inthe coalitions) among SBSs.Using the social trust network, the cost due to managing the security risk that SBS i faces when offloading computation tasks to other SBSs (e.g. adopting stronger yet more costly securitymechanisms) is modeled as follows: R i = w r X j ∈N ( β uij + β ij )(1 − T ij ) (12)where β uij = P m ∈M ij (1 − τ m ) λ am is the amount of offloaded workload due to direct MUE-SBSassociation, β ij is the amount of offloaded workload in SBS peer offloading and w r convertsrisk into a value comparable to the monetary cost.III. C OLLABORATIVE
SBS
NETWORK AS A C OALITIONAL G AME
To formally study the formation of SBS coalitions and the resulting workload offloadingdecisions, we use the framework of the coalitional game theory [12], [13]. A coalitional gameis defined as a tuple ( N , v ) where N is the player’s set and v : 2 N → R is a function thatassigns for every possible coalition S ⊆ N a real number representing the total benefit achievedby coalition S . By evaluating the values of different coalitions, players decide what coalitionsare formed among themselves. In what follows, we first define the value function v ( S ) for anygiven coalition S ⊆ N . Clearly, v ( S ) depends on not only which SBSs are in the coalition S but also how they collaborate, namely how they perform load balancing. Then we will describewhat coalitions are desired in terms of stability. A. Collaborative load balancing and value function for coalitions
In this subsection, we investigate the interaction among SBSs that belong to any given coalition S (which may not be stable though). Let S s ⊂ S denote the set of seller SBSs in S and S b ⊂ S denote the set of buyer SBSs in S . We must have S s ∪ S b = S . Although there are manyapproaches to match buyers with sellers in the coalition (e.g., double auction or other matchingalgorithms [14]), for ease of implementation, we consider a simple scheme similar to [15] thatrelies on the preference of the buyers inside the coalition to decide the workload offloadingdecisions among the SBSs. Specifically, buyers can act sequentially (according to some order Π ) to acquire their needed computation resource as follows:(1) Buyer b i ∈ S b requests to acquire its needed computation resource from seller s j ∈ S s that will potentially yield the smallest offloading cost according to the SBS peer offloadingscheme in Algorithm 1 (which returns results of M b i s j and β b i s j ). – If seller s j can offer the required computation resource of buyer b i , then the buyer doesnot act further. – Otherwise, buyer b i acquires as much computation resource as possible from seller s j and then tries to fulfill the rest of its computation resource demand by acquiringresources from other sellers in S s .(2) Buyer b i repeats the above sequence until it has covered up all its computation resourcedeficit or no available sellers in S s exist. Then the next buyer SBS starts its acquiringprocess.This process is repeated for all buyers in S b . If a buyer is unable to find a seller in S s andstill needs computation resource, then the buyer will offload the remaining computation tasks,represented by β b i to the cloud. Essentially a buyer SBS tries to offload as much computationworkload as possible to peer seller SBSs. Algorithm 1
SBS peer offloading scheme
Input : Computation surplus | α s j | of seller s j ; Computation deficit | α b i | of buyer b i . Maximum task offloading: α = min( | α b i | , | α s j | ) ; Stage 1 : MUE-SBS association Find users co-covered by buyer b i and seller s j , denoted by R b i s j ; if P m ∈R bisj (1 − τ m ) λ am ≥ α then Choose M b i s j satisfying: P m ∈M bisj (1 − τ m ) λ am = α ; Stop ; else M b i s j = R b i s j ; ˜ α = α − P m ∈M bisj (1 − τ m ) λ am ; Go to Stage 2 ; end ifStage 2 : SBS peer offloading β b i s j = ˜ α ; return M b i s j , β b i s j ;Following the above buyer-seller matching and workload allocation process, the values of M b i s j , β b i s j and β b i can thus be determined for each b i and s j . In particular, the workload ω b i (or ω s j ) that buyer SBS b i (or seller SBS s j ) needs to process locally can be determined asfollows: ω b i = λ sb i − X s j ∈ S s X m ∈M bisj (1 − τ m ) λ am − X s j ∈{ S s ∪{ }} β b i s j (13) ω s j = λ ss j + X b i ∈ S b X m ∈M bisj (1 − τ m ) λ am + X b i ∈ S b β b i s j (14)With all these values derived, we are able to compute the operational cost C i as well as therisk management cost R i for each SBS i ∈ S according to our system model. Clearly, the valuesof these costs also depend on the ordering of the buyer SBSs in the aforementioned matchingprocess. Let O S be the set of all possible orderings over buyers in S . Then given an ordering Π ∈ O S , the utility of SBS i in coalition S is thus defined as u i ( S, Π) = − ( C i + R i ) , i ∈ S (15)and the total utility for coalition S is U ( S, Π) = X i ∈ S u i ( S, Π) (16)The minus sign is inserted to turn the problem into a maximization problem in order to facilitatethe analysis of the coalitional game. The value function for the SBSs coalition formation game ( N , v ) is defined as v ( S ) = max Π ∈O S U ( S, Π) (17)which is the maximum achievable total utility over all possible orderings of the buyers, orequivalently, the minimum achievable total cost of SBSs in the coalition. B. Payment scheme within a coalition
The previous subsection describes how SBSs in a coalition can collaborate with each other toimprove their total utility (i.e. reduce their total cost). However, although the overall performanceof the coalition may be improved, individual SBSs, especially the seller SBSs, do not share theircomputing resources with others for free. In this subsection, we design a payment scheme toprovide seller SBSs with incentives to cooperate. In the next section, we will study what stablecoalitions are formed under this payment-based incentive mechanism. Let g i be the payment/reward of a buyer/seller SBS i , then its post-payment utility φ i becomes φ i = u i − g i (18)Clearly, the total payment must equal the total reward within a coalition and hence P i ∈ S g i = 0 .If g i > , then SBS i pays g i . If g i < , then SBS i receives | g i | reward.Our payment scheme is developed by following a simple yet strict fairness criterion, namely proportional fairness payoff division . Nevertheless, other fairness criteria, such as egalitarianfair, Shapley value, nucleolus, can also be adopted. In this scheme, the values of payments andrewards are decided by dividing the payoff (the utility improvement) of the whole coalitiondue to cooperation among the SBSs proportionally to their utility achieved without cooperation.Specifically, for SBS i , its post-payment utility will be φ i = ψ i v ( S ) − X j ∈ S v ( { j } ) ! + v ( { i } ) (19)where v ( { i } ) represents the utility of SBS i if it does not join any coalition (so only localprocessing or offloading to the cloud), and ψ i is the proportional weight satisfying P i ∈ S ψ i = 1 and ψ i ψ j = ˜ v ( { i } )˜ v ( { j } ) (20)where ˜ v ( { i } ) is the normalized utility of SBS i within its coalition. The normalization is to mapnegative SBS utilities to a positive interval. It is easy to verify that P i ∈ S φ i = v ( S ) . Based onthe proportional fairness criterion, the payment/reward of SBS i can thus be determined as g i ( S ) = φ i ( S ) − u i ( S ) , ∀ i ∈ S (21)In the above equation, φ i can be interpreted as the expected utility of SBS i by participatingin the coalition, while the u i is the actually realized utility. The gap of the two is filled by thepayment scheme.There are two implementation issues for the payment scheme. First, payments need to beproperly distributed since multiple buyers and sellers may be involved in the transaction.Moreover, direct payment from buyers to sellers faces fraud risks in the monetary transaction.To enable the effective and safe transaction, the edge orchestrator, which is a trusted third-party,collects payments from all buyers and then distributes them to the sellers. C. Stability of Coalitions
SBSs may form multiple disjoint coalitions and there are many ways that SBSs form coalitions.However, we are interested in forming stable coalitions such that no SBS or group of SBSs haveincentives to leave the current coalition to form a different coalition. In particular, the requirementthat all SBSs (buyers and sellers) in a coalition must at least receive higher utilities than workingindividually is a necessary but not sufficient condition for stability.Consider any subset
K ⊆ N of SBSs, we call S = { S , ..., S L } a collection of coalitionsformed by these SBSs, where S l ⊆ K , ∀ l are disjoint subsets of K . If K = N , then we call S a partition of N . A defection function D is a function that associates each possible partition S of N with a group of collections. The stability of a partition S is defined with respect to adefection function. Definition 1. ( D - stability ). A partition S of N is D -stable if no group of SBSs are interested inleaving S and forming a new collection of coalitions S ′ ∈ D ( S ) . That is, at least one SBS insuch a group does not improve its utility by leaving the current partition. In other words, a defection function D restricts the possible ways that SBSs may deviate/defect.Two defection functions are of particular interest. The first function, denoted by D c , associateswith each partition S the group of all possible collections in N , namely there is no restrictionon the way SBSs may deviate. The second function, denoted by D hp , associates each partition S with the group of collections that can be formed by merging or splitting coalitions in S .Therefore, D hp -stability is weaker than D c -stability. In the next section, we design a distributedSBS coalition formation algorithm that achieves at least D hp -stability.IV. D ISTRIBUTED C OALITION F ORMATION
A. Distributed Coalition Formation Algorithm
To present the distributed SBS coalition formation algorithm, we first introduce the notion ofPareto dominance to compare the “quality” of two collections of coalitions.
Definition 2. ( Pareto Dominance ) Consider two collections of disjoint coalitions S and S formed by the same subset of SBSs K ⊆ N . S Pareto-dominates S , denoted by S ⊲ S , if andonly if φ i ( S ) ≥ φ i ( S ) , ∀ i ∈ K with at least one strict inequality for some SBS. Pareto dominance implies that a group of SBSs prefer to form coalitions in S rather than S ,if and only if at least one SBS is able to strictly improve its utility without hurting any otherSBS. The following two operations, namely merge and split [13], are central to our coalitionformation algorithm: • Merge : merge a set of coalitions { S , . . . , S l } into a bigger coalition S lj =1 S j if { S lj =1 S j } ⊲ { S , . . . , S l } . • Split : split a coalition { S lj =1 S j } into a set of smaller coalitions { S , . . . , S l } if { S , . . . , S l } ⊲ { S lj =1 S j } .By performing Merge, a group of SBSs can operate and form a single and larger coalition ifthis formation increases the utility of at least one SBS without decreasing the utility of any otherinvolved SBSs. Hence, a Merge decision ensures that all involved SBSs agree on its occurrence.Likewise, a coalition can decide to split and divide itself into smaller coalitions if splitting ispreferred in the Pareto sense.Our SBS coalition formation algorithm is developed based on the Merge and Split operations,which is presented in Algorithm 2. The algorithm consists of two phases. The coalition formationphase iteratively executes the Merge and Split operations. Given the current partition S , eachcoalition S ∈ S negotiates, in a pairwise manner, with neighboring SBSs to assess a potentialmerge. The two coalitions will then decide whether or not to merge. Whenever a Merge decisionoccurs, a coalition can subsequently investigate the possibility of a Split. Clearly, a Merge or aSplit operation is a distributed decision that an SBS (or a coalition of SBSs) can make. Aftersuccessive Merge-and-Split iterations, the network converges to a partition composed of disjointcoalitions and no coalition has any incentive to further merge or split. In other words, thepartition is Merge-and-Split proof . The convergence of any Merge-and-Split iterations such asthe proposed algorithm is guaranteed as shown in [13]. Upon convergence, the second phase ofthe actual computation offloading then starts using mechanisms described in Section III.
B. Stability Analysis
The outcome of the above algorithm is a partition of disjoint independent coalitions of SBSs.As an immediate result of the definition of D hp stability, every partition resulting from proposedalgorithm is D hp -stable. In particular, no coalitions of SBSs in the final partition have the incentive Algorithm 2
Distributed SBS coalition formation Initial : The SBS network is partitioned by S = N = { , . . . , N } with non-cooperative SBSsat the beginning of each operational time slot. Phase 1: SBS Coalition Formation Repeat (a) S ′ ← Merge( S ): SBS coalitions in S decide to merge by examining the Paretodominance. (b) S ←
Split( S ′ ): SBS coalitions in S ′ make distributed split decision using the Paretodominance. Until
Merge and split converges to a final partition S f Phase 2: Cooperative computation offloading (a) each coalition S i ∈ S f order its buyers in a way to minimize the offloading cost(maximize (17)). Repeat for every S i ∈ S f (b) each buyer in a coalition S i ∈ S f attempts to acquire computation demands in coalition S i . Until no peer offloading in the coalition is available. (c) any buyer who still has unsatisfied computation demand performs SBS-to-cloudoffloading.
These two stages are repeated periodically to adapt the partition to environmental changes.to pursue a different coalition formation through Merge or Split. Next, we investigate whetherthe proposed algorithm can achieve D c -stability.A D c -stable partition has the following properties according to [13]. (i) No SBSs are interestedin leaving S to form other collections in N (through any operation). (ii) A D c -stable partitionis the unique outcome of any arbitrary iteration of merge-and-split, if it exists. (iii) A D c -stablepartition S is a unique ⊲ -maximal partition, i.e., for all partition S ′ = S , we have S ⊲ S ′ .Therefore, the D c -stable partition provides a Pareto optimal utility distribution. However, theexistence of a D c stable partition is not always guaranteed [13]. Nevertheless, we can still havethe following result. Theorem 1.
The proposed distributed SBS coalition formation algorithm converges to the Pareto-optimal D c -stable partition, if such a partition exists. Otherwise, the final partition is D hp -stable.Proof. The proof is immediate due to the fact that, when it exist, the D c -stable partition is aunique outcome of any Merge-and-Split iteration [13], such as any partition resulting from ourcoalition formation algorithm.The stability of the grand coalition (e.g. all SBSs form a single coalition) is of particular interestin the coalitional game theory. It can be easily shown that the considered SBS coalitional gameis generally not superadditive and its core is generally empty due to the extra offloading cost(transmission delay, cost and collaboration risk) and hence, the grand coalition is not stable.Instead, independent disjoint coalitions will form. Readers who are interested in more details onthe stability of grand coalition in coalitional games are referred to [14], [16]. C. Complexity Analysis
The complexity of the proposed coalition formation algorithm lies mainly in the complexityof the Merge and Split operations. For a given network, in one Merge operation, each currentcoalition attempts to merge with other coalitions in a pairwise manner. In the worst case scenario,every SBS, before finding a suitable merge partner, needs to make a merge attempt with allother SBSs in N . In this case, the first SBS requires N − attempts for merge, the secondrequires N − attempts and so on. The total number of merge attempts in the worst case is thus P Ni =1 ( N − i ) . In practice, the merge process requires a significantly lower number of attemptssince finding a suitable partner does not always require to go through all possible merge attempts(once a suitable partner is identified the merge will occur immediately). The complexity is furtherreduced due to the fact that SBSs do not need to attempt to merge with physically unreachableSBSs. Moreover, after the first run of the algorithm, the initial N non-cooperative SBSs willself-organize into larger coalitions. Subsequent runs of the algorithm will deal with a networkcomposed of a number of coalitions that is much smaller than N .For the split operation, in the worst case scenario, splitting can involve finding all the possiblepartitions of the set formed by the SBSs in a single coalition. For a given coalition S , this numberis given by the Bell number P | S | k =1 (cid:0) | S | k (cid:1) which grows exponentially with the number of SBSs | S | in the coalition. In practice, this split operation is restricted to the formed coalitions, and thus it will be applied to small sets. The split complexity is further reduced due to the fact that,in most scenarios, a coalition does not need to search for all possible split forms. For instance,once a coalition identifies a suitable split structure, the SBSs in this coalition will split, and thesearch for further split forms is not needed in the current iteration.V. S IMULATION
In this section, we conduct systematic simulations in practical scenarios to evaluate theperformance of the proposed system and algorithm.
A. Setup
Our simulation adopts the widely-used stochastic geometry approach for ultra dense SBSdeployment, which is modeled as a homogeneous Poisson Point Process (PPP) [17]. Specifically,we simulate a 100m × ×
50m office building where a set of SBSs are deployed whoselocations are chosen according to the PPP with density 0.15. The distribution of MUEs alsofollows another PPP with density 0.6. The task generation process of each MUE is modeledas a Poisson process with a rate of 5 tasks per time slot. The maximum transmission powerof MUEs is set as 10 dBm. The channel model follows the ITU indoor path loss model [18]: L [db] = 20 lg f +10 ν lg d u + L f ( n ) − (The values and corresponding explanations of parametersare shown in TABLE I). The target MUE-SBS transmission rate is r u = 25 Mbps and hencethe corresponding transmission power can be computed. Similar requirements are imposed onthe transmissions between SBSs with SBS maximum transmission power 20 dBm and targettransmission rate r s = 50 Mbps. Figure 4 shows the SBS deployment and MUE association inone operational time slot used in the simulation.For simplicity, we consider a fixed social trust network throughout the simulation time horizon.Nevertheless, our algorithm is also compatible with evolving trust networks that are updatedcontinuously or periodically according to SBS interactions. The adopted social trust network isillustrated in Figure 5. SBSs that are physically unreachable will not have mutual trust values(e.g. SBS 3 and SBS 10). SBSs that are physical neighbors may also miss mutual trust due tothe lack of recent interactions. In this case, a trust value is obtained by finding the shortest pathin the social trust network (e.g. SBS 5 → SBS 10 → SBS 13).The proposed SBS collaboration scheme is compared with three benchmark schemes: TABLE IS
IMULATION SETUP : SYSTEM PARAMETERS
Parameters ValueMaximum UE transmission power p m
10 dBmMaximum SBS transmission power p s
20 dBmUE transmission rate requirement r u
25 MbpsSBS peer transmission rate requirement r s
50 MbpsFrequency (indoor path loss model) f
900 MHzIndoor path loss exponent ν L f ( n ) , n =[1,2,3] [9,12,24] dbNoise power σ -126.2 dbSBS density (PPP) 0.15User density (PPP) 0.6Task arrival rate of MUEs λ a W
20 MHzCloud offloading delay d c,tx X-axis (m)Y-axis (m) Z - a x i s ( m )
50 100
80 806040 40 Small-cell base stationUser equipment
Fig. 4. SBS deployment and MUE association • Non-cooperative scheme : Every SBS does not share computation resources with peer SBSs.For overloaded SBSs, all unsatisfied computation tasks will be offloaded to the cloud server. • Cloud-offloading minimization : The scheme greedily exploits the computation resourcesof peer SBSs to minimize the number of tasks offloaded to the cloud server. Therefore, peer
4 13 5 6 7 8 9 10 11 12 T =0.62 T , = . T , = . Fig. 5. Social trust network offloading is performed whenever possible regardless of the offloading and risk managementcosts. • Centralized collaborative scheme : This scheme uses brutal force to search for the bestcoalition structure that minimizes the total system cost without considering the coalitionstability or SBS incentives.
B. Coalition formation in one time slot D e f i c i t S u r p l u s SBS index -25-20-15-10-50510152025
BuyersSellers
Fig. 6. Computation resource surplus/deficit
We exemplify the distributed coalition formation process by considering the computationsurplus/deficit profile shown in Figure 6 in one operational time slot. Figure 7 depicts theevolution of the intermediate post-payment utilities φ during the coalition formation process, where weights in the cost function are set as w c = 0 . , w r = 0 . , w = 1 . The horizontalaxis represents the iterations in the Merge-and-Split process and for each iteration, we indicateif it is a Merge operation or a Split operation. Since all SBSs have their own computationtasks to process, they incur positive costs (hence negative utilities). In particular, SBSs 1, 5,8, 9, 10, 13 have computation resources deficits. Without SBS collaboration, they have tooffload the extra computation tasks to the remote cloud, thereby incurring large transmissiondelay and cloud payment costs. During the coalition formation, each iteration is executed byfollowing the Merge/Split operation that aims to find a Pareto-dominant coalition partition thanthe current partition. Therefore, after each iteration, at least one of the SBSs improves its utilitieswithout decreasing the utilities of other SBSs. Figure 8 shows the system utility evolution ofeach specific Merge or Split operation. We see that the system utility is improved with everyMerge/Split operation and after only several iterations, the network converges to a stable partitionof coalitions. This indicates that in practice, the complexity of running the proposed algorithmis low and hence, it can be easily implemented. Initial M M M M M M M M S
Action -20-15-10-50510 P o s t - pa y m en t u t ili t y SBS 1SBS 2SBS 3SBS 4SBS 5SBS 6SBS 7SBS 8SBS 9SBS 10SBS 11SBS 12SBS 13
M: Merge S: Split
Fig. 7. Evolution of post-payment utility φ The final coalitions and the number of exchanged computation tasks are presented in Figure 9,where buyers are matched with nearby sellers. Several points are worth noting. First, a coalitioncan contain multiple buyers and multiple sellers and is not necessarily just a matching betweenone buyer and one seller. For example, the coalition { , } involves only one buyer SBS 9 andseller SBS 4, whereas the coalition { , , , } involves two buyer SBSs 8, 13 and two sellerSBSs 3, 6. In particular, SBS 6 is sharing its computation resources with both SBSs 8 and 13. Initial M M M M M M M M S
Action -70-65-60-55-50-45-40-35 S ys t e m U t ili t y M: Merge S: SplitMerge {2};{10}Merge {3};{8} Merge {3,8};{11}Merge {4};{9}Split {1,3,5,6,8,11,13} to {3,6,8,13},{1,5,11}Merge {1,6,5};{3,8,11,13}Merge {3,8,11};{13}Merge {1,6};{5}Merge {1};{6}
Fig. 8. System utility evolution and coalition formation
Second, an SBS may not want to join any coalition. In other words, an SBS may want to forman isolated coalition that contains only itself. In this particular simulation, we observe that SBS7 and SBS 12 separately form isolated coalitions. As a result, the utilities of these two SBSsstay the same before and after the coalition formation. This can also be observed in Figure 7.By reading both Figure 6 and Figure 9, we can see that not all computation demands of buyerscan be satisfied via SBS coalition. For instance, consider SBS 9, it has a computation resourcedeficit for 18 tasks, yet it can only offload 10 tasks to SBS 4, which is the only matched sellerSBS. In this case, the remaining 8 unsatisfied tasks will be offloaded to the cloud. Figure 10further shows the computation resource deficit (or surplus) and the actual computation resourcebought (or sold) for each SBS. Clearly, the deficit (or surplus) serves an upper bound on whatis actually bought (or sold) and hence, the magnitude of the red bar is always larger than thatof the corresponding blue bar. In particular, SBSs 7 and 12 do not sell any of their computationresource surplus to other SBSs. In the same figure, we also show the payments made by buyerSBSs and the rewards received by seller SBSs. It can be verified that the total payment equals thetotal reward within each coalition. For instance, in the coalition { , , , } , the total paymentis 0.19 + 8.30 made by buyer SBSs 8, 13 and the total reward is 4.13 + 4. 36 received by sellerSBSs 3, 6.We note that what coalitions will be formed depends on the adopted cost function. In thisset of simulations, we investigate the impact of the relative weights of offloading cost w c , riskmanagement cost w r and payment to the cloud w . Table II reports the formed SBS coalitions X-axis (m)
12 1 Z - a x i s ( m )
109 510 Y-axis (m) Fig. 9. Coalitions and computation peer offloading
SBS index -10-50510 P a y m en t/ R e w a r d g ( $ ) SBS index -20-1001020 D e f i c i t/ S u r p l u s and B ough t/ S o l d Deficit/Surplus ( )Bought/Sold
Isolated sellersBuyersSellersPaymentReward Isolated sellers
Fig. 10. Payment/reward and bought/sold of SBSs for different weight profiles. We can see that, although in our scenario the grand coalition isdifficult to form due to the physical network constraints, larger coalitions tend to form withsmaller weights assigned to the peer offloading cost and the risk management cost. Figure 11presents the number of formed coalitions and the average coalition size. TABLE IIW
EIGHTS AND COALITION STRUCTURE [ w c , w r , w ] SBS Coalition Structure [0 . , . , . { [1 , , , , , , , , , , } [0 . , . , . { [1 , , , , , , , , } [1 . , . , . { [1 , , , , } [1 . , . , . { [1 , , , the rest isolated SBSs } [1 . , . , . { [1 , , , , the rest isolated SBSs } [1 . , . , . { [1 , , the rest isolated SBSs } Weight w c N u m be r o f c oa li t i on s w r =0.1w r =0.5w r =1w r =2 (a) Number of coalitions Weight w c A v e r age c oa li t i on s i z e w r =0.1w r =0.5w r =1w r =2 (b) Average coalition sizeFig. 11. Impact of weights on coalition formation ( w = 1 ). C. Performance evaluation and comparison
Figure 12 shows the cost incurred by different parts of the system and offers a comparisonwith the three benchmarks. (1) The non-cooperative scheme incurs the highest total cost. Sincethere is no collaboration among the SBSs, each SBS has to offload its extra computation tasks tothe remote cloud, thereby incurring a large transmission delay and cloud payment cost. However,since there is no task offloading between SBSs, its operational cost is lowered and totallyavoids the risk management cost since all tasks are processed locally or in the secure cloud.(2) The purpose of the cloud-offloading minimization scheme is to minimize the number oftasks offloaded to the remote cloud, thereby reducing the transmission delay and cloud paymentcost. As can be seen, the cost due to using cloud service is significantly reduced. However,since the optimization ignores the operation cost due to offloading among SBSs and especiallythe risk management cost, the total cost is still high. (3) The centralized collaborative scheme Operational Cost Risk Management CloudService Weighted Cost (-Utility)020406080 C o s t Distributed coalition formationNon-cooperativeCloud-offloading minimizationCentralized collaborative
Fig. 12. Costs characterization w c W e i gh t ed C o s t (- U t ili t y ) Non-cooperativeWithout MUE-SBS associationWith MUE-SBS association
Fig. 13. Advantage of MUE-SBS association scheme minimizes the overall network cost by jointly considering all cost sources, thereby achievinga much lower total cost. However, the centralized scheme is performed under the assumptionthat all SBSs are cooperative with no incentive issues, which is not suitable for our consideredproblem where SBSs are self-interested. (4) Our proposed solution based on the coalitional gamegracefully addresses the incentive challenge. As can be seen, the proposed algorithm achievessimilar performance to the centralized scheme while ensuring that the adopted coalitions arestable.In Figure 13, we demonstrate the benefits achieved by introducing the workload balancing inMUE-SBS association, which is a distinct feature of ultra dense SBS networks and that existingwork [9] did not consider. We run the coalition formation algorithm under two settings: with andwithout MUE-SBS association scheme. As can be observed, the MUE-SBS association scheme
10 20 30 40 50 60 70 80 90
Number of MUEs W e i gh t ed c o s t (- U t ili t y ) N u m be r o f SBS bu y e r s / s e ll e r s Distributed coalition formationNon-cooperativeCloud-offloading minimizationCentralized collaborativeNumber of SBS buyersNumber of SBS sellers
Exceeds system capacitymaximum utility gain(relative) 41%maximum utility gain(absolute) 23.5
Fig. 14. Impact of MUE number
Fraction of private task W e i gh t ed c o s t (- U t ili t y ) Distributed coalition formationNon-cooperativeCloud-offloading minimizationCentralized collaborative
Utility gain
Fig. 15. Impact of private fraction τ helps to reduce the system cost and the cost reduction depends on the value of w c . When w c is small, the transmission delay and energy consumption saved by MUE-SBS associationscheme are less valued, therefore, a modest cost reduction is realized. As the w c increases, theedge system benefits more by adopting the MUE-SBS association scheme. However, as shownpreviously, a too large w c discourages formation of SBS coalitions which restrains the role ofMUE-SBS association. Hence, the benefit of MUE-SBS association scheme diminishes whenthe w c grows larger than 0.6.How much performance improvement (i.e. cost reduction) can be achieved by SBS coalition Time slots T a sk r eque s t s t o SBS s s max SBS 1SBS 2SBS 3SBS 4SBS 5SBS 6SBS 7SBS 8SBS 9SBS 10SBS 11SBS 12SBS 13
Fig. 16. Dynamics of task arrival
Time slots S ys t e m u t ili t y ga i n SBS 1SBS 2SBS 3SBS 4SBS 5SBS 6SBS 7SBS 8SBS 9SBS 10SBS 11SBS 12SBS 13
Fig. 17. Dynamics of utility gain will depend on the spatial traffic pattern in the network. Intuitively, if all SBSs have a lightworkload, then there is no need for collaboration, whereas if all SBSs are overloaded, then it isnot possible to collaborate. Now, we investigate the performance of collaborative edge computingas a function of the system utilization level (i.e. ratio of expected task number in the network tosystem computation capacity P i ∈N ω max i ). We simulate a spectrum of the system utilization levelby changing the number of MUEs in the network. Figure 14 depicts the impact of the numberof MUEs on the collaborative performance in terms of total system cost. When there are only afew MUEs, most of the SBSs can use its own computation resource to satisfy the computationrequests. The system is thus a “buyers’ market”. When there is an excessive number of MUEs,most of the SBSs need extra computation resources. The system is thus a “sellers’ market”. Inboth cases, coalitions are difficult to form. The maximum utility gain by collaboration occurswhen the system computation capacity matches the number of MUEs. By allowing collaborationamong SBSs, the spatial workload intensity heterogeneity is mitigated via workload balancing.In our simulations, the maximum absolute utility gain is achieved at around 50 MUEs and themaximum relative utility gain (41%) is achieved at around 40 MUEs.The performance improvement by SBS coalition also depends on how flexibly computationtasks can be offloaded. Recall that computation tasks can be either normal tasks or private tasksthat must be processed locally or offloaded to the remote cloud. Figure 15 shows the impactof the fraction of the private tasks among the total tasks. As can be seen, a larger utility gainis achieved at a lower fraction of private tasks because peer offloading among SBSs is moreflexible. Again the proposed coalition formation algorithm significantly reduces the total system cost and achieves close-to-optimal performance.In order to evaluate the performance of proposed algorithm over multiple operational slots,we further simulate a dynamic edge system with random MUE arrival and computation taskarrival; the social trust network is assumed to be observed and updated every 5 slots. Thetotal task requests received by SBSs are given in Figure 16. With the temporally heterogeneouscomputation task requests, the SBSs intermittently switch between “buyer” and “seller” modes.Figure 17 shows the corresponding system utility gain across 30 operational slots, where eachcolor block denotes the post-payment utility of an SBS. It can be observed that the system utilitygain is mainly decided by the buyer-seller composition in the edge system. For example in timeslot 23, there is only one “buyer” (SBS 6) in the system and all other SBSs are in the “seller”mode. In this case, only one coalition { } is formed and a low system utility gain is realized.By contrast, in time slot 15, a more balanced composition of “seller” and “buyers” is presented,where buyers have a large demand for computation resource which can be potentially satisfiedby the sellers. This motivates the formation of SBS coalitions and hence results in larger systemutility gain. VI. R ELATED WORK
Resource allocation in small cell networks has been widely studied in the literature. Forinstance, belief propagation method is applied to manage interference problems in the femtocellnetwork[19]. Orthogonal bandwidth allocation for femtocells is investigated using fractionalfrequency reuse [20]. However, these works only manage communication resources and do notconsider the computing capabilities of SBSs and how SBSs can form a pool of computationalresources while providing radio access service. Computational resource sharing is the mainconcern of geographical load balancing techniques originally proposed for data centers todeal with spatial diversities of workload patterns [10] and electricity prices [11]. However,conventional clouds manage only computational resources without considering the radio access.In edge systems, the provisioning of radio access between the SBSs and end users is a criticaldesign aspect that has a significant impact on the system performance. Recently, with SBSs beingconsidered as a major form of edge devices in the new edge computing paradigm, increasinglymany works start to look at the joint optimization of computation and communication resourcesof SBSs [21], [22]. However, most of these works assume that the coalitions among the SBSs have already been determined and focus on the offloading decisions of MUEs. In [23], [24],computation clusters of SBSs are optimally built by performing joint allocation of radio andcomputation resources, focusing on reducing the power consumption and processing complexity.However, the incentive issue of SBSs is not considered.Since SBSs are typically developed by individual owners, how to provide SBSs with incentivesto collaborate is key to improving the overall system performance. In [25], [26], [27], incentivemechanisms based on game theoretic methods are designed to motivate femtocells to adoptopen/hybrid radio access mode, which does not consider the cooperative edge computing. In[28], a double auction mechanism is developed for matching user computation request to a setof cloudlets. These works consider incentives of SBSs to provide services to end users. Ourpaper studies incentives of SBSs to collaborate among each other.The coalitional game theory is a powerful tool for studying user cooperation problems withindividual incentive issues, which has been widely adopted in various problems, e.g. interferencemanagement [29], [30], spectrum sensing [31] and smart grids [15], [32]. Recently, it is alsointroduced in [9] to the collaborative edge computing system for forming Femto-clouds amongindividual femtocells. Our considered system differs from this paper in the following aspects.First, we consider an ultra dense deployment scenario. Therefore, collaboration does not onlyoccur on the SBS peer offloading level but also on the MUE-SBS association level. Second, weconsider socially-trusted collaboration by introducing the social trust network. This allows riskmanagement between any pair of SBSs.VII. C ONCLUSION
In this paper, we investigated collaborative edge computing in a densely-deployed small cellnetwork, where the SBSs are incentivized to form coalitions and cooperate with SBS peers toincrease system utility. Within the coalitions, buyers and sellers are allowed to cooperate at bothMUE-SBS association stage and SBS peer offloading stage by exploiting the dense deployment ofSBSs. We developed a distributed coalition formation algorithm based on Merge-and-Split rules.The proposed algorithm jointly considers SBS operational cost, cloud service fees, and potentialsecurity risks during coalition formation and guarantees the stability of coalitions by followinga payment-based incentive mechanism. Our simulation results show that the collaborative edgesystem can dramatically reduce the system cost by more than 40%. Our study not only provides new guidelines for cooperation among densely deployed edge devices but also delivers importantinsights for social trust and security issues in edge cooperation, which deserves more futureinvestigation in collaborative edge computing systems.R EFERENCES [1] Y. Mao, C. You, J. Zhang, K. Huang, and K. B. Letaief, “Mobile edge computing: Survey and research outlook,” arXivpreprint arXiv:1701.01090 , 2017.[2] W. Shi, J. Cao, Q. Zhang, Y. Li, and L. Xu, “Edge computing: Vision and challenges,”
IEEE Internet of Things Journal ,vol. 3, no. 5, pp. 637–646, 2016.[3] J. Rivera and R. van der Meulen, “Gartner says the internet of things will transform the data center,”
Retrieved August ,vol. 5, p. 2014, 2014.[4] P. Garcia Lopez, A. Montresor, D. Epema, A. Datta, T. Higashino, A. Iamnitchi, M. Barcellos, P. Felber, and E. Riviere,“Edge-centric computing: Vision and challenges,”
SIGCOMM Comput. Commun. Rev. , Dec 2016, pp. 1–6.[7] T. Zhao, S. Zhou, X. Guo, Y. Zhao, and Z. Niu, “A cooperative scheduling scheme of local cloud and internet cloud fordelay-aware mobile cloud computing,” in , Dec 2015, pp. 1–6.[8] J. G. Andrews, S. Buzzi, W. Choi, S. V. Hanly, A. Lozano, A. C. Soong, and J. C. Zhang, “What will 5g be?”
IEEEJournal on selected areas in communications , vol. 32, no. 6, pp. 1065–1082, 2014.[9] S. Tanzil, O. Gharehshiran, and V. Krishnamurthy, “A distributed coalition game approach to femto-cloud formation,”
IEEETransactions on Cloud Computing , 2016.[10] M. Lin, Z. Liu, A. Wierman, and L. L. Andrew, “Online algorithms for geographical load balancing,” in
Green ComputingConference (IGCC), 2012 International . IEEE, 2012, pp. 1–10.[11] J. Luo, L. Rao, and X. Liu, “Spatio-temporal load balancing for energy cost optimization in distributed internet datacenters,”
IEEE Transactions on Cloud Computing , vol. 3, no. 3, pp. 387–397, July 2015.[12] T. Basar and G. J. Olsder,
Dynamic noncooperative game theory . SIAM, 1998.[13] K. R. Apt and A. Witzel, “A generic approach to coalition formation,”
International Game Theory Review , vol. 11, no. 03,pp. 347–367, 2009.[14] W. Saad, Z. Han, M. Debbah, A. Hjorungnes, and T. Basar, “Coalitional game theory for communication networks,”
IEEESignal Processing Magazine , vol. 26, no. 5, pp. 77–97, 2009.[15] W. Saad, Z. Han, and H. V. Poor, “Coalitional game theory for cooperative micro-grid distribution networks,” in , June 2011, pp. 1–5.[16] A. Bogomolnaia and M. O. Jackson, “The stability of hedonic coalition structures,”
Games and Economic Behavior , vol. 38,no. 2, pp. 201–230, 2002.[17] F. Baccelli, B. Baszczyszyn et al. , “Stochastic geometry and wireless networks: Volume ii applications,”
Foundations andTrends R (cid:13) in Networking , vol. 4, no. 1–2, pp. 1–312, 2010. [18] P. Series, “Propagation data and prediction methods for the planning of indoor radiocommunication systems and radiolocal area networks in the frequency range 900 mhz to 100 ghz,” Recommendation ITU-R , pp. 1238–7, 2012.[19] S. Rangan and R. Madan, “Belief propagation methods for intercell interference coordination in femtocell networks,”
IEEEJournal on Selected Areas in Communications , vol. 30, no. 3, pp. 631–640, April 2012.[20] J. Y. Lee, S. J. Bae, Y. M. Kwon, and M. Y. Chung, “Interference analysis for femtocell deployment in ofdma systemsbased on fractional frequency reuse,”
IEEE Communications Letters , vol. 15, no. 4, pp. 425–427, April 2011.[21] O. Munoz, A. Pascual-Iserte, and J. Vidal, “Optimization of radio and computational resources for energy efficiency inlatency-constrained application offloading,”
IEEE Transactions on Vehicular Technology , vol. 64, no. 10, pp. 4738–4755,2015.[22] S. Barbarossa, P. Di Lorenzo, and S. Sardellitti, “Computation offloading strategies based on energy minimization undercomputational rate constraints,” in
Networks and Communications (EuCNC), 2014 European Conference on . IEEE, 2014,pp. 1–5.[23] J. Oueis, E. C. Strinati, and S. Barbarossa, “The fog balancing: Load distribution for small cell cloud computing,” in , May 2015, pp. 1–6.[24] ——, “Small cell clustering for efficient distributed cloud computing,” in , Sept 2014, pp. 1474–1479.[25] Y. Chen, J. Zhang, and Q. Zhang, “Utility-aware refunding framework for hybrid access femtocell network,”
IEEETransactions on Wireless Communications , vol. 11, no. 5, pp. 1688–1697, May 2012.[26] S. Y. Yun, Y. Yi, D. H. Cho, and J. Mo, “The economic effects of sharing femtocells,”
IEEE Journal on Selected Areasin Communications , vol. 30, no. 3, pp. 595–606, April 2012.[27] R. Langar, S. Secci, R. Boutaba, and G. Pujolle, “An operations research game approach for resource and power allocationin cooperative femtocell networks,”
IEEE Transactions on Mobile Computing , vol. 14, no. 4, pp. 675–687, April 2015.[28] A. L. Jin, W. Song, and W. Zhuang, “Auction-based resource allocation for sharing cloudlets in mobile cloud computing,”
IEEE Transactions on Emerging Topics in Computing , vol. PP, no. 99, pp. 1–1, 2016.[29] Z. Zhang, L. Song, Z. Han, and W. Saad, “Coalitional games with overlapping coalitions for interference management insmall cell networks,”
IEEE Transactions on Wireless Communications , vol. 13, no. 5, pp. 2659–2669, 2014.[30] F. Pantisano, M. Bennis, W. Saad, M. Debbah, and M. Latva-Aho, “Interference alignment for cooperative femtocellnetworks: A game-theoretic approach,”
IEEE Transactions on Mobile Computing , vol. 12, no. 11, pp. 2233–2246, 2013.[31] W. Saad, Z. Han, T. Basar, M. Debbah, and A. Hjorungnes, “Coalition formation games for collaborative spectrum sensing,”
IEEE Transactions on Vehicular Technology , vol. 60, no. 1, pp. 276–297, Jan 2011.[32] W. Lee, L. Xiang, R. Schober, and V. W. S. Wong, “Direct electricity trading in smart grid: A coalitional game analysis,”