manet sessions

8/20/2019 manet sessions

1/8

Robust cloud management of MANET checkpoint sessions

Hazzaa Naif Alshareef

Department of Computer Science

University College Cork (UCC)

Cork, Ireland

[email protected]

Dan Grigoras

Department of Computer Science

University College Cork (UCC)

Cork, Ireland

[email protected]

Abstract — In a traditional mobile ad-hoc network

(MANET), if two nodes are engaged in a session and

one of them departs suddenly, their communication is

aborted. The session is not active any more, work is lost

and, consequently, the energy of the batteries has been

wasted. This paper proposes a model that uses a cloud

service to register, save, pause and resume sessions

between MANET member nodes so that both work in

progress and energy are saved. A checkpoint technique

is introduced to capture the progress of a session and

allow it to be resumed. This is an additional service to

our cloud management of the MANET. The model

proposed in this paper was tested on Android-based

devices and an Amazon cloud instance. Experimental

results show that the model is feasible, robust, saves

time and, more importantly, energy if session breaks

occur frequently.

Keywords - component; MANET; checkpoint; cloud;

sessions.

I. I NTRODUCTIONThe most recent mobile devices offer greater

functionality to users than simply receiving and makingcalls. Users can check emails, browse the internet, and share

data or play games with friends. One example of the tasks amobile device can support is starting a session to do a jobas part of a client-server relationship within a mobile ad-hocnetwork (MANET). However, these sessions can beaffected due to mobile device features such as mobility orlimited battery power. Therefore, solutions for savingdevice resources have to be considered in the context ofsessions between MANET nodes.

In a previous paper [1], we proposed a model thatintroduced cloud services to deal with difficult MANETmanagement operations, such as IP allocation, split, mergeand the sudden departure of mobile users. After the set-upof a MANET, any node can establish a session to perform atask, for example, sharing a file, with another node of the

same MANET. Traditionally, if an active MANET sessionis interrupted because one of its parties suddenly departs,the session will be aborted/terminated and data lost.

In this paper, we propose a solution to deal with session breaks during execution. As an extension to our previousMANET management cloud service, a new cloud service isintroduced to help active sessions to be registered, savedand resumed. If the session has been saved, when twocorrespondents in an interrupted session become activeagain, the session can be resumed from the point that had been reached before disconnection occurred. Doing so will

avoid executing the whole session from the beginning, as isnormally the case in a MANET. To report session progress,a checkpoint technique is proposed whereby informationabout the session is captured and stored locally on mobiledevices. Using checkpoints makes it easier to resume asession. Different methods for setting up checkpoints areintroduced, based on how resource-intensive and importantthe session is.

When an interruption occurs, the latest, or every,checkpoint is uploaded to the cloud. The cloud will thenmonitor the connectivity of the nodes to notify them when both node states change from disconnected to active. As anadditional benefit of using cloud storage, the cloud servicecan take on responsibility for completing interruptedsessions if both parties are not directly connected.

The rest of the paper is organized as follows: section IIdiscusses similar works; section III introduces our model;section IV describes the implementation and experimentalframework; section V presents the experimental results andtheir interpretation. Finally, section VI presents ourconclusions and future work.

II. R ELATED WORK Different approaches to set up checkpoints have been

presented by Khunteta and Pooja [2]. They take intoaccount MANET properties such as mobility and device

limitations. The paper defines a checkpoint as “a fault-tolerant technique that is a designated place in a program atwhich normal processing is interrupted specifically to preserve the status of information necessary to allowresumption of processing at a later time” (p.31). Therefore,if a failure occurs, the computation can be restarted from themost recent checkpoint instead of repeating the whole taskfrom the beginning.

A checkpoint-restart solution is provided to deal withthe dynamic and long runtime of Infrastructure-as-a-Service(IaaS) clouds by Nicolae and Franck [3]. The solution isintended to reduce storage space and computationaloverheads. The idea concerns attaching virtual machine(VM) disk images to the checkpoint protocol at the user

