Expert Systems with Applications 39 (2012) 9554–9563

Contents lists available at SciVerse ScienceDirect

Expert Systems with Applications

journal homepage: www.elsevier .com/locate /eswa

A management Ad Hoc networks model for rescue and emergency scenarios q

Rommel Torres b,⇑, Luis Mengual a, Oscar Marban a, Santiago Eibe a, Ernestina Menasalvas a, Byron Maza b

a Facultad de Informática, Universidad Politécnica de Madrid Campus de Montegancedo, 28660 Boadilla del Monte (Madrid), Spainb Laboratorio de Redes y Telecomunicaciones, Universidad Técnica Particular de Loja, Ecuador

a r t i c l e i n f o

Keywords:Ad Hoc networks managementAd hoc routing protocolMANET management

0957-4174/$ - see front matter � 2012 Elsevier Ltd. Adoi:10.1016/j.eswa.2012.02.097

q This work has been supported by SENESCYT (Ecua05924 of Spanish Ministry of Education.⇑ Corresponding author.

E-mail addresses: rovitor@utpl.edu.ec (R. TorrMengual), omarban@fi.upm.es (O. Marban), seibe@fi.ufi.upm.es (E. Menasalvas), bpmaza@utpl.edu.ec (B. Ma

a b s t r a c t

This present research shows the creation of a model for the management of Ad Hoc mobile networkscalled HAMAN (High Availability Management Ad Hoc Networks). The HAMAN model has been struc-tured in layers in which each of the components and interfaces has been formally defined. HAMAN usesa hierarchical routing strategy through subsets of nodes or clusters. In order to improve the hierarchicalrouting and the convergence of the clusters and of the network it is proposed to use a backup clusterhead. The use of a event discrete simulator is used for the implementation of a hierarchical routing pro-tocol called the Backup Cluster Head Protocol (BCHP). Finally it is shown that the BCHP protocol, part ofthe proposed management model, improves the convergence and availability of the network through acomparative analysis with the Ad Hoc On Demand Distance Vector (AODV) (Perkins, Belding-Royer, &Das, 2003) routing protocol and Cluster Based Routing Protocol (CBRP) (Jiang, Li, & Tay, 1999).

� 2012 Elsevier Ltd. All rights reserved.

1. Introduction

The Ad Hoc, MANET (Mobile Ad Hoc Networks) mobile net-works are temporary and self-configurable networks. Its nodescould be its source, destination and a bridge for information. Ithas finite resources (bandwidth, battery, processing) that mustbe well used in order to improve the performance of the whole net-work. In this type of network it is important to collect informationon the state of each of the nodes accurately in such a way that withthe necessary intelligence it is possible to achieve the best manage-ment of the network by maximizing the availability, speed andstate of the network as a whole. For example, if a node has insuffi-cient battery or its processor is saturated, then, in order to notcompromise the availability of the whole network, its participationmust be limited as a bridge or router in the exchange ofinformation.

The continuous improvement in the hardware for equipmentwith end users (telephones and mobile equipment), the improve-ment in the wireless technologies which give rise to an increasein transmission speed and the appearance of new applicationswhich allow the creation of new ways of user interaction whichmakes it necessary for the management of a mobile network effi-cient, light and flexible. The management of an Ad Hoc network

ll rights reserved.

dor) and the project TIN2008-

es), lmengual@fi.upm.es (L.pm.es (S. Eibe), emenasalvas@za).

must fulfil the characteristics of minimum overload, adaptability,flexibility, redundancy and security (Kant & Chadha, 2008).

The need for the management of MANET networks depends di-rectly on the scenario in which the network will be used in such away that in military and emergency scenarios, the managementof the network will be more necessary than in academicscenarios.

When the Ad Hoc networks are used in emergency/militaryscenarios (Dengiz, Konak, & Smith, 2011), the management ofthe networks and the nodes is essential as the health of the per-son that uses the mobile device is indirectly involved. If a deviceis unreachable by the administration system, the network mustset off search and rescue events for the person associated withthe device.

The main objective of this article is to improve the managementof mobile Ad Hoc networks. That is why a management modelbased on layers called High Availability Management Ad Hoc Net-works (HAMAN) is proposed. A hierarchical router protocol for AdHoc mobile networks called the Backup Cluster Head Protocol(BCHP) is also proposed as part of the model. The protocol incorpo-rates the use of redundant Cluster Heads (CHs) with the aim ofimproving the availability of the network.

2. Related work

2.1. Management of the network and management of the network inMANET

The most relevant models in the area of the management of thenetwork are:

R. Torres et al. / Expert Systems with Applications 39 (2012) 9554–9563 9555

� Simple Network Management Protocol, SNMP (Andrey, Festor,Lahmadi, & Pras, 2009).� Common Management Interface Protocol, CMIP.� Web Based Enterprise Management, WBEM.

SNMP is an application layer protocol, developed for the workwith TCP/IP. It uses the User Datagram Protocol (UDP) as a trans-port layer protocol with ports 161 and 162. There are currentlythree versions (Andrey et al., 2009). The SNMP centralized way ofworking in a highly flexible scenario, such as Ad Hoc mobile net-works, gives rise to a simple failure point and an unnecessaryuse of bandwidth and of resources for information that must besent from the administrated nodes to the administrator node(Saravanan, Reuter, & Verma, 2008).

The CMIP protocol is based on the OSI reference model, it sup-ports the exchange of information between applications for han-dling the network and handling agents and is most efficient inthe control of large networks related to the SNMP protocol. Thereis a version of CMIP that works on TCP/IP called the Common Man-agement Information Protocol (CMOT).

