Reliable on-demand multicast routing with congestion control in wireless ad hoc networks

Transcription

1 Reliable on-demand multicast routing with congestion control in wireless ad hoc networks KenTang,MarioGerla Computer Science Department University of California, Los Angeles Los Angeles, CA ABSTRACT In this paper, we address the congestion control multicast routing problem in wireless ad hoc networks through the medium access control (MAC) layer. We first introduce the Broadcast Medium Window (BMW) MAC protocol, which provides reliable delivery to broadcast packets at the MAC layer. We then extend the wireless On-Demand Multicast Routing Protocol (ODMRP) to facilitate congestion control in ad hoc networks using BMW. Through simulation, we show that ODMRP with congestion control adapts well to multicast sources that are aggressive in data transmissions. Keywords: multicast, on-demand routing, congestion control, ad hoc network, broadcast medium window 1. INTRODUCTION Multicast routing in wireless ad hoc networks has gain considerable interest in recent years. The main benefit of multicasting is the significant reduction of network load gained when packets need to be transmitted to a group of nodes. Congestion control (at the network level) is vital in multicast since the most important form of congestion control in the Internet, TCP, is not practical in multicast due to ACK implosion. Moreover, overload control is essential in wireless networks where scarce bandwidth is the norm. Some multicast routing protocols include AMRoute 4, AMRIS 26, CAMP 8, multicast AODV 23, and the On-Demand Multicast Routing Protocol (ODMRP) 16, 17, 18. ODMRP disseminates multicast packets on a mesh instead of the traditional multicast tree. By using a mesh, ODMRP introduces redundancy to combat packet loss in ad hoc networks where channel noise, collisions and mobility are common. Under low traffic load, ODMRP performs well. However, as traffic load increases, ODMRP progressively suffers from network congestion. This deprivation is not limited to ODMRP but is prevalent among other multicast protocols as well. In this paper, we introduce a novel MAC protocol, Broadcast Medium Window, (BMW) which supports reliable MAC broadcast in ad hoc networks. Furthermore, by exploiting BMW, we propose congestion control in ODMRP to reduce network load when contention is high. Our method is not confined to ODMRP alone; it can also be implemented on other multicast protocols, such as multicast AODV. We first describe our BMW protocol in section 2. Section 3 explains our congestion control scheme in ODMRP. Simulation results are given in section 4. Finally, section 5 concludes the paper. 2. BROADCAST MEDIUM WINDOW (BMW) The fundamental idea behind BMW 25 is to reliably transmit each packet to each neighbor in a round robin fashion. However, since BMW exploits many of the same concepts of IEEE , a brief operational overview of is in order. IEEE utilizes a collision avoidance scheme along with RTS/CTS/ACK control frames to transmit unicast packets. In , the Distributed Coordination Function (DCF) represents the basic access method that mobile nodes utilize to share the wireless channel. The scheme incorporates CSMA with Collision Avoidance (CSMA/CA) and acknowledgement (ACK). Optionally, the mobile nodes can make use of the virtual carrier sense mechanism that

