Title: Multicast Communication

Abstract:
Multicast potentially optimises bandwidth consumption and node resources, when several users
simultaneously participate in a communication session. Nevertheless, contrary to the expectations,
IP multicast has not experienced widespread deployment, with the exception of IPTV. On the other
hand, emerging Wireless Sensor Network (WSN) applications could greatly benefit from multicast
and constitute another field where multicast can be an effective and efficient technique. The
question is: do multicast advantages hold in WSN scenarios? This paper discusses and evaluates
the use of multicast in Wireless Sensor Networks. A WSN platform with IP support and multicast
is being developed. Concurrently, simulation studies were performed in order to assess the
usefulness of multicast in WSNs. The results clearly point to the benefits of the use of this
technique in processing and energy-restricted environments such as this one.

Introduction:
Traditional networking involves communications between two end systems. However, important
emerging applications like IPTV, remote teaching or videoconference, require simultaneous
communication between groups of users.
Multicast protocols can offer several benefits. The use of a set of point-to-point channels to support
a virtual multicast environment results in a complex and inefficient process, mainly in wide area
networks. When a source needs to transmit a message to n receivers using point-to-point channels,
it is necessary to transmit the same message n times. In the case of IPTV, where the number of
receivers is extremely high, this is not only technologically impossible but also the required
resources are prohibitive.
The emergence of applications with inherent multicast requirements led to the development of
native multicast protocols. In the case of IP networks, multicast support was typically based on the
Internet Group Management Protocol (IGMP) to announce hosts interested in receiving multicast
information, and on Protocol-Independent Multicast – Sparse Mode (PIM-SM), Multicast Border
Gateway Protocol (MBGP) and Multicast Source Discovery Protocol (MSDP) to route multicast
messages between core routers.
With the increasing demand for multicast support, new protocols were proposed. The most
promising protocol is the Source-Specific Multicast (SSM) protocol. According to this protocol,
when a host decides to join a multicast group it is necessary to specify not only the IP multicast
address, as usual, but also the source address or a list of source addresses that the node joining the
multicast sessions accepts to receive information from. This source identification significantly
reduces the routing complexity. However, SSM has several limitations when applied to mobile
environments.
Recent advances in wireless communications, electronics and miniaturization supported the
development of a new generation of multi-functional, low-cost sensor nodes. These new sensor
nodes, with control components and communication functionality, are at the base of the
development of Wireless Sensor Networks (WSNs).
Wireless Sensor Networks are composed by a set of several nodes which can cooperate in order to
perform certain measurements and tasks and can re-organize themselves in an ad-hoc way.
Typically, sensors collect ambient measurements, process them and transmit them to a sink node.
The applicability of WSNs is becoming very high, and although some approaches have already
been proposed, it is crucial to evaluate if:
- multicast can be useful for the next generation Internet, which will integrate WSNs, -
the current multicast protocols are well prepared for WSN environments.

Multicasting in Wireless Sensor Network:

