An energy-efficient object discovery protocol for context-sensitive ...knarig/candidacy/energyefficient.pdf · context-sensitive ubiquitous computing environment and energy-efficiency

An Energy-Efficient Object Discovery Protocolfor Context-Sensitive Middleware for

Ubiquitous ComputingStephen S. Yau, Fellow, IEEE, and Fariaz Karim, Member, IEEE

Abstract—Many ubiquitous computing applications may be context-sensitive due to the ambient environments, mobile devices, and

other detectable factors. A context-sensitive middleware provides the necessary support to context-sensitive application objects to

participate in spontaneous and ad hoc communications with other applications in remote devices whenever suitable contexts exist. A

context-sensitive middleware can provide this support effectively if its communication subsystem, such as an Object Request Broker

(ORB), can properly discover other objects in devices. This capability is usually known as object discovery protocol. An energy-efficient

object discovery protocol is needed to help prolong a device’s battery life because many devices in ubiquitous computing environments

are battery-powered and, thus, have limited energy sources. In this paper, an energy-efficient object discovery protocol, RKS, for

context-sensitive middleware for ubiquitous computing is presented. RKS reduces energy consumption by reducing the amount of

information that needs to be sent to remote devices to discover objects. A novel feature of RKS is that it advertises its server-objects’

availability only when it detects that these servers can be activated in the current context and when it finds that the neighbor devices

have some potential clients that are willing to discover objects. Analytical comparisons of the energy-consumptions are given between

RKS and two other protocols for object discovery in context-sensitive middleware. Furthermore, our experimental results, based on the

implementations of these protocols and RKS on a context-sensitive middleware test bed, confirm our analytical results in that the RKS

conserves more energy than the other two.

Index Terms—Object discovery protocol, context-sensitive middleware, ubiquitous computing, mobile ad hoc networks, energy

efficiency, reconfigurable context-sensitive middleware.

�

1 INTRODUCTION

CONTEXT-SENSITIVITY is a desirable characteristic for manyapplications that need to operate in ubiquitous com-

puting environments [1], [2], [3], [4]. Ubiquitous computing(also known as pervasive or invisible computing) environ-ments can be considered as a collection of embedded,handheld, wearable, and mobile devices, all intermittentlyconnected to each other through wireless connections andpossibly to fixed network infrastructures such as the WorldWide Web. A common goal of many ubiquitous computingapplications is to make information accessible anywhereand anytime by making the enabling computing andcommunications technology essentially invisible and moreautonomous. Context-sensitivity facilitates this goal sincethis characteristic allows application objects to sense andanalyze different contexts, such as the location of a hostdevice, data from various sensors, the state of the ambientenvironment, and user profiles. Context-sensitivity enablesa software system to adaptively take different actions indifferent contexts.

Many context-sensitive applications may also need toengage in spontaneous and ad hoc communications withremote devices if these applications need some specific

services or information in different conditions [5], [6], [7],[8], [9], [10], [11]. Since the topology of the network isexpected to change due to device mobility, a device mustdynamically discover other devices, identify if any of thepeer devices has a service or data that it needs and, if so,establish a short-lived ad hoc network with the appropriatedevice to exchange the necessary information. This style ofcommunication is also known as context-sensitive commu-nication because the establishment of such communicationlinks is triggered by the context of context-sensitiveapplications. As it can be deduced, a prerequisite ofestablishing context-sensitive communication links is todiscover objects in other devices by sensing when anapplication object becomes ready-to-be-activated in thecurrent context. To facilitate the discovery process, a devicewith ready-to-be-activated objects can transmit willingnessmessages to discover remote ready-to-be-activated in otherdevices.

Providing this type of object discovery mechanism insidea middleware architecture, especially if it is a context-sensitive middleware [5], can be very effective for manydifferent reasons. A middleware, by its very definition,provides a uniform, often standardized, and single-pointsolution for many distributed computing needs [12], [13].The communication subsystem of a middleware, such as itsObject Request Broker (ORB), often needs to providecommunication intensive services that include connectingtwo remote objects. In an enterprise network environmentwhere clients usually know the servers beforehand, theobject discovery issue is not important. However, inubiquitous computing environments where devices may

1074 IEEE TRANSACTIONS ON PARALLEL AND DISTRIBUTED SYSTEMS, VOL. 14, NO. 11, NOVEMBER 2003

. S.S. Yau is with the Department of Computer Science and Engineering,Arizona State University, P.O. Box 875406, Tempe, AZ 85287-5406.E-mail: [email protected].

. F. Karim is with Intel Corporation, RA3-250, 2501 NW 229th Ave.,Hillsboro, OR 97124-6794.E-mail: [email protected] and [email protected].

Manuscript received 8 Dec. 2002; revised 31 July 2003; accepted 3 Aug. 2003.For information on obtaining reprints of this article, please send e-mail to:[email protected], and reference IEEECS Log Number 118746.

1045-9219/03/$17.00 � 2003 IEEE Published by the IEEE Computer Society

operate in both mobile (both infrastructure and ad hoc) andin fixed-network environments, dynamic discovery ofobjects is a norm.

