Journal of Network and Computer Applications 34 (2011) 1883–1893

Contents lists available at ScienceDirect

Journal of Network and Computer Applications

1084-80

doi:10.1

n Corr

E-m

sochoa@

messeg

dolors@

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

A communication infrastructure to ease the development of mobilecollaborative applications

Juan Rodrıguez-Covili a,n, Sergio F. Ochoa a, Jose A. Pino a, Roc Messeguer b, Esunly Medina b, Dolors Royo b

a Department of Computer Science, Universidad de Chile, Santiago, Chileb Department of Computer Architecture, Universitat Polit�ecnica de Catalunya, Barcelona, Spain

a r t i c l e i n f o

Article history:

Received 16 September 2010

Received in revised form

16 November 2010

Accepted 11 December 2010Available online 19 December 2010

Keywords:

Mobile communication infrastructure

Development of mobile collaborative

applications

Services reuse

MANET

Loosely coupled work

45/$ - see front matter & 2010 Elsevier Ltd. A

016/j.jnca.2010.12.014

esponding author.

ail addresses: jrodrigu@dcc.uchile.cl (J. Rodrıg

dcc.uchile.cl (S.F. Ochoa), jpino@dcc.uchile.cl

uer@ac.upc.edu (R. Messeguer), esunlyma@ac

ac.upc.edu (D. Royo).

a b s t r a c t

Mobile workers doing loosely coupled activities typically perform on demand collaboration in the

physical workplace. Communication services available in such work scenarios are uncertain, therefore

mobile collaborative applications supporting those activities must provide ad hoc communication

mechanisms in order to use each cooperation opportunity. Typically, the complexity of implementing

such mobile ad hoc communication mechanisms becomes a challenge that jeopardizes the development

of mobile collaborative solutions. This article presents a communication infrastructure named HLMP API

dealing with that challenge. HLMP API intends to ease the development of such applications through the

reuse of communication services. The infrastructure is an application programming interface that

implements the HLMP routing protocol and also some awareness mechanisms that are required for

mobile loosely coupled work. Developers using this infrastructure do not have to perform low-level

programming.

& 2010 Elsevier Ltd. All rights reserved.

1. Introduction

Advances in wireless communication technologies and mobilecomputing have opened many opportunities to perform computersupported mobile collaboration activities. Nomad users usually dothese activities in a loosely coupled way supported by a mobilecollaborative application. Some of the work scenarios where mobilecollaborative applications can support nomadic activities are thefollowing ones: hospital work (they support nurses’ and physicians’activities) (Pinelle and Gutwin 2006; Moran et al., 2007), education(supporting students’ and instructors’ work) Casas et al., 2009; Zuritaet al., 2008, emergency relief (supporting firefighting and rescueactivities) (Monares et al., 2011; McCarthy et al., 2006), m-commerce(supporting salesmen’s work) (Jensen, 2007; Tarasewich, 2003) andproduction processes (supporting engineers’ or technicians’ activities)(Ochoa et al., 2011; Jupp et al., 2007).

The development of mobile collaborative applications usuallyaddresses several challenges. One of them is the design and imple-mentation of the communication infrastructure that will allow nomadworkers to interact with each other in order to perform loosely coupledwork (Neyem et al., 2009).

ll rights reserved.

uez-Covili),

(J.A. Pino),

.upc.edu (E. Medina),

According to Ellis et al. (1991), communication is the basis thatallows implementing coordination and collaboration mechanisms.Implementing communication-supporting services in mobile col-laborative work scenarios is a major challenge for developers. Oneof the main reasons is the large number of complex requirementsthat must be taken into account (Herskovic et al., in press); some ofthese requirements are managing automatic connection/discon-nection of nodes, dealing with a dynamic network topology andproviding routing among network nodes.

The need to implement a suitable communication infrastructure asa part of the mobile collaborative application forces developers tofocus on basic groupware design issues, such as node identification,message delivery and routing. Implementing appropriate commu-nication services helps ensure that coordination and collaborationservices will then be suitable to support loosely coupled activities interms of usability and performance. However, the high effort andknow-how required to implement an adequate communicationinfrastructure able to support mobile ad hoc collaboration typicallyjeopardizes the development of the whole project (Neyem et al., 2009).

A typical strategy to address this problem is to use a framework/middleware that allows developers to reuse already implementedcommunication services. This saves developers the need to addresshighly important but secondary issues.

This paper presents an application programming interfacenamed HLMP API, which implements the HLMP routing protocol(Rodrıguez-Covili et al., 2010) and various awareness mechanismswhich are usually required in mobile collaborative applications.Like other APIs, it provides an interface to reuse the services it

J. Rodrıguez-Covili et al. / Journal of Network and Computer Applications 34 (2011) 1883–18931884

implements sparing developers to deal with basic groupwaredesign issues. Since the reuse of services helps reduce the complex-ity of the development process and increase the developers’productivity (Boehm, 1999; Mohagheghi and Conradi, 2007), weassume that HLMP API is able to inherit such benefits.

One important contribution of this API is the quality of thecommunication services it provides. In order to show this feature,the performance of HLMP API was compared with OLSRd, a well-known implementation of OLSR (Clausen and Jacquet, 2003). It isimportant to note that OLSR is one of the most recognized routingprotocols for mobile ad hoc networks. The obtained results showthat HLMP API is able to provide appropriate communicationsupport regardless of the users’ mobility type.

Next section describes some features of the collaborationprocess, when mobile ad hoc networks support it. Section 3discusses the related work. Section 4 presents the HLMP APIstructure and its main components. Section 5 shows the performedtests, the obtained results and also a comparison between HLMPAPI and OLSRd. Finally, Section 6 presents the conclusions andfuture work.

2. Collaboration supported by mobile ad hoc networks

Most activities involving mobile workers can be classified asloosely coupled work (Pinelle and Gutwin, 2006). This type of workhas nomad users collaborating on demand during irregular unpre-dictable time periods.

