Documents
Resources
Learning Center
Upload
Plans & pricing Sign in
Sign Out

Requirements and concepts for context casting service enablers .pdf

VIEWS: 3 PAGES: 49

									 Project Number:                                                            ICT-2007-216462

 Project Title:                                                                       C-CAST

 CEC Deliverable Number:                                                 216462/TILab/DS/D6

 Contractual Date of Delivery to CEC:                                           October 2008

 Actual Date of Delivery to CEC:                                              November 2008

 Title of Deliverable:                         Requirements and concepts for context casting
                                                  service enablers and context management
 WP contributing to the Deliverable:                                                   WP3

 Nature of the Deliverable:                                                                 R

 Deliverable Security Class:                                                               PU

 Editors:                                                                    Boris Moltchanov




Abstract:
This is the first WP3 deliverable and describes the terminology, research objectives, system-
level requirements and draft concepts of the research activities identified within WP3. Building
upon the state of the art research and the identified system-level requirements, a WP3 refer-
ence architecture is proposed. The architecture support complete context management func-
tionality along with service components like group management and content selection. Initial
concepts for inter-component interaction are also presented. The architecture will evolve and
mature as a result of research conducted within the project. Draft concepts for group manage-
ment, content selection and reasoning research activities are presented in the document. These
concepts will evolve into technical specifications.




Keywords:
context, context-aware, context-awareness, context management, context management system,
context management architecture, management, architecture, system, definition, group, group
formation, group management, reasoning, reasoner
                                    Deliverable D6
    216462                                                                           C-CAST
                  Requirements and concepts for context casting service
                          enablers and context management



                                 Executive Summary

The WP3 of the project "Context Casting Service Enablers & Context Management" is aimed to
research, design and develop context and group management service enablers to support con-
text casting applications and services and thereby to contribute to the evolution of mobile multi-
cast context aware services. Work within this package will also contribute to developing a pro-
ject wide holistic model of interaction combining context aware framework, context enablers and
context brokering mechanisms, group management framework and service activation models
specifically for mobile multimedia broadcast.
This document describes the state of the art in the field of context awareness, specifically con-
text management, representation, modelling, reasoning paradigms, group management and
content selection models. Research objectives for WP3 are identified and the work plan for the
duration of the C-CAST project is elaborated by grouping the objectives according to the WP3
activities structure. The objectives fall under the research areas of context management and
representation, context dissemination, representation, adaptation, group management and con-
text selection.
All the requirements that shall be addressed and supported by the context management sys-
tem, group management and content selection components designed within the C-CAST project
are listed in two categories: 1) functional requirements, describing operations that the Context
Management System (CMS) shall support and 2) technical requirements for the CMS platforms
addressing particular issues such as performance, reliability, type of connections and protocols,
interoperating with other platforms and systems, etc. Requirements have been identified based
on expected challenges and technical activities mentioned in Technical Annex to the project
[28].
Building on the existing literature, research objectives and the system-level requirements, a
Context Management Architecture (CMA) is proposed that forms the foundation for a complete
WP3 architecture. Draft concepts relating to the research objectives, in light of the system re-
quirements are also discussed.




CONTEXT CASTING                                                                            Page   ii
                                           Deliverable D6
     216462                                                                                                     C-CAST
                         Requirements and concepts for context casting service
                                 enablers and context management



                                             List of Contributors

        Name                            Company                         Address                    Phone/Fax/E-mail
    Boris Moltchanov              Telecom Italia Lab                    Turin, Italy                    +39 011 228 7094
                                                                                               boris.moltchanov@telecomitalia.it
  Michael Knappmeyer      University of Applied Sciences Os-     Faculty of Engineering and             +49 541 969-3453
                                        nabrück                 Computer Science, P.O. Box             +49 541 969-13453
                                                               1940, 49009 Osnabrück, Ger- m.knappmeyer@fh-osnabrueck.de
                                                                            many
      Madiha Zafar         University of the West of England    CCCS, CEMS, UWE, Bristol,           Tel : (+44) 787 7590992
                                                                       UK BS16 1QY                  Fax: (+44) 117 3282734
                                                                                                   madiha2.zafar@uwe.ac.uk
      Nigel Baker          University of the West of England    CCCS, CEMS, UWE, Bristol,            Tel : (+44) 7798742857
                                                                       UK BS16 1QY                  Fax: (+44) 117 3282734
                                                                                                     nigel.baker@uwe.ac.uk
      Ahsan Ikram          University of the West of England    CCCS, CEMS, UWE, Bristol,            Tel : (+44) 7878807027
                                                                       UK BS16 1QY                  Fax: (+44) 117 3282734
                                                                                                    ahsan.ikram@uwe.ac.uk
      Saad Liaquat         University of the West of England    CCCS, CEMS, UWE, Bristol,            Tel : (+44) 7912352230
                                                                       UK BS16 1QY                  Fax: (+44) 117 3282734
                                                                                                   saad2.liaquat@uwe.ac.uk
  Christian Mannweiler        University of Kaiserslautern     Department of Electrical Engi- Tel.: +49 (0)631 205 2702
                                                               neering and Information Tech- Fax: +49 (0)631 205 4151
                                                               nology, Paul-Ehrlich-Straße – E-Mail: mannweiler@eit.uni-kl.de
                                                               Building 11, 67663 Kaiserslau-
                                                                             tern
    João Gonçalves                    Portugal Telecom                PT Inovação S.A.                   +351 234377900
                                                                    Rua José F. P. Basto               jmgonc@gmail.com
                                                                     3810-106 AVEIRO           joao-m-goncalves@ptinovacao.pt
                                                                          Portugal
  André Zimmermann                    Portugal Telecom                PT Inovação S.A.                   +351 234377900
                                                                    Rua José F. P. Basto               spanfer@gmail.com
                                                                     3810-106 AVEIRO
                                                                          Portugal
   Jordi Jaen Pallares       Fraunhofer-Gesellschaft zur              Berlin, Germany                    +49 3034637137
                             Förderung der angewandten                                        jordi.jaen.pallares@fokus.fraunhof
                                   Forschung e.V.                                                              er.de

    Claudio Venezia*                   Telecom Italia                   Turin, Italy                  +39 011 228 8075
                                                                                               claudio.venezia@telecomitalia.it
   Peter Bloodsworth*     University of the West of England     UWE, Bristol, UK BS16 1QY      Peter2.Bloodsworth@uwe.ac.uk
 Clemens Westerkamp*      University of Applied Sciences Os-     Faculty of Engineering and           +49 541/969-3649
                                        nabrück                Computer Science, P.O. Box               cwe@fhos.de
                                                               1940, 49009 Osnabrück, Ger-
                                                                            many
*External Quality Control Reviewers




CONTEXT CASTING                                                                                                         Page   iii
                                                 Deliverable D6
        216462                                                                                                                           C-CAST
                               Requirements and concepts for context casting service
                                       enablers and context management



                                                         Table of Contents
EXECUTIVE SUMMARY.............................................................................................................................. II

LIST OF CONTRIBUTORS ......................................................................................................................... III

TABLE OF CONTENTS .............................................................................................................................. IV

LIST OF FIGURES ...................................................................................................................................... VI

LIST OF TABLES ....................................................................................................................................... VI

LIST OF ACRONYMS ................................................................................................................................ VII

1.      INTRODUCTION ................................................................................................................................... 1

2.      STATE OF THE ART AND RELATED RESEARCH ............................................................................ 3
     2.1    DEFINITIONS AND TERMINOLOGY ....................................................................................................... 3
     2.2    CONTEXT-AWARE SYSTEMS.............................................................................................................. 4
       2.2.1    Context Management ............................................................................................................. 6
       2.2.2    Context Representation .......................................................................................................... 7
       2.2.3    Context-Meta Information ....................................................................................................... 8
       2.2.4    Context Querying .................................................................................................................... 8
       2.2.5    Context Reasoning/Inference ................................................................................................. 9
     2.3    GROUP AND COMMUNITY MANAGEMENT .......................................................................................... 10
     2.4    CONTEXT-AWARE CONTENT SELECTION.......................................................................................... 11
3.      WP3 RESEARCH OBJECTIVES ....................................................................................................... 12
     3.1    CONTEXT MANAGEMENT ARCHITECTURE AND REPRESENTATION ...................................................... 12
       3.1.1   Context Management Architecture and Federation .............................................................. 12
       3.1.2   Distribution/Diffusion of Context ........................................................................................... 12
       3.1.3   Context Representation Model ............................................................................................. 13
       3.1.4   Context Based Adaptation .................................................................................................... 14
     3.2    GROUP-AWARENESS ...................................................................................................................... 15
       3.2.1   Group Recognition ................................................................................................................ 15
       3.2.2   Group Management .............................................................................................................. 16
     3.3    CONTENT SELECTION ..................................................................................................................... 16
     3.4    REASONING AND INFERENCE ........................................................................................................... 17
4.      SYSTEM LEVEL REQUIREMENTS ................................................................................................... 19
     4.1      CONTEXT MANAGEMENT AND REASONING ....................................................................................... 19
     4.2      GROUP MANAGEMENT .................................................................................................................... 19
     4.3      CONTEXT-AWARE CONTENT SELECTION.......................................................................................... 20
5.      CONTEXT MANAGEMENT ARCHITECTURE CONCEPT ................................................................ 21
     5.1    OVERVIEW ..................................................................................................................................... 21
     5.2    LOGICAL ARCHITECTURE DEFINITION AND CONTEXT REPRESENTATION............................................. 21
       5.2.1    Context Acquisition (CA) ....................................................................................................... 21
       5.2.2    Context Entity Directory and Exchange (CEDE) .................................................................. 22
       5.2.3    Context Consumer (CC) ....................................................................................................... 22
       5.2.4    Service Component .............................................................................................................. 22
       5.2.5    Context Representation ........................................................................................................ 23
       5.2.6    Logical Architecture Breakdown ........................................................................................... 23
     5.3    FUNCTIONAL ENTITIES BREAKDOWN ................................................................................................ 23



CONTEXT CASTING                                                                                                                                   Page    iv
                                                Deliverable D6
        216462                                                                                                                        C-CAST
                              Requirements and concepts for context casting service
                                      enablers and context management

       5.3.1   Context Consumer (CC) ....................................................................................................... 24
       5.3.2   CEDE and Context Broker (CB) ........................................................................................... 24
       5.3.3   CA and Context Provider ...................................................................................................... 25
       5.3.4   Service Component and Service Enabler (SE) .................................................................... 27
     5.4    WP3 FUNCTIONAL ARCHITECTURE .................................................................................................. 27
       5.4.1   Components Relationships ................................................................................................... 29
6.      DRAFT CONCEPTS ........................................................................................................................... 30
     6.1    GROUP MANAGEMENT .................................................................................................................... 30
       6.1.1   Group Recognition Context Providers .................................................................................. 30
       6.1.2   Group Management Service Enabler ................................................................................... 31
     6.2    CONTEXT-AWARE CONTENT SELECTION.......................................................................................... 32
     6.3    CONTEXT REASONING AND INTERPRETATION ................................................................................... 33
7.      CONCLUSION .................................................................................................................................... 35

REFERENCES ........................................................................................................................................... 37




CONTEXT CASTING                                                                                                                                 Page    v
                                              Deliverable D6
      216462                                                                                                                     C-CAST
                            Requirements and concepts for context casting service
                                    enablers and context management



                                                        List of Figures
Figure 1-1: WP3 Functional Breakdown ....................................................................................................... 1
Figure 2-1: Examples of layered Reasoning (Korpipää, 2003; Minsky, 2000; Van Laerhoven, 2000) ...... 10
Figure 3-1: Context Awareness Lifecycle Overview ................................................................................... 14
Figure 3-2: Context Provider Dependencies .............................................................................................. 17
Figure 3-3: Knowledge-based Context Detection Control .......................................................................... 18
Figure 5-1: Context Management Logical Architecture .............................................................................. 23
Figure 5-2: Overall Context Management (Functional) Architecture and Entities ...................................... 28
Figure 5-3: CMA relationships .................................................................................................................... 29
Figure 5-4: Context Reasoning as a part of CA (attached to CP shown in Figure 5-3) ............................. 29
Figure 6-1: Context Provider Model ........................................................................................................... 30
Figure 6-2: Implementing Context and Enabler Functions ......................................................................... 31
Figure 6-3: CACSE interfaces and functional dependencies ..................................................................... 32
Figure 6-4: Layered Context Inference Process ........................................................................................ 34
Figure 6-5: Context Inference inside Context Provider .............................................................................. 34




                                                          List of Tables
Table 5-1: Context Consumer Requirements ............................................................................................. 24
Table 5-2: Context Broker Requirements ................................................................................................... 25
Table 5-3: Context Provider Requirements ................................................................................................ 27
Table 5-4: Service Enabler Requirements ................................................................................................. 27




CONTEXT CASTING                                                                                                                            Page   vi
                                    Deliverable D6
   216462                                                                           C-CAST
                  Requirements and concepts for context casting service
                          enablers and context management



                                  List of Acronyms

   CA               Context Acquisition
   CACSE            Context-Aware Content Selection Enabler
   CASS             Context-Awareness Sub-Structure
   CB               Context Broker
   CC               Context Consumer
   C-CAST           Context Casting
   CC/PP            Composite Capabilities/Preference Profile
   CDE              Context Detection Environment
   CEDE             Context Entity Directory and Exchange
   CIBB             Context Inference Building Block
   CM               Context Management
   CMA              Context Management Architecture
   CMS              Context Management System
   CoBrA            Context Broker Architecture
   ContextML        Context Meta Language
   CORTEX           CO-operating Real-time senTient objects
   CP               Context Provider
   CR               Context Reasoner
   CS               Content Selection
   D10              Deliverable 10
   ER               Entity Relationship
   GM               Group Management
   GPS              Global Positioning System
   ICT              Information and Communication Technologies
   MBMS             Multimedia Broadcast and Multicast Services
   NGN              Next Generation Networks
   OPUCE            Open Platform for User-centric service Creation and Execution
   ORM              Object-Role Modelling
   OWL              Web Ontology Language
   P2P              Peer-to-Peer
   RDF              Resource Description Framework
   RDF-S            Resource Description Framework-Schema
   SE               Service Enabler
   SCE              Service Creation Environment
   SOCAM            Service-Oriented Context-Aware Middleware
   SPARQL           Simple Protocol and RDF Query Language
   SPICE            Service Platform for Innovative Communication Environment
   SQL              Structured Query Language
   UML              Unified Modelling Language
   W3C              World Wide Web Consortium
   WP               Work Package
   XML              Extendible Markup Language