Object discovery mechanisms in a middleware should beenergy efficient because most devices in ubiquitouscomputing environments are battery-powered. Hence,judicious use of power by such a protocol can help a deviceto prolong its battery life. In this paper, we will addressthese issues and present an energy-efficient object discoveryprotocol, RKS, for context-sensitive middleware for ubiqui-tous computing. RKS will reduce its energy consumption byreducing the amount of information that needs to be sent toremote devices to discover objects. A novel feature of RKS isthat, instead of having the clients query or having theservers broadcast periodically, RKS advertises its server-objects’ availability only when it detects that these serverscan be activated in the current context and when it findsthat the neighbor devices have some potential clients thatare willing to discover objects. RKS does not assume anyspecial features from the underlying network layer, such asneighbor discovery or location detection functionality. Wehave analytically compared the energy consumption of RKSin a given period with two other protocols, P1 and P2, thatare used in context-sensitive middleware for ubiquitouscomputing. P1 is a predecessor of RKS and broadcasts onlythe server objects’ information whenever the servers’ ready-to-be-activated set changes. The second one, which we referto as the P2 protocol, broadcasts all the object information(related to both client and server objects) periodically,whenever the ready-to-be-activated set changes. We chosethese protocols because their designs allow for spontaneousobject discovery in the middleware for ad hoc networkenvironments. Our experimental results, based on theimplementations of the P1, P2, and RKS protocols on an802.11b-equipped ad hoc network using our ReconfigurableContext-Sensitive Middleware (RCSM) [5], [10], [14], in-dicate that RKS conserves more power than the other two.

2 RELATED WORK

Various work and standards on service discovery protocolscurrently exist. However, only a few have addressed thecontext-sensitive ubiquitous computing environment andenergy-efficiency as their main foci. Among the maturemiddleware standards, CORBA specifications include itsNaming Service and Trader Service architectures. Theseservices, while rich in functionality, essentially require aninfrastructure-based approach to locating objects. Sun’sJava-based JINI architecture also follows this model, wherea client must find a location service to discover newservices. For mobile ad hoc networks, the JSDP protocolprovides a method for both immediate and mediatedservice discovery [15]. The Bluetooth standard includes aspecification for Service Discovery Protocol (SDP), whichdetails the methods for discovering various services in aBluetooth piconet or scatternet environments [16]. SDPprovides searching capability based on service attributesand service classes. The actual process of discoveringservices involves opening an L2CAP connection channelto a remote device and querying the necessary services.GSD is also a service discovery protocol for mobile ad hocnetworks that relies on an advertisement-based method todiscovering various services [17]. SDS is an infrastructure-based secure service discovery architecture that alsoincludes security and XML-based encoding to query

different services [18]. Research in energy-efficiency inubiquitous or mobile computing environments has mainlyfocused on various MAC protocol design and low powerhardware design issues. For example, various ways ofpredicting the usage and communication patterns tooptimally manage energy sources have been discussed in[19], [20], [21], [22]. A different strategy is taken in [23], byaugmenting PDAs with a second low-power radio trans-ceiver to reduce energy consumption of the more energy-consuming 802.11 adapters.

Our approach differentiates from the above mentionedenergy-efficient techniques in the sense that we reduceenergy consumption in the middleware level withoutimposing additional assumptions on the type of operatingsystem, hardware, or network layers. In addition, althoughenergy could be conserved by other approaches that focuson the network or data link layer, our approach is focusedabove the presentation layer, especially in the middlewarelevel. A middleware resides just below the applicationsoftware and, hence, it is often best suited to monitorvarious application-specific runtime data, such as theamount of data sent and received and the frequency ofsend and receive operations. Since it is the applications thatmainly drive the communication cost and consequently theenergy consumption of a device, a middleware-orientedapproach to help conserve the energy of a device canprovide the greatest benefit.

3 TARGET ENVIRONMENTS

We assume a device, which will use our middlewareprotocol, RKS, will have the necessary hardware capabilityto work in mobile ad hoc networks using available wirelessnetwork technologies, such as 802.11 or Bluetooth. It meansa communication link can be established among a numberof devices without relying on a fixed base station (e.g., anaccess point in an 802.11 network). Devices are free to movearbitrarily, connect with other mobile and stationarydevices, and typically have limited energy sources. We alsoassume that applications running in the devices are context-sensitive, which means these applications may takedifferent or no actions at different times and contexts.

As shown in Fig. 1, we assume that an RKS in a devicewill use the point-to-point unicast services of a transportlayer (e.g., TCP). In addition, the RKS needs to usebroadcast (e.g., UDP datagrams) functionality to exchangebeacon messages with other remote instances of the sameprotocol.

4 ENERGY CONSUMPTIONS OF OBJECT DISCOVERY

PROTOCOLS FOR CONTEXT-SENSITIVE

MIDDLEWARE

In this section, we will discuss two factors that affect theenergy consumptions during object discovery. These twofactors are the amount of date transmission and receptionand the level sensitivity. Although many other factors areimportant, we chose to study these two because they can beclosely observed and controlled in the middleware level.Clearly, an object discovery protocol in a device needs tocommunicate with other devices whenever the applicationsneed to communicate with other remote applications.Hence, it is important to understand how much data and

YAU AND KARIM: AN ENERGY-EFFICIENT OBJECT DISCOVERY PROTOCOL FOR CONTEXT-SENSITIVE MIDDLEWARE FOR UBIQUITOUS... 1075

how often an object discovery protocol needs to commu-nicate with other devices.

4.1 Amount of Data Transmission and Reception