A well-known option to support communication requirementsof these persons is to use a Mobile Ad hoc Network (MANET)(Corson and Macker, 1999; De Rosa et al., 2005; Messeguer et al.,2009). These networks provide communication autonomy tonomad users, and allow them to collaborate on demand. TheMANET does not require a communication infrastructure at theworkplace in order to let workers perform their activities.

A MANET creates a dynamic communication mesh to exchangemessages among the mobile workers’ devices. Those devices arefree to move, change their connection status and get involved inunpredictable on-demand collaborative interactions. TypicallyMANETs have a small communication range, a dynamic topologyand a high disconnection rate (De Rosa et al., 2005).

Mobile collaborative applications using MANETs are not able toutilize centralized components because the nodes mobility gen-erates frequent disconnections. Therefore the access to centralizedservices cannot be ensured when the user requires them. Conse-quently, the communication, coordination and collaboration ser-vices embedded in a mobile collaborative application must adhereto a fully distributed architecture (Neyem et al., 2008).

The collaboration process performed by these mobile workersmay be done according to various interaction styles: attended,

partially unattended and unattended. Attended collaboration hasinteractions requiring the intervention of end users engaged in thecollaboration process. Typically those users remain stationaryduring these interactions because their participation gets easier.An example of attended collaboration is the exchange of usermessages through a collaborative application such as a chat.

Partially unattended collaboration involves a nomad user whointeracts with one or more mobile devices, but it does not directlycommunicate with other users. This collaboration style occurswhen a mobile worker performs actions on his/her application, e.g.to access, update or distribute shared files. Users containingreplicas of such files are unaware of this interaction process. Justthe user triggering the action is stationary in this scenario; the restof the participants keep moving.

Unattended collaboration instances involve users that are onthe move while their devices are interacting in order to provide

some collaboration service. The users are typically unaware of theinteractions among the mobile devices. Unattended collaborationis used to implement several awareness mechanisms that areusually embedded in the mobile collaborative applications; e.g.users’ connection and location, work sessions’ composition andshared resources availability.

The communication infrastructures supporting mobile colla-borative work must provide appropriate services (in terms ofusability and performance) to allow users to interact using thepreviously mentioned styles into a fully distributed way. Theauthors have proposed a routing protocol called High Level MANETProtocol (HLMP) trying to address this challenge (Rodrıguez-Coviliet al., 2010). HLMP was specifically designed to support mobilecollaborative work using MANETs. That protocol was then imple-mented through the HLMP API, which does not only support theseinteraction styles, but it also eases the development of mobilecollaborative applications, through a set of very easy-to-useservices and functionalities.

3. Related work

Several initiatives propose reusable solutions to support colla-boration in peer-to-peer networks. One of them is LaCOLLA(Marques and Navarro, 2006). This middleware has a fully decen-tralized peer-to-peer architecture and it provides general-purposefunctionalities for building collaborative applications. However,this middleware requires networks with high signal stability, itdoes not provide routing and it is unable to run on hardware withscarce resources.

A similar framework is iClouds, which offers spontaneousmobile user interaction and file exchange support in MANETs(Heinemann et al., 2003). Unfortunately this platform is focusedjust on file sharing.

Other frameworks providing specific functionalities to supportmobile collaboration through an API are YCab (Buszko et al., 2001)and JXTA (2010). Although these platforms have shown to be usefulto support collaboration in peer-to-peer networks, they requiresignal stability. Therefore, they are unsuitable to be used on ad-hocmobile work settings.

Nokia is an interesting protagonist. This company has developeda services-oriented framework that could be used to supportmobile collaboration. This framework includes a set of APIs andan SDK (Software Development Kit) allowing developers to createservice-oriented applications that act as consumers of Web ser-vices on mobile devices (Hirsch et al., 2006). Since mobileapplications can just consume services, their autonomy is smallbecause they require a service provider (i.e. a centralized compo-nent), which is unsuitable for MANETs.

There are also several proposals to share information in P2Pnetworks, even considering mobile computing devices (Neyemet al., 2008; Hauswirth et al., 2005). Typical examples of theseplatforms are the tuple-based distributed systems derived fromLINDA, such as: FT-LINDA, JINI, PLinda, T-spaces, Lime, JavaSpacesand GRACE (Bosneag and Brockmeyer, 2005; Handorean et al.,2003; Nemlekar, 2001). All these solutions use centralized com-ponents; therefore they cannot be used on MANETs. XMIDDLE(Mascolo et al., 2002) is another middleware allowing mobile hoststo share XML documents across heterogeneous mobile hosts,permitting on-line and off-line access to data. Nevertheless, thesemiddleware are just focused on data sharing and they do notsupport the autonomy and interoperability capabilities required bymobile workers.

Neyem et al. (2008) proposed a fully distributed platformnamed SOMU (Service-Oriented Mobile Unit), which provides aset of communication and coordination services supporting mobile

J. Rodrıguez-Covili et al. / Journal of Network and Computer Applications 34 (2011) 1883–1893 1885

collaboration. Such work inspired the definition of HLMP and alsothe communication infrastructure described in this article. HLMPAPI improves the routing protocol proposed in SOMU and also thecommunication services provided by that platform.

There are several implementations of routing protocols forMANETs, which can also be used to support the mobile interactionsamong users. Some of them are DSR (Johnson and Maltz, 1996),OLSR (Jacquet et al., 2001), TORA (Park and Corson, 1997), BATMAN(Neumann et al., 2008) and AODV (Perkins and Royer, 1999). Theseprotocols were not designed to support mobile collaboration;therefore they do not provide mechanisms to ease the implemen-tation of basic groupware design issues, such as work sessionmanagement, awareness mechanisms, dynamic detection of usersand roles support.

4. HLMP API

HLMP API is composed of two main components (Fig. 1): a coreand plug-ins. On the one hand, the core implements the mechan-isms to support the communication process, network data inter-change and operating systems interoperability procedures fordelegated functionalities. On the other hand, the plug-ins compo-nent contains specifications for structuring groupware commu-nication protocols and awareness mechanisms, which use theservices provided by the core. Next subsections explain thesetwo components in detail.