CONTEXT CASTING                                                                        Page   vii
                                     Deliverable D6
    216462                                                                                                                              C-CAST
                   Requirements and concepts for context casting service
                           enablers and context management


1. Introduction
The main objective of Context Casting (C-CAST) project is to evolve mobile multimedia multi-
casting to exploit the increasing integration of mobile devices with our everyday physical world
and environment [28]. C-CAST will provide an end-to-end context-aware communication
framework specifically for intelligent multicast-broadcast services. The framework has two fac-
ets; first one is context acquisition, management and distribution, the other equally significant is
the service (or content) transport and delivery. These two facets are tied together by service
enablers and adaptation functions.
The Context Casting Service Enablers & Context Management Work Package (WP3) is aimed
to research, design and propose a „context management architecture‟ and develop „service en-
ablers‟ (group management and content selection) to support context casting applications and
services over multi-party transport system and thereby contribute to the evolution of mobile mul-
ticast context aware services.

                                             WP5: Content Casting

              WP3:                            Service
              Context Casting
                                                                              Adaptation




                                              Enablers                                        Group Management
              Service Enablers &
              Context                                                                          Content Selection
              Management

                 Context Management                                                        Reasoning
                                                     Context Representation




                      Context Distribution                                                    Group Recognition
                                                                                                                     Reasoning Model/
                                                                                                                          Rules



                       Context Storage                                                       Situation Recognition


                      Context Acquisition                                                      Other Reasoners


                                     Context Management Architecture


                 WP4: Context Detection and Context-Aware Multiparty Transport


                               Figure 1-1: WP3 Functional Breakdown
The WP3 functional layout and interface with technical C-CAST work packages is illustrated in
Figure 1-1. Multiple functions illustrated in the Figure 1-1 can be mapped to the research activi-
ties allocated with WP3. The three research activities are the following:
       Activity 3.1: Context Representation and Management;
       Activity 3.2: Group and Community Management;
       Activity 3.3: Context Reasoning and Interpretation.
The development of context aware systems is a complex task because of the need to accom-
modate for a vast variety of context types and their values, including the ones that cannot be
anticipated at the time when the system is designed. The approach adopted by WP3 is to de-
sign a context infrastructure which is flexible and extensible. An initial context management ar-


CONTEXT CASTING                                                                                                                             Page   1
                                     Deliverable D6
    216462                                                                               C-CAST
                   Requirements and concepts for context casting service
                           enablers and context management

chitecture proposal is presented in this deliverable. The architecture will evolve as the work pro-
gress within WP3. Just as one of the key objectives in the mobile communications industry is to
provide innovative services and applications; WP3 also adopts a service driven approach where
services and their composition will be the driver for context awareness. The service logic is
maintained as service enablers and the focus is on group services. In order to support context-
aware group service delivery, two key service enablers, group management and content selec-
tion, are crucial. It should be however noted that additional service enablers will be required for
a complete end-to-end system, but falls out of the project‟s scope. In addition, context aware
applications by definition must be adaptable which means they must change behaviour in some
strategic or “intelligent” way according to fulfil some plan or goal. This is very application specific
but does need support from the hosting architecture. Part of this work involves investigating and
developing the most promising reasoning and aggregation mechanisms. WP3 will also contrib-
ute to developing a project wide holistic model of interaction combining context aware frame-
work, service enablers and brokering mechanisms and service activation models specifically for
mobile multimedia broadcast.
The deliverable intends to identify and present the detailed research objectives addressed in the
scope of WP3 and C-CAST. The research will be driven by key system-level requirement defini-
tion. Section 2 presents a brief overview of related research activities in the field of context-
aware mobile communication systems and frameworks. Section 3 presents the research objec-
tives identified within the WP and forms the foundation for the system-level requirements as
discussed in section 4. Section 5 explains the concept and initial proposal of the context man-
agement framework and WP3 architecture. Draft concepts for group management, content
matching and reasoning are presented in sections 6. The document is finally summarised and
concluded in section 7.




CONTEXT CASTING                                                                                 Page   2
                                     Deliverable D6
      216462                                                                           C-CAST
                   Requirements and concepts for context casting service
                           enablers and context management


2. State of the Art and Related Research

2.1     Definitions and Terminology
This section introduces relevant terminology which is important for providing a common under-
standing on the basis of existing definitions taken from literature review.


Context
Ryan et al. [44] referred to context as the user‟s location, environment, identity and time. Dey
[45] defines context as the user‟s emotional state, focus of attention, location and orientation,
date and time, as well as objects and people in the user‟s environment. Another common way of
defining context was the use of synonyms. Hull et al. [46] describe context as the aspects of the
current situation. These kinds of definitions are often too wide. However, a good one can be
found in Brown [47]. Brown defines context to be the elements of the user‟s environment which
the computer knows about. One of the most accurate definitions is given by Dey and Abowd
[48]. These authors refer to context as “any information that can be used to characterize the
situation of entities (i.e., whether a person, place or object) that are considered relevant to the
interaction between a user and an application, including the user and the application them-
selves.” Zimmermann [27] proposes five fundamental categories of context information: time,
location, activity, relations, and individuality.
In the scope of C-CAST Dey's and Abowd's definition will be used. Hence, the envisaged con-
text management system will be designed for supporting a large variety of multimodal contex-
tual information, incl. network context, primitive physical context (e.g. Global Positioning System
(GPS) coordinates and environment characteristics), user/group preferences, user/group activi-
ties and situations, user/group goals, content meta data, and device capabilities. This incom-
plete list illustrates the need for a generic and extendible context management system, support-
ing evolving context models, evolving application and usage scenarios.


Situation
Regarding the definition of a situation in context-aware systems, different views exist in the re-
search community. Zimmermann [27] defines it as “the state of a context at a certain point (or
region) in space at a certain point (or interval) in time, identified by a name”. Being a structured
representation of a part of the context it can be compared to a snapshot taken by a camera. Lo-
cation and time can be used as spatio-temporal coordinates.
Henricksen presents a logical and arithmetical model based on object relations [12]. Giunchiglia
follows a more philosophical approach and sees context as a “subset of the complete state of
an individual that is used for reasoning about a given goal” [12]. Situation is then “the complete
state of the universe at an instant of time”. In conclusion, a situation may comprise an infinite
variety of contextual information.

C-CAST will concentrate on Henricksen's and Zimmermann's definitions without ignoring the
other ones available in literature.




Reasoning and Inference


CONTEXT CASTING                                                                              Page   3
                                    Deliverable D6
      216462                                                                          C-CAST
                  Requirements and concepts for context casting service
                          enablers and context management

In the scope of the proposed research, reasoning and inference refer to the sub-processes of
context discovery, generation and abstraction of usable context information by means of fusion
and inference. Reasoning is a cognitive process for deriving high-level contextual information
from lower level context information or raw data (e.g. databases or sensor output).
Reasoning and inference has a wide scope, for example, it can be used to identify user‟s physi-
cal movement, possible intention based on history and calendar, etc. The subsequent sections
will further elaborate methodology adopted by/within C-CAST.


Group
A unit consisting of a number of users or devices bounded with each other with respect to some
common properties. The common properties can be referred to as user and/or device context
information. The context information can be either low-level or high-level i.e. reasoned, for ex-
ample users with common activity.
A precise group definition and classification, as considered within C-CAST, is given in subse-
quent sections.


Service Enabler
A service enabler is a component which performs a set of generic functions via well-defined in-
terfaces. The underlying technology is hidden behind these components and allows rapid de-
velopment of application.


Content
The content considered within C-CAST project might be multimedia data such as text, audio,
video or their combination, which has certain value for the user that the user is able to pay for,
creating value for service provider. The Content Provider is a logical entity providing the content
on itself or on behalf of content creators.


Context Dissemination/Diffusion
Context dissemination and context diffusion both describe the process through which context is
distributed and shared along multiple context-providing and context-consuming entities with the
help of the context management system.



2.2     Context-Aware Systems
In literature the term context-aware appeared in [43] for the first time. There the authors de-
scribed context as location, identities of nearby people, objects and changes to those objects
[25]. Such enumerations of context examples were often used in the beginning of context-aware
systems research. The history of context-aware systems started when Want et al. [39] intro-
duced the Active Badge Location System, which is considered to be one of the first context-
aware applications. The infrared technology based system was able to determine a user‟s cur-
rent location and used to forward phone calls to a telephone close to the user. In the middle of
the 1990s, a couple of location-aware tour guides [40], [41], [42] emerged. While location infor-
mation is by far the most frequently used type of context, attempts to use other context informa-
tion as well have grown over the last few years. Hence, it is a challenging task to define the


CONTEXT CASTING                                                                             Page   4
                                     Deliverable D6
    216462                                                                              C-CAST
                   Requirements and concepts for context casting service
                           enablers and context management

word „context‟ and many researchers tried to find their own definition for what context actually
includes.
One popular way to classify context instances is the distinction of different context dimensions.
Prekop and Burnett [49] and Gustavsen [50] call these dimensions external and internal, and
Hofer et al. [51] refer to it as physical and logical context. The external (physical) dimension re-
fers to context that can be measured by hardware sensors, i.e., location, light, sound, move-
ment, touch, temperature or air pressure, whereas the internal (logical) dimension is mostly
specified by the user or captured by monitoring and inferring user interactions, i.e., the user‟s
goals, tasks, work context, business processes, the user‟s emotional state. Most context-aware
systems make use of external context factors as they provide useful data, such as location in-
formation. Furthermore, external attributes are easy to sense by using off-the-shelf sensing
technologies. Most of the existing context aware systems apply physical context information
[23]. Examples for the use of logical data are the Watson Project (Budzik and Hammond, [52])
and the IntelliZap Project (Finkelstein et al., [53]) which support the user by providing relevant
information based on the content read out of opened web pages, documents, etc.

Context-aware systems can be implemented in many ways. The approach depends on special
requirements and conditions such as the deployment of sensors (local or remote), the amount
of possible users (one user or many), the available resources of the used devices (high-end-
personal computers or small mobile devices) or the facility of a further extension of the system
[9] [10]. Ailisto et al., [55] and Dey and Abowd [56] proposed a layered conceptual architecture
that augments layers for detecting and using context by adding interpreting and reasoning func-
tionality. Context-aware systems dealing with location information are widespread and the de-
mand for them is growing due to the increasing market penetration of location-aware (for exam-
ple, GPS enabled) mobile devices.

In middleware based systems, the Service-Oriented Context-Aware Middleware (SOCAM) pro-
ject introduced [58] an architecture for the building and the rapid prototyping of context-aware
mobile services. It uses a central server as well, here called context interpreter, which gains
context data through distributed context providers and offers it in mostly processed form to the
clients. One further extensible centralised middleware approach designed for context-aware
mobile applications is a project called Context-Awareness Sub-Structure (CASS) presented in
[59]. The Context Toolkit [60], another context-aware framework, takes a step towards a peer-
to-peer architecture but it still needs a centralised discoverer where distributed sensor units
(called widgets), interpreters and aggregators are registered in order to be found by client appli-
cations. The CORTEX system is an example for a context-aware middleware solution. The ar-
chitecture is based on the Sentient Object Model [61], designed for the development of context-
aware applications in an ad-hoc mobile environment. Similarly an application prototype tool is
discussed in [22].

Many EU projects have explored context-awareness aspects, specially focusing on context cap-
turing and context reasoning; however some important functionalities have not yet been investi-
gated. Among the main systems and projects cited in the literature, this work is particularly re-
lated to MobiLife [29], SPICE [30], and OPUCE [31]. Integration of context aware systems with
mobile multimedia delivery technologies is explored in [32]. The numerous platforms and solu-
tions described in the literature, fail to offer a flexible, generic solution and service and delivery
integration with context management continues to be a challenging research area.

It is evident from the literature survey that there is not shortage of experiments in the domain of
context aware systems, but even with nearly two decades of research behind it, context aware-
ness has still not stepped out of the laboratory into the real world. One of the main reasons was
lack of end user devices that could „carry‟ the context aware applications for the users. With the
wide scale availability of these devices, it is now possible to harness the promise of context


CONTEXT CASTING                                                                                Page   5
                                     Deliverable D6
    216462                                                                             C-CAST
                   Requirements and concepts for context casting service
                           enablers and context management

awareness.

2.2.1   Context Management
Although in context-aware system, domain knowledge is very much tied to the application, how-
ever building context aware applications from scratch is not practical. Therefore one of the aims
of any context management architecture is to decouple context from application, to enable re-
use and support for many applications [16]. In general, context management deals with
        Context acquisition as a mechanism to obtain context from diverse sources;
        Context fusion for merging correlated contextual information;
        Context discovery as a mechanism to locate and access context sources;
        Context diffusion/dissemination for efficiently propagating the context while ensuring
        availability and reliability.
A separation of detecting/acquiring and using/managing context is necessary to improve exten-
sibility and reusability of systems. The method of context-data acquisition is very important
when designing context-aware systems because it predefines the architectural style of the sys-
tem at least to some extent. Chen [54] presents three following different approaches on how to
acquire contextual information:
        Direct sensor access: This approach is often used in devices with sensors locally built in.
        The client software gathers the desired information directly from these sensors, i.e.,
        there is no additional layer for gaining and processing sensor data. Drivers for the sen-
        sors are hardwired into the application, so this tightly coupled method is usable only in
        rare cases. Therefore, it is not suited for distributed systems due to its direct access na-
        ture which lacks a component capable of managing multiple concurrent sensor ac-
        cesses;

        Middleware infrastructure: Modern software design uses methods of encapsulation to
        separate e.g., business logic and graphical user interfaces. The middleware based ap-
        proach introduces a layered architecture to context-aware systems with the intention of
        hiding low-level sensing details. Compared to direct sensor access this technique eases
        extensibility since the client code has not be modified anymore and it simplifies the reus-
        ability of hardware dependent sensing code due to the strict encapsulation;

        Context server: The next logical step is to permit multiple clients access to remote data
        sources. This distributed approach extends the middleware based architecture by intro-
        ducing an access managing remote component. Gathering sensor data is moved to this
        so-called context server to facilitate concurrent multiple access. Besides the reuse of
        sensors, the usage of a context server has the advantage of relieving clients of resource
        intensive operations. As probably the majority of end devices used in context-aware sys-
        tems are mobile gadgets with limitations in computation power, disk space etc., this is an
        important aspect. In return one has to consider about appropriate protocols, network per-
        formance, quality of service parameters etc., when designing a context-aware system
        based on client-server architecture.

