the design of a novel context-aware policy model to support machine-based learning and reasoning

27
Cluster Comput (2009) 12: 17–43 DOI 10.1007/s10586-008-0069-4 The design of a novel context-aware policy model to support machine-based learning and reasoning John Strassner · José Neuman de Souza · David Raymer · Srini Samudrala · Steven Davy · Keara Barrett Received: 2 October 2008 / Accepted: 9 October 2008 / Published online: 11 November 2008 © Springer Science+Business Media, LLC 2008 Abstract The purpose of autonomic networking is to man- age the business and technical complexity of networked components and systems. However, the lack of a common lingua franca makes it impossible to use vendor-specific network management data to ascertain the state of the net- work at any given time. Furthermore, the tools used to an- alyze management data are all different, and hence require different data in different formats. This complicates the con- struction of context from diverse information sources. This paper describes a new version of the DEN-ng context-aware policy model, which is part of the FOCALE autonomic net- work architecture. This model has been built using three guiding principles: (1) both the context model and the pol- icy model are rooted in information models, so that they can govern managed entities, (2) each model is expressly con- structed to facilitate the generation of ontologies, so that J. Strassner ( ) · S. Davy · K. Barrett TSSG, Waterford Institute of Technology, Carriganore, Co. Waterford, Ireland e-mail: [email protected] S. Davy e-mail: [email protected] K. Barrett e-mail: [email protected] J.N. de Souza Federal University of Ceará, Fortaleza, Brazil e-mail: [email protected] D. Raymer · S. Samudrala Motorola Labs, Schaumburg, IL, USA D. Raymer e-mail: [email protected] S. Samudrala e-mail: [email protected] reasoning about policies constructed from the model may be done, and (3) the model is expressly constructed so that a policy language that supports machine-based reasoning and learning can be developed from it. Keywords Autonomic architecture · Context · FOCALE · Machine-based learning and reasoning · Ontology-based management · Policy management · Semantic reasoning 1 Introduction The business, technical, and even social aspects of systems have increased dramatically in complexity, requiring new technologies, paradigms and functionality to be introduced to cope with these challenges [35]. This increase in com- plexity has made it almost impossible for a human to man- age the different operational scenarios that are possible in today’s communication systems. While IP network manage- ment problems have been extensively documented [3, 32, 35, 36, 40], wireless systems present even more difficult problems. For example, wireless failures are usually not ob- tainable from a set of attributes—they must be inferred. Key Performance and Quality Indicators (KPIs and KQIs) are calculated to provide a machine-interpretable view of sys- tem quality as perceived by the end user for a particular type of wireless system for a specific set of radio access tech- nologies (RATs). However, current RATs use a set of non- compatible standards and vendor-specific functionality. This is exacerbated by current trends, such as network conver- gence (which combine different types of wired and wireless networks), as well as future multi access mode devices [26] and cognitive networks [25], in which the type of network access can be dynamically defined. The vision of Seamless Mobility [17, 33] is even more ambitious—the ability for the

Upload: john-strassner

Post on 15-Jul-2016

212 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: The design of a novel context-aware policy model to support machine-based learning and reasoning

Cluster Comput (2009) 12: 17–43DOI 10.1007/s10586-008-0069-4

The design of a novel context-aware policy model to supportmachine-based learning and reasoning

John Strassner · José Neuman de Souza ·David Raymer · Srini Samudrala · Steven Davy ·Keara Barrett

Received: 2 October 2008 / Accepted: 9 October 2008 / Published online: 11 November 2008© Springer Science+Business Media, LLC 2008

Abstract The purpose of autonomic networking is to man-age the business and technical complexity of networkedcomponents and systems. However, the lack of a commonlingua franca makes it impossible to use vendor-specificnetwork management data to ascertain the state of the net-work at any given time. Furthermore, the tools used to an-alyze management data are all different, and hence requiredifferent data in different formats. This complicates the con-struction of context from diverse information sources. Thispaper describes a new version of the DEN-ng context-awarepolicy model, which is part of the FOCALE autonomic net-work architecture. This model has been built using threeguiding principles: (1) both the context model and the pol-icy model are rooted in information models, so that they cangovern managed entities, (2) each model is expressly con-structed to facilitate the generation of ontologies, so that

J. Strassner (�) · S. Davy · K. BarrettTSSG, Waterford Institute of Technology, Carriganore,Co. Waterford, Irelande-mail: [email protected]

S. Davye-mail: [email protected]

K. Barrette-mail: [email protected]

J.N. de SouzaFederal University of Ceará, Fortaleza, Brazile-mail: [email protected]

D. Raymer · S. SamudralaMotorola Labs, Schaumburg, IL, USA

D. Raymere-mail: [email protected]

S. Samudralae-mail: [email protected]

reasoning about policies constructed from the model maybe done, and (3) the model is expressly constructed so that apolicy language that supports machine-based reasoning andlearning can be developed from it.

Keywords Autonomic architecture · Context · FOCALE ·Machine-based learning and reasoning · Ontology-basedmanagement · Policy management · Semantic reasoning

1 Introduction

The business, technical, and even social aspects of systemshave increased dramatically in complexity, requiring newtechnologies, paradigms and functionality to be introducedto cope with these challenges [35]. This increase in com-plexity has made it almost impossible for a human to man-age the different operational scenarios that are possible intoday’s communication systems. While IP network manage-ment problems have been extensively documented [3, 32,35, 36, 40], wireless systems present even more difficultproblems. For example, wireless failures are usually not ob-tainable from a set of attributes—they must be inferred. KeyPerformance and Quality Indicators (KPIs and KQIs) arecalculated to provide a machine-interpretable view of sys-tem quality as perceived by the end user for a particular typeof wireless system for a specific set of radio access tech-nologies (RATs). However, current RATs use a set of non-compatible standards and vendor-specific functionality. Thisis exacerbated by current trends, such as network conver-gence (which combine different types of wired and wirelessnetworks), as well as future multi access mode devices [26]and cognitive networks [25], in which the type of networkaccess can be dynamically defined. The vision of SeamlessMobility [17, 33] is even more ambitious—the ability for the

Page 2: The design of a novel context-aware policy model to support machine-based learning and reasoning

18 Cluster Comput (2009) 12: 17–43

user to get and use data independent of access mode, device,and media.

Part of the allure of Policy-Based Network Management(PBNM) [36] is its simplicity in providing different servicesto different users while automating device, network and ser-vice management. However, most PBNM systems have beenlow-level systems that manage changes in commands forrouters, switches, and firewalls. Hence, there is no link be-tween business needs and the configuration of network re-sources and services.

In addition, relatively new concepts, such as using con-text changes to determine which network services and re-sources should be made available to the set of users and/orapplications to satisfy a given set of business objectives,have not yet been realized.

Our approach for solving this problem is realized as theFOCALE autonomic architecture [34, 40], and is based onfive key concepts. First, the use of a shared informationmodel is required in order to harmonize the different datamodels that are used in Operational and Business SupportSystems (OSSs and BSSs). Second, since information anddata models are each in and of themselves not capable ofrepresenting the detailed semantics required to reason aboutbehavior, we augment our use of knowledge extracted frominformation and data models with knowledge extracted fromontologies. This novel combination of modeled and onto-logical data enables reasoning to be used to define the bestset of policies applicable for a given context change. Third,we define a new, enhanced policy model that, while con-structed as an information model, has been specifically de-signed to be able to generate and be harmonized with on-tologies. Fourth, we link this policy model to a new contextmodel, so that policies can be written that adapt offered re-sources and services to sensed context changes. Finally, weoutline how this novel context-aware policy architecture canbe used, together with machine learning and reasoning, tobuild a new adaptive control architecture.

The organization of this paper is as follows. Section 2provides a brief introduction to autonomic computing andnetworking. Sections 3 and 4 summarize current PBNMand context approaches. Section 5 describes our new pol-icy model in detail. Section 6 links this model to our newcontext model. Section 7 describes initial progress that wehave made in building an adaptive control architecture thatselects policies to govern behavior based on the nature ofcontext changes. Section 8 summarizes the paper.

2 Autonomic networking overview

This section discusses the difference between autonomiccomputing and autonomic networking.

Fig. 1 Autonomic computing control loop

2.1 Autonomic computing

The purpose of autonomic computing is to manage complex-ity. The name was chosen to reflect the function of the au-tonomic nervous system in the human body. By transferringmore manual functions to involuntary control, additional re-sources (human and otherwise) are made available to man-age higher-level processes.

The fundamental management element of an autonomiccomputing architecture is a control loop, as defined in[20, 22]. IBM’s version is shown in Fig. 1. The idea is to in-strument a Managed Resource so that an Autonomic Man-ager can communicate with it. This is done using sensorsthat retrieve data, which is then analyzed to determine if anycorrection to the managed resource(s) being monitored isneeded (e.g., to correct “non-optimal”, “failed” or “error”states). If so, then those corrections are planned, and ap-propriate actions are executed using effectors that translatecommands back to a form that the managed resource(s) canunderstand. The Autonomic Element embodies the controlloop, and enables the autonomic manager to communicatewith other types of autonomic and non-autonomic managersusing its sensors and effectors.

2.2 Autonomic networking

The motivation behind autonomic networking is to identifynetwork management functions that can be done without hu-man intervention to reduce the dependence on skilled re-sources for managing devices, networks, and networked ap-plications. If the autonomic network can perform manual,time-consuming tasks (such as configuration management)on behalf of the network administrator, then that will freethe system and the administrator to work together to per-form higher-level cognitive functions, such as planning andoptimization of the network.

A fundamental difference between autonomic computingand autonomic networking is that the latter must cope with

Page 3: The design of a novel context-aware policy model to support machine-based learning and reasoning

Cluster Comput (2009) 12: 17–43 19

Fig. 2 Simplified FOCALE autonomic architecture

heterogeneous management data, programming models, andcontrol mechanisms (used by different networks), which theformer doesn’t consider [32, 35, 38, 40]. The FOCALE au-tonomic architecture has defined a new management modelthat is equally appropriate for legacy devices and applica-tions as well as for next generation and cognitive networks.Figure 2 shows a simplified version of FOCALE [34, 40].

Multiple networks and network technologies requiremultiple control planes that can use completely differentmechanisms; this makes managing an end-to-end servicedifficult, since different management mechanisms must becoordinated. FOCALE addresses this in two ways. First,it uses a novel model-based translation layer, which trans-forms vendor-specific data into a normalized XML represen-tation; similarly, it takes normalized XML commands andtransforms them into vendor-specific commands. Second, incurrent environments, user needs and environmental condi-tions can change without warning. Therefore, the system, itsenvironment, and the needs of its users must be continuallyanalyzed with respect to business objectives. FOCALE usesa context-aware policy architecture to change the set of ser-vices and resources provided at any given time to meet thechanging needs of a user. This is implemented using a set ofadaptive control loops that employ machine-based learningand reasoning to govern the (re)configuration of the FO-CALE control loops in order to protect the current businessobjectives of the organization.