WBEM is a series of standards developed by DMTF1 to permitthe management distributed networks, facilitating the informationon different technologies. It uses Hypertext Transfer Protocol (HTTP)for the encapsulation of the information and Extensible Markup Lan-guage (XML) as a language for the description of the messages.

The development of a management system for Ad Hoc networkshas been dealt with by several authors. In the models based onevents and node status, the bandwidth consumption and the useof resources of the nodes is moderate. However, this approach actsin a reactive manner and not proactive which implies the conver-gence time of the network is not the most convenient for the net-work management.

In Shen, Jaikaeo, Srisathapornphat, and Huang (2002) the com-patibility with existing network management systems (SNMP) ismaintained, where the nodes with little capacity (processing andenergy) are the administrated nodes, while those with a largecapacity act as collectors of management information.

For a large sized Ad Hoc network (Basagni, Turgut, & Das,2001a) the use of a backbone protocol is proposed, in which thenodes in the best state of health act as an information bridge. Thisstrategy divides a large network into more manageable adminis-tration areas. This approach is useful to network management,since the nodes belonging to the backbone, could be useful astrustworthy nodes and for the collection of information, thusimproving its availability.

There is also the development of policy-driven mobile Ad Hocnetwork management systems. Kant and Chadha (2008) define acomplete system based on policies that are hierarchically distrib-uted. This focus allows a saving in bandwidth as the nodes havethe intelligence (the policies) to apply the configuration definedin the policies.

The management based on the policies proposed in Kant andChadha (2008) and Chadha et al. (2004), focus on the collectionand sending of management information. In order to reduce theload on the network, an administrator node of a cluster (theadministrated part of the Ad Hoc network) summarizes the infor-mation on the state of the network before sending it.

Liu, Sacchetti, Sailhan, and Issarny (2005) use grouping tech-niques for the management of MANET networks. However, it onlydoes it at the transport and application layer level.

Grigoras and Riordan (2005) created two algorithms for the cre-ation, the partition and the union of Ad Hoc mobile networks forthe management of an Ad Hoc network. It is based on the identifi-

Fig. 1. Cluster ad hoc network.1 Distributed Management Task Force. http://www.dmtf.org.

cation of the network, of the node and the messages sent betweenthe nodes that need a service or an application.

SNMP behaves better than WBEM in the MANET network envi-ronment with a hierarchical routing (Pras, Drevers, van de Meent,& Quartel, 2004) as the number of nodes per cluster is limited bythe area or coverage, the mobility of the nodes and by the sharedbandwidth.

2.2. Hierarchical routing

The OSI network layer (Ali, Ahmad, & Aljunid, 2008; Im, Wu, &Lee, 2011), is where the Ad Hoc network processes take place andare identified. In this way the improvement efforts in this layer aredirectly visible in the upper layers.

The Ad Hoc network routing protocols are generally grouped to-gether as proactive, reactive and as a hierarchical router.

The proactive routing protocols keep information about all ofthe routes in the network, thus they are not required. Each nodemaintains routes on all of the nodes of the network. The Destina-tion-Sequence Distance- Vector routing (DSDV) protocol is anexample of this type of protocol.

The reactive routing protocols generate routes on demand whenone node wants to communicate with another. There are, in gen-eral, two components: discovering the route used when a sourcedoes not know how to get to a destination and the route mainte-nance to deal with failure in the routes brought about by mobilityin the nodes. The Ad Hoc Demand Distance Vector (AODV) protocolproposed in Perkins et al., 2003 is an example of a reactiveprotocol.

The hierarchical routing protocols divide the network into sub-sets (Ramrekha, Talooki, & Politis, 2010) of nodes called clusters, inwhich a cluster head is used to concentrate and distribute theinformation generated within the cluster. An example of this typeof protocol is the Cluster Based Routing Protocol (CBRP) (Jianget al., 1999). Fig. 1 shows the basic components of a hierarchicalrouting protocol.

While more nodes become part of a MANET network, the hier-archical router protocols are managed better than the reactive andproactive protocols. In these scenarios the reactive protocols havethe disadvantage of the overload that involves maintaining theinformation on the entire network. The proactive protocols are

9556 R. Torres et al. / Expert Systems with Applications 39 (2012) 9554–9563

slower in achieving the convergence of the network as they mustexchange information between a greater number of nodes.

This research focuses on improving the sublayer process of anAd Hoc network using hierarchical routing with so as to achievethe greatest possible availability for the management processes.

There are several studies (Biradar & Patil, 2006, Wu, Chen, &Chen, 2011) that identify and group hierarchical routing protocols.These hierarchical routing protocols and strategies center on thechoice of Cluster Head and the maintenance of the clusters anddo not focus on improving the availability of the whole network,as happens in this research.

Yassein and Hijazi (2010) propose the inclusion of a backupcluster head node. However, the objective of this work is limitedsolely to the network layer.

This research is different from previous work as it integrates thehierarchical routing based on weights with the strategy of themanagement models proposed by Liu et al., 2005 and Grigorasand Riordan, 2005. It also improves the management through theuse of redundancy for the main nodes. A hierarchical routing calledthe BCHP (Backup Cluster Head Protocol) has been implementedwhich is part of the HAMAN management model.

Fig. 3. Model proposed for the MANET network management.

3. HAMAN, management model proposed for Ad Hoc mobilenetworks

The network management model for Ad Hoc mobile networks isgenerally made up of four elements: the managed nodes, the man-agement server, the protocol for the sending of information be-tween nodes and a standard representation of the managementinformation.