Object discovery for context-sensitive ubiquitous comput-ing must work in environments where devices have limitedenergy sources. To understand the importance of thisproblem, we have performed a simple experiment toobserve the energy consumption of a Casio E-200 PDA inidle (with and without a network adapter) and in a10 millisecond broadcast mode. After 20 minutes, as shownas the IWN bar in Fig. 2, the PDA lost almost 10 percent ofits power in the idle receiving mode, but without any actualdata reception. On the other hand, the PDA did not lose anypower without the network adapter card attached, asshown as the INN bar in Fig. 2. When the PDA wasbroadcasting 1K of data in every 10 milliseconds, the energylevel of the PDA dropped to almost 70 percent of its fullpower. Although we chose an 802.11b card as our networkadapter in this experiment, the results can be generalized toother wireless communication networks [24], [25], [26], [27].Feeney and Nilsson [26] empirically showed that the energyconsumption behavior for an 802.11 card in ad hocnetworking mode follows the equations below:

Esend � msend � Sizsend þ bsendð Þ ð1ÞEreceive � mrecv � Sizreceive þ brecvð Þ; ð2Þ

where Esend and Ereceive are energy consumptions due tosend and receive, respectively, bsend and brecv are fixed costs,and msend and mrecv are incremental costs associated withsend and receive, respectively. Sizsend and Sizreceive repre-sent the size of being sent and received. The values derivedfrom (1) and (2) are expected to generate different costsdepending on whether a unicast or a broadcast-basedmethod is used. Unicasts are usually more expensive due tothe RTS/CTS and ACK cost associated with a sendoperation [26]. Note that other factors, some of whichcannot be controlled by a single device, especially not by amiddleware, affect the energy consumption as well. Forexample, devices in a highly dense ad hoc network mayconsume more energy than those in a lightly dense networkdue to increased probability of packet collisions. Never-theless, as (1) and (2) indicate, from a middleware protocoldesign perspective, the parameter that can be controlled isthe Sizsend. However, a reduced Sizsend on a device does notnecessarily mean a reduced Sizreceive on some other devices.This depends on whether the broadcast or unicast methodis used. Therefore, controlling the Sizsend parameter so thatSizreceive stays small is an important issue in an energy-efficient object-discovery protocol design.

4.2 Level of Sensitivity

In ubiquitous computing, context changes cause differentapplication objects in a single device to become ready-to-be-activated at different times. For example, context-sensitivepersonal messaging applications, such as the ones pre-sented in [9], [10], change their information sources andmethods of delivering their messages based on their users’contexts. What it means for an object discovery protocol isthat new objects become available and some objectsdisappear when the ready-to-be-activated set changes.1

This points to the level of sensitivity issue. By level of


Fig. 1. RKS in the communication subsystem of a context-sensitive middleware.

Fig. 2. Energy consumption of a Casio E-200 PDA in idle (with and

without a D-Link 660W 802.11 adapter) and 10 msec broadcasting

modes.

1. How and when these application objects decide that they are ready-to-be-activated depends on application-specific requirements, current context,and the nature of context analysis [5].

sensitivity, we consider how quickly an object discoveryprotocol in a device can find the latest ready-to-be-activatedsets in a network. More specifically, the level of sensitivityLS can be simply described as follows:

LS ¼ FCSC

Ts � Tcscð Þ ; ð3Þ

where FCSC is the frequency at which the protocol checkswhether ready-to-be-activated set has changed, Ts repre-sents the time when the latest ready-to-be-activated set isreceived in a device, and Tcsc represents the time when theready-to-be-activated set has most recently changed in otherdevices. Obviously, an object discovery protocol can reduceenergy-consumption by reducing the FCSC parameter (bysleeping longer), but such redcution will decrease the valueof LS. On the other hand, the value of Ts � Tcscð Þ, in reality,is never zero due to the latency in the protocol processingand communication protocols.

Clearly, if the ready-to-be-activated set is empty, there isno need to discover objects at all and, hence, energy isconserved by default. However, if the ready-to-be-activatedset and the number of devices in a network continue tochange, the above factors become considerable issues. Basedon the discussion above, we can formulate our problem fordesigning an energy-efficient object discovery protocol basedon the following criteria: the protocol should use a broadcast-based approach, reduce the amount of data to send, andprovide a high-level of sensitivity.More specifically, if such aprotocol operates for T time units, then it should achieve thefollowing primary goal:Minimize Sizsend andSizreceive in (1),with a reasonably high level of sensitivity as presented in (3).

We will evaluate RKS by both analytically and experi-mentally comparing the energy-efficiency of RKS with twoother protocols, P1 and P2.

5 OUR ENERGY-EFFICIENT OBJECT DISCOVERY

PROTOCOL RKS

RKS reduces energy consumption by reducing the numberand amount of information that need to be broadcasted andunicasted to remote devices. RKS does not rely on acentralized approach to discovering objects. It assumes anunderlying TCP/IP-like network protocol stack that pro-vides broadcast and unicast functionality. RKS does notrequire any specialized services, such as a neighbor-discovery protocol or a neighbor lookup service. RKSassumes that it is notified with a context-match event whenan application object becomes ready-to-be-activated in thecurrent context. We highlight the main concepts of RKS inthe following sections. All the terms for RKS are defined inTable 1.

5.1 The Key Idea of RKS