4.1. HLMP API core

The core is the basic structure of the HLMP API implementation.It performs the configuration of threshold values; it establishes theMANET connection procedures; and it structures, routes anddelivers messages through the network. This component alsokeeps control of the events delivered to the collaborative applica-tions connected to the MANET. Such information is reported to theapplication upper layers, which are in charge of implementing theawareness mechanisms that help mobile users to collaborate on-demand; e.g. awareness of users’ availability and location.

The core is divided into three functional sub-structures: System

Interoperability, which is the procedure bus for operating systems(OS) delegated functions; Network Layer, which is responsible forthe exchange of UDP and TCP services and datagrams; andCommunication Layer, which is the API potentially used by devel-opers as support for mobile collaborative applications.

(1)

System Interoperabilty

This layer is in charge of specific OS delegated functions. Thesefunctions include the actions required to carry out the MANETconnection procedure. These actions are:� Configuration of the WLAN profile in an XML outline.� Management of the wireless network adapter in order to

provide automatic deployment of the network and reactionto disconnections.

Fig. 1. HLMP API stru

� Configuration of the IP address and subnet mask.� Detection of duplicated address (strong DAD procedure)

when connecting to the specified WLAN, through OSnotifications.

ctu

(2)

Network Layer

This component implements the services required to send andreceive data in a MANET, using a net handler element. Thosepackets are validated according to the specified networkmessages structure of HLMP. Messages are also queued, whilebeing received, in separated data structures depending on theOS protocol used to transmit the message (UDP or TCP). Then,the Communication Layer processes them. This module is alsothe component managing the links with the remote devicesneighborhood, using TCP listening and direct connectionprocedures.

(3)

Communication Layer

This unit implements the application–programming interfacethat developers can use to support communication in colla-borative mobile applications. This component is also a managerof the HLMP services, i.e. routing mechanisms, messagesorganization, message packing and unpacking. The mainprocess performed by this component is the processing ofthe network messages queue, previously received by theNetwork Layer. This component uses a factory to transformthese network messages into high-level communication mes-sages. From this point, the system has access to the wholemessages’ information; it can analyze it and decide the nextactions. Typically these actions are routing or processing themessages locally. There is also a queue for outgoing high-levelmessages, which are decomposed into network messages inorder to be routed towards the destination nodes.

Fig. 2 shows how the communication messages are organized.The API uses the requirements of HLMP for creating a composedobject-oriented specification. The main abstract class Message

contains the basic information of a message, i.e. identificationnumber, meta-type code, message type code, sub-protocol typecode, information about the sender and the number of hopsthrough which the message has been routed. Five main abstractclasses are derived from this class. These derived classes corre-spond to the five meta-type messages defined in HLMP (Rodrıguez-Covili et al., 2010), i.e., Multicast Message, Safe Multicast Message,Unicast Message, Safe Unicast Message and Fast Unicast Message.

Every meta-type message decides how to send a packet, byusing the appropriate functionality offered by the Network Layer.This delivery also considers the semantic mechanism specified inHLMP for each type of distribution. For example, Multicastmessages are sent using the UDP channels to every user in theMANET. Unicast messages are sent through the TCP channels to oneremote user, who is identified by the target user property. SafeUnicast messages are sent to just one user with the samemechanism than the previous one. However, in the latter casethe sender waits for a confirmation of the reception message

re.

Fig. 2. Message context diagram.

J. Rodrıguez-Covili et al. / Journal of Network and Computer Applications 34 (2011) 1883–18931886

(i.e., an ACK). If the ACK is not received within a certain time period,then the message is sent again.

Developers must extend and implement classes derived fromthe meta-type messages in order to build new kinds of messages todeal with specific groupware requirements. Examples of theseextensions are the internal construction of the ‘‘I’m Alive’’ messageused to implement the peers’ detection mechanisms, and also the‘‘Ack’’ message used for notifications of received Safe Unicastmessages.

It is also significant that every implemented message isresponsible for the procedures of reading and writing its own bytepackets (depending on the information they need to propagate).The meta-types use polymorphism to call the appropriate proce-dures when packing/unpacking the high level messages.

Fig. 3 shows the main components of the communicationprocess. The manager of this process is the Communication class,which offers the functionality for connecting or disconnecting to/from the MANET, and sending/receiving any kind of derivedmessage. This class also allows the activation of the event deliverysystem. An object initialization of this class and a simple function-call starts the entire automatic connection procedures, usersdetection, routing mechanisms and the described functionalities.

A user in the MANET is managed as a NetUser. This class has allthe properties required to identify and keep the information aboutthe user signal quality, traffic state, semantic information like thename, identification number and various other data required bygroupware applications. Local user information is kept in theConfiguration object along with local network parameters. Therest of the MANET users are kept in a NetUserList object, which ismanaged and updated internally by the Communication class. Allthe users’ parameters are automatically refreshed and maintainedby the API, so developers only need to read this data in order tomake collaboration decisions, or build profiles informationstructures.

Events in the MANET are communicated to collaborativeapplications, because these systems typically need to implement

awareness mechanisms based on such information. This capabilityof HLMP API helps to reduce the complexity and the required effortto develop a mobile collaborative application. The Event classspecifies the basic structure and data that is triggered by variousevents, such as users’ actions, quality measures changes andnetwork status. Examples of events warned to upper layers usingthe API are the following ones: (1) the connection status of the localuser is changing or it has changed, (2) new users are connected tothe network and (3) a mobile user is moving away from the mesh.

Several events that occur in the network layer and related to thereceived and accepted messages must be processed by the upperlayer (i.e. the communication layer) in order to identify whichaction is appropriate to take in each case. For example, the SafeUnicast messages, that were sent by the groupware layer and thatwere not successfully delivered to the destination node, are sent tothe upper layer. The communication failure can happen due todisconnection of the target user or problems when trying to find apath to the destination node. In either case the upper layer willdecide which action must be taken in order to deal with such event.The Communication object sends also notifications about theinternal behavior of the system, such as log information andexceptions. Developers only have to subscribe their proceduresto the API events, in order to perform an application response orshow elements in the GUI concerning the event information.