The HAMAN management model proposed has additionallyspecified and abstraction of the model by dividing it into levels thatdetermine how they are related and how to carry out the exchangeof information of the nodes.

Of all of the studies analyzed, it can be appreciated that none ofthem deal with the solution to the problem of high availability andthe efficiency of the management of the MANET networks. What ismore, the majority of the works presented to date involve solutionsto the layer level of the network and transport, yet do not resolvethe problem of the availability of the service in its totality. Theyonly resolve very specific and concrete problems in a very limitedapplication environment.

This research work resolves the problems of the availability andefficiency of the MANET management networks by using a four-layer architecture and redundancy nodes for the cluster head andthe administration server of the network. Fig. 2 shows the distribu-tion in layers proposed for the management and Fig. 3 shows the

Fig. 2. Levels of interaction.

components of an Ad Hoc network including the backup heads,the administration server and the backup administration server.

The division of the Ad Hoc network into clusters allows theoverload of the network to be reduced as the communication be-tween the clusters is concentrated and a dominant set of Clusterheads is produced. The nodes belonging to this dominate seriescommunicate between themselves by means of a mesh networkmaking up a backbone. The function of the backbone is to transportthe information between the nodes and the Administration Server(AS). The Backup Administration Server (BAS) is the redundantnode of the Administration Server (AS).

In each cluster a Cluster Head (CH) will have a node called theBackup Cluster Head (BCH) which will take the main functions ofthe cluster in case of a failure in the main mode. The BCH maintainsa periodical communication with its CH in order to obtain updatedmanagement information on the nodes of the cluster and informa-tion of the state of the CH. The convergence of the network is im-proved by means of the BCH as the cluster does not make a newchoice of CH.

A protocol has been developed for the validation of the Ad Hocnetwork model called the BCHP (Backup Cluster Head Protocol)based on the Cluster Based Routing Protocol (CBRP). The processesfor the choice of the BCH are implemented in the BCHP protocol asis the communication between the CH and its backup.

The implementation of the BCHP protocol is carried out using aevent discrete simulator NS2 (Kim & Shin, 2011). There are othersimulators that include MANET: OPNET,2 OMNeT++,3 GloMoSim,4

NS3,5 and QUALNET.6 However NS2 has been chosen as:

� The NS2 simulator is the one most used by researchers inMANET networks. Of the total amount of research papers pub-lished that mention the use of a simulator in ACM7 ACM7

2 OPNET, Application and Network Performance. http://www.opnet.com.3 OMNet++, Discrete event simulation environment. http://www.omnetpp.org.4 GloMoSim – Global Mobile Information Systems Simulation Library. http://

pcl.cs.ucla.edu/projects/glomosim/.5 The ns-3 network simulator. http://www.nsnam.org/.6 QualNet. http://www.scalable-networks.com/products/qualnet/.7 Association for Computing Machinery. http://www.acm.org.

R. Torres et al. / Expert Systems with Applications 39 (2012) 9554–9563 9557

43.8% use NS2. The following most used simulator in use, theGloMoSim, is used by 10% (Kurkowski, Camp, & Colagrosso,2005).� Experience and knowledge of the way the simulation tool

works.� It is free and open source allowing new protocols and function-

alities to be added.

3.1. Layers or levels of the HAMAN management model

The division of the model into levels serves to improve andfacilitate the focus and development of each process or protocoldescribed. As can be seen in Fig. 2, the model is based on a hierar-chical architecture in which four levels of interaction are defined:

1. Access level: given by the interaction of the NM, including theinformation between the NM and the CH and BCH. The pro-cesses for the choice and synchronization of the CH and theBCH are carried out at his level.

2. Distribution level: given by the interaction between the CH,including the communication with the AS and BAS nodes. Theprocesses for the creation of the mesh network or backbonebetween the CH nodes (Basagni, Turgut, & Das, 2001b) nodesfor the distribution of the management information and thechoice and synchronization of the SA and the BAS are carriedout at his level.

3. Intelligence level: The software necessary for storing, processingand sending actions based on the management informationstored is found at this level.

4. Link level: The MANET networks can communicate with aninfrastructure network. In the proposed model, in the best ofcases, a Backup Administrative Server (BAS) must be locatedin the infrastructure network.

3.2. HAMAN management model components

As can be seen in Fig. 3, the network is divided into groupscalled clusters. Each cluster has a cluster head node (HC) and atleast one Backup Cluster Head (BCH) and an arbitrary number ofManaged Nodes (MN) at a radius of two-hop in the transmissionrange of its Cluster Head. The Ad hoc network has main manage-ment servers (CH) and a backup (BCH). The CH is a central admin-istrator which will be chosen from among all of the cluster heads.

The protocols used for the sending of information are: UDP inthe transport layer, Backup Cluster Head Protocol (BCHP) in theAd Hoc network and SMNP for the collection of managementinformation.

The topology discovering process is carried out periodically inorder to maintain the network in convergence and synchronizethe information in all of the nodes.

Fig. 4. Architecture of t

All of the nodes implement the action received from the SAthrough its corresponding CH.

3.2.1. Managed Nodes (MN)Three types of managed nodes are defined in the proposed man-

agement model:Managed Node (MN): These are all of the devices that are part of

the cluster and contain management information shared with theCH. As can be seen in Fig. 4, an MN has management objects, suchas network cards. At the same time, the management objects main-tain management information related to the object, for example,the number of errors in the transmission.

Additionally the MN has software (Agent) which collects, repre-sents, summarizes and encrypts the control information. In ourmodel the MN has a database similar to a management informa-tion base (MIB) in which the information on the identification ofthe CH and BCH is saved. It is the same one used for the sendingof management information when there are problems with theCH node.

