Notification of Holdoff Time Base Value Change

Here, we propose a practical protocol that can notify new SS nodes of the holdoff time base value used in a network. A BS node can use this protocol to check whether a new SS node can operate using a holdoff time base value other than 4. If an SS node cannot do so, the BS node should reject the network registration request from this SS node because this SS node cannot work well with other SS nodes in the network.

Our proposed protocol exploits the reserved “vendor-specific information” field to help SS nodes know the holdoff time base value used in the network. This field is defined in the standard for the registration procedure to exchange additional information not specified in the standard. The signaling protocol is described as follows: An SS node first adds a holdoff time base query message (carried by the “vendor-specific information” field) into the registration request (REG-REQ) message, which is destined to the BS node.

On receiving this REG-REQ message, the BS node replies the SS node with a regis-tration response (REG-RSP) message, which contains the holdoff time base value used in this network (also carried by the “vendor-specific information” field). If the BS node does not find the holdoff time base query message in the SS node’s REG-REQ message, it should reject this SS node’s registration request because this SS node may not be able to change its holdoff time base value.

There are three ways to reject a registration request. The first one is simply to ignore the REG-REQ message if the BS node decides to reject it. The second way is to utilize the “de/re-register command” (DREG-CMD) message, defined in the standard. The DREG-CMD message can be used to notify the SS node of the rejection action. The last way is to return a REG-RSP message with the response code set to 1, indicating that this registration request cannot be accepted because the SS node may not be capable of changing its holdoff time base value.

3.2 Proposed Scheme for Networks using Single-switched-beam Antennas

The effects of MEA on the performances of the 802.16(d) mesh CDS mode have been extensively studied [2][3][4][5][6]; however, most of the prior work were based on omni-directional radios. In the literature, rare work studied the performances and challenges of the 802.16(d) mesh CDS-mode network when it uses directional antennas. Because the 802.16(d) mesh CDS mode assumes that MEA operates using omnidirectional radios, MEA encounters several operational problems when operating over directional radios.

Recent antenna technologies for directional message transmission/reception can be categorized into three classes. The first class is the switched-beam antenna, which uses pre-defined antenna gain patterns and can point to several pre-determined directions.

Switched-beam antennas can operate optimally in environments without the presence of the multi-path effect (such as in the free-space environment). Due to lacking the nulling capability, however, they cannot achieve the optimal concurrent transmission schedules in multi-path-prone environments, as compared with the other two directional antenna classes.

The second antenna class is the adaptive array antenna, which is capable of forming arbitrary beams to point to arbitrary directions. By forming “nulls” to directions in which a transmitter does not intend to disseminate its signal or from which a receiver does not intend to sense the signal, adaptive array antennas can effectively reduce the multi-path effects. The last antenna class is the Multiple Input Multiple Output (MIMO) array antenna, which employs multiple antenna elements on both the transmitter and receiver ends. MIMO is well-known for its three capabilities: precoding, spatial multiplexing, and

diversity coding, which can more effectively increase network capacity.

Although adaptive array antennas and MIMO antennas can be superior to switched-beam antennas in achieved network capacity and signal quality, the cost and complexity of their designs and implementations are much higher than those of switched-beam an-tennas. Due to the less design and implementation complexity, switched-beam antennas can be made with less form factor and at a lower cost; they therefore provide a cost-effective solution for wireless mesh networks using directional radios and more suitable for constructing emergent and tactic wireless mesh networks.

In this section, we reviewed the design of the 802.16 mesh CDS mode, identified the problems that result from using single-switched-beam antennas 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.) We conducted proof-of-concept simulations to evaluate the network capacity increased by using single-switched-beam antennas 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 protocol widely used in current network applications (such as FTP, HTTP, etc.) and is sensitive to network congestion and end-to-end packet delay jitters. Due to the unique protocol design of the 802.16 mesh CDS mode, how TCP performs under this network with single-switched-beam antennas is interesting and worth studying.