The key to FOCALE’s adaptive control loops is the in-teraction between the context manager, policy manager, andautonomic manager. Conceptually, the context manager de-tects changes in the network, or in user needs, or even inthe business; these context changes in turn trigger a new

set of policies to take over control of the autonomic system.This enables the services and resources provided by the au-tonomic system to adapt to these new needs. Context acts asa filter to select the particular subset of policies that applyfor a given context, providing a macro-level of adaptivitythat is inherent in the FOCALE architecture. A correspond-ing micro-level of adaptivity is provided by the autonomicmanager, which uses these policies to govern each of thearchitectural components of the control loop, enabling thedifferent control loop components to change the type of al-gorithm used, the type of function used, and even the typeof data to use as a function of context. Each control loop isthen able to fine-tune the resources and services offered bythe component or system that is being managed, as a func-tion of context and policy.

FOCALE is self-governing, in that the system senseschanges in itself and its environment, and determines theeffect of the changes on the currently active set of businesspolicies. In general, those changes could either cause a newset of business policies to be activated, or be symptomaticof one or more goals of the currently active set of businesspolicies being endangered. In the latter case, FOCALE re-configures the system to ensure that the currently active setof business policies is not violated and observes the resultsto make certain that the reconfiguration did was it was sup-posed to [35, 40]. FOCALE is capable of choosing amongstpre-defined policies, as well as in building small modifi-cations to policies by putting together pre-defined buildingblocks (e.g., from events, conditions, and actions). In gen-eral, FOCALE cannot build a new policy from “scratch”; itis limited to making small changes in policies, and then onlywhen the administrator explicitly approves those changes.

Page 4: The design of a novel context-aware policy model to support machine-based learning and reasoning

20 Cluster Comput (2009) 12: 17–43

Fig. 3 An example of the Policy Continuum

This reflects the dichotomy between the conflicting desiresbetween automation and human governance for certain op-erations.

FOCALE responds to both changing user needs as wellas changing conditions in the business and in the networkinfrastructure through the use of a Policy Continuum [5, 6,34, 36], an exemplar of which is shown in Fig. 3. The con-cept of the Policy Continuum is essential for next generationnetworks and services, as it enables the requirements for dif-ferent OSS and BSS components to be translated among dif-ferent groups of users and applications. The essential com-ponent of the Policy Continuum is not the number of lev-els or their labels, but rather the set of transformations per-formed between different policy rules. This enables PBNMsystems to embrace multiple constituencies that use differ-ent concepts and terminologies, enabling these constituen-cies to work together.

In particular, each view of the Policy Continuum is op-timized for a different type of user that needs and/or usesslightly different information, even though they interact withthe same managed entities. For example, the business userwants Service Level Agreement (SLA) information, andisn’t interested in the type of queuing or other traffic con-ditioning functions that will be used to support the SLA.Conversely, the network administrator may want to developCommand Line Interface (CLI) or Simple Network Manage-ment Protocol (SNMP) commands to program the device,and may need to have a completely different representationof the policy in order to develop the appropriate commandchanges. Thus, the requirement is for policy to be treated asa continuum, where different policies take different formsand address the needs of different users. Note that unlessthere is a lexicon that can be used to relate these differentforms of policy to each other, it becomes difficult (if notimpossible) to define a set of mappings that transform thedata between each type of policy in the continuum. Our lex-icon takes the form of knowledge extracted from the DEN-ng information model augmented with knowledge extractedfrom a set of ontologies [34, 35]. This provides a layered setof policies with different levels of abstractions, and modelmappings to translate between them.

3 Current PBNM approaches

Policy-based Network management (PBNM) [36] is a con-cept developed originally to reduce the administrative com-plexity of reconfiguring a device and/or a network to re-spond to the changing conditions of the business and theinfrastructure. The manual process of reconfiguring the net-work is very difficult; two important sources of this diffi-culty are the challenge of enabling the business to determinethe set of network services and resources to be provided atany given time, and because of the vast amount of hetero-geneous devices a network comprises [36]. PBNM aims todecrease this complexity and its associated cost by automat-ing, to some degree, the reconfiguration process. This con-cept corresponds to the vision of self-governance innate inautonomic communications [27].

Damianou et al. [4] provide a comprehensive, but slightlydated, survey of common approaches. One of the key pointsthat are raised in [4] is that there is a marked separation be-tween policy languages that are applied to specific domains.For example, the syntax, constructs used, and underlyingmodel are very different between existing security and man-agement policy languages. Three languages that claim to beindependent of domain are briefly discussed below. Note thefollowing shortcomings of all of these related works:

• None address the multiple stakeholders and views embod-ied in the Policy Continuum concept.

• None provide a common lingua franca that enables dif-ferent management data to be harmonized.

• All are limited in their representation of knowledge com-pared to our method, which combines information modelsand ontologies.

The Policy Technologies group at the IBM T.J. WatsonResearch Center has developed the Policy Management forAutonomic Computing (PMAC) technology. PMAC is em-bedded within software applications, and is positioned asIBM’s policy based autonomic management infrastructure.PMAC has a policy language called the Autonomic Com-puting Policy Language (ACPL), which in turn uses theAutonomic Computing Expression Language (ACEL) [14].An “autonomic manager” tool can make decisions based onpolicies (business rules), created by the developer to makeapplications capable of self-managing and self-configur-ing [12]. However, PMAC only uses a condition-action tu-ple, which creates efficiency and predictability problems.The most obvious is that if policy rules don’t contain anevent specification, then the system cannot determine whenconditions will be evaluated. This in turn means that con-flicts cannot be detected. In addition, continuously checkingevery condition against every event is not going to be com-putationally efficient, nor will it produce temporally pre-dictable firing of policy actions without prescriptive real-time requirements. Finally, the predictability problems that

Page 5: The design of a novel context-aware policy model to support machine-based learning and reasoning

Cluster Comput (2009) 12: 17–43 21

may be introduced can open the door to a wide range ofanomalous runtime behaviors.

Ponder, a policy language for distributed system man-agement, has been developed as part of ongoing work inImperial College, London. The language, which is declar-ative, strongly-typed and object-oriented, codifies six policytypes, namely positive authorization, negative authorization,refrain, positive delegation, negative delegation and obliga-tion. While these policy types allow for a rich policy set tomanage the behavior of a domain, the language has someshortcomings. Both positive and negative authorizations aretarget based, which means that a subject cannot specify pos-itive authorization policies to control its own behavior re-garding interaction with a target. Refrain policies are ap-proximately equal to subject based negative authorizationpolicies, although the semantics of ‘must refrain from’ arenot as strong as ‘not authorized’. Moreover, refrain, positiveauthorization and negative authorization policies do not havean event clause, which can cause efficiency and predictabil-ity problems as discussed in relation to PMAC. Delegationpolicies, both positive and negative, allow the subject of anauthorization policy to delegate temporarily access rightsto a grantee. However, as authorization policies are targetbased, it therefore seems imprudent to allow the subject ofan authorization policy to delegate permission/revocationaccess rights. Finally, the semantics of the Ponder policylanguage [3] itself have not been formally defined, mak-ing automated reasoning over policies, as required for au-tonomic networking, not possible through formal means.

The University of Maryland, Baltimore, has developedRei to facilitate the definition of deontic logic based poli-cies that are used to manage the behavior of agents oper-ating in open distributed environments. More specifically,Rei defines constructs for right, prohibition, obligation anddispensation policies. However, unlike Ponder, Rei does notspecify explicitly if a policy is target based or subject based,which can be limiting for policy conflict detection. OWL-Lite is used to encode the grammar of Rei; therefore indi-vidual instances of policies are defined as individuals/slotsof the defined classes and properties. Rei also uses OWL-Lite to reason over domain knowledge expressed in eitherRDF or OWL. To overcome the issue of defining policiesthat contain variables, which is inherited by implementingOWL to encode the grammar, Rei uses placeholders sim-ilar to those used in Prolog. This non-standardized exten-sion, however, means that (DL Implementation Group) DIGreasoners and the REI engine are able to reason about thedomain-specific knowledge, but not about all policy specifi-cations. Finally, the most important critique of the Rei policyspecification language is that the semantics of the languagehave not been formally defined. A natural language descrip-tion (English) of the semantics has been provided but thisis of little benefit for automated knowledge acquisition andinferencing [21, 42].

4 Current context approaches

Gu et al. [11] describe the development of a software archi-tecture to support the building of context-aware applicationsby defining a conceptual framework. While the frameworksimplifies the task of acquiring and delivering context to ap-plications, it doesn’t provide an information model to visu-alize or define how context is used, nor does it describe howpolicy is used.

Román et al. [29] define a context service to let appli-cations query and register for particular context informationusing a first-order logic to model context. This limits appli-cations to using only context data from the context providersdefined in the registry.

Khedr and Karmouch [23] points out that most contextaware approaches focus on building frameworks and toolk-its to support ad hoc context representation. Hence, [23]describes an ontology for describing concepts for context-aware applications. However, it is designed to support con-text negotiation, not general purpose analysis, and doesn’tuse information models at all.

There are several proposed extensions to the Compos-ite Capabilities/Preferences Profile (CC/PP) [43] and UserAgent Profile (UAProf) [44] standards. Both of these men-tion context, but are in reality focused on describing devicecapabilities and user profiles.

One of the most popular definitions of context is: “Con-text is any information that can be used to characterize thesituation of an entity. An entity is a person, place, or objectthat is considered relevant to the interaction between a userand an application, including the user and application them-selves” [7].

For our purposes, this definition has some significantshortcomings when it is applied to autonomic computing orautonomic networking. The most significant problems are

• “characterize the situation” is too vague. We need to dif-ferentiate between measured and inferred data, since theyhave different relevancies and confidence factors. We alsoneed to explicitly differentiate between current and histor-ical knowledge.

• “situation” is, at the very least, odd. Situation usually con-notes “relation to its surroundings”, but context is not justlimited to location.

• “relevant to the interaction between a user. . .” explicitlyexcludes non-human context interactions as well as envi-ronments in which a user is not interacting with an appli-cation (i.e., user is sleeping).

Therefore, we use the following definition of context inDEN-ng: “The Context of an Entity is a collection of mea-sured and inferred knowledge that describe the state and en-vironment in which an Entity exists or has existed”. In par-ticular, our definition emphasizes two types of knowledge—

