environment's network infrastructure. Applications and services may belong to a. 'personal' zone (e.g. sharing of data on one's own PDA). More often they are.
Ambient Intelligence G. Riva, F. Vatalaro, F. Davide, M. Alcañiz (Eds.) IOS Press, 2005, http://www.ambientintelligence.org
5
Context-Awareness for Physical Service Environments Giovanni CORTESE, Massimiliano LUNGHI, Fabrizio DAVIDE
Abstract. Over the next few years, mobile computing, sensing technologies, and distributed middleware will combine to create a new generation of adaptive, context-aware services. Context sensing infrastructures will be deployed in Physical Service Environments such as airports, conference centers, government agencies, and services. These infrastructures will use the wealth of information generated by sensors to better serve the needs of mobile users, including visitors and people and businesses operating in the physical environment. In this paper we describe Physical Service Environments, which combine pervasive computing and context awareness to deliver enhanced, highly usable services to mobile users. At the communications layer, this kind of pervasive computing will require adaptive access technologies, ad-hoc networking and architectures to achieve seamless interoperability among wireless technologies. As far as concerns middleware, innovative architectures for pervasive computing will enable mobile clients, sensors and application servers to interact in the physical service environment. But context-aware service environments also require a well designed, standardizable architecture for the management of context information. Unfortunately, while good design alternatives for context architectures already exist, it will be a long time before standard, interoperable context information management becomes a reality.
Contents 5.1 5.2 5.3 5.4
Introduction ................................................................................... 72 Managing diversity in pervasive computing environments .......... 75 The design of context-aware application ...................................... 81 Summary and conclusions…………………………………………….......92 References ..................................................................................... 93
71
G. Cortese, et al. / Context-Awareness for Physical Service Environments
5.1
72
Introduction
With the rapid deployment of wireless LAN connectivity in the private and public sectors, opportunities for businesses to offer services to users moving within their physical premises with portable computers (including PDAs and smart phones) are increasing. At the same time, emerging sensing and semantic interpretation technologies enable the implementation of presence, identity and localization services that are key enablers for the types of pervasive, context-aware services we envision. Also, a variety of low cost sensors can easily be embedded in the environment and in user devices. Possible service providers include companies owning (or operating their business within) conference / training centers, shopping centers, airports or stations. In the public sector, government agencies and hospitals provide additional examples of environments that may provide contextualized services to visitors. We refer to these kinds of space as ‘physical service environments1. Physical service environments provide services that are enhanced by knowledge of the physical environment: for example, the distance between users and objects located in this space, position of users, and specific characteristics of environment and user. A physical environment seamlessly integrates the services provided by the computing devices it contains. These are likely to include sensors, embedded systems and portable devices owned by mobile users as well as more traditional application servers running in a separate computer room, or remotely on a “grid”. Service users operating in physical service environments may include, members of the organization owning the environment, who can use the service infrastructure to perform management tasks, surveillance, and other activities, as well as visitors from outside. The major classes of services that a physical service environment can deliver include: • • • • •
Information provisioning: delivery of personalized, context-dependent content Physical environment awareness and control: access to information collected from sensors (e.g. video from cameras, events from presence sensors, smoke detectors) and control of the physical environment (e.g. open/close doors) Remote work support: access to personal data stores and services for users visiting the environment Collaborative work support: sharing information among users and service components present in the environment (e.g. by generating a context-based virtual shared data space) Sharing or leasing of networked devices and appliances, e.g. printers, fax machines, etc.
The guiding vision of our research is to make the physical world interact with the digital world of services and applications by collecting data from heterogeneous sensors in the environment, and bringing this data together in an ‘intelligent’ way. To implement this goal, we will develop a standardizable infrastructure, supporting the development and delivery of services, in which mobile users interact with the environment around them and in which the environment reacts intelligently to the needs and perceptions of users.
1
This term emphasizes our focus on ‘service’ and on the technologies which enable effective service development and provisioning. We thus prefer it to other frequently used terms such as ‘smart space’ or ‘smart environment’
G. Cortese, et al. / Context-Awareness for Physical Service Environments
73
5.1.1 Scenario for Physical Service Environments We begin by describing the main characteristics of a Physical Service Environment. Personal Device: The user is equipped with a portable personal device (e.g. PDA, smartphone, wearable computer, or - more generally - a set of interconnected wireless devices forming a Body Area Network). The device or devices adapt dynamically to different radio protocols. Network Architecture: The user moves within a space where heterogeneous wireless communications islands form an extension of the wired network. User devices interconnect using ad hoc or infrastructure-based wireless networks. They may also connect to devices, sensors and services present in the environment. Service Provisioning: In the envisioned service model, the user moves through ‘environments’ within which she can use local services provided by the environment and by wireless connectivity resources. These services are delivered by devices embedded within the environment and by application servers accessible over a network infrastructure. Another group of potential service providers are other mobile users with whom the user comes into contact in the environments visited, either in ad hoc mode or via the environment’s network infrastructure. Applications and services may belong to a ‘personal’ zone (e.g. sharing of data on one’s own PDA). More often they are environmental (e.g. local information services delivered by an environment). These services may include both paying services and services that are available free of charge. Digital Environment
City services
Airport services
Home services
Vehicular services
Supermarket services
Office services
Train services
Ambient Intelligence
Office
Supermarket City monument Home
Train
CITY Airport
Real Environment
Figure 5.1. Physical Service Environments
Sensing Architecture: To support the delivery of these services, environments are ‘augmented’ with heterogeneous sensors. These allow the extraction of context information making interaction with the user and service delivery more efficient. The sensors capture information continuously, taking into account users’ activities. They then communicate the information to an “ambient intelligence” module which processes context information and distributes it to applications. Sensors may include both traditional sensing devices (e.g temperature, pressure, light and humidity sensors), and more complex devices such as cameras connected to a wired network. Since users’ personal devices are often able to capture data from the physical world (e.g. through GPS and other position sensors,
G. Cortese, et al. / Context-Awareness for Physical Service Environments
74
IRDA receivers, RFID Tag readers, Webcams) they too can be considered as sensors. The ambient intelligence infrastructure should thus be capable of using information sensed by user devices. Modes of Interaction between the User and the Services: The user interacts with services through a multimodal user interface, which uses the personal device’s resources to communicate with the user. Alternatively the interface may use I/O devices embedded within the environment. Communication between the user and services (or other users) may be mediated by a ‘Personal Agent’ belonging to the user. This is an application with reasoning capabilities. The task of the Personal Agent is to filter information and provide intelligent support for the management of interpersonal communications. In this scenario, services adapt to the situation of the user in the environment. 5.1.2.
Context-awareness and pervasive computing
This “scenario” – like all pervasive computing environments – implies a number of challenges. As Ferscha [1], quoting Mark Weiser’s work [2], has put it: “…The most profound technologies are those that disappear. They weave themselves into the fabric of everyday life until they are indistinguishable from it“ was Mark Weiser’s central statement in his seminal paper in Scientific American in 1991. His conjecture, that “we are trying to conceive a new way of thinking about computers in the world, one that takes into account the natural human environment and allows the computers themselves to vanish into the background” has fertilized the embedding of ubiquitous computing technology into a physical environment which responds to people’s needs and actions. Most of the services delivered through such a “technology-rich” environment are services adapted to context, particularly to the person, the time and the place of their use. Along Weiser’s vision, it is expected that context-aware services will evolve, enabled by wirelessly ad-hoc networked, mobile, autonomous special purpose computing devices (i.e. “smart appliances”), providing largely invisible support for tasks performed by users. It is expected that services with explicit user input and output will be replaced by a computing landscape sensing the physical world via a huge variety of sensors, and controlling it via a manifold of actuators in such a way that it becomes merged with the virtual world. Applications and services will have to be greatly based on the notion of context and knowledge, will have to cope with highly dynamic environments and changing resources, and will need to evolve towards a more implicit and proactive interaction with users…” Pervasive computing environments are characterized by interactions among large numbers of small, heterogeneous, at least partially autonomous, embedded and mobile devices. These devices use ‘peer to peer’ mechanisms to communicate with each other, and with the surrounding infrastructure (e.g. a local intranet or Internet). So, what does this imply in terms of context-awareness? According to Ferscha, “Context-aware environments intelligently monitor objects in the real world, and interact with them in a pro-active, autonomous, responsible and userauthorized way … Context-awareness refers to the ability of the system to recognize and localize objects as well as people and their intentions”. Another definition of context proposed by A. Dey ([2], [4]) reflects the vision we proposed in the introduction to this paper: “… Context is any information that can be used to characterize the situation of an entity.
G. Cortese, et al. / Context-Awareness for Physical Service Environments
75
An entity is a person, place, or object that is considered relevant to the interaction between a user and an application, including the user and applications themselves …”
Typically, a context-aware service uses context information to: • • • •
5.1.3
Automatically deploy services for a user or control an environment Associate context information with other information, allowing subsequent access to this based on “contextual” search criteria (e.g. “find all information relevant to this place”) Personalize modes of interaction between the user and the service Select services relevant to the user in a given environment or situation (ContextAware service discovery and provisioning). Outline of the paper
In this paper, we analyze the challenges we have to meet if we wish to deliver a seamless Physical Service Environment that achieves the ‘calm computing’ vision outlined by Mark Weiser, also through building and exploiting a model of situations happening within the environment. Such a service environment should allow a user to access services provided by a mesh of people, objects and places, minimizing interoperability issues due to technology diversity and with minimal user involvement or distraction. Such services should be programmed to be adaptive to changes in user and environment state. From a different point of view, the networking and transmission infrastructure should exploit its awareness of the current status of environment, and its understanding of the goals of the communication, to save energy, and to achieve more efficient communication. This is especially important for wireless networking, sensor networks and in general in situations where dynamic communicating entities are constrained by scarce resources. We have structured the paper around two complementary classes of requirements. In section two we describe technologies and architectures for seamless communication i.e. techniques to overcome technological diversity, delivering ‘calm computing’ to users and objects interacting in physical spaces. In section 5.3 we describe context-awareness in applications as a way to achieve simplified, more rewarding interaction among human and digital entities. Summary and conclusions, in section 5.4, close the paper.
5.2
Managing diversity in pervasive computing environments
When we speak of support infrastructures for context-aware systems, we refer to a scenario in which mobile users use wireless communications to interact with surrounding networks, sensors, applications, services, and other users present in the environment. The enormous number of wireless network solutions currently available (see Figure 5.2) means that we will require an infrastructure capable of supporting services that can adapt to diversity at many different levels including: data transmission, management of energy resources, Quality of Service, user expectations and user profiles. Similarly, when the user “roams” between areas of an environment where the wireless connection is provided by different technologies (e.g. WI-FI and UMTS) how can we ensure that services automatically adapt to different network connections? How can we implement applications that have different ways of interacting with the user in different situations? How can we explain loss of service continuity to the user (e.g. loss of network connection,
G. Cortese, et al. / Context-Awareness for Physical Service Environments
76
disconnection of another user with whom the first user is interacting, lack of energy resources, etc.)? Applications E-MAIL WEB ACCESS
SMS CABLE REPLACEMENT
VIDEO VIDEO VOIP DOWNLOAD STREAMING ON DEM
Bluetooth
HOME, OFFICE, PUBLIC ACCESS
Ultra Wide Band 802.11a/g HiperLan/2
Range
Wi-Fi
CITY, SUBURBS COUNTRY WIDE
UMTS GPRS GSM 10 kbit/s
100 kbit/s
Source: Re:Think!, revised by M. Dècina, 2002
1 Mbit/s
Bandwidth
10 Mbit/s
100 Mbit/s 1 Gbit/s
Figure 5.2. Wireless Access Networks
Context-aware systems must necessarily take into account limitations and variations in computational and communications resources. Some devices (e.g. sensors) have miniaturization requirements which lead to constraints on resources. In general, portable devices rely on their own energy resources. This means that we need to balance computational capabilities, GUI, communications, bit-rates and battery life. We also need to bear in mind that resources - especially network resources for wireless communications - may vary dynamically. For example, if we pass from an area covered by 80211.b to a connection based on a mobile network, the available bandwidth will change considerably. In this section, we analyze issues related to adaptivity, interoperability, and management of technology and service diversity in this kind of dynamic computing scenario. For the system to adapt to a rapidly changing environment, the technological infrastructure must itself be context-aware and adapt constantly to ambient conditions. Adaptation must take place as far as possible without the intervention of the user. It is the task of the “infrastructure” to provide these capabilities. Seamless communication requires an interplay between layers in the architecture, from the physical up to the applications level. In what follows, we try to show how cross-layer interactions allow devices to set up associations, engage in sophisticated interactions, and keep communications alive in spite of mobility, scarcity of resources and other challenges. 5.2.1
Communications and Networking
The need to communicate easily on the move, even in environments with no network infrastructure to mediate communication between users, has led to the idea of ad-hoc networking. Current research sees ad hoc networks as “mobile extensions” of the Internet in environments with no network infrastructure. Ad hoc networking is a fundamental step towards achieving the goal of uninterrupted ubiquitous communications [50]. Below, we discuss current research on ad hoc networking and related technologies of relevance to Context-aware systems. We concentrate on these rather than infrastructure-based networks (including wireless networks) because they are more innovative and will therefore be of greater interest to readers.
G. Cortese, et al. / Context-Awareness for Physical Service Environments
5.2.1.1
77
Adaptive access
Let us consider a person equipped with one or more mobile personal devices who is moving around a series of intelligent environments. As she moves, these devices come into contact with a potentially large and heterogeneous set of other devices with wireless connectivity. Devices in specific areas of the environment, automatically indicate to the user - on the physical level - the presence of one or more communications standards (e.g. IEEE 802.11b, Bluetooth, 2G and/or 3G mobile standards and UWB). Devices may do this by determining the air interface, the type of modulation etc. They then intelligently select the most appropriate standard for establishing a connection between the user and the environment. The Software Defined Radio (SDR) [42] approach addresses this scenario. To implement adaptivity through SDR, it will be necessary to develop signal processing technologies that can provide a high degree of terminal reconfigurability, allowing terminals to take account of the multimodal reception/transmission context. More specifically, SDR technology allows dynamic, adaptive management of transmission resources (modulation, bit-rate, etc), based on channel conditions and the type of information transmitted. In this way the technology guarantees dynamic, user-friendly management of the physical layer of the transmission channel. This allows the implementation of transmission/reception architectures which are totally reconfigurable and strongly adaptive. 5.2.1.2
Network Layer: Interconnected MANETs
In classic network architectures, protocols and network responsibilities are organized in a rigid layered structure (OSI stack). The application of this type of organization to ad hoc networking has many advantages. These include: 1) the use of IP; 2) the multi-hop nature of the ad hoc network, where each node is a potential router for traffic with other nodes; 3) the flexibility provided by independent layers. These advantages have led to the adoption of this framework in Mobile Ad hoc NETworks (MANETS). However, it should be pointed out that these design principles also have disadvantages. 1) energy management, security and cooperation issues affect the entire protocol stack and cannot be resolved within individual layers; 2) ad hoc networks and the Internet have contrasting limitations. The former are dynamic whereas the latter is relatively static. These problems can be resolved by: •
Cross-layering. The IETF MANET Working Group has shown that “vertical” communications within the protocol stack improves the performance of ad hoc networks [41].The practice of accessing not only the layer immediately above or below a given layer in the protocol stack, but every other layer, is known as crosslayering. The introduction of cross-layer modules is particularly important for Context-aware systems. This technology represents a first step towards Contextaware Networking as well as allowing efficient management of network resources. More specifically, all layers in the protocol stack can supply cross-layer modules with information on network topology, energy levels, the position of the device, etc.. This allows us to implement local real-time optimization of protocol behavior, reducing overheads. This information can also be supplied to the middleware and application layers, allowing them to adapt their output to network conditions [43]. Cross-layering thus produces an improvement in system performance. However, it
G. Cortese, et al. / Context-Awareness for Physical Service Environments
•
•
78
should also be recognized that cross-layering also reduces the architectural flexibility given by the OSI stack’s layered organization “Energy-Aware” Protocols. Studies of ad hoc networks have concentrated on solutions allowing efficient management of energy resources on the terminal. This requirement is particularly important for sensor networks, where nodes have stringent energy and computational requirements. As a result, it is necessary to design MAC and routing algorithms that take account of these requirements [44] Overlay Network. It is also important to study techniques for rearranging network topology on an overlay basis. This allows us to maintain an optimal topology as network congestion and connectivity change [48]. Current MANETs use Dynamic Source Routing (DSR) protocols. However, the calculation of routing paths from one node to another introduces a heavy overhead. As a result, protocols of this type do not guarantee the scalability required to support large numbers of network nodes. Solutions capable of guaranteeing the required scalability have been identified by studies on new routing protocols such as Dynamic P2P Source Routing (DPSR), PeerNet, based on peer2peer (p2p) and overlay networking technologies e.g. Pastry, CAN, Chord e Tapestry) [45]. Publish/subscribe middleware can be efficiently layered on top of an overlay network. SCRIBE [46] and BAYEAUX [47] are examples of middleware that uses the overlay network to build efficient distribution trees, and includes additional mechanisms (leveraging those provided by the routing overlay) to maintain and repair the tree when nodes join or leave the network. It has been shown that such systems can be scaled to support networks with large numbers of peers, and a high degree of ‘churn’. As a consequence, they are good candidates for the communications backbone connecting peers in pervasive environments. Current studies in this area are developing technologies which make it possible to build applications which work well in ad-hoc networking environments while providing transparent handling of failures and seamless communications for users. The reader should note that, although we will not cover overlay network technology further in this paper, peer-to-peer overlays are being actively researched also as a technique for addressing application layer challenges in pervasive computing environments.
The definition of protocols allowing effective and user-friendly bridging between different networks at the IP level is of fundamental importance. The VICom project [38] has taken a step in this direction by developing a system for the management of ad-hoc multi-technology networks based on the cross-layering principle. 5.2.1.3
Transmission of Sensor Data
The wireless transmission technology for sensor networks differs from WLAN because it was designed for different purposes. Since interaction between the user and the surrounding sensor networks has to take place in a way that the user can understand, it should be implemented through ad hoc configurations. Ad hoc networks allow the establishment of temporary, self-configuring communications. The network of sensors has to be based on technologies with extremely low energy consumption and low bit-rates. Sensors are characterized by limited information processing capabilities, limited energy resources and limited data storage. MOTE technology, currently at the prototype stage [49], is a promising area of research. Our research into the VICom Project [38] will thus concentrate on the definition of “light-weight” protocols for communication among
G. Cortese, et al. / Context-Awareness for Physical Service Environments
79
sensors, thereby minimizing the consumption of energy and bandwidth resources. We will also need to design efficient protocols for bridging/routing towards WPANs and WLANs. 5.2.2
The middleware layer
Figure 5.3. The Tower of Babel of communication and coordination protocols
Thanks to the technologies just discussed, mobile hosts will be able to dynamically network with devices belonging to other users, as well as with appliances, sensors and infrastructure-based services in the environments they visit. If they are to profit from these opportunities they will have to understand the services and information other components have advertised and use appropriate coordination mechanisms and middleware to access them effectively. The situation is complicated by the lack of a standard ‘language’ for service discovery and coordination understood by all players in the game (see Figure 5.3) We will now focus on service advertisement and discovery issues. 5.2.2.1
Discovery
There has already been a significant volume of research into service discovery in pervasive environments. Commercial protocols and middleware for this purpose (e.g. Jini, UPnP, Salutation, SLP) are already available. To date, however, none of these solutions has emerged as a clear winner. As a result the problem of managing the heterogeneity of devices remains unresolved. Protocols such as UPnP and Jini, often rely on physical proximity to establish associations between components. Such protocols provide a range of features, from relatively low level functionalities (such as UPnP AutoIP feature, which facilitates networking among devices), to higher level ones, such as advertisement and discovery of device-oriented services (e.g. printing) or application-oriented services. Jini, for example, is increasingly being used as middleware for distributed enterprise architectures. Alternative service-oriented architectures, such as Web Services [5], which are currently targeting service integration on the Internet and in enterprise architectures, use different technologies for discovery. Discovery mechanisms for Web Services (or in other service oriented architectures, such as GRIDs) aim to provide sophisticated search mechanisms with high precision of retrieval ([6], [7]). Research based on the ‘Semantic
G. Cortese, et al. / Context-Awareness for Physical Service Environments
80
Web’ ([8]) extends service description languages, allowing even more flexible matching between nodes providing and requesting services. These proposals help in achieving service interoperability even when service interfaces fail to match exactly or suffer from other kinds of incompatibility. 5.2.2.2.
Coordination
After setting up an association, two components need to communicate using a common protocol and known service interfaces. At the lowest level, a coordination model allows two entities to communicate via synchronous or asynchronous exchange of messages. These can be either direct or mediated by other entities. Coordination models define how to achieve sophisticated interactions between large numbers of interacting components. We consider two main families of coordination model, namely process-oriented and data-oriented models. Given the strength of industry support, Web Services will play a major role as far as process oriented models are concerned. Though initially developed for business applications, Web Services have the potential to become the ‘middleware of middleware2 for pervasive environments. A Web Service is a software component designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically, the Web Services Description Language, based on XML). Service Descriptions can be discovered by other software systems, which may then interact with the web service using XML messages conveyed by Internet protocols. The Web Service Description Language (WSDL), makes it possible to describe the abstract service interface separately from descriptions of (possibly multiple) mappings to concrete implementations of the service. Web Services architecture includes protocols both for simple request-response interaction and for more complex forms of coordination among components. For example, flexible transaction mechanisms help components to ‘undo’ actions when related actions fail; workflow languages help application designers to ‘orchestrate’ elementary services into complex process-oriented applications ([9]). Web Service architectures require the service interface to be known to both parties in the communication. Data oriented models aim at a lesser degree of coupling among interacting components. In publish-subscribe systems, communication involves the ‘publication’ of information to an event-dispatching middleware, which then distributes the information among all ‘subscribers’ to ‘similar’ messages. ‘Tuple spaces’ approaches offer greater flexibility. In these approaches, the system provides only a limited number of communication primitives (e.g. add tuples, read or extract tuples from the space); all applications write to the same ‘blackboard’ which is the basis for all subsequent interactions. In publish-subscribe and tuple space systems, communication between components is indirect; components do not know each another directly. It is obvious, however, that to obtain ‘intelligent’ behaviour at the application level components need to have some knowledge of the meaning of the data they are processing. An approach of this type thus requires standardization of the data which the components use to communicate. 5.2.2.3
Towards a unified architecture
Pervasive, mobile scenarios require an architecture that supports interoperability among components that have not been specifically designed to work together. 2
I.e. a layer providing an abstraction for different middleware implementations
G. Cortese, et al. / Context-Awareness for Physical Service Environments
81
Ideally, there should be a universally agreed architecture for service discovery and interaction. Such an architecture will result from a combination of standardization efforts, imposing constraints on the heterogeneity of middleware platforms, and innovation in middleware supporting greater adaptivity to diversity in coordination mechanisms (e.g. service oriented vs. tuple space) and in middleware implementations (e.g. SOAP vs CORBA). We are exploring Web Services as a standard framework for this kind of architecture. Though support for XML-based protocols can be an issue for pervasive devices with very limited resources, the number of platforms supporting support (e.g. embedded Java platforms) is increasing. In the medium term, then, protocol support will not be a major obstacle. Other service platforms for embedded systems also use Service Oriented Computing and are gaining in popularity ([10]). These platforms are reasonably close to the Web Service model and could be adapted to provide interoperability with Web Services. The use of Web Services to model service descriptions and for overall coordination (orchestration of elementary interactions and transactions) enjoys widespread industry acceptance. Web services could provide a basic architectural framework for pervasive environments. It would, however, be necessary to extend the current model to include additional features. For example, Web Services lack the ability to dynamically adapt the binding of abstract service interfaces to different concrete implementations (e.g. SOAP vs. RMI), to match the capabilities of other peers present in the environment. Ideally, adaptivity should also handle the differences between different coordination models (e.g. allow services programmed in a publish subscribe style to interoperate with services using remote procedure calls. One research project which tackles these issues is REMMOC ([11]). REMMOC assumes that client programs use a neutral, WSDL based interface to invoke services. The project uses what it calls “reflection” to achieve run-time adaptivity and interoperation among different middleware implementations. This approach allows services to be discovered and invoked despite possible diversities. WSIF (Web Services Invocation Framework) is another approach allowing a client to be programmed in a way which is neutral with respect to the current binding. In this case the key aim is to ensure design time compatibility. To summarize, service discovery and applications are converging towards a single, service-oriented architecture (based on best-of-breed mechanisms from Web Services, Grid, the Semantic Web, and OSGi). This architecture will scale from the needs of resource limited devices to those of applications based on powerful hosts. What we are still missing are architectural models capable of merging a service-oriented style of application development with multicasting, group communications, and data oriented models.
5.3
Designing Context-aware Applications
In this section we analyse challenges in the implementation of a fundamental characteristic of services for physical service environments, namely context-awareness. Context-aware services are able to understand various aspects of the current situation and use them to interact with the user in a more intelligent way. The implementation of context-awareness is made possible by a combination of different technologies. First, we need appropriate sensing and data collection technologies, and (at a higher level) technologies for fusing, analysing and interpreting sensor data.
G. Cortese, et al. / Context-Awareness for Physical Service Environments
82
While it is clear that ‘there is more to context than location’ [12], location sensing technology remain extremely important. Efficient and scalable data management middleware for large scale distribution, storage and query of sensor data, is another key technology we will depend on. Technologies to look for in this area include general purpose distributed data management ([13]) and specialized sensor database techniques. ([14], [15], [16]). From a software engineering perspective, context-awareness requires mechanisms allowing easier implementation of applications and services which use context data, as well as design of reusable sensing components. Decoupling the sensing layer from applications is a key design principle for context-aware applications. To this end, software frameworks to simplify and standardize (for example, using appropriate patterns) the communication between applications, sensors and actuators, are needed. Also, to maximize the possibility that applications will be able to use context information from the environment, designers need to create standard and widely accepted models (ontologies) for context information, together with standard mechanisms for accessing these models. Technologies for Advanced Human Computer Interfaces have a strong relationship with context-awareness. These technologies facilitate users’ perception of (and interaction with) entities in the physical world and their virtual representations. When applications create virtual representations of natural objects, these should be ‘natural’. Actions performed on physical objects should affect their virtual counterparts, and vice versa. One important project exploring potential metaphors for integrating physical and virtual worlds is Cooltown [20]. One approach is to use ‘mixed’ and ‘augmented’ reality to transmit context information in an intuitive and natural way. Figure 5.4 (adapted from [18]) illustrates this technique.
Figure 5.4. Mixing synthetic and real world images
5.3.1
Context-aware Services
In current systems, human-machine interaction is mainly based on ‘explicit’ communications. The user communicates her processing requests to the computer at a certain degree of abstraction (e.g. by pushing a button on a menu or using voice commands to control a GUI).
G. Cortese, et al. / Context-Awareness for Physical Service Environments
83
By contrast, implicit communication would allow the computer to interpret the user’s behaviour and the context. This could provide the basis a new generation of services. In such services users would no longer interact with the computer via a single interface generated by the computer itself. Rather they would use a variety of input (sensor) and output devices (actuators). These would include mobile personal devices and/or devices embedded in the environment. A first step in this direction is to reduce the need for explicit interaction with the user. In interpersonal communications, we use a variety of information. With traditional HCI technology, on the other hand, users have very few mechanisms for providing input to the system. Obviously, we cannot expect users to explicitly input context information. This task will have to be performed by an infrastructure that captures and processes sensor data. By increasing the system’s ability to access context information, we create an opportunity for services that behave in an ‘intelligent’ way. Taking this approach to extremes, we might imagine a scenario where human machine interfaces disappear completely within the environment. By using context information designers can create user interfaces which are easier to use in a range of different situations [19]. For example, content can be adapted to terminal characteristics and network characteristics. Recent years have seen the introduction of new mobile devices for browsing the Web. Many of these devices have very different input and output capabilities and different levels of language support. Different mobile devices also have widely differing network connectivity capabilities. Users of these devices expect to be able to view data regardless of these capabilities. Likewise, they expect content and applications to systematically adapt to their preferences (e.g. turn audio on/off). Whereas, in reality, device heterogeneity, and the lack of a standard way for users to convey their preferences to the server means that in many cases they find content which is too large to be transmitted over the network or to be stored on their device, or which cannot be displayed or which is not the kind of content they want. W3C's Composite Capabilities/Preferences Profile (CC/PP) specification addresses these problems by allowing a client to encode its delivery context - device capabilities, user preferences, network characteristics, etc. - in such a way that a server can use the context to customize content for the device and user. Another issue for adaptable user interfaces is the need to adapt the user interaction to the user environment (e.g. by switching from voice-based to text-based interaction in the presence of high levels of noise). A more advanced example of context interpretation would be a User Interface based on gesture interpretation. 5.3.2
Modelling context information
We now go into more detail about what we mean by context information. In this section, we describe the main features of a model of context information, that captures the concepts we have been talking about in. In section 5.3.2.1, we will then look into possible architectural and implementation options for collecting the information specified by the model and making it available to context-aware services. The model we are about to describe has two main goals. The first is to create a common vocabulary, identifying typical relationships among context data; in this way the model will provide conceptual support to the designers of context-aware infrastructures. The second goal of the model is to lay the foundations for standards allowing the implementation of interoperable context-aware infrastructures and applications.
G. Cortese, et al. / Context-Awareness for Physical Service Environments
84
G. Cortese, et al. / Context-Awareness for Physical Service Environments
5.3.2.1
85
The Context Model – a conceptual view
The purpose of context information is to allow improved collaboration among entities and service components interoperating in a pervasive service environment (as described in section 5.3). A number of proposals for context information modeling have already been published, among which [23], [24], and [25]. Here, we present an informal overview of the model we have developed for the VICom project (Figure 5.5). The key entities in the model are, not surprisingly, people, objects/ devices, locations, services, and sensors. Italic words refer to entities in the model.
Figure 5.5. A logical model of context information
People: Information about people includes static information about users and visitors (for example, identity and user profiles, for access control or service personalization), and dynamic information describing people currently in the environment. A Person visiting an environment (a mobile user) may carry one or more Personal, Mobile Devices. Mobile users share information about themselves, including their position and movements, preferences, profiles, the history of past interactions with the services present in the environment, and application-specific data such as plans and schedules, and skill descriptions. The local service environment exploits this information to deliver adaptive services. Personal data typically includes identity, characteristics (physical, languages spoken, personal disabilities, …), capabilities, universal or context-specific preferences, and resources (such as owned devices). Dynamic context for mobile users, is acquired through location and other sensors, in the user device or in the environment, and may include:
G. Cortese, et al. / Context-Awareness for Physical Service Environments
• • • •
86
Position and trajectory Current activity, body gestures, patterns of device use Mood, emotional state ‘Digital’ context: information about current service sessions, and events during these sessions (e.g. navigation history, connections to network services etc.).
Other application-specific data may also be relevant for context-aware services e.g. Personal Information Manager data, address books, schedules. Knowledge management applications for example can exploit information about the user skills and interests.. For the sake of clarity the diagram only shows a few examples this kind of information. Places: Locations are typically arranged in containment hierarchies (e.g. cities, streets, buildings, rooms, corridors). These may be based on physical decomposition criteria (i.e. criteria reflecting the geometric properties of the space) or on logical criteria (i.e. any other criteria which may be significant for a specific application). Locations carry context information of their own. This may include data on temperature, humidity, brightness, sound levels, acquired by sensors in the environment. Given that entities such as people, devices, and objects live and move in physical space, locations can also be seen as ‘containers’ for other entities. This approach provides natural criteria for organizing and analyzing context information (for example, it may be convenient for an application to refer to ‘the average temperature of the first floor’ rather than to observations from individual sensors). The concept of location makes it possible to ‘fuse’ observations from sensors, transforming low-level sensor data into semantically meaningful information (‘situations’). Objects: What interests us here are ‘digital’ objects, which provide some kind of service to other components. Such devices may be mobile devices carried by users, or devices installed in the environment (including appliances, PCs, printers, or smart objects, i.e. physical objects augmented with some embedded computing capability, sensors). See the service provisioning section. Sensors: Dynamic information is collected by sensors. Sensors generate information about users, devices, applications, and the environment. Sensors can be standalone devices or they may be attached to wireless user devices (e.g. PDAs with GPS, motion sensors, a camera, a microphone etc.). Alternatively they can be ambient devices. Sensors produce ‘dynamic’ context in the form of timed observations and events. Situations Situations are produced by fusion agents which correlate input from sensors, applications, and user input to produce high level information. Situations bind sensor data, people, and objects to a spatial model of locations. Simple situations describe which people and objects are present in a given physical space. More complex situations might include descriptions of events involving multiple entities (e.g. “John and Mary are having a meeting in room 321”).
G. Cortese, et al. / Context-Awareness for Physical Service Environments
87
Service Provisioning: Devices (connected to other wireless devices) and application servers on connected networks provide services to users. Service Provisioning entities include application servers, embedded ambient devices (such as sensors or smart objects and appliances), and personal user devices. These are operated under policies defined by an owning ‘authority’ (a Service Provider). Services are divided into application-oriented services and deviceoriented services. Technically, a service can be anything ranging from a web service, a web (or client-server) application, or a functionality of a networked appliance (such as a projector) accessed through a peer-to-peer protocol such as UPnP. A service typically implies an access control, or payment schema. Sessions bind a user and a service instance. A session contains information about the status of a service instance, including user preferences and choices (e.g. use voice instead of web browsing, navigation history). 5.3.2.2
From conceptual models to implementation models
To move from concept to implementation we have to enhance our model with additional details, while maintaining an appropriate balance between generality and the needs of specific kinds of application (e.g. security, collaborative apps, entertainment, knowledge management, environmental control, building automation). It is easy to see that conflicting requirements from different types of applications make it difficult to create a single, standard ontology3 for context information. A more sensible approach is to build an extensible framework for context information management. Such a framework would include: • • •
A (set of) standard protocol(s) allowing applications to access context information A common ontology language A base ontology for common entities, attributes and relationships.
Different interest groups could then develop their own, applications or industry specific ontologies using the standard ontology language. This is similar to what has happened with network management based on the highly successful SNMP protocol and information modeling standard ([26],[27]). Candidate modeling languages include plain XML, RDF [28] or languages from the semantic Web community such as DAML+OIL [30] and Owl [29]. RDF, designed by the W3C Consortium, defines a mechanism for describing (Web) resources (meta-data), which enables “automated” processing of these resources. It provides a model for representing meta-data, and proposes XML as the syntax for this model. One of the goals of RDF is to specify semantics for XML-based data in a standardized, interoperable manner. The broad goal of RDF is to define a resource-description mechanism that makes no assumptions about the application domain or its semantics. The choice of protocols depend heavily on the adopted context management architecture. We will discuss this issue in the next section. We conclude this section by reviewing a number of existing information models and ontologies for some of the entities in the context model. It should be noted that these come from different communities (e.g. mobile telecoms, semantic web, software agents). This accounts for differences in their goals and modeling approach.
3
An ontology is a shared, usually machine-readable information model in a specific domain of interest
G. Cortese, et al. / Context-Awareness for Physical Service Environments
88
Location: There is a huge literature on the representation of location information. WGS-84 [31] provides broadly accepted formats for physical location (e.g. absolute location, grid based pairs). Other attributes may include vertical position and accuracy information.. JSR-179 [32] specifies an API to access position information on a mobile terminal. The API aims to be independent of any specific location technology. Geographical location is used to deal with natural geographic objects, and is more suitable than physical location for conveying spatial information to humans. In geometric models, locations and located objects are represented by sets of coordinate n-tuples, understood by humans as points, areas, and volumes. Symbolic models use abstract symbols to label locations in terms of country, city, zip code, postal address and so on. Existing systems often use mixed models ([33]). Services: Service modeling is currently the subject of extensive research. There are currently two main camps. The Web Services community bases service descriptions on the WSDL standard, and proposes UDDI for service discovery. Additional insight into service characteristics can be gained by accessing process models described in process description languages such as BPEL. The agent/ semantic web community has proposed DAML-S and OWL-S for the purpose [34] Terminals and devices: The Composite Capabilities/Preferences Profile (CC/PP) framework aims to standardize the specification of user agent profiles. The goal of the CC/PP framework is to specify how client devices can express their capabilities and preferences (the user agent profile) to a server providing content to the device (the origin server). The origin server uses the ‘user agent profile’ to produce and deliver content appropriate to the client device. In addition to computer-based client devices, particular attention is being paid to other kinds of devices such as mobile phones. The framework describes a standardized set of CC/PP attributes – a vocabulary – that can be used to express a user agent profile in terms of capabilities, and the user’s preferences for the use of these capabilities. CC/PP is specified using RDF. The User Agent Profile Specification [22] extends the WAP v1.1 standard to enable end-to-end flows of user agent profiles in mobile environments. The UAProf specification defines a set of so-called Capability and Preference Information (CPI), which is exchanged between the WAP client, intermediate network points, and the origin server. The specification seeks to interoperate seamlessly with the emerging standards for the distribution of Composite Capability/Preference Profiles (CC/PP) over the Internet. Environmental conditions: Work by VTT documented in [35] proposes ontologies for sound and other kinds of environment input. User profiles: A 3GPP solution to user profiling, currently in the standardization process, is the Generic User Profile (GUP) [21]. A GUP is a collection of user data that can be used to configure and personalize services. 3GPP makes no assumptions about the content of the profile, limiting itself to the definition of its structure. For this reason it is said to be an open framework. User profiles tend to be application dependent (e.g., the descriptions of skills and abilities required by an e-commerce recommendation system are quite different from those used by an eLearning system).
G. Cortese, et al. / Context-Awareness for Physical Service Environments
89
A proposed ontology for pervasive computing, which emphasizes user profiles, can be found in [23]. 5.3.4
Architectures for context information processing
We will now discuss architectural options for context-aware services. First we present a logical architecture, which highlights key logical components. We go on to discuss possible implementation architectures and related technologies. 5.3.4.1
Logical Architecture
In this section we present the basic logical components required for context information processing: that is for the generation of context information from sensors and the distribution of this data to applications.
Figure 5.6. Context Data Acquisition, Fusion, and Distribution
Figure 5.6 summarizes the process. The sensing layer The transformation of low level sensor data into meaningful ‘semantic context’ information implies the following steps [35]: • • • •
Acquire raw, high frequency sensor data Build arrays of measurement data, calculate features for each time interval Perform feature extraction Bind feature values to information which has a meaning for humans or applications.
At the binding stage it is possible to associate data with confidence values, making it easier for users and applications to handle uncertain information. For example, sound information could be processed to generate semantic context information such as: < environment sound level = silent (0.7) moderate (0.3) loud (0) >. At this stage of
G. Cortese, et al. / Context-Awareness for Physical Service Environments
90
processing it is possible to use Bayesian classifiers. In some cases it may be necessary to use sophisticated data fusion techniques in which multiple sensors cooperate to extract information. To simplify implementation of the sensing layer, we need programming interfaces or protocols that allow the software to communicate with physical sensors and actuators. It is important that these sensing components should be implemented with appropriate abstractions to enhance their reusability and their shared use by several applications (see, for example, the concept of the ‘Context Widget’ introduced in [2]). The semantic layer: In one widely-accepted architectural pattern, context data is published in a shared data space; applications and symbolic fusion agent components (see below) access and possibly subscribe to this information. In this last case, they receive automatic notification of new information Symbolic fusion agents generate additional context information at a higher level of abstraction. For example, a fusion agent might use observations of light, humidity and temperature to generate a situation describing whether the user is currently in an outdoor or an indoor environment. Fusion agents can be implemented as traditional, procedural components or as inference engines. While it is obviously necessary to adopt standardized mechanisms for interfacing to the shared context space, we do not believe this architecture should dictate specific inference mechanisms or technologies for symbolic fusion agents. The choice between Semantic Object Maps, time logic etc. or other technologies should depend on the kind of functions required by the application. Information published in the context space should be organized in terms of a wellknown vocabulary shared between context producers and consumers. Examples of such a vocabulary have been surveyed in section Errore. L'origine riferimento non è stata trovata.” Applications: Applications access the context space, either in a proactive (query) or publish subscribe style. Applications must have a way to discover sources of context information (i.e. to join the context space) as well as the formats and semantics of data in the space (i.e. as described in ontologies). 5.3.4.2
Coordination through a Shared Context Space
The Shared Context space pattern implements a common, distributed “blackboard” offering publish-subscribe style coordination to a number of peers. Providers of information to this space include: • • •
Sensors in the physical environment (cameras, environmental sensors, etc.) Sensors in the user’s Personal Area Network (GPS, motion sensors, cameras, speakers etc) Inference components for high level, interpreted context.
In addition to basic publish-subscribe mechanisms the context space should provide more sophisticated features such as: •
The ability for applications to obtain time series in addition to single observations
G. Cortese, et al. / Context-Awareness for Physical Service Environments
• • • •
91
Aging mechanisms (allowing context information to ‘expire’ after some predefined time) History mechanisms to ease storage of observations, and queries on these observations Policy-based control over the quantity of data stored and refresh intervals for sensor observations Extensibility and ontology discovery: data in the context space should belong to well-defined ontologies; but flexibility is needed to allow sensor and inference components to implement new ontologies. Middleware should provide for (provider) publication and (client) discovery of context ontologies.
5.3.4.3
Technical Architecture: Options
Though context data collection and distribution is inherently a peer-to-peer application, there are several possible options for the middleware infrastructure, for example with respect to the choice between a centralized and fully distributed architecture. Architectural choices depend on assumptions about the scenario the architecture intends to support. In this section we describe a number of possible technologies which could be used to implement the logical architecture we have described and outline some of their architectural implications. The conteXt Data Manager (XDM): In Telecom Italia, we have implemented a testbed to experiment with context-aware computing. The testbed encompasses a 400 mq area of office space, in which we have deployed WLAN connectivity, WLAN-based location technology, and a number of WebCams. In this setting, we have developed XDM, a context data management middleware, which provides the main building blocks for a context-aware infrastructure. These include: • • • • •
A framework to simplify sensor data acquisition Publish/ subscribe middleware for dynamic context data distribution A symbolic model of the environment Context-aware service provisioning mechanisms User context management.
The architecture is designed to support a nomadic user scenario. Users visit different smart environments, equipped with a device which runs a web browser. The environment provides a number of information services to the user. Applications services, context detection and context processing services run in the infrastructure; the only component on the user device is the browser. In the prototype, service provisioning is based on Web protocols; a number of contextaware services are deployed on a Web Application server. Context-aware provisioning of services enables dynamic adaptation of the set of services and content available to the user, based on criteria such as position, time, and environmental conditions. Example of the services implemented in the testbed include: indoor guide, find-a-friend, device leasing and the monitoring of queues at facilities such as copiers or Automatic Teller Machines. Given the specific applications scenario, the designers have opted for a relatively centralized architecture. Sensors share context data and applications through a TSpaces
G. Cortese, et al. / Context-Awareness for Physical Service Environments
92
server a tuple space middleware by IBM. The symbolic location model of the environment is implemented using a relational database. User context management is a key feature of the prototype. User profiles and global preferences, as well as environment and service-specific preferences (for example, configurations of local service settings established on previous visits, histories etc.), are transparently stored in the network. The user terminal hands a certificate identifying the user to the service environment. The service environment uses it to retrieve all user profile data, which may be needed to perform service configuration and personalization, from an Internet-based, profile data storage service based on peer-to-peer protocols.4 A description of an early version of this prototype can be found in [37]. The development of the testbed was partly supported by the VICom project [38]. XDM is currently being enhanced to support also a more ad-hoc style of interaction between user and ambient devices (see next section). Context Management in the VICom project: Together with the other partners in the VICom project, we have designed a distributed, peer-to-peer context architecture, reflecting the goals of the project, which assigns a predominant role to ad hoc interactions. In the VICom target scenario, users interact seamlessly with peers (other users, sensors, or embedded devices), using a mix of ad-hoc connectivity, and infrastructure-based services, accessed via wireless access points. Services can be provided by any of the connected components. Though the project does not mandate a specific architecture for service provisioning; the emphasis is on data-centric coordination based on Lime, a tuple space middleware [39]. The VICom testbed is distributed across a number of university and enterprise campus(es). The testbed uses a variety of wireless networks and localization technologies. Semantic interpretation technologies based on video sensors are deployed in selected areas, supporting functionalities such as identity recognition, object counting and tracking, gesture recognition, and detection of safety and security critical situations. The VICom context management architecture is peer-to-peer, based on extensions to the Lime middleware. Lime provides data-centric coordination for mobile agents based on the concept of transiently shared tuple spaces. Lime is based on the Linda model, which it extends by breaking up the Linda tuple space into many tuple spaces, each permanently associated with a mobile unit, and by introducing rules for transient sharing of these individual tuple spaces based on connectivity. Each peer runs a context agent, which interfaces to sensors and publishes observations (represented as tuples) in the peer’s Lime tuple space. All connected peers see the tuples by virtue of Lime, yielding what we refer to as the distributed context. Tuples can be accessed both in a proactive (query) style or a reactive (publish/ subscribe) style. The middleware provides a convenient way of representing single values and sequences of temporally related values as tuples. This makes it easy to maintain history and to aggregate context information. We are currently integrating Lime with a DHT-based publish-subscribe mechanism to ensure proper scalability to multi-site context collection and distribution. Device location is collected through a variety of technologies, including GPS, GSM, and 802.11b. Localization is device-centric: the terminal selects an available location provider, and acquires its position. The context agent republishes this information for use in the shared context space. 4
We are currently extending and refining this idea as part of the IST Simplicity project. For further information on Simplicity see www.ist-simplicity.org
G. Cortese, et al. / Context-Awareness for Physical Service Environments
93
IrisNet: An example of large scale context data management infrastructure is IrisNet [40]. IrisNET makes the assumption that in coming years, the range and number of sensors available to applications is likely to increase steadily. On this assumption, the goal of the project is to design a general purpose software infrastructure to implement worldwide sensing services, which can be used by a new generation of sensor-enriched (i.e. contextaware) Internet services; the main focus is on efficient sensor data management for sensors dispersed in a wide area network. IrisNet shows a few interesting concepts. For scalability and decreased bandwidth consumption, IrisNet pushes sensor feed processing and queries close to sensor nodes. As in the architectures we have already discussed, sensors produce data which can be used by multiple applications. However in IrisNet, sensor feed processing can be pushed to the sensor node by the application service. This is useful for complex sensors such as webcams, where it can be important to limit the volume of data transferred by the sensor to the needs of the application, or to have image processing functions performed locally at the sensor node. At each sensor node, an IrisNet code module, called a sensing agent (SA), provides a common runtime environment allowing services to share the node's sensor feeds. Service implementers can download service-specific “senselets” to SAs, using these to extract useful information (e.g. availability of parking) from a sensor feed (e.g. from a webcam overlooking the street). Similarly in query processing, IrisNet pushes query processing close to the data, enabling increased parallelism and ensuring that only the query answer (not the raw data) is transferred over the network. IrisNet provides query routing, caching, load balancing, and replication schemes tailored to the unique query characteristics discussed above. VTT Context Architecture: Last, we briefly discuss the work by VTT on context information management for mobile devices [35], which we have already cited throughout this section. The specificity of this proposed architecture is that it is user device centric. The goal of the VTT proposal is to enhance the usability of mobile applications by letting them adapt to conditions that directly affect their operations. This work describes a mobile terminal software framework that provides systematic methods for acquiring and processing useful context information from a user’s surroundings and feeding it to applications running on the device. The framework is designed for Symbian type devices. Context information can be acquired from a variety of sources including local sensors (GPS, accelerometers, light, microphones,), local processes (e.g. applications), and remote sources reachable through the Internet or ad-hoc connectivity. All the components in the architecture described in Figure 5. run on the user’s mobile terminal, though data can be acquired through the network from sensors running in the environment. An extensible ontology, using RDF as the description syntax, is defined as part of the API for inserting and accessing context information.
5.4
Summary and Conclusions
Context-aware systems will be with us in the next few years, as physical service environments are deployed by business and public organizations. Pace of deployment and ambition of context-aware projects (systems?) will depend on pregress of a number of background technologies, which we have outlined in this paper.
G. Cortese, et al. / Context-Awareness for Physical Service Environments
94
Implementation of a physical service environment, which can perform with contextaware abilities, requiresthe following steps: • • •
Deployment of a sensing infrastructure Design and implementation of a context management architecture infrastructure, including context data acquisition, distribution and management Implementation and deployment of applications which use context information. Context-aware applications will be in the short term custom, specific to each service environment; this will possibly change as standard context ontologies establish for the different vertical markets.
Though context aware services are not limited to that (for example, business intelligence applications, surveillance applications, process monitoring are important classes of services which do benefit from a context management infrastructure), it comes out from the discussion and examples in this paper that a main goal for them is to enhance and simplify the mobile user experience in accessing services. Context awareness goes then hand-in-hand with pervasive computing; we have showed that an appropriate pervasive computing architectures for provisioning of services to visiting users should be deployed as well in physical service environment. Our discussion so far has been centered on technological and standardization issues. However research on context aware services should be tackled with a more interdisciplinary approach, which takes into accounts also human factors. How can we be sure that users will like and accept services which, after all, rely on machines monitoring their activities ? Also, how can they react to services which are not predictable i.e. take different actions than those explicitly required by their users ? Approaches such as usercentered design, usability analysis and testing are highly relevant to the design of this class of services. Analysis of social impact of the technology is also necessary. Benefits (which can be many – as an example, a number of researchers including ourselves are experimenting services to ease the life of people with physical inabilities) should be weighted against drawbacks such as threatens to people privacy.
References [1]
[2] [3] [4] [5] [6] [7] [8] [9] [10] [11]
[12]
A. Ferscha, Coordination in Pervasive Computing Environments, Proceedings of the Workshop on Enabling Technologies: Infrastructure for Collaborative Enterprises, Proceedings of the Twelfth IEEE International, Linz - Austria, IEEE, 3-9, June 2003. M. Weiser, The Computer of the Twenty-First Century, Scientific American, 1991, 94-100. A. K. Dey, Understanding and using context, Personal and Ubiquitous Computing, 5 (1), (2001) 4-7. A. K. Dey, Providing Architectural Support for Building Context-Aware Applications - PhD thesis, College of Computing, Georgia Institute of Technology, December 2000. Web Services Architecture http://www.w3.org/TR/ws-arch/. Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language http://www.w3.org/TR/wsdl20/. UDDI Specification http://www.oasis-open.org/committees/uddispec/doc/tcspecs.htm#uddiv3. DAML-S home page http://www.daml.org/services/. Business Process Execution Language for Web Services Version 1.1 may 2003. OSGi Alliance – Home http://www.osgi.org. P. Grace, G. S. Blair and S. Samuel, ReMMoC: A Reflective Middleware to Support Mobile Client Interoperability. In Proceedings of International Symposium on Distributed Objects and Applications (DOA), Catania, Sicily, Italy, November 2003. A. Schmidt, M. Beigl, and H. W. Gellersen, There is More to Context than Location, 1998
G. Cortese, et al. / Context-Awareness for Physical Service Environments [13]
[14]
[15] [16] [17]
[18]
[19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30] [31] [32] [33] [34] [35] [36] [37] [38] [39]
[40] [41] [42] [43]
95
J. Kubiatowicz, D. Bindel, Y. Chen, S. Czerwinski, P. Eaton, D. Geels, Gummadi, R., Rhea, S., Weatherspoon, H., Weimer, W., Wells, C., and Z. B. OceanStore: An architecture for global-scale persistent storage. In Proceeedings of the Ninth international Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS 2000) (Boston, MA, November 2000), 190-201. S. Chandrasekaran, O. Cooper, A. Deshpande, M. J. Franklin, J. M. Hellerstein, W. Hong, S. Krishnamurthy, S. Madden, V. Raman, F. Reiss, M. Shah, TelegraphCQ: Continuous Dataflow Processing for an Uncertan World (2003). S. Madden, M. J. Franklin, Fjording the Stream: An Architecture for Queries over Streaming Sensor Data, 2001. P. Bonnet, J. E. Gehrke, and P. Seshadri. Towards Sensor Database Systems. In Proceedings of the Second International Conference on Mobile Data Management. Hong Kong, January 2001. T. Kindberg, J. Barton, J. Morgan, G. Becker, D. Caswell, P. Debaty, G. Gopal, M. Frid, V. Krishnan, H. Morris, J. Schettino, B. Serra, M. Spasojevic, People, Places, Things: Web Presence for the Real World, 2000. W. Narzt, G. Pomberger, A. Ferscha, D. Kolb, R. Müller, J. Wieghardt, H. Hörtner, C. Lindinger, Pervasive Information Acquisition for Mobile AR-Navigation Systems, 5th IEEE Workshop on Mobile Computing Systems & Applications, Monterey, California, USA, October 2003. M. Nilsson et al. (eds), Composite Capabilities/Preference Profiles: Requirements and Architecture, W3C Working Draft, 21 July 2000. Online: http://www.w3.org/Mobile/CCPP/. Resource Description Framework (RDF) Model and Syntax Specification, Ora Lassila, et al., (eds.). W3C Recommendation 22 February 1999. Online: http://www.w3.org/TR/REC-rdf-syntax. 3GPP TS 22240-600: 3GPP GUP, Requirements, Stage 1 Release 6, March 2003. Online: www.3gpp.org. Wireless Application Group, User Agent Profile Specification, WAP Forum Approved Specification WAP-174, 10 November 1999. Online: http://www1.wapforum.org. H. Chen, T. Finin, A. Joshi, An Ontology for Context-Aware Pervasive Computing Environments, Article, IJCAI workshop on ontologies and distributed systems, Acapulco MX, August 2003. K. Henricksen, J. Indulska, A. Rakotonirainy, Modeling Context Information in Pervasive Computing Systems, In Proceedings Pervasive Computing, Zurich, August 2002. M. R. Tazari, & M. Grimm, & M. Finke, (2003). Modelling User Context. Proceedings of the 10th International Conference on Human-Computer Interaction (HCII2003), Crete (Greece). J. Case, R. Mundy, D. Partain, B. Stewart, Introduction and Applicability Statements for InternetStandard Management Framework, IETF RFC 3410 December 2002. D. Harrington, R. Presuhn, B. Wijnen, An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks. IETF RFC 3411 December 2002. W3C RDF Home Page, http://www.w3.org/RDF/. Web-Ontology (WebOnt) Working Group page, http://www.w3.org/2001/sw/WebOnt/. The DARPA Agent Markup Language Homepage http://www.daml.org/. World Geodetic System 84, http://www.wgs84.com/. Nokia Corporation, JSR-179 Location API for J2ME Specification, version 1.0, 2003. S. Domnitcheva, Location Modeling: State of the Art and Challenges, 2001 Semantic Web Services home page, http://www.daml.org/services/. P. Korpipää, J. Mäntyjärvi, J. Kela, H. Keränen, E.-J. Malm, Managing Context Information in Mobile Devices IEEE Pervasive Computing 2003. TSpaces - http://www.almaden.ibm.com/cs/TSpaces/. G. Cortese, F.Davide, A. Detti, eCASA: an Easy Context-Aware System Architecture, IEEE Vehicular Technology Conference 2003. VICom project - Virtual Immersive Communications; MIUR-FIRB project Italy 2003-2005. Online: http://www.vicom-project.it/. A. L. Murphy, G. P. Picco, and G.-C. Roman. Lime: A Middleware for Physical and Logical Mobility. In Proceedings of the 21 st International Conference on Distributed Computing Systems (ICDCS-21), May 2001. P. B. Gibbons, B. Karp, Y. Ke, S. Nath, S. Seshan - IrisNet: An Architecture for a World-Wide Sensor Web To appear, IEEE Pervasive Computing, 2003 IETF Manet Working Group. Online: http://www.ietf.org/html.charters/manet-charter.html. Software Defined Radio. Online: http://www.sdrforum.org/. M. Conti, S. Giordano, G. Maselli, G. Turi, Cross-layering in Mobile Ad Hoc Network Design, IEEE Computer, Special Issue on Mobile Ad Hoc Networks, Feb. 2004.
G. Cortese, et al. / Context-Awareness for Physical Service Environments [44]
[45] [46]
[47] [48]
[49] [50]
96
A. Safwat, H. Hassanein, H. Moufta, MAC-based performance study of energy-aware routing schemes in wireless ad hoc networks, Global Telecommunications Conference, 2002. GLOBECOM '02. IEEE, Vol 1, 47-51. Y. C. Hu, S. M. Das, and H. Puchathe, E. Synergy between Peer-to-Peer and Mobile Ad Hoc Networks; Purdue University; 9th Workshop on Hot Topics in Operating Systems, 2003. M. Castro, P. Druschel, A. Kermarrec and A. Rowstron, “SCRIBE: A large-scale and decentralized application-level multicast infrastructure”, IEEE Journal on selected areas in communications, 2002, Vol. 20 (8). S. Q. Zhuang, B. Y. Zhao, A. D. Joseph, R. H. Katz, J. D. Kubiatowicz, Bayeux: An Architecture for Scalable and Fault-tolerant Wide-area Data Dissemination, 2001, Proceedings of NOSSDAV. X. Y. Zhang, Q. Zhang, Z. Zhang; G. Song, W. Zhu, Construction of locality-aware overlay network: mOverlay and its performance, Selected Areas in Communications, IEEE Journal on, (2004) Vol. 22 (1), 18-28. Berkeley WEBS – Wireless Embedded Systems. Online: http://webs.cs.berkeley.edu/. X. Bangnan, S. Hischke, B. Walke, The role of ad hoc networking in future wireless communications, Communication Technology Proceedings, 2003. ICCT 2003. International Conference on, Vol. 2, 1353-1358
