Collision-Avoidance Transmission Scheduling for Ad-Hoc ... - CiteSeerX

Collision-Avoidance Transmission Scheduling for Ad-Hoc Networks Zhenyu Tang and J. J. Garcia-Luna-Aceves Computer Engineering Department University of California Santa Cruz, CA 95064 ktang,[email protected] Abstract— A novel multichannel schedule-based Medium Access Control (MAC) protocol for ad-hoc networks, named collision-avoidance transmission scheduling (CATS) is introduced. CATS allows nodes to contend for and reserve data channels for specific time slots by means of distributed reservation and collision-avoidance handshakes. Contention is limited among nodes within two hops of one another, which provides a very efficient spatial reuse of the bandwidth available. CATS ensures that no collisions occur in successfully reserved data links, even when hidden terminals exist. Reservations in CATS support unicasting, multicasting and broadcasting at link level simultaneously and adapt to dynamic data size. The throughput achieved by CATS is analyzed for unicast traffic and broadcast traffic. Numerical results show that CATS can achieve very high throughput.

I. I NTRODUCTION Ad-hoc networks (i.e., multi-hop packet radio networks), which have received considerable attention recently for both commercial and military applications [1], are an ideal technology to provide a seamless extension of the Internet to the wireless environment. Medium access control (MAC) protocols, with which nodes (stations or packet radios) coordinate their access to the shared radio channel, are of great importance in adhoc networks. The multi-hop propagation nature of ad-hoc networks poses difficult problems, such as the “hidden-terminal” problem, to MAC protocols and makes it important to achieve spatial reuse of the bandwidth available. Many MAC protocols have been developed for multi-hop packet-radio networks, which mainly fall into two dominant types, random access, and scheduled access approaches. CSMA was the first random access protocol to be used in multihop packet-radio networks [2]. CSMA in multihop networks suffers from “hidden terminal” interference, which degrades CSMA’s performance to that of the pure ALOHA protocol [3]. Many collision-avoidance random MAC protocols have then been proposed and implemented to solve the hidden-terminal problem of CSMA. These protocols use three- or four-way “collisionavoidance” handshakes based on small control packets meant to avoid data collisions when sources of data packets cannot hear one another. Collision-avoidance protocols for wireless networks include SRMA [4], MACA [5], MACAW [6], IEEE802.11 [7] and FAMA [8], among many others. Two key performance limitations of all collision-avoidance MAC protocols are that: (a) they cannot provide inter-packet delay guarantees, which represents a big problem for real-time applications; and (b) they lack explicit support of multicasting or broadcasting, which implies that either a node must transmit the This work was supported in part by the Defense Advanced Research Projects Agency (DARPA) under Grant F30602-97-2-0338

same multicast packet multiple times, once to each multicastgroup neighbor, or packets are sent with likelihood of reception as low as the ALOHA protocol. A scheduled-access approach consists of establishing transmission schedules, i.e., allocating stations to different times and data channels (e.g., frequencies, spreading codes, or their combination) in a way that no collisions (conflicts) occur and efficient spatial reuse of the available bandwidth is achieved, which supports QoS and renders much higher channel utilization than such fixed assignment approaches as TDMA and FDMA. Because the minimum-length scheduling problem is NP-complete [9], [10] and normally needs complete topology information, most of the work on transmission scheduling protocols has focused on distributed sub-optimal solutions [10], [11], [12], [13], [14], [15]. An interesting class of transmission scheduling protocols proposed recently are topologytransparent, which guarantees that each node has at least one successful transmission among several transmissions in each frame using coding techniques [16], [17]. However, all these scheduled-access MAC protocols are designed either for broadcasting (node scheduling) or unicasting (link scheduling), but not both. We proposed a new scheduled-access protocol called CATA in [18], which supports unicasting, multicasting and broadcasting simultaneously. However, like most other topology-dependent approaches, CATA is based on a single channel. In this paper, we introduce a new multi-channel scheduledaccess protocol named collision-avoidance transmission scheduling (CATS) for ad-hoc networks based on CATA. Establishing multi-channel ad-hoc networks over ISM bands is simple to do using commercial frequency-hopping radios available today (and in 2.4 GHz band, for example, there are about 80 channels), and they exhibit important advantages over single-channel networks, namely: the ability to support multiple collision-free simultaneous unicast and multicast transmissions, improved delay characteristics and better fault tolerance. In fact, CATS is designed to work with commercially-available half-duplex slow frequency-hopping radios operating in ISM bands [19], such as those used in IEEE802.11 networks. Like CATA, CATS supports unicasting, multicasting and broadcasting simultaneously. CATS employs an enhanched handshake procedure over that used in CATA to eliminate the hidden-terminal problem, make and maintain reservations. The reminder of the paper is organized as follows. Section II specifies CATS in detail. Section III proves that CATS gener-

