Bandwidth Guarantee for Real-Time Flows

The aforementioned spectral reuse framework can allocate time slots to SSs proportionate to their requests. However, when SSs request new flows or need more bandwidths for their old flows, the system may no longer guarantee enough bandwidths for the original flows. To solve this problem, we propose an admission control mechanism to extend our spectral reuse framework. Specifically, we separate flows into real-time and non-real-time flows. When an SS requests a new flow or more bandwidth for its old flows, we will check whether the

Algorithm 2: Load-aware tree construction (LTC) algorithm Input: set G of all SSs in the network

Output: routing tree T

let A be the set of SSs without parents which have the largest hop counts to the BS;

G ← G − A;

bandwidth requirements of all real-time flows can be still satisfied. If so, we will admit this request. Otherwise, we will reject this request to guarantee bandwidths of existing real-time flows.

Fig. 2.5 illustrates the flowchart of our admission control mechanism. The idea is to pri-oritize real-time from non-real-time flows. For each SS, we always ensure sufficient slots to satisfy the bandwidth requirements of all its real-time flows, and then distribute the remaining slots to its real-time flows. This is what we mean by prioritizing real-time from non-real-time flows. This implies that an SS can always admit more non-non-real-time flows since its real-time flows always have higher priority. However, when an SS j requests a new real-time flow i (or wants to increases bandwidth of a real-time flow i), the following steps will be

SS j requests a new flow i

Is i a real-time flow?

check whether SS j has enough slots to support all its real-time flows

reallocate slots to SSs by spectral reuse framework with the bandwidth

requirements of all flows

reallocate slots to SSs by spectral reuse framework with the bandwidth

requirements of only real-time flows

reject flow i admit flow i no

yes

no

no

no

yes

yes

yes

Figure 2.5: Flowchart of the admission control mechanism.

executed:

1. Check whether SS j’s current slots can support required bandwidths of all its real-time flows (including flow i). If there are enough slots, we can admit flow i. Otherwise, it means that we have to reallocate slots in the system to support this new request (refer to step 2).

2. To reallocate slots of SSs in the network, we will execute our spectral reuse framework in Section 2.3. We will update the bandwidth requirement of SS j, run the routing module to reconstruct the routing tree, and then run the scheduling module to allocate slots to all SSs. Then we check whether this new allocation can support the real-time flows of all SSs. If so, we can admit flow i and adopt the new allocation. Otherwise, it

means that the new scheduling cannot satisfy some real-time flows, so we go to step 3.

3. Update the bandwidth requirements of all SSs by removing their non-real-time flows.

With these requirements, we execute our spectral reuse framework again. We run the routing module to reconstruct the routing tree, and then run the scheduling module to allocate slots to all SSs. Then we check whether this new allocation can support the real-time flows of all SSs. If so, we can admit flow i and adopt the new allocation.

Otherwise, the system does not have enough slots to support flow i, so we should reject the request of flow i.

Note that although the above step 3 allocates slots to SSs based on their requirements of real-time flows, an SS can still transmit non-real-time flows, as long as its real-time flows do not consume all bandwidths of the SS. Also, we comment that although the above discussions only cover two classes (real-time and non-real-time) of traffics, general multiple m classes of traffics are applicable. In this case, we should check whether the addition of a new flow i (say, in class k < m) can still guarantee the bandwidth requirements of all flows in classes 1, 2, · · · , k. If not, we can remove flows in classes k + 1, k + 2, · · · , m and reallocate slots to check whether the system has enough slots to support the request of flow i.

Next, we formulate our admission control mechanism in a mathematical way for imple-mentation. Here we introduce an uplink channel usage threshold δ^{U L} to determine whether the network for uplink traffics is congested. Let Fctrl and Fdata be the ratios of control and data subframes in a frame. According to the scheduling module, we can obtain that

δ^{U L}= F_data

Since C_max^UL is the sum of ratios ^d_rUL^ULj

j of the total transmission time allocated to each SS j in E_i of the “bottleneck” SS i, we can use C_max^UL as the degree of uplink channel usage in the network.

