A Multi-Channel MAC Proposal for Ad-Hoc Wireless ... - CiteSeerX

17 downloads 75588 Views 48KB Size Report
frequency-agile radio. Currently, we focus on .... 2) Bi-directional Transfer When a sender has finished sending data, the receiver may proceed to send data back.
McMAC: A Multi-Channel MAC Proposal for Ad-Hoc Wireless Networks Hoi-Sheung Wilson So, Jean Walrand Department of Electrical Engineering and Computer Sciences University of California, Berkeley, CA 94720 {so,wlr}@eecs.berkeley.edu

Abstract Traditionally, all devices of an ad hoc wireless network uses the same frequency band (or channel) for communication. Quite often, however, multiple channels are available but each device cannot operate on all channels concurrently. In such case, multi-channel MAC protocols enable pairs of devices to communicate on different channels simultaneously to increase network throughput. In this paper, we describe one such protocol called McMAC. The goal of this protocol is to increase the throughput of an ad hoc network in which each device has only 1 frequency-agile radio. Currently, we focus on the simple case where the ad hoc network is single hop.

I. I NTRODUCTION 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 device problems. A complete multi-channel MAC solution must address both issues. However, in this paper, we restrict ourselves to the simpler case in which devices are within 1 hop of each other. This can be the case for a group of people in the same room communicating with their notebook computers. This simplification allows us to focus on the first issue for now. Note that, given more spectrum, there are other ways to increase the capacity of an ad hoc network. For example, one can design a more sophisticated radio to modulate a wider bandwidth to achieve a higher link speed. The use of a multi-channel MAC complements, rather than competes with, wide-band radios. Given the cost and engineering constraints, one should build a radio that can modulate as much bandwidth as possible. Additionally, a multi-channel MAC protocol enables the network, as a whole, to efficiently use more spectrum than is feasible with a single radio. II. R ELATED W ORK The simplest multi-channel MAC protocol is to equip each device with one radio per available channel, but such approach is not economical. With fewer radios than available channels, a multi-channel MAC protocol must coordinate the communicating devices so that a sender and its receiver tune their radios to the same channel during data transfer. In this section, we survey several existing multi-channel MAC protocol proposals and discuss their common limitation. In the next section, we will introduce an improved MAC based on the central idea of parallel rendezvous. A. Existing approaches to Multi-Channel MAC The traditional multi-channel MAC proposals can be classified into 3 generalized categories: (i) dedicated control radio, (ii) split-phase, and (iii) common hopping sequence. In the dedicated control radio approach, each device is equipped with one control radio and one data radio. The control radio is always tuned to the control channel where all devices contend for access to any of the data channels. Since each device always listens to the control channel, it can overhear control messages from its neighbors to easily keep track of the status of all channels and neighbors. This approach is used in by DCA [8], DCA-PC[9],

2

