Design and Performance Evaluation of CAM-MAC ... - Semantic Scholar

1

Design and Performance Evaluation of CAM-MAC for Ad Hoc Networks Technical Report March, 2007 Tie Luo, Vikram Srinivasan and Mehul Motani Department of Electrical and Computer Engineering National University of Singapore Email: {tie, elevs, motani}@nus.edu.sg

Abstract—Medium access control (MAC) protocols have been studied under different contexts for decades now. In all decentralized MAC protocols, nodes make independent decisions on when to transmit a packet and when to back-off from transmission. However the decisions often turn out to be uninformed due to deficient knowledge at individual nodes, which, in multi-channel ad hoc networks, creates a multi-channel coordination problem. In this paper, we introduce a notion of cooperation that has not been explored before to address this problem, and thereby propose a protocol called CAM-MAC. Qualitatively, CAM-MAC needs only a single transceiver per node and is fully asynchronous. Quantitatively, (i) our analysis shows that CAM-MAC has an throughput upper bound of 91% of hardware capacity, and simulations show that its average throughput achieves 96% of the upper bound, (ii) although CAM-MAC uses a control channel, both our analysis and simulations show that it can saturate 14.2 channels and typically does not suffer from the control channel bottleneck problem, (iii) in the comparison of CAMMAC with and without cooperation, we observe a throughput improvement of 281% and 173% in single-hop and multi-hop networks, respectively, which shows the value of cooperation, (iv) compared with three recent and representative multi-channel MAC protocols, MMAC [2], SSCH [3] and AMCP [4], CAMMAC substantially outperforms all of them. Index Terms—Cooperation, multi-channel MAC, ad hoc networks.

I. I NTRODUCTION The vagaries of the wireless channel and its locationdependent nature often prevent wireless networking devices from acquiring sufficient knowledge about channel status in their vicinity. This results in network nodes making uninformed decisions at times and thereby degrades system performance. Specifically in the MAC layer, simultaneous transmissions from non-adjacent nodes can have strong influence on each other (e.g., the hidden terminal problem [5]), but such non-local information is not readily available when a node wishes to establish communication with another. This knowledge deficiency is aggravated by the usage of multiple frequency channels in ad hoc networks. Regardless of the original intention of achieving more concurrent transmissions and higher spatial utilization, it is however hard to realize due to a fundamental hardware limitation—commercial offthe-shelf (COTS) multi-channel wireless cards do not support This is an extended version of [1].

operating on multiple frequencies simultaneously. This causes a node to miss channel usage information disseminated over channels other than the channel it is currently tuned to. This eventually creates a multi-channel coordination problem, which consists of two sub-problems. The first is a channel conflict problem, caused by a node (unintentionally) selecting a busy channel for data transmission and results in collision.1 The second is a deaf terminal problem, caused by a node initiating communication with another node which is however on a different channel, which leads to unnecessarily retransmissions. Consequently, although the IEEE 802.11a/b/g/n standards all provide multi-channel support in the PHY layer, multi-channel MAC protocols for ad hoc networks are still in the research phase. In the mainstream of existing proposals, one approach is to equip each node with one more transceiver for monitoring channel usage when the other transceiver is engaged in communication [6]–[11]. The other approach is to regulate nondeterministic node behaviors by requiring all nodes to negotiate channels in well-known time slots [2], [12], [13], or to follow certain channel hopping sequences [3], [14], [15], such that nodes can have prior knowledge of channel usage. This approach assumes clock synchronization. Clearly, the multitransceiver solution leads to increased hardware cost, size, and possibly energy consumption, and the synchronization solution incurs considerable overhead and complexity [16], and compromises network scalability [17]. In this paper, we propose a multi-channel MAC protocol which uses a single transceiver and is fully asynchronous. The key to our solution is a new concept of cooperation. The basic idea is inspired by an observation that, due to the broadcast nature of wireless channels, every node inherently possesses an opportunity to compensate for its deficient knowledge by resorting to its neighbors. To visualize this, see Fig. 1(a). Node pair (U1 , U2 ) and (V1 , V2 ) are performing data transmissions on channel 1 and 3 respectively. This fact may be unknown to nodes A1 and A2 but known to nodes C, D, and E since nodes can be on different channels. Suppose A1 wishes to initiate communication with A2 at this moment, then C, D, and E can share their knowledge with (A1 , A2 ) to avoid 1 One of such scenarios is that control packets sent on a certain channel fail to inform neighboring nodes communicating on a different channel, which is termed by [2] as a multi-channel hidden terminal problem.

2

C

D

A2

A1

U1

V1

1

3

U2

V2 E

neighbor relationship

#

new communication

ongoing data transmission cooperation

(a) The observation that inspires cooperation. C

D

E

1 X 2 OK 3 OK

1 OK 2 OK 3 X

1 X 2 OK 3 X

(b) Illustration of why cooperation can solve the channel conflict problem. By consolidating the knowledge of nodes C and D, or acquiring knowledge from node E, the transmit-receive pair (A1 , A2 ) will be able to select a conflict-free channel, i.e., channel 2. Fig. 1.

Basic idea of cooperation.

