Release-time-based multi-channel MAC protocol for wireless mesh networks

(1)

Release-time-based multi-channel MAC protocol for wireless

mesh networks

q

Andy An-Kai Jeng, Rong-Hong Jan

⇑

, Chi-Yu Li, Chien Chen

Department of Computer Science, National Chiao Tung University, 1001 Ta Hsueh Road, Hsinchu 30005, Taiwan

a r t i c l e

i n f o

Article history:

Received 21 August 2009

Received in revised form 12 July 2010 Accepted 28 February 2011 Available online 6 March 2011 Responsible Editor: L. Lenzini Keywords:

Wireless mesh network Multi-channel multi-interface Medium access control Channel selection

a b s t r a c t

The wireless mesh network (WMN) has been considered one of the most promising tech-niques for extending broadband access to the last mile. In order to utilize multiple channels to increase the throughput in WMNs, a variety of multi-channel MAC (MMAC) protocols have been proposed in the literature. In particular, the dedicated control channel (DCC) approach can greatly simply many design issues in multi-channel environments by using a common control channel to exchange control signals. On the other hand, it allows each sender–receiver pair to dynamically select a data channel for their data transmission in an on-demand matter. However, the common control channel would become a bottleneck of the overall performance. Besides, the selection of data channels would be highly related to the final throughput. In this paper, we propose a new MMAC protocol, named the release-time-based MMAC (RTBM) to overcome the control channel bottleneck and data channel selection problems in the DCC approach. The RTBM consists of three major compo-nents: (1) Control initiation-time predication (CIP); (2) Dynamic data-flow control (DDC); (3) Enhanced channel selection (ECS). The CIP can predict a proper initiation time for each con-trol process to reduce concon-trol overhead. The DDC can dynamically adjust the flow of each data transmission to fully exploit the channel bandwidth. The ECS can achieve a higher reusability of data channels to further enhance the throughput. Simulation results show that the RTBM can substantially improve the throughput in both single-hop and multi-hop networks.

1. Introduction

The wireless mesh network (WMN) has been considered one of the most promising techniques for extending broadband access to the last mile[1]. The WMN consists of a set of mesh access points (MAPs). A mobile station can access the network by connecting to a nearby MAP. Each MAP acts as a wireless router to forward trafﬁc hop-by-hop to destinations. Thus, by deploying in such a fashion, a backhaul network can easily be built up without wired connection. Moreover, the network capacity can be substantially improved by using multiple channels. The IEEE 802.11b/g and 802.11a standards provide up to 3 and 12 orthogonal channels, respectively, in 2.4 GHz and 5 GHz spectrums. Nodes within the interference range of each other can transmit on different channels simultaneously to increase the throughput.

In order to utilize multiple channels in WMNs, a key issue is to design a multi-channel medium access control (MMAC) pro-tocol[2]to handle operations at the data-link layer. However, due to the limitation that a wireless card (for most commercial

q

This research was supported in part by the National Science Council, Taiwan, ROC, under grants NSC97-2219-009-006, and 97-2221-E-009-049-MY3.

⇑ Corresponding author. Tel.: +886 3 5712121x31539. E-mail address:rhjan@cis.nctu.du.tw(R.-H. Jan).

Contents lists available atScienceDirect

Computer Networks

(2)

devices) cannot perform on two different channels at a time, the design of many essential mechanisms, such as contention resolution, hidden terminal avoidance, and broadcasting support, could be much more difﬁcult in comparison with a single-channel MAC (e.g. IEEE 802.11 DCF).

To overcome the above limitation, a prominent approach, called the dedicated control channel (DCC), was proposed[3–10]. In this approach, each node is equipped with a control interface and a data interface. The control interface is permanently ﬁxed on a common channel (called control channel) for sensing or exchanging control signals. On the other hand, the data interface can switch among the remaining channels (called data channels) for data transmission. As shown inFig. 1, if node u intends to transmit to node

v

, it ﬁrst initiates a control process with

v

on the control channel to coordinate a data channel. Then, nodes u and

v

can communicate on that channel. Since the control channel is shared by all nodes, other competitors in the interfer-ence range of u or

v

can be aware of the coordination. Besides, a link-layer broadcast can be easily achieved by emitting on the control channel. Most importantly, since each node has an interface dedicated to listen to the control channel, nodes can exchange control signals without any time synchronization mechanism.

However, designing a DCC-based MMAC protocol confronts two major challenges:

(1) Control channel bottleneck problem: As described above, using a common control channel can greatly simplify the design of a MMAC. Nonetheless, if too many nodes contend on it, the control channel would become a bottleneck of the overall performance. As shown inFig. 2(a), three sender–receiver pairs {u,

v

}, {x, y}, and {w, z} are coordinating on the control channel ch0. Besides, there are three data channels with bandwidth B. Ideally, the throughput can

achieve 3B if each pair transmits on a different data channel. However, since the time required for a control process is about a half of a data transmission in this example, at most two data channels can be utilized at the same time, resulting in a lower throughput of 2B. In other words, the throughput is saturated by the control channel’s bandwidth. The bottleneck problem will become more serious as the number of data channels, data rates, or node’s density increases[3].

(2) Data channel selection problem: The DCC approach allows each sender–receiver pair to select a data channel in an on-demand matter. But, if the selection strategy were not carefully designed in concern with the reusability of channels, the throughput would be lower. As shown inFig. 2, assume that the sets of channels which are free to nodes y, x, u, and

v

are as speciﬁed inFig. 2(b). Clearly, the transmissions from y to x and from u to

v

can be active simultaneously on different channels. But, if nodes u and

v

do not consider channel statuses at nearby nodes, they may select ch2in prior

to nodes y and x, further degrading the throughput from 2B to B.

In this paper, we propose a new MMAC protocol to resolve the two challenges in the DCC approach, composing of the following three components:(1) Control initiation-time prediction (CIP) reduces the control overhead by properly predicting the initiation time of each control process to avoid unsuccessful channel coordination; (2) Dynamic data-ﬂow control (DDC) dynamically adjusts the amount of ﬂow in each data transmission to balance the congestion in the control and data

Ctrlu,v Ctrlu,v data channels control channel data channels control channel Datau,v(2) Datau,v(2) Ctrlu,v Ctrlu,v Datau,v(3) Datau,v(3)

u

v

ch2 ch3 ch3 ch2 ch1 ch0 ch3 ch2 ch1 ch0 Fig. 1. Dedicated control channel approach.

u

v

w

z

y

x

Ctrlw,z Datax,y(1) ch3 Ctrlu,v Ctrlx,y Ctrlx,y Ctrlw,z Datau,v(3) Dataw,z(2) Datax,y(1)... ch2 ch1 ch0

(a)

u

v

x

y

{ch

1

, ch

2

}

Datau,v(2)

{ch

2

, ch

3

} {ch

1

, ch

2

, ch

3

}

{ch

1

, ch

2

, ch

3

}

(b)

(3)

channels. (3) Enhanced channel selection (ECS) improves the reusability of data channels by selecting a channel that adds the least total delay to the starting times of the transmissions at nearby nodes. The design of these components is primarily based on exploiting the release times of channels and interfaces. Hence, we named this protocol the Release-Time-Based MMAC (RTBM).

The rest of this article is organized as follows: In Section2, we compare different types of MMAC approaches and review existing protocols related to the DCC approach. Section3describes the basic operation of the RTBM protocol. The detailed design of each component is present in Section4. In Section5, we conduct a series of simulations to evaluate the perfor-mance. Concluding remarks are given in the last section.

2. MMAC approaches and related works

This section consists of two parts. First, we compare the pros and cons of different MMAC approaches. Next, existing pro-tocols related to the DCC approach are reviewed.

2.1. MMAC approaches

A variety of MMAC protocols has been proposed in the literature. According to the way of coordinating data channels

[1,2,23], existing protocols can be classiﬁed into the channel ﬁxed, receiver based, hybrid, spite control phase, dedicated control channel, and single/parallel rendezvous approaches.