level to accelerate resumption of the application process. Anumber of similar projects that use fault tolerance are alsodiscussed by Elnozahy et al. [4]. The system presented,known as BlobCR, periodically saves the global status of anapplication to maintain stable storage and then restarts theapplication from an intermediate point if an interruptionoccurs. The authors claim that checkpoints of disk-onlysnapshots are more compact and faster than those for thewhole status of a VM instance.

14th International Symposium on Parallel and Distributed Computing

978-1-4673-7148-3/15 $31.00 © 2015 IEEE

DOI 10.1109/ISPDC.2015.15

66


2/8

A system involving “follow me sessions” is proposed byHandorean et al. [5], whereby a session follows the clientand can be continued with another peer if disconnectionoccurs. As a result, the client is connected to a serviceinstead of being connected to a server. The paper assumesthat the new provider node offers the same functionality.The checkpoint technique is used to record the execution

state for the purpose of resuming the session from anintermediary point, preventing processor time being wasted.Two types of migration are provided: weak migration,where a session can be run from the beginning (notresumed), and strong migration, where a session is stopped,transferred, and resumed. The latter is more powerful but isalso more expensive to perform in terms of network,resources and delays.

To sum up, the idea of creating checkpoints in theMANET area is not new. However, to the best of ourknowledge, there has not been much done in the way ofresearch/solutions that has introduced cloud services to saveMANET active sessions.

III. SYSTEM DESIGN A. Model overview

The architecture of the system considered in this paper

is that of the mobile cloud. Mobile devices can connect to

the cloud, either directly or indirectly, using a cellular or

Wi-Fi network. Mobile devices can organize a MANET

and carry on joint tasks.

Figure 1. The mobile cloud model

Figure 1 shows a high-level view of our model, wherebyusers can register, save and resume a session with a cloudsession management service introduced to deal withdisconnection issues. When one of the correspondentsinvolved in the session is disconnected, the session can be

saved in the cloud and resumed when both users arereconnected. With the cloud service, the session can becompleted even if the two users are reconnected to differentMANETs. To avoid losing the job, each user creates acheckpoint locally that contains what has been performedso far. The most recent checkpoint is stored in the cloudwhen a disconnection occurs. As a result, when both users become active again, the session is re-established from thischeckpoint instead of starting the session from scratch.

Resuming a session can be done in two ways: either bythe cloud, where it sends a request to the users who wereinvolved in the session to remind them of the suspended job,or by the users, where one of them sends a request to thecloud to reactivate the session. One important advantage ofusing the cloud is that it works as a bridge between the twousers if they cannot communicate directly.

B. Session protocolsA protocol execution is triggered when a user sends a

request to the cloud to register a session. The requestincludes application details (ID, name, description, payload,etc.) and sender/receiver details (IDs, MANET, IPs, etc.).The cloud generates a unique ID and two security keys forthis session and then sends them to the requester. When therequester receives the session ID and the two keys, thesession can start. Figure 2 presents these steps graphically.

Figure 2. The sequence of operations needed to start a new session

When a session is established, the sender will create anew checkpoint each time an acknowledgement is receivedfrom the receiver. On the other side, the receiver will createa new checkpoint every time a new message is received. Allthe checkpoints are stored locally in a mobile devicedatabase to minimize communication with the cloud. Onlythe most recently stored checkpoint will be sent to the cloudif a disconnection occurs. If the session is completed, thesender notifies the cloud about the completion of thesession, whereupon the cloud stores the session informationin the log table in its database. Figure 3 shows an exchangeof messages between the sender, the receiver and the cloudto perform a session that is completed without anyinterruption.

If a session is aborted, the sender sends an “uncompletedsession” request to the cloud attaching the most recentlycreated checkpoint to the request. It is assumed that thereceiver also has the recent checkpoint saved locally. Thecloud updates the status of the session in its database thenchecks both users’ connectivity and sends a reminder when both users are reconnected. Figure 4 provides an illustrationof this.

67


3/8

Figure 3. A sequence diagram showing the start and completion of asession without interruption

Figure 4. A sequence diagram of a session that has been interrupted

C. Checkpoint frameworkThe main purpose of creating checkpoints is to

determine the progress of a session. This means that byreading such a checkpoint, the session can be resumed

without the need to start again from the beginning.Therefore, each checkpoint has to include information suchas application details and what has been done so far, as wellas what is left to complete the session.