selecting the two busy channels (1 and 3), thereby solving the channel conflict problem. Fig. 1(b) gives a further illustration. In case that node A2 is on a channel different from A1 (who is initiating communication with A2 ), node E can inform A1 of this fact, thereby solving the deaf terminal problem. Consequently, a cooperative mechanism in which idle neighbors actively participate in communication by sharing knowledge so that transmit-receive pairs can make more informed decisions, is potentially a viable solution. This is in contrast to the design philosophy of conventional MAC protocols, where transmit-receive pairs make decisions on their own. Furthermore, we highlight that this notion of cooperation, which refers to knowledge sharing, is different from the conventional concept of cooperation which refers to intermediate nodes helping to relay data for source-destination pairs. On the basis of this idea, we design a Cooperative Asynchronous Multi-channel MAC protocol, CAM-MAC, to address the multi-channel coordination problem. We note that this approach of using cooperation is unique in the literature. It uses a single transceiver and its performance advantages have been demonstrated via our analysis and extensive simulations. We show that it has a throughput upper bound of 91% of system capacity and its average throughput can approach the upper bound with a mere gap of 4%. Although CAMMAC uses a control channel, we show that it can saturate 14.2 channels and does not suffer from the control channel bottleneck problem in typical cases. In the comparison of CAM-MAC with and without cooperation, which shows the value of cooperation, a throughput improvement of 281% and 173% is observed in single-hop and multi-hop networks, respectively. We also compare CAM-MAC with three recent and representative multi-channel MAC protocols, MMAC [2], SSCH [3], and AMCP [4]. The results show that CAM-MAC substantially outperforms all of them. In the rest of the paper, after reviewing literature in Section II, we identify in Section III new challenges to designing

a cooperative protocol. Then we present the protocol details in Section IV together with mathematical analysis. Following that, Section V provides simulation results in various scenarios. Finally, we discuss relevant aspects in Section VI and give concluding remarks in Section VII. II. R ELATED W ORK Multi-channel MAC protocols for ad hoc networks can be categorized into two classes as below. A. Multi-Radio Solutions Wu et al. [6] propose DCA (dynamic channel assignment) to allocate channels on demand. Each node is equipped with two transceivers, one dedicated to exchanging control messages and the other dedicated to data messages. Nasipuri et al. [7] propose a multi-channel CSMA protocol with “soft” channel reservation. It is assumed that the number of channels is equal to the number of transceivers on each node, which is very expensive. Jain et al. [9] propose a protocol similar to DCA, using a dedicated transceiver for control purposes, but they use a receiver-based channel selection strategy (comparing signalto-noise ratios at receivers). A multi-radio unification protocol (MUP) is proposed by Adya et al. [10], using two transceivers but both for control messages and data. The key drawback of this class of protocols is obviously the requirement of multiple transceivers per node, which not only increases device size and cost, but also boosts energy consumption. B. Single-Radio Solutions So and Vaidya [2] propose a protocol called MMAC. The protocol assumes the IEEE 802.11 power saving mode and partitions time into slots. Nodes use the ATIM window, which is the leading portion of each slot, to exchange control messages for reserving channels, and then transmit data packets on respective channels in the remaining portion of the same slot. Two of its drawbacks are (i) network dynamics such as various node densities and traffic loads need different ATIM window sizes for exchanging control messages, making it hard to determine the optimal window size, and (ii) data packets can be of variable sizes but time slots are fixed, which requires slots to use the maximum possible length and thus incurs inefficiency. Chen et al. [12] propose a similar protocol called MAP, using a reservation interval corresponding to the ATIM window of MMAC. This protocol uses variable-size time slots and hence can adapt to variable-size data packets to some extent (not a complete solution because multiple data packets are transmitted in the same slot due to multiple channels), but it still has the problem of adjusting reservation intervals based on network dynamics. Channel hopping is another scheme which falls into this category. CHMA [14] and CHAT [15] require all nodes to switch among channels by following a common hopping sequence when idle. A transmitter and a receiver stop hopping when they need to communicate with each other, and after that rejoin the sequence. Bahl et al. [3] propose SSCH (slotted

3

seeded channel hopping) which, unlike common hopping schemes, uses multiple hopping sequences (the number of hopping sequences is equal to the number of channels). Each node randomly adopts a sequence, and a communication can only start when the transmitter and the receiver hop onto the same channel. This results in extra delay. Besides, a common disadvantage of all the channel hopping schemes is that their performance is very sensitive to channel switching delay. According to current COTS products [18], each channel switching takes 150-200µs, about twice the transmission time of a RTS packet at the 802.11b 2Mbps rate, 80µs. The common drawback of these time-slotted schemes and channel hopping schemes is the requirement of clock synchronization. Some of them even demand tight synchronization (e.g., [2], [12], [14], [15]). This is a notoriously hard task especially for a large distributed network, and, according to So et al. [16], becomes more difficult in the presence of multiple channels. Furthermore, even if clock synchronization is achieved, two partitioned network may not be able to discover each other if their schedules are out of synchronization (Tseng et al. [19]). Recently, Shi et al. propose a multi-channel MAC protocol called AMCP [4]. This protocol uses a single transceiver and is also asynchronous. To achieve this and avoid channel conflicts, a node always selects its previously used channel. However, if that channel is occupied by other nodes, it has to wait for an avail timer to expire before using another data channel. This avail timer has to be set according to the maximum data packet transmission time, thereby sacrificing efficiency especially under high traffic load or variable packet sizes. All these existing studies address the channel conflict problem but not all of them address the deaf terminal problem. Our protocol, CAM-MAC, solves both subproblems and operates in a distinct way by using the cooperation that we introduce in this paper. Our solution uses a single transceiver and does not require synchronization, and its performance advantages are quantitatively demonstrated. III. C AVEATS TO C OOPERATIVE P ROTOCOL D ESIGN We identify three major issues in designing a cooperative MAC protocol, which will adversely affect protocol performance unless properly addressed. A. Control Channel Bottleneck Using a dedicated control channel can facilitate the design of a cooperative protocol, because a control channel provides a unique rendezvous for nodes to disseminate, gather and share information. However, this design scheme may come with a drawback: when a large number of channels and nodes are present, the single control channel which is used to setup communications can be highly congested and become a performance bottleneck. In this section, we define a metric to analyze this bottleneck problem, and derive a condition by which this problem can be avoided. Without loss of generality, suppose a complete communication process comprises of a control channel handshake preceded by a random CCA (clear channel assessment) period,