Page 6: The design of a novel context-aware policy model to support machine-based learning and reasoning

22 Cluster Comput (2009) 12: 17–43

facts (which can be measured) and inferred data, which re-sults from machine learning and reasoning processes appliedto past and current context. It also includes context history,so that current decisions based on context may benefit frompast decisions, as well as observation of how the environ-ment has changed.

5 The design of the new policy model

The DEN-ng model is built on two important concepts: pat-terns and roles. DEN-ng is the only object-oriented infor-mation model that was built from the beginning using pat-terns [10, 16]. This formalism, along with best current prac-tices such as using roles to abstract concepts, is the sourceof much of the inherent extensibility of the model.

5.1 The importance of using an information model

Since the aim of autonomic networking is to manage net-worked applications and systems, we need a means to rep-resent the characteristics and behavior of system elements.ITU-T recommendations, along with IETF and other foradocuments, describe current state data for managed objects,but do not describe how to manage the lifecycle aspects ofmanaged objects. Hence, we turn to information models.

There are three main information models being used to-day: DEN-ng [36], the TMF SID [19] and the DMTF CIM[15] (other efforts are too sparse in their domain coverage tomeet the needs of autonomics). The SID is partially derivedfrom DEN-ng v3.5; unfortunately, the aims of the TMF di-verged, and DEN-ng (the latest version is 6.6.2) will now besubmitted to the Autonomic Communications Forum. TheTMF has had a five-year liaison relationship with the DMTF,trying to align the DMTF CIM with the TMF SID. This workhas been hampered by three important problems: (1) the lackof a common metamodel, (2) the type of modeling done, and(3) the lack of the use of patterns. The CIM uses its ownproprietary metamodel, not that of UML [18]. This meansthat the concepts used to build models (e.g., classes, at-tributes, and relationships) are defined differently. The CIMis in reality a data model, as it contains technology-specificconcepts, such as keys and weak relationships, which arenot technology neutral. Information models by definition re-quire technology neutrality, or else coherency between thesame knowledge represented in different forms in differ-ent data models will be lost. Finally, patterns play a criti-cal role in model-driven design [28]. Successful transforma-tion between models requires that the original model containenough details and semantics to completely guide softwaretools through the transformation process. By incorporatingthe semantics through the use of software patterns, insteadof manual insertion, we gain multiple benefits:

• Design of an architecture is less time consuming.• Resulting model is easier to learn, since it reuses familiar

concepts.• Resulting model reflects the collective wisdom of all con-

tributors, and Tools can work with the patterns throughthe transformation, ultimately pulling implementationcode from a library written by experts and inserting itinto the final application and/or system.

DEN-ng also uses roles [13]. Roles make a design in-herently scalable by abstracting individual users, devices,and services into roles that can be played by various man-aged entities. DEN-ng is unique, in that roles are not limitedto just people; rather, they may include roles representingresources, services, products, locations, and other managedentities of interest. In [37], both the entities requesting ac-cess as well as the target entities being accessed have roles;in addition, the application of policy is done using roles,both to represent the subject and the target of policy. Notethat [37] uses the old DEN-ng policy model.

5.2 Rationale for building a new policy model

The original DEN-ng policy model has worked well, as doc-umented in [36]. However, the old DEN-ng model was neverintended to be used in conjunction with a set of ontologies toinfer and understand data. Information models are meant torepresent known facts, not for discovering new knowledge.Since information models do not have the ability to use for-mal logic, such as a first order logic, they are limited to asimple pattern matching technique, and cannot (for exam-ple) reason about data—what it means, where it should beplaced in the hierarchy, and so forth. Put another way, if datacorresponding to a class exists in the model, it can be used;if it does not, then it cannot be used. Unfortunately, auto-nomic networks require both the discovery (and subsequentclassification) of new knowledge as well as the updating ofexisting knowledge for several reasons. First, network de-vices are inherently extremely complicated. It is impossibleto build a complete model of (for example) a router, becausein order to do that, one would have to model its static prop-erties (e.g., an interface) as well as its dynamic properties(e.g., instantiating a VPN requires use of shared resources)and behavior (e.g., modeling of particular bugs and side ef-fects). Hence, what is needed is to construct a model thatapproximates the static properties of the router, and use adifferent tool to model its dynamic and behavioral proper-ties.

One might ask why UML is not able to model the dy-namic and behavioral properties of a managed element, likea router. There are several reasons, all of which are beyondthe scope of this paper. Suffice it to say that in order to modeldynamic properties and behavior, we need a set of mecha-nisms beyond what UML currently provides. For example,

Page 7: The design of a novel context-aware policy model to support machine-based learning and reasoning

Cluster Comput (2009) 12: 17–43 23

Fig. 4 Mapping a high-levelfunction to different commandsets

we need the ability to reason about the meaning of senseddata, and how to best interpret it. UML has no facilities forlogic based reasoning. The deficiencies in UML are particu-larly felt in the areas of meaningful mechanisms for model-ing actions and the semantics of said actions, semantic andontological imprecision as well as poor support for modelinstance management and manipulation.

The problem is that networks are made up of heteroge-neous devices, each with its own vendor-specific conceptsand implementation dependencies. Hence, incompatibilitiesbetween different means of representing and processing in-formation, along with defining the meaning of said infor-mation, arise. These issues result in a phenomenon calledcognitive dissonance. Cognitive dissonance was first intro-duced in 1957, by Dr. Leo Festinger, then a member of theDepartment of Psychology at Stanford University. Simplis-tically, cognitive dissonance results in a situation where twosupportable, held beliefs are in opposition to each other. Interms of UML models, this most often results when consid-ering instances of models due to the lack of precision in thespecification of relationships in the presence of inheritancehierarchies. Furthermore, UML does not contain the con-structs necessary to support the definition of knowledge orreasoning about knowledge, which requires formal seman-tic definitions that enable unambiguous representations andorganization of the representations that facilitate the calcula-tion of semantic similarity construction [34, 45]. As anotherexample, UML does not have the mechanisms required toestablish semantic relationships between information (e.g.,synonyms and antonyms). For example, there is no abilityin UML to represent explicit semantics (i.e., the definitionsused in UML are implicit). In addition, relationships, such as“is similar to”, that are needed to relate different vocabular-ies (such as commands from different vendors) to each other,

along with tense, modals, and episodic sequences, cannot bedefined.

Thus, when different terms need to be equated, exist-ing standards-based models and vendor programming com-mands, such as SNMP and vendor-specific command-lineinterfaces, express knowledge differently. End-to-end man-agement requires different commands from different ven-dors to be equated. This is, conceptually, a graph-matchingproblem, where one concept in one model (which might mapto one or more model elements) must be equated to anotherconcept in the other model, as shown in Fig. 4.

Most network management devices and applications donot share a common vocabulary, which necessitates a map-ping between these two sub-graphs. The different semanticsof each model require semantic similarity mappings to re-solve these problems [34, 45]. For example, it is commonto find a single command from one vendor map to multiplecommands from another vendor.

In addition, autonomics requires traceability of configu-ration changes made. Hence, it is important to be able toreason about changes in past and present configurations, andwhat may need to be done in the future. If network manage-ment is going to be able to be made easier to understandby non-experts, then a restricted natural language interfacemust be built that includes concepts such as modals andother modifiers (e.g., mood and tense). This also includesepisodic sequences, which are used to formalize the set ofactions performed in a configuration. Interaction diagramsfall short of this, because of their lack of semantics and theirinability to specify irregular patterns.

These limitations also make it impossible to do basicfunctions, such as define the set of simple network man-agement protocol (SNMP) monitoring commands that can

Page 8: The design of a novel context-aware policy model to support machine-based learning and reasoning

24 Cluster Comput (2009) 12: 17–43

Fig. 5 Root of the new DEN-ngpolicy model

determine if a command line interface (CLI) configurationcommand was successful or not. Even though UML hasdefined extension mechanisms (profiles, tagged data, andstereotypes), those mechanisms are insufficient to guaran-tee interoperability, because they require too much addi-tional custom processing that is not specified in the stan-dard. In [32] and [38], initial work on the fusion of infor-mation models and ontologies is described; this will be ex-tended in future work to include the fusion of machine learn-ing and reasoning mechanisms [34]. This fusion is critical—models and ontologies represent facts and extended seman-tic meaning describing the facts; reasoning enables hypoth-esis generation using those facts and meanings; learning ac-celerates the incorporation of knowledge. It is only throughthis knowledge fusion approach that autonomic systems canrelate diverse data and understand the current state of thesystem, and hence any reconfiguration that is required.

5.3 The root of the new DEN-ng model

Figure 5 shows the root of the new DEN-ng policy model(note that this is different from the DEN-ng policy modeldescribed in [36]). A PolicyConcept is an abstract class, andis the root of the new DEN-ng Policy model. As such, it de-fines common attributes, methods and relationships that allpolicy subclasses use and take part in. This class is namedPolicyConcept because it does not define the characteristicsand behavior of a Policy Rule (or any of its components);rather, from a classification theory point-of-view, it defines anew part of the overall DEN-ng model that is concerned withmodeling generic concepts related to policy. Note that thisalso helps in generating ontologies from the model, in thatthe name makes clear that this is not a Policy Rule or a com-ponent of a Policy Rule. This is in direct contrast to othermodels (e.g., the CIM, whose root class is called “Policy”;we have found that this generates confusion, since “policy”and “policy rule” are often used interchangeably).

A PolicyDomain is a collection of entities and servicesthat are administered in a coordinated fashion using a setof policies. The policies are used to control the set of ser-vices and entities according to a common methodology, suchas a finite state machine. The HasPolicySubDomains aggre-gation enables a PolicyDomain to contain other PolicyDo-mains.

5.4 Modeling policy applications

In the DEN-ng model, all Applications inherit from Logical-Resource. A PolicyApplication defines concepts and com-ponents that can use policy entities to manage the behaviorand configuration of other entities. A PolicyApplication, asa minimum, consists of entities to provide policy decision-making capabilities, as well as entities to enforce and exe-cute policies, as shown in Fig. 6. It also includes entities tocoordinate management and usage aspects of policy as wellas entities to enable policy components to scale to large dis-tributed systems.

There are different types of Applications. For this pa-per, we are interested in ManagementApplications, whichare used to manage one or more types of ManagedEntities.A ManagementApplication is a type of PolicyApplicationthat controls the state of the system using policies. Controlis implemented using a management model such as a finitestate machine. In addition, PolicyApplication is used as aconvenient place for defining relationships to managed enti-ties that it governs as well as managed entities that providepolicy management functionality.