Moreover, three basic context management models are known [26]:
   1. Widgets are derived from GUI elements and provide a public interface for a hardware
      sensor [7]. They hide low-level sensing details and allow for a reusable and easy appli-
      cation development. They are often controlled by a widget manager. Though increasing
      efficiency, they are not robust to component failures;



CONTEXT CASTING                                                                              Page   6
                                    Deliverable D6
    216462                                                                           C-CAST
                  Requirements and concepts for context casting service
                          enablers and context management

   2. The networked service model is more flexible and resembles the context server architec-
      ture. Discovery techniques are used to find networked services, resulting in lower effi-
      ciency compared to the widget approach. However, robustness is increased;

   3. The blackboard model represents a data-centric view. By means of asynchronous com-
      munication shared media is posted to the blackboard and be forwarded based on event
      subscription. Addition of new context sources is simplified whereas communication effi-
      ciency decreases.

Building upon the context acquisition and context management models discussed in literature, a
broker-based architecture is a viable option. It is rooted in middleware technology that manages
communication and data exchange between processes, objects or entities. Chen [6] [91] pre-
sents a FIPA specified Context Broker Architecture (CoBrA), which is an agent based architec-
ture for supporting context-aware systems in smart spaces [4] (e.g., intelligent meeting rooms,
smart homes, and smart vehicles). Central to this architecture is an intelligent agent called Con-
text Broker (CB) that maintains a shared model of context on the behalf of a community of
agents, services, and devices in the space and provides privacy protections for the users in the
space by enforcing the policy rules that they define. Other well-known examples for CB-based
approaches are the SOUPA, and GAIA [84].


2.2.2   Context Representation
The context information needs to be represented and modelled for being machine interpretable
and exchangeable using well-defined interfaces. The goals are to support easy manipulation,
i.e. low overhead in keeping the model up-to-date, easy extension, i.e. cheap and simple
mechanism for adding new types of information, efficient search and query access and scalabil-
ity In literature different approaches for representing contextual knowledge and semantic infor-
mation can be found. On the one hand the representation is tightly coupled to the inference
mechanism, e.g. probabilistic logic requires the modelling of probabilities. On the other hand the
representation is often tailored to the problem domain and to the specific goal of the system.
Strang and Linnhoff-Popien [68] identify generic requirements: The modelling approach should
(1) be able to cope with high dynamics and distributed processing and composition, (2) allow for
partial validation independently of complex interrelationships, (3) enable rich expressiveness
and formalism for a shared understanding, (4) indicate richness and quality of information, (5)
must not assume completeness and unambiguousness, (6) be applicable to existing infrastruc-
tures and frameworks.
Context models can be classified into six different model categories, namely Key-value models,
markup scheme models, graphical models, object oriented models, logic based models and on-
tology based models [69].
   1. Key-value pairs form a simple tuple of information. The context information is assigned
      to a unique key in order to allow for easy lookup by applying a matching algorithm.
      These pairs are easy to manage but lack structuring and therefore do not allow for effi-
      cient context retrieval;

   2. Markup scheme models incorporate a hierarchical data structure of markup tags, attrib-
      utes and content. Well known examples are the User Agent Profile and the Composite
      Capabilities/Preference Profile (CC/PP) [70] being based on XML (Extendible Markup
      Language). For a rather lightweight modelling of contextual information, some projects
      and labs have developed proprietary context exchange formats like ContextML (Context
      Meta Language) [71][72];



CONTEXT CASTING                                                                            Page   7
                                    Deliverable D6
    216462                                                                           C-CAST
                  Requirements and concepts for context casting service
                          enablers and context management

   3. Graphical models (e.g. based on the Unified Modelling Language (UML)) allow for a pic-
      turesque description of a context model [73] and for deriving an Entity Relationship (ER)
      model as required in rational databases. An extension is proposed by Henricksen et al.
      [13], introducing Object-Role Modelling (ORM);

   4. Object oriented models offer powerful capabilities of inheritance, reusability and encap-
      sulation. Access of contextual information is provided by well defined interfaces [2][74];

   5. Logic based models offer a high degree of formalism and typically comprise facts, ex-
      pressions and rules. They enable formal inference, e.g. by means of general probability
      logic, description logic, functional logic or first-order predicate logic;

   6. Ontological modelling intends to capture an abstract conceptual vision of the world. The
      relations within could also be described by object oriented methods. Ontology is com-
      monly described by using languages standardised by the World Wide Web Consortium
      (W3C) in the context of the semantic web. Most relevant are the Resource Description
      Framework Schema (RDF-S) and the Web Ontology Language (OWL) [21]. Available
      reasoning engines currently do not support complete interpretation of OWL Full [75]. Re-
      searchers in [1][57][69][24][76][79] concluded that ontologies are in principle the best
      way to represent and model context due to the extendibility and unambiguousness.
      However, with the size of the ontology, querying and processing the information embed-
      ded within becomes slow, in particular if performed at resource constraint mobile de-
      vices. Full featured ontological representations tend to decrease the inference perform-
      ance and may not be suited for highly dynamic systems.

Summing up, various approaches for representing and modelling context exist [62][64][65][66].
An extendible and generic framework for context provisioning might have to support several of
them and include mechanisms for translation.


2.2.3   Context-Meta Information
Beside of the context information itself a model for representing related meta-data appears cru-
cial. Such context-meta information may include a quality of information quantifier, e.g. the de-
gree of uncertainty, possibility, measurement accurateness, resolution or confidence interval.
The required attributes are dependant on the inference and reasoning mechanisms.
Especially when taking historic context into account, it is important to embed data related to the
time such as time of creation (timestamp) and expiry time. Rapidly changing information can be
differentiated from rather static information (such as gender, year of birth). Location based in-
dexing might be useful when considering spatial dependencies [77].
In their work Hyunjun Chang et al. [78] propose the modelling of a lifecycle for contextual infor-
mation and an appropriate representation of meta-data. The state of contextual information (e.g.
ready, running, expired, suspended) enables flexible and fast transitions when the context
changes temporarily.


2.2.4   Context Querying
Part of context modelling [66] is to make it available and accessible it in an efficient way. Key-
value pairs require assignment of unique keys and a matching algorithm to retrieve the context
information. Markup models require efficient parsing whereas object oriented modelling necessi-
tates well-defined access interfaces.




CONTEXT CASTING                                                                            Page   8
                                     Deliverable D6
    216462                                                                              C-CAST
                   Requirements and concepts for context casting service
                           enablers and context management

According to an Structured Query Language (SQL) statement for rational database access, on-
tological information can be retrieved by using Simple Protocol and RDF Query Language
(SPARQL), an Resource Description Framework (RDF) query language specified by W3C [75].
Complex context retrieval tasks should be transparent to the end-users. An example is querying
the number of devices and people in a specific geographic area, who share the relation 'col-
leagues' - for autonomous recognition of spontaneous meetings. Therefore, special context
query models may be designed and deployed. Compared to the relational database theory, a
temporal database scheme may be required to accelerate access and increase system per-
formance.


2.2.5   Context Reasoning/Inference
Reasoning and interpretation are seen as crucial tasks or the context-aware system, for deriving
high-level contextual information from lower level context or raw data (e.g. databases or sensor
output) [11]. Context inference typically comprises several processing stages as depicted in
Figure 2-1 below. The various logical layers and reasoning mechanisms are presented within.
The focus of the C-CAST project comprises the processing of context information (and not sen-
sor data), i.e. the availability of primitive (= low level) context information is assumed.
According to the abstraction level, the components of the reasoning are organised in layers.
Korpipää et al. [14] provide a system being able to reason about the user situation in her mobile
device. Based on audio (microphone), acceleration, light intensity and humidity sensors they
recognise situations such as “Drive car”, “Run to the door”, “Walk to the elevator”, “Wait for the
elevator”, “Open the door”, “Sit down in a restaurant” and “Listen to music”. Figure 2-1 (left) illus-
trates the chosen context representation layers and the relevant reasoning mechanisms. At the
bottom features are extracted from the sensed audio samples by applying neural networks. The
quantisation above associates defined fuzzy sets to these features (e.g. loud speech, dry hu-
midity environment). Classification is then achieved by Bayesian networks linking the quantified
features to situations. Minsky [17] compares such a representation in layers to the internal un-
conscious behaviour of the human brains. He conceptually suggests an approach comprising
Micronemes, Neural nets, K-lines, Semantic nets, Frame-arrays and Transframes to finally allow
for story-like scripts (cp. Figure 2-1, right).
The project Solar aims at designing and implementing a context fusion network for large-scale
applications [5]. Based on graph theory, they provide an infrastructure model connecting several
context sources to a context-aware application (the context consumer). The nodes are repre-
sented by their component model Planet providing functionalities for data fusion, mobility sup-
port and multicast tree management. Though not extensively, Solar addresses reliability and
self-management as well. However, the approach lacks the autonomous distribution of sub-
functionalities. Instead the fusion service remains abstract and therefore no negotiation of the
functional components between the Planet components has been studied.




CONTEXT CASTING                                                                                Page   9
                                    Deliverable D6
      216462                                                                          C-CAST
                  Requirements and concepts for context casting service
                          enablers and context management




Figure 2-1: Examples of layered Reasoning (Korpipää, 2003; Minsky, 2000; Van Laerhoven, 2000)


Van Kranenburg et al. [15] design an architecture composed of “Context-Reasoners” (CR) as
part of their context management framework. They define the tasks of such an element as to
ensure a composition of sensors being relevant for the requesting entity‟s application domain
and to derive useful contextual information. Its functionalities comprise (1) matching sensors
descriptions with application-specific parameters, (2) retrieval and selection of existing sensors,
(3) derivation of estimation of entailed context information. Context derivation is based on high-
level predefined rules and on detection of regularities in context information and application be-
haviour. Context is modelled exclusively by ontologies and consequently reasoning is limited to
description logic. Although the architecture is pictured in a clear way, the details of CR incorpo-
rations are missing. The CR is more seen as functional part of a CP or sensors. The project
DRAGO aims at providing a distributed reasoning architecture for the semantic web hence fo-
cussing on the cooperation of different ontologies [19]. Distributed reasoning is limited to a tab-
leau-based procedure in the context of distributed description logics.
Due to fuzzy and incomplete source data, imprecise reasoning received much attention in the
domain of context-aware systems [18][79][80][81]. Beside of classical probabilistic logic, Bayes-
ian Networks and Fuzzy Logic are widely adopted.



2.3     Group and Community Management
The deployment of context-aware systems and ubiquity of mobile devices, as potential context
sources, e.g. embedded sensors, microphones and cameras, is a major step towards pervasive
systems and smart spaces. The availability of user and environment data offers a variety of con-
text information to enrich future communication and content delivery systems. It is likely for
smart spaces to grow from smart homes/offices to urban smart spaces in which plenty of arte-
facts and people are interconnected over distance. Traditional web groups have evolved from
simple buddy list to more active social communities like Facebook, and on the network-side IP
multicast opportunities have been explored. The demand and popularity of the first has grown
many folds but it is not the case with the later. User mobility, mobile networks and ubiquity of
connected devices make it interesting to explore multicast over user or device groups, where
bandwidth is variable and often scarce. At present simple service-based multicast is available
[85] [86] or application-level web-community support is present for mobile users but lacks to ex-
ploit the benefits of underlying access network and context-aware adaptation at both levels.
With the gradual integration of sensor networks and emergence of smart spaces powered by


CONTEXT CASTING                                                                            Page   10
                                     Deliverable D6
      216462                                                                            C-CAST
                   Requirements and concepts for context casting service
                           enablers and context management

user/device mobility the web communities and context-aware mobile groups can be exploited
for context-aware services.
Some group management and ad hoc community issues are touched on research on mobile ad
hoc networks, where mobile nodes form a communication network without any infrastructure
support. The group membership attributes and managements functions are discussed by Liu et
al. [87] and Prakash and Baldoni [88] and a middleware is presented by Bottazzi et al. [89]. Only
a few studies have been carried out for supporting context aware groups [20]. Ferscha et al.
[90] proposes a software framework for group interaction support, which abstract context infor-
mation along with location model.
In sociology, a group is a unit consisting of a number of individuals interacting with each other
with respect to common motives and goals and/or established relationships. The interaction fol-
lows the accepted norms and values with reference to matters relevant to the group. Even
though the definition is rooted in sociological observations and premises; it reveals three impor-
tant questions and offers an insight into answering those; 1) "How is a group formed?" 2) "How
does a group function?" 3) "How does one describe those social interactions that occur on the
way to forming a group and within the group?" C-CAST will explore these questions along with
the group management challenges arising due to dynamic context-based change in group dy-
namics.



2.4     Context-Aware Content Selection
Adaptation is a key word when talking about context-aware systems. Celentano and Gaggi [34]
define adaptation as "the ultimate outcome of context-awareness", achieved "without explicit
user tuning operations". In the content delivery services, this is commonly associated to media
and web content adaptation considering terminal capabilities, including content selection from
different versions [35]. But adaptation may go further and include content selection or recom-
mendation of different content, based on the context. There have been a few attempts of ad-
dressing this issue, namely by Brunato and Battiti [36], by Chen [37], and by Park, Yoo and Cho
[38].
By considering content selection, the C-CAST project aims to define a framework that allows
services built on top of it to easily take advantage of the collected context information for a flexi-
ble and enhanced user experience. The content shall be selected based on service logic, the
available content for that service, and user context. Advertisement selection based on service
rules and context will be addressed as a more specific case of content selection.




CONTEXT CASTING                                                                               Page   11
                                     Deliverable D6
      216462                                                                         C-CAST
                   Requirements and concepts for context casting service
                           enablers and context management


3. WP3 Research Objectives
This section presents research objectives identified within the WP3 and elaborate the work
planned for the duration of the C-CAST project. They are grouped according to the WP3 activi-
ties structure.


3.1     Context Management Architecture and Representation