4.2. HLMP API Plug-ins

The API offers, as an optional feature, an organization forreusable sub-protocols implementations (e.g. groupware specificprotocols), which deals with complex services, e.g. text messaging,mail boxes, files sharing and transfer, or data synchronizationmechanisms. Fig. 4 shows the Sub-Protocol I interface, which can beinstantiated in order to create a new sub-protocol that uses theHLMP API Core. These objects are added to a SubProtocolList,managed by the Communication object. Whenever messages of a

Fig. 3. Communication context diagram.

Fig. 4. Sub-protocol context diagram.

Alvaro

Juan Francisco

Sergio

Bob

Sun.jpg

Liberian.mp3

NotesOER.doc

Moon.jpg

Flower.jpg

ProjectOER.mpp

Completed

Completed

Completed

Queued

Active

Active

Fig. 5. Common communication interfaces.

J. Rodrıguez-Covili et al. / Journal of Network and Computer Applications 34 (2011) 1883–1893 1887

specific sub-protocol type are received, the Communication classassigns those messages to the corresponding instantiated sub-protocol.

HMLP API presents some pre-built basic sub-protocols, such as atext message delivery protocol, for group and private communica-tions; file transfer protocol, which allows network users to share anddownload any type of files; and ping protocol to perform speedmeasures of communication between users. These implementations

include simple interfaces that can be linked to any other softwarecomponents or GUIs in order to save efforts when developing suchfunctionalities.

The complementary Plug-ins also offers mobile groupwarecommunication GUIs. Pre-built communication awareness com-ponents can be embedded in the mobile collaborative applicationsand make them available to the end users through application userinterfaces. For instance, Fig. 5(a) presents an awareness component

J. Rodrıguez-Covili et al. / Journal of Network and Computer Applications 34 (2011) 1883–18931888

that shows a users list connected to the MANET. The first usershown in black is the local one. The color intensity of theparticipant’s icon indicates the communication quality with thatuser: the darker the better.

The awareness component presented in Fig. 5(b) shows thecurrent MANET graph, indicating the networking links amongmobile users. It is useful to see the paths that messages can usefor reaching their destinations. It can also be used to check themobile network evolution, users’ behavior and physical distancebetween two mobile users. Finally, the component presented inFig. 5(c) shows the GUI corresponding to the file transfer sub-protocol. It illustrates the list of transferred files and their currentstatus. All these awareness components can be easily embeddedinto a mobile application if it uses HLMP API as communicationsupport. Additional information about the HLMP API implementa-tion can be found in HLMP API (2010).

Fig. 6. Evaluation scenario I.

Fig. 7. Packet sizes used by the protocols.

Fig. 8. Control overhead.

5. Performance comparison

The experiments were performed at several settings that tried toevaluate the communication capability of the proposed infrastruc-ture. In each setting, the HLMP API implementation was comparedwith OLSRd, a well-known implementation of the OLSR protocol(Clausen and Jacquet, 2003). OLSRd was chosen because it is one ofthe best routing implementations available for MANETs. The testscenarios used in the experiments involved stationary and mobilenodes, as a way to mimic the interaction instances occurring inmobile collaborative work.

Seven laptops (model HP NX6310 with an IBM Intel Core 2 T5500of 1.66 GHz processor and 1 GB of RAM) were used in the test. Each ofthese computers had an internal Intel PRO/Wireless 3945ABG Net-work Connection card for IEEE 802.11 b/g wireless connectivity.During the experiments, the wireless cards on the laptops were setto channel 1 at the 802.11 b/g band, using auto rate, transmissionpower 1 dBm and RTC/CTS off, following recommendations inTschudin et al. (2005).

All laptops were equipped with the Linux Operating System(Ubuntu 8.04 Linux distribution with the 2.6.24-19-generic kernel)and also MS Windows XP. The traffic generator used in the test wasIperf (version 2.4) and the regular ping service provided by theoperating system.

The traffic analyzers were Wireshark and tcpdump. Followingthe Kiess and Mauve (2007) recommendations, a MAC filter wasalso used to classify packets on the MAC layer and force a multi-hopbehavior avoiding direct communication between two nodes.

A LiveCD was prepared in order to avoid human intervention asmuch as possible. This LiveCD adds an extension to the operatingsystem facilitating the test bed implementation, use and datagathering (Tschudin et al., 2005).

The physical environment used to perform these tests was alaboratory with a large open area. We avoided using built areas inorder to ensure the repeatability of the communication conditionsduring the several tests of a test case. Next sections describe theevaluation scenarios and the obtained results.

5.1. Test case I

All nodes in this case were located at one hop of distance.Initially there were just two nodes in the MANET, then, a third onewas added, then a fourth one, and so on to complete seven nodes(Fig. 6). This scenario does not consider information transfer amongnodes; it just has control packages intended to maintain thetopology, check the links quality and update the routing tables.The goal of this test is to evaluate the control overhead and packetsize used by both protocols.

The obtained results (Fig. 7) show that HLMP packet sizes are abit larger than OLSR datagram sizes. OLSR packets seem to have ahigher incremental proportion when new nodes are added. How-ever, Fig. 8 shows that HLMP needs to send more packets when thenodes number increases in a group scenario.

Nevertheless, most of those packets are discarded and droppedwhen performing the HLMP duplication detecting mechanisms.The control configuration for both protocols is the default one;in the case of OLSR is LQ (link quality).

Fig. 10. Traffic overhead.

J. Rodrıguez-Covili et al. / Journal of Network and Computer Applications 34 (2011) 1883–1893 1889

Although the differences between both packet sizes are notsignificant, they have a simple explanation: HLMP API uses twolayers (the networking and application layers) to keep the networktopology updated. Therefore, services running in these two layersmust include an additional header to manage the packets in anappropriate way.