In mobile devices, each checkpoint is represented as arow in a table. Table I provides the fields that eachcheckpoint has to include, as well as a description of eachone.

A new checkpoint is created each time any interaction between the sender and the receiver occurs.

Checkpoints can be useful when the session is a longone and there is a strong possibility of it being interrupted.However, in some cases, checkpoints could add anunnecessary overhead to a session. Therefore, different

checkpoint models are proposed here: Intensive: this creates a checkpoint each time a

new interaction occurs and, at the same time, storesit in a device database as well as uploading it to thecloud. The benefit of using this model is that it willsave mobile storage; users can delete checkpointsand retrieve them when a resumption process isstarted. On the other hand, it adds extra cost interms of time and energy.

Normal: this creates a checkpoint locally and onlyif a session is interrupted will it be uploaded to thecloud.

Local: this creates a checkpoint locally each time anew interaction occurs. Checkpoints will not beuploaded to the cloud at all, even if the session isinterrupted.

None: the checkpoint technique is not used at all.The latest, or every, checkpoint can be retrieved in the

case that it has been deleted due to the limited storage spaceof the mobile device. Retrieving a checkpoint can be donelocally between the sender and the receiver or from thecloud. In the latter case, the cloud has to check if the user is part of the session or is eligible to retrieve a checkpoint fromthe sender.

TABLE I. CHECKPOINT INFORMATION

Field Description

ID The unique ID of a checkpoint.

App IDA unique ID that is generated by the

session issuer.

Checkpointtype

Contains the checkpoint model.

Data sentContains the ID of a recently sent

chunk/part of the app's payload.

Data pathThis field is used only for a file path

in mobile external storage.

Sender ID The cloud ID of the sender.

Target ID The cloud ID of the receiver.

User keyThe key that is generated by the

cloud when the session is registered.

MANET ID The ID of the connected MANET.

Registration

ID

The ID received from the cloud after

the session is registered in the cloud.

ProgressWhat has been executed so far as a

proportion of the whole job.

Created timeA timestamp generated when the

checkpoint is created.

Uploaded to

the cloud

Flag: YES - the checkpoint was sent

to the cloud; NO – the checkpoint

was not sent to the cloud.

When a session correspondent does not receive any newACKs from the other party, it will be assumed that adisconnection has occurred. Resuming the session after aninterruption will be done either by the cloud or by one of theusers involved in the session. The following subsection

presents the two scenarios.1)Resumption by the session issuer

The sender can resume a suspended session from thelatest checkpoint when the correspondent reconnects.

However, if the correspondent is not reachable becauseit is not connected to the same MANET, is not a one-hopneighbour of the sender, or is not connected any more (forexample because of a dead battery), the sender can issue arequest to the cloud to look for the receiver to finish the

68


4/8

session. The result of the look-up will be one of thefollowing:

The receiver is not connected to the cloud and itsstatus is inactive: the cloud notifies the sender of the receiver status.

The receiver is connected to a differentMANET: the cloud will either merge the two

MANETs, as presented in our previous paper [1],or takes on the responsibility for completing thesession, which means the cloud acts as a bridge between the two.

The receiver is connected to the same MANETbut is not a one-hop neighbour of the sender: both users will complete the session using anintermediate node link.

2)Resumption by the cloudIf a session status is marked in the cloud as “paused”,

the cloud will monitor the connectivity of the two usersinvolved in the session. When both users are reconnected, anotification message is sent to the session issuer (the

sender). The action the cloud takes will depend on the replyfrom that user. If the session issuer (the sender) is interestedin completing the session, the cloud will then check towhich MANET each of the users is connected. If both usersare connected to the same MANET, the cloud waits for anyupdate to the session status. However, if the users areconnected to different MANETs, the cloud takes on thenotification finishing the session. In contrast, if the sessionissuer is not interested in completing the session, the sessiondata and details will be deleted. The second user (thereceiver) will also be notified that the session has beenignored at the sender’s side.

D. Security mechanismOnly users who have an account in the cloud can register