2 employs RTS/CTS exchange for channel reservation and fragmentation of packets in situations where the wireless channel experiences high bit error rate. CSMA/CA works as follows. A node wishing to transmit senses the channel. If the channel is free for a time equal to the DCF InterFrame Space (DIFS) interval, the node transmits. If the channel is busy, the node enters a state of collision avoidance and backs off from transmitting for a specified interval. In the collision avoidance state, the node sensing the channel busy will suspend its backoff timer, only resuming the backoff countdown when the channel is again sensed free for a DIFS period. A typical sequence of exchanges in using the virtual carrier sensing mechanism involves the source node first sensing the channel using CSMA/CA. After CSMA/CA is executed, the source node transmits RTS, followed by the destination node responding with CTS, then with the source node sending the data frame and finally with the destination node confirming with an ACK to the source node. Any nodes receiving RTS, CTS or data frame that is not an intended destination will yield long enough for the source and destination nodes to complete the data exchange. For broadcast packets, IEEE nodes simply execute collision avoidance and then transmit the data frame Data structures In BMW, each node is required to maintain three lists: a neighbor list (NEIGHBOR LIST), a list of transmitted frames (SEND BUFFER) and a list of received sequence numbers (RECEIVER BUFFER). All nodes keep track of their neighbors through reception of frames (RTS/CTS/DATA/ACK/HELLO). Upon receiving any type of frames, a node updates its NEIGHBOR LIST. Furthermore, the NEIGHBOR LIST is purged if a neighboring node in the NEIGHBOR LIST has not been heard from for a specified amount of time. Each node also maintains a SEND BUFFER. The SEND BUFFER holds copies of the frames that were already transmitted but might be needed later for retransmission. A copy is removed from the SEND BUFFER after all neighbors have received it. The size of the SEND BUFFER should be at least as large as the maximum number of neighbors for any given node. Besides the SEND BUFFER, there is also a queue that stores packets that have not yet been transmitted. Finally, each node also maintains RECEIVER BUFFER. When a node receives a new frame, it records the frame s sequence number in RECEIVER BUFFER. When a source node transmits RTS to a destination node specifying a range of (from and to) sequence numbers, the destination node examines its RECEIVER BUFFER to determine whether it is missing any previous sequence numbers in the specified range. If so, the destination node replies with the missing sequence number in the CTS response Round robin approach In BMW, when a node has a packet to transmit, it first senses the channel and goes through a collision avoidance (CSMA/CA) phase similar to that of Upon the completion of the collision avoidance phase when the channel becomes free, the node sends RTS to one of its neighbors, specifying what sequence numbers have already been sent and what the current sequence number is. This is accomplished by extracting the lowest sequence number from the SEND BUFFER and specifying it into the RTS frame along with the current sequence number expected by the source node. Upon receiving the RTS, the intended neighbor examines its RECEIVER BUFFER and determines what sequence number it needs. If the node is missing a frame of a previous sequence number, the CTS response frame will reflect that. Likewise, if only the current sequence number is needed, the CTS response frame will reflect that as well. All other neighbors hearing the RTS will yield long enough for the CTS/DATA/ACK transmission. After the reception of the CTS, the source node then transmits the DATA (packet) that corresponds to the sequence number specified in the CTS frame. All other nodes hearing the CTS frame will yield long enough for the DATA/ACK transmission. Upon receiving the DATA, the destination node updates its RECEIVER BUFFER and replies with an ACK. All other neighboring nodes that received the DATA will also update their RECEIVER BUFFER. Upon receiving the ACK, if the DATA sent was not a current DATA but was instead obtained from the buffer, the source node continues its dialogue with the destination node with another RTS until the current DATA is sent from the queue. Here, the collision avoidance phase is skipped. Once the current DATA is transmitted and acknowledged, the source node then buffers the packet and chooses the next neighbor in its NEIGHBOR LIST and repeats the whole process over again. The round robin process runs smoothly when there are always packets to send. However, when there are no packets left in the transmit queue, the round robin process will halt and the source will not know whether the next neighbor in the NEIGHBOR LIST received all the broadcast DATA correctly until there is a new packet to send. To prevent this, BMW sets a timer for transmitting to the next node in the NEIGHBOR LIST. If the queue is empty for the time equal to this timer, the next node in the NEIGHBOR LIST will be chosen and the round robin process continues. If all the neighbors are visited in the round robin process and the queue is still empty, the round robin process stops until there is a new packet to transmit.