ates correct schedules, i.e., data packets are sent collision-free in the presence of hidden terminals. Section IV discusses the robustness of CATS to problem topologies, and the worst-case minimum frame length and number of data channels required for CATS’ proper operation. Section V provides an approximate throughput analysis of CATS and some numerical results. Section VI presents our conclusions. II. CATS P ROTOCOL A. System Model and Assumptions We assume that multiple orthogonal channels are available, which can be implemented by means of multiple frequency bands. The radios used are half-duplex and can only tune to one channel at a time, although they can switch to any of the available channels. Like previous MAC protocols based on transmission scheduling, CATS assumes that time is slotted and that slots are grouped into frames. Because of the handshake procedures needed, it is assumed that physical links are bi-directional. It is also assumed that time-overlapped transmissions at a receiver over the same channel (collision) causes the receiver to hear noise, however, if a packet does not collide with any other packet, it is received successfully. Noise and outside interference are ignored. At the link level, broadcast means simultaneous transmissions from a node to all its neighbors, multicast means simultaneous transmissions from a node to a subset of its neighbors, and unicast means a transmission from a node to one of its neighbors. CATS uses one channel for its control packets, which we refer to as the signaling channel (SCH). CATS uses a separate channel for broadcasting packets; this channel is called the broadcast data channel (BCH). The rest of the channels are used for unicasting or multicasting packets; these channels are simply called data channels (DCH). With the above assumptions, CATS’ basic service consists of reserving collision-free links for unicasting, multicasting or broadcasting. A link, therefore, refers to the assignment of a particular DCH or the BCH for a particular time slot over which a node can transmit data to one or multiple neighbors without interference from other nodes. For convenience, we refer to all the data that must be transmitted by a node to one or multiple neighbors over a given collision-free link (i.e., a reserved slot in a DCH or the BCH) as a flow or message. Data packets in the same message, therefore, can be addressed to different networklevel destinations sharing the same relay. Our description of CATS assumes a non-persistent random backoff policy for link reservations, i.e., when the reservation is not successful, CATS will back off for a random value of time before try again; however, other policies are also possible. In addition, error recover such as acknowledgement, time-out and retransmission, or stale reservation detection, is assumes to be left for higher layers. We consider relatively stationary networks in this paper. B. Protocol Description Small control packets are used for nodes to contend for and reserve links (i.e., data channels at specific slots); these packets are called beacons and are mostly sent over the signaling channel (SCH). There are seven classes of beacons in CATS,

namely: link reservation beacon (LRB), request broadcast beacon (RBB), request multicast beacon (RMB), request unicast beacon (RUB), stop broadcast beacon (SBB), stop multicast beacon (SMB) and concur-with-unicast beacon (CUB). As a minimum, a beacon specifies (a) the source address, (b) the destination address (a broadcast address, a multicast group address, or a node address), (c) the source’s reserved broadcast and multicast slots, and (d) the intended data channel (for the case of RUB or RMB). The operation of CATS is based on a few basic principles: 1. Senders and receivers must find one another easily. To accomplish this over multiple channels, a node in CATS must listen on the SCH, unless it is engaged in reserving a link or sending or receiving data over a link. 2. Data from a source must flow without interference from other sources over a reserved link, until conflicts due to mobility, errors due to the physical link, or the end of the flow are detected. Because of possible hidden terminals, the receiver(s) of a link must be the one(s) telling the potential sources that the link is reserved. 3. Links must be established over multiple available data channels. Because of possible hidden terminals, both sender and receiver(s) of a link must decide that the intended data channel for the link is available during a given time slot. 4. The sender of a broadcast or multicast link should not have to receive explicit feedback on the reservation from each neighbor. In CATS, this is accomplished with what amounts to negative acknowledgments to reservation requests, and by each node sending a beacon at the start of a slot in which it is busy receiving or sending. To accomplish link reservations according to the above principles, CATS divides a slot into six mini-slots, which, from the first to the last, are called MS1 to MS6. The first five mini-slots are intended primarily for control packets and are also called control mini-slots (CMS). The last mini-slot is meant for data and is also called data mini-slot (DMS). In practice, the DMS should be much longer than any CMS to attain high utilization. Fig. 1 illustrates how collision-free data are sent over a reserved link, and how broadcast, multicast and unicast links are reserved. Fig. 1(a) illustrates how data are transmitted over reserved links and links are identified as being reserved. MS1 is used to provide a “busy tone” to senders attempting to establish multicast or broadcast links. Every node that is sending or receiving data during the current slot sends an LRB in MS1 over the SCH; this beacon causes noise or is received by its neighbor nodes, which prevents them from attempting to reserve the slot for broadcast or multicast. In addition, for a unicast or multicast link, every receiver of the link must send an LRB during MS2 over the DCH assigned to the link, which serves as a “busy tone” for the reserved DCH to senders attempting to establish multicast or unicast links over it. Data can flow from sender to receiver(s) of a link during MS3 to MS6 over either a DCH (for unicast and multicast links) or the BCH (for a broadcast link). Figs. 1(b) to (d) show how broadcast, multicast and unicast links are reserved. During MS1, the sender of an intended reservation listens over the SCH to ensure that there is no busy tone

