VAN KRANENBURG LAYOUT
7/19/06
10:33 AM
Page 67
ADVANCES IN SERVICE PLATFORM TECHNOLOGIES FOR NEXT-GENERATION MOBILE SYSTEMS
A Context Management Framework for Supporting Context-Aware Distributed Applications Herma van Kranenburg, Mortaza S. Bargh, Sorin Iacob, and Arjan Peddemors, Telematica Instituut
ABSTRACT Service platform functions are enablers of adaptive communication services and applications that hide the heterogeneity of the infrastructure, manage personal reachability, manage implicit context, and adapt modality to the context. Furthermore, they can offer a diversity of services, whereby an optimal tradeoff can be made for end users in comfort, cost, security, and mobility. We consider the enablers of context-aware services in distributed environments and present a context management framework that is generic through its hierarchic ordering of context sources and extensible with multiple reasoning realizations. The article focuses on the architectural principles and reasoning methods of the framework.
INTRODUCTION Mobile end users are interested in tailored applications that they can access and use from any place at any time. This is reflected in a mantra coined in 1991: “giving all the freedom to communicate anywhere, anyplace, anytime, in any form.” End users are best served if this target is fulfilled keeping the user’s perspective in mind, such that the user is in control, and not from a technology push perspective. Such a user-centric view has been adopted by various visionary groups like the WWRF and the EU’s IST advisory group (ISTAG) [1, 2]. According to these visions, the technology should adapt to and comply with user needs and preferences. This requires tailoring services and applications to the context (i.e., need, situation, resources, etc.) of end users using any device available. Recently we have witnessed a new paradigm arising: “enabling services in the right place, at the right time, and with the right media.” Realization of this advanced vision demands mechanisms for ubiquitous search and discovery, and techniques for anticipating user needs while the end user
IEEE Communications Magazine • August 2006
remains undisturbed by the underlying technology. Figure 1 illustrates these paradigms. With the growing diversity of services, devices, and means of connectivity, intelligent service platforms provide service enablers or functions for provisioning of seamless and adaptive applications and services. These enablers for personalization and contextualization include context sensing, context exchanging, context interpreting, context brokering, and semantic matching. The service platform functions will typically be distributed in various domains. For instance, consider context-gathering components that may exist on your smart phone (collecting presence and GPS location information), in your home or office system (sensing your login status at your personal computer), and in your cellular network (collecting location information based on your cell ID). The service platform must hide the complexity associated with services and applications crossing over different access domains and cope with the various access network technologies. On the other hand, it should lead toward a user-transparent infrastructure and provide application developers and third parties with service enablers that ease and quicken context-aware application development. The enablers of context awareness, in particular, enable applications to be (dynamically) tailored and adapted to enduser preferences and circumstances. We have designed a generic framework for context-processing entities that support tailored applications and services in a multidomain mobile environment. This framework is scalable, supports logic for application-specific context, allows for processing cross-layer context, supports heterogeneous context-exchange protocols and data-formats, and offers a single interface to multidomain context sources. This article describes our approach for context management activities such as gathering, interpreting, and distribution. The main contributions of this article are the highlevel architecture of the framework and an overview of reasoning methods available for intel-
0163-6804/06/$20.00 © 2006 IEEE
67
VAN KRANENBURG LAYOUT
7/19/06
10:33 AM
Page 68
Middleware abstractions for
Is my buddy around?
Anywhere
context acquisition shield low-level sensing implementations
In any form
How can I send a picture?
from high-level applications, which is quite
What is my location?
On any device
essential in providing support for context awareness.
Freedom to communicate Use services tailored to user needs and situations
Service platform Discovery services
Intelligent services
Internet and intranet Intranet services
Anytime
Context services
Telecom systems
Internet services
Telecom services
■ Figure 1. Seamless services and tailored applications everywhere and always are supported by service platform functions. ligent processing of context information. In the remainder we first present an overview of related work, followed by requirements and our architecture. We review context-reasoning methods and approaches. Next, we present our implementation results. Conclusions are given in the final section.
CONTEXT MANAGEMENT APPROACHES Context is a broad concept. We apply a definition based on Dey and Abowd [3]: any information that can be used to characterize the situation of an entity, in which the entity can be a person, a place, or a physical or computational object that is considered relevant to the interaction between entity and application. In addition, we consider context from a user-centric perspective, as illustrated in Fig. 2, and partition it into categories that are of particular relevance to software infrastructures facilitating context awareness. These categories include: subscription and identity information; device, network, and resource specifications; and user-environment information (such as location, presence, and other persons in the surroundings). This section gives a brief overview of common approaches for supporting context aware-
68
ness. These approaches include middleware abstractions for context aggregation and distribution, agent-based approaches, loosely coupled Web service frameworks, and various contextprocessing service architectures with intelligent context-handling functionality. Middleware abstractions for context acquisition shield low-level sensing implementations from high-level applications, which is quite essential in providing support for context awareness. This is done, for instance, in the Context Toolkit, where context widgets abstract real-life (sensed) contextual information and interact with interpreters and aggregators. Although flexible, this framework is limited in scalability and in dealing with unreliable context information, and suffers from communication overload. In [4] the Context Toolkit is described, evaluated, and compared to other approaches such as the scalable peer-to-peer Solar platform and Aura. Other overviews of middleware approaches are provided in [5, 6] and include CoolTown, Sentient Computing, Oxygen, and Endeavour. In CONTEXT [4], an extension on the virtual home environment service platform is made with reusable context-handling components and context brokers. The result is a robust end-to-end system that, however, is complex and lacks in flexibility and modularity. The event-based mid-
IEEE Communications Magazine • August 2006
VAN KRANENBURG LAYOUT
7/19/06
10:33 AM
Page 69
Applications can interact with the context service to
Application
obtain the required information. New or
Active session Access network
derived context information can be made available by a context service that can be plugged into the context
Devices Personal environment
infrastructure. This is extended with integrated support
Identities
for privacy and a quality of information measure.
■ Figure 2. Context seen from a user-centric perspective. dleware in CORTEX uses autonomous objects (so-called sentient objects) that are able to discover and interact with each other; they sense their environment, process contextual information, and provide contextual information. In many other research projects broker components or agents are used: well-known examples are the Context Broker Architecture (CoBrA), SOUPA, and GAIA [7]. Central in these is a context broker that maintains a shared network model, ontology, and a common policy language, and negotiates resources and services between software agents, context sources, context brokers, service providers, users, applications, services, communication and computational networks, and devices. No use has been made (as yet) of artificial intelligence tools to bridge the semantic mismatch between different domains. In order for software agents to have a common understanding of information (such as terms used for describing the contextual information), semantic Web can be used to express information in a precise, machine-interpretable form. Web-based loosely coupled frameworks use the existing Internet and Web infrastructures as glue for communication between people, places, and other objects. For instance, myCampus [8] is a prototype semantic Web environment that aims at enhancing everyday campus life. Sources of contextual information are modeled as Web services that can automatically be discovered and accessed by agents assisting the end user. Another example is CoolTown; a loosely coupled framework that is based on the notion of a Web presence for people, places, and things, with a focus on displaying context and services to end users. As users move around, a list of available services in their current environment is displayed on their device. However, this design did not include support for interpretation of low-level sensed context information. Generic middleware infrastructures for context collection and dissemination are realized as
IEEE Communications Magazine • August 2006
an extendible context service that can be accessed by any device and any application, as described in [9]. The context service collects and maintains contextual information about users and devices. Applications can interact with the context service to obtain the required information. New or derived context information can be made available by a context service that can be plugged into the context infrastructure. This is extended with integrated support for privacy and a quality of information measure. The PACE middleware [6] addresses advanced context handling with a focus on distributed systems. A context management system is combined with a preference management system providing customizable decision support to applications and a programming toolkit facilitating interaction between applications and these managers. Unsolved issues include scalability (planned to be solved by federating the context and preferences managers of various domains), configuration and management of sensors, mobility support, and user-control mechanisms.
ENABLING CONTEXT AWARENESS This section describes in more detail our approach, for which we tried to learn from those mentioned in the previous section and then combine the best solutions. With reference to the previous section, these include aggregation and inference of both multidomain distributed context and multi-interpreted-level (from raw sensor data to higher semantics) context. Instead of prescribing a particular implementation, we support heterogeneous context exchange protocols. The constellation of our Context-Source components (abstracting sensed data) together with a peer-to-peer brokering approach in the context domains yields a scalable solution, whereas particular reasoners can be optimized for processing uncertain, vague, superfluous, and conflicting contextual information. We have also incorpo-
69
VAN KRANENBURG LAYOUT
7/19/06
10:33 AM
Application components
Application layer
Infrastructure (per domain)
Page 70
ContextSource
Get, publish/subscribe
Context reasoner Context reasoner Data sensor
Context provider
User manager
Context wrapper Context reasoner
■ Figure 3. Functional blocks in our service architecture.
rated quality of context (QoC). Our ContextSource’s approach allows for separation of generic and application-specific context exchange paradigms, which we extended with intelligent context-handling functionality. The intelligence in context-handling components (“Reasoners”) can extend from expert systems and various plain and hybrid reasoning techniques specializing, for example, in resolving ambiguities.
REQUIREMENTS The following requirements can be formulated for service enablers capable of dealing with heterogeneous information and facilitating context processing: • Find and provide access to sources of contextual information, (e.g., regarding persons, devices, location, network status, and presence). The number of contextual sources can be huge, and they are likely to be controlled by different stakeholders. • Gather the information from these context sources and exchange this between functions within one service platform; between different service platforms; and between different interested parties (operators, applications, network providers, etc.). Context gathering and exchange should allow for transparent use of distributed context sources. • Interpret the context information and derive a plausible and usable semantic piece of information that allows for expression of only the information needed for the given purpose. • Capture and represent the contextual information in syntax and semantics that are interoperable with the ones used in other service platforms. • Support for anticipatory responsiveness to (upcoming) changes in the environment by proactively triggering mobile services in advance to changes actually having occurred.
ARCHITECTURE The requirements led us to a design and realization of our Context Management Framework (CMF). In that CMF, the Context-Source component integrates distributed information from multiple sources of contextual information and from multiple administrative domains. It can be considered as a single point of access for context information by context-aware applications [10].
70
Each Context-Source can call upon the interface of other Context-Sources, through which a dependency hierarchy (or constellation) of Context-Sources arises. This recurrent calling upon various Context-Sources is an essential aspect of the CMF’s functional decomposition. Figure 3 illustrates the Context-Source component. Its functionality is to provide for relevant context information, either by directly monitoring the environment or by proper interpretation of heterogeneous and distributed context information. Together with the Context-Provider (that provides a single point of entry to multidomain context information for applications and ASPs and covers scalable access and discovery mechanisms), the constellation of Context-Sources constitute the CMF. The User-Management function shown in Fig. 3 holds information on end users, the devices they own, and their subscription specifications that is linked to their associated rights in accessing certain parts of the contextual information. User management takes care of privacy-related aspects, which are not further explored in the current article. A Context-Source provides both a synchronous retrieval interface, that is, GetContext(), through which a particular context information object can be retrieved, and an asynchronous event interface, that is, “EventSink,” Subscribe(), and Unsubscribe(), that can be used by an application (or another Context-Source) to register events that it wants to be notified of (e.g., changes in location). We distinguish between Context-Wrapper and Context-Reasoner as Context-Source components. Whereas a Context-Wrapper encapsulates information about a particular (“single”) piece of context information — such as location or activity — interpretation of that information is done by a Context-Reasoner. In the next section we describe the context-reasoning methods and approaches in more detail.
CONTEXT REASONERS In order to be efficiently used, context parameters have to be properly selected, adapted, and interpreted in terms that are relevant for the requesting entity. This is a relatively complex task for which different solutions have been proposed [11, 12]. Context reasoning groups a number of analysis techniques for contextual data that help in selecting and interpreting the context parameters.
FUNCTIONAL MODEL Context-Sources are a particular type of service component providing certain contextual information. These ContextServices can be used to adapt functional or nonfunctional properties of applications. When a Context-Source only does straightforward sensing of, for example, temperature or movement (typically a Context-Wrapper), we speak of a context sensor. Generally, the information acquired from context sensors cannot be directly used for adapting arbitrary applications, for the following reasons. From the perspective of end users, multiple context sensors may be needed to acquire all parameters that are relevant for instantiating or adapting a certain application. Typically, each of these sen-
IEEE Communications Magazine • August 2006
7/19/06
10:33 AM
Page 71
sors will only provide part of the relevant parameter-set. Additionally, different context sensors can provide similar information, while some of the needed context parameters may remain unavailable. The problem becomes even more complex when the requested context information has a relative nature, in that it refers not only to the requesting entity, but to other entities as well. A Context-Reasoner’s task is to ensure a composition of context sensors that is relevant for the requesting entity’s application domain and to derive useful contextual information. From an architectural perspective, the Context-Reasoner functionality resides between applications and context sensors. It can be deployed either at the context sensor side, at the application side, or at a third entity usually referred to as context broker [4]. From a functional perspective, the ContextReasoners need to solve the following problem classes: • Matching Context-Source descriptions with application-specific parameters • Retrieval and selection of existing ContextSources • Derivation or estimation of entailed context information by combining existing context parameters from (multiple) ContextSource(s) Figure 4 shows a high-level model for a Context-Reasoner based on these categories. For simplicity, the Context-Wrapper and Provider from Fig. 3 are excluded so as to depict a Context-Reasoner. The interface towards context-aware applications solves the problem of matching application-specific requests with available Context-Sources. There might be multiple implementations of these request-matching modules, specific to different application domains. The interface towards context sensors solves the problem of context selection and retrieval. In case there is no selection of sensors that satisfy a request, additional context parameters have to be derived through some combination of sources (stemming from sensors or/and already interpreted information), or estimated from existing parameters values.
REASONING METHODS Methods for Request Matching — For simplicity, but also following the current trends, we may assume that both context parameters and context-aware application parameters are explicitly described in terms of some ontology, rather than hardwired in application logic [10]. The core of the matching problem lies in the fact that context requests are likely to be formulated in terms of application domain ontology, while context parameters are likely described in terms of an ontology more adequate for the context domain. Although ontology mapping is still a challenging problem (see, e.g., the overview in [11]), this is beyond the scope of this article. Assuming that suitable techniques for mapping are available, the matching problem reduces to computing a similarity measure (a so-called inverse distance) between two semantic constructs: the request and candidate matching context descriptions. The main limitation of these direct matching techniques is that the ontology mappings are static, and changes in one ontology need to be reflect-
IEEE Communications Magazine • August 2006
1
2
Context sensors
n
Context retrieval
Context retrieval Context-Reasoner
VAN KRANENBURG LAYOUT
Derivation and estimation Requests matching
1
Requests matching
2
m
Context-aware applications
■ Figure 4. High-level architecture of Context-Reasoners. ed in the mapping itself, which leads to a rather large maintenance effort for keeping the matched ontology in synchronism. To overcome this limitation, we envisage the use of learning techniques to adapt ontology mappings: in case of query terms not being matched by Context-Source descriptions, unmatched terms can be replaced by semantically related ones that have matching terms in the target ontology. User feedback could subsequently be used as a reward measure in a reinforcement learning algorithm. The reinforcement signal should be cumulated over a large number of interactions until either a new relation is derived between the new term in the application domain ontology and existing ones in the context ontology, or the need for a new term in the context ontology is signalized. This strategy, however, is not yet included in our present solution. Context Retrieval and Selection Techniques — Once requests and Context-Source descriptions can be expressed in terms of context ontology, and a similarity measure between these semantic constructs can be calculated, different information retrieval techniques can be applied for producing a raw set of candidate context-information elements. An overview on the basic technical background of information retrieval techniques can be found in [13]. Regardless of the retrieval technique, the selected context information will have a description whose similarity with the request is higher than a specified constant. If multiple instances of a certain Context-Source exist, a subsequent selection process should ensure that only one instance is returned. Generally, this selection process is based on some no-functional parameters, like quality of context-information (e.g., most accurate, reliable, or fresh context information). Note that the information retrieval paradigm is well suited for context-information retrieval as long as both the context request and ContextSource description are expressed in terms of the same ontology, or there is a mapping between their source ontologies, and the requesting application can tolerate limited recall and precision. Context Derivation and Estimation — Generally, the abstraction level and the semantic
71
VAN KRANENBURG LAYOUT
7/19/06
The contextual information originating from Context-Source components is provided to applications, services, and other Context-Sources via a uniform interface that hides the details of the underlying context-sensing and context-interpreting mechanisms.
10:33 AM
Page 72
richness of context information needed for adapting context-aware applications is much higher than that of context sensors. An example is “being inside” instead of “at position x,y.” Context derivation and estimation bridges this gap by combining raw context information in a way that is meaningful and useful for specific application domains. Context derivation and estimation is performed in our solution in two ways: • Based on high-level, predefined rules • Based on detection of regularities in context information and application behaviors Rule-based reasoning techniques are relatively easy to implement when context sources and application-adaptation parameters are expressed consistently. Abstract contextual information is obtained from elementary context data according to a set of rules defined for each application domain. For instance, a reasoner for tourist guide services would infer a person’s proximity to a certain hotel by subtracting his (device’s) GPS coordinates from those of the hotel. Obviously, complex rules, incorporating geographic information (like rivers and roads) and actual traffic information (like traffic jams) are required in realistic application scenarios. Regularities in context data can be detected through statistical analysis, clustering techniques, data mining, or unsupervised learning. Regardless of the actual technique used, all these processes require a relatively large data set collected from many (similar or just related) context sources over large periods of time. Statistically significant regularities can subsequently be embedded in additional rules. For instance, the tourist guide service could use statistics to detect correlations between the time of day and museum and restaurants requests. The latter one might peak around 6 PM, while the museum requests peak around 10 AM. This would allow an application designer to define a new rule for disambiguating certain user requests. In our framework we use an expert system (the OWL-DL reasoner, extendible with rule-based inference), a knowledge base (our office-environment and resources are modeled in an ontology), coupled via a Jena API to contextual data and JAVA-based application. An ontology is an explicit specification of concepts in a domain and their interrelations (e.g., parent and female are mother, the so-called T-box). Instance data are specific instances of the concepts (the so-called A-box). Concepts and instances together constitute the basis of semantic Web, and are used in our case for mobile communication services.
FUTURE DIRECTIONS Classically, intelligence in applications is handled in a reactive way. Context changes are tracked and notified to applications that behave accordingly. Examples of these are a simple contextaware reminder, event-driven notification services, and personalization based on learning mechanisms. True ubiquitous environments will enable services and applications to proactively anticipate context changes in the environment. This means that potentially relevant and imminent context changes are anticipated during a given activity and that related solutions are provided by the service or application at the right time. Activity mod-
72
eling and monitoring in combination with reasoning methods can be used to provide (prioritized) alternatives and to ensure that only the relevant triggers to services are generated.
IMPLEMENTATION The CMF approach enables processing and exchange of heterogeneous context information that pertains to various categories, is distributed over multiple administrative domains, and stems from different protocol layers. This section provides a high-level overview of two proof-of-concept prototypes. We first describe a generic CMF implementation designed for (interdomain) distributed settings and subsequently a specific CMF designed for managing interlayer context in mobile devices.
DISTRIBUTED CMF PROTOTYPES The contextual information originating from Context-Source components is provided to applications, services, and other Context-Sources via a uniform interface that hides the details of the underlying context-sensing and context-interpreting mechanisms. Context consumers can access this information by polling or by notification. In polling, the context information can be retrieved at any moment. Both Structured Query Language (SQL) queries and Resource Description Framework Query Language (RDQL) queries are supported in retrieving the contextual information. The notification interface is offered by the Context-Sources to provide context information via a publish/subscribe mechanism. Applications (or other Context-Sources) that are interested in certain changes of particular contextual information can register at a callback interface through which they are notified when an update of the context information occurs. Discovery of the appropriate Context-Source is facilitated by Context-Source descriptions stored in a registry. The registry specifies the entities that provide the different types of contextual information, along with a reference to the Context-Source interface. Next to the registry, a user-management system maintains part of the Context-Source description. Currently we implement an RPC over the IP protocol and make use of a key-based discovery of Context-Sources. This discovery method matches a set of keywords against the meta-data stored in the registry. Our ongoing work addresses more advanced contextaware discovery. The user-management system allows for associating end users with other entities, such as the set of devices he or she uses. This enables us to relate device identifiers to users and, as a consequence, to associate the device-specific context information with the user. Of course, this association of device context with the user is with some uncertainty. The CMF runs on devices of about 10 colleagues and (logged) contextual data can be queried in combination with the semantic descriptions in the ontology. The ontology deployed in our Context-Reasoner models an indoor office environment, distinguishing between classes for space (position), presence, resources, tasks, and persons. The information from the user-management system is coupled to
IEEE Communications Magazine • August 2006
VAN KRANENBURG LAYOUT
7/19/06
10:33 AM
Simple application
Page 73
Aware application
Even if an
Aware application influencing own communication context
application on a mobile device works
ctxt api
Network api
ctxt api
Network api
properly without
Network api
knowing about network resources, it
TCP
TCP
Adapt
MIP
CCP
IP
MIP
IP
Adapt
Adapt
CCP
CCA
TCP
benefits significantly when taking the
MIP
IP
network context into consideration. umts
uwb
umts
uwb
umts
uwb
We call the information about network resources
Network connection with other end point
■ Figure 5. Different types of mobile applications using network resources; depending on their needs, they use the Communication Context-Provider (CCP) and actuator (CCA) through the communication context API, which may be coupled to the network API (e.g., the Sockets API).
and associated communication resources communication context.
the person class in the ontology. The ontology assists in queries to find the current position and status of persons and resources, and their relative distance in our office environment. Thus, in this case our service platform support for reasoning benefits from semantic descriptions. Easily deployable applications include finding buddies and their current activity, selecting the most suitable devices for presentation, selecting the nearest and quickest printer for your print job, and so forth. Examples of contextual information supplied by our Context-Wrappers include: • Location coordinates via: –GPS receiver (in Symbian, Windows XP, and Windows Mobile environments) –WLAN access points associations (using SNMP) –RFID scan measurements –Bluetooth scan measurements for device discovery (in Symbian and Windows XP environments) –GSM cell ID (in Symbian environments) • Printer jobs via print server queue logging • Presence status via MSN (or Windows) Messenger • Calendar information via MS Outlook (in Windows XP and Windows Mobile environments) • Battery power level (in Windows XP and Windows Mobile environments) • Telephone usage (TAPI) • Active applications • Browse actions in Internet Explorer • Keyboard activity
INTERLAYER CMF PROTOTYPE As another example of Context-Sources, we discuss our work on providing applications running on mobile devices with information about available network resources [14]. In a mobile environment, these resources typically are highly dynamic, and therefore are of interest to those applications that need to generate network traf-
IEEE Communications Magazine • August 2006
fic. A mobile device may be equipped with multiple network interfaces that can simultaneously connect to a number of wireless networks — each with their own dynamic characteristics and technology specific settings. Thus, even if an application on a mobile device works properly without knowing about network resources, it benefits significantly when taking the network context into consideration. We call the information about network resources and associated communication resources communication context. Communication context consists of three different elements: • A description of the available network resources, including cross-layer information (e.g., link-layer characteristics such as maximum throughput and network-layer configurations such as the selection of the default route) • The state of (operating) system facilities, (e.g., indications of an upcoming network activation or deactivation) • The state of facilities available in the network infrastructure such as DNS servers and proxies The communication context is delivered to applications by the Communication Context Service (CCS): a system service running on the mobile host as a background process. It supplies both Context-Provider functionality and context actuator functionality. The application uses the actuator functionality to influence its own communication context, for example, by expressing interest to let the mobile host connect to certain wireless networks. Figure 5 shows how different types of applications interact with the CCS. An important aspect is the way communication context is offered to the applications: it must be at the right level so as to allow for balanced decisions about the usage of network resources without the burden of excessive details. Therefore, we have developed a resource model with different layers of abstraction: depending on the needs of the application, it may choose a
73
VAN KRANENBURG LAYOUT
7/19/06
Our framework benefits from the reasoning methods of semantic descriptions and matching techniques. Access and exchange of context information are, in our framework, the prime function of the Context-Provider. Federation of context providers in multiple administrative domains will be the topic of our future studies.
10:33 AM
Page 74
high level of abstraction or use more detailed information. This model is domain specific, that is, it is used to describe cross-layer network stack characteristics. Based on the CCS, we have designed a context-aware network activation strategy for mobile devices with multiple heterogeneous network interfaces. This strategy aims at optimum use of the complementary features of the underlying networks based on the device-operation context. A key context parameter for the strategy is the remaining battery energy. The strategy governs the CCA for activating the most appropriate network interface for a given data flow. An outline of the strategy and a study on energy consumption behavior of two network interface types are described in [14].
CONCLUSION AND FUTURE WORK Context awareness is being used by many applications to adapt service behavior accordingly. Rightfully interpreting that information, however, is as yet a huge challenge due to missing, superfluous, or even contradicting context information. Hence, additional context sources and context quality parameters need to be taken into account to make more appropriate selections, fitting to the services’ needs. In dealing with the various heterogeneous contextual and knowledge sources, we use a generic CMF approach that enables processing and exchange of the context information distributed in context domains, over administrative domains, and in protocol layers. The peer-topeer architecture is scalable. New context sources, sensors, and reasoners (with different reasoning methods) can easily be added. The contextual information originating from any of the Context-Sources is provided to applications, services, and other Context-Source’s via a uniform interface, which hides the details of the underlying context-sensing and context-interpreting mechanisms. Our framework benefits from the reasoning methods of semantic descriptions and matching techniques. Access and exchange of context information are, in our framework, the prime function of the Context-Provider. Federation of context providers in multiple administrative domains will be the topic of our future studies.
ACKNOWLEDGMENT This work is part of the Freeband AWARENESS project (http://awareness.freeband.nl). Freeband is sponsored by the Dutch government under contract BSIK 03025.
REFERENCES [1] WWRF Book of Visions BoV, http://www.wireless-worldresearch.org/general_information/book_of_visions.php [2] K. Ducatel et al., Advisory Group to the European Community’s Information Society Technology Programme (ISTAG), “Scenarios for Ambient Intelligence in 2010,” Feb. 2001. [3] A. K. D. Dey and G. D. Abowd, “Towards a Better Understanding of Context and Context Awareness,” Wksp. What, Who, Where, When, and How of Context Awareness, affiliated with the 2000 ACM Conf. Human Factors in Computer Systems (CHI 2000), The Hague, Netherlands, Apr. 2000.
74
[4] S. A. Xynogalas et al., “Context Management for the Provision of Adaptive Services to Roaming Users,” IEEE Wireless Commun., Apr. 2004, pp. 40–47. [5] D. Saha and A. Mukherjee, “Pervasive Computing: A Paradigm for the 21st Century,” IEEE Computer Society, Mar. 2003, pp. 25–31. [6] K. Henricksen et al., “Middleware for Distributed Context-Aware Systems,” Proc. DOA 2005, LNCS 3760, 2005, pp. 846–63. [7] M. Roman et al., “GAIA: A Middleware Infrastructure to Enable Active Spaces,” IEEE Pervasive Computing, vol. 1, no. 4, 2002, pp. 74–83. [8] F. L. Gandon and N. M. Sadeh, “Semantic Web Technologies to Reconcile Privacy and Context Awareness,” Computer Science Technical Report CMU-ISRI-03-107, Dec. 2003. [9] H. Lei et al., “The Design and Applications of a Context Service,” Mobile Computing and Commun. Rev., vol. 6, no. 4, pp. 45–55. [10] H. van Kranenburg and H. Eertink, “Processing Heterogeneous Context Sources,” Proc. SAINT 2005, Next Generation IP-based Service Platforms for Future Mobile Systems Wksp, Trento, Italy, 2005, pp. 140–43. [11] X. H. Wang et al., “Ontology-Based Context Modeling and Reasoning using OWL,” Proc. 2nd IEEE Annual Conf. Pervasive Computing and Communications Wksps. (PERCOMW’04), 2004. [12] H. Wache et al., “Ontology-based Integration of Information: A Survey of Existing Approaches,” Proc. IJCAI, Aug. 2001. [13] M. Mitra and B. B. Chaudhuri, “Information Retrieval from Documents: A Survey,” Information Retrieval 2, 2000, pp. 141–63. [14] A. Peddemors, H. Eertink, and I. Niemegeers, “Communication Context for Adaptive Mobile Applications,” Wksp. Proc. 3rd Conf. Pervasive Computing — Middleware Support for Pervasive Computing Wksp. (PerWare’05), Mar. 2005.
BIOGRAPHIES H ERMA VAN K RANENBERG (
[email protected]) received an M.Sc. degree in 1988 and a Ph.D. degree in 1992, both in electrical engineering. She is a senior member of scientific staff at Telematica Instituut with research and management experience in several projects in the field of content engineering, mobile services, and middleware for heterogeneous IP-based mobile environments. She is active in WWRF in the area of ambient awareness and personalization and a member of several program committees of international conferences, and regularly publishes papers on both scientific and technical popular levels. Her present research interests are in the area of context awareness, application-layer mobility support, and tailoring of nextgeneration mobile services in a multi-access environment. M ORTAZA S. B ARGH (
[email protected]) received an M.Sc. degree in 1995 and a Ph.D. degree in 1999, both in electrical engineering, from Eindhoven University of Technology, the Netherlands. Since 1999 he has been a member of scientific staff at Telematica Instituut, where he is involved in many projects concerning mobile networks, services, and applications. His research interests are in the area of pervasive communication and security, where he currently focuses on mobility management protocols and algorithms for secure and seamless handovers. To this end, he is particularly interested in applying information theory methods for event prediction and machine learning. S ORIN M A R C E L I ACOB (
[email protected]) received a Dipl.Eng. degree in electronics and telecommunications in 1991 from TU Cluj-Napoca, Romania, and a Ph.D. degree in computer science and engineering in 1998 from Polytechnic University of Bucharest. He has held different teaching and research positions at TU Cluj-Napoca and TU Delft. He is currently a member of scientific staff at Telematica Instituut. His main research experience and interests include multimedia content analysis, context-aware and autonomous systems, and service-oriented architectures. ARJAN PEDDEMORS (
[email protected]) is a research engineer at Telematica Instituut. His interests are in the area of mobile and pervasive computing, with a specific focus on mobility management and network resource awareness for mobile applications. He is currently working toward his Ph.D.
IEEE Communications Magazine • August 2006
