Modelling Context for Autonomic Networking

Abstract

This paper describes a new version of the DEN-ng context model, and how this model in conjunction with the DEN-ng policy model can be used for more effective and flexible context management for autonomic networking. Both are part of the FOCALE autonomic network architecture. Context selects policies, which select roles that can be used, which in turn define allowed functionality for that particular context. A brief description of applications of this model for the FP7 Autonomic Internet project are described.

Full text

Page 1

Modelling Context for Autonomic Networking

John Strassner1, Yan Liu1, Michael Jiang1, Jing Zhang1,
Sven van der Meer2, Mícheál Ó Foghlú2, Claire Fahy2, Willie Donnelly2

1Motorola Labs, Schaumburg, IL, USA
{john.strassner, yan.liu, michael.jiang, jing.zhang}@motorola.com
3TSSG, Waterford Institute of Technology, Ireland
{vdmeer, mofghlu, cfahy, wdonnelly}@tssg.org

Abstract. This paper describes a new version of the
DEN-ng context model, and how this model in
conjunction with the DEN-ng policy model can be used
for more effective and flexible context management for
autonomic networking. Both are part of the FOCALE
autonomic network architecture. Context selects policies,
which select roles that can be used, which in turn define
allowed functionality for that particular context. A brief
description of applications of this model for the FP7
Autonomic Internet project are described.
Keywords: Autonomic Architecture, Autonomic Networking,
Context Management, FOCALE, Semantic Reasoning.
I.
INTRODUCTION
This paper extends our previous policy paper [1] to more
thoroughly discuss our evolving model of context, and to
present a newer, more powerful context model. Network
convergence (which combines different types of wired and
wireless networks), cognitive networks [2] (in which the type
of network access can be dynamically defined), and Seamless
Mobility [3] (the ability for the user to get and use data
independent of access mode, device, and media) all seek to
provide context-aware services, in which offered services
may change when context changes. One of the fundamental
principles of autonomic computing [4] [5] [6] is to be able to
detect changes in the environment, as well as needs of the
user or business, and change the system functionality
provided in accordance with those changes while obeying
business objectives. While autonomic architectures to date do
not adequately address the subject and needs of context
awareness, the FOCALE autonomic architecture [7] was
defined to use context to choose policies that in turn govern
the functionality provided by a device, component or system.
This paper builds on this initial approach.
Our approach for implementing context-aware services is
realized as the FOCALE autonomic architecture, and is based
on five key concepts. First, we use the DEN-ng information
model [8] as a shared lingua franca to map different types of
vendor-specific management data used in Operational and
Business Support Systems (OSSs and BSSs) to a common
form. Second, since information and data models are not
capable of representing the detailed semantics required to
reason about behaviour, we augment our use of knowledge
extracted from information and data models with ontologies.
Conceptually, models provide facts, while ontologies
augment the meaning of those facts to enable semantic
reasoning. Third, we define a new, enhanced context model
that, while constructed from an information model, has been
specifically designed to be able to link to ontologies for
governing behaviour. Fourth, we link this context model to
the policy model of [1], so that policies can be written that
adapt offered resources and services to sensed context
changes. Finally, we build an adaptive control architecture,
where context-aware policies are used, together with machine
learning and reasoning, to dynamically adapt the structure
and functionality of the autonomic control loops.
The creation of this context model feeds into the work of
the European research project, Autonomic Internet [21].
Within this project, we are endeavouring to create a
communication resource
characteristics for the purposes of fast and guaranteed service
delivery. The overlay will be self-managed based on the
system’s business goals which drive the service specifications,
the subsequent changes in these goals (service context) and
changes in the resource environment (resource context). In
achieving this goal, the DEN-ng information and context
model will be validated towards the requirements of such an
autonomic service-driven resource overlay.
The organization of this paper is as follows. Section 2
provides a brief introduction to autonomic computing and
networking. Section 3 describes the design of the newly
revised DEN-ng context model. Section 4 summarizes the
DEN-ng policy model from [1] and links these two models
together. Section 5 shows how context-aware policies meet
the needs of cognitive networks and Seamless Mobility
applications. Section 6 presents related work, and Section 7
summarizes the paper.
overlay with autonomic
II. CONTEXT DEFINITION AND APPLICABILITY TO
AUTONOMIC NETWORKING
There are a host of definitions of context. One of the most
common is from Dr. Anind Dey from Berkeley Research
Labs, who defines context as “any information relevant to an
interaction that can be used to characterize the situation of an
entity. An entity is a person, place, or object that is
considered relevant to the interaction between a user and an
application, including the user and application themselves”.
[9]
It is interesting to note Dey’s rationale for his definition,
compared to previous definitions: “We cannot enumerate
which aspects of all situations are important, as this will

Page 2

