McMAC: A Parallel Rendezvous Multi-Channel MAC Protocol Hoi-Sheung Wilson So

Jean Walrand

Jeonghoon Mo

Department of Electrical Engineering Department of Electrical Engineering School of Engineering and Computer Sciences and Computer Sciences Information and Communications University of California University of California University (ICU) Berkeley, CA 94720, USA Berkeley, CA 94720, USA Yusong P.O. Box 77, Taejon, 305-600, Korea Email: [email protected] Email: [email protected] Email: [email protected]

Abstract— Many multiple channel MAC protocols for wireless networks have been proposed to make efficient use of multiple channels where each node has a single radio which allows it to send or receive on one channel at a time. However, most of the proposed protocols are single rendezvous protocols that are subject to the congestion of the control channel. We propose a new parallel rendezvous protocol, McMAC, to avoid control channel congestion so that it can scale to use a large number of channels efficiently. We validate our protocol design using simulation and implementation.

I. I NTRODUCTION Many multi-channel wireless MAC protocols have been proposed to increase the throughput of ad hoc networks. These protocols exploit the availability of multiple disjoint channels (i.e., frequency bands) and the ability of modern radios to switch channels quickly. Using a multi-channel MAC protocol, different devices can transmit in parallel on distinct channels. The parallelism increases throughput and can potentially reduce delay as well, provided channel access time is not excessive. Protocols differ in how devices negotiate the channel to use and resolve medium contention. Dedicated Control Channel approach designate one channel exclusively for control purposes. Each node listens to that channel to make an agreement [14], [15], [5]. A separate transceiver is used for data transmission. Unlike the Dedicated Control Channel, other approaches typically use only one radio for both control and data packets. For example, for Split-phase protocols [3], [10], time is split into alternating periods of control and data phases. In a control phase, all devices listen to the control channel to make an agreement. In the data phase, nodes change to their respective channels negotiated in the previous control phase to exchange data in parallel. In Common-hopping approach [12], [13], all idle devices hop together over every channel sequentially. They make an agreement as they hop together and pauses only if they have data to exchange. Even though Dedicated Control Channel, Split-phase, and Common Hopping differ in the way nodes make channel agreements, they are all categorized as single rendezvous protocols because at any instance, the rendezvous between a sender and its receiver can happen on at most one channel.

With more data channels, single rendezvous protocols can lead to control channel congestion. In [6], we showed through both analysis and simulation that control channel can saturate when the amount of data exchanged after each rendezvous is small, or when many channels are available. In [4], Han et. al also reported control channel can be a bottleneck. To avoid congestion, another approach which allows different pairs to rendezvous simultaneously on different channels was proposed. One proposal is SSCH (Slotted Seeded Channel Hopping) [2]. We also outlined a parallel rendezvous protocol proposal called McMAC to illustrate the potential benefits of the parallel rendezvous approach in [6]. In both SSCH and McMAC, each node can have a different hopping sequence. In SSCH, each node time-multiplexes four hopping sequences to create its own hopping pattern. The four sequences of each sender are selected dynamically to match its receivers’ current hopping sequences. Since two nodes can exchange data only when their hopping sequence coincide, senders must constantly re-align their hopping sequences to that of their receivers as traffic demand changes. Moreover, all nodes have to keep their hopping boundaries synchronized. We note that in certain applications, communication pattern may change faster than nodes can adapt and announce their new hopping patterns. Therefore, it is desirable to have a parallel rendezvous protocol which relies on randomization rather than careful pair-wise scheduling for load balancing across channels. The operation of McMAC is quite simple in that a sender chooses a hopping pattern at random and it never needs to change. In addition, a node can deviate from its constant hopping sequence and jump to the receiver’s channel to send if necessary. In [6], we showed rendezvous protocols such as McMAC has merits, but the sketch design did not consider many necessary details such as scheduling. In this paper, we explore the detailed design of McMAC and evaluate its performance. The rest of the paper is organized as follows. In Sec.II, we describe the McMAC protocol in details. In Sec.III, we explain our network assumptions and simulator platform. In Sec.IV, we recap the performance difference of McMAC obtained through analysis. Next, in Sec.V, we explore several important design options related to scheduling. Next, we present our

