Experimental Investigation Of Streaming Over Mobile Ad Hoc Networks Using PUMA

Experimental Investigation Of Streaming Over Mobile Ad Hoc Networks Using PUMA

Aiswarya Antony1, Swarna Parvathi .S2 Akshya Venkatesan3 Department of Information Technology Department Of Computer Science and Engineering Sri Venkateswara College of Engineering Santa Clara University, Santa Clara

Sriperumbudur.India California

Abstract

An ad hoc network is a dynamic wireless network with the engagement of cooperative nodes without a fixed infrastructure. Multicasting is intended for group communication that supports the dissemination of information from a sender to all the receivers in a group. On the basis of comparison of multicasting protocols, Protocol for Unified Multicasting through Announcement (PUMA) has been chosen for initial implementation. PUMA does not rely on any unicast routing approach. It delivers data at a higher efficiency, while also providing a tight bound for control overhead in a wide range of network scenarios. Secure communication is a major concern in PUMA, especially because multicasting protocols are applied in areas such as audio/ video conferencing, corporate communications, collaborative and groupware applications. PUMA achieves desired packet delivery ratio with variable number of nodes. The intention of this paper is to bring efficient and secure multicasting with PUMA protocol over the IEEE 802.11 standard. Simulations are carried out in the Network Simulator NS-2 to evaluate the performance of the protocol. The results show that PUMA outperforms other multicast protocols in terms of throughput, packet delivery ratio and scalability.

Keywords– Ad Hoc Networks, Multicast, PUMA.

1. Introduction

   An ad hoc mobile network [1] is a collection of mobile nodes that are dynamically and arbitrarily located in such a manner that the interconnections between nodes are capable of changing on a continual basis. Mobile ad-hoc networks operate in the absence of fixed infrastructure. They offer quick and easy network deployment in situations where it is not possible otherwise. Nodes in mobile ad-hoc

   network are free to move and organize themselves in an arbitrary fashion. Each user is free to roam about while communication with others. The path between each pair of the users may have multiple links and the radio between them can be heterogeneous. This allows an association of various links to be a part of the same network. Mobile ad-hoc networks can turn the dream of getting connected "anywhere and at any time" into reality.

   Ad hoc networks have become increasingly relevant in recent years due to their potential applications in military battlefield, emergency disaster relief, vehicular communications etc. In ad hoc applications, collaboration and communication among a group of nodes are necessary. Instead of using multiple unicast transmissions, it is advantageous to use multicast in order to save network bandwidth and resources. Multicasting is a communication process in which the transmission of message is initiated by a single user and the message is received by one or more end users of the network.

   The objective of a multicast routing protocol for mobile ad hoc networks is to support the dissemination of information from a sender to all the receivers of a multicast group while trying to use the available bandwidth efficiently in the presence of frequent topology changes. Multicasting is especially important in mobile ad hoc networks(MANET) [2] because one to many communication is especially important in the context of ad hoc networks. Over the past few years, several multicast routing protocols have been proposed for ad hoc networks. On the basis of comparison of multicasting protocols, Protocol for Unified Multicasting through Announcement (PUMA) has been chosen for initial implementation. PUMA does not rely on any unicast routing approach. It delivers data at a higher efficiency, while also provides a tight bound for control overhead in a wide range of network scenarios. Secure communication is a major concern

   Mesh Membership code	Distance to core
   Group ID
   Core ID
   Sequence Number
   Parent ID

   Mesh Membership code	Distance to core
   Group ID
   Core ID
   Sequence Number
   Parent ID

   in PUMA, especially because multicasting protocols are applied in areas such as audio/ video conferencing, corporate communications, collaborative and groupware applications. The rest of the paper is organized as follows Section II presents an overview of the PUMA protocol. Section III shows Simulation on NS-2 and concluding remarks are made in Section IV. Finally, future work is discussed in Section V.