and resume a session. Nevertheless, the sender has theauthority to resume a session on another member ’s behalf.Once a session is registered in the cloud, two keys will bedistributed. Each key has a unique hash value that isgenerated by the cloud. The first key is for the sender andthe second is for the receiver. Hence, a user who is part ofsuch a session has to provide a key as well as a session IDto resume that session. As a result, the cloud will match therequester’s ID, its key and the session ID to ensure no roguedevices are attempting to claim resumption of a session ofwhich they were not a part. Regarding the session content,all data will be encrypted on the sender side, and decryptedon the receiver side. This ensures a high level of protection.

E. Session management in the cloudOnce a “session registration” request is received by the

cloud, the registration ID and security keys are generatedand sent back to the session’s issuer. After sending a sessionID and user keys to the requester, the cloud startsmonitoring this session.

IV. SYSTEM IMPLEMENTATION AND EVALUATIONThis section presents the implementation of the

aforementioned model. Two terms will be used frequently:

The session issuer (or sender): the user who startsthe session, also called the sender.

The target user (or receiver): the neighbour chosen by the sender with whom to perform the session.

A. Testing applicationsTwo sorts of application were used to test the protocol

validity: a sharing file application and a databasetransaction application.

1)Sharing file application

a) App descriptionThe file can, for example, be a utilities map of a city that

is shared by the rescue team in a disaster area (e.g., after ahurricane or earthquake). The MANET is set up andregistered in the cloud before deploying it in the disasterarea. The shared file will be split into several equal parts.

b) App interactionWhen the session is registered and acknowledged by the

target user, the sender starts sending parts of the file. Eachtime a part is received, the next part is sent and a checkpoint

is also created locally in the databases of both mobiledevices. This checkpoint is only uploaded to the cloud if anintensive checkpoint is chosen. When all parts have beensent and received successfully, the cloud will be notifiedabout the termination of the session. The receiver mergesall the file parts to obtain the original file.

2)Transaction application

a) App descriptionA session can be extended to perform transactions such

as executing queries on a database or downloading a filefrom a remote server using the neighbours’ links. Weimplemented a transaction to execute a number of databasequeries on the neighbour ’s side, as well as for retrieving

textual information from a cloud database.b) App interaction

A database query will be sent to the target user. Whenthe target user has received the request, it will acknowledgethe sender in order to create a checkpoint. Afterwards, thesender waits for the query to be executed. Once the query isexecuted successfully, the target user will redirect the resultto the sender. Finally, the sender sends anacknowledgement if the data are received successfully andcreates a new checkpoint. If the session is completedwithout a break, a notification will be sent to the cloud. Thelatest checkpoint will be uploaded with the progress of thesession if a break is detected.

B. Database modellingTwo databases were used in our model. A mobile device

database (DB) was used to store checkpoints periodicallyduring an active session. Secondly, the cloud database wasused to store session details and checkpoints. The followingtwo sections present these databases and their tables.

1)Mobile device DBTwo tables were created for the mobile device storage:

69


5/8

a) A checkpoint table that holds all the checkpoint

information (see Table I).

b) A session table that holds all the information for

the sessions (see Table II).

2) Cloud DB

The cloud will host a table in its database called the sessiontable. The table has similar fields to those presented in

Table II.

TABLE II. SESSION TABLE INFORMATION

Field Description

App IDContains a unique ID for the chosen

application.

App nameContains the chosen application name (for

example: file-sharing).

App

description

Contains the chosen application

description.

App

direction

Specifies if the session is outgoing or

ingoing.

Sender ID

& IP

Contains the sender ID in the cloud and

the MANET IP address.

Target IDContains the receiver ID in the cloud and

the MANET IP address.

Users’ keys

Contains the sender ’s and the receiver ’s

security keys to be used for resuming the

session.

MANET

SSID

Contains the SSID of the connected

MANET.

Registration

ID

Remains null unless the session is

registered in the cloud.

Progress

Specifies session current progress. Itcontains one of the following:

“Startup” when the session has juststarted.

“Finished” when the session is completed.

“Paused” when the session is interrupted.

Created atContains data and time regarding when thesession is created.

Stored in

the cloud

Contains either “YES” or “NO” dependingon whether session information was storedin the cloud database or not.