In the channel fixed approach[11,12], each interface is fixed on a channel permanently or for a long period of time. If a node A wants to communicate with a neighboring node B, they must have some interfaces fixed on the same channel. Then, A can send packet (e.g. RTS/CTS/DATA) directly to B, without additional control overheads to find a common channel. Besides, since the channels are fixed, contention within each group of interfaces on the same channel can be resolved by a standard MAC (e.g. 802.11 DCF). However, the fixed structure also limits the ability of using diverse channels. The number of channels that can be used by a node is limited by the number of its interfaces. In addition, if there is no common channel shared by two adjacent nodes, their traffic has to be relay through a longer path.

In contrast, the receiver based approach allows each node to utilize diverse channels with a single interface[3,13]. Each node is speciﬁed a channel in advance. For communication, a node u can connect with any nearby node

v

by just turning its interface the channel speciﬁed to

v

. However, since nodes are always fixed on the specified channels, some control signals may lose. As shown inFig. 3(a), nodes A, B, C, and D are specified ch1, ch2, ch2, and ch3, respectively. At the beginning, node A

intents to transmit to B. So, it exchanges the RTS-CTS with B using B’s channel. However, at the moment, node C has turned its interface to ch3for transmitting to D. Thus, node C cannot be aware of the CTS from B. As a result, after the current

trans-mission, node C may content for ch2and incur a collision at B. It is the so called multi-channel hidden terminal problem[2].

Even worse, the lost signals may cause link failure. InFig. 3(b), node C is sending requests to B using B’s channel. But, node B has turned its interface to ch1so that it cannot be aware of the request from C. Thus, node C may keep sending the RTSs until

it falsely concludes that its link to B has broken. It is the so-called deafness problem[2].

The hybrid approach employs two interfaces to overcome the problems in both channel fixed and receiver based ap-proaches[23,24]. One interface is fixed on a specified channel for receiving tasks, and the other interface can be dynamically switched on the channel of the fixed interface of the intended receiver. In this way a node can utilized diverse channel via its switchable interface and keep trace of control packets via its fixed interface. Moreover, singe channels of fixed interfaces are rarely changes, a channel switching can be made immediately without any coordination. However, this approach has two drawbacks. First, although a node can utilize more diverse channels, not limited by the number of its interface, the

commu-A B C D {ch1} RTS(2) CTS(2) CTS(2) ACK(2) RTS(2) Collision DATA(2) DATA(3) time {ch2} {ch2} {ch3}

A

B

C

D

RTS(1) RTS(1) CTS(1) DATA(1) RTS(2) Drop RTS(2) RTS(2) RTS(2) time {ch2} {ch2} {ch3} {ch1}

(a) (b)

(4)

nication channel between two nodes is still ﬁxed, which is not ﬂexible when the channel of the intended receiver is highly interfered. Second, a link-layer broadcast is hard to be implemented. A node should broadcast the same message on all chan-nels to ensure the delivery.

The split control phase approach divides each beacon interval into a control phase and a data phase[14,15]. As shown inFig. 4, all nodes periodically rendezvous to a common channel in the control phase to sense carriers and coordinate channels for the subsequent transmissions in the data phase. In this approach, nodes have the most ﬂexibility to use diverse channels during the data phase. Besides, the exchange of control packets and link-layer broadcast can be easily achieved during the control phase. Nonetheless, the phase alignment relies on strict time synchronization so that it is hard to implement in practice.

The dedicated control channel approach does not require any time synchronization mechanism. With the control interface, each node can access the control channel at anytime. However, as mentioned in Section1, the throughput could be limited by the bandwidth of control channel and inﬂuenced by the selection of data channels. Besides, the dynamic channel selection means that more control overheads are required for the channel coordination. Hence, in this paper we focus on solving these challenges.

Finally, in the common rendezvous approach[16], nodes not exchanging data hop through all channels synchronously. A pair of nodes stops hopping as soon as they make an agreement for transmission and rejoin the common hopping pattern subsequently after transmission ends. In comparison with the DCC, this approach can make use of all the channels for data exchange and requires only one interface per node. However, it does not resolve the control bottleneck problem since only one pair of nodes can make an agreement at the same time. The parallel rendezvous approach[17,18]overcomes this problem by assigning different hopping sequences to nodes. In SSCH[17], each node picks multiple sequences and follows them in a time-multiplexed manner. When node A wants to talk to node B, A waits until it is on the same channel as B. The McMAC[18]

improves SSCH by allowing a sender to temporally hop to the sequence of the receiver to avoid waiting. The major problem in these rendezvous approaches is that they may incur large switching delay for channel hopping, and each node requires synchronization mechanisms to track the hopping sequence of the others. Besides, a link-layer broadcast is hard to be imple-mented in a hopping fashion.

2.2. Existing protocols for DCC approach

The concept of using separated channels or special devices (e.g. busy tones) to improve medium access control has been extensively studied in works such as[19–22], but these researches consider only one data channel, i.e. designed for single-channel MAC. The ﬁrst MMAC protocol under the DCC approach was presented in[3]and named the dynamic channel assign-ment (DCA). In this protocol, each node maintains a free channel list (FCL) to record unused data channels. As a node u intends to transmit to a node

v

, it ﬁrst sends a RTS to

v

carrying its FCL. Then, node

v

compares the received FCL with its own FCL to select a common free channel. If there is any, the selected channel will be replied to u using a CTS. Once received the CTS, node u emits a reserve-to-send (RES) to inhibit other nodes from using the same channel. Meanwhile, nodes u and

v

can start to exchange the DATA and ACK frames on the selected channel. Integration with the power control technique was proposed in[4].

Compared with the IEEE 802.11 DCF, the DCA needs an additional control frame (e.g. RES) to reserve the channel selected at the receiver’s side. To avoid such overhead, the protocol in[5]suggests that each sender can ﬁrstly propose a free channel in the RTS. If the channel is free to the receiver, the data transmission can be started immediately upon received the CTS. Otherwise, it follows the same way in[3]. A similar protocol appears in[6], where the proposed channel in the RTS will be replied by a reply-to-RTS (RRTS) that indicates whether the channel is free or not. The negotiation will continue until a common free channel is found. Nonetheless, these protocols may spend more control bandwidth if the proposed channel is not accepted by the receiver.

Another way to relieve the bottleneck problem is by using multiple control channels. Koubaa[7]showed that the number of control channels required to achieve the maximal throughput is a function of the available channels and packet size. For instance, with 12 channels and packet size of 1024 bytes, providing three control channels is optimal. Likewise, the protocol in[8]employs an extra channel for replaying ACKs to improve the channel reusability. By replying the ACK in a separated channel, a sender can be active simultaneously with its hidden terminals. Although using multiple control channels is ben-eﬁcial, coordinating on different channels could be more complicated.

The channel selection strategy in the DCA[3]is simply to ﬁnd a communicable channel. Each sender–receiver pair coor-dinates a channel that is free at the two sides. If there are multiple choices, one channel will be chose at random. The strategy was slightly improved in[9,10]. In[9], the channel with the least received power will be chosen to avoid potential interfer-ence. Similarly, in[10], the most robust channel will be selected according to the carrier-to-interference ratio. In other words,[9,10]are concerned about not only the communicability, but also the quality of the selected channel.

Ctrl(0) Data(1) Ctrl(0) Data(2)

control phase data phase control phase data phase

(5)

3. Protocol description

The RTBM is primarily based on the DCA protocol[3]. Similarly to the DCA, each sender–receiver pair has to exchange the RTS-CTS-RES sequence on the control channel to coordinate and reserve a data channel for the subsequent transmission of the DATA and ACK messages. The RTBM further incorporates with the following components to resolve the control channel bottleneck and data channel selection problems in the DCC approach:

(1) Control initial-time prediction (CIP): In the DCA[3], each sender has to initiate a control process (e.g. the RES-CTS-RES) with the intended receiver to coordinate a data channel that is free at two sides. If the coordination succeeds, the data transmission (e.g. the DATA-ACK) can be started on the selected channel. However, if the coordination fails, the expensed control bandwidth and time (including backoff timer, transmission time, inter-frame spaces, propagation delay, and processing time) are wasted. The CIP can avoid unsuccessful channel coordination by properly predicting the initiation time of each control process. The prediction will jointly consider the channels and interfaces statuses at the sender and receiver.