2. PUMA

   PUMA [3] is a reactive routing protocol which discovers route only when it is required. The most noticeable aspect of PUMA is that it uses a very simple and effective method to establish and maintain the mesh, this results in a low control overhead. Its multicast connectivity is established and maintained by means of receiver initialization approach in which the receivers joins into the multicast group by using address of core node without the need for network- wide flooding of control or data packets from all the sources of the group. Each group has exactly has one special node which is called as core node in the group. PUMA uses the shared mesh based multicast topology for constructing routes to the members of the multicast group without depending upon any unicast routing protocol. Multicast group maintenance of PUMA is achieved by using the soft state approach where in which the multicast group membership and its associated routes are refreshed periodically by flooding its Multicast Announcement (MA) packet.

   1. Control Packet

      PUMA uses a single control packet called Multicast Announcement (MA) to create and maintain its multicast topology in mobile ad hoc networks. Multicast announcements are used to:

      • elect cores dynamically

      • determine the routes for sources outside a multicast group to unicast multicast data packets towards the group

      • join and leave the mesh of a group

      • maintain the mesh of the group.

      Each multicast announcement specifies a sequence number, the address of the group (group ID), the address of the core (core ID), the distance to the core, a mesh member flag that is set when the sending node belongs to the mesh, and a parent that states the preferred neighbour to reach the core. Figure.1 depicts the multicast announcement packet format.

      Figure1.Multicast Announcement Packet Format

      Mesh membership code this field is set to 1 when a node wants to join into the group; else it is unset. Distance to core hop count from the current node to core node.

      Group ID address of the group.

      Core ID address of the core node.

      Sequence number sequence number of the group. Parent ID address of the neighbor to reach the core.

      Successive multicast announcements have a higher sequence number than previous multicast announcements sent by the same core. With the information contained in such announcements, nodes elect cores, determine the routes for sources outside a multicast group to unicast multicast data packets towards the group, notiy others about joining or leaving the mesh of a group, and maintain the mesh of the group.

   2. Connectivity Lists and propagation of Multicast Announcements

      A node which is core of a group transmits multicast announcements periodically for that group. As the multicast announcement travels through the network, it establishes a connectivity list at every node in the network. Using connectivity lists, nodes will be able to establish a mesh, and route data packets from senders to receivers. A node stores the data from all the multicast announcements it receives from its neighbors in the connectivity list. Fresh multicast announcements overwrite entries with lower sequence numbers for the same group. For a given group, a node has only one entry in its connectivity list from a particular neighbor and it keeps only that information with the latest sequence number for a given core. Each entry in the connectivity list, it stores the multicast announcement, stores the time

      when it was received, and the neighbor from which it was received. Next the node generates its own multicast announcement based on the best entry in the connectivity list. For the same core ID and sequence number, multicast announcements with smaller distances to the core are considered. When all those fields are the same, the multicast announcement that arrived earlier is considered. After selecting the best multicast announcement, the node generates the fields of its own multicast announcement i.e. Core ID, Group ID, Sequence number, Distance to core, Parent, Mesh member. The connectivity list stores information about all the routes that exist to the core. When a core change occurs for a group then the node clears the entries of its old connectivity list and builds a new list, specific to the new core.

   3. Mesh Establishment and Maintenance

      At the initial stage only receivers are considered as mesh members and their mesh member flag is set to TRUE in the MAs. Non receivers consider themselves as mesh members if and only if they have at least one mesh child in their connectivity list. A neighbor in the connectivity list is a mesh child if

      1. Its mesh member flag is set

      2. The distance to core of the neighbor is larger than the nodes distance to core

      3. The multicast announcement corresponding to this entry was

         received in within a time period equal to two MA intervals.

         If a node has a mesh child and is hence a mesh member, then it means that it lies on a shortest path from a receiver to the core.This condition is used to ensure that a neighbor is still in the neighborhood.

         Figure 2:Mesh Structure in PUMA

   4. Core Election Procedure in PUMA

PUMA chooses a core for each multicast group in the network. Each connected component has only one core. If one receiver joins the group before other receivers, then it becomes the core of the group. If several receivers join the group at the same time, then the one with highest ID becomes the core of the group.

When a receiver needs to join a multicast group, it first determines whether it has received a multicast announcement for that group. If the node has received, then it takes on the core specified in the announcement it has received, and it transmits the multicast announcements that specifies the same core for the group. Otherwise it assumes itself as the core of the group and starts transmitting multicast announcement periodically to its neighbors stating itself as the core of the group and a hop count of 0 distances to itself. Nodes propagate multicast announcements based on the best multicast announcement they receive from their neighbors.

A node that believes itself to the core of a group, it transmits multicast announcements periodically for that group. As the multicast announcement pass through the network, it establishes a connectivity list at every node in the network. Connectivity list is used to form a mesh structure and to route data packets from receivers to the core.

A node keeps track of the data from all the multicast announcements it receives from its neighbors in the connectivity list. Fresher multicast announcements from a neighbor overwrite entries with lower sequence numbers for the same group. Hence all the nodes in a group store the recent information about a neighbor for each core in the group. Each entry in the connectivity list also stores the time when it was received, and the neighbor from which it was received. The node then generates its own multicast announcement based on the best entry in the connectivity list.

While electing core, on receiving a multicast announcement with higher core ID, all entries in the connectivity list with a lower core ID are erased. Hence all suitable entries in the connectivity list at any point of time have the same core ID and sequence number. Among these suitable entries, the entries with a shortest distance to core be qualified as best entries, and the neighbors corresponding to these entries are called parents.

After selecting the best multicast announcement, the node generates the fields of its own multicast announcement in the following way:

• Core ID: The core ID in the best multicast announcement.

• Group ID: The group ID in the best multicast announcement.

• Sequence number: The sequence number in the best multicast announcement.

• Distance to core: One plus the distance to core in the best multicast announcement.

• Parent: The neighbor from which it received the best multicast announcement.

• Mesh member: A node sets its membership code field based on whether it is a mesh member or non-member.

