Mobile ad hoc networks (MANETs), unlike traditional networks, exhibit characteristics – such as mobility, flexibility and ease of deployment – that makes them suitable to become the paradigm on which the scientific community can rely to make pervasive communications and computing a reality. However, MANETs present some drawbacks that are unique to them and inherent to some of their features. First of all, MANETs use the wireless medium, which is error prone, and this makes communications unreliable. And secondly, their mobility grants them the ability to dynamically alter their network topology due to nodes changing position at their will and entering or leaving the network unexpectedly. These drawbacks pose challenges that are continuously addressed by the research community along with other problems that appear along the way.
In MANETs applications and services are not deployed onto a pre-existing network, but instead the network itself grows out of the applications and services according to the users’ needs, enabling the users to view the network in the manner most appropriate to them and their requirements. However, to be capable of doing this, devices need to know what services are available in the network and how and where to contact them. In traditional networks the strategies envisioned to tackle these challenges are known as service discovery mechanisms and they have successfully accomplished the task. Following this trend, similar strategies have been studied to accomplish the same task in MANETs, but it has become obvious that owing to MANETs’ special features those strategies cannot be satisfactorily applied to such environments. Therefore, service discovery mechanisms more distributed and resilient in nature are the focus of current research on this area.
Aspects of this research field include:
- Interoperability between devices with different capabilities and operating systems.
- Selection of the most suitable device to carry out a task.
- Task division and distribution over the network (network load balance and device suitability).
- Latency, overhead, resiliance and rate of success to contact services.
- Performance in terms of service repositories distribution (centralised, fully distributed, hybrid).
- Performance in terms of the policies to acquire server details (proactive, reactive, hybrid).
- Heavy weight vs. light weight service repositories.
This section of the Quality of Service Management Information Portal serves as a focal point for research related to service discovery in Mobile Ad Hoc Networks.
The main objective of a service discovery protocol (SDP) is to provide the network with the necessary tools to allow users to make use of services that are not available in their devices but that may be available in other devices within the network. Such services can represent hardware (e.g. cameras, printers, storage devices, etc), software (e.g. music/video on demand, an application to chat, a word processor, etc) or both (e.g. an application that takes a picture with a webcam attached to a computer, saves it into a jpg/gif/pdf file and sends it back to you). Following this trend it is clear that in a network some nodes offer services while other nodes use those services. On top of that, a SDP adds a third type of nodes which coordinate the way services are discovered. Thus, a node belonging to a network running a SDP can play any, all or none of the roles described below.
- Service Providers: devices/components hosting/managing a hardware or software service. Depending on the specific discovery protocol applied they are also known as Jini Services, Service Agents, Servers, etc.
- Clients: devices/components that employ a service offered by a service provider. They are also known as User Agents.
- Service Repositories: the core of a service discovery strategy. They are in charge of managing all the information about the services present in the network and the devices hosting them. Their tasks include accepting registrations of new services sent by service providers and replying to any requests for services sent by clients. Other names are Lookup Servers, Directory Agents, Service Brokers, etc.
A client application requires to know i) the location of the service and ii) how to use the service before contacting a service provider. Both data can be found through a Service Discovery Protocol. However, some approaches follow the model of a well known interface for every service. In this model, it is assumed that a client trying to contact a service knows its interface beforehand while the service location is still a responsibility of the SDP.
Service discovery protocols have played an important part in traditional networks by allowing applications to interact with other applications and hardware in a process that nowadays is taken for granted by users no matter whether they are in a small local area network or in the Internet. Some well known SDPs that have made this possible are Sun Microsystems’ Jini, Internet Engineering Task Force’s Service Location Protocol (IETF’ SLP), IBM’s Salutation Protocol, Microsoft’s Universal Plug and Play (UPnP) and Bluetooth Service Discovery Protocol (SDP). More recently, the research community has been working on the design of SDPs capable of offering high performance when deployed over MANETs realising the relevance they have to make pervasive communications and computing a reality. Whereas many SDPs for MANETs can be found in the literature, none has been widely adopted.
Service discovery protocols can be roughly categorised according to two criteria: i) their architecture, ii) the way clients acquire a service information.
According to their architecture SDPs are classified as:
- Centralised: A group of devices is selected to act as service repositories. A device having a service to offer must register it with the service repositories providing the type of service, attributes and how to locate the service (normally through the network address of the device where it is running). Later, when a client needs to use a service it queries to at least one service repository requesting information on a service matching its requirements. If more than a match is found the client chooses the most appropriate service provider.
- Distributed: A client in need of a service broadcasts or multicasts a query containing its requirements. Each service provider offering a service matching the query unicasts back a reply and the client selects the more appropriate service provider. Broadcasts are often limited to small areas to avoid network wide flooding which is an undesirable feature in any protocol. To accomplish this, parameters such as the TTL field in an IP header can be used.
- Hybrid: This architecture tries to blend the strengths of centralised and distributed approaches while getting rid of any weaknesses.
The list of journals, conferences and technical societies related to multicast communication does not mean to be exhaustive rather it is indicative. For additions/updates please contact the webmaster.