The MN, at the same time, also manages its membership andthe degree of interactivity within the cluster.

Selfish Node (SN): The SN is an MN that does not want its re-sources to be used as an information-forwarding node and explic-itly, stops providing information on its state to the CH.

The SN can change its state at the MN sending a change statenotification together with the corresponding management infor-mation to the CH.

Silence Node (SN): The SN is a node which does not have the re-sources necessary either for installation or for the functioning ofthe agent. Therefore, it cannot communicate directly with theCH. However, it can use the resources of the network such as theexisting band width.

3.2.2. Cluster headThe CH node is an MN that has better features than the rest of

the nodes belonging to a cluster. The CH sends the managementinformation collected in the MN to an SA (Fan, Cao, & Wu, 2011).The node is selected as a Cluster head when it has the best metrics.The metrics of the node is calculated based on the followingcriteria:

� Resources available of the node, for example, free capacity forprocessing, memory, band width.� The node with the lower mobility (change of topology).� Range of transmission.� Level of battery power.

The CH node also maintains a MIB where the information on allof the nodes is stored and later sent to the SA.

he Managed Node.

9558 R. Torres et al. / Expert Systems with Applications 39 (2012) 9554–9563

In the network the CHs make up a mesh network to send theinformation to the SA. This mesh network is called a backbone.For the creation and functioning of the backbone it might be nec-essary to use bridge nodes. A bridge node is any node that is nota CH which allows information to be distributed between CH nodesin different clusters.

3.2.3. Backup cluster headThe Backup Cluster Head, BCH, is the second best node, chosen

during the same process as the selection of the CH. All of the nodesbelonging to the cluster keep the reference of the CH and BCHnodes. This allows the convergence of the all of the network tobe accelerated should there be an event that does not permit thework of the CH.

The main purpose of the BCH is to improve the availability. Itinteracts with the MN and the CH. When the CH fails, this nodeautomatically takes on the CHs functions and immediately invokesthe selection process of the new BCH.

The BCH and the CH maintain periodical synchronization ses-sions in order to validate the integrity of the information. In thebest of cases the management information stored in the CH mustbe the same as that in the BCH.

3.2.4. Administration serverThe AS is a CH with the best features. Its main task is the collec-

tion and storage in their managed information base all of the infor-mation compiled from the different nodes and all of the networksent by the CH.

The AS only interacts with each of the CHs for the exchange ofinformation. It periodically collects management information fromthe nodes (state of the resources of the available nodes) and con-trols all of the management activity with the aim of updating thenetwork and has the current state of the network.

In order to improve the availability of the network in general,the AS can carry out pre-defined actions to events in the networkand can distribute them by means of the CHs. It must also alertthe administrator of events that are out of its control or presentstendencies to reduce the state of the network.

3.2.5. Backup administration serverIt takes the place and functions of the AS when it detects a fail-

ure. The use of two BASs is proposed; one within the Ad Hoc net-work and the other at the link level inside of an infrastructurenetwork.

There is a periodical update between the AS and the SAR to-gether with a synchronization of the management information ofthe network. Communication between them is by means of thebackbone of the CH nodes.

3.3. Communication interfaces of the HAMAN model

The communication interfaces existing between the differentcomponents of the model are detailed in this section. As can beseen in Fig. 5 the communication interfaces are defined by the rela-tionship between each of the nodes and the components of themodel.

3.3.1. Interface 1. Communication between NM and NMThe managed nodes communicate between each other to make

up a cluster and to carry out the selection of the CH and BCHmodes. A variant of the Weighted Clustering Algorithm (WCA)algorithm is proposed for the formation of the cluster. The objec-tive of this variant is for the MN nodes to register the second-bestnode or the BCH node and that all of the MN nodes saves referenceinformation of the CH, BCH and AS nodes. This information will be

used to accelerate the sending and reception of the managementinformation.

Algorithm 1 shows the process for the formation of the clusterand for the choice of the CH and the BCH that is implemented ineach node in the network.

Algorithm 1:Cluster formation and choice of CH and the BCH

Require: Routing table of the neighbor nodes K = {r1, . . . ,rn}.Ensure: Node Status (bn) updated from M = {UNDECIDED,

MEMBER,JC,JCR}.1: if (bn = UNDECIDED) then2: bn JC3: while (K – /) do4: Obtain the neighbors from ri de K5: Obtain neighbor status ur and neighbor metric tr6: end while7: Sort K by tr8: First First Kr9: Second Second Kr10: if (Firstu \ {UNDECIDED,MEMBER,JCR}) then11: if (nt P Firstt) then12: bn JC13: else if (Firstu = JC) then14: if (nt P Firstt)15: bn JC16: else if (nt P Secondt)17: bn JCR18: else19: bn MEMBER20: end if21: end if22: end if23: end if24: return bn

3.3.2. Interface 2. Communication between NM and CHThe managed nodes communicate with the Cluster Head for the

sending and reception of the management information. The use ofthe proposed Ad Hoc routing protocol, Backup Cluster Head Proto-col (BCHP), is necessary as the MN and the CH can be two-hopsfrom the transmission range.

3.3.3. Interfaces 3 and 5. Communication between CH/CH and CH/SAThe CH nodes, those with the best features, create a logical com-

munication between each other called backbone or mesh. As it is alogical communication, the presence of a nodes gateway (GN) isnecessary. The CH nodes periodically send, or send on demand,the compressed management information of the cluster to the SAby means of a mesh or backbone network made up of the CHs. Thisbackbone is used for the sending of management information fromthe AS to all of the nodes belonging to the network.

