The design, implementation, and performance evaluating of the on by dsu13762


									             The Design, Implementation, and
              Performance Evaluation of the
          On-Dema n d Multicast Routing Protocol in
               Multihop Wireless Networks
                  Sang Ho Bae, Sung-Ju l, William Su, and Mario Gerla, University of California

                                  Multicasting has emerged a s one of the most focused areas in the field o network-
                                  ing. As the technology and popularity o the Internet grow, applications such as
                                  video conferencing that require the multicast feature a r e becoming more
                                  widespread. Another interesting recent development has been the emergence of
                                  dynamically reconfigurable wireless ad hoc networks to interconnect mobile users
                                  for applications ranging from disaster recovery to distributed collaborative comput.
                                  ing. In this article we describe the On-Demand Multicast Routing Protocol for
                                  mobile ad hoc networks. ODMRP is a mesh-based, rather than convention01 tree-
                                  based, multicast scheme and uses a forwarding group concept [only a subset of
                                  nodes forwards the multicast packets via scoped flooding). It applies on-demand
                                  procedures to dynamically build routes and maintain multicast group membership.
                                  W e also describe our implementation of the protocol in a real laptop testbed.

               n ad hoc network [1, 21 is a dynamically reconfig-                             wcll in ad hoc networks because multicast tree structures are
               urablc wirclcss network with no fixcd infrastruc-                              fragilc and must he readjustcd as connectivity changcs. Fur-
               tnre or central administration. Due to thc limitcd                             thermore, multicast trccs usually requirc a global routing sub-
               radio propagation rmgc of wireless deviccs, routcs                              structure such HS link state or distancc vcctnr. The frequent
   are often multihop. Applications such as disastcr recovery,                                 cxchangc of routing vcctors or link state tablcs, triggcrcd hy
   crowd control, scarch and rescue, and automated battlefields                               continuous topology changcs, yiclds excessivc channcl and
   are typical examples of whcrc ad hoc networks iirc dcployed.                               processing ovcrhcad.
   Nodes in thesc nctworks move arbitrarily; thus, nctwork                                        To ovcrconic these limitations, we have devclopcd thc On-
   topology changes frequently and unprcdictably. Morcovcr,                                    Demand Multicast Routing Protocnl ( O D M R P ) [7-91.
   bandwidth and battery powcr arc limited. These constraints,                                O D M R P applics on-demund routing techniques to avoid
   io combination with the dynamic nctwork topology, tnakc                                    channel overhcad and improve scalability. It nses the concept
   routing and multicasting in ad hoc nctworks extremely chzil-                               of forwarding jiroiip [lo], a set of nodcs rcsponsihle for for-
   lenging.                                                                                   warding multicast data on shortest paths bctwccn any member
      In a lypical ad hoc cnvirnnmcnt, network hosts work in                                  pairs, to build a forwarding mesh fnr each multicast group. By
   groups to carry out a givcn task. Hence, multicast plays an                                mainlaining and using a mesh iiistcad of a tree, the drawbacks
   important role in ad hoc nctworks. Multicwt protocols used i n                             of multicast trees in mobilc wircless networks (c.g., intcrmil-
   static networks - for cxample, Distance Vcctor Multicast                                   tcnt conncctivity, traffic conccutration, frequcnt trcc rcconfig-
   Routing Protocol (DVMKP) [3], Multicast Opcn Shortcst                                      uration, non-shortcst path in ii sharcd tree) are avoided. A
   Path First (MOSPF) [4],    Corc Bascd Trces (CBT) 151, and                                 .soft-strrte approach is taken in ODMRP to maintain inulticast
   Protocol Indcpcndcnt Multicast (PIM) [h] -do not perform                                   group memhcrs. Nn cxplicit control mcssage is required to
                                                                                              lcavc thc group. Wc bclicvc the reduction of channcllstorage
                                                                                              ovcrhcad and relaxed conncctivity make ODMRP morc scal-
                                                                                              able for Iargc networks and morc stable for mobile wirclcss
                                                                                                  T h e performance of O D M R P has hcen tested using a

Authorized licensed use limited to: Univ of Calif Los Angeles. Downloaded on October 12, 2008 at 20:20 from IEEE Xplore. Restrictions apply.
detailcd simulator [7, 91. The rcsults obtained from simula-
tion led us lo take the ncxt step in devclopinent: implemcut
ODMRP in a real tcstbed to validatc and finc-tune thc pro-
tocol. No prior work cxists in building a midticast protocol
in an ad hoc network testbcd. Our implemcntation utilizes
thc multicast extension built into thc Linux kernel. A wire-
less mobile tcstbed consisting of laptops with the Liiiux
opcrating system has been organized to test the implcmen-
   A few other multicasting protocols h a w recently been
proposed for ad hoc networks [10-22]. The Reservation-
Based Multicast (RBM) routing protocol [14] builds a core
(or rendezvous point) based trce for cach multicast group.
RBM is a comhination of multicast, resourcc reservation,
and admission control protocol whcrc users specify rcquire-
inelits and constraints. Thc Lightwcight Adaptive Multicast                              I Figure 1. An on-demundprocedureformembership setup and
(LAM) algorithm [17] is a group sharcd tree protocol that                                   maintennnce.
docs not require timcr-based messaging. Similar to othcr
core-based protocols, it suffcrs from disadvantages of traffic
concentration and vulnerability of thc corc. The Ad Hoc                                  ODMRP Illustrated
Multicast Routing Protocol (AMRoutc) [ I ] ] is also a shared
trce protocol which allows dyiiamic core migration bascd on                              Multicast Route and Membership Maintenance
group membership and network configuration. The Ad Hoc                                  In ODMRP, group membcrship and multicast routes are
Multicast Routing Protocol utilizing Increasing ID Numbers                              cstablishcd and updated by thc source on demand.’Similarto
(AMRIS) [22) builds a shared-trce to dcliver multicast data.                            on-demand unicast routing protocols, a rcquest phase and a
Each nodc in the multicast session is assigncd an ID num-                               reply phase constitute the protocol (Fig. 1). While a multicast
her, and it adapts to connectivity changcs by utilizing thc ID                          source has packets to send, it floods a mcmber advertising
numbers. A multicast extcnsion of the Ad Hoc On Demand                                  packet with data payload attached. This packet, called JOIN
Distance Vcctor (AODV) routing protocol has been ncwly                                  DATA, is pcriodically broadcast to the cntire network to refresh
proposed in [20]. Its uniqucncss stems from the nsc of a                                the membcrship information and update the routes as follows.
destination sequcnce numbcr for each multicast entry. The                               When a node reccives a nonduplicatc JOINDATA,it stores thc
sequencc numbcr is generated by thc multicast grouphead                                 upstream node ID (i.e., backward learning) into the routing
to prcvent loops and discard stale routes. Similar to                                   tablc and rebroadcasts thc packet. When the JOIN DATA packct
ODMRP, thc Core-Assisted Mcsh Protocol (CAMP) [151                                      reachcs a multicast receivcr, the recciver creates and broadcasts
nscs a mesh. However, a convcntional routing infrastructure                             a JOIN TABLE its ncighbors. When a node reccives a JOIN
based on a cuhancctl distancc vector algorithm, such as                                 TABLE, it checks if the next node I D of one of the entries
Wireless Routing Protocol (WRP) 1231, is requircd for                                   matchcs its own ID. If it docs, the nodc realizes that it is on the
CAMP to opcrate. Core nodes are used to limit the traffic                               path to thc source and thus is part of thc forwarding group. It
required when a node joins a multicast group.                                           then sets the FG-FLAG (Forwarding Group Flag) and broad-
   T h e rest of this articlc is organized a s follows. We                              casts its own JOIN TABLE built on matched entries. The JOIN
describc the design of ODMRP, followed by thc protocol                                  TABLE is thus propagatcd by each forwarding group membcr
implementation description. Performance evaluation results                              until it reaches thc multicast source via the shortest path. This
and analyses arc presentcd, and concluding remarks are                                  proccss constructs (or updates) thc routes from sources to
madc.                                                                                   reccivcrs and builds a mesh of nodcs, the forwardincprouu.  .
                                                                                                      Wc have visualized tbc’fonkding group concept
                                                                                                   in Fig. 2. The forwarding group is a sct of nodes
                                                                                                   which is in chargc of forwarding multicast packets.
                                                                                                   It supports shortest paths between any member
                                                                                                   pairs. All nodes insidc the “bubble” (multicast mcm-
                                                                                                   bers and forwarding group nodes) forward multicast
                                                                                                   data packcts. Note that a multicast receivcr can also
                                                                                                   be a forwarding group node if it is on thc path
                                                                                                   betwecn a multicast sourcc and another receiver.
                                                                                                   The mesh provides richer connectivity among multi-
                                                                                                   cast membcrs than trees. Flooding redundancy
                                                                                                   among a foiwardiiig group helps overcome node dis-
                                                                                                   placements and channel fading. Hence, unlike for
                                                                                                   trccs, frequcnt reconfigurations are not required.
                                                                                                      Figure 3 is an cxample to show the robustness of
                                                                                                   a mcsb configuration. Three sourccs (SI, and Ss)
                                                                                                   send multicast data packets to three reccivers (RI,
                                                                                                   R2, and R,) via threc forwarding group nodes (A,E ,
                                                                                                   and C ) . Suppose the routc from SIto R , is SI-A-B-
                                                                                                   Rz.In a tree configuration, if the link between nodes
                                                                                                   A and B breaks or fails, R2 cannot rcceive any pack-
                                                                                                   ets from SIuntil the trcc is reconfigured. ODMRP,
  Figure 2. The forwardinggroiip concept.                                                          on thc other hand, already has a rcdundant ronte

IEEE Network * JanuaryIPcbrua~y
                              2000                                                                                                                    71

Authorized licensed use limited to: Univ of Calif Los Angeles. Downloaded on October 12, 2008 at 20:20 from IEEE Xplore. Restrictions apply.
                                                                                            group. Nodcs in the forwarding group arc demoted to nonfor-
                                                                                            warding iiodcs if no1 refrcshcd (no JOINTAMI.US  received)
                                                                                            before they tiincnnt.
                                                                                            Selection of Timer Vaiues
                                                                                            Timer v;ilucs for route rcfrcsh interval and forwarding group
                                                                                            timeool intcrviil caii have impacts on ODMRP performance.
                                                                                            Tlie sclcction of tliese soft state timers sliiiuld he adaptivc t n
                                                                                            network cnvironmcnls (e.g., traffic lypc, traffic load, mobility
                                                                                            pattcrn, mobility speed, clianncl capacity). When small route
                                                                                            rcfrcsh interval valucs are used, frcsh routc and membership
                                                                                            infnrmation can be nlitained frcqucntly at thc cxpcnse of pro-
                                                                                            ducing more packets and causing network congestion. On the

               Sources 5,. 52,5,  YY
               Receivers RI, R2, R3
                                                                                            other hand, when largc route refresh valncs are selectcd, cvcn
                                                                                            though less control traffic will he generated, nodcs may not
                                                                                            know up-to-date route and multicast membership. Thus, in
               Forwarding nodes A, B, C                                                     highly mnbilc networks, using large rontc refresh inteival val-
                       _ _ _ _ ~
                                                                                            ues can yicld poor protocol performance. Tlie lorwarding

   3 Figure 3 Whys medr?
                                                                                            group tiniconl interval should also be carefully selectcd. lo
                                                                                            heavy traffic load, smdl valucs should be used so that uniieccs-
                                                                                            saly iiodcs can tiincout quickly and not crcatc excessive rcdun-
   (e.g., SI-A-C-B-R2)to deliver packets without going tlirougli                            dancy. In situations with high mobility, however, large Valiics
   llie hrokcn liiik bclween nodcs A and B .                                                should bc chosen so that more alternative paths can be provid-
                                                                                            ed. It is important to not^ that tlic forwarding group timeout
   An Example                                                                               value must be larger (e.g., thrcc to five times) rlian the value
   Let us consider Fig. 4 iis an example of ti JOIN TATILL! for-                            of the route rcfrcsh interval.
   warding process. Nodcs SI ;incl S z arc mu1tic;ist snurccs, and
   nodcs R I , R2, and X 3 are multicast receivers. Nodcs It2 and R?                        Unicast Capability
   scrld their JOIN TABLES to both SI and S 2 via 12. R I sends its                         One [if the major strengths of ODMRP is its unicast routing
   JOIN TARI.1. to SIvia I and to S2 via 12, When rcceivers send
                             I                                                              capability. Not only caii ODMRP coexist with any unicast
   thcir JOINT A I ~ Lto S
                         E ncxt-hop nodcs, an intcrincdiatc nnde I1                         routing protocol, it can also opemtc vcry erficiently as a nni-
   scls the FG-FLAG and builds ils own JOIN silicc thcrc is                     cast routing protocol. Thus, a network equipped with ODMRP
   a next-node I l l cntry in the JOIN TABLE   received from R I that                       docs not require a separate unicast protocol. Other ad hoc
   matclics its ID. Note that the JOIN TABLE         built by I , hils an                   multicast routing protocols such as AMRoute [ I I],CAMP
   cntry for sender SI but not for S Z bcc;insc the next-node ID                            [lS],RRM [14], and LAM [17] m u s t he run on lop of ii uni-
   for S2 i n the received JOIN TABI.Ii is riot I ] . In the mcantinic,                     cast routing protocol. CAMP, RBM, and LAM in particular
   nodc l 2scls tlic FG-FLAG, constructs its own JOIN TABLE,                                only work with certain undcrlying unicast protocols.
   and sciids it tn its neighbors. Nntc tlial cvcn though l2receives
   thrcc JOIN   TAMI.Es from the rcccivers, it broadcasts l l i c JOIN                      Enhancements
   TAUIUi only oiicc hecausc lhc sccond and third tablc arrivals                            Adopting the Refresh iiilervul vi" Mobiliiy Predictioii ODMRP    ~

   carry no new sourcc infnrmation. Clianncl overhead is t h u s                            requires periodic flooding of JOIN DAM to relresh routes and
   ieduccd dramatically in cases where numerous multicast                                   group mcmbcrsliip. Excessive flooding, howcvcr, is not desir-
   receivers sharc tlic same links to the sourcc.                                           able in ad hoc networks hecausc of bandwidth constraints. Fur-
                                                                                            thermore, flooding oftcn causes congcstion, contention, and
   Data Forwarding                                                                          collisions. Finding the oplimal rcfrcsh interval is critical in
   After tlic group cstahlishment ;ind routc construction proccss. a                        ODMKP perfnrni;incc. Here we proposc a scheme tliat ;idapts
   source caii multicast packets lo receivers via selected
   routcs and forwmiiig groups. When rccciving the                                               -             ~~~                                    ~

   multicast data packct, a nodc fo~warcls imly when it

   is not a duplicxtc and t h e sctting of tlic FG-FLAG for                                                                                    JOIN TABLE   of node RI
   tlic multicast group liiis nnt expired. This prnccdure
   minimizes the lraSfic ovcrhc;id and prevents sending
   packets through stalc routes.
   Soft State
   In ODMRP, no cxplicit control packcts necd be sent                                                                                            52               12

   to join o r leave tlic g r n u p I t a multicast source
   w a n t s to lcavc tlic group, it simply stiips sending
   Join Data packets sincc it docs not have any ninlti-                                                                                        JOIN TABLE   Of   node I ,
   cast dzita ti1 send t o t h e group, I I a rcccivcr 110
   longer wants tn rcccivc from a particular multicast
   group, i t docs n o t ~ c n ttlh e J O I N TABLE f u r that

                                                                                                                                IEEE Nclwork      JanuaryIPchruary 2000

Authorized licensed use limited to: Univ of Calif Los Angeles. Downloaded on October 12, 2008 at 20:20 from IEEE Xplore. Restrictions apply.
                                                                                                 by the previous node with its own information. When
                                                       -Link with delaytime]
                                                                          and       I
                                                                                                 a multicast memhcr rcccives the JOIN DATA, it calcu-
                                                                                                 lates the predicted LET of the last link of the path.
                                                                                                 The minimum between the last link cxpiratiim time
                                                                                                 and the MIN-LET value specified in the JOINDW      A.
                                                                                                 is the routc expiration time (RET). This RET valuc is
                                                                                                 enclosed in the JOINTABLEand broadcast. If a for-
                                                                                                 warding group node receives multiplc J O I N TAULEs
                                                                                                 with different RET values (is., lies in paths from tlie
                                                                                                 same sourcc to multiplc receivers), it sclccts the mini-
                                                                                                 nmm RET among them and scnds its own JOINTABIC
                                                                                                 with the choscn RET valoc attaclicd. Whcn tlic sourcc
                                                                                                 receives J O l N TAHLEs, it selccts the minimum RET
                                                                                                 among all the JOINTABI.F.s reccived. Thcn tlic source
                                                                                                 can build new routes bv floodine a JOINDATAbefore

                                                                                                 tlic minimum RET approachcs (i.e., the route breaks).
                                                                                                    In addition to thc cstimatcd ROT valuc, othcr fac-
the refresh interval to mobility patterns and speeds. By utiliz-                        tors nccd to he considered when clloosing the refrcsli interval.
ing thc location and mobility information provided hy Glohal                            If the node mobility rate is high and the topology changes fre-
Positioning System (GPS) [24], we prcdict the duration of time                          quently, routes will expire quickly and oftcn. l h e sourcc may
routes will remain valid.' With the predicted time of route                             propagate JOINIIATA cxcessively, and lhis excessive flooding
disconnection, JOINDATA arc only flooded when route hreaks                              can cause collisions and congestion, and clogs the network
of ongoing data sessions arc imminent.                                                  with colltrol packets. Thus, the MIN-REFRESH-INTERVAL
   In our prediction method, we assume a free space propaga-                            should be enforced to avoid control mcssagc overflow. On thc
tion modcl 1251, wherc tlie rcceivcd signal strciigth depends                           other hand, if nodcs are stationary o r move slowly aiid link
solcly on its distance to the transmitter. We also assume that                          conncctivity remains unchanged for a long duration of time,
all nodes in the network have their clock synchronized (e.g.,                           routes will hardly expire and the sonicc will rarely send JOIN
by using thc Network Time Protocol, NTP [26], or tlic GPS                               DATA. A few prohlems arise in this situation. First, if a node
clock             Therefore, if the motion parameters of two                            in the ronte suddenly changes its movement direction or
nciglibors (e.g., speed, direction, radio propagatiiio rangc) arc                       speed, the predicted RET vahie becnmcs obsolete and routes
known, we can detcrmiiic the duralion of time these two                                 will not be rcconstructed i n timc. Second, when a nonmember
uodcs will rcmain connccted. Assunic that two nodes i and j                             node which is located remote from multicast members wants
are within transmission rangc r of cacli other. Let (xi, yi) bc                         to join tlie group, it cannot inform thc new mcmbcrship or
the coordinates of mobile host i and (xi, j ) hc those of mobile
                                             y                                          receive data until a J O I N DATA is rcceivcd. Hence, t h e
host j . Also Ict v, and v . bc the speeds, and 'ai and e, (0 5 el, e,                  MAX- FRESH-INTERVAL should be set.
< 2r) be tlic moving directious of nodcs i and j , respectively.
Then thc amount of time that they will stay connected, U,, is                           Route Selection Criteria- In hasic ODMRP, 21 multicast rcceiv-
predicted by                                                                            er selccts routes based on l h c minimum dclay (i.e., routes
                               _ _ _ _ ~ ~ -                                            takcn by the first J O I N DATA received). A different ruutc
          -(ah+cd)     +q
                        @       + c 2 ) r Z-(ad- bc)'                                   selection method is applied when wc usc the mobility predic-
                                                                                        tion. The idca is inspired by the Associativity-Based Rvuting
                                                                                        (ABR) prolocol L271 which chooscs associatively stable routcs.
where                                                                                   In our new algorithm, instead of using tlie minimum dclay
   a = vicosei - vi cosCI,,                                                             path, we choose a route that is the most stablc (i.e., the one
   b = 2 -x.                                                                            with the largest RET). To sclcct a route, a multicast rcceivcr
         I    I'
   c = visinei - v.sin'aj, and
                  '                                                                     must wait for an appropriatc amount of time after rccciving
   d = y; -y,.                                                                          the first JOINDATAso that all possible routes and thcir RETS
Note that when v, = v1 .and Bi = e,, I), is set to -without                             will be known. The rccciver then chooscs the most stable route
applying the above equation.                                                            and broadcasts a JOIN TABLE. Routc breaks will occur less
   To utilize thc information ohtained from tlie prediction,                            oftcn, and the number of JOIN DATA propagalions will reduce
