Service Naming and Discovery in Mobile Ad Hoc Networks
Károly Farkas*, Dan Grigoras**
*Computer Engineering and Networks Laboratory (TIK), ETH Zurich,
Gloriastrasse 35, CH-8092 Zurich, Switzerland Email: farkas@tik.ee.ethz.ch
**Computer Science Department, University College Cork,
Cork, Ireland Email: d.grigoras@cs.ucc.ie
Abstract
The increasing number and diversity of wireless mobile devices are driving a revolutionary change in the way users are accessing and using services and resources.
Mobile ad hoc networks (MANETs), temporarily created by mobile devices, offer opportunities for sharing services and resources made available by member nodes.
Consequently, the user of a device with limited resources can avail of the rich offer of services within the network it joined. To be effective, MANET applications need supporting services like name, discovery and routing services, adapted to the MANET features – mobility, heterogeneity, lack of support from the Internet, limited battery power etc. As the name service is a basic service, used by all applications, its effectiveness is of paramount importance to MANETs. In this paper, we discuss several proposals for the name service of MANET and the influence of this service on other services, particularly on the discovery service. Every solution has benefits and limits and, therefore, it is difficult to make a clear option at this stage. Our conclusion is that supporting services and protocols devised for MANETs should adapt in some form to the network characteristics.
1 Introduction
As more and more wireless-enabled mobile devices are on the market, the interest in designing mobile network applications is increasing. One basic service that needs to be revisited in the new context is the name service. Although it is very effective on wired networks in its actual form, it has no provisions for mobility.
In the wired Internet, the IP address/name mapping allows for both effective routing and easy to use addressing by names. The Domain Name Service (DNS) is invoked whenever a look up is needed. For example, when a browser-client wants to contact http://www.ucc.ie, the name part of the URL is looked up by the DNS and the IP address of the server host, 143.239.1.60, is returned to the client. All the datagrams of the client will be routed to that IP address. The IP address of the host shows its logical location in the Internet – the sub-network to which it is connected.
A mobile host connected to an Access Point (AP) can still use DNS, as any other Internet service, by means like Mobile IP, or IP Paging. In either case, extending the IP concept to the one-hop mobile domain has the cost of more indirection (e.g., home and foreign agents are used) and it is error prone. Although, initially, Internet had no provision for mobility, the recent inclusion of the Mobile IP concept in IPv6 is an effort to fix the problem. Additionally, it manifests the interest to preserve the TCP/IP stack of protocols for the mobile domain as well.
A more complex architecture is that of mobile ad hoc networks (MANETs) where there is no link to the wired Internet and, consequently, no service support from that side of the Internet. Moreover, MANETs’ features like node mobility, heterogeneity, limited resources including battery power, feeble communication links, etc., increase the complexity of providing services to clients. Designers face the challenge of choosing either to deploy some form of (Mobile) IP for inter-operability purposes [1], or to devise a new naming scheme that would match MANETs’ features and users’
interests. Indeed, users of mobile devices are basically interested in accessing services available in their proximity (within the radio range of the device). The probability of finding services is even higher if multi-hop MANETs are present and can be joined.
When a mobile node temporarily joins an ad hoc network, the locations of surrounding devices have no relevance (anyway, they change) as long as services can be discovered and used. This fact is in contrast to IP-based networks, where servers (providers of services) are bound to IP addresses and routing is IP guided.
An important property of MANET is that due to mobility not only its topology changes dynamically, but also the shape and nodes membership. At any time, one MANET can split and/or more MANETs can merge. How can the network and node identities be preserved in these circumstances? If node identity is IP-based, its validity is questionable as the network identity changed. For example, when mobile networks merge, there are chances for duplicate IPs. Therefore, the merge event should trigger duplicate IPs detection, and this operation adds an important management overhead.
If a mobile network splits, communication becomes difficult, as nodes belonging to the same network (IPs with the same network prefix) should now use inter- networking routing. The only persistent information the node carries with it, irrespective of the current location and mobile ad hoc network it joins, regards the set of services it provides. This important fact can create a different perspective on the design and deployment of effective services in MANETs.
In the next section, we will review current name schemes. Then new ideas of more appropriate name schemes for MANETs will be discussed. The impact of the name service on another network service, the discovery one, will be considered next. And finally, we illustrate our ideas by a test case and give a conclusion.
2 Current Naming Schemes
Name systems in use by MANETs vary from the conventional IP/DNS to more radical approaches that focus on services description and use.
One simple approach for an IP-based MANET is Auto-configuration (Zero Configuration). Some nodes of the network run DHCP and DNS, providing any new node that joins the network an IP address from the link-local range. This way, the IP address can be used within that MANET. Even a simpler solution is by auto- configuration with an IP address from a (reserved) private IP addressing domain, where there is no DHCP available. Each node assigns itself an IP address and sends out a gratuitous ARP. If there is no conflict with existing nodes, it keeps that address.
All IP-based MANETs need means for detecting duplicate IPs. The current implementations of duplicate address detection (DAD) add even more overhead, spare power, which is a critical issue for limited-power mobile devices, and do not guarantee there will be no address conflict. Problems arise when the MANET network splits or merges with similar networks, or when nodes get connected to APs and try to communicate with correspondents. There is no provision that IP-based MANETs’
nodes have unique IPs and this is the receipt for disaster. However, not all MANETs are IP-based.
A typical example of MANET is a Bluetooth piconet [2]. A Bluetooth device is by default in standby state. To move to the connected state, it goes through the inquiry and page states. While in the page state, the master invites devices to join the piconet – it assigns a 3-bit address to a new node. Consequently, the maximum number of piconet members is eight. Though piconets can overlap and create larger MANETs called scatternets, the limit on the number of piconet’s members stands to eight.
A different approach is represented by the use of distributed hash tables (DHT) [3].
Introduced by the P2P community in different forms, the addressing of both information and nodes that store the information is based on a hash function applied to the information content or node ID, respectively. This way, the address/identity is location independent. The nodes share a virtual space, each being responsible for a part of it, according to the key produced by the hash function. The node stores information about the location of all data whose keys belong to its partition. The discovery process is facilitated by the use of the same hash function.
Recognising that for mobile applications, location is less important than service features, the INS/TWINE project introduced the Intentional Name System (INS) [4].
Here, a service name is a hierarchical arrangement of attribute-value (a-v) pairs, such that an a-v pair that is dependent on another one is a descendant of it.
Name descriptors have a representation that is used when they are included in a message header to describe the source and destination of the message. In addition to exact value matches, name descriptors also permit wild card matching of values.
However, the system’s architecture is an overlay network supported by an IP-based infrastructure.
3 Attribute-Value Based Naming Schemes
As in mobile ad hoc networks, the presence and availability of services is more important than host’s location, it makes sense to consider an alternative to the IP concept. In a natural way, the model of attribute-value service description is the best candidate. It offers the possibility of presenting the service profile, namely what it does, and its model, that is how the service works. Moreover, it may include
information about how the service can be accessed and used. Coded in XML, the description is flexible and both human and computer readable.
Examples of attribute-value based naming scheme are introduced in [5], [6]. The service-oriented name system [5] proposes a service name made of three categories of information, equally important. The first category defines the service profile and therefore is called “service” – see Figure 1 for the example of a projector service. It includes static information like the name of the service, its version, specific features like resolution and control, the service address URL for invoking the service via SOAP, and dynamic information like the nature of the service, public, private or group, its availability and time-to-live (TTL). The second category called “device”
includes all the attributes of the host, relevant to the service. These can be the manufacturer, device’s commercial ID, operating system, execution environment, port number, etc. Finally, the “owner” category may reduce to a name (can be of the user), as the attribute, and a universally unique identifier (UUID), as its corresponding value. The UUID can be extracted from the device own unique identifier (e.g., MAC address) or any other universally unique number and can be used for several purposes.
One of them is to allow for private MANET formation. Indeed, all devices belonging to the same user can create a private network that is not accessible to outsiders. The same UUID can be used to create the MANET’s network ID, when the node is the creator of the MANET, and allow for inter-MANET routing. If necessary, the same UUID can be used to create a temporary IP.
The service name is of variable length and adapted to express the service features.
The search message will include the XML description of the service.
<service> projector
<version>1.2</version>
<control>wireless</control>
<resolution>XGA</resolution>
<nature>public</nature>
<availability>yes</availability>
<time_to_live>499</time_to_live>
</service>
<device>company_X</device>
<market>WP-X444</market>
<owner>990-1881-8771-1146</owner>
Fig.1. The XML Description of a Projector Service
SIRAMON [6] assumes that each node has a unique address (identifier) by which it will be known in the ad hoc network. Services are designated as leafs of a hierarchical service identifier tree. The hierarchy of the tree can be adapted to the respective application(s). Figure 2 depicts a sample service tree. In this tree, service categories and specific services (ellipses indicate service categories while specific services are denoted by boxes) are distinguished. A service category represents a class of specific services but does not specify any real service itself. A specific service is a real service or application that can be used by service users.
Fig. 2. Sample Hierarchical Service Identifier Tree in SIRAMON
SIRAMON uses URIs (Uniform Resource Identifiers) to name or label services. A URI is built of the scheme’s name (e.g., siramon) and the hierarchical part of the service identifier. The slash ‘/’ character is used to separate the hierarchical components, thus the definition of the SIRAMON URI syntax is the following:
absolute_URI = scheme ‘:’ hier_part
hier_part = ‘//’ authority ‘/’ path_segments ‘/’ local_name
After this, a game service (e.g., DeathMatch) can be addressed by the following URI:
siramon://Service/Entertainment/Games/Multiplayer/RealTime/
DeathMatch
4 Service Discovery
The adopted name system has an important influence on other network services like discovery of services and routing. In an IP-based network, servers, including service directories, are bound to IP addresses. First of all, clients need to discover the location of such a service and, then, all queries will be directed to the respective address, by IP datagrams. Currently, Internet is using the Domain Name System.
DNS names are called domain names as their structure represents their position in a hierarchic name space. For example, star.cs.ucc.ie is the name of a computer of the cs sub-domain that belongs to the ucc sub-domain, which belongs to the ie domain. The Internet name service, DNS, is provided by a hierarchy of servers that delegate parts of the name space to local servers. Robustness and adequate performance are achieved through replication and caching. The system architecture is client-server:
any process that needs a lookup addresses the local DNS server as a client. If the look up cannot be solved locally, the local DNS server acts like a client to a root DNS server.
In contrast to the client-server model, the appropriate computing model of MANETs is Peer-to-Peer (P2P), as hosts contact each other while on the move. The transitory nature of information and hosts in a certain area makes irrelevant the presence of a server devoted to the name service (i.e. directory server of advertised services, or a name server) within a MANET. Either the device running the server leaves the area or becomes unavailable, or its data is outdated.
If an attribute-value name scheme is used, each device stores the names of its services and the lookup is replaced by search. The search itself is executed by each host as a full or partial matching operation of the service name of interest and names of local services. If there is a match, the service is found and its description (set of attribute- value pairs) is sent to the requestor.
Therefore, the simplest approach is to let each device manage the service directory for all its public/private services, and advertise it or answer to service requests. To speed up the search process, service directories can be duplicated and stored by volunteer hosts, in their caches. However, the cached information is just an indication of possible available services but provides no guarantee.
In the case of the service-oriented name system, when a client looks for a service, it broadcasts a query message that includes the description of the service – full or partial. Each node that receives the request will compare the description with those of local services. Any match will trigger a reply.
SIRAMON provides two ways for service discovery. If a device hosts a service it registers this service in its local service registry and after joining the ad hoc network it can advertise this service to the other devices of the network using intelligent broadcast mechanism. On the other hand, devices in the network can lookup services they are interested in using broadcast to send out the lookup request message and using direct communication to deliver the reply from the service host device. After this, the URIs are mapped to the discovered device identifier and the mapping is cached in the local service registry. By using URIs, partial matching of the service identifiers is possible making service discovery more powerful and universal. For example, if an application looks for multiplayer games (‘.../Games/Multiplayer’) using partial matching, it will receive replies with service descriptions that match exactly the requested URI, as well as replies that match for more general services (e.g., ‘.../Games’).
Konark [8] is another protocol, specifically designed for service discovery and delivery of device independent services in self-organized networks. Konark is based
on a P2P model with each participating device having the capabilities to host its local services, deliver these services using a resident micro-HTTP server, query the network for available services offered by others, and use the services it discovered in the network.
Konark assumes an IP level connectivity among devices of the ad hoc network over any wireless link like IEEE 802.11 or Bluetooth. In the absence of the administrative services, these devices obtain an IP address by automatic configuration mechanisms (e.g., using Zero Configuration). All these devices join a locally scoped multicast group for Konark – a multicast address out of link-local range 239.255.0.0/16. Each Konark device has an SDP (Service Discovery Protocol) Manager that is central to the service discovery mechanism. It discovers the required services on behalf of Konark applications, and also registers and advertises the device’s local services. Figure 3 depicts the Konark device model. The SDP Manager interacts with the messaging layer to send and receive the discovery and advertisement messages, which is built above the transport layer.
Fig. 3. Konark Device Model
To discover services in the network, clients use a discovery process known as the active pull mechanism. Servers use an advertisement process to periodically announce their registered services. This mechanism is termed as passive push. Konark supports both push and pull mechanisms, so that both clients and servers can discover and advertise services on a need basis. When a client wants to look up a service, it sends out a discovery message on a fixed multicast group. It contains the service name and related attributes using the hierarchical service tree approach discussed in the case of SIRAMON. After receiving a discovery message, each server node performs service matching. If the server finds a match, it creates a service advertisement message.
Service delivery primarily involves communication between an application client and the micro-HTTP server of the service provider node. Once a service has been discovered by a client device, the client has very limited knowledge about the service.
It only knows the user-friendly name of the service, service type, the IP address and
the duration of availability of the service. Then, the client device can follow the URL obtained during the discovery phase to access the XML-based service description.
The service description file contains complete information about the properties of the service and the methods provided by the service. The user can interact with the service by invoking any of the available functions with proper parameters. The user function invocation is packaged as a SOAP request and sent to the micro-HTTP server.
The distributed service discovery architecture [9] relies on a virtual backbone for locating and registering available services within a dynamic network topology. It consists of two independent mechanisms: the formation of a virtual backbone which includes the nodes acting as service brokers; and the distribution of service registrations, requests and replies which establishes sub-trees rooted at service requesting devices and registers servers for efficient dissemination of the service discovery messages.
The first mechanism is called BBM – BackBone Management. The goal of the BBM algorithm is to obtain a small size (not necessarily minimum size) and relatively stable backbone. The algorithm is highly distributed and based on local decisions which makes it fast to react back to the changes in the network topology. The BBM algorithm has three components: (i) initial selection of backbone nodes, (ii) mesh formation by finding the paths between backbone nodes, (iii) and maintenance against topology changes. All the components rely on the periodically broadcasted hello beacons. BBM selects a subset of the network nodes to form a relatively stable dominating set, a dynamic virtual backbone, below the routing layer such that each node in the network is either part of the backbone or one hop away from at least one of the backbone nodes. Service broker nodes are co-located with the backbone nodes and each non-backbone node is associated with at least one service broker node. Then BBM discovers the paths between dominating nodes and adapts to the topology changes by adding or removing network nodes into this dominating set. After the BBM phase is successfully carried out, a virtual backbone is established that constitutes a mesh structure with the backbone nodes and the virtual links connecting them.
The second mechanism is called DSD – Distributed Service Discovery. DSD is used to efficiently distribute the request and registration messages from the service discovery agents running on any nodes to the directory agents running on the backbone nodes. These messages assist in forming multicast trees rooted at client and server nodes on top of the backbone mesh. Reverse paths in these multicast trees are used for reply messages. When a server located on a node wants to register its service, it has to register with the directory agent associated with the node (i.e., with the closest backbone node’s directory agent). Then, this directory agent distributes the registration messages to the other directory agents located on the other backbone nodes using multicast mechanism. When a client wants to look up a service, it has to consult with its associated directory agent (i.e. the closest backbone node’s agent) that can be found maximum one hop away from the client. This makes service lookup fast and efficient.
Magnetic Routing [10] is an interesting technique for service discovery in MANETs.
In this approach, a service is modeled by a (positive) point charge, and service request
packets are seen as (negative) test charges that are attracted by the service instances and thus are routed automatically in the network. This physical field model is mapped to a mobile ad hoc network in a way where each network element calculates a potential value in respect of a service and routes service requests towards the neighbor with the highest potential, hence towards a service instance.
In Magnetic Routing, every node is assumed to participate in the service discovery process. When a service appears in the network, it advertises itself by using broadcast.
Intermediate nodes store and exchange information about offered services given from service hosts. The discovery process is then initiated from a client by sending out a query message that specifies the desired service type. Such a query is forwarded towards a service instance matching the service type specified in the query. When a discovery message arrives at the service instance, the service sends back a reply to the client. If multiple service instances of the same type exist, the service instance discovered by the client is not arbitrary. The discovery system “selects”, on behalf of the requesting client, a service instance based on two metrics, the network distance (number of hops) between client and service instance and the capacity of service (CoS). For example, the CoS of an Internet gateway service may indicate the link capacity of its Internet connection. In the same way, the CoS for a printer can be used to indicate the print speed. Alternatively, the CoS can be used to express an average load to perform load balancing.
Fig. 4. Service Discovery with Potentials in Magnetic Routing
Magnetic Routing is inspired from the physics, specifically of test charges in an electric field, considering the selection of a service and thus determine how to forward service queries. The service selection algorithm is distributed and does not involve interaction with the client. Any negative test charge moves along the field’s flux line towards a positive charge. The direction of the flux line is determined by evaluating the gradient of the field. Thus, to draw the analogy, a query is associated with a negative test charge and the capacity of a service instance (CoS) with a positive point charge that creates a field. Figure 4 shows a simple example with two service instances and one client. In this example, the resulting potential from the two charges at the service instances is used to deliver a query from a client to a service. Since both services have the same charge, the query is delivered to the closer service on the left side.
5 A Multiplayer Test Case
SIRAMON has a Java-based prototype implementation running in a mobile ad hoc testbed network. The testbed consists of 5 laptops and 5 PDAs (HP iPaq). Each device is running Linux operating system, is equipped with IEEE 802.11b wireless network interface and using mobile mesh ad hoc routing protocol for packet forwarding.
Moreover, a real-time multiplayer game called Rolf’s Blast is implemented as a test application. A player can ramble in a labyrinth and shoot other players (see Figure 5).
The score of a player is increased by one for each other player it shoots down, and decreased by one each time it was hit by another player (the score cannot become negative). The goal of the game is to have the highest score among the players, thus shoot as many other players as possible and avoid being shot by others. Rolf’s Blast has a server/client-based game architecture which is very error prone in a dynamic ad hoc environment thus it requires intensive support from SIRAMON.
Fig. 5. Rolf’s Blast
SIRAMON gives support in several steps to make use of the game application. First, it handles the advertisement and lookup of the game’s service and session descriptions. Then, SIRAMON tries, according to the service description, to discover a corresponding session in the network and then either starts a new game client with the discovered session information, or establishes a new session by instantiating a game server before the game client is deployed. If several game servers are available, SIRAMON selects an appropriate one to which the game client will be connected.
The game servers will inquire the framework about the availability of the other servers and adapt the session information of the game accordingly. Thereby, the session description is updated each time a new server is deployed or a running server disappears. Furthermore, SIRAMON advertises this information in the network, such
that the other game instances can be adapted accordingly. And finally, each time the game observes that only one server is available, SIRAMON starts to deploy a redundant server if possible. Thus, SIRAMON deploys autonomously the new server on an appropriate node in the network.
6 Conclusions
Although structured networking environments are becoming more and more pervasive, there will always exist situations where devices need to communicate in the absence of any pre-established networking infrastructure – they will create mobile ad hoc networks. Mobile ad hoc networks are useful self-organizing systems as their aggregate offer of services and resources is much larger than that of any individual device. But, to avail of these services, the networks middleware should consist of effective supporting services. One of them is the name service that, in its IP address/name form, does not match the network features. Indeed, IP addressing represents an unnecessary level of indirection and its management is too demanding in terms of resources – bandwidth, battery power. For this reason, new approaches based on a natural description of services, are investigated. The attribute-value model has the benefit of describing exactly what is available. The client will search for the service, using its name, and not for a location (IP address) totally irrelevant in the mobile context. However, the new model raises the question of routing that currently is IP based. For these reasons, we consider the problem of the name service for MANETs an open question of high importance. Its resolution will have an impact on other services, like discovery and routing.
References
[1] Y-C Tseng, C-C Shen and W-T Chen, “Integrating Mobile IP with ad hoc networks”, IEEE Computer, May 2003, pp. 48-55.
[2] B. Miller and C. Bisdikian, Bluetooth Revealed, Prentice Hall, 2002.
[3] A. Viana, M. Dias de Amorim, S. Fdida and J. Ferreira de Rezende, “Self- organization in spontaneous networks: the approach of DHT-based routing protocols”, Ad Hoc Networks Journal, Febr. 2005.[4] W. Adjie-Winoto, E.
Schwartz, H. Blakrishnan and J. Lilley, “The design and implementation of an intentional naming system”, Operating Systems Review, 34(5), Dec 1999, p.186- 201.
[5] D. Grigoras, “Service -oriented Naming Scheme for Wireless Ad Hoc Networks” , in Proceedings of the NATO ARW “Concurrent Information Processing and Computing”, July 3-10 2003, Sinaia, Romania, IOS Press 2005, pp. 60-73.
[6] K. Farkas, L. Ruf, M. May and B. Plattner, “Framework for Service Provisioning in Mobile Ad Hoc Networks”, In Proceedings of the First International Conference on Telecommunications and Computer Networks, (IADAT-tcn2004), San Sebastian, Spain, December 2004.
[7] M. Balazinska, H. Balakrishnan and D. Karger, “INS/Twine: a scalable peer-to- peer architecture for intentional resource discovery”, In Proceedings of the Pervasive 2002 – International Conference on Pervasive Computing, Zurich, Switzerland, August 2002.
[8] S. Helal, N. Desai, V. Verma and C. Lee, “Konark – A Service Discovery and Delivery Protocol for Ad-hoc Networks”, In Proceedings of the Third IEEE Conference on Wireless Communication Networks (WCNC), New Orleans, USA, March 2003.
[9] U. C. Kozat and L. Tassiulas, “Network Layer Support for Service Discovery in Mobile Ad Hoc Networks”, In Proceedings of the IEEE INFOCOM, San Francisco, USA, April 2003.
[10] V. Lenders, M. May and B. Plattner, “Service Discovery in Mobile Ad Hoc Networks: A Field Theoretic Approach”, To appear in the IEEE International Symposium on a World of Wireless, Mobile and Multimedia Networks (WoWMoM), Taormina, Italy, June 2005.