3.3.4. Interface 4 and 6. Communication between CH/BCH and SA/SARThe communication between the CH and the BCH is part of the

contribution of our research. This communication includes twoprocesses: synchronization of the information between the CHand BCH nodes and knowledge on the unavailability both of theCH node and the BCH node. It is propose that the two processestake place using the same strategy: the use of synchronizationmessages and its respective acknowledgment receipt to determineand provide information on the availability of the CH and BCHnodes.

Fig. 5. Communication interfaces.

R. Torres et al. / Expert Systems with Applications 39 (2012) 9554–9563 9559

When the CH is not available, the BCH node will use the infor-mation from the previous registered update and will provide infor-mation on the new state to the MN nodes. As the NM has thereference information of the BCH, they identify this as a new CHand the management information is sent to it. The new CH againinvokes the algorithm in order to choose a new BCH.

When the BCH node is not available, the CH node does not ob-tain the acknowledgment receipt of the synchronization (failedsynchronization), then the CH node invokes the algorithm againin order to choose a new BCH.

There is a total synchronization between the CH and the BCHnodes based on the periodical exchange of their MIB. The synchro-nization interval can be adjusted in accordance with the scenariosin which the proposed management model will be used. This pro-cess is initiated by the CH and the information is confirmed by theBCH by means of an acknowledgment of receipt.

The determination of the availability of the CH and the BCH willbe by means of periodical messages also used by the synchroniza-tion processes and updating of the information. There are threeevents that identify failures in the main nodes:

� The BCH node does not receive periodic updates of the manage-ment information.� The CH node does not receive an acknowledgment of receipt in

the determined periods.� The MNs send management information to the BCH node as it

has been determined that the CH node is not available.

By using similar strategies, the AS and the BAS communicate atdefined time periods in order to update its management informa-tion base with the aim of the BAS taking the place of the AS in caseof failure.

4. Backup cluster head protocol specification hierarchicalrouting protocol

This section describes the stages of the Backup Cluster HeadProtocol, BCHP protocol. The BCHP has been developed based onthe CBRP protocol. The main difference between the BCHP andthe CBRP is the improvement in the availability of the networkthrough the inclusion of the BCH nodes.

The BCHP protocol has three clearly defined steps: creation,maintenance and routing between clusters.

4.1. Creation of the cluster

When the nodes begin they do not belong to any cluster andthey start their state as UNDECIDED. They calculate a valuecalled a metric in accordance with the speed characteristics,state of the battery and location within the cluster. It later sendsits state together with the value of its metric to all of the nodesby means of broadcast messages. With these values each nodecreates its routing table and determines which neighbors havebidirectional links towards it. This information serves to deter-mine the two nodes with best characteristics and that the CHand BCH can be chosen. Each node stores the address of theCH and the BCH in order to accelerate the routing process. Algo-rithm 1 shows the creation of the cluster and the choice of theCH and the BCH.

4.2. Maintenance of the cluster

The movement of the nodes, the consumption of energy andfailure of the CH node cause the cluster change in density and loca-tion. They are also able to divide or unite which is why in order tomaintain the convergence of the network it is important to main-tain the hierarchy of the cluster.

When several clusters are united it is possible for the CH to bewithin the area of coverage of another CH node, in which case aperiod of contention is initiated. After the period of contention ex-pires the CH node is chosen again as is the BCH of the new cluster.

When a CH is not available the BCH takes on the value of the CH.The BCH node determines that the CH node is not availablethrough the use of periodical messages and the updating of thetransmission between them. When the BCH node assumes thehierarchy, it becomes the CH and sends a message by broadcastto all of the nodes of the cluster informing on the new state. Againit is chosen the new BCH node.

4.3. Routing between clusters

There are three levels of routing:

1. Within the transmission area: in which the nodes can bereached directly since they have a bidirectional scope betweenthem and are directly visible. Here the source node sends theinformation directly to the destination node.

Table 1Inclusion of the BCHP protocol in NS2.

File Detail

ns-2.34/common/packet.h

The method of accessing the heading of the packetBCHP is defined. The BCHP packet is included in thelist recognized by NS2. It defines BCHP as a routingprotocol. It defines the word BCHP in order to identifythe protocol in the trace archives

ns-2.34/trace/cmu-trace.h

Declaration of the functions of the trace register

ns-2.34/trace/cmu-trace.cc

Inclusion of the BCHP in the heading libraries of thepacket. Implementation of the function of the traceregister. Obtaining the displacement of the BCHPheading with respect to the packet

ns-2.34/tcl/lib/ns-packet.tcl

Add the heading of the BCHP packet to the generalpacket

ns-2.34/tcl/lib/ns-lib.tcl

Initialize the routing agent in the OTcl environment.Allow the coexistence of the BCHP and other routingprotocols in the case that there is a base station.Define the node as a BCHP node. Link the agents tothe nodes with the routing protocol, in the case theBCHP

ns-2.34/tcl/lib/ns-mobilenode.tcl

Implementations of the functions of the OTcl toinstantiate and relate the agent and the routingprotocol in the simulator

ns-2.34/Makefile Include the source code so that it is compiled with thesimulator

9560 R. Torres et al. / Expert Systems with Applications 39 (2012) 9554–9563

2. Within the cluster: here the nodes communicate directlyamong themselves through their table of neighbors. Each nodemaintains a routing table of neighbors in which the address ofthe node can be obtained which will serve as a router in orderto reach its destination.