and a data channel handshake that immediately follows. We use the following notation: • Tctrl : duration of a successful control channel handshake. • Tdata : duration of a successful data channel handshake. min • Tcca : duration of a CCA period. Let Tcca = min(Tcca ). • Tsw : channel switching delay. Consider a network in which all nodes are within communication range of each other. We define a metric, mbot , to be the maximum number of data channels that can be simultaneously used for a given protocol. See Fig. 2 for an illustration. When a bottleneck problem happens, mbot data channels are simultaneously in use, and there are still free data channels and transmit-receive pairs on the control channel. But, no more data channels can be actually used because a subsequent usage of data channel (the (mbot + 1)th in the figure) can only happen after t, while at least one data channel (indicated by ) will become free before t. Therefore, mbot reflects the “capacity” for a multi-channel system. It is clear that a larger mbot is favorable. 1 Tcca Tctrl

m bot

2

...

Tcca Tctrl

Tcca Tctrl

m bot+1 Tcca Tctrl

Tdata

T sw data channels

Tdata

control channel

t time

T sw

...

T sw

Tdata

T sw

Fig. 2. Illustration of the control channel bottleneck: no more than mbot data channels can be simultaneously in use

By noticing in Fig. 2 that Tdata is bounded by the duration of mbot successive control channel handshakes, each of which min lasts a period of at least Tcca + Tctrl , mbot is given by Tdata mbot = . (1) min + T Tcca ctrl Note that Tsw does not affect mbot (a data channel is actually free during Tsw and can be used by other nodes). Suppose the objective is to design a protocol capable of saturating m?bot data channels, then mbot ≥ m?bot must be satisfied. This is equivalent to Tdata min Tcca + Tctrl

> m?bot − 1

which translates to min Tcca + Tctrl
m, all m data channels can be simultaneously in use by m node pairs, and the rest of nodes have to wait on the control channel until some data channel becomes free. Fig. 8 depicts this scenario, where we can see a period of Tcca + Tctrl + Tsw + Tdata will appear periodically. Hence, the maximum utilization ratio of a data channel is Tpayload , (4) ηmax = min Tcca + Tctrl + Tsw + Tdata where Tpayload is the transmission time of the payload in a data packet. So, Smax = ηmax mC,

(5)

where C is the capacity of a data channel. the rest of nodes waiting for free data channels

1 Tcca Tctrl

m

2 Tcca Tctrl

...

Tcca Tctrl

Tcca Tctrl Tdata

Ldata

T sw data channels

control channel

time

...

T sw

Ldata

T sw

Fig. 8. Case 1. m ≤ mbot . The bottleneck is at data channels and thus some nodes have to wait for free data channels. According to our protocol, only when at least one data channel is free can a node start contention on the control channel (indicated by CCA).

If nf ≤ m, Smax is achieved by assigning each sourcedestination pair with a dedicated data channel. The maximum channel utilization ratio remains the same as (4), and Smax = ηmax nf C.

(6)

2) m > mbot (bottleneck at the control channel) If nf > mbot , the control channel becomes bottleneck (the reader can refer back to Fig. 2). Since data channels are more

7

than what can be saturated (mbot ), each control channel handshake leads to a successful transmission of Tpayload (channel conflicts are eliminated). This translates to a maximum system gain of Gmax =

Tpayload , min + T Tcca ctrl

(7)

and thus Smax = Gmax C.

(8)

If nf ≤ mbot , then Smax is again achieved by the dedicated channel assignment as in (6), i.e., Smax = ηmax nf C. Finally, the necessary and sufficient conditions for a network to be unsaturated, are derived from the above: λ < ηmax C, λ < ηmax mC/nf , λ < GC/nf ,

if nf ≤ min(m, mbot ), if nf > m, and m ≤ mbot , if nf > mbot , and m > mbot .

• Discussion First we compute two key quantities, the maximum channel utilization ηmax and maximum system gain Gmax , by substituting the protocol parameters (in Section IV-B, plus Tsw = 0) into the above equations. We obtain ηmax = 91% and Gmax = 13.56. Then we revisit the two purposes mentioned in the beginning of this subsection: (i) compared against total channel capacity, CAM-MAC can theoretically utilize up to 91% of the capacity, (ii) compared against simulation results, CAMMAC achieves a throughput of 13.2C in the case of control channel bottleneck (Fig. 7), which is very close to the upper bound, 13.56C. In the case of no control channel bottleneck, the upper bounds are 0.91mC and 0.91nf C according to (5) and (6), respectively, and will be compared against simulations in the next section. V. P ERFORMANCE E VALUATION We implement and compare five protocols, namely IEEE 802.11, CAMMAC-RAND, CAMMAC-MRU, UNCOOPRAND and UNCOOP-MRU, using a discrete-event simulator which we develop on Linux. Among the five protocols, IEEE 802.11 is used as a baseline for comparison, X-RAND and X-MRU are two versions of protocol X, using the random and the MRU channel selection strategies respectively. The protocol UNCOOP is identical to CAM-MAC except that the cooperation element is removed, i.e., neighboring nodes do not actively participate (by sending cooperative messages) in communications within transmit-receive pairs, which essentially results in a conventional MAC protocol. We use this comparison to investigates the value of cooperation. We use three performance metrics: (a) aggregate (endto-end) throughput, defined as the payload bits per second successfully delivered over all flows, (b) channel conflict rate, defined as the packet collisions on data channels per second over all nodes, and (c) packet delivery ratio, defined as the number of data packets successfully received by destinations