3.1.1   Context Management Architecture and Federation
In order to design a generic and large context-aware system being able to provide the next
generation of mobile services, a large variety of context information needs to be created, main-
tained and distributed. Hence, an efficient context management framework needs to be pro-
vided, allowing for extendibility and scalability. Various architecture models are discussed in
previous section and based on the system-level requirements identified in the subsequent sec-
tion, a context management architecture is proposed in Section 5.
The architecture should allow the flexibility to manage multiple entities which produce, manage
and consume context information. The research objective of this activity is to analyze the vari-
ous architecture and federation models. A typical federation model is the hierarchical organiza-
tion of context entities within context management architecture. Peer-to-Peer (P2P) federation is
also a strong candidate. We aim to address this issue in following research objectives:
        Investigate and identify the requirements of an efficient and scalable context manage-
        ment architecture;
        Investigate the requirements of an efficient and scalable context federation model that
        offer load balancing, fault tolerance and failure recovery;
        Explore existing federation models for context management model (hierarchical, peer-to-
        peer, etc);
        Investigate the feasibility of peer-to-peer and hierarchical setup of context entities for
        discovery, query routing and management.


3.1.2   Distribution/Diffusion of Context
Context dissemination is the process through which context is distributed and shared between
multiple context producing and consuming entities in a context aware system. For example, one
of the most prominent architecture used to facilitate context dissemination in a context aware
system has been the broker architecture. For efficient context management, which includes
context dissemination, it is imperative to consider communication schemes with respect to the
decoupling they provide. Various forms of decoupling are:
        Space Decoupling: The interacting parties do not need to know each other. The pub-
        lishers (providers) publish information through an event/information service and the sub-
        scribers (consumers) receive information indirectly through that service. The publishers
        and subscribers do not usually hold references to each other and neither do they know
        how many subscribers/publishers are participating in the interaction;
        Time Decoupling: The interacting parties do not need to be actively participating in the
        interaction at the same time i.e., the publisher might publish some information while the



CONTEXT CASTING                                                                           Page   12
                                     Deliverable D6
    216462                                                                              C-CAST
                   Requirements and concepts for context casting service
                           enablers and context management

        subscriber is disconnected and the subscriber might get notified about the availability of
        some information while the original publisher is disconnected;
        Synchronization Decoupling: Publishers are not blocked while producing information,
        and subscribers can get asynchronously notified (through call-backs) of the availability of
        information while performing some concurrent activity i.e. the publishing and consump-
        tion of information does not happen in the main flow of control of the interacting parties.
This decoupling is important to cater for because decoupling of production and consumption of
information increases scalability by removing all explicit dependencies between the interacting
participants. Removing these dependencies strongly reduces coordination requirements be-
tween the different entities and makes the resulting communication infrastructure well adapted
to distributed environments. This advantage becomes more beneficial when mobile entities exist
in a distributed system (owing to their limited resources, intermittent connectivity etc). Keeping
this in view, it is clear that further effort is needed for development of a context dissemination
and distribution framework which can efficiently accommodate the existence of mobile entities
and provision of context aware adaptable services within a distributed context aware system.
We aim to address these issues in following research objectives:
        Investigate and identify the requirements of an efficient and scalable context manage-
        ment mechanism that can improve the adoption of context aware services in a real world
        environment containing mobile users and distributed context aware systems;
        Explore existing information dissemination techniques for dissemination of context in-
        formation across a distributed context aware system (P2P, Multicasting, Flooding, Epi-
        demiological Models, etc);
        Investigate the feasibility of peer-to-peer and hierarchical setup of context entities for ef-
        ficient dissemination and diffusion of context information;
        Investigate publish-subscribe communication mechanism for distribution and manage-
        ment of context and context related information.


3.1.3   Context Representation Model
Formal representation of context information is an integral part of any context management ar-
chitecture. A richer representation model enables complex and intuitive reasoning. Several rep-
resentations models have been discussed in previous section and have respective strengths
and weaknesses. The objective of this research activity is to analyze these models and select
the most appropriate model for C-CAST. In addition, further extensions will be proposed to the
selected model.
In order to provide a lightweight and agile reasoning and communication system, heavy ontolo-
gies might not be an appropriate choice for a very fast system handling a lot of data as overall
contexts flowing through CMS. However, if required by some specific reasoning methodology,
ontologies may be used. A more appropriate option for representation and exchange of context
information is the ContextML [63] based on the XML format. ContextML is used to announce the
type of context (e.g. language) and the provided scope (e.g. Germany). Furthermore it can rep-
resent time constraints such as context creation time and period of validity. Context meta-data
comprises the quality of information (with respect to degree of vagueness, uncertainty) as well.
   WP3 aim to address these issues in following research objectives:

        Investigate and identify the requirements for context representation;
        Explore existing representation models in detail and analyse their pros and cons;



CONTEXT CASTING                                                                               Page   13
                                     Deliverable D6
    216462                                                                             C-CAST
                   Requirements and concepts for context casting service
                           enablers and context management

        Investigate the feasibility of Mark-up scheme models, specially ContextML.


3.1.4   Context Based Adaptation
The primary goal of a context aware application or service is to be able to adapt its behaviour in
response to a context change. Consequently it is an essential requirement that the context
management system is engineered to be able to achieve this. Delivering adaptation to the end
users is also the validation and verification of effectiveness of the end-to-end context manage-
ment framework. This end-to-end lifecycle is illustrated in Figure 3-1.
To avoid confusion, during this discussion we use the terms Adaptation, Context and Orches-
trate/Coordinate as follows:


Adaptation is a process where a component, such as a device, application, service or mecha-
nism, is changed or changes so as to become suitable to a new or special application or emerg-
ing situation. In addition, adaptation changes the behaviour of a system or component in re-
sponse to new or modified surroundings;

Coordination/Orchestration is a process to arrange or manipulate behaviour of components,
especially by means of clever or thorough planning or manoeuvring and to arrange or control
the components so as to achieve a desired effect and to combine components in a harmonious
relation or action.




                        Figure 3-1: Context Awareness Lifecycle Overview


Providing context aware services-applications is complex on many grounds but one of the chal-
lenging difficulties is that it is no longer possible to create and provide pre-defined services and
inter component communication because the system decides the response on individual
event/trigger and every instance can have a different response, setup and delivery procedure.
Considerable research has been done in the areas of dynamic service composition and orches-
trations, summarizing salient efforts, the most popular approaches are:
        Code generation techniques;
        Web services based solutions;


CONTEXT CASTING                                                                             Page   14
                                     Deliverable D6
      216462                                                                          C-CAST
                   Requirements and concepts for context casting service
                           enablers and context management

        Intelligent proxies for context based service triggering;
        Agent based solutions;
        End-user application-oriented adaptation;
        Formal modelling techniques.
Adaptation and reasoning is distributed over different WP3 functional modules of the architec-
ture. However, it is not clear how each component will interact with others accordingly to rea-
soning and adaptation concept and logic. Another issue is the starting point of the whole proc-
ess as based on scenario the execution flow can start at more than one entity in the overall ar-
chitecture.
The context aware adaptation research will investigate some of the issues discussed above. In
particular the following are considered to be important:
        Investigate and identify the requirements for situation/event modelling in context aware
        ubiquitous environments;
        Investigate the adaptation implications for the design of the context management sys-
        tem;
        Investigate the communication models based on previous inference step‟s output;
        Investigate and identify the adaptation methods on the mobile device;
        Investigate the execution of adaptation oriented work flow in terms of communication
        and triggers.



3.2     Group-Awareness
A group is a derived entity which comprises of multiple individual entities called users. The indi-
vidual entities/users have associated information (context) and based on commonality and/or
influences of certain context information groups are created/formed. The groups can be divided
into two broader categories; social groups (established relationships) and communica-
tion/multicast groups (physically co-located or service-based). Within social groups there could
be numerous groups like work group, tourist group etc. Whereas the multicast or communica-
tion group do not consider the social aspect rather it focuses on the delivery aspect.
In C-CAST project we can consider some innovative kinds of groups by bringing together the
social and multicast/communication groups. This fused socio-delivery approach towards group,
powered by context information, offers countless opportunities to exploit group/community
communication. The activity is divided into two main functional components: 1) group recogni-
tion and 2) group management.


3.2.1   Group Recognition
The novel aspect is to use both user context and network context information to evolve and im-
prove the group recognition process. This will result in a multicast content delivery, which is op-
timally tailored to the users‟ profiles, to their environment and to the network connectivity and
characteristics. The group recognition can be either context-based i.e. uses context information
to intelligently define a group or it can be context-aware i.e. depending on contextual change(s),
dynamically identify a group and initiate the group communication without any prior specifica-




CONTEXT CASTING                                                                            Page   15
                                       Deliverable D6
      216462                                                                         C-CAST
                     Requirements and concepts for context casting service
                             enablers and context management

tion. [It should be noted that, in order to have truly context-aware group communication, addi-
tional components like context-aware service adaptation and provisioning is also required.]


3.2.2    Group Management
The group management comprises of the traditional functions to create/delete a group,
add/remove user from a group and manage group profile. Individual users‟ context and derived
group context information can be used to evolve group creation and group management (group
splitting or merging) functions. The standard group management requirements are presented in
Section 4.2.
The context-aware group awareness research will investigate some of the issues discussed
above. In particular the following are the key research objectives:
         Investigate and identify the requirements for group recognition and group management
         Investigate the group recognition models, representation and their implications on the
         context management system
         Investigate and identify the group management features and functional components
         Investigate the data and control exchange between group recognition and management
         Investigate the data and control exchange between group management and context
         management architecture



3.3      Content Selection
The context-aware content selection module shall provide means for selecting content for a
user or group based on service-level input, on available content and its metadata, and on the
context of the specified user or group. Also, this component may not only be responsible for
recommending content but may also be required to manage the sequence in which content
items are transmitted for sequential content delivery (TV-like) services. The context-aware con-
tent selection shall also provide means for the most suitable ads for a user or group to be se-
lected.
Existing approaches for simple recommendation systems, context-aware recommendations and
ad selection and their suitability for its use in the C-CAST platform shall be studied. The objec-
tive is to define a framework as generic as possible within the scope of content delivery plat-
forms. Also, specific recommendation techniques will be analysed for use within this kind of
recommendation system.
      In particular the following are the key research objectives:
         Define a framework that allows services to flexibly but easily configure context-aware
         content selection;
         Explore and identify recommender system techniques and approaches that may be used
         in context-aware content selection;
         Evaluate the feasibility of the selected recommender system techniques and ap-
         proaches.




CONTEXT CASTING                                                                           Page   16
                                    Deliverable D6
      216462                                                                          C-CAST
                  Requirements and concepts for context casting service
                          enablers and context management

3.4     Reasoning and Inference
In this subsection, context providing network entities will be entitled as "Context Provider" for
facilitating reading.
Not only being processed in layers, the described task of reasoning and interpretation is fur-
thermore distributed amongst several networking and functional entities as highlighted in Figure
3-2 below. The depicted Context Providers depend on each others' output. Linked to the layered
design presented above (cp. section 2.2.5), the mechanisms are deployed on distributed enti-
ties. An exemplar User Situation Context Provider would apply rule-based reasoning and rely on
primitive context provided by the Calendar Context Provider.


                        Environment (2)       User Action         Calendar
                        Context Provider    Context Provider   Context Provider

                         User Profile (1)    User Situation       Location
                        Context Provider    Context Provider   Context Provider

                         Group Profile      Group Situation       Proximity
                        Context Provider    Context Provider   Context Provider


                         User Profile (2)   Social Community   Environment (1)
                        Context Provider    Context Provider   Context Provider


                            Figure 3-2: Context Provider Dependencies


Most related research activities saw the context inference process as unidirectional process and
rather static as far as the control or configuration are concerned. Instead, C-CAST aims at in-
vestigating means for influencing and tailoring the lower level mechanisms based on available
knowledge as illustrated in Figure 3-3. The control will not be restricted to adapting the sensor
data acquisition process but will also comprise the adaptation on higher context processing lay-
ers.
Due to the highly dynamic nature of mobile communication systems (e.g. mobility, activity
change), reasoning and inference mechanisms [3] need to be able to cope with the continuously
change of contextual information. Furthermore, the computational power of mobile devices and
their communication bandwidth are limited and require light-weight algorithms. Distributed rea-
soning is tightly coupled to efficient context provisioning and exchange. A subject-based pro-
vider-consumer context management model as suggested in this work is promising approach.
However it is a matter of investigation as to how extendible and scalable it can be in supporting
distributed fast robust reasoning.
Machine learning approaches aim at deriving knowledge from historic context information. The
consideration of such mechanisms appears essential due to the lack of existing statistics and
trials concerning user behaviour in pervasive environments. By adding such a control loop, the
system is able to improve constantly and (semi-)autonomously, i.e. it adapts itself to the entities
(e.g. users). How such (semi-) autonomous learning systems can best be made available and
integrated with the context management system is also a matter of investigation.




CONTEXT CASTING                                                                            Page   17
                                    Deliverable D6
   216462                                                                                                           C-CAST
                  Requirements and concepts for context casting service
                          enablers and context management


                                    Semantic Info.                              Knowledge

                                                  Knowledge based Interpretation




                                                                                                Focus / Selection
                                      Features                                     Model

                                                      Model driven Grouping
                  Aggregation



                                    Sensor Data                               Proc. Paramters

                                                         Pre-Processing

                                  Raw Sensor Data                             Sensor Param.

                                                             Sensing

                                         Signal



                                Figure 3-3: Knowledge-based Context Detection Control


   Therefore the major research objectives are:
      How to select and plug in appropriate reasoning and interpretation mechanisms, allow-
      ing for control by parameterisation during runtime; ensuring fast and robust behaviour in
      a highly dynamic surrounding;
      How best to design a framework (or extending the context management architecture) for
      context inference control; design of Context Provider interfaces to enable controlling the
      internal context inference;
      Investigation of how to distribute the context inference efficiently and how to provide con-
      textual information in a scalable way and compare with other context management mod-
      els;
      Investigation of how to select and plug in machine learning algorithms to be applied to
      historic contextual information;
      Selection and adaptation of context models and representation languages to support
      fast and robust reasoning and expressive context meta information, such as quality of in-
      formation, probability and uncertainty.




CONTEXT CASTING                                                                                                        Page   18
                                    Deliverable D6
      216462                                                                          C-CAST
                  Requirements and concepts for context casting service
                          enablers and context management