3 To detect neighbors, BMW relies on either transmitting HELLO frames periodically or listening in on existing MAC frames (RTS/CTS/DATA/ACK). To reduce HELLO frame overhead, a node that has just transmitted a frame will not send a HELLO frame for that given time period. In the event that nodes have absolutely no knowledge of any of their neighbors, transmissions by nodes are done by unreliable broadcasting (strict CSMA/CA) of the packets until the neighbors are detected Example We illustrate the concept of BMW through an example. Let us assume that node 5 wants to transmit a broadcast packet in Figure 1. Node 5 first determines a neighbor, say node 1, and sends RTS with sequence numbers ranging from 0 to 0 since no DATA frames have yet been sent. Node 1, upon receiving the RTS frame, replies with sequence number 0 in the CTS frame. Nodes 2, 3, and 4, upon receiving the RTS frame, yield long enough for the CTS/DATA/ACK exchange between node 5 and 1. After receiving the CTS frame, node 5 transmits DATA with sequence number 0. Node 1, upon receiving DATA, updates its RECEIVER BUFFER and replies with an ACK. For illustration purposes, let s say node 2 did not receive the DATA (possibly due to interference from neighboring nodes) while node 3 and 4 received the DATA correctly. Thus, node 3 and 4 also update their RECEIVER BUFFER. Upon receiving the ACK, node 5 stores the DATA that was sent into the SEND BUFFER and then selects node 2 as its next neighbor to transmit to. After executing the collision avoidance phase, node 5 sends RTS with sequence number range 0 to 1. Upon receiving the RTS, node 2 examines its RECEIVER BUFFER and noticed that frame 0 has not yet been received. Node 2 then sends CTS requesting sequence number 0. Node 5, upon receiving the CTS, obtains the DATA with sequence number 0 from the buffer and transmits the DATA. Upon receiving the DATA, node 2 updates its RECEIVER BUFFER and responds with an ACK. Upon receiving the ACK, node 5 sends RTS again with sequence number range 0 to 1 since the most recent DATA has not yet been sent. Node 2, upon receiving the RTS, sends CTS with sequence number 1 after examining its RECEIVER BUFFER. Node 5, upon receiving the CTS, sends the DATA with sequence number 1. Node 2, upon receiving the DATA, replies with an ACK. Again, for illustration purposes, let s say nodes 1, 3 and 4 successfully receive the DATA and update their respective RECEIVER BUFFER. Node 5, upon receiving the ACK, buffers the DATA in SEND BUFFER and elects node 3 as its next neighbor. Following the collision avoidance phase, node 5 transmits RTS with sequence number range 0 to 2. Upon receiving the RTS, node 3 examines its received sequence number list and sends CTS requesting sequence number 2 (since 0 and 1 were successfully received previously). Node 5, upon receiving CTS, transmits DATA with sequence number 2. Node 3, upon receiving DATA, transmits ACK and updates its RECEIVER BUFFER. Node 5, upon receiving ACK, buffers the DATA in SEND BUFFER, selects node 4 as it s next neighbor to transmit to, and the process resumes Figure 1. Node 5 broadcasting packets. Nodes 1, 2, 3 and 4 are within range of node 5 but not with each other. 3. ON-DEMAND MULTICAST ROUTING PROTOCOL WITH CONGESTION CONTROL The basic concept behind ODMRP is the creation of a mesh instead of a tree to route multicast packets 16, 17, 18. The source periodically probes the network for members. Upon receiving the probes, the members respond and the forwarding groups are formed. The forwarding groups create a mesh and data packets traverse through the forwarding groups to the multicast members.

4 To achieve congestion control, we examine the queue length as the network feedback criteria and use BMW as the underlying MAC layer. BMW is required for the following reason. ODMRP broadcasts data packets to all neighbors instead of delivering them point-to-point to selected individual neighbors, as commonly done by multicast protocols. The underlying MAC protocol generally used for broadcast is CSMA without ACK (to avoid ACK implosion). With CSMA, the queue length does not represent an accurate measure of congestion. Broadcast packets are delivered blindly, that is, if the packet is not received because of receive-buffer overflow or channel congestion (e.g., hidden terminal), it is dropped and no retransmission is attempt. Therefore, even in presence of congestion, the queue length will always be minimal. In contrast, the version of the IEEE protocol used in unicast, point-to-point transmissions is equipped with RTS and CTS control packets and ACKs. It is protected against receive-buffer overflow and hidden terminals, and thus provides accurate congestion feedback. This unicast version however is not attractive for multicast applications since it does not exploit the so-called broadcast advantage of the wireless channel, and requires an individual transmission to each multicast member. Therefore, BMW is needed to accurately portray the network state via queue lengths as BMW provides reliable delivery of broadcast packets Multicast route discovery In ODMRP, route discovery is initiated and maintained by the source. When the source has packets to transmit for a particular multicast group, the source first determines if there exists a route to the members of the group. If a route does not exist, ODMRP attempts to establish one via the route discovery process. The process of route discovery is similar to on-demand unicast routing protocols such as AODV 20 and DSR 11. There are two phases during route discovery: a request phase and a reply phase Request phase During the request phase, the source floods the network with a member advertisement packet with the data piggybacked. This packet is called JOIN QUERY. JOIN QUERY packets are periodically broadcasted to the entire network to refresh membership information and reestablish new multicast routes. Upon receiving a non-duplicate JOIN QUERY, a node inserts or updates in its ROUTING TABLE the upstream node address as the next node to the source node. The ROUTING TABLE will later be used when a JOIN REPLY is needed to be forwarded to the source during the reply phase. This technique is commonly known as backward learning Reply phase Once the non-duplicate JOIN QUERY reaches a multicast member, the reply phase begins. During the reply phase, the multicast member creates and broadcasts JOIN REPLY packet to the network with the address of the node the member receives the JOIN QUERY from stamped in the JOIN REPLY. Upon receiving the JOIN REPLY, a node determines if its address is stamped in the JOIN REPLY. If it is, the node realizes it is on the path to the source. The node then sets FORWARDING_GROUP_FLAG and becomes part of the forwarding group. Afterwards, the node rebroadcasts JOIN REPLY with the upstream node address to the source stamped in the JOIN REPLY. The upstream node address is obtained from the ROUTE TABLE via backward learning. This process continues until the JOIN REPLY reaches the source. Once the source receives JOIN REPLY, a mesh of nodes, or forwarding groups, is formed and packets can be delivered to the members Route maintenance ODMRP maintains the mesh by periodically broadcasting JOIN QUERY to the network and receiving JOIN REPLY in return. The periodic broadcast of JOIN QUERY will update the forwarding group nodes accordingly and adapt to membership fluctuations Multicasting data Once the source receives JOIN REPLY, data packets can be delivered to the members. The source broadcasts the data packet. Upon receiving the non-duplicate data packet, a node determines if it is a forwarding group for the data packet (by examining FORWARDING_GROUP_FLAG). All nodes in the forwarding groups then rebroadcast the packet until the packet reaches the multicast members Congestion control and other extensions We made several modifications to ODMRP described in S.J. Lee et al 17. First of all, each JOIN QUERY packet header also contains the largest mean aggregate MAC queue length thus far traversed. Furthermore, although duplicate JOIN