normalized by the number of data packets sent by sources. This metric reflects the deaf terminal problem since deaf terminals can lead to packet drops. We do not measure packet delay because it is taken into account by throughput (inversely, for delivered packets) and packet delivery ratio (for dropped packets). We adopt the protocol model given by Gupta and Kumar [20], i.e., a node can correctly receive a packet if and only if it is within the communication range of the transmitter and no other nodes are transmitting within its interference range which is equal to the communication range. Note that this is assumed only by our simulations but not by our protocol design. There is one control channel and five data channels with capacity 1Mbit/s each. The size of control packets can be readily computed according to the frame formats shown in Fig. 6. Plus, PLCP (short) preamble is 9byte, and PLCP header is 6byte. Data packets are generated at each source node according to a Poisson point process. Payload size is 2048byte. SIFS is 10µs, the cooperation collision avoidance period is 12µs, and propagation delay is negligible. Retry limit is 7. In the comparison of CAM-MAC and UNCOOP, we ignore channel switching delay because it is common to both protocols and each data transmission needs to switch only twice. However in comparison to the other protocols, namely MMAC, SSCH, and AMCP, we use the parameters that they respectively use, including channel switching delay. We terminate each simulation when a total number of 100,000 data packets have been sent over the network, rather than terminate after a fixed simulation time, in order to avoid the initial transient problem [21], [22]. All presented results are averaged over 15 randomly generated networks. Our pseudo-random number generator (PRNG) is a non-linear additive feedback PRNG with a cycle length of 16×(231 −1). A. Single-hop Networks In single-hop networks, nodes are designated as disjoint source-destination pairs (i.e., flows). The case of non-disjoint flows is considered in multi-hop network simulations. Varying traffic load (Fig. 9(a)): We deploy 30 nodes (i.e., 15 flows) and vary traffic load at each source node from 50kbit/s to 600kbit/s. In low-traffic scenarios (≤100kbit/s), we see that all protocols have almost equal performance due to the very mild channel contention. After that, a sharp difference appears between CAM-MAC and UNCOOP for both versions: the two versions of UNCOOP quickly saturate at a throughput of 1.6Mbit/s while those of CAM-MAC keep increasing until they saturate at 4.5Mbit/s, indicating a remarkable improvement of 281%. Also, the results show that CAM-MAC approaches the throughput upper bound with a gap of less than 4%. The reason that the MRU and random channel selection strategies do not make much difference is explained in the discussion of varying the number of nodes (Fig. 9(c)). Varying data payload size (Fig. 9(b)): There are still 30 nodes but source nodes are always backlogged. We observe that the two curves of UNCOOP are not monotonic; they first

8

3

2

Aggregate Throughput (Mbit/s)


4

802.11 UNCOOP−RAND UNCOOP−MRU CAMMAC−RAND CAMMAC−MRU UPPER BOUND

1

0 0

100 200 300 400 500 Traffic Generation Rate per Flow (kbit/s)

(a) Impact of traffic load. Fig. 9.

600

5 Aggregate Throughput (Mbit/s)

5

5

802.11 UNCOOP−RAND UNCOOP−MRU CAMMAC−RAND CAMMAC−MRU

4 3 2 1 0 0

2000 4000 6000 Data Payload Size (byte)

8000

(b) Impact of data payload size.

4

802.11 UNCOOP−RAND UNCOOP−MRU CAMMAC−RAND CAMMAC−MRU UPPER BOUND

3 2 1 0 0

10

20 Number of Nodes

30

40

(c) Impact of the number of nodes.

Single-hop simulation results.

ascend, then descend, and finally level off. This is accounted for by three factors: (i) a longer data packet is more susceptible to channel conflicts (more likely to be collided), (ii) on the contrary, longer data packets keep nodes on data channels for longer time and hence nodes initiate fewer control channel handshakes, thereby lowering down the chance of causing channel conflicts, (iii) a larger payload size offsets protocol overhead more effectively, leading to higher throughput, which also conforms to our analysis (specifically, (4) and (7)). However unlike UNCOOP, the throughput of CAM-MAC continuously increases. This is because cooperation helps avoid the channel conflict problem which relates to factor (i) and (ii), and the third factor becomes dominant, which leads to the throughput growth. Varying the number of nodes (Fig. 9(c)): In this set of simulations, we vary the number of nodes from 2 to 40. Unlike the previous two sets of results, it demonstrates an evident difference between the random and the MRU channel selection strategy. When the number of nodes is not more than 10 (i.e., ≤ 5 flows), MRU strategy in effect assigns each flow with a dedicated data channel (recall that there are five data channels). Therefore UNCOOP-MRU and CAMMAC-MRU both achieve throughput close to the upper bound. However, when there are 12 nodes, the one additional pair of nodes frequently grab the MRU channel of one of the other five pairs of nodes, making the node pair with MRU channel deprived resort to the random channel selection. This accounts for the dramatic performance degradation of UNCOOP-MRU and CAMMAC-MRU. After that, as the number of nodes increases, MRU channels are more likely to be occupied by more additional nodes, but on the other hand, additional nodes also increase the availability of cooperation. These two contradicting factors explain why UNCOOP-MRU continues to degrade while CAMMAC-MRU gradually recovers performance. Finally, after all curves level off, both versions of UNCOOP and CAM-MAC converge respectively, because the very frequent MRU channel deprivation at a large number of nodes almost eliminates the difference between the two channel selection strategies. On the other hand, the factor of cooperation dominates the large difference between CAM-MAC and UNCOOP, where CAMMAC again achieves a throughput of 281% of UNCOOP, and also approaches the upper bound within a ratio of 96%.