(2) Dynamic data-flow control: (DDC): As shown inFig. 2(b), the bottleneck problem from the common control channel would lower down the utilization of data channels. To breakthrough this limitation, an intuitive way is to expend the data flow (i.e. the number of packets to be sent) for each control process to increase the bandwidth usage[20]. However, if too many packets were transmitted with only a few control processes, the data channels could be occu-pied by some node pairs for a long period of time, which may instead incur unfairness problem to other competitors who are intended to access the data channels. Ideally, the above problems can be optimally solved by adjusting the data flow such that both the control and data channels are fully utilized. For example, inFig. 2(b), if node u sent 1.5 times of packets to node

v

by each control process, all channels can be fully exploited. However, due to the dynam-icity in wireless environments, such as the variation in network trafﬁc or topology, the optimal setting would be varied from time to time. The DDC component can dynamically adjust the amount of ﬂow in each data transmission to bal-ance the congestion in the control and data channels.

(3) Enhanced channel selection: (ECS): The selection strategy in the DCA[3]is simply to find a communicable data channel that is free to sender and receiver. If there are multiple choices, one channel will be chose at random. Succeeding works in[9,10]also consider the quality of the selected channel, but none of them concerns the influence to nearby transmissions. The ECS can improve the reusability of data channels. Each pair will cooperatively coordinate a free data channel that will add the least total delay to the starting times of potential transmissions at nearby nodes. In other words, the selected channel is not only communicable, but also has the least influence to the transmission opportu-nities of nearby nodes.

In the following, we first define the statuses and symbols used in this protocol. Next, the basic operation is described. We will focus here on how the RTBM interacts with the three components and defined statuses. The detail design of each com-ponent will be presented in the next section.

3.1. Statuses and symbols

We assume that the network has a set of orthogonal channels H ¼ fhjh ¼ 0; 1; 2; . . . ; Hg. Each node has a control interface and a data interface. The ﬁrst channel (h = 0) is for control purpose, and the remaining channels (h = 1, 2, . . . , H) can be used for data transmission. A channel (or interface) is released when it can be used for a transmission or reception. Each node u has the following statues:

ch_rel_time(u, h): the release time of the hth channel at u, h = 0, 1, . . ., H; if_rel_time(u): the release time of the data interface at u.

In addition, each node u maintains a channel release time table (CRTu) and an interface release time vector (IRVu) to record

the channels’ and interfaces’ statuses at nearby nodes. The ﬁelds CRTu(

v

, h) and IRVu(

v

), respectively, keep track of the latest

statuses about the ch_rel_time(

v

, h) and if_rel_time(

v

) for each neighboring node

v

. Moreover, a separate queue is created for each 1-hop destination. The purpose is to avoid head-of-line blocking if two or more packets need to be sent for the same node. Other time symbols that will be used in our protocol are listed inTable 1.

3.2. Basic operation

The basic operation of the RTBM is illustrated inFig. 5. Consider node u. Let us see how node u operates with other nodes in this protocol. In the beginning, node u creates a separate queue for nodes a and

_v

. To avoid starvation, when some packets arrived in queues the destination with the oldest packet will be chosen as the target. Assume that node u has decided to transmit to node

v

. First of all, it applies the CIP to predict a control initiation time for

v

, denoted as ctrl_ini_time(u,

v

). The

(6)

time indicates when node u can successfully initiate a control process with

v

. As shown inFig. 5, ctrl_ini_time(u,

v

) = t2. The

prediction process will continue before the control process is actually started.

At ctrl_ini_time(u,

v

), node u starts the following control process. It ﬁrst applies the DDC to determine the number of data frames to be sent for

v

, denoted as Ku,v. According to the Ku,v, the network allocation vector required to exchange the DATA

and ACK messages can be set as

NAVDATA¼

XKu;v i¼1

ðTDATAiþ SIFSÞ þ TACKþ 2

s

;

where TDATAiis the time to transmit the ith data packet in the queue for

v

. As shown inFig. 5, Ku,v= 3 and NAVDATA= t10t6. So,

node u will transmit the ﬁrst three packets to

v

during t6to t10. Next, node u applies the ECS to evaluate the cost for

trans-mitting on each data channel h. The cost, denoted asDu(h), is the total increment to the starting times of possible

transmis-sions at u’s nearby nodes as if node u transmitted on channel h for a period of NAVDATA. Then, following the IEEE 802.11

backoff mechanism, if there was no carrier on the control channel in a DIFS plus the BF, node u sends a RTS to

v

, containing the NAVDATAand theDu(h), for any h = 1, 2, . . . , H.

Once received the RTS, node

v

also applies the ECS to evaluate the costDv(h), for each data channel h, i.e. the total

incre-ment to the starting times of possible transmissions at v’s nearby nodes as if node

v

transmitted on channel h for a period of NAVDATA

s

. Combining the costs evaluated from the two sides, the total cost for communicating between u and

v

on a

chan-nel h, denoted asDu,v(h), is the sum of theDu(h) andDv(h). The data channel that will be released to u and

v

and has the least Du,v(h) will be selected. If such a channel can be found, denoted as h⁄, node

v

has to update the following statues for the

forth-coming data transmission on h⁄

such that

if rel timeð

v

Þ ¼ ch rel timeð

v

;h

Þ ¼ Tcurrþ 2SIFS þ TCTSþ NAVDATA:

For example, at Tcurr= t4, node

v

sets if_rel_time(

v

) = t9, and ch_rel_time(

v

, h⁄) = ch_rel_time(

v

, 2) = t9. Besides, node

v

sets two

timers as follows in its CTS.

Table 1

Time symbols used in the RTBM protocol.

Symbols Meanings

Tcurr Current time of a node

TDATAi Time to transmit the i-th data packet in a queue

TRTS Time to transmit a RTS frame

TCTS Time to transmit a CTS frame

TRES Time to transmit a RES frame

TACK Time to transmit an ACK frame

BF Remaining backoff time

s Maximal propagation delay

a

u

v

b

D NAVDATA(2) BF 0 1 2 NAVDATA(2) 3 NAVDATA(3) NAVDATA(2) NAVDATA(1) NAVDATA(3) NAVDATA(1) RTS CTSSRES NAVCTRL RTS S DATA2 S DATA3 RTS S CTS RES RES

DATA1 DATA2 DATA3SACK

NAVDATA(2) CTS 0 1 2 3 0 1 2 3 0 1 2 3 a ... a v ... v

h*

Data Transmission Time

t

2 ctrl_ini_time(u, v) ACK

h*

BF: Backoff S: SIFS D: DIFS Control Process Prediction Process DATA1 (Ku,v = 3)

t

1

t

4

t

5

t

7

t

8

t

9

t

10

t

0

t

3

t

6

(7)

if durationð

v

Þ ¼ maxf0; if rel timeð

v

Þ Tcurr ðSIFS þ TCTSþ

s

Þg;

ch durationð

v

;hÞ ¼ maxf0; ch rel timeð

v

;hÞ Tcurr ðSIFS þ TCTSþ

s

Þg; h ¼ 1; 2; . . . ; H:

The if durationð

v

Þðch durationð

v

;hÞÞ indicates the amount of time the data interface (data channel h) of node

v

will be re-served. For example, at Tcurr= t4, node

v

sets

if durationð

v

Þ ¼ maxf0; t9 t4 ðSIFS þ TCTSþ

s

Þg ¼ t9 t5;

ch durationð

v

;1Þ ¼ maxf0; t8 t4 ðSIFS þ TCTSþ

s

Þg ¼ t8 t5

ch durationð

v

;2Þ ¼ maxf0; t9 t4 ðSIF þ TCTSþ

s

Þg ¼ t9 t5;

ch durationð

v

;3Þ ¼ maxf0; t1 t4 ðSIFS þ TCTSþ

s

Þg ¼ 0: After waiting a SIFS, node

v

replies a CTS to u, containing the h⁄

(if there is any), if_duration(

v

), and ch_duration(

v

, h), for any h = 1, 2, . . . , H.

Once received the CTS, if a channel h⁄_{was indicated, node u also updates}

if rel timeðuÞ ¼ ch rel timeðu; h

Þ ¼ Tcurrþ ch durationð

v

;hÞ þ

s

;

for the forthcoming data transmission on h⁄_{and sets two timers as follows in its RES.}

if durationðuÞ ¼ maxf0; if rel timeðuÞ Tcurr ðSIFS þ TRESþ