and DPC[1]. When a device A wants to send to device B, it first checks that A itself has a free data radio and a free channel. If so, using the control radio, A sends a Request-To-Send (RTS) message to B including a list of free channels that are acceptable to A and the proposed duration of the data transfer. Upon receiving the RTS message, B compares the list of proposed channels to its own list of free channels. B chooses a common channel that is also free and returns a Clear-to-send (CTS) message indicating the chosen channel and duration. Others who overhear the CTS should refrain from sending on that channel during the stated duration. Finally, A optionally responds with a reservation packet announcing to its neighbors that the proposed channel should not be used for the time being. In the split-phase approach, the time is divided into fixed periods, each consisting of a control phase and a data phase. In control phases, all devices meet on a default channel to exchange control messages to decide how to assign themselves to the various available channels during the immediately following data phases. MMAC[4] uses this approach. In the control phase of each period, devices waiting to send packets broadcast a message proposing to meet one of its receiver on one of the available channels. This message includes the channel preferences of the sender. The prospective receiver either accepts or denies the proposal. Since each device can only choose one channel during each period, the receiver cannot accept a proposal if it has already committed to meeting another device on a different channel. If accepted, receiver returns a confirmation message. The neighbors who overhear the proposal and confirmation requests try to choose the channel with the least number of device pairs in order to load balance among all channels. This control phase goes on for a fixed amount of time after which the devices switch to their agreed channels for the data phase of the period. In the common hopping sequence approach, all devices that are not actively sending or receiving follow a common hopping sequence through all the channels. A common hopping sequence guarantees senders can use RTS/CTS to find their prospective receivers if they are not currently busy. Devices overhear control messages destined for others in order to keep track of which channels and devices are busy. When a device has a packet to send, it broadcasts an RTS in the current common hop after a random delay and waits for the receiver to return a CTS. If the receiver returns a CTS, the two stop hopping and remain in the current channel to transfer data packets. The channel on which RTS/CTS occurs has then been implicitly reserved by the two devices. All other devices continue to follow the common hopping sequence. If the data transfer does not finish by the time the common hopping sequence wraps around and visits the same channel, the pair must broadcast again to reassert their ownership of the channel. The devices do not have to explicitly keep track of the status of the other devices but doing so can improve the efficiency of the network by avoiding sending RTS to busy devices. This common hopping sequence technique is employed by HRMA[5], CHMA[7], and CHAT[6]. B. Limitations of existing schemes These three approaches have a common feature: all devices waiting to transmit always converge on the same channel. The difference among these approaches is that in the dedicated control radio and the common channel approaches, all medium access requests are always resolved on the same contention channel. In the common hopping sequence approach, the contention channel changes over time. But in all three approaches, the contention channel can become a bottleneck when the data packets are not much longer than the control packets or when a large number of channels is available. If Lc and Ld are the average lengths (in bits) of control and data packets respectively. Let k be the minimum number of control messages that must be exchanged for each data packet. If the speed of the radios is S bits/s, then the contention channel will be saturated when the data packets arrive faster than S/(kLs ). Therefore, the data throughput will be limited to SLd /(kLs ) regardless of the number of channels available. This problem of contention channel saturation has been identified by several authors (DPC[1], DCA[8], DCA-PC[9], and HRMA[5]) as the reason for the inability to use more channels efficiently. DPC simulation results shows that it uses up to 4 channels effectively. DCA uses 7 channels well, but completely saturates at 11 channels. HRMA shows that fewer than 20 channels can be used effectively. III. D ESIGN In this section, we introduce McMAC, a multi-channel MAC protocol that allows devices to rendezvous simultaneously on different channels.

3

Thop

Overlap

Channel 4 Channel 3 Channel 2 Channel 1

A

B

A A

B

A A

B

B

B

B B

B

A A

A

Time

Fig. 1.

Pseudo-random home sequences of devices A and B. They are independent and overlaps from time to time.

A. Discovery Discovery is the process in which devices learn about other 1-hop neighbors in the network. In McMAC, each device hops over all available channels every Thop micro-seconds in a pseudo-random fashion. The devices need not hop at the same instance. This allows networks to merge or split easily without requiring devices to re-align their hopping time boundaries. The hopping sequences are defined by a common pseudo-random number generator but with seeds chosen by devices independently. We called the sequence chosen by a device its home sequence. Using seeds of 4 bytes long, the chance of two devices picking the same hopping sequence is negligible. Each device choose a seed at startup and it does not change. A device may deviate from its home sequence briefly during data exchange. Every packet sent includes the seed of the sender, the current index into its random hopping sequence, and the time remaining until the next hop. As a result, upon hearing any packet, the receiver can immediately predict the future hopping sequence of the sender. If a device does not have any packet to send for a long time, it generates empty beacon packets approximately every Tbeacon seconds on the average to ensure that newcomers to the network can quickly discover them. B. Rendezvous Rendezvous is the process in which a sender makes an agreement with the receiver to use the same channel for data transmission. In the 3 schemes presented earlier, at most 1 channel is used for rendezvous at any given time. Using McMAC, however, the rendezvous process can happen on multiple channels simultaneously. We define a hop to be a period of Thop seconds during which the home sequence of a device remains unchanged. At the beginning of each hop, each device with a send backlog flips a coin. With probability Ptx , it allows itself to deviate from its home sequence. Otherwise, it follows its home sequence and transmits during this hop only if there is a receiver whose home sequence overlaps with its during the upcoming hop. If it deviates, it must first choose a channel among all the channels for which it has a receiver. Next, it chooses a receiver among all receivers on that channel. The procedure for choosing a channel and a receiver is summarized in Fig.2. After the channel and the receiver have been chosen, the sender changes its channel to that of the receiver’s and senses the carrier for a random period between Tcs and Tcs + Tcs × Wmax . Tcs is the minimum time needed to sense carrier on the medium. Wmax is a fixed integer parameter. The additional random wait time is required to resolve contention among multiple devices waiting to transmit on the same channel. IV. I MPROVEMENTS There are many possible variations on the basic McMAC protocol. We discuss several ones that are likely to improve performance. 1) Send Time Limit When a sender makes an agreement with the receiver, it is possible for the sender to send more than 1 packet to the same receiver without contending for the channel again. Doing so would be less fair to other senders in the short term, but it will increase the achievable throughput of the network in the long run. The maximum duration for which a sender can monopolize a channel is called the send time limit. 2) Bi-directional Transfer When a sender has finished sending data, the receiver may proceed to send data back to the sender without contending. This is potentially useful for devices running a reliable transport protocol such as TCP for which the communication is always 2-way.

