Implementation of a Lightweight Service Advertisement and Discovery Protocol for Mobile Ad hoc Networks

Implementation of a Lightweight Advertisement and Discovery Protocol for Mobile Ad hoc Networks Wenbin Ma * Department of Electrical and Computer Engineering 19 Memorial Drive West, Lehigh University Bethlehem, PA 18015, USA wem2@lehigh.edu Baoning Wu, Wei Zhang, Liang Cheng * Department of Computer Science and Engineering 19 Memorial Drive West, Lehigh University Bethlehem, PA 18015, USA cheng@cse.lehigh.edu Abstract advertisement and discovery are important components for computing in mobile ad hoc network (MANET). In this paper, a lightweight protocol of service advertisement and discovery has been implemented, which is based on a MANET multicast protocol ODMRP (On-Demand Multicast Routing Protocol). In this protocol, service advertisement and discovery information is piggybacked in ODMRP routing control packets. Simulation results of the implementation prove that the implementation workload and resource consumption of the protocol are lightweight. Keywords-service advertisement and discovery; mobile ad hoc networks; on-demand multicast routing protocol I. INTRODUCTION A. Mobile Ad hoc Network and ODMRP A mobile ad hoc network (MANET) is a collection of intercommunicating mobile nodes without a centralized coordinating entity or fixed infrastructure, which is an autonomous network modeled in the form of an arbitrary graph. This is in contrast to the well-known single hop cellular network model that supports the needs of wireless communication by installing base stations as access points. In these cellular networks, communications between two mobile nodes completely rely on the wired backbone and the fixed base stations. In a MANET, no such infrastructure exists and the network topology may dynamically change in an unpredictable manner since nodes are free to move. A MANET uses some routing algorithms to organize the network by automatically discovering the topology of the connectivity among constituent nodes. ODMRP [1] (On- Demand Multicast Routing Protocol) is one of the multicast routing protocols that have been proposed for MANETs. It is based on a mesh topology and a forwarding group concept (i.e., only a subset of nodes forward the multicast packets). A soft state approach is taken in the ODMRP to maintain multicast group memberships. No explicit control message is required to leave a multicast group. B. Discovery and Advertisement in MANET A service is an entity that can be used by a person, a software program, or another service [2]. It may be a computation, storage, a communication channel to another user, a software filter, a hardware device, or another user. advertisement and discovery are important components for ubiquitous computing platforms since they enable communication and computing entities to provide services to peers and to be aware of and use the available services from peers. It addresses how network devices discover services that are available in the network. A service advertisement and discovery protocol that piggybacks service advertisement and discovery information in ODMRP routing control packets has been proposed in [2]. We have implemented this protocol with both pull and push models considering service mobility and network-resource saving. The rest of this paper is organized as follows. Section II presents the related work of various service advertisement and discovery mechanisms. Section III introduces the motivation of our design and Section IV discusses the details of our implementation and simulations. Simulation results have been presented in Section V. The last section concludes this paper. II. RELATED WORK Several service advertisement and discovery mechanisms have been extensively researched, such as Jini [3] and SLP ( Location Protocol) [4]. A. Jini The service advertisement and discovery in Jini technology include a trio of protocols called discovery, join, and lookup. A pair of these protocols, discovery/join, fulfills the service advertisement functionality. It occurs when a device is plugged in. The discovery protocol is used when a service looks for a lookup server with which to register. The join protocol is used when a service has located a lookup server and wishes to join it. The lookup protocol is used when a client or user needs to locate and invoke a service described by its interface type (written in the Java programming language) and possibly, other attributes. * Laboratory Of Networking Group (LONGLAB, http://long.cse.lehigh.edu) GLOBECOM 2003-1023 - 0-7803-7974-8/03/$17.00 2003 IEEE

Object Directory Agents (DA) Directory Agents (DA) Client lookup Figure 1. Jini processes of discovery/join/lookup Active DA discovery request DA advertisement Lookup Server discovery DA advertisement Figure 2. Methods of service discovery in SLP. B. Location Protocol The SLP establishes a framework for service discovery using three types of agents that operate on behalf of networkbased software: (1) Agents (SA) advertise the location and attributes on behalf of services, (2) Directory Agents (DA) aggregate service information, and (3) User Agents (UA) perform service discovery on behalf of client software. Fig. 2 illustrates active and passive methods for service discovery in the SLP. In active discovery, UAs and SAs multicast SLP requests to the network. In passive discovery, DAs multicast advertisements for their services and continue to do this periodically in case any UAs or SAs have failed to receive the initial advertisement III. MOTIVATION OF OUR EXPERIMENT The existing service discovery approaches are not suitable for mobile ad hoc networks with highly dynamic topologies since they either rely on centralized servers or employ resource-consuming query flooding. Our goal is to find a lightweight service advertisement and discovery protocol that considers both mobility and network-resource saving in mobile ad hoc communication environment. Multicast is favorable for the implementation of service discovery in MANETs because of: (1) the broadcast nature of wireless communication environment, (2) the infrastructureless feature of MANETs, and (3) the one-to-many character of service advertisement and discovery. There are many multicast protocols for MANETs. Simulation results in [5] show that the ODMRP achieves better performance than other multicast protocols in most cases. The protocol implementation complexity and resource consumption will be lightweight if the service discovery information is piggybacked in the ODMRP join Provider User Agents (UA) User Agents (UA) Passive DA discovery Object Attributes Agents (SA) Agents (SA) routing control packets assuming that the mobile devices support multicast routing functionality in the mobile ad hoc networking environment. Moreover, our implementation avoids excessive traffic overhead of periodic advertisements since only updated service advertisements are distributed and the service query/reply mechanism in the pull model is used. IV. SIMULATION DESIGN The simulation is designed to evaluate the performance of the service discovery and advertisement protocol based on the ODMRP in MANETs. Network simulator ns2 [6] is used. Since the original ns2 from University of Southern California does not support mobile ad hoc network multicast protocols, we use an alternated version [7] that provides full supports of two types of multicast routing protocols: ADMR (Adaptive Demand-Driven Multicast Routing protocol) [8] and the ODMRP. In the rest of this section, we will describe how we modify the original ODMRP protocol to implement and simulate our new protocol. A. Header Definitions To implement service discovery and advertisement, we extend the definition of the original ODMRP header by adding new header fields. The extended header for the service advertisement and discovery resides in the original ODMRP control packets. The definition of the header structure is shown in TABLE I [2]. TABLE I. FORMAT OF SERVICE ADVERTISMENT 1 BYTE 1 BYTE 1 BYTE 1BYTE Type 1 Option Field 2 Time to Live 3 Port 4 Server Address 5 (in unicast form) Name 6 (ID) Protocol Type 7 Reserved 8 Optional Fields 9 1. 0x01 as service advertisement. 2. 0 means no optional information; 1 means optional fields at the end 3. Geographical scope the service covers in terms of the number of hops 4. The port number of the service point 5. The unicast IP address of the server 6. The index or the name of the service 7. Protocol type that the server and clients use 8. If 0, ignored on reception 9. description for multi-level services B. Types To implement service advertisement and discovery, the node should have the knowledge of the service types in advance. In our simulation, we define four different IDs for three different types of services. The detailed definitions are shown in TABLE II. GLOBECOM 2003-1024 - 0-7803-7974-8/03/$17.00 2003 IEEE

TABLE II. TYPES OF SERVICES Type ID Value Notes SER_CONSUMER 0x0 Consumer does not provide any service. SER_PRINTER 0x1 Node with printing service. SER_SCANNER 0x2 Node with scanning service. SER_ADDR_BOOK 0x3 Node with address book service. C. ODMRP Agent Each node in ns2 should have an agent. The agent handles events, sends, and receives packets. The ODMRP also has its own agent implementation. In our simulation, we modify the ODMRP agent and make it have the intelligence to fulfill the service advertisement and discovery functionality. First, we define two new member variables: node_type and discover_type. Node_type stands for the service type of this node and discover_type stands for the service type that the node wants to query. Then, we set the new advertisement and discovery header. Finally, we rewrite the code to output some log information of service discovery and advertisement for each node in the multicast groups. The sample result log is shown in Fig. 3. Node 29: I have a service (id = 2, name = Scanner) Node 33: Found a service from node 29 (id = 2, name = Scanner). Node 19: I have a service (id = 3, name = Address Book) Node 27: Found a service from node 19 (id = 3, name = Address Book). Node 12: I have a service (id = 2, name = Scanner) Node 16: Found a service from node 12 (id = 2, name = Scanner). Figure 3. Simulation output log snippet. D. Simulation Senarios There are several parameters that we can set to implement different kinds of scenarios in the simulation. The first parameter is the maximum moving speed of nodes. The faster the relative speed, the more dynamic the network is. The second parameter is the pause time, which means how long a node can be stationary in one place before it moves to another place. The larger the pause time, the more stable the network is. The third one is the number of multicast groups. The last parameter is the moving range of all the nodes in the simulation. In our simulation, all the scenarios are run in the boundary of 500*500 and will last for 200 seconds. V. SIMULATION RESULTS To evaluate the performance of our protocol, we use the following three metrics: Successful delivery ratio: The ratio for the number of all the service advertisement and discovery packets that have been received successfully by our protocol to the number of packets sent. In the rest of the paper, the successful delivery ratio and the success ratio are interchangeable terms. Overhead ratio: The ratio of the number of packets our protocol has used for service advertisement and discovery to the number of all the ODRMP control packets. Delay time: The time for all the client nodes to discover all the services available in the network. The success ratio is an important performance index as it describes the efficiency of the protocol to propagate service information through the network. The overhead ratio is also important since it describes the cost that our implementation has added to the original ODMRP protocol for service advertisement and discovery. The delay time is used to compare our protocol with other ad hoc network service discovery protocols to see how fast the service advisement and discovery can converge in mobile ad hoc networks. A. Success Ratio To study the protocol performance in terms of the success ratio, we have conducted simulations in two ways. First, we fix the pause time to be 2 seconds and change the speed of nodes from 1 m/s to 50 m/s. Then, we fix the speed of nodes to be 1m/s and change the pause time from 1 second to 50 seconds. In all scenarios, the number of nodes has been set to 50. There are five multicast groups and each group has three service providers and six client nodes. The join-group and leave-group events happen randomly during the simulations. Table III and Fig. 4 show the success ratio versus various node moving speeds. Table IV and Fig. 5 show the success ratio versus moving pause time. TABLE III. SUCCESS DILIVERY RATIO VS. NODE SPEED Speed(m/s) Expected total Real total Success ratio packets packets (%) 1 90 86 95.6 5 90 80 94.4 10 90 82 93.1 15 90 81 92.5 20 90 85 94.4 25 90 85 94.4 30 90 86 95.6 35 90 84 93.3 40 90 85 94.4 45 90 83 92.2 50 90 77 85.5 GLOBECOM 2003-1025 - 0-7803-7974-8/03/$17.00 2003 IEEE

100 95 90 85 80 75 100 95 1 5 10 15 20 25 30 35 40 45 50 Figure 4. Success delivery ratio as a function of node moving speed (x axis as the node moving speed in m/s and y axis as the success ratio in %). TABLE IV. SUCCESS DILIVERY RATIO VS. PAUSE TIME Pause time(s) Expected total Real total Success ratio packets packets (%) 1 90 85 88.4 5 90 81 90.0 10 90 86 91.2 15 90 85 90.0 20 90 82 91.1 25 90 83 92.2 30 90 85 94.4 35 90 83 92.2 40 90 76 94.4 45 90 86 95.6 50 90 78 95.5 When the nodes move faster and more continuously, more packets will be dropped. This probably causes slow propagation of service advertisement and discovery. However, in all simulation scenarios, the values of the success delivery ratio always remain in a quite high level, e.g., all the values are above 85%. B. Overhead Ratio To observe the overhead ratio, we conduct simulations in six scenarios. Each scenario has four multicast groups. The number of service providers in each group has been set from one to six and the number of client nodes in each group has been set to six. In all the scenarios, nodes move with the maximum speed of 1 m/s and an average pause time of 2 seconds. The join-group and leave-group events happen randomly during the simulations. Table V and Fig. 6 show the overhead ratio with different numbers of service providers. The simulation results show that the overhead ratio remains almost a constant when the number of service providers in each group has increased. When the number of service providers increases, the number of packets for service advertisement and discovery increases. In the meantime, the number of the original ODMRP packets has also increased because the total number of nodes in network has been increased. Therefore the overhead ratio only changes slightly. TABLE V. provider (per group) OVERHEAD RATIO VS. NUMBER OF SERVICE PROVIDERS Total packets Packets for service discovery and advertisement Overhead ratio (%) 1 208718 714 0.34 2 415538 1538 0.37 3 685633 2439 0.36 4 888755 3078 0.35 5 1008256 3758 0.37 6 1161419 4313 0.37 90 0.5 85 0.45 80 0.4 75 1 5 10 15 20 25 30 35 40 45 50 0.35 0.3 Figure 5. Success delivery ratio as a function of pause time (x axis as the pause time in second and y axis as the success ratio in %). The results show that (1) the success ratio drops when the node moving speed increases; and (2) the success ratio increases when the pause time for node movement increases. Therefore the success delivery ratio of service discovery and advertisement packets depends on the mobility of the nodes. 0.25 0.2 1 2 3 4 5 6 Figure 6. Overhead ratio as a function of the number of service providers (x axis as the number of service providers and y axis as the overhead ratio in %). GLOBECOM 2003-1026 - 0-7803-7974-8/03/$17.00 2003 IEEE

In all the scenarios, the values of the overhead ratio remain less than 0.4%. This is because only updated service advertisement packets are distributed in the network and the service query/reply mechanism in the pull model is used. These mechanisms make the service information to be sent in the network only when necessary. Therefore, network resources can be saved by avoiding unnecessary query flooding. In summary, the protocol presented in this paper successfully provides service advertisement and discovery by adding small overheads to the original ODMRP. Therefore it is a lightweight protocol. C. Delay Time To measure the delay time, we conduct simulations in ten scenarios. The number of multicast groups in each scenario has been set from one to ten. Each group has five nodes, where two of them are service providers and the rest three are client nodes. In all the scenarios, all the nodes have associated with a certain group from the beginning of the simulations and there is no join-group and leave-group event during the simulations. The nodes move with the maximum speed of 1 m/s and an average pause time of 2 seconds. Table VI and Fig. 7 show the delay time with different numbers of nodes. TABLE VI. DELAY TIME VS. NUMBER OF NODES Total number of nodes Delay time (s) 5 0.012 10 0.012 15 0.023 20 0.087 25 0.078 30 0.093 35 0.096 40 0.198 45 0.224 50 0.373 0.8 0.7 0.6 0.5 0.4 0.3 0.2 0.1 0 5 10 15 20 25 30 35 40 45 50 Figure 7. Delay time as a function of the number of nodes (x axis as the number of nodes and y axis as the delay time in second). When the number of nodes increases, it takes more time for all the clients to discover the services in the network. Since our implementation is based on the ODMRP that is designed for efficient multicasting in MANETs, the delay time value remains in a low level and changes slightly. VI. CONCLUSIONS In this paper, we have presented a lightweight service advertisement and discovery protocol which is based on a multicast protocol in mobile ad hoc networks: ODMRP. Using this protocol, mobile nodes can be aware of the services in the MANETs by listening to the service advertisement; and any node in the MANET can send service inquiries and wait for the responses from the service providers to utilize those services. Simulation results have been studied to evaluate the performance of the protocol, which show that it achieves the goal of service advertisement and discovery in mobile ad hoc networks with small overheads. Future research includes performance comparisons and experiment studies. ACKNOWLODGEMENT This research is supported by Laboratory Of Networking Group (LONGLAB, http://long.cse.lehigh.edu) at Lehigh University, which is sponsored by the National Science Foundation and Pennsylvania Department of Community and Economic Development. REFERENCES [1] S. J. Lee, W. Su, and M.. Gerla, On demand multicast routing protocol, in Proceedings of IEEE WCNC 99, pp 1298-1303, September 1999. [2] L. Cheng, advertisement and discovery in mobile ad hoc networks, in Workshop on Ad hoc Communications and Collaboration in Ubiquitous Computing Environments, in conjunction with the ACM 2002 Conference on Computer Supported Cooperative Work, New Orleans, USA, November 16-20, 2002. [3] W. K. Edwards, Core Jini, Prentice Hall PTR, Upper Saddle River, NJ, USA, 2000. [4] J. Veizades, E. Guttman., C. Perkins, and S. Kaplan, location protocol, Request for Comments (RFC) 2165, Internet Engineering Task Force, June 1997. [5] S. Lee, W. Su, J. Hsu, M. Gerla, and R. Bagrodia, A performance comparison study of ad hoc wireless multicast protocols, in Proceedings of IEEE Infocom 2000, pp. 565 574, Tel-Aviv, Israel, March 2000. [6] S. Bajaj, L. Breslau, and D. Estrin, Improving simulation for network research, Technical Report 99-702, University of Southern California, Los Angeles, March, 1999. [7] D. B. Johnson, Validation of wireless and mobile network models and simulation, in Proceedings of the DARPA/NIST Workshop on Validation of Large-Scale Network Models and Simulation Fairfax, VA, May 1999. [8] J. G. Jetcheva and D. B. Johnson, Adaptive demand-driven multicast routing protocol (ADMR), Internet Draft, draft-jetcheva-manet-admr- 00.txt, work in progress, June 2001. GLOBECOM 2003-1027 - 0-7803-7974-8/03/$17.00 2003 IEEE