s

Þg;

ch durationðu; hÞ ¼ maxf0; ch rel timeðu; hÞ Tcurr ðSIFS þ TRESþ

s

Þg; h ¼ 1; 2; . . . ; H:

After waiting a SIFS, the h⁄_{is rebroadcasted to nearby nodes along with a RES to reserve the channel. Meanwhile, node u can}

start to send Ku,vpackets to node

v

via channel h⁄. Finally, node

v

replies an ACK to node u at the end of the data transmission.

On the other hand, once an irrelevant node x (e.g. nodes a and b) received the CTS or RES from a node y (e.g. nodes u and

v

), if a channel, i.e. h⁄_{, was indicated inside, node x has to inhibit itself from using the same data channel by setting}

ch rel timeðx; hÞ ¼ maxfch rel timeðx; hÞ; Tcurrþ ch durationðy; h

Þg:

Note that the NAVDATAhas been implicated in both the ch_duration(

v

, h⁄) and ch_duration(u, h⁄). Hence, it is neither in the CTS

nor in the RES.

Moreover, to prevent nodes from disrupting the control process between u and

v

, an extra NAV is employed on the control channel. More precisely, once an irrelevant node x (e.g. node a) received the RTS from u, it has to block its control channel for a period of time by setting

ch rel timeðx; 0Þ ¼ Tcurrþ NAVCTRL;

where NAVCTRL= 2SIFS+ TCTS+ TRES+ 2

s

, specifying the amount of time the control channel will be for the RTS-CTS-RES

dialogue.

Lastly, to maintain the statuses of nearby nodes, once a node x (e.g. nodes a, b, u, and

v

) receives a CTS or RES from a node y (e.g. nodes u and

v

), it has to update its channel release time table (CRTx) and its interface release time vector (IRVx) as follows.

IRVxðVÞ ¼ Tcurrþ if durationðyÞ;

CRTxðy; hÞ ¼ Tcurrþ ch durationðy; hÞ; for any h ¼ 1; 2; . . . ; H:

The above processes are in normal situation which could be interrupted in some circumstances. First, node u detected some control signals before the BF expires. In this case, the RTS will not be sent out by u. Second, the RTS or CTS was collided or the control channel of

v

was blocked by a NAVCTRL. In this case, node u will not receive the CTS from

v

within the timeout

period of SIFS + TCTS+ 2

s

. Third, there was no data channel h⁄in indicated in the CTS from

v

. In this case, the data

transmis-sion cannot be started by u. When some of these cases happened, the following process should be done: If the retry limited is not reached, node u has to terminate the current control process, apply again the CIP, and restart the next attempt at the new ctrl_ini_time(u,

v

); otherwise, node u has to abort any process with

v

an select a new target from its queues.

4. Components design

In this section, we present the detail design of the three components in our protocol.

4.1. Control initiation-time prediction

The CIP is designed to reduce unsuccessful channel coordination that would incur redundant control overhead. It is achieved by properly predicting the initiation time of each control process, based on the information about the release times

(8)

of channels and interfaces at sender and receiver. To explain the idea, let us see the example inFig. 6(a).1_{In the beginning,}

node u has some packets for

v

at t0. At the moment, the release times of ch1, ch2, and ch3at u and

v

are (t3, t1, t10) and (t14, t8, t17),

respectively. We know that two nodes can communicate with each other only if at least one data channel has been released to both of them. Therefore, node u cannot send any data frame to

v

before t8= min{max{t3, t14}, max{t1, t8}, max{t10, t17}}, i.e., the

release time of ch2. Moreover, no data frame can be transmitted until the data interfaces of both u and

v

have been released.

With the two considerations, we deﬁne the link release time of u and

_v

as

u

v

_NAV DATA(1)

0

1

2

3

0

1

2

3 t

0

t

3 NAVDATA(1)

t

1

pre_ctrl

D BF RTS

CTS

S

RES

DATA ...

NAVDATA(3)

Data transmission (3)

NAVCTRL

t

8

t

10

t

12

Control initiation point

Prediction Process

Control Process

Data Transmission

t

17

t

2 NAVDATA(2) NAVDATA(2)

t

5

RTS

S

CTS

RES

DATA ...

h* = 2

t

14

(a)

u

v

_NAV DATA(1)

0

1

2

3

0

1

2

3 t

0 NAVCTRL

RTS

t

3 NAVDATA(1) Defer

pre_ctrl

t

5

New NAVDATA(2)

pre_ctrl

D BF RTS

CTS

S

RES

RTS

S

CTS

RES

DATA ...

CTS

NAVDATA(3)

Data transmission (3)

Defer NAVCTRL

t

4

t

6

t

7

t

8

t

10

t

11

t

14

t

16

Prediction Process

Control Process

Data Transmission

t

17

t

18 NAVDATA(2) NAVDATA(2) h* = 1

(b)

u

v

_NAV DATA(1)

0

1

2

3

0

1

2

3 t

0 NAVCTRL

RTS

t

3 NAVDATA(1)

New NAVDATA(2)

pre_ctrl

D BF RTS

CTS

RTS

S

CTS

NAVDATA(3)

Data transmission (3)

NAVCTRL

t

8

t

10

t

11

t

14

Prediction Process

Control Process

t

17

t

18 NAVDATA(2)

NAVDATA(2)

New NAVDATA(1)

CTS

t

9

t

7

Must fail Possibly success

t

15

No h*

Defer

pre_ctrl

t

13

(c)

Fig. 6. Control initiation prediction process (a) without deferral, (b) with deferral and (c) invalid scenario.

1

(9)

link rel timeðu;

v

Þ ¼ max min h¼1;...;H max ch rel timeðu; hÞ; CRTuð

v

;hÞ ; if rel timeðuÞ; IRVuð

v

Þ 8 > > > < > > > : 9 > > > = > > > ; ;

which means that all resources required for communicating on the virtual link between u and

v

will be released at link_rel_-time(u,

v

). InFig. 6(a), the link release time of u and

v

at t0is t10= max{t8, t10, t0}. Clearly, it is the earliest possible time that u

can start a data transmission with

v

.

With the observation, now we discuss when node u can initiate the control process with

v

. In the DCC approach, since control frames (e.g. RTS/CTS/RES) and data frames (e.g. DATA/ACK) are exchanged using different interfaces and channels, a control process can be started earlier before the virtual link (data channels and data interfaces) is released. Besides, the data frames can be sent out once node u has received the CTS from

v

for a SIFS. Therefore, if node u intends to transmit at the earliest time t10, it should initiate the control process in advance at t10 (DIFS + BF + TRTS+ TCTS+ 2SIFS + 2

s

). However,

the backoff timer BF should be removed from the composition of (DIFS + BF + TRTS+ TCTS+ 2SIFS + 2

s

). Otherwise, other

send-ers waiting for the same resource (u’s data interface) may send their RTSs at the same time with u’s RTS, and thus incur col-lision. In addition, node u cannot perform any control process until the control channel is released. Combining these facts, the control initiation time of u and

v

is deﬁned as

ctrl ini timeðu;

v

Þ ¼ max link rel timeðu;

v

Þ pre ctrl;

ch rel timeðu; 0Þ

;

where pre_ctrl = DIFS + TRTS+ TCTS+ 2SIFS + 2

s

, denoting the preprocessing time. In this example, node u can apply this

func-tion at t0and predict that the initiation time is t5= max{t10 pre_ctrl, t2}.

Note that, before the control process is actually started, the predicted time could be updated if the ch_rel_time(u, 0) or link_rel_time(u,

v

) is changed. When such event occurs, the control process is deferred to the updated initiation time. For example, inFig. 6(b), node u received a RTS at t4that changes the ch_rel_time(u, 0) to t7. So, the ctrl_ini_time(u,

v

) is deferred

from t5to t7. Furthermore, node u received a CTS at t6, indicating that ch2will be released at t18. Hence, the link_rel_time(u,

v

)

is changed from t10to t14. Accordingly, the ctrl_ini_time(u,

v

) is further deferred from t7to t11.

In addition, since the records in the CRTuand IRVuare not always the newest, the predicted time could be invalided. As

shown inFig. 6(c), node

v