4. System Level Requirements
This chapter lists all the requirements that shall be addressed and supported by the context
management system, group management and content selection components designed within
the C-CAST project. The requirements falls under two generic groups: 1) functional require-
ments, describing operations that the Context Management System (CMS) shall support and 2)
technical requirements for the CMS platforms addressing particular issues such as perform-
ance, reliability, type of connections and protocols, interoperating with other platforms and sys-
tems, etc.
It should be noted that in order to have a complete system, additional functionality such as ser-
vice adaptation and provisioning, privacy and trust management, identity management, etc, is
required. However, the scope of this WP limits it to group management and content selection
requirements.


4.1     Context Management and Reasoning
The main context requirements of the CMS being considered accordingly to a black-box ap-
proach are indicated within Deliverable 10 (D10) [33] and they are listed below for sake of clarity
and integrity of this document:
       CM1.    CMS shall provide means for retrieving of an entity‟s context requested by con-
               text consumers;
       CM2.    Distributed architecture;
       CM3.    Event based notification of context changes;
       CM4.    Publish/subscribe mechanism registering/data providing by context entities;
       CM5.    Publish/subscribe mechanism for context data registering and retrieval;
       CM6.    Query based context retrieval mechanism;
       CM7.    Provision of context history;
       CM8.    Using defined and flexible context representation with mandatory context attrib-
               utes (related entity and timestamp);
       CM9.    Context may be extended with additional attributes, e.g. validity and quality of in-
               formation;
       CM10.   Subject based lookup service for context information;
       CM11.   Context information source discovery and management;
       CM12.   Addressing privacy, security and trust;
       CM13.   Scalable and extendable, reliable and robust;
       CM14.   Context acquisition from distributed sources of context information;
       CM15.   Context aggregation and fusion of other context data;
       CM16.   Context inference based on available context information or raw data;
       CM17.   Context-aware reasoning and inference process.



4.2     Group Management
The identified requirements for Group Management (GM) are enumerate below.
       GM1.    The group management component shall have well-defined generic functional
               features;
       GM2.    The group management component shall have well-defined interface;




CONTEXT CASTING                                                                            Page   19
                                    Deliverable D6
      216462                                                                        C-CAST
                  Requirements and concepts for context casting service
                          enablers and context management

       GM3.  The group management component shall be able to communicate with the Con-
             text Management System, other components and applications;
       GM4.  The group management component shall be able to identify a potential group;
       GM5.  The group management component shall be able to create and/or delete a group
       GM6.  The group management component shall be able to add and/or remove a user or
             an entity from a group;
       GM7.  The group management component shall be able to authenticate and/authorize
             the user or entity;
       GM8.  The group management component shall be able to initiate group session;
       GM9.  The group management component shall be able to defined group profile and its
             characteristics;
       GM10. The group management component shall be able to split a group and/or merge
             multiple groups based on context information.




4.3     Context-Aware Content Selection
The following requirements have been identified with regard to the envisaged Content Selection
(CS) component.
       CS1.    The content selection component shall have well-defined generic functional
               features;
       CS2.    The content selection component shall have well-defined interface;
       CS3.    The content selection component shall be able to communicate with the Con-
               text Management System, other components and applications;
       CS4.    The content selection component shall be able to provide means for selecting
               content for a user or group based on service-level input, on available content and
               its metadata, and on the context of the specified user or group;
       CS5.    The content selection component shall be able to manage the sequence in which
               content items are transmitted for sequential content delivery (TV-like) services;
       CS6.    The content selection component shall be able to provide means for the most
               suitable advertisements for a user or group to be selected;
       CS7.    The content selection component shall be able to estimate the suitability of con
               tent for a user manage the sequence of transmitted content perform content se
               lection and ad selection decisions.




CONTEXT CASTING                                                                          Page   20
                                     Deliverable D6
      216462                                                                          C-CAST
                   Requirements and concepts for context casting service
                           enablers and context management


5. Context Management Architecture Concept
Taking into account the literature survey, research objectives and the system-level requirements
presented in previous sections, a Context Management Architecture (CMA) is proposed. The
CMA forms the foundation for a complete WP3 architecture, also presented in this section.


5.1     Overview
A well-known and often used paradigm of the combined context server and networked service
model is the producer-consumer role model. Network components may take the roles of a Con-
text Provider (CP) (often referred to as a context source) or may take the role of information
sinks, i.e. Context Consumers (CC) [72][71][82]. These basic two role entities may interconnect
by means of Peer-to-Peer (P2P) techniques [15][83] or by a Context Broker (CB) providing a
directory and lookup service. Broker architecture in its various forms exists as a middleware
technology that manages communication and data exchange between objects or entities.
The producer-consumer role model is able to offer flexibility, modularity and extendibility. It
combines the aforementioned advantages of widget, blackboard and networked service models.
However, certain mechanisms for ensuring robustness and efficiency need to be integrated.
Hence the proposed research will concentrate on this model without ignoring the other con-
cepts.
The following sub-sections will link the identified requirements to this model. They will present
the concept in more detail and argue need for further research.



5.2     Logical Architecture Definition and Context Representation
The Context Management Architecture (CMA) may be derived through classification of the sys-
tem-level requirements into groups of requirements. The classification is based on logical se-
quence of acquiring, delivering, storing and eventually using/consuming context information.
Logically the following requirements‟ groups along with related requirements are distinguished
and described within following subsections.


5.2.1   Context Acquisition (CA)
This is a logical point where context is detected and acquired or extracted from other contexts.
This point is distinguished by the following identified requirements from the above list of generic
requirements:
        Distributed architecture (CM2);
        Event based model (CM3);
        Publish/subscribe mechanism for context entities (CM4);
        Query based mechanism (CM6);
        Availability of context history (CM7);
        Using defined and flexible context representation with mandatory context attributes
        (identified entity or subject and timestamp or moment) (CM8);




CONTEXT CASTING                                                                            Page   21
                                     Deliverable D6
    216462                                                                             C-CAST
                   Requirements and concepts for context casting service
                           enablers and context management

        Context may be extended with additional attributes e.g. validity and quality attributes
        (CM9);
        Addressing privacy, security and trust (CM12);
        Context acquisition (CM14);
        Context aggregation and fusion of other context data (CM16);
        Context inference based on other context or data and reasoning (CM17).


5.2.2   Context Entity Directory and Exchange (CEDE)
This is a set of functionalities or logical entity that creates a relationship between a context pro-
vider and context consumer. This entity is distinguished by the following identified requirements
from the above list of generic requirements:
        Distributed architecture (CM2);
        Publish/subscribe mechanism for context entities (CM4);
        Query based mechanism (CM6);
        Using defined and flexible context representation with an extensible list of mandatory
        context attributes (identified entity or subject and timestamp or moment) (CM8);
        Subject based lookup service for context (CM10);
        Context information source discovery and management (CM11);
        Addressing privacy, security and trust (CM12);
        Scalable and extendable, reliable and robust (CM13).


5.2.3   Context Consumer (CC)
This is a logical point where context is used (or consumed) accordingly to a context-aware ser-
vice logic. This point is distinguished by the following identified requirements from the above list
of generic requirements:
        Distributed architecture (CM2);
        Event based model (CM3);
        Publish/subscribe mechanism for context data (CM5);
        Query based mechanism (CM6);
        Context-aware adaptation (CM15).


5.2.4   Service Component
This is a set of generic and well defined functions. The service component targets specific func-
tions and hides the complexity to the application. In general, the entity is distinguished by follow-
ing requirements:
        The component shall have well-defined functional features (GM1) (CS1);
        The component shall have well-defined interface and hide the complexity (GM2) (CS2);



CONTEXT CASTING                                                                              Page   22
                                    Deliverable D6
      216462                                                                          C-CAST
                  Requirements and concepts for context casting service
                          enablers and context management

        The component shall be able to communicate to the Context Management System, other
        components and applications (GM3) (CS3).


5.2.5   Context Representation
Context data shall be represented in a form that is univocally understandable, validated, clear
and identifiable for all logic elements of the architecture. At least the following properties from
the above generic requirements shall be respected for the context data and assigned to all the
logical modules handling or dealing with the context data:
        Using defined and flexible context representation with extensible list of mandatory con-
        text attributes (identified entity or subject and timestamp or moment) (CM18);
        Context may be extended with additional attributes e.g. validity and quality attributes
        (CM19).


5.2.6   Logical Architecture Breakdown
According to the above identified logical blocks the following Figure 5-1 shows the logical com-
position of the proposed context management architecture.




                      Figure 5-1: Context Management Logical Architecture




5.3     Functional Entities Breakdown
Functional Architecture or Functional View of overall reference Context Management Architec-
ture (CMA) here below defined is derived from the logical architecture or logical view by an ad-
ditional decomposition and split of coarse grained logic modules into smaller entities where
possible.



CONTEXT CASTING                                                                            Page   23
                                           Deliverable D6
     216462                                                                                                  C-CAST
                         Requirements and concepts for context casting service
                                 enablers and context management

5.3.1     Context Consumer (CC)
Context consumer as module of the logical architecture is an entity of the WP3 functional archi-
tecture. It is assigned with a few functionalities, with no reasons for an additional split. This en-
tity fulfils the requirements shown in the Table 5-1 below.

                       Requirement                                              Requirement details
 [CM1] Shall have means to discover structure of context
 data or context model
 [CM2] Distributed Architecture                                  [CM2.1]    Shall be able to identify the directory service
                                                                 [CM2.2]    Shall be able to communicate with a CEDE or
                                                                            CA upon discovery
                                                                 [CM2.3]    Shall have means to retrieve required context
                                                                            information relying upon distributed architecture
 [CM3]     Publish/Subscribe Mechanism for Context Data          [CM3.1]    May subscribe to context information or context
                                                                            related event
                                                                 [CM3.2]    Shall be able to receive context information in
                                                                            an asynchronous mode
 [CM4]                                                           [CM4.1]    Shall be able to handle (receive and process)
                                                                            events from CMA
 Event-based model
 [CM5]                                                           [CM5.1]    Shall be able to query context data to CMA
                                                                 [CM5.2]    Shall be able to query CEDE for CA credentials
 Query-based Mechanism                                           [CM5.3]    Shall be able to query context structure or
                                                                            model to CMA [CM3]
 [CM6]     Context-aware Adaptation                              [CM6.1]    Shall adapt service (the output for which it was
                                                                            created) according to context

                                    Table 5-1: Context Consumer Requirements


5.3.2     CEDE and Context Broker (CB)
Context Entity Directory and Exchange acts as a Context Broker within Functional Architecture
with the following requirements listed within the Table 5-2 below.


           Requirement                                               Requirement details
[CM1] Distributed Architecture              [CM1.1]   Efficient management for context data/requests
                                            [CM1.2]   Efficient management of Context Providers
                                            [CM1.3]   Self configuration (e.g. new CB announcement, automatic insertion and
                                                      network configuration update) shall be supported
                                            [CM1.4]   Shall be resilient and have high availability
                                            [CM1.5]   Shall have means to retrieve required context information relying upon
                                                      distributed architecture
[CM2] Publish/Subscribe Mechanism for       [CM2.1]   Shall be able to handle subscription request from CC
      Context Entities                      [CM2.2]   Shall be able to publish itself
                                            [CM2.3]   Shall be able to register CP and CB (handle publish requests)
[CM3] Query-based Mechanism                 [CM3.1]   Shall be able to query context data to CMA
                                            [CM3.2]   Shall be able to query other CB for CA credentials
                                            [CM3.3]   Shall be able to query context structure or model to CMA
                                            [CM3.4]   Shall be able to handle and respond to queries
[CM4] Using Defined and Flexible Con-       [CM4.1]   Shall be able to request/retrieve context structure/model
      text Representation with Manda-       [CM4.2]   Shall be able to render available context structure/model
      tory Context Attributes (identified   [CM4.3]   Shall be able to validate context structure/model


CONTEXT CASTING                                                                                                     Page   24
                                         Deliverable D6
     216462                                                                                                    C-CAST
                       Requirements and concepts for context casting service
                               enablers and context management

          Requirement                                                Requirement details
      entity or subject and timestamp
      or moment)
[CM5] Subject based Lookup Service       [CM5.1]     Shall be able to provide mechanisms to perform lookup for a context or
      for Context                                    all contexts of certain subject/entity
                                         [CM5.2]     Shall be able to provide overall contexts of an entity/subject combining
                                                     available local and remotely retrieved contexts for that entity on behalf of
                                                     requesting party (CC or CA)
[CM6] Context Information Source Dis-    [CM6.1]     Shall be able to provide context entity lookup for requested context data
      covery and Management              [CM6.2]     Shall be able to distinguish local contexts and mechanisms for retrieval
                                                     and providing of references to remote sources of contexts of an entity
                                         [CM6.3]     Shall maintain information about how and where to retrieve context in-
                                                     formation regarding entities
[CM7] Addressing Privacy, Security and   [CM7.1]     Shall guarantee required privacy and security level for entities involved
      Trust                                          in context information exchange
                                         [CM7.2]     Shall provide means to protect context data from unauthorized usage
[CM8] Scalable and Extendable, Reli-     [CM8.1]     Distributed CB infrastructure shall be scalable and extendable by joining
      able and Robust                                additional CBs
                                         [CM8.2]     Context and other entities’ data retrieval shall be reliable and robust
                                         [CM8.3]     Shall provide and guarantee reliable communications treating context
                                                     and context information references’ data
                                         [CM8.4]     Entities’ context data obtained through distributed CBs shall be consis-
                                                     tent and robust
                                         [CM8.5]     Shall include means for fast and robust retrieval of valid context data
                                                     without impact on overall context exchange performance This functional-
                                                     ity may be organized into a cache functionality that would be a part of
                                                     CB

                                    Table 5-2: Context Broker Requirements


5.3.3    CA and Context Provider
Context acquisition may be split into three functional entities performing well defined and distin-
guishing functionalities, having impact on complexity of a whole CA from simplest to most com-
plex. CA is broken down into three entities which may be part of a single, complex CA:
         Context Provider;
         Context History;
         Context Reasoning.
The following requirements listed in the Table 5-3 below apply to a CA, while some of them,
where mentioned, refer to the single split components.
    Requirement                          Requirement details
[CM1]    Publish/Subscribe     [CM1.1]   Shall be able to publish its type of con-
         Mechanism for Con-              text data within CMA to CB
         text Data             [CM1.2]   Shall be able to register subscription of
                                         other CMA entities for context data re-
                                         garding certain entity it provides
                               [CM1.3]   The publish/subscribe mechanism shall
                                         be automatically performed by CP and
                                         other CMA components
