Resource Sharing in the Edge: A Distributed Bargaining-Theoretic Approach
We use a two-player game as a toy example to introduce NBS. Consider two players $`1,`$ and $`2`$ that need to reach an agreement (e.g., resource allocation decision) in an outcome space $`\mathcal{A}\subseteq \mathbb{R}^2`$ . Both players have a utility given by $`u_1`$ and $`u_2`$ over the space $`\mathcal{A} \cup \{D\}`$ where $`D`$ specifies a disagreement outcome for players in the event of a disagreement, i.e., when two players cannot reach an agreement. Let $`\mathcal{S}`$ be the set of all possible utilities that both players can achieve:
\begin{align}
\label{eq:possibleut}
\mathcal{S}= \{(u_1(a_1),u_2(a_2)) | (a_1,a_2) \in \mathcal{A} \}
\end{align}
We also define $`d=(d_1, d_2)`$, where $`d_1=u_1(D)`$ and $`d_2=u_2(D)`$, as the payoff each player receives at the disagreement point. We define the bargaining problem as the pair $`(\mathcal{S},d)`$ where $`\mathcal{S} \subset \mathbb{R}^2`$ and $`d \in \mathcal{S}`$ such that
-
$`\mathcal{S}`$ is a convex and compact set;
-
There exists $`s \in \mathcal{S}`$ such that $`s > d`$.
In NBS, the goal is to obtain a function $`f(\mathcal{S},d)`$ that provides a unique outcome in $`\mathcal{S}`$ for every bargaining problem $`(\mathcal{S},d)`$. Nash studied the possible outcomes (agreements) that players can reach whereas the agreements, along with the Pareto optimality, must also satisfy the following set of axioms (also called fairness axioms) :
-
Symmetry: The bargaining solution will not discriminate among players if players are indistinguishable, i.e., players have identical utilities.
-
Invariance to equivalent utility representation: If a bargaining problem $`(\mathcal{S},d)`$ is transformed into another bargaining problem $`(\mathcal{S}',d')`$ where $`s_i'=\gamma_is_i+\zeta_i`$ and $`d_i'=\gamma_id_i+\zeta_i`$, $`\gamma_i >0`$, then $`f( \mathcal{S}',d')=\gamma_if(\mathcal{S},d)+\zeta_i`$
-
Independence of irrelevant alternatives: For any two bargaining problems $`(\mathcal{S},d)`$ and $`(\mathcal{S}',d)`$ where $`\mathcal{S}'\subseteq \mathcal{S}`$, if $`f(\mathcal{S},d) \in \mathcal{S}'`$, then $`f(\mathcal{S}',d)=f(\mathcal{S},d)`$.
shows that there is a unique bargaining solution that satisfies above axioms. We present it in the following theorem.
There exists a unique solution satisfying the aforementioned axioms and this solution is the pair of utilities $`(s_1^*,s_2^*) \in \mathcal{S}`$ that solves the following optimization problem:
\begin{align}
\label{eq:nashProb}
\max_{s_1,s_2}\;(s_1-d_1)(s_2-d_2),\; s.t. (s_1,s_2)\in \mathcal{S}, \; (s_1,s_2)\geq (d_1,d_2).
\end{align}
The solution of [eq:nashProb] is the NBS. The above framework can be extended to $`N`$ players by allowing $`\mathcal{S}`$ to be an $`N`$-dimensional space . For this case, the bargaining problem $`(\mathcal{S},d)`$, with $`d=(d_1,d_2,\cdots, d_N)`$ as the disagreement point, becomes the unique solution of the optimization problem below.
\begin{align}
\vspace{-0.1in}
\label{eq:nashProbNplayer}
\max_{s_1,\cdots,s_N}&\;\prod_{n=1}^{N}(s_n-d_n),\; \nonumber \\
s.t.\quad &(s_1,\cdots,s_N)\in \mathcal{S}, \nonumber \\
& (s_1,\cdots,s_N)\geq (d_1,\cdots, d_N).
\end{align}
Solving [eq:nashProb] is easier compared to the $`N-`$player bargaining problem in [eq:nashProbNplayer]. In this paper, we transform our problem into an equivalent convex problem that is comparatively easier to solve.
As each player in an $`N`$-player bargaining game has a particular objective to optimize, the resulting problem is multi-objective, where the goal is to obtain a Pareto optimal solution. NBS is a fair and Pareto optimal solution for such MOO problems, provided that the fairness axioms are satisfied.
Any entity or service provider that has specific resources such as CPU, storage and communication links can serve as the building block of our system as shown in Figure 1. We call this basic building block a domain1. The domain can be as small as a sensor and as large as data centers. Each domain has a domain controller that is aware of all resources available within the domain. The domain controller only shares an abstraction of this resource information and does not share the entire information2. Different domains share resources with the presence of a coalition controller. The coalition controller can be either a separate controller or chosen among the domain controllers. Table 1 provides notation used in this paper. Below, we model our resource allocation and sharing problem from a game theoretic perspective.
| NOT. | Description | NOT. | Description |
|---|---|---|---|
| $`\mathcal{N}`$ | Set of game players | $`n`$ | Player from set $`\mathcal{N}`$ |
| $`\mathcal{M}`$ | Set of applications | $`\mathcal{M}_n`$ | Set of native applications of player $`n`$ |
| $`\mathcal{K}`$ | Set of resource types | $`k`$ | Resource from set $`\mathcal{K}`$ |
| $`C^{(n)}`$ | Capacity of player $`n`$ | $`C_k^{(n)}`$ | Capacity of $`k^{th}`$ resource at player $`n`$ |
| $`x_{ik}^{(n)}`$ | Resource $`k`$ allocated to application $`i`$ by player $`n`$ | $`r_{ik}^{(n)}`$ | Request for resource $`k`$ from application $`i`$ of player $`n`$ |
List of notations (Not.) used in the paper
Let $`\mathcal{N}=\{1,2, \cdots, N\}`$ be the set of all domains (or service providers) that act as players in our game. We assume that each player has a set of $`\mathcal{K}=\{1,2,\cdots, K\}`$ different types of resources such as communication, computation and storage resources. The $`n`$-th domain reports its available resources $`C^n = \{ C_1^{(n)},\cdots, C_K^{(n)}\}`$ to a central entity, the coalition controller. Here $`C_k^{(n)}`$ is the amount of type $`k`$ resources available to domain $`n`$. Vector $`C=\{\sum_{n \in \mathcal{N}}C_{1}^{(n)}, \sum_{n \in \mathcal{N}}C_{2}^{(n)}, \cdots ,\sum_{n \in \mathcal{N}}C_{K}^{(n)}\}`$ represents all available resources in different domains. Each domain $`n`$ has a set of native applications $`\mathcal{M}_n= \{1,2,\cdots, M_n\}`$ that ask for resources. Furthermore, the set of all applications that ask for resources from the set of domains (coalition of domains) is given by $`\mathcal{M}=\mathcal{M}_1\cup\mathcal{M}_2\cdots\cup \mathcal{M}_N , \;`$ where $`|\mathcal{M}|=M`$, and $`\mathcal{M}_i \cap \mathcal{M}_j=\emptyset, \; \forall i \neq j,`$ i.e., each application originally asks only one domain for resources. The coalition controller receives a request (requirement) matrix $`R^{(n)}`$ from every player (domain) $`n \in \mathcal{N}`$.
\begin{equation}
\label{eq:R_Req}
R^{(n)}=\Biggl[\begin{smallmatrix}
\mathbf{r^{(n)}_1}\\
.\\
.\\
.\\
\mathbf{r^{(n)}_{{M}_n}}
\end{smallmatrix}\Biggr] = \Biggl[\begin{smallmatrix}
r^{(n)}_{11} & \cdots &\cdots & r^{(n)}_{1{K}} \\
. & . &. &. \\
. & . &. &. \\
. & . &. &. \\
r^{(n)}_{M_{n}1}&\cdots &\cdots & r^{(n)}_{{M}_n{K}}
\end{smallmatrix}\Biggr].
\end{equation}
where the $`i^{th}`$ row corresponds to the $`i^{th}`$ application while columns represent different resources, i.e., $`r_{ij}^{(n)}`$ is the amount of $`j^{th}`$ resource that application $`i \in \mathcal{M}_n`$ requests. The coalition request matrix $`R`$ is a combination of all the request matrices (from all the domains) as given below.
\begin{equation}
\label{eq:R_Reqco}
R^{}=\Biggl[\begin{smallmatrix}
\mathbf{r^{}_1}\\
.\\
.\\
.\\
\mathbf{r^{}_{{M}}}
\end{smallmatrix}\Biggr] = \Biggl[\begin{smallmatrix}
r^{}_{11} & \cdots &\cdots & r^{}_{1{K}} \\
. & . &. &. \\
. & . &. &. \\
. & . &. &. \\
r^{}_{M1}&\cdots &\cdots & r^{}_{{M}{K}}
\end{smallmatrix}\Biggr].
\end{equation}
where $`r_{ij}`$ is the amount of $`j^{th}`$ resource that application $`i \in \mathcal{M}`$ requests. The coalition, based on $`R`$ and $`C`$, has to make an allocation decision $`\mathcal{X}`$ that optimizes the utilities of all the domains $`n \in \mathcal{N}`$. The allocation decision for the entire coalition $`\mathcal{X}`$ consists of all the allocation decisions $`X^{(n)}`$ in every domain $`n \in \mathcal{N}`$ i.e., $`\mathcal{X}=\{X^{(1)},X^{(2)},\cdots, X^{(N)}\}`$. Mathematically, $`X^{(n)}`$ is represented by
\begin{equation}
\label{eq:A_n}
X^{(n)}=\Biggl[\begin{smallmatrix}
\mathbf{x_1^{(n)}}\\
.\\
.\\
.\\
\mathbf{x_{{{M}}}^{(n)}}
\end{smallmatrix}\Biggr] = \Biggl[\begin{smallmatrix}
x_{11}^{(n)} & \cdots &\cdots & x_{1{K}}^{(n)} \\
. & . &. &. \\
. & . &. &. \\
. & . &. &. \\
x_{{{M}}1}^{(n)}&\cdots &\cdots & x_{{{M}}{K}}^{(n)}
\end{smallmatrix}\Biggr].
\end{equation}
where $`x_{ik}^{(n)}`$ is the amount of resource $`k\in \mathcal{K}`$ belonging to player $`n \in \mathcal{N}`$ that is allocated to application $`i \in \mathcal{M}`$.
-
Throughout the paper, we will use domain, service provider and player interchangeably. ↩︎
-
This can be due to a number of reasons including security and privacy. For example, Amazon and Dropbox may share limited information to satisfy their user’s needs. However, they will not provide the entire information to each other. ↩︎