5 QUERYs are still discarded, the ROUTE TABLE is updated to the upstream node that transmitted the duplicate JOIN QUERY if the duplicate JOIN QUERY contains a mean aggregate queue length that is smaller than the one reported in the ROUTE TABLE. We want to always use the route back to the source with lesser congestion. The mean aggregate queue length is defined as the mean length of the queue shared by all source 21, 22. Each node computes the mean aggregate queue length as the average over queue regeneration cycles. A queue regeneration cycle is broken down into a busy and an idle period. The busy period starts when the queue transitions from empty to non-empty and ends when the queue transitions back to empty. Conversely, the idle period starts when the queue is empty and ends when the queue shifts to non-empty. It has been shown that averages computed over regeneration cycles are able to provide a good balance between the sensitivity of the current system and the stability in the measurement 22. However, simply measuring past regeneration cycles is not adequate to convey the current network state as past regeneration cycles may reflect outdated conditions and the current regeneration cycle may be significantly longer than past cycles. In order to circumvent this, we measure the mean aggregate queue length as the average over past and current (partial) regeneration cycles 15. Figure 2 illustrates the regeneration periods. Queue length N Previous cycle Averaging interval Current cycle T Figure 2. Regeneration periods. A regeneration period begins when a queue goes from empty to non-empty, and ends when the next period begins. To exercise congestion control, JOIN QUERY packets are forwarded only if the mean aggregate queue length is less than or equal to QUEUE_LENGTH_THRESHOLD. By doing so, routes that have long mean aggregate queue length, and thus may cause a bottleneck, are avoided. Upon receiving JOIN QUERY, a member will also include the mean aggregate queue length that it is currently experiencing in the JOIN REPLY sent back to the source. Nodes that are forwarding groups, upon receiving JOIN REPLY, check the mean aggregate queue length stamped in the packet. If the mean aggregate queue length is less than the current mean aggregate queue length the node is experiencing, the node s current mean aggregate queue length value will replace the one carried by the JOIN REPLY and the JOIN REPLY is unicasted to the upstream nodes. Once the source node receives the JOIN REPLY, the source adjusts its sending rate based on the mean aggregate queue length specified in the JOIN REPLY. More specifically, the source employs the following algorithm: factor = meanaggregatequeuelength * MILLI_SECOND / originalinterdepartureinterval * (100 + K); if (factor == 0) { newinterval = originalinterdepartureinterval; } else { newinterval = originalinterdepartureinterval * (factor + 1); } where MILLI_SECOND is used to convert meanaggregatequeuelength to the same unit as originalinterdepartureinterval.