[CM2]    Context-aware Ad-     [CM2.1]   Shall deploy or implement context-
         aptation                        aware features/functionalities as a CC


CONTEXT CASTING                                                                                                       Page   25
                                         Deliverable D6
     216462                                                                                                       C-CAST
                       Requirements and concepts for context casting service
                               enablers and context management

    Requirement                             Requirement details
                                 [CM2.2]    Shall modify its behaviour/parameters
                                            accordingly to relevant for its function-
                                            ality contexts provided by itself or other
                                            CMA components
[CM3]   Distributed Architec-    [CM3.1]    Shall support distributed architecture
        ture                     [CM3.2]    Shall have means to retrieve required
                                            context information relying upon dis-
                                            tributed architecture
[CM4]   Event-based model        [CM4.1]    Shall be able and have means to pro-
                                            vide context information based on
                                            events (time, timer period, context
                                            match or change)
[CM5]   Query-based              [CM5.1]    Shall be able to handle and respond to
        Mechanism                           queries
[CM6]   Availability of Con-     [CM6.1]    Shall be able to collect and store all the   These requirements refer to the entity
        text History                        context data provided to CMA by itself       storing context data, also expired data,
                                                                                         for a possible future usage e.g. statistic.
                                                                                         Thus, they are assigned to the Context
                                                                                         History (CH) entity and addressed in
                                                                                         more details within below section.
[CM7]   Using defined and        [CM7.1]    Shall be able to render available con-
        flexible context rep-               text structure/model
        resentation       with
        mandatory context
        attributes (identified
        entity or subject and
        timestamp or mo-
        ment)
[CM8]   Context May be           [CM8.1]    Shall be able to provide context infor-
        Extended with Addi-                 mation with additional, not context, at-
        tional Attributes e.g.              tributes such as validity (validity time,
        validity and quality                expiration time) and time and quality at-
        attributes                          tributes (precision, accuracy, meas-
                                            urement method, etc.)
[CM9]   Addressing Privacy,      [CM9.1]    Shall guarantee required privacy and
        Security and Trust                  security level for its context information
                                 [CM9.2]    Shall provide means to protect context
                                            data from unauthorized usage
                                 [CM9.3]    May provide means to define trustwor-
                                            thiness of its context data
[CM10] Context Acquisition       [CM10.1]   Shall be able to retrieve context from
                                            CMA (other CMA components) or from
                                            its own embedded context providers
                                            (physical elements measuring phe-
                                            nomenon)
[CM11] Context Aggregation       [CM11.1]   Shall be able to aggregate context           This functionality may be performed at an
       and Fusion of Other                  coming from different internal sources       entity outside of a CP handling context
       Context Data                         to unique context information regarding      data from many CPs. Therefore, it may
                                            certain entity                               be a part of CEDE or CB in order to sim-
                                 [CM11.2]   Shall be able to correctly merge context     plify CPs.
                                            data based on their intrinsic ontology
                                            and subordination
[CM12] Context Inference         [CM12.1]   Shall provide future context of an entity    These requirements refer to the entity
       based on Other                       and may define its trustworthiness           acquiring or extracting context data from
       Context or Data and                                                               other source context data. Thus, they are


CONTEXT CASTING                                                                                                          Page   26
                                        Deliverable D6
      216462                                                                                             C-CAST
                      Requirements and concepts for context casting service
                              enablers and context management

      Requirement                       Requirement details
         Reasoning             [CM12.2] Shall be able to “intelligently” handle    assigned to the Context Reasoning
                                        “raw” context data in order to retrieve    (CR) entity and addressed in more de-
                                        other, non-directly available and gener-   tails within Chapter 6.2
                                        ated, context data regarding same or
                                        another entity
                               [CM12.3] May implement and employ intelli-
                                        gence, based on a logic or mathematic
                                        model, in order to retrieve other data
                                        (not necessary context) within CMA not
                                        available directly from another CP or a
                                        non-context providing entity

                                    Table 5-3: Context Provider Requirements



5.3.4    Service Component and Service Enabler (SE)
Within the architecture the service component is identified as Service Enabler (SE). These
components encompass functionality to exploit the context information. The set of requirements
for the service enablers is as follows:


         Requirement                                              Requirement details
[GM1, CS1] Well-defined Generic Func-    The group management component:
       tional Features                   [GM4] shall be able to identify a possible group
                                         [GM5] shall be able to create and/or delete a group
                                         [GM6] shall be able to add and/or remove a user from a group
                                         [GM7] shall be able to authenticate and/authorize the user
                                         [GM8] shall be able to initiate group session
                                         [GM9] shall be able to define group profile and its characteristics
                                         [GM10] shall be able to split a group and/or merge multiple groups based on con-
                                                  text information
                                         The content selection component:
                                         [CS4]    shall be able to estimate the suitability of content for a user
                                         [CS5]    shall be able to manage the sequence of transmitted content
                                         [CS6]    shall be able to perform content selection decisions
                                         [CS7]    shall be able to perform ad selection decisions
[GM2, CS2] Well-defined Interface        [GM2.1, CS2.1] The interface shall be generic
                                         [GM2.2, CS2.2] Interface shall be comprise of a set of well-defined methods
[GM3, CS3] Inter-Component Commu-        [GM3.1, CS3.1] Shall discover Context Management Architecture components via
       nication                                            the Context Broker
                                         [GM3.2, CS3.2] Shall be able to communicate with Context Provider via Context
                                                           Broker or directly to the Context Provider
                                         [GM3.3, CS3.3] Shall be Context Consumer in the producer-broker-consumer
                                                           model of the Context Management Architecture

                                    Table 5-4: Service Enabler Requirements




5.4      WP3 Functional Architecture
Logical modules are split into entities and the resulting functional architecture is presented as
the one shown in below Error! Reference source not found..


CONTEXT CASTING                                                                                                 Page   27
                                     Deliverable D6
     216462                                                                                           C-CAST
                   Requirements and concepts for context casting service
                           enablers and context management


                               Context                               CP     Address Book
                              History DB
                                                                               Google
 PD                                                                  CP       Calendar
 A




                                                Context / Trigger
                                                                     CP         XDM

Smart                            CB1                                CP         Location
                                                                                Engine
Phone
                                                                               Smart
                                 Context                             CP
                                                                               Space
                                 Cache
                                                                    CP
                                                                             Body Area           Casting enabled
                                                                               NW                   network
PC
                                              Context               CB2
                                              Cache
                                           Group Recognition              Context-aware Social
                                           Context Providers                                      Place-based
                                                                            Group Provider          Context-
                                            Generic Context-based             Situation-based     aware Group
                                               Group Provider                 Group Provider        Provider
               Casting enabled
 CC               network
                                       Service Execution
                 Casting               Environment       Service Adaptation                Content Discovery
                 Gateway                                  & Composition                     Service Enabler
                 (Caster)
                                       Group Management Content Matching                       Identity
                                        Service Enabler  Service Enabler                     Management




          Figure 5-2: Overall Context Management (Functional) Architecture and Entities


The following components are derived accordingly to the previously performed top-down analy-
sis:
        CB – Context Broker;
        CP – Context Provider;
        CC – Context Consumer
        Context Cache;
        Context History DB;
        Context-Aware and Group-based Service Enablers;
        Context is indicated of context data flows;
        Trigger is functionality allowing to match certain condition or event in context.




CONTEXT CASTING                                                                                            Page    28
                                     Deliverable D6
    216462                                                                                  C-CAST
                   Requirements and concepts for context casting service
                           enablers and context management

5.4.1   Components Relationships
According to the functional requirements listed in the Chapter 5.3, the following Figure 5-3
shows relationships between different entities. The service enablers are considered as “Context
Consumers”.




                                       Figure 5-3: CMA relationships


The following Figure 5-4 below shows the Context Reasoning that may be related to a CP and
therefore be a part of a complex CA.

                          Context
                      Representation &
                         Exchange
                        (ContextML)

                    May Use      May Use




               Logic Based            Ontology
                 Models                Models
                                                                     A see previous slide



                     May Use    May Use                         nt
                                                              me
                                                           ple
                                                      y Im
                          Inference              Ma
                         (Learning,
                         Reasoning)




        Figure 5-4: Context Reasoning as a part of CA (attached to CP shown in Figure 5-3)


CONTEXT CASTING                                                                                Page   29
                                     Deliverable D6
      216462                                                                                       C-CAST
                   Requirements and concepts for context casting service
                           enablers and context management

6. Draft Concepts

6.1     Group Management


6.1.1   Group Recognition Context Providers
The group recognition and group management functional components are illustrated as group
recognition context providers and group management service enabler in the WP3 architecture
diagram Error! Reference source not found.. The group recognition context provider require-
ments are presented in Section 4.2. It includes reasoning component which process the context
information acquired from the other context providers as illustrated in Figure 6-1.

                                        Context Provider

                                                    Reasoning




                                                                          Context Representation
                                                   Aggregation
                                      Learning




                                                 Filter & Extraction


                                                    Acquisition



                                         Context                   Context
                                        Provider 1                Provider N

                                 Figure 6-1: Context Provider Model


At present three group recognition context providers are considered within this activity. As the
work proceeds more innovative group providers will be added.

Context-aware Social Group Provider
This group provider considers a user‟s online social communities as an input and based on
user‟s current context filters out a most suitable „contextualized snapshot‟ of that community.
The reasoning algorithm builds on the strength of social/web communities and exploits the
available context information to offer user a more personalized communication space. The web
communities can be users‟ friends list or fan clubs or blog communities, etc.

Generic Context-based Group Provider
This group provider identifies users fulfilling a certain criteria. This criterion can be defined by an
application or user themselves. As the group recognition is based on contextual information of
users which is dynamic and changes over time, the group identified might be different at differ-
ence instance of time. More specific example can be of „situation-based‟ group provider or sim-
ply location-based group provider.




CONTEXT CASTING                                                                                       Page   30
                                    Deliverable D6
    216462                                                                           C-CAST
                  Requirements and concepts for context casting service
                          enablers and context management

Place-based Context-aware Group Provider
The place-based context-aware group provider is the most innovative and dynamic group rec-
ognition model. Such group providers will be deployed in smart spaces, hence place-based and
identify groups dynamically. The trigger is initiated by context change within the user environ-
ment. They employ a complex reasoning model.


6.1.2   Group Management Service Enabler
Service enablers are components which perform a set of generic control functions, used by ap-
plications and other service enablers. Traditionally, these enablers act as a bridge between the
content provider and content consumer. The group management enabler is used for the devel-
opment, deployment or operation of group-oriented services and provides standard APIs. The
group management service enabler has close interaction with context providers, specially the
group recognition context providers. A generic service enabler model is illustrated in Figure 6-2.



                Service Enabler
                                                Enabler Logic

                         Information Retrieval Model      Data Management Model

                        Subscription     Notification       Store     Manipulate



                       Context Consumer-                Service Enabler
                       Provider Interface               Interface




                    Figure 6-2: Implementing Context and Enabler Functions
The interface and communication paradigm between the group management service enabler
and group recognition context-aware provider is crucial to the WP3 architecture and will be
thoroughly analyzed and specified within this research activity. In addition, the interface
amongst other service enablers will be specified as well.


Group Characteristic
As mentioned in previous sections, groups can be formed in many different ways. Co-located
people could form a group easily by using Bluetooth or Near Field Communication on the cur-
rently used device, or it could be done manually by simply adding people to a group. However
they share some common characteristics. These are listed below as follow:
1. Group context: The context entities which defined the group, i.e. group of teenagers in city
   centre;
2. Group service: Associates the group with a service. In case on context-aware group creation
   this will be empty or a default service might be used;
3. Group priority: The group priority can be high, standard or low. The priority is useful during
   session and admission control;
4. Privacy Level/Scope: The group can be private, protected or public;


CONTEXT CASTING                                                                           Page   31
                                     Deliverable D6
      216462                                                                             C-CAST
                   Requirements and concepts for context casting service
                           enablers and context management

5. Life-time: A group can be permanent, temporal, i.e. it could exist for a short duration of time,
   or context-based, i.e. depends on a certain context value, e.g., location;
6. Creation timestamp: The time stamp when a group is created is stored.



6.2     Context-Aware Content Selection
As both platform components and the services built above the platform are likely to use this
function, it is best to implement the content selection as an enabler, using generic request-
response and subscribe-notify interaction. The interested components or services will request or
subscribe to the result of the content selection process. The service-level input necessary for
context selection will be provided through the use of a framework that the Context-Aware Con-
tent Selection Enabler (CACSE) will provide. The available content and its metadata will be
needed by the CACSE in order for it to do the selection. The context of single users can be re-
trieved if the CACSE behaves as a CC towards the CMA. In case of groups, the CACSE shall
retrieve the context that originated group formation from the Group Manager.
Any services and platform components may use the CACSE through request-response or sub-
scribe-notify interaction. The request-response interaction is tasked to getting the most suitable
content item, or ordered list of content items, at any moment in time, for a specified set of con-
text information and matching rules. The subscribe-notify interaction will focus on telling when is
it useful to transmit a certain content item to a group of users that have certain coincident con-
text.

                                             Service




                                       Configuration
                    Group
                                        Framework
                   Manager
                                      Context-Aware                        Context
                                                               Context
                                     Content Selection                   Management
                                                              Consumer
                                         Enabler                         Architecture
                   Content
                                 Request/         Subscribe
                   Metadata
                                 Response          /Notify
                                 Interface        Interface



                                    CACSE-dependent
                                      components



                     Figure 6-3: CACSE interfaces and functional dependencies


In request-response interaction [67], the request done to CACSE specifies the user or group for
which a content selection must be performed, and the service this delivery is associated to. Op-
tionally, the request can require a list of candidates along with their relevance rating. The re-
sponse, in turn, the content item identifier (or identifiers) and rating information, if requested. For
example, if a request for user “Bob” and service “News” comes in, the CACSE will have to
check what was the service-level input for service “News”, what is the context of user “Bob” and
return the most suitable content, that might be news for Bob's location.
For performance reasons, two different request-response interfaces may be provided. One that
only returns results based on pre-processed data, for time-critical requests, and another that re-
computes the ratings (if necessary).




CONTEXT CASTING                                                                                Page   32
                                    Deliverable D6
      216462                                                                         C-CAST
                  Requirements and concepts for context casting service
                          enablers and context management