bcast

bcast

Frame

slot 1 slot 2

slot 3

slot 1 slot 2 LRB LRB LRB LRB LRB

Unicast Data Packet

SL

SL RBB

Broadcast Data Packet

Broadcast

SL

SL RBB Clear

(a) Identifying reservations and data flowing

SL RMB

SL

SL RMB

MS1 MS2

MS3

Unsuccessful multicast contention

RL SL

Clear MCD

MS4 MS5

Signaling CH

Successful multicast contention

MS6 Data CH

RMB: Request Multicast Beacon, SMB/N: Stop Multicast Beacon/Noise MCD: MultiCast Data, SL: Sender Listens, RL:Receiver Listens

(c) Making reservation for multicast

i

ucast mcast

mcast

ucast

(b)

(c)

Broadcast CH

(b) Making reservation for broadcast

slot L

SMB/N

i ucast

(a)

ucast

RBB: Request Broadcast Beacon, BCD: BroadCast Data SBB/N: Stop Broadcast Beacon/Noise SL: Sender Listens

Frame

slot 3

RL SL

bcast

ucast

Fig. 2. Types of channel re-use in CATS

MS1 MS2 MS3 MS4 MS5 MS6

Frame

SL

Successful broadcast contention

BCD

Signaling CH

Reserved Data CH's

LRB: Link Reservation Beacon

slot 1 slot 2

slot L Unsuccessful broadcast contention

SBB/N

Multicast

MS1 MS2 MS3 MS4 MS5 MS6 Broadcast CH

slot 3

i

Unicast

Multicast Data Packet

Signaling CH

mcast

Frame

slot L

slot 1 slot 2

slot L

slot 3

Unsuccessful unicast contention

SL

SL RUB RL

SL

SL RUB RL CUB UCD

MS1 MS2

MS3

C/N

MS4 MS5

Signaling CH

Successful unicast contention

MS6 Data CH

RUB: Request Unicast Beacon, UCD: UniCast Data, SL: Sender Listens CUB: Concur with Unicast Beacon, RL: Receiver Listens, C/N: Clear/Noise

(d) Making reservation for unicast

Fig. 1. Basic operations in CATS

for broadcast or multicast, or a beacon sent without collision by the intended unicast receiver. The sender of an intended reservation also listens over a channel during MS2. For a unicast or multicast link reservation, the sender listens over the target DCH to ensure that the channel is clear. For a broadcast reservation, the sender listens to the SCH again to catch any beacon. For a unicast reservation, the source sends an RUB during MS3 over the SCH if it does not hear a beacon from the intended receiver during MS1 and detects that the target DCH is clear during MS2. For a broadcast reservation, the sender sends an RBB during MS3 over the SCH if the SCH is clear during MS1. For a multicast reservation, the sender sends an RMB during MS3 over the SCH if the SCH is clear during MS1 and the target DCH is clear during MS2. If an RUB is received correctly at the intended receiver specified in the RUB, the receiver listens to the intended DCH during MS4 and sends a CUB during MS5 if the target DCH is free; otherwise, no CUB is sent in MS5. The sender of an RUB detects a successful unicast link reservation with the reception of the CUB. Data can flow over the unicast link for the rest of the time slot, and in the same slot and DCH in subsequent frames, until the unicast link is terminated. If a node receives a correct RBB during MS3 or detects the SCH clear during MS3, then it remains quiet during MS4; otherwise, it sends an SBB as a negative acknowledgment to any potential broadcast reservation being made. The sender of an RBB detects the failure of its broadcast reservation request when it either receives an SBB or detects noise during MS4. If the sender of an RBB detects the SCH clear during MS4, it concludes that the reservation is successful and can start transmitting in the BCH during MS5. The operation of CATS for multicast reservations is slightly different. If a node receives a correct RMB during MS3 addressed for a group to which the node belongs, then it listens to the target DCH specified in the RMB during MS4, and remains