change from situation to situation. For example, in some
cases, the physical environment may be important, while in
others it may be completely immaterial.” [9] While we agree
with this logic, the above definition has some significant
shortcomings when it is applied to autonomic computing or
autonomic networking. There are five primary reasons for
this.
First, context is more than “just” data or information – it
is knowledge. We use the following definitions for these
three terms. Data is an arbitrary, informal piece of
information without explicit structure or format. DEN-ng
imposes a common structure and format on that data, which
turns the data into information. Information is defined for a
particular context, which enables different meanings to be
associated with information that are context-specific. (Note
that this step also eliminates information that is not relevant
for a particular context.) When contextual information is
interpreted and understood using one or more interpretation
rules, we then have knowledge. We explicitly model
knowledge using a combination of models and ontologies,
and update this knowledge using machine learning and
reasoning.
The second thing that is odd about this definition is the
phrase “characterize the situation of an entity”. First of all,
why does an entity have to be in a situation to define context?
Second, situation connotes “relation to its surroundings”,
which implies that context is focused on location. We think
that location is important, but it is “just another aspect” of
context. [10] Hence, we have built an extensible model,
based on a set of software patterns [11] [12], to represent an
aggregate model of context, where the specific aspects of
knowledge to be aggregated are determined by context-aware
policies.
The third problem is the lack of formal definitions of
concepts that involve and interact with context. For example,
the phrase “An entity is a person, place or object” includes
only some concepts that are relevant, and doesn’t include
such concepts as communication, walking, being in a noisy
environment, or numerous others. This is the fundamental
reason why we base our context model definition in an
object-oriented information model constructed from software
patterns – we are thus able to leverage the work in the
information model to dynamically adjust the definition of
context to meet application-specific needs.
The fourth thing that is problematic is the phrase
“interaction between a user and an application”. Why does
context only exist if there is an interaction between a user and
an application? Isn’t the fact that I’m sleeping and do not
want to be woken up context? How about the example of a
pressure sensitive floor with no one walking or sitting or
standing on it – does the floor now not have any context?
Surely the fact that no one is walking or sitting or standing on
the floor is context in and of itself? This is one area where we
need a richer expression of semantics than UML is capable
of; hence, we use ontological data to represent semantics.
Finally, when we look at the entire second sentence of
this definition (“An entity…that is considered relevant to the
interaction…), this means that only people, places or objects
that are relevant to the interaction between a user and an
application are considered context. This is clearly wrong for
autonomics, as well as ubiquitous computing and other
similar approaches, since such approaches emphasize the
concept of invisible management. In other words, if these
approaches are working correctly, the user shouldn’t even be
aware that an application is there! Again, we use models and
ontologies to overcome this problem.
These problems have motivated our own definition of
Context, which is described in the next subsection.
III. THE DEN-NG CONTEXT DEFINITION AND
DESIGN APPROACH
The definition of context in DEN-ng is as follows: “The
Context of an Entity is a collection of measured and inferred
knowledge that describe the state and environment in which
an Entity exists or has existed”. In particular, our definition
emphasizes two types of knowledge – known, or measured,
facts, and inferred facts, which result from machine learning
and reasoning processes applied to past and current context
data and knowledge. It also includes context history, so that
current decisions based on context may benefit from past
decisions, as well as observation of how the environment has
changed.
In order to accommodate as flexible a set of definitions
as possible, our context design consists of two classes,
Context and ContextData, as shown in Figure 1.

Figure 1. The DEN-ng Context Model Core Classes
The DEN-ng model represents the Context of an Entity
as a collection of data, information, and knowledge that result
from collecting measurements of and reasoning about that
Entity. Context can have multiple distinct sets of related data
and knowledge that are used individually or collectively to
both define it as well as to adjust its state in accordance with
the changes in the environment that it exists in. For example,
the connectivity of a laptop of a user and the connectivity of a
phone that supports WiFi as one of its access technologies
could be combined to provide the overall state of connectivity
of a user; this could then be augmented by GPS data if the
user is traveling. Our strategy is thus to provide an extensible
set of building blocks that can be combined as required to
model the Context of an Entity according to its application-
specific needs and, more importantly, ensure that the
definition of the context of an entity can dynamically change
as required.
The foundation of this DEN-ng model is formed by
defining two classes, called Context and ContextData, to
0..n0..n
ContextDataDetails
isValidContextData : Boolean
contextDataValidityStartTime : String
contextDataValidityEndTime : String
isContextDataMandatory : Boolean
ContextData
Atomic
ContextAtomic
ContextDataFactContextDataInference
ContextComposite
ContextData
Composite
Context
1..n1..n
0..n0..n
{>=1 ContextAtomic ||
>=1 ContextComposite}
{ordered}
AggregatesContext
0..n0..n
0..n0..n
RelatedContexts
ContextData
1..n1..n
0..n0..n
HasContextData
0..n0..n
1..n
1..n
{ordered}
{>=1 ContextDataAtomic ||
>=1 ContextDataComposite}
AggregatesContextData
ManagedEntity
0..n0..n
0..n0..n
ManagedEntityHasContext
0..n0..n
ManagedEntityHasContextData
ContextFact
ContextInference

Page 3

