In this section, we discuss the proposed mechanism, called IBRC for MHMM, and show that it achieves good resource utilization. We analyze the mechanism's truthfulness and computational complexity, and compare the signaling overhead with that of the traditional centralized approach.
4.1. Business model and proposed scheme
Before discussing the proposed scheme, we describe the business model. To distribute the wireless resource efficiently, we adopt the concept of the Bandwidth Broker (BB) proposed in [27]. The BB is operated by the network carrier or service provider that owns the radio bandwidth. The value of the unit price is discrete and chosen by the BB from a predetermined matrix , where Imax is the number of price options. To transmit a stream and earn revenue from the SSs, each sender must submit its resource requirement under each unit price(i.e., required resources under P
i
, i = 1 to Imax) to the BB. After the BB decides the final unit price and allocates the resources, the senders use the acquired resources to deliver the streaming content and derive their profit from the SSs, which pay their respective senders a fixed price (i.e., pstream) for the received data. However, when the channel quality is good enough, each RS can receive the stream from other senders free of charge because the stream is subscribed by the SSs and has no utility to the RS itself. Figure 3 shows an example of the relationship between the BS, RSs, SSs, and the BB in a network.
The pseudo-code of IBRC is shown in Figure 4. Since the BB is the core agent of the proposed procedure, it executes the main function of IBRC. For all possible unit prices P
i
, i = 1, 2, ..., Imax, the BB implements the algorithm to query all senders in order to determine the amount of the resource each one wants to buy under unit price P
i
. It then decides the final allocation (i.e., ). To distinguish between processed and unprocessed nodes, we let array asked_RS record if the RSs have been queried already and served_SS indicate the SSs that have received the stream. Meanwhile, a binary array D records the current value of for all m.D is initialized as [1, 0, 0, ... 0] because only the BS (i.e., node 0) can receive the stream initially. Consequently, the BB always queries the BS first, and the value of D is updated by the function query, which we discuss later in this section. In the subsequent round of the do loop, the BB selects an available sender, which is a sender m that (1) has not been queried before (i.e., ask_RS[m] == 0), and (2) can receive the stream with the given allocation (i.e., D[m] == 1). It then queries the sender m for a bidding decision (, served_SS_new, D
new
) via the function query and marks the array asked _RS[m] as 1. If more than one RS satisfies the above conditions, they are selected at random so that each sender is queried in a different order for different prices. As a result, a sender cannot block the service of other senders.
Based on the value of pstream and served_SS, the queried sender m indicates its preferred resource . To maximize its profit, m sets as . If m is allocated the required resource, the arrays served_SS_new and D
new
record the new served_SS and D, respectively. The steps of the procedure are shown in Figure 5. If , the BB updates allocation by setting , since the residual resource is still sufficient to serve m. It also updates served_SS and D with served_SS_new and Dnew, respectively. The new served_SS and D are given to the sender queried in the next round. This procedure repeats until no more SSs can be served (i.e., include_node == 0) because all senders have been queried, or all SSs have been served, or the resource is exhausted. After obtaining the requested allocations under all prices (i.e., , i = 1, 2, ..., Imax), the BB decides the unit price by setting i
set
to . It then distributes the resource to each sender based on .
As shown in Figure 5, each sender only participates if the allocation will be profitable. In other words, the revenue each sender receives from the SSs (i.e., Pstream N, where N is the number of SSs the sender serves,) must be greater than the price it pays the BB for the resource. Therefore, the preferred amount of resource it submits to the BB is proportional to the lower bound of the number of served users. For the BB, given the preferred resource of sender m under the unit price p
i
, it can derive revenue of and serve at least senders. Therefore, under p
i
, the total revenue that the BB can derivefrom all senders is , and it can serve at least SSs. Therefore, when the BB tries to maximize its revenue (i.e., ), it also maximizes the lower bound of the served SSs (i.e., ). In other words, the BB sets the price to maximize the efficiency of global resource allocation among senders. Meanwhile, each sender attempts to maximize its profit by serving as many users as possible with the given resource.
Clearly, IBRC can utilize RSs to make resource allocation more efficient. As mentioned earlier, the BB queries each sender for its preferred resource under each price. Since the BS is always the first sender to be queried, it is always offered the same array served_SS = [0, 0, ..., 0], irrespective of the number of RSs in the network. Given the same served_SS and identical channel conditions r0,M+1, r0,M+2, ..., r0,M+N, the BS always requests the same amount of the resource and serves the same number of SSs regardless of the number of RSs. Therefore, if there are RSs in the network, the SSs that were originally served by BS will always be served; while unserved SSs can be served by the RSs. This means that the performance of the RSs is always at least as good as that of the pure-BS approach.
4.2. Best strategies for each agent
As mentioned in Section 1, each agent is selfish, so its objective is to maximize its income. Therefore, we have to prove that the operation of IBRC can yield the maximum revenue so that each sender can operate as proposed under IBRC. In the analysis, we assume that each role in the system makes decisions in dependently, and no collusion occurs. In IBRC, the BB's strategy is to set the price index i
set
as , as shown in the last two lines of Figure 4. The process implemented by each sender (i.e., function query) is detailed in Figure 5. The sender m sets the preferred resource as , and returns arrays served_SS_new and D
new
to indicate the changes to served_SS and D if it is allocated resource . In Theorems 4.1 and 4.2, we prove that these functions yield the maximum profit; thus, they are the most effective strategies for the BB and the RSs, respectively.
Theorem 4.1 Setting i
set
as yields the highest expected revenue for the BB.
Proof:
If the radio resource is sold at unit price pi, the BB's profit is the price p
i
multiplied by the total amount of the resource consumed under p
i
. Since the allocation under p
i
is , the total resource consumed is . To maximize its profit, the BB must choose the price p
i
that maximizes the value of . Therefore, the best price for the BB (i.e., i
set
) would be .
Theorem 4.2 The pseudo-code in Figure 5(i.e., acting truthfully) yields the highest expected revenue for each sender.
Proof:
In IBRC, the BB queries each sender for its preferred resource requirement under all prices (i.e., query(m, pstream, p
i
, served_SS, D)). To determine the amount of the resource that would maximize its profit, each sender m bases its decision on the array served_SS and the local information about the channel quality (i.e., r
m,n
for all n). Since senders do not exchange information, they are not aware of each other's preferred resource (i.e., for all m) or channel quality (i.e., r
m',n
for all m' and n). Moreover, under the rules of the proposed schemes, senders are not given any information about the resource budget rbudget, which is only stored in the BB. Senders are also queried in different orders for different prices, as mentioned earlier. Therefore, it is impossible for a sender to predict the decisions of other senders and the BB, let alone alter the result. Consequently, the probability that the resource price is p
i
can be viewed as an unknown value 0≤ p
i
≤ 1, where . Given that R
m,i
(r) denotes the revenue of each sender m if it buys resources r under price p
i
, the total expected value of the revenue is . Therefore, irrespective of the value of p
i
, the most effective strategy is to maximize R
m,i
(r) for all i because other decisions would not yield revenues larger than .
Next, we consider finding under a given price p
i
. When the resource claimed by m is 0, its profit is 0. It pays nothing and earns nothing because the sender does not receive the stream from other senders, so it does not serve any nodes. If r (i.e., the allocated resource) ≥ 0, then , where rp
i
is the total price the sender has to pay the BB; while is the income m receives from the SSs it serves. Therefore, under this dominant strategy, for all prices p
i
, m's preferred amount of resource (i.e., the best strategy to use when requesting the resource)would be , as shown in the second line of Figure 5.
4.3. Computational complexity
Theorem 4.3 The computational complexity of IBRC is polynomial.
Proof:
As shown in Figure 4, the main function of IBRC comprises two for loops and one do loop. The complexity of the first for loop is O(1) because I
max
is a constant; while the complexity of the do loop is O(M) because it queries at least one sender in each round and thus executes M times at most. The complexity of the second for loop is also O(M) because the value of m ranges from 0 to M. Finally, the complexity of the pricing decision (i.e., i
set
← ) is O(M) because, for each price, the BB has to sum the resource requirements of all the senders. The function query has to consider n = 0 to N, and the subsequent two for loops execute N and M times, respectively. Therefore, its overall complexity is O(N + N + M) ≅ O(N) because, in a relay network. The number of SSs should be much larger than the number of RSs. Combining all the loops and sub-functions based on the loop structure, the overall complexity of IBRC is O(M M N + M) = O(M2N), which is in polynomial time.
Note that although the worst-case complexity of IBRC is O(M2N), the actual overhead during computation is much lower and approximates O(MN). This is because, in each round of the first for loop in the main function, the algorithm picks one available sender to query. In a round where the sender m does not satisfy the conditions (i.e., D
m
== 1 and asked_RS[m] == 0), only one simple judgment is made, so its complexity can be ignored. After the algorithm queries the selected sender, it exits the for loop and starts the next round of the do loop. Therefore, the combined complexity of the first for loop and the do loop approximates O(M), so the complexity of IBRC also approximates O(MN).
4.4. Truthfulness analysis
Under IBRC, the system must ensure that the transactions about the resource between the senders and the BB, as well as the transactions about the multicast stream between the senders and SSs, are undeniable and cannot be forged. This can be achieved by providing some group signature/cypher technologies, by making a contractual agreement in advance, or by using a third-party to monitor the transactions. For example, an SS has to pay the sender pstream for the key to decode the multicast stream. If the sender not serve the SS after receiving pstream, it will be reported and penalized. Similarly, since all senders inform the BB about their preferred resource at a certain price (i.e., ), the system has complete information about the senders' resource requirements under all prices. Hence, the system can penalize a sender if it does not pay for the allocated resource, or if the BB receives the payment and does not allocate the resource. On the other hand, the reply to query is based on each sender's incentive. In the first for loop in Figure 5, the sender m marks all the SSs that it serves (i.e., ) by letting served_SS_new[n] = 1, and leaves the remaining SSs unchanged (i.e., served_SS_new[n] = served_SS [n]). Similarly, it updates array D by marking all RSs that it serves as 1 in the second for loop. The array served_SS_new and D
new
returned by m can only influence other senders that have not been queried. Since the BB queries those senders after allocating the resource to m, if m updates served_SS_new or D
new
incorrectly, the altered behavior of senders queried afterwards cannot benefit m, or the SSs that m serves. Recall that senders are queried in a different order for each price so they cannot prevent each other from being served by providing false served_SS_new and D
new
information. In other words, senders do not have any incentive to give false information; thus, the design of IBRC encourages honesty.
4.5. Signaling overhead
If a centralized approach is used to solve MHMM, the information about the channel quality between all nodes must be concentrated in one place (typically the BS) so that the algorithm can gain a complete picture of the network and calculate the outcome. Consequently, the channel quality of M + N nodes must be transmitted separately over the wireless medium. For M + N nodes, the number of channel conditions between each pair of nodes (i.e., r
i,j
for all r
i,j
, 1 ≤ i, j ≤ M + N and i ≠ j,) is O((M + N)2. Under a traditional centralized allocation scheme, the RSs would have to report all of this information before a central node could allocate the resource. In contrast, the signaling overhead of IBRC is O(M(M + N)) because, for i = 1 to Imax, the algorithm only queries each sender once (i.e., by calling the function query). For each query, the sender returns the arrays served_SS_new and D
m_new
, whose sizes are O(N) and O(M), respectively. Since Imax is a constant, the total signaling overhead of the function query is O(M(M + N). When the number of SSs (i.e., the value of N) is large, the difference between the signaling overhead of a centralized scheme and that of IBRC can be substantial.