preliminary implementation results in Sec.V-D. Finally, we conclude in Sec.VI. II. M C MAC P ROTOCOL D ESCRIPTION A. Key Ideas The design of any multi-channel MAC revolves around two core issues. First, a sender must know the channel on which its receiver is listening. This is so because each device can only listen to 1 channel at any time. Second, the sender must know whether that channel is idle or not. The first issue is specific to multi-channel MAC, while the second is common to all MAC protocols. However, the second problem becomes more difficult because devices may hop to a channel after an RTS/CTS exchange, rendering RTS/CTS less effective in combating hidden terminal problems. McMAC solves the first problem by using the MAC address of each node as a random number generator seed to generate its hopping sequence known as the default sequence. During each dwell period (aka hop), the channel specified by the home sequence is the default channel of the device during that hop. When idle, a device listens on its default channel. As a result, if a sender knows the seed, the hop boundary, and the current offset into a receiver’s sequence, it can predict the hopping pattern of a receiver. McMAC solves the second problem using a combination of techniques. First, it uses traditional RTS/CTS. Second, it listens for carrier after switching channel to avoid collision. Ideally, this period should be longer when traffic load is heavy to reduce the chance of missing an RTS/CTS packet. The description of McMAC is divided into four major sections: 1) Random Channel Hopping: Devices hop according to a pseudo-random hopping sequence of their choice. This home sequence is fixed although temporary deviation is allowed. 2) Discovery: When a device is turned on, it discovers its 1-hop neighbors and adds them to its neighbor table. Subsequently, it adds neighbors to or removes them from the list when network topology changes. 3) Synchronization: Each node estimates the relative speed of the clocks of its neighbors accurately in order to track the hopping boundaries of its neighbors in a pairwise fashion without requiring global synchronization. 4) Rendezvous and Scheduling: In order for a node to send a data packet, it must decide when to change its channel to match its receiver’s. It also needs to decide when to send and when to listen for incoming packets. Multiple nodes may decide to send at the same time on the same channel. The access to the medium must be resolved in a fair and efficient manner. Each node may simultaneously have data to send to several neighbors. Scheduling decides the order in which a sender visits its receivers which affects the efficiency of the protocol.

B. Random Channel Hopping In McMAC, each device hops over all M available channels in a pseudo-random fashion using its own MAC address as the seed. Time is divided into Small Slots (Ts ) and Big Slots (Tb ) as shown in Fig.1. Each Small Slot should be roughly equal to the shortest time it takes for the radio to detect a carrier when using Carrier Sense Multiple Access (CSMA). Typical values should be on the order of 10µs. Hopping happens at Big Slot boundaries. To reduce computation overhead, only 2L numbers from the beginning of the hopping sequence is used where 2L is much larger than the number of channels M (e.g., 10 times). During neighbor discovery, the entire hopping sequence of a new neighbor can be precomputed and saved in memory. The repeating sequence can be generated using a linear congruential generator [7], for example,: X(t) = 16807 · X(t − 1) mod

(231 − 1),

(1)

