context-aware paradigm for a pervasive computing ... - Semantic Scholar

IADIS International Conference WWW/Internet 2007

CONTEXT-AWARE PARADIGM FOR A PERVASIVE COMPUTING ENVIRONMENT (CAPP) Umar Mahmud CS Dept, Military College of Signals 4 – Humayun Road, Rawalpindi

Naima Iltaf CS Dept, Military College of Signals 4 – Humayun Road, Rawalpindi

Abdur Rehman CS Dept, Military College of Signals 4 – Humayun Road, Rawalpindi

Farrukh Kamran Center for Advanced Studies in Engineering 19 Attaturk Avenue, Sector G-5/1, Islamabad.

ABSTRACT Pervasive Computing integrates numerous, casually accessible and inexpensive mobile devices with traditional distributed systems. The foremost issue of pervasive computing is Context-Awareness. Context-Aware Paradigm for Pervasive Computing Environments (CAPP) is a Service Oriented Architecture (SOA) that enhances smart service discovery in a pervasive environment. Objective of CAPP is to deliver the best service available, among a pool of similar services, to the mobile user. The system gathers the low-level service and user contexts and interprets both these contexts into the highlevel ‘Who’, ‘What’, ‘Where’ and ‘When’ contexts. The interpreted high-level context is then used to discover the best available service for the user. The effectiveness of CAPP is measured in terms of success and failures where success is the systems ability to select an appropriate service from a pool of similar service to the user, based on the contexts. The projected success rate of the test cases is 89%. KEYWORDS Context-Awareness, Service Discovery, Ubiquitous Computing.

1. INTRODUCTION Pervasive computing bridges the gap between the ever increasing variety of smart devices and the existing services which were previously invoked through conventional systems (Moran, 2001). The term contextawareness was first coined by Schilit in 1994. Context encompasses all of the information relevant to an interaction between a service and its set of users including the participants as well. A comprehensive definition of context as viewed in the setting of pervasive computing is given by Dey as information used to characterize the situation of an entity where an entity could be a person, object or a place relevant to an interaction. We propose a SOA that follows the Networked Services approach of context management for the development of CAPP. CAPP is platform independent, modular and is based on industry standards. The system gathers contextual data, interprets it and discovers services for the user. In the following sections we

337

ISBN: 978-972-8924-44-7 © 2007 IADIS

describe a context aware smart service discovery setup that provides the best service to a user based on the contexts of both the user and the services.

1.1 Related Work The pioneering location-aware systems were developed in Olivetti Research Lab and Xerox as Active Badge System and Xerox PARC respectively in the early 90’s (Want, et al, 1992 and Schilit, 2002). These systems took only location as the contextual information. The Cyberguide and GUIDE took time in addition to the location as the contextual data (Abowd, et al, 1997 and Chaverst, et al, 1998). The second generation of context-aware system introduces a rich contextual data that includes all the information relevant to an interaction. GAIA is a CORBA based middleware operating system that runs on top of existing systems, such as Windows and Solaris (Roman, et al, 2002). CAMUS is JINI based middleware architecture for contextaware systems (Riaz, et al, 2005) and provides context-based service delivery to the client. The Context Managing Framework follows a classical hierarchical infrastructure approach with one or many centralized components (Korpipaa, et al, 2003). The SOCAM project is architecture for the building and the rapid prototyping of context-aware mobile services (Gu, et al, 2004). CoBrA is agent based architecture for supporting context-aware computing in intelligent spaces (Chen, et al, 2003).

2. ARCHITECTURE OF CAPP This research provides smart service discovery to mobile users in smart spaces. The discovery process is facilitated by addressing the issue of context-awareness. The earlier context-aware systems used a static and fixed discovery process and the contextual data was used to adapt specific applications. In CAPP, the context is used for service discovery where the user is delivered a different service of the same type under different circumstances. CAPP is designed as an SOA so that it can facilitate service discovery in any pervasive environment. The preferred implementation is envisaged to be platform as well as programming language independent following an industry standard. The objective is to select the best service, among a pool of similar services, for a user based on the user’s context as well as the services’ context. The entire gathered context is represented as a hierarchy while providing flexibility of change. The context is interpreted by inferring the ‘What’, ‘Who’, ‘When’ and ‘Where’ contexts while weighted averages are used to facilitate the selection of the best service. CAPP follows the Networked Services approach for Context Management and Ontology Based Model for Context Representation (Baldauf, et al, 2007). The networked services approach is robust and is based on the client-server model. The Ontology based representation allows for the incorporation of rich context that also facilitates reasoning process. The architecture of CAPP is shown in Figure 1. CAPP has three main components, The Context Congregator, the Context Interpreter and the Decision Maker. Table 1 outlines the functions of each component.