received a CTS with an updated ch_duration(

v

, 1) at t9and the ch_rel_time(

v

,1) is changed

accord-ingly. Normally, the control initiation time should be deferred from t11to t13to response to the change. But, since node

v

does

not send any control frame during t9to t11, the change is invisible to u. As a result, node u will still initiate the control process

at t11and the control process may fail. However, the CIP does ensure that any control process initiated before t11must fail,

because for any channel h (or interface), if it is not released at CRTu(

v

, h) (or IRVu(

v

)) to u, it is also not released at

ch_rel_ti-me(

v

, h) (or if_rel_time(

v

)) to

v

. Thus, the CIP can help nodes to avoid unsuccessful channel coordination.

4.2. Dynamic data-ﬂow control

The DDC can dynamically adjust the number of data packets being sent in each data transmission to balance the conges-tion in the control and data channels. The DCC maintains a variable Ku,vfor each 1-hop node

v

specifying the number of data

packets that will be sent in the next transmission from nodes u to

_v

. Ku,vis initiated as 1 and will be dynamically adjusted

according to the idle statuses on the control and data interfaces.

Take a look atFig. 7to explain this idea. There are three sender–receiver pairs of {u,

v

}, {x, y}, and {w, z} with data ﬂows sustained during [t0, t3], [t1, t3], and [t1, t2], respectively. Besides, nodes u and

v

are in the interference range of nodes x and w,

v

u

Ctrl

u,v

Ctrl

x,y

Ctrl

u,v

Ctrl

u,v

idle

Ctrl

u,v

Ctrl

u,v

Data

u,v

Idle

Data

u,v

Data

u,v

Data

u,v

Ctrl

x,y

Ctrl

x,y

Ctrl

x,y

….

Ctrl

u,v

Ctrl

w,z

Ctrl

u,v

Ctrl

u,v

Ctrl

u,v

Ctrl

u,v

Data

u,v

Data

u,v

Data

u,v

Data

u,v

Ctrl

w,z

….

t

1

t

2

Ctrl

l

x,yy

Ctrlw,z

Datau,v

Ctrl

l

xx yy,

Datau,v

Ctrlw,z

Ctrl

x,yy

Ctrl

x,yyx

Dat

Expend K

u,v

= 1 + 2 = 3

Shrink K

u,v

= 3 – 1 = 2

t

0

Initiate K

u,v

= 1

u

v

w

z

y

t

1 ~

t

3

x

t

0 ~

t

3

t

1 ~

t

2 control interface data interface control interface data interface

t

3

+

_–

(10)

receptively. Assuming that the time required for a control process is equal to the time required for sending one data packet, we show how DDC adjusts Ku,v. In the beginning, Ku,v= 1. Thus, node u sends one data packet to

v

. Then, node u intends to

send the next packet to

v

. However, at this moment, the control processes for other two ﬂows have started, so node u cannot initiate a control process immediately with

v

. Consequently, u’s data interface experiences a period of idle status before the next data transmission starts. In order to mitigate such inﬂuence from control channel, the DDC expends Ku,vin proportion to

the idle time experienced from u’s data interface (i.e. Ku,v= 1 + 2 = 3) to increase the utilization of data channels for the

sub-sequent data transmission to

v

. As shown in this example, by the end of the second data transmission, the next data trans-mission can be started immediately without any idling. Nonetheless, during the third data transtrans-mission, since the data ﬂow between w and z has ﬁnished, the control channel becomes less congested at

v

, resulting in a period of idle status in u’s con-trol interface before the next concon-trol process starts. In order to reﬂect such fact, the DCC shrinks Ku,vin proportion to the idle

time experimented from u’s control interface (i.e. Ku,v= 3 1 = 2). Finally, Ku,vconverges to 2 and the congestion in control

and data channels are balanced. The process will continue if any further change occurred.

In summary, Ku,vis adjusted according to two idle timers: the data interface idle time, denoted as dif_idle_time(u,

v

), and

the control interface idle time, denoted as cif_idle_time(u,

v

). Therefore, below we give a more realistic example to show how an idle status occurs in the RTBM. Then, the two idle timers and adjusting rule are formally deﬁned. Lastly, we provide an online algorithm for efﬁcient maintenance.

InFig. 8(a), node u has some packets for

v

at t0. At the moment, node u ﬁnds that the link release time

link_rel_ti-me(u,

v

) = t4and control initial time ctrl_rel_time(u,

v

) = t4 pre_ctrl = t2. Ideally, if there is no contention before t2, the data

transmission can start at t5= t2+ pre_ctrl + BF (recall that BF is not in the pre_ctrl). However, at t1an irrelevant RTS is

de-tected, so node u has to update ctrl_ini_time(u,

v

) = max{t4 pre_ctrl, t1+ NAVCTRL} = max{t2, t3} = t3. Consequently, the data

transmission should be deferred from t5to t7= t3+ pre_ctrl + BF. The deferral will result in a period of idle status from t5

to t7on u’s data interface. Therefore, we can estimate that dif_dile_time(u,

v

) = t7 t5at this time point.

Then, the control process starts at t3(seeFig. 7(b)). During the BF, another RTS is detected, so node u has to suspend the

current process and update the new control initiation time to t8. Consequently, the data transmission should be further

de-ferred from t7to t11= t8+ pre_ctrl + BF, resulting in a longer period of idle status on u’s data interface from [t5, t7] to [t5, t11].

However, during the sub period [t6, t9], node u cannot transmit any data to node

v

even if the control channel is not

con-gested, since all data channels (ch1and ch3of node u and ch2of node

v

) are blocked by some NAVs in this time interval. Thus,

the dif_idle_time(u,

v

) should be set as dif_idle_time(u,

v

) = (t11 t5) (t9 t6) to reﬂect the deferral purely incurred by the

control channel congestion. We call the time interval [t6, t9] the non-idle time.

After a DIFS and BF, node u sends a RTS and waits for the CTS from

v

(seeFig. 8(c)). However, before the RTS arrived, the control channel of

v

has been blocked by another RTS so that u cannot obtain any reply from

v

before the end of the time out period at t10. As a result, the starting time of the data transmission is further deferred from t11to t12. That is, the

dif_idle_-time(u,

v

) should be updated as (t12 t5) (t9 t6). This example shows that the idle status of u’s data interface could be

incurred by the control congestion at both node u and node

v

.

Continuing the example, inFig. 8(d), the data transmission starts at t12and ends at t17= t12+ NAVDATA. During this period,

the control interface of u is released after sending the RES and reserved for the next control process after t16= t17 pre_ctrl.

In addition, the control channel is contended during the sub-period from t14to t15. Therefore, the control interface idle time

is the sum of the two periods from t13to t14and from t15to t16, i.e. cif_idle_time(u,

v

) = (t16 t15) + (t14 t13).

Now, we formally deﬁne the two idle timers based on the above observations. Let data_tx_time⁄

(u, v) and data_tx_ti-me(u, v) stand for the earliest and the actual starting times of a data transmission from u to

v

, respectively. At any time t, the data interface of u is idle if and only if

(i) data_tx_time⁄_{(u, v) 6 t < data_tx_time(u, v);}

(ii) link_rel_time(u, v) < t.

For a transmission from u to

v

, dif_idle_time(u, v) is the total time satisfying (i) and (ii). InFig. 8, data_tx_time⁄

(u, v) = t5, and

data_tx_time(u, v) = t7, t11, and t12, respectively, inFigs. 8(a)–(c). The period of time not satisfying (ii) is [t6, t9], i.e. the

non-idle time. Similarly, at any time t, the control interface of u is non-idle if and only if (i) data_tx_time(u,

v

) + TRES+

s

< t < data_tx_time(u,

v

) + NAVDATA pre_ctrl;

(ii) ch_rel_time(u, 0) Ttype< t, where type is the type of the received control frame.

For a transmission from u to

v

, the cif_idle_time(u,

v

) is the total time satisfying (iii) and (iv).

With the two idle timers, at the start point of each control process (i.e. t3, t8, and t10), Ku,vcan be updated as

Ku;v¼ min

16k6Q v

Xk

i¼1

ðTDATAiþ SIFSÞ P Lu;vþ dif dile timeðu;

v

Þ

( )

;

where Qvis the number of data packets remaining for

v