We use a scheme that adaptively broadcasts small messagesand unicasts large messages. As illustrated in Fig. 3, thescheme works as follows: RKS uses low energy-consumingbroadcast messages to advertise the willingness of a deviceto discover or to be discovered by other devices. Instead ofcontaining all the information about the ready-to-be-activated objects, these willingness broadcast messagescontain the device identifier and encoded informationabout the ready-to-be-activated set of objects in a device.If another device receives such a willingness beacon, itessentially detects a device with context-sensitive objects.This process corresponds to the device detection. Followingthe detection of a device and based on the informationobtained from the willingness beacons, RKS uses point-to-point unicast messages to retrieve objects’ information fromthe appropriate device. As such, the decision to obtain allthe information about a device is now left to the receiver ofthe beacon. If no unicast discovery message is received, the


TABLE 1Definitions of Terms for RKS

source device turns off its willingness beacon knowing thatno device in the network is willing to discover objects.

Here, unnecessary energy consumption is reduced intwo ways. A device now has the ability to turn off smallerwillingness messages if no device queries this object.Furthermore, an interested device only uses unicastmessages to discover the actual information about theready-to-be-activated objects. This means other devices,which are not interested, do not need to unnecessarilyreceive information about remote objects.

An additional benefit of this scheme is that, because themessages that contain all the information about ready-to-be-activated objects are usually much larger than the will-ingness messages, broadcasting too many such largemessages in a dense mobile ad hoc network might causethe broadcast storm problem [28]. This problem mayindirectly cause devices to drain more energy unnecessarilydue to higher probability of packet collisions. This problemmay now be significantly reduced due to the combinationour broadcast-small-messages and unicast-large-messagesscheme. We have observed this in our experiments, asdevices receive less broadcast messages when using RKSthan using P1 or P2.

5.2 RKS Protocol Description

RKS operates in the following two phases:

Phase 1—Willingness Beacon Advertisement: In thisphase, RKS checks whether it is suitable to broadcast thewillingness by analyzing two conditions. First, RKS exam-ines whether there is any neighbor device with outgoingIM_PAIRs that are currently willing to discover incomingIM_PAIRs. Second, RKS checks whether any ready-to-be-activated IM_PAIR currently exists in the local device. Ifboth conditions are true, RKS broadcasts a willingnessmessage. As shown in Fig. 4, the message contains theIP address of the host device and encoded informationabout the ready-to-be-activated IM_PAIR. If these condi-tions are not true, RKS shuts down its willingness broad-cast. However, it restarts the beaconing process once itreceives a willingness beacon from a remote device.

Phase 2—Object Information Discovery and PeerMatching: In this phase, RKS discovers the compatiblecommunication endpoints in remote devices. By detectingsuch willingness broadcast messages from remote devices,


Fig. 4.RKS’sORB_I_BEACON (orORB_O_BEACON)beaconmessage.

Fig. 3. Examples to illustrate RKS. The ovals represent devices, solid arrows represent ORB_I_BEACON, and dotted arrows represent

ORB_O_BEACONs, respectively. The heavy arrowwith a hollow arrowhead represents unicast request-reply message. The sequence starts from (a).

RKS performs unicasts to the appropriate neighbor deviceto discover the capability of incoming IM_PAIRs. After asuccessful unicast, the peer matching process starts. Aftersuccessful peer match, objects in both are activated and dataexchange is initiated.

5.3 RKS’s Normal and Energy-Save States

Since a device may have both incoming and outgoingIM_PAIRs, at any instance, RKS’s state is defined by {I_X,

O_Y}, where X and Y individually represents either the“normal state” or the “energy-save-state.” Hence, a total offour states are possible. To ensure safety and livelinessproperties, RKS broadcasts either an ORB_I_BEACON orORB_O_BEACON whenever it receives the first context-match event from the upper layer. RKS, in both devices,begins in {I_ENERGY_SAVE, O_ENERGY_SAVE} state.

I_NORMAL: As shown in Fig. 5a, this state correspondsto the context-matched IM_PAIRs in a device to indicate


Fig. 5. RKS state transition diagrams for (a) incoming IM_PAIRs and (b) outgoing IM_PAIRs.

TABLE 2Data Structure Definitions for Energy-Efficient RKS’s Algorithms

that RKS can detect devices that have context-matched andoutgoing IM_PAIRs in remote devices. In this state,whenever RKS finds that new INC_CM_EVENTs arepending, it broadcasts an ORB_I_BEACON.

O_NORMAL:As shown in Fig. 5b, this state correspondsto outgoing IM_PAIRs to indicate that RKS candetect devicesthat have context-matched and incoming IM_PAIRs. In thisstate, RKS broadcasts an ORB_O_BEACON whenever itdetects that one or more OUTC_CM_EVENTs are pending.

I_ENERGY_SAVE: This state corresponds to the energysave mode corresponding to incoming IM_PAIRs. RKS canbe in this state for two reasons. First, RKS has not detectedany device with context-matched and outgoing IM_PAIRs.In this state, if RKS sees new INC_CM_EVENTs, it simplyupdates this information. However, if the INC_CM_EVENTis the first in this state, RKS broadcasts an ORB_I_BEACONto “wake-up” any remote RKS with pending context-matched outgoing IM_PAIRs. The second reason is simplythat no pending INC_CM_EVENT exists.