Multicast in IP networks is based on the concept of group. An arbitrary set of receivers express
their interest in receiving a particular data stream. This group does not have any specific physical
or geographical boundaries. Hosts that are interested in receiving packets sent to a particular
multicast group must join the group using Internet Group Management Protocol (IGMPv3) or
Multicast Listener Discover (MLDv2), for IPv4 and IPv6, respectively. These protocols manage
the communication between hosts and routers. Each router maintains a list of active members per
multicast group in its sub-network. Forwarding of multicast packets is subject to certain risks. If
there are several routers on the same physical network and if special care is not taken, they may
all relay the packets again and again. In this way, there is the risk of creating not only a multicast
loop but also a multicast avalanche (network flood), bringing the whole network to a stop as it is
quickly filled to capacity. The whole purpose of multicast routing is, precisely, to achieve delivery
of multicast packets without loops and without excess transmissions. There are different routing
protocols, some using rudimentary techniques such as flooding, and others using more elaborate
techniques that rely on source-based trees or shared-based trees algorithms. Work in the multicast
area started by developing and refining intra-domain routing protocols. Later, particular emphasis
was placed on developing inter-domain multicast routing protocols. Nowadays, with the advent of
wireless systems and with the use of 4th Generation Protocols, it is also important to apply and to
study each new protocol in mobile environments. There are several projects addressing the
problems of multicast and mobility. The main approaches are based on home subscription, remote
subscription and hybrid solutions. Before analyzing the use of multicast approaches in WSNs, it is
important to discuss if it is possible to integrate IP with WSNs. Adding the TCP/IP stack to sensors
can be too much for sensors with reduced processing power and can lead to prohibitive power
consumption. However, if it is possible to eploy a thin IP protocol, it will be possible to integrate
future WSNs with the Internet, and a significant number of new applications will appear. This is a
big step towards the announced heterogeneity of the future 4G environments and to the sensor
networks. There are a few projects that carry out work in this area. SICS developed a new operating
system for microprocessors, where IP-based connections are supported. More recently the well
known platform TinyOS, adopted an extension that allows IP connectivity.

Designing Multicast in WSNs:

Multicasting in WSNs can be designed in different ways. We will look at two approaches, reliable
IP Multicast and Overlay Multicast. For both approaches we will look at source driven and
receiver-driven designs, both centrally managed as well as de-centrally organized. Generally we
will distinguish between two node types. Branching nodes have to duplicate packets and store state
information about receivers and/or about other branching nodes. Forwarding nodes have less or no
information about the multicast state and just forward the multicast data to one neighbour. We will
also limit our discussion to core-based trees, where only the dedicated root node will disseminate
the data, while other senders would need to transmit the data to the root node first for
dissemination.
• Overlay Multicast
For the source driven scenario we can use a de-centralized as well as a centralized approach.
Generally, we distinguish between active and inactive multicast trees. While data is transmitted
to a multicast group, the tree is in the active state with all required TCP connections for the
overlay links established. New nodes are not allowed to join the group while its tree is active,
though the joins are cached and processed later.

