- Email: [email protected]
Middleware support for service discovery in special operations mobile ad hoc networks
ARTICLE IN PRESS Journal of Network and Computer Applications 33 (2010) 611–619
Contents lists available at ScienceDirect
Journal of Network and Computer Applications journal homepage: www.elsevier.com/locate/jnca
Middleware support for service discovery in special operations mobile ad hoc networks Yasser Gadallah n, Mohamed Adel Serhani, Nader Mohamed College of Information Technology, UAE University, P.O. Box 17551, Al Ain, UAE
a r t i c l e in fo
abstract
Article history: Received 1 November 2009 Received in revised form 16 February 2010 Accepted 18 March 2010
Technology can play a significant role in the management and coordination activities of special operations such as emergency response, military combat missions, forest firefighting, etc. Mobile ad hoc networks (MANETs) can be used quite effectively to manage resource sharing in such operations due to their flexibility and ease of establishment. The concept of service discovery has some appealing characteristics and features that can be adopted and adapted for the nature and needs of these applications. In this study, we present the middleware architecture of a service discovery and allocation system that we propose for the applications of special operations. The main purpose of the proposed system is to locate, reserve and assign a certain service to the party that is in need of this service, with little or no human intervention. The concerned service could be medics, equipment, ambulances, etc. The network participants are divided into service providers, service requestors and anchor nodes. The anchor nodes are the ones which are used to manage resource discovery and allocation. The proposed middleware takes into consideration the classification of these network nodes on the basis of their function. Based on the classification of a certain node, only the middleware modules relevant to its function are activated. We describe the design of this middleware in detail. We also experiment with the proposed technique and present some results that show its capabilities from different performance perspectives. & 2010 Elsevier Ltd. All rights reserved.
Keywords: Emergency response Mobile ad hoc networks Middleware Service discovery
1. Introduction Emergency response and similar special operations may potentially involve the use of many resources such as personnel and equipment. These operations therefore require accurate and continuous coordination among operations’ participants. Examples of these operations include forest firefighting, earthquake disaster recovery, coordinated military combat missions, etc. The use of technology can facilitate the goal of achieving optimal, or close to optimal resource management and allocation in such operations. Specifically, the use of mobile ad hoc networks (MANETs) for locating, managing and allocating resources can prove invaluable. Mobile ad hoc networks are usually used in networking applications where infrastructure networks cannot be accessed or are expensive to establish. MANETs have the advantage of the possibility of being established hastily with the use of simple communication devices. The use of a MANET based automated system to coordinate operations can provide a level of efficiency, speed and ease that is difficult to achieve through the use of human coordination alone.
n
Corresponding author. E-mail addresses: [email protected] (Y. Gadallah), [email protected] (M. Adel Serhani), [email protected] (N. Mohamed). 1084-8045/$ - see front matter & 2010 Elsevier Ltd. All rights reserved. doi:10.1016/j.jnca.2010.03.009
The concept of service discovery is traditionally used to locate web services that are needed by network clients. There have been many studies that dealt with traditional service discovery in MANET (Mian et al., 2009). These studies have mainly addressed the discovery of electronic-type services that are provided on specific nodes within the network. A service of this type can normally be provided to several requestors simultaneously based on the bandwidth and capabilities of the service provider. In this study, we adapt the concept of service discovery to emergency response operations using MANETs. In such operations, there are normally two classes of scenario participants; providers of services and requestors of these services. Examples are medics who provide a variety of medical services to injured or distressed persons. Medics are considered ‘‘service providers’’ while victims are considered ‘‘service requestors’’, according to this notion. The concept of service discovery within MANET can therefore be applied, after making some necessary adaptations, for use in such situations. The adapted service discovery scheme that we propose in this study differs from the traditional service discovery concept in the following main aspects: 1. The service providers have to physically move to the location of the service requestors in order to provide their services. 2. A service provider can generally serve one and only one service requestor at any point of time.
ARTICLE IN PRESS 612
Y. Gadallah et al. / Journal of Network and Computer Applications 33 (2010) 611–619
3. Each time a specific provider is used after it has completed a certain mission, a new discovery needs to be launched in order to locate it. This is due to the fact that keeping localization information about mission-dependent physically moving providers is not useful for future uses. The main goal of this study is therefore to design a middleware architecture that can be used for the purpose of finding and allocating service providers in such environments. We target a configuration that is composed of simple network devices such as PDA’s, which are used by personnel who are participating within the network. In such environments there are several challenges to deal with such as scalability with the potentially large number of requests and system interactions. There is also the need for realtime resolution of client requests as failure to do so could be lifethreatening in some cases. The heterogeneous environment that is expected due to the variety of network participants and the different roles they assume also places requirements on the architecture, e.g. to accommodate the different functions. The middleware solution that we propose addresses the above issues as follows. We establish a network arrangement where the operations area is divided into several geographical zones. The size and number of zones are determined based on operational requirements, i.e. application-dependent. In each zone, there is a central node, which we term an anchor node, whose only function is to coordinate the service discovery and resource allocation operations in its zone. The middleware architecture can therefore scale well with the size of the network and the number of requests within this network. It also requires minimal or no operator intervention as the request resolution is done in an automated manner hence providing high levels of speed and accuracy. This middleware is also nodedependent, i.e. module activation within the structure depends on the function of the node that it resides on. There are three types of nodes that are involved in the interactions within the proposed scheme:
capabilities, e.g. GPS. The operations area is divided into several zones. Within each zone, a generally stationary high-capability device, which is called an anchor throughput this study, is used to coordinate the service providing operation within each zone (i.e. intra-zone) as well as between the different zones (i.e. interzone). All these devices combined can thus form a mobile ad hoc network. The network members are service providers, service requestors or anchors. The service in this case can be defined as any help needed while the operation is going on. In case of emergency response operations, the examples of these services could include medics, equipment, ambulance services, emergency workers, etc. Using the communication devices, also called network nodes throughput this study, a service (e.g. a medical doctor) can be requested via communicating the required service specifics to the anchor nodes. Service specifics are pre-determined parameters that characterize each type of available services within the network. Service providers receive the assignments from the anchor nodes on their devices as well. Fig. 1 gives an illustration of the network layout. When a node within a certain zone needs to obtain some service, it communicates its need to the anchor node of its zone. Then the anchor node has the responsibility of locating and assigning the proper service provider to the requesting node based on the parameters of the request. If a new node joins the network or a node moves into a new zone, it can determine the anchor node of this zone via issuing a query to other nodes within its communication range. If no service provider is available within a certain zone to satisfy a request within this zone, the anchor of the zone communicates with the anchors of the other zones in order to request a provider that may be available in their zones, for the request at hand.
3. Related work
The service provider nodes: are the devices carried by the
different emergency personnel who can provide one or more types of service such as different kinds of medical services, rescue workers, etc. The service requestor nodes: are the ones that are carried by personnel who are the care takers associated with the victims or the parties who require a certain type of service. The anchor nodes: these nodes are at the center of the operation. They are computationally powerful communication devices and are established, preferably, at the middle of each zone of the operations area in order to coordinate the service discovery and dissemination within their zone. These nodes are considered to be command centers for the operation. It is also the responsibility of the anchor node to communicate and coordinate with other zones’ anchor nodes for the different aspects of the overall operation, as will be explained later.
The remainder of this paper is organized as follows. In Section 2, we give an example to illustrate the environment that we target in this study. In Section 3, we discuss some related studies. In Section 4, we give the detailed design of the system. In Section 5, we present some evaluation results. In Section 6, we conclude the study.
2. Illustrative scenario We consider a scenario where we have an emergency or military operation of which personnel are deployed over a certain geographical area. Each person carries a lightweight hand held communications device that has limited wireless range and computational resources. Each device has location determination
There have been a number of studies that aimed at providing technological support to emergency response efforts. In Kanchanasut et al. (2007), a long-distance multimedia wireless mesh network for collaborative disaster emergency responses is proposed. The study has focused on developing a system for the purpose of enabling multimedia communication under the effects of limited network bandwidths and high network latencies in the event of a complete destruction of the wired network infrastructure by a disaster. In Bottazzi et al. (2006), the authors proposed a context-aware middleware, termed ACAPE, to provide outdoor emergency assistance to elderly people. This middleware helps manage the assistance teams in terms of creating the team and supporting the team members’ interactions for anytime and anywhere emergency assistance. The communication environment considered in here is based on MANET. In Liu (2004), an agent-based resource discovery architecture for environmental emergency management was proposed. In this environment, agents cooperate to respond to environmental emergency situations. These agents are used for monitoring the environment, for simulating and analyzing the environment and for knowledge management using Petri nets. In Catarci et al. (2008), a pervasive software environment for supporting disaster response is discussed. This system consists of two layers: frontend and back-end. The front-end layer is represented by teams of first responders, e.g. police and fire departments, carrying PDA devices. The back-end layer is an integrated peer-to-peer network that lets front-end teams collaborate and exchange information. Back-end centers communicate directly with the team leaders at the front-end while team members communicate through a MANET.
ARTICLE IN PRESS Y. Gadallah et al. / Journal of Network and Computer Applications 33 (2010) 611–619
613
Fig. 1. Emergency response scenario layout.
Different middleware approaches were proposed to solve some of the issues that are encountered during the use of MANETs in emergency response applications (Hadim et al., 2006; Meier and Cahill, 2002; Musolesi et al., 2005; Bisignano et al., 2003; G€orgen et al., 2004; Murphy et al., May 2001; Herrmann, 2003; Levis and Culler, 2002; Benssam et al., 2007). Of particular interest to this study is the concept of service discovery which can be implemented as part of the middleware for MANETs. There are many studies that addressed service discovery in MANET, e.g. Cheng and Marsic (2000), Chakraborty et al. (2002), Ratsimor et al. (2002), Helal et al. (2003), Klein et al. (2003), Klein et al. (2003), Kozat and Tassiulas (2003), Zhu et al. (2003), Varshavsky et al. (2005), Tyan and Mahmoud (2004), Lenders et al. (2005), Chakraborty et al. (2006) and Engelstad et al. (2006). These studies present different approaches that are related to different service discovery aspects such as: service description, service registration, service discovery, routing and mobility support (Mian et al., 2009). A considerable number of these works have used the XML language for service descriptions such as in Chakraborty et al. (2002) and Helal et al. (2003). However, the use of XML is a rather heavy-handed approach in an environment where bandwidth is limited. Service registration is a process that is used to make services available and known to service requestors. This is done through registering the services by the providers at specified service registries. Registering a service requires providing information about the expiration time of the service and the distance, in hops, of the service provider. This information is stored either in directories in some network nodes or in the local caches of the service providers themselves. However, there is no third party authority that can manage the registration process and keep track of any update/removal of registered services. Concerning service discovery, the above studies focused mainly on the processes of search and selection of services. A service requestor can search for specific service requirements, where multiple service providers that satisfy these requirements may exist. The goal of the selection process is to determine a suitable service provider from this list. Most of
discovery approaches rely on the client to select the appropriate service or delegate the discovery process to a centralized entity that does the discovery on behalf of the client who might lack expertise and knowledge to make the discovery decision. Collaborating between different third parties in discovering services for the clients will definitely improve the discovery success. Our study is different from the above studies in the fact that it proposes a MANET-based middleware that supports scalable and automated resource discovery, management and allocation in special operations such as emergency response and military combat missions. It uses the abstract concept of service discovery after adapting it to suit the nature and needs of this environment. It ensures a seamless operation in which resources are located on the basis of service attributes, and allocated on the basis of a bestmatch policy. While doing so, cooperation between command centers supports the discovery and transfer of resources from one zone to another in the event of resource shortages in the zone of need. Lightweight messaging is used in all communications, which accommodates the nature of the environment where bandwidth is limited due to the limited capabilities of the involved devices.
4. Detailed middleware architectural description The middleware that we propose in this study has several modules that support the different aspects of the functionality, depending on the type of the network node that hosts the middleware. There are several communication modes that support the required interactions including the intra-zone, inter-zone and modular communications. In the following, we present the detailed middleware architecture and discuss the interactions at the different communication levels. 4.1. Architecture overview The proposed service discovery and allocation scheme spans three modes of operation of network participants as represented
ARTICLE IN PRESS 614
Y. Gadallah et al. / Journal of Network and Computer Applications 33 (2010) 611–619
by anchor nodes, service requestor nodes and service provider nodes. Depending on the mode of operation, the relevant middleware modules are activated. Fig. 2 shows the middleware structure for the different types of network participants. There are three modes of communications according to this architecture:
communication protocols that are needed by the system, e.g. the underlying MAC protocol as well as the networking protocol. It can therefore accommodate any set of protocols that are suitable for the purpose of this application. The details of these protocols are implementation specific and are beyond the scope of this study.
Intra-zone communications: this mode of communications
As shown in Fig. 2, the main modules of the middleware are: the anchor advertisement (AD) module, the service discovery (SD) module, the service advertisement (SA) module, the service reservation (SR) module, the anchor-to-anchor coordination module and the communication module. In the following sections, we discuss the above modes of communications as well as the involved modules in detail. 4.2. Intra-zone communications Intra-zone communications include the interactions among nodes within the same zone. These interactions occur among the corresponding modules at the different node types, depending on the purpose of the communication. In the following, we describe the different module types involved in intra-zone communications including their functionality and interactions. 4.2.1. Communication module This module is included in the middleware structure of all network node types. It is the module through which all external communications in both directions are made. Therefore, any module that needs to communicate with the corresponding module on any other node has to do so through the communication module. The communication module implements the set of
Anchor, Zone x
Anchor, Zone y
Communication Module
Service Reservation Module
Service Advertiseme nt Module
Service Discovery Module
Service Provider, Zone x
Anchor-toAnchor Coordinatio n Module
Service Reservation Module
Service Reservation Module
Service Advertiseme nt Module
Service Advertiseme nt Module
Anchor AD
Anchor AD
Service Discovery Module
Anchor AD
Intra-zone Comm.
Service Discovery Module
Service Requestor, Zone x
Inter-zone Comm.
Module Interaction
Fig. 2. Middleware structure for interactions within the proposed service discovery scheme.
Communication Module
Communication Module
Anchor-toAnchor Coordinatio n Module
4.2.3. Service advertisement (SA) module When a service provider becomes available for providing services to requestors, it advertises its availability to the anchor node. This situation is encountered at network initialization, when a new provider joins the network and upon completing a service mission that was previously assigned to a service provider. It is expected that a provider node would only move to serve a requestor, or to return to its base. For example, we would not expect a heavy piece of equipment that it used to remove rubble from an area to rescue a trapped person to be moving around constantly; it would only move to execute a mission or to return back to its base. To announce its availability, the service provider composes an SA message using its SA module. The message gets sent out through the communication module. When this message is sent by the provider for the first time (i.e. at network initialization or when a new provider joins the network), it includes the attributes of this service provider. For any subsequent SA communications, the provider only sends a shorter message announcing its availability without including its attributes to save energy and communication bandwidth, unless any
Comm. Mod.
4.2.2. Anchor advertisement (AD) module This module is included in the middleware structure of all network node types. Upon network initialization, the anchor node of a specific zone announces its presence to all zone nodes. The anchor advertisement module of the anchor node creates the announcement message and includes the attributes of the anchor node and specifically those required to communicate with it such as its address. This message gets passed to the communication module where its gets broadcast to all nodes within the zone. This message gets also broadcast periodically to inform zone nodes of the continued availability of this anchor node. At the receiving end, the AD module of each receiving node processes the AD messages from the anchor and stores its attributes in order to use them later to communicate with the anchor node.
Anchor AD
handles the communications between the corresponding modules in the different nodes that operate within the same zone. As an example, the service discovery communications between the anchor and the service requestor nodes. Inter-zone communications: this mode of communications deals with the communications between two anchor nodes. It therefore handles the communications between two different zones of the operation. Modular communications: this mode organizes the message exchanges between the different middleware modules within a certain node.
ARTICLE IN PRESS Y. Gadallah et al. / Journal of Network and Computer Applications 33 (2010) 611–619
change of the attributes has occurred since the last time it has sent an SA message. When this SA message is received by the communication module of the anchor node, it gets passed to its SA module. The SA module then marks this provider available in the ‘‘service providers’’ table. The service provider table is the table that includes service providers’ information for this zone. It includes the provider’s address, position, attributes and availability status. If there is any change in the attributes of the provider, this information gets updated in the service providers table. 4.2.4. Service discovery (SD) module When there is a need for a certain service such as a medic or a piece of equipment in a particular zone, the SD module of the service requestor creates the service discovery request in which the specifics of service are specified with the required service parameters. This request is then communicated to the anchor of the zone in which this requestor currently exists. For this to occur, the created message gets transmitted internally within the requestor node from the SD module to the communication module, which invokes the services of the networking services in use. The networking services transmit the message, possibly in a multi-hop communication, until it reaches the anchor node of the same zone. The message gets received by the communication module of the anchor node which passes it to the SD module. The SD module then checks the service providers table for the available providers that have attributes that match the requirements of the required service. If one or more providers with matching attributes are found, the SD module calls the services of the service reservation (SR) module to reserve the best matching service provider as indicated in Section 4.2.5. If no suitable provider is found in the table, the anchor node sends an SD multicast message to its peer anchors as indicated in Section 4.3.2. 4.2.5. Service reservation (SR) module The service reservation module has an important role. It makes the calculations and hence the service provider selection decision in case there are more than one provider available to service a certain request, as we discuss shortly. The separation between the SD and SR modules helps realize the benefits of the modular architecture, e.g. ease of upgrade of the different pieces of functionality of the middleware. When the anchor receives a request of a certain service, its SD module searches its service providers table for available providers which meet the requestor’s requirements. There are three possibilities that can be encountered:
A single provider that meets the requirements is available. More than one provider that meet the requirements are available.
No providers that meet the requirements are available in the zone. In case of the first possibility, the anchor sends this available provider a ‘‘service reservation’’ message. Once the provider responds with an ‘‘ACK’’ message, the anchor in turn sends an ‘‘ACK’’ message to the requestor along with specific information about the provider including the estimated time of transfer of this provider to the requestor to provide the service. All these communications are conducted through the communication module, as we described before. In the second case, the anchor has more than one option to select from. Therefore, the SR module of the anchor performs a comparison of the service attributes of the different provides to the requested service parameters. The provider with the best match is selected and reserved, as
615
described before. For example, when the time-to-service is considered as a criterion for comparison, the anchor calculates it as follows: Time-to-service¼time-to-availability + transfer time The time-to-availability is the estimated time after which the provider can start moving towards the requestor (e.g. after preparing the required equipment, etc.). If the provider is able to start moving immediately, then the value of this time-toservice component is zero. The transfer time is the time taken by the potential provider to reach the requestor. This is calculated as the current distance between the requestor and the potential provider divided by the average speed of the provider. As for the last possibility, which is the unavailability of a suitable provider in the service providers table, the anchor in this case performs an inter-zone search by sending an SD multicast message to peer anchors as described in Section 4.3.2. 4.3. Inter-zone communications The interaction between anchor nodes is considered an interzone type of communications due to the fact that it crosses zone boundaries. It is done via the same communication module that we described in Section 4.2.1. This module can include various communication protocols, which helps with communications within the same zone as well as between zones. The interaction and cooperation between anchors is conducted via the anchor-toanchor coordination module. This module manages three categories of interactions: anchor-to-anchor advertisements, request for service discovery and provider information transfer. 4.3.1. Anchor-to-anchor advertisements (AAD) At network initialization, pre-determined anchor nodes exchange their information using multicast communications in order to initiate the cooperation between them. This information may include exact location and any other attributes necessary for the operation. A shorter AAD message can also be multicast periodically to ensure that each anchor is still in service and communicable. In addition, if a new anchor comes on line as in the case of extending the operations area or as a replacement of another anchor, it also advertises its presence to its peer anchors using the AAD module. 4.3.2. Anchor-to-anchor service discovery (ASD) Normally, when an anchor gets a service discovery request from a service requestor within its zone, it tries to satisfy this request using help from providers within the same zone as we described in Section 4.2.4. If no suitable provider within the same zone is available, the anchor node can request a service provider from its peer anchors. Therefore, the anchor creates an ASD request and multicast it to all anchor nodes of the other zones within the operations area through the communications module. This request is similar to the SD request that we described in Section 4.2.4. 4.3.3. Anchor-to-anchor service reservation (ASR) When anchor nodes receive an ASD message from a peer anchor, they check their service providers tables to see if there is an available service provider match. If a match is found, the donor anchor sends a message to the requesting anchor informing it of the attributes of the available provider. The requesting anchor then checks all responses and selects the best match from all the responses it got. It sends a service reservation request (ASR) to the anchor that has the best provider for the request at hand. The donor anchor then sends an SR message to its provider informing it of the requestor’s information in the other zone. Once it receives
ARTICLE IN PRESS 616
Y. Gadallah et al. / Journal of Network and Computer Applications 33 (2010) 611–619
Fig. 3. Service discovery example.
an ACK from its provider, it sends an ACK to the requesting anchor.
a situation where no suitable provider is available in the zone of the requestor. Therefore, anchor-to-anchor discovery is conducted to look for the requested service in other zones.
4.4. Internal modular communications The modules within the anchor node cooperate in order to achieve the goal of the network. Aside from the fact that all modules have to interface with the communication module for the purpose of dealing with the external world, the following sections describe the main internal modular interactions. 4.4.1. Service discovery module and service reservation module interactions When the anchor node receives an SD message from a service requestor, the service discovery module locates a suitable provider in the service providers table as we described previously. When found, the SD module calls for the services of the SR module in order to reserve the services of this provider. The parameters that it passes to this module are mainly the location and address attributes of both the service provider and the requestor. The SR module returns back an ‘‘ACK’’ to the SD module upon the successful reservation of the provider. 4.4.2. Service discovery module and anchor-to-anchor coordination module interactions If the SD module on the anchor node is unable to find a suitable service provider within its zone, it calls for the services of the anchor-to-anchor coordination module in order to locate a suitable provider in any other zone. The parameters that are passed from the SD module are the requested service attributes and the location of the service requestor. Once located, the anchor-to-anchor coordination module passes back service provider address information, current location and service attributes. 4.4.3. Anchor-to-anchor coordination module and service reservation module interactions When the anchor-to-anchor coordination module on an anchor node receives an ACK message from a peer anchor in response to a provider offer that it has previously sent to it, it calls for the services of the SR module in order to reserve the services of this provider. The attributes that are passed to the SR module in this case are the location and address attributes of both the service provider and the requestor. The sequence diagram shown in Fig. 3 describes an example scenario of the interactions followed to discover and reserve a service provider to fulfill a requestor’s need. The scenario assumes
5. System evaluation We conduct experimental evaluation of the performance of the proposed service discovery middleware. We use a simulator called DisSERV that we have developed for this purpose. We use a simple multi-hop communication scheme that we also developed in order to use for this evaluation purpose. 5.1. Experimental environment The DisSERV simulator implements the different modules of the proposed middleware structure. This also includes the communication protocols, mobility models, etc. For mobile nodes, the random waypoint mobility model (Camp et al., 2002) is used in the experiments. The simulation area is 1000 1000 m2. Unless otherwise stated in connection to a specific experiment, the default simulation parameters are as follows. The number of operations zones is 4. The size of the request packet is 64 bytes. Service provider and requestor device communication range is 250 m. Network nodes are initially uniformly distributed. Each service provider node moves at a speed of value that is randomly selected in the range of 1–6 m/s. The service requesting nodes are stationary. The anchor node of each zone is stationary and is roughly located at the center of its zone. The simulation experiment time is 600 s. The main metric that we use in our experiments is the ‘‘discovery success’’ metric. It measures whether a service requesting node was able to get a service provider that meets its conditions located and reserved successfully in two situations: within the zone (intra-zone) and outside the zone (inter-zone). This depends on the different levels of availability of such service providers both within the zone of the requestor and elsewhere. We also evaluate the middleware scalability as the number of service requests increases. 5.2. Results and discussion For the purpose of conducting the experimental evaluation, we have implemented the communication module using a simple multi-hop scheme for intra-zone communications and a direct multicast scheme for inter-zone communications. We have
ARTICLE IN PRESS Y. Gadallah et al. / Journal of Network and Computer Applications 33 (2010) 611–619
617
Fig. 4. Intra-zone service discovery.
Fig. 5. Inter-zone service discovery.
conducted the following experiments to evaluate the proposed middleware discovery scheme: 5.2.1. Scenario 1: intra-zone discovery In this experiment, we evaluate the intra-zone abilities of the middleware to locate required service providers (i.e. finding providers within the requestors’ zones). Hence, we set the number of providers within each zone to be greater than the number of generated service discovery requests. The goal is to verify that the anchor-based discovery within each zone is capable of locating the available providers within the same zone. We set the total number of generated requests to 100 requests. Fig. 4 shows that the percentage intra-zone service discovery is maintained at a high value (around 90% for most zones) in all four zones, while the percentage intra-zone discovery failures are generally low. This shows the high ability of the middleware to perform the required discovery through the cooperation of the different modules both between the nodes as well as internal to each node. The non-fulfilled requests through intra-zone discovery are handled through inter-zone anchor-to-anchor cooperation. The total number of successful discovery requests is slightly less than 100% which shows that the number of failed discovery requests, in both intra-zone and inter-zone discovery attempts, is quite small. 5.2.2. Scenario 2: inter-zone discovery In this experiment, we evaluate the inter-zone capabilities of the middleware to locate required service providers (i.e. finding providers outside the requestors’ zones). We set the number of available providers with the required attributes within each zone to be less than the generated requests in the corresponding zone. We set the total number of generated requests to 100 requests. This is to force the anchor of the zone with the shortage in providers to request help from other zones. Fig. 5 shows that the requests of a given zone are able, through the help of the anchor nodes of their zones, to locate service providers from neighboring zones with a high success percentage. Roughly, an average of 35% of the requests is serviced by providers from different zones. The rest of the requests are serviced by providers within the same zone. The total number of requests is slightly less than 100%, which shows that the percentage failure is also small in this case. 5.2.3. Scenario 3: middleware scalability In this experiment, we evaluate the ability of the middleware to scale with the increase in the number of requests. For this
Fig. 6. Middleware scalability.
purpose, we increase the number of requests for specific specializations that are generated in each zone and we measure the resulting intra-zone and inter-zone discovery success. The goal is to verify that the middleware maintains high discovery success as we increase the number of requests. Fig. 6 shows that intra-zone and inter-zone service discovery success is almost constant, while we increase the total number of requests for all zones between 100 and 250 requests. The overall success ratio is almost 100% in all cases, which reflects the high ability of the middleware to scale with the increasing number of requests. As we see from the above experiments, the proposed middleware shows high level of efficiency in discovering service providers both within the zones of the requests and also through inter-zone anchor-to-anchor cooperation.
5.3. Comparison with other solutions In this section, we compare the proposed middleware technique to other solutions (Bottazzi et al., 2006; Helal et al., 2003; Juszczyk and Dustdar, 2008) that have been developed in order to address similar issues. In this comparison, we focus on operational aspects that are normally required in emergency response situations such as reliable operation, scalability, mobility handling, etc. Table 1 gives a summary of this qualitative comparison.
ARTICLE IN PRESS
Designed specifically for ERO Not addressed Not addressed
Addressed
Not designed specifically for ERO Addressed Not addressed
Lightweight communication overhead RESCUE (Juszczyk and Dustdar, 2008)
KONARK (Helal et al., 2003)
Heavy communication overhead especially with visual/speech communications Heavy overhead due to using XML based messages AGAPE (Bottazzi et al., 2006)
Ad hoc peer-to-peer operation. Hence scalability is limited Peer-to-peer operation. Hence scalability is limited
Not addressed
Addressed Not addressed
Addressed
Anchor-based operation, hence load balancing is carried out through anchor collaboration Not addressed Text-based, lightweight The proposed technique
Highly scalable due to the fact that centralized high capability nodes organize the operations Lack of overall centralized entities reduces system scalability
Addressed
Mobility Load balancing Reliability (in terms of discovery success) Scalability Message overhead Emergency response operations middleware solution
Table 1 Comparison of middleware based MANET for emergency response operations.
Highly suitable; designed specifically for general ERO. Use of service attributes makes it suitable for all kinds of ERO Deals mainly with elderly people assistance. No service attributes involved
Y. Gadallah et al. / Journal of Network and Computer Applications 33 (2010) 611–619
Suitability for emergency response operations (ERO)
618
As shown in Table 1, we see that the middleware that we propose in this study addresses all the requirements of emergency response operations significantly better than the other techniques. This is due to the fact that its design is based on the requirements of such environments unlike the other techniques which targeted only specific aspects that may be encountered in such environments.
6. Conclusions Mobile ad hoc networks can be used quite effectively in managing resource discovery and allocation while conducting special operations such as disaster recovery operations. This is due to the ability to establish such network in a short time without the need of any existing infrastructure. In this study, we used the concept of service discovery in MANET and adapted it to the situations that are encountered in such missions. We proposed modular middleware architecture for the system that is used for locating, managing and allocating resources, e.g. medics, equipment, ambulance services, etc., to the parties in need. We described the architecture in detail and showed that it is adaptable to the type of the network nodes, depending on the function of the node that is using the middleware. We also performed evaluation experiments to measure the ability of the proposed middleware to discover providers within the zone of the requestors. The experiments also show the ability of the middleware to discover and reserve providers from other zones if no sufficient providers are available for the requests within the same zone. Also, the evaluations show that the middleware is highly scalable with the increase of the number of requests within the system. References Benssam A, Berger J, Boukhtouta A, Debbai M, Ray S, Sahi A. What middleware for network centric operations? Knowledge-Based Systems 2007;20:255–65. Bisignano M, Calvagna A, Modica GD, Tomarchio O. Experience: a Jxta middleware for mobile ad hoc networks. In: Proceedings of the third international conference on P2P computing. 2003. Bottazzi D, Corradi A, Montanari R. Context-aware middleware solutions for anytime and anywhere emergency assistance to elderly people. IEEE Communications Magazine 2006:82–90. Camp T, Boleng J, Davies V. A survey of mobility models for ad hoc network research. IEEE Wireless Communication & Mobile Computing (WCMC): Special issue on Mobile Ad Hoc Networking: Research, Trends and Applications 2002;2(5):483–502. Catarci T, Leoni M, Marrella A, Salvatore B, Vetere G, Dustdar S, Juszczyk L, Manzoor A, Truong H. Pervasive Software environments for supporting disaster responses. IEEE Internet Computing 2008:26–37. Chakraborty D, et al. GSD: a novel group-based service discovery protocol for MANETS. In: Proceedings of the fourth IEEE conference on mobile and wireless communications networks (MWCN 02). IEEE Press; 2002. p. 140–4. Chakraborty D, et al. Toward distributed service discovery in pervasive computing environments. IEEE Transactions on Mobile Computing 2006;5(2):97–112. Cheng L, Marsic I. Service discovery and invocation for mobile ad hoc networked appliances. In: Proceedings of the second international workshop networked appliances (IWNA 00). December 2000. Engelstad PE, Zheng Y, Koodli R, Perkins CE. Service discovery architectures for ondemand ad hoc networks. International Journal of Ad Hoc and Sensor Wireless Networks, Old City Publishing (OCP Science) 2006;2(1):27–58. G€orgen D, Frey H, Lehnert JK, Sturm P. SELMA: a middleware platform for selforganizing distributed applications in mobile multihop ad-hoc networks. In: Western Simulation MultiConference WMC ’04. 2004. Hadim S, Al-Jaroodi J, Mohamed N. Trends in middleware for mobile ad hoc networks. Journal of Communications 2006;1(4):11–21. Helal S, et al. Konark: a service discovery and delivery protocol for ad hoc networks. Wireless Communication and Networking 2003;3:2107–13. Herrmann K. MESHMdl—a middleware for self-organization in ad hoc networks. In: Proceedings of the first international workshop on mobile distributed computing (MDC’03). May 19, 2003. Kanchanasut K, Tunpan A, Awal MA, Wongsaardskul T, Das D, Tsuchimoto Y. Building a long-distance multimedia wireless mesh network for collaborative disaster emergency responses. intERLab technical report. Thailand, Aril: Asian Institute of Technology; 2007.
ARTICLE IN PRESS Y. Gadallah et al. / Journal of Network and Computer Applications 33 (2010) 611–619
Klein M, Konig-Ries B, Obreiter P. Service rings: a semantic overlay for service discovery in ad hoc networks. In: Proceedings of the 14th international conference on database and expert systems applications (DEXA 03), IEEE CS Press; 2003. p. 180–5. Klein M, Konig-Ries B, Obreiter P. Lanes: a lightweight overlay for service discovery in mobile ad hoc networks. In: The third workshop applications and services in wireless networks (ASWN 03), July 2003. Kozat U, Tassiulas L. Network mobile ad hoc networks. In: Proceedings of the IEEE conference on computer communication (INFOCOM03). IEEE Press; 2003. p. 1965–75. Lenders V, May M, Plattner B. Service discovery in mobile ad hoc networks: a field theoretic approach. In: Proceedings of the sixth IEEE international symposium on world of wireless mobile and multimedia networks (WoWMoM 05), vol. 1, IEEE Press; 2005. p. 120–30. Levis P, Culler D. Mate: a tiny virtual machine for sensor networks. In: Proceedings of the international conference on architectural support for programming languages and operating systems, October 2002. Liu KFR. Agent-based resource discovery architecture for environmental emergency management. Expert Systems with Applications 2004;27: 77–95. Juszczyk Lukasz, Schahram Dustdar. A middleware for service-oriented communication in mobile disaster response environments. In: The proceedings of the sixth international workshop on middleware for pervasive and ad-hoc computing, Belgium, 2008. p. 37–42.
619
Meier R, Cahill V. STEAM: event-based middleware for wireless ad hoc networks. In: The 22nd international conference on distributed computing systems workshops (ICDCSW’02), Austria, July 2002. Mian A, Baldonu R, Beraldi R. A survey of service discovery protocols in multihop mobile ad hoc networks. IEEE Pervasive Computing 2009;8(1):66–74. Murphy AL, Picco GP, Roman G-C. Lime: a Middleware for physical and logical mobility. In: Proceedings of the 21st international conference on distributed computing systems (ICDCS-21). May 2001. Musolesi M, Mascolo C, Hailes S. EMMA: epidemic messaging middleware for ad hoc networks. In: Personal and ubiquitous computing. 2005. Ratsimor O, et al. Allia: alliance-based service discovery for ad hoc environments. In: Proceedings of the second international workshop mobile commerce (WMC 02), ACM Press; 2002. p. 1–9. Tyan J, Mahmoud Q. A network layer based architecture for service discovery in mobile ad hoc networks. In: Proceedings of the 17th annual IEEE Canadian conference on electrical and computer engineering (CCECE04), vol. 3. IEEE Press; May 2004. p. 1379–84. Varshavsky A, Reid B, de Lara E. A cross layer approach to service discovery and selection in MANETS. In: Proceedings of the second International conference on mobile ad-hoc and sensor systems (MASS 05), IEEE Press; 2005. Zhu F, Mutka M, Splendor L. A secure, private and location-aware service discovery protocol supporting mobile services. In: Proceedings of the first international Conference on pervasive computing and communication (Per-Com 03), ACM Press; 2003. p. 235–42.
Contents lists available at ScienceDirect
Journal of Network and Computer Applications journal homepage: www.elsevier.com/locate/jnca
Middleware support for service discovery in special operations mobile ad hoc networks Yasser Gadallah n, Mohamed Adel Serhani, Nader Mohamed College of Information Technology, UAE University, P.O. Box 17551, Al Ain, UAE
a r t i c l e in fo
abstract
Article history: Received 1 November 2009 Received in revised form 16 February 2010 Accepted 18 March 2010
Technology can play a significant role in the management and coordination activities of special operations such as emergency response, military combat missions, forest firefighting, etc. Mobile ad hoc networks (MANETs) can be used quite effectively to manage resource sharing in such operations due to their flexibility and ease of establishment. The concept of service discovery has some appealing characteristics and features that can be adopted and adapted for the nature and needs of these applications. In this study, we present the middleware architecture of a service discovery and allocation system that we propose for the applications of special operations. The main purpose of the proposed system is to locate, reserve and assign a certain service to the party that is in need of this service, with little or no human intervention. The concerned service could be medics, equipment, ambulances, etc. The network participants are divided into service providers, service requestors and anchor nodes. The anchor nodes are the ones which are used to manage resource discovery and allocation. The proposed middleware takes into consideration the classification of these network nodes on the basis of their function. Based on the classification of a certain node, only the middleware modules relevant to its function are activated. We describe the design of this middleware in detail. We also experiment with the proposed technique and present some results that show its capabilities from different performance perspectives. & 2010 Elsevier Ltd. All rights reserved.
Keywords: Emergency response Mobile ad hoc networks Middleware Service discovery
1. Introduction Emergency response and similar special operations may potentially involve the use of many resources such as personnel and equipment. These operations therefore require accurate and continuous coordination among operations’ participants. Examples of these operations include forest firefighting, earthquake disaster recovery, coordinated military combat missions, etc. The use of technology can facilitate the goal of achieving optimal, or close to optimal resource management and allocation in such operations. Specifically, the use of mobile ad hoc networks (MANETs) for locating, managing and allocating resources can prove invaluable. Mobile ad hoc networks are usually used in networking applications where infrastructure networks cannot be accessed or are expensive to establish. MANETs have the advantage of the possibility of being established hastily with the use of simple communication devices. The use of a MANET based automated system to coordinate operations can provide a level of efficiency, speed and ease that is difficult to achieve through the use of human coordination alone.
n
Corresponding author. E-mail addresses: [email protected] (Y. Gadallah), [email protected] (M. Adel Serhani), [email protected] (N. Mohamed). 1084-8045/$ - see front matter & 2010 Elsevier Ltd. All rights reserved. doi:10.1016/j.jnca.2010.03.009
The concept of service discovery is traditionally used to locate web services that are needed by network clients. There have been many studies that dealt with traditional service discovery in MANET (Mian et al., 2009). These studies have mainly addressed the discovery of electronic-type services that are provided on specific nodes within the network. A service of this type can normally be provided to several requestors simultaneously based on the bandwidth and capabilities of the service provider. In this study, we adapt the concept of service discovery to emergency response operations using MANETs. In such operations, there are normally two classes of scenario participants; providers of services and requestors of these services. Examples are medics who provide a variety of medical services to injured or distressed persons. Medics are considered ‘‘service providers’’ while victims are considered ‘‘service requestors’’, according to this notion. The concept of service discovery within MANET can therefore be applied, after making some necessary adaptations, for use in such situations. The adapted service discovery scheme that we propose in this study differs from the traditional service discovery concept in the following main aspects: 1. The service providers have to physically move to the location of the service requestors in order to provide their services. 2. A service provider can generally serve one and only one service requestor at any point of time.
ARTICLE IN PRESS 612
Y. Gadallah et al. / Journal of Network and Computer Applications 33 (2010) 611–619
3. Each time a specific provider is used after it has completed a certain mission, a new discovery needs to be launched in order to locate it. This is due to the fact that keeping localization information about mission-dependent physically moving providers is not useful for future uses. The main goal of this study is therefore to design a middleware architecture that can be used for the purpose of finding and allocating service providers in such environments. We target a configuration that is composed of simple network devices such as PDA’s, which are used by personnel who are participating within the network. In such environments there are several challenges to deal with such as scalability with the potentially large number of requests and system interactions. There is also the need for realtime resolution of client requests as failure to do so could be lifethreatening in some cases. The heterogeneous environment that is expected due to the variety of network participants and the different roles they assume also places requirements on the architecture, e.g. to accommodate the different functions. The middleware solution that we propose addresses the above issues as follows. We establish a network arrangement where the operations area is divided into several geographical zones. The size and number of zones are determined based on operational requirements, i.e. application-dependent. In each zone, there is a central node, which we term an anchor node, whose only function is to coordinate the service discovery and resource allocation operations in its zone. The middleware architecture can therefore scale well with the size of the network and the number of requests within this network. It also requires minimal or no operator intervention as the request resolution is done in an automated manner hence providing high levels of speed and accuracy. This middleware is also nodedependent, i.e. module activation within the structure depends on the function of the node that it resides on. There are three types of nodes that are involved in the interactions within the proposed scheme:
capabilities, e.g. GPS. The operations area is divided into several zones. Within each zone, a generally stationary high-capability device, which is called an anchor throughput this study, is used to coordinate the service providing operation within each zone (i.e. intra-zone) as well as between the different zones (i.e. interzone). All these devices combined can thus form a mobile ad hoc network. The network members are service providers, service requestors or anchors. The service in this case can be defined as any help needed while the operation is going on. In case of emergency response operations, the examples of these services could include medics, equipment, ambulance services, emergency workers, etc. Using the communication devices, also called network nodes throughput this study, a service (e.g. a medical doctor) can be requested via communicating the required service specifics to the anchor nodes. Service specifics are pre-determined parameters that characterize each type of available services within the network. Service providers receive the assignments from the anchor nodes on their devices as well. Fig. 1 gives an illustration of the network layout. When a node within a certain zone needs to obtain some service, it communicates its need to the anchor node of its zone. Then the anchor node has the responsibility of locating and assigning the proper service provider to the requesting node based on the parameters of the request. If a new node joins the network or a node moves into a new zone, it can determine the anchor node of this zone via issuing a query to other nodes within its communication range. If no service provider is available within a certain zone to satisfy a request within this zone, the anchor of the zone communicates with the anchors of the other zones in order to request a provider that may be available in their zones, for the request at hand.
3. Related work
The service provider nodes: are the devices carried by the
different emergency personnel who can provide one or more types of service such as different kinds of medical services, rescue workers, etc. The service requestor nodes: are the ones that are carried by personnel who are the care takers associated with the victims or the parties who require a certain type of service. The anchor nodes: these nodes are at the center of the operation. They are computationally powerful communication devices and are established, preferably, at the middle of each zone of the operations area in order to coordinate the service discovery and dissemination within their zone. These nodes are considered to be command centers for the operation. It is also the responsibility of the anchor node to communicate and coordinate with other zones’ anchor nodes for the different aspects of the overall operation, as will be explained later.
The remainder of this paper is organized as follows. In Section 2, we give an example to illustrate the environment that we target in this study. In Section 3, we discuss some related studies. In Section 4, we give the detailed design of the system. In Section 5, we present some evaluation results. In Section 6, we conclude the study.
2. Illustrative scenario We consider a scenario where we have an emergency or military operation of which personnel are deployed over a certain geographical area. Each person carries a lightweight hand held communications device that has limited wireless range and computational resources. Each device has location determination
There have been a number of studies that aimed at providing technological support to emergency response efforts. In Kanchanasut et al. (2007), a long-distance multimedia wireless mesh network for collaborative disaster emergency responses is proposed. The study has focused on developing a system for the purpose of enabling multimedia communication under the effects of limited network bandwidths and high network latencies in the event of a complete destruction of the wired network infrastructure by a disaster. In Bottazzi et al. (2006), the authors proposed a context-aware middleware, termed ACAPE, to provide outdoor emergency assistance to elderly people. This middleware helps manage the assistance teams in terms of creating the team and supporting the team members’ interactions for anytime and anywhere emergency assistance. The communication environment considered in here is based on MANET. In Liu (2004), an agent-based resource discovery architecture for environmental emergency management was proposed. In this environment, agents cooperate to respond to environmental emergency situations. These agents are used for monitoring the environment, for simulating and analyzing the environment and for knowledge management using Petri nets. In Catarci et al. (2008), a pervasive software environment for supporting disaster response is discussed. This system consists of two layers: frontend and back-end. The front-end layer is represented by teams of first responders, e.g. police and fire departments, carrying PDA devices. The back-end layer is an integrated peer-to-peer network that lets front-end teams collaborate and exchange information. Back-end centers communicate directly with the team leaders at the front-end while team members communicate through a MANET.
ARTICLE IN PRESS Y. Gadallah et al. / Journal of Network and Computer Applications 33 (2010) 611–619
613
Fig. 1. Emergency response scenario layout.
Different middleware approaches were proposed to solve some of the issues that are encountered during the use of MANETs in emergency response applications (Hadim et al., 2006; Meier and Cahill, 2002; Musolesi et al., 2005; Bisignano et al., 2003; G€orgen et al., 2004; Murphy et al., May 2001; Herrmann, 2003; Levis and Culler, 2002; Benssam et al., 2007). Of particular interest to this study is the concept of service discovery which can be implemented as part of the middleware for MANETs. There are many studies that addressed service discovery in MANET, e.g. Cheng and Marsic (2000), Chakraborty et al. (2002), Ratsimor et al. (2002), Helal et al. (2003), Klein et al. (2003), Klein et al. (2003), Kozat and Tassiulas (2003), Zhu et al. (2003), Varshavsky et al. (2005), Tyan and Mahmoud (2004), Lenders et al. (2005), Chakraborty et al. (2006) and Engelstad et al. (2006). These studies present different approaches that are related to different service discovery aspects such as: service description, service registration, service discovery, routing and mobility support (Mian et al., 2009). A considerable number of these works have used the XML language for service descriptions such as in Chakraborty et al. (2002) and Helal et al. (2003). However, the use of XML is a rather heavy-handed approach in an environment where bandwidth is limited. Service registration is a process that is used to make services available and known to service requestors. This is done through registering the services by the providers at specified service registries. Registering a service requires providing information about the expiration time of the service and the distance, in hops, of the service provider. This information is stored either in directories in some network nodes or in the local caches of the service providers themselves. However, there is no third party authority that can manage the registration process and keep track of any update/removal of registered services. Concerning service discovery, the above studies focused mainly on the processes of search and selection of services. A service requestor can search for specific service requirements, where multiple service providers that satisfy these requirements may exist. The goal of the selection process is to determine a suitable service provider from this list. Most of
discovery approaches rely on the client to select the appropriate service or delegate the discovery process to a centralized entity that does the discovery on behalf of the client who might lack expertise and knowledge to make the discovery decision. Collaborating between different third parties in discovering services for the clients will definitely improve the discovery success. Our study is different from the above studies in the fact that it proposes a MANET-based middleware that supports scalable and automated resource discovery, management and allocation in special operations such as emergency response and military combat missions. It uses the abstract concept of service discovery after adapting it to suit the nature and needs of this environment. It ensures a seamless operation in which resources are located on the basis of service attributes, and allocated on the basis of a bestmatch policy. While doing so, cooperation between command centers supports the discovery and transfer of resources from one zone to another in the event of resource shortages in the zone of need. Lightweight messaging is used in all communications, which accommodates the nature of the environment where bandwidth is limited due to the limited capabilities of the involved devices.
4. Detailed middleware architectural description The middleware that we propose in this study has several modules that support the different aspects of the functionality, depending on the type of the network node that hosts the middleware. There are several communication modes that support the required interactions including the intra-zone, inter-zone and modular communications. In the following, we present the detailed middleware architecture and discuss the interactions at the different communication levels. 4.1. Architecture overview The proposed service discovery and allocation scheme spans three modes of operation of network participants as represented
ARTICLE IN PRESS 614
Y. Gadallah et al. / Journal of Network and Computer Applications 33 (2010) 611–619
by anchor nodes, service requestor nodes and service provider nodes. Depending on the mode of operation, the relevant middleware modules are activated. Fig. 2 shows the middleware structure for the different types of network participants. There are three modes of communications according to this architecture:
communication protocols that are needed by the system, e.g. the underlying MAC protocol as well as the networking protocol. It can therefore accommodate any set of protocols that are suitable for the purpose of this application. The details of these protocols are implementation specific and are beyond the scope of this study.
Intra-zone communications: this mode of communications
As shown in Fig. 2, the main modules of the middleware are: the anchor advertisement (AD) module, the service discovery (SD) module, the service advertisement (SA) module, the service reservation (SR) module, the anchor-to-anchor coordination module and the communication module. In the following sections, we discuss the above modes of communications as well as the involved modules in detail. 4.2. Intra-zone communications Intra-zone communications include the interactions among nodes within the same zone. These interactions occur among the corresponding modules at the different node types, depending on the purpose of the communication. In the following, we describe the different module types involved in intra-zone communications including their functionality and interactions. 4.2.1. Communication module This module is included in the middleware structure of all network node types. It is the module through which all external communications in both directions are made. Therefore, any module that needs to communicate with the corresponding module on any other node has to do so through the communication module. The communication module implements the set of
Anchor, Zone x
Anchor, Zone y
Communication Module
Service Reservation Module
Service Advertiseme nt Module
Service Discovery Module
Service Provider, Zone x
Anchor-toAnchor Coordinatio n Module
Service Reservation Module
Service Reservation Module
Service Advertiseme nt Module
Service Advertiseme nt Module
Anchor AD
Anchor AD
Service Discovery Module
Anchor AD
Intra-zone Comm.
Service Discovery Module
Service Requestor, Zone x
Inter-zone Comm.
Module Interaction
Fig. 2. Middleware structure for interactions within the proposed service discovery scheme.
Communication Module
Communication Module
Anchor-toAnchor Coordinatio n Module
4.2.3. Service advertisement (SA) module When a service provider becomes available for providing services to requestors, it advertises its availability to the anchor node. This situation is encountered at network initialization, when a new provider joins the network and upon completing a service mission that was previously assigned to a service provider. It is expected that a provider node would only move to serve a requestor, or to return to its base. For example, we would not expect a heavy piece of equipment that it used to remove rubble from an area to rescue a trapped person to be moving around constantly; it would only move to execute a mission or to return back to its base. To announce its availability, the service provider composes an SA message using its SA module. The message gets sent out through the communication module. When this message is sent by the provider for the first time (i.e. at network initialization or when a new provider joins the network), it includes the attributes of this service provider. For any subsequent SA communications, the provider only sends a shorter message announcing its availability without including its attributes to save energy and communication bandwidth, unless any
Comm. Mod.
4.2.2. Anchor advertisement (AD) module This module is included in the middleware structure of all network node types. Upon network initialization, the anchor node of a specific zone announces its presence to all zone nodes. The anchor advertisement module of the anchor node creates the announcement message and includes the attributes of the anchor node and specifically those required to communicate with it such as its address. This message gets passed to the communication module where its gets broadcast to all nodes within the zone. This message gets also broadcast periodically to inform zone nodes of the continued availability of this anchor node. At the receiving end, the AD module of each receiving node processes the AD messages from the anchor and stores its attributes in order to use them later to communicate with the anchor node.
Anchor AD
handles the communications between the corresponding modules in the different nodes that operate within the same zone. As an example, the service discovery communications between the anchor and the service requestor nodes. Inter-zone communications: this mode of communications deals with the communications between two anchor nodes. It therefore handles the communications between two different zones of the operation. Modular communications: this mode organizes the message exchanges between the different middleware modules within a certain node.
ARTICLE IN PRESS Y. Gadallah et al. / Journal of Network and Computer Applications 33 (2010) 611–619
change of the attributes has occurred since the last time it has sent an SA message. When this SA message is received by the communication module of the anchor node, it gets passed to its SA module. The SA module then marks this provider available in the ‘‘service providers’’ table. The service provider table is the table that includes service providers’ information for this zone. It includes the provider’s address, position, attributes and availability status. If there is any change in the attributes of the provider, this information gets updated in the service providers table. 4.2.4. Service discovery (SD) module When there is a need for a certain service such as a medic or a piece of equipment in a particular zone, the SD module of the service requestor creates the service discovery request in which the specifics of service are specified with the required service parameters. This request is then communicated to the anchor of the zone in which this requestor currently exists. For this to occur, the created message gets transmitted internally within the requestor node from the SD module to the communication module, which invokes the services of the networking services in use. The networking services transmit the message, possibly in a multi-hop communication, until it reaches the anchor node of the same zone. The message gets received by the communication module of the anchor node which passes it to the SD module. The SD module then checks the service providers table for the available providers that have attributes that match the requirements of the required service. If one or more providers with matching attributes are found, the SD module calls the services of the service reservation (SR) module to reserve the best matching service provider as indicated in Section 4.2.5. If no suitable provider is found in the table, the anchor node sends an SD multicast message to its peer anchors as indicated in Section 4.3.2. 4.2.5. Service reservation (SR) module The service reservation module has an important role. It makes the calculations and hence the service provider selection decision in case there are more than one provider available to service a certain request, as we discuss shortly. The separation between the SD and SR modules helps realize the benefits of the modular architecture, e.g. ease of upgrade of the different pieces of functionality of the middleware. When the anchor receives a request of a certain service, its SD module searches its service providers table for available providers which meet the requestor’s requirements. There are three possibilities that can be encountered:
A single provider that meets the requirements is available. More than one provider that meet the requirements are available.
No providers that meet the requirements are available in the zone. In case of the first possibility, the anchor sends this available provider a ‘‘service reservation’’ message. Once the provider responds with an ‘‘ACK’’ message, the anchor in turn sends an ‘‘ACK’’ message to the requestor along with specific information about the provider including the estimated time of transfer of this provider to the requestor to provide the service. All these communications are conducted through the communication module, as we described before. In the second case, the anchor has more than one option to select from. Therefore, the SR module of the anchor performs a comparison of the service attributes of the different provides to the requested service parameters. The provider with the best match is selected and reserved, as
615
described before. For example, when the time-to-service is considered as a criterion for comparison, the anchor calculates it as follows: Time-to-service¼time-to-availability + transfer time The time-to-availability is the estimated time after which the provider can start moving towards the requestor (e.g. after preparing the required equipment, etc.). If the provider is able to start moving immediately, then the value of this time-toservice component is zero. The transfer time is the time taken by the potential provider to reach the requestor. This is calculated as the current distance between the requestor and the potential provider divided by the average speed of the provider. As for the last possibility, which is the unavailability of a suitable provider in the service providers table, the anchor in this case performs an inter-zone search by sending an SD multicast message to peer anchors as described in Section 4.3.2. 4.3. Inter-zone communications The interaction between anchor nodes is considered an interzone type of communications due to the fact that it crosses zone boundaries. It is done via the same communication module that we described in Section 4.2.1. This module can include various communication protocols, which helps with communications within the same zone as well as between zones. The interaction and cooperation between anchors is conducted via the anchor-toanchor coordination module. This module manages three categories of interactions: anchor-to-anchor advertisements, request for service discovery and provider information transfer. 4.3.1. Anchor-to-anchor advertisements (AAD) At network initialization, pre-determined anchor nodes exchange their information using multicast communications in order to initiate the cooperation between them. This information may include exact location and any other attributes necessary for the operation. A shorter AAD message can also be multicast periodically to ensure that each anchor is still in service and communicable. In addition, if a new anchor comes on line as in the case of extending the operations area or as a replacement of another anchor, it also advertises its presence to its peer anchors using the AAD module. 4.3.2. Anchor-to-anchor service discovery (ASD) Normally, when an anchor gets a service discovery request from a service requestor within its zone, it tries to satisfy this request using help from providers within the same zone as we described in Section 4.2.4. If no suitable provider within the same zone is available, the anchor node can request a service provider from its peer anchors. Therefore, the anchor creates an ASD request and multicast it to all anchor nodes of the other zones within the operations area through the communications module. This request is similar to the SD request that we described in Section 4.2.4. 4.3.3. Anchor-to-anchor service reservation (ASR) When anchor nodes receive an ASD message from a peer anchor, they check their service providers tables to see if there is an available service provider match. If a match is found, the donor anchor sends a message to the requesting anchor informing it of the attributes of the available provider. The requesting anchor then checks all responses and selects the best match from all the responses it got. It sends a service reservation request (ASR) to the anchor that has the best provider for the request at hand. The donor anchor then sends an SR message to its provider informing it of the requestor’s information in the other zone. Once it receives
ARTICLE IN PRESS 616
Y. Gadallah et al. / Journal of Network and Computer Applications 33 (2010) 611–619
Fig. 3. Service discovery example.
an ACK from its provider, it sends an ACK to the requesting anchor.
a situation where no suitable provider is available in the zone of the requestor. Therefore, anchor-to-anchor discovery is conducted to look for the requested service in other zones.
4.4. Internal modular communications The modules within the anchor node cooperate in order to achieve the goal of the network. Aside from the fact that all modules have to interface with the communication module for the purpose of dealing with the external world, the following sections describe the main internal modular interactions. 4.4.1. Service discovery module and service reservation module interactions When the anchor node receives an SD message from a service requestor, the service discovery module locates a suitable provider in the service providers table as we described previously. When found, the SD module calls for the services of the SR module in order to reserve the services of this provider. The parameters that it passes to this module are mainly the location and address attributes of both the service provider and the requestor. The SR module returns back an ‘‘ACK’’ to the SD module upon the successful reservation of the provider. 4.4.2. Service discovery module and anchor-to-anchor coordination module interactions If the SD module on the anchor node is unable to find a suitable service provider within its zone, it calls for the services of the anchor-to-anchor coordination module in order to locate a suitable provider in any other zone. The parameters that are passed from the SD module are the requested service attributes and the location of the service requestor. Once located, the anchor-to-anchor coordination module passes back service provider address information, current location and service attributes. 4.4.3. Anchor-to-anchor coordination module and service reservation module interactions When the anchor-to-anchor coordination module on an anchor node receives an ACK message from a peer anchor in response to a provider offer that it has previously sent to it, it calls for the services of the SR module in order to reserve the services of this provider. The attributes that are passed to the SR module in this case are the location and address attributes of both the service provider and the requestor. The sequence diagram shown in Fig. 3 describes an example scenario of the interactions followed to discover and reserve a service provider to fulfill a requestor’s need. The scenario assumes
5. System evaluation We conduct experimental evaluation of the performance of the proposed service discovery middleware. We use a simulator called DisSERV that we have developed for this purpose. We use a simple multi-hop communication scheme that we also developed in order to use for this evaluation purpose. 5.1. Experimental environment The DisSERV simulator implements the different modules of the proposed middleware structure. This also includes the communication protocols, mobility models, etc. For mobile nodes, the random waypoint mobility model (Camp et al., 2002) is used in the experiments. The simulation area is 1000 1000 m2. Unless otherwise stated in connection to a specific experiment, the default simulation parameters are as follows. The number of operations zones is 4. The size of the request packet is 64 bytes. Service provider and requestor device communication range is 250 m. Network nodes are initially uniformly distributed. Each service provider node moves at a speed of value that is randomly selected in the range of 1–6 m/s. The service requesting nodes are stationary. The anchor node of each zone is stationary and is roughly located at the center of its zone. The simulation experiment time is 600 s. The main metric that we use in our experiments is the ‘‘discovery success’’ metric. It measures whether a service requesting node was able to get a service provider that meets its conditions located and reserved successfully in two situations: within the zone (intra-zone) and outside the zone (inter-zone). This depends on the different levels of availability of such service providers both within the zone of the requestor and elsewhere. We also evaluate the middleware scalability as the number of service requests increases. 5.2. Results and discussion For the purpose of conducting the experimental evaluation, we have implemented the communication module using a simple multi-hop scheme for intra-zone communications and a direct multicast scheme for inter-zone communications. We have
ARTICLE IN PRESS Y. Gadallah et al. / Journal of Network and Computer Applications 33 (2010) 611–619
617
Fig. 4. Intra-zone service discovery.
Fig. 5. Inter-zone service discovery.
conducted the following experiments to evaluate the proposed middleware discovery scheme: 5.2.1. Scenario 1: intra-zone discovery In this experiment, we evaluate the intra-zone abilities of the middleware to locate required service providers (i.e. finding providers within the requestors’ zones). Hence, we set the number of providers within each zone to be greater than the number of generated service discovery requests. The goal is to verify that the anchor-based discovery within each zone is capable of locating the available providers within the same zone. We set the total number of generated requests to 100 requests. Fig. 4 shows that the percentage intra-zone service discovery is maintained at a high value (around 90% for most zones) in all four zones, while the percentage intra-zone discovery failures are generally low. This shows the high ability of the middleware to perform the required discovery through the cooperation of the different modules both between the nodes as well as internal to each node. The non-fulfilled requests through intra-zone discovery are handled through inter-zone anchor-to-anchor cooperation. The total number of successful discovery requests is slightly less than 100% which shows that the number of failed discovery requests, in both intra-zone and inter-zone discovery attempts, is quite small. 5.2.2. Scenario 2: inter-zone discovery In this experiment, we evaluate the inter-zone capabilities of the middleware to locate required service providers (i.e. finding providers outside the requestors’ zones). We set the number of available providers with the required attributes within each zone to be less than the generated requests in the corresponding zone. We set the total number of generated requests to 100 requests. This is to force the anchor of the zone with the shortage in providers to request help from other zones. Fig. 5 shows that the requests of a given zone are able, through the help of the anchor nodes of their zones, to locate service providers from neighboring zones with a high success percentage. Roughly, an average of 35% of the requests is serviced by providers from different zones. The rest of the requests are serviced by providers within the same zone. The total number of requests is slightly less than 100%, which shows that the percentage failure is also small in this case. 5.2.3. Scenario 3: middleware scalability In this experiment, we evaluate the ability of the middleware to scale with the increase in the number of requests. For this
Fig. 6. Middleware scalability.
purpose, we increase the number of requests for specific specializations that are generated in each zone and we measure the resulting intra-zone and inter-zone discovery success. The goal is to verify that the middleware maintains high discovery success as we increase the number of requests. Fig. 6 shows that intra-zone and inter-zone service discovery success is almost constant, while we increase the total number of requests for all zones between 100 and 250 requests. The overall success ratio is almost 100% in all cases, which reflects the high ability of the middleware to scale with the increasing number of requests. As we see from the above experiments, the proposed middleware shows high level of efficiency in discovering service providers both within the zones of the requests and also through inter-zone anchor-to-anchor cooperation.
5.3. Comparison with other solutions In this section, we compare the proposed middleware technique to other solutions (Bottazzi et al., 2006; Helal et al., 2003; Juszczyk and Dustdar, 2008) that have been developed in order to address similar issues. In this comparison, we focus on operational aspects that are normally required in emergency response situations such as reliable operation, scalability, mobility handling, etc. Table 1 gives a summary of this qualitative comparison.
ARTICLE IN PRESS
Designed specifically for ERO Not addressed Not addressed
Addressed
Not designed specifically for ERO Addressed Not addressed
Lightweight communication overhead RESCUE (Juszczyk and Dustdar, 2008)
KONARK (Helal et al., 2003)
Heavy communication overhead especially with visual/speech communications Heavy overhead due to using XML based messages AGAPE (Bottazzi et al., 2006)
Ad hoc peer-to-peer operation. Hence scalability is limited Peer-to-peer operation. Hence scalability is limited
Not addressed
Addressed Not addressed
Addressed
Anchor-based operation, hence load balancing is carried out through anchor collaboration Not addressed Text-based, lightweight The proposed technique
Highly scalable due to the fact that centralized high capability nodes organize the operations Lack of overall centralized entities reduces system scalability
Addressed
Mobility Load balancing Reliability (in terms of discovery success) Scalability Message overhead Emergency response operations middleware solution
Table 1 Comparison of middleware based MANET for emergency response operations.
Highly suitable; designed specifically for general ERO. Use of service attributes makes it suitable for all kinds of ERO Deals mainly with elderly people assistance. No service attributes involved
Y. Gadallah et al. / Journal of Network and Computer Applications 33 (2010) 611–619
Suitability for emergency response operations (ERO)
618
As shown in Table 1, we see that the middleware that we propose in this study addresses all the requirements of emergency response operations significantly better than the other techniques. This is due to the fact that its design is based on the requirements of such environments unlike the other techniques which targeted only specific aspects that may be encountered in such environments.
6. Conclusions Mobile ad hoc networks can be used quite effectively in managing resource discovery and allocation while conducting special operations such as disaster recovery operations. This is due to the ability to establish such network in a short time without the need of any existing infrastructure. In this study, we used the concept of service discovery in MANET and adapted it to the situations that are encountered in such missions. We proposed modular middleware architecture for the system that is used for locating, managing and allocating resources, e.g. medics, equipment, ambulance services, etc., to the parties in need. We described the architecture in detail and showed that it is adaptable to the type of the network nodes, depending on the function of the node that is using the middleware. We also performed evaluation experiments to measure the ability of the proposed middleware to discover providers within the zone of the requestors. The experiments also show the ability of the middleware to discover and reserve providers from other zones if no sufficient providers are available for the requests within the same zone. Also, the evaluations show that the middleware is highly scalable with the increase of the number of requests within the system. References Benssam A, Berger J, Boukhtouta A, Debbai M, Ray S, Sahi A. What middleware for network centric operations? Knowledge-Based Systems 2007;20:255–65. Bisignano M, Calvagna A, Modica GD, Tomarchio O. Experience: a Jxta middleware for mobile ad hoc networks. In: Proceedings of the third international conference on P2P computing. 2003. Bottazzi D, Corradi A, Montanari R. Context-aware middleware solutions for anytime and anywhere emergency assistance to elderly people. IEEE Communications Magazine 2006:82–90. Camp T, Boleng J, Davies V. A survey of mobility models for ad hoc network research. IEEE Wireless Communication & Mobile Computing (WCMC): Special issue on Mobile Ad Hoc Networking: Research, Trends and Applications 2002;2(5):483–502. Catarci T, Leoni M, Marrella A, Salvatore B, Vetere G, Dustdar S, Juszczyk L, Manzoor A, Truong H. Pervasive Software environments for supporting disaster responses. IEEE Internet Computing 2008:26–37. Chakraborty D, et al. GSD: a novel group-based service discovery protocol for MANETS. In: Proceedings of the fourth IEEE conference on mobile and wireless communications networks (MWCN 02). IEEE Press; 2002. p. 140–4. Chakraborty D, et al. Toward distributed service discovery in pervasive computing environments. IEEE Transactions on Mobile Computing 2006;5(2):97–112. Cheng L, Marsic I. Service discovery and invocation for mobile ad hoc networked appliances. In: Proceedings of the second international workshop networked appliances (IWNA 00). December 2000. Engelstad PE, Zheng Y, Koodli R, Perkins CE. Service discovery architectures for ondemand ad hoc networks. International Journal of Ad Hoc and Sensor Wireless Networks, Old City Publishing (OCP Science) 2006;2(1):27–58. G€orgen D, Frey H, Lehnert JK, Sturm P. SELMA: a middleware platform for selforganizing distributed applications in mobile multihop ad-hoc networks. In: Western Simulation MultiConference WMC ’04. 2004. Hadim S, Al-Jaroodi J, Mohamed N. Trends in middleware for mobile ad hoc networks. Journal of Communications 2006;1(4):11–21. Helal S, et al. Konark: a service discovery and delivery protocol for ad hoc networks. Wireless Communication and Networking 2003;3:2107–13. Herrmann K. MESHMdl—a middleware for self-organization in ad hoc networks. In: Proceedings of the first international workshop on mobile distributed computing (MDC’03). May 19, 2003. Kanchanasut K, Tunpan A, Awal MA, Wongsaardskul T, Das D, Tsuchimoto Y. Building a long-distance multimedia wireless mesh network for collaborative disaster emergency responses. intERLab technical report. Thailand, Aril: Asian Institute of Technology; 2007.
ARTICLE IN PRESS Y. Gadallah et al. / Journal of Network and Computer Applications 33 (2010) 611–619
Klein M, Konig-Ries B, Obreiter P. Service rings: a semantic overlay for service discovery in ad hoc networks. In: Proceedings of the 14th international conference on database and expert systems applications (DEXA 03), IEEE CS Press; 2003. p. 180–5. Klein M, Konig-Ries B, Obreiter P. Lanes: a lightweight overlay for service discovery in mobile ad hoc networks. In: The third workshop applications and services in wireless networks (ASWN 03), July 2003. Kozat U, Tassiulas L. Network mobile ad hoc networks. In: Proceedings of the IEEE conference on computer communication (INFOCOM03). IEEE Press; 2003. p. 1965–75. Lenders V, May M, Plattner B. Service discovery in mobile ad hoc networks: a field theoretic approach. In: Proceedings of the sixth IEEE international symposium on world of wireless mobile and multimedia networks (WoWMoM 05), vol. 1, IEEE Press; 2005. p. 120–30. Levis P, Culler D. Mate: a tiny virtual machine for sensor networks. In: Proceedings of the international conference on architectural support for programming languages and operating systems, October 2002. Liu KFR. Agent-based resource discovery architecture for environmental emergency management. Expert Systems with Applications 2004;27: 77–95. Juszczyk Lukasz, Schahram Dustdar. A middleware for service-oriented communication in mobile disaster response environments. In: The proceedings of the sixth international workshop on middleware for pervasive and ad-hoc computing, Belgium, 2008. p. 37–42.
619
Meier R, Cahill V. STEAM: event-based middleware for wireless ad hoc networks. In: The 22nd international conference on distributed computing systems workshops (ICDCSW’02), Austria, July 2002. Mian A, Baldonu R, Beraldi R. A survey of service discovery protocols in multihop mobile ad hoc networks. IEEE Pervasive Computing 2009;8(1):66–74. Murphy AL, Picco GP, Roman G-C. Lime: a Middleware for physical and logical mobility. In: Proceedings of the 21st international conference on distributed computing systems (ICDCS-21). May 2001. Musolesi M, Mascolo C, Hailes S. EMMA: epidemic messaging middleware for ad hoc networks. In: Personal and ubiquitous computing. 2005. Ratsimor O, et al. Allia: alliance-based service discovery for ad hoc environments. In: Proceedings of the second international workshop mobile commerce (WMC 02), ACM Press; 2002. p. 1–9. Tyan J, Mahmoud Q. A network layer based architecture for service discovery in mobile ad hoc networks. In: Proceedings of the 17th annual IEEE Canadian conference on electrical and computer engineering (CCECE04), vol. 3. IEEE Press; May 2004. p. 1379–84. Varshavsky A, Reid B, de Lara E. A cross layer approach to service discovery and selection in MANETS. In: Proceedings of the second International conference on mobile ad-hoc and sensor systems (MASS 05), IEEE Press; 2005. Zhu F, Mutka M, Splendor L. A secure, private and location-aware service discovery protocol supporting mobile services. In: Proceedings of the first international Conference on pervasive computing and communication (Per-Com 03), ACM Press; 2003. p. 235–42.