3.1. Network Model
The basic features of our network model are as follows.
-
(i)
Each node is uniquely identifiable.
-
(ii)
Node and time synchronization are available. However, the methods for achieving synchronization are out of the scope of this paper.
-
(iii)
The targeted system operates in discrete (or, slotted) time. A maximum-sized packet can fit into a time slot.
-
(iv)
Communication is established via omnidirectional antennas over a single physical radio channel.
-
(v)
Each node in the network has a single half-duplex radio, and the nodes' radios are always on.
-
(vi)
Each node keeps a single-packet queue, not differentiating the packets from different connections.
-
(vii)
2-hop interference model is used as the interference model, which assumes that the interference between the nodes that are separated by more than 2-hops in the physical topology is negligible [23].
3.2. Overview of UBS Mechanism
In UBS, each node aims to adjust its own weight independently such that the network resources are utilized effectively, resulting in an increase in the overall throughput. UBS divides the time into equal intervals called frames. Each node is assigned a dynamic weight value which approximates the node's demand for transmission slots in the next frame. The number of time slots assigned to each node in a single frame is proportional to its weight. Each node periodically runs our Additive Increase Multiplicative Decrease- (AIMD-) based weight adjustment algorithm (Algorithm 1) and decides to increase/decrease its weight using the readily available information such as its slot utilization history and queue occupancy. UBS weighting scheme is composed of 3 basic mechanisms:
-
(1)
node state detection,
-
(2)
dynamic weight adjustment, and
-
(3)
weight sharing (weight dissemination).
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
Considering configurations complying with our network model, following information is available at every node X and might be used for weight-adjustment purposes:
-
(1)
detailed information about 1-hop and 2-hop neighbors of node X,
-
(2)
instantaneous packet queue length of node X,
-
(3)
maximum size of packet queue,
-
(4)
number of time slots allocated to node X in each time frame,
-
(5)
number of time slots wasted by node X in each time frame.
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.1. Node State Detection
Nodes periodically detect their current states. Node state detection is composed of two different parts: (1) detection of the packet queue state and (2) maintenance of the slot usage statistics.
At the end of each time frame, each node samples its instantaneous queue length. The instantaneous queue lengths are held in a sliding window which is then used to calculate the average queue length,
, over
frames.
is a network parameter which denotes the weight-adjustment period. The impact of
on the overall network performance is discussed in Section 4.1.
Each node in the network also keeps its slot usage statistics through a counter for the number of slots it has wasted, which is reset every
frames. A slot is considered to be wasted if a node is given the opportunity to transmit at a particular time slot although it has no packets to send. The obtained state information is then used within the weight adjustment.
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)
If there are no wasted slots and there are packets waiting in the queue. (In this case, the node's weight is increased.)
-
(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)
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
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 networks using the 2-hop interference model, there are two main types of conflicts that should be avoided in order to achieve a collision free schedule:
-
(1)
primary conflict: observed if a node is scheduled to transmit and receive at the same time, and
-
(2)
secondary conflict: observed if a node is scheduled to receive from two different nodes simultaneously.
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:
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.