represent the concepts of whole (or assembled) context and
partial (or component pieces of) context, respectively. The
ContextData class represents the context of one or more
ManagedEntity classes that are part of a larger context; in the
above example, the context of the laptop (independent of the
user) is critical to the user being able to use it, and is
represented by ContextData objects. The Context object
represents the context of the ManagedEntity that we are
ultimately interested in, and consists of its own knowledge
plus a set of aggregated ContextData objects. In the above
example, the context of the laptop and mobile phone are
represented by ContextData objects, which are aggregated to
form the context of the user. The advantages of this approach
are (1) it encourages the modelling of smaller “context
building blocks” that can be reused and combined to form
larger contexts, (2) the information model, which contains a
technology- and platform-, and language-independent
definition of ManagedEntities, can be used to define different
aspects of context as either ContextData or as Context, and
(3) since the object of the information model is to represent
data and relationships between data, we can draw on its
inherent relationships to model different aspects of context in
the varying detail that they require whilst still being able to
assemble them into a coherent whole.
This approach is unique in context modelling. It avoids a
common weakness of traditional context models, which try to
represent context using an unorganized smattering of objects
that contain some interesting attributes, but aren’t cohesive in
nature. This is why we use the DEN-ng information model:
we take advantage of existing models, and if we find the
model lacking in some way, we use the inherent extensibility
of DEN-ng (for example, its use of patterns [11] [12] and
roles [13]) to add required concepts to either the Context
and/or ContextData hierarchies. Referring to Figure 1, the
ContextData and Context classes form two hierarchies for
representing individual aspects of context and an overall
context, respectively. This enables us to model different
aspects of context in varying levels of detail and then
combine them to form an integrated whole.
The ContextDataDetails association class defines the
semantics of how each particular type of ContextData are
aggregated by the Context object. The four attributes of
ContextDataDetails are common to all types of aggregations
of ContextData; this enables different applications to have a
common “control point” for processing context information.
We have constructed a pattern that captures this behaviour:
different applications can represent their needs by
constructing an association to the ContextDataDetails class; a
context processing application could also subclass the
ContextDataDetails class to add its own specific semantics to
control how ContextData is aggregated by Context. We call
these “semantic control points”. Policy management of
context is thus consistently done by defining application-
specific policies and associating
ContextDataDetails association class.
The composite pattern is applied to both the Context as
well as the ContextData objects, enabling the construction of
extensible hierarchies of different aspects of aggregate
contexts. The ContextDataAtomic class models ContextData
as a single, stand-alone object. In contrast, ContextData
objects that are composite in nature (e.g., made up of multiple
them with the
distinct ContextData objects that can each be separately
managed) are modelled using the ContextDataComposite
class. ContextDataComposite objects function as containers,
while ContextDataAtomic classes function as entities with
content, similar to folders and files in a directory.
For example, instead of defining a “locatedAt” attribute
in the Context class (which would necessarily have a fixed
meaning associated with it), we can have the Context and/or
ContextData classes reference a set of location classes that
provide more detailed information and semantics for what
location “means”. In addition, these classes can vary
according to the type of location and/or type of entities that
make up the context. This approach allows the semantics of
location to change as a function of context. Figure 2 abstracts
this by representing location as a set of aggregations to
ContextData, where ContextData is a class that focuses on
one specific type of data and/or knowledge that is aggregated
by the Entity's Context. The physical characteristics of
Location are defined in these Location classes, while the
semantics of the Location are defined in the ContextData
classes. Note that location is more than just latitude and
longitude, but also includes height, proximity, co-location
with other entities, orientation, and factors. This genericity is
why a set of classes (and appropriate units of measurement in
2-D or 3-D space) are required for defining location, as
opposed to a simple attribute.

Figure 2. Example of ContextData for Location
In DEN-ng, a ManagedEntity is something of interest
that can be managed. Typical examples include Products (e.g.,
an application suite), Resources (network devices and
computers), and Services (VPNs, VoIP, video on demand,
and protocols). Any ManagedEntity can have Context or
ContextData associated with it – this is denoted by the
optional associations relating ManagedEntity to Context and
ContextData shown in
Figure
ContextDataHasLocationSemantics is an optional association
(meaning that location doesn’t have to be part of context) that
is used to associate location information with ContextData.
This analysis takes the form of measured and deduced
knowledge, which are represented by the ContextDataFact
and ContextDataInference classes. In this approach, the
inherent characteristics and behaviour of the ManagedEntity
objects associated with ContextData are not altered by
context; rather, they are associated with context, and all
context processing is done within the ContextData hierarchy.
Hence, if other parts of the model change or update Location,
those changes are seamlessly reflected in the context model.
This also avoids breaking applications that cannot process
context – in that case, the context additions are simply
1. In
Figure 2,
0..n0..n
0..n0..n
LocationAtomic
Address
Geographic
Region
PositionStructure
ContextDataAtomic
ContextDataFactContextDataInference
LocationComposite
ManagedEntity
ContextData
Semantics
Location
ManagedEntityHasPhysicalLocation
0..n0..n
1..n
1..n
HasLocationElements
ContextData
0..n0..n
0..n0..n
ManagedEntityHasContextData
1..n1..n
0..n
0..n
HasContextDataSemantics
0..n0..n 0..n0..n
ContextDataHasLocationSemantics
ContextDataLocationDetails
PolicyRuleStructure
0..n0..n
0..n 0..n
SelectsPoliciesToActivate
0..n
0..n
0..n 0..n
PoliciesGoverningContextDataLocation

Page 4

ignored. The required processing is defined by an association
class that has different subclasses to process different types of
location data (not shown in Figure 2 for simplicity). The
attributes in the association class are determined by policy
rules that enable different applications to customize which
types of Location data are aggregated by ContextData, and
how the aggregation is done. For example, the GPS
coordinates of two people that are in the same social network
in the same city can be compared to compute the proximity of
one to the other. As another example, inference can be used
to determine which people in which locations are in greatest
danger from an approaching fire.
The ContextDataFact and ContextDataInference classes
are used to represent additional data that is either known a
priori or can be inferred from other knowledge about a given
ContextData. For example, a given access point’s signal
strength can vary over time – this can be observed by a
sensor and a decision made as to whether the access point is
stable enough to support mission-critical data communication
over an encrypted link or not. Similarly, the ContextFact and
ContextInference classes are used to represent additional data
that appears at the aggregate context level with results from
individual ContextData objects that are being aggregated at
that level. Thus, we can support multiple levels of context
processing – within ContextData hierarchies and within
Context hierarchies – as both use the composite pattern.
.
IV. THE DESIGN OF THE DEN-NG CONTEXT MODEL
The DEN-ng context model is modular and extensible –
modularity allows developers to use only those parts of the
model that they need, and extensibility provides convenient
places to refine the model for application-specific needs. Part
of this extensibility is obtained from borrowing from the
Zachman Framework [14], which use the six questions of
“who”, “what”, “when”, “where”, “why”, and “how” to
organize information. In Figure 3, the “who” is modelled by
the Identity, Context, ContextData, and other classes; the
“what” is modelled by the combination of the type of
ManagedEntity, Context, ContextData, and associations that
are being represented; the “when” is modelled by the Context,
ContextData, and ContextAffectedByTime
ContextDataAffectedByTime associations; the “where” is
modelled by the Context, ContextData, Location, and the
ContextDataHasLocationSemantics association. Portions of
the “why” and “how” are represented by the Context,
ContextData, Activity, State, and Semantics associations and
classes.
The ContextSemantics
classes represent data and/or knowledge that describes, but
does not contribute to or impact, the behavioural aspects of
the Context and ContextData that this ManagedEntity is
associated with. Conceptually, ContextSemantics and
ContextDataSemantics are the top of two class hierarchies
that define “static semantics” associated with Context (the
whole concept) and ContextData (different parts of Context).
By “static semantics”, we mean simple semantics that can be
defined at design time. For example, the semantics of a
network connection could be defined as wired or wireless,
and for wired, it could be further defined as using Ethernet or
and
and ContextDataSemantics
some other protocol. In this case, Ethernet for wired
communication implies a connection using the company’s
intranet, whereas other protocols (e.g., PPP) imply an
external connection over the Internet. These semantics
describing the context of the connection are important, as
business rules might take into account the nature of and
security of connections in determining whether to grant
access to requested resources. The two aggregations,
HasContextSemantics and HasContextDataSemantics, each
are implemented using association classes (not shown) that
determine how the semantics classes are bound to the context
classes.