3. Outside the cluster: where each CH concentrates the informa-tion and sends it towards the destination cluster. One nodedetermines that there is now way towards the destination oncethe packet is delivered to the Cluster Head. The Cluster Headcontains an additional routing table for communicationbetween clusters. The CH sends the information to the destina-tion cluster or by dissemination to all of the CH nodes, depend-ing on whether it has an entry in the routing table to thedestination node.

5. Inclusion of the BCHP protocol in NS2

This section shows the process of how to include the BCHP pro-tocol in the NS2 simulation tool. This process includes the creationand location of the structure of the archives and directories properto the protocol and the changes that need to be carried out to thesimulator archives.

5.1. Definition of the physical structure

In order to include the BCHP protocol into the simulator, adirectory called the BCHP must be created within the main folderof the protocol, in which the following files which are used as li-braries and source code are placed:

� bchpagent.h: Definition of the properties and methods of theBCHP agent.� bchpagent.cc: The methods of the BCHP agent are to be found in

this file. Constructors, methods for the reception and sending ofthe routing protocol packets, methods for the handling of com-munications errors and failings.� bchpntable.h: Definition of the property types and methods for

the handling of the routing tables of the protocol.� bchpntable.cc: The source code for the implementation of the

methods and access to the properties of the types that definethe routing of the BCHP protocol are found here. The implemen-tation for the managing of timers is also found here. It alsoincludes the processes for the creation and maintenance ofthe clusters.� bchp_packet.h: The structure of the BCHP packet that will be

used for sending and receiving the protocol is defined.� hdr_bchp.h: It defines the heading of the BCHP packet, its meth-

ods and properties.� hdr_bchp.cc: The implementation of the types necessary for the

integration between the types defined in C++and OTcl are foundhere.

5.2. Changes made to the simulator

The files defined in Table 1 were modified to include the BCHPprotocol at the simulator.

6. Validation of the proposal

6.1. Mathematical validation

The availability of an Ad Hoc network is dependent on the prob-ability that there is a BCH in each cluster. In order to calculate theavailability, it is necessary to obtain the probability that there is aBCH.

In this manner, an Ad Hoc network that uses a hierarchical rout-ing can be expressed in the following terms (Bettstetter, 2004):

Ri ¼ ðar0;nÞ ð1Þ

Where Ri is a specific cluster, r0 is the transmission range of thenode, a is a factor that identifies the area of coverage expressed inthe transmission range and n is the number of neighbors of thenode located within the area of coverage.

A node could be CH and BCH base in its situation and the num-ber of neighbors. The situation of the node is defined by a series offactors proper to the node which include the state of the node (bat-tery), the speed of the movement of the node and the position orlocation of the node within the cluster. The values can be ex-pressed in the following way:

The state of a node, defined by pe, can have two values, on or off.The speed of the node, defined by pv, on a Cartesian plane

A = x � y, directly effects the choice of the CH, because if the nodeis slower than its neighbors it has a greater probability of beingchosen as the CH. In such a way that:

Mv i ¼1T

XT

t¼1

ffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiðXt � Xt�1Þ2 þ ðYt � Yt�1Þ2

qð2Þ

where Mvi > 0 ^Mv1 6 Vmax. Vmax

Then

pv ¼1

Mv ið3Þ

The location of the node, pu, defined in terms of the transmissionrange of the del node, r0, is given by:

pu ¼ pðr0Þ2=b; ð4Þ

Where b > 0 ^ b <= n, determines the area of incidence of the CHnode. Where the smaller the area of incidence, the closer the nodeis to the cluster.

The number of neighbors is an independent characteristic of thenode and is indirectly proportional to the probability, pCH of itbeing elected CH. While the more nodes that there are, the lessthe probability that a node in particular is elected.

Finally the probability that a node is elected CH, is given by:

Fig. 6. Emergency and rescue scenario for the city of Loja.

8 NS2, The Network Simulator. http://www.isi.edu/nsnam/ns.

R. Torres et al. / Expert Systems with Applications 39 (2012) 9554–9563 9561

pCH ¼1n� pu þ pv þ pe

3ð5Þ

n P 1

The BCH being the node with the following metric less than the CH,a potential CH node, it can be mentioned that the probability thatthere is a BCH is the same as the probability that there is m clusterheads. Therefore:

pBCH ¼ 1� pmCH ð6Þ

m P 2 ^m 6 n� 1

The probability that there is a BCH has been determined in Eq. (6)With this information the availability of the network is calculated:

In the first place the calculation on the availability for just oneCH is carried out, and the representation as gCH, is a randombinominal variable which assumes the values of {1,2, . . . ,r}, thenthe P(gCH = i) is given by:

PðgCH ¼ iÞ ¼Xr

i¼1

r!

ðr � iÞ!i!

� �pi

CHqr�iCH ; ð7Þ

r P 1

Now we show that by adding one or more BCH it improves the effi-ciency or availability of the Ad Hoc network. For this case we definethe availability as gBCH. Then:

PðgBCH ¼ iÞ ¼Xr

i¼1

r!

ðr � iÞ!i!

� �pi

BCHqmðr�iÞCH ; ð8Þ

r P 1

Finally, from (7) and (8) we conclude that:

PðgBCH ¼ iÞ > PðgCH ¼ iÞ

Therefore the availability of an Ad Hoc network with CHR is betterthan with just one CH.

6.2. Validation by simulation

The NS28 a event discrete simulator is used to validate the BCHPprotocol. The scenarios are defined for the simulation and an analy-sis of the results is carried out.

6.2.1. Definition of the emergency and rescue scenarioIn order to validate the simulation a real scenario has been used.