quiet during MS5 if the DCH is free during MS4. Alternatively, if the node detects noise during MS3, it sends an SBB during MS4, and sends an SMB during MS5 if it receives a correct RMB for its group but detects noise in the DCH during MS4. The sender of an RMB assumes that the reservation is successful and can transmit over the target DCH during MS6 if it finds the SCH clear during both MS4 and MS5; it assumes that the reservation attempt fails otherwise. Fig. 2 illustrates the types of channel re-use allowed in CATS based on the above rules for establishing and maintaining reservations. As Fig. 2 shows, during a given time slot in the neighborhood of a node i, there can be only one broadcast link reserved incident from i, or one multicast link incident from i and multiple broadcast or multicast links incident to i’s nongroup-member neighbors and multiple unicast links incident to or from i’s non-group-member neighbors established after the multicast link incident from i is reserved, or one unicast link incident from i and multiple broadcast or multicast links incident to i’s non-destination neighbors or multiple unicast links incident to or from i’s non-destination neighbors reserved. We note that the algorithms and radio equipment needed for CATS are much the same as those needed for collisionavoidance MAC protocols. Furthermore, most handshakes via small control packets are only needed to reserve the link before communications start. After successful reservations, nodes only need to send beacons in MS1 and MS2. In an ad-hoc network of up to a few hundred nodes, a beacon need to be only a few bytes to specify sender, receiver, target channel and multicast or broadcast slots; on the other hand, time slots should be capable of supporting average-size IP packets and multiple acknowledgments to such packets. Therefore, the overhead of control mini-slots is small compared to the needed length of the data mini-slot. III. C ORRECTNESS

OF

CATS

The following theorems demonstrate that CATS can generate collision-free transmission schedules for broadcast, multicast and unicast simultaneously. We denote all the neighbors of node A by the set N (A). Theorem 1: CATS guarantees that no unicast data packets can collide with any packet at any destination in ad-hoc networks. Proof: It is obvious that collision in CATS could only happen between packets that are sent in the same slot or mini-slot over the same channel. Thus we only need to prove that data packets can not collide with one another. A node S wishing to reserve a DCH in a slot i for unicast transmission to its neighbor D sends an RUB to D over the SCH during MS3 of slot i only if S neither receives or transmits data in slot i nor hears any transmission over the target DCH in MS2. Because any node that receives data in a reserved DCH during

slot i sends an LRB over the reserved DCH during MS2 of slot i, once S is allowed to make reservation for the unicast link, it ensures that S ’s data transmission over the target link will not interfere with any existing data transmission. If the RUB from S is not successful at D,1 then S will not receive any CUB from D and will back off. Hence, S can not cause any data collision. Let us consider the case where RUB from S is successful at D. If D successfully receives the RUB from S , it must be true that no node other than D in N (S ) can receive a correct request beacon addressed to it in slot i, for otherwise the RUB from S would interfere with it. Therefore, D is the only one in N (S ) who sends CUB in MS5 and the CUB is collision free at S . It must also be true that no node other than S in N (D) is sending a request beacon in slot i, for otherwise there will be a collision in MS3 in the SCH at D. Therefore, the unicast data packets from S can not collide with any newly established data transmission in slot i at D. It also ensures that the unicast data from S will not collide at D with any existing transmission that can reach D because D sends the CUB only if it did not hear any transmission over the target DCH in MS4. Therefore, it follows that CATS guarantees that the unicast data packets are free of collision at any data destination. 2 Note that after a DCH at a slot is reserved for unicast, the LRB sent by the destination neighbor in the reserved DCH and slot (in MS2) is collision free at the source because the unicast destination is the only data receiver in the reserved DCH and slot in the source’s neighborhood. Theorem 2: CATS guarantees that no broadcast data packets can collide with any packet at any destination, and all neighbors of the source can receive the broadcast data packets collision free in ad-hoc networks provided that source nodes have one or more common listening neighbors. Proof: It is easy to see that there would be no data collision at any node if all source nodes are three or more hops away from one another. Accordingly, we only need to consider the cases in which sources are within two hops of one another. In CATS, node S contends for a broadcast link only when all its neighbors are neither sending nor receiving data in the intended slot i, because any node engaged in sending or receiving data in slot i sends an LRB during MS1 of slot i and S sends RBB in MS3 only when it did not detect any transmission in MS1. Hence, any newly established broadcast transmission does not collide with any existing data transmission and all oneor two-hop neighbors of S are either listening or sending request beacons over the SCH during MS3 of slot i. If any node X within two hops of S sends a request beacon in the same slot i, then there will be a collision at any of their common neighbors D, who is listening on the SCH. However, when D hears a collision in MS3 it sends an SBB in MS4, which forces S to back off and abort the intended reservation, thus no broadcast data can be transmitted during MS5. After MS5, all S ’s neighbors become aware of the reservation failure and no data collisions take place. If, on the other hand, S is the only node that contends for slot i within its two-hop neighborhood, then all neighbors of S will receive the RBB correctly and no

D

1 This can happen if in the same slot, either (a) experiences a collision in MS3 on the SCH, or (b) is transmitting or receiving data, or (c) is sending a request beacon.