where X(t) is the channel number for t-th Big Slot (t = 1, 2, . . . , T .) To map X(t) to a number between 0 and N − 1, a modular M operation is applied to X(t). Once each device has an initial value X(0), the seed of the sequence, the hopping sequence of each node can be generated using the common function (1). The reason for using only the first 2L numbers from the sequence is that a device can precompute the sequences of its neighbors and store them in memory. McMAC intentionally allows nodes to keep independent slot boundaries. Fig.1 shows the unaligned slot boundaries of two nodes. If nodes were required to hop at the same time, nodes must re-align their slot boundaries whenever two disjoint networks merge. Changing the hopping boundaries can cause transient confusion among neighbors and packet losses, especially in networks where network partition and merging happen frequently. C. Discovery In McMAC, every packet sent includes the hopping signature of the sender, namely the current time (Big Slot, Small Slot indices) and the seed of the sender. Since the seed is the sender’s MAC address, it does not impose any additional overhead. The time stamp should be taken when the packet is sent on the medium, after any queueing and processing delay at the MAC layer. Discovery in McMAC relies on two mechanisms: primary and backup. Using the primary mechanism, when a node turns on, it monitors the a well-known discovery channel for any packet for an initial period of 10 seconds. After 10 seconds, the newcomer starts following its own default hopping sequence. From then on, the newcomer beacons once every second with a small randomized delay while following its hopping sequence to ensure that it beacons on all channels with equal probability. In addition, it also beacons at least once every 2 seconds when its home sequence lands on the default discovery channel. When a node receives any packet, if the sender is a new neighbor, the receiver records the hopping signature of the sender consisting of the time stamp and the seed of the sender.

Small Slots

Big Slot boundaries (i.e., hopping boundaries) of node A .. . .

.. . . Big Slot boundaries (i.e., hopping boundaries) of node B

.. . .

.. . . Time

Fig. 1.

Each node keeps independent slot boundaries. Hopping occurs at Big Slot boundaries.

Otherwise, the synchronization algorithm uses the send time stamp to update the receiver’s estimation of the clock drift relative to the sender, such that it can accurately predict the home channel of the sender. Whenever a new neighbor is discovered, the receiver sends a courtesy packet with its own hopping signature to speedup mutual discovery. It is also possible to ask a neighbor for a list of its known neighbors, but for simplicity, this approach is not currently used. D. Synchronization If the crystal clocks in different devices are perfectly accurate, then there is no need for synchronization after the initial discovery. Unfortunately, clock drifts are inevitable and must be compensated for. Otherwise, a sender will lose track of the hopping sequence used by the intended receiver after a period of inactivity. Various schemes have been proposed to account for clock drifts for single-channel networks [1],[8]. However, for supporting multi-channel MAC, only pair-wise synchronization between neighbors, rather than global synchronization, is necessary. In addition, broadcast becomes highly unreliable since nodes are not always on the same channel, a new synchronization mechanism is needed. We designed and implemented a robust pair-wise synchronization protocol for this purpose in TinyOS [11]. It can synchronize neighbors to within ±200µs over 99% of the times. The basic idea is for a node to include a 32-bit time stamp in every packet it sends. The neighbors then compare the differences in the rate at which the clocks of the sender advances versus that of their own. The difference is an estimate of the drift rate of an individual neighbor. Our scheme uses a recursive least square algorithm to achieve constant time update and constant amount of memory per neighbor regardless of the length of history kept. For more details, please refer to [9]. E. Rendezvous and Scheduling Rendezvous is the process in which a sender makes an agreement with the receiver to use the same channel for data transmission, given that the sender has an accurate estimate of the current home channel of the receiver. Using McMAC, rendezvous can happen on multiple channels simultaneously among several pairs of senders and receivers. Each device keeps one packet queue per destination to avoid head-of-line blocking and to facilitate scheduling. At the beginning of each Big Slot, if the device has no data to