After generating its own multicast announcement, it will broadcast to its entire neighbor. The connectivity list stores information about one or more routes that exist to the core. When a core change occurs for a particular group, the node clears the entries of its old connectivity list and builds a new one, specific to the new core. Figure 3 illustrates the propagation of multicast announcements and Table 1 shows the building of connectivity lists. The solid arrows indicate the neighbor from which a node receives its best multicast announcement. Node 6 has three entries in its connectivity list for neighbors 5, 1, and

1. However it chooses the entry it receives from 5 as the best entry, because it has the shortest distance to core and has been received earlier than the one from node 1. Node 6 uses this entry to generate its own multicast announcement, which specifies Core ID = 11, Group ID = 224.0.0.1, Sequence Number = 79, Distance to Core = 2 and Parent = 5. When a node wants to send data packets to the group, it forwards them to the node from which it received its best multicast announcement.

   If that link is broken, then it tries its next best and so on. Hence each node in the network has one or more routes to the core. The multicast announcement sent by the core has distance to core set to zero and parent field set to invalid address. Multicast announcements are generated by the core every three seconds. After receiving announcements multicast announcement with a fresh sequence number, nodes wait for a short period (e.g. 100 ms) to collect multicast announcements from multiple neighbors before generating their own multicast announcement.

   Table 1: Connectivity List at node 6

   Core ID = 11 Group ID = 224.0.0.1. Seq No = 79

   Neighbour	Multicast Announcement		Time (ms)
   	Distance To Core	Parent
   5	1	11	12152
   1	1	11	12180
   7	2	5	12260

   When multiple groups exit,nodes collect all the fresh multicast announcements they receive, and broadcast them periodically for every multicast announcement interval. However, multicast announcement representing groups being received for the first time, resulting in a new core, or resulting in variations in the mesh membership code are forwarded immediately, without aggregation. This is to pass up delays in critical operations, when electing core node and establishing mesh structure.

   Figure 3: Dissemination of Multicast Announcement

   1. Simulation Scenario

      The performance of packet delivery ratio is evaluated by computer simulation using ns 2.31. Network Simulation environment (NS2) [4] is used for setting up the experimental setup for multicasting the data packets. The main goal is to perform streaming of packets over ad hoc networks. Multicast routing protocol PUMA is used to achieve scalability in the network. PUMA achieves desired packet delivery ratio with variable number of nodes. Figure 4 shows the streaming of data packets over IEEE 802.11 using PUMA.

      Table 2 shows the results of PUMA protocol performance parameters for varying 25 to 125 nodes. Based on the simulation results shown in Table 2 the routing overhead of PUMA is far less compared to other multicast routing protocols. Also for increasing number of nodes, the throughput and packet delivery ratio of PUMA is higher than many other routing protocols

      Figure 4 : Streaming of data packets over IEEE 802.11 using PUMA.

      Table 2: Performance Evaluation of PUMA Protocol

      Number of nodes	Routing Overhead	Throughput	PDF
      25	117.84	163.96	3.3854
      50	135.72	209.86	8.0537
      75	138.03	400.70	12.7654
      100	156.71	651.07	15.4042
      125	170.62	713.65	16.9352

   2. Conclusion

      This paper evaluates performance of the multicast routing protocol PUMA. The results show that PUMA outperforms other multicast protocols in terms of throughput, packet delivery ratio and

      scalability. PUMA incurs far less overhead as compare to tree based multicast protocols and has higher delivery ratios because tree based protocols have to maintain tree structure so they expend too many packets which leads to congestion. Secure communication is a major concern in multicast ad hoc networks, especially because multicasting protocols are applied in many emerging applications.

   3. Future work

Future work will mainly focus on performance analysis of PUMA to achieve secure streaming of the scalable video streams over WiMAX using PUMA.

References

1] Akshay R. Gupta and Pankaj Kawadkar , Secure Multicasting in Ad-Hoc Network International Journal of Emerging Technology and Advanced Engineering,ISSN 2250-2459, Volume 2, Issue 8,

August 2012.

1. Osmah S. Badarneh and Michel Kadoch, Multicast Routing Protocols in Mobile Ad Hoc Networks: A Comparative Survey and Taxonomy, EURASIP Journal on Wirelesss Communication and Networking, Volume 2009(2009), Article ID 76047, 42 pages.

2. A. Amuthan and D. Nagamani Abirami, Multicast Security Attacks And Its Counter Measures For Puma Protocol Int. J. Comp. Tech. Appl., Vol 2 (3), 594-600.

3. The Network Simulator ns- 2,[Online].Available: http://www.isi.edu/nsnam/ns/.

4. Ravindra Vaishampayan and J.J.Garcia-Luna- Aceves, Efficient and Robust Multicast Routing in Mobile Ad Hoc Networks, Proceeding of IEEE International Conference on Mobile Ad hoc and Sensor Systems (MASS), 304-313,(2004).

5. WiMAX Forum http://www.wimaxforum.org.

6. Poonam, K. Garg and M. Misra, Trust Based Multi Path DSR Protocol, International Conference on Availability, Reliability and Security, pp: 204- 209, 2010.