O_ENERGY_SAVE: This state corresponds to the en-ergy save mode corresponding to outgoing IM_PAIRs.Being in this state means that RKS has not either 1) detectedany device with context-matched and incoming IM_PAIRsin the current cycle, or 2) found any updates in theORB_I_BEACONs received previously. In this state, if RKSreceives OUTC_CM_EVENTs, it simply updates this in-formation, but does not send out any information. How-ever, just like in the case of I_ENERGY_SAVE_STATE, RKSbroadcasts an ORB_O_BEACON if the OUTC_CM_EVENTis the first one in the energy_save mode.

5.4 RKS’s Algorithms

We will first define some terms as shown in Table 2 tofacilitate the discussion. We will present our algorithms forPhases 1 and 2 in the following steps:

1. RKS periodically checks its incoming messagequeue. If there is no message, it goes to sleep andrestarts Step 1. Otherwise, it continues to Step 2.

2. RKS checks whether any O_BEACON or anyIM_PAIR object discovery unicast is received. Iftrue, it sets the BCAST_OR_UCAST variable to true.

3. RKS checks whether any I_BEACON is received. Iftrue, RKS checks whether the I_BEACON came fromalready known neighbors and, if so, RKS checkswhether the beacon contains information about anynew incoming IM_PAIR. If yes, RKS sets theI_BEACON_RECEIVED to true. Otherwise, it re-mains false.

4. RKS checks whether the BEACON_OR_UCAST istrue or the I_STAY_IN_NORMAL variable is greaterthan zero. A true value causes RKS to perform Step 5.A false value causes RKS to perform Step 6.

5. The current state is I_NORMAL. If the previous stateis I_ENERGY_SAVE, RKS sets the I_STAY_IN_NORMAL to a specific value—it is 5 in our implementa-tion—and the FIRST_I_CM_EVENT_OCCURRED tofalse. RKS constructs and broadcasts an ORB_I_BEACON and goes to sleep. If the previous state isnot I_ENERGY_SAVE, RKS directly broadcasts anORB_I_BEACON and goes to sleep.

6. (Alternative step of Step 6) The current state isI_ENERGY_SAVE. If the FIRST_I_CM_EVENT istrue, RKS broadcasts an ORB_I_BEACON and sets

the FIRST_I_CM_EVENT to true. If the FIRST_I_CM_EVENT is false, RKS directly goes to sleep.

7. RKS checks whether the I_BEACON_RECEIVED istrue or the O_STAY_IN_NORMAL variable is great-er than zero. A true value causes RKS to performStep 8. A false value causes RKS to perform Step 9.

8. The current state is O_NORMAL. If the previous stateis O_ENERGY_SAVE, RKS sets the O_STAY_IN_NORMAL to a specific value—it is 5 in our imple-mentation. RKS sets the FIRST_O_CM_EVEN T_OCCURRED to false. RKS constructs and broadcasts anORB_O_BEACON. RKS now checks whether it hadqueried the same neighbor before. If false, RKSperforms a unicast message to discover the incomingIM_PAIRs of that device.

9. (Alternative of Step 8) The current state is O_ENERGY_SAVE. If the FIRST_O_CM_EVENT is true,RKS broadcasts an ORB_O_BEACON, sets the


Fig. 6. Incoming beacon and IM_PAIR unicast request processing in

RKS.

FIRST_O_CM_EVENT to false, and goes to sleep. Ifthe FIRST_O_CM_EVENT is false, RKS directly goesto sleep.

Steps 1 through 3, as illustrated in Fig. 6, correspond toRKS’s incoming beacon and incoming unicast messageprocessing. It is important to note that the RTA set allowsRKS to avoid sending IM_PAIR messages to devices withno recent change in their incoming IM_PAIRs. In Steps 4, 5,and 6, RKS decides the suitability of generating anORB_I_BEACON to let other devices know of the newlyavailable local incoming IM_PAIRs. In Steps 7 and 8, RKSuses this algorithm to decide the suitability of broadcastingwillingness messages to indicate that it is now willing todiscover incoming IM_PAIRs. RKS uses Steps 8 and 9 toperform IM_PAIR unicast operations to facilitate theoperations in Phase 2. It is important to note that in Step 8,the decision to query a neighbor depends on either 1) theneighbor is a new device, which means it has not beenqueried about its incoming IM_PAIRs yet, or 2) theneighbor has been in the vicinity for sometime, but its listof available incoming IM_PAIRs have changed due to somechange in context.

6 IMPLEMENTATION AND EVALUATION OF RKS

We evaluate RKS by first, analytically comparing it with P1and P2 protocols based on energy efficiency (see Section 1,last paragraph). We were limited to these protocols since wecould not find existing protocols that simultaneouslyaddress energy-efficiency during object discovery in themiddleware level.

6.1 Analytical Results

Due to limited space, instead of presenting the details of theanalysis, we will focus on the results of the analysis. RKSsaves energy over P1 and P2 as long as a mobile ad hocnetwork becomes stationary for sometime during its opera-tion. If a mobile ad hoc network immediately becomes astationary ad hoc network, the best case occurs. On the otherhand, theworst case occurs when the number of ready-to-be-activated objects (possibly due to some fluctuation in contextor mobility) and all the neighbor devices change constantly.In this case, all the newneighbor devices continue to discoverthe local ready-to-be-activated objects and, thus, RKS always