neighbor will send SBB, which leads to a successful broadcast link reservation for S and guarantees that all S ’s neighbors can receive the broadcast data collision-free. 2 Theorem 3: CATS guarantees that no multicast data packets can collide with any packet at any destination, and all multicastgroup neighbors can receive the multicast data packets collision free in ad-hoc networks provided that the source nodes have one or more common listening neighbors. Proof: As in Theorem 2 we only need to consider the case where source nodes are within two hops of one another. As in the broadcast case, a node S wishing to make reservation for a multicast link sends an RMB in MS3 of an intended slot i only if no neighbor of S sends an LRB in MS1. Therefore, any newly established multicast transmission will not collide with any existing data transmission and all one- or two-hop neighbors of S are either listening or sending request beacons over the SCH during MS3 of slot i. If any node X within two hops of S sends a request beacon in the same slot i, then as in the broadcast case, a common neighbor of S and X , who is listening on the SCH, will hear the collision and send an SBB in MS4, which will force S to back off and stop making the multicast reservation. If, on the other hand, S is the only node that sends request in slot i within two hops of S , then all neighbors of S will receive the RMB correctly, in which case any addressed neighbor listens to the intended DCH during MS4 of slot i, and sends an SMB in MS5 if it detects any transmission. S reserves the intended DCH in slot i only if it does not hear any transmission in MS5, which indicates that no neighbors of S ’s multicast-group neighbors are sending data over the intended DCH in slot i, which in turn can interfere with the intended multicast transmission. Therefore, the multicast data from S are collision-free at all its group-member neighbors and all its group-member neighbors can receive the multicast data collision-free. 2 IV. ROBUSTNESS

AND

S CALING

A. Robustness to Problem Topologies It is possible (though not often) that the nodes contending for a broadcast or a multicast link do not have any common neighbor, or their common neighbors are also sending request in the same slot. If this is the case, a contending node who sends an RBB or RMB is not able to know whether any of its one-hop or two-hop neighbors is sending request beacon simultaneously. This will cause an undesired saturation in which some neighbor(s) of the broadcasting node or some addressed neighbor(s) of the multicasting node cannot receive the broadcast or multicast data because they are broadcasting or multicasting at the same time. This very problem was pointed out by Zhu and Corson [15] and solved in the protocol they proposed. Rather than resolving this unusual situation as part of the handshake rules as it is done in [15], CATS resolves these rare conflicts by asking the nodes to send beacons listing all the broadcast and multicast links they have reserved periodically within the data mini-slot. Furthermore, after a successful reservation of a broadcast and multicast link, the source sends a beacon listing all its reserved broadcast and multicast links during the data-mini-slot, picking randomly when in the mini-slot to send the beacon. Once a node finds in a beacon received that

any addressed neighbor is transmitting in the same slot as it is broadcasting or multicasting, it will reschedule its broadcast or multicast. A simple rule, such as “smallest node ID keeps the right for a link” can be used to resolve conflicts. In addition, keep in mind that the beacons sent in control mini-slots identify sender’s broadcast and multicast slots and it is likely that a node can receive a beacon from its neighbor. A node can resolve a conflict by rescheduling its broadcast or multicast transmission when it finds the conflict in a beacon. Accordingly, conflicting broadcast or multicast reservations can be reduced and finally eliminated. B. Frame Length and Number of Channels Required Frame length (number of slots per frame) is an important performance parameter for any MAC protocol based on time scheduling, because it directly affects inter-packet delay and channel reuse. The frame length for the fixed TDMA protocol with N nodes is N slots. The frame length needed by CATS to broadcast once very frame is equal to the maximum number of nodes in any two-hop neighborhood, which, in the worst case, is L = M infd2 + 1; N g slots, where d is the maximum node degree (number of neighbors a node has) of the network and N is the total number of nodes. Note N is normally much larger than d for a typical ad-hoc network, This result is the same obtained for the scheme proposed in [13], while topology-independent protocols have larger frame length. We state, without proof due to the limited space, that the worst-case minimum frame length needed for each node to unicast successfully once every frame in CATS is 2d slots provided that there are at least d data channels available, and the worstcase minimum frame length needed for each node to unicast successfully to each of its neighbors once every frame in CATS is 2(2d 1) provided that there are at least 2d 1 data channels available. The upper bound of the frame length in slots for singlechannel TDMA link scheduling is normally proportional to d2 , e.g., M infN d=2; 2d2 2d + 1g in [20]. It is interesting to note that the upper bound of frame length in CATS is only proportional to d. This is because CATS schedules transmissions jointly based on time and multiple data channels. Although the total resource (channels and slots) required is about the same order ((d2 )), CATS is a more attractive approach when smaller time delays are desirable. V. A PPROXIMATE T HROUGHPUT A NALYSIS A. Assumptions To simplify our analysis, we assume that either all flows are broadcast or all flows are unicast. Each node can reserve at most one transmission slot in each frame. If a node has no reserved transmission slot in a frame, the node is called an idle node in the frame and the frame is called an idle frame for the node; otherwise, the frame is called a transmitting frame for the node . We assume that reservation requests generated at each node form a Poisson source with a mean rate G requests per slot. The request can be generated for a new or retransmitted message. The CATS at each node can only buffer one message; it simply