B. Multi-hop Networks In multi-hop networks, nodes are uniformly distributed in a terrain of 1500m×1500m, The communication range is 250m. In each simulation with n nodes, we randomly form n nondisjoint flows by designating each node as the source of one flow and the destination of another flow. Shortest path routing is used. Each node has a single queue for data packets.2 Varying traffic load (Fig. 10): Traffic generation rate is varied from 2.5kbit/s to 50kbit/s per flow, and node density is 10/r2 where r is the communication range (this results in a total number of 360 nodes in a network). From Fig. 10(a) we see that, all the four multi-channel MAC protocols have significantly higher throughput than the single-channel 802.11 protocol, and the ratios against 802.11 are often larger than in single-hop networks. This is because of a link scheduling and a single-hop bottleneck problem: for a single-channel MAC protocol like 802.11, nearby links (even if one-hop apart) cannot be simultaneously active [] due to interference, while the most congested (single) link will dominate the end-toend throughput. On the contrary for a multi-channel MAC protocol, nearby links can be simultaneously in use, which mitigates the bottleneck problem and increases spatial utilization than a single-channel protocol. We also observe that, after the throughput of each protocol saturates (after the knee points of the curves), CAM-MAC maintains a nearly constant throughput gain of ∼1.2Mbit/s over UNCOOP, which amounts to a ratio of 173% between CAM-MAC and UNCOOP at the traffic generation rate of 50kbit/s. In addition, the channel conflict rate shown in Fig. 10(b) and the packet delivery ratio shown in Fig. 10(c) also demonstrate large difference between CAM-MAC and UNCOOP. Varying data payload size (Fig. 11): We vary data payload size from 256 to 8192 bytes. We find that, although the throughput and packet delivery ratio of all protocols keep increasing (Fig. 11(a) and Fig. 11(c)), the channel conflict rate of UNCOOP exhibits a bell-shape curve (Fig. 11(b)). Recall the three factors described in the explanation of the corresponding single-hop result (varying payload size, Fig. 9(b)), where the former two factors relate to channel conflict rates and are con2 Some work such as [23] assumes that each node has a dedicated queue for each neighbor, in order to avoid the head-of-line blocking problem. This unpractically yields higher throughput and lower delay.

9

Channel Conflict Rate

3 2.5 2 1.5 1 0.5 0 0

802.11 UNCOOP−RAND UNCOOP−MRU CAMMAC−RAND CAMMAC−MRU

10 20 30 40 Traffic Generation Rate per Flow (kbit/s)

1

2000

0.8

1500

500 0 0

50

(a) Aggregate throughput. Fig. 10.

802.11 UNCOOP−RAND UNCOOP−MRU CAMMAC−RAND CAMMAC−MRU 2000 4000 6000 Data Payload Size (byte)


0.2 0 0

50


50

(c) Packet delivery ratio.

UNCOOP−RAND UNCOOP−MRU CAMMAC−RAND CAMMAC−MRU

1200

8000



1400

3

0 0

0.4

Impact of traffic load in multi-hop networks. Node density is 10/r2 .

4

1



0.6

(b) Channel conflicts.

5

2


1000

1000 800 600 400 200 0 0



8000

1 0.8 Packet Delivery Ratio


3.5

2500

Packet Delivery Ratio

4


0.6 0.4 0.2 0 0


8000


Impact of data payload size in multi-hop networks. Node density is 10/r 2 , and traffic generation rate is 20kbit/s.

tradicting: (i) longer packets are more susceptible to channel conflicts, and (ii) longer packets keep nodes on data channels for more time and hence reduce new communications which has to be setup on the control channel, thereby lowering down the chance of channel conflicts. These two factors account for the bell shape. The third factor, longer packets offset protocol overhead more effectively, dominates the growth of throughput and packet delivery ratio. Varying node density (Fig. 12): We vary node density from 2/r2 to 20/r2 . The curves are similar to Fig. 10 (varying traffic load). This is because increasing node density and increasing traffic generation rate per flow have an equivalent consequence of (linearly) increasing the aggregate offered traffic load for a whole network. Remark on the relationship between channel conflicts and throughput: We raise attention to the relationship between channel conflict rates and throughput observed in the above three scenarios (Fig. 10, Fig. 11 and Fig. 12), where, between CAM-MAC and UNCOOP, the difference in channel conflict rates is often much larger than in throughput. This is because a channel conflict rate does not translate to throughput linearly. The reason is that, in a cooperative protocol, cooperation avoids many (conflicting) channel selections resulting in actual data channel usage, therefore a cooperative protocol uses data channels for less times than an uncooperative protocol. Another phenomenon which is subtle but worth attention is that, in all scenarios, although the two CAMMAC flavors (RAND and MRU) have nearly the same channel