remains in the normal states. As such, RKS consumes slightlymore energy than P1 due to send operations of theORB_I_BEACON and ORB_O_BEACONs. However, inter-estingly, even during the worst-case, RKS saves energy overP1 and P2 because the actual object discovery process usesless energy due to unicast messages instead of broadcastmessages.

Concerning sensitivity, RKS is almost as sensitive as P1and P2 because the presence of ORB_I_BEACON orORB_O_BEACON messages causes RKS to query the objectinformation. However, the message complexity increases by1 due to the unicast messages and, hence, theoretically,RKS’s sensitivity to the arrival of new objects is slightly lessthan those of P1 and P2. It is also important to note that wehave designed RKS to recover from faults, such as move-ment of a node after it broadcasts an ORB_I_BEACON orORB_O_BEACON message. RKS, by its own design,concludes that a device is not available from failed unicastmessages. Clearly, here, we assume that two devicesworking in the range of a third device do not have thesame IP addresses.

In terms of executable code size, Windows CE 3.0-basedimplementation for RKS is 7.5 KB, while P1 and P2 are 5 KBand 4.5 KB, respectively.

6.2 Experimental Test Bed

We implemented RKS forWindows CE 3.0 so that it could beused and evaluated inside RCSM Object Request Broker (R-ORB) [5]. R-ORB is a lightweight and context-sensitive objectrequest broker for RCSM and provides an object-basedframework for context-sensitive computing in ad hoc net-works. R-ORB provides IM_PAIR registration, context dataacquisition, raw context to structured context conversion,context data propagation, IM_PAIR method invocation,broadcast and unicast, and context-sensitive communicationmanagement facilities. Furthermore, RCSM can be config-ured in several different ways to provide a suitableinfrastructure for ubiquitous computing experiments. Atthe time of our experiments, RCSM provided support for10 different contexts, including location, noise level, lightintensity, andmotion inside a room.Figs. 7a and7b showRKSin terms of main components.


Fig. 7. RKS’s size charts.

6.3 Experimental Results

We performed several experiments to evaluate RKS with P1and P2. We will discuss one experiment in detail in thissection. In this experiment, we used several Casio E-200PDAs, each equipped with Li-ion rechargeable and replace-able battery with 950-mAh current rating. Each PDA wasalso equipped with a D-LINK Air DCF-660W CompactFlash 802.11b adapter. These adapters were configured tooperate in power-saving mode in ad hoc network config-urations. As such, no infrastructure, such as an access point,was necessary to provide the communication support. Thepower consumption ratings for each 660 W adapter are350mA and 250mA for transmission and reception, respec-tively. We chose the Casio E-200 PDAs and the D-Link660 W because they were already tested and usedsatisfactorily in the RCSM test bed.

We put four PDAs in a 6� 2 feet square feet area. Two ofthe PDAs, referred to as PDA-3 and PDA-9, wereprogrammed with five objects, each with four outgoingcontext-sensitive methods. Thus, PDA-3 and PDA-9 eachhad 20 outgoing IM_PAIRs. The IM_PAIRs in PDA-3 were

programmed to randomly generate context-match events20 percent of the time. On the other hand, the IM_PAIRs inPDA-9 were programmed to randomly generate context-match events 50 percent of the time. We programmed theremaining PDAs, PDA-1 and PDA-10, to have the sameconfiguration as the first two PDAs with the exception thatall the IM_PAIRs in PDA-1 and PDA-9 were incoming. Thegoal here was to have both incoming and outgoingIM_PAIRs with two different levels of context-match eventgeneration patterns. We used RKS, P1, and P2 protocols ineach of these devices to run for 30 minutes. Each protocolhad a sleep period of 250 milliseconds. We measured thebattery level of each device in every 5 minutes using ourown battery-reader tool. We also instrumented all protocolsto collect the following runtime data in each PDA: totalcycles executed, number of cycles in the energy save (ornormal) mode, total number of ORB_I_BEACON andORB_O_BEACONs sent and received, total number unicastrequest received or sent, total number of unicast repliesreceived or sent, total number of beacons received, and totalnumber context-match events.


Fig. 8. (a) Total amount of data (in bytes) sent and received by PDA-1 (incoming IM-PAIRs). (b) Total amount of data (in bytes) sent and received byPDA-3 (outgoing IM-PAIRs). (c) Total amount of data (in bytes) sent and received by PDA-10 (incoming IM-PAIRs). (d) Total amount of data (inbytes) sent and received by PDA-9 (outgoing IM-PAIRs).

The following are some figures from our experimentalresults that show the amount of send and receive (includingbroadcast, which was generated by the other three and wasnot intended for the host device). We also wanted to studyhow much data each PDA received due to unicast replies,useless broadcast from the other three PDAs (e.g., receivingan ORB_I_BEACON in a device with all incoming IM_PAIRs), and useful broadcasts (e.g., receiving an ORB_O_BEACON in adevicewith all incoming IM_PAIRs).As Fig. 8ashows, P1 performs better than RKS in PDA-1, but as Figs. 8b,8c, and 8d indicate, P1 causesmuch higher data receptions inother devices. This phenomenon indirectly may cause thesender to spend more energy in the long run due to the highprobability of packet collisions at the other nodes (therebyhaving the sender to send the packets again). Our RKSprotocol performs better due to its characteristic about firstdiscovering the willingness of other devices to discover theirobjects. In addition, RKS broadcasts the willingness in smallpackets (of 6 bytes), but uses unicast to receive the largeIM_PAIR information from a remote device. This avoids thecase where the protocol stacks in devices need to accept andprocess unnecessary data. However, as Fig. 8a indirectlyindicates, a small overhead of our protocol exists in a verystable network, where client objects are always willing todiscover server objects. This overhead can be eliminated ifwehad used a mechanism in RKS to check whether the serverobjects’ RTA sets had changed before sending out unicastmessages. Fig. 9 shows the energy drain charts for the resultsshown in Fig. 8 for RKS and P1.

