International Journal of Computer Science Trends and Technology (IJCST) Volume1 Issue2, Nov-Dec 2013

ISSN: 2347-8578 www.ijcstjournal.org Page 11

RBMulticasting Protocol in Ad-Hoc Networking
Santhiya R
1
, MohanRaj E
2
, Dr D.DuraiSwamy
3
Department of Computer Science and Engineering,
K.S.Rangasamy College of Technology

ABSTRACT
An emerging network application for delivering packet from one source to group of destination. The
application includes the transfer of audio, video, text to live lecture to set of participants, Video broadcasting
to media such as headlines, weather, and sports, from file distribution and caching to monitoring of
information such as stock prices, sensors, and security. In adaptive Network with data traffic, where long time
of intervals are expected among the bursts of data, thus multicast state maintenance adds a large amount of
communication, processing, and memory overhead for no benefit to the network application. Implementing a
stateless receiver-based multicast protocol that simply uses a directory of the multicast members addresses,
attached in packet headers, to enable group to decide the best way to ahead the multicast traffic. Which
exploits the information of the geographic locations of the nodes to remove the need for costly state
maintenance, making it ideally suited for multicasting in dynamic networks. RBMulticast will be implemented
in the Ns2 simulator.
Index Term Ad-Hoc Networking, Stateless, Receiver-based, Multicast, Routing, Protocol

1. Introduction
Multicasting is the transmission of packets to
the group of mobile nodes identified by a single
multicast destination address and hence is intended
for group-oriented computing. An applications such
military battlefields, emergency search and rescue
sites, classrooms, video broadcasting to push media
such as headlines, weather, and sports, from file
distribution and conventions where participants share
information dynamically using their mobile devices
that lend themselves well to multicast operations.
Improved transmission efficiency can reduce energy
consumption, which is an important consideration in
MANETs.
Multicasting topology y can be classified into
Tree-Based and Mesh-based topology. Further Tree-
based is divided into group-shared tree and Source
based tree. Group-shared tree is to constructs one
single tree for a multicast group even if there is more
than one source which uses less memory, get sub-
optimal path from source to destination. Source-
Based Tree is to Constructs an individual tree for
each sender in a multicast group which uses more
memory, get optimal path from source to destination
and minimizes delay. Mesh-based topology is to
create a multiple paths exist between any sender and
receiver pair. One possible way to implement mesh
is using the concept of forwarding group.
Work is focused on a Receiver-Based
Multicasting Protocol, which is stateless cross-layer
multicast protocol where packet routing, packet
splitting medium access of single node rely solely on
location information of multicast destination nodes.
RBMulticast includes a list of the multicast members
locations in the packet header, which prevents the
overhead of building and maintaining a multicast tree
at intermediate sensor nodes, because all the
necessary information for routing the packet is
included within the packet header. Additionally, the
medium access method employed does not require
any state information such as neighbor wake-up time
or any a priori operations such as time
RESEARCH ARTICLE OPEN ACCESS
International Journal of Computer Science Trends and Technology (IJCST) Volume1 Issue2, Nov-Dec 2013
ISSN: 2347-8578 www.ijcstjournal.org Page 12

synchronization. No tree creation or maintenance or
neighbor table maintenance is required, making
RBMulticast require the least state of any multicast
routing protocol, and it is thus ideally suited for
dynamic networks.
RBMulticast is a receiver-based protocol,
which means that the send node of a packet
transmission is decided by the probable receivers of
the packet in a spread manner. This routing draw near
does not require routing tables and enables the use of
the current spatiotemporal locality; this can be
compared to proactive and reactive routing protocols
where the route is decided using the latest available
information, which can be decayed. This is a crucial
property, especially for energetic networks. In
RBMulticast, receivers contend for the channel based
on their potential payment toward forwarding the
packet, which is inspired by the cross-layer protocol
XLM, a receiver based unicast protocol designed for
sensor networks. Nodes that make the most forward
development to the destination will contend earlier
and hence have a higher possibility to become the
next-hop node. In RBMulticast, the multicast routing
uses the concepts of virtual node and multicast
region for forward packets closer to the destination
multicast nodes and determining when packets should
be split into separate routes to finally reach the
multicast members.