, and Lu,vis the time of the previous data transmission. As shown in Fig. 8(c), Ku,v= 3 at t10, since

(11)

u

RTS NAVCTRL NAVDATA(3) NAVDATA(2) NAVDATA(1)

v

NAVDATA(3) NAVDATA(2) pre_ctrl pre_ctrl + BF

New NAVDATA(1)

pre_ctrl + BF 0 1 2 3 0 1 2 3 idle t0 t1 t2 t4 t5 t7 t3 deffer S DATA2 [t5, t7] Ku,v = 2 S DATA1 Lu,v

(a)

u

v

NAVDATA(3) NAVDATA(2) pre_ctrl pre_ctrl + BF S D BF_RTS _NAV CTRL

CTS New NAVDATA(1)

idle non-idle pre_ctrl pre_ctrl + BF 0 1 2 3 0 1 2 3 idle t0 t3 t4 t5 t6 t8 t10 t12 deffer S DATA2 [t9, t12] [t5, t6] Ku,v = 2 S DATA1 Lu,v

(b)

u

v

NAVDATA(3) NAVDATA(2) pre_ctrl pre_ctrl + BF S D BF_RTS _NAV CTRL

New NAVDATA(1)

idle non-idle D BF_RTS RTS NAVRTS CTRL D BF RTS RTS S CTS CTS S RES RES DATA idle timeout pre_ctrl + BF DATA 0 1 2 3 0 1 2 3 t0 t4 t3 t5 t6 t8 t10 t13 t11 deffer S

DATA2 DATA3 S Ku,v= 3

[t5, t6] [t10, t13] t9 S DATA1 Lu,v

(c)

u

v

RES RES S

DATA1 DATA2 S DATA3 ACK

DATA1 DATA2 DATA3 SACK

RTS NAVCTRL

RTSNAVCTRL CTS

non idle idle

idle t12 t13 t14 Ttype _T type t17 t15 S DATA4 [t13, t14] [t15, t16] Ku,v = 2 0 1 2 3 0 1 2 3 D BF pre_ctrl …. …. RES + Ttype t16 Lu,v S DATA5

(d)

CTS

(12)

On the other hand, at the end point of each data transmission (i.e. t17), Ku,vcan be updated

Ku;v¼ max

16k6Q v

Xk

i¼1

ðTDATAiþ SIFSÞ < Lu;v cif dile timeðu;

v

Þ

( )

:

Note that Lu,vshould be updated according to the time of the previous data transmission when used. As shown inFig. 8(d),

Lu,v= t17 t12, and Ku,v= 2 since

ðTDATA4þ SIFSÞ þ ðTDATA5þ SIFSÞ < Lu;v ðt16 t15Þ þ ðt14 t13Þ:

In accordant with the above deﬁnitions, an algorithm is presented below to maintain the Ku,v. Additional time symbols

used in this algorithm are listed inTable 2. The corresponding values forFig. 8are shown inTable 3. The algorithm is de-signed in an online fashion and takes only constant time in each step. Thus, it is very efﬁcient and practical.

Online algorithm:DDC Component Initial:

Ku,v= 1;Lu,v=TDATAi+SIFS + TACK+ 2

s

;

Whenever node v is chosen as a target at Tcurr:

ctrl_ini_time⁄_(u,

_v

_{) = max{T}

curr,link_rel_time(u,

v

) pre_ctrl};

data_tx_time⁄

(u,

v

) =ctrl_ini_time⁄

(u,

v

) +pre_ctrl + BF; dif_nid_end(u,

v

) =data_tx_time⁄_(u,

_v

_);

dif_nid_time(u,

v

) = 0; Before ctrl_ini_time(u, v):

Once thelink_rel_time(u,

v

) is deferred atTcurr, update

dif_nid_time(u,

v

) =dif_nid_time(u,

v

) +link_rel_time(u,

v

) max{Tcurr,dif_nid_end(u,

v

)};

dif_nid_end(u,

v

) = max{data_tx_time⁄_(u,

_v

_),_{link_rel_time(u,}

_v

_)};

At ctrl_ini_time(u, v):

data_tx_time(u,

v

) =ctrl_ini_time(u) + pre_ctrl + BF; dif_idle_time(u,

v

) =data_tx_time(u,

v

) data_tx_time⁄

(u,

v

) dif_nid_time(u,

v

); Ku;v¼ min16k6Q vfPki¼1ðTDATAiþ SIFSÞ P Lu;vþ dif dile timeðu;

v

Þg;

At data_tx_time(u, v):

cif_nid_time(u,

v

) = 0;

cif_nid_end(u,

v

) =data_tx_time(u,

v

) +TRES+

s

;

Before data_tx_time(u, v) + NAVDATA pre_ctrl:

Once thech_rel_time(u, 0) is deferred at Tcurr, update

cif_nid_time(u,

v

) =cif_nid_time(u,

v

) +ch_rel_time(u, 0) max{Tcurr Ttype,cif_nid_end(u,

v

)};

cif_nid_end(u,

v

) = max{data_tx_time(u,

v

) +

r

res,ch_rel_time(u, 0)};

At data_tx_time(u, v) + NAVDATA pre_ctrl:

cif_idle_time(u,

v

) =NAVDATA pre_ctrl cif_nid_time(u,

v

);

Lu;v¼Pi¼1Ku;vðTDATAiþ SIFSÞ þ TACKþ 2

s

;

Ku;v¼ max16k6Q vfPki¼1ðTDATAiþ SIFSÞ < Lu;v dif dile timeðu;

v

Þg;

4.3. Enhanced channel selection strategy

The ECS aims at improving the reusability of data channels. The main idea is based on exploiting the release times of chan-nels and interfaces at neighboring nodes to select a free data channel that will cause the least inﬂuence to nearby transmissions.

(13)

The concept is shown inFig. 9. Nodes a and c are in the interference range of node u, and nodes b and d are in the inter-ference range of node

v

. According to the speciﬁed NAVs, nodes a, b, c, and d cannot transmit to any other node, respectively, before t6, t9, t2, and t7, since prior to these time points, there is neither an interface nor a channel released (note that the

interface of node d will be released by t7). In other words, the earliest possible time to start a transmission from a, b, c,

and d are t6, t9, t2, and t7, respectively. Assume that nodes u and

v

have decided to communicate on ch1. See what happen

to nearby nodes. Since ch1is not the ﬁrst channel released to node a, node a can still transmit at t6. Likewise, the earliest

possible starting time of node d remains t7. However, to nodes c and d, since ch1is no longer the ﬁrst channel released to

them, they cannot start any transmission before ch2and ch3 are released to them at t8and t9, respectively. As a result,

the earliest possible starting times of b and c are increased (postponed). Our goal is to coordinate a data channel that is

Table 2

Time symbols in the online algorithm of the DDC component.

Status Meaning

ctrl_ini_time⁄

(u,v) Earliest control initiation time withv

dif_nid_time(u,v) Non-idle time of u’s data interface before a data transmission tov

dif_nid_end(u,v) End point of the non-idle status of u’s data interface before a data transmission tov cif_nid_time(u,v) Non-idle time of u’s control interface during a data transmission tov

Table 3

Corresponding values of the used statues forFig. 8. ctrl_ini_time⁄ (u,v); ctrl_ini_time(u,v) data_tx_time⁄ (u,v); data_tx_time(u,v) dif_nid_time(u,v); cif_nid_time(u,v) dif_nid_end(u,v); cif_nid_end(u,v) dif_idle_time(u,v) cif_nid_time(u,v) Ku,v t2 t5 0 t5 0 1 t3 t7 0 t5 (t7 t5) 2 t8 t11 (t9 t6) t9 (t11 t5) (t9 t6) 2 t9 t12 (t9 t6) t9 (t12 t5) (t9 t6) 3 t17 – (t15 t14) t15 (t16 t13) (t15 t14) 2 NAVDATA(1) NAVDATA(3) NAVDATA(2) NAVDATA(3) NAVDATA(2) D BF RTS RTS S CTS CTSSRES RES NAVCTRL NAVDATA(3) NAVDATA(2) NAVDATA(1) NAVDATA(2) NAVDATA(1) NAVDATA(1) NAVCTRL RTS RTS CTS CTS

c

a

u

v

b

d

