Reliable on-demand multicast routing with congestion controlin wireless ad hoc networksKenTang,MarioGerlaComputer Science DepartmentUniversity of California, Los AngelesLos Angeles, CA 90095ABSTRACTIn this paper, we address the congestion control multicast routing problem in wireless ad hoc networks through themedium access control (MAC) layer. We first introduce the Broadcast Medium Window (BMW) MAC protocol, whichprovides reliable delivery to broadcast packets at the MAC layer. We then extend the wireless On-Demand MulticastRouting Protocol (ODMRP) to facilitate congestion control in ad hoc networks using BMW. Through simulation, weshow 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 window1. INTRODUCTIONMulticast routing in wireless ad hoc networks has gain considerable interest in recent years. The main benefit ofmulticasting 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 theInternet, TCP, is not practical in multicast due to ACK implosion. Moreover, overload control is essential in wirelessnetworks where scarce bandwidth is the norm.Some multicast routing protocols include AMRoute4,AMRIS26,CAMP8, multicast AODV23, and the On-DemandMulticast Routing Protocol (ODMRP)16, 17, 18. ODMRP disseminates multicast packets on a mesh instead of thetraditional multicast tree. By using a mesh, ODMRP introduces redundancy to combat packet loss in ad hoc networkswhere channel noise, collisions and mobility are common. Under low traffic load, ODMRP performs well. However, astraffic load increases, ODMRP progressively suffers from network congestion. This deprivation is not limited toODMRP 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, byexploiting BMW, we propose congestion control in ODMRP to reduce network load when contention is high. Ourmethod is not confined to ODMRP alone; it can also be implemented on other multicast protocols, such as multicastAODV.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 BMW25is to reliably transmit each packet to each neighbor in a round robin fashion.However, since BMW exploits many of the same concepts of IEEE 802.115, a brief operational overview of 802.11 is inorder.IEEE 802.11 utilizes a collision avoidance scheme along with RTS/CTS/ACK control frames to transmit unicast packets.In 802.11, the Distributed Coordination Function (DCF) represents the basic access method that mobile nodes utilize toshare the wireless channel. The scheme incorporates CSMA with Collision Avoidance (CSMA/CA) andacknowledgement (ACK). Optionally, the mobile nodes can make use of the virtual carrier sense mechanism thatemploys RTS/CTS exchange for channel reservation and fragmentation of packets in situations where the wirelesschannel experiences high bit error rate. CSMA/CA works as follows. A node wishing to transmit senses the channel. Ifthe channel is free for a time equal to the DCF InterFrame Space (DIFS) interval, the node transmits. If the channel isbusy, the node enters a state of collision avoidance and backs off from transmitting for a specified interval. In thecollision avoidance state, the node sensing the channel busy will suspend its backoff timer, only resuming the backoffcountdown when the channel is again sensed free for a DIFS period. A typical sequence of exchanges in 802.11 usingthe virtual carrier sensing mechanism involves the source node first sensing the channel using CSMA/CA. AfterCSMA/CA is executed, the source node transmits RTS, followed by the destination node responding with CTS, thenwith the source node sending the data frame and finally with the destination node confirming with an ACK to the sourcenode. Any nodes receiving RTS, CTS or data frame that is not an intended destination will yield long enough for thesource and destination nodes to complete the data exchange. For broadcast packets, IEEE 802.11 nodes simply executecollision avoidance and then transmit the data frame.2.1. Data structuresIn 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 theirneighbors through reception of frames (RTS/CTS/DATA/ACK/HELLO). Upon receiving any type of frames, a nodeupdates its NEIGHBOR LIST. Furthermore, the NEIGHBOR LIST is purged if a neighboring node in the NEIGHBORLIST has not been heard from for a specified amount of time. Each node also maintains a SEND BUFFER. The SENDBUFFER holds copies of the frames that were already transmitted but might be needed later for retransmission. A copyis removed from the SEND BUFFER after all neighbors have received it. The size of the SEND BUFFER should be atleast as large as the maximum number of neighbors for any given node. Besides the SEND BUFFER, there is also aqueue 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 sourcenode transmits RTS to a destination node specifying a range of (from and to) sequence numbers, the destination nodeexamines its RECEIVER BUFFER to determine whether it is missing any previous sequence numbers in the specifiedrange. If so, the destination node replies with the missing sequence number in the CTS response.2.2. Round robin approachIn 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 802.11. Upon the completion of the collision avoidance phase when the channelbecomes free, the node sends RTS to one of its neighbors, specifying what sequence numbers have already been sent andwhat the current sequence number is. This is accomplished by extracting the lowest sequence number from the SENDBUFFER and
View Full Document
Unlocking...