Figure 3. Simplified DEN-ng Context Semantics Model
The ContextSemantics and ContextDataSemantics
classes represent a convenient point for fusing information
from ontologies with data from the information model. These
classes, and their associations, are semantic control points,
and enable applications to subclass them and to build
associations to them as described above. They also present
convenient points for either augmenting context information
(e.g., tagging it with metadata to enhance information
retrieval) and/or using context changes to change the current
set of services that is being offered. Finally, these two
semantics classes enable the application to declare what it
needs to complete its view of context, as opposed to merely
obtaining context information. These examples are each
complex processes and beyond the scope of this paper.
Time is a common attribute of context. For example,
time can determine when something is allowed to be used, or
when use is no longer permitted. Since time can be handled
differently for different types of contexts, we define two
association classes (ContextAffectedByTimeDetails and
ContextDataAffectedByTimeDetails)
semantics of the corresponding
ContextAffectedByTime and ContextDataAffectedByTime.
These association classes define how Time is used to
constrain Context and ContextData. The full DEN-ng model
also defines different types of policy rules that can be used to
govern how Time is used.
DEN-ng uses finite state automata to manage entities. A
DEN-ng state is a unique collection of information, valid
during a particular time period during the life of an object,
during which one or more of the following apply: (1) one or
more of its attributes each has a range of values that are
unique to this particular state; (2) the object can perform one
or more internal actions that are used to either maintain its
to represent
associations
the
HasContextDataSemantics
ContextDataDetails
isValidContextData : Boolean
contextDataValidityStartTime : String
contextDataValidityEndTime : String
isContextDataMandatory : Boolean
ContextDataAffected
ByTimeDetails
ContextAffectedBy
TimeDetails
ContextSemantics
ContextDataSemantics
State
PolicyConditionTimePeriod
timePeriod : String
monthOfYearMask : String
dayOfMonthMask : String
dayOfWeekMask : String
timeOfDayMask : String
isLocalTime : Boolean = TRUE
Context
0..n
0..n
0..n0..n
RelatedContexts
1..n1..n
0..n0..n
HasContextSemantics
0..n0..n
0..n0..n
ContextHasState
0..n0..n
0..n0..n
ContextAffectedByTime
Identity
0..n 0..n
11
ContextHasIdentity
ManagedEntity
0..n0..n
0..n0..n
ManagedEntityHasContext
LocationAtomic
Location
LocationComposite0..1
0..n
0..n
0..1
HasLocationElements
ActivityAtomic ActivityComposite
ContextData
0..n0..n
0..n0..n
ManagedEntityHasContextData
1..n1..n
0..n0..n
0..n 0..n
0..n
0..n
ContextDataHasState
0..n0..n
0..n0..n
ContextDataAffectedByTime
1..n1..n 0..n0..n
HasContextData
0..n
0..n
11
ContextDataHasIdentity
0..n0..n
0..n 0..n
ContextDataHasLocationSemantics
Activity
0..n0..n
0..1 0..1
HasActivityElements
0..n 0..n
0..1 0..1
ContextDataHasActivitySemantics

Page 5

current state or to transition to a new state, and (3) the object
waits for an external event to trigger a new action. Note that
both ContextData as well as Context can have state
associated with them. This enables us to build nested as well
as hierarchical state machines. This is beyond the scope of
this paper; the point of this discussion is to illustrate that this
model has the ability to determine state from contextual data,
which can then be used to change existing policies or select
new policies to govern the functionality of the system.
An Activity is an abstract concept that must take place in
order to fulfill an operation. It can represent the invocation of
an operation, a step in a business process, or an entire
business process. The composite pattern is used to
differentiate between activities and tasks that make up an
activity. This part of the model is used to orchestrate the steps
required to change behaviour as a function of context, and is
beyond the scope of this paper.
An important part of context is the notion of identity.
Identity enables the system to unambiguously refer to an
object instance. The identifier has to be unique in the
namespace that the object instance exists in. A simplified
portion of the DEN-ng identification model is shown in Figure
4.