When no data needs to be transmitted, the tree is inactive and all required TCP connections to
build the distribution overlay are closed. Nodes can only join to a multicast group while its tree
is inactive. This limitation ensures, that subscribed members get all data for a dissemination
session, because late joins are avoided. In the de-centralized and source-driven approach, the
source sends the list of all receivers of the multicast data to its one-hop neighbours. The
neighbour nodes then check if all receivers in the list can be reached through a single of their
next-hop neighbours. In this case, such a node just forwards the list to its next hop and
remembers that it acts as a forwarder for that multicast group. If nodes from the list can be
reached via different neighbours, the list is split accordingly and the partial lists (with the
node's own address as source of the message) are forwarded to the respective neighbours. The
node splitting the list becomes a branching node and opens a TCP connection for the overlay
link to the sender of the original list, when the corresponding tree is activated. Finally, if such
a list message arrives at the receiver (group member), then that node prepares the overlay link
to the source of the message (normally the last branching point). Therefore, TCP connections
for the overlay network links are only established between the source, branching nodes and the
receivers (see also Figure 1) when the corresponding multicast tree becomes active. New nodes
are added to the multicast tree by sending a list message including the new nodes as described
before. Only when a tree is inactive, new nodes can be added, Therefore, no connections are
established directly, but potential new overlay links are just prepared and only established upon
activation of the tree. If a branching node now receives a list message with new nodes, it
changes the source address of the list message, splits the list if required, and forwards it/them
further. If a forwarding node has to become a branching node, it prepares the overlay link to
the source of the list message, splits the message and forwards the new list messages further
as described before. This new branching node tells the source of the original list message which
receivers it handles in the future. Therefore, the previous branching node removes the overlay
link that previously was using this new branching node as forwarder. Upon reactivation of the
modified tree, the overlay link connections are opened from the source, via branching nodes
to the receivers. New and old receivers then become aware of their new group membership or
of the change of branching nodes for existing group memberships. Nodes can also be removed
using remove list messages accordingly and the forwarding and branching nodes have enough
information (as with adding new nodes) to modify the resulting tree. In the source-driven
centralized approach, the source node determines all required branching nodes ahead.
Therefore, the source also creates the complete distribution tree that is required for a multicast
group. The branching nodes are then notified, process the information and further forward
these notifications. If new receivers need to be added to a tree while it is inactive, the source
calculates the new and/or modified branching nodes. Only these nodes are notified about the
changes in the tree, branching nodes that do not need to be changed require no notification.
Removing receivers from the tree is done similarly, branching nodes that need to be modified
or removed are notified accordingly. For the centralized receiver-driven approach, the join
messages from the receivers are forwarded to the source, which manages the tree as described
for the source-driven centralized approach. In the receiver-driven de-centralized approach,
receivers send the join message to their neighbour responsible for the default route. If this node
is not a forwarder or branching node for that group it becomes a forwarding node (only
knowing that it is on the path of an overlay link when the tree would become active) and
forwards the join message further. Intermediate nodes, which are already branching nodes of
the requested group drop the join message and prepare the overlay link to the new receiver.
Forwarding nodes receiving join messages, become new branching nodes, prepare the new
overlay link and send this information (about becoming a branching node) towards the source,
dropping the original join message. A branching node receiving such a message modifies its
overlay link in that direction. Therefore, the overlay link of which the new branching node has
been acting just a forwarder before, is removed and replaced by an overlay link to this new
branching node. Receivers that want to leave a group send a leave message towards the source.
Forwarders on the path update their status for that group and forward the leave message further.
Branching nodes receiving a leave message update their status, remove the overlay link to the
leaving node, and discard the leave message. If the branching node has just one overlay link
left, it has to change its status to a simple forwarding node for the remaining receiver and
removes the affected overlay link. Further, it sends a notification towards the source and all
intermediate nodes update their states accordingly. They forward the message until it reaches
a branching node, which then establishes the overlay link to the remaining receiver. To support
end-to-end reliability in overlay multicast, the receivers have to acknowledge the receipt of
each multicast message or acknowledge the receipt accumulated after a series of messages.
Branching nodes aggregate and forward the acknowledgments. In case of missing
acknowledgments, they send negative acknowledgments further towards the source. Branching
nodes also take care of retransmission of lost packets and therefore need to cache the multicast
data up to a certain degree.
• Reliable IP-based Multicast
Contrary to Overlay Multicast (which uses TCP) we do not have a reliable end-to-end transport
protocol. Instead we are using UDP. End-to-end reliability is realized using acknowledgment
messages as described above. Branching nodes know only that their one-hop neighbours are
forwarding the packets on their behalf. Acknowledgments be handled on one-neighbour basis
(hop-to-hop), and not between branching nodes as for Overlay Multicast.
For the source-driven de-centralized approach the source sends the join list to its direct
neighbours that should act as forwarders. The next forwarder is determined on a hop-to-hop
basis. If a node has to become a branching node, it remembers from which neighbours it
expects acknowledgments. Joins and leaves are handled by appropriate messages that could
cause forwarders to become branching nodes (and vice versa) triggering a modification of the
expected acknowledgments state for a node. In the centralized source-driven approach the
source sends the list of all branching nodes to the closest branching node, which processes and
forwards them further to the nearest branching nodes on the path. Intermediate nodes become

forwarders and store the status for the involved multicast group. Acknowledgments are handled
directly between the branching nodes. Additional joining nodes trigger an update of the
affected branching nodes all initiated directly by the source. Leaves are handled accordingly
triggering updates of the branching and forwarding nodes involved. In the receiver-driven
centralized approach joins are sent to the source, which then acts as in the source-driven
centralized approach. In the de-centralized receiver-driven approach, joins cause intermediate
nodes to react as in the Overlay Multicast case. They either become forwarding nodes for that
group if they are not handling that group yet or become branching nodes if applicable.
Acknowledgments are handled the same way as described above in the de-centralized
sourcedriven approach.
Protocol Stack:
Figure 2 shows a possible protocol stack for reliable multicast in WSNs. End-to-end reliability for
reliable IP-based Multicast is ensured by REMC (Reliable Multicast) and for Overlay Multicast
by SNOMC (Sensor Network Overlay Multicast). To avoid unnecessary end-to-end retransmission
or caching in branching, we use a hop-to-hop reliable network protocol realized by H2HR (HopTo-
Hop Reliability) in combination with the MAC protocol. This allows to directly delete cached
packets after successful transmission to the next hop. To optimize the mentioned protocols,
information is exchanged across different layers using the cross-layer interface. For example, the
MAC layer informs H2HR about the successful (or unsuccessful) transmission of a packet. H2HR
is caching the packet until it has been transmitted successfully. Additional neighbourhood
information for deciding how to forward multicast packets and the involved paths is also requested
from the cross-layer interface by REMC and SNOMC. TSS (TCP Support for Sensor Nodes)
supports optimizations of TCP-specific mechanisms, such as intermediate caching, local
retransmission and acknowledgment recovery and regeneration. Additional energy-saving is
achieved by disabling the radio interface by the MAC layer when no transmission is required.

Multicast Routing Protocols:

There are two kinds of multicast routing protocols: dense mode routing protocols and spare mode
routing protocols. Dense mode routing protocols use flooding techniques to propagate information
between the routers. When using flooding techniques the routing information is propagated to
every router on the network. Thus these protocols use a lot of bandwidth and is most suited for
networks where the multicast group members are densely distributed. The spare mode routing
protocols use techniques that demands less bandwidth to propagate the routing information. These
techniques are said to be selective which means that they use different methods to select the routers
to which the routing information is propagated. Since the spare mode routing protocols are
designed not to burden the network with to much traffic they are well suited for networks where
bandwidth are not necessarily widely available. The first multicast routing protocols that were
designed all relayed on some unicast routing protocol. Today routing protocols that are
independent of the mechanism provided by any particular unicast protocol are designed.
1. Dense mode routing protocols
Dense-mode routing protocols use a data-driven approach to construct the routing trees. The
routers periodically floods out routing information on the network.
• Distance Vector Multicast Routing Protocol (DVRMP): This protocol creates its routing
trees according to the RPM forwarding technique. DVRMP relays on information that is
provided from some unicast protocol when creating its routing trees. Originally DVRMP
was used as routing protocol throughout the whole MBone and is defined in RFC1075.
• Multicast Extensions to Open Shortest Path First (MOSPF): MOSPF is standardised
in RFC- 1584. MOSPF is only used within autonomous systems, e.g. networks that is
controlled by a single organisation. Each MOSPF router has complete knowledge of the
network's topology. Based on this knowledge the routers construct the routing trees.
MOSPF is a development of OSPF which is a unicast routing protocol for autonomous
systems.
• Protocol Independent Multicast - Dense Mode (PIM-DM): PIM is a unicast independent
multicast routing protocol that is under development by an IETF working group. PIM-DM
comes in two versions, one dense mode and one spare mode. PIM-DM is the dense mode
version of PIM. Like DVRMP PIM-DM constructs routing trees based on the RPM
technique.
2. Spare mode routing protocol
Spare mode routing protocols is usually receiver-initiated. This means that a router is only
included in a routing tree if it explicitly asks for it. By using an receiver-initiated technique
these protocols avoids burdening routers that don't participate in the multicast communication
with routing information. Thus a lot of the network's bandwidth is saved.
• Core Based Trees (CBT): This protocol builds routing trees based on the shared tree
technique. Consequently one shared tree is constructed for each multicast group. Every tree
contains a core router which constitute the tree's root. Routers joins the shared tree by
sending a join message to the core router. CBT does not relay on any unicast routing
protocol. CBT does not relay on any unicast routing protocol.
• Protocol Independent Multicast - Sparse Mode (PIM-SM): PIM-SM is the spare mode
version of PIM. Like CBT PIM-SM constructs routing trees that are shared by all members
 of a multicast group. When a router joins a multicast group it registers at the group's
Rendezvous Point Multicast Router (RP).Once the routing tree is constructed a router can
change it's connection to the tree. This can be advantageous if the router receives a lot of
packets from a certain host a would like to have a connection closer to that host. As
mentioned above PIM-SM is a unicast independent routing protocol.

Applications of Multicasting:
As businesses use more intranet, groupware, multimedia, and client/server technologies, they need
more IP multicasting applications. Video conferencing, audio conferencing, online training, news
distribution, software distribution, and database replication are all good candidates for IP
multicasting, one-to-many communication from a source to a group of selected destinations.
Multicasting applications can minimize the demand for network bandwidth while delivering
information from a source to multiple destinations via one stream.
Traditionally, network traffic is either unicast or broadcast. Unicasting is one-toone
communication from a source to a destination on the network. If n hosts request the same
information from the same source, n copies of the information move from the source host to n
destination hosts. Broadcasting is one-to-everyone communication from a source to the rest of
hosts on the network. The broadcast information reaches every host regardless of whether the host
needs the information. Broadcasting wastes network bandwidth by flooding the network when only
a small number of users need the information.
Unicasting and broadcasting do not work for certain applications. For example, your CEO wants
to conduct an audio conference with 50 senior managers through the network. If the multimedia
application for the conference uses unicasting, the CEO's computer repeatedly sends out 50 audio
streams to 50 managers' computers. Unicasting wastes bandwidth because it sends 50 duplicate
copies over the network, and it causes a significant delay before the last manager hears the CEO.
Broadcasting cannot solve the problem: Broadcasting sends only one audio stream over the
network, but it sends the information to every computer on the network. Therefore, the audio
stream floods every corner of the network and can bring the network down.
Multicasting comes to the rescue. The multicast host sends out only one copy of the information,
and only the destination hosts that need the information receive it. In the audio conferencing
example, the CEO's computer sends only one audio stream to the network, and only the 50 senior
managers receive the stream. The information uses only required network bandwidth and arrives
at every manager's computer without a noticeable delay.

Conclusion:
The full potential of Wireless Sensor Networks can only be explored if Internet connectivity is
provided. In order to do this, IP must, somehow, be supported in WSNs. Although sensor nodes
have stringent energy and processing limitations that constitute an obstacle to the use of a
fullyfledged IP protocol, simplified versions are already being used. In this respect, exploring the
use of IPv6 is also promising, because IPv6 uses simpler headers and offers native support for
mobility and multicast.
In this paper we have addressed both the use of IPv6 and the use of multicast in WSNs. The results
clearly show that WSNs can greatly benefit from both. Specifically, multicast leads to reductions
in the number of transmitted packets and, consequently, in energy consumption. In fact, WSNs
may become the next successful field of multicast deployment, in addition to the emerging field
of IPTV.
Further research will continue to explore the use of multicast in WSNs. Specifically, a new
multicast protocol based on Source Specific Multicast is being developed and will be deployed
and evaluated in the WSN platform presented in this paper.

References:
1. C. Sule, P. Shah, K. Doddapaneni, O. Gemikonakli and E. Ever, "On Demand Multicast
Routing in Wireless Sensor Networks," 2014 28th International Conference on Advanced
Information Networking and Applications Workshops, 2014, pp. 233-238
2. M. Hosseini, D. T. Ahmed, S. Shirmohammadi, N. D. Georganas A Survey of
ApplicationLayer Multicast Protocols Communications Surveys & Tutorials, 9(3), 58-74,
2007
3. J. S. Silva, T. Camilo, A. Rodrigues, M. Silva, F. Gaudencio and F. Boavida, "Multicast in
Wireless Sensor Networks The next step," 2007 2nd International Symposium on Wireless
Pervasive Computing, 2007, pp.