2. RELATED WORK
Existing multicast protocols for WSNs and MANETs
generally use a tree to connect the multicast
members. Additionally, multicast algorithms rely on
routing tables maintained at intermediate nodes for
building and maintaining the multicast tree. ODMRP
applies on-demand routing techniques to avoid
channel overhead and improve scalability. It uses the
concept of, forwarding group, a set of nodes
responsible for forwarding multicast data on shortest
paths between any member pairs, to build forwarding
mesh for each multicast group. A soft state approach
is taken in ODMRP to maintain multicast group
members. No explicit control message is required to
leave the group.
The Core-Assisted Mesh Protocol (CAMP) is
designed to support multicast routing in very
dynamic ad-hoc networks with broadcast links. It
adopts the same basic architecture used in IP
multicast. A mapping service is assumed to exist that
provides routers with the addresses of groups
identified by their names. In the Internet, this service
Would be provided by the Domain Name System
(DNS), for example. Hosts wishing to join a
multicast group must first query the mapping service
to obtain a group address and then interact with their
local routers (which we call routers here) through
IGMP or an equivalent host-to-router protocol to
request membership in a multicast group.
PUMA implements a distributed algorithm to
elect one of the receivers of a group as the core of the
group, and to inform each router in the network of at
least one next-hop to the elected core of each group.
The election algorithm used in PUMA is essentially
the same as the spanning tree algorithm introduced
for internetworks of transparent bridges. Within a
finite time proportional to the time needed to reach
the muter farthest away from the eventual core of a
group, each router has one or multiple paths to the
elected core.


3. RBMulticast Protocol
RBMulticast is a receiver-based cross-layer protocol
that performs multicast routing based on receiver-
based location unicast protocols such as XLM [2].
Void hole problem is solved implicitly by
RBMulticast.

3.1. Multicast Regions
Multicast region is formed which has a set of node
and assumed as a destination. When node receives
the packet from the source, packets are split of the
packet to each region that contains one or more
multicast members. Approaches for dividing the
multicast is either by quadrants or by dividing the
region into three regions.
International Journal of Computer Science Trends and Technology (IJCST) Volume1 Issue2, Nov-Dec 2013
ISSN: 2347-8578 www.ijcstjournal.org Page 13

3.2. Packet Splitting
For Simplicity, algorithm 1 and algorithm 2 the
RBMulticast method that splits packets at relay nodes
for which the multicast destinations reside in
different regions. Variation form RBMulticast
requires similar or lower average number of hops to
reach all members.
Algorithm 1. RBMulticast Send
Require: Packet output from upper layer
Ensure: Packets inserted to MAC queue

1: Get group list N from group table
2: for node n in group list N do
3: for multicast region r in 4 quadrants regions R do
4: if n 2 r then
5: Add n into r:list
6: end if
7: end for
8: end for
9: for r 2 R do
10: if r:list is non-empty then
11: Duplicate a new packet p
12: Add RBMulticast header (TTL, checksum,
r.list) to p
13: Insert p to MAC queue
14: end if
15: end for

Algorithm 2. RBMulticast Receive
Require: Packet input from lower layer
Ensure: Forwarded packets inserted to MAC queue

1: Calculate checksum. Drop packet if error detected
2: Drop packet if not in Forwarding zone
3: Get destination list D from packet header
4: for node d in destination list D do
5: if I am d then
6: Duplicate the packet and input to upper layer
7: Remove d from list D
8: end if
9: end for
10: if TTL in header 0 then
11: Drop the packet
12: return
13: end if
14: for d 2 D do
15: for multicast region r in 4 quadrants regions R do
16: if d 2 r then
17: Add d into r:list
18: end if
19: end for
20: end for
21: for r 2 R do
22: if r:list is non-empty then
23: Duplicate a new packet p
24: Add RBMulticast header (TTL _ 1,
checksum; r:list) to p
25: Insert p to MAC queue
26: end if
27: end for

3.3. Virtual Nodes

In RBmulticast,No knowledge of neighbor nodes and
no routing tables are maintained. So, assume that
virtual node located at the geographic mean of the
multicast members for each multicast region. when
using the nearest multicast node as the destination, all
node addresses physically exist and virtual node
necessary.


International Journal of Computer Science Trends and Technology (IJCST) Volume1 Issue2, Nov-Dec 2013
ISSN: 2347-8578 www.ijcstjournal.org Page 14



Fig. 1 Performance comparisons for RBMulticast: static scenario, five sinks. (a) Packet delivery ratio versus
number of nodes (static nodes, five sinks). (b) Average latency versus number of nodes (static nodes, five
sinks). (c) Average traffic for transmitting one data packet versus number of nodes (static nodes, five sinks).

3.4 RBMulticast Header
Objective of stateless is to keep intermediate
nodes from having to store any data for routing and
medium access. Destination List Length (DLL)
indicates how many nodes are in the node list, and
thus will determine the length of the header.

3.5 Group Management
RBMulticast simulations to compute the three
performance metrics: packet delivery ratio, latency,
and the average traffic generated to transfer one data
packet to all multicast members Multicast group
management where nodes can join or leave any
multicast group. Node manages the multicast groups
and act as the group heads. Nodes join and leave a
group by sending join and leave packets to the
group head.

4. Performance Evaluation
In all scenario, the area is a 150 m _ 150 m
square. The transmission range is 30 m and the
interference range is approximately 80 m. The
channel data rate to be 220 Kbps, the length of RTS,
CTS, and ACK packets to be 78 bits and of raw data
packets to be 400 bits. The source packet generation
rate is 0.2 pkts.

