prove the reliability of data packet delivery. ... first looks up its TLT to retrieve the reachability informa- ..... Fig. 10. Ratio of Recovered Data to Recoverable Lost.
SCALABLE TEAM ORIENTED RELIABLE MULTICAST ROUTING PROTOCOL FOR TACTICAL MOBILE AD HOC NETWORKS Emy E. Egbogah1,2, Abraham O. Fapojuwo1, Norbert Chan2 1
Department of Electrical and Computer Engineering The University of Calgary ABSTRACT
This paper presents the Scalable Team Oriented Reliable Multicast (STORM) routing protocol, designed to provide reliability in a tactical mobile ad hoc network (MANET) under a wide range of scenarios and network conditions. STORM organizes individual nodes with similar mobility patterns and speeds into teams, and builds a hierarchy-based multicast mesh structure among elected team nodes. A Unicast Acknowledgement Scheme (UAS) is developed to build the routing structure in an efficient manner. To improve the reliability of STORM, a modified version of Reliable Adaptive Congestion controlled multicasT (ReACT) is used as a reliable transport protocol. The simulated performance results indicate that STORM is scalable with respect to number of multicast groups, multicast sources, and network load. Furthermore, the adoption of ReACT as a transport protocol improves the performance of STORM in conditions of heavy network traffic. I INTRODUCTION A Mobile Ad Hoc Network (MANET) is a selforganizing adaptive network composed of a dynamic collection of wireless mobile devices that can communicate and move simultaneously. MANETs can be formed and de-formed on-the-fly without the support of a centralized administrator or fixed wired infrastructures. Ad hoc networks have mostly been deployed in the military sector where being able to communicate through infrastructureless and wireless means is a necessity. In a tactical environment where military units typically move in groups (e.g. squad, brigade, platoons, battalions, etc.) and must receive up-to-date combat instructions from military headquarters, communication over the ad hoc network can be achieved using multicast routing protocols [1]. However, the integration of multicasting with ad hoc networking poses a set of challenges to overcome, the primary being the design of effective, efficient, and robust multicast routing protocols for tactical MANETs. The design of multicast routing protocols for tactical MANETs is very challenging due to limited radio bandwidth, an unreliable wireless channel, node mobility, multicast group dynamics, and limited battery and memory resources.
978-1-4244-2677-5/08/$25.00 ©2008 IEEE
1 of 7
2
General Dynamics Canada Calgary, Alberta
In this paper, the Scalable Team Oriented Reliable Multicast (STORM) [2] routing protocol is proposed to address the impending issues. The paper offers the following contributions: (1) The design of a multicast routing protocol (STORM) that offers scalability as the network size, multicast groups, and total number of multicast group members increase, (2) A performance comparison of STORM with other existing multicast routing protocols, particularly On Demand Multicast Routing Protocol (ODMRP [3]), Protocol for Unified Multicasting via Announcements (PUMA [4]), and Team Oriented Multicast (TOM [5]), in a large scale tactical MANET where the performance of the protocols is evaluated under several different scenarios, (3) The use of a memory savings mechanism called the Unicast Acknowledgement Scheme (UAS) for creating and propagating control packets with reliable delivery and low memory consumption, and (4) The integration of a reliable transport protocol Reliable, Adaptive Congestion controlled multicast protocol (ReACT [6]) with the STORM protocol to achieve increased reliability in large scale MANETs. The remainder of this paper is organized as follows. In Section II, a detailed description of STORM’s design is presented. Section III evaluates the performance of STORM using a simulation approach and then compares its performance against three multicast routing protocols selected from the literature. Finally, the paper is concluded in Section IV. II STORM PROTOCOL DESIGN STORM is a large-scale multicast routing protocol that offers several enhancements and distinguishing features to and from the TOM routing protocol – an existing hierarchical-based multicast protocol. One of the distinguishing features of STORM is its use of UAS for unicast transmission to reliably deliver control packets from source to destination in order to build its routing structure. UAS is employed because it consumes significantly less memory resources than flooding and broadcast, while also being able to reliably deliver control packets. This is beneficial for military communication equipment that has limited battery and memory resources. A second distinguishing feature of STORM is its use of a combination of ondemand and periodic mechanisms to maintain the multi-
cast mesh structure more proficiently. Another feature that distinguishes STORM from TOM is the adoption of a modified reliable transport protocol called ReACT to improve the reliability of data packet delivery. The following content further describes the design of the main features of STORM. A. Team Definition and Discovery A team is formed based on a group of nodes’ relative mobility, common interests, and ability to reach one another. The nodes in a team share multicast group membership, meaning any two nodes in the same team should have subscribed to at least one common multicast group. By subscribing to a common group, nodes in the same team implicitly share the same interest. When all the nodes belonging to a group have been learned, each node within the group elects a team leader. The node that receives the most votes becomes the team leader node (TLN) and a team is subsequently formed. The TLN is responsible for maintaining routing information and forwarding data to its members. B. Multicast Mesh Creation Once all the teams in the network have been formed, the TLN of each team initiates the Group Membership Join procedure for the purpose of joining a multicast mesh structure. Membership to the multicast mesh structure is initiated and maintained by a group manager node (GMN). A TLN is designated as a GMN if it is the first node to join or discover a multicast group. In a connected multicast mesh structure, each TLN has at most c routing paths to other TLNs so that any two TLNs in the multicast mesh structure can be mutually reachable. The value selected for parameter c affects the redundancy of the mesh and influences the overall reliability of the network. Increasing the value of c results in increased number available routing paths to deliver data in the mesh. To ascertain the full connectivity of the mesh (i.e. each TLN is connected to at least another TLN), c should be greater than 2, as recommended in [5]. An illustration of a fully connected mesh with c = 3 is shown in Fig. 1.
C. Multicast Mesh Structure Maintenance To maintain the connectivity of the multicast mesh structure, each TLN manages a table that stores the reachability information for every other TLN in the network. The table is called the team leader table (TLT). A TLN’s TLT contains an entry for each neighboring TLN and specifies how many hops away the neighboring TLN is, the next hop node to it, and when an update was last received from it. A TLN uses its TLT to determine the most suitable neighboring TLNs to connect to. For example, a neighboring TLN B that is 1 hop away and has routing updates that are regularly received by a TLN A is a better candidate for connection than a neighboring TLN C that is 3 hops away and has transmitted updates that are seldom received. 1. Group Membership Join When a new team wants to join a multicast group, its TLN first looks up its TLT to retrieve the reachability information for the GMN of the multicast group it wants to join. If the GMN for the particular multicast group is not found in the TLT, it is assumed that either the TLN is a new incoming node to the network (with no TLT entries) or that no TLN has subscribed to the multicast group yet. As a result, the TLN claims itself as the GMN of the multicast group and starts advertising the new membership information for the multicast group through the periodic TLT exchanges. If the GMN for the multicast group is found in the TLT, the TLN sends a Join Query (JQ) request to the GMN. After receiving the JQ request, the GMN assigns the requesting TLN a unique sequence number that is used for the maintenance of the multicast group. The GMN also sends a Join Reply packet and member list table (stores information for all the TLNs that have already joined the multicast group) to the TLN to indicate that it can now initiate a connection request to join the multicast group. The entire process is illustrated in Fig. 2. seqmg = 6
D
V1
C(3)
B(2)
C(3) D(4)
1
C
Join Query
Level - 1 B
F(6) E(5)
A
TEAM 1
G()
V2
seqmg = 7
A(1) GMN
A(1) GMN
Multicast Mesh Structure A
seqmg = 6+1 = 7
B(2)
A(1) GMN
C(3) D(4)
Join Reply 2 F(6) E(5) 3 Connection Request G(7)
B(2)
X
D(4)
4
Disconnected path F(6)
E(5)
Connection Granted 5 G(7)
D C
TEAM 4
Level - 2
V3 B
V4
(a) Joining TLN sends Join Query1 to GMN
TEAM 3 Team Leader Node (TLN)
TEAM 2
4 (b) GMN sends Join (c) Old path is disconnected 5 Reply2 back to TLN with to allow for new connection new seq number; TLN to joining TLN then sends a Connection Request3
Fig. 2. Illustration of Join Procedure with c = 3
Team Member Node
Fig. 1. Multicast Mesh Structure with 3 connections
2 of 7
2. Connection Establishment Using the information stored in its member list table (MLT), a TLN sends up to c Connection Request Packets (CRP) to the neighboring TLNs that are reachable within the fewest hops. These neighboring TLNs must have a sequence number less than its own. Sequence numbers are used as a tool to assure that all TLNs connected to the mesh routing structure are mutually reachable. If the sequence number of the TLN searching for a connection is less than another TLN, it is designated as a child TLN. If it is greater, the TLN is a parent TLN. Each TLN maintains tables for the child and parent TLNs it has established connections with, called Child Table (CT) and Parent Table (PT), respectively. A TLN can have a maximum of c active connections to a combination of child and parent TLNs. To ensure that all TLNs can communicate with each other in the mesh, each TLN must be connected to at least one parent TLN (A proof is provided in [5]). A TLN initiates the connection process by sending CRPs to its neighboring TLNs. If a neighbor TLN receives a CRP, it responds to the request based on the conditions listed in Table 1. Table 1. TLN’s response to a Connection Request Condition Less than c Connections
Response Grants connection request and updates its CT or PT Connected to 1 parent Connection request is rejected TLN Greater than c Connec- (1) Removes connection to tions and connected to furthest away parent TLN more than 1 parent TLN (2) Grants connection request TLN is a GMN, has c (1) Removes connection to connections, and is not furthest away child TLN connected to a parent (2) Grants connection request TLN If a TLN is granted a connection by a neighboring TLN, it updates its CT (or PT) to indicate that it is either a new parent (or child) TLN to the neighbor TLN that granted the connection. For the purpose of fault tolerance and redundancy, the TLN always floods a copy of its CT or PT to its team members when a new connection has been established. Each time a TLN has been granted a new connection, it must also inform its GMN. If a TLN that is also a GMN has been granted a new connection it must forward the new connection information to its head GMN. If the TLN is a head GMN (has children nodes that are GMNs), it does not have to publicize the new connection. When the GMN receives the information regarding the new connection, it updates its MLT and propagates the new changes to all the TLNs that belong to the multicast group. By doing so, all TLNs have up-to-date knowledge of the members belonging to its multicast group.
3. Connection Maintenance The key strength of STORM is its ability to maintain the connections established between TLNs in the midst of a dynamic network environment. Each TLN monitors the stability and liveliness of connections to other TLNs by utilizing information received from periodic TLT exchanges. Each time a periodic TLT update is received from a connected parent or child TLN, the TLN updates the entry in its TLT that matches the TLN from which the update was received. If an update has not been received from a connected TLN for a period T, the entry for the connected TLN is removed from both the MLT and CT/PT. If a TLN loses a connection to the only parent TLN it was connected to, it must reinitiate the Connection Establish procedure to reconnect to a different parent TLN. Although each TLN only requires a single connection to a parent TLN to maintain connectivity in the mesh, STORM attempts to connect the TLN to a maximum number of TLNs to promote redundancy and higher reliability. If the TLN has less than c connections, it does one of the following: (1) If it has no connected parent TLN, it attempts to connect to the closest parent TLN or (2) If it does have a connected parent TLN, it attempts to connect to the closet child TLN. In addition to monitoring and maintaining connections with each periodic TLT exchange, current connections are constantly analyzed to assure that they are the most optimal connections available. For example, when a new connection is granted in the multicast group, the GMN is notified and it sends an updated copy of the MLT to all TLNs in the multicast group. If the MLT is received by a TLN that already has a maximum number of connections, it searches the MLT to determine if a neighboring TLN’s hop count to it is less than or equal to half the hop count of one of its currently connected TLNs. If so, a connection request is sent to that TLN. 4. Propagation of Mesh Structure Control Packets STORM uses UAS to propagate control packets such as Join Query, Join Reply, Connection Request, Disconnection Request, etc. Unicast of control packets to build the multicast mesh is chosen over flooding because it requires far less memory resources. Yi et al.[5] used flooding for building the mesh in a large sized network. However, our experience has shown that employing flooding consumes a significant amount of memory resources and may thus pose problems for the memory and battery limited devices deployed on battlefields. As a result, an alternative method, UAS, was conceived to efficiently and reliably deliver control packets from one TLN to another. In UAS, control packets are unicast hop by hop to the destination. An acknowledgment packet is sent to the previous hop node with each successful reception of the control packet. For example, when node n wants to transmit a
3 of 7
control packet to a destination node d that is several hops away; it first determines the next hop node to d. It is done by looking up node n’s Local Routing Table (LRT) and finding an entry for node d. If an entry is not found, the node then searches its TLT for a match for d. If that search is also unsuccessful in yielding a next hop node, node n checks its Neighbor NextHop Table (NNT) for a path to the destination. If the NNT has no entries, it means that node n does not have knowledge of a next hop to node d. and must use a broadcast instead of a unicast to send the control packet. To build a path for sending control packets using UAS, the neighbor query process is initiated. The goal of the neighbor query process is to query node n’s neighbors for a next hop node to node d, and store the result in node n’s NNT. The neighbor query process starts by node n broadcasting a Neighbor Query packet to all its neighbors. Each neighbor node responds to the query with a Neighbor Reply packet specifying a next hop node and the hop count to node d. Upon receiving the Neighbor Reply packets from all neighbors, node n updates its NNT and proceeds to send the control packet to the next hop node with the shortest path to node d. When a node on the path to a destination has a control packet to forward, it first stores a copy of it in its Ack Receipt Table. An entry of the Ack Receipt Table maintains the acked attribute to indicate whether the reception of the control packet was acknowledged. If the control packet has been sent via unicast to a next hop node, the reception of the control packet by the next hop node is acknowledged with an Acknowledgement packet. If the Acknowledgement packet has not been received within a certain interval TACK, the sender node assumes that the next hop node did not receive the control packet and retransmits it up to 3 times (waits TACK between each retransmission). If the unicast transmission is unsuccessful, the control packet is broadcasted. An acknowledgement packet is not required when the control packet is broadcasted. Upon successfully transmitting the control packet, the entry in the Ack Receipt Table that corresponds to the control packet is removed. D. Intra-team Membership Maintenance and Data Forwarding STORM uses a similar scheme to [5] for intra-team membership. For intra-team data forwarding, STORM uses a scoped flooding algorithm. If a node receives a broadcasted team data packet, it compares the Neighbor List Table (NLT) of the transmitting node to its own NLT. If the entries in the receiving node’s NLT have 85% of the entries in the transmitting node’s NLT, it does not forward the team data packet, otherwise it does. E. STORM with Reliable Transport Protocol STORM uses a modified version of the ReACT protocol [6] to perform receiver-based error recovery and source-
based control. Two modifications are made to the ReACT protocol, as described in the following sub-sections. 1. Selecting a Recovery Node In order to recover from losses locally (i.e. losses suffered within a team or multicast group), nodes must obtain information about other multicast group members as potential recovery nodes. Each node maintains a reliability metric which stores a running percentage of multicast data packets it receives from its recovery nodes. This reliability metric is used to select the best node for recovery if multiple ones exist. When receiving a new data packet, the member node updates the reliability metric of the member from which the data packet was last received. The reliability metric of the member node is calculated by first searching the data cache for the last data packet received (pktsTxd) from the data source. Next, the data cache is searched for the total number of data packets received (pktsRcvd) from the member node for the data source. The reliability metric is then calculated by the formula:
reliability _ metric =
pktsRcvd pktsTxd
(1)
2. Feedback Control When there are lost packets, a Feedback Receiver node must be selected to assure the lost packets are reliably recovered. In this paper, we modify the ReACT protocol so that a node chooses a new feedback receiver based on common lost packets. Fig 3 illustrates the selection of the feedback receiver using common lost packets. Stored Pkt (s) [7,9] Selected Feedback Receiver D
C
Node that Lost Packets
B Stored Pkt (s) [3,9]
A Lost Packets [3,5,7,9]
Stored Pkt (s) [5]
Fig. 3. Selection of Feedback Receiver using Common Lost Packets In Fig. 3, node D is selected as the recovery node because it has all the lost packets that are common to all the feedback receivers. The benefit of selecting the feedback receiver based on common lost packets is the reduction in number of retransmissions. Using Fig 3, the round robin approach adopted in ReACT would result in 3 retransmissions (by nodes A, B, and C) while the common lost approach uses 1 retransmission to send the packets (by node D).
III
PERFORMANCE EVALUATION
A. Methodology The performance of the proposed STORM protocol is evaluated using QualNet 3.9. In our simulations, each source generates data in a Constant Bit Rate (CBR) fash-
4 of 7
Each simulation was executed five times with random seed numbers and the results were averaged over those runs. The results are presented with 90% confidence intervals, shown for STORM only. The simulations for ODMRP and PUMA were executed for 200 seconds while the STORM and TOM simulations ran for 100 seconds with randomly chosen multicast source(s) and destination team(s). By default, each source transmits packets at a rate of 4 packets per second with each packet having a size of 512 Bytes unless otherwise specified. The performance of the protocols is measured by the following metrics: Packet Delivery Ratio (PDR), Number of Data Packets Transmitted per Data Packet Delivered, and Number of Control Bytes Transmitted per Data Byte Delivered. These metrics were suggested by the Internet Engineering Task Force (IETF) MANET working group for routing/multicasting protocol evaluation [8]. B. Simulation Results and Discussion Experiments were carried out to determine the effect of scalability (number of multicast sources, number of multicast members and groups) and mobility on the performance of the ODMRP, PUMA, TOM, and STORM multicast routing protocols. Additionally, experiments were executed to determine the effect a reliable transport protocol (mReACT) would have on the performance of STORM.
5 of 7
1 Packet Delivery Ratio
In addition to STORM, we implemented three multicast routing protocols for MANETs: ODMRP, PUMA, and TOM, and validated our implementations against those in the published literature. For the configuration of the network, 1000 nodes are uniformly placed within a 6000m x 6000m terrain. The network is divided into 36 groups (average of 25 members per group) where each group moves following the Reference Point Group Mobility (RPGM) model [7]. For all simulations (except for the mobility study) each group moves at 10 m/s with a pause time of 10 seconds. The relative speed amongst the individual nodes is 1 m/s. For maintaining the routing structures, ODMRP uses 3 second intervals for each Join Query, PUMA uses 3 second interval for each Multicast Announcement, and STORM and TOM use 1 second intervals for TLN/TRN Table updates and 5 second intervals for Local Routing Table updates. Both STORM and TOM have a multicast mesh structure that maintains 3 undirected connections with other team leaders.
1. Impact of Scalability on Performance To test scalability, the number of multicast groups is varied across the set {1, 2, 3, 4, 5}. Each multicast group has five randomly selected subscribed teams with a single multicast source. Fig. 4 shows a plot of the PDR versus the number of multicast groups. As the number of multicast groups increases from 1 to 3, the PDR of all the protocols decreases slowly to 80%. However, when the number of multicast groups increases to 4, the PDR of ODMRP and PUMA drops drastically to 45% and 55%, respectively, while the PDR of STORM and TOM stays relatively constant at 78%. Although ODMRP and PUMA utilize 5 to 50 times less control overhead than STORM and PUMA (as seen in Fig. 5), the significant drop in PDR when the number of multicast groups is greater than 3 indicates that the flat architecture employed by ODMRP and PUMA is not scalable. Since STORM is able to consistently maintain a higher level of reliability in its delivery of data packets than ODMRP and PUMA, the fact that it expends significantly more control overhead than ODMRP and PUMA is not a major concern. 0.9 0.8 0.7
ODMRP
0.6
PUMA
0.5
STORM
0.4
TOM
0.3 1
2
3 Multicast Groups
4
5
Fig. 4. PDR as a function of Multicast Groups 12 Number of Control Bytes Txed / Data Byte Delivered
ion with the User Datagram Protocol (UDP). We use the IEEE 802.11 MAC with Distributed Coordinated Function (DCF) and the two-ray ground path-loss model with no additional fading for the physical channel. The transmission range of each node is 376m and the bandwidth of the device is 2Mbps.
ODMRP
10
PUMA STORM
8
TOM
6 4 2 0 1
2
3
4
Multicast Groups
Fig. 5. Number of Ctrl Bytes Transmitted per Data Byte Delivered as a function of Multicast Groups
5
2. Effect of Mobility on Performance In this experiment, the group speed is varied in the range {2, 10, 15, 20} m/s with 10 seconds pause time. Seven randomly selected teams subscribe to a single multicast group and there is 1 data source. In Fig. 6, the PDR as a function of speed is shown for the four multicast routing protocols. All the protocols show decreasing PDRs as the mobility increases because it becomes increasingly difficult to maintain up-to-date routing information due to an increased number of link failures and frequently changing routing paths. 1
Packet Delivery Ratio
0.95 0.9 0.85 0.8 0.75
ODMRP
0.7
PUMA
0.65
STORM
0.6
TOM
0.55 0.5 2
10
15
20
Mobility Speed (m /s)
Fig. 6. PDR as a function of Mobility Speed
Of the four multicast routing protocols evaluated, the proposed STORM protocol is the most robust to mobility. STORM has a PDR of 87% when the speed is 20 m/s. The main reason for the high PDR displayed by STORM at high mobility is its ability to maintain connections amongst TLNs in the mesh. In contrast to TOM, TLNs in STORM are encouraged to connect with up to three other TLNs. By connecting with more TLNs, the data forwarding structure promotes redundancy through the presence of multiple forwarding paths. The resiliency of STORM to increasing speed is further evidenced by the relatively small increase in control overhead in Fig. 8. For example, there is only an 18% increase in control overhead when the speed increases from 10 to 20 m/s.
3.5
Number of Control Bytes Txed / Data Byte Delivered
Number of Data Packets Txed / Data Packet Delivered
4
packet delivered. In TOM, the PDR decreases significantly from 91% to 67% as the mobility increases from 2 m/s to 20 m/s, respectively. The results show that at lower mobility speeds, team representative nodes (TRN) can connect and form a mesh more effectively and thus deliver more packets. When the mobility speed increases, it becomes increasingly difficult for TRNs to form a stable mesh and stay connected to each other. As a result, the TRNs become disconnected and continuously attempt to regain their lost connections. The increased level of control overhead displayed in Fig. 8 as the mobility speed increases shows that the TRNs in TOM are continuously attempting to reconnect (sending Join Query packets) with each other. The increased control overhead eventually leads to congestion and a lower PDR.
3 2.5 2 1.5
ODMRP
1
PUMA STORM
0.5
TOM
0 2
10
15
12 10 8 6
ODMRP PUMA
4
STORM
2
TOM
0 2
20
10
15
20
Mobility Speed (m /s)
Mobility Speed (m /s)
Fig. 7. Number of Data Packets Transmitted per Data Packet Delivered as a function of Mobility Speed
Fig. 8. Number of Control Bytes transmitted per Data Byte delivered as a function of Mobility Speed
Both ODMRP and PUMA deliver a reasonable percentage of packets when the speed is high (77% and 73%, respectively, at 20 m/s). At high node speeds when link breaks are prevalent, ODMRP and PUMA create an increased number of forwarding paths to reliably deliver data packets, as seen in Fig. 7 by the increased number of data packets transmitted per data
3. Effects of Using Reliable Transport Mechanism In this experiment, the performance of two different transport protocols, UDP and modified ReACT, running over the STORM protocol, were simulated. The modified ReACT (mReACT) protocol was simulated both with a sender backoff rate mechanism enabled and disabled.
6 of 7
Figs. 9 and 10 show the results of the simulation.
IV CONCLUSION In [9], Mandak states that Tactical Networks should be able to support a packet loss between 20% and 40%. Therefore, it is deemed that a packet delivery ratio of 80% is acceptable for any of the results. Using the mentioned guideline, the following observations can be made from the simulation results: (1) A hierarchical architecture is more scalable than a flat architecture because a significantly higher PDR was delivered as the number of multicast groups was increased, (2) STORM was the most resilient to path changes and link breaks caused by increased mobility, suggesting that a multicast routing protocol be designed to use a combination of periodic and on-demand mechanisms to maintain its routing structure, and (3) Employing the mReACT (with backoff enabled) with STORM can improve the reliability of a multicast routing protocol in a large scale MANET that has highly mobile nodes and heavy traffic.
1 0.9 Packet Delivery Ratio
0.8 0.7 0.6 0.5 0.4
STORM w UDP
0.3
STORM w m ReACT
0.2
STORM w m ReACT & Backoff
0.1 0 4
8
12
16
24
32
Netw ork Traffic Load (pkts/sec)
Fig. 9. PDR as a function of Network Traffic Load with Different Transport Protocols
REFERENCES
In Fig. 9, STORM with mReACT and backoff, delivers approximately 15% more data packets than STORM with UDP when the network source traffic load is 32 packets per second. By accurately detecting congestion in the network, mReACT alerts the source node(s) to reduce the data sending rate so that the congestion in the network can be eased and data packets adequately recovered. Fig. 10 shows that the recovery mechanism in mReACT recovers approximately 43% of recoverable lost data packets when the network traffic is 32 packets per second. There is a tradeoff to increasing reliability in STORM using mReACT when the network is congested: lowered delivered throughput for higher reliability. 0.5 Recovered Data Packets / Recoverable Data Packets
0.45 0.4 0.35 0.3 0.25 0.2 0.15
STORM w m ReACT & Backoff
0.1
[1] J. Macker, J. Klinker, and M. Corson, "Reliable Multicast Data Delivery for Military Networking”, Proceedings of IEEE MILCOM '96, vol.2, no.1, pp. 399-403, Oct 1996, doi:10.1109/MILCOM.1996.568570 [2] E. Egbogah, “Scalable Team Oriented Reliable Multicast Routing Protocol for Tactical Mobile Ad hoc Networks”, Master’s Thesis, University of Calgary, Jan 2008. [3] SJ. Lee, W. Su, M. Gerla, “On-Demand Multicast Routing Protocol in Multihop Wireless Mobile Networks,” Mobile Networks and Applications, vol.7, no. 6, pp. 441–453, Dec. 2002. [4] R. Vaishampayan and J.J. Garcia-Luna-Aceves, "Efficient and Robust Multicast Routing in Mobile Ad Hoc Networks", In Proceedings of the IEEE International Conference on Mobile Ad-hoc and Sensor Systems, pp. 304-313, Oct 2004. [5] Y. Yi, M. Gerla, JS. Park, and D. Maggiorini, "Team-oriented Multicast: A Scalable Routing Protocol for Large Mobile Networks", Proc. 5th International Workshop on Networked Group Communications (NGC 2003), pp. 143–154, Sep. 2003. [6] V. Rajendran, Y. Yi, K. Obraczka, SJ. Lee, K. Tang, M.Gerla, “Reliable, Adaptive, Congestion-Controlled Adhoc Multicast Transport Protocol: Combining Source-based and Local Recovery”, Lecture Notes in Computer Science, vol.3042/2004, Springer Berlin/Heidelberg, pp. 112-124, 2004. [7] X. Hong, and M. Gerla, "Dynamic Group Discovery and Routing in Ad Hoc Networks", in Proc. of the First Annual Mediterranean Ad Hoc Networking Workshop (Med-hoc-Net 2002), Sep. 2002. [8] S. Corson and J. Macker, “Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations”, RFC 2501, IETF, January 1999. [9] W. Mandak, “Network-Centric Applications and Tactical Networks”, in Proc. Of the Eighth International Command and Control Research and Technology Symposium, June 2003.
0.05 0 4
8
12
16
24
32
Netw ork Traffic Load (pkts/sec)
Fig. 10. Ratio of Recovered Data to Recoverable Lost Data Packets as a function of Network Traffic Load
7 of 7
