On the performances of IEEE 802.16(d) mesh CDS-mode networks
using Single-Switched-Beam Antennas
Chih-Che Lin, Shie-Yuan Wang
⇑, Teng-Wei Hsu
Department of Computer Science, National Chiao Tung University, 1001 University Road, Hsinchu, Taiwan
a r t i c l e
i n f o
Article history: Received 25 March 2011
Received in revised form 13 October 2011 Accepted 17 December 2011
Available online 29 December 2011 Keywords:
Directional antenna Switched-beam antenna Mesh network
Coordinated distributed scheduling mode IEEE 802.16
a b s t r a c t
The IEEE 802.16(d) mesh coordinated distributed scheduling (CDS) mode is a novel tech-nology for future fixed wireless backbone networks and designed for the use of omnidirec-tional antennas. The use of Single-Switched-Beam Antennas (SSBAs) may have great potential to increase network capacity due to the antenna directivity. However, a network designed for omnidirectional antennas usually cannot operate well or achieve good perfor-mance with the presence of antenna directivity.
In this paper, we review the designs of the IEEE 802.16 mesh CDS-mode network, study the issues of this network with the use of Single-Switched-Beam Antennas (SSBAs), and propose a complete solution to solve these issues. The performances of our proposed scheme is evaluated using simulations. The simulation results show that our proposed scheme can effectively solve the issues of using SSBAs in the IEEE 802.16 mesh CDS-mode network and greatly increase its network capacity.
2011 Elsevier B.V. All rights reserved.
1. Introduction
The IEEE 802.16(d) mesh coordinated distributed scheduling (CDS) mode [1] is a wireless technology for next-generation fixed broadband relay networks. The 802.16(d) mesh CDS mode uses a TDMA-based Medium Access Control (MAC) layer and OFDM-based physical layer and mainly operates at a single frequency. The transmis-sions of control messages and data are separated. The con-trol message transmissions are determined using a distributed pseudo-random algorithm, called the Mesh Election Algorithm (MEA), which employs a unique expo-nential holdoff design. MEA allows a node to know the pos-sible next control message transmission intervals of the nodes in its two-hop neighborhood. Thus, by using MEA each node can schedule collision-free control message transmissions in its one-hop neighborhood. The data trans-mission of this network is scheduled in an on-demand manner. A pair of transmitting and receiving nodes should
negotiate a data transmission schedule using a three-way handshake procedure (THP). The handshake information of THP should be transmitted using control messages. Because the transmission timing of a control message is controlled by MEA, how MEA influences the network per-formance of the IEEE 802.16(d) mesh CDS mode is worth studying.
The performance of MEA has been extensively studied for years (e.g., [2–7]); however, most of the prior works were based on the use of omnidirectional radios. In the literature, rare work studied the performances and chal-lenges of the 802.16(d) mesh CDS-mode network when it uses directional antennas. Since the MEA specified in the standard is assumed to operate over omnidirectional antennas, several operational problems will need to be solved, when it operates over directional antennas.
Recent directional antenna technologies can be catego-rized into three classes: (1) the switched-beam antenna (SBA); (2) the adaptive array antenna; and (3) the Multiple Input Multiple Output (MIMO) array antennas. SBA can point to several determined directions with pre-defined antenna gain patterns, which can work well
1389-1286/$ - see front matter 2011 Elsevier B.V. All rights reserved. doi:10.1016/j.comnet.2011.12.012
⇑ Corresponding author.
E-mail address:shieyuan@csie.nctu.edu.tw(S.-Y. Wang).
Contents lists available atSciVerse ScienceDirect
Computer Networks
without the presence of the multi-path effect (such as in the free-space environment). Due to lacking the nulling capability, they may not achieve the optimal concurrent transmission schedules in multi-path-prone environments. The adaptive array antenna can form arbitrary beams and point to arbitrary directions. By forming ‘‘nulls’’ to-wards directions of unwanted transmitters and receivers, the adaptive array antenna can effectively reduce the sig-nal interference. The MIMO antenna employs multiple an-tenna elements on both the transmitter and receiver ends, which thus can further increase the capacity of a network. Adaptive array antennas and MIMO antennas can outper-form SBAs in achieved network capacity and signal quality; however, SBAs are superior in cost and design complexity
[8]. For this reason, in this paper we adopt Single-Switched-Beam Antennas (SSBAs) to construct a cost-effec-tive directional-antenna network using the IEEE 802.16 mesh CDS mode.
In the remainder of this paper, we reviewed the design of this new network, identified the problems of using SSBAs in this network, and proposed a scheme to solve these problems. The proposed scheme can operate using only directional transmissions/receptions. (Most of the previous proposals for directional antenna networks have to use omnidirectional transmissions/receptions in some phases of network operation, which increases the design complexity of the power control.) We conducted proof-of-concept simulations to evaluate the network capacity increased by using SSBAs in this network. In addition, we also evaluated the performances of TCP (Transport-layer Control Protocol) using a real-life TCP implementation in such networks. TCP is a well-known transport-layer proto-col widely used in current network applications (such as FTP, HTTP) and sensitive to network congestion and end-to-end packet delay jitters. Due to the unique protocol de-sign of the 802.16 mesh CDS mode, the performance of TCP over this network with SSBAs is interesting and worth studying.
To the best of the authors’ knowledge, this paper is the first work that discusses how to enable the IEEE 802.16(d) mesh CDS-mode network to operate with SSBAs and evalu-ates the performances of this network with SSBAs. Although there have been many prior works studying TDMA net-works with directional radios[9–19], they differ from an IEEE 802.16(d) mesh CDS-mode network using SSBAs in either control message scheduling or data scheduling. Thus, the issues and performances of the IEEE 802.16(d) mesh CDS-mode network employing SSBAs is worth studying.
The remainder of this paper is organized as follows. In Section 2, we survey prior works related to this paper and explain the differences between these works and ours. In Section3, we briefly review the operation of the IEEE 802.16(d) mesh CDS-mode network. In Section4, we ex-plain the problems of the IEEE 802.16(d) mesh CDS mode when it operates with SSBAs and present the design of our proposed scheme. In Section5, we evaluate the perfor-mances of the proposed scheme using the NCTUns network simulator[20]. Finally, in Section7we conclude the paper. In addition, the issues of network initialization with SSBAs for this new network are discussed and solved in appendix.
2. Related work
In addition to the mesh CDS mode, the IEEE 802.16(d) specification also defines the Point-to-MultiPoint (PMP) mode and the mesh Centralized Scheduling (CS) mode. The issues and performance on using directional antennas in the latter two modes have been well studied. These two modes employ centralized mechanisms to schedule control messages and data. Due to this fundamental difference, the previous studies on these two modes differ from this work. Regarding the unique holdoff time design of the 802.16(d) mesh CDS mode, several dynamic holdoff time schemes have been proposed to enhance the network per-formance[2–4,21–25]. The main ideas of these proposals are to dynamically adjust each node’s holdoff time value according to several criteria (e.g., its output buffer occu-pancy, its intention to send data, etc.) to increase network performances without generating network congestion. These proposals assume that the network uses omnidirec-tional antennas and thus each node in the network only needs to run one instance of MEA to schedule control mes-sages. However, our work considers the network uses SSBAs to additional network capacity. In this network, due to limited coverage of SSBAs, single MEA cannot sche-dule a control message broadcast to all neighboring nodes at the same time. With this constraint, we propose a scheme where each node runs multiple MEA instances with a dynamic holdoff time design. For these differences, our proposed dynamic holdoff time scheme greatly differs from those proposed in the previous works.
The deployment cost of an IEEE 802.16-based network using directional antennas was discussed in[26]. In[27], Xiong et al. relaxes the data scheduling rules to increase the concurrency of data transmissions with nodes using omnidirectional antennas. We integrated this notion into our developed data scheduler for 802.16(d) mesh CDS-mode omnidirectional antenna networks. However, for 802.16(d) mesh CDS-mode networks using SSBAs, we developed a transmission-domain-aware minislot sched-uler that can utilize the advantage of SSBAs to increase the concurrency of data transmissions.
In the literature, collision-free distributed algorithms for time-division networks have been proposed. Most of them, however,[12–16]require nodes to use omnidirec-tional transmissions or receptions in some phases. In con-trast, our work need not use omnidirectional transmissions and receptions to operate. Note that, the antenna gain of an SSBA in the directional mode and that in the omnidirec-tional mode may greatly vary. Without proper transmis-sion power control, the connectivity among nodes in the directional mode and that in the omnidirectional mode can be inconsistent and hinder network operation. Since the objective of our work is to propose a cost low-complexity solution for the IEEE 802.16 mesh CDS-mode network, in our proposal the omnidirectional broadcast of SSBA need not be used, which avoids the use of compli-cated power control and thus reduces the complexity of MAC-layer design and the efforts of network deployment. MAC protocols using pure directional transmissions/
proposals, control messages can be transmitted at arbitrary time; however, the IEEE 802.16(d) mesh CDS-mode net-work uses a unique holdoff time design to control its con-trol message transmission timing in a special manner. This fundamental distinction differentiates these works and ours. In addition to the difference of the operations of the studied networks, in this paper we also studied the perfor-mances of a real-life TCP implementation (BIC-TCP) over the IEEE 802.16(d) mesh CDS-mode network with SSBAs. To the best of the authors’ knowledge, this is the first work that studies the performance of a real-life TCP implemen-tation over this new network with SSBAs.
3. Introduction to the IEEE 802.16(d) mesh CDS mode To make this paper self-contained, we briefly present the operation of an IEEE 802.16(d) mesh CDS-mode network here. In this network, link bandwidth is divided into frames on the time axis and managed in a time-division-multiple-access (TDMA) manner. Each frame comprises one control and one data subframes. A control subframe is further divided into transmission opportuni-ties (TxOpps), whereas a data subframe is further divided into minislots. Control messages and data packets are transmitted over TxOpps and minislots, respectively.
The 802.16 mesh CDS mode defines three types of con-trol messages: (1) Mesh Network Entry (MSH-NENT); (2) Mesh Network Configuration (MSH-NCFG); and (3) Mesh Distributed Coordinated Scheduling (MSH-DSCH). The MSH-NENT and MSH-NCFG messages are used for nodes to exchange control information for network initialization whereas the MSH-DSCH message is used for nodes to sche-dule minislot allocations. A minislot allocation is a set of consecutive minislots across several consecutive data sub-frames for data packet transfers. The standard categorizes TxOpps into three types, each for transmitting a specific type of control messages. The TxOpps used for transmitting MSH-NENT, MSH-NCFG, and MSH-DSCH messages are called NENT TxOpps, NCFG TxOpps, and MSH-DSCH TxOpps, respectively[1].
3.1. Control message scheduling mechanism used in the 802.16(d) mesh CDS mode
In the mesh CDS mode, each node’s control message transmission is scheduled by MEA[1], which is hash-based algorithm with an exponential holdoff mechanism. In this mode, each node needs to maintain (i.e., learn) the infor-mation about its two-hop neighborhood (which is an input of MEA). The two-hop neighborhood of a node i is defined as follows:
nbrðiÞ ¼ fig [ nbr1ðiÞ [ nbr2ðiÞ; ð1Þ
where nbr1(i) and nbr2(i) are defined as follows,
respectively
nbr1ðiÞ ¼ fk jnode k 2 node i’s one-hop neighboring
nodes; when omnidirectional antennas are usedg ð2Þ
nbr2ðiÞ ¼ fk jnode k 2 node i’s two-hop neighboring nodes;
when omnidirectional antennas are usedg ð3Þ
The purpose of maintaining the two-hop neighborhood is to avoid the hidden terminal problem when transmitting control messages. By using the same MEA in every node, this algorithm guarantees that in the network only one node in any two-hop neighborhood will win the chance to use a specific TxOpp. Thus, when nodes transmit their control messages, no message collisions will occur. Since the transmission of control messages can be guaranteed collision-free and these messages are used for scheduling a collision-free minislot allocation, the transmission of data packets can also be guaranteed collision-free. To maintain the two-hop neighborhood information, every node in the network must periodically broadcast its MSH-NCFG and MSH-DSCH messages in a collision-free manner. Because the scheduling processes of these two messages are the same, in the following we only explain the latter for brevity.
Each node should perform the MEA to determine the TxOpp on which to broadcast its next MSH-DSCH message. The MEA takes a given TxOpp number and an eligible node list (a list of nodes eligible to contend for the given TxOpp) as input. It then iteratively computes a hash value for each node in the given eligible node list on the given TxOpp. Finally, it outputs the ID of the winning node whose computed value is the largest among all the nodes in the eligible node list. The detailed hash operations used in MEA are defined in[1]. Since nodes within two hops use the same MEA and consistent eligible node lists, every node knows whether it will win a given TxOpp in its two-hop neighborhood.
To achieve the consistency of neighboring nodes’ eligible node lists for each TxOpp, each node should peri-odically broadcast the next MSH-DSCH TxOpps used by it-self and its one-hop neighboring nodes. If a neighboring node j’s next MSH-DSCH TxOpp is unknown, node i will conservatively consider that node j potentially contends for every TxOpp and put node j into the eligible node list for all following TxOpps until receiving the information of node j’s next MSH-DSCH TxOpp. Using this design, no collision will occur on any TxOpp. If a node cannot win a given TxOpp, it repeats the above process with the next TxOpp as input until eventually winning one TxOpp.
The eligibility of a node for contending for a TxOpp is determined by the holdoff time mechanism[1]. The hold-off time mechanism first defines the control message transmission cycle of a node as the time interval between the node’s two consecutive control message transmissions. As shown inFig. 1, the transmission cycle of a node com-prises (1) the holdoff time and (2) the contention time. The former is defined as the number of consecutive TxOpps during which a node must suspend its contention for TxOpps after wining a TxOpp. The latter is defined as the number of consecutive TxOpps for which a node may con-tend to win a TxOpp. Conceptually, by obtaining the hold-off times of the nodes in its two-hop neighborhood, a node can know for which TxOpps these neighboring nodes will and will not contend. Based on such information, it can construct an eligible node list of its two-hop neighborhood
for each TxOpp. In the standard [1], the holdoff time of each node is fixed and defined as follows:
Holdoff Time ¼ 2exponentþbase; ð4Þ
where the base value is fixed to 4 and the range of the exponent value is between 0 and 7. In contrast, the conten-tion time may vary depending on which and how many nodes are eligible to contend for TxOpps.
Similar to the next MSH-DSCH TxOpp, each node should put the holdoff times of its own and its one-hop neighbor-ing nodes in MSH-DSCH messages. By this design, every node knows such information about every other node in its two-hop neighborhood, for any given TxOpp; thus, the output of every node’s MEA in any two-hop neighborhood is consistent. The consistency of the MEA output means that, each node only knows if it wins a TxOpp or not. If it wins the TxOpp, no other nodes in its two-hop neighbor-hood will win the same TxOpp. If it did not win the TxOpp, it would think that some node a wins it while other node may think that node b wins it. (This is because, in reality, each node’s two-hop neighborhoods may not be the same but partially overlap.) However, except the winning node, all the other nodes in the same two-hop neighborhood will not win the same TxOpp.
Another advantage of the holdoff time design is that it prevents nodes from contending for TxOpps after they win one until the holdoff time has elapsed. This design en-sures that nodes other than the winning node will have a chance to win subsequent TxOpps and all nodes can fairly share TxOpps in the long run.
3.2. Data scheduling mechanism used in the 802.16(d) mesh CDS mode
The 802.16(d) mesh CDS mode schedules data trans-missions of nodes in a distributed and on-demand manner. A three-way handshake procedure (THP) is used for a pair of nodes to negotiate a minislot allocation agreed by both nodes. A minislot allocation is a set of consecutive minis-lots on which the transmitting node can transmit data packets and the receiving node can receive data packets. As shown inFig. 2, the THP uses a ‘‘request-grant-confirm’’ control sequence for two peer nodes to negotiate a mini-slot allocation. In a THP, the requesting node first transmits a request IE (Information Element) and an availability IE to the granting node using an MSH-DSCH message. The re-quest IE specifies the number of minislots that the rere-quest- request-ing node needs to transmit data packets and the
availability IE specifies a set of consecutive minislots on which the requesting node are available for data transmission.
On receiving these two IEs, the granting node first determines whether it can receive data packets from the requesting node within the minislot set specified by the re-ceived availability IE. If not, the granting node can simply ignore the received request IE. Otherwise, it allocates a minislot allocation within the specified minislot set and then transmits a grant IE to the requesting node as an acknowledgment using its MSH-DSCH message. The grant IE specifies a subset of the minislots specified by the re-ceived availability IE on which the granting node is willing to receive data packets from the requesting node. Upon receiving the grant IE, the requesting node then broadcasts a confirm IE using its MSH-DSCH message to complete this THP. The confirm IE is simply a copy of the received grant IE and used to notify the requesting node’s one-hop neigh-boring nodes of the duration on which this minislot alloca-tion will take place.
4. Using SSBAs in the 802.16(d) mesh CDS mode The definition of the two-hop neighborhood in [1]is based on the use of omnidirectional antennas and thus has an important property: if node A is in node B’s two-hop neighborhood, then node B is also in node A’s two-two-hop neighborhood. It is this property ensuring that the MEA used in each node generates collision-free TxOpp schedul-ing because nodes A and B cannot both win the same TxOpp in their respective two-hop neighborhoods. How-ever, when radio coverage is purely directional, the above
Fig. 1. Transmission cycle of a node.
property no longer holds. This makes receiving control messages from other nodes non-trivial and network oper-ation encounters several issues that need to be solved. These issues and our proposed solutions are explained below.
4.1. Problem 1: imprecise representation for TxOpps in control messages
In the standard, to reduce bandwidth consumption, the next TxOpp number of a node carried in MSH-DSCH and MSH-NCFG messages is represented by a 5-bit Mx field and a 3-bit Exp field [1], rather than a single long field. Using this representation scheme, a TxOpp number is rep-resented using the following formula:
2exp
Mx < TxOpp number 6 2exp ðMx þ 1Þ; ð5Þ
where 0 6 Mx 6 30, 0 6 exp 6 7. The interval between (2exp
⁄Mx, 2exp
⁄(Mx + 1)] is called the next transmission interval of a control message in the standard.
It is known that using MEA no two nodes in the same two-hop neighborhood will use the same TxOpp to trans-mit messages. However, the transmission intervals of two nodes in the same two-hop neighborhood may overlay with each other. For example, consider two nodes A and B are in node C’s two-hop neighborhood. Suppose that the current TxOpp is 0 and nodes A and B choose TxOpps 33 and 36 as their next MSH-DSCH TxOpps, respectively. In this condition, both nodes A and B may use (25⁄1, 25⁄2] (base = 4, exp = 1, Mx = 1) as their next
trans-mission intervals and notify node C of these settings. This overlapping problem does not hinder the operation of this network, when omnidirectional radios are used, because each node can listen incoming messages omnidi-rectionally, when it need not transmit control messages. In this condition, a node will not miss any control mes-sages broadcast from neighboring nodes as long as it is not in the transmitting state. However, using pure tional reception, a node cannot determine to which direc-tion its antenna should point because this imprecise representation cannot provide sufficient information for a node to know which node will transmit a message on a specific TxOpp among nodes with overlapped next trans-mission intervals.
Another problem is that this imprecise representation scheme reduces the flexibility of control message schedul-ing. Consider two neighboring nodes A and B. Using this TxOpp representation, on receiving an MSH-DSCH message from node B, node A cannot know the exact next TxOpp number won by node B. Instead, it can only derive an inter-val of 2exp TxOpps in length during which node B will
broadcast its next MSH-DSCH message. Since node A cannot know the exact next TxOpp that node B wins, to successfully receive the message transmitted from node B, it has to point its antenna towards node B during the whole interval. In contrast, if the exact TxOpp that node B will use can be known, node A can exchange control mes-sages with other neighboring nodes in this long interval, reducing the latency of control message exchange.
From this observation, to enhance the performance of the 802.16(d) mesh CDS-mode network using SSBAs, a control message scheduling scheme has to control nodes’ antenna directions in a per-TxOpp manner. To this end, our proposed scheme introduces a new offset field into the MSH-NCFG and MSH-DSCH message formats. With the help of the offset field, a node can use the following expression to precisely derive the TxOpp numbers won by each of its neighboring nodes and thus know to which direction it should point the antenna on each TxOpp
TxOpp number ¼ 2exp
Mx þ offset: ð6Þ
4.2. Problem 2: control message scheduling using SSBAs
The original MEA defined in [1] schedules when to
broadcast control messages for nodes using omnidirec-tional radios, which cannot be directly applied to networks using SSBAs. The reason is that a node using the original MEA cannot know to which direction it should point its an-tenna for data transmission and reception on a given TxOpp. To solve this problem, we propose a distributed control message scheduling scheme called the Multiple Transmission Domain (MTD) Scheme to coordinate nodes’ antenna pointings on each TxOpp. The MTD scheme uses a Transmission-domain-aware Mesh Election Algorithm (TMEA) and a Transmission-domain-aware Minislot Sched-uling Algorithm (TMSA). The former is designed for a node to properly control when and in which direction it should transmit a control message using a SSBA, while the latter is designed for a node to exploit the spatial-reuse advantage of SSBAs to increase data transmission concurrency. The notion of a transmission domain (TD) is explained below. 4.2.1. Transmission domain and its two-hop neighborhood
In this section, we define a transmission domain (TD) and its two-hop neighborhood for the use of SSBAs. A TD of a node is defined as the set of nodes that are located in the coverage of a single switched beam and can simulta-neously receive a message directionally transmitted by the node in that coverage. According to this definition, a node using an omnidirectional antenna has a single TD that in-cludes all of its one-hop neighboring nodes in its 360-de-gree radio coverage. In contrast, a node using a SSBA has several TDs, each of which includes only the nodes in a specific beam coverage.
A node using a SSBA has2p
B disjoint TDs to form a
360-degree radio coverage, where B denotes the antenna beam-width in radians. Each TD is assigned a unique identifier i called the ‘‘Transmission Domain Index (TDI).’’ A TD i is composed of the nodes in the sector area between B i 1 2 mod 2
p
and B i þ1 2mod 2
p
in polar coordi-nates,8i 2 N; 0 6 i 62pB. In this paper, B is set top2radians
and it can be changed to another value to better suit a given network topology. Therefore, each node has four disjoint
TDs each comprising nodes in the areas of p
2 i 1 2
mod 2
p
in polar coordinates, where i 2 N, 0 6 i 6 3. A node i using an SSBA maintains a two-hop neighbor-hood for each of its TDs. nbr(ij) denotes the set of nodes innode i’s two-hop neighborhood associated with TD j and its definition is given as follows:
nbrðijÞ ¼ fig [ fkjk is in the radio coverage of TD jg
[ fnbr1ðkÞjk is in the radio coverage of TD jg;
ð7Þ
where nbr1(k) is defined by Eq.(2). The reason why we use
nbr1(k) in the last term is that, a node k in TD j may point its
SSBA to any of its one-hop neighboring nodes to transmit/ receive messages when node i intends to transmit a mes-sage to it. Thus, from the perspective of TxOpp scheduling, the message schedulings of nodes in nbr1(k) may conflict
with those of node i to node k. For this reason, nbr1() should
be used to take such conflicts into consideration.
The details of the MTD scheme are explained below in Section 4.2.2. For clarity, in the remainder of this paper, the 802.16(d) mesh CDS mode that operates over an omnidirectional-antenna network is referred to as the sin-gle-transmission-domain (STD) scheme.
4.2.2. Transmission-domain-aware Mesh Election Algorithm (TMEA)
One intuitive idea for the 802.16(d) mesh-CDS network with SSBAs is to run multiple MEAs in each TD of a node. However, this intuitive approach cannot work and achieve good performance without a proper revision. In the follow-ing, we first present a basic version of TMEA that uses a Static holdoff time design (called TMEA-S) and discuss its drawbacks. We then present an advanced version of TMEA that uses a dynamic holdoff time design (TMEA-D) to boost the performance of this network.
Consider an 802.16(d) mesh CDS-mode network using SSBAs, where each node has four TDs. Following the design in[1], each node should execute four MEA Instances (de-noted as MEAIs), each maintaining a two-hop neighbor-hood and scheduling next message transmission for a specific TD. For brevity, the MEAI for a TD k is denoted as TD-k MEAI. The standard[1]does not define how multiple MEAIs of the same node operate and coordinate with each other; thus, these MEAIs calculate their next TxOpps inde-pendently. Without coordination, the MEAIs on a node may choose the same TxOpp because they do not know whether the TxOpp that they choose has already been cho-sen by other MEAIs. In this case, some of neighboring nodes will inevitably miss important control messages broadcast from this node.Such a scheduling conflict is called an ‘‘intra-node scheduling conflict’’ in this paper as it takes place among the TDs on the same node.
A basic solution that we proposed to address the intra-node scheduling conflict is TMEA-S, which only uses the static holdoff time design defined by the standard. The ba-sic idea of TMEA-S is to let all MEAIs on the same node share their next TxOpp information with each other. Fol-lowing this design, if an MEAI finds a scheduling conflict, then it will yield the chosen TxOpp and start next iteration to find new TxOpp that it can win.
Fig. 3 illustrates an example operation of TMEA-S. In this example, a TD-1 MEAI is scheduling its next control message transmission. At the first two iterations, the TD-1 MEAI chooses TxOpps that have been chosen by the TD-3 MEAI and TD-2 MEAI, respectively. Thus, it yields these TxOpps and start next iteration and finds a TxOpp that will not result in intra-node scheduling conflicts.
Note that in TMEA-S, a TD-j MEAI should use an eligible node list derived from the holdoff times of nodes in [nbr(im), "TD m 2 node i, rather than an eligible node list
derived from the holdoff times of nodes in nbr(ij) only.
Con-sider the example network shown inFig. 4, where nodes A and B are located in the other’s TD 2 and TD 0, respectively. Assume that the TD-0, TD-1, and TD-3 MEAIs of node A have chosen TxOpps 5, 2, and 3, respectively, and the TD-2 MEAI of node B has chosen TxOpp 8.
Later on, when the TD-2 MEAI of node A schedules its next TxOpp, if the TD-2 MEAI of node B is not included in its two-hop neighborhood (which is included only in nbr(A0)), it may also choose TxOpp 8 as its next TxOpp,
resulting in a scheduling conflict on TxOpp 8. When node B sends a control message to node A on TxOpp 8, node A will not be able to receive the message because node A will point its antenna to its TD 2 on TxOpp 8. Because such a scheduling conflict is caused by the MEAIs on different nodes, it is called an ‘‘inter-node scheduling conflict’’ in this paper. To avoid them, each node using TMEA-S has to notify its one-hop neighboring nodes of the next TxOpp numbers of all its own MEAIs and those of all its one-hop neighboring nodes’ MEAIs (learned from received MSH-DSCH messages transmitted by its one-hop neighboring nodes) using MSH-DSCH messages.
With the complete next TxOpp information of all neigh-boring MEAIs, TMEA-S can build an eligible node list con-sidering the next TxOpps of all nodes’ MEAIs in [nbr(im),
"TD m 2 node i to avoid inter-node scheduling conflicts. For instance, for the example shown inFig. 4, using this design the TD-2 MEAI of node A will include node B in its eligible node list for TxOpp 8 according to the next TxOpp
information of node B’s last MSH-DSCH message. Because there can be only one winner in any two-hop neighbor-hood, the TD-2 MEAI of node A will not choose the same TxOpp 8 as the TD-2 MEAI of node B did, resolving a poten-tial inter-node scheduling conflict.
Recall that, when the next TxOpp of a neighboring node in node i’s two-hop neighborhood is unknown, node i should include this node into its own eligible node lists for subsequent TxOpps, until receiving the next TxOpp information of this neighboring node. We expand this node-based conservative eligibility determination rule into a TD-based form: ‘‘When the next TxOpp of a neighboring node’s MEAI in node i’s two-hop neighborhood is unknown, each MEAI of node i should include this MEAI into its own eli-gible node lists for subsequent TxOpps, until receiving the next TxOpp information of this MEAI.’’ Using this conservative rule avoids another type of the inter-node scheduling con-flicts resulting from unknown and obsolete next TxOpp information of neighboring nodes.
For example, for node i, when the next MSH-DSCH mes-sage of node j that are two-hop away from it cannot be re-ceived before node i schedules its own next MSH-DSCH TxOpp, using this rule each MEAI of node i will include node j into its own eligible node list and conservatively consider that an MEAI of node j will contend for each sub-sequent TxOpp. Thus, when an MEAI of node i wins a TxOpp, it will ensure that all node j’s MEAIs will not win the same TxOpp, preventing inter-node scheduling con-flicts among two-hop nodes from occurring.
4.3. TMEA-D
To solve the inter-node scheduling conflicts, each TMEA-S of the same node’s TD has to use an eligible node list derived from all nbr(im), "m on the same node, and the
TD-based conservative eligibility determination rule. How-ever, these two designs of TMEA-S may make the MEAIs of the same node derive nearly the same eligible node list. In this condition, the diversity of the inputs of MEA, which chooses a winning node of a given TxOpp using a pseu-do-random hash function, is very limited. Thus, the win-ning TxOpp of each MEAI on the same node is likely to be the same at the first k iterations (which continuously
re-sults in intra-node scheduling conflicts), where k is the number of TDs on a node.
This is because in this condition each MEAI’s eligible node list for the same TxOpp may have many common nodes (worse yet, their eligible node lists may be the same for many TxOpps due to the conservative TD-based eligi-bility determination rule), MEAIs on the same node,there-fore, may find that MEA always chooses the same node, generating many intra-node scheduling conflicts. We call this problem the ‘‘continuous intra-node scheduling con-flict’’ problem, which results in three drawbacks. First, it significantly increases the interval of each MEAI’s trans-mission cycle and therefore increase the required time to negotiate data transmission; second, for the first reason, the utilization of the link bandwidth will be decreased; third, the MAC control unit will waste the time and com-puting power for the first k iterative executions of MEA, which is very inefficient to the implementation of MAC-layer control chips.
To address this problem, we propose TMEA-D to in-crease the diversity of the inputs fed into MEA. TMEA-D has three advantages. First, it provides more scheduling flexibility for MEAIs to avoid continuous intra-node scheduling conflicts by allowing each MEAI on the same node uses distinct holdoff time values. Second, TMEA-D can generate fair TxOpp scheduling for MEAIs on the same node. Finally, TMEA-D can assign active MEAIs (those that have data to send) smaller holdoff time expo-nent values and idle MEAIs larger holdoff time expoexpo-nent values. Thus, using TMEA-D the time required for a trans-mitting node to handshake a minislot allocation can be reduced, which allows nodes to more efficiently utilize link bandwidth.
The operation of TMEA-D is shown in Algorithm 1. In the initialization phase, an MEAI first sets its small-est_tmp_txopp and reference_start_txopp to the current TxOpp and constructs its Lij. It then empties the set Scalc,
which is used to store the TxOpp numbers that are chosen by this MEAI when executing Algorithm 1 but have been used by other MEAIs. If the node has data to send in the TD, the MEAI of this TD randomly chooses a holdoff time exponent value exp from Sactive. Sactiveis composed of
smal-ler exp values from 0 to the number of TDs where this node
has data to send. We call such a TD an active TD and denote the number of active TDs as Num_of_ActTDs in Algorithm 1. The chosen exp value is stored in the tmp_exp variable and used to derive the contention_start_txopp, which is the reference_start_txopp plus 2tmp_exp. Then, an MEAI
calculates the next TxOpp that it can win (stored in
tmp_txopp) using MEA with the chosen
conten-tion_start_txopp value and Lij. If the chosen next TxOpp
is not used by other MEAIs on the same node, it first calcu-lates proper exp and offset values for this chosen TxOpp number and then return the 3-tuple (tmp_txopp, proper_-exp, proper_offset) as its output. Otherwise, it adds the chosen next TxOpp number into Scalc, removes the used
tmp_exp value from Sactive, and repeats the above process
until it wins a TxOpp that has not been used by other MEAIs on the same node. (Note that, for brevity, the calcu-lation for the proper_exp proper_offset values shown in
this paper does not consider the sequence number wrap-ping problem of tmp_txopp, which has been properly solved in our implementation.)
In case that Sactive becomes empty, it means that this
MEAI cannot find a tmp_txopp value that has not been won by other MEAIs on the same node using the conten-tion_start_txopp values derived from the current small-est_tmp_txopp value and the tmp_exp values in Sactive. To
address this problem, the MEAI advances its small-est_tmp_txopp to the minimum TxOpp stored in the Scalc
(which is the smallest TxOpp that it wins in the iterations of the while loop) and then re-performs the above process. By doing so, this MEAI can have a chance to win a TxOpp that has not been won by other MEAIs belonging to the same node. Such an iterative process repeats until the MEAI finally wins an unused TxOpp that has not been cho-sen by other MEAIs on the same node.
Algorithm 1. TMEA-D
1: Num_of_ActTDs :¼ the number of TDs on the same node where there is data to send
2: Lij:¼ {(k, Lij(k))j"TxOpp k, Lij(k) is the eligible node list of node i’s TD j,
3: constructed based on the eligibility of all nodes in [nbr(im), "TD m 2 node i}
4: smallest_tmp_txopp :¼ current TxOpp
5: reference_start_txopp :¼ current TxOpp
6: Scalc:¼ ;
7: Sactive:¼ {0, 1, 2, 3, . . . , min(Num_of_ActTDs 1, max_exp)}
8: Scalc ;
9: if there is data to send in my TD then
10: found_flag :¼ false
11: while Sactive–; do
12: tmp_exp :¼ random(Sactive)
13: contention_start_txopp :¼ smallest_tmp_txopp + 2tmp_exp
14: tmp_txopp MEA(contention_start_txopp, Lij)
15: if tmp_txopp has been used by other MEAIs on the same node then
16: Scalc Scalc[ {tmp_txopp}
17: Sactive Sactive {tmp_exp}
18: else
19: found_flag true
20: break
21: end if
22: end while
23: if found_flag = false then
24: smallest_tmp_txopp min (Scalc)
25: goto line 7
26: end if
27: else
28: found_flag :¼ false
29: if min (Num_of_ActTDs, max_exp) 6 4 then
30: starting_exp :¼ 4
31: else
32: starting_exp :¼ min (Num_of_ActTDs, max_exp)
33: end if
34: for tmp_exp starting_exp to max_exp do
35: contention_start_txopp :¼ smallest_tmp_txopp + 2tmp_exp
36: tmp_txopp MEA(contention_start_txopp, Lij)
37: if tmp_txopp has been used by other MEAIs on the same node then
38: Scalc Scalc[ {tmp_txopp}
Fig. 5illustrates an example of how TMEA-D solves the above problem. Suppose that a node i has six MEAIs and its TD-1 MEAI is calculating the next MSH-DSCH TxOpp. First, the TD-1 MEAI sets its smallest_tmp_txopp to 0 and then performs MEA to find its next TxOpp number. In the first round, it finds that the TxOpp numbers that node i can win have been used by other MEAIs on node i (TxOpps 9, 18, 33, 66, and 130). As a result, it advances its small-est_tmp_txopp to 9 and restarts the next TxOpp finding process. In this round, it successfully wins TxOpp 14 that has not been won by other MEAIs of node i.
The reason why TxOpp 14 can only be found in the sec-ond round is explained here. TxOpp 14 is between TxOpp 9 and TxOpp 18. The former is chosen when the exponent value is advanced to 3 (i.e., the holdoff time becomes 23= 8) and the latter is chosen when the exponent value is
advanced to 4 (i.e., the holdoff time becomes 24= 16).
According to the standard, when MEA wins TxOpp 9, it immediately returns that TxOpp as the output. Later on, when MEA finds that TxOpp 9 has been won by another MEAI and a new one should be found, it advances the expo-nent value from 3 to 4 and starts the searching from TxOpp 16 = 0 + 16 (where 0 is the value of smallest_tmp_txopp and 16 is the current holdoff time 24). However, this exponential
holdoff time expansion causes TxOpp 14 to be skipped in the search during the first round. At the second round, be-cause smallest_tmp_txopp is moved to TxOpp 9 and the
exponent value starts over from 0 again, the search can start from TxOpp 10 = 9 + 20and eventually find TxOpp 14.
For the case where there is no data to send in the TD, the MEAI need not use a small next TxOpp to transmit its next control message. Thus, it first determines the starting holdoff time exponent value (stored as starting_exp) using
the minimum between Num_of_ActTDs and max_exp.1If
this value is below 4, then MEAI adjusts it to 4. The rationale behind this design is that the number of active TDs of a node may dynamically fluctuate. Because the node has no data to send in this TD, the control message dissemination of this TD is not time-critical. Thus, TMEA-D prevents the MEAI of an idle TD from using small holdoff time exponent values, which are more valuable for MEAIs of active TDs to reduce the time required for negotiating minislot allocations.
After determining the starting_exp value, the MEAI of an idle TD iteratively finds its next TxOpp using holdoff time exponent values from start_exp to max_exp. The cal-culation in this iterative process is similar to that used by an MEAI of an active TD. The main difference is that an MEAI of an active TD chooses a smaller holdoff time expo-nent value from Sactivein a random manner while an MEAI
of an idle TD chooses a larger holdoff time exponent value
39: contention_start_txopp contention_start_txopp + 1 40: else 41: found_flag true 42: break 43: end if 44: end for
45: if found_flag = false then
46: smallest_tmp_txopp min(Scalc)
47: goto line 8
48: end if
49: end if
50: proper_exp :¼ floor(log2(tmp_txopp reference_start_txopp))
51: proper_offset :¼ (tmp_txopp reference_start_txopp) 2proper_exp
52: return (tmp_txopp, proper_exp, proper_offset)
Fig. 5. An example of the iterations of TMEA-D.
1
The maximum holdoff time exponent value is defined as 7 in the standard.
from [max(4, min (Num_of_ActTDs,max_exp)), max_exp] in an iterative manner. For brevity, the same explanation for these calculations is not repeated here.
The MEAIs of active TDs on the same node share the useable smaller holdoff time values in a random manner, which prevents some of them from monopolizing the smallest holdoff time values and thus ensures a fair sharing of these valuable small holdoff time values among them in a long term. Thus, for MEAIs of active TDs on the same node, the average times required by them to negotiate minislot allocations (to transmit data) can be the same. 4.4. Problem 3: Transmission-domain-aware Minislot Scheduling
The 802.16(d) mesh CDS-mode network uses a THP to negotiate minislots for data transmission[1]. The schedul-ing algorithm for allocatschedul-ing minislots has not been stan-dardized. Thus, a minislot scheduling algorithm that can exploit the spatial-reuse property of SSBAs is desired for our work. In this section, we propose an easy-to-imple-ment Transmission-domain-aware Minislot Scheduling Algorithm (TMSA) which need not modify the control mes-sages used in the original THP. We explain its operation below.
TMSA defines four types of minislot allocations for a node x. The first one is the ‘‘local node transmission’’ type (denoted as ‘‘LOCAL_XMIT’’), indicating that a minislot allocation is used by node x to transmit data packets to its neighboring node; the second one is the ‘‘local node recep-tion’’ type (denoted as ‘‘LOCAL_RECV’’), indicating that a minislot allocation is used by node x to receive data packets from its neighboring node; the third one is the ‘‘neighboring node transmission’’ type (denoted as ‘‘NBR_XMIT’’), which indicates that a minislot allocation is used by a node x’s neighboring node to transmit data packets to another neighboring node (other than node x); and the final one is the ‘‘neighboring node reception’’ type (denoted as ‘‘NBR_RECV’’), which indicates that a minislot allocation is used by a node x’s neighboring node to receive data from another neighboring node (other than node x). For brevity, we use the notation (x ? y) to represent a minislot
alloca-tion that is used by node x to transmit data packets to node y.
In TMSA, the description of a minislot allocation is rep-resented by a 7-tuple pair (TDI, NID, type, SFN, validity, SMN, MR), where the TDI field denotes the transmission domain index. The type field denotes the type of this mini-slot allocation; SFN denotes the starting frame number of this minislot allocation, validity denotes the number of frames that this minislot allocation lasts; SMN denotes the starting minislot number of this minislot allocation within a frame; and MR (Mini-slot Range) denotes the number of minislots occupied by this minislot allocation within a frame. The interpretation of the NID field depends on the value of the type field. The NID field represents the ID of the receiving node when the following type field is ‘‘LOCAL_XMIT.’’ Otherwise, it represents the ID of the transmitting node. The allocations of ‘‘NBR_XMIT’’ and ‘‘NBR_RECV’’ types are learned from received MSH-DSCH messages.
We use the example shown in Fig. 6to illustrate the operation of TMSA. In this example, node D has scheduled a minislot allocation (D ? C) that occupies minislots rang-ing from 5 to 29 durrang-ing the frames from 20 to 147 and node F has scheduled a minislot allocation (F ? E) that occupies the same duration. From the perspective of node A, the former minislot allocation is represented as two 7-tuple pairs (0, D, NBR_XMIT, 20, 128, 5, 20) and (1, C, NBR_RECV, 20, 128, 5, 20), and the latter minislot alloca-tion is represented as another two 7-tuple pairs (3, F, NBR_XMIT, 20, 128, 5, 20) and (0, E, NBR_RECV, 20, 128, 5, 20).
Suppose that node A wants to schedule its minislot allo-cation (A ? B) in the same duration. Using TMSA, node A first checks its minislot allocation list to see whether there is any minislot allocation with the LOCAL_XMIT or LOCAL_-RECV type in that duration. If yes, it cannot schedule any minislot allocation in this duration because it cannot simultaneously transmit or receive packets in two different TDs. In this condition, node A should try to schedule (A ? B) within a different duration.
In case no such a minislot allocation exists in the list, node A then checks whether the list contains any learned
NBR_XMIT allocations with node B being the transmitting node for the same duration. If yes, it should not schedule (A ? B) because node B cannot receive its packets in that duration. If no, node A finally checks whether the list con-tains a learned NBR_RECV allocation in the TD where node B resides for the same duration. If yes, it should not sche-dule (A ? B); otherwise, this transmission will interfere with the neighboring node’s data packet reception. If no, (A ? B) can be scheduled. In this example, because no such an allocation exists, node A can schedule this (A ? B) at the same time when (D ? C) and (F ? E) take place. This example scheduling shows that the proposed TMSA can utilize the spatial-reuse advantage of SSBA to increase net-work capacity on the data plane.
5. Performance evaluation
In this section, we use the NCTUns network simulator
[20]to evaluate the performances of our proposed scheme. NCTUns is an advanced network simulator with two un-ique advantages: (1) directly using the real-world TCP/IP protocol stacks in the Linux kernel; and (2) allowing real-world network application programs to run over its simu-lated networks. By these two features, NCTUns can provide high-fidelity simulation results with real implementations of TCP and application traffic generator.
5.1. Simulation environment
We created a 25-node grid network topology shown in
Fig. 7as our simulation topology. The main parameter set-tings used in the simulations are listed inTable 1. Two dif-ferent traffic types are used to generate network traffic. One is TCP and the other is greedy UDP. The word ‘‘greedy’’ means that the source node of a flow will transmit data as many as it can.
In a simulation case, each node sets up a greedy UDP flow to each of its 1-hop neighboring nodes. UDP is a
transportation layer protocol that simply transmits data down to the MAC-layer; thus, the throughputs obtained by all greedy UDP flows of a node are equivalent to the MAC-layer throughputs that can be obtained by the nodes minus the bandwidth overheads introduced by MAC-layer, network-layer, and transport-layer headers. For conve-nience, we use aggregate UDP throughputs to evaluate the capacity gain of an 802.16(d) mesh CDS-mode network using SSBAs.
In addition to evaluate the raw network capacity, we also use TCP flows to conduct simulations in the same sce-nario. TCP is a complicated transportation-layer protocol that employs sophisticated error-control and congestion-control mechanisms to guarantee error-free in-order data delivery. It is widely used by many network applications, e.g., the File Transfer Protocol (FTP) and the HTTP web ac-cess. Thus, observing how TCP works over this new net-work using SSBAs is important for transport-layer study and application development.
Each of our simulation case was run ten times, each time using a different random number seed. The simulated time of each run was 500 s. In a simulation, the traffic gen-erator programs are activated at the 200-th second of the simulated time. This arrangement is to ensure that they transmit data packets after the simulated network has been stabilized.2In each of the figures shown below, both
the average and the standard deviation of the collected sim-ulation results are presented.
In the simulated grid network, each node is spaced 450 m away from its neighboring nodes and equipped with an SSBA. The gain pattern of the used SSBA on the horizon-tal plane is plotted inFig. 8, which is derived from[28]. For wireless channel modeling, we conducted simulations with several channel models, such as the two-ray model, Erceg’s model with terrain type B, and the ECC-33 model. In our experiences, in absence of dynamic fading effects (e.g., the Rayleigh fading), by properly setting the physi-cal-layer parameters and the distance between nodes, the link connectivity and signal quality experienced by nodes can be adjusted to the same level. Thus, to save space we
Fig. 7. The topology of the simulated network.
Table 1
The parameter settings used in the simulations.
Parameter name Value
Number of TxOpps per frame 8 Number of TxOpps per frame used by the
CDS mode
8 Number of mini-slots per frame 220 Number of OFDM symbols per mini-slot 3
Requested mini-slot size per THP 10, 20, 30, 40, 50, 60, 70
Requested frame length 20
, 21 , 22
, 23 , 25
, 27 Modulation/CODING SCHEME 64QAM-3/4
Channel model ECC-33
Frame duration 10 ms
TCP version Binary increase
Congestion control TCP (BIC-TCP)
2
A stabilized network is defined as a network in which all of its nodes have joined the network.
only present the simulation results using the ECC-33 mod-el in this section and discuss the effects of the Rayleigh fad-ing in Section5.3.4.
Without the presence of the dynamic fading, the effec-tive transmission range and interference range in our sim-ulations are adjusted to 500 and 850 m, respectively. With the presence of the dynamic fading, there are no explicit values for the transmission range and the interference range of a node. In this condition, a proper receive power threshold is set for each simulation case to maximize flow throughputs. Because the antenna gain patterns of the used SSBA and the omnidirectional antenna greatly differ, the transmit powers of the radios used in the MTD and STD schemes were set to 22 dBm and 50 dBm, respectively, to maximize their respective network performances.
The ECC-33 model was originally proposed for model-ing the path loss effect over 3.5 GHz omnidirectional radios. For this reason, when SSBAs are used, the transmit and receive antenna gains used in this model will be re-computed using the gain pattern shown inFig. 8. 5.2. Performance metrics
Two performance metrics are used in this work: (1) the Average Throughput of a UDP Flow in a network (ATUF) and (2) the Average Throughput of a TCP Flow in a network (ATTF). In addition, the coefficients of variation (CVs) of the ATUF and ATTF values of all flows in a network are pre-sented to study the fluctuation degree of application throughputs under the evaluated schemes. In addition to these application-layer metrics, we use two MAC-layer performance metrics to evaluate the performance gain of the proposed scheme. One is the Average TxOpp Utilization of Nodes (ATOUN) and the other is the Average Three-way
Handshake Procedure Time (ATHPT). The definitions of these performance metrics are given below.
5.2.1. ATUF and ATTF
The ATUF metric is defined as the average throughput of a UDP flow across all network nodes, which is defined as follows:
ATUF ¼TTAF
TNST; ð8Þ
where TTAF (total throughputs of all flows) denotes the sum of all nodes’ average UDP-flow throughput samples across the different runs of a case, which is defined by the following equation:
TTAF ¼X nc m¼1 Xnn i¼1 X te time1 n¼ts timeþ1
udp thijmðnÞ;
8
j 2 nbr1ðiÞ; ð9Þwhere nc denotes the number of runs that a simulation case was performed and nn denotes the number of nodes in the simulated network. The ts_time denotes when a UDP-flow sender program starts transmitting data packets in seconds and the te_time denotes when a UDP-flow sen-der program stops transmitting data packets in seconds. In our simulations, ts_time and te_time are set to 200 and 499 s, respectively. The udp_thijm(n) denotes the average
throughput of a UDP flow from node i to node j during the nth second in the mth run. The definition of nbr1(i)
has been given in Eq.(2).
TNST (total number of sampled throughput3) denotes
the total number of sampled UDP-flow throughputs across all flows and all runs of a case and is defined as follows:
Fig. 8. Gain pattern of the used SSBA.
3
In our simulations, a flow is sampled every one second to record its average throughput in the past one second.
TNST ¼X nc m¼1 Xnn i¼1 X te time1 n¼ts timeþ1 jnbr1ðiÞj: ð10Þ
The definition of ATTF is similar to that of ATUF, except that ATTF uses the following formula to calculate its TTAF:
TTAF ¼X nc m¼1 Xnn i¼1 X te time1 n¼ts timeþ1 tcp thijmðnÞ;
8
j 2 nbr1ðiÞ; ð11Þwhere tcp_thijm(n) denotes the average throughput of a TCP
flow from node i to node j during the nth second in the mth run.
5.2.2. CV-ATUF and CV-ATTF
The coefficients of variation (CV) of ATUF and ATTF val-ues (denoted as CV-ATUF and CV-ATTF) are used to estimate the fluctuation degree of a traffic flow’s throughput during simulation. The zero value of CV-ATUF (or CV-ATTF) indi-cates that the flow throughput in the network is stabilized at any given time, while a large CV-ATUF (CV-ATTF) value indicates the flow throughput in the network fluctuates greatly over time. The definition of CV-ATUF is defined as follows:
CV ATUF ¼StdDev ATUF
ATUF ; ð12Þ
where StdDev_ATUF denotes the standard deviation of all UDP-flow throughput samples in a case, which is defined by the following equation:
StdDev ATUF ¼ ffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffi Pnc m¼1 Pnn i¼1 Pte time1
n¼ts timeþ1ðudp thijmðnÞ ATUFÞ2;8j 2 nbr1ðiÞ
TNST :
s
ð13Þ
The definition of CV-ATTF is similar to that of CV-ATUF and is shown as follows:
CV ATTF ¼StdDev ATTF
ATTF ; ð14Þ
where StdDev_ATTF denotes the standard deviation of all TCP-flow throughput samples in a case, which is defined as follows: StdDev ATTF ¼ ffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffi Pnc m¼1 Pnn i¼1 Pte time1
n¼ts timeþ1ðtcp thijmðnÞ ATTFÞ2;8j 2 nbr1ðiÞ
TNST :
s
ð15Þ
5.2.3. ATOUN
The ATOUN metric evaluates the efficiency of utilizing the control-plane bandwidth for a network. The average TxOpp utilization viewed from a node j using SSBA can be defined as follows: AvgTxOppUtilðjÞ ¼ PNumTD1 k¼0 P i2ðnbrðjkÞfjgÞtxnumðiÞ þ txnumðjÞ totalðjÞ ; ð16Þ
where txnum(i) denotes the number of TxOpps won by a node i; total (j) denotes the number of total TxOpps that have elapsed since node j joins the network; NumTD
denotes the number of TDs that node j has; and the defini-tion of nbr(jk) has been given in Eq.(7). On the other hand,
the average TxOpp utilization viewed from a node j using an omnidirectional antenna can be defined as:
AvgTxOppUtilðjÞ ¼ P
i2nbrðjÞtxnumðiÞ
totalðjÞ : ð17Þ
The ATOUN metric is defined as the average of the AvgTxOppUtil values across all nodes in a case. The defini-tion of ATOUN is shown as follows:
ATOUN ¼
Pm
j¼1AvgTxOppUtilðjÞ
m ; ð18Þ
where m is the number of nodes in a simulation case. Each ATOUN result presented in Section5.3is the average across ten runs. A higher value of ATOUN indicates that a network case has a higher utilization of TxOpps while a lower value of this metric indicates that a network case has a lower uti-lization of TxOpps.
5.2.4. ATHPT
The ATHPT metric is defined as the average time required to complete a THP across all nodes in a case. A node is allowed to transmit data packets to another node only after it has scheduled a minislot allocation with that node. For this reason, ATHPT significantly influences the packet delay time experienced by applications. Its defini-tion is explained here. We first define THPT (i) as the average time required to establish minislot allocations for a node i in a case, which is given below:
THPTðiÞ ¼
Pn
j¼1tij
n ; ð19Þ
where tij denotes the time required to establish the jth
minislot allocation of node i with one of its neighboring nodes and n denotes the number of minislot allocations that node i establishes during simulation. We then com-pute the ATHPT value of a case as follows:
ATHPT ¼
Pm
i¼1THPTðiÞ
m ; ð20Þ
where m is the number of nodes in a simulation case. Sim-ilar to ATOUN, each ATHPT result presented in Section5.3
is the average across 10 runs. 5.3. Simulation results
5.3.1. Effects of holdoff exponent values
In this section, we studied the effects of nodes’ holdoff times on network performances. For the STD scheme, a gi-ven holdoff time exponent value x means that all nodes use the 2x TxOpps as their holdoff times in simulations,
while for the MTD scheme a given holdoff time exponent va-lue x means that the Sactiveset used in the TMEA-D algorithm
is {x, x + 1, x + 2, . . . , min(x + Num_of_ActTDs 1, max_exp)}, where x is from 0 to 4 in our simulations. In this series of simulations, the requested frame duration and the number of requested minislots per frame in a THP were set to 32 frames and 30 minislots, respectively.
Fig. 9shows the ATOUN results of the STD and MTD schemes over different holdoff time exponent values. As one knows, increasing the holdoff time exponent value will increase the transmission intervals of nodes’ control messages. Thus, the TxOpp utilization of the network will decrease, when this value increases. One interesting phe-nomenon is that the TxOpp utilization of the STD scheme is higher than that of the MTD scheme, when the holdoff time exponent value is very small (i.e., below 2), but drops more rapidly than that of the MTD scheme, when this va-lue increases. We explain this phenomenon from two as-pects. First, when using the MTD scheme a node i uses multiple MEAIs to manage its transmission domains. Due to this design, from the perspective of node i’s neighboring nodes, on TxOpp T the set of TxOpps for which node i will not contend is denoted as Siinact txðTÞ and given as follows:
Siinact txðTÞ :¼ \H i
jðTÞ; 0 6 j 6 Num of ActTDs 1; ð21Þ
where HijðTÞ denotes the holdoff time interval of node i’s
MEAI j known by node i’s neighboring nodes on TxOpp T. For node i, it is impossible that Hi
jðTÞ; 8existing MEAI j,
ex-actly overlap. Thus, the size of Siinact txðTÞ in the MTD
scheme is much less than that in the STD scheme. This means that nodes in the MTD scheme more conservatively choose TxOpps to transmit control messages to avoid in-ter-node scheduling conflicts. As a result, when the flexi-bility of TxOpp scheduling is large (e.g. all nodes can use small holdoff time exponent values), the TxOpp utilization of the STD scheme can be better than that of the MTD scheme. Second, the reason why the TxOpp utilization of the MTD scheme decreases slower than that of the STD scheme, as the holdoff time exponent value increases, is explained here. The MTD scheme employs multiple MEAIs to manage directional control message transmissions and all of these MEAIs need to find a conflict-free TxOpp to transmit their control messages in their respective TDs. Nodes using the MTD scheme therefore needs to consume more TxOpps than the STD scheme. As a result, when nodes’ holdoff time intervals becomes large, nodes in the MTD scheme will use more TxOpps than those in the STD scheme, which makes the TxOpp utilization of the MTD scheme drops more slowly than that of the STD scheme.
However, as can be seen inFig. 10, the time required for a node to establish a minislot allocation is insensitive to
the holdoff time exponent value when it is below 3. This is because the procedure to establish a minislot allocation is three-way based, which should finish a ‘‘requester–gran-ter–requester’’ control message transmission sequence. Due to the randomness of the distributed TxOpp schedul-ing used in the 802.16(d) mesh CDS mode, the requestschedul-ing and granting nodes may not always achieve the most effi-cient TxOpp scheduling to minimize the time for establish-ing a minislot allocation. In addition, although decreasestablish-ing the holdoff time exponent value increases the TxOpp scheduling flexibility of nodes, it does not guarantee that a node that is performing a THP can always win a smaller TxOpp. (This is affected by how many MEAIs on this node and its neighboring nodes are performing THPs at the same time.) For these reasons, even when the holdoff time expo-nent value is set to very small (e.g. no more than 3), the average of the time required for establishing a minislot allocation remains the same.
As one also sees, a larger holdoff time exponent value (e.g., 4) can increase the time required for establishing a minislot allocation. These results confirm the findings pre-sented in [5,6,2,21]. Another noticeable phenomenon is that the average minislot allocation establishment time of a node using the MTD scheme is greatly higher than that of a node using the STD scheme. Such a phenomenon re-sults from two reasons. One is that, due to the directivity of SSBAs, a node using the MTD scheme cannot exchange control messages with a specific peer node on every TxOpp that it wins. Instead, it is only allowed to communicate with a specific peer node on TxOpps won by its MEAI that manages the TD where this peer node resides. In contrast, nodes using the STD scheme can communicate with any of its neighboring nodes on every TxOpp that it wins. Due to this difference, nodes using the MTD scheme require more time to complete a THP and obtain a minislot allocation.
However, because the MTD scheme can utilize the spa-tial reuse advantage of SSBAs, it still outperforms the STD scheme on UDP and TCP flow throughputs. As shown in
Figs. 11 and 12, the MTD scheme can on average outper-form the STD scheme on ATUF by a factor of 2.71 and on ATTF by a factor of 5.88, regardless of the used holdoff time exponent value. The reason why TCP performs worse than UDP on average throughput is that TCP uses a complicated congestion control algorithm to prevent network band-width from being exhausted by a single flow, which 0 0.2 0.4 0.6 0.8 1 0 0.5 1 1.5 2 2.5 3 3.5 4 ATOUN
Holdoff Exponent Value Legends
STD MTD
Fig. 9. ATOUN results over different holdoff time exponent values.
0 20 40 60 80 100 120 140 160 180 0 0.5 1 1.5 2 2.5 3 3.5 4 ATHPT (ms)
Holdoff Exponent Value Legends
STD MTD
usually regards packet losses as an indication of network congestion. Because the IEEE 802.16(d) mesh CDS mode schedules minislots in a distributed manner, the time for a node to obtain a minislot allocation may fluctuate and the number of minislots obtained in a minislot allocation may greatly vary. In this condition, an outgoing network interface needs to temporarily store packets in its own packet queue. If the packet queue of an interface becomes full, packets sent from upper-layer applications will be dropped, which may make TCP unnecessarily reduce its congestion window size and under-utilize link bandwidth. In this section, we showed that the holdoff time expo-nent value has great impacts on TxOpp utilization. How-ever, because the IEEE 802.16(d) mesh CDS mode uses a distributed three-way handshake design to schedule mini-slot allocations on the data plane, as long as the used hold-off time exponent value is not too large (e.g. above 4), the average time for nodes to negotiate a minislot allocation is insensitive to the holdoff time exponent value. Thus, the average UDP and TCP flow throughput results of both the MTD and STD schemes are unchanged when the holdoff time exponent value is between 0 and 4.
5.3.2. Effects of requested frame duration per THP
In this section, the holdoff time exponent value was set to 0, for maximizing the scheduling flexibility of both schemes. The number of requested minislots per frame in a THP was set to 30. Following[1], the requested frame duration for a minislot allocation was set to 20, 21, 22, 23,
25, and 27, respectively. Figs. 13 and 14show the ATUF
and ATTF results over different requested frame duration in a THP, respectively. One intuitive result is that increas-ing the requested frame duration in a THP can increase the utilization of minislots, which results in increased UDP and TCP flow throughputs for both of the evaluated schemes.
A noticeable phenomenon is that, when the requested frame duration per THP is below 23frames, the UDP and
TCP flow throughputs achieved by the MTD scheme is only the same as those achieved by the STD scheme. This is be-cause, as discussed previously, using the MTD scheme nodes on average need 100 ms (i.e., 10 MAC-layer frames) to obtain a minislot allocation. To prevent a node from monopolizing link bandwidth, in our implementation a node A will be triggered to perform a THP with a neighbor-ing node B, only when it has data destined to node B and does not possess any valid minislot allocation granted by node B. Due to this design and the long ATHPT property of the MTD scheme, if the requested frame duration in each THP does not exceed d(ATHPT/Num_of_ActTDs)e frames, nodes using the MTD scheme will not be able to schedule minislots as tight as those using the STD scheme. In con-trast, when the requested frame duration greatly exceeds d(ATHPT/Num_of_ActTDs)e frames, due to the spatial reuse advantage, the MTD scheme can greatly outperform the STD scheme on UDP and TCP flow throughput performances.
We plotted the ATHPT results of the two evaluated schemes under the UDP and TCP traffic cases over different requested frame durations inFigs. 15 and 16. The results 0 200 400 600 800 1000 0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 ATUF (KB/s)
Holdoff Exponent Value Legends
STD MTD
Fig. 11. ATUF results over different holdoff time exponent values.
0 100 200 300 400 500 0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 ATTF (KB/s)
Holdoff Exponent Value Legends STD MTD
Fig. 12. ATTF results over different holdoff time exponent values.
0 200 400 600 800 1000 0 1 2 3 4 5 6 7 ATUF (KB/s)
Number of requested frames per THP (2x) Legends
STD MTD
Fig. 13. ATUF results over different requested frame durations in a THP.
0 100 200 300 400 500 600 0 1 2 3 4 5 6 7 ATTF (KB/s)
Number of requested frames per THP (2x) Legends
STD MTD
show that the time required for a node to complete a THP is less related to the requested frame durations.
5.3.3. Effects of MAC-layer traffic loads
In this section, we changed the number of requested minislots per frame in a THP from 0 to 70, to generate dif-ferent MAC-layer traffic loads. The holdoff time exponent value and the requested frame duration in a THP were set to 0 and 27frames, respectively.
As shown inFig. 17, the ATUF under the MTD scheme significantly outperform those under the STD scheme over most of the evaluated MAC-layer traffic loads. These
results evidence that the MTD scheme can effectively ex-ploits spatial-reuse advantages of SSBAs to provide more network capacity. One may notice that, when the number of requested minislots per THP is 10 only, the ATUF results of the two evaluated schemes are close. This is because, when the generated traffic load is very light, the STD scheme can accommodate it without causing network con-gestion. However, when the number of requested minislots in a THP increases (i.e., the generated MAC-layer traffic load increases), the STD scheme quickly reaches its satura-tion point and cannot keep up with the performance of the MTD scheme.
Fig. 18shows the CV-ATUF results over different num-bers of requested minislots in THPs, which indicate the fluctuation degree of the achieved throughputs of flows in a network over time and the fairness of network band-width allocation among them. One can see that the CV-ATUF values of the MTD scheme are much lower than those of the STD scheme, showing that network applica-tions can achieve a more stable throughput over time un-der the MTD scheme than unun-der the STD scheme. These results also indicate that network bandwidth sharing among these competing UDP flows is fairer under the MTD scheme.
Fig. 19 shows the ATTF results of the two evaluated schemes over different numbers of requested minislots per THP. There are several findings about this figure. First, 0 20 40 60 80 100 120 140 160 180 0 1 2 3 4 5 6 7 ATHPT (ms)
Requested Frame Duration per THP (2x) Legends
STD MTD
Fig. 16. ATHPT results over different frame durations under the TCP flow case. 0 20 40 60 80 100 120 140 160 180 0 1 2 3 4 5 6 7 ATHPT (ms)
Requested Frame Duration per THP (2x) Legends STD MTD
Fig. 15. ATHPT results over different frame durations under the UDP flow case. 0 200 400 600 800 1000 1200 1400 1600 0 10 20 30 40 50 60 70 ATUF (KB/s)
Number of requested minislots per THP Legends
STD MTD
Fig. 17. ATUF results over different numbers of requested minislots in a THP. 0 0.5 1 1.5 2 0 10 20 30 40 50 60 70 Coefficient of Variation
Number of requested minislots per THP Legends STD MTD
Fig. 18. CV-ATUF results over different numbers of requested minislots in a THP. 0 100 200 300 400 500 600 0 10 20 30 40 50 60 70 ATTF (KB/s)
Number of requested minislots per THP Legends
STD MTD
Fig. 19. ATTF results over different numbers of requested minislots in a THP.