Figure 1. Architecture of CAPP

338


Table 1. Functions of modules in CAPP Dispatcher module

Context congregator module

Context interpreter module

Function Description Inputs Outputs Function Description Inputs Outputs Function Description

Inputs Outputs Decision Function making module Description Inputs Outputs

Receives request and acts as an interface This module listens to incoming requests and forwards them to the congregator for context gathering Client information and request Client information and request with a request ID Gather context data on the basis of client’s info and request and represent the gathered information in the form enforced by the rule repository This module gathers context data Client information and with a request ID Gathered (vital) context To interpret the gathered context This module interprets the gathered context by and identifying Who, What, Where and When contexts for both the user and the service Gathered (vital) context Interpreted context Makes decision on which service is to be delivered to the client Decides as which is the best available service using weighted average of the contexts Interpreted context Best service/list of probable services

3. CONTEXT CONGREGATOR The context is a large data set and can be classified into numerous context types that organize the raw contextual data into spatial, temporal, environmental, activity, community and identification categories. The context types that have been identified in CAPP are described in Table 2. The contextual information is classified into different categories thus providing efficient retrieval. The main entities are the user and the services. The user interacts with the services including the system through a number of devices. These devices are part of the user’s context since they are the client to the services. Table 2. Context data types Context data type Identification spatial Temporal activity Environmental Community Health Advanced

Description This category includes the identification parameters of both the user and the service This is the context that is related to the location parameters. For the mobile user or service it is the expected location Time, date, month, year, etc. are part of the temporal information of both the user and the service Attributes that describe the activity of the user as busy or idle as well as those that describe the status and activity of the service as idle, offline or active The environmental conditions of the surrounding areas of both the user and the service in terms of temperature, humidity, noise, air quality, dust levels and illumination, etc Context that describes the peers and their devices and available services and their status Information that provides the health situation of the user including blood pressure, temperature, etc. This also specifies if the user has any health constraints e.g. allergies, etc Advanced information includes mood, emotions, and role of the user while it specifies the availability time, queue length, load, battery power and the network bandwidth parameters of the service. Mood and emotional information maybe provided by the user

3.1 Context Space in CAPP The contextual information is classified into hierarchical categories that provide efficient organization and retrieval. The main entities are the user and the services. The user interacts with the services including the system through a number of devices. These devices are part of the user’s context since they are client to the services. Figure 2 shows the context space in CAPP. The broad subcategories of both types of context are same as well as some of its attribute names like location, time etc but the values stored in these attributes are in perspective of either the user or the service. The context space comprises of set of contextual information

339

ISBN: 978-972-8924-44-7 © 2007 IADIS

where a point in the context space identifies a situation or interaction between the user and the service. Based on the concept classification in Figure 2, the concept taxonomy was generated using the Protégé OWL tool.

Figure 2. Context space

3.2 Controlled Vocabulary Controlled Vocabulary is a set of word or phrases that are used to tag units of information for smart and efficient retrieval by a search. The Context Congregator requires that it searches for sensor services present in the system relevant to the interaction. These services may have different names that the request made by the client due to the ambiguities occurring in natural languages. These ambiguities can be reduced by providing a controlled vocabulary. Such a controlled vocabulary has keywords that provide us to search for a type of context that is to be sensed. For example, a user asking for a latest score service could be replied providing data from a sports service.

3.3 Vital Contextual Data The amount of the gathered context data is large and not easily manageable. It is inefficient to gather all the data at all times or when a user has requested an interaction. Some of the data is necessary for a particular interaction while the rest has no effect on the interaction. If all the data is to be maintained at all time, the system will become memory heavy as well as inefficient. The solution is to gather the data only when the user has requested for an interaction and to collect only the data that is critical to the interaction. A list of necessary data for an interaction is also maintained in the Context Congregator Module. This list is generated by the developers and at the moment does not have any learning techniques to modify and update the list.

4. CONTEXT INTERPRETER The gathered low-level context is interpreted to high-level context that provides meaning to the raw data. This task is carried out in the Context Interpreter Module that takes the vital context as its input and generates the interpreted context of both the user and the service.

4.1 High-Level View of Context The high-level context is the context as viewed from the top layer of user context and service context in Figure 2. The high-level context identifies the ‘Who’, ‘What’, ‘Where’ and ‘When’ contexts of both the users’ as well as the services’. The ‘Who’ context is concerned with the identification and description parameters