The subscribe-notify model works in a slightly different manner. The CACSE will receive a sub-
scribe request with the required content and associated service. Optionally, the request will in-
dicate a threshold value for the calculated rating. The rating will be calculated based on rules
defined by that service, and the CACSE will send notifications to the subscribed components
when user or group context changes in a way that the rating for that content is increased to a
value above the threshold. For example if a new subscription request for content “The history of
the Eiffel Tower” and service “Paris Tourist Service” is done. Let us assume that the service-
level input rules for the “Paris Tourist Service” mean something like “deliver content about the
Eiffel Tower to users that are near there”. In this case, the CACSE shall trigger a notification
when a group of users that has been grouped because of their similar location is sufficiently
close to the Eiffel Tower
The returned content identification refers to the actual content item, and has nothing to do with
its format, resolution, or any other content property inherently addressed by the platform, agnos-
tic to the service above.
The service-level input is done at the service deployment. It comprises of a set of rules and be-
haviour configuration that define how important specific context information will be to the selec-
tion of the content. This service configuration may reference content metadata and context in-
formation extensions that are service-specific. Thus, content metadata and context information
representation should be easily extensible.



6.3     Context Reasoning and Interpretation
Summing up the presented literature review, the process of Context Reasoning/Inference com-
prises several abstraction levels and sub-steps. It is both layered and distributed amongst sev-
eral network entities. Figure 6-4 proposes an overview of the entire process and assigns appro-
priate mechanisms to the layers. They are borrowed from the areas of knowledge based sys-
tems and artificial intelligence.
Within the C-CAST CMS (cp. section 5) the context inference process is candidate to be em-
bedded into Context Providers. Figure 6-5 provides a view on an exemplar CP, focussing on the
reasoning and interpretation aspect. A CP may use internal data sources (such as profile data
bases) or may consume context information provided by other CP for aggregating, deriving and
providing its context information (defined by the context scope).
The internal context inference would then be composed of various Context Inference Building
Blocks (CIBB), each providing the functionality corresponding to one layer of the context infer-
ence process (cp. Figure 6-5).
The CP and the CIBB provide means for re-configuration. Control by re-configuration means
addition, modification or removal of rules and moreover the addition, modification or removal of
data sources. Approaches and concepts will be adopted from the research area of Service
Creation Environments (SCE).
Moreover, these elemental CIBB modules may be reused for accelerating the development of a
new CP.




CONTEXT CASTING                                                                           Page   33
                                      Deliverable D6
   216462                                                                                                                                 C-CAST
                    Requirements and concepts for context casting service
                            enablers and context management

                                             User Intention, User Goals i.e. high-level context

                                                 Intention Prediction, i.e. by Hidden-Markov

                                       User Activity, Environment States, i.e. mid-level context

                                                Event, State, Activity Recognition, e.g. based
                                                 on Rules, Neural and Bayesian Networks

                                     Extracted Features, i.e. low-level context (primitive context)

                             Feature extraction and grouping, e.g. by Kohonen-maps or fuzzy logic

                                          Aggregated, Filtered, Pre-Processed Sensor Data

                                         Fusion, Aggregation, i.e. removal of redundant data

                                                  Filtered and Pre-processed Sensor Data

                                    Filtering, Pre-processing, i.e. removal of noise and faulty data

                                                               Raw Sensor Data

                                                               Sensing, Sampling

                                                                  Real World



                                    Figure 6-4: Layered Context Inference Process



                                                         Developer



                                                  Context Detection Environment (CDE)

                      Context Inference Configuration                             Context Provider Development


                                                                          CP/CCIB control and                CP/CCIB control and
                    Context                                                (re-) configuration                (re-) configuration
                  Requirements
                                                              Context Provider (CP)
                            Output Context
                             Information                        Context Inference                                            Context
                                                                                                                            Context
                                                                                                                            Context
                                                                 Building Block          Output Context                   Provider (CP)
                                                                                                                         Provider (CP)
                                                                                                                         Provider (CP)
                                                                   (CIBB) #8              Information


                                                                Context Inference
             Context                                             Building Block
                              Context Request
            Consumer                                               (CIBB) #7
              (CC)
                                                                Context Inference
                     Context                                     Building Block              Context
                  Provider lookup                    Source        (CIBB) #5               Information
                                                      Data

              Context
                                                                                                         Input Context
            Broker (CB)                                                             Context                                  Context
                            Advertisement &                                                               Information       Context
                                                                                                                            Context
                              Registration          Data Source                    Consumer                               Provider (CP)
                                                                                                                         Provider (CP)
                                                                                                                         Provider (CP)
                                                                                     (CC)



                           Figure 6-5: Context Inference inside Context Provider




CONTEXT CASTING                                                                                                                              Page   34
                                    Deliverable D6
    216462                                                                           C-CAST
                  Requirements and concepts for context casting service
                          enablers and context management

7. Conclusion
In this deliverable the EU-ICT project C-CAST presented an overview of both state-of-the-art
and relevant research activities in the field of context-aware mobile communication systems.
Context-Awareness has been studied extensively for the last decade. However, there is still ur-
gent need for further investigation as highlighted by the identified research objectives C-CAST
is going to address.
The overall project goal is to evolve mobile multimedia multicasting to exploit the increasing in-
tegration of mobile devices with our everyday physical world and environment. An end-to-end
context-aware content provisioning system is envisaged. As a consequence, WP3 ("Context
Casting Service Enablers & Context Management") deals with the underlying context manage-
ment issues and an adequate way of making contextual information available for applications
and services. A general purpose context management system is targeted being able to be util-
ised for providing a large variety of context-aware applications and services.
Given this goal and related work, the following high-level research objectives have been identi-
fied and argued.
       An extendible and modular context management system needs to be provided. It should
       support both evolving context models and evolving services and applications. Context
       modelling and representation are subject of research but may concentrate on light-
       weight markup models rather than on complex ontologies. Besides of context acquisition
       and context modelling, C-CAST will elaborate performant context diffusion/distribution
       mechanisms tailored to mobile (cellular) communication systems. The federation of sev-
       eral context-aware systems is seen as promising approach for enabling scalability;
       Embedded Reasoning and Inference mechanisms need to be able to cope with rapid
       context changes and resource limited mobile devices. They need to offer robustness and
       support imprecise fast reasoning. In addition, an adaptation of the reasoning/inference
       process to available system knowledge, contextual information and service/application
       requirements is targeted in order to provide a scaling and efficient solution. In C-CAST
       an optimal and dynamic distribution of context processing amongst network entities and
       logical abstraction layers is investigated. Moreover, C-CAST will investigate how to se-
       lect and plug in machine learning algorithms to be applied to historic contextual informa-
       tion;
       Group Management and Group Recognition are seen as crucial elements for exploiting
       the full potential of context-aware systems. Dynamic ad-hoc recognition of groups allows
       in particular for emerging social community applications. Moreover, it connects the two
       technologies of context-awareness and multicast communication being the key pillars of
       the project. In particular, C-CAST aims at investigating group recognition models, repre-
       sentation and their implications on the context management system. In addition, the data
       and control exchange between group recognition and management, and between group
       management and context management system are subject of investigation;
       The provision of a generic Content Selection Framework is another important objective
       of C-CAST. Multimedia content should be selected for a user or group based on service-
       level input based on the context of the specified user or group. The context-aware con-
       tent selection shall also provide means for the most suitable ads for a user or group to
       be selected. The objective is to define a framework as generic as possible within the
       scope of content delivery platforms. Also, specific recommendation techniques will be
       analysed for use within this kind of recommendation system.




CONTEXT CASTING                                                                           Page   35
                                    Deliverable D6
    216462                                                                        C-CAST
                  Requirements and concepts for context casting service
                          enablers and context management

Besides of research objectives, this report presented first concepts for targeting the defined
goals. A modular context management system has been introduced based on a subject-based
consumer-producer role model. The system is built upon three basic functional entities: Context
Consumer, Context Broker and Context Provider. The deliverable presents draft concepts of
how reasoning/inference, group management/recognition and content selection can be realised
under the umbrella of this context management system.
In conclusion, we highlighted significant need for further innovation in context-aware mobile
communication systems. For finally deriving an end-to-end context-aware content provisioning
system, the context management system and the attached service enablers are essential ele-
ments.




CONTEXT CASTING                                                                        Page   36
                                      Deliverable D6
       216462                                                                          C-CAST
                    Requirements and concepts for context casting service
                            enablers and context management


References
[1]      Pellet: The Open Source OWL DL Reasoner. Available at: http://pellet.owldl.com/ [Ac-
         cessed April 30, 2008]
[2]      Adamopoulos, D., Pavlou, G. & Papandreou, C., 2002. Advanced service creation using
         distributed object technology. Communications Magazine, IEEE, 40(3), 146-154
[3]      Burghardt, C. & Kirste, T., 2007. Inferring intentions in generic context-aware systems. In
         Proceedings of the 6th international conference on Mobile and ubiquitous multimedia.
         Oulu,          Finland:         ACM,          pp.         50-54.        Available       at:
         http://portal.acm.org/citation.cfm?id=1329469.1329475&jmp=cit&coll=ACM&dl=ACM&C
         FID=59155803&CFTOKEN=90500365#CIT [Accessed March 13, 2008]
[4]      Castro, P. & Munz, R., 2000. Managing context data for smart spaces. Personal Com-
         munications, IEEE [see also IEEE Wireless Communications], 7(5), 44-46
[5]      Chen, G., Li, M. & Kotz, D., 2004. Design and implementation of a largescale context
         fusion network. In Proceedings of the First Annual International Conference on Mobile
         and Ubiquitous Systems: Networking and Services (MobiQuitous). Available at:
         http://citeseer.ist.psu.edu/chen04design.html [Accessed July 28, 2008]
[6]      Chen, H., 2004. An Intelligent Broker Architecture for Pervasive Context-Aware Sys-
         tems. University of Maryland
[7]      Dey, A., Salber, D. & Abowd, G., 2001. A conceptual framework and a toolkit for sup-
         porting the rapid prototyping of context-aware applications. Available at:
         http://citeseer.ist.psu.edu/dey01conceptual.html [Accessed July 28, 2008]
[8]      Dey, A. et al., 2004. A CAPpella: Programming by demonstration of context-aware appli-
         cations, Available at: http://citeseer.ist.psu.edu/dey04cappella.html [Accessed July 29,
         2008]
[9]      Dey, A.K., 2000. Providing architectural support for building context-aware applications. ,
         240. Available at: http://portal.acm.org/citation.cfm?id=932974 [Accessed June 9, 2008]
[10]     Gellersen, H., 2005. Smart-Its: computers for artifacts in the physical world. Commun.
         ACM, 48(3), 66
[11]     Giunchiglia, F., 1992. Contextual Reasoning, Trento, Italy. Available                     at:
         http://citeseer.ist.psu.edu/giunchiglia92contextual.html [Accessed April 24, 2008]
[12]     Henricksen, K., 2003. A framework for context-aware pervasive computing applications.
         Available at: http://espace.library.uq.edu.au/view/UQ:106832 [Accessed July 28, 2008]
[13]     Henricksen, K. et al., 2005. Middleware for Distributed Context-Aware Systems. In On
         the Move to Meaningful Internet Systems 2005: CoopIS, DOA, and ODBASE. pp. 846-
         863. Available at: http://dx.doi.org/10.1007/11575771_53 [Accessed June 13, 2008]
[14]     Korpipää, P. et al., 2003. Bayesian approach to sensor-based context awareness. Per-
         sonal Ubiquitous Comput., 7(2), 113-124
[15]     van Kranenburg, H. et al., 2006. A context management framework for supporting con-
         text-aware distributed applications. Communications Magazine, IEEE, 44(8), 67-74.
[16]     Laerhoven, K.V. & Aidoo, K., 2001. Teaching Context to Applications. Personal Ubiqui-
         tous Comput., 5(1), 46-49
[17]     Minsky, M., 2000. Common sense-based interfaces. Commun. ACM, 43(8), 66-73




CONTEXT CASTING                                                                             Page   37
                                       Deliverable D6
       216462                                                                         C-CAST
                     Requirements and concepts for context casting service
                             enablers and context management

[18]     Ranganathan, A., Al-Muhtadi, J. & Campbell, R., 2004. Reasoning about uncertain con-
         texts in pervasive computing environments. Pervasive Computing, IEEE, 3(2), 62-70
[19]     Serafini, L. & Tamilin, A., 2005. DRAGO: Distributed Reasoning Architecture for the Se-
         mantic Web. In The Semantic Web: Research and Applications. pp. 361-376. Available
         at: http://dx.doi.org/10.1007/11431053_25 [Accessed April 18, 2008]
[20]     Singh, M.P., Yu, B. & Venkatraman, M., 2001. Community-based service location.
         Commun. ACM, 44(4), 49-54
[21]     Smith, M.K., Welty, C. & McGuineess, D.L., OWL Web Ontology Language Guide.
         Available at: http://www.w3.org/TR/owl-guide/ [Accessed July 28, 2008]
[22]     Sohn, T. & Dey, A., 2003. iCAP: an informal tool for interactive prototyping of context-
         aware applications. In CHI '03 extended abstracts on Human factors in computing sys-
         tems. Ft. Lauderdale, Florida, USA: ACM, pp. 974-975. Available at:
         http://portal.acm.org/citation.cfm?id=766102 [Accessed July 28, 2008]
[23]     Van Laerhoven, K. & Cakmakci, O., 2000. What shall we teach our pants? In Wearable
         Computers, 2000. The Fourth International Symposium on. pp. 77-83.
[24]     Wang, X. et al., 2004. Ontology based context modeling and reasoning using OWL. In
         Pervasive Computing and Communications Workshops, 2004. Proceedings of the Sec-
         ond IEEE Annual Conference on. pp. 18-22
[25]     Weiser, M., 1995. The computer for the 21st century. In Human-computer interaction:
         toward the year 2000. San Francisco, CA, USA: Morgan Kaufmann Publishers Inc., p.
         933―940
[26]     Winograd, T., 2001. Architectures for Context. Human-Computer Interaction, 16(2), 401
[27]     Zimmermann, A., 2007. Context Management and Personalisation. , 260
[28]     17/01/2008, Annex I – Description of Work, C-CAST
[29]     MobiLife, an Integrated Project in European Union‟s IST 6th Framework Programme,
         http://www.ist-mobilife.org
