Utilization-Based Dynamic Scheduling Algorithm for Wireless Mesh Networks

1.1. Motivation and Contributions

In statically weighted scheduling schemes, nodes are assigned static weights that remain constant throughout the network lifetime. However, these statically assigned weights do not always map very well to the dynamic traffic conditions passing through the nodes. Unless a dynamic readjustment scheme is used, the mismatch between the statically assigned weight of a node and its actual traffic load may never be eliminated.

Realization of excessive allocation and excessive demand phenomena motivate us to devise a utilization-based packet scheduling policy to alleviate these problems. The main contributions of this paper are (i) the proposal of a novel dynamic weighting scheme and (ii) the proposal of a channel access scheduling scheme called Utilization-Based Scheduling (UBS), which employs our proposed dynamic weighting scheme. UBS is a fully distributed STDMA-based scheduling scheme which aims to prevent slot wastes while providing enough transmission opportunities to all nodes. To achieve this, we make use of the following ideas: (i) maintaining the slot usage statistics, (ii) periodically monitoring each node's packet queue, and (iii) adjusting each node's slot allocation in an adaptive fashion.

1.2. Paper Organization

The remainder of this paper is organized as follows. Section 2 provides background on STDMA-based channel access schemes and briefly reviews the proposals available in the literature. Section 3 presents the proposed dynamic weighting scheme and UBS's scheduling decision mechanism in detail. Section 4 reports our ns-2 simulation results, and finally, Section 5 concludes the paper emphasizing the key insightful points.

3.1. Network Model

3.2. Overview of UBS Mechanism

Algorithm 1: UBS weight adjustment.

if   then

 if   then

   ;

 end if

else

  ;

end if

;

Each node detects its state periodically and adjusts its own weight. Then, these weights are shared among the nodes within the same 2-hop neighborhood and used for schedule formation. Schedule formation is performed via a pseudorandomized election mechanism, where each node has as many agent as its weight contending on its behalf.

3.3. Dynamic Weight Adjustment Scheme

In the following subsection, we discuss the three mechanisms of UBS weighting scheme and explain how UBS exploits the above-listed information for dynamic weight information.

3.3.2. Weight Adjustment

UBS uses an Additive Increase/Multiplicative Decrease- (AIMD-) based weight adjustment mechanism to keep nodes' weights well-matched with their actual demands. AIMD in TCP literature represents a congestion control mechanism with a linear growth of congestion window combined with an exponential (multiplicative) decrease in the case of congestion [24].

Different from AIMD in TCP, in UBS, what is adjusted is not the size of the congestion window, but the weight of the node. AIMD approach is shown to converge [25], and it is also shown to be the right approach especially when the source is operating close to the availability of the network [26].

Each node invokes UBS weight-adjustment algorithm (Algorithm 1) once in every frames and the algorithm is triggered to take action under two different conditions:

1. (1)

   If there are no wasted slots and there are packets waiting in the queue. (In this case, the node's weight is increased.)

    
2. (2)

   If there are wasted slots observed since the last adjustment of the weight. (In this case, the node's weight is decreased.)

   If there are no slots wasted by a node and if there are packets still waiting in the queue, it can be inferred that the node is in need of more slots because its queue could not be drained although it did not waste any of the time slots assigned to it. Hence, the weight of the node X, , is increased using the formula given in(1)

   

   (1)
    

According to (1), a node's weight is increased in accordance with its average queue occupancy percentage. We name the parameter as the increase coefficient, which is able to change the range of values used for incrementing the weight values.

When , the result from the multiplication of by the logarithm of the queue percentage is rounded to the closest integer, returning 0, 1, or 2. Since the maximum of 1 or the logarithm of the queue percentage in base-10 is chosen as the increase step size, the increase step size is either 1 or 2. We use as the increase step size in order to ensure that a node's weight is incremented whenever incrementing the weight value is determined to be required. In our simulations, we use as 2, allowing 1, 2, 3, or 4 to be used for incrementing the weight values. In Section 4.1, the impact of the increase coefficient parameter, , is further investigated. additive increase algorithm (Algorithm 2) implements (1).

Algorithm 2: Additive increase.

 

 if   then

   ;

 enf if

 if   then

   ;

 end if

  ;

On the other hand, if the node has wasted one or more slots since the last invocation of the UBS weight adjustment algorithm, then it implies that node has been assigned more slots than it actually needed. In this case, the node's weight is reduced via multiplicative decrease

(2)

By using (2), the weight is at most reduced to its half. If the weight rounds down to 0, it is restored to 1 to guarantee the participation of each node in the schedule formation elections because only nodes with nonzero weights are eligible to participate. Multiplicative decrease algorithm presented in Algorithm 3 implements (2). Multiplicative decrease algorithm is also useful in ensuring that nodes are not allowed increase their weights maliciously. When a node increases its weight maliciously, then the number of slots it has wasted will come into play as a factor stopping this artificial increase, making UBS robust to such attacks.

Algorithm 3: Multiplicative decrease.

;

if   then

  ;

end if

Alternatively, weight adjustment could be performed using an Additive Increase/Additive Decrease- (AIAD-) based algorithm. We have observed that AIMD performs better than AIAD. If a node wastes its assigned slots, it is very likely that this node will not need more slots in the following frames. When the number of its assigned slots is reduced aggressively as in AIMD, the nodes that need more slots will be able to get what they need quicker. In AIAD, the transition of slots is slower; hence, the performance is lower.

3.4. Scheduling-Formation Mechanism

In order to ensure that both kinds of conflicts are avoided, no two nodes within the same 2-hop neighborhood should be scheduled to transmit at the same time slot [27, 28].

UBS is a distributed weighted channel access scheme where each node determines the time slots it will use for transmission based on the information about its 1-hop and 2-hop neighbors (including the weight information) that can be collected by a link-layer or network-layer mechanism.

The scheduler algorithm (Algorithm 4) is independently run by each node at the end of each frame in order to select the time slots the node is eligible to transmit during the next frame.

Algorithm 4: Scheduler algorithm.

 for   to   do

  if   then

  end if

 end for

The first two lines of the scheduler algorithm is where UBS weight information is actually used. In the first two steps of the scheduler algorithm, the set of AgentIDs for the owner node's agents (localAgtLst) and the set of AgentIDs of its 2-hop neighbors' agents (nbrAgtLst) are generated. Each node, including the local node, has as many agents as its weight where all of its agents compete to win slots on its behalf. Therefore, for each slot, the winning probability of a node is roughly proportional with the number of its agents, hence its weight. All agents generated in these two steps are involved in all contentions held for the entire frame.

In the for loop, a separate contention (MeshElection) is held for each time slot in a frame. MeshElection takes two parameters: (1) the identifier of the time slot the contention is held for (e.g., contestTime) and (2) the set of contenders (e.g., nbrAgtLst). MeshElection function returns a set of pairs where each pair involves the AgentID and its corresponding hash value. The agent with the largest hash value is then elected as the winner of the contended time slot. If the winner AgentID belongs to localAgtLst, then the node marks the slot as one of the slots it is eligible to transmit.

To calculate the hash values, we use the smear function given in 802.16-2004 standard [4] that converts a uniform value to an uncorrelated uniform hash value through mixing. To elaborate more, it is a function with a number of arithmetic operations (e.g., ≪,≫, +, −). It uses these operations to mix the positions of the bits that represent the seed value given as the parameter to the function, and the outcome is a uniformly distributed hashing value. Hash-value generation is the pseudorandomized part of UBS as it takes the combination of the AgentID and the ContestTime as its unique, pseudorandom seed value.

The hash value is obtained as follows:

(3)

Smear function is very simple to implement in hardware, and the time it takes to return an answer is significantly less than those of traditional random number generator functions. Therefore, we prefer using this smear function over a random number generator.

3.5. Weight Sharing

To be able to form a channel access schedule, each node needs to know the weights of nodes in its vicinity. To keep the messaging overhead required for the weight dissemination at minimum, we propose a distributed pseudorandom scheduling mechanism and exploit the capabilities of the network layer routing protocol to learn about the neighboring nodes and the network topology. For the routing protocol, we use OLSR [29], which is a table-driven link state routing protocol collecting various information in its tables. To disseminate UBS weight information without incurring any communication overhead, we replace the unused reserved fields in OLSR's periodic HELLO messages. The mechanism of UBS is independent of OLSR's functionality. Any routing protocol performing periodic status broadcasts can be used with UBS. However, in the rest of the paper, we assume that OLSR is the network layer routing protocol.

The HELLO message structure given in RFC 3626 [29] has "Reserved" fields which are unused and filled with zeros. "Reserved" field within the local information section is 2 bytes while "Reserved" field in the link information section is 1 byte long.

We extend the HELLO message structure specified in RFC 3626 to include weight information for the originating node itself and its listed 1-hop neighbors. The proposed modified message structure is shown in Figure 1. In the new message structure, the second half of the "Reserved" field within the local information section is replaced with the "Weight" field and the "Reserved" field in the link information section is substituted with "Nb_Weight" field. In a single HELLO message, there is only one "Weight" field, but there might be multiple "Nb_Weight" fields depending on the number of the 1-hop neighbors advertised. Both "Weight" and "Nb_Weight" fields are of 1 byte long. "Weight" field holds the weight information of the originating node. The "Nb_Weight" field holds the weight information for the advertised neighbor node.

Using this new HELLO message structure, every node is able to collect the weight information of all the nodes in its 2-hop neighborhood without requiring the MAC layer to exchange any further messages. There is no communication overhead introduced by UBS weighting scheme as the unused parts of OLSR HELLO messages are utilized for the dissemination of the weight information.

In the implementation of UBS, only Algorithm 1 is allowed to change a node's weight at the MAC layer. OLSR is not allowed to trigger the recalculation of the weight when a HELLO message is about to be sent. When preparing a HELLO message, OLSR extracts the most recently calculated weight from the MAC layer to fill in HELLO message's weight field and the most recently learned neighbor weights to fill in Nb_Weight fields.

4.1. Effects of UBS Design Parameters

In this section, the effects of two UBS parameters, the weight-adjustment period ( ), and the increase coefficient ( ) on the overall performance are discussed.

Figure 2 presents the impact of UBS parameters and on the performance of UBS in terms of the number of dropped packets, while other simulation parameters are set to the values presented in Table 1. The results presented in Figure 2 represent the average of multiple simulation runs performed on 3 different 20-node networks under 3 different traffic scenarios with different values of and .

MAC Parameters	Value
Bandwidth	3 Mbps
Max packet length	1500 bytes
Frame size	100 slots
Number of nodes	20 nodes
Sliding window size	10

As shown in Figure 2, increasing or decreasing the value of (weight adjustment period) too much have a negative effect on the overall performance of the network. If is set to be too large, UBS cannot respond to the changes in nodes' demand for time slots in a timely manner, trying to enforce stale weight values. On the other hand, if is too small (UBS) reacts to the queue state changes too hastily, resulting in high fluctuations in node weights. This again achieves inferior performance.

The other parameter affecting the overall performance of the network is the increase coefficient ( ), which changes the range of increment values used in the additive increase method given by (1). The range of allowed step sizes should be large enough so that nodes' demands for time slots can be differentiated. However, if a too large range of step sizes is allowed, the weights of nodes increase very rapidly and the convergence of the weights is delayed, leading to a lower performance.

In Figure 2, the number of dropped packets is smaller along the line weight-adjustment period = 10. Likewise, when the increase coefficient = 2, the number of dropped packets tends to get smaller compared to the other values of the increase coefficient. Considering the results presented in Figure 2, we choose and in the set of experiments presented in Sections 4.3 and 4.4.

4.2. Effects of Network Topology: Case Study

Network topology is another factor that also has a considerable effect on the obtained performance results. In this section, through a case study, we provide a general discussion on the discussed protocols' behaviors in different network topologies and how the topology can affect the overall network performance.

Figures 3(a) and 3(b) provide examples of two randomly generated 15-node connected networks for which the obtained performance results tend to be quite different. We name the topology in Figure 3(a) as Topology-1 (T-1) and the topology depicted in Figure 3(b) as Topology-2 (T-2). In OLSR-enabled networks, multipoint relay (MPR) nodes are the only nodes that forward data for the other nodes. In other words, not all nodes flood the network with link state updates but only a set of selected special nodes, called MPR nodes, disseminate link state information and data. In Figures 3(a) and 3(b), we present two different topologies with their MPR nodes marked.

The performance difference between these two networks (see Figure 4) stems not only from the placement of nodes in the network and but also from the routes used by the individual packets. In Topology-1, node-2 is a bottleneck node. Due to its position in the topology, no other node (except node-10) can transmit while node-2 is transmitting because node-2 involves all other nodes except no node-10 in its 2-hop neighborhood and its 2-hop neighborhood is very large compared to the other nodes in the network. This situation also constitutes the reasons for node-2's being chosen as MPR by many nodes to forward their data. Therefore, node-2 is along the routes of many connections, usually carrying a heavy traffic. Since its traffic load is too much, UBS determines that node-2 requires more slots almost every time it performs a state check and prioritizes this node's transmissions over other nodes'. In the results for Topology-1, we observe that the performance of nonconcurrent TDMA and uniform-weighted TDMA are very close, as the possibility of concurrent transmissions is very low.

In Topology-2, no node is the only bottleneck node as node-2 in Topology-1. Therefore, the possibility of performing concurrent transmissions is much higher. However, the lengths of the paths between the two ends of the network are larger compared to Topology-1. Therefore, the performance of nonconcurrent TDMA is severely affected.

Considering the results on both topologies, we observe that the performance of uniform-weighted TDMA degrades significantly in Topology-1 while the performance of nonconcurrent TDMA degrades in Topology-2. However, in both topologies, the performance of UBS remains almost constant. Therefore, we conclude that UBS is highly adaptive to different topologies.

4.3. Uniform Traffic Simulation Results

The three protocols (UBS, uniform-weighted TDMA, and nonconcurrent TDMA) are simulated and compared under the same uniform traffic scenarios, where every node generates a connection to every other node in the network. In each of these simulation scenarios, there are O(N²) connections that start and end at the same time, where N is the number of nodes in the network. The packet generation rate (in bps) and the packet size (200 bytes) are kept the same for all connections in a single scenario, and a wide range of different CBR traffic rates is applied over different simulations.

Simulation results with uniform traffic patterns are presented in Figures 5 and 6. Figure 5(a) illustrates the relationship between the packet generation rate and the total number of packets received at the application layer. The results indicate that concurrent protocols perform significantly better than the nonconcurrent TDMA protocol and using dynamic weighted transmission scheduling provides additional improvements.

Figure 5(b) provides information about the ratio of the number of packets that are delivered successfully to the packet generation rate. While maintaining their relative performance rankings, the packet delivery ratios of all three protocols tend to decrease as the packet generation rate increases, due to the increasing congestion.

Figures 6(a) and 6(b) show how the average end-to-end delay changes as functions of the rate and the throughput, respectively. The end-to-end delay values are averaged only for the packets that are successfully delivered. In Figure 6(a), considering the performance gap between the nonconcurrent TDMA and the concurrent protocols, the impact of exploiting spatial reuse (i.e., allowing concurrent transmissions in the nonconflicting parts of the network) is clearly visible.

In Figure 6(a), it is also observed that UBS provides additional improvements not only in terms of the number of successfully delivered packets but also in terms of the average end-to-end delay. The delay of UBS remains below that of uniform-weighted TDMA although they tend to get closer as the packet generation rate increases. The reason for the two protocols' delay values getting closer is that UBS is able to deliver more packets while uniform-weighted TDMA has to drop them. The performances difference of the discussed protocols becomes more apparent, especially when the average end-to-end delay values are compared against the throughput, as depicted in Figure 6(b).

4.4. Nonuniform Traffic Simulation Results

In this section, we present our simulation results under a number of different nonuniform traffic scenarios in which some nodes either create or receive more traffic than the others. In this second set of simulations, again CBR traffic is used, and CBR rate is held fixed at 500 bps. The simulations last for 200 seconds and all connections start at sometime between 25th and 50th seconds and end at some time between 125th and 150th seconds. The connection pairs over a network in each single simulation are randomly chosen and the number of active flows in the network is changed between 20 and 380 with a step size of 30.

Figures 7 and 8 present the related results. The results obtained with nonuniform traffic patterns are quite similar to the uniform traffic simulation results and can be interpreted with similar reasoning. In Figure 7, the number of delivered packets and the packet delivery ratio are presented as the functions of CBR packet generation rate while Figure 8 presents how the average end-to-end delay values change with respect to the CBR packet generation rate and the number of successfully delivered packets. It is observed that both in Figures 7 and 8, the performance rankings of the protocols obtained in the simulations with uniform traffic patterns are preserved. As one apparent difference from the uniform traffic simulation results, in Figure 8(a), the difference between the average end-to-end delays of UBS and uniform-weighted TDMA is more clearly observable than in Figure 6(a).