6 The above algorithm adjusts the sending interval (and rate) of the source based on the maximum mean aggregate queue length along the path to the members and the original sending rate of the source. The faster the source transmits data, the more the source has to adjust. The constant K determines the degree of the adjustment. The higher the K, the more the source adapts to congestion. We choose K = 30 in our simulation experiments. Note that since ODMRP attempts route discovery periodically, the source will be able to adapt its sending rate to the ever-changing network load accordingly. We also made some enhancements to ODMRP. First, instead of aggregating JOIN REPLY packets into one bulky packet as in S.J. Lee et al 17, we modified ODMRP to transmit each JOIN REPLY separately. Our reasoning is that packets transmitted in ad hoc networks are error prone, possibly due to channel noise interference, collisions and mobility. This is the same basis behind IEEE s decision to use control frames to test the waters before transmitting the actual data. Transmitting large packets is wasteful in ad hoc networks since there is a high probability of loss. Thus, it is better to transmit packets of smaller sizes. The other beneficial side effect of this approach is that now the JOIN REPLY is transmitted much earlier than in S.J. Lee et al 17, where a node would have to wait for a certain time period to aggregate the JOIN REPLY packets before transmitting it out. Therefore, this modification also speeds up the route discovery process. Finally, instead of utilizing passive acknowledgements for each JOIN REPLY as in S.J. Lee et al 17,wechooseto exercise explicit acknowledgements. The most important step in route discovery is to form the forwarding groups; we want to explicitly make sure that the forwarding groups are properly and timely formed Backpressure vs end-to-end congestion notification The reader may have noticed that BMW by itself already provides backpressure flow control. More precisely, if the MAC queue at a node fills up, the node will drop (and not ACK) packets from upstream nodes. Consequently, because of the reliable BMW transmission mode, the queues at upstream nodes will also fill up, leading to a backpressure phenomenon that propagates back to the source. This form of congestion control alone, however, tends to be too slow, and moreover causes major backup in the entire network before having effect on the offending sources. In this paper, we have proposed an end-to-end congestion notification mechanism, similar to the ECN (Explicit Congestion Notification) scheme in TCP/IP 6, the DEC Bit scheme 21, 22 and the PRCA (Proportional Rate Control Algorithm) scheme in ATM 10. The novelty of our end-to-end notification scheme, with respect to previous schemes, is the fact that it applies equally easily to unicast and multicast; moreover, it does not require special control packets other than the periodic refresh packets. 4. SIMULATION In this section, we evaluate the effectiveness of our changes in ODMRP to support congestion control using simulation Environment ODMRP and BMW are simulated using the GloMoSim network simulator 2, 27. GloMoSim is a discrete even, parallel simulation environment implemented in PARSEC1. In our simulation, we consider a grid topology consisting of 16 nodes as shown in Figure 3 and a topology where 25 nodes are uniformly placed in a 1000m x 1000m area.

7 Figure node grid topology In Figure 3, nodes are within radio power range of their intermediate neighbors and vice versa. UDP traffic is multicasted using ODMRP with and without congestion control. When using ODMRP with congestion control, BMW is utilized as the MAC layer. When ODMRP without congestion control is applied, IEEE is deployed. Radios with no capture ability are modeled with a channel capacity of 2Mbps for each node. We assume a free-space channel with a threshold cutoff and the power of a signal attenuates as 1/d 2 where d is the distance between two nodes. Simulation results are obtained from multiple runs, each lasting 200 seconds, with varying seed numbers, and the results are averaged over the runs. Each data packet is 512B. To determine the effectiveness of our congestion control enhancements to ODMRP, we examine the packet delivery ratio of ODMRP and number of packets sent by the multicast sources with and without our congestion control mechanism (referred to as normal ODMRP). The packet delivery ratio is defined as the number of actual packets received by the multicast members over the number of packets that the members are supposed to receive. The packet delivery ratio metric measures the effectiveness of a multicast routing protocol Results We examine ODMRP, with and without congestion control, first using a contrive scenario. In this scenario, nodes 0 through 3 in Figure 3 are the multicast sources and nodes 12 through 15 are the multicast members. Source 0 through source 3 starts transmitting data ten seconds after one another. Multiple experiments are run using varying interdeparture rates. The results of our simulation are depicted in Figure 4. Grid Experiment Packet Delivery Ratio MS 100MS 150MS 200MS 250MS 300MS 350MS 400MS 450MS 500MS Packet Interdeparture Rate Normal Congestion Control Figure node grid experiment (packet delivery ratio) From Figure 4, we observe that the packet delivery ratio of normal ODMRP collapses under high traffic load, receiving a mere 20% packet delivery ratio with a packet interdeparture rate of 50ms. The low packet delivery ratio is attributed to