Figure 7 shows that PolicyApplications must have at leastone or more PolicyApplicationComponents, which have asimilar inheritance hierarchy to PolicyApplications. Appli-cationComponents are entities that provide modular func-tionality that is part of a larger application. PolicyApplica-tion functions include installing and deleting policy rules aswell as monitoring system performance to ensure that theinstalled policies are working correctly. A PolicyApplica-tion, as a minimum, consists of entities to provide policydecision-making, execution, and verification capabilities, aswell as entities to coordinate management and usage aspectsof policy. This enables scalable models to be composed byreusing appropriate components.

The ApplicationComponentDetails association class de-fines the semantics of the ContainsApplicationComponentscomposition. Different Applications need different sets ofApplicationComponents to function. Hence, this associationclass serves as the base class for defining the semantics ofthis relationship.

The principal subclasses of PolicyApplication are shownin Fig. 7. More detail is provided in [2].

Page 9: The design of a novel context-aware policy model to support machine-based learning and reasoning

Cluster Comput (2009) 12: 17–43 25

Fig. 6 Policy Application andPolicyApplicationComponent

Fig. 7 Types ofPolicyApplications

A PolicyDecisionApplication makes policy decisions foritself or for other entities that request such decisions, such asPolicyExecutionApplications. PolicyDomains must containat least one PolicyDecisionApplication, and a PolicyDeci-sionApplication must contain at least one PolicyDecision-Component. A PolicyDecisionApplication represents the fi-nal, implemented, deployed unit of functionality, whereasthe PolicyDecisionComponent represents solely the contentof one or more policy decision algorithms. A PolicyDe-cisionComponent is just the algorithm implementation—it

does not contain computing and memory resources requiredto execute the algorithm. In contrast, the PolicyDecision-Application provides the computational resources requiredto function correctly. (This difference between Applicationsand Components holds for all subclasses.)

DEN-ng enhances the IETF/DMTF definition of a Pol-icy Enforcement Point by separating the concept of execu-tion of one or more actions on a PolicyTarget versus veri-fying that a set of executed PolicyActions did what was ex-pected of them (e.g., changed the state of a managed entity).

Page 10: The design of a novel context-aware policy model to support machine-based learning and reasoning

26 Cluster Comput (2009) 12: 17–43

Fig. 8 Accommodating different PolicyRule representations

This is modeled by PolicyExecutionApplications (which areresponsible for executing a set of PolicyActions on a pre-scribed set of PolicyTargets) and PolicyVerificationApplica-tions (which are used to verify that a prescribed set of Poli-cyActions have done what was requested of them).

PolicyConflictApplications enable policy conflict detec-tion and/or resolution applications to be defined. A Poli-cyConflictDetectionApplication detects policy conflicts be-tween two or more policy rules. These are usually at thesame level of the Policy Continuum [5, 6], but do not haveto be. A PolicyConflictResolutionApplication resolves con-flicts between two or more policy rules.

A PolicyBrokerApplication governs how policy is ap-plied through collaborating PolicyApplications to affectManagedEntities in a particular set of PolicyDomains. Inthis regard, it has two different functions. The first func-tion is to ensure that any conflicts between different policyrules from different PolicyApplications in different Policy-Domains are resolved when those policy rules are appliedto the same set of ManagedEntities. The second function isto coordinate the application of different policies in differ-ent Policy Domains (e.g., how to resolve priority, and moreimportantly, which policies are allowed to be used) whenone or more policies from multiple PolicyApplications areapplied to a common set of ManagedElements.

Referring back to Fig. 5, the PolicyContainedIn associa-tion defines the set of Policies that reside in a particular Poli-cyDomain. PolicyApplications are related to a given Policy-Domain through the ScopesPolicyApplication aggregation.When this is combined with role-based access control [8,9, 14, 30, 31, 37], different types of PolicyApplications, aswell as different types of Policies that a PolicyApplicationuses, can have their access and usage limited to roles thatdifferent users takes on.

5.5 Redesign of the concept of a PolicyRule

In the “old” DEN-ng model, the purpose of the PolicyRuleclass was to model a policy rule in its entirety. This meansthat a PolicyRule must contain all concepts that are requiredfor a PolicyRule to be instantiated. This, from a pure se-mantic viewpoint, is incorrect. For example, the conceptsof policy subject, policy target, and policy continuum level(not shown in the old policy model; suffice it to say that theywere all directly related to PolicyRule in some fashion) havenothing to do with the representation of a PolicyRule. The“new” policy model separates the structural representationof a Policy Rule from other semantic aspects of that PolicyRule in the model.

Before we describe the redesign, it is important toremember that there are many different types of Poli-cyRules [35]. No policy model to date has actually triedto represent more than one basic type of policy (from astructural point-of-view) in the same UML model. We wantthe new DEN-ng model to be able to represent all types ofrelevant policy rules. As a simple example, if we define aPolicyRule to be of the form event-condition-action, thenhow do we represent a policy rule from the DMTF or IETF,which only uses simple condition-action representations?(The reason that we want to be able to do this is to be able tomap between different policy rule representations that dif-ferent systems may use; however, this is beyond the scope ofthis paper.) While this is somewhat trivial, representing goalpolicies and utility functions with this approach will fail.

Figure 8 shows the high-level design, along with a fewkey attributes, of representing multiple policy rules. Note theuse of the abstract class PolicyRuleStructure, which servesas a common root of different types of policy rules.

Page 11: The design of a novel context-aware policy model to support machine-based learning and reasoning

Cluster Comput (2009) 12: 17–43 27

Fig. 9 PolicyRuleComponents

The PolicyRuleStructure class is used to define the con-cept of representing the structure of a policy rule. Supportedrule types include CA (condition-action, for backwardscompatibility), ECA (event-condition-action, preferred overCA), Goal, and Utility policies. Common attributes and re-lationships that are independent of the particular representa-tion of a policy rule are defined in the PolicyRuleStructureclass. For example, Fig. 8 defines two common attributes forhandling policy rules that fail to execute correctly, and moreimportantly, define an aggregation that relates a set of Poli-cyRules to a set of State Machines. Thus, any type of DEN-ng PolicyRule will be able to use a state machine to governbehavior. Subclasses of this class formalize the semanticsof different types of PolicyRules using a subsumption re-lationship. This enables DEN-ng to import different typesof PolicyRules, each with their own specific structure, andrepresent how each is used. This provides extensibility, sothat new PolicyRule types can be added without adverselyaffecting the overall design of the DEN-ng PolicyHierarchy.

From an ontological perspective, it is important to sepa-rate the semantics of the structural representation of the pol-icy rule from other concepts that are required to use the Pol-icyRule, such as PolicyTarget and PolicySubject. This en-ables other policy types, for example ManagementPolicy,to define the appropriate semantics as required. An exam-ple of a subclass that can be defined from PolicyRuleStruc-ture is ECAPolicyRule, which formalizes the semantics of aPolicyRule with an {Event, Condition, Action} structure. Inessence, an ECAPolicyRule is a PolicyRule that has at leastone of a PolicyEvent, a PolicyCondition and a PolicyAction.

A unique feature of this model is the definition of thePolicyRuleMetaData class, which defines the basic meta-data that applies to different types of policy rules, such asECAPolicies. This decouples common metadata that differ-ent Policy representation systems need from the actual real-ization of the Policy, enabling all PolicyRules to share com-

mon metadata while enabling specific types of PolicyRulesto define their own particular metadata. It also decouples therepresentation and structure of a particular type of policy(e.g., an ECAPolicy) from the metadata. This is critical forproperly constructing ontologies from policy models.

A similar approach is used to for PolicyRuleCompo-nents, and is shown in Fig. 9. The three subclasses re-peat this abstraction in order to define different types ofevents, conditions and actions; PolicyRuleComponentMeta-Data and PolicyRuleComponentStructure mirror the use ofthe PolicyRuleMetaData and PolicyRuleStructure classes.