extra fields must he added into JOINDATA and JOIN TABLE                                 because stable routes arc used. An cxainplc showing thc diffcr-
packets. Whcn a source scnds JOIN D A ~ ' A , appends its loca-
                                             it                                         ence between two route scleclion algorithms is prescnted in
tion, speed, and direction. It sets the minimum link expiration                         Fig. 5. Two routes are available from source S to receiver R.
timc (MIN-LET) ficld to the MAX-LET-VALUE since the                                     Routc I lias the path S-A-B-R, and route 2 has thc path S-A-
source does not havc any previous-hop nodc. Thc next-hop                                C-R. If thc minimum dclay is used as the route sclectioii mct-
neighbor, upon rcceiving a JOINDATA,predicts the link expi-                             ric, receiver node R selects routc 1. Route I lias a dclay of I (3
ration timc between itsclf and the previous hop using thc                               + 1 + 3 = 7), whilc route 2 has ii delay of 9 (3 4 2 = 9).  + +
above equation. The minimum between this value and lhc                                  Since the JOINDATAthat takcs routc 1 reaches thc reccivcr
MIN-LET indicated by the Join Data is included in the pack-                             first, node R chooses route 1. If thc stablc routc is sclectcd
et. The ratioiialc is that as soon as a single link on a path is                        instcad, r w t c 2 is choscn by the receiver. The route expiration
disconnected, the entire path is invalidated. The node also                             timc of route 1 is 2 (min ( 5 , 2, 3 ) = 2), while that of route 2 is
ovenvritcs the location and mohility information ficld written                          4 (min (5, 5 , 4) = 4). The rcceivcr selccts tlie routc with the
                                                                                        maximum RET, hencc, ronte 2 is sclectcd.

                                                                                        An Alternative Mrfhod of Prediction - Since GPS may not work
                                                                                        properly in certain situations (e.g., indoor, fading), wc may uot
                                                                                        always he ablc to accuratcly prcdict thc link expiration time for