The scenario comprises part of the map of the city of Loja in Ecua-dor, defined in a rectangular area of 1 km by 0.5 km. This area in-cludes the historical and commercial part of the city. Obstacleshave been randomly defined in the streets simulating the occur-rence of an undesired event. The upper part of Fig. 6 shows amap of the city before the undesired event, and the lower part de-tails the obstacles.

For the effects of the simulation, the nodes are randomly placedin the spaces free of obstacles, for example, in the streets orsquares. The evacuation points are placed randomly (the pointsthat are the objective of the movement of the nodes).

With these parameters a mobility model for emergency and res-cue scenario has been implemented, in which the nodes move at arandom speed and in the direction of the nearest evacuation point.

Table 2General parameters for the simulation.

Parameters Values

Simulation area 1000 m � 500 mMobility model Emergency and rescueNumber of nodes 25, 30, 40, 50, 60, 70, 80, 90, 100Number of connexions 20Simulation time 150 sProtocols of the network

layerCBRP, BCHP and AODV

Protocols of thetransport layer

Transmission Control Protocol (TCP) and ConstantBitrate (CBR)

Propagation model TwoRayGroundType of antenna Omnidirectional

Fig. 7. Rate of sent packets.

Fig. 8. Rate of application sent packets.

Fig. 9. End to End delay.

Fig. 10. Average of Packet delay Variation.

9562 R. Torres et al. / Expert Systems with Applications 39 (2012) 9554–9563

Every time a node reaches an intersection or comes across anobstacle it generates a pause in order to determine the followingdirection and destination.

The final objective is the generation of evacuation routes foreach of the nodes. The generation time of the routes must be theminimum possible, which is why the choice of a routing protocolis determinant for this type of scenario.

6.2.2. Parameters for the simulationIn order to define the simulation scenarios, the parameters de-

scribed in Kurkowski, Navidi, and Camp, 2007. have been used as abasis. The values for each of these parameters are shown in Table 2.

For the analysis of the results, some authors Andrey et al.(2009), Chenna Reddy and ChandraSekhar Reddy (2006), Karaoglu,Numanoglu, and Heinzelman (2011), Seno, Budiarto, and Wan(2011), and Xu, Borcea, and Iftode (2011) have revised the seriesof indicators. In order to evaluate the BCHP protocol, particularindicators have been selected to measure the availability of thenetwork. These indicators are: performance, overload, loss of pack-ets, average delay and the variation in the delay of the packet or jit-ter. These indicators have been compared with those obtained forthe CBRP Jiang et al. (1999) and the AODV Perkins et al. (2003)protocol.

7. Results of the simulation

7.1. Rate of sent packets

The rate obtained between the sent packets for the number ofpackets received. As the formation and maintenance of the clusterneeds the exchange of packets in order to have updated packets, itcan be seen in Fig. 7 that the CBRP and BCHP hierarchical routingprotocols have a greater send rate than AODV, while the BCHP

R. Torres et al. / Expert Systems with Applications 39 (2012) 9554–9563 9563

protocol in general has a send rate slightly greater than the CBRPprotocol as it maintains a more stable formation of the cluster.

Fig. 8 shows the send rate of the packets on an application level.The protocol is better because it is closer to one. When TCP areused, in AODV, the reason for sending is slightly better than thehierarchical routing protocols, while between BCHP and CBRP itis similar, CBRP being slightly better. When CBR connections areused the hierarchical router protocols are equally efficient betweenthem and better than AODV.

7.2. Average delay

For our purpose, it is a very significant measurement as it isdesirable to send and receive network management informationas fast as possible.

In Fig. 9 the BCHP protocol the average extreme delay is slightlybetter than CBRP when the density of the nodes is less than 70nodes and it is used as traffic connections with TCP. When CBRconnections are used, the hierarchical routing protocols developwell compared to AODV. This means that the use of a hierarchicalrouting is the best option with traffic not oriented to theconnection.

7.3. Packet delay variation

It is the difference in the delay between extreme to extremeconnections between selected packets. In an Ad Hoc network itserves to measure the stability and convergence of the network.As can be seen in Fig. 10, the average packet delay variation hasbeen obtained for the entire network. The dynamic router proto-cols function better than AODV. The BCHP protocol has a bettervariation.

8. Conclusions and future work

A new management model for mobile networks called HighAvailability Management Ad Hoc networks (HAMAN) has been pre-sented, made up of four layers or levels. All of the components andcommunication interfaces of the model have been defined.

As part of the management model a hierarchical routing proto-col has been implemented, which has been called the Backup Clus-ter Head Protocol (BCHP). The BCHP protocol includes the use ofthe Backup Cluster Head node. It has been demonstrated that theBCHP improves the availability and convergence of the networkcompared to the AODV and CBRP protocols.

It has been determined that the use of the HAMAN managementmodel, together with the use of the BCHP hierarchical model, issuitable for emergency and rescue scenario.

The Backup Cluster Head acts in a reactive manner when thereis an event in the network that gives rise to a failure in the clusterhead. It is proposed to include a proactive behavior for the head ofthe backup cluster in future work for when the limits of use of re-sources of the cluster head are reached.

References

Ali, N. Z., Ahmad, R. B., & Aljunid, S. A. (2008). Link availability estimation for routingmetrics in MANETs: an overview. Time, 6–8.

Andrey, L., Festor, O., Lahmadi, A., Pras, A., et al. (2009). Survey of SNMPperformance analysis studies. International Journal of Network Management,19, 527–548.