On the one hand, the invocation of services located at differentlayers enlarges the packet size; particularly the number of bytesused for communication control. On the other hand, dealing withmobility requires increasing the frequency of network topologyupdates, which also increases the control overhead. In otherswords, the control overhead per packet is similar for both proto-cols; however HLMP sends more packet per time unit than OLSR.This is because HMLP was designed to deal with users thateventually are highly mobile. Therefore, the communication infra-structure must react fast to changes in the network topology.

In the case of OLSR, the whole implementation runs at thenetworking layer; therefore it does not require extra bytes forcommunication control. Moreover, OLSR was not particularlydesigned to support high mobility; therefore, it uses less packetsfor control and it reacts slower than HLMP to changes in thenetwork topology.

The communication infrastructures that try to deal with mobilitydo not necessarily have to be located at two layers and thus having anextra overhead. However, in case of collaborative systems managinginformation at the application level is very convenient because theimplementation of interaction awareness mechanisms (a key designelement for this type of systems) becomes easy and direct. Therefore,implementations of MANET-based routing protocols designed tosupport mobile collaborative systems will require an extra controloverhead compared with implementations that consider just the usermobility; such as OLSRd.

5.2. Test case II

The second test scenario consisted of the transmission of a filebetween a sender (Tx) and a receiver (Rx). The main goal was tocompare the traffic overhead in both implementations.

Initially the MANET had two nodes; interim nodes were thenadded in a line to complete three hops (Fig. 9). Two different fileswere used in this experiment. The first one weighted 993 KB andthe second one weighted 2.7 MB. The file transfers were done overTCP connections for OLSR, and using Safe Unicast messages forHLMP (these messages were implemented using TCP as well).Moreover, two OLSR implementations (for Windows and Linux,respectively) were used in this test case, and also one implementa-tion of HLMP API for Windows.

The transfer overhead (bytes) related to each routing protocolimplementation was measured, and the obtained results arepresented in Fig. 10.

The results show that HLMP API and OLSRd have a similartransfer overhead for the same operating system. Consideringdifferent operating systems, the HLMP API overhead is 30% lessthan the OLSRd overhead. This is because the transportation layer

Fig. 9. Evaluation scenario II.

depends on the operative system protocol implementation for theTCP stack.

The traffic overhead for both implementations was small. Lessthan 6% of the total bytes transferred through the network wereused for control in the HLMP case. It is a very small overhead if wetake into account the particularities of transferring data in MANETs.

The difference in the traffic overhead of HLMP API and OLSRd(for the same operating system) is due to two main reasons. On theone hand HLMP API requires sending a small number of additionalpackages in order to keep always updated the network topologyand composition. Thus collaborative systems using HLMP API areable to react fast and properly to network topology changesproduced by the nomad users’ mobility. Please note that HLMPAPI was particularly designed to deal with the communicationchallenges involved in mobile collaboration.

The second reason for the extra traffic overhead is that HMLPuses services located at two different layers (i.e. networking andapplication layers) to monitor the network and deliver messages.The inter-layer services invocations increase the traffic overhead.

5.3. Test case III

This scenario consisted of the transmission of a file between tworemote nodes (i.e. Tx and Rx), but in a mobility context. Again, thefile transfer is done over TCP for OLSR and using the Safe Unicastmessages for HLMP. The nodes acting as sender and receiver werestatic. Five moving nodes where placed between them, creatingactive routes every 30 s (Fig. 11). Nomad users moved through apath drawn on the floor and with a uniform speed. Five tests wererecorded in order to have representative samples.

This experimentation scenario mimics those where two usersdecide to perform attended collaboration. In such case the parti-cipants are static and the intermediary nodes are on the move. Herethe behavior of the data transmission and the impact of changes inthe MANET topology were measured. The TCP connection betweenTx and Rx is continuously established.

When a movement of the interim nodes occurs, the networkmust recalculate the paths to send the packets. The network showsa pause in the data transmission during such recalculation process(also known as the reaction time). Therefore, the transfer speed isimpacted by the cost of discovering the topology changes, checkingthe quality of each link and updating the routing tables for OLSR orrecalculating the routing paths for HLMP.

J. Rodrıguez-Covili et al. / Journal of Network and Computer Applications 34 (2011) 1883–18931890

After comparing the reaction time of both protocols, theobtained results show that HLMP reacts faster than OLSR tochanges in the network topology. Fig. 12 shows an average sampleof a network pause in the OLSR implementation routine, when thesystem is reacting to connections and disconnections of thedevices. Fig. 13 shows the same sample, but for the HLMP API.There OLSRd seems to have longer inactivity periods (13–15 s) thanHLMP API (lower than 10 s) for all tried sequences.

The difference in the reaction time is a consequence of thestrategy adopted by each protocol to update its routing table. OLSRis a proactive protocol; therefore it maintains a routing table withinformation to deliver the messages. OLSR uses the ETX metric forthe selection of the routes, and that metric utilizes statisticalinformation of the 10 last probes to compute its current value. Sincethe mobile user location is constantly changing, the computed bestroute becomes out-dated soon; therefore almost all network pathsmust be recalculated for each change.

HLMP is a reactive protocol; therefore it does not pre-establish apath. Such path is dynamically defined (with each hop) while themessage travels towards the destination. Since HLMP deliverssuch information during the interaction process, the recalculation

Fig. 11. Evaluation scenario III.

Fig. 12. OLSRd re

Fig. 13. HLMP API

process is less frequent and involves just part of the routing table.Hence, HLMP is more time efficient than OLSR.

5.4. Test case IV

Seven nodes participate in this test case. Four of them keep staticand the other three are mobile (Fig. 14). Mobile nodes (thoselabeled as ‘‘Mn’’) remained as part of the network, but they changedthe MANET topology during the test. In order to have representa-tive samples, we had the same care than with the previous test.

action time.

reaction time.

Fig. 14. Evaluation scenario IV.

J. Rodrıguez-Covili et al. / Journal of Network and Computer Applications 34 (2011) 1883–1893 1891

Two files (one of 933 KB and other of 2.7 MB) were transferredfrom nodes A to D. A possible connection path between A and D wascontinuously established during the experiment.