4

Transmit if potential receivers are present

1-P TX

Follow Home Sequence Listen if no potential receivers are present

Beginning of a Hop

1/k 1/k P TX

Fig. 2.

Deviate from Home

1/k 1/k 1/k

Ch k w/ receiver(s) : : Ch 3 w/ receiver(s) Ch 2 w/ receiver(s) Ch 1 w/ receiver(s)

Randomly choose a receiver on this channel. : : Randomly choose a receiver on this channel.

Procedure to determine whether to stay with the home sequence or deviate from it.

3) Hopping Period Hopping period Thop is the amount of time a device dwells on each channel of its home sequence. It is an adjustable parameter. On one extreme, the hopping period is infinite, and hence the home sequence of each device is a constant. This requires no synchronization between devices but load imbalance might occur if popular receiver devices happen to choose the same home channel. On the other extreme, a short hopping period means the devices change channels frequently. It makes load imbalance among channels highly unlikely but requires devices to synchronize more accurately. It also wastes more time due to channel switching. 4) Device Status Gossip One potential problem is when a device is busy sending or receiving away from its home sequence, others continue to try to make agreement with it futilely. To alleviate this problem, a device can keep track of the duration for which its neighbors are busy. In each packet (including RTS, CTS, and data packets), the sender includes the duration for which it will use the channel. This allows the neighbors overhearing the packet to refrain from sending to the sender or receiver during the stated period. To increase the effectiveness of the bookkeeping, albeit at an increased overhead, each device can share information it has collected with others. To do so, each device appends a list of current senders and receivers on each channel (if known), and their busy durations to each packet sent. Others who overhear this information can then merge this information with their own. This gossiping is more effective when senders and receivers tend to occupy the channel for relatively long periods of time. 5) Channel Status Gossip Another problem is that when a channel is being occupied, no new agreement can be made on the channel. It is therefore useless to visit a busy channel when a node decides to deviate. To alleviate this problem, a sender should ignore potential receivers on channels that are known to be busy. This can be achieved by using the same information exchanged as the Device Status Gossip. 6) Deviate when Busy If a device knows the next hop of its home sequence will land on a busy channel, it should always become a sender and find a free channel elsewhere if possible. 7) Favor Local Receiver It is possible that when the load is high, all devices are backlogged. As a result, many devices will try to deviate from their home channel making it difficult for any device to find their receiver. The probability of deviation (Ptx ) must therefore adapt to the load. One simple heuristic to adapt Ptx is to disallow deviation when the sender has at least 1 potential receiver during the upcoming hop on its home sequence. V. C ONCLUSION In this paper, we have considered the problem of designing an efficient multi-channel MAC protocol for an ad hoc wireless network in which each device has one frequency-agile radio. We explained that existing multi-channel MAC protocols require that all channel agreements be made on a single rendezvous channel. As a result, they cannot use many channels effectively. Our proposed McMAC protocol, on the ohter hard, allows different pairs of nodes to rendezvous concurrently on multiple channels. thereby improving performance when data packets are

5

short or when a large number of channels are available. A more careful study of the performance of McMAC under different conditions is required to turn McMAC into reality. R EFERENCES [1] 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. [2] IEEE. IEEE 802.11a-1999 (Supplement to IEEE Std 802.11-1999), High-speed Physical Layer in the 5GHz Band, 1999. [3] Jinyang Li, Charles Blake, Douglas S. J. De Couto, Hu Imm Lee, and Robert Morris. Capacity of ad hoc wireless networks. In Mobile Computing and Networking, pages 61–69, 2001. [4] Jungmin So and Nitin H. Vaidya. A multi-channel mac protocol for ad hoc wireless networks. Technical report, UIUC, 2003. [5] Z. Tang and J. Garcia-Luna-Aceves. Hop Reservation Multiple Access (HRMA) for Multichannel Packet Radio Networks. In Proc. of the IEEE IC3N’98, Seventh International Conference on Computer Communications and Networks, 1998. [6] 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. [7] Asimakis Tzamaloukas and J. J. Garcia-Luna-Aceves. Channel-hopping multiple access. In ICC (1), pages 415–419, 2000. [8] 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. [9] 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.