ACK new NAVDATA(1) new NAVDATA(1) new NAVDATA(1) new NAVDATA(1)

DATA S DATA S DATA

DATA DATA DATA S

RES

Δ

u

(c,1)

Data transmission to other node

Δ

v(b,1)

σ

res

σ

cts 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3 ACK

t

1

t

2

t

3

t

4

t

5

t

6

t

7

t

8

t

9

t

10

t

11 Time

(14)

not only free to the sender and receiver themselves, but also adds the least total delay to the starting times of possible trans-missions at nearby nodes.

Now, we formally describe the ECS below. Consider a sender u and a receiver

v

. As the control process is initiated at ctrl_i-ni_time(u,

v

), node u ﬁrstly identiﬁes a list of data channels that will be released to itself at the expected starting time of the transmission to

v

as follows.

FCLðuÞ ¼ fh

H j ch rel timeðu; hÞ 6 ctrl ini timeðu;

v

Þ þ pre ctrl þ BFg:

Note that by deﬁnition of the CIP, FCL(u) must be non-empty at ctrl_ini_time(u,

v

). In addition, let Nudenote the set of nodes

in u’s interference range. For each w

e

Nu {

v

}, node u calculates the time that at least one data channel will be released to w

as

CRuðwÞ ¼ minfCRTuðw; hÞj h

Hg:

The CRu(w) is called the critical channel release time of w, and the ﬁrst data channel released to w is called the critical channel

of w. Combining with the interface release time of w in IRVu, we deﬁne

NRuðwÞ ¼ maxfCRuðwÞ; IRVuðwÞg:

It is called the node release time of w. Clearly, node w cannot start any transmission before NRu(w).

Next, node u evaluates the cost for transmitting on each h

e

FCL(u). For each w

e

Nu {

v

} and h

e

FCL(u), if nodes decided

to transmit on channel h for a period of NAVDATA, the CRu(w) could be enlarged (at least equally), and the new critical release

time of w can be formulated as

CRþ

uðwjhÞ ¼ min

max CRTuðw; hÞ;

Tcurrþ ðpre ctrl þ BFÞ þ NAVDATA

; min CRT uðw; h0Þjh0

H fhg 8 > < > : 9 > = > ;:

The above equation indicates that the original CRu(w) could be replaced by the release time of another channel h0

e

H {h},

if the release time of the original critical channel of w is enlarged so that it is no longer critical to w. As shown inFig. 9, at t1,

CRu(c) = t2, but CRþu(c|1) = t8The gap between t2and t8is due to the fact that the critical channel of c will be altered from ch1

to ch2if u transmits on ch1. Similarly, the corresponding node release time of w can be wrote as

NRþ

uðwjhÞ ¼ maxfCR

þ

uðwjhÞ; IRVuðwÞg:

Using these terms, the increment to the node release time of w resulted from transmitting on channel h can be charac-terized as

D

uðw; hÞ ¼ maxfNRþuðwjhÞ; Tcurrþ

r

resg maxfNRuðwÞ; Tcurrþ

r

resg;

where

r

res= pre_ctrl + BF + TRTS+

s

, denoting the duration before other nodes can receive the RES from u. Notice that the Du(w, h) neglects the increment before ctrl_ini_time(u,

v

) +

r

res, since the transmission is not inﬂuential to w before the

RES is received by w. As shown inFig. 9, although NRu(c) = CRu(c) = t2and NRþu (c|1) = CR þ

u(c|1) = t8, since the RES will arrive

at t5, theDu(c, 1) is (t8 t5) instead of (t8 t2). Accordingly, if node u transmits on channel h, the total increment to the nodes

release time of all neighboring nodes can be deﬁned by

D

uðhÞ ¼

X

wNufvg

D

uðw; hÞ:

TheDu(h) will be sent to

v

along with a RTS frame for any h

e

FCL(u).

When node

v

received the RTS, it performs the same evaluation for each h

e

FCL(

v

) \ FCL(u) and w

e

Nv {u} Nu, where FCLð

v

Þ ¼ fh

Hjch rel timeð

v

;hÞ 6 Tcurrþ 2SIFS þ TCTSþ

s

g:

That is, node

v

calculates

CRþ_vðwjhÞ ¼ min max

CRTvðw; hÞ;

Tcurrþ ð

r

ctsþ SIFSÞ þ ðNAVDATA

s

Þ

; min CRT vðw; h0Þjh0

H fhg 8 > < > : 9 > = > ;;

D

_vðw; hÞ ¼ maxfNRþ_vðwjhÞ; Tcurrþ

r

ctsg maxfNRvðwÞ; Tcurrþ

r

ctsg; and

D

vðhÞ ¼ X

wNv fugNu

D

vðw; hÞ;

(15)

Then, combining the transmission costs from the two sides, the total cost for communicating between u and

v

on a chan-nel h can be deﬁned as

D

u;vðhÞ ¼

D

uðhÞ þ

D

vðhÞ:

The Du,v(h) is the total increment to the node release time of all neighbors of u and/or

v

. In Fig. 9, Du,v(1) =Du(1) +Dv(1) =Du(a, 1) +Du(c, 1) +Dv(b, 1) +Dv(d, 1) = (t5 t5) + (t8 t5) + (t8 t10) + (t7 t7) = (t8 t5) + (t8 t10).

=Du(a, 1) +Du(c, 1) +Dv(b, 1) +Dv(d, 1) = (t5 t5) + (t8 t5) + (t8 t10) + (t7 t7) = (t8 t5) + (t8 t10). Similarly, we can ﬁnd

theDu,v(2) andDu,v(3). Finally, a channel h

e

FCL(

v

) \ FCL(u) that has the leastDu,v(h) will be chosen as the communication

channel, i.e. the h⁄_{. The selected h}⁄_{will be sent back to u using the CTS. By deﬁnition, the h}⁄_{will be released to both u and}

_v

and has the least total increment to the node release times (starting times of possible transmissions) of potentially interfered nodes.

5. Simulations

In this section, we conduct simulations using the ns2 simulator. In order to evaluate how much performance gain each of the three components obtains, we have implemented the following versions for the RTBM:

RTBM (CIP) consists of CIP only, has no ﬂow control (i.e. Ku,v= 1), and follows the random channel selection strategy in[3].

RTBM (CIP + DDC) is akin to the ﬁrst version except that DDC is applied. RTBM (CIP + DDC + ECS) employs all designed components.

Note that DDC cannot be applied without CIP, since Ku,vdepends on the link release and control initiation times updated from

CIP. Besides, if Ku,vwas always ﬁxed on 1, the discrepancy between different data channels h’s would be insigniﬁcant in terms

of their communication costsDu,v(h)’s. Hence, we do not individually test DDC and/or ECS for the RTBM.

In addition, due to transmission failures or delays in updating control messages, the values stored in CRTuand IRVucould

be stale or incomplete. The inaccuracy may lead to a series of invalid decisions in the RTBM (as shown inFig. 6(c)). For this reason, we provide an ideal version, denoted as RTBM⁄_{(CIP + DDC + ECS), where each node can directly access the information}

in its neighbors, to show how the performance degrades due to inaccurate information.

On the other hand, we compare the RTBM with the representative DCC-based protocol (DCA) in[3]and the parallel ren-dezvous protocol (McMAC) in[18]. The primary goal of McMAC is also to overcome the control bottleneck problem. The dif-ference is that McMAC disperses control trafﬁc across all available channels by allowing a sender switch to the hopping sequence of the intended receiver with a probability p. Here, we set p as the default setting in[18]. For all of our evaluations, the IEEE 802.11 DCF serves as the baseline protocol.

For each network under test, we generate 100 static nodes uniformly distributed on a 1500 m 1500 m region. Each node is equipped with two interfaces, each with a default transmission range of 250 m. The interference range is assumed to be twice the transmission range. On the other hand, we provide 12 orthogonal channels. One of them is used for control pur-poses and the others are used for data transmission. The default channel bit rate is 11 Mbps.