Basagni, S., Turgut, D., & Das, S. (2001a). Mobility-adaptive protocols for managinglarge ad hoc networks. In IEEE international conference on communications. ICC2001 (vol. 5, pp. 1539–1543).

Basagni, S., Turgut, D., & Das, S. (2001b). Mobility-adaptive protocols for managinglarge ad hoc networks. In IEEE international conference on communications. ICC2001 (vol. 5, pp. 1539–1543).

Bettstetter, C. (2004). The cluster density of a distributed clustering algorithm in adhoc networks, in: IEEE international conference on communications (vol. 7, pp.4336–4340).

Biradar, R., & Patil, V. (2006). Classification and comparison of routing techniques inwireless ad hoc networks. In: International symposium on ad hoc and ubiquitouscomputing. ISAUHC ’06 (pp. 7–12).

Chadha, R., et al. (2004). Policy-based mobile ad hoc network management. InProceedings of the fifth IEEE international workshop on policies for distributedsystems and networks. POLICY 2004 (pp. 35–44).

Chenna Reddy, P. & ChandraSekhar Reddy, P. (2006). Performance analysis of adhocnetwork routing protocols. In International symposium on ad hoc and ubiquitouscomputing. ISAUHC ’06 (pp. 186–187).

Dengiz, O., Konak, A., & Smith, A. E. (2011). Connectivity management in mobile adhoc networks using particle swarm optimization. Ad Hoc Networks, 9,1312–1326 [PT: J; TC: 0; UT: WOS:000292622200016].

Fan, X., Cao, J., & Wu, W. (2011). Contention-aware data caching in wireless multi-hop ad hoc networks. Journal of Parallel and Distributed Computing, 71, 603–614[PT: J; TC: 0; UT: WOS:000288354500008].

Grigoras, D., & Riordan, M. (2005). Service driven mobile ad hoc networks formationand management. In The 4th international symposium on parallel and distributedcomputing. ISPDC 2005 (pp. 191–198).

Im, J. H., Wu, H., & Lee, D. J. (2011). Optimal cluster-based routing scheme usingnode mobility in ad hoc networks. Wireless Networks, 17, 921–935 [PT: J; TC: 0;UT: WOS:000289730300008].

Jiang, M., Li, J., & Tay, Y. C. (1999). Cluster based routing protocol (CBRP) functionalspecification, internet draft. MANET working group.

Kant, L., & Chadha, R. (2008). MANET management: industry challenges & potentialsolutions. In 2008 International symposium on a world of wireless, mobile andmultimedia networks. WoWMoM 2008 (pp. 1–8).

Karaoglu, B., Numanoglu, T., & Heinzelman, W. (2011). Analytical performance ofsoft clustering protocols. Ad Hoc Networks, 9, 635–651 [PT: J; SI: SI; TC: 0; UT:WOS:000288522700013].

Kim, K. H., & Shin, K. G. (2011). Self-reconfigurable wireless mesh networks. IEEE–ACM Transactions on Networking, 19, 393–404 [PT: J; TC: 0; UT:WOS:000289845700008].

Kurkowski, S., Camp, T., & Colagrosso, M. (2005). MANET simulation studies: theincredibles. SIGMOBILE – Mobile Computing and Communications Review, 9,50–61.

Kurkowski, S., Navidi, W., & Camp, T. (2007). Discovering variables that affect manetprotocol performance. In IEEE global telecommunications conference. GLOBECOM’07 (pp. 1237–1242).

Liu, J., Sacchetti, D., Sailhan, F., & Issarny, V. (2005). Group management for mobileAd Hoc networks: design, implementation and experiment. In Proceedings ofthe 6th international conference on mobile data management. ACM (pp. 192–199).

Perkins, C., Belding-Royer, E., & Das, S. (2003). Ad hoc on-demand distance vector(AODV) routing.

Pras, A., Drevers, T., van de Meent, R., & Quartel, D. (2004). Comparing theperformance of SNMP and web services-based management. IEEE Transactionson Network and Service Management, 1, 72–82.

Ramrekha, A., Talooki, V., & Politis, C. (2010). Energy efficient and scalable routingprotocol for extreme emergency ad hoc communications. Mobile Networks andApplications.

Saravanan, P., Reuter, E., & Verma, S. (2008). Enhancing enterprise networkmanagement using smart. In Annual IEEE India conference. INDICON 2008 (vol.2, pp. 343–348).

Seno, S. A. H., Budiarto, R., & Wan, T. C. (2011). A routing layer-based hierarchicalservice advertisement and discovery for MANETS. Ad Hoc Networks, 9, 355–367[PT: J; TC: 0; UT: WOS:000287285300010].

Shen, C. C., Jaikaeo, C., Srisathapornphat, C., & Huang, Z. (2002). The guerrillamanagement architecture for ad hoc networks. In Proceedings of the MILCOM2002 (vol. 1, pp. 467–472).

Wu, S. H., Chen, C. M., & Chen, M. S. (2011). Collaborative wakeup in clustered adhoc networks. IEEE Journal on Selected Areas in Communications, 29, 1585–1594[PT: J; TC: 0; UT: WOS:000294133200008].

Xu, G., Borcea, C., & Iftode, L. (2011). A policy enforcing mechanism for trusted adhoc networks. IEEE Transactions on Dependable and Secure Computing, 8,321–336 [PT: J; TC: 0; UT: WOS:000288453700001].

Yassein, M. & Hijazi, N. (2010). Improvement on cluster based routing protocol byusing vice cluster head. In Fourth international conference on next generationmobile applications, services and technologies (NGMAST) (pp. 137–141).