conflict rates, they do have slight difference in throughput. This is because the random channel selection strategy selects conflicting channels more often than the MRU strategy and thus incurs more cooperative messages to be sent, resulting more overhead and hence decreasing throughput. Both our single-hop and multi-hop simulations demonstrate that the introduction of cooperation mitigates the multichannel coordination problem effectively. C. Comparison with MMAC, SSCH, and AMCP We compare CAM-MAC with three recent multi-channel MAC protocols, MMAC [2], SSCH [3] and AMCP [4].3 They all use a single transceiver but MMAC and SSCH require clock synchronization while AMCP does not. In the comparison, CAM-MAC adopts the MRU strategy, and uses the same setup as MMAC, SSCH, and AMCP use respectively, for the purpose of comparing with their reported data under those settings. TABLE II PARAMETERS FOR C OMPARISON WITH MMAC channel capacity 2Mbit/s

WLAN no. channels packet size 3 512byte

multi-hop no. channels packet size 4 1024byte

1) Comparison with MMAC: The parameters are shown in Table II (note that only two and three data channels 3 We do not compare with DCA [6], which is representative among earlier protocols, because it uses multiple transceivers and has been shown in [2] to be outperformed by MMAC in almost all scenarios.

10

2000

4

1

3 2.5 2 802.11 UNCOOP−RAND UNCOOP−MRU CAMMAC−RAND CAMMAC−MRU

1.5 1

1500

1000

Packet Delivery Ratio



3.5


500


0.8 0.6 0.4 0.2

0.5 0 0

5

10 2 Node Density (1/r )

15

0 0

20


5

10 15 Node Density (1/r2)

0 0

5


10 15 Node Density (1/r2)

20


Impact of the number of nodes in multi-hop networks. Traffic generation rate is 20kbit/s.

are available to CAM-MAC, respectively). The first set of simulations are conducted in a wireless LAN over 6, 30 and 64 nodes, respectively. Nodes are configured as disjoint and fullyloaded flows as what MMAC does. The results are presented in Fig. 13(a), where we see that CAM-MAC achieves throughput by a factor of 1.05, 1.30, and 1.35 over MMAC, respectively. The second set of simulations are conducted in a multi-hop network. The same as in MMAC, 100 nodes are randomly placed in a 500m×500m area, the communication range is 250m, and 40 sources and 40 destinations are randomly chosen. The results are shown in Fig. 13(b). We see that at the saturation point, CAM-MAC achieves a throughput of 222.5% of MMAC.


3 MMAC CAM−MAC

2.5 2 1.5 1 0.5 0

6

30 Number of Nodes

64

(a) Wireless LAN.


5 4 MMAC CAM−MAC

3

TABLE III PARAMETERS FOR C OMPARISON WITH SSCH

no. channels 13

channel capacity 54 Mbit/s

packet size 512byte

channel switching delay 80µs

by-packet basis. In both configurations, all flows are always backlogged. Actually, the simulation parameters (Table III) are favorable to SSCH but unfavorable to CAM-MAC. To understand this, see the operation of the two protocols. In SSCH, nodes hop among channels following their respective sequences, and hence a transmitter has to wait for its receiver to hop onto the same channel to start communication. Therefore, SSCH prefers both channel switching delay and data packets to be as short as possible to reduce the waiting time. In their simulations, data packet size is 512byte, channel switching delay is 80µs while typical COTS hardware (such as [18]) has a switching delay of over 200µs. On the other hand, CAMMAC favors long data packets to offset its control packet overhead, and its performance is not affected by channel switching delay as significantly as SSCH, because it only needs to switch channel twice for each data transmission. Nevertheless, using the same parameter as SSCH uses, we see in the results shown in Fig. 14 that CAM-MAC still outperforms SSCH with a factor of up to 150%, in both disjoint and non-disjoint flow cases. TABLE IV PARAMETERS FOR C OMPARISON WITH AMCP

2

channel capacity 2 Mbit/s

1 0 0 10

1

2

3

10 10 10 Traffic Generation Rate per Flow (kbit/s)

packet size 1000byte

channel switching delay 224µs

4

10

(b) Multi-hop networks. Fig. 13.

20

Comparison with MMAC.

2) Comparison with SSCH: The parameters are shown in Table III (CAM-MAC uses 12 data channels). In SSCH, a disjoint-flow configuration and a non-disjoint-flow configuration are used, where the latter configuration means randomly selecting source-destination pairs (flows) on a packet-

3) Comparison with AMCP: The parameters are shown in Table IV, and there are 30 nodes forming 15 disjoint flows in a single-hop network. In the first set of simulations, the flows are always backlogged and the number of channels is varied from 2 to 12. The corresponding results are shown in Fig. 15(a). We see that when there are 12 channels, CAM-MAC achieves a throughput of 11.86Mbit/s while AMCP achieves 8.5Mbit/s, which indicates a ratio of 140% between them. Furthermore, the throughput of AMCP saturates at 10 channels whereas

120

12

100

10



11

80 60 40

SSCH CAM−MAC

20 0 0

5 10 Number of Flows

2 4

6 8 Number of Channels

10

12

5 Aggregate Throughput (Mbit/s)


4

(a) Throughput versus number of channels.

60 50 40 30 SSCH CAM−MAC

20 10

4 3

10 Number of Flows

15

20

Comparison with SSCH.