8 the fact that under high load, the network becomes congested. At the same time, the sources continue to maintain their high sending rate, which leads to packet drops due to queue overflow and packet collisions (hidden terminals). On the other hand, the aggressive sources have no effect on the packet delivery ratio of ODMRP with congestion control. As sources become aggressive, the mean aggregate queue length feedback sent from the members back to the source via JOIN REPLY informs the sources that the network has become congested and that the sources should decrease their sending rate based on the level of congestion indicated by the JOIN REPLY. By reducing the send rate, and thus the network load, ODMRP with congestion control is able to deliver data packets at or near the optimal packet delivery ratio (100%). As the interdeparture rate decreases, both versions of ODMRP were able to achieve perfect packet delivery ratio, as expected. Figure 5 provides another viewpoint of the congestion control effect. We observe here that with congestion control, the sources maintain a relatively constant number of packet transmissions (at or below 10,000 packets) that is independent of the original sending rate. Moreover, as the sending rate decreases, the number of packets sent by the sources with and without congestion control converges since there is no longer a need for congestion control at low sending rates. Grid Experiment Number of Packets Sent MS 100MS 150MS 200MS 250MS 300MS 350MS 400MS 450MS 500MS Packet Interdeparture Rate Normal Congestion Control Figure node grid experiment (number of packets sent) We now compare the behavior of normal ODMRP and ODMRP with congestion control in a more random environment. To this end, we uniformly placed 25 nodes in a 1000m x 1000m area. Five multicast sources are sending data to five multicast receivers, with each source starting the data transmission ten seconds after the other. The transmission range of each node is 300m. The results are given in Figure 6. Uniform Experiment Packet Delivery Ratio MS 100MS 150MS 200MS 250MS 300MS 350MS 400MS 450MS 500MS Packet Interdeparture Rate Normal Congestion Control Figure 6. Uniform experiment (packet delivery ratio)

9 Note that the graph in Figure 6 resembles that in Figure 4. We again observe that the packet delivery ratio of ODMRP with congestion control is near optimal to optimal under all traffic rates whereas under normal ODMRP, the packet delivery ratio is inversely proportional to the sending rate. Similar to Figure 5, Figure 7 provides another perspective of the network behavior in terms of the total number of packets sent by the sources with and without congestion control. Uniform Experiment Number of Packets Sent MS 100MS 150MS 200MS 250MS 300MS 350MS 400MS 450MS 500MS Packet Interdeparture Rate Normal Congestion Control Figure 7. Uniform experiment (number of packets sent) Not surprisingly, the results of Figure 7 mirror those of Figure 5; the number of packets sent under ODMRP with congestion control remains relatively constant while, without congestion control, the number of packets sent is directly coupled to the initial sending rate. Next, we examine a typical ad hoc scenario where nodes move. Here, 25 nodes are initially placed in a 1000m x 1000m area. Again, five multicast sources are sending data to five multicast receivers, with each node having a transmission power of 300m. We use the random waypoint mobility model, where a node randomly selects a destination from the 1000m x 1000m area and then moves in the direction of the selected destination with a certain speed. Once the destination is reached, the node chooses another destination and the process repeats over again. In this experiment, we vary the mobility speed, ranging from 10 meters per second to 50 meters per second. Each multicast source sends data at a packet interdeparture rate of 200ms. The simulation result is shown in Figure 8. Mobility Experiment Packet Delivery Ratio Speed (m/s) Regular Congestion Control Figure 8. Mobility experiment (packet delivery ratio) The results indicate that ODMRP with congestion control performs better in the mobile environment as mobility speed increases. We first observe that regular ODMRP degrades as mobility speed rises. The packet delivery ratio ranges from 72% for mobility speed of 10m/s to 64% as mobility speed increases to 50m/s. The performance exhibit here is

