This paper presents Q-CALl, a resource discovery framework

that enables pervasive computing applications to discover

and select the resource(s) best satisfying the user

needs, taking the current execution context and quality-ofservice

(QoS} requirements into account. The available resources

are first screened, so that only those suirable to the

current execution context of the application will be considered;

the shortlisted resources are then evaluated against

the QoS needs of the application, and a binding is established

to the best available

Capra, L.

Mascolo, C.

Zachariadis, S.

English

UCL Discovery

Q-CAD: QoS and Context Aware Discovery Framework for Mobile Systems Licia Capra, Stefanos Zachariadis and Cecilia Mascolo Dept. of Computer Science, University ColIege London Gower Street, London WC 1E 6BT, UK {L.CapralS.ZachariadislC.Mascolo)ecs.ucl.ac.uk Abstract This  paper  presents Q-CALl, a resource discovery frame- work  that enables pervasive computing applications to dis- cover and  select  the  resource(s) best  satisfying  the  user needs, taking the current execution context and quality-of- service (QoS} requirements into account.  The available re- sources are first screened, so that only those suirable to the current execution context of the application will be consid- ered; the shortlisted resources are then evaluated against the QoS needs of  the application, and  a binding is estab- lished to the best available. 1  Introduction Technological advances,  both  in wireless  networking and portable device capabilities, have met social popularity, so that we are now witnessing an increase in the number of devices and services we use to accomplish our daily tasks. Interaction with these services and devices is enabled by means of various components, some located on the mobile device, some available for download remotely. We refer to these services, devices and components as resources. Research in the area of resource discovery for pervasive environments has been very intense in recent years. Its main focus has been on the development of efficient algorithms that take the pervasive network topology into account when routing advertisements and queries (e.g.,  [4,  51).  However, more effort is needed to improve the  user experience,  so that the resources that the user considers most suited in the current execution context and according to hisher quality- of-service (QoS) needs are actually selected. In this paper  we  present Q-CAD, a  context and QoS aware resource discovery and selection framework for per- vasive  environments.  Each  application  dynamically  en- codes in an application profile the way context should in- fluence the discovery of, and the binding to, resources; Q- CAD uses this infomation to reduce the resources  avail- able to the application in the current context to a subset of 0-780380326/05/$20.00 02005 IEEE ‘plausible’ ones.  Each application also encodes the QoS needs of  the user into a  utility function that Q-CAD ap- plies to select the most suitable resource among the plau- sible ones.  Q-CAD builds on the following assumptions: the existence of  a shared ontology to refer to context el- ements and conditions, resource names and characteristics, and non-functional requirements; the integration with an  ex- isting discovery protocol for pervasive networks on which Q-CAD relies to route advertisements and  queries. The paper is structured as follows: Section 2 describes Q-CAD application profiles and utility functions, and de- tails the discovery and selection protocol; Section 3 presents the Q-CAD architecture; finally,  Section 4 compares  Q- CAD with related work and presents our conclusions.  For more  detailed and up-to-date  information  about Q-CAD please refer to [  21. 2  Q-CADModel Q-CAD achieves context and QoS awareness by means of application profiles and utility functions respectively. In this section, we describe the information they encode and il- lustrate how the discovery and selection protocol uses them. Before doing so, we define what a resource is in this set- ting, what binding to a resource implies and we introduce the concept of resource descriptor. Q-CAD Resources, Descriptors and Binding. Cenual to our model is the notion of a resource. The resources that the Q-CAD model considers are:  services provided by re- mote providers, sensors from which an application may re- trieve data, and components located remotely and that can be downloaded and deployed on the local host.  We refer to these resources as remote resources, to distinguish them from hose local to a device (e.g., battery, memory, CPU, etc.). We assume remote resources are uniquely identified by means of an addressable naming scheme that is resolved by the underlying communication framework.  We define the binding to a resource (i.e.,  the last step of  a resource discovery and selection process) as the association of  the selected remote resource to a component that is  local to the 453 icmwnent. displayvid-l  {Gize. 70KB1 IC&,  display8006Oo.jar1  Icost. $101 Iresolution.  BOOxhOOl  h".  21 IPlbtfom.  m2L a.11  Ibattery. 41 Figure 1. Example of Resource Descriptor. device and that is able to interact with it. A remote resource could itself be a component: in this case, binding refers to downloading and deploying the component on the local sys- tem. Every remote resource is also associated with a static specification, or resource descriptor, that characterises the resource by means of a list of attributdvalue pairs. Figure 1 illustrates an example of a remote resource descriptor for a component that displays video at a resolution of 800x600; besides implementation details, the descriptor contains in- formation that can be used to assess the quality of the re- source itself; this includes, for example, estimates of local resources consumption. Application Profiles. Application profiles specify how the user wishes the context to influence the discovery of remote resources.  Discovery can be either proactive (i.e., the consequence of an explicit request of the user to locate a service) or reactive (i.e.,  the result of context changes). Both types of discovery demand a similar behaviour from the discovery framework: locating and binding to a resource (be it a service provider, a sensor, or a component) that is best suited in the current context (conbexl-awareness) and according to the current non-functional requirements of the user (QoS-awareness). In the remainder of  the paper, we provide examples of proactive discovery only '  . Let  us imagine a tourist that wishes  to  print  the pic- tures she has taken  with her digital camera.  In order to do  so,  she has to discover and select a photo  develop- ment service provider, among the many available. Differ- ent parameters may influence this choice: for example, lo- cation of the provider, cost of the service, quality of  the prints,  and so on.  For  each  remote resource the  appli- cation may  be willing to  bind to, the proactive encoding of  its profile contains an association between the resource name (tag  <BINDRESOURCE>)  and  the context condi- tions  that must hold  for  the  binding to be  enabled  (tag <REMOTE-CONTEXT>). For example, the encoding shown in Figure 2 states that only printing service providers that give customers at least lOOMB of disk space should be con- sidered. This condition acts as a filter over the possibly high number of providers of the same service. Only one context configuration (tag <REMOTEXONTEXT  id=  " 1 >),  can- taining a single condition (tag <CONDITION>)  is specified. More generally, multiple contexts can be associated to the same binding resource, and more conditions may be asso- ciated to the same context. The semantics of these encod- 'A  discussion of reactive discovery is available at 121. Figure 2. Example of Proactive Encoding. ings are the following: the binding to the remote resource is enabled if and only if ut least one of  the context configu- rations is enabled (or semantics); a context configuration is enabled if and only if all the conditions associated to it hold (and semantics). If more than one service provider passes the filtering, the actual provider to bind to will be selected using the application's utility function. Once a remote  service provider  has  been  discovered and  selected,  the  application has  to  decide  how  to  in- teract  with  it  (i.e.,  what  component to  use),  as  differ- ent behavioudprotocols may be available.  The  compo- nent should be selected out of  a list of desirable ones (tag <ADAPT-COMPONENT>);  the choice depends on the fol- lowing information, that is attached to each of these compo- nents: local context, remote context, and application pref- erences.  For example, the encoding of  Figure 2 dictates that pictures should be uploaded to the provider site using a component that supports an encryption protocol when the remaining battery is above 30%,  while using a plaintext up- load otherwise.  If multiple components match the criteria given, the utility function will be used to select the one that best satisfies the  QoS needs of the user. Note that the cho- sen component may not be available locally; in this case, discovery, download and depIoyment of a component im- plementation is required; this process is almost identical to the one that has been discussed above, as components are treated as yet another type of resource. Utility Functions.  Once the pruning operated by  ap- plication profiles has been completed, utility functions are used to select the best resource out of the context-suitable ones, according to the non-functional requirements of  the user. Similarly to profiles, a utility function exists for each application, so that user preferences may vary depending 454 on the particular application. Figure 3 illustrates an exam- ple of  a utility function encoding.  As shown, the encod- ing is divided into two parts: a <MAXIMISE> part, and a <RETURN> part.  Under the tag <MAXIMISE>,  the appli- cation lists the non-functional parameters it is interested in, together with weights that express their relative importance. The <MAXIMISE>  part of the utility function is executed on a resource descriptor, as a summation of products (i.e., normalised estimates multiplied by weights, as found in the resource descriptor and  utility function, respectively); it re- turns a single value that can be used to compare the quality of different resources.  However, there are cases in which the selection process should not be fully automated. For ex- ample, the user may not want to download a component that maximises her non-functional requirements, if it is too ex- pensive. We use the <RETURN>  part of the utility function specification  when intervention on  behalf of the application or user is required. Figure 3 dictates that selection can be automated if the cost of the component is less than $10; oth- erwise, information has to be prompted to the application to obtain the final decision. This information includes, besides the result of the maximisation part, all the attributes listed in the <FILTER>  part of the utility function, Discovery  PMtOCOl.  The discovery protocol  that Q- CAD realises so to achieve QoS and  context awareness con- sists of  three main steps: matching, evaluation and selec- tion. On behalf of the application, Q-CAD sends a discov- ery message containing details about the wanted resource (e.g., component type, resolution, platform, etc.).  This in- formation can be  found  in the application  profile and is used to prune the number of  potential matches.  The re- mote resources receiving this message  evaluate it locally against their resource descriptors, and only those matching the query will reply  (matching step).  The resources that have survived the pruning now receive a message contain- ing the application's utility function; each remote resource evaluates the function over the relevant resource descriptors and returns an answer to the querying application (evalua- tion step).  Note that a resource may refuse to perform this computation, either because it does not have the capabilities to do so, or because it does not want to consume local re- sources. On the other hand, the application may not be will- Figure 3. Example of a Utility Function. ~,.-..............I ........... ....  ............... ........... .... ....... .... __~______...._.____________________II___ .'< j _.... .....l..... I  ___________...... j j Figure 4. The Q-CAD Architecture. ing, for privacy reasons, to disclose its utility function.  In these cases, the resource descriptor may be returned instead, and the application itself will compute the utility function over the descriptor locally, Finally, if no application inter- vention is required, the resource that maximises the applica- tion utility is automatically selected, based on the answers received andor the  local computation performed; if inter- vention is required instead, the retumed values are passed to the application to obtain a final choice (selection step). 3  Q-CAD Architecture As  shown in  Figure 4, the Q-CAD architecture is  or- ganised into four conceptual layers: the Application Meta- Interface layer, the  Information layer, the Decision layer and the Action layer. The Application Meta-Interface Layer encapsulates the interaction of the applications with the Q-CAD architec- ture. It is composed of the PolicyRepo and NotificationSer- vice components:  PolicyRepo represents the reflective as- pects of the application, as it allows for the dynamic inspec- tion and modification of the application profile and utility function; the NotificationSeIlrice  is responsible for extract- ing the information from the profile and  passing it on to the components in the Infomation layer, as well as returning the result of a resource discovery to the application. The Information Layer is responsible for the manage- ment of local and remote context-related information.  In particular, the Contextsensing component is responsible for monitoring the state of  the locaI system (e.g.,  remaining battery power, etc.), while the Discovery component is re- sponsible for detecting the remote resources (in particular, services and sensors) currently available to the local host, that the application  is interested in.  The two repository components are  responsible €or encapsulating information 455 about components already deployed locally (LocuiReposi- tory), or available for download and deployment on remote hosts (RemoteRepository). The Decision Layer encapsulates the evaluation and se- lection aspects of  the Q-CAD  protocol.  After the  Infor- mation layer has performed its pruning, the Decision layer evaluates the utility function against the shortlisted resource descriptors, and selects the one that maximises the applica- tion’s utility. It comprises both a Local and a Remote com- ponent, for local and remote evaluation of the utility func- tion respectively. The execution of the Evaluation compo- nent may generate events that need application input; if that is the case, the NotificationService component in the Appli- cation Meta-Interface layer is used to pass the events to the application and get the required input. The  Action Layer encapsulates  the  logical  mobility techniques [3] required  by the Decision layer (i.e.,  code- on-demand and remote evaluation).  It consists of the De- pluyer component, which comprises: the RemoteEvuZuation component, used by  the Remote component in the Deci- sion layer to depIoy the utility function on a remote host, and the CodeOnDemand component, that is responsible for downloading any remote component locally needed to per- form  adaptation.  The downloaded  components are reg- istered with the  LocalRepasitory,  so that the Information layer maintains an up to date status of the system. 4  Discussion and Conclusions In recent years, research has been very active in the area of  service discovery for pervasive  systems.  Most of  the work has  concentrated on designing protocols and architec- tures that could fit the mobile network topology. Examples include:  directory-based approaches,  such as Jini, U€”, the Service Location Protocol, the Salutation Architecture, and the Bluetooth Service Discovery Protocol; totally de- centralised approaches based on flooding algorithms, such as SSDP; approaches for single-hop ad-hoc networks (e.g., IBM DEAPspace [SI), multi-hop (e.g., Lanes [5]), and P2P (e.g.,  JXTA-Search 191).  A common limitation of these ap- proaches is that they concentrate on providing a commu- nication infrastructure, while supporting only primitive ser- vice matching mechanisms based on the exact match of  sim- ple pre-defined attributes. Approaches that move a step closer to our goal include: the Intentional Naming Scheme [I],  an overlay that allows each node to intelligently choose the nodes to which to for- ward queries based on the semantics of the request; MAG- NET [6],  a trading  framework that has been proposed to allow user-customised service matching, based on service types, rather than on service names, and [7],  a QoS-aware service selection framework that takes both the user per- spective and resource consumption into account. However, the semantics of  service queries and  matching is still not rich enough. In this  paper  we have described  Q-CAD, a resource discovery and selection framework for pervasive environ- ments that supports semantically rich descriptions of  both the current context and QoS needs.  The Q-CAD rtrchitec- ture has been implemented using Java 2 Micro Edition and the SATIN [lo] component model and middleware system for adaptive mobile systems.  In total, the Q-CAD imple- mentation occupies 127-  (compressed),  making it suit- able for mobile devices.  We have implemented a bench- mark application to evaluate Q-CAD performance in terms of:  overhead imposed by the evaluation of  context infor- mation (as encoded in application profiles), and overhead imposed by the evaluation of QoS information (as encoded in utility functions).  Experimental results (available at [2]) demonstrate that Q-CAD supports rich queries and match- ing, while imposing a low overhead on the device. References W. Adjie-Winoto, E.  Schwartz, H. Balakrishnan, and J. Lil- ley. The Design and  Implementation of an Intentional Nam- ing System. In Pmc. ojrh  I 7th  ACM Symposium on Oper- ating Systems Principles, pages 186-201. ACM Press, 1999. L. Capra, S. Zachariadis, and C. Mascolo. Q-CAD: QoS and Context Aware Discovery Framework for Mobile Systems. http://www.cs.ucl.ac.uk/stafffl.capra/projectdqcad, 2005. A. Fuggena, G.  Picco, and G.  Vigna.  Understanding Code Mobility.  IEEE  Transactions on  Software  Engineering, 24(5):342-361,  May 1998. R. Harbird, S.  Hailes, and C. MascoIo.  Adaptive Resource Discovery for Wbiquitous Computing.  In  Proc. offhe  Znd Int.  Workshop  on Midilavare for  Pervasive  and Ad-Hoc Cumputing, pages 155-160.  ACM Press, Oct. 2004. M.  Klein,  B. Konig-Ries,  and  P.  Obreiter.  Lanes  -  A Lightweight Overlay for Service Discovery in Mobile Ad Hoc Networks. In  Proc. ofthe 3‘d  IEEE Workshop  on  Ap- plications and Services in Wreless Networks (ASWN2Gtl3), Beme, Switzerland, July 2003. P.  Kostkova and J. McCann. Aduptive evulufionary  informa- tion systems, chapter Support for dynamic trading and run- time adaptability in mobile environments, pages 229-260. Idea Group Publishing,  2003. 1. Liu and V. Issamy. QoS-aware Service Location in Mobile Ad Hoc Networks. In Pmc. of the 5th IEEE Int. Con$  on Mobite Data Management, Berkeley, USA, Jan. 2004. M. .Nidd. Service Discovery in DEAPspace. EEE  Presonal Communications, pages 39-45, Aug. 2001. S. Waterhouse.  JXTA Search: Distributed Search for Dis- tributed Networks. http://search.jxta.org/. S. Zachariadis, C. Mascolo, and W.  Emerich. SATIN: A component model for mobile  self-organisation.  in Inter- national Symposium on Distributed Objects and Applica- dons (DOA), volume 3291, pages 1303-1321,  Agia Napa, Cyprus, October 2004. LNCS,  Springer. 456 

Q-CAD: QoS and Context Aware Discovery framework for adaptive mobile systems

Abstract

Similar works

Full text

Available Versions

UCL Discovery