All PolicyRuleComponents use a common pattern, anexample of which is shown in Fig. 10 for PolicyEvents.Each of the xxxStructure classes has two subclasses—anxxxGroup and an xxx class (so, for Fig. 10, the Poli-cyEventStructure class has the PolicyEventGroup and thePolicyEvent subclasses). Each xxxGroup class has twoaggregations, a recursive one for forming hierarchies ofxxxGroups, and one that contains the xxx class instances.Each of the xxx classes has three subclasses, an xxxCom-posite to form containers of xxx instances, an xxxAtomic torepresent stand-alone xxx instances that have “standard” at-tributes defined in this model, and an xxxNonStd, which is ageneric extension mechanism for representing xxx instancesthat have not been modeled with the attributes specified inthis model. A PolicyClause, which is shown in Fig. 11, isused to enable a standard three-tuple ({variable, operator,value} to be used to define clauses for policy events, condi-tions, and actions. The DEN-ng model defines standard ob-jects for variables, operators and values; hence, a completePolicyClause can be completely developed out of standard,object-oriented classes. This is similar in principle to lan-guages such as Smalltalk. In contrast, the PolicyEventNon-Std class defines the eventEncoding and eventData proper-ties for defining the format and content of a vendor-specificevent, and the eventResponse property for providing a stan-

Page 12: The design of a novel context-aware policy model to support machine-based learning and reasoning

28 Cluster Comput (2009) 12: 17–43

Fig. 10 PolicyEventStructure diagram

Fig. 11 PolicyClause model

dard result. For example, the eventEncoding attribute canpoint to an entry in a Registry that defines how to interpretthe eventData information.

5.6 Metadata for PolicyRules and PolicyRuleComponents

Figure 12 provides an overview of how metadata is usedwith the new policy model. PolicyMetaData subclasses(generic) MetaData to define metadata that is specific to

PolicyRules and PolicyRuleComponents. In particular, thepriority attribute can be used for conflict resolution, and thepolicyValidFor attribute defines a time period during whichthat policy object is valid. This provides a high-level hookfor external applications and administrators to govern theuse and application of policies.

The four different xxxConstraints attributes enable ex-ternal applications and/or the administrator to populate theconstraint that will be applied. The MandatoryEvaluation at-

Page 13: The design of a novel context-aware policy model to support machine-based learning and reasoning

Cluster Comput (2009) 12: 17–43 29

Fig. 12 MetaData overview

tribute is used to ensure that a particular PolicyRule is al-ways evaluated. This is necessary because a decision strat-egy could be “match first”, meaning that as soon as any oneof a set of PolicyRules is triggered, the rest are skipped. Notethat the ManagementPolicyMetaData class does not define asimilar attribute, since (as will be seen), PolicyRules are ag-gregated by a ManagementPolicy.

5.7 Event-Condition-Action PolicyRules in detail

The ECAPolicyRule subclass is used to define a particulartype of PolicyRule—one that has an {Event, Condition, Ac-tion} structure, as shown in Fig. 13. In keeping with theoriginal DEN-ng model as defined by [36], this class repre-sents an intelligent container that gathers metadata and Pol-icyEvents, PolicyConditions, and PolicyActions. As such,it doesn’t have an inherent relationship with PolicySubject,PolicyTarget, or any particular level of the Policy Contin-uum; these all represent bound semantics for a particular useof an ECAPolicyRule. Different types of policy rules willuse these and possibly other elements to add content withinthe structure defined by a PolicyRule.

Another change was how PolicyRules were grouped. Fig-ure 14 shows an overview of this process.

The ECAContainedPolicyGroups aggregation is usedsolely to nest PolicyGroups. In contrast, the PolicyGroup-ContainsECAPolicyRules aggregation is used to define the

set of ECAPolicyRules that are contained in a particular Pol-icyGroup. These two aggregations differentiate the seman-tics between simple nesting of policy rules versus a morecomplex composition of policy rules. This makes sense fromthe ontology point-of-view: since there is a distinct seman-tic difference between a PolicyGroup (which is just a simplecontainer) and an ECAPolicyRule (which has a fixed struc-tural semantic form). While both the new PolicyGroup andECAPolicyRule classes are containers, they contain verydifferent things and have very different semantics.

The new DEN-ng model allows policy events, conditions,and actions to not just be aggregated by an ECAPolicyRule,but to also be applied to an ECAPolicyRuleGroup. Eachof the three associations linking an ECAPolicyRuleGroupto a policy event, condition, or action is realized using anassociation class in order to capture additional semanticsthat define how the PolicyRuleComponent interacts with theECAPolicyRuleGroup. For example, PolicyActions can beused to change the decision strategy of a PolicyGroup; Pol-icyConditions can be used to test a fact or inference to beused to affect the behavior of a PolicyGroup; PolicyEventscan be used to trigger the evaluation of a PolicyConditionthat is attached to a PolicyGroup.

5.8 PolicySubjects, PolicyTargets, and ManagementPolicy

A PolicySubject is a set of entities that represent the author-ity imposing policy. The PolicySubject can make policy de-

Page 14: The design of a novel context-aware policy model to support machine-based learning and reasoning

30 Cluster Comput (2009) 12: 17–43

Fig. 13 The ECAPolicyRule class

cision and information requests, and it can direct policies tobe enforced at a set of PolicyTargets. A PolicyTarget is a setof entities that a set of policies will be applied to. The objec-tive of applying policy is to either maintain the current stateof the PolicyTarget or to transition the PolicyTarget to a newstate.

In the old DEN-ng model, these were directly associatedwith a PolicyRule. In the new DEN-ng policy model, wecould associate them with a new subclass of the ECAPol-icyRule. However, this would have the unfortunate effectof binding the usage of PolicySubject and PolicyTarget toan ECAPolicyRule (instead of any type of policy rule). In-stead, we define a new construct called ManagementPolicy,as shown in Fig. 15. By using ManagementPolicy to aggre-gate one or more PolicyRuleStructure objects, we can in-termix different types of policy rules to realize an efficientmanagement directive.

Since the PolicyRule only defines the structure and meta-data of the policy rule, a separate concept is needed to builddifferent types of policy rules and apply them to the man-aged environment. The PolicyCategory abstract class is usedto define how a Policy is used (e.g., what type of Policythis instance is). Important subclasses include managementpolicies, application-specific policies, (e.g., backup, storage,query), and governance policies (management of policies).This paper will only examine management policies.

A ManagementPolicy is used for realizing deontic ac-tions (e.g., authorizations, obligations, and prohibitions) thatgovern behavior. These are independent of the actual struc-ture of the PolicyRule being used. That is, one set of Man-agementPolicies using ECAPolicyRules can be defined forvarious deontic actions (e.g., authorization and obligation)by aggregating the appropriate type of rule structure usingthe aggregation ManagementPolicyHasPolicyRules.

ManagementPolicy is the superclass for PolicyRules thatmanage a system. As such, ManagementPolicy has explicitassociations with PolicySubjects and PolicyTargets, definedthrough the SubjectInteractsWith and TargetInteractsWithassociations.

5.9 Deontic PolicyRules and MetaPolicies

In the old DEN-ng design, the semantics of deontic policiescould only be defined as subclasses of the PolicyRule class.This means that the concept of deontic logic is derived fromthe structural representation of a policy rule combined withassociations to policy subjects and policy targets. With ournew approach, we can define the concept of deontic logicseparate from how it is represented, thereby allowing differ-ent structural forms of policy rules to be able to be used torepresent deontic logic. Furthermore, we reinforce the con-cept that management is a deontic process by defining the

Page 15: The design of a novel context-aware policy model to support machine-based learning and reasoning

Cluster Comput (2009) 12: 17–43 31

Fig. 14 Groups of PolicyRules

ManagementPolicy abstract class to be the superclass of alldeontic policy rules. Finally, since the associations betweenManagementPolicy and both PolicySubject as well as Pol-icy Target are completely optional (since their multiplicityis 0..n–0..n), we are free to define deontic management as afunction of PolicySubject and/or PolicyTarget. The flexibil-ity described here does not exist in any other policy modelto date.

Figure 16 shows the derivation of DeonticPolicy andManagementMetaPolicies, which operate on DeonticPoli-cies. They are shown in more detail in Fig. 17.

This version of DEN-ng defines four types of deonticpolicies—authorization (may), obligation (must), prohibi-tion (may not), and exemption (need not), and two typesof metapolicies (delegation and revocation). Each of thesehas two subclasses (not shown), one for a subject-based ver-sion and another for a target-based version. This provides anumber of significant benefits that are not currently availablein other policy models. First, the literature takes the sim-

plistic view of defining subject-based obligation and target-based authorization (e.g., Ponder [3]). In addition to pro-viding target-based obligation and subject-based authoriza-tion, this model also enables the definition of an authoriza-tion policy that is jointly dependent on its subject and target.Second, in a distributed system, the concepts of delegatingfunctionality and revoking that functionality are very im-portant. We explicitly represent delegation and revocationas separate concepts so that they can be related to deonticpolicy rules. However, there must be a PolicyRule in placefor them to act on—hence, they are classified as metapoli-cies. Third, by explicitly differentiating between subject-,target-, and jointly-dependent policies, we make the seman-tics associated with different types of policy rules explicit,and hence easier to both define as well as detect. This con-siderably simplifies policy rule conflict detection and reso-lution. Along these lines, by formally defining subject andtarget-based forms of deontic policies, we can more explic-

Page 16: The design of a novel context-aware policy model to support machine-based learning and reasoning

32 Cluster Comput (2009) 12: 17–43

Fig. 15 ManagementPolicyoverview

Fig. 16 MakingManagementPolicy moreextensible

itly model complex orchestration that is needed in next gen-eration and autonomic systems.

Authorization embodies the concept of “is permitted to”or “is allowed to”. Deontic logicians assign the concept

“may” to authorization. A subject-based authorization pol-icy is a policy that is enforced by a subject, and definesthe actions that a subject is permitted to perform on oneor more targets. Conceptually, subject-based authorization

Page 17: The design of a novel context-aware policy model to support machine-based learning and reasoning

Cluster Comput (2009) 12: 17–43 33

Fig. 17 RealizingDeonticPolicy rules

policies are designed to define actions that can be performedon the target by the subject that will not adversely affect thesubject. In contrast, target-based authorization policies areenforced by the target, and define the actions that a targetpermits a subject to perform on the target.

Prohibition defines the set of actions that an entity is for-bidden to execute on another entity. Deontic logicians as-sign the concept “may not” to authorization. Hence, subject-based prohibition policies are enforced by the subject, anddefine actions that the subject is forbidden to perform ona target, because performing such actions would jeopardizethe subject. Target-based prohibition policies are enforcedby the target, and define the actions that a target forbids asubject to execute on that target.

Obligation defines the set of actions that one entity mustperform on another entity. Deontic logicians assign the con-cept “must” to authorization. Subject-based obligation poli-cies are enforced by the subject, and define the set of actionsthat a subject must do on a target. Target-based obligationpolicies are enforced by the target, and define the set of ac-tions that the subject must do on a target.

Exemption is, literally, immunity or release from anobligation. Deontic logicians assign the concept “need not”to authorization. Subject-based exemption policies are en-forced by the subject, and define the set of actions that thesubject need not perform on the target. Target-based exemp-tion policies are enforced by the target, and define the set ofactions that the subject need not perform on the target.

Delegation defines the ability for a sender to confer somefunction or privilege, to a receiver. Subject-based delegationpolicies are enforced by the subject, and apply a subject-based policy to a receiver. Similarly, a target-based delega-tion policy is enforced by the target, and applies a target-based policy to a receiver.

Revocation policies are used to retract functionality thatwas previously delegated. Subject-based revocation policiesare enforced by the subject, and retract a subject-based pol-icy from a receiver. Target-based revocation policies are en-forced by the target, and retract a target-based policy from areceiver.

6 The design of the new context model

In order to accommodate as flexible a set of definitionsas possible, the core of our context design consists of twoclasses, Context and ContextData, as shown in Fig. 18.

The DEN-ng model enables context to consist of multipledistinct sets of related data and knowledge. Therefore, weuse two different classes to represent context. The Contextclass is used to represent a completely assembled represen-tation of context, while the ContextData class is used whencontext contains multiple distinct types of different data thatneed to be combined in order to determine the overall con-text of an entity. For example, when modeling a phone callwhich can involve handover between two different technolo-

Page 18: The design of a novel context-aware policy model to support machine-based learning and reasoning

34 Cluster Comput (2009) 12: 17–43

Fig. 18 Core of the DEN-ng context model

gies, we instantiate two different sets of “sub-contexts”—each consists of a collection of ContextData classes that isbound to a particular technology. This enables us to bettermanage the phone call, since the underlying technologiesare themselves fundamentally different.

In FOCALE, we implement the above notion in areusable manner by providing a generic mechanism for as-sociating detailed models and ontologies with content. Con-sider the concept of location. Instead of defining a “locate-dAt” attribute in the Context class (which would necessarilyhave a fixed meaning associated with it), we can have theContext class reference a set of location classes that providemore detailed information and semantics for what location“means” to the Context of this particular ManagedEntity.This also allows the semantics of location to change as afunction of context.

Figure 19 shows how this approach works in practice.First, we define a ContextData to represent the concept oflocation. We link the ContextData class to a set of locationclasses, which describe the location in a reusable way. Thephysical characteristics of the location are defined in thisset of Location classes, while the semantics of the locationare defined in the ContextData classes. Note that locationis more than just latitude and longitude, but also includesheight, proximity, co-location with other entities, and orien-tation. This genericity is why a set of classes (and appropri-ate units of measurement in 2-D or 3-D space) are requiredfor defining location, as opposed to a simple attribute. Inparticular, this enables other applications that use the con-

cept of location to reuse not just the set of classes describingthe location, but the ContextData classes that are linked toit. In this way, we create reusable context models that areapplication-independent.

Flexibility is provided through the model. The asso-ciations relating ManagedEntity to Context and Context-Data are optional. The association ContextDataHasLoca-tionSemantics is used to pull location information in tobe analyzed; ContextDataFacts and ContextDataInferencesare then produced describing the location. (Note that Con-textFact and ContextInference are subclasses of Context,and serve a similar purpose as their ContextData brethren,but are not shown for simplicity.) For example, the GPS co-ordinates of two people in the same city can be comparedto compute the proximity of one to the other. As anotherexample, inference can be used to determine which peopletrapped in a building that has a fire are in greater danger.

The DEN-ng ContextData taxonomy is divided into adomain-independent portion (its “Upper Ontology”) and aset of domain-specific portions, as shown in Fig. 20. Theupper ontology captures generic context knowledge, whileeach domain-specific ontology delineates the details of con-cepts defined in the upper ontology in a manner specificto each sub-domain. This enables reusable context modelsto be created by attaching application-specific ContextDataDomain Specific Ontology data to ContextData Upper On-tology information. This separation of common vs. domain-specific semantics reduces the burden of context process-ing for each individual application, and ensures simple re-

Page 19: The design of a novel context-aware policy model to support machine-based learning and reasoning

Cluster Comput (2009) 12: 17–43 35

Fig. 19 Example of ContextData for location

Fig. 20 DEN-ng ContextDataTaxonomy

purposing through its ability to dynamically connect or dis-connect different ontologies to or from the upper ontologyin order to meet the needs of resource-constrained devices,such as a cell phone.

This latter is an important design consideration. For ex-ample, when a user leaves his home to drive to work, oursystem can swap out the “home context” ontology with a“car context” ontology that reflects the different devices andtheir capabilities that the user now has access to. Similarly,

when the user arrives at work, the “car context” ontology isswapped out with the “work context” ontology. Each contextmodel is reusable, and from a processing point-of-view, eachmodel only needs to be loaded when the context changes tomake it relevant. This streamlined processing is critical forapplications such as those embedded in cell phones, sincethey do not have a lot of freely available processing power.

Our Upper Ontology consists of five top-level types ofinformation: ManagedEntity, Location, Time, Activity, and

Page 20: The design of a novel context-aware policy model to support machine-based learning and reasoning

36 Cluster Comput (2009) 12: 17–43

Fig. 21 DEN-ng core context model extensions

PersonOrGroup. Each of these information types is detailedin the DEN-ng information model. This is similar to [11];notable differences are (1) the DEN-ng ManagedEntity classis more generic than the ComputationalEntity of [11], (2)the DEN-ng PersonOrGroup is more generic than the Personof [11], and (3) time is missing in [11]. While the first fourtypes of ContextData can all be valid for a particular time,the purpose of the fifth (Time) class is to model informationthat is purely temporal in nature.

Both the Context and ContextData classes use the com-posite pattern for flexibility and extensibility. The Contex-tAtomic and ContextDataAtomic classes represent contextthat can be modeled as a single, stand-alone object. Incontrast, the ContextComposite and ContextDataCompos-ite classes represent context objects that are composite innature (e.g., made up of multiple distinct Context or Con-textData objects that can each be separately managed). Thisworks because a ContextComposite class aggregates Con-text, and both ContextAtomic and ContextComposite in-herit from Context. (This same line of reasoning applies toContextData.) The design shown in Fig. 18 enables hierar-

chies of context information to be related to other hierar-chies of context information. Each context node (a Contextobject) can have a set of ContextData objects that providefurther detail describing the characteristics and behavior ofthat node. For example, the Context object “Communica-tion” could have the following ContextData objects associ-ated with it: PSTN (to model the characteristics of fixed tele-phone lines), CellularDevice (to model the characteristics ofmobile phones and PDAs), ComputerDevice (to model thecharacteristics of laptops and desktops) and VisualAudioDe-vice (to model the characteristics of a television with Inter-net capability). Each of these four classes of device uses dif-ferent types of media and provides different types of com-munication experiences. This model is especially useful tomodel a user that has access to one or more of these devicesat any particular time; in this case, the model defines howthe user can communicate.

The purpose of the ContextDataDetails association classis to define the particular semantics of how ContextData re-lates to Context. This enables different types of Context-

Page 21: The design of a novel context-aware policy model to support machine-based learning and reasoning

Cluster Comput (2009) 12: 17–43 37

Data, each modeling a specific aspect of an overall Context,to be aggregated together with their own semantics.

The ContextDataFact and ContextDataInference classesare used to represent additional data that is either knowna priori or can be inferred from other knowledge about agiven ContextData. For example, a given access point’s sig-nal strength can vary over time—this can be observed by asensor and a decision made as to whether the access pointis stable enough to support mission-critical data communi-cation over an encrypted link or not. Similar capabilities ex-ist for the Context class—it has ContextFact and ContextIn-ference subclasses. In both cases, these Fact and Inferenceclasses complete the Context (or ContextData) model, andrepresent conclusions from examining the associated DEN-ng data attached to them (e.g., the location information at-tached to the ContextData class in Fig. 19).

Figure 21 enhances the above basic model in several im-portant ways. First, it provides placeholders for modelingadditional semantics that are beyond the ability of UML tomodel. The ContextSemantics and ContextDataSemanticsclasses represent data and/or knowledge that describes thebehavioral aspects of the Context and ContextData objects,respectively, that this ManagedEntity are associated with,and represent a convenient point for fusing information fromontologies with data from information and data models. Thisdone by using these points to associate code generated fromthe model with code generated from the ontologies. Thisin turn enables modeled data, which represent facts, to beaugmented with additional semantics from ontological data;this combination forms an efficient and self-describing set ofknowledge that can be fed into machine-based learning andreasoning systems [34]. They also present convenient pointsfor either augmenting context information (e.g., tagging itwith metadata to enhance information retrieval) and/or us-ing context data to perform (for example) a set of services.Finally, these two semantics classes enable the applicationto declare what it needs to complete its view of context, asopposed to merely obtaining context information. However,these latter examples are each complex processes and be-yond the scope of this paper.

Identity enables the system to unambiguously refer toan object instance. The identifier has to be unique in thenamespace that the object instance exists in.

Time is a common attribute of context. For example, timecan determine when something is allowed to be used, orwhen use is no longer permitted. Since time can be handleddifferently for different types of contexts, we define two as-sociation classes (ContextDataAffectedByTimeDetails andContextAffectedByTimeDetails) to represent the semanticsof the corresponding associations ContextDataAffectedBy-Time and ContextAffectedByTime, respectively.

[36] defines a policy as “Policy is a set of rules that areused to manage and control the changing and/or maintaining

of the state of one or more managed objects”. In FOCALE,context is related to the state of an entity [41]. State can varyfrom object type to object type. For example, for a person,it can refer to the activity that the person is currently doing,physiological factors such as whether the person is sick ortired, whether the person is busy or not, different physicalconditions, and other factors. In contrast, the state of a net-work device includes its operational status, its power state,and other attributes that can be queried.

In particular, changes in context trigger state transitionsthat adjust the behavior the entity in accordance with thechanges in the environment that it exists in. For example,imagine a user is switching between a business profile andan entertainment profile. The former uses a special serviceprovider that offers encrypted, highly secure communicationfor business use, while the latter uses a completely differentset of service providers (one for local and a different one forlong distance calling) as well as links to social networks. Inthis situation, the policies defined as being usable for thatcontext state will in general be different: some policies maybe the same (e.g., rules about which devices can be used),some policies may be completely different (e.g., rules aboutwhich services can be used), and some policies may be mod-ified (e.g., rules that govern communication).

Khedr and Karmouch [23] define three types of context.Passive context is when an application presents new or up-dated context data to a user, but does not adapt its functional-ity or behavior as a result of context changes. Active contextis when an application automatically adapts its functional-ity to discovered changes in context, by changing the appli-cation’s behavior. Spontaneous context is when an applica-tion must be able to cope with the uncertainty and vaguenessof acquired context information. DEN-ng supports all threeuses of context; the type of algorithms and amount of rea-soning that must be done is a function of the specific needsof the application and, more importantly, whether the con-text is passive, active, or spontaneous. Figure 22 shows con-ceptually how context is used to affect policy.

The SelectsPoliciesToActivate aggregation defines a setof Policies that should be loaded and activated based onthe current context. Hence, as context changes, policy canchange accordingly, enabling our system to adapt to chang-ing demands. Note that this selection is an “intelligent de-cision”, in that the selection process depends on other com-ponents that are part of a particular context. Another “intel-ligent decision” is the PolicyResultAffectsContext associa-tion, which enables policy results to influence Context viathe ContextControllerComponent, the application that man-ages Context. For example, if a policy execution fails, notonly did the desired state change not occur, but the contextmay have changed as well.

The selected working set of Policies uses the Con-textAwarePolicyEnablesManagedEntityRoles association to

Page 22: The design of a novel context-aware policy model to support machine-based learning and reasoning

38 Cluster Comput (2009) 12: 17–43

Fig. 22 Conceptual DEN-ng context-aware policy model

define and enable the appropriate ManagedEntity roles thatare influenced by this Context; each ManagedEntityRole de-fines functionality that the ManagedEntity can use. In thisway, policy indirectly (through the use of roles) controlsthe functionality of the system, again as a function of con-text. Similarly, ContextAwarePolicyEnablesMgmtInfo de-fines the set of management data that is useful for thisContext; ManagementInfoAffectsContext represents feed-back from these management data regarding the executionof the policy rule. Once the management information is de-fined, then the two associations MgmtInfoAffectsContextand ManagedEntityRoleAffectsContext codify these depen-dencies (e.g., context defines the management informationto monitor, and the values of these management data affectcontext, respectively).

Finally, the ContextControllerComponent defines its ownset of ManagedEntityRoles and ManagementInfo to use tomonitor the environment; feedback from the ManagedEn-tities identified by their roles and specific measurements(in the form of ManagementInfo) are used by the Con-textControllerComponent to operate its own finite state ma-chine (FSM). This FSM is used to orchestrate the actions

of the ContextControllerComponent, including which Man-agedEntities it should determine the context for, how a par-ticular element of context should be analyzed, and what pro-cedures for determining its context should be used.

7 Realizing context awareness

We provide a consistent and coherent set of knowledgethrough the use of the DEN-ng comprehensive information.This enables us to build a model-driven system [28], wherechanges to the model can be directly translated into changesin code. Thus, we are able to generate code to reconfigurethe system in response to a context change. This is a funda-mental advantage of our approach compared to other similarapproaches.

DEN-ng is best viewed as a toolbox that contains the el-ements to model application-specific behavior using mod-els [36]. The DEN-ng model can be viewed as containingsub-models of ManagedEntities, Context and ContextDatathat can be associated with each other to represent the be-havior and characteristics that an application requires.

Page 23: The design of a novel context-aware policy model to support machine-based learning and reasoning

Cluster Comput (2009) 12: 17–43 39

One of the main goals of our FOCALE autonomic ar-chitecture is to adapt network services and resources tochanging user needs, environmental conditions, and busi-ness goals [39]. FOCALE accomplishes this goal throughthe use of multiple types of adaptive control loops. Figure 2shows two types of control loops: a maintenance loop (the“yes” branch) and a reconfiguration loop (the “no” branch).A single control loop having fixed functionality, such as thatdescribed in [20, 22], cannot adjust to varying user needs,environmental changes, and business objectives. Hence, FO-CALE uses a set of different control loops. Since FOCALEis designed to adapt its functionality as a function of context,the loop controlling the reconfiguration process must be ableto have its functionality adapted to suit the vendor-specificneeds of the different devices being adapted.

For example, suppose that a particular type of manage-ment data is being collected. Referring to Fig. 2, this willhave the following effects:

• Set the sensors to retrieve a particular type of data.• Load appropriate data templates in the model-based trans-

lation function to enable disparate data management def-initions to be analyzed.

• Define a particular algorithm that uses pre-defined datastructures to analyze sensed data.

• Define a particular algorithm to enable these data to beanalyzed, so that the current state of the managed entityto which the management data belong can be determined.

• Define a particular algorithm to compare the computedcurrent state to the desired state, and from that informa-tion, create an orchestrated set of changes to implementthe state changes.

When context changes, the above ensures that the func-tionality of the appropriate control loops are changed tomatch the new nature of what is being governed [41]. Sim-ilarly, if the system is performing a goal and needs to tem-porarily change its focus (e.g., examine sensor data from adifferent data source and correlate those data with the datathat it is currently examining), the above processes can beused to again adapt the control loop.

Another important reason to use multiple control loopsis to protect the set of business goals and objectives of theusers as well as the network operators. The implementationof these objectives is different and sometimes in conflict—having a single control loop to protect these objectives issimply not feasible.

FOCALE performs these tasks by first, establishing thecontext; second, using that context to select a set of policiesthat govern the functionality of the system; third, using thosepolicies (via the autonomic manager) to control each of thefunctions of the multiple control loops shown in Fig. 2.

When context changes, the above ensures that the func-tionality of the appropriate control loops are changed to

match the new nature of what is being governed. Similarly,if the system is performing a goal and needs to temporarilychange its focus (e.g., examine sensor data from a differ-ent data source and correlate those data with the data thatit is currently examining), the above processes can be usedto again adapt the control loop. Another important reason touse multiple control loops is to protect the set of businessgoals and objectives of the users as well as the network op-erators. The implementation of these objectives is differentand sometimes in conflict—having a single control loop toprotect these objectives is simply not feasible.

The reconfiguration process uses dynamic code genera-tion based on models and ontologies [32, 34, 35, 38, 45].This enables the autonomic system to adapt to change byreconfiguring managed elements to perform different tasks.Note that this is facilitated by changing the structure andfunctionality of the control elements to suit the change.

The models are used to populate the state machines thatin turn specify the operation of each entity that the auto-nomic system is governing. Ontologies are used to augmentthe meaning of the nodes and edges in the state machine.The management information that the autonomic system ismonitoring signals any context changes, which in turn ad-justs the set of policies that are being used to govern the sys-tem, which in turn supplies new information to the state ma-chines. The goal of the reconfiguration process is specifiedby the state machines, which defines the (re)configurationcommands required.

8 Implementation

Our test system uses policy to govern the operation of a Cog-nitive Radio [24, 25, 34]. A high-level overview of our pro-totype system is shown in Fig. 23. The GUI enables poli-cies by four different types of policy authors—regulators,network operators, network equipment provides, and end-user/subscribers—to define and manage policies. The GUIsupports the business and system level of the policy contin-uum, and translates policies into an XML form. This is thenparsed to generate an object representation of the Manage-mentPolicy and its components. The GUI front end providesdifferent dialects of the DEN-ng policy language, whereeach dialect is aligned with a particular level of the policycontinuum. The GUI supports creating ManagementPoliciesas well as the underlying subjects, targets, events, condi-tions, and actions that the ManagementPolicy uses. As partof this process, other Managed Objects from the DEN-ngmodel can be specified and used. This enables the power ofthe DEN-ng model to be leveraged by its policy model. Forexample, the variables and values that are being comparedin a PolicyClause may correspond to a set of attribute valuesfor different Managed Objects in the DEN-ng model. A cus-tom Class Loader is used to resolve these references.

Page 24: The design of a novel context-aware policy model to support machine-based learning and reasoning

40 Cluster Comput (2009) 12: 17–43

Fig. 23 Conceptual overviewof the prototype

PolicyRules are always bound to a particular continuumlevel. PolicyRules are translated to a different continuumlevel by the PolicyEngine. The translation is done using acombination of pre-defined mappings as well as linguisticmechanisms; however, that is beyond the scope of this pa-per.

We define three fundamental types of policies for theaccess point (AP) and mobile station (MS) in our system.Transmission policies govern what can be transmitted andwhat can be received when, where, and why. Sensing poli-cies govern what should be sensed when, where, and how.This data is needed for the control loop to function. Gov-ernance policies define the list of APs that an MS (or evenan AP) should be associated with. The demonstration startswith one or more of these three types of policies defined.When an AP or MS is recognized by the system, one or moreof each of these policies are loaded into the MS or AP. Atthat point, the MS or AP is ready to be cognitively managed.

Several different test scenarios are demonstrated, includ-ing (1) a MS moves into a new location, prompting newpolicies for that location to be downloaded and executedthat govern how that MS can transmit and sense; (2) an MSis preempted by an emitter of higher priority (in our case,a wireless microphone) and hence must vacate its current

channel, scan for a new channel, and choose the “best” chan-nel to transmit; (3) the channel that is being used by an APor MS is subjected to interference, causing the AP or MSto again vacate, scan, and switch channels. In each case, theevent(s) that signal the change in the system cause one ormore ManagementPolicies to be executed that change theoperation of the radio. The changes are defined using anagent framework that translates sensed data to a common,normalized form that is processed by the system, which thensends normalized commands that are translated to AP or MSspecific commands.

9 Future work

We are building a new policy language that will be derivedfrom this policy model. It will consist of a number of di-alects, where each dialect supports one or more layers ofthe Policy Continuum. Since this policy model can be usedto generate ontologies, our new policy language will alsocontain syntactic and semantic links to concepts in our gen-erated ontology. This is a complex topic, and due to spacelimitations, will be deferred to a separate paper.

Page 25: The design of a novel context-aware policy model to support machine-based learning and reasoning

Cluster Comput (2009) 12: 17–43 41

Our context-aware policy model is also being consid-ered by the European research project, Autonomic Inter-net [1]. Within this project, we are creating a communica-tion resource overlay with autonomic characteristics for thepurposes of fast and guaranteed service delivery. The over-lay will be self-managed based on the system’s businessgoals which drive the service specifications, the subsequentchanges in these goals (service context) and changes in theresource environment (resource context). In achieving thisgoal, the information and context model will be used to re-alize an autonomic service-driven resource overlay. Hence,we would also like to acknowledge the support of Part ofthe European Commission under the EU IST FP7 project,Autonomic Internet (Grant agreement number 216404).

10 Summary

This paper has described a novel context-aware policymodel that has been designed for next generation networkedapplications and services. This new model enhances theoriginal DEN-ng policy model to make it more semanti-cally accurate. This in turn enables it to be used with otherknowledge engineering tools, such as ontologies and ma-chine learning, to reason about policies.

The FOCALE architecture is based on context-aware pol-icy management. Changes in context change the set of poli-cies that are being used; this in turn changes the allowedfunctionality that can be used in the system. Hence, changesin user needs and environmental conditions can be adjustedfor by the FOCALE architecture.

Future work will concentrate on automatic ontologygeneration, including updating the ontology to conform tochanges in the underlying information and policy models.We will build a new policy language that has the abilityto include syntactic and semantic links to both informationmodel objects as well as ontology concepts. We will thenapply these to our FOCALE test bed and use them in vari-ous Seamless Mobility experiments to measure how usefulontologies and a new policy language can be.

Acknowledgements This research activity is part of continuing jointresearch between Motorola Labs and WIT. We’d like to acknowledgeSven van der Meer, Brendan Jennings, Claire Fahy, Mícheál Ó Foghlú,and Willie Donnelly from WIT. In addition, this activity is partially co-funded by the Science Foundation Ireland (SFI) under the AutonomicManagement of Communications Networks and Services programme(grant no. 04/IN3I404C).

References

1. Bassi, A., Denazis, S., Galis, A., Fahy, C., Serrano, M., Ser-rat, J.: Autonomic Internet: a perspective for future internet ser-vices based on autonomic principles. In: 2nd IEEE International

Workshop on Modelling Autonomic Communications Environ-ments (MACE 2007) San José, United States, October 29–30,2007

2. Cox, G., Serrat, J., Strassner, J., de Souza, J.N., Raymer, D., Samu-drala, S., Jennings, B., Barrett, K.: An enhanced policy modelto enable autonomic communications. In: 5th IEEE Workshopon Engineering of Autonomic and Autonomous Systems (EASe),pp. 184–193, 2008

3. Damianou, N., Dulay, N., Lupu, E.C., Sloman, M.: The ponderpolicy specification language. In: LNCS Proceedings, IEEE 2ndInternational Workshop on Policies for Distributed Systems andNetworks, pp. 18–38, 2001

4. Damianou, N., Bandara, A., Sloman, M., Lupu, E.C.: A survey ofpolicy specification approaches. Department of Computing, Impe-rial College of Science Technology and Medicine, London, 2002

5. Davy, S., Jennings, B., Strassner, J.: Application domain indepen-dent policy conflict analysis using information models. In: 20thNetwork Operations and Management Symposium (NOMS) 2008,Salvador Bahia, Brasil, 2008

6. Davy, S., Jennings, B., Strassner, J.: Efficient policy conflict analy-sis for autonomic network management. In: 5th IEEE InternationalWorkshop on Engineering of Autonomic and Autonomous Sys-tems (EASe), Belfast, Northern Ireland, 2 April 2008

7. Dey, A.: Providing architectural support for building context-aware applications. Ph.D. Thesis (2000)

8. Ferraiolo, D., Cugini, J., Kuhn, D.: Role based access control: Fea-tures and motivations. In: Proceedings of the 11th Annual Con-ference on Computer Security Applications, pp. 241–248. IEEEComputer Society Press, Los Alamitos (1995)

9. Ferraiolo, D., Barkley, J., Kuhn, D.: A role-based access controlmodel and reference implementation within a corporate Intranet.ACM Trans. Inf. Syst. Secur. (TISSEC) 2(1), 34–64 (1999)

10. Fowler, M.: Analysis Patterns—Reusable Object Models. ISBN0-201-89542-0

11. Gu, T., Wang, X., Pung, H., Zhang, D.: An ontology-based contextmodel in intelligent environments. In: Proceedings of Communi-cation Networks and Distributed Systems Modeling and Simula-tion Conference, vol. 2004, 2004

12. http://www.alphaworks.ibm.com/tech/pmac13. http://citeseer.ist.psu.edu/355724.html14. http://dl.alphaworks.ibm.com/technologies/pmac/acpl.pdf15. http://www.dmtf.org/standards/cim/cim_schema_v214/16. http://hillside.net/patterns/17. http://www.motorola.com/content.jsp?globalObjectId=6611-9309

(2008)18. http://www.omg.org/cgi-bin/doc?ptc/2004-10-0519. http://www.tmforum.org/browse.aspx?catID=168420. IBM: An Architectural Blueprint for Autonomic Computing. v7,

June 200521. Kagal, L., Finin, T., Joshi, A.: A policy language for a pervasive

computing environment. In: Proceedings IEEE 4th InternationalWorkshop on Policies for Distributed Systems and Networks, June2003

22. Kephart, J.O., Chess, D.M.: The Vision of Auto-nomic Computing. In: IEEE Computer, January 2003.http://research.ibm.com/autonomic/research/papers/

23. Khedr, M., Karmouch, A.: Negotiating context information incontext-aware systems. IEEE special issue on context aware ap-plications 19(6), 21–29 (2004)

24. Mitola, J.: Cognitive Radio. In: Ph.D. thesis, KTH, Stockholm,Sweden, (2000)

25. Mitola, J.: Cognitive Radio Architecture: The Engineering Foun-dations of Radio XML. Wiley-Interscience, New York. ISBN0471742449

26. Ovesjö, F., Dahlman, E., Ojanperä, T., Toskala, A., Klein,A.: FRAMES multiple access mode 2—wideband CDMA. In:PIMRC 1997

Page 26: The design of a novel context-aware policy model to support machine-based learning and reasoning

42 Cluster Comput (2009) 12: 17–43

27. Prehofer, C., Bettstetter, C.: Self-organization in communicationnetworks: principles and paradigms. IEEE Commun. Mag. July(2005)

28. Raymer, D., Strassner, J., Lehtihet, E., van der Meer, S.: End-to-end model driven policy based network management. In: in Pro-ceeding of the 7th IEEE Workshop on Policies for DistributedSystems and Networks (Policy 2006), Western Ontario, London,Canada, 2006

29. Román, M., et al.: A Middleware Infrastructure for Active Spaces.IEEE Pervasive Comput. 1(4), 74–83 (2002)

30. Sandhu, R., Coyne, E., Feinstein, H., Youman, C.: Role-based ac-cess control models. IEEE Comput. 29(2), 38–47 (1996)

31. Sandhu, R., Ferraiolo, D., Kuhn, D.: The NIST model for rolebased access control: towards a unified standard. Postscript PDF.In: Proceedings 5th ACM Workshop on Role Based Access Con-trol, July 26–27, 2000, first public draft of proposal for an RBACstandard

32. Strassner, J.: Knowledge management issues for autonomic sys-tems. In: TAKMA 2005 Conference

33. Strassner, J.: Seamless mobility—a compelling blend of ubiqui-tous computing and autonomic computing. In: in Dagstuhl Work-shop on Autonomic Networking, Jan. 2006

34. Strassner, J.: Enabling autonomic network management decisionsusing a novel semantic representation and reasoning approach.Ph.D. thesis (2008)

35. Strassner, J.: Autonomic networks and systems: theory and prac-tice. In: NOMS 2008 Tutorial, Brasil, April 2008

36. Strassner, J.: Policy Based Network Management. Morgan Kauf-man. ISBN 1-55860-859-1

37. Strassner, J., Fu, Z.: Policy based enforcement of ubiquitous rolebased access control. In: 4th International IEEE Workshop onManaging Ubiquitous Communications and Services (MUCS),Munich, Germany, 25 May 2007

38. Strassner, J., Menich, B.: Philosophy and methodology for knowl-edge discovery in autonomic computing systems. In: PMKD 2005Conference

39. Strassner, J., Raymer, D.: Implementing next generation servicesusing policy-based management and autonomic computing princi-ples. In: NOMS 2006, Vancouver, Canada, 2006

40. Strassner, J., Agoulmine, N., Lehtihet, E.: FOCALE—a novelautonomic networking architecture. Int. Trans. Syst. Sci. Appl.(ITSSA) J. 3(1), 64–79 (2007)

41. Strassner, J., Samudrala, S., Cox, G., Liu, Y., Jiang, M., Zhang,J., van der Meer, S., Ó Foghlú, M., Donnelly, W.: The designof a new context-aware policy model for autonomic networking.In: 5th IEEE International Conference on Autonomic Computing(ICAC), Chicago, Illinois, 2–6 June 2008

42. Toninelli, A., Montanari, R., Kagal, L., Lassila, O.: A semanticcontext-aware access control framework for secure collaborationsin pervasive computing environments. In: Proceedings 5th Interna-tional Semantic Web Conference (ISWC), pp. 473–486, Novem-ber 2006

43. W3C: Composite Capabilities/Preferences Profile (CC/PP). http://www.w3.org/Mobile/CCPP

44. WAPFORUM: User Agent Profile (UAProf). http://www.wapforum.org

45. Wong, A., Ray, P., Parameswaran, N., Strassner, J.: Ontology map-ping for the interoperability problem in network management.J. Sel. Areas Commun. 23(10), 2058–2068 (2005)

John Strassner is a Professor ofComputer Science at Waterford In-stitute of Technology. Previously, hewas a Motorola Fellow and VicePresident of Autonomic Researchat Motorola Labs. Before that, hewas the Chief Strategy Officer forIntelligence and a former Cisco Fel-low. John is the Chairman of theAutonomic Communications Fo-rum. John invented DEN (Direc-tory Enabled Networks) and DEN-ng as a new paradigm for manag-ing and provisioning networks andnetworked applications. He was the

past working group chair for P1900.5, which works on policy lan-guages and architectures for dynamic spectrum access (part of IEEESCC 41). He is also the past chair of the TMF’s NGOSS SID, meta-model and policy working groups. He has authored two books (Di-rectory Enabled Networks and Policy Based Network Management),written chapters for 4 other books, and has been co-editor of five jour-nals dedicated to network and service management and autonomics.John is the recipient of the Daniel A. Stokesbury memorial award forexcellence in network management, is a member of the Industry Ad-visory Board for both University of California Davis and DePaul Uni-versity, a TMF Fellow, and has authored 203 refereed journal papersand publications.

José Neuman de Souza is a Re-searcher and Associate Professorat the Federal University of Ceará,Brazil. He holds a D.Sc. degree atParis VI (Pierre et Marie Curie)University, France, since 1994. From1990 to 1994 he was technical mem-ber at the European projects PEM-MON, ADVANCE and ICM, devel-oping solutions to Telecommunica-tions Network Management. His re-search interests areas include but arenot restricted to network and servicemanagement, QoS, grid computing,high speed and pervasive networks.

He was General Chair of the 11th IEEE/IFIP ICT 2004 and 3rdIEEE/IFIP MMNS 2000 and he has been serving in several TechnicalProgram Committees of international (and national) conferences onTelecommunications and Networking. Nowadays he has been servingon the Editorial Board of Computer Networks, Computer Communi-cations and Journal of Network and Computer Applications (Elsevier).He is the editor of the Lecture Notes in Computer Science (LNCS)3124 and 3126 (Springer) and the book Managing QoS in MultimediaNetworks and Services printed by Kluwer Academic Publishers. Hehas spent a month as invited Professor at the LiPN-Paris 13 Universityin 2005 and 2006 as well as at Ottawa University, Canada, in 2007.From 2000 to 2005 he was member of the Administration Council ofthe Brazilian Research National Network. He has been the Brazilianrepresentative at the IFIP TC6 (Communications Systems) since 1999.

Page 27: The design of a novel context-aware policy model to support machine-based learning and reasoning

Cluster Comput (2009) 12: 17–43 43

Srini Samudrala is a Software Re-searcher in the Applied Technologyand Research Center at Motorola.He completed his Masters in Com-puter Engineering from Universityof Texas at Dallas and Bachelors inElectrical Engineering from Mum-bai University, India. He has morethan 7 years of experience in theSoftware industry, specializing inScalable Distributed Systems, SOAand User Experience. His researchinterests include, but are not limitedto, Policy, Distributed Control andDecision Making, User Experience,SDPs and AI.

Steven Davy is a Researcher inthe Telecommunication Software &Systems Group located at Water-ford Institute of Technology in Ire-land. He recieved a first class ho-nours degree in Computer Sciencefrom Trinity College Dublin in 2003and his Ph.D. from the WaterfordInstitute of Technology in 2008.His research interests include, net-work and service management us-ing Policy-based Management par-adignms. He is particluarly inter-ested in formal policy analysis foruse in QoS, autonomic communica-tions and cognitive networks.

Keara Barrett is a lecturer in theDepartment of Computing and Net-working at Institute of Technol-ogy Carlow, Ireland. She is alsoaffiliated with TelecommunicationSoftware and System Group whereshe worked as a research assistanton both national and internationalprojects. She is presently complet-ing postgraduate research under thesupervision of Prof. John Strassnerand Dr. Sven van der Meer. Herprincipal research interests includecomparing the semantics of policylanguages, varied ontology applica-tions and mobile networking.