10 worse than the static scenario reported in Figure 6 due to packet loss caused by mobility; the faster the nodes move, the higher the loss rate. Note that the packet delivery ratio of regular ODMRP is still quite sufficient in this mobile scenario. This robustness to mobility is due to the redundancy of ODMRP s mesh approach, i.e., the forwarding group. However, under ODMRP with congestion control, the behavior is reversed. The packet delivery ratio of ODMRP with congestion control actually increases! This result is counter-intuitive, as we would expect the performance to degrade as well due to loss caused by mobility. However, a closer examination reveals that as mobility speed increases, the multicast sources actually reduce their sending rate. This is because of two reasons. First of all, the multicast sources will reduce its transmission rate when the network is congested. Secondly, the multicast sources do not send any further data until the congestion information propagates back to the sources via JOIN TABLE. The rationale is that since no JOIN TABLEs are received, the network is most likely congested or exhibiting high error rates, possible due to channel noise or mobility. Therefore, no further data should be sent. Instead, new JOIN QUERY packets are sent out at intervals to probe the network until JOIN TABLEs are received (i.e., when the network is more stable). These two actions diminish the number of data packets that are transmitted as mobility increases. Figure 9 shows the number of packets sent by regular ODMRP and ODMRP with congestion control in the mobile scenario. Mobility Experiment Number of Packets Sent Speed (m/s) Regular Congestion Control Figure 9. Mobility experiment (number of packets sent) Figure 9 reveals that regular ODMRP maintains a constant transmission rate irrespective of the mobility speed, as expected. However, under ODMRP with congestion control, the total number of packets decreases as the mobility speed increases. The decrease in the number of packets sent in response to mobility speed reduces the network traffic, which in turn increases the probability of successful reception at the multicast receivers. We see from Figure 9 that the number of packets sent decreases with mobility speed under ODMRP with congestion control. Therefore, since fewer packets are sent as mobility speed increases, there is less network congestion as nodes move faster. This leads to a higher packet delivery ratio, although overall throughput is sacrificed. 5. CONCLUSION In this paper, we have presented a novel MAC protocol, BMW, which reliably delivers broadcast packets, and extend ODMRP to support network level congestion control using the mean aggregate queue length as the network feedback metric. Alternatively, the instantaneous queue length could also be utilized. We choose the mean aggregate queue length over the instantaneous queue length due to the fact that the instantaneous queue length feedback does not take into consideration bursty and non-uniform traffic. Under bursty and non-uniform traffic, the instantaneous queue length measurement would provide an erroneous view of the network condition to the multicast sources. In addition to congestion control, we have introduced BMW, a wireless ad hoc MAC protocol that supports reliable broadcasting of data and provides a means to obtain effective congestion feedback. We argue that in a broadcast scenario the MAC queue maintained by conventional wireless ad hoc MAC protocols, such as IEEE (broadcast version), do not accurately reflect the contention level of the network, and therefore claim for the need for a new scheme such as BMW to address this issue. Finally, through simulation we show that ODMRP with congestion control running on top of