Figure 4. DEN-ng Simplified Identity Model
Identification is used to distinguish between different
instances of the same Entity. DEN-ng provides the ability for
policy to be used to select which methods and attributes of
which classes will be used to establish the identity of an
entity. Identity is attached to Entity, not just ManagedEntity,
to enable objects that are not manageable, such as Domains
and MetaData, to have identities.
EntityIdentification uses the composite pattern to provide
identification of stand-alone and groups of Entities. Figure 4
shows one important subclass of the stand-alone type of
identification – ParticipantIdentification. This is an abstract
class that contains common information used as proof of
identity by a Participant. Note that there are no direct
relationships between ParticipantIdentification
Participant. This is because a Participant is a subclass of
Entity, and therefore inherits the IdentifiesEntity association.
and
OrganizationIdentification and IndividualIdentification
represent information used as proof of identity by an
Organization or Individual, respectively. Figure 4 shows some
examples of each. Note that IndividualIdentification is
subclassed into physical and logical types of identification to
enable different association classes and policies to be used to
govern the type of identification and method used. An
example of this interaction
PublicParticipantIdentification, which uses a set of policy
rules to control which types of ParticipantIdentification
attributes and behaviour are allowed to be displayed and used
in the public version of this information. This is used to
enable systems such as Liberty [15] to identify an Entity.
DEN-ng uses the role-object pattern [16] to abstract
concepts to make the resulting model more flexible. Figure 5
shows the role-object pattern applied to Participants.
is the definition of

Figure 5. Participant-ParticipantRole Model
Participant is an abstract class, and represents an
individual, organization or organizational unit that performs
or is assigned an action. Instead of changing the definition of
a person or organization class to accommodate different
business functions, we instead use the role object pattern to
define roles that the person or organization can play. This
enables the duties and functions of a person or organization
to remain constant; new functionality is modelled by
aggregating zero or more ParticipantRoles, where each role is
one or more classes and subclasses that models the
functionality of that role. This also enables a person to have
multiple roles (e.g., an Employee, a Manager, and a
CustomerSupport person).
ValueNetworkRole is the superclass of all entities
defined in the eTOM as such [17]. A Customer is a type of
PartyRole, and is associated with buying goods and services.
Customers do not have to subscribe, or even choose, features
in the purchased goods and services, as this cleanly separates
the act of purchasing something from the act of selecting
options to be purchased. A Subscriber is an entity (associated
with one or more users) that is engaged in a service
subscription with a service provider. The subscriber is
allowed to subscribe and unsubscribe services, to register a
user or a list of users authorized to use these services, and
also to set the limits relative to the use that associated users
make of these services. A User is defined as a Participant
who uses or operates something. Users do NOT purchase
anything, and do NOT make choices that change the price of
the services that the User is using (e.g., change the
Subscription).
IndividualOrganization
Participant
0..10..1
0..n0..n
HasParticipants
ParticipantRole
0..n0..n
0..n
0..n
InteractingParticipantRoles
0..1
0..1
0..n0..n
HasPartyRoles
ValueNetworkRoleEmployee
Customer
User
InteractingParticipant
RoleDetails
Administrator
Subscriber
ServiceProviderVendor
ContentProvider
Technician
ApplicationServiceProvider InternetServiceProviderNetworkServiceProvider
WirelessServiceProvider
EntityIdentification
Atomic
Entity
EntityIdentification
Composite
EntityIdentification
1..n1..n
0..n0..n
IdentifiesEntity
0..n
0..n
1..n 1..n
HasEntityIdentification
CompanyRegistration
Passport
SocialSecurityIdentification
IdentityCard
IdentificationOrganization
Details
IdentificationIndividual
Details
IdentificationMethod
11
1..n 1..n
IdentificationOrgInfoObtainedBy
11
1..n1..n
IdentificationIndividualIfnoObtainedBy
IndividualIdentificationPhysicalIndividualIdentificationLogical
DriversLicenseIdentification
ContractorIdentification
BirthCertificateIdentification
Individual
IndividualIdentification
110..n0..n
IndividualIdentifiedBy
OrganizationIdentification
UsernamePasswordID
BiometricID Certificate
ManagedEntity
ContextData
0..n0..n
0..n0..n
ManagedEntityHasContextData
ParticipantIdentification
PublicParticipant
Identification
1..n1..n
1
1
ProvidesPublicID
Organization
110..n0..n
OrganizationIdendifiedBy
PolicyRuleStructure
ProvidesPublicIDDetails
0..n 0..n
0..n0..n
GovernsPublicIDDetails

Page 6

Context is then used to decide which, if any, of the roles
that a Participant can take on, should be enabled and used.
This is shown in Figure 6. The RoleInteraction association
defines the set of Roles and Role subclasses that can interact
with each other. The semantics governing which specific
roles can interact with which other specific roles is
application-specific, and is defined in part using the
InteractingRolesDetails association class. This is an
association class, and defines the semantics of the
InteractingRoles association. It is abstract, so the application
designer has the flexibility to subclass it to reflect the specific
semantics of how different Roles interact with each other.
Note that ParticipantRoles can interact with ContextRoles
and/or ContextDataRoles because all three classes inherit the
RoleInteraction association from Role. Policies may be used
to constrain and govern
PoliciesGovernRoleInteraction association (not shown).
this interaction via the

Figure 6. Context and Participants
Resources and Services are also linked to Context using
Roles. This model, shown in Figure 7, shows how the
InteractingRolesDetails association class can be subclassed to
accommodate specific types of Role that need to interact. Not
shown are additional associations to policy rules and
constraints that can be applied to further restrict inter-role
interaction. This model enables the management of roles to
be succinctly and uniformly designed. For example, the
DEN-ng model differentiates between customer- and
resource-facing services; customer facing services are those
that the Customer is directly aware of (e.g., a VPN) while
resource facing services are those that the Customer is not
directly aware of (e.g., a protocol used within the VPN, such
as OSPF) but are required for the customer facing service to
work properly. Hence, the Service model is divided into two
sub-hierarchies, one for customer-facing and one for
resource-facing
ServiceManagedByParticipantRole
association that is used to define which ParticipantRole can
manage this particular ServiceRole. This decision is based on
a number of factors, such as skill set, experience, and
criticality of task. The use of roles is thus very powerful, as it
abstracts the specific person (or group of people) as well as
the service. The Resource Model is similar: it has physical,
logical, and compound resources, but this is beyond the scope
of this paper.
services. The
is an exemplar