[30]     Service Platform for Innovative Communication Environment (SPICE), An Integrated
         Project in European Union‟s IST 6th Framework Programme, http://www.ist-spice.org
[31]     Open Platform for User-centric service Creation and Execution OPUCE), An Integrated
         Project in European Union‟s IST 6th Framework Programme
[32]     C-MOBILE, a STREP Project in European Union‟s IST 6th Framework Programme,
         http://c-mobile.ptinovacao.pt
[33]     C-CAST, D10, Requirements and Global Reference Architecture, March 2009
[34]     Celentano, A.; Gaggi, O., "Context-aware design of adaptable multimodal documents,"
         Multimedia Software Engineering, 2004. Proceedings. IEEE Sixth International Sympo-
         sium on , vol., no., pp. 427-434, 13-15 Dec. 2004
         http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=1376691&isnumber=30047
[35]     Kurz, B.; Popescu, I.; Gallacher, S., "FACADE - a framework for context-aware content
         adaptation and delivery," Communication Networks and Services Research, 2004. Pro-
         ceedings. Second Annual Conference on , vol., no., pp. 46-55, 19-21 May 2004
         http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=1344710&isnumber=29617
[36]     Brunato, M.; Battiti, R., "PILGRIM: A location broker and mobility-aware recommenda-
         tion system," Pervasive Computing and Communications, 2003. (PerCom 2003). Pro-


CONTEXT CASTING                                                                          Page   38
                                      Deliverable D6
       216462                                                                          C-CAST
                    Requirements and concepts for context casting service
                            enablers and context management

         ceedings of the First IEEE International Conference on , vol., no., pp. 265-272, 23-26
         March 2003
         http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=1192749&isnumber=26747
[37]     Chen A., “Context-Aware Collaborative Filtering System: Predicting the User‟s Prefer-
         ence in the Ubiquitous Computing Environment,” Location- and Context-Awareness,
         2005, pp. 244-253
         http://dx.doi.org/10.1007/11426646_23
[38]     Park, H.; Yoo, J.; Cho, S., “A Context-Aware Music Recommendation System Using
         Fuzzy Bayesian Networks with Utility Theory,” Fuzzy Systems and Knowledge Discov-
         ery, 2006, pp. 970-979
         http://dx.doi.org/10.1007/11881599_121
[39]     Want, R., Hopper, A., Falcao, V. and Gibbons, J. (1992) „The active badge location sys-
         tem‟, ACM Transactions on Information Systems, Vol. 10, No. 1, pp.91–102.
[40]     Abowd, G.D., Atkeson, C.G., Hong, J., Long, S., Kooper, R. and Pinkerton, M. (1997)
         „Cyberguide: a mobile context-aware tour guide‟, Wirless Networks, Vol. 3, No. 5,
         pp.421–433.
[41]     Sumi, Y., Etani, T., Fels, S., Simonet, N., Kobayashi, K. and Mase, K. (1998) „C-map:
         Building a context-aware mobile assistant for exhibition tours‟, Community Computing
         and Support Systems, Social Interaction in Networked Communities, Springer-Verlag,
         UK, pp.137–154.
[42]     Cheverst, K., Davies, N., Mitchell, K., Friday, A. and Efs-tratiou, C. (2000) „Developing a
         context-aware electronic tourist guide: some issues and experiences‟, Proceedings of
         the SIGCHI conference on Human Factors in Computing Systems, ACM Press, New
         York, USA, pp.17–24.
[43]     Schilit, B. and Theimer, M. (1994) „Disseminating active map information to mobile
         hosts‟, IEEE Network, Vol. 8, No. 5, pp.22–32.
[44]     Ryan, N., Pascoe, J. and Morse, D. (1997) „Enhanced reality fieldwork: the context-
         aware archaeological assistant‟, Proceeding of the 25th Anniversary Computer Applica-
         tions in Archaeology
[45]     Dey, A.K. (1998) „Context-aware computing: the CyberDesk project‟, Proceedings of the
         AAAI, Spring Symposium on Intelligent Environments, Menlo Park, CA, pp.51–54.
[46]     Hull, R., Neaves, P. and Bedford-Roberts, J. (1997) „Towards situated computing‟, Pro-
         ceeings of the First International Symposium on Wearable Computers (ISWC „97),
         p.146.
[47]     Brown, P.J. (1996) „The stick-e document: a framework for creating context-aware appli-
         cations‟, Proceedings of the Electronic Publishing, Palo Alto, pp.259–272.
[48]     Dey, A.K. and Abowd, G.D. (2000) „Towards a better understanding of context and con-
         text-awareness‟, Proceedings of the Workshop on the What, Who, Where, When and
         How of Context-Awareness, ACM Press, New York.
[49]     Prekop, P. and Burnett, M. (2003) „Activities, context and ubiquitous computing‟, Special
         Issue on Ubiquitous Computing Computer Communications, Vol. 26, No. 11, pp.1168–
         1176.




CONTEXT CASTING                                                                             Page   39
                                      Deliverable D6
       216462                                                                         C-CAST
                    Requirements and concepts for context casting service
                            enablers and context management

[50]     Gustavsen, R.M. (2002) „Condor – an application framework for mobility-based context-
         aware applications‟, Proceedings of the Workshop on Concepts and Models for Ubiqui-
         tous Computing, Goeteborg, Sweden.
[51]     Hofer, T., Schwinger, W., Pichler, M., Leonhartsberger, G. and Altmann, J. (2002) „Con-
         text-awareness on mobile devices – the hydrogen approach‟, Proceedings of the 36th
         Annual Hawaii International Conference on System Sciences, pp.292–302.
[52]     Budzik, J. and Hammond, K.J. (2000) „User interactions with everyday applications as
         context for just-in-time information access‟, Proceedings of the 5th international Confer-
         ence on Intelligent User Interfaces, New Orleans, Louisiana, USA, pp.44–51
[53]     Finkelstein, L., Gabriolovic, E., Matias, Y., Rivilin, E., Solan, Z., Wolfman, G. and Rup-
         pin, E. (2001) „Placing search in context: the concept revisited‟, Proceedings of the 10th
         International World Wide Web Conference (WWW 10), Hong Kong.
[54]     Chen, H. (2004) An Intelligent Broker Architecture for Pervasive Context-Aware Sys-
         tems, PhD Thesis, University of Maryland, Baltimore County.
[55]     Ailisto, H., Alahuhta, P., Haataja, V., Kylloenen, V. and Lindholm, M. (2002) „Structuring
         context aware applications: Five-layer model and example case‟, Proceedings of the
         Workshop on Concepts and Models for Ubiquitous Computing, Goteborg, Sweden
[56]     Dey, A.K. and Abowd, G.D. (2001) „A conceptual framework and a toolkit for supporting
         rapid prototyping of context-aware applications‟, Human-Computer Interactions (HCI)
         Journal, Vol. 16, Nos. 2–4, pp.7–166.
[57]     Strang, T. and Linnhoff-Popien, C. (2004) A Context Modeling Survey, First International
         Workshop on Advanced Context Modelling, Reasoning and Management, UbiComp.
[58]     Gu, T., Pung, H.K. and Zhang, D.Q. (2004a) „A middleware for building context-aware
         mobile services‟, Proceedings of IEEE Vehicular Technology Conference (VTC), Milan,
         Italy.
[59]     Fahy, P. and Clarke, S. (2004) „CASS – a middleware for mobile context-aware applica-
         tions‟, Workshop on Context Awareness, MobiSys 2004.
[60]     Dey, A.K. and Abowd, G.D. (2001) „A conceptual framework and a toolkit for supporting
         rapid prototyping of context-aware applications‟, Human-Computer Interactions (HCI)
         Journal, Vol. 16, Nos. 2–4, pp.7–166.
[61]     Biegel, G. and Cahill, V. (2004) „A framework for developing mobile, context-aware appl
         cations‟, Proceedings of the 2nd IEEE Conference on Pervasive Computing and Com-
         munication, pp.361–365.
[62]     Brezillon, P. (2003) „Context Dynamic and Explanation in Contextual Graphs‟, Modeling
         and Using Context (CONTEXT-03), Springer Verlag p. 94-106.
[63]     Ryan N. „ConteXtML: Exchanging contextual information between a Mobile Client and
         the FieldNote Server‟, http://www.cs.kent.ac.uk/projects/mobicomp/fnc/ConteXtML.html.
[64]     Gonzalez A., Ahlers R. „Context based representation of intelligent behavior in training
         simulations‟, Trans. of the Society for Computer Simulation International, Vol. 15, No. 4,
         p. 153-166, 1999.
[65]     Bucur, O., Beaune, P. and Boissier, O. „Representing Context in an Agent Architecture
         for Context-Based Decision Making‟,
[66]     Henricksen K., Indulska J. and Rakotonirainy A. „Modeling Context Information in Perva-
         sive Computing Systems‟, Proc. First International Conference on Pervasive Computing
         2002, p. 167-180.


CONTEXT CASTING                                                                            Page   40
                                     Deliverable D6
       216462                                                                      C-CAST
                   Requirements and concepts for context casting service
                           enablers and context management

[67]     WP3_PTIN_ContextAwareContentSelectionContributionToD6-image.vsd
[68]     Strang, T. & Linnhoff-Popien, C. (2004) A Context Modeling Survey. In: Workshop on
         Advanced Context Modelling, Reasoning and Management, UbiComp 2004 - The Sixth
         International Conference on Ubiquitous Computing, Nottingham/England.
[69]     Baldauf, M., Dustdar, S. & Rosenberg, F. (2007) A survey on context-aware systems.
         International Journal of Ad Hoc and Ubiquitous Computing, 2(4), 263-277.
[70]     Composite          Capabilities/Preferences        Profile        Home           Page,
         http://www.w3.org/Mobile/CCPP
[71]     Goix, L. et al., (2007) Situation Inference for Mobile Users: A Rule Based Approach. In
         Mobile Data Management, 2007 International Conference on. pp. 299-303.
[72]     Moltchanov, B. et al. (2008) Context-Aware Content Sharing and Casting. ICIN 2008
         Proceedings, Bordeaux, France.
[73]     Sheng, Q. & Benatallah, B. (2005) ContextUML: a UML-based modeling language for
         model-driven development of context-aware Web services. In Mobile Business, 2005.
         ICMB 2005. International Conference on. pp. 206-212.
[74]     Hofer, T. et al. (2003) Context-awareness on mobile devices - the hydrogen approach. In
         System Sciences, 2003. Proceedings of the 36th Annual Hawaii International Confer-
         ence on.
[75]     Eiter, T. et al. (2008) Rules and Ontologies for the Semantic Web. In Reasoning Web.
         pp. 1-53.
[76]     Ejigu, D., Scuturici, M. & Brunie, L. (2007) Semantic approach to context management
         and reasoning in ubiquitous context-aware systems. In Digital Information Management,
         2007. ICDIM '07. 2nd International Conference on. pp. 500-505.
[77]     Pils, C., Roussaki, I. & Strimpakou, M. (2007) Distributed Spatial Database Management
         for Context Aware Computing Systems. In Mobile and Wireless Communications Sum-
         mit, 2007. 16th IST. pp. 1-5.
[78]     Hyunjun Chang, Seokkyoo Shin & Changshin Chung (2007) Context Life Cycle Man-
         agement Scheme in Ubiquitous Computing Environments. In Mobile Data Management,
         2007 Interna-tional Conference on. pp. 315-319.
[79]     Anagnostopoulos, C. & Hadjiefthymiades, S. (2008) Enhancing Situation-Aware Sys-
         tems through Imprecise Reasoning. Mobile Computing, IEEE Transactions on, 7(10),
         1153-1168.
[80]     Anagnostopoulos, C.B., Pasias, P. & Hadjiefthymiades, S., 2007. A Framework for Im-
         precise Context Reasoning. In Pervasive Services, IEEE International Conference on.
         pp. 181-184.
[81]     Frank, K., Röckl, M. & Robertson, P. (2008) The Bayeslet Concept for Modular Context
         Infer-ence. In Mobile Ubiquitous Computing, Systems, Services and Technologies, 2008.
         UBI-COMM '08. The Second International Conference on. pp. 96-101.
[82]     Ramparany, F. et al. (2007) An open context information management infrastructure the
         IST-amigo project. In Intelligent Environments, 2007. IE 07. 3rd IET International Con-
         ference on. pp. 398-403.
[83]     Dobson,      S.   &    Nixon,   P.,    Pervasive   Adaptation.   Available            at:
         http://www.perada.eu/summer-school/6-perada-summer-school-2008-pervasive-
         adaptation [Accessed November 21, 2008].



CONTEXT CASTING                                                                         Page   41
                                      Deliverable D6
       216462                                                                        C-CAST
                    Requirements and concepts for context casting service
                            enablers and context management

[84]     M. Roman et al. (2002) “GAIA: A Middleware Infrastructure to Enable Active Spaces,”
         IEEE Pervasive Computing, vol. 1, no. 4, 2002, pp. 74–83
[85]     TS 22.146 (2006) „Multimedia broadcast/multicast service; Stage 1 (Release 8)‟, 3GPP,
         v8.1.0
[86]     DVB-H (2004) „DVB-Handheld: IP broadcasting to handheld devices based in DVB-T‟,
         White Paper, http://www.dvb.org/documents/white-papers/wp07.DVB-H.final.pdf
[87]     Liu, J., Sailha, F., Sacchetti, D. & Issarny, V. (2005) „Group management for mobile ad
         hoc networks: design, implementation and experiment‟, Proc. Mobile Data Management
[88]     Prakash, R. & Baldoni, R. (1998) „Architecture of group communication in mobile sys-
         tems‟, 17th IEEE Symp. On Reliable Distributed Systems, pp. 235-242
[89]     Bottazzi, D., Corradi, A. & Montanari, R., (2005) „A context-aware group management
         middleware to support resource sharing in MANET environments‟, Proc. ACM MDM
[90]     Ferscha A., Holzmann, C. & Oppl, S., (2004) „Context Awareness for Group interaction
         support‟, Proc. 2nd Int‟l Work. Mobility Manage. & Wireless Access Protocols, pp. 88 – 97
[91]     Chen, H., Finin, T. & Joshi, A. (2003) „An Intelligent Broker for Context-Aware Systems‟,
         Article, Adjunct Proceedings of Ubicomp 2003




CONTEXT CASTING                                                                           Page   42

								
To top