(If you use this implementation in any research/thesis work, please do let me
know by sending an email at the address mentioned below.)

SERVICE DISCOVERY IN MOBILE AD-HOC NETWORKS WITH AODV AS ROUTING PROTOCOL

Abstract
--------

This is a modification of original aodv implementation of ns-2.26 to include
service discovery. The implementation is based on IETF's
draft-koodli-manet-servicediscovery-00.txt.

There can be mobile nodes in an ad-hoc network offering various services like
printing, nameservice, smtp etc. Whenever some othe node wishes to access these
services, it needs to start a service discovery. Appropriate node(s) reply back
to such queries.

Installation
------------

Make sure you have ns installed on your system. This implementaion has been
built and tested in ns-2.26. I am not sure if it will work with previous/other
versions of ns.

Follow these steps to install :
1. Go to ns directory and move original source code in directory 'aodv' to some
other place for back-up.
2. Unzip aodv-svc-disc.tar.gz in ns/aodv/
3. Issue 'make clean' followed by 'make' command with your current directory as
ns/
(NB. Doing a 'make' without 'make clean' is also known to work but it may have
some unforeseen effects on working of ns in other areas.)

Writing Scripts
---------------

(See sample scripts provided for more information.)

	For binding service to a node

		1. Get handle to routing agent of that node
			set ra [set $node_(0) ragent_]

		2. Bind service to that node by issuing svc-bind command. eg if one wants to
		   bind smtp service
			$ns_ at 0.1 "$ra_ svc-bind 25 smtp"	#where 25 is the port number
			and smtp is the service string

	For discovering service

		1. Get handle to routing agent of the node
			set ra1 ]set $node_(1) ragent_]

		2. For discovering a service by port issue "svc-disc-port" command
			$ns_ at 2.4 "$ra1 svc-disc-port 25"	#discover service at port no, 25

		3. For discovering a service by service string (name), issue "svc-disc-string"
		   command
			$ns_ at 3.0 "$ra1 svc-disc-string smtp"	#discover service named smtp

One can see tracefile or use 'nam' to verify exchange of requests and replies.

Caveats and Assumptions
-----------------------

Following assumptions have been made while implementing service discovery
extension in AODV.

1. Each service has an associated port number and a service string/name.

2. Every node that receives a SREQ (Service Request extension) or SREP (Service
Request extension) processes it. If it receives a reply and has not got that
binding in its cache or it receives ``better" binding, adds it to its cache.
``Better" route is determined on the basis of number of hops to the service
provider and lifetime of service binding, in that order.

3. Service predicate in SREP URL extension is only used to carry port number (if
possible) and not other predicates like user name etc. (which would depend on
actual application starting discovery)

4. Underlying routing protocol discovers and maintains routes.

5. If a node has a service binding but an expired route to the service provider,
it broadcasts an SREQ URL extension, even if it got SREQ port extension. This is
done so that an intermediate node that has a route to the service provider but
no knowledge of service binding can also reply back with SREP.

6. Fields #URL auth. and URL auth. blocks in SREP are not used.

7. Default service binding time is 10 sec. This is the lifetime for which nodes
receiving SREP will have a valid service binding.

8. Broadcast timer (which gets triggered every 6 sec) is used for purging out
stale service bindings.

9. Each node waits for 5 sec after initiating service discovery. It reports a
failure if it is not able to find any relevant service binding within this
period.

Acknowledgement
---------------

Thanks to Prof. Manish Singh, under whose guidance this project was successfully
carried out.

About Author
------------

I am a 2nd semseter student of M.Tech - Wireless Communication and Computing
from Indian Institute of Information Technology, Allahabad, India. Please send
bug reports, suggestions and queries at the following address :

	sandy@iiita.ac.in

- SANDEEP GUPTA, May 2003