Figure 7. Simplified DEN-ng Model of Service, Resource, and Roles
V. CONTEXTDATA TAXONOMY
DEN-ng
ContextData. A portion of the ContextData taxonomy is
shown in Figure 8. These taxonomies are divided into a
domain-independent portion (the “Upper Ontology”), which
captures generic context knowledge, and a set of domain-
specific ontologies, which delineate concepts specific to each
sub-domain. Both share the same domain-independent Upper
Ontology, which enables different ContextData ontologies to
be combined and reused with different Context ontologies to
model different characteristics and behaviour of context
information for different applications. This separation of
common vs. domain-specific semantics reduces the burden of
context processing for each individual application, and
ensures simple re-purposing through its ability to
dynamically connect or disconnect different ontologies to or
from the upper ontology in order to meet the needs of
resource-constrained devices, such as a cell phone. For
example, when a user leaves his home to drive to work, our
system can swap out the “home context” ontology with a “car
context” ontology that reflects the different devices and their
capabilities that the user now has access to. Similarly, when
the user arrives at work, the “car context” ontology is
swapped out with the “work context” ontology. Note that for
each of these cases, the “user” ontology could be either the
same or swapped out (for example, to change from a “home
user” to a “business user” or “employee”). This “swapping”
feature is used as a means to determine which portions of the
DEN-ng model to load (DEN-ng itself is very large; by
equating portions of the overall ontology to corresponding
parts in the information model using semantic equivalence
[18], we can link corresponding portions of the ontology to
the model) in order to prepare the application(s) to adapt their
functionality to suit the new context.
Our Upper Ontology consists of five top-level types of
information: ManagedEntity, Location, Time, Activity, and
Participant. This is similar to [19]; notable differences are (1)
the DEN-ng ManagedEntity class is more generic than the
ComputationalEntity of [19], (2) the DEN-ng Participant is
more generic than the Person of [19], and (3) time is missing
defines taxonomies for Context and
ContextAtomic
ResourceRole
ContextDataAtomic
ServiceRole
ParticipantRole
Role
0..n0..n
0..n0..n
RoleInteraction
ContextComposite
ContextRole
ParticipantRoleInteraction
Details
ManagedEntityRole
Context
0..n0..n
1..n1..n
AggregatesContext
0..n0..n
0..10..1
HasContextRoles
ContextDataComposite
ContextDataRole
ContextData
0..n0..n1..n1..n
HasContextData
0..n0..n
1..n
1..n
AggregatesContextData
0..n0..n
0..10..1
HasContextDataRoles
ResourceRoleInteraction
Details
ServiceRoleInteraction
Details
PolicyRuleStructure
InteractingRolesDetails
0..n0..n
0..n0..n
PoliciesGovernRoleInteraction
0..1 0..1
Participant
ParticipantRole
0..n0..n
0..n
0..n
InteractingParticipantRoles
0..1
0..1
0..n 0..n
HasPartyRoles
ContextDataAtomic
ContextDataComposite
ContextDataRole
Role
0..n0..n
0..n0..n
RoleInteraction
InteractingRolesDetails
InteractingParticipant
RoleDetails
ContextData
isUpdateEnabled : Boolean = TRUE
0..n0..n
1..n1..n
AggregatesContextData
0..n0..n
HasContextDataRoles
Context
0..n0..n
1..n
1..n
HasContextData
ContextRole
0..1 0..1
0..n 0..n
HasContextRoles

Page 7

in [19]. While the ManagedEntity, Location, Activity, and
Participant types of ContextData can all be valid for a
particular time, the purpose of the Time classes is to model
information that is purely temporal in nature. For example,
most context systems view context information as static in
nature. A notable exception is that of [20]. While their
definition is different from that in this paper, two key ideas
from [20] are (1) each entity has a decision function that
determines if a fact is context data or not, and (2) a relevance
function assigns a fact a priority with respect to other
priorities of other facts. These ideas are enhanced in this
model. Figure 9 shows an example of the decision function,
with a relevance threshold (which of course could also be
defined as a function!) set at 0.6.

Figure 8. DEN-ng ContextData Taxonomy Overview

Figure 9. Deciding Whether a Fact is Currently Context Information
VI. CONTEXT AND STATE
One of the strengths of our context definition is that it
supports the creation of context-aware applications by
relating such applications to different states. [8] defines a
policy as “Policy is a set of rules that are used to manage and
control the changing and/or maintaining of the state of one or
more managed objects.” Accordingly, both Context and
ContextDetails can have a particular state; this enables the
state of context information to influence which set of policy
rules should be applicable or invoked.
State is complex, as it can vary from 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 or tired, whether the person is
busy or not, different physical conditions, and other factors.
In contrast, the state of a network device includes its
operational status, its power state, and other attributes that
can be queried. Furthermore, state changes as context
changes, since changes in context will in general introduce
new behaviours, and hence states. This is why the DEN-ng
information model is used as a basis for constructing context:
as context changes, different parts of the model can be
“plugged in” to model those changes.
This enables a powerful, context-aware, policy-
management paradigm: as context changes, the state
associated with context changes, which causes policy to
change, which changes the functionality offered by the entity.
For example, imagine a user is switching between a business
profile and an entertainment profile. The former uses a
special service provider that offers encrypted, highly secure
communication for business use, while the latter uses a
completely different set of service providers (one for local
and a different one for long distance calling) as well as links
to social networks. In this situation, the policies defined as
being usable for that context state will in general be different:
some policies may be the same (e.g., rules about which
devices can be used), some policies may be completely
different (e.g., rules about which services can be used), and
some policies may be modified (e.g., rules that govern
communication). This is shown in Figure 10.