Remarks on Possible Energy Measurement Errors: Wemeasured the energy efficiency by measuring the batterypower in different intervals during the experiments. EachCasio E-200 PDA draws its energy from one primary batteryand one backup battery. We removed the backup batterysource from each device to perform a clean measurement ofthe primary battery source, which was a Li-ion 950 mAhrechargeable battery. To keep the measurements of theenergy consumption accurate, we took several precautions.

We reduced the brightness of the display in all the PDAs toa consistent, low level so that the same amount of batterypower was used due to the brightness settings. Usually, thebrightness mechanism in a PDA consumes significantbattery power. Second, we did not connect any otherhardware or software with the PDAs. We measured thebattery power at different times using a custom-made toolthat works independently of our protocols. We used theGet-System-Power-Status-Ex2 function of Windows CE inthis battery power measurement tool to read the currentstatus of the battery. We were particularly interested inthree different aspects related to the battery power: theamount of full time of a battery if the battery is completelyrecharged (it is 14,400 in all Casio E-200s), the amount ofremaining battery power, and the percentage of remainingbattery power. Since the tool itself runs entirely in software,it did not consume any additional power beyond what isrequired to run the Windows CE 3.0 operating system.

One of the major difficulties with the energy calculationduring the experiments was that the Casio E-200 PDAs didnot provide readings (although the APIs were availablethrough Windows CE) based on voltage, instantaneouscurrents, and average currents. These values could havebeen used to calculate the energy consumption moreprecisely. The granularity of the Get-System-Power-Status-Ex2 function is limited to 10 percent of the full power (i.e., itshows battery power as integer multiples of 1/10th of thefull battery power). As such, it is possible that some errorsexisted in our measurements. However, despite thislimitation, there were noticeable differences in our readingswhen we used RKS, P1, and the P2 protocols.

7 DISCUSSION

We have presented an energy-efficient object discoveryprotocol RKS for context-sensitive ubiquitous computing.This protocol can be used in a middleware to facilitatecontext-sensitive communications among applications in


Fig. 9. (a) Energy consumption in four PDAs when using RKS. (b) Energy consumption in four PDAs when using P1.

devices in mobile ad hoc networks. This reduces energyconsumption by reducing the amount of data that needs tobe transmitted. A limitation to RKS is that it consumesslightly more energy than P1 during send operations whennew devices with server objects are detected at every cycle,but these devices do not stay around long enough for theunicast operation to be completed. However, in reality, suchan environment may not be appropriate for meaningfulinteractions among applications. Nevertheless, RKS can beslightly modified to handle such situations by trading off itssensitivity level, thereby responding slower to the incomingcontext-match events from the application layer. Moreexperiments with RKS, especially in dense ad hoc networks,will be conducted to investigate the effect of high-densityon RKS’s energy conservation. Further research includesinvestigation on the issues related to neighbor stability anddevelopment of an adaptive version of RKS, which willfine-tune its sensitivity to the incoming context-matchevents to conserve precious energy in highly fluctuatingand mobile environments.

ACKNOWLEDGMENTS

This research is supported in part by the US NationalScience Foundation under grant number ANI-0123980. Theauthors would like to thank Microsoft Research andTektronix, Inc. for donating the equipment used in theirexperiments. The authors would also like to thank DanzhiHuang and Yisheng Yao for the many discussions on theimprovement of the presentation of this paper.

REFERENCES

[1] M. Weiser, “The Computer for the Twenty-First Century,”Scientific Am., vol. 265, no. 3, pp. 66-75, Sept. 1991.

[2] B. Schilit, N. Adams, and R. Want, “Context-Aware ComputingApplications,” Proc. IEEE Workshop Mobile Computing Systems andApplications, pp. 85-90, 1994.

[3] A.K. Dey, “Understanding and Using Context,” J. Personal andUbiquitous Computing, vol. 5, no. 1, pp. 4-7, Feb. 2001.

[4] G. Abowd and E.D. Mynatt, “Charting Past, Present, and FutureResearch in Ubiquitous Computing,” ACM Trans. ComputerHuman Interaction, vol. 7, no. 1, pp. 29-58, Mar. 2000.

[5] S.S. Yau, F. Karim, Y. Wang, B. Wang, and S. Gupta, “Reconfigur-able Context-Sensitive Middleware for Pervasive Computing,”IEEE Pervasive Computing, vol. 1, no. 3, pp. 33-40, July-Sept. 2002.

[6] G. Chen and D. Kotz, “A Survey of Context-Aware MobileComputing Research,” Technical Report TR2000-381, Dept. ofComputer Science, Dartmouth College, Hanover, NewHampshire,2000.