340


and the ‘What’ context interprets the user’s request as well as the services’ capabilities or functionalities. The ‘Where’ context specifies the location and environmental parameters while ‘When’ gives the time when the request was made and the time when the service will be delivered. The High-level user context attempts to identify the context related to the user. The ‘Deduced What’ context type for the user is the requested service type and is handled in the context congregator to provide smooth functionality. Table 3 lists the description of the high-level user context types. With the deductions of the high-level context in terms of ‘Who’, ‘Where’, ‘When’ and ‘Health’ of the user, the interpreted user context is hypothesized as, User Deduced User (User) has requested a Deduced What (User) service at Deduced When (User) time. The user wants the service to be delivered at Deduced Location (User) while he/she is involved in activity Deduced Activity (User) and has health condition Deduced Health (User). Table 3. High-level user context types High-level user Description context type Deduced who The user is deduced on the basis of the ID, role, name, etc. Role of the user is deduced by comparing the activities of the user with the activities of its peers, if it is not available Deduced Deduced when is divided into two parts; Deduced Time and Deduced Activity. The objective of the when first part is to infer the time when the service is requested by the user using the user date and user time. In the absence of all or some of the user time parameters, the time is identified as the time when the request was received. The second part infers the time when the service should be delivered to the user. This time is based on the activity of the user and the state of users’ devices Deduced This type of context is concerned with as, where the service will be delivered to the user. More where specifically, this identifies on the basis of user location, user mobility and user orientation that where the user is located. In an event the user location information is missing, user surroundings information is then used to deduce the location of the user. Deduced The health category involves all those parameters that are part of the health parameters of the user. If health the health of the user is not normal, this would constraint the selection of best service for the user

The High-level service context attempts to identify the service and its type, locate the service and when the service will be available for use. With the inferences of the high-level context in terms of what, where, when and who of the service the interpreted service context is hypothesized as, Service Deduced Service (Service) is of type Deduced What (Service). The service is located at location Deduced Where (Service) and will be available at time Deduced When (Service). Table 4. High-level service context type Description High-level service context type Deduced who The service is deduced on the basis of the service name, ID, alias or the owner information Deduced when It identifies the time when the service will be available for use based on the load on the service, the network situation of the service Deduced where This specifies where the service is located and in case the service is mobile specifies its expected location. In an event the location information is unavailable the location of the service is inferred through the service surrounding information Deduced what This category infers the primary and secondary types of the service by evaluating the type information in service list as well as the description of the service. If the type of the service is available then the deduced what is simply the available type information. In the absence of the type information, the service description is used to infer the type of the service

5. DECISION MAKING IN CAPP The decision making in CAPP selects the best service among a pool of similar service for a user based on both the users’ and the services’ contexts. The outputs generated by the Context interpreter are the interpreted user context and the interpreted service context, both of which are input to this module.

341

ISBN: 978-972-8924-44-7 © 2007 IADIS

5.1 Which Service In a typical scenario the decision making module is met with a single user context and multiple service contexts. The presence of multiple service contexts against a single user context for a single interaction highlights the selection of the most appropriate or ‘Which’ service for the user. The selection is made on the basis of deduced high-level contexts of ‘What’, ‘When’ and ‘Where’. The outcome is a ‘Who’ service that is most suitable for the ‘Who’ user.

5.1.1 Deduced What (User) vs. Deduced What (Service) The user request is deduced to find the type of the requested service as ‘Deduced what’ of the user. All the services listed under the same type are evaluated as a candidate for decision making module. On the other hand, the ‘Deduced what’ in terms of the service infers the primary and secondary type of each service listed in the smart space. Both the deduced values are compared with each other and if the values of both variables are same then the service is selected. Otherwise, the output of this process is a priority list of the probable services on the basis of the requested type matched with the primary the secondary type of the service.

5.1.2 Deduced Where (User) vs. Deduced Where (Service) The ‘Deduced when’ in terms of the user specifies the location of the user while, the ‘Deduced when’ of the service identifies the location of the service. This comparison process lists the services starting from the nearest to the farthest service from the user in the smart space.

5.1.3 Deduced When (User) vs. Deduced When (Service) The ‘Deduced when’ of the user is the time when the user initiated the request while, the ‘Deduced when’ of the service is the time when the service will be available for use. This comparison process makes a list of the services starting from the service that will be available the earliest to the service that will be delivered at the latest.