11 BMW effectively and accurate adapts to the network load. One important point to emphasize is that the propagation model used in the experiments is the free-space model. Free-space is a relatively conservative channel model in wireless networks as wireless links are more prone to errors than what the free-space channel models. Under more realistic propagation models, the advantages of using BMW become more evident. One drawback of BMW, however, is that as the number of neighbors increases for any given node, the time needed to guarantee delivery to all neighbors also grows. This problem can be addressed by decreasing the radio s transmit power to limit the number of neighbors. Decreasing the radio s transmit power also provides the added advantage of reducing power consumption, which is paramount in wireless ad hoc networks. Currently, BMW is needed in order to implement ODMRP with congestion control. However, exporting the reliability concept of BMW into ODMRP can decouple this relationship between the network and MAC layer. That is, the neighbors in BMW can be mapped to the forwarding group nodes in ODMRP. Thus, only the neighbors that are part of the forwarding group need to be reliably delivered to. This reduction in guaranteeing reliable delivery from all neighbors to a subset of the neighbors (the forwarding group) will improve network congestion. Work is in progress in several directions including: decoupling ODMRP from BMW, investigation of more refined rate adjustment mechanisms, fairness among UDP multicast sessions sharing the same bottlenecks, friendliness of multicast streams to unicast, and application to other wireless multicast protocols (e.g., multicast AODV). REFERENCES 1. R. Bagrodia, R. Meyer, et al, PARSEC: A Parallel Simulation Environment for Complex System, Computer Magazine, R. Bagrodia and M. Gerla, A Modular and Scalable Simulation Tool for Large Wireless Networks, International Conference on Modeling Techniques and Tools for Computer Performance Evaluation, V. Bharghavan, A. Demers, S. Shenker, and L. Zhang, MACAW: A Media Access Protocol for Wireless LAN's, ACM SIGCOMM, E. Bommaiah, M. Liu, A. McAuley, and R. Talpade, AMRoute: Ad-hoc Multicast Routing Protocol, Internet- Draft, draft-talpade-manet-amroute-00.txt, Aug. 1998, Work in progress. 5. Editors of IEEE , Wireless LAN Medium Access Control (MAC and Physical Layer (PHY) specifications, Draft Standard IEEE , S. Floyd, TCP and Explicit Congestion Notification, ACM Computer Communication Review, V. 24 N. 5, October C. Fullmer and J.J. Garcia-Luna-Aceves, Floor Acquisition Multiple Access (FAMA) for packet radio networks, Computer Communication Review, vol. 25, (no. 4), (ACM SIGCOMM '95, Cambridge, MA, USA, 28 Aug.-1 Sept ) ACM, Oct J.J. Garcia-Luna-Aceves and E.L. Madruga, The Core-Assisted Mesh Protocol, IEEE Journal on Selected Areas in Communications, vol. 17, no. 8, Aug. 1999, pp J. Haartsen, M. Naghshineh, J. Inouye, O.J. Joeressen, and W. Allen, Bluetooth: Vision, Goals, and Architecture, ACM SIGMOBILE Mobile Computing and Communications Review, vol. 2, no. 4, Oct. 1998, pp M. Hluchy et al, Closed Loop Rate-Based Traffic Management, Technical Report, ATM Forum, September D. B. Johnson and D. A. Maltz, Dynamic Source Routing in Ad Hoc Wireless Networks, Mobile Computing, edited by Tomasz Imielinski and Hank Korth, Kluwer Academic Pusblishers, Anthony Joseph, B. R. Badrinath, and Randy Katz, A Case for Services over Cascaded Networks, First ACM/IEEE International Conference on Wireless and Mobile Multimedia (WoWMoM'98), Dallas, Texas, October 30, John Jubin and Janet D. Tornow, The DARPA Packet Radio Network Protocols, Proceedings of the IEEE, Jan P. Karn, MACA A New Channel Access Method for Packet Radio, in ARRL/CRRL Amateur radio 9th Computer Networking Conference, ARRL, S. Keshav, An Engineering Approach to Computer Networking: ATM Networks, the Internet, and the Telephone Network, Addison-Wesley, Menlo Park, California, S.-J. Lee, M. Gerla, and C.-C. Chiang, On-Demand Multicast Routing Protocol, Proceedings of IEEE WCNC'99, New Orleans, LA, Sep. 1999, pp

12 17. S.-J. Lee, W. Su, J. Hsu, M. Gerla, and R. Bagrodia, A Performance Comparison Study of Ad Hoc Wireless Multicast Protocols, Proceedings of IEEE INFOCOM2000, Tel Aviv, Israel, Mar S.-J. Lee, W. Su, and M. Gerla, Internet Draft, draft-ietf-manet-odmrp-02.txt, Jan K.J. Negus, J. Waters, J. Tourrilhes, C. Romans, J. Lansford, and S. Hui, HomeRF and SWAP: Wireless Networking for the Connected Home, ACM SIGMOBILE Mobile Computing and Communications Review, vol. 2, no. 4, Oct. 1998, pp C. E. Perkins and E. M. Royer, Ad-Hoc On Demand Distance Vector Routing, Proceedings of the 2 nd IEEE Workshop on Mobile Computing Systems and Applications (WMCSA), New Orleans, LA, Feb K. K. Ramakrishnan and R. Jain, A Binary Feedback Scheme for Congestion Avoidance in Computer Networks with a Connectionless Network Layer, Proceedings of ACM SIGCOMM 88, Stanford, August K. K. Ramakrishnan and R. Jain, A Binary Feedback Scheme for Congestion Avoidance in Computer Networks, ACM Transactions on Computer Systems, Vol. 8, No. 2, E. M. Royer and C. E. Perkins, Multicast Operation of the Ad-hoc On-Demand Distance Vector Routing Protocol, Proceedings of ACM/IEEE MOBICOM 99, Seattle, WA, Aug Andrew S. Tanenbaum, Computer Networks: Third Edition, Prentice Hall PTR, New Jersey, K. Tang and M. Gerla, MAC Reliable Broadcast in Ad Hoc Networks, MILCOM 2001, McLean, Virginia, October C.W. Wu, Y.C. Tay, and C.-K. Toh, Ad hoc Multicast Routing Protocol utilizing Increasing id-numbers (AMRIS) Funcational Specification, Internet-Draft, draft-ietf-manet-amris-spec-00.txt, Nov. 1998, Work in progress. 27. X. Zeng, R. Bagrodia and M. Gerla, GloMoSim: a Library for the Parallel Simulation of Large-scale Wireless Networks, PADS, 1998.