Figure 10. Conceptual DEN-ng Context-Aware Policy Model
The HelpsSelectPoliciesToActivate association defines
information that enables the policy system to select a set of
Policies that should be loaded and activated based on the
current context. Hence, as context changes, policy can change
accordingly, enabling our system to adapt to changing
demands. Note that this selection is an “intelligent decision”,
in that the selection process depends on other components
that are part of a particular context. Another “intelligent
decision” is the PolicyResultAffectsContext association,
which enables policy results to influence Context via the
Context
ContextData
1..n1..n
0..n0..n
HasContextData
ManagedEntity
Management
MethodEntity
11
1..n 1..n
SupportedMgmtMethods
DescribedMgmt
InfoDetails
11
1..n1..n
MgmtInfoObtainedBy
ManagementInfo
LogicalResource
11
1..n1..n
DescribedByMgmtInfo
ManagedEntityRole
0..n
0..n
0..n0..n
TakesOnManagedEntityRoles
SupportedMgmt
MethodDetail
ContextControllerComponent
1..n1..n
1..n 1..n
ContextGovernedByContextControllerComponent
1..n
1..n
0..n 0..n
ManagedEntityRoleAffectsContext
0..n 0..n
1..n1..n
ContextAssignsManagedEntityRoles
1..n1..n
0..n0..n
ManagementInfoAffectsContext
0..n0..n
1..n1..n
ContextAssignsMgmtInfo
PolicyRuleStructure
1..n1..n
0..n0..n
PolicyResultAffectsContext
0..n0..n
0..n0..n
HelpsSelectPoliciesToActivate
1..n1..n
1..n1..n
ContextAwarePolicyEnablesMgmtInfo
1..n 1..n
1..n1..n
ContextAwarePolicyEnablesManagedEntityRoles
1..n1..n
1..n1..n
ContextAssignsPolicies

ContextData
ContextData
Upper Ontology
Participant
Ad Hoc
Scheduled
Position
Address
Structure
Geographic
Region
Product
Service
Resource
Policy
Scheduled
Org
Individual
Ad Hoc
Activity
ManagedEntity
Time
Location
ContextData Domain Specific Ontologies
PastPastPastNear PastNear PastNear Past PresentPresentPresent Near FutureNear FutureNear Future Future FutureFuture
Time tTime tTime t
000
0.2 0.20.2
0.4 0.40.4
0.60.60.6
0.80.80.8
111
Probability PProbability PProbability P
P of F

Page 8

ContextControllerComponent, the application that manages
Context. For example, if a policy execution fails, not only did
the desired state change not occur, but the context may have
changed as well.
The ContextAwarePolicyEnablesManagedEntityRoles
association enables the appropriate ManagedEntityRoles to
be used according to this Context; each ManagedEntityRole
defines functionality that the ManagedEntity can use. In this
way, policy indirectly controls the functionality of the system,
again as a function
ContextAwarePolicyEnablesMgmtInfo defines the set of
management data that is useful for this Context in order to
track the state of the ManagedEntities relevant to this
Context; ManagementInfoAffectsContext
feedback from these management data regarding the
execution of the policy rule. Once the management
information is defined, then
MgmtInfoAffectsContext
ManagedEntityRoleAffectsContext
dependencies (e.g., context defines the management
information to monitor, and the values of these management
data affect context, respectively).
ContextControllerComponent defines its own set of
ManagedEntityRoles and ManagementInfo to use to monitor
the environment; feedback from the ManagedEntities
identified by their roles and specific measurements (in the
form of ManagementInfo)
ContextControllerComponent to operate its own finite state
machine (FSM). This FSM is used to orchestrate the actions
of the ContextControllerComponent, including which
ManagedEntities it should determine the context for, how a
particular element of context should be analyzed, and what
procedures for determining its context should be used.

of context. Similarly,
represents
the two associations
and
these codify
Finally, the
are used by the
VII. RELATION TO THE AUTONOMIC INTERNET
FP7 PROJECT
The goal of autonomic networking in general and the
Autonomic Internet FP7 programme in particular is to create
a management overlay with autonomic characteristics for the
purposes of fast and guaranteed service delivery. In
particular, the management overlay should be able to define
or deduce context and then adjust the behaviour of the
entities that it is governing to meet the new demands
signalled by that context change.
Behaviour is orchestrated using state automata as shown
in Figure 11. In this figure, different states of a
ManagedEntity are defined as nodes in a graph, and state
transitions are similarly defined as edges in the graph. One
way to orchestrate such a system uses finite automata, where
the delivery of a service corresponds to a state or set of states;
additional states can be used to represent important
configuration steps and/or error conditions. C(ex) denotes the
cost of an edge, Py defines a policy called y, C(P(ex)) denotes
the cost of an edge computed by executing policy Py, and
MP(P1, P2) defines a management policy MP that governs the
application of both P1 and P2. Now, we can use policies to
define the cost of an edge, which then determines which
states a managed entity should be in. This approach can
involve a potentially large number of states. One way to limit
this explosion of states is to use the notion of context to
eliminate states and state transitions from consideration.
Hence, by representing the context of a ManagedEntity as a
set of states, we can define a set of policies that define the
cost of each edge, or state, transition. Note that this also
enables us to define context-aware policies as a means of
governing which transitions are legal in the graph. For
example, a change in context might prohibit reaching a state
that was, before that context change, legal to be in. An
important benefit of this approach is that a system using this
approach can be insulated from changing user needs, business
objectives, and environmental conditions as explained
previously in this paper. We are currently implementing this
approach, using the DEN-ng information model to represent
context, policy and state.