5.1.4 Deduced Health (User) The user health imposes restrictions on the selection of the service. For example, a user having dust allergy would not like a service in the dusty area or a user with fever will not require a service located in cold server rooms. These restrictions are evaluated and a priority list is made.

5.1.5 Final Selection of Which Service The final selection process selects the best service for the user that is labeled as the most appropriate following a weighted average scheme of What, Where, When and Health for any scenario. The outcome of each comparison described in Section 5.1.1–Section 5.1.4 is a priority list of the service contexts on the basis of type, location, time and health of the user. Weights are then used to provide a bias for one type of context over the other. The normalized weighted averages are calculated for each service and the selected service is the one with the highest normalized weighted average. Equation 1 shows the weighted average for a service, where p, q, r and s are the weights in Equation 1. Weighted averages have been employed in decision making to provide a linear and simple mathematical basis for the decision making process.

⎡ ( p × WhatValue) + (q × WhereValue) + (r × WhenValue) + (s × HealthValue)⎤ ServiceNWA = ⎢ ⎥ 4 ⎣ ⎦ (1)

Figure 3 illustrates the flow model of the decision making process in CAPP. This model is developed to assist the programming of the decision making module. The system starts with the interpretation of the gathered contexts and then calculates the weighted averages of each interpreted context. The system then discovers if the selected appropriate service is a single service or a short list of the probable services. Both types of the result are returned to the user.

342


5.2 Uncertainty in Decision Process In the event that the services selected by the comparison between interpreted contexts of both the user and the services do not lead to the selection of a single best service, the short list of the most probable service (services having the same weighted average) is then returned to the user. The user then selects the service from the short list. It may happen that all of the services may be returned as a result of the decision making process, the system is then considered to be unable to reach a conclusion and the outcome is termed a failure.

Figure 3. Decision making in CAPP

6. EVALUATION CRITERION To evaluate CAPP a simulation approach has been selected to validate the results of test case scenarios. The effectiveness of the system is termed successful if it is able to return a single service or a short list of probable services to the user. In an event the system is unable to reach a conclusion either by returning a single service or a short list of probable services, the test run is considered as a failure. For the case when the user requests a service that is not listed in the smart space, informing the user that the service is not listed is also termed as a success. The evaluation criterion has been set as; the successes should be at least 75% of the total number of cases.

6.1 Performance of CAPP The performance of CAPP is measured in terms of the success rate i.e., number of successes among all cases Only cases where there are no health constraints and the weights are set to 1 are considered in Equation 1. The total number of values where there are three services and each service can have the same three values is given in Equation 2 where ‘A’ is the all possible combination when ‘V’ is the value levels for ‘N’ number of services. Table 5 lists all the failures among all possible combinations when three value levels are used for three services.

343

ISBN: 978-972-8924-44-7 © 2007 IADIS

A =V N A = 33 A = 27

(2)

As highlighted in Table 5, there are 3 failures out of a total 27 possible combinations. 15 cases resulted in selection of single service while 9 cases provided a short list of the probable services. The success rate is given in Equation 3, where ‘F’ is the failure rate when ‘f’ is the number of failures among ‘A’ possible combinations and ‘S’ is the success rate. Equation 3 shows that 89% of the time the system will be able to reach a conclusion. This value is a high success rate for a context-aware system and is also higher than the criterion set by us i.e., a success rate of minimum 75%.

F = f

A

F = 3

27 F ≅ 0 . 111

(3)

S ≅ 0 . 889 ≈ 89 % Table 5. Success and failure cases 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

344

Service A 0.9 0.9 0.9 0.9 0.9 0.9 0.9 0.9 0.9 0.5 0.5 0.5 0.5 0.5 0.5 0.5 0.5 0.5 0.1 0.1 0.1 0.1 0.1 0.1 0.1 0.1 0.1

Service B 0.9 0.9 0.9 0.5 0.5 0.5 0.1 0.1 0.1 0.9 0.9 0.9 0.5 0.5 0.5 0.1 0.1 0.1 0.9 0.9 0.9 0.5 0.5 0.5 0.1 0.1 0.1

Service C 0.9 0.5 0.1 0.9 0.5 0.1 0.9 0.5 0.1 0.9 0.5 0.1 0.9 0.5 0.1 0.9 0.5 0.1 0.9 0.5 0.1 0.9 0.5 0.1 0.9 0.5 0.1

Outcome ABC AB AB AC A A AC A A BC B B C ABC AB C AC A BC B B C BC B C C ABC