discards any message passed from the upper layer if the buffer is not empty. An idle node will try to make reservation for a request arrival in the next slot. CATS discards any message when the reservation for it is not successful. This traffic model implies that a node can attempt to reserve a link in every slot and makes our results the worst case results, which can be improved with more sophisticated backoff algorithm. We consider variable-length flow and assume that, on the average, it takes Æ slots to send all the data packets in a flow, i.e., the average flow length (AFL) is Æ slots. For broadcasting we assume that the flow length is geometrically distributed, which implies that the probability that a broadcasting flow ends at the end of a transmission slot is q = 1=Æ . Throughput is defined as the probability that any given node has a reserved slot for transmitting data in any given frame. B. Unicast Throughput We first analyze the throughput of CATS when only unicast traffic exists. For simplicity, we assume a symmetric hyper-cube network topology in which each node has d neighbors and the neighbors of the same node are hidden from each other. The hyper-cube topology is a simple multihop topology. Although not reflecting the typical topology found in a real ad-hoc network, it constitutes the worst-case scenario for hidden-terminal interference and provides very useful insight on the performance of any reservation-based protocol. Assuming the same number of neighbors per node permits us to focus on any one node to analyze the throughput of the system. We assume that the reserved transmission slot for a node is uniformly distributed among all the slots in a frame and the data channel used for the transmission is uniformly distributed among all the data channels available. The destination of each flow from a node is uniformly distributed among all its neighbors. Each frame has L = 2d slots and there are C = d data channels available, which provide the worst-case minimum frame length and number of data channels for each node to unicast collision-free once every frame, as described before. We assume that the system is in stable operation and that steady state exists. Let PT be the steady state probability that a node has reserved a link for transmission in a frame. We observe that for any node, the idle period, consisting of one or more idle frames, and the transmitting period, consisting of one or more transmitting frames, always occur alternatively. This is because any successful data transmission must follow a successful reservation. For any node, an idle period (in frames) ends at the end of a frame if and only if the node successfully reserves a slot on an intended DCH. We denote by QI the probability that an idle node ends its idle period during a frame, and by PS the probability that an idle node makes a successful reservation in a slot. We denote by PR the probability that a node is receiving data in a frame. Due to the symmetry of the network topology and the traffic model for the whole system, it is reasonable to assume that PT = PR . To keep the analysis tractable, we assume that the transmissions or receptions of all the neighbors of any given node are independent on each other. Given that node A is idle, A can successfully reserve a given slot on an intended DCH to send data to one of its neighbors B

if and only if (1) A has an arrival in the previous slot; (2) none of A’s neighbors other than B is sending data to A or receiving data on A’s intended DCH in the given slot; (3) none of B ’s neighbors other than A is sending RUB, or sending data to B , or sending data to nodes other than B on A’s intended DCH in the given slot; and (4) B is not sending RUB or data in the given slot. We denote by P1 , P2 , P3 and P4 the probabilities that the above four conditions are satisfied, respectively. We therefore have: P1

=1



P2

= 1 (1 PT )PR L1 C1

G

e



= 1 (1

)

PT P1 P2

PT



PT

1 1 + (1 1 )P 1 1 d RL 1C Ld L

1  1 + (1 1 ) 1 )d L d d C

= PT (1 L1 ) + (1

PT

)(1

)

P1 :

= P P P P and QI is given by QI = 1 (1 PS )L :

Thus it follows that PS

1

2

1

(7)

3



(4)

= I +Æ Æ :

(6)

We now have a set of nonlinear equations in PT , which can be solved by iteration PT new = PT old . This procedure can converge with only a small number of iterations, and the throughput is simply S = PT . C. Broadcast Throughput We now present the throughput of CATS when only broadcast traffic is present. For simplicity, we consider a fully connected network with N nodes. Given that CATS guarantees collisionfree data transmission after reservation in the presence of hidden terminals, a fully connected network is the worst case scenario in terms of interference, contention or spatial reuse. Each frame therefore needs to have L = N slots. The system can be fully described by one state variable k; 0  k  L, the number of reserved slots, i.e., the number of nodes who have a reserved transmission slot, in a frame. We model the evolvement of the system as a discrete-time Markov chain, each state of which can transit to any state. A transition may occur

 i

=0

s t < s:

If the system is in state k , the probability that n data senders (n) end their flows during a frame, denoted by Dk , is

n Dk

( )

=

k  n

qn

(1

q

)k

n

0  n  k:

(8)

When calculating the transition probabilities, we will condition on the number of data senders ending their flows in a frame, n. For the transition from state k in frame f to state l in frame f + 1, at least n ^ = max(0; k l) nodes must end their flows in ^  n  k, and s = l (k n) nodes should frame f ; therefore, n each successfully reserve a slot in frame f + 1. The transition probability from state k to state l is thus given by