To the best of the authors’ knowledge, our work is the first work that discusses how to enable the IEEE 802.16(d) mesh CDS-mode network to operate with single-switched-beam antennas and evaluates the performances of this network with single-switched-single-switched-beam antennas. Although there have been many prior works studying TDMA networks with di-rectional radios [7][8][9][10][11][12][13][14][15][16][17], they differ from the IEEE 802.16(d) mesh CDS mode using single-switched-beam antennas in either control message scheduling or data scheduling. Thus, the issues and performances of the IEEE 802.16(d) mesh CDS mode employing such an antenna configuration is worth studying. Although the IEEE 802.16 mesh mode may not be maintained in the next-generation 802.16 standard family due to several reasons, e.g., its design complexity is higher than that of the traditional point-to-multipoint (PMP) mode and its current business potential is less than that of the

PMP mode, in the literature so far it is one of the most representative WMNs that have been well developed and studied and can be a good design reference for next-generation WMNs.

In this dissertation, we do not assume that a single-switched-beam antenna allows omnidirectional transmission and reception because the antenna gain of such an antenna in the directional mode and that in the omnidirectional mode may greatly vary. Without proper transmission power control, the connectivity among nodes in the directional mode and that in the omnidirectional mode may be inconsistent and hinder network operation.

To simplify the scheduling complexity, our proposed scheme operates only with pure directional transmission and reception. As a result, several protocol issues will arise due to such a harsh constraint. For example, in the IEEE 802.16(d) mesh CDS mode each node maintains its two-hop neighborhood to avoid the hidden-terminal problem when transmitting its control messages. The definition of such a two-hop neighborhood 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-hop neighborhood. It is this property ensuring that the MEA used in each node generates collision-free TxOpp scheduling because node A and node B cannot both win the same TxOpp in their respective two-hop neighborhoods. However, when only pure directional transmission and reception are allowed (e.g., when using single-switched-beam antennas), the above property no longer holds at all time. This makes receiving control messages from other nodes non-trivial. In this condition, network operation and network initialization encounter several issues that need to be solved. In the following, we explain the problems of the IEEE 802.16(d) mesh CDS mode, when it uses single-switched-beam antennas to operate and initialize the network, and present our solutions to these problems.

3.2.1 Problem 1: Imprecise Representation for TxOpps in Con-trol Messages

In the 802.16(d) mesh CDS mode, to save the bandwidth consumed by control mes-sages, the next TxOpp number of a node carried in an MSH-DSCH message and an MSH-NCFG message 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 represented

using the following formula:

2^exp∗ Mx < TxOpp number ≤ 2^exp∗ (Mx + 1), (3.4) where 0 ≤ Mx ≤ 30, 0 ≤ exp ≤ 7. The interval between (2^exp∗ Mx, 2^exp∗ (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 transmit 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 (2⁵ ∗ 1, 2⁵ ∗ 2]

(base=4, exp=1, Mx=1) as their next transmission intervals and notify node C of these settings.

The overlapping of two neighboring nodes’ transmission intervals does not hinder the operation of the 802.16(d) mesh CDS mode, when omnidirectional radios are used, because each node can listen incoming messages omnidirectionally, when it need not transmit control messages. In this condition, a node will not miss any control messages broadcast from neighboring nodes as long as it is not in the transmission state. However, when only directional reception is allowed, a node cannot determine to which direction 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 those nodes whose next transmission intervals are overlapped.

In addition, even though the transmission intervals of neighboring nodes do not over-lap with each other, this imprecise representation scheme still reduces the flexibility of scheduling control message transmissions. Consider nodes A and B that are neighboring to each other. Using this TxOpp representation scheme, 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 interval of 2^exp 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, it has to point its antenna towards node B during the whole interval to successfully receive the next MSH-DSCH message broadcast from node B. However, if the exact next TxOpp won by node B can be known, node A can exchange control messages with some other nodes in this long interval to reduce the latency of

Figure 3.10: The auxiliary offset field for precisely representing a TxOpp number updating network management information and scheduling data packet transmissions.

From this observation, to ensure that an 802.16(d) mesh CDS-mode network can obtain performance gains when using single-switched-beam antennas, 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. As shown in Fig. 3.10, with the help of the newly-added offset field, a node now can use Eq. (3.5) 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 = 2^exp∗ Mx + offset (3.5)

3.2.2 Problem 2: Control Message Transmissions using Pure