send, it will follow its default sequence and listen. If outgoing data is pending, it flips a coin to determine which channel it will switch to. With probability Pdeviate , it allows itself to temporary deviate from its default hopping sequence and transmit to a receiver on another channel. Otherwise, it simply stays on the current channel. If it decides to deviate, it will choose among the channels for which there is at least one receiver. Only the default channel of a receiver for the next BigSlot is known. The sender will deviate from its home sequence just in time to listen on the receiver’s home sequence when BigSlot of the receiver begins. To alleviate collision, McMAC uses carrier sensing and a contention window. When a node visits a new channel, it first perform carrier sensing to check if there is ongoing transmission. If the channel is idle, it waits for a random duration of contention window CW between 1 and CWmax . If no packet is detected for this random period of CW , the sender will start transmission of its data packet to the receiver. If the beginning of other packet transmission is detected, the sender halts the counting, and returns to its home sequence. III. N ETWORK AND S IMULATION M ODEL We created two different network scenarios in order to study McMAC under different assumptions of available channels, link speed, and number of nodes. These two simulation scenarios are called 802.11b and 802.11a because they are modeled after 802.11 network parameters. In the 802.11b scenario, there are 20 devices, 3 channels, and each channel has a data rate of 2 Mbps. In the 802.11a scenario, there are 40 devices, 12 channels with a rate of 6 Mbps each. In both scenarios, channel switching time is assumed to be 100µs, while the time required for RTS/CTS is 200µs and 812µs respectively for 802.11a and 802.11b scenarios. We developed a simulation in Matlab to study and validate the McMAC protocol. The simulator is a discrete time simulator in which each discrete time unit corresponds to the time required for an RTS/CTS exchange. Each device hops using its own sequence characterized by a hopping signature. The simulator simulates a single collision domain. IV. P ERFORMANCE C OMPARISON WITH OTHER P ROTOCOLS In [6], we classified existing multi-channel MAC protocols into four categories. Through mathematical analysis and simulation, we showed that the Parallel Rendezvous class of