4

(5)

( )]t ;

(i; t; s) = [1 0;

1

:

The duration of the idle period can be modeled as a geometrically distributed random variable with a probability of ending in a frame being QI . Therefore, we obtain the mean idle period in frames I = 1=QI and that yields PT

( )] (i; t 1; s) + (i)(i 1; t 1; s 1)

 i

with the ending condition

(3) To simplify our analysis, we assume that if B is idle and has a flow arrival, it will send a RUB in the next slot. This simplifying assumption leads to a lower bound of PS and thus a lower bound of the throughput. With this assumption, P4 can be expressed as P4

(i; t; s) = [1

(1)

(2)

P3

when any data sender ends its flow or any idle node successfully reserves a transmission slot. Let k denote the probability that the system is in state k . Given our traffic model, an idle node contends for a slot with probability pa = 1 e G . The probability that with i idle nodes there is a successful reservation in an unreserved slot is given by (i) = ipa (1 pa )i 1 : Thus the probability that among i idle nodes there are s successful reservations in t unreserved slots can be expressed recursively as

Plk

=

k X (n) Dk (N

n=^n

k

+ n; L

k

+ n; l

k

+ n):

(9)

PL

We can solve the global balance equations l = k=0 k Plk PL with the condition l=0 l = 1, which yields the throughput of P the system S = L1 L k=1 k k: D. Numerical Results We present numerical results for several examples in this section. Fig. 3(a) shows the unicast throughput of CATS in a hypercube network where each node has 10 neighbors, there are 10 data channels available and the frame length is 20 slots. The throughput versus normalized offered load per node curves are plotted for various values of average flow length (AFL). As it should be expected, throughput grows significantly when AFL increases. For large AFLs, the throughput is close to that of fixed TDMA, whose throughput is close to one under very heavy load. However, CATS needs a much shorter frame length for practical ad-hoc networks (where N >> d2 ) and thus has much higher channel reuse ratio. Fig. 3(b) shows the effect of the network density (number of neighbors per node) on the performance. The figure shows the throughput of CATS for hyper-cube networks with AFL equal to 10 slots and each node having 10 or 20 neighbors. The curves indicate that the throughput is almost the same for the different network densities. This is because each system has enough slots per frame and data channels, i.e., 2d slots per frame and d data

0.8

0.8

0.7 0.6 0.5 0.4 0.3 0.2

AFL=100 AFL=10 AFL=2 AFL=1

0.1

the nodes’ transmission power to reduce their neighborhoods.

CATS: L=2d slots, C=d DCH’s, AFL=10 slots 1 0.9

Throughput per Node S

Throughput per Node S

BAMA: d=10, L=20 slots, C=10 DCH’s, AFL in slots 1 0.9

VI. C ONCLUSIONS

0.7 0.6 0.5 0.4 0.3 0.2

d=10 d=20

0.1

0

0 0

0.2

0.4 0.6 0.8 Offered Load per Node G

1

1.2

0

(a) Different values of AFL

0.2

0.4 0.6 0.8 Offered Load per Node G

1

1.2

(b) Different node degrees

Fig. 3. Unicast throughput performance of CATS

CATS: L=N slots, AFL=10 slots 0.9 0.8

0.8

0.7

Throughput per Node S

Throughput per Node S

BAMA: N=16 nodes, L=16 slots, AFL in slots 1 0.9

0.7 0.6 0.5 0.4 0.3 0.2

0.5 0.4 0.3 0.2

AFL=100 AFL=10 AFL=2 AFL=1

0.1

0.6

N=9 nodes N=16 nodes

0.1

0

0 0

0.1

0.2

0.3 0.4 0.5 0.6 Offered Load per Node G

0.7

(a) Different values of AFL

0.8

0.9

0

0.1

0.2

0.3 0.4 0.5 0.6 0.7 Offered Load per Node G

0.8

0.9

1

(b) Different numbers of nodes

We have described a new distributed MAC protocol for ad-hoc networks called the collision-avoidance transmission scheduling (CATS) protocol. CATS dynamically allocates unicast, multicast or broadcast links (i.e., data channels reserved during specific time slots of a frame) to nodes through a reservation and handshake mechanism, such that data packets are transmitted without hidden-terminal interference and spatial reuse of available network bandwidth is achieved. We have verified the correctness of CATS’ link reservation mechanisms. We showed analytically that CATS achieves very high throughput, especially with larger size flows, and that it requires smaller frame sizes than prior topology-independent transmission scheduling protocols. CATS is designed to operate well in ISM bands using simple half-duplex frequency-hopping radios such as those used in IEEE802.11 networks today. CATS’s simplicity and ability to provide channel-access delay guarantees and support for collision-free broadcast and multicast traffic makes it much more attractive than the collision-avoidance MAC protocols that are being explored for ad-hoc networks today.

Fig. 4. Broadcast throughput performance of CATS

R EFERENCES [1]

channels. However, networks with higher node density need larger frame length and more data channels. The range of traffic load within which the networks remain stable is larger with lower network densities, because CATS uses a common signaling channel and a larger number of neighbors per node leads to more contention in the signaling channel. Fig. 4(a) and (b) display the results for broadcast flows in fully-connected networks. Fig. 4(a) shows the broadcast throughput per node for a fully connected network with 16 nodes, 16 slots per frame, and AFLs varying from 100 slots to 1 slot. Fig. 4(b) exhibits the broadcast performance of fullyconnected networks where AFL equals 10 slots, the total number of nodes equals 9 and 16, and the frame length equals the number of nodes in the system. The results show that, for both unicast and broadcast, CATS achieves very high throughput for the range of traffic load within which the network is stable. As mentioned before, our traffic model makes our results the worst case results. The throughput and stability of CATS can be improved further with more sophisticated backoff algorithms or collision resolution algorithms. Reservations in ad-hoc networks tend to be long term since a node is both a host and a router, especially for broadcasting because they are needed for network control packets, for example, which leads to high throughput. Admittedly, the examples shown are simplistic in nature. However, they are indicative of the fact that CATS will perform very well in ad-hoc networks in ISM bands, in which the number of links available to a node (slots per frame times the number of orthogonal frequency hops available in the band) is much larger than the number of nodes in its two-hop neighborhood. This is particularly the case if we consider the possibility of controlling

[2] [3]

[4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20]

Special issue on wireless ad-hoc networks, Z. Haas eds. IEEE JSAC, 17(8), Aug. 1999. B. M. Leiner, D. L. Nielson, and Tobagi F. A. eds, Proceedings of the IEEE, vol. 75, no. 1, Jan. 1987. F. Tobagi and L. Kleinrock, “Packet switching in radio channels: Part II - the hidden terminal problem in carrier sense multiple-access modes and the busy-tone solution,” IEEE Trans. commun., vol. 23, pp. 1417–33, Dec. 1975. F. Tobagi and L. Kleinrock, “Packet switching in radio channels: Part III - polling and (dynamic) split channel reservation multiple access,” IEEE Trans. Comput., vol. 24, pp. 832–45, Aug. 1976. P. Karn, “MACA - a new channel access method for packet radio,” in Proc. ARRL/CRRL Amateur Radio 9th Comput. Networking Conf., 1990. V. Bharghavan et al., “MACAW: A media access protocol for wireless LAN’s,” in Proc. ACM SIGCOMM, 1994. IEEE P802.11 Draft Standard for Wireless LAN: Medium Access Control (MAC) and Physical Layer (PHY) Specifications, IEEE, July 1996. C. L. Fullmer and J. J. Garcia-Luna-Aceves, “Solutions to hidden terminal problems in wireless networks,” in Proc. ACM SIGCOMM, 1997. E. Arikan, “Some complexity results about packet radio networks,” IEEE Trans. Inform. Theory, vol. 30, pp. 681–5, July 1984. A. Ephrreamides and T. Truong, “Scheduling broadcasts in multihop radio networks,” IEEE Trans. Commun., vol. 38, pp. 465–60, Apr. 1990. L. C Pond and V. O. K. Li, “A distributed time-slot assignment protocol for mobile multi-hop broadcast packet radio networks,” in Proc. IEEE MILCOM, 1989. I. Cidon and M. Sidi, “Distributed assignment algorithms for multihop packet radio networks,” IEEE Trans. Comput., vol. 38, pp. 1353–61, Oct. 1989. I. Chlamtac and S. Kutten, “A spatial-reuse TDMA/FDMA for mobile multi-hop radio networks,” in Proc. IEEE INFOCOM, 1985. I. Chlamtac and A. Lerner, “Link allocation in mobile radio networks with noisy channel,” in Proc. IEEE INFOCOM, 1986. C. Zhu and M. S. Corson, “A five phase reservation protocol (FPRP) for mobile ad hoc networks,” in Proc. IEEE INFOCOM, 1998. I. Chlamtac and A. Farago, “Making transmission schedules immune to topology changes in multi-hop packet radio networks,” IEEE/ACM Trans. Networking, vol. 2, pp. 23–29, Feb. 1994. J.-H. Ju and V. O. K. Li, “An optimal topology-transparent scheduling method in multihop packet radio networks,” IEEE/ACM Trans. Networking, vol. 6, pp. 298–306, June 1998. Z. Tang and J. J. Garcia-Luna-Aceves, “A protocol for topology-dependent transmission scheduling in wireless networks,” in Proc. IEEE WCNC, 1999. FCC Rules and Regulations, Part15.247 and 15.249. October 1997. I. Chlamtac and A. Lerner, A link allocation protocol for mobile multihop networks. In Proc. IEEE GLOBECOM, 1985.