Latest

checkpoint

Remains null unless a session is pausedand a new checkpoint created.

C. Test scenariosThe experimental scenarios performed were:

a) Session is completed without interruptions.b) Interruptions occur . Session is interrupted before

receiving the last chunk/part of the session’s payload .

c) Resumptions

By the session’s issuer:o Session is resumed from the beginning.o Session is resumed from the latest checkpoint that

was sent before the session was interrupted.

By a one-hop neighbour.

By the cloud, where the cloud will only send anotification to the session issuer when both parties become reconnected.

D. Android app framework and interactionsThe mobile cloud system presented in our previous

paper was extended to evaluate this paper’s model. The

MANET activities (neighbour discovery, routing protocol)and cloud operations (login, logout, tracking membership)are dealt with in the pre-existing system, where only sessionmanagement is added. New activities were created in themobile app to serve this model.

a) Starting a new session activityThis activity provides the interface required to start a

new session.

b) Resuming a paused session activityIn this activity, a list of all paused sessions is presented.

If a user clicks on one of these paused sessions, aresumption operation is started.

c) All session activity

This activity shows a list of all the sessions in a mobiledatabase, completed as well as non-completed.

d) All checkpoint activityThis activity lists all the created checkpoints with the

ability to read the details of each checkpoint. Users candelete a checkpoint from the list, in which case the sessionis resumed from the beginning if the deleted checkpoint wasthe latest created in a paused session.

E. Cloud instance configurations and interactionsA Java Server Pages (JSP) page, hosted on the EC2

cloud [6], was developed to deal with mobile users’requests. For instance, if a user sends a session registrationrequest to the cloud, the request, including the generation ofsecurity keys, etc., will be dealt with on this page.Communication between mobile users and the clouddatabase is also dealt with through this page.

F. Data collectionTime and energy were calculated both in the case of

interruption using no checkpoint and when our checkpointmodel was used. We were interested in comparing in termsof energy and delay costs the no checkpointing case againstthe checkpointing cases, where a session is resumed fromthe latest checkpoint. This would show the overhead cost ofresuming a session, as well as the cost when no checkpointwas used.

An Eclipse IDE tool [7] was used to develop an Android

app using an ADT plugin [8] and cloud services using anAWS plugin [9]. Another plugin, called Trepn [10],captured energy consumption. A Trepn Profiler is adiagnostic tool that allows developers to profile the performance and power consumption of Androidapplications.

V. EXPERIMENTAL RESULTS AND INTERPRETATIONThe experiments were run on four devices: three

Samsung Galaxy S III smartphones and one HTC One smart

70


6/8

device. The devices were located within their radiofrequency range. Each experiment was run five times.

A. Checkpoint modelsThe main purpose of the experiment was to determine

the running cost of different checkpoint models. All theaforementioned checkpoint models (intensive, local,

normal and none) were tested.

Figure 5. Checkpoint models’ costs in terms of time

Figure 6. Checkpoint models cost in terms of power

Figures 5 and 6 show that using an intensive checkpointhas the highest cost because each time a new checkpoint iscreated, it is uploaded to the cloud at the same time. Thenormal model was less costly but still higher than the localand none models. However, using a local checkpoint resultsin a cost comparable with not using a checkpoint.

For example, completing a session using intensivecheckpoints results in around a 50% increase in the costversus completing the session without creating checkpoints.Here, repeating the session from the beginning would be better than using the intensive model.

Therefore, using intensive and normal modes will addan unnecessary overhead to the system if the session is short

or its completion is not essential. However, it would becounterproductive if the session were sensitive, requiring along computational process, such as joining multi-queriesin the case of a database transaction, or the link was notstable and there was a higher chance that a break couldoccur.

B. The cost of using checkpointsWe calculated the checkpoint cost using the

following equation: = + (1)

Where is the cost of completing the session without

interruption and is the cost of completing the session

using a checkpoint technique. This includes the totaloverhead.

1) File app resultsLooking at the left-hand side of Figures 5 and 6, it is clear

that using local checkpoints results in a slightly higher costin terms of time and energy compared with no checkpoint:13-18% and 6-14%, respectively, higher than performingthe session without creating any checkpoints. However, thisextra cost adds strength to the app; it guarantees that progress is saved and what it has already performed will not be repeated.