CAM-MAC still exhibits a growing trend even beyond 12 channels. This is consistent with our analysis. To see how, substitute the parameters (in Table IV and Section IV-B) into (1) and obtain mbot = 7 (d6.98e). This means m > mbot and nf > mbot (there are nf = 15 flows), which directs us to use (7) and (8), and accordingly compute Smax = 13.24M bit/s (Gmax = 6.62). Comparing Smax with the throughput CAMMAC achieves at 12 channels (11.86Mbit/s) shows that CAMMAC can still have throughput growth before approaching the upper bound Smax (recall that in our simulation results in Section V-A CAM-MAC approaches the upper bound very closely). In the second set of simulations, there are four channels and the traffic generation rate is varied from 8kbit/s to 8Mbit/s. The results are shown in Fig. 15(b). Both CAM-MAC and AMCP have equal throughput at light traffic load, but apparent difference appears at medium to high load, and finally CAMMAC saturates at 5Mbit/s while AMCP saturates at 4.2Mbit/s. Our extensive simulations demonstrate the high productivity of CAM-MAC. We note that this is essentially attributed to the introduction of cooperation. VI. D ISCUSSION We reflect below on some relevant aspects. Two-hop neighbor discovery: Two-hop neighbor information is necessary for cooperation. To visualize this, see Fig. 1(a) again, where node C only cooperates if it knows that node U2 is adjacent to node A1 , though U2 is not adjacent to C itself. To acquire such information, one simple way is to take advantage of the traditional one-hop neighbor discovery, where each node exchanges Hello messages carrying its own

AMCP CAM−MAC

2 1 0

5

(b) Non-disjoint flows. Fig. 14.

AMCP CAM−MAC

6

0 2

15

(a) Disjoint flows.

0 0

8

1

10

2

3

10 10 Traffic Generation Rate per Flow (kbit/s)

4

10

(b) Throughput versus traffic load. Four channels. Fig. 15.

Comparison with AMCP.

ID to detect neighbors. Therefore, by letting each Hello message piggyback its sender’s neighbor IDs, a node can learn its two-hop neighbors easily. This process will not noticeably increase control traffic, because it reuses the existing one-hop neighbor discovery, and occurs only in the initialization phase or periodically with fairly large intervals. Impact of mobility: Mobility is a major factor attributing to network dynamics and affecting the reliability of (one-hop and two-hop) neighbor information. One simple way of adapting CAM-MAC to a mobile environment is to accordingly increase the frequency of updating neighbor information. We conducted multi-hop simulations using random waypoint model [24], with the same setup as in Section V-B. We do the same three sets of simulations (varying traffic, payload size, and node density), except that each node moves at a speed uniformly distributed in (0, 10]m/s and toward a randomly chosen target point for each movement. Each node independently updates neighbor information every 8 seconds. Our results showed only a marginal (3–8%) performance degradation in comparison to the static scenarios in Fig. 10, Fig. 11 and Fig. 12. The details are omitted for space constraints. Actually, these results are not surprising because (i) in essence, cooperation is not a coordination mechanism which is compulsory for establishing a communication, but an auxiliary mechanism, without which a communication can still proceed, and (ii) cooperation is provided in the sense that one cooperative node is enough to solve a multi-channel coordination problem. In consequence, cooperation is robust to low mobility levels which apply to most application scenarios. Energy consumption: Energy consumption is a critical issue for battery-powered devices commonly used in ad hoc networks. To save energy and prolong network lifetime, nodes

12

should be kept in sleep mode as long as possible. However, they also need to stay active to gather channel usage information for both self-use (make informed decisions) and for cooperation purposes. This dilemma presents a challenge to multichannel MAC protocol design, especially when cooperation is introduced. In this paper, as an initial attempt of cooperative protocol design, we focus on throughput performance while do not specifically consider energy. This is also for fairness in the comparison with other state-of-the-art protocols, as those protocols do not consider energy either. Nevertheless, we recognize that energy conservation is an important issue and one of our ongoing work is on integrating energy-aware features into cooperative protocols. Multi-channel sensor networks: Wireless sensor networks (WSN) were initially motivated by low data rate applications, but new applications demanding higher throughput and/or lower delay quickly emerged after a few years, such as those in wireless multimedia sensor networks [25]. Current sensor platforms, however, only provide very limited bandwidth, e.g., 19.2kbit/s on MICA2 [26], 250kbit/s on MICAz [26] and Telos [27]. On the other hand, some RF transceivers such as CC2420 used by MICAz and Telos also provide multiple frequency channels. Therefore, we advocate that multi-channel MAC protocols for wireless sensor networks are not only in need but also realizable. Recently, Zhou et al. propose such a protocol called MMSN [28], which is reported to be able to boost sensor network performance in comparison to its single-channel counterpart. However, MMSN uses complicated mechanisms and requires tight clock synchronization, making it impractical for simple, miniature, and powerless embedded systems.We argue that CAM-MAC can be a candidate for WSN. The reasons are that (i) it is simple, asynchronous, and only use a single transceiver, and (ii) we have successfully implemented CAMMAC on sensor platforms and observed desirable performance in real environments. But, we also realize that there are two issues must be properly addressed before applying CAM-MAC to WSN: energy efficiency and small packet size. Nonetheless, we believe that CAM-MAC and the cooperation idea merit further investigation for sensor networks. VII. C ONCLUSION In this paper we introduce a new concept of cooperation into multi-channel ad hoc networks, and propose a cooperative MAC protocol called CAM-MAC on the basis of it. CAM-MAC uses a single transceiver and, unlike many other protocols, is fully asynchronous. Distinct from traditional MAC protocols, neighboring nodes in CAM-MAC actively participate in communication to overcome multi-channel coordination problems. CAM-MAC does not assume specific channel selection strategies, making it flexible, nor assume isotropic or homogeneous radio patterns, making it adaptive for realistic environments. Essentially, cooperation overlays the conventional MAC as a thin tier. This tier compensates nodes for their knowledge deficiency and helps them make informed decisions. It is thin because cooperation, unlike coordination, adds an auxiliary instead of a compulsory functionality—nodes do not rely