Figure 11. Behavioural Orchestration in the Autonomic Internet
VIII. SUMMARY
This paper has described the design of a novel context model.
The foundation of this model is to address the needs of
Ubiquitous Computing and Autonomic Networking. After
exploring existing context definitions, we have concluded
that they lack the richness and functionality for our needs.
Therefore, we have explained these drawbacks and defined
our new definition to address these problems.
After creating our new context definition, we then
enhanced the DEN-ng information model to support it. This
model is based on the use of patterns and roles, and uniquely
addresses the representation of context management and
functionality. It features an extensible representation of
context by aggregating domain-specific models of different
aspects of context, which enable it to be easily repurposed to
suit the needs of different applications. This approach also
enables us to dynamically adjust the model, and hence
change code that is generated, to match these changes.
Future work will include merging ontologies with the
DEN-ng information model to enable us to reason about
knowledge and policies.
IX. ACKNOWLEDGMENTS
There are three main information models being used
today: DEN-ng [8], the TMF SID [11] and the DMTF CIM
[12] (other efforts are too sparse in their domain coverage to
meet the needs of autonomics). The SID is partially derived
InitRun End
ResumeSuspend
Managed Entity
Policy 1
Policy 2
C(e1) C(e2)
C(e5)C(e3)
C(e4)
C(P1(e1))C(P2(e2))
Policy 3
MP(P1, P2)

Page 9

from DEN-ng v3.5; unfortunately, the aims of the TMF
diverged, and DEN-ng (the current version is 6.6) will now
be submitted to the Autonomic Communications Forum. The
TMF has had a five-year liaison relationship with the DMTF,
trying to align the DMTF CIM with the TMF SID. This work
has been hampered by three important problems: (1) the lack
of a common metamodel, (2) the type of modeling done, and
(3) the lack of the use of patterns. The CIM uses its own
proprietary metamodel, not that of UML [13]. This means
that the concepts used to build models (e.g., classes, attributes,
and relationships) are defined differently. The CIM is in
reality a data model (and is so classified by [14]), as it
contains technology-specific concepts, such as keys and weak
relationships, which are not technology neutral. Information
models by definition require technology neutrality, or else
coherency between the same knowledge represented in
different forms in different data models will be lost.
ACKNOWLEDGMENTS
Part of this work has received support from the European
Commission under the EU IST FP7 project, Autonomic
Internet (Grant agreement no.:216404). We would also like
to thank additional staff in Motorola Labs and TSSG for
working on various aspects of this project, including Steven
Davy, Brendan Jennings, Greg Cox, Dave Raymer, and Srini
Samudrala.
REFERENCES
[1] J. Strassner, J. de Souza, D. Raymer, S. Samudrala, S. Davy, K.
Barrett, “The Design of a New Policy Model to Support
Ontology-Driven Reasoning for Autonomic Networking”,
LANOMS 2007, pgs 114-125
[2] J. Mitola, “Cognitive Radio Architecture: The Engineering
Foundations of Radio XML”, Wiley-Interscience, ISBN
0471742449
[3] http://www.motorola.com/content.jsp?globalObjectId=6611-
9309
[4] J.O. Kephart, and D.M. Chess, “The Vision of Autonomic
Computing”, IEEE Computer,
http://research.ibm.com/autonomic/research/papers/
[5] IBM, “An Architectural Blueprint for Autonomic Computing”,
v7, June 2005
[6] J. Strassner “Autonomic Networks and Systems: Theory and
Practice”, IM 2007 Tutorial, May 2007
[7] J. Strassner, E. Lehtihet, N. Agoulmine, “FOCALE – A Novel
Autonomic Computing Architecture: extended version”,
accepted by ITSSA journal, 2007
[8] J. Strassner, “Policy Based Network Management”, Morgan
Kaufman,
1-55860-859-1
[9] A. Dey, “Providing Architectural Support for Building Context
Aware Applications”, Ph.D. Thesis, 2000
[10] A. Schmidt, M. Beigl, and H. W.-Gellerson, “There is More to
Context than Location”, <>
[11] http://hillside.net/patterns/
[12] M. Fowler, “Analysis Patterns – Reusable Object Models”,
ISBN 0-201-89542-0
[13] M. Fowler, “Dealing
http://www.martinfowler.com/apsupp/roles.pdf
[14] http://www.zifa.com/
[15] www.projectliberty.org
January 2003.
ISBN
with Roles”,
[16] The Role Obejct Pattern, which can be downloaded from:
http://www.riehle.org/computer-science-research/1997/plop-
1997-role-object.pdf
[17] TMF, GB921 and addenda, available at www.tmforum.org
[18] Wong, A., Ray, P., Parameswaran, N., Strassner, J., “Ontology
mapping for the interoperability problem in network
management”, Journal on Selected Areas in Communications,
Oct. 2005, Vol. 23, Issue 10, page(s): 2058- 2068
[19] T. Gu, X. Wang, H. Pung, D. Zhang, “An Ontology-based
Context Model in Intelligent Environments”
[20] V. Osmani, S. van der Meer, “Context? Yes, but to whom?”, in
Proc. of International Workshop on Context in Mobile HCI, in
conjuction with Mobile HCI’05, Salzburg, Austria, September
19, 2005
[21] A. Bassi, S. Denazis, A. Galis, C. Fahy, M. Serrano, J. Serrat,
“Autonomic Internet: A Perspective for Future Internet
Services Based on Autonomic Principles”, 2nd IEEE
International Workshop
Communications Environments (MACE 2007) San José,
United States, October 29-30, 2007
on Modelling Autonomic