[7] M.L. Dertouzos, “The Future of Computing,” Scientific Am.,vol. 281, no. 2, pp. 52-55, New York: Scientific American, Inc.,Aug. 1999.

[8] S.S. Yau and F. Karim, “Context-Sensitive Middleware for Real-Time Software in Ubiquitous Computing Environments,” Proc.Fourth IEEE Int’l Symp. Object-Oriented Real-Time DistributedComputing, pp. 163-170, 2001.

[9] N. Marmasse and C. Schmandt, “Location-Aware InformationDelivery with comMotion,” Proc. Second Int’l Symp. Handheld andUbiquitous Computing, P. Thomas and H.-W. Gellersen, eds.,vol. 1927, no. 1, pp. 157-171, Sept. 2000.

[10] N. Sawhney and C. Schmandt, “Nomadic Radio: Speech andAudio Interaction for Contextual Messaging in Nomadic Envir-onments,” ACM Trans. Computer Human Interaction, vol. 7, no. 3,pp. 353-383, Sept. 2000.

[11] A.K. Dey and G. Abowd, “The Context-Toolkit: Aiding theDevelopment of Context-Aware Applications,” Proc. Conf. HumanFactors in Computing Systems, pp. 434-441, 1999.

[12] K. Geihs, “Middleware Challenges Ahead,” Computer, vol. 34,no. 6, pp. 24-31, June 2001.

[13] P.A. Bernstein, “Middleware: A Model for Distributed Services,”Comm. ACM, vol. 39, no. 2, pp. 86-97, Feb. 1996.

[14] S.S. Yau and F. Karim, “Reconfigurable Context-Sensitive Mid-dleware for ADS Applications in Mobile Ad-Hoc NetworkEnvironments,” Proc. Fifth IEEE Int’l Symp. Autonomous Decen-tralized Systems, pp. 319-326, Mar. 2001.

[15] S. Preu, “JESA Service Discovery Protocol,” Proc. Networking Conf.,pp. 1196-1201, 2002.

[16] J. Schiller, Mobile Communications. first ed., Addison-Wesley, 2000.[17] D. Chakraborty, A. Joshi, Y. Yesha, and T. Finin, “GSD: A Novel

Group-Based Service Discovery Protocol for MANETs,” Proc.Fourth IEEE Conf. Mobile and Comm. Networks, Sept. 2002.

[18] S.E. Czerwinski et al., “An Architecture for a Secure ServiceDiscovery Service,” Proc. Fifth Int’l Conf. Mobile Computing andNetworking, pp. 24-35, 1999.

[19] Y.-H. Lu, E.-Y. Chung, T. Simunic, and G. Michelli, “QuantitativeComparison of Power Management Algorithms,” Proc. Conf.Design, Automation, and Test in Europe, pp. 20-26, Mar. 2000.

[20] C.-H. Hwang and A.C.-H. Wu, “A Predictive System ShutdownMethod for Energy Saving of Event-Driven Computation,” ACMTrans. Design Automation and Electronic Systems, vol. 5, no. 2,pp. 226-241, New York: ACM Press, Apr. 2002.

[21] L. Benini, A. Boglio, and G. Michelli, “A Survey of DesignTechniques for System-Level Dynamic Power Management,”IEEE Trans. VLSI Systems, vol. 8, no. 3, pp. 299-316, June 2000.

[22] Y.-H. Lu, L. Benini, and G. Michelli, “Power-Aware OperatingSystems for Interactive Systems,” IEEE Trans. VLSI Systems, vol. 10,no. 2, pp. 119-134, Apr. 2002.

[23] E. Shih, P. Bahl, and M.J. Sinclair, “Wake on Wireless: An EventDriven Energy Saving Strategy for Battery Operated Devices,”Proc. Eighth Int’l Conf. Mobile Computing and Networking, pp. 160-171, 2002.

[24] D.M. Blough and P. Santi, “Investigating Upper Bounds onNetwork Lifetime Extension for Cell-Based Energy ConservationTechniques in Stationary Ad Hoc Networks,” Proc. Eighth Int’lConf. Mobile Computing and Networking, pp. 183-192, 2002.

[25] M. Zagali, J.-P. Hubaux, and C. Enz, “Minimum-Energy Broadcastin All-Wireless Networks: NP-Completeness and DistributionIssues,” Proc. Eighth Int’l Conf. Mobile Computing and Networking,pp. 172-182, 2002.

[26] L. Feeney and M. Nilsson, “Investigating the Energy Consump-tion of a Wireless Network Interface in an Ad Hoc NetworkingEnvironment,” Proc. 20th IEEE Conf. Computer Comm., pp. 1548-1557, 2001.

[27] J.C. Chen, K.M. Sivalingam, P. Agrawal, and S. Kishore, “AComparison of MAC Protocols for Wireless Local Networks Basedon Battery Power Consumption,” Proc. IEEE Infocom, pp. 150-157,1998.

[28] S. Ni et al., “The Broadcast Storm Problem in a Mobile Ad HocNetwork,” Proc. Fifth ACM/IEEE Int’l Conf. Mobile Computing andNetworking, pp. 152-162, Aug. 1999.


Documents

An energy-efficient object discovery protocol for context-sensitive ...knarig/candidacy/energyefficient.pdf · context-sensitive ubiquitous computing environment and energy-efficiency