on cooperation and communication can still proceed without cooperation. However, this thin tier turns out to be very effective. In the comparison of CAM-MAC with and without cooperation, we observe remarkable performance difference. In comparison to three recent and representative multi-channel singletransceiver MAC protocols, MMAC, SSCH and AMCP, CAMMAC significantly outperforms all of them. R EFERENCES [1] T. Luo, M. Motani, and V. Srinivasan, “CAM-MAC: A cooperative asynchronous multi-channel MAC protocol for ad hoc networks,” in IEEE Broadnets, San Jose, CA, USA, October 2006. [2] J. So and N. Vaidya, “Multi-channel mac for ad hoc networks: Handling multi-channel hidden terminals using a single transceiver,” in ACM MobiHoc, 2004. [3] P. Bahl, R. Chandra, and J. Dunagan, “SSCH: Slotted seeded channel hopping for capacity improvement in IEEE 802.11 ad-hoc wireless networks,” in ACM MobiCom, 2004. [4] J. Shi, T. Salonidis, and E. W. Knightly, “Starvation mitigation through multi-channel coordination in CSMA multi-hop wireless networks,” in ACM MobiHoc, 2006. [5] F. A. Tobagi and L. Kleinrock, “Packet switching in radio channels: Part II–the hidden terminal problem in carrier sense multiple-access and the busy-tone solution,” IEEE Trans. Commun., vol. COM-23, no. 12, pp. 1417–1433, Dec. 1975. [6] S.-L. Wu, C.-Y. Lin, Y.-C. Tseng, and J.-P. Sheu, “A new multi-channel MAC protocol with on-demand channel assignment for multi-hop mobile ad hoc networks,” in I-SPAN, 2000. [7] A. Nasipuri, J. Zhuang, and S. R. Das, “A multichannel CSMA MAC protocol for multihop wireless networks,” in WCNC, 1999. [8] A. Nasipuri and J. Mondhe, “Multichannel CSMA with signal powerbased channel selection for multihop wireless networks,” in IEEE VTC, 2000. [9] N. Jain and S. Das, “A multichannel CSMA MAC protocol with receiver-based channel selection for multihop wireless networks,” in IEEE ICCCN, 2001. [10] A. Adya, P. Bahl, J. Padhye, and A. Wolman, “A multi-radio unification protocol for IEEE 802.11 wireless networks,” in IEEE Broadnets, 2004. [11] R. Maheshwari, H. Gupta, and S. R. Das, “Multichannel MAC protocols for wireless networks,” in IEEE SECON, 2006. [12] J. Chen, S. Sheu, and C. Yang, “A new multichannel access protocol for IEEE 802.11 ad hoc wireless LANs,” in PIMRC, 2003. [13] J. Zhang, G. Zhou, C. Huang, S. H. Son, and J. A. Stankovic, “TMMAC: an energy efficient multi-channel MAC protocol for ad hoc networks,” in IEEE ICC, Glasgow, UK, 2007, to appear. [14] A. Tzamaloukas and J. Garcia-Luna-Aceves, “Channel-hopping multiple access,” in IEEE ICC, 2000. [15] ——, “Channel-hopping multiple access with packet trains for ad hoc networks,” in IEEE Device Multimedia Communications, 2000. [16] H.-S. W. So, G. Nguyen, and J. Walrand, “Practical synchronization techniques for multi-channel MAC,” in ACM MobiCom, 2006. [17] L. Huang and T.-H. Lai., “On the scalability of IEEE 802.11 ad hoc networks,” in ACM MobiHoc, 2002. [18] Maxim Integrated Products Inc., MAX2820, MAX2820A, MAX2821, MAX2821A 2.4GHz 802.11b Zero-IF Transceivers Data Sheet rev. 04/2004, Sunnyvale, California, USA, 2004. [19] Y.-C. Tseng, C.-S. Hsu, and T.-Y. Hsieh, “Power-saving protocols for IEEE 802.11-based multi-hop ad hoc networks,” in IEEE Infocom, 2002. [20] P. Gupta and P. R. Kumar, “The capacity of wireless networks,” IEEE Trans. Information Theory, vol. 46, no. 22, pp. 388–404, March 2000. [21] L. F. Perrone and Y. Yuan, “Modeling and simulation best practices for wireless ad hoc networks,” in IEEE Winter Simulation Conference (WSC), 2003. [22] D. Goldsman and G. Tokol, “Output analysis procedures for computer simulations,” in IEEE Winter Simulation Conference (WSC), 2000. [23] J. Mo, H. W. So, and J. Walrand, “Comparison of multichannel mac protocols,” in ACM MSWiM, 2005. [24] J. Broch, D. A. Maltz, D. B. Johnson, Y.-C. Hu, and J. Jetcheva, “A performance comparison of multi-hop wireless ad hoc network routing protocols,” in ACM MobiCom, New York, NY, USA, 1998, pp. 85–97.

13

[25] I. F. Akyildiz, T. Melodia, and K. R. Chowdhury, “A survey on wireless multimedia sensor networks,” Computer Networks, no. 51, pp. 921–960, 2007. [26] Crossbow Technology Inc., http://www.xbow.com. [27] J. Polastre, R. Szewczyk, and D. Culler, “Telos: Enabling ultra-low power wireless research,” in ACM/IEEE IPSN/SPOTS, April 2005. [28] G. Zhou, C. Huang, T. Yan, T. He, J. Stankovic, and T. Abdelzaher, “MMSN: Multi-frequency media access control for wireless sensor networks,” in IEEE Infocom, 2006.