protocols has the best overall performance. Our McMAC protocol belongs to the Parallel Rendezvous family of protocols. Here, we briefly recap the performance difference between Parallel Rendezvous (specifically McMAC) and other classes of protocol. We compared McMAC with different multi-channel MAC protocols using two simulation scenarios: 802.11b and 802.11a as mentioned above. The packets generated have a random length with a geometric distribution with average length of 1 KB or 10 KB. One should think of the packet length as the amount of data a device can transfer after each channel agreement since there is no queueing. The bar charts of Fig. 2 shows that congestion of control channel happens when packets are short 1 for both 802.11a and 11b scenarios. 802.11b Short & Long Packets 6 5

) 4 s p b M ( tu 3 p h g u o rh T 2

simLite Analysis

V. D ESIGN T RADEOFFS A. LQF vs. Random Scheduling We considered two scheduling policies: random selection and longest queue first (LQF). LQF is attractive because it increases the average amount of data transferred after each rendezvous and hence can improve throughput. However, one interesting observation is that LQF can lead to degradation of performance and even cause instability. To illustrate this point, we consider a network of 10 nodes hopping over 3 channels. The link speed is 2Mbps. Each node has 5 unidirectional CBR flows to 5 neighbors chosen at random. Hence, there are a total of 50 unidirectional flows among the 10 nodes. The total throughput of these connections is 4.8Mbps, which is 80% of the total available bandwidth of all 3 channels combined. As shown in Fig.3, using LQF, the length of queues grow without bound. However, if each sender chooses a receiver uniformly at random (i.e., random scheduling), the queue lengths are bounded. The reason for this difference is that using LQF, occasionally, due to randomness of arrival and medium contention, multiple senders choose to send to the same receiver at the same time. This causes higher contention for the receiver. As a result, the queues for this receiver builds up faster at all other senders who are trying to send to this receiver, thereby creating a vicious cycle.

1

10000

) ) ) ) (s (s (s (s d lit ac on de sp m m c m m co

9000

(l) (l) (l) (l) d lit ac on de m sp m c m m co

Total Queue Length (packets)

0

802.11a Short & Long Packets 70 60 50 )s p b (M40 tu p h g 30 u ro h T 20

sim Lite analysis

LQF Random

8000 7000 6000 5000 4000 3000 2000 1000 0

0

10

20

30

40

50

60

Time(s)

70

80

90

100

10 0

) ) ) ) (s (s (s (s d lit ac on de sp m cm m m co

Fig. 3. Instability of LQF policy (80% load) compared to random scheduling. (l) (l) (l) (l) d lit ac on de sp m cm m m co

Fig. 2. Throughput predicated by the analysis vs. simulation. Top: 802.11b setting Bottom: 802.11a setting.

Although parallel rendezvous protocols show better performance than single rendezvous protocols, there are still many open questions regarding the parameter settings and scheduling policy that can significantly affect performance. In the rest of the paper, we explore the different parameter settings in depth.

1 Refer

to [6] for the details on the analytical model.

B. Effects of Pdeviate McMAC has the deviation probability parameter to control how likely a node deviates from its default hopping sequence. In this section, we study the effects of Pdeivate on the delay and determine a reasonable value of Pdeviate . We vary it from 0.2 to 0.8 with a step size of 0.2 and observe the average delay experienced by packets. We also vary the total load from 0.2 to 0.8. As a reminder, the load reported is per channel. We ran the simulations under two network scenarios as described in Sec.III. The traffic is a mix of 50% CBR flows and 50% random short file arrivals. CBR flows are unidirectional with a constant packet sizes of 1KB. Each node has 5 outbound CBR flows. The size of short files has a geometric distribution

Total load Prefer local Pdev = 0.2 Pdev = 0.4 Pdev = 0.6 Pdev = 0.8

20%

40%

60%

80%

N

Y

N

Y

N

Y

N

Y

13.3

13.2

26.0

25.3

252.2

198.5

1448.6 1101.0

11.7

11.6

22.7

22.6

383.7

238.7

1694.3 1105.1

10.2

10.3

21.7

21.7

611.0

265.6

2265.8 1151.5

9.6

9.6

23.7

21.7

974.5

312.7

3028.4 1146.9

TABLE I PACKET DELAY ( IN ms) WITH AND WITHOUT PREFERENCE GIVEN TO LOCAL RECEIVERS USING

802.11 B NETWORK SETTINGS .

Total load Prefer local Pdev = 0.2 Pdev = 0.4 Pdev = 0.6 Pdev = 0.8

20%

40%

60%

80%

N

Y

N

Y

N

Y

N

Y

13.0

12.9

73.1

68.5

479.4

381.8

1806.5 1487.2

8.9

8.9

92.0

70.7

697.0

412.0

2168.6 1505.5

7.2

7.1

210.9

103.0

1109.6 453.3

2824.2 1531.3

6.4

6.4

768.7

171.3

2185.3 494.4

3995.7 1556.8

TABLE II PACKET DELAY ( IN ms) WITH AND WITHOUT PREFERENCE GIVEN TO LOCAL RECEIVERS USING

802.11 A NETWORK SETTINGS .

C. Adaptive Probability of Deviation with an average of 1KB. File traffic arrive uniformly random among all pairs of nodes. The results of both 802.11a and 11b simulations follow similar trends. We present the delay results for the 802.11b network settings in Fig.4. Observe that when load is heavy, a larger Pdeviate leads to a higher delay, while the opposite is true when the load is light. The reason is that when load is high and if Pdeviate is also high, too many nodes deviate from their default hopping sequences to attempt transmission. In turn, it is harder for senders to find their receivers as too many of these receiver nodes are away from their default hopping sequence. On the other hand, when the network load is light, a higher deviation probability means senders wait a short time before meeting their receivers, thereby reducing delay. These results suggest using a higher Pdeviate such as 0.6 when the system load is low, and using a small value such as 0.2 when the system load is high. The system load can be easily measured by the fraction of time that the medium is busy (i.e., when carrier-sense is high.) In the next section, we explore an alternative method to achieve the same effect without explicitly changing Pdeviate .

4

10

Load = 0.8 3

Delay (ms)

10

Load = 0.6

2

10

Load = 0.4 1

10

Load = 0.2

0

10 0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

P

deviate

Fig. 4. Delay performance for different values of system load and probability of deviation Pdeviate under 802.11b assumptions.

In the previous section, we pointed out Pdeviate can have a large effect on the delay. The goal of adapting Pdeivate is such that a node spends more time listening if channel load is high. One observation is that a node can listen for its own packet while waiting to send to a receiver, as long as it does not need to deviate from its default sequence to send to the receiver. This can be done by always preferring to send to receivers who are on the same channel as the sender itself at the moment it wants to send. Furthermore, as the system load increases, it becomes more likely that queues for multiple receivers will be backlogged. As a result, a sender is more likely to find a receiver whose default hopping sequence happen to coincide with itself at that moment. This allows the sender to send without having to deviate from its hopping sequence. During the backoff countdown process, if a frame destined for the sender arrives, the sender can abort its own transmission and receive immediately. We modified the scheduler to always checks if a potential receiver will happen to be on the same channel as itself. And if so, it will not try to deviate. Instead, the local receiver is chosen. We simulated two network scenarios again with both local receiver preference turned on and off. In Tab.I, we show the average delay in the case of the 802.11b network settings. When the network load is light to medium (20%, 40%), the difference between using receiver preference or not is negligible. There is some small dependence between Pdeviate and delay. When the network load is at 60%, as Pdeviate increases 4-fold from 0.2 to 0.8, the delay increases by only about half from 198.5ms to 312.7ms if local receivers are preferred. However, without such preference, the delay increases almost 3 times from 252.2ms to 974.5ms. This shows that the local receiver preference heuristics is effective in both reducing the delay and also the sensitivity to the choice of Pdeivate . This advantage is even more pronounced when network load further increases to 80%. Again, when one considers the 802.11a settings, the results shown in Tab.II point to the same conclusion. For instance, when the load is very high at 80%, there is hardly any increase in the delay when Pdeviate increases from 0.2 to 0.8. In short,

Fig. 5.

Implemented on a testbed of 802.15.4-equipped nodes (Telos).

by preferring local receivers over the others, the scheduler manages to reduce the time a sender needs to deviate from its default hopping sequence and as a result reduces both delay and the sensitivity to the Pdeviate parameter. D. Implementation Results We have implemented a simplified version of McMAC on the Telos sensor network platform running TinyOS[11] as shown in Fig. 5. This platform uses an 802.15.4 radio operating in the 2.4GHz ISM band. The reason for choosing this platform is that it allows us to have low-level control of the radio and timing, as compared to more rigid 802.11a/b/g-based platforms. Unfortunately, these lower power devices are not suitable for high data-rate experiments. The micro-controllers on this platform is too slow to saturate the radio link. As a result, the achievable throughput of this platform is much lower than the link rate of 250kbps. Nonetheless, the platform is useful for our proof-of-concept implementation. In this implementation, we use a short dwell time (i.e. BigSlot) of 3.9ms as a stress test. The time to switch channel on this platform is about 300µs. Nodes hop randomly and independently over 4 channels. They beacon every 3 seconds. Each beacon contains a 4-byte time stamp. Using the timestamp and the MAC address of the sender, any neighbor can discover and predict this sender’s future hopping sequence. After discovery, a node can send data packets to the discovered neighbor. Our experiments involving 15 nodes show that McMAC correctly coordinates senders and receivers to rendezvous on the right channel about 98% of the times. In addition, node pairs are synchronized to within 200µs over 99% of the times. Therefore, we conclude that (i) McMAC is practical even on resource-limited devices, and (ii) commercial-off-the-shelf radios can easily support a channel hopping scheme such as McMAC. VI. C ONCLUSION In this paper, we proposed a new multiple channel MAC protocol that can make multiple agreements simultaneously. Compared to existing multi-channel MAC protocols require that channel agreements be made on a single rendezvous channel and hence suffer from control channel congestion, our

proposed protocol allows different node pairs to rendezvous concurrently on multiple channels. Parallel rendezvous protocols improve performance significantly compared to traditional single rendezvous multi-channel protocols when data packets are short or when a large number of channels are available. We studied various design tradeoffs in the design of this protocol. Specifically, we explored the use of a longest-queue-first scheduling policy and found it to exhibit stability problems under certain traffic conditions. We also studied the relation between delay and the deviation probability. The use of a simple heuristics of favoring receivers on the same channel as the sender can dramatically reduces such dependence. Finally, we implemented McMAC on the Telos platform to prove the feasibility of our proposal. This work was supported in part by the National Science Foundation under Grant CNS-0435478 and in part by by grant No. R01-2006-000-10753-0 from the Basic Research Program of the Korea Science & Engineering Foundation. The authors would like to thank them for their support. R EFERENCES [1] Emmanuelle Anceaume and Isabelle Puaut. Performance evaluation of clock synchronization algorithms. Technical Report RR-3526, INRIA, 1998. [2] P. Bahl, R. Chandra, and J. Dunagan. Ssch: Slotted seeded channel hopping for capacity improvement in ieee 802.11 ad-hoc wireless networks. In MobiCom, 2004. [3] J. Chen, S. Sheu, and C. Yang. A new multichannel access protocol for ieee 802.11 ad hoc wireless lans. In PIMRC, volume 3, pages 2291 – 2296, 2003. [4] Y. S. Han, J. Deng, and Z.J. Haas. Analyzing multi-channel medium access control schemes with aloha reservation. IEEE Transactions on Wireless Communications, 5(8):2143–2152, August 2006. [5] Wing-Chung Hung, K.L. Eddie Law, and A. Leon-Garcia. A Dynamic Multi-Channel MAC for Ad-Hoc LAN. In Proc. 21st Biennial Symposium on Communications, pages 31–35, Kingston, Canada, June 2002. [6] Jeonghoon Mo, H. Wilson So, and Jean Walrand. Comparison of multichannel mac protocols. In the 8-th ACM/IEEE International Symposium on Modeling, Analysis and Simulation of Wireless and Mobile Systems, October, 2005. [7] S. K. Park and K. W. Miller. Random number generators: good ones are hard to find. Commun. ACM, 31(10):1192–1201, 1988. [8] Kay Romer, Philipp Blum, and Lennart Meier. Time synchronization and calibration in wireless sensor networks. In Handbook of Sensor Networks: Algorithms and Architectures, pages 199–237. John Wiley and Sons, September 2005. [9] H. W. So, G. Nguyen, and J. Walrand. Practical synchronization techniques for multi-channel mac. In MobiCom ’06: Proceedings of the he Twelfth Annual International Conference on Mobile Computing and Networking, New York, NY, USA, 2006. ACM Press. [10] Jungmin So and Nitin Vaidya. Multi-channel mac for ad hoc networks: Handling multi-channel hidden terminals using a single transceiver. In ACM International Symposium on Mobile Ad Hoc Networking and Computing (MobiHoc), May 2004. [11] The TinyOS Project. http://webs.cs.berkeley.edu/tos/. [12] A. Tzamaloukas and J. Garcia-Luna-Aceves. Channel-hopping multiple access with packet trains for ad hoc networks. In In Proc. IEEE Mobile Multimedia Communications (MoMuC ’00), Tokyo, 2000. [13] Asimakis Tzamaloukas and J. J. Garcia-Luna-Aceves. Channel-hopping multiple access. In ICC (1), pages 415–419, 2000. [14] Shih-Lin Wu, Chih-Yu Lin, Yu-Chee Tseng, and Jang-Ping Sheu. A Dynamic Multi-Channel MAC for Ad-Hoc LAN. In Proc. International Symposium on Parallel Architectures, Algorithms and Networks (ISPAN ’00), page 232, Dallas/Richardson, Texas, USA, December 2000. [15] Shih-Lin Wu, Yu-Chee Tseng, Chih-Yu Lin, and Jang-Ping Sheu. A Multi-channel MAC Protocol with Power Control for Multi-hop Mobile Ad Hoc Networks. The Computer Journal, 45:101–110, 2002.