2) Database transactions app resultsThree different database queries - create, insert, and

union - were sent from one device to another within thesame MANET. The right-hand side of Figures 5 and 6shows that creating checkpoints locally will result in aslightly higher cost compared with the cost resulting fromexecuting the session normally. Using the normal and

intensive models will result in a higher cost compared with both no checkpointing and local models. These models arerecommended in the case of an unstable link between twonodes, or if the session has a large amount of data.

C. Session resumption overheads

1)LocallyThis experiment reported the overheads associated with

resuming a session. When a session is interrupted and acheckpoint technique has been used, the session can beresumed from the latest checkpoint. The type of applicationthat was used in this session had no impact on this process.However, before resuming a session, the following actionswere performed:

Retrieving the session details, including the latestcheckpoint ID.

Retrieving the latest checkpoint to identify whathad been sent and received before the session break.

Checking if the target user who was involved in thesession is active and reachable.

Delays resulting from the above operations werecollected and are presented in the following chart.

Figure 7. Resuming sessions overheads in terms of time

Figure 7 shows that the average delay time resultingfrom preparing a paused session for resumption is around30 milliseconds. This amount of time is reasonable andensures that the session will not restart from scratch.

71


7/8

2)Cloud initiativeResuming the suspended session can be done by the

cloud, as mentioned earlier. We found that sending a resumerequest to the cloud took around 2 seconds and consumedaround 1 milliwatt per hour. These results were higher thanresumption overheads locally. As devices can only run inone mode, either in the ad-hoc or normal mode, a cellular

interface is required to reach the cloud. However, if userscan reach the cloud using a Wi-Fi connection whileconnecting to an active MANET, this will result in aroundhalf of that delay with less energy usage.

Figures 8 and 9 present the overheads incurred when the paused sessions were resumed using the cloud services with95% confident intervals.

Figure 8. Resumption overheads using cloud services in terms oftime

Figure 9. Resumption overheads using cloud services in terms of power

D. Energy consumptionFor the file-sharing application, we compared the total

amount of battery energy used to resume a session using acheckpoint technique with the energy used to resume asession without checkpoints. We calculated the cost ofresumption by using Equation 2:

If

is the cost of completing the session after a breakoccurs and is the cost resulting from interrupting the

session before the last part is received, the cost of resumingthe session, , will be:

= + (2)Once no checkpoint is used, the session will start from

scratch, which means the value of will be equal to thecost resulting from performing the session without incident.

On the other side, the cost of resuming the session whencheckpoints are used, , will be the sum of which is

the cost resulting from a interrupted session that usedcheckpoints and ,which is the cost of completing the

session from the latest checkpoint (see Equation 3). = + (3)

Figure 10 compares the cost resulting from resuming asession when a checkpoint technique was used with onewhen it was not. The left-hand side of this chart shows that

using a checkpoint technique can save up to 37% moreenergy than an interrupted session that did not createcheckpoints.

For the database application, we calculated the costresulting from resuming a transaction session usingEquations 2 and 3. The right-hand side of Figure 10indicates that using our scheme could save up to 36% of thecost resulting from a session that is interrupted and nocheckpoints were created.

Figure 10. Cost of resuming sessions in terms of energy

E. Resumption by a peer

This experiment showed the cost of resuming an

interrupted session via a neighbour who is one hop away

from both users (sender and receiver). We calculated the

cost of resuming the session via a peer using Equation

4: = + (4)

Where is the cost resulting from an interrupted

session that used checkpoints and is the cost of

completing a session from the latest checkpoint through a peer. We used the OLSR routing protocol, thus anintermediate peer was chosen from the routing table.

Figures 11 and 12 show the cost of resuming aninterrupted session through another neighbour and the costof resuming a session without using a checkpoint technique.These two charts show that the cost of resuming a sessionvia a peer one hop away from the sender and the receiverconsumed around 30% more power than that consumed byrepeating the session from the beginning when the break inthe link occurred. However, the receiver might not bereachable any more. However, since the receiver might not be reachable any more, the extra cost that this entails should be taken into account when considering the peer resumptionmethod as a possible solution. . Furthermore, each time thesender fails to reach the receiver, the total cost will beincreased, so resuming the session from the beginning mayresult in higher costs than resuming the session throughanother peer.