Specifically, when C_max^UL ≤ δ^{U L}, the network for uplink traffics is not congested and thus all uplink flows can receive enough bandwidth to satisfy their QoS requirements. Similarly, we can determine whether the network for downlink traffics is not congested by C_max^DL ≤ δ^DL, where the downlink channel usage threshold δ^DL is

δ^DL = F_data

F_ctrl+ F_data × C_max^DL C_max^UL + C_max^DL .

Based on the above argument, once C_max^UL > δ^{U L}, the network for uplink direction becomes congested and we have to exclude some flows to alleviate congestion. The idea is to first ex-clude some non-real-time flows since they do not have stringent deadlines. When the network is still congested even if all non-real-time flows are excluded, we have to exclude some new real-time flows. Here a new real-time flow is defined as a real-time flow that does not exist in the previous scheduling result or that changes its bandwidth demand. Given the bandwidth demands of all flows in each SS, the extension of our framework involves the following steps:

1. Run the spectral reuse framework in Section 2.3 to determine the bandwidth allocated to each SS. If C_max^UL ≤ δ^{U L}, it means that each SS can obtain enough bandwidth and thus the BS will broadcast the scheduling result to all SSs through the MSH-CSCH:Grant message. Otherwise, we will go to step 2.

2. If there are non-real-time flows in the network, then go to step 3. Otherwise, go to step 5.

3. For each SS i, we check whether its allocated bandwidth can satisfy bandwidth require-ments of all its real-time flows. If not, without changing the total bandwidth allocated to SS i, we reduce the bandwidth allocated to SS i’s non-real-time flows until the band-width requirements of SS i’s real-time flows can be satisfied. If the bandband-width

require-ments of every SS’s real-time flows can be satisfied by the above operation, the BS will broadcast the new scheduling result to all SSs. Otherwise, there must be at least one SS whose allocated bandwidth cannot satisfy its real-time flows even if all its non-real-time flows are excluded. In this case, we will go to step 4.

4. For each SS i, we change its demand of uplink transmission time from T_i^UL to T_i(RT)^{U L} , where T_i(RT)^{U L} is the demand of uplink transmission time of all real-time flows in SS i.

Then, we execute the scheduling module to recalculate the new result of bandwidth allocated to each SS. After this operation, if C_max^UL ≤ δ^{U L}, we will conduct the following actions:

• If there exists free slots, we will assign them to the non-real-time flows in the net-work. Specifically, we select the SS i with the minimum value of T_i(RT)^{U L} and assign these free slots to its non-real-time flows. We continuously repeat this operation until there is no free slot.

• Broadcast the new scheduling result to all SSs.

Otherwise, the network is still congested even if we exclude all non-real-time flows in the network. In this case, we will go to step 5.

5. We then exclude some new real-time flows to alleviate the network congestion. Let n_{RT new} be the total number of new real-time flows in the network. We sort these flows by the following method:

(a) Select the SS i with the maximum value of T_i(RT)^{U L} . Then, from SS i, we pick the new real-time flow fj with the largest bandwidth demand b(fj).

(b) Remove f_j from SS i and decrease T_i(RT)^{U L} by ^b(f_r^j)

i .

(c) Repeat the above two steps until all new real-time flows are picked.

We then exclude some new real-time flows from the network by the binary exclusion:

(a) Set up two variables β = ¹₂ and k = 2.

(b) Exclude the first bβ × n_{RT new}c new real-time flows and execute the spectral reuse framework to check whether C_max^UL ≤ δ^UL. If so, it means that we may reject too many new real-time flows. In this case, we update β = β − ₂¹k. Otherwise, it means that we have to reject more new real-time flows to alleviate the network congestion. In this case, we update β = β + ₂¹k.

(c) Update k = k + 1 and repeat step (b) until n_{RT new} ≤ 2^k.

After the network becomes non-congested by the binary rejection, the BS will broadcast the scheduling result to all SSs.

For the downlink direction, we follow the similar way to exclude some flows to alleviate the network congestion.