2008 IEEE Workshop on Policies for Distributed Systems and Networks
A Context-Aware, Policy-based Framework for Ambient Network Hassine Moungla INRIA – ARLES Project Team Domaine de Voluceau, Rocquencourt, B.P. 105, 78153 Le Chesnay Cedex, France Email:
[email protected] affect context awareness in general. Such challenges include the representation of context data, the integration of such data with existing systems and applications, the storage and distribution of context data, and the frequency of context retrieval. Furthermore, one of the striking challenges affecting context awareness is the reduction of ambiguity associated with context data. Context refers to the physical and social situation in which computational devices are embedded [4]. A context-aware service (CAS) can be more flexible and autonomous so as to respond accordingly to the highly changing computational environments. For example, a mobile phone will vibrate rather than ring during a meeting, if the system knows the location of the mobile phone and the meeting schedule. While most of the research on context-aware computing focuses mainly on the human-computer interface (HCI) [4,5], this paper tends to tackle context awareness from the perspective of networks, i.e., network-centric contextaware services also. To facilitate the provision of contextaware services, both an appropriate infrastructure to gather, manage, and disseminate contextual information and the design and development of a context model are required. Policies are ideal for context modeling as they easily facilitate the implementation of context-aware services in the underlying networks where policy-based network management (PBNM) is widely regarded as a promising means. PBNM technology can relieve the network administrator of the burden of configuring every single device manually and it is more flexible since network elements can be reconfigured by just producing or changing policies [6,7]. The policy-based method is well suited as context is usually complex, changing and layered. We describe below a context policy-based framework for pervasive systems by introducing a logical plane. This paper is structured as follows. After the architecture description in section 2, section 3 defines and classifies context. Section 4 describes the policy specification. After the logical plane and policy-based context modeling system architecture are presented in Section 5 and 6 respectively. Section 7 presents the initial service implementation with the conclusions and future work in section 8.
Abstract There has been an ever-increasing interest in contextaware computing expressed by the pervasive computing community. Without the presence of context based framework, pervasive systems become more incapable of adapting themselves with the surrounding environment. This article describes a context aware policy-based framework for improves the self-adaptability of the system for the multi media services (in our case Video over IP).First experimental results show the performance of the system.
1. Introduction The convergence of both fixed networks and wireless networks has attracted much research aiming to bring together the high speed of wired networks and the wider coverage of wireless networks (typically represented by GPRS/UMTS). As the hardware and protocols of wireless networks get mature, the demands from higher-level applications and services in integrated networks are rapidly growing, especially when wireless LAN (WLAN) technology becomes increasingly popular for providing IP connectivity and 3G is undergoing deployment stage. This paper tends to contribute to this literature from the services and environments perspective by introducing the idea of context-awareness to the integrated services operating on pervasive next generation networks. Pervasive systems are required to realize knowledge of their surroundings so as to become better integratable and adaptable to the heterogeneity of their surrounding environment. Much research has been proposed to allow pervasive systems to become context aware [1]. As such, a key characteristic for context aware systems is that they must maintain the capability of acquiring and using context related information through interaction with an environment that is sensor-rich, and that is also capable of providing accurate information about itself. Sensing devices can provide pervasive systems with information such as the location of people and devices [2], however; only an intelligent system would be able to utilize the aggregated data into a meaningful, more useful form, a form that will allow a pervasive system to more naturally interact with users, hence going beyond the legacy of isolated interaction [2]. In most cases, context awareness will involve capturing and making sense of imprecise conflicting data and uncertain physical worlds. Various components of a pervasive system must then be able to reason about uncertainty and reduce ambiguity associated with gathered contextual information [3]. Many challenges
978-0-7695-3133-5/08 $25.00 © 2008 IEEE DOI 10.1109/POLICY.2008.54
2. Architecture The basic premise behind the proposed work is that, in order to realize decision autonomy, firstly, the system must possess detailed understanding of the context of the surrounding environment, which includes information pertaining to users (e.g., users’ locations, preferences), terminal characteristics (e.g., battery level, CPU power,
203
memory constraints), application service requirements (e.g., frame rates, media types) and underlying network characteristics (e.g., types of routers, transmission media, services offerings). This information must be presented in a manner that will allow reasoning and inferences concerning management functionalities. Secondly, a strong logic and reasoning component must be available to replace human operators in the decision making and adaptation processes. Finally, the system must provide a flexible means for communicating the decided adaptation operations to system components where they are applied. Based on the above premise, the proposed framework realizes pervasive autonomic management in four orthogonal and canonical planes, namely, the logic, context, policies, and events planes. The logic plane represents the core component which orchestrates the interactions among the other planes. In functional terms, each of the four planes is composed of a number of layers and a plane manager. Figure 1, depicts the interactions between the managers of different planes. A general overview of the functionalities of different planes will be described in the following sections.
Notify events
Reply/Notify context Information Context engine & logic Plane
Context representation
Request context information
Context of domain Components User Layer
Applicat ion/ Services Layer Devic e Layer
User (Location, Budget, Time), server (location
Media type (voice, video), duration
Battery Display, CPU Connection interfaces
Reply/Notify Policy Manager
Fig.1. Interactions and managers at different planes
Evaluate generic policies/ Create/modify dynamic policies
messages
flow
Networ k Layer
BW, transmission media, Security
Services Context
User Activities/ Server offerings
Application services
High quality Display With long life battery
Context manager
Events Plane
Configure/query
and the context of the services offered within that domain. The former context includes the context of the participating entities in the domain spread over four layers. The first layer includes the user context, such as his location, time, preferences, along with context of the managed domain. For example, for a WLAN in an airport, this context will include location of the servers, types of services offered by these servers such as on-demand news and movies, and hotspot locations. The second layer, contains running applications’ context such as available software, types of media used (e.g., voice and video) and types of configuration parameters used by each application. The third layer stores the context related to the domain devices, this includes the characteristics of the user terminals along with the domain servers.
composed Network Services
Fig.2. Schematic description of the context management plane Finally, the fourth layer stores network related context such as routers capacities, configuration parameters, performance monitoring components, etc. Context updates across the four layers are obtained from various sources such as sensors and software probes. This part of the context can be modelled using any of the available models in literature e.g., [11]. The CM is also responsible for detecting context changes and reporting notifications about the changes to the corresponding layers at the event plane. The latter type of context, that is the context of the offered services, provides the essence for management automation. For example, the services offered at the network level are services offered by edge routers to connected hosts and routers of neighbouring domains or are offered by core routers to flows. At the application level services can be an email service, a web browsing service, or real-time video conferencing, etc. As depicted in Figure 2, these services are spread across four different layers.
between
3. Context Previous definitions of context seed our development of context types. Dey [8, 9] proposed, location, identity, environment time, and activity as basic context types for characterising the situation of a particular context entity, as depicted in Figure 2. This context classification clearly answers the questions of who (Identity), where (Location), when (Time), and what (Activity) for a specific context entity (ContextEntity). Furthermore, a whole design of these context types can also be considered. Context modelling addresses the issue of how to represent the contextual information in a way that can help bridge the gap between the application that uses context information and the deployment of the context aware service. Schilit in his PhD thesis [10] used a simple model with context being maintained by a set of environment variables. The context model proposed is a network-centric one and thus has the ability to take into account the main underlying network implementation technology, i.e., policy based network management. Therefore a concrete object oriented context modelling is presented. The Context Plane manages the persistent repository of context information. As shown in Figure 2, the Context Manager is mainly responsible for managing two different types of context information, namely, the context of the entities in the managed domain,
4. The Policy based context Here policy specification language is a kind of highlevel English-like declarative language used by an administrator to add and update management policies. As suggested by the Internet Engineering Task Force (IETF) Policy Framework Working Group, policies take the following rule-based format: IF {condition(s)} THEN
204
{action(s)}, it means action(s) is/are taken if the corresponding condition(s) is/are true. A typical contextaware service scenario can be represented by the following policy, which forces a mobile handset to vibrate rather than ring during meeting time. IF (location == meeting Room) and (time within meeting Schedule) THEN MobileVibrate, only by this means, any policies related to the contextaware services can be defined.
or knowledge context information. When a context elicitor first issues a query to the event plane asking a macro question about a given provider such as: Is the given provider in a meeting? Is the provider currently having lunch? Or a general question such as: What is the given provider currently doing? The query request is forwarded to the context engine coupled with logical plane. As a prerequisite, the context engine requires the presence of policy rules, along with the raw state information in order to come up with conclusive decisions regarding the answer to the submitted query.
5. Logical plane This plane is instruments the multi-dimensional adaptation process and provides the orchestration between the managers at the other planes. It reasons about changes in the current context, received from the event plane, and decides whether or not to perform any required adaptations by providing a new policy context knowledge rule. The context engine utilizes concepts of the event calculus to reason about changes in the environment. Similar to other planes, this plane is divided into four layers. Each layer defines part of the context frame problem components. Typically, each layer defines sets of sorts, fluents and events. Effects of events on fluents across the four layers are represented by a set of domain dependent axioms that are used by the logic manager to infer further context knowledge. The following points summarize the main functionalities of the manager of this plane: - It is responsible for the evaluation of triggered events received from the event plane. - It communicates with context manager at corresponding layers to obtain information about network services, and learns the users’ preferences as well as causes of service violation in case of a violation event, etc. - Based on the received events along with the obtained context, it is responsible for taking the appropriate measures to perform any required adaptation steps in response to the triggered event. Adaptations performed by the logic plane fall under one of two categories. The first are adaptations in the types of the services offered by the managed domain, this can be analogous to the adaptation performed manually in current systems by network administrators to the network information model such as CIM or PCIM documents. These are communicated to the corresponding layers at the context plane. The second types of adaptations are concerned with the rules governing the offering of these services which are communicated to the policy plane. This step is analogous to manual configuration of network policies.
Fig.3. Class Inheritance Hierarchy in the Context Information Model. The policy-based context information model is designed based on the IETF PCIM (Policy Core Information Model) and its extensions [12]. Figure 3 depicts example part of the inheritance hierarchy of our information model representing context in a network service. It also indicates its relationships to IETF PCIM and PCIM extensions (PCIMe). Context rooting from ContextVariable is mainly reflected in this figure as some elements are not shown due to space limitation. Context information is expressed in the policy conditions in the form of elementary Boolean expressions of the form: MATCH . Therefore, the modelling of context information starts from ContextVariable and ContextValue. As discussed in the classification of context, every context entity should at least be described by four basic features, i.e., identity, location, activity and time. The first three of them are modelled in this class hierarchy as shown in Figure 3. The time feature of context can be directly expressed by PolicyTimePeriodCondition which is available as a direct child of PolicyCondition in the IETF PCIM. Network elements play a vital role in context aware service providing and as such, NetworkElement class is defined explicitly as a child of Device class. Network management station, which maintains intra/inter-domain information, is defined as a kind of entity that has all the four basic context types. ContextValue is used for modelling context values and constants used in contextrelated policy conditions.
7. Primary experimental results We have implemented an interactive Autonomic computing Java-based Policy Tool editor, for editing the QoS policies rules set and detecting the conflicts between the rule being specified and the existing rules set. If a conflict is detected, we resolve it by defining a priority or defining a new meta-policy. Figure 4 shows the screendump of computing Java-based Policy Tool editor. It can open the text file of an existing rule or meta-policy rules
5. Context engine The context engine within our system is the sole entity containing the logic capable of converting raw context information about a given provider into macro-contextual
205
set, and load the rules set into its internal XML structure, and check the coherence with the other rules. We conducted implementation and experiments over fixed network to determine the performance behaviours of the system as video-on-demand self-adaptation service based on context-awareness.
when using without architecture and our Context architecture, respectively. In contrast, in our context architecture we were able to decode the whole video sequence (250 frames).
(a)
(b)
Fig7. (a) Decoded frame (n°75) without cross-layer architecture. (b) Decoded frame (n°75) with context architecture.
8. Conclusion
Fig.4. Ambient computing Java_Management_Tool Editor. The proposed scenario deal firstly by providing all policy rules needed for the configuration of our real network (see figure 4), firstly with three normal users in the same meeting room. We add after a new user with high priority with also Video on Demand services. The event will be detected and the context engine with a logical plane provides a new context-rule. This context-rule is forwarded to Cisco routers in order to minimizing the bandwidth, for other users and improves it for the super new user.
This paper presented a context-management and framework that utilizes a novel policy-based model to represent context. The adopted model within facilitates the representation of the multi-facets of an entity’s context, hence, leading to the correct evaluation of context according to the current context of the entity, the client or the environment. The proposed work provides the necessary formalization that will allow the automated reasoning and inferences concerning various management functionalities. In addition, through the enforcement of pre-existing policies or dynamically created ones or knowledge, the Architecture context clients, services, networks in adapting their behaviours as their surrounding environments change. We are currently in the process of implementing the components of our architecture particularly evaluating the performance within the domain of the ambient and pervasive networks by studying the case of mobile users and services in the same time.
Context Self-adaptation Module
Events
Control Loop
Users (2)
(3)
LSR
New Reconfiguration rule
LER CiscoRouter New extra User
9. References
Video Server
[1] G. K. Mostefaoui, J. Pasquier-Rocha, and P. Brezillon ,“Context Aware Computing: A Guide for the Pervasive Computing Community”, The IEEE/ACS International Conference on Pervasive Services (ICPS’04), Lebanon, 2004. [2] D. Saha and A. Mukherjee, “Pervasive Computing: A Paradigm for the 21st Century” IEEE Computer. Pp. 25-31, March 2003. [3] A. Ranganathan, J. Al-Muhtadi, and R. Campbell, “Reasoning about Uncertain Contexts in Pervasive Computing Environments” IEEE Pervasive Computing, Pp. 62-70, April-June 2004. [4] B. Schilit, M. Theimer. “Disseminating Active Map Information to Mobile Hosts”. IEEE Network, 8(5): 22-32, 1994. [5] A. K. Dey and G. D. Abowd. “Towards a better understanding of context and contextawareness”. Proceedings of Workshop on the What, Who, Where, When and How of Context-Awareness, April, 2000. [6] M. Sloman. “Policy Driven Management For Distributed Systems,” Journal of Network and System Management, vol. 2, no. 4, Dec. 1994. [7] http://www.ietf.org/html.charters/policycharter.html [8] A. K. Dey and G. D. Abowd. “Towards a better understanding of context and contextawareness”. Proceedings of Workshop on the What, Who, Where, When and How of Context-Awareness, April, 2000. [9] A. K. Dey. “Providing Architectural Support for Building ContextAware Applications”. PhD thesis, Georgia Institute of Technology, November 2000. [10] B.N., Schilit. A Context-Aware System Architecture for Mobile Distributed Computing, PhD thesis, 1995. [11] M. Khedr and A. Karmouch, “ACAI: Agent-Based Context-aware Infrastructure for Spontaneous Applications”, Network and Computer Applications, vol. 28, n. 1, pp. 19–44, Jan. 2005. [12] B. Moore. “Policy Core Information Model Extensions”. IETF-RFC 3460, IETF Policy Framework Working Group, Jan.2003.
IP CISCO Network
Fig.5. the network topology simulation This realisation was adding new context-rules. As indicated earlier, a specific providing rule takes some delay because to query submitted to the system and waiting answers. H.264 delay transmission 3
Delay (s)
2,5 With cross-layer architecture Without
2 1,5 1 0,5 0 1
3
5
7
9
11
13
15
second
Fig6. H.264 delay transmission with and without context architecture. Figures 6 show both the delays experienced by Contextarchitecture and without, respectively. Our architecture reduces the delay to the minimum level for the super user, indicating that packets are transmitted almost immediately. However without our architecture, we observe a greatly increased packet delays and no adaption on context. Figures 7a, 7b, represent a final decoded frame (n°75)
206