The transfer duration in HLMP is always a bit longer than OLSR(Fig. 15a). The explanation is simple: HLMP works at the applica-tion layer and requires more packages to transfer a file than OLSR(Fig. 15b). HLMP is an application layer protocol, thus it requires afew additional small messages controlling the transfer and it alsohas an extra processing, when comparing it with protocols workingat the transport layer. We can also say OLSR makes an end-to-endtransfer whereas HLMP makes a hop-by-hop transfer including anextra cost and delay.

The results show that the larger is the file to be transferred thesmaller is the difference in performance between the two protocols.

The transfer overhead was below 6%. In particular, it was 4.2%(avg.) for HLMP and 4.1% (avg.) for OLSR in the example illustratedin Fig. 10.

Fig. 16. Evaluation scenario V.

Fig. 17. Throughput with disconnections/reconnections.

5.5. Test case V

This test case has a topology similar to the previous case, but themovement of mobile nodes produces disconnections and recon-nections of the intermediary users (those labeled as ‘‘Mn’’) in thisscenario (Fig. 16). A file weighting 5 MB was transferred from A toD, and the observed variable was the throughput. This scenario isalso representative of attended collaboration processes.

Although this test included several node disconnection/recon-nection (D/R) rates, the resulting throughput followed the samepattern. Therefore the results in Fig. 17 present just D/R rates of5 and 10 s. A D/R rate of 5 seconds indicates there is a D or R changeevery 5 seconds while the file is being transferred. Consequently,the network topology changes and the routing protocol must try toself-adapt to the new topology.

The first unexpected result obtained during this test was thetransfer failure rate (i.e. unsuccessful transfers). In the case of OLSRconfigured using LQ, the TCP connection was lost for topologychanges every 40 s. The system was unable to check the quality ofthe links and update the routing tables. Therefore, the transferconnections were lost. For OLSR configured using RFC (without linkquality), using D/R rates from 5 to 15 s, OLSR has transfer failurerates of about 30%. Longer D/R rates reduce the failure rate almostlinearly. For D/R rates of 40 s the failure rate was 10%.

The failure transfers rate was 0% for HLMP in all tests. Theprotocol never aborted or ended in a deadlock during the tests. Therobustness helps ensure a certain performance and usability levelof the application during the mobile work. We may explain thisdifference between OLSR and HLMP as the consequence of using an

Fig. 15. Transfer duration a

end-to-end transfer (OSLR) instead of a hop-by-hop transfer(HLMP).

Fig. 17 presents just the results of the positive tests; i.e. thosewhere the transfer using OLSRd with the RFC default configuration

nd number of packets.

J. Rodrıguez-Covili et al. / Journal of Network and Computer Applications 34 (2011) 1883–18931892

did not fail. These results showed that the throughput obtainedwith both protocols is quite stable regardless of the D/R rate.Moreover, HLMP API is able to transfer more information thanOLSRd when the network topology changes frequently.

HLMP API thus reacts faster than OLSRd to changes in thetopology. This feature also helps ensure the usability (in terms ofperformance) of the communication-supporting infrastructure.

5.6. Discussion

The experimental results show that HLMP API and OLSRd aresimilar in terms of routing performance and throughput. OLSRdgets better results in static or low mobility work scenarios, whileHLMP API works better in scenarios with important mobility or D/Rrates. However, HLMP API does not fail during a file transfer, whichensures in some way that the mobile collaborative application willhave an acceptable performance during any collaboration style(i.e. attended, partially unattended and unattended collaboration).The performance of the communication, coordination and colla-boration services (including several awareness mechanisms)depend on the communication-supporting infrastructure.

It is important to notice that all tests involved static end-users,which is the worst scenario for HMLP API. Based on the resultsobtained in the test cases III to V we can hypothesize that HLMP APIwould show a better performance than OLSRd if all nodes aremobile. In other words, HLMP API should be better than OLSRd tosupport partially unattended and unattended mobile collaborationactivities.

Since HLMP API implements the protocol at the applicationlayer, the infrastructure has an ample control to decide the momentto deliver the messages or the packets size to be used in each case.In other words, this infrastructure can be easily adjusted to addressparticular communication requirements to support a specificmobile collaborative work. However, managing networking infor-mation at two levels adds an extra communication overhead.

On the contrary, OLSR works inside the networking layer;therefore any mobile collaborative application that uses thisprotocol has to utilize the parameters established by the operatingsystem when performing data transportation procedures. Itreduces the ability to tune the collaborative solutions and imple-ment collaboration awareness mechanisms based on users’ con-nection and interaction. However, it produces a communicationoverhead that is smaller than the one of the previous case.

Considering the HLMP API performance and services, it is clearthat this is a component which is worth of reusing. Examples ofreusable services provided by this API are MANET automaticallyarrangement, IP addresses self-configuration and duplicationdetection, peers discovery, and routing for multicast and unicastmessages.

Developers of mobile collaborative applications can take advan-tage of this infrastructure in order to save cost, time and effortinvolved in the development of the mobile communication sup-port. This type of solution usually helps also to reduce thecomplexity of the developments and to improve the quality ofthe final product (Ravichandran and Rothenberger, 2003; Sadaouiand Yin, 2004).

Various researchers and also the authors have developed mobilecollaborative applications that use HLMP API as communication-supporting infrastructure. These applications are the followingones: COIN (Construction Inspector), which supports inspectors’work during construction inspection activities (Ochoa et al., 2011;Rodrıguez-Covili et al., 2011); MobileMap that supports the work offirefighters during emergencies (Monares et al., 2011; Rodrıguez-Covili et al., 2011); and MeetU that assists physicians and nursesduring hospital work (Moran et al., 2010; Rodrıguez-Covili et al.,

2011). All these applications have been tested in real scenarios andthe users think they are usable (in terms of performance andcollaboration support) and also useful to support the correspond-ing loosely coupled activity.