IEEE Nctwork lanoary/Fehruary 2000                                                                                                                        73

 Authorized licensed use limited to: Univ of Calif Los Angeles. Downloaded on October 12, 2008 at 20:20 from IEEE Xplore. Restrictions apply.
                                                                                              single-device forwarding, no changes were made at the kernel
                                                                                              level. The Linux kernel supports multicast by altering the for-
                                                                                              warding destination interface of IP packets and rapidly for-
                                                                                              warding thcm without sending them to the user level. The
                                                                                              destination interfacc is changcd in accordance with tlie listings
                                                                                              in the kernel-level multicast routing table. The kernel-level
                                                                                              routing tablc is updated and maintained by a uscr-level rout-
                                                                                              ing daemon which kccps its own user-level routing table. The
                                                                                              user-level table is copied to the kernel-level table as the
                                                                                              updates are made. We have used this hasic routing table intcr-
                                                                                              face to build and maintain ODMRP routing tables on both
                                                                                              the kernel and user levels. In the following sections, our
                                                                                              schemes to manage the control packets and routing table are
                                                                                              described, and a forwarding scheme based on virtual inter-
                                                                                              faces is discussed.

                                                                                              Packet and 7able Management - There are two types of con-
          r&o device.                                                                         trol packets in ODMRP. JOINDATApackets are used to adver-
                                                                                              tise the multicast session, and JOIN      TABLE packets are used to
                                                                                              establish the path and the forwarding group. These packets are
     a particular link. However, there is an alternative method to                            implemcnted as new types of Internet Group Management Pro-
     predict the LET. This method is based on a more realistic                                tocol (IGMP) [32] packets with a data section. The existing
     propagation model, and has been proposed in (28, 291. Basical-                           ICMP packet structure and handler function are expanded to
     ly, transmission power samples are measured periodically from                            include functionalities for JOIN DATA and JOIN        TABLE.
     packets received from a mobile's neighbor. From this informa-                                When a JOIN DATApacket arrives at the router, tho con-
     tion it is possible to compute the rate of change for a particu-                         tent of the packet is cached in a temporary routing table,
     lar neighbor's transmission power level. Thcrefore, the time                             t r - t a b l e , and the timer for the entry is started. If the router
     when the transmission power level will drop helow the accept-                            does not receive a corresponding J O I N TABLEn time, the i
     able value (i.e., hysteresis region) can be predicted. We plan to                        timer expires and the cached entry is removed. If a JOIN
     investigate this option in our future work.                                              TABLE         which has a corresponding cntry in the tr-table
                                                                                              arrives before the timeout, tlie user-level routing table, r o u t -
     lmplementation                                                                           ing-table, is searched to find the (source, multicast group)
                                                                                              pair that matches the tr-table entry. If such a pair is found,
      The implementation Piatform                                                             the soft state timer for the entry is reset and the ronter waits
     The operating System and Software - ODMRP is developed                                   for thc next evcnt. If thc pair cannot he found in the r o u t -
     on Linux kcrnel version 2.0.36, the kernel version provided by                           ing-table, a new entry is created and inserted into the table.
     Red Hat Linux version 5.2. All tools and software packages                               The routing-table is periodically checked for timer expira-
     used in our devclopmeut originatc from the software bundle                               tion, and expired entries are removed. The trigger for the
     incorporated within the Red Hat Linux version 5.2 operating                              update of the kernel-level routing table, kr-table, is activat-
     svstem oackaae with the sinelc cxcevtion of a Lucent Wavc-                               ed whenever an entm is inserted or deleted.
     can IEkE SOi.11 device dri& [30]. ?he Linux operating sys-
     tem is chosen for its availahilitv. familiaritv. and.. most
                                                      ,.                                      Forwardina on Virtual Interfaces - DVMRP 131. PIM 161. and
                                                                                              CBT [SI &sed multicast routers are all huili tb: he uiedover
                                                    1 .

     important, kernel-level support for multicasting. Kernel sup-
     port for multicast allows fast kernel-level multicast packet                             wired networks. Thcrefore, their frameworks are designed for
     switching and miuimizes expensive delays caused by
     kerncl-to-application and application-to-kernel-
     lcvel crossing.
        Later, the bandwidth utilization of DVMRP [3]
     in a wireless environment is studied by routing
     Multicast Backbone (MBone) [31] traffic from a
     wired to a wireless network with thc Linux version
     of mrouted, a DVMRP-based multicast routing

     Hardware - Ad hoc network nodes consist of Intel
     Pentium 11-based Hewlett Packard Omnihook 7150
     laptops equipped with Lucent IEEE 802.11 Wave-
     Lan radio devices [30]. The WaveLan deviccs oper-
     ate on 2.4 GHz bandwidth and communicate at the
     maximum capacity of 2 Mhis with the semi-opcn
     space range of 150 m. The WaveLan devices are
     operatcd in an ad hoc mode.
     Software Architecture
     ODMRP uses the kernel-level multicast support
     option built into the Linux operating system. With
     the exception of a minor alteration made to allow                         U Figure 7. The testbed topolo0 for DVMRP traffic traces

     74                                                                                                                           IEEE Nctwark * JanuaryiFebruaty 2000

Authorized licensed use limited to: Univ of Calif Los Angeles. Downloaded on October 12, 2008 at 20:20 from IEEE Xplore. Restrictions apply.
                                                                                 .      .

routers with multiple network interfaces. The for-             Aierage session length                         178 s           NIA
                                                                                 ____.._. .. .
warding capability of these systcms is strictly limitcd        IGMP control packet overhead
to passing the packets from one interface to another.                                  -        ..
In wired networks, having multiple interfaces does             Average number of acr’ue mulricasr ch
not cause any problems since the devices do not
interfere with onc another. This is not the case with          Overhead caused oy multicast channe I
our wirelcss network testhed because we use omnidi-            Banowidth bsea oy data
rectional antennas and a common hroadcast channel.           . ...
Having multiple wireless interfaces does not improve         w Table 1 . DVMRP bandwidth di,vtn‘bution
tlie performance. Unless specifically configured, the
devices interfere with one another. Howcver, tlie
framework in Linux docs allow the fonvarding between virtual          packets received and, at each succcssful reception, record thc
interfaces (VIFs) to support tunneling among multicast                signal strength. Thc signal strength is the signal-to-noisc ratio
islands. Single-device forwarding is madc possible by creating        in dBm. Measuring the pure signal strength alone is meaning-
VIFs through aliasing the existing hardware interface and             less unless the ambicnt noise level is known. The average sie-              I    I

then enabling the fowirding of thcmulticast packets to VIFs           nal strength valucs at cach location are plotted in Fig. 6. As
corresponding to the routing-table entries.                           expected, thc signal strength degraded with incrcase in dis-
                                                                      tance, hut thc packet loss rate remained nearly the same
ODMRP lmplementation                                                  throughout the experiment. The packct loss rate, on averagc,
The enhancement mechanisms utilizing GPS havc not been                remaincd hclow 0.5 percent. The packct loss dcpeiids more on
incorporatcd in our current implemcntation. While the imple-          the position of the node (next to a steel beam, ncdr the eleva-
mentation of our enhancements with GPS is in progress, the            tor, ctc.) than the strength of thc signal a s long as the signal-to-
results rcported in this article correspond to the hasic version.     noisc ratio remains above zero. This result indicates that in our
   For thc ODMRP soft state timer values, we selccted 1 s for         environment, wireless communications suffer more losses from
the routc refresh interval and 5 s for the forwarding group           random noise than from signal degradation. Some of the effects
timeout intelval.                                                     o random channel loss arc explained in the next section.
                                                                                        DVMRP Bandwidth Utilization
Performance Evaluation                                                                  The basic topology of the testbed is shown in Fig. 7. On each
The radio channel performance of a hasic wireless link with                             node, thc DVMRP-based multicast routing daemon mrouted
WaveLAN dcviccs is presented next along with our channel                                is installed. Thc base station in the lower lcft corner of thc
cxperimental results. For multicast experiments, we created a                           figure links the wired and wirclcss networks, and through this
testbed consisting of fonr nodes. The handwidth utilizations of                         node we cxtcnded the Internet multicast backbone (MBonc)
DVMRP and ODMRP are studied, and the rcsults are pre-                                   to thc wireless network. Initially, thc multicast daemons on
sentcd later.                                                                           each nodc arc activated one by onc. Thc timc it takes for thc
                                                                                        routing daemon to stabilizc as the routing updates from tlie
Radio Channel Evaluation                                                                parent node in tlie multicast trce are forwarded is variable.
The channel data was collected hy initiating a large-scale Uscr                         The duration of timc dcpeiids on the number of scnder and
Datagram Protocol (UDP) packet transfer from one station to                             destination pairs in the network. The testhed is rcady for the
another. We chose UDP as the transport layer protocol                                   measuremcnt once the waves of initial control packets subside
instcad of TCP in order to study the behavior of packet loss.                           and a rcgular control packet traffic pattern emerges.
Thc experiments were rcpcated at every 6-m intcrval until it                               Thc cxpcriments are carricd out in the following stcps.
reached the maximum line of sight distancc within tlie huild-                           First, the traffic traccs are started at each router nodc using
ing. At each trial, 13,600 UDP packets of size 532 bytes arc                            tcpdump. The receivcrs at nodes B and D then join an audio
sent. The reccivcrs are programmed to collect the numbcr of                             and a vidco multicast session. The multicast is monitored for
                                                                                                    approximateh 3 min. Thc rcsults arc comoiled in

                                                                                                 I    streams to bcforwarded downsGeam and then
                                                                                                      pruning thc unwanted stream from thc bottom up
                                                                                                      with IGMP messages. This practicc works well it1
                                                                                                      wired networks sincc vcry few control packets are
                                                                                                      lost. In wirclcss networks, however, packet losses
                                                                                                      are Erequcnt. When a prune message is lost, the
                                                                                                      corresponding multicast group is allowed to contin-
                                                                                                      ue forwarding on thc router until another prmie
                                                                                                      message is sent. This causes the control ovcrhead
                                                                                                      shown in Table 1 to be relatively high. If a more
                                                                                                      complex topology is deployed, thcrc will be more
                                                                                                      control packct losses and more bandwidth wastage.
                                                                                                       ODMRP Bandwidth Utilization
                                                                                                      Io ODMRP experiments, thc hasc station nodc of
                                                                                                      thc DVMRP experimcnts is replaced with a wire-
                                                                                                      less source. Thc rcst of the topology is kcpt the
                                                                                                      same as i n DVMRP cxpcrimcnts for comparison
W Figure   8.Testbed topologyfor ODMRP traffictraces.                                                 purposcs (Fig. 8 . The ODMRP multicast routing

IEEE Nclwork JanuarylFebruary2000                                                                                                                     75

 Authorized licensed use limited to: Univ of Calif Los Angeles. Downloaded on October 12, 2008 at 20:20 from IEEE Xplore. Restrictions apply.
        Table 2. ODMXP bandwidth distribution.

   daemon does not need the stabilizing period required by
   D V M R P since n o control packets a r e switchcd betwcen
   routers to establish the initial state. Currently, MBone traffic
   cannot be forwarded onto the ODMRP testbed, so the obscr-
   vation was made at the forwarding group nodes while FTP
   packets were multicast from node C to nodes B and D.The
   results are shown in Table 2.
      The sessions in this experiment last only until the file is
   transferred, so the session length field in the table is left blank.
   Since the forwarding nodes relay the packet only when Join
   Table packets setirefresh the FG-FLAG, unnecessary fonvarding
   does not exist. This results in zero overhead caused by chan-                                  Nov. 1998, pp. 1817-22.
   nels. On the other hand, the control packet overhead is much                                [I41 M. S. C o r m and S. G. E a t 4I, "A Reielvationdored Multicart (REM1 Rout-
                                                                                                  ing Protocol for Mobile Networks: Iniliol Route Construction Phose,"
   larger than in D V M R P since O D M R P control overhead                                      ACM/EoIlzer Wireless Networks, vol. 1, no. 4, Dec. 1995, pp. 427-50.
   increases in proportion t o the numbcr of active channels.                                  . .
                                                                                               1151 J. J. GorciaAuno~Aceverand E. 1. Madruao. "A Multicart Routing Protocol
   Unfortunately, this overhead cannot be totally eliminated,                                      for Ad-Hoc Networks," Proc. IEEE INFOEOM '99, New York, NY, Mor.
   although the amount of control overhead can be adjusted to                                     1999, pp. 784-92.
                                                                                              1161 S. K. S. Gupta ond P. K. Srimani, "An Adoptive Protocol far Reliable Multi-
   an optimal value in time. It is essential for the dynamic adapta-                                cast in Mobile Multi-hop Radio Networks," Proc. IEEE WMCSA'99, New
   tion scheme in ODMRP to use control packets efficiently to                                       Orleanr. LA. Feb. 1998, OD. 111-22.
   adapt to the frequent route changes due to mobility or changes                             1171 L. Ji and M. S. Conon; 'A Lightweight Adaptive Multicart Algorithm." Proc.
   in intermediate link quality. In contrast, recall that DVMRP,                                    IEEE GLOEECOM '98, Sydney, Australia, Nov. 1998, p 1036-42.
                                                                                              [ I E ] Y:E. KO and N. H. Voidya, "Geocarting in M o d A d Hoc Networks:
   when there is a severe change in link condition, simply discon-                                  Location-Eared Mullicoil Alaorithmr." Pioc. IEEE WMCSA '99, New
   tinues the forwarding of the multicast streams. DVMRP rout-                                      Orleonr, LA, Feb. 1999,p~.,l~l-I0;,
   ing table update frequency is inadequate for handling rapid                                (191 T. Ozoki. J. E. Kim, an T %do, Bandwidth-Efficient Multicart Routing
                                                                                                    Pralocol for Ad-Hoc Networks," Proc IEEE ICCCN '99, Boston, MA, Oct.
   topology changes. Because of these limitations, DVMRP can                                         1999, pp. 10-17.
   he operated only in a relatively stable environment.                                       [ZO] E. M. Royer and C. E. Perkinr, "Multicart Operation of the Ad~hocOn-
                                                                                                    Demand Dirtonce Vector Routing Protocol," Proc. ACMAEEE MOBICOM
                                                                                                     '99, Seaftle, WA,Aug. 1999, pp. 207-18.
    Conclusions                                                                               [ZI] P. Sinha, R. Sivakumar, and V. Ehorghavon, "MCEDAR: Multicost Core-
      We present ODMRP for a mobile ad hoc wireless network.                                                                                   -.
                                                                                                    Extraclion Distributed A d hoc Routina." Proc. IEEE WCNC'99. New
                                                                                                    Orleans, LA, Sep. 1999, pp. 1313-17.
   O D M R P is based on mesh (instead of trec) forwarding. It                                1221 C. W. W u and Y. C. Toy, "AMRIS: A Multicast Protocol for Ad hoc Wire-
   applies on-demand (as opposed to periodic) multicast route                                       less Networks," Proc. IEEEMILCOM '99, Atlantic City, NJ, Nov. 1999.
   construction and membership maintenance. The advantages                                    1231 S. Murthy and J. J. Garcia-Luna-Acever, "An Efficient Routing Protocol for
                                                                                                    Wireless Networks." ACM/Boltrer Mobile Networks and Appr., vol. I , no.
                                                                                                                                                                 ,.          no.
   of ODMRP are:                                                                                                         i83-97,
                                                                                                    2, Oct. 1996, pp. 183-97.

    * Low channel and storage overhead
      Usage of up-to-date shortest routes
    * Robustness to host mobility
                                                                                              [24] E. D. Koplan, Ed., Underrtanding the GPS: Principles and Applications,

                                                                                              . .
                                                                                                    Boston: Artech Home, Feb. 1996.
                                                                                              1251 T. S. Raooaoort. Wireless Communications: Princioler and Practice. U ~ o e r
                                                                                                    Saddle &,'NJ:'Prentice      Hall, Oct. 1995.
                                                                                                                                                         '              . I ,

   * Maintenance and exploitation of multiple redundant paths                                 [26] D. 1. Mills, "lnlernet Time Synchronization: the Network Time Protocol." IEEE
   *Exploitation of the broadcast nature of the wireless environ-                                   lmnr. Common.,vol. 39, no. IO, Oct. 1991, pp. 1482-93.
      ment                                                                                    [27] C . Toh, "Armciotivity-Bared Routing for Ad-Hoc Mobile Networks,"
                                                                                                    Wireless P e n Commvn. 1..SDeciol Issue on Mobile Netwoikina and Com-
      Unicast routing capability                                                                       uting Syrlemr, Kluwer, v d 4 : no. 2, Mor. 1997, pp. 103-39. "
      We have studied the performance of O D M R P and                                        [ZEPP. Agrawal, D. K. Anvekar, ond E. Narendron, "Optimol Prioritization of
   DVMRP in a real ad hoc network testbed with four network                                         Handovers in Mobile Cellulor Networks," Proc. IEEE PM R '94, The Hague,
                                                                                                                                                           I MC
   hosts. From our experiments, we discovered that DVMRP                                            Netherlands. Seot. 1994. DO. 1393-98.
   suffered from high channel overhead due to control message                                 129) E. Norend&".          Agra& ond D. K. Anvekar, "Minimizing Cellular Hand-
                                                                                                    over Failures Without Channel Utilizotion torr." Proc. IEEE GLOEECOM '94,
   loss in the wireless channel. Our study showed that ODMRP                                        Son Francisco, CA, Dec. 1994, pp. 1679-85.
   is more suitable in a multihop ad hoc wireless environment                                 [30] W . van der Moolen, "IEEE 802.1 I WaveLAN PC Card Urer'r Guide,"
   than DVMRP. Our ongoing work includes implementing                                               Lucent Technologies, June 1998.
   ODMRP enhancements utilizing GPS, building the network                                     [311 H. Erikrron, "MEONE: The Multicart Backbone," Commun. ACM, vol. 37,

                                                                                                    no. E, Aug. 1994, pp, 54-60.
   for an outdoor environment, and increasing the number of                                   1321W. Fenner, *Internet Group Manogement Protocol, Version 2." RFC 2236,
   hosts in our ad hoc network testbed.                                                             Nov. 1997.

    References                                                                                 Biographies
   [ I ] IETF Mobile A d Hoc Networks (MANET) Working Group Charter;                          SANG Ho EAE ( has received his E.S. in information and comput-
         hnp://"~t-chor,.                                        er science from Univerriy of California, lrvine in June 1992 ond his M.S. in
   [2] J. Jubin and J. D. Tornow, "The DARPA Packel Radio Network Protocolr,"                 computer science from COifornio State Polyiechnic University, Pomona in Decem-
        P m . IEEE, vol. 75, no. 1, Jan. 1987, pp. 21-32.                                     ber 1994. He is currently CI Ph.D. student at the Computer Science Deporiment of

   76                                                                                                                              IEEE Network JanuatyiFchruary 2000

Authorized licensed use limited to: Univ of Calif Los Angeles. Downloaded on October 12, 2008 at 20:20 from IEEE Xplore. Restrictions apply.
University of Colifornio, Los Angeler and CI member of the Wireless Adoptive                 MARIO GEM [MI ( his graduate degree in electrical
Mobili IWAM) Loboratory. His research interest includes multicasting, routing,               engineering from Politecnico di Milono, Italy, in 1966, and his M. S. and Ph.D.
hmdox and forwarding i s m i in od hoc ond cellular wireleis networks.                       degrees in computer science from the University of California, Lor Angeler in
                                                                                              1970 and 1973, respectively. From 1973 to 1976, he was (I monoger (11 the
SUNG-JU LEE [StM] received his B.S. degree in computer sei-                Network Analysis Corporation, Glen Cove, New York, where he WOI involved in
ence and engineering from Honyan University, Korea, in February 1996 and                     sever01 computer network design projects for both government and industry,
his M.S. degree in computer s c i e n c e k m Univerri of California, Lor Angeles in          including performance onolpir and topological updoting of the ARPANET under
June 1998. He is currently CI Ph.D. candidate at #e Computer Science Deport-                 a c ~ n t r afrom the Deparlmenl of Defense. From 1976 to 1977, he wcli with
ment of the University of California, Lor An dei and is also a member of the                 Trun Telecommunication, Lor Angeles, where he poriisipated in he development
WAM Laboratory. His mearch interest incdes ad hoc networks, routing, multi-                  of on integrated packet and circuit network. Since 1977. he has been on the
carting, mobile computing, and wireles~networks performonce evolmlion and                    facul of the Computer Science Deparlmenl of UCLA. His research interests
modeling. He if o student member of ACM.                                                     in&% the design, performonce evolucltion, and control of dirlributed computer
                                                                                             communication I rlemr and networks. His current research projects cover the fol-
WILLIAM [StM] received his B.S. and M.S. in computer sci-
      SU                                                                                     lowing CITBOI: dkrign ond performonce evaluation of protocols and control
ence from the University of California, Los Angeles in 1994 and 1996, rerpec-                Ichemei for od hoc wireless nehvworkr; rouling, multicasti? congertion control,
tively. He is curtently a Ph.D. candidate in computer science and o member of                ond bandwidth allocation in wide orecl networks; and tro IC measurements and
the WAM Laboratory ot UCLA. His ore0 of research includes ad hoc network                     choracterirotion. He currenlly ~ e w e on the editorial b w r d for IEEE/ACM Tmnr-
protocol design ond simulation, wireless ATM networks, and mobile IP.                        actions on Networking and ACM/Ballzer Jaurnol of Wireless Networks (WINET).

                                                            Appendix: Protocoi ~peciiication
Protocol operation specification is presented as a psciido codc in Fig. 9. For more detailed operations, readers are referred to [8].

 ~~                   ~~                               ~~

  Procedure OriginateData                                      Procedure ProcessData                                             Procedure CheckFgFligTimeout
     if (route exists to the destination) and                    if (the received packet is not a duplicate) and                    if FG-Flag-Timer expires
         (Route_nefr-.sh_Timer   has not expired)                             for
                                                                     (m-~iag the multicast group is set)                            then reset FGcF1e.g;
    then send data:                                              then forward data;
    else originate JOIN DATA:

 Procedure ProcessJoinData                                                             Procedure ProcessloinTable
   if the received packet is not a duplicate                                             for each entry in the received JOIN TABLE{
   then {                                                                                   If the node address matches the next.hop address field
       insert (source address. sequence no) into message cache;                            then {
       insen (source address, last hop address) into route table;                               set FG-Flag for the multicast group:
       if the node is a member of the multicast group                                           if the node address does not match the source address field
       then {                                                                                   then build a JOIN TABLE entry with a new next hop address;
           Originate JOIN TABLE;                                                           }
           if n L > O                                                                    1
           then forward JOIN DATA;
          1                                                                              If number of newly built JOIN TABLEentry > 0
          else if T I L > 0                                                              then send JOIN TABLE;
          then forward JOIN DATA;
                                              ~   ~~

 I Figure 9.Protocol specification.

IEEE Network * JanuaryiFehruary ZOO0                                                                                                                                       77

  Authorized licensed use limited to: Univ of Calif Los Angeles. Downloaded on October 12, 2008 at 20:20 from IEEE Xplore. Restrictions apply.

To top