Download pdf - Negotiating Context Information in Context-Aware Systems

NOVEMBER/DECEMBER 2004 1541-1672/04/$20.00 © 2004 IEEE 21Published by the IEEE Computer Society

C o n t e x t - A w a r e A p p l i c a t i o n s


Negotiating ContextInformation in Context-Aware SystemsMohamed Khedr and Ahmed Karmouch, University of Ottawa

In a pervasive environment, a wide range of devices and resources use heterogeneous

networks to perform the tasks involved in spontaneous ad hoc communication. The

environment’s infrastructure must therefore make available a rich set of computing capa-

bilities and services at all times and in all locations in a transparent, integrated, and

convenient way.1 Context provides perceptual infor-mation about the location and status of the people,places, and other devices in the environment.2

The design and development of context-awareapplications introduce requirements and challengesnot found in traditional applications. First, thedynamic, adaptive provisioning of context informa-tion requires negotiating context features (location,identity, and activity), engagement (conditions, events,and actions), and dependency. Next, agents and con-text-aware applications must be able to effectively andreliably use context information during negotiation.So, context-aware systems require these components:

• Context ontology and inference to facilitate thesharing, management, and inference of a givencontext

• Context-level negotiation to agree on levels of con-text that can be provided and enable personal con-text provisioning

• Context management to store, retrieve, query, andmodify context information

These characteristics elevate context from anambiguous concept to a value-added service that tai-lors levels of context information representation andquality to user needs.

We’ve developed the context-level negotiationprotocol to facilitate development of context-aware,personalized applications and an ontology model forrepresenting context and negotiation information.Our context-based conferencing environment dem-onstrates our approach’s effectiveness.

Context and context-level agreementPervasive-computing research shows that a user’s

environment is dynamic, adaptive, and interactive.It contains sensors, wireless devices, and personaland service agents operating autonomously with theaid of context. By context, we mean informationabout physical characteristics (such as location andnetwork elements), the system (such as applicationsrunning and available services), and the user (such asprivacy and presence). The environment becomescontext-aware when it can capture, interpret, andreason about this information. The vast quantityand diverse quality of context, in addition to thefact that no user is interested in all available con-text, led us to the concept of context-level agree-ment, in which entities negotiate context specifi-cations using an ontology-based model. CLA’sadvantages include

• A declarative method with which users statetheir context requirements and context providersoffer dynamic customized context-based serviceinformation

• Protection against unexpected performance degra-dation because context providers know users’needs and can thus better manage their resources

• Seamless context-based services across domainsin a large environment

• An easy mechanism with which context providerscan intelligently supply and monitor contextresources

We define three broad types of CLA:

Context-aware

environments must

allow adaptive and

autonomous access to

context information.

This multiagent

middleware uses a

negotiation protocol

and ontology model to

make the environment

more easily

personalized at

runtime and adapted

and managed at

provisioning time.

• Passive context. Each user’s context spec-ifications are simple, requiring little or no complex operation from the contextprovider.

• Active context. Users’context specificationsresult from complex content provider oper-ations such as filtering, merging, compos-ing, and monitoring. Negotiation at thislevel aims to achieve common understand-ing of the context’s meaning and format.

• Spontaneous context. Context manage-ment and inference must be able to copewith the uncertainty and vagueness inher-ent at higher context levels. Negotiation atthis level lets a personalized group of con-text providers manage user context re-quirements such as information persis-tence, delivery methods, remote access,and inference on each user’s context.

For CLA to be dynamic, automated, andextensible, it must provide a framework fornegotiating context specifications and anontology that provides standard and exten-sible constructs of context and negotiationperformatives.

Context-aware systemarchitecture