On top of each generated network, we consider the throughput under two circumstances. In single-hop communication, we establish UDP flows with a variable bit rate over 200 random node pairs (i.e. each node communicates with four 1-hop nodes on average). Each communication pair is confined within the transmission range of each other. This case is intended to eval-uate the link-layer performance. In multi-hop communication, we establish UDP flows with a constant bit rate over 20 ran-domly chosen node pairs. All sources and destinations are distinct nodes. Each packet is forwarded along with a shortest path in terms of the hop count. In both cases, the (average) packet arrival rate is 1 Mbps and the packet length is 1024 bytes. The throughput is defined as the total size of data packets successfully received by all destinations divided by the simulation time (100 s). Besides, each node u maintains a 50-packet queue for any 1-hop node

_v

, i.e. Qv650.

Table 4lists the frame sizes of each compared protocol under H = 11. In addition to those in IEEE 802.11 DCF speciﬁcations (i.e. 20 bytes for RTS, 14 bytes for CTS, and 14 bytes for ACK), the DCA needs a 2-byte bitmap to carry the free channel list in RTS, and 2 bytes to indicate the selected channel and a parameter in CTS (see[3]). Thus, the frame sizes of RTS and CTS in DCA are 22 bytes (i.e. 22 = 20 + 2) and 16 bytes (i.e. 16 = 14 + 2), respectively. About the RTBM, its RTS additionally needs

Table 4

Frame sizes under H = 11 and system values of DSSS PHY.

802.11 DCF/McMAC DCA RTBM

RTS length 20 bytes 22 bytes 44 bytes

CTS length 14 bytes 16 bytes 39 bytes

RES length – 16 bytes 39 bytes

ACK length 14 bytes

Propagation delay 5ls

Backoff slot time 20ls

SIFS 10ls

(16)

2 bytes to encode the communicationDu(h) for each data channel h. Thus the size of RTS under H = 11 is 44 bytes (i.e.

44 = 20 + 2 + 2 11). Moreover, the CTS and RES needs 2 bytes for each duration of if_duration(

v

) and ch_duration(u, h), and 1 byte for the selected channel h⁄_{(see Section}_3.2_{). Thus, the sizes of the later two frames under H = 11 are 39 bytes}

(i.e. 39 = 14 + 2 + 2 11 + 1). Other system values specified for the DSSS PHY are also listed inTable 4. Although the RTBM needs larger frame sizes, as shown later, the benefit from our components can wholly compensate for such a drawback. The above contexts are the default settings. We also vary some parameters one at a time to assess the performance under different scenarios. Any result point of the following figures is averaged from 20 networks.

Fig. 10reports the throughput versa the number of data channels (H). In comparison with the single-channel 802.11 DCF, the DCA can use multiple data channels to increase the throughput. When H = 2, it achieves a 28.98% gain in single-hop case and a 44.72% gain in multi-hop case. However, the improvement becomes very limited as more channels are provided. With 11 channels, the DCA obtains merely a 40.08% and 79.59% gain in the two cases, respectively. The results indicate that only a small portion of data channels were utilized due to the bottleneck in control channel.

The bottleneck problem can be mitigated by CIP. As shown inFig. 10, the RTBM(CIP) has 4–42% throughput increments over the DCA. The reason is that CIP can prevent nodes from sending redundant RTSs and thus avoid unnecessary blocking from NAVCTRL. Notice that CIP is particularly useful for small H, because a coordination process may fail when two nodes have no free

data channels in common, and there are relatively fewer common channels when H is small. Nonetheless, CIP cannot entirely break through the limitation of the control channel, since a coordination process is still required before sending each data packet. The DDC can substantially resolve this problem. As shown inFig. 10, RTBM(CIP+DDC) has improved the baseline through-put by over 2.26 times in single-hop case and 3.49 times in multi-hop case, with just one additional data channel, i.e. H = 2. Moreover, for H = 4, it can further gain 2.86 times and 5.17 times performance in the two cases. However, since the trafﬁc load is not quite heavy in default, the throughput reaches the limit when H P 6. As shown inFig. 11, by pressuring nodes

Fig. 10. Variation in the number of data channels.

(17)

with more data flows, the throughput is almost linear to the number of flows under H = 11. Contrarily, other protocols with-out DDC even degrade the throughput as the number of flows exceeds a certain limit.

The bottleneck problem is also resolved by McMAC. As shown inFig. 10(a), the throughput of McMAC increases signifi-cantly when H raises. However, when H is small, McMAC does not perform well (even worse than the original DCC when H = 2). One reason is that the congestion in each channel is still heavy for a small H. In contrast, DDC can dynamically adjust the number of data packets being sent to balance the congestion in both control and data channels no matter how many channels are provided. Another reason is that the DCC-based approach can separate control and data traffic into different channels so that control and data signals are not interfering to each other. Note that although RTBM needs one additional channel for control purposes, we can see that the throughput of RTBM(CIP + DDC) with h channels is higher than that of McMAC with h + 1 channels in all cases. Moreover, McMAC has no significant improvement in a multi-hop case, because a node may frequently depart to different hopping sequences to forward messages, which however are always not visible to other nodes in the interference range, incurring a serious collision problem. In contrast, RTBM allows each node to acquire the status of other nodes and channels at any time.

The ECS can further enhance the throughput. As shown in Fig. 10, RTBM(CIP + DDC + ECS) shows clear gains over RTBM(CIP + DDC), especially when more data channels are provided. One observation explains this tendency: When H is large, each sender u and receiver

v

have more choices to ﬁnd a data channel h which has a lower costDu,v(h). Particularly, under 11

data channels and 500 ﬂows, ECS additionally contributes 26.37% of throughputs in single-hop case (15.41% in multi-hop case). InFig. 12, we vary the channel bit rate (R) to show how raw channel capacity relates to the throughput. As R is raised from 0.5 Mbps to 11 Mbps, we can see that 802.11 DCF gains approximately 9–10 times throughput, but there are relatively lower gains (no more than 4 times) for DCA and RTMB(CIP). The lower growth rates are caused by the following reason: with a high-er channel bit rate, the data transmission is fasthigh-er, which implies that a node may initiate more control processes within a shorter period of time. As a result, contention in the control channel becomes more intensive. RTBM can get rid of such lim-itations by using DDC. As shown inFig. 12, RTMB(CIP + DDC + ECS) obtains 8.22 times throughput in the single-hop case and 9.39 times throughput in the multi-hop case as long as R is raised from 0.5 Mbps to 11 Mbps, which are very close to those achieved by 802.11 DCF, where no control bottleneck exists. The reason for this is that DDC can dynamically send multiple data frames to prolong the data transmission whenever the control channel is congested, i.e. data interface’s idle time rises. Besides, ECS can provide more enhancements when R is large, because the greater the channel bit rate is, the more free data channels exist, providing more choices for ﬁnding the lower communication cost.

Fig. 13demonstrates the impact of increasing transmission (interference) range We can see that the throughputs of 802.11 DCF, DCA, and RTBM(CIP) degrade drastically as the range increases. In contrast, RTBM(CIP + DDC) has only suffered a slight decrement in its throughput, since DDC can dynamically adapt to any increasing interference in the control channel. Moreover, ECS can help nodes to achieve better channel reusability. Hence, RTBM(CIP + DDC + ECS) is almost not affected by this factor. Surprisingly, the throughput can be even better when the range is more than 250 m. This phenomenon possibly stems from the fact that a larger transmission (interference) range can avoid the presence of hidden terminal nodes in the control channel.

Now let us compare with the ideal version. We can see that the throughput of RTBM(CIP + DDC + ECS) is very close to that of RTBM_{(CIP + DDC + ECS) especially when H is large (see}_{Fig. 10}_{), because the change of a channel release time can be less}

frequent if more other channels are offered. Besides, the throughput degradation is very small even under a heavy loading (seeFig. 11). Therefore, the inaccuracy of information has a little impact to our protocol.

Fig. 14shows the normalized control overhead for each protocol (the total size of control messages being sent divided by that of the 802.11 DCF) over different number of ﬂows. Consider the single-hop case: By comparingFig. 11(a), we can see

(18)

that the control overhead of McMAC goes up in accompany with more data throughput, because McMAC can spread control loading over different channels. By contrast, the throughput of DCA is saturated by a small number of ﬂows, since the control overhead is congested in a single channel. Compared with DCA, although RTBM needs larger control frames sizes, it incurs

Fig. 13. Variation in transmission range (H = 11).

Fig. 14. Normalized control overhead (H = 11).