72


8/8

Figure 11. The cost of resuming via a peer and the cost of resumingnormally in terms of time

Figure 12. The cost of resuming via a peer and the cost of resumingnormally in terms of power

VI. CONCLUSIONS AND FUTURE WORK Loss of work and resources in a MANET when sessions

are broken is a serious problem. This paper demonstratesempirically that saving session details in the cloud will provide robustness to the network as a session can beresumed as soon as the disconnected node(s) reconnect.Furthermore, if the corresponding nodes are connected to

different MANETs, the session can still be completed by thecloud as the cloud works as a bridge to finish the session.The use of the cloud service does not affect the ad-hocnature of a MANET. On the contrary, it supports the sessioncompletion in the context of users’ mobility and mobiledevices’ scarce resources.

According to the experimental results, the energyconsumed by resuming a session locally is around one-thirdlower than when a session is interrupted and no checkpointis used. Using a checkpoint technique will add 6-14% extracost (in terms of energy) to the session but will ensure thesession will not restart from scratch. In addition, aninterrupted session can be resumed if its users cannotcommunicate directly. Even though this will consume more

power, it can be considered as a feasible solution. Theresults could be even better if a session takes a long timedue to large data transfers.

The results presented in this paper can be used as a guidefor the best practice regarding session management in aMANET. Applications history or current network parameters can be used as input into the decision componentto decide before a session starts if checkpoints are worthusing or not.

Future work will include the aforementioned securitymechanism. We will also implement session resumptionusing the cloud and we plan to capture the time and energyconsumed by that type of resumption.

ACKNOWLEDGEMENTHazzaa Alshareef’s PhD research is funded by the Saudi

Electronic University in Saudi Arabia.

R EFERENCES

[1] H. Alshareef and D. Grigoras, "Mobile Ad-hoc

Network Management in the Cloud," Parallel and

Distributed Computing (ISPDC), 2014 IEEE 13th

International Symposium, pp. 140-147, 2014.

[2] A. Khunteta and S. Pooja, "A Survey of

Checkpointing Algorithms in Mobile Ad Hoc

Network," Global Journal of Computer Science and

Technology, pp. 30-38, 2012.

[3] Amazon, "AWS | Amazon Elastic Compute Cloud

(EC2) – Scalable Cloud Servers.," [Online].

Available: http://aws.amazon.com/ec2/. [Accessed

21 Feb 2014].

[4] Amazon, "AWS Toolkit for Eclipse," Amzon,

[Online]. Available:

http://aws.amazon.com/eclipse/. [Accessed 23 Feb

2014].

[5] Eclipse IDE, "The Eclipse Foundation," 2007.

[Online]. Available: https://www.eclipse.org/.

[6] Android Development , "Android Development

Tools (ADT)," [Online]. Available:

http://developer.android.com/tools/sdk/eclipse-

adt.html. [Accessed 23 Feb 2014].

[7] E. N. M. Elnozahy, L. Alvisi, Y.-M. Wang and D.B. Johnson, "A Survey of Rollback-recovery

Protocols in Message-passing Systems," ACM

Computing Surveys (CSUR), no. ACM, pp. 375-

408, 2002.

[8] R. Handorean, R. Sen, G. Hackmann and G.-C.

Roman, "Context Aware Session Management for

Services in Ad Hoc Networks," IEEE International

Conference on Services Computing, no. IEEE, pp.

113-120, 2005.

[9] B. Nicolae and C. Franck, "BlobCR: Efficient

Checkpoint-restart for HPC Applications on IaaS

Clouds Using Virtual Disk Image Snapshots,"

Proceedings of 2011 International Conference for

High Performance Computing, Networking, Storage

and Analysis, no. IEEE, pp. 1-12, 2011.

[10] Qualcomm, "Trepn Profiler," [Online]. Available:

https://developer.qualcomm.com. [Accessed 01 09

2014].

73

manet sessions

Documents