HLMP API was not designed to support large number of nodesperforming mobile collaboration activities, but to support looselycoupled work. Typically in such type of work the number ofparticipants is small. The empirical results reported in this articleand others obtained during the evaluation of applications that useHMLP API, indicate the platform has an acceptable performancewhen supporting interactions between nodes that are up to 4 hopsof distance. It clearly supports loosely coupled work in severalscenarios. However, the maximum number of nodes manageableby HLMP API in an interaction process has not been established yet.

6. Conclusions and future work

The successful development of mobile collaborative applica-tions usually has to deal with network related issues, instead offocusing efforts on social groupware architectures and function-alities (Dyck, 2006; Messeguer et al., 2009). This situation arisesbecause collaboration and coordination problems are highlydependent on computer-mediated communication (Ellis et al.,1991; Messeguer et al., 2009; Neyem et al., 2009). An appropriatecommunication support eases the implementation of coordinationand collaboration services that will be embedded in the mobileapplication. However, developing such communication-support-ing infrastructure is an important challenge, which sometimesjeopardizes the whole project.

A typical solution to deal with this issue is to use alreadyimplemented services, which are exposed through an API. Such APIprovides an abstract solution allowing developers to reuse thenetworking services without having to deal with low-level pro-gramming details.

This paper has presented the HLMP API, a particular imple-mentation of the HLMP routing protocol (Rodrıguez-Covili et al.,2010). This communication infrastructure implements an API thatallows developers to obtain the previously discussed benefits. Thisinfrastructure is fully distributed and it is organized in layers,which contributes to its extensibility.

The upper layer of this API is able to create collaborative workfunctionalities by using the message exchange paradigm. It is alsopossible to reuse or implement network awareness mechanismsdue to the several event types that are triggered to the collaborativeapplication when important information or particular networkevents occur.

The tests conducted to the API have shown the performance ofthis infrastructure is comparable to those obtained using OLSRprotocol. If we consider that OLSR is one of the best protocols forMANETs, it is clear that the HLMP API is worth of reusing.

HLMP API has also shown a performance better than OLSRd inwork scenarios involving high mobility or D/R rates. The stability ofthe throughput and the robustness during file transfer operationsmakes HLMP API an interesting support for developers of this typeof solutions. This infrastructure has already been used as supportfor various mobile collaborative systems. The obtained results arehighly encouraging.

Next steps for this research consider including new context-awaremechanisms to the API. Thus, the authors will intend to combine andadapt the API threshold values to increase the network performanceor reduce excessive control overhead. These values can be groupedand configured depending on the work context. The API can informthe collaborative application about changes in certain variables;therefore the application will implement self-adaption processesaccording to the work context changes.

J. Rodrıguez-Covili et al. / Journal of Network and Computer Applications 34 (2011) 1883–1893 1893

Future research also includes several tests in work scenarioswith full mobility in order to validate the hypothesis raised fromthe empirical results. It will also help to identify the currentlimitations of this infrastructure.

Acknowledgements

This work was partially supported by Fondecyt (Chile), Grantsnos. 11060467 and 1080352, LACCIR Grants no. R0308LAC004 andR0308LAC005, and Spanish MICINN project Delfin TIN2010-20140-C03-01.

References

Boehm B. Managing Software Productivity and Reuse. IEEE Computer 1999;32(9):111–3.

Bosneag AM, Brockmeyer M. GRACE: Enabling collaborations in wide-area dis-tributed systems. In: Proceedings of the WETICE’05, Workshop on Distributedand Mobile Collaboration (DMC), Linkoping University Sweden, IEEE CS Press,2005, p. 72–77.

Buszko D, Lee W, Helal A. Decentralized ad-hoc groupware API and framework formobile collaboration. In: Proceedings of the ACM International Conference onSupporting Group Work (GROUP’01), Colorado, USA, ACM Press, 2001, p. 5–14.

Casas I, Ochoa SF, Puente J. Using tablet PCs and pen-based technologies to supportengineering education. In: Proceedings of the Human-Computer InteractionInternational (HCII), San Diego, CA, USA. July 19–24, Lecture Notes in ComputerScience 5613, 2009, p. 31–38.

Clausen T, Jacquet P. Optimized link state routing protocol (OLSR). IETF RFC 3626,October 2003.

Corson S, Macker J. Mobile ad hoc networking (MANET): routing protocol perfor-mance issues and evaluation considerations. IETF, RFC 2501, January 1999.

De Rosa F, Malizia A, Mecella M. Disconnection prediction in mobile ad hoc networksfor supporting cooperative work. IEEE Pervasive Computing 2005;4(3):62–70.

Dyck J. A survey of application-layer networking techniques for real-time dis-tributed groupware. University of Saskatchewan, Technical Report HCI-TR-06-06, 2006.

Ellis CA, Gibbs SJ, Rein GL. Groupware: some issues and experiences. Communica-tions of the ACM 1991;34(1):38–58.

Handorean R, Payton J, Julien C, Roman G. Coordination middleware supportingrapid deployment of ad hoc mobile systems. In: Proceedings of the ICDCS’03,Workshop on Mobile Computing Middleware, Rhode Island, USA, IEEE CS Press;2003. p. 363–368.

Heinemann A, Kangasharju J, Lyardet F, Muhlhauser M. iClouds: peer-to-peerinformation sharing in mobile environments. In: Proceedings of the Euro-Par’03,Klagenfurt Austria, Lecture Notes in Computer Science 2790, p. 1038–45, 2003.

Herskovic V, Ochoa SF, Pino J, Neyem A. The iceberg effect: mobile collaborativesystems behind the user interface. Journal of Universal Computer Science,in press.

Hirsch F, Kemp J, Ilkka J. Mobile web services: architecture and implementation;Nokia research center. John Wiley & Sons; 2006.

Jacquet P., Muhlethaler P, Clausen T, Laouiti A, Qayyum A, Viennot, L. Optimized linkstate routing protocol for ad hoc networks. In: Proceedings of the IEEEInternational Multi-Topic Conference, Le Chesnay, France, IEEE Press; 2001p. 62–8.