Figure 1 shows our distributed multiagentsystem architecture. Agents are lightweightand expected to operate in pervasive environ-ments in which resources and computingnodes have limited capabilities. We imple-ment system agents (such as the context-man-agement agent and the inference agent) inhosts with moderate computing power. Otheragents (such as user and service agents) residein user nodes that can support any availablelightweight-agent platform, such as the Light-weight Extensible Agent Platform (LEAP),which is based on the Java Agent Develop-ment Framework (JADE, http://jade.tilab.com). In addition, the inference agent andknowledge base repositories span several nodesto decrease bottlenecks and increase scalabil-ity and robustness against failure. Agents per-form negotiation, query, and service invoca-tion through agent message passing.

Agent typesFive main agent types perform the func-

tions required for context negotiation and pro-visioning. We group these functions into threemodules, as Figure 2 shows. The context rep-resentation module gathers context from thesurrounding area and provides it in an ontol-ogy-based representation that facilitates inter-pretation and inference. The context commu-nication module governs communicationbetween agents using a registration process aswell as the negotiation protocol. The contextmanagement module provides methods forquerying and storing context information.

User and service agents. User agents repre-sent users in the environment, negotiating on

their behalf to set both the required contextspecifications and the methods of context rep-resentation and delivery. They maintain userprofiles consisting of user activities, schedul-ing, and associated devices, as well as contextparameters such as identity, location repre-sentation, and personal context information.

Service agents represent services in the envi-ronment. They maintain service profiles,which define service capabilities and theknowledge required to negotiate each service’soptimal performance according to context.

Context management agent. The contextmanagement agent is the system administra-tor. The CMA negotiates with user agents toachieve CLA and with context provider agents(which we describe later) to schedule andguarantee the required context. After negoti-ating the context, the CMA monitors ongoingcontext-based sessions and manages environ-mental resources. The CMA can also cancel,modify, or renegotiate context specificationsbecause of environmental changes or becauseagents violate their CLA-negotiated tasks.

Registering with the CMA lets agents pro-ject their presence to other environmental enti-ties and obtain the authorization needed to useand negotiate context information. The CMAstores relevant information in a knowledgebase repository for inference, consistency, andknowledge sharing. The multiagent systemuses this repository to track entities’ informa-tion and store temporal session information.

Inference agent. The inference agent inte-grates reasoning, conflict resolution, and coor-dination. Algorithms from AI, semantic knowl-edge, and fuzzy logic make the inferenceprocess powerful, extensible, and adaptable.The inference agent manages the engagementand inference processes shown in Figure 2. Ituses context captured from sensors and userand service profiles as facts in the context infer-ence process, using these facts to build a sys-tem knowledge base repository for deducingnew context information. The inference agentuses logic-reasoning mechanisms to ensurethat captured context instances are consistentwith each other and with arguments defined inthe context ontology. This also lets us constructan inferred hierarchy of context informationbased on the designed ontology classes andresolve inconsistencies that can arise from fir-ing rules and triggering actions.

Ontology agent. The ontology agent pro-vides the semantic functionalities that other


22 www.computer.org/intelligent IEEE INTELLIGENT SYSTEMS

Event orcontext

engagement

ConsistencyValidity

Adaptability

High-levelcontext

information

Inference agent

PersistenceQuery

Data storage

Personalizedcontextservices

Systemknowledgebase agent

Serviceagents

Sensoragents

Useragent

Event-monitoring

agent

Contextmanagement

agent

Ontologyagent

Figure 1. A multiagent system architecture.

Access Storage

Context management module

Context communication module

Query

Discovery Delivery Negotiation

Context representation module

Interpretation Engagement Inference

Figure 2. The multiagent system supportsnine functions divided into three modules.

agents can use to represent and share contextin the system. At negotiation time, it com-bines context specifications from agentrequests and profiles according to the de-signed ontology’s constructs, axioms, andrules of composition, which it then providesto the CMA. It also provides searching andbrowsing interfaces so that registered agentscan look up and use available ontologies.

Context provider agents. The system wrapseach context source with a CPA responsiblefor capturing the raw data from the sourceand interpreting it so that it’s understandableby other agents using the lookup service thatthe ontology agent provides. The CPA nego-tiates context specifications that are capturedand acquired by the context source under itscontrol.

The context ontology modelContext-aware applications require a uni-

fied context model that is flexible, extensible,and declarative to accommodate a wide varietyof context features and dependency relations.Research in context-aware applications3 (seealso the “Related Work” sidebar) defines mod-els based on a top-down architecture in whichcontext is modeled according to the applica-

NOVEMBER/DECEMBER 2004 www.computer.org/intelligent 23

Few approaches in the context awareness field explicitlyfocus on context modeling in widely deployed pervasive-com-puting systems. Rather, most current research concentrates onframeworks and toolkits to support ad hoc context representa-tion, and thus limits the interoperability and ease of integra-tion necessary for providing smart pervasive environments.1

The Gaia metaoperating system recognizes the need forcontext information in a context service component.2 Its con-text service lets applications query and register for particularcontext information, which helps them adapt to their environ-ment. Applications can search a registry of available contextproviders for providers of their desired context. This approachuses a first-order logic to model context, allowing the systemto write rules describing context information. However, thisapproach doesn’t support negotiation between applicationsand context providers, which could provide flexible contextprovisioning. Applications can use only the context providersin the registry. Additional application instances will introducescalability issues such as temporary failure or inability to pro-vide context information because of access overloading.

Wai Yip Lum and Francis Lau propose a context-aware deci-sion engine for content negotiation.3 They use a proxy serverfor content modification based on certain context decisions.However, they limit the context definition to quality of service,a significantly more narrow definition than ours, which consid-ers context to be any information affecting an entity (such aslocation and presence). Because the context definition is lim-ited, the adapted content might still lack context awareness.

Reconfigurable Context-Sensitive Middleware provides theadaptive object container (ADC) for runtime context acquisi-tion.4 The RCSM interface definition language (IDL) compilertailors ADCs to particular context-sensitive objects. The con-text-sensitive interface lists the contexts the applications use,the actions they provide, and a mapping between the con-texts and the actions that clearly indicates the values at whichan action should be completed.

Our multiagent system outperforms RCSM in two situations.First, our ability to negotiate context using the multiattributeutility function lets us use a just-in-time range of context val-ues when an action is to be performed or completed. The ne-gotiation gives us the flexibility and extensibility to add newcontext information and modify existing information duringruntime. Second, the RCSM has no clear method for compos-ing context semantically or for reasoning with the composedcontext information.

Other researchers describe a framework that uses compositecapabilities/preferences profiles to enable communication andnegotiation of device capabilities and user preferences in the

context of a Web session.5,6 They use the framework to assertmetadata information about Web elements. This approachdepends on a negotiation protocol in which intermediateproxies can adapt content to the device profile in advance. In apervasive environment, nothing can be statically configured. Anegotiation mechanism such as ours dynamically sets contextinformation at runtime. Moreover, CC/PP is based on the re-source definition framework, whose small set of constructs forrepresenting metadata limits the information that can be pre-sented and inferred. In contrast, our proposed model presentscontext ontologies in much richer semantic languages, such asDAML+OIL and OWL.

Cobra also uses OWL to define ontologies for pervasive envi-ronments.7 However, our design objective is a straightforwardgeneric ontology for context representation that developerscan apply while using the negotiation mechanism to set andmodify context specifications. We also provide a powerful in-ference engine based not only on logic reasoning (as in Cobra)but also on fuzzy and inductive reasoning. We chose this overa Bayesian approach8 because fuzzy reasoning provides a nat-ural extension to our context ontology through its use of lin-guistic terms and linguistic hedges.

References

1. N. Davies and H.-W. Gellersen, “Beyond Prototypes: Challenges inDeploying Ubiquitous Systems,” IEEE Pervasive Computing, vol. 1,no. 1, 2002, pp. 26–35.

2. M. Román et al, “A Middleware Infrastructure for Active Spaces,”IEEE Pervasive Computing, vol. 1, no. 4, 2002, pp. 74–83.

3. W.Y. Lum and F.C.M. Lau, “A Context-Aware Decision Engine forContent Adaptation,” IEEE Pervasive Computing, vol. 1, no. 3,2002, pp. 41–49.

4. S. Yau et al., “Reconfigurable Context-Sensitive Middleware forPervasive Computing,” IEEE Pervasive Computing, vol. 1, no. 3,2002, pp. 33–40.

5. L. Suryanarayana et al., “CC/PP for Content Negotiation and Con-textualization,” Proc. 2nd ACM Int’l Conf. Mobile DataManagement, ACM Press, 2001, pp. 239–245.

6. T. Lemlouma et al., “The Negotiation of Multimedia Content Ser-vices in Heterogeneous Environments,” Proc. 8th Int’l Conf. Multi-media Modeling, MMM Press, 2001, pp. 187–206.

7. H. Chen et al., “An Ontology for Context-Aware Pervasive Comput-ing Environments,” Proc. IJCAI 03 Workshop Ontologies and Dis-tributed Systems, IJCAI Press, 2003.

8. P. Korpipää et al., “Managing Context Information in Mobile De-vices,” IEEE Pervasive Computing, vol. 2, no. 3, 2003, pp. 42–51.

Related Work

tion-layer objectives and functional intentions.These models are ad hoc and have limitedextensibility and interoperability with othercontext-based systems. Ad hoc modeling alsolimits the use of the multiagent system acrossdomains because not all agents can understandand use context information. Our context-mod-eling approach is therefore ontology based andrepresents the generic context types needed inpervasive computing. The ontology is moti-vated by the need to share knowledge aboutactors, locations, and schedules so that con-text-aware applications can trigger actions andinfer outcomes.

In our ontology, the root class ContextViewprovides an organizational point of referencefor declaring context information. At least

one instance of ContextView exists for each dis-tinct entity in the environment. Its proper-ties are contains and invokes, with the classesContextFeature and ContextEngagement as the prop-erties’ respective ranges. Each ContextViewinstance contains at least one subclass ofContextFeature, associated with one or moreContextDependency classes and invoked by Con-textEngagement.

ContextFeature consists of classes related tothe physical environment (such as location),the system (such as services), individuals (suchas users), and the underlying network (such asnetwork characteristics).

The Location class interprets an entity’s loca-tion information as detected by embeddedlocation sensors. The ontology associates

location with such concepts as university,company, and generic place. The location classalso includes meta-information fields suchas location-updating rate, services in the cur-rent location, and types of network the loca-tion supports.

The Actor class provides information inter-preted by identity context providers such asthe radio frequency tag system. It has twomain subclasses:

• Person has person-related properties de-tected by the sensors.

• Agent represents the system’s softwareagents.

Information provided includes an IDvalue, the entity type detected (such asinfrared model or RF tag), the entity’s role(such as printer agent or student), detectiontime, and reference to the actor’s personalprofile for further context acquisition.

The Network class identifies resources, pro-tocols, and topology configurations. We limitour scope to wireless networks, especially802.11 and Bluetooth. A network profile classcontaining the resource’s capabilities and pref-erences represents each network resource,such as a gateway server or an access point.

The Service class identifies services discov-ered in the environment. It includes the ser-vice profile (such as a printer profile), ser-vice parameters, applications engaging theservice, and the service’s complexity type.

The Action class represents activities in auser’s current location that involve other usersor other services detected and projected to theuser’s ContextView. Activities currently definedin the ontology relate to our proposed imple-mentation scenario and include audio- andvideoconferencing, local or remote presenta-tion-based meetings, and regular activitiessuch as emailing, chatting, and file sharing.

Figure 3 shows a partial representation ofthe ontology, with classes represented by bullets and properties given between brack-ets. The complete ontology is available atwww.daml.org/ontologies/397 and at www.schemaweb.info/schema/SchemaDetails.aspx?id=181.

Context-level negotiationprotocol

CLNP is a multiattribute-based negotia-tion protocol that allows automated contextidentification and complex decision makingaccording to user needs—functions tradi-tionally performed manually. User or service



Figure 3. A partial representation of the context ontology showing the ontologyclasses and their properties.

• Context Feature ()❍ ActionProfile (actionprofileName, actionStartTime, actionEndTime, actionExpectedDuration,

hasInvolvingAgents, hasInvolvingPersons, hasInvolvingServices)❍ Network (hasNetworkProfile, nDomain, nName)

� NetworkResource (hasServiceProfile)• Laptop ()• PDA ()• Phone ()• Printer ()

❍ NetworkTopology ()� Wireless (hasAccessPoint, hasAccessPointAddress)

• 802.11 (modeOfOperation)• Bluetooth (modeOfOperation)

❍ NetworkProfile ()� NetworkProtocol (hasProtocolChar, protocolName)� NetworkParameter (nParameterName, nParameterValue)� ProtocolCharacteristic (pValue)

❍ Physical ()� Actors (actorID, actorLocation, actorName, actorRole, hasCurrentAction, usesCurrentService)

• Agent (hasCommunicationLanguage, hasPlatformType)• Person (hasPersonalProfile)

� Location (altitude, degree, direction, hasCurrentAgents, hasCurrentPersons, hasLoadedServices, hasLocationRange, hasNetworkSupport, hasRestrictedActions, latitude, longitude, placeName)

❍ ServiceCategory ()� Application (aName, effect, input, output, precondition)� Resource (effect, input, output, precondition, rName)� ServiceParameter (sParameterCondition, sParameterName, sParameterValue)

• ServiceProfile (hasNetworkSupport, hasServiceCategory, hasServiceLocation,hasServiceParameter, hasServiceProfileName, hasServiceActor)

❍ Social ()� Action (actionLocation, actionName, hasActionProfile, hasCurrentAgents, hasCurrentPersons,

hasNetworkSupport)• Conference ()

o AudioConference (usesCurrentService)o VideoConference (usesCurrentService)o Meeting (usesCurrentService)

❍ Role ()� AgentRole (agentName, agentRole, hasRestrictedActions)� PersonRole (hasRestrictedActions, personName, personRole)

agents send CLA requests to the CMA, whichmaps the CLA to context specification para-meters and issues a negotiation request toavailable CPAs. The CPAs evaluate the pro-posed specifications and either accept orrepropose. Negotiation continues until theagents reach an agreement based on the util-ity function calculation (described in the nextsection).

CLNP aims to

• Set the context specifications between userand service agents and CPAs explicitly anddeclaratively

• Authorize the CMA to register and reserveresources and services implicitly anddecide how the CPA will deliver and mon-itor context

• Set alternatives for unexpected situationsimplicitly

• Let CPAs schedule context-based tasksimplicitly and minimize overloading

Negotiation uses our ontology model. Itinvolves context exchange and specification,a utility function for decision-making, and aprocedure for message flow between agentsto set context specification values.

The utility functionQuantifying the negotiation process

requires normalizing each context specifica-tion’s range. We then use a multiattribute util-ity function to model each negotiated contextspecification. The utility function, which weadopted from the work of Antony Richardsand his colleagues,4 has these characteristics:

• A lower bound on x (the normalized nego-tiated context parameter), below whichuser satisfaction is negligible and approx-imated to zero

• An upper bound on x, above which anygain in user satisfaction is negligible andapproximated to one

• Between these two bounds, a satisfactionfactor that’s a monotonically increasingfunction of x

• A sensitivity parameter p for projectinguser satisfaction

The logarithmic function matches theserequirements. We can therefore represent theutility function as a logarithmic function inthe form of

(1)

(2)

(3)

, (4)

where U(x) is the utility function, x is thecontext parameter values in negotiation, p isthe user sensitivity parameter, Ao is theexpected context sensitivity, A is the mini-mum context parameter value, and R is themaximum context parameter value.

The utility function depends on the sensi-tivity parameter p. For every value of p, agents

project their interest in a context specificationaccording to the utility function shape. Forexample, for p values smaller than Ao, the useris more sensitive to large context parametervalues than to small values, such as locationinformation in outdoor applications. For p val-ues larger than Ao, the user is more sensitive tosmall context values than to large values, suchas delay in emergency notification.

The CMA uses the negotiation process(discussed in the next section) to determinethe working utility curve. To find the optimalutility curve, the CMA applies the followingdecision equation on the initial context para-meter value AL requested by the user or ser-vice agent:

(5)

If U(AL) << U(R) for AL < R and AL > [A +R/2], then p < Ao, the agent is more sensitiveto large context values, and the CMA uses pfrom Equation 2 to satisfy Equation 5.

If U(AL) >> U(A) for AL > A and AL < [A +R/2], then p > Ao, the agent is more sensitiveto small context values, and the CMA choosesp from Equation 2 to satisfy Equation 5.

After deciding the utility function curvefor each context parameter, the CMA assignsa weighted priority value for each contextparameter indicating its importance (as per-ceived by the user) in the overall negotiation.The CPAs and CMA use the priority valuesto differentiate the levels of context repre-sentation and delivery to the user.

The weighted priority value takes the form

U A a b A cL x A LL( ) .ln( . )= = +

cR Ae

R A

a

= −−

1/

be

R A

a

= −−

1 1/

ap Ao

=−1

U x a b x c( ) .ln( . )= +


(1) Send:CLA_Negotiation

Receive:CLS_Proposal

(3) Send:CLS_Repropose

(6) Send:CLS_Agree

Receive:CLS_Agree

Start Wait

Evaluate

Confirm

Receive:CLS_Repropose

Receive:CLS_Offer

Receive:CLA_Negotiation

StartCreate

context-levelspecification

Receive:CLS_request

Start

Send:CLS_Proposal

(2) Send:CLS_Proposal

Repropose

Wait

Wait

(6) Send:CLS_Agree

(5) Send:CLS_Offer

Receive:CLS_Agree

Evaluate

Confirm

(4) Send:CLS_Request

Evaluate

Receive:CLS_Agree

Confirm

(6) Send:CLS_Agree

Receive:CLS_request

(a) (b) (c)

Figure 4. The context-level negotiation protocol from three perspectives: (a) the user agent; (b) the context management agent; (c) the context provider agent. Processes in each part follow and precede processes in the other parts.

,

where i = 1 … N and N is the total number ofcontext parameters. The total satisfactionvalue will equal

.

The CMA uses this value to decide whetherthe agents have reached agreement or thenegotiation should continue.

The negotiation processand message flow

The user or service agent starts the nego-tiation by sending the CMA a CLA_Negotiationmessage with the initial context specification((1) in Figure 4a)—that is, the context spec-ifications defined according to the ontologymodel. The user or service agent sets speci-fications, such as location and availabilityinformation, and adds an expected deadlinefor the negotiation.

When the CMA receives the CLA_Negotiationmessage, it builds a template from the contextspecifications fed to it by the CPAs. The CMAassigns the utility function parameters {a, b, c,Ao, R, A} that match user context specifica-

tions using Equations 1 through 4 and thedecision functions in Equation 5. After deter-mining the best utility function to use, theCMA builds a composite context templatereflecting the user or service agent ContextView.The CMA creates the composite context atruntime using a relation-based binding processcontaining eight main relationships:

• Consists_of relates the environment with theplaces under the CMA’s management.

• Occupied_by relates the environment with theusers currently detected by the sensors.

• Contains associates the environment with thediscovered services.

• Composed_of defines subservices composingservices.

• Loaded_with relates the places under theCMA’s management with the service atthose places.

• Member_of identifies the group the userbelongs to (for example, administrators orvisitors).

• Essential defines requirements that the usercan’t negotiate or modify.

• OverLoaded lists interdependent requirementsthat can overload other requirements.

• Overridden defines requirements that will bepreempted by essential or high-priorityrequirements.

Every user or service agent provides aninitial profile with its requirements and pref-erences. The CMA uses the profile to set rela-tionships and assembles the differentinstances into one composite component.

After composition, the CMA responds tothe user or service agent with a CLS_Proposal((2) in Figure 4b). The CLS_Proposal containsthe template most closely matching the sat-isfaction criteria. If the agent accepts theCMA’s proposed context specifications, itsends a CLS_Agree message ((6) in Figure 4a).If not, it reallocates the satisfaction point onthe utility curve and sends a CLS_Repropose ((3)in Figure 4a) with the modified context para-meters. The CMA then engages nearby CPAsand negotiates the new proposed contextspecifications by sending them a CLS_Request((4) in Figure 4b). The CPAs collaborate tomaximize the utility function satisfactionpoint. When they succeed, they send the newcontext parameters to the CMA through aCLS_Offer message ((5) in Figure 4c). TheCMA responds by reproposing to the user orservice, and the negotiation continues untilthey reach an agreement.

The agreement decision depends on oneor both of these factors:

• The proposed context specifications max-

U x Wi ii

( ).∑

WA A

R AiLi=

−−



• Negotiation• Registration• Validation• Consistency• Lookup• Inference

Inference agent

Systemknowledgebase agent

Context

Contextmanagement

agent

Ontologyagent

Map & locationservice Presence

service

Printingservice

Office service

Useragent

Serviceagent

Contextnegotiation

Query

Response

Weatherservice

Schedulingservice

Hotel serviceEntertainment service Email service

Figure 5. The conference environment integrated with the multiagent system. Available services are either services in advance orservices on the fly, depending on the input context source.

imize the total gain in the utility functionand can be provided by the CPAs.

• The negotiation deadline expires (in thiscase, the most recently negotiated contextparameters are used).

ImplementationOur context-based conferencing environ-

ment customizes conference services usingcaptured context and attendee and serviceprofiles defined according to our contextontology. Defining CLAs for attendees usingthe negotiation protocol between CPAs anduser agents greatly reduces the complexityof customizing the conference operation.

Figure 5 shows the services and agents inthe conference environment. We divide avail-

able services into two categories:

• Services in advance, such as hotel book-ing, scheduling, and entertainment, takeinput context from attendee profiles pro-vided during conference registration.

• Services on the fly, such as map and loca-tion, weather, and printing services, takeinput context from attendees’physical andlogical contexts.

We implement agents using JADE, modi-fying the agent communication language(ACL) package to include our negotiationperformatives while preserving JADE’s FIPA(Foundation for Intelligent Physical Agents)compatibility for legacy applications.

The CMA provides APIs for registration,service selection, context specification, noti-fication, and event-based triggering methods.The ontology agent provides APIs for brows-ing, navigation, searching, and validatingontology-based instances stored in a persis-tence repository and managed by the systemknowledge base agent. The inference agentprovides APIs for ontology-based inferencesuch as subsumption, equivalence, similarity,and consistency checking. Moreover, it pro-vides a fuzzy-based inference mechanism tosupport vagueness and uncertainty in contextinformation such as location proximity, pres-ence range, and service selection.

Our default deployment strategy is toinstall one CMA at each domain. Domains


Register (Service_Profile, Context_Spec)

CLS_Offer (Context_Spec)

Context provideragent 1 ... N

System knowledgebase agent

Inferenceagent

Ontologyagent

Contextmanagement agent

Useragent

Validate (Service_Profile)

CLA_Negotiation(User_Profile, Context_Spec)

Valid (Service_Profile)

Validate (User_Profile)

Valid (User_Profile)

Add (Service_Profile, Context_Spec)

Infer results (Rset, U(x))

Inform results (Rset, U(x))

CLS_Request (Context_Spec, TTL,)

CLS_Agree

Invoke (Sname, Uname, Context_Spec)

Add (User_Profile, Context_Spec)

Fetch (Sname, Context_Spec)

Consistencyupdate

Consistencyupdate

Lookup

Evaluatebid

Evaluate

CLS_Proposal(new Context_Spec)

CLS_Agree

CLS_Agree

Service_Request (Sname)

Notify result(Sname, Ser_Spec)

(new Rset, U(x))Inform results

(new Rset, U(x))Inform results

Figure 6. Message exchange between agents for registration and for negotiating context information.

can be physical, such as a building, or logical,such as a network domain. We also deploy aninference agent at each domain, allowing it toclone itself on nearby hosts and form a fed-eration in case of overloads.

Customizing a conference environment

Customizing the conference environmentinvolves two phases corresponding to the twoservice categories. For services in advance,attendees log in to a Web page where theyspecify their context-based services require-ments, such as hotel location, price, and lengthof stay. As Figure 6 shows, the user agentsends this information with the user profile tothe CMA as a CLA_Negotiation message. TheCMA registers the user and sends the userprofile to the ontology agent, which validatesit against the ontology constructs and rules.The ontology agent sends the profile to thesystem knowledge base agent, which adds itto the conference repository for furtheraccess and manipulation.

After registration and validation, the CMAsends the user’s specifications to registeredcontext providers to find matching services inadvance. The CPAs reply with a CLS_Offer thatshows available services. The CMA sendsthese results to the inference agent to find theclosest match maximizing the user’s utilityfunction. Finally, after receiving the resultsfrom the inference agent, the CMA sends aCLS_Agree message to the user that includes theselected service.

The second phase—services on the fly—has the same message flow but, because theservices are dynamic, shared, and distributedacross the conference domain, agents can re-negotiate context specifications, request avail-able services, and infer received results at run-time. (In Figure 6, this process begins withthe user agent’s service request and lasts to theend of the message sequence diagram.) Invok-

ing services on the fly depends on current usercontext. Examples include invoking theprinter that’s nearest to the user’s location andhas the least load, and invoking a mapping ser-vice to provide directions, with the user spec-ifying update rate and notification delay as thecontextual specifications to be negotiated.

Experimental resultsTo evaluate our approach’s feasibility, we

deployed the agent system and conferenceapplication, interconnected via 802.11 wire-less connections, at several locations in theUniversity of Ottawa’s Multimedia and MobileAgent Research Laboratory. Conference par-ticipants mainly used laptops, PDAs, and sta-tionary computers to access the system, whichincluded a wide range of services, activities,and context requirements. The conferenceenvironment had one repository. We consid-ered each physical location a separate domainand gave each domain one CMA, one ontol-ogy agent, and several inference, user, and ser-vice agents. Implemented agents were of mod-erate size to make them lightweight and easyto deploy in currently available handhelddevices. User agents were 14 Kbytes, serviceagents were 16 Kbytes, CMAs were 21Kbytes, and inference agents were 18 Kbytes.

We conducted several experiments to eval-uate the effectiveness of negotiating context.Effectiveness refers to the system runtimeperformance as the number of entities habit-uating the environment increases and re-sources remain constant. We measure thiseffectiveness by averaging both the delay inreaching an agreement to users’ requests andthe number of exchanged messages.

We used a range of context providers withdifferent context parameters and serviceclasses. For example, some context providersgave location and location-based informa-tion with parameters such as location granu-larity, update rate, and notification delay.

The number of conference attendeesranged from five to 100. Varying the numberof users when calculating the average delayfor negotiating context information let usmeasure the system’s scalability. The aver-age delay for 10 attendees was 861.75 mil-liseconds. Of this delay, 309.92 ms were forinferring and matching user requests and 243ms were for subscription, repository access,and querying. We also counted the numberof messages exchanged during the negotia-tion as indicating the overhead imposed byCLNP. We used these measurements as weexpect these measures will be directly pro-portional to user satisfaction when the sys-tem is widely deployed.

Table 1 shows a typical context negotia-tion required by a conference attendee,including the initial preferred values and thealternative values if the system can’t providethe exact requirements. Figure 7 is the actualnegotiation message in OWL using the con-structs defined in our ontology. It shows anegotiation for location, including the delayin providing location-based information. Themessage also includes the rule the user agentused to decide whether the CMA-providedvalue is acceptable: If the delay is between 5 and 10 ms, renegotiate.

Experimental results showed that the aver-age delay in negotiating context is linear witha moderate number of users (about 60 per-cent of the system’s expected capacity),becoming nearly constant as the number ofusers increases. CPAs tend not to renegoti-ate their proposed context specificationswhen they approach capacity, which reducesthe number of messages exchanged andmakes the average delay nearly constant. Wefound the same results with the number ofmessages exchanged, because the number ofexchanged messages is directly proportionalto average delay. The average number ofmessages exchanged at saturation point waseight, representing two round trips in thenegotiation process.

We’re extending the context ontologywith fuzzy inference constructs to let

agents reason with the uncertainty in capturedcontext and to provide actions not explicitlydefined in the context specifications. We’realso adding an automated context-based induc-tive-fuzzy-inference mechanism to the infer-ence agent. The mechanism will provide adynamic CLA feature letting the CMA modify



Table 1. Context specifications used in negotiation.

Context specification Preferred choice Alternative choice

User location Type: GPS → place name Type: GPS → location addressDelivery delay: 5 ms Delivery delay: 10 msUpdate rate: location changes Update rate: every 30 minutes

User availability Available at: room name Available at: hotel nameUpdate rate: location changes Update rate: periodic

Services (printing) Distance from user: within 5 meters Distance from user: at most 20 metersAvailability: least loaded Availability: mediumCapability: color, 10 pages per minute Capability: 10 pages per minute

Media (wireless) Availability: 75 percent Availability: 70 percentCapability: 1 Mbps, 5 ms delay Capability: 20 ms delay

some user requirements autonomously. Agentswill no longer have to renegotiate when a givensituation is similar but operates at a different

location or time. One remaining challenge is toprovide a communications mechanism span-ning different agent domain platforms. Such a

mechanism would provide a seamless, per-sonalized, and completely context-aware per-vasive environment.

References1. M. Khedr et al., “Agent-Based Context Aware

Ad Hoc Communication,” Proc. 4th Int’lWorkshop Mobile Agents for Telecommuni-cation Applications (MATA 02), LNCS 2521,Springer-Verlag, 2002, pp. 105–118.

2. A. Dey, “Understanding and Using Context,”Personal and Ubiquitous Computing, vol. 5,no. 1, 2001, pp. 4–7.

3. K. Henricksen, J. Indulska, and A. Rakotoni-rainy, “Generating Context ManagementInfrastructure from High-Level Context Mod-els,” Proc. 4th Int’l Conf. Mobile Data Man-agement—Industrial Track, 2003, pp. 1–6.

4. A. Richards et al., “Mapping User Level QoSfrom a Single Parameter,” Proc. 2nd IFIP/IEEE Int’l Conf. Management of MultimediaNetworks and Services, 1998.


T h e A u t h o r sMohamed Khedr is aPhD candidate in elec-trical and computerengineering at the Uni-versity of Ottawa. Hisresearch interests in-clude pervasive com-puting, agent-basedmiddleware, context-

aware environments, and semantic informationmodeling. He received his MS in electrical andcomputer engineering from the Arab Academyfor Science and Technology, Egypt. Contact himat 800 King Edward Ave. Room 5105, mailbox105, PO Box 450, Stn. A, Ottawa, ON K1N 6N5,Canada; [email protected].

Ahmed Karmouch isa professor of electri-cal and computer engi-neering and computerscience at the Univer-sity of Ottawa’s Schoolof Information Tech-nology and Engineer-ing. He also holds an

industrial research chair from the Ottawa Car-leton Research Institute and Natural Sciencesand Engineering Research Council. His researchinterests are in distributed multimedia systemsand communications, mobile computing, homearchitecture and services, context-aware ad hoccommunications, and mobile software agents fortelecommunications. Karmouch received hisPhD in computer science from the University ofPaul Sabatie. He’s a member of the ACM andthe IEEE. Contact him at 161 Louis Pasteur St.,Univ. of Ottawa, CBY, Ottawa, ON K1N 6N5,Canada; [email protected].

Figure 7. OWL representation of the negotiation message exchanged between UA and CMA.

<CLNP:CLNP rdf:ID=”CLNP_khedr”><CLNP:hasRequester>

<CLNP:UA rdf:ID=”khedrAgent”/></CLNP:hasRequester><CLNP:hasContextSpec>

<CLNP:ContextSpecification rdf:ID=”Location”CLNP:hasContextElement=”Location”><CLNP:hasContextParameter rdf:resource=”#DeliveryDelay”/>

</CLNP:ContextSpecification></CLNP:hasContextSpec><CLNP:hasProcess>

<CLNP:NegotiationMessage rdf:ID=”CLS_Proposal”CLNP:messageType=”CLS_Proposal”CLNP:TimeToLive=”20ms”><CLNP:hasRule>

<CLNP:NegotiationRules rdf:ID=”Rule1”><CLNP:hasOperand rdf:resource=”#and”/>

</CLNP:NegotiationRules></CLNP:hasRule>

</CLNP:NegotiationMessage></CLNP:hasProcess>

</CLNP:CLNP><CLNP:RuleOperand rdf:ID=”and”

CLNP:operandName=”And”><CLNP:hasAntecedent>

<CLNP:Antecedent rdf:ID=”bigger_than”CLNP:hasValue=”5ms”><CLNP:hasContextParameter>

<CLNP:ContextParameter rdf:ID=”DeliveryDelay”><CLNP:usedByUtilityFn>

<CLNP:UtilityFunction rdf:ID=”LogUF”CLNP:hasSensitivityparameter=”5”><CLNP:hasContextParameter rdf:resource=”#DeliveryDelay”/>

</CLNP:UtilityFunction></CLNP:usedByUtilityFn>

</CLNP:ContextParameter></CLNP:hasContextParameter>

</CLNP:Antecedent></CLNP:hasAntecedent><CLNP:hasAntecedent>

<CLNP:Antecedent rdf:ID=”less_than”CLNP:hasValue=”10ms”>

<CLNP:hasContextParameter rdf:resource=”#DeliveryDelay”/></CLNP:Antecedent>

</CLNP:hasAntecedent><CLNP:hasConsequent>

<CLNP:Consequent rdf:ID=”Renegotiate”><CLNP:hasContextParameter rdf:resource=”#DeliveryDelay”/>

</CLNP:Consequent></CLNP:hasConsequent>

</CLNP:RuleOperand>