6.2 User Bias The failure rate calculated in Section 6.1 is the maximum failure rate. This rate was calculated when the weights of the ‘what’, ‘where’ and ‘when’ contexts were set to 1. To further decrease this rate the weights must be altered. Altering the weights will have more effect of one type of context on the weighted average than the rest of the contexts. This increases the probability of successes by ensuring that the system reaches a conclusion. These weights cannot be set randomly but must be set according to some external bias or the user bias. Some users have preference for services that are closely located while others have preference for services that are available at the earliest. These preferences are the user bias. User bias is a dynamic term and changes with context. For example, a person who has a bias for rice as lunch may not like to have rice for dinner since he is having the same course for the past three days. Hence, the user bias changes with context. But, this prediction of the users’ bias requires close monitoring of users’ history.

7. LIMITATIONS OF CAPP The prime constraint in the system is the availability of the context sensing devices or the sensor services. All of the sensor devices cannot be available everywhere and at all times. This requires that some of the necessary context be predicted on the basis of some history. In CAPP, a history is not included as it is considered storage overhead. We assume that the sensor devices are available and provide true and real time data to the system. The system will not be able to function in the absence of sensor services. The contextual data of the users as well as the services is sensitive information. This data can be easily exploited if it is not secure. There is a need for the presence of access control module that disallows unauthorized access and a privacy control module that ensures confidentiality of the data. The secrecy can be provided by encrypting and then storing the data.

8. CONCLUSION In the computing era of pervasive computing, context-awareness being a prime issue demands a generic context-aware system that gathers and interprets contextual data and facilitates the process of smart service delivery to a mobile user. The process starts with context acquisition, followed by the representation using a rich and standardized ontology language and its subsequent interpretation, decision making on the basis of users’ and the services’ context and ends in the delivery of the appropriate service to the user. CAPP is a service oriented framework that realizes context-awareness in pervasive computing environments. CAPP is designed as a robust, scalable and modular architecture that masks heterogeneity of the underlying platform and conforms to the object-oriented features of encapsulation and information hiding. The model facilitates delivery of the finest service to the users by interpreting the contextual data. The context interpretation is carried out on the axes of ‘Who’, ‘What’, ‘Where’ and ‘When’ contexts of the user and the services involved.

REFERENCES Abowd, G.D. et al, 1997, Cyberguide: a mobile Context-Aware Tour Guide. ACM Wireless Networks, Vol. 3, No. 5, pp 421-433. Baldauf, M. et al, 2007, A Survey of Context-Aware System. International Journal of AdHoc and Ubiquitous Computing, Vol. 2, No. 4, pp 263-277. Chaverst, K. et al, 1998, Design of an Object Model for a Context Sensitive Tourist GUIDE. Proceedings of the International Workshop on Interactive Applications of Mobile Computing (IMC 98), Rostock, Germany, pp 883-891. Chen, H. et al, 2003, An Intelligent Broker for Context-Aware Systems. Proceedings of UbiComp, Seattle, pp. 183-184. Dey, A.K., 2001, Understanding and Using Context. Personal and Ubiquitous Computing, vol. 5, No. 1, pp. 4–7.

345

ISBN: 978-972-8924-44-7 © 2007 IADIS

Gu, T. et al, 2004, A Middleware for Building Context-Aware Mobile Services. IEEE Vehicular Technology Conference, Los Angles, USA, pp 2656-2660. Korpipaa, P. et al, 2003, Managing Context Information in Mobile Devices. IEEE Pervasive Computing, Vol. 2, No. 3 pp 42–51. Moran, T.P. and Dourish, P., 2001, Context-Aware Computing. Special Issue of Human-Computer Interaction, Vol. 16, pp 1-8. Riaz, M. et al, 2005, Service Delivery in Context Aware Environments: Lookup and Access Control Issues. Proceedings of the 11th IEEE International Conference on Embedded and Real-Time Computing Systems and Applications (RTCSA'05)Hong Kong , pp 455-458. Roman, M. et al, 2002, Gaia: A Middleware to Enable Active Spaces. IEEE Pervasive Computing, Vol. 1, pp 74-83. Schilit, B. and Theiner, 1994, Disseminating Active Map Infrastructure to Mobile Host. IEEE Network, Vol. 8, No. 5, pp 22-32. Schilit, B.N. et al, 2002, Context-Aware Communication. IEEE Wireless Communication, Vol. 5, No. 5, pp 46-54. Want, R. et al, 1992, The Active Badge Location System. ACM Transactions on Information Systems, Vol. 10, pp 91-102.

346