Jensen R. The digital provide: information (technology) market performance andWelfare in the South Indian Fisheries Sector. The Quarterly Journal of Economics2007;122(3):879–924.

Johnson D, Maltz D. Dynamic source routing in ad hoc wireless networks.In: Imielinski T, Korth H, editors. Mobile Computing. Kluwer AcademicPublishers; 1996. p. 153–81.

Jupp J, Langdon P, Godsill S. Mobile computing in maintenance activities:a ‘situational induced impairments and disabilities’ perspective. Lecture Notesin Computer Science, vol. 4554, p. 696–705, 2007.

JXTA Project, 2010, /https://jxta.dev.java.net/S. Last visit: September 2010.Kiess W, Mauve M. A survey on real-world implementations of mobile ad-hoc

networks. Ad Hoc Networks 2007;5(3):324–39.

Marques J, Navarro L. LaCOLLA: a middleware to support self-sufficient collaborativegroups. Computing and Informatics 2006;25(6):571–95.

Mascolo C, Capra L, Zachariadis S, Emmerich W. XMIDDLE: a data-sharing middle-ware for mobile computing. Journal on Personal and Wireless Communications2002;21(1):77–103.

McCarthy B, Edwards C, Dunmore M. The integration of ad-hoc (MANET) and mobilenetworking (NEMO): principles to support rescue team communication.In: Proceedings of ICMU�06, 2006, p. 284–9.

Messeguer R, Ochoa SF, Pino JA, Medina E, Navarro L, Royo D, Neyem A. Building real-world ad-hoc networks to support mobile collaborative applications: lessonslearned. Lecture Notes in Computer Science 2009;5784:1–16.

Mohagheghi P, Conradi R. Quality, productivity and economic benefits of softwarereuse: a review of industrial studies. Empirical Software Engineering2007;12(5):471–516.

Monares A, Ochoa SF, Pino JA, Herskovic V, Rodriguez-Covili J, Neyem A. Mobilecomputing in urban emergency situations: improving the support to firefightersin the field. Expert Systems with Applications 2011;38(2):1255–67.

Moran E, Tentori M, Gonzalez V, Favela J, Martınez-Garcia A. Mobility in hospitalwork: towards a pervasive computing hospital environment. InternationalJournal of Electronic Healthcare 2007;3(1):72–89.

Moran AL, Rodrıguez-Covili J, Mejıa D, Favela J, Ochoa SF. Supporting informalinteraction in a hospital through impromptu social networking. In: Proceedingsof the 16th CRIWG Conference on Collaboration and Technology, Maastricht,The Netherlands. Lecture Notes in Computer Science 6257, p. 305–20, 2010.

Nemlekar M. Scalable distributed tuplespaces. M.Sc. Thesis. Department of Elec-trical and Computer Engineering, North Carolina State University, Chapter 5,2001.

Neumann A, Aichele C, Lindner M, Wunderlich S. Better approach to mobile ad-hocnetworking. /http://tools.ietf.org/html/draft-wunderlich-openmesh-manet-routing-00S, 2008.

Neyem A, Ochoa SF, Pino JA. Integrating service-oriented mobile units to supportcollaboration in ad-hoc scenarios. Journal of Universal Computer Science2008;14(1):88–122.

Neyem A, Ochoa SF, Pino JA. Communication patterns to support mobile collabora-tion. In: Proceedings of the 15th CRIWG International Workshop on Groupware.Douro, Portugal. Lecture Notes in Computer Science 5784, p. 270–7, 2009.

Ochoa SF, Bravo G, Pino J, Rodriguez JF. Coordinating loosely-coupled work inconstruction inspection activities. Group Decision and Negotiation 2011;20(1):39–56.

Park V, Corson M. Highly adaptive distributed routing algorithm for mobile wirelessnetworks. In: Proceedings of the 16th Annual Joint Conference of theIEEE Computer and Communications Societies, Kobe, Japan. IEEE Press; 1997,p. 1405–13.

Perkins C, Royer E. Ad-hoc on-demand distance vector routing. In: Proceedings of theMobile Computing Systems and Applications, New Orleans, LA, USA, p. 90–100,1999.

Pinelle D, Gutwin C. Loose coupling and healthcare organizations: deploymentstrategies for groupware. Computer Supported Cooperative Work Journal2006;15(5/6):537–72.

Ravichandran T, Rothenberger MA. Software reuse strategies and componentmarkets. Communications of the ACM 2003;46(8):109–14.

Rodrıguez-Covili J, Ochoa SF, Pino JA, Herskovic V, Favela J, Mejıa D, Moran AL.Towards a reference architecture for the design of mobile shared workspaces.Future Generation Computer Systems 2011;27(1):109–18.

Rodrıguez-Covili J, Ochoa S, Pino J. Enhancing mobile collaboration with HLMP. In:Proceedings of the 14th International Conference on Computer SupportedCooperative Work in Design (CSCWD’10), Shanghai, China, IEEE Press; 2010,p. 462–72.

Sadaoui S, Yin P. Generalization for component reuse. In: Proceedings of the 42ndAnnual Southeast Regional Conference. ACM-SE 42. ACM Press; 2004, p. 134–9.

Tarasewich P. Designing mobile commerce applications. Communications of theACM 2003;46(12):57–60.

Tschudin C, Gunningberg P, Lundgren H, Nordstrom E. Lessons from experimentalMANET research. Journal of Ad Hoc Networks 2005;3(2):221–33.

Zurita G, Baloian N, Baytelman F. Using mobile devices to foster social interactions inthe classroom. In: Proceedings of the 12th International Conference onComputer Supported Cooperative Work in Design (CSCWD), Xi’an, China, IEEEPress;2008, p. 1041–6.

Hauswirth M, Podnar I, Decaer S. On P2P collaboration infrastructures. In: Proceedingsof the WETICE’05, Workshop on Distributed and Mobile Collaboration (DMC),Linkoping University Sweden, IEEE CS Press;2005, p. 66–71.

HLMP API. Available at URL: /http://hlmprotocol.bicubic.cl/S. Nov. 2010.