Advances in wireless technology and portable computing, along with demands for greater user mobility, have provided a major impetus toward the development and deployment of multicast services to support data-centric mobile computing and content distribution in Mobile Wireless Networks (MWNs). The main objective of a multicast service in WMNs is to deliver content with a high degree of reliability to a dynamic group of receivers. Efficient multicasting in mobile and wireless networks faces numerous challenges not encountered in other types of networks. Some of these challenges are inherent to the complexity of the problem itself, whereas other challenges result from characteristics of the environment.
The challlenges inherent to the multicast problem stem from the fact that building an optimal multicast tree is NP-complete. This is further compounded by the need to create and manage a group of nodes as a multicast group in which the nodes may join and leave the group over time. The challenges resulting from the environment result from the characteristics of the wireless network infrastructure, communication devices, and transmission meduim. The time-varying nature of MWNs, coupled with node mobility, leads to high-level of unpredictability which may require significant cooperation among nodes to route traffic. The limited transmission, computing, and storage capabilities of the nodes further compound this problem. These inherent limitations must be considered in the development of multicast protocol for MWNs. Consequently, any solutions to the multicast problem in MWNs must address the following set of questions:
How can we make end-to-end delivery of data in multicast group communications highly reliable?
How can we adapt to the variability in bandwidth when sending packets to a multicast group?
How can we reduce the impact due to mobility to the overall performance of the multicast protocol?
This paper addresses these challenges by providing a framework and architecture with proactive and reactive components to support multicasting in MWNs emphasizing reliability and efficiency of end-to-end packet delivery. The architecture includes the Robust Multicast Routing protocol (RoMR) to provide multicast services to multicast applications. RoMR's proactive component calculates multiple multicast trees based on the prediction of future availability of the links and the assumption that the trees will become disconnected over time. The reactive components respond to changes in the network topology due to the mobility of the nodes and to changes in the multicast group's membership.
Sending redundant data packets over multiple paths further enhances the reliability at the cost of an increase in the use of network resources. RoMR uses approximations to Steiner trees during tree formation and forward error correction (FEC) encoding techniques during packet transmission in order to counteract this increase. To avoid additional network traffic, trees are distributed only when the existing trees cannot be easily patched to accommodate changes in topology or group membership.
The novelty of the proposed protocol stems from integrating techniques that have not previously been combined into a multicasting protocol and a unique method to calculate the relative weights of the links.
In addition to the specifications of the protocol, a simulation framework was developed to test different implementations of the various components of RoMR. Simulations compared the performance of the basic version of RoMR to a version that ignored link weights, and to the Multicast Optimized Link State Routing (MOLSR) protocol, a source tree-based, topology-aware multicast protocol. A statistical analysis of the results showed that RoMR performed better, overall, than the other two protocols.
The rest of the paper is organized as follows: in Section 2 background material on routing protocols is presented as well as a discussion of several multicast protocols that have been proposed for use in wireless ad hoc networks. In addition to the protocols is a section pertaining to multicast trees, concentrating on Steiner tree heuristics. Section 3 gives an overview of the RoMR protocol, our solution to the multicasting problem in MWNs. Section 4 derives the formulas used to compute the weights associated with the links in a network and Section 5 presents the algorithms of RoMR. The parameters, results, and analysis of the data generated by the simulation are given in Section 10. Finally, the conclusion and future work are discussed in Section 13.
2. Related Work
Multicast algorithms designed for wired networks do not adequately deal with problems that arise due to a node's mobility or to the less reliable transmission medium. Although some of the wired protocols can deal with link or node failures as rare events, they would not be able to handle the increased frequency of failures found in a wireless ad hoc network in an efficient manner.
To address these shortcomings, a number of multicast protocols were designed specifically to address the characteristics of a wireless ad hoc network. Some are based on source-rooted trees; others on shared trees. MAODV is an example of the former and Ad hoc Multicasting Routing protocol (AMRoute), Ad Hoc Multicasting Routing protocol utilizing Increasing ID NumberS (AMRIS), and G-S are examples of the latter. Several proposals including Multicast Core Extraction Distributed Ad hoc Routing (MCEDAR), Core-Assisted Mesh Protocol (CAMP), and On-Demand Multicast Routing Protocol (ODMRP), are based on meshes to increase the protocols' robustness.
MAODV is not an extension of AODV, but is considered to be an integral part of AODV which can perform unicasting, multicasting and broadcasting 1. The process of joining a multicast group is similar to discovering a route to another node when sending a unicast message. The node wishing to join the group sends a route request message with the join flag set to the group leader in a unicast message if the leader is known. If the node does not know of a route to the leader or does not know the identity of the leader the request is broadcast. All nodes that receive the request record which node sent the request and on which link. If the node receiving the request is already part of the tree, it sends a reply message to the requester via unicast; otherwise it rebroadcasts the request to its neighbors. When the network becomes partitioned, a new group leader is selected for the section without a leader.
The AMRIS is based on a shared tree and is geared towards long-lived multicasting sessions so that route reconstruction is emphasized over route discovery 2. Each node is assigned an ID number that increases with the number of hops from the core, usually the first source node. In order to reduce the number of join requests that propagate through the network, nodes only forward requests to lower numbered nodes. Each node on the tree periodically sends a one-hop broadcast containing its ID number as well as the ID numbers for its parent and children. When a link breaks, the higher numbered node (downstream from the core) is responsible for recovery actions. If it knows of a neighboring node that is a potential parent, it will send a join request to that potential parent node, otherwise it will broadcast a join request using an expanding ring search technique. If the upstream node of the broken link has no other downstream children on the tree then it will request to be pruned from the tree.
The AMRoute is another protocol based on the idea of a shared tree, but only the senders and receivers are nodes of the tree; there are no relay nodes. This is accomplished through the use of IP-in-IP unicast tunnels. If a tree contains a virtual link between node A and node B, AMRoute uses a unicast route between the two nodes. If the path from A to B changes, the multicast tree is not affected as long as some path between the two nodes exists. Dynamically chosen core nodes detect new members and manage the tree but they are not central data distribution points as in other shared tree protocols. Several restrictions are imposed on tree nodes—a node is not allowed to graft itself to its own logical core, a node is only allowed to have a limited number of tree links, and a node's designation as a core can be changed due to characteristics of the multicast tree or an expired time period. Disadvantages of the scheme are reduced efficiency since the intermediate nodes between A and B do not participate in packet replication and an increase in the delay of the receipt of a packet, although it is no more than twice the delay in a protocol in which the unicast tunnels are not used.
A multicast protocol for mobile multi-hop radio networks, based on the Core Based Tree protocol, aims at increasing the reliability of a multicast message arriving at each of the intended receivers 3. When a node becomes disconnected from the multicast tree, it sends a REJOIN message downstream along the old tree branches. A REJOIN message causes a node to destroy its current routing information for the multicast tree and to have member nodes send a join request to the core. The use of the old path prevents loops from occurring. While the node is in the process of becoming reattached to the tree, any messages that are sent to any of the multicast nodes in the disconnected fragment are flooded into a selective area. The calculation of the flooding area guarantees that the message will be delivered to the destinations if possible.
The ODMRP is a multicasting scheme which uses a mesh over which packets are forwarded through the use of scoped flooding 4. Moreover, since ODMRP builds its own link state tables on demand, it can function as a unicast routing protocol as well as a multicast protocol without the need to maintain global link state information.
As found in many of the multicast protocols, ODMRP has a request phase and a reply phase. A source periodically broadcasts a join request throughout the network. When a join request is first received by a non-member node, it stores the incoming link as the link from the source and rebroadcasts the packet. When a node that wishes to become a member of the group receives the join request, it updates its own join table and periodically broadcasts it to its neighbors. If a node that receives a join table is listed as one of the entries, it becomes a forwarding node, updates its own table and sends it to its neighbors, thus propagating the multicast group link state information. The method of joining a group produces shortest paths from each source to each receiver. The intermediate nodes simply flood a non-cached data packet if the node is on any one of these paths. The flooding increases the robustness since a node that is mobile has a better chance of receiving one of the redundant data packets. An extension of ODMRP incorporates predictions based on traffic patterns gathered from a global positioning system (GPS) to determine how long a route is good and to compute the timeout values for the soft state and the frequency of join request broadcasts.
The CAMP creates a mesh of shared trees and shortest path trees 5, 6. It relies on a distance vector unicast wireless routing protocol (WRP) to determine paths to cores and to source nodes. Core nodes may be designated at the time the multicast group is set up or they may be dynamically chosen. The former assumes that a node can find out initial group information from a service similar to a domain name server (DNS). The latter requires the core to periodically broadcast its own advertisement messages.
The MCEDAR is a multicast version of the unicast routing protocol CEDAR7. MCEDAR uses a subset of the core nodes established by CEDAR for group communication. A ‘robustness factor’ controls the number of core neighbors a core may have in a multicast group's mesh. The group's core nodes perform multicast tree operations on behalf of the nodes in their domain. Communications pertinent to the multicast group are efficiently broadcast over the mesh. Each core node implicitly determines a source-based tree from itself to the other core nodes over the mesh established for the group as a result of the core broadcasts. Data forwarding can be done over these trees, but an optimization is available to reduce the congestion on the mesh and the length of the paths. In the optimization, each core node determines a source-based tree from the nodes in its domain to those in the neighboring downstream domains.
Multicast is an efficient point-to-multipoint communication paradigm in local area networks. The focus of multicast protocols in these environments is on achieving bandwidth efficiency and reducing feedback collision 8. Most of these approaches use group consensus and leadership election as the basis for multicasting 9. Scalable and efficient approaches for multicating in wireless mobile networks have taken a hierarchical approach to achieve efficient and adaptive multicast communications firstly inside each cluster and secondly among the clusters 10. Other approaches have been proposed to reduce overhead by eliminating unnecessary traffic to non-interested recipients 11, and achieve fast failure recovery by using logical ordering of nodes within the multicast delivery tree 12, 11. More recent approches to the mulitcast problem in ad hoc and wireless networks focus on using geographic routing for traffic forwarding and reducing state information within the router to improve performance and scalablity 13–16.
The multicast protocols discussed above can be compared based on their reliance on a unicast protocol, the primary structure used for distributing data, the amount of flooding that is done, and the amount of data redundancy provided. MAODV and AMRIS react to link failures by discovering a new route to the multicast tree. Data may be lost during the discovery period. AMRoute depends on a unicast protocol to forward data, so if the underlying unicast method finds a route on-demand, similar packet loss will occur. G-S reacts to a link failure that partitions the core-based tree by selective flooding so the data will arrive at the disconnected nodes, but the use of the shared tree may cause more traffic overall for the group. ODMRP uses the concept of a forwarding group when links fail which results in data redundancy, but otherwise relies on shortest paths between members. CAMP converges to shortest paths between members, so if an important link fails and another path is not active, it would have to wait for the unicast protocol to determine the new route.
The existing proposed multicast protocols react to a link failure after it occurs. None attempt to predict link availability and provide reliability using data redundancy based on the prediction before the link fails. Our solution to the multicasting problem in mobile ad hoc networks uses a proactive approach to tree creation and maintenance in order to reduce the overhead encountered at the time of link failures without sacrificing optimality of the tree structure. Even though we construct multiple trees, those trees are based on approximations of optimal trees in order to counteract the effect of allocating resources to multiple trees. An additional improvement over the current protocols is the specification of system parameters that can be fine-tuned to specific environments and network conditions.
In the next section, we propose RoMR with variations as our solution to the multicasting problem. It incorporates the use of a proactive link-state unicast protocol and multiple Steiner tree approximations in a novel multicasting protocol.
3. RoMR Architecture
The main goal of RoMR is to deliver packets to the recipients in a reliable and efficient manner. To ensure a high level of reliability, RoMR creates multiple multicast trees, instead of creating a single dynamic multicast tree over which all of the packets from the source are routed as found in existing multicast protocols. This approach provides alternate paths for packets to travel in the event that some of the paths become disconnected. Packets travel down each one of the trees in the set of trees increasing the likelihood that a receiver receives the packet sent from the sender node as the topology of the network changes. Another aspect of RoMR which further enhances its reliability is that it does not wait until all trees become disconnected before it computes a new set. Rather it tracks the number of trees in the current set of trees that remain connected and when that number reaches a threshold, new trees are computed and distributed before all distribution paths are lost.
The second major goal of RoMR is to deliver the packets reliably without placing an undue burden on the network. Inefficiency stems from two sources: (i) routing may result in many unnecessary redundant packets and (ii) recomputing and distributing the multicast trees may occur too often. In order to accomplish the subgoal of efficient multicasting, RoMR incorporates two ideas into its heuristics. First, it makes use of an encoding scheme whereby k packets are encoded as n packets, where n is the number of multicast trees in the current set of multicast trees. When k = 1 and n is large, the number of extra packets injected into the network is high, producing an n-fold increase in the number of packets travelling in the network due to multicasting. RoMR attempts to find values of k and n such that the reliability due to redundancy is high, yet the amount of extra network traffic is not overly burdensome. Second, RoMR makes the trees based on the reliability of the links in hopes that the trees will remain intact as long as possible. This second approach to efficiency must not make the paths from sender to receiver overly long.
The questions that RoMR must answer in an effort to meet the objective and to satisfy the subgoal as closely as possible are:
How many trees, n, should be created in a multicast tree set?
Should links be shared among trees in a tree set? If so, how many should be shared?
What value of k should be used in the encoding scheme?
How can the trees be created so that they will remain intact as long as possible while not introducing overly long paths?
How can weights be assigned to known links to aid in the computation of the trees?
The actual number of trees created is a function of the level of reliability specified by the user as well as the topology of the network at the time of tree creation. An elastic application will specify three values when using RoMR as its multicast routing protocol: µ, a minimum number of trees to be formed, τ, a reliability threshold associated with the set of trees, and ρ, the percentage of links that can be reused from one tree to the next. A value of 0 for ρ would ensure disjoint trees which may be appropriate in networks with very few or no strongly reliable links. Default values for the parameters are used if the application does not specify them.
Should links be shared among trees in a tree set? RoMR shares only those links that are deemed to be the more reliable links in the set of candidate links at the time of tree creation, again supporting reliability as well as efficient use of network resources. When constructing a set of trees, RoMR will reject percent of the links in the most recently constructed tree from being candidate links in the other remaining trees in the tree set.
In order to determine the value of k, RoMR starts with an initial value and then examines the time interval between the formation of the current set of trees and the previous set. If this is smaller than a given threshold, then the recomputation of the trees has occurred too frequently. As a result the value of k is reduced when possible so that the next tree set will be recomputed when the number of intact trees reaches this new smaller value. If the degree of dynamicity of the network remains somewhat constant, this should result in a longer time interval between tree set computations. This also results in the recipient needing to receive a smaller fraction of the packets sent along the n trees. Similarly, if the time interval between successive tree computations is extremely long, then the amount of redundancy may be reduced, which is caused by an increased value of k. Subsection 5.5 provides more detail in the determination of the value of k.
In order to ensure that trees are created without introducing overly long paths, RoMR uses a Steiner tree heuristic in which we attach branches to the tree in such a way to increase its ‘bushiness’ as opposed to its depth when such a choice is available. The particular algorithm is an enhancement of an online version of the Shortest Path Heuristic (SPH) 17. It is guaranteed to have an upper bound of twice the number of branches as the optimal tree; it is also easy to implement. The enhancement addresses the question about overly long paths. The paths that are added to the tree will maximize the degree of the relay nodes in the multicast tree when multiple choices exist for the attachment of the next node. This minimizes the number of retransmissions and reduces the chance for packet collision. More details of the algorithm are given in subsection 5.2.
Finally, RoMR assigns weights to the known links in the network to reflect the probability that the link will continue to exist into the next time frame. The underlying unicast protocol must be slightly modified in order to include these weights of links during the exchange of topological information. During the creation of a single multicast tree within a set of trees, these weights are taken into account so that only links that are likely to remain in existence for the longest time are eligible to be shared among trees. The method to calculate the weights of the links is another feature unique to RoMR and is discussed in subsection 4.1.
3.1. RoMR Framework
The main objective is to build and maintain a multicast tree in order to support group communication in MWNs. Formally, this objective can be expressed as follows:
(1): A time-varying network modelled as a directed graph, where:
(a)N(t): a set of nodes that comprises the network at time t. It is assumed that all nodes in the network have the capabilities to receive and forward transmissions so a node is able to act as a router in a multicast tree as well as a receiver in a multicast group.
(b)E(t): a set of directed edges representing the radio links at time t. If link (u, v) exists, then we assume link (v, u) also exists.
(2)Q: a dynamic set of join and leave requests. Each request is a triplet (node, action, t) to describe the action of a particular node joining or leaving the set of receivers of a group at a given time t.
(3)ρ: a percentage of the links that can be reused from one tree in the formation of the next tree in a set of trees.
(4)τ: a threshold that represents the lowest level of desired reliability of an entire set of trees.
(5)µ: a minimum number of trees to create.
W(t): a set of weights . Each link is associated with a weight which corresponds to the probability that link e will continue to exist over the next time interval given link e existed during time interval Ik.
A dynamic graph for group gid of m multicast trees such that
each tree may have at most ρ percent of its links in common with the successive tree,
the value of m is based on the topology of the current network, as well as τ and µ,
the set of trees are adjusted to reflect the group membership changes specified in Q,
whenever possible, m ≥ µ,
the cumulative weight of whenever possible,
the degree of interior nodes of is as large as possible given the other constraints.
An encoding method that will encode a group of packets from the source as n packets (where n = m, the number of multicast trees) such that a receiver that receives a subset of a given size of the n packets will be able to decode the original source packets.
A group management scheme that will maintain group membership information and update the multicast trees when a change in membership occurs.
3.2. RoMR Architecture
RoMR has four main components that work together to accomplish the goal under the set of constraints of the problem. The link component is responsible for monitoring the signal strengths of links, calculating weights for the links, and exchanging the link information with neighbors using the underlying unicast protocol. The tree component is responsible for making, distributing, and maintaining the multicast trees, the routing component is responsible for the routing of packets from other applications to the group members over the multicast trees, and the membership component is responsible for servicing requests for nodes to join and leave the group and to maintain the membership lists. The routing component uses the trees formed in the tree component, the tree component uses the topology tables maintained by the unicast protocol as well as the list of member nodes kept by the membership component, and the unicast component includes the weights of the links determined by the link component during its exchange of topology tables.
The link component in each node monitors the strength of the radio signal from neighboring nodes and determines the weights associated with adjacent links. Using values of readings over a time interval, the node will determine an area in which the neighboring node could be located in the near future. The ratio of the overlapping area in which the neighbor could possibly hear the transmission from the original node to that of the entire area of the neighbor's locus results in a weight in the range [0,1] to assign to the link. This will reflect the probability that the link will exist during the next time-interval, given that it existed in the most recent time interval. The link component will work in conjunction with the underlying table-driven link-state unicast protocol to distribute these values during the exchange of topology tables. The appropriate formulas and their derivations are given in subection 4.1.
The tree component in RoMR computes multiple multicast trees that may be interconnected through the sharing of reliable links and then maintains these trees as the group membership and network topology changes. The idea is to make a set of n possibly interconnected multicast trees connecting a single source to a set of receivers. Specifically, the functions of the tree component include:
(1)Determine n, the number of trees to create.
(2)Build the multiple multicast trees based on information gathered by the underlying unicast protocol and the link component.
(3)Determine the best value of k to use in the (n, k) encoding scheme based on the dynamicity of the network. A higher value of k results in lower overhead but reliability may be adversely affected in highly dynamic networks, whereas a lower value of k may result in increased reliability with a higher overhead cost. Any k of the n packets received will be sufficient for the member node to be able to decode the k original packets.
(4)Distribute the trees to the relay nodes and group members.
(5)Monitor the topology of the network by examining the topology tables provided by the unicast link state protocol. The number of intact trees is expected to decrease with time. When the number of intact trees reaches k, remake and distribute the trees. Special actions are taken when k = 1.
(6)Send messages to relay nodes to use current trees when new trees are not made within the timeout interval, thus avoiding premature timeouts from occurring.
The value of k mentioned above is dynamically determined as a tradeoff between the quality of the tree set and the overhead. If the trees are being made too frequently then the value of k will decrease resulting in the receiver nodes needing to receive fewer of the n packets in order to decode the originals, increasing the time needed between tree creations. Given the dynamics of the network, RoMR will strive to provide enough redundancy to increase the likelihood that a node receives the packets according to the desired level of performance while controlling the amount of redundancy to avoid overloading the network. The algorithms of the tree component are given in Section 5.
The routing component has two complementary parts. The first subcomponent processes packets that come from upper layers of the protocol stack that are addressed to a group address. In this subcomponent, the router component buffers k of the packets addressed to the group, then applies a (n, k) forward error correction (FEC) encoding scheme before sending the n encoded packets on to the MAC layer. The second part of the routing component examines a data packet that is received from the MAC layer from another node. If the packet is addressed to a group and if the node is a relay for that group for one of the trees then the node forwards the packet. The use and caching of sequence numbers prevents the occurrence of possible loop formation. If the node is a member of the group then the node buffers the incoming packets addressed to the group until k packets have been received at which time the routing component decodes the packets and passes them up the protocol stack to the upper layers. All routing tables are kept as soft state. If a node does not receive periodic updates the entries will timeout and be deleted from the multicast part of the routing table. The algorithms associated with the routing component are discussed in Section 6.
The membership component services the join and leave requests for the group and keeps the tree component informed of the current membership lists. A node interacts with multicast manager (MM), using a set of group management commands for creating, destroying, joining, and leaving a group.
3.3. RoMR Node State Diagram
A node may be in one of five basic states, namely Default, MM, Sender, Receiver, and Relay. Other composite states exist and are combinations of the last four states listed. The state of the node reflects the responsibilities and thereby the actions of the node. The transitions between these states in response to occurring events are depicted in Figure 1.
In the default state, a node is not associated with a multicast group in any way. It is not a sender, receiver, relay node, or a MM. All nodes are in the default state before multicast communications are initiated. Each multicast group includes a node which acts as the MM for the group. This node is responsible for performing the duties of the tree and membership components. Initially the first source node will be designated as the MM. If the source becomes a bottleneck, it will advertise to its neighbors that it is looking for a node to take over the MM duties. The willing neighboring nodes will respond and the current MM will select one of those willing nodes, sending it the group information. The selection can be based simply as the lowest IP number or may involve more sophisticated load distribution analysis. RoMR is designed on the basis of closed groups, although the existence of the group is public knowledge. Any node may join a group by contacting the group's MM. The node will be able to determine the MM node for a group as that information will be available to all nodes through a registration system similar to a local DNS.
A node switches to the sending state becoming a source node when an application in the node begins to send data to a multicast group address. In order to use RoMR as the multicast protocol, the application either must specify the values of the parameters used by RoMR through an API or accept the default values for µ, τ, and ρ which are the minimum number of trees to create, the minimum cumulative weight of the set of trees, and the reuse factor, respectively. The sender will obtain the values of k, the number of trees that must remain intact before forming a new set of trees, and n, the number of trees in the current set of trees, as well as current set of multicast trees from the MM. Once the values of k and n are known, the network layer in the sender node is responsible for the encoding of the outgoing packets. When the network layer of the source node receives a packet to send to a specific group address from the transport layer, the source node proceeds as follows:
(1)Buffer k successive packets addressed to that group.
(2)Encode the k packets as n unique packets.
(3)Broadcast the n packets to neighboring relay nodes and receivers.
The relay nodes are determined when the multicast trees are formed. They are the nodes that are the interior nodes on at least one of the multicast trees. Each relay node is associated with one or more of the trees in the current tree set. If the relay is part of the ith tree, then the relay node will forward packets designated as belonging to the ith tree. If a relay node does not belong to tree j, then it will not forward packets that are designated as being routed on tree j. Note that some or all of the receivers may also act as relays. In the simplest version of RoMR, a relay node does not save a copy of the tree in order to reduce the demands on the relay node. The responsibilities of a relay node include:
(1)Update the forwarding information when a new set of n trees arrives, recording the trees to which it belongs.
(2)Forward all tree packets to downstream relay nodes and receivers.
(3)If a data packet is designated as being routed on the ith tree and if the relay node belongs to the ith tree, then forward the packet to the neighboring nodes.
(4)Delete the entry in the forwarding table for tree j of the specified multicast group, if no data or new multicast trees has arrived since the previous time-out for tree j.
A receiver node in the multicast group has the following responsibilities:
(1)When it receives a (non-duplicate) data packet,
(a)Keep track of the number of packets received for the indicated packet group.
(b)If k packets have previously been received for the indicated packet group, then ignore the packet since it has already been decoded.
(c)Otherwise if the received packet is the kth packet decode the group of k encoded packets and send the k recovered packets to the application.
(d)Otherwise buffer the packet until enough of the other packets in the packet group arrive or a time out occurs.
(2)When it receives a new set of multicast trees, determine the encoding scheme and create the corresponding decoding matrix.
A node may act both as sender as well as a MM, thus, giving rise to a composite state senderMM. The other combination states are receiverMM, relayMM, receiverRelay, receiverRelayMM.
All nodes in the network will participate in the exchange of topology information in the underlying unicast protocol regardless of their state. Thus all nodes will:
(1)Gather data for link availability calculations.
(2)Perform the link availability calculations.
(3)Exchange the link availability information with neighbors in the unicast protocol's topology table exchange.
4. RoMR Link Availability
Various approaches to predicting a link's availability have been proposed. It is often the case that these approaches either overly simplified the prediction calculations, assumed the availability of unobtainable information, or relied on statistical distributions of mobility patterns on which to base predictions. As such, these models may be unrealistic. RoMR uses a different approach. A node computes an area in which a neighboring mobile node is likely to be in the near future and then examines the portion of that area which overlaps the transmission range of the node performing the calculations. A weight is assigned to the link to the neighboring node, reflecting the ratio of the overlap area to the possible location area. In order to perform the calculations, RoMR relies on signal strength readings from neighboring nodes. Once the link calculations have been performed, the values are distributed with the topology tables by the underlying link-state protocol, thus RoMR requires a slight modification to the unicast protocol.
4.1. Link Weights Computation
Link weight is a function of two accumulated measures of signal strength received from a neighboring node. The first is the average signal strength received from the transmitting node from time until time ti. In the ensuing discussions, this is simply referred to as the received signal strength at time ti. The second measure is the average signal received during the time interval from ti to from the same transmitting node. Likewise, this will be referred to as the signal strength of the received signal at time . The power of the transmitted signal at the sender is assumed to be constant over the small interval of time Δt. A locus of possible destinations for the transmitting node at time is determined relative to the receiving node based on the strengths of the previously received signals. The intersection of this locus set with the area in which the receiving node is able to receive a reliable signal determines the weight of the incident link corresponding to the probability that the link will be available over the next time interval.
Most of the reduction in a signal's strength from the time of transmission to the time of reception is due to the distance between the two nodes, the obstacles between them, and the number of different paths the signals travel due to reflection. In a free space environment, the average received power at the receiving antenna is
where Pt is the transmitted power, λ is the carrier wavelength, d is the distance between transmitter and receiver, n is the path loss coefficient, gr is the antenna gain at the receiver, and gt is the antenna gain at the transmitter 18. The value of n depends on the environment, varying from 2 in a free-space environment, 4 in a typical urban environment and up to 6 when there are many obstacles in indoor transmissions.
In the idealistic free-space formula for the received power, we assume that the path loss is a function of distance, but in reality other sources of path loss exist. Radio waves travel over multiple paths from the source to the destination and as a consequence other more complex models have been developed. The two-ray model assumes the radio signals travel over two paths—one part of the signal travels in a direct line-of-sight path and the other is bounced off of the surface of the earth. Another model incorporates the effects of shadow fading due to the signal being blocked by objects in the environment. Several additional path loss models based on the size of the radio cells are discussed in Reference 19. In addition to these large-scale effects, rapid fluctuations in the signal result from small-scale fading. Small-scale fading is caused by the movement of the transmitter, receiver, and/or objects between them. Multipath fading and effects of the Doppler spectrum are two sources of small-scale fading.
For the calculations that follow, we assume n = 2 and there is no other source of path loss. For a particular pair of nodes during a short time span, the values of Pt, λ, gt, and gr can be considered to be constant and can be combined with the 4π into one constant K giving
Notice that the value of K may need to be recomputed periodically as the transmission power decreases due to a node's battery becoming depleted.
Lemma. Lemma 1:If p0 is the power of the signal received by node n from node m at time ti, p1 is the power of the signal received by node n from node m at time , and p0 < p1, then the area, , of the locus of the possible locations of node m at time is:
Proof. Proof: Let and from Equation (1). Solving for the distances, we obtain:
We have d1 < d0 since we know that p0 < p1.
Let point N be the location of node n. Let points P0 and P1 represent the perceived locations of node m at times t0 and t1, respectively, relative to node n (see Figure 2). P0 could be any point on circle C0 with center N and radius d0 and P1 could be any point on circle C1 with center at node n and radius d1. The analysis is equivalent for all possible positions of P0 on circle C0 at distance d0 from node n so fixing P0 will not affect the results. In order to perform the analysis we assume that the net effect of the node's mobility during one time frame is greater than or equal to the net effect during the next time interval in which case node m will be on or in the interior of circle C2, the circle centered at P1 with radius at time . The union of all possible circles where node m could be located at time forms the interior region of a limaçon. A limaçon has two basic shapes. When d0 ≤ d1 < 2d0, the limaçon has a dimple as in Figure 3(a) and when d1 < d0, the limaçon has a keyhole as in Figure 3(b). The dimple disappears when d1 ≥ 2d0 and the limaçon becomes convex. We will assume that the general characteristics of the node's movement change an insignificant amount over the interval , that is, the node will not experience a significant deviation in speed.
A limaçon with the orientation as shown has the following formula:
in a polar coordinate system with the center of the two circles at (0, −d0) in rectangular coordinates. Furthermore, the region bounded by lines θ = α, θ = β, and the curve r = f(θ) has area .
In the case when d0 > d1, the limaçon has a keyhole area that begins when r is first equal to zero as θ increases from 0 and the keyhole region continues while r is negative, until the point when r is zero once again. Let ϕ be the angle at the beginning of the keyhole, thus the keyhole occurs from ϕ up to π–ϕ where so the formula for the area, , of the limaçon that does not duplicate the keyhole is:
where . Replacing d0 and d1 with the expressions involving p0 and p1 from Equations (2) and (3) yields to , which completes the proof of the Lemma 1.□
Lemma. Lemma 2: If p0 is the power of the signal received by node n from node m at time ti, p1 is the power of the signal received by node n from node m at time , and p0 ≥ p1, then the area, , of the locus of the possible locations of node m at time is:
Proof. Proof: The proof is basically the same as above changing the bounds of the integration to match the limaçon corresponding to Figure 3(a).
Suppose the minimum power at which node n can reliably read a packet is pm. The distance between the sender and node n has a maximum value of D where
Assume, the reception area for node n to receive a signal from node m is a circle centered at n with radius D. The intersection of the interior of this circle with the interior of the limaçon is where node m could be at time t2 if node n were able to receive an adequate signal from node m.
Lemma. Lemma 3: Given a limaçon with center at , and a circle with center at and diameter D , then the circle and the limaçon intersect only if .
Proof. Proof: Solve the simultaneous equations:
The solution of the simultaneous equations is:
When the argument of the arcsin function is not in [−1, +1] the arcsin is not a real number indicating that the two shapes do not intersect. □
Lemma. Lemma 4: If p0 is the power of the signal received by node n from node m at time ti, p1 is the power of the signal received by node n from node m at time , pm is the minimum power level that node n can receive, p0 < p1, and then the area, A, of the locus of the possible locations of node m at time that is inside node n's receiving area can be expressed as:
Proof. Proof: The receiving area for node n is assumed to be a circle with center at (0, −d0) and radius D where D is defined in Equation (6). The equation for the circle in polar coordinates is
The intersection of the circle and the limaçon is determined from the simultaneous solution of Equations (7) and (4).
The solution of the simultaneous equations is:
Again, we put the expressions in terms of p0 and p1 and simplify:
We know from Lemma 3, if the argument of the arcsin is in the range [−1, +1] then the circle and limaçon intersect. This is guaranteed from the assertions of the lemma.
Let P2 be the intersection point which occurs in either quadrant I or quadrant IV. Due to the symmetry there is also an intersection point in quadrant II or III.
Since p0 < p1, the limaçon has a keyhole which begins when r = 0. Substituting 0 for r in the equation for limaçon (Equation (4)) we have
Solving for β:
Thus, the keyhole begins at polar coordinate (0, β).
Now consider the triangle , the triangle is shown in Figure 4. We know
The measure of can be found using the Law of Cosines: Let
Solving for α yields:
Substituting the expressions using the power levels for the distances, we get:
Now we can find the area, , of
Substituting α by its value, we obtain:
The area of the portion of the limaçon that is inside the receiving circle consists of six parts, three parts in quadrants I and IV and congruent corresponding parts in quadrants II and III. Figure 4 shows the parts in quadrants I and IV: the area bounded by the limaçon curve and the segment , the area of , and the area of the sector of the circle.
Area of sector of circle =
Let γ be the angle at the start of limaçon piece. We have . Furthermore, let β be the angle at the start of the keyhole. We have . When p1 > p0, the area of intersection, , is equal to the sum of two limaçon pieces, two triangles, and two sectors. Consequently, the area can be expressed as:
After simplification and substitution we find the area of intersection to be
Now perform the same analysis for the dimple case.
Lemma. Lemma 5: If p0 is the power of the signal received by node n from node m at time ti, p1 is the power of the signal received by node n from node m at time , pm is the minimum power level that node n can receive, p1 ≤ p0, and , then the area, , of the locus of the possible locations of node m at time that is inside node n's receiving area can be expressed as:
Proof. Proof: The only difference in the calculations is in the limits of integration for the area of the two pieces of the limaçon that are inside the circle. Previously the angle varied from γ to β; in this case, the angle varies from γ to π/2.
Finally, we can consider the ratio of the area of the locus of locations of node m at time that are inside node n's receiving range to that of the area of node m's entire locus to be the probability that node n will be able to receive a signal from node m at time given that it received signals at ti and .
If p0 is the power of the signal received by node n from node m at time ti, p1 is the power of the signal received by node n from node m at time , pm is the minimum power level that node n can receive, p0 < p1, and , then the probability, P, that link (m, n) will exist at time can be expressed as:
Proof. Proof: The probability that link (m, n) will exist at time corresponds to the ratio of the area of the locus of locations of node m at time that are inside node n's receiving range to that of the area of node m's entire locus so we divide the result from Lemma 4 by the result from Lemma 1 giving the indicated expression. □
If p0 is the power of the signal received by node n from node m at time ti, p1 is the power of the signal received by node n from node m at time , pm is the minimum power level that node n can receive, p0 < p1, and , then the probability that link (m, n) will exist at time is 1.0.
Proof. Proof: If the fraction is not between −1 and +1 inclusive, then the limaçon representing node m's locus does not intersect node n's receiving circle. Since node n did receive signals p0 and p1, the corresponding points must be located inside the receiving range, thus the entire limaçon must be inside the receiving range. □.
Likewise, we can examine the case when p1 ≤ p0.
If p0 is the power of the signal received by node n from node m at time ti, p1 is the power of the signal received by node n from node m at time , pm is the minimum power level that node n can receive, p1 ≤ p0, and , then the probability, , that link (m, n) will exist at time is:
Proof. Proof: Using the same argument as in Theorem 1, we divide the result from Lemma 5 by the result from Lemma 2 to achieve the indicated expression. □
If p0 is the power of the signal received by node n from node m at time ti, p1 is the power of the signal received by node n from node m at time , pm is the minimum power level that node n can receive, p1 ≤ p0, and , and then the probability that link (m, n) will exist at time is 1.0.
Proof. Proof: There are two cases when the dimpled limaçon does not intersect the transmission circle. When , the limaçon is entirely inside the circle so the probability is 1.00. □
If p0 is the power of the signal received by node n from node m at time ti, p1 is the power of the signal received by node n from node m at time , pm is the minimum power level that node n can receive, p1 ≤ p0, and , then the probability that link (m, n) will exist at time is .
Proof. Proof: The second case when the dimpled limaçon does not intersect the circle is when the circle is entirely inside the limaçon in which case the probability is the ratio of the area of the circle to the entire limaçon. Area of the circle = πD2 and area of the limaçon . Dividing and substituting yields □.
Although the calculations are somewhat complex, since they only rely on p0, p1, and pm, a table of values for various values of p0 and p1 given the device's receive threshold sensitivity pm can be hard-coded into the device so that the determination of the link reliability is simply a table lookup operation requiring constant time.
In this section, we have derived the formulas used by RoMR to calculate the weights associated with the links in the network topology. These weights reflect the probability that the link will be available in the next time frame, and will be used in the computation of RoMR multicast trees.
5. RoMR Tree Management
In this section, the algorithms used to perform the tasks associated with each of the states of nodes under RoMR are discussed. A description of the basic steps of the main algorithms is provided.
5.1. Procedure CheckTrees()
When a MM receives a message from the unicast protocol that the topology has changed, it needs to determine how many of the trees specified in the current tree set are still connected. If the number of connected trees has fallen below a threshold, the tree set needs to be recalculated and distributed. Pseudocode for CheckTrees is listed in Figure 5.
5.2. Function MakeTrees()
A node in the MM state is responsible for creating the set of trees to be used in RoMR when the need to do so is determined by CheckTrees. Three parameters are associated with a multicast session when it starts: the Reuse Factor (RF), the Weight Threshold (WT), and a minimum number of trees (MT). These parameters are referred to as ρ, τ, and µ, respectively. Combined, these values reflect the desired reliability level to be achieved and can be specified by the application. If the application does not specify values for these parameters, RoMR will use default values.
The RF is the percentage of links in a tree that are eligible to be used in the next tree. The RF value must be less than 1 (100%). A value of 0 would result in disjoint trees, increasing the chance that a node would receive packets in an extremely dynamic network, but at the same time also increase the use of network resources.
The weight threshold (WT) and minimum number of trees (MT), similar to a Quality of Service (QoS) parameter, are specified by the node initiating the multicast session. The tree module will attempt to make a sufficient number of trees so that the probability of at least MT trees existing in the next time frame is above WT.
The steps in creating a tree set are outlined in Figure 6. In Figure 7, node A is the sender and nodes D, E, and G are the receiver nodes. The diagram shows the first tree created as a result of the modified SPH algorithm. The order in which the nodes are added to the first tree is A, D, E, and G. This example assumes the RF = 0.5 so the branch from D to C, with weight 0.7, and the branch from G to E are eliminated from consideration in the construction of the second tree. The modified SPH algorithm is once again followed to produce the second tree.
5.3. Function MakeSingleTree()
The MM makes a single tree in the process of creating the current tree set for the group. The main idea of the algorithm stems from an enhancement to the SPH. If two paths from a given member to the existing tree have the same hop count, then the path that connects to the node in the tree with the highest degree relative to the tree is selected. If the degrees of the nodes in the current tree are the same and if one of the tree nodes is the sender, the path to the sender is selected. The same proof to show that SPH produces a tree having at most twice the number of links as the optimal tree 17 applies to the modified version. The steps of the algorithm are listed in Figure 8. The choice of SPH to create the trees addresses the concern that RoMR should use network resources efficiently by making trees that may be closer to optimal than simply using the union of shortest paths. The modification to attach paths to nodes having a higher degree in the current tree prevents the branches in the tree from becoming overly long.
The computation of the best path from a single node to all of the other nodes in the network is based on Dijkstra's shortest path algorithm which has O(n2) complexity; so the complexity of the makeSingleTree as stated is O(|R|n2) where |R| is the number of reachable receivers in the group.
An alternative method was considered to construct the trees with the goal of producing the most reliable tree. The above technique was modified using the greatest product of the link weights as opposed to the least sum of distances. In dense networks this created two problems. The first problem was the increase in the length of time a packet took to reach a receiver. The second problem was caused by the long paths in the local area that resulted in a large number of packet collisions due to the fact that the broadcast medium is shared by all nodes in the local area. Figure 9 illustrates these problems. Node A is the sender and node F is the receiver. The values on the links represent the weights of the links. The shortest path between A and F is clearly the one hop path from A to F with the product of the weights equal to 0.8 whereas the most reliable path based on the product of the weights would be A, B, C, D, E, F using five hops with a reliability product of 0.995 = 0.95.
An enhancement was added after initial testing of RoMR. When two paths have the same length to a node in the current tree, choose the node in the current tree that is closest to the sender. This has the advantage of decreasing the overall path length to the member.
5.4. Function ProbAtLeastKAreGood()
In the procedure MakeTrees, the cumulative weight of all the trees currently in the tree set was computed with a call to ProbAtLeastKAreGood. Recall from subsection 4.1 that a weight of a link reflects the probability that the link would continue to exist from time until time . If the existence of all links in a tree continuing to exist during the same interval were considered to be independent events, then the probability of tree T remaining intact until time would be
However, the duration of the links are not independent. Suppose nodes A, B, and C are linearly arranged with B being between A and C. As B moves slowly toward A, the weight of AB increases while the weight of BC decreases. Simulation confirms that the product is a vast underestimate of the probability. As an approximation to the probability that all of the links in the tree will survive until the next time interval, we selected the minimum weight of all of the links in the tree to represent the probability that the tree would remain connected until time .
If every tree in a tree set has the same probability p associated with it, then the probability of exactly k out of the n trees in the tree set being connected at time is
and the probability of k or more of the n trees being connected at time is
Changing this to a form in which each of the pi values may differ, the probability that at least k trees will remain intact is
where ji is the ith bit of jand
Clearly we can see that for a fixed value of k, the larger the value of n, the larger the sum will become while being bounded from above by 1.00.
The above formula can be stated as a recursive routine as shown in Figure 10. The complexity of the computation is exponential in the general case due to the recursion, but in the actual implementation, the number of trees that will be created is bound by a small constant MAX_TREES thus eliminating exponential execution time concerns.
5.5. Procedure Determine K Packets Needed()
By design, RoMR attempts to make the length of time between the creations of tree sets through the use of FEC codes as large as possible while meeting the primary goal. Every k packets that the application sends will be encoded as n unique packets by RoMR at the routing layer. The ith packet of the group of n packets will be sent to receivers over the ith tree. The receiver only needs to receive any k of the n packets that were sent in order to recreate the original k packets. The encoding is performed by a node in the sender state and the decoding by a group member in the receiving state. It is the responsibility of the the node in the MM state for the group to determine the value of k.
Every time a new tree set is calculated, the value of k is recomputed based on the previous value of k and the length of time that elapsed since the creation of the previous tree set. The unicast protocol specifies an interval of time, TC_INTERVAL, between sequential topology control messages. In RoMR, if the elapsed time since the previous tree set was created is greater than or equal to 4 times the TC_INTERVAL, then the network is considered to be stable and will increase the value of k if possible to reduce the overhead due to redundancy. The unicast protocol also specifies the length of time it will maintain information about a neighbor in the event it does not receive any update information from the neighbor. This time interval, NEIGHB_HOLD_TIME, is also used in the calculation of k. If the elapsed time since the creation of the previous tree set is less than the NEIGHB_HOLD_TIME, then the trees were being made too often, so decrease the value of k if possible, so that fewer of the trees in the tree set need to remain intact before recomputing the entire set of trees.
6. RoMR Traffic Encoding Algorithms
6.1. Forward Error Correction Codes
The techniques employed by RoMR to reduce the amount of packets travelling through the network for redundancy purposes is based on FEC techniques developed for use in telephone systems to recover from noise in the lines so that switching signals can still be understood despite the loss of some of the pieces of the signal.
Erasure Codes and Galois Fields: One class of FEC codes is based on erasure coding methods. This refers to a coding technique wherein the original data may be recovered even if some of the data that was sent did not arrive at the destination (i.e., it had been erased). Rabin 20 discusses a method based on a finite field, mentioning the fact that Galois Fields could be used in order to avoid increasing the number of bits in the encoded packets. Rizzo 21 provides details in using the Galois Fields.
RoMR's encoding process takes k packets of source data and produces n unique packets such that the original data can be determined from any k of the n encoded packets. The product of an n × k encoder matrix E and the k × 1 matrix of original packets yields a n × 1 matrix of encoded packets. Matrix arithmetic operations are based on + and * defined for GF(2r). Maximum values of n and k are and , respectively. The algorithm shown in Figure 11 specifies how to construct the encoding matrix E. The decoding matrix depends on which subset of size k of the n packets was received. The steps are outlined in the algorithm given in Figure 12. Note that different decoding matrices are possible.
6.2. FEC in the Sender State
After the n trees of a tree set have been created, the source node creates an n × k encoding matrix, E, as described in Figure 11. Since this matrix only depends on the values of k and n, it can be calculated once and used any time in the future with the same values of k and n. In fact, if k and n are limited to a small number of values, all possible matrices that might be needed could be computed offline and stored in memory.
When an application layer program sends a data packet, RoMR's routing layer component in the source node examines the destination address. If the destination is a node address, RoMR passes the packet on to the unicast protocol with no further processing. If the destination is a group address, the source node will buffer the outgoing packets. (A group address has an IP address between 18.104.22.168 inclusive and 240.0.0.0 exclusive 22.) When the number of packets in the buffer reaches k, it encodes the packets as n unique packets. The group of k packets to encode may be viewed as a k × 1 matrix P. The matrix product of E × P yields a n × 1 matrix of the n encoded packets. After performing the encoding, a header is added to each packet containing information needed for the routing and decoding processes. Specifically, the header includes the sequence number of the tree set, a value to indicate which tree of the tree set should carry this packet, and the value of k. After the header has been attached then the packets are broadcast to the node's one-hop neighbors.
It may be the case that RoMR's routing component in the source node does not receive k outgoing packets from the application within a timeout period or that the values of k and/or n have changed due to a new set of trees being used. RoMR will simply send these few remaining packets out with k = 1 over the existing set of n trees so that no encoding needs to take place on either the sender's or receiver's end of the path. Thus, in highly dynamic networks with rapidly changing sets of trees, RoMR degenerates into sending a copy of each packet down each tree with none of the advantages associated with encoding. The encoding scheme produces a n/k-fold increase in network load. For example, when k = 1, RoMR is sending n packets for every packet originally produced by the application. On the other hand, when k = n, as in the case of a static network, no extra packets are injected into the network for redundancy purposes.
The algorithm in RoMR's network layer component that receives a data packet addressed to a multicast group from the transport layer is given in Figure 13.
6.3. FEC in the Receiver State
When the network layer receives a packet from the MAC layer it examines the destination address. If it is not a group address then the underlying unicast routing protocol routes the packet. If the destination is a group address, then RoMR performs a sequence of actions. First, it checks a message cache to see if it is a duplicate packet. If it is a duplicate then the packet is simply ignored. If the packet is not a duplicate, RoMR checks to see if the node that received the packet is a member of the indicated group. If so, RoMR buffers k of the incoming packets belonging to the indicated packet group sent by the source. It then selects or creates the appropriate k × k decoding matrix, D. The buffered encoded packets form a k × 1 matrix, P and the matrix product D × P yields a k × 1 matrix of the original data packets which are then sent on to the upper layers of the protocol stack. Once k packets of a particular group of packets have been received then all of the other possible packets that are received belonging to the indicated packet group are ignored. Since the first k packets of the group of packets are encoded using the identity matrix, if the first k packets to arrive do arrive via one of the first k trees, then no decoding is necessary, slightly speeding up the overall delivery of the packets to the application layer.
RoMR's network layer component's algorithm that deals with the buffering and routing of incoming data packets addressed to a multicast group that are received from the MAC layer is given in Figure 14.
7. Algorithms for Relay Nodes
A node in the Relay state has three responsibilities. First when a node receives a tree packet, it parses the packet to determine if it is a relay node. If so, it updates its forwarding information and forwards the tree packet. Second, when the time since the arrival of a new set of trees (or a message to use the current tree set) reaches a threshold, the appropriate entries for the forwarding table are deleted, and the node's state changes accordingly. Third, when a node in one of the relay states associated with a particular group receives a data packet addressed to the group from the MAC layer, it checks to see if it has already received a copy of this packet. If not, it then checks to see if it is a relay for the tree value indicated in the packet's header. If so, the node forwards the packet without modification so that any receiver or relay node that receives the packet can process it. Since RoMR does not restrict the processing of the packet to the specific child on a given branch, a node might be able to receive it earlier than if it went the entire path. The caching of packet ID numbers prevents broadcast storms from occurring. The caches are periodically flushed. Since a receiver node may also act as a relay node, the algorithm for a relay is embedded in the algorithm given in Figure 14.
8. Join and Leave Algorithms
When a node wishes to join a multicast group, it sends a JOIN message to the MM for the group as determined by a DNS-like lookup. The MM determines the receiver that is closest to the new member and sends an UPDATE message to the receiver. The recipient of the UPDATE message extends all trees in the tree set to the new member over the shortest path between the new member and the receiver by resending the packet from the MM as a tree set packet in the same manner as in distribution of new tree sets. At the time of the next tree set calculation performed by the source, the new nodes will be included in the tree calculations.
When a node wishes to leave a multicast group, it sends a LEAVE message to the MM. The change in the tree occurs when the next tree message is sent from the sender due to a topology change or a topology time-out.
9. RoMR Variations
Several variations of RoMR may be considered by giving the relay nodes a more active role in tree formation and maintenance. In the first variation, the relay nodes make local repairs to the trees as needed until a new tree set arrives. In the second variation, the MM only determines the trees within a local scope and assigns proxy nodes to be responsible to create the rest of the tree. The third variation deals with an alternate method of selecting the MM for the group. The fourth variation examines ways to reduce the size of the packets used to distribute the tree sets to the relay nodes. The last variation discusses an alternate way to calculate the weight of an entire tree.
9.1. Local Repair by Relay Nodes
A relay node records the set of downstream one-hop neighbors that act as relays or are member nodes when it receives a new tree set. When a link to one of these neighbors becomes unavailable, the node can determine from the topology table obtained from the unicast protocol if a two-hop path to the former neighbor exists. If so, the relay node will send a ‘mini’ tree set packet to the new intermediate node to inform it that it is to act as a relay for the given set of trees. Again, the use of sequence numbers will prevent loop problems from occurring. The node will send a message to the MM informing of the repair. The new relay node will continue to forward the packets until a new tree set is received. The advantage is that the tree set will remain intact for a longer period of time reducing the number of tree set packets being sent. The disadvantage is the requirement for relay nodes that are not group members to store the subtrees rooted at the relay node and to monitor them.
9.2. Tree Creation Using Proxies
The MM will calculate the trees based on the current topology tables available from the unicast protocol. Typically in unicast link state protocols each node knows all of the links within a certain local scope (usually 2 hops), while it may or may not know of all of the links outside of this range. The MM will consider each of the relay nodes on the periphery of its scope as proxy nodes and send the proxy node a list of trees to be extended to connect the indicated members to the indicated tree. The advantage is that the proxies will have more recent local information and can form more reliable trees than the MM alone. The disadvantage is the increased computational demands required of the relay nodes selected as proxy nodes.
9.3. Multicast Manager Selection
When the current MM becomes a bottleneck and wishes to delegate the duties to another node, how should that node be selected? Instead of merely using neighbor nodes as in the simpler RoMR case, a more complex method could be utilized. The MM determines the three candidate nodes that are most central to the set of receivers and begins negotiations with those nodes to determine the new MM. Let M be the set of senders and receivers of the multicast group and N be the set of all nodes in the network, find such that
Once the set of candidate nodes has been determined, poll each one to see if they are willing to assume the MM responsibilities.
9.4. Forwarding Tree Packets
In the simplest version of RoMR, a node that receives a new set of trees examines the list of branches in the trees and if it finds that it is a parent of a child for some branch then it updates its records and forwards the tree packet unmodified. What are other techniques for handling the tree packet? One packet format would omit the branches that lead to leaf nodes. In this situation the node would be a relay node if it found itself listed as a parent or a child in the tree list. The result would be a reduction in the size of the tree packet. Another packet handling technique increases the involvement of the relay nodes. In this second method, a relay node would only forward the tree information that applied to the tree(s) rooted at that node. The disadvantage is the analysis required by the relay and the repeated repackaging of the tree data which may slow dissemination of the trees.
9.5. Tree Weight
In the simplest version of RoMR, the weakest link in the tree is used as the tree's weight. Another technique would be to estimate the lifetime of each link based on past behavior and to calculate the weight of the tree as being the ratio of the number of nodes with a predicted lifetime greater than a threshold τ to the total number of links in the tree.
10. RoMR Simulation and Results
The purpose of simulation is to study the effectiveness of the protocol in a variety of environments. Two of the freely available programming packages, ns and GloMoSim, are designed to provide a basis for network simulations including wireless mobile ad hoc networks. After performing a few experiments with each, GloMoSim was selected as the simulation package based on ease of use. Once the simulator was selected, additional C code was added to the provided code in order to specify the algorithms of RoMR. Once the code was written and debugged, the parameters of the simulations were determined for a variety of network densities, multicast group sizes, and speeds of the nodes. The simulations were run to assess the performance of the protocol and to compare it to another proposed multicast protocol.
A simulator framework was written to test the RoMR protocol as it evolved over time. The framework included the basic simulator built on top of GloMoSim, a visualization program written in C++ as well as several additional helper programs to generate the test cases and analyze the results. The C++ code to calculate the FEC codes based on Vandermonde matrices was written by Luigi Rizzo.
GloMoSim was selected as the simulator due to its being freely available and the fact that it was designed to simulate wireless networks. The underlying unicast protocol was initially chosen to be the Fisheye State Routing protocol since it was provided as part of the GloMoSim package. Later simulations used the Optimized Link State Routing (OLSR) protocol as the unicast protocol since an Internet draft detailing its operation as well as a multicast version (MOLSR) were available which could be used for comparison purposes. The unicast protocol was slightly modified in order to use it with RoMR. Specifically, the topology tables were modified so they included the links' probabilities when they were exchanged between neighbors.
Since GloMoSim is written using APIs to communicate between layers, only files that were directly related to the implementation of RoMR needed to be modified providing sufficient hooks for the RoMR code to execute. These files, which are written in C, are preprocessed by PARSEC and then compiled using Microsoft's Visual C++ on Microsoft Windows platform.
The overall objective of the simulation is to examine and assess the performance of the basic version of RoMR. In order to isolate the effects of the use of multiple trees, link weights, and the FEC encoding scheme, the initial simulations assume static groups for the duration of the simulations. We also assume the MM is the sender for the duration of the simulation. The main item of interest is the percentage of the packets sent by the source node that were received by the group members. This metric will reflect the reliability of the protocol. The delay of the packet is inversely proportional to the overhead associated with the data redundancy. The higher the average delay, the fewer the number of redundant packets. The performance of the protocol is to be examined under a number of varying conditions, specifically the mobility of the nodes, the density of the network, and the size of the multicast group relative to the size of the network. Once the data has been gathered and examined, a statistical analysis of the data will determine if the average number of packets received in variations of RoMR is significantly different from the number of packets received under MOLSR. The appropriate test to use in this case is a t-test of two samples assuming unequal variances.
11. Simulation Parameters
The main constant and variable parameters used in the simulation study are listed in Tables I and II, respeectively. All of simulation experiments were run in a terrain of 1000 m by 1000 m. The nodes were randomly placed within the terrain. One node was randomly selected as the sender. The mobility was based on a random waypoint model with nodes travelling at constant speeds. In a random waypoint model, a point in the terrain is randomly selected and the node travels to that point at the assigned speed. Once the node arrives at the point, another point is selected and travel continues to the new point at the same speed. Input files were randomly generated for both the initial positioning of the nodes as well as the mobility trace files so that both a RoMR simulation and the corresponding MOLSR simulation would be based on the same initial node placements and subsequent node movements. Each group was initialized with its members at the beginning of the simulation. The group membership did not change during the simulation in order to reduce the number of aspects under consideration. The sender node generated a 512 byte constant bit rate packet every 2 s for 9 min starting 30 s into the simulation to allow time for an initial set of topology tables to be exchanged before multicasting began. Each simulation was run for 10 min of simulated time.
Table I. Constant simulation parameters.
1000 × 1000 m
Received signal min power
1 packet per 2 s
Table II. Variable simulation parameters.
Network density (ND)
0.5, 0.2 and 0.1 of Net Size
0.5, 1, 5, 10, 20, 30
Min number of trees (µ)
Min cumulative weight (τ)
Reuse factor (ρ)
For all of the simulations, the parameters were set to reflect the radio communications of a typical laptop computer circa 2002–2003: frequency of 2.4 GHz, bandwidth of 11 Mbps, and transmit power of 20 dBm. The minimum power of a received packet is set to −78 dBm. A packet is processed only if the signal to noise ratio is above 10 using an accumulative noise model.
To narrow the number of aspects affecting the results only three factors were varied in any given given group of simulation runs while the other parameters remained fixed. The three factors were network density, group size relative to the size of the network, and the speed of the nodes as suggested in RFC 2501 from the Network Working Group of the IETF 23, 24, 9. Three densities of the network were tested: a sparse network with 10 nodes, a medium network with 30 nodes, and a dense network with 50 nodes. With each of the density values, three sizes of groups were examined: 1/10, 1/5, and 1/2 of the network nodes. The simulations were run with the nodes travelling at six different speeds: 0.5, 1, 5, 10, 20, and 30 m/s to test rates resembling slow walking up to highway vehicular speeds. Finally, each configuration was run using multiple starting seed values for the random number generator.
The first set of data was run with the set of multicast trees being formed under the condition that at least two trees must exist in the next time epoch with a cumulative weight of 0.10 or better. Other simulations varied the µ and τ and input parameters.
A second set of experiments was performed to investigate the advantages of the use of the Steiner tree as the basic type of tree as opposed to a tree composed of the union of shortest paths from each of the receivers to the sender. The percentage of packets successfully delivered to the receivers as well as the differences in the overhead due to control packets carrying tree set information and the duration of the tree set was examined.
12. Simulation Results
The simulations tested the basic version of RoMR to investigate the performance under varying network conditions and RoMR parameters stated in Section 11 and to compare the results with the performance of MOLSR.
The captions in Figure 15 have the following meanings:
molsr: Multicast version of OLSR
romrOff: An experiment in which all link were assumed to have equal weight as a test of the effectiveness of calculating the weights and using them in the tree calculations. In the original version of RoMR, the links with the lesser weights were discarded from consideration in the construction of the next tree. In romrOff, the links to be discarded were chosen at random.
romrOn: Reuse factor = ρ = 0.5, cumulative weight threshold = τ = 0.15, and minimum number of Trees = µ = 2
romr25Thresh: ρ = 0.5, τ = 0.25, and µ = 2
romr3Trees: ρ = 0.5, τ = 0.15, and µ = 3
Overall, RoMR delivered more packets to the group members than MOLSR, as depcited in Figure 15. Examining the data for the individual cases, shows a general increase in the number of packets delivered to the group members when using RoMR as opposed to MOLSR along with an increase in the delay in the slow-moving network configurations. The increase in delay resulted from RoMR increasing the value of k to approach n with the purpose of reducing the overhead due to redundant packets. Since more packets comprise a packet group, the application had to wait longer for all of the packets in the packet group to arrive in order to decode them, but then all of the packets in the group were delivered with no delay to the upper layers. Indirectly this can be viewed as a measurement of the efficiency of the protocol. The higher the delay indicates a lower number of packets injected into the network for redundancy purposes.
The following questions can be answered by performing statistical analysis of the data.
Did the use of the link weights affect the performance of RoMR?
Was the performance of RoMR significantly different from that of MOLSR?
Did increasing the value of τ result in a significant difference in the number of packets received?
Did increasing the value of µ result in a significant difference in the number of packets received?
In order to answer these questions, a two-sample t-test assuming unequal variances with a 95% confidence interval was performed on the accumulated data under each of the various versions of the protocol. Tables III–VII show the results of the tests. In all cases, the differences in the mean number of packets received was shown to be significant.
Table III. T-test 1.
RomrOn vs RomrOff
Hypothesized mean difference
One-tail: P (T ≤ t)
Two-tail P (T ≤ t)
Table IV. T-test 2.
RomrOn vs MOLSR
Hypothesized mean difference
One-tail P (T ≤ t)
Two-tail P (T ≤ t)
Table V. T-test 3.
RomrOn vs Romr3Trees
Hypothesized mean difference
One-tail P (T ≤ t)
One-tail t critical
Two-tail P (T ≤ t)
Two-tail t critical
Table VI. T-test 4.
RoMROn vs Romr25Thresh
Hypothesized mean difference
One-tail P (T ≤ t)
Two-tail P (T ≤ t)
Table VII. T-test 5.
Romr3Trees vs Romr25Thresh
Hypothesized mean difference
One-tail P (T ≤ t)
One-tail T critical
Two-tail P (T ≤ t)
The second set of experiments compared the effectiveness of using a Steiner tree as the basic type of tree as opposed to a tree made up of shortest paths from each of the receivers to the sender. The parameters were the same as used in the romrOn case described above. The results, given in Table VIII, showed that the successful delivery of packets to the receivers was very similar in both of the two cases, but other statistics gathered indicate the superiority of the use of the Steiner trees. The average amount of time a tree set remained active before a new tree set was distributed was 8% shorter in the shortest paths trees than in the Steiner tree version. This is due to the likelihood that more links are in the shortest paths tree than in the Steiner tree and thus the tree set becomes obsolete sooner in the shortest paths version. Another indicator that Steiner trees performed better than the shortest paths trees was in the examination of the amount of overhead. The overhead due to the control packets which carried the tree set information increased by an average of 16% when using the shortest paths trees.
Table VIII. Steiner tree (ST) vs shortest paths tree (SPT).
% Packets received
# Of tree sets
# Of control bytes
Support for multicast services is crucial for MWNs to support content distribution at a large scale. Efficient multicasting in MWNs faces challenges not encountered in other types of networks such as the mobility of nodes, the unreliable status of communication links, limited capability of network nodes, and unpredictable behavior of the network topology. In addition to these problems the task of finding the optimal multicasting tree is NP-complete. This paper addresses these challenges by providing a framework and architecture with proactive and reactive components to support multicasting in MWNs emphasizing reliability and efficiency of end-to-end packet delivery. The architecture includes RoMR, a robust mulicast routing protocol, to support multicast services and multi-party content distribution. RoMR's proactive component calculates multiple multicast trees based on the prediction of future availability of the links and the assumption that the trees will become disconnected over time. The reactive components respond to changes in the network topology due to the mobility of the nodes and to changes in the multicast group's membership.
Sending redundant data packets over multiple paths further enhances the reliability at the cost of an increase in the use of network resources. RoMR uses approximations to Steiner trees during tree formation and FEC encoding techniques during packet transmission in order to counteract this increase. To avoid additional network traffic, trees are distributed only when the existing trees cannot be easily patched to accommodate changes in topology or group membership. The novelty of the proposed protocol stems from integrating techniques that have not previously been combined into a multicasting protocol and a unique method to calculate the relative weights of the links.
In summary, the Robust Multicast Routing (RoMR) protocol overcomes the challenges of multicast communications in mobile ad hoc networks and achieves the desired results of increasing the overall delivery of packets to members of a multicast group while keeping the number of extra data packets for redundancy purposes low and thereby conserving the use of network resources. Any multicast protocol is not expected to work in all circumstances, but the major strength of the RoMR lies in its flexibility to adapt to a variety of network conditions during the course of execution as exemplified in the simulation results. The novelty of RoMR is due to the development of the link weight calculations and the integration of methods not previously combined into a multicast protocol including FEC encoding techniques, Steiner tree approximations, and link availability estimates.
The contributions of this paper include:
A novel method used to compute the weights of the links in a mobile ad hoc network based on previous power levels of the received signal by a node.
The development of a tree-based multicast protocol which seamlessly incorporates:
–a modified Steiner tree approximation algorithm,
–the use of multiple interconnected trees, and
–the use of efficient FEC codes.
The formulation of a simulation framework.
Work on RoMR can be continued in several areas. Simulations incorporating more variation in group membership and the change in the designation of the MM need to be written, run, and analyzed. In the future RoMR could be expanded to support Quality-of-Service (QoS) with realtime guarantees in elastic applications. Another area is to address the scalability issue in RoMR. In extremely large networks, seeking to compute the set of trees based on shortest paths or Steiner trees may not be feasible. How can RoMR be adapted to work in such an environment? One possibility that addresses this last question is to disseminate the packets to strategically positioned nodes in the network and to have the interested parties seek the information based on content, name, or other attributes.
Gretchen Lynn received the B.S. degree in Mathematics from Concord College, Athens, WV, the M.S. degree in computer science from the University of Tennessee—Knoxville, and the Ph.D. degree in computer science from the University of Pittsburgh, Pittsburgh, PA. She is an associate professor in the Computer Science Department at West Virginia Wesleyan College, Buckhannon, WV. Her areas of interest include mobile computing and computer science education.
Taieb F. Znati received a Ph.D. degree in Computer Science from Michigan State University in 1988, and a M.S. degree in Computer Science from Purdue University, in 1984. He is a Professor in the Department of Computer Science, with a joint appointment in Telecommunications in the Department of Information Science, and a joint appointment in Computer Engineering at the School of Engineering. Znati served as the Director of the Computer and Network Systems Division at the National Science Foundation. He also served as a Senior Program Director for networking research at the National Science Foundation. In this capacity, Znati led the Information Technology Research (ITR) Initiative, a cross-directorate research program, and served as the Chair of ITR Committee. Znati's research interests focus on the design and analysis of evolvable, secure and resilient network architectures and protocols for wired and wireless communication networks. He currently serves as the General Chair of GlobeCom 2010. He also served as the general chair of IEEE INFOCOM 2005, the general chair of SECON 2004, the first IEEE conference on Sensor and Ad Hoc Communications and Networks, the general chair of the Annual Simulation Symposium, and the general chair of the Communication Networks and Distributed Systems Modeling and Simulation Conference. He is a member of the Editorial Board of the International Journal of Parallel and Distributed Systems and Networks, the Pervasive and Mobile Computing Journal, the Journal on Wireless Communications and Mobile Computing, and Wireless Networks, the Journal of Mobile Communication, Computation and information. He was also a member of the editorial board of the Journal on Ad-Hoc Networks, and a member of IEEE Transactions of Parallel and Distributed Systems.