4.1 Static nodes, five sinks
To compute the performance of RBMulticast
using Static Nodes. Fig 1a The packet delivery ratio
is very low for a small for nodes and its close to
100%.Fig 1b The latency as a function of the number
of nodes. Under low duty cycle and low node density
of RBMulticast, since the sleeping times are not
synchronized, it is very possible that no relay node
candidate can be found in the first attempt, and
multiple retransmissions are needed to find a relay
node. RBMulticast reduces the total number of
transmissions to reach all multicast members; the
average latency is lower than the other two protocols.
Fig. 1c The average traffic generated to transmit one
data packet to all multicast members is shown in Fig.
1c. It is calculated by dividing the total number of
traffic generated to transmit one data packet
(RTS/CTS/DATA/ACK) by the packet delivery ratio.
Since RBMulticast requires fewer packet
transmissions, it generates the least traffic for the
delivery of a data packet among the three methods.
International Journal of Computer Science Trends and Technology (IJCST) Volume1 Issue2, Nov-Dec 2013
ISSN: 2347-8578 www.ijcstjournal.org Page 15


Fig. 2 Performance comparisons for RBMulticast: Dynamic scenario, five sinks. (a) Packet delivery ratio
versus Moving Speed (b) Average latency versus Moving Speed (c) Average traffic for transmitting on se data
packet versus Moving Speed.

4.2 Mobile Nodes, Five Sinks
All intermediate nodes move according to the
Random Waypoint mobility model with a certain
speed. The source and multicast members are moved
inward 25 m as compared to avoid the issues with the
cluster into the middle effect of the Random
Waypoint model A duty cycle of 100 percent is
investigated for three different numbers of nodes:
100, 200, and 300. Fig. 2a shows the packet delivery
ratio as a function of mobile speed. Note that the data
points corresponding to 0 m/s show the performance
of static networks. All three curves indicate that when
the intermediate nodes are moving at low speeds and
the node density is low, the performance is slightly
better than that when they are static.
Fig. 2b shows the average latency as a
function of mobile speed. When density is increased,
less time is required to finish the transmission.
Fig. 2c shows the average traffic generated to
transmit one data packet as a function of mobile
speed. When the speed of mobile nodes increases, the
average traffic generated per transmission becomes
higher due to the increase in the number of
retransmissions caused by more link breaks.



5. Conclusion
RBMulticast uses geographic location
information to route multicast packets, where nodes
divide the network into geographic multicast
regions and split off packets depending on the
locations of the multicast members. RBMulticast
stores a destination list inside the packet header; this
destination list provides information on all multicast
members to which this packet is targeted. Thus, there
is no need for a multicast tree and therefore no tree
state is stored at the intermediate nodes. RBMulticast
also utilizes a receiver-based MAC layer to further
reduce the complexity of routing packets. Because we
assume that the receiver-based MAC protocol can
determine the next-hop node in a distributed manner
the sender node does not need a routing table or a
neighbor table to send packets but instead uses a
virtual node as the packet destination. Our
simulations and implementation of RBMulticast
showed that it can achieve high success rates, low
latency, and low overhead in terms of the number of
bits transmitted in the network for both static and
dynamic scenarios, making RBMulticast well suited
for both mobile and stationary ad hoc network
environments.


International Journal of Computer Science Trends and Technology (IJCST) Volume1 Issue2, Nov-Dec 2013
ISSN: 2347-8578 www.ijcstjournal.org Page 16

6. References

[1] Chen-Hsiang Feng ., Iiker Demirkol
and Wedi B.Heninzelman
(2012),Stateless Multicast Protocol for
Ad Hoc Network,IEEE Transactions
on Mobile Computing, Vol.11, No.
2,pp.240-253.
[2] Chiang C., M. Gerla and S.-J. Lee
(1999), On-Demand Multicast
Routing Protocol, Proc. IEEE
Wireless Comm. and Networking
Conf.(WCNC 99), Vol. 3, pp. 1298-
1302.
[3] Das S., Pucha H (2008), Distributed
Hashing for Scalable Multicast
Wireless Ad hoc Networks, IEEE
Trans. Parallel and Distributed
Systems,Vol. 19, No. 3, pp. 347-362.
[4] Garcia-Luna-Aceves J and Madruga E
(1999), A Multicast Routing Protocol
for Ad-Hoc Networks , Proc. IEEE
INFOCOM, Vol. 2, pp. 784-792.
[5] Garcia-Luna-Aceves J and
Vaishampayan R (2004), Efficient and
Robust Multicast Routing in Mobile Ad
HOC Networks, IEEE Intel Conf.
Mobile Ad-Hoc an d Sensor
Systems,pp. 304-313.
[6] Ruiz H.,Sanchez J and Stojmnenovic I
(2006), GMR: Geographic Multicast
Routing for Wireless Sensor
Networks, IEEE Comm. Soc. Conf.
Sensor and Ad Hoc Comm. and
Networks (SECON 06),Vol. 1, pp. 20-
29.