Pers Ubiquit Comput (2016) 20:209227

DOI 10.1007/s00779-016-0904-1

ORIGINAL ARTICLE

A user-centric approach to dynamic adaptation of reusable

communication services
Andrew A. Allen1 Fabio M. Costa2 Peter J. Clarke3

Received: 6 April 2015 / Accepted: 5 January 2016 / Published online: 3 February 2016
 Springer-Verlag London 2016

Abstract The pervasiveness of electronic devices coupled with increasing resources within these devices has
aided the explosion of available software services. While
reusable software services have become more accessible
and the cost of using these services has become cheaper,
the increased number of services and access methods also
increases the complexity for the user of these services,
demanding too much attention from the user. On the other
hand, automation can alleviate some of the complexity
issues but at the expense of user control. We propose a
balance between smart reusable integration, automation
and user controllability, through a dynamically adaptive
user-centric approach that utilizes goal-oriented intent
modeling. This work leverages the convergence of services
and providers for the user through reuse, autonomic
adaptation of services to relieve the users of laborious and
tedious tasks, while ensuring that the users end-goal
remains central at all times. We applied our approach to the
domains of collaborative communication as demonstration
of the feasibility of the approach.

& Andrew A. Allen

andrewallen@georgiasouthern.edu
Fabio M. Costa
fmc@inf.ufg.br
Peter J. Clarke
clarkep@cis.fiu.edu
1

Department of Computer Sciences, Georgia Southern

University, Statesboro, GA 30460, USA

Instituto de Informatica, Universidade Federal de Goias,

Goiania, GO, Brazil

School of Computing and Information Sciences,

Florida International University, Miami, FL, USA

Keywords Dynamic adaptation  Autonomic computing 

User-centric  Communication services  Reusability 
Middleware  Multimedia

1 Introduction
The pervasiveness of electronic devices, especially mobile
electronic devices, coupled with increasing resources
within these devices has aided the explosion of communication services. Services previously limited to wired
networks are transitioning to wireless devices, while
bandwidth intensive services such as video conferencing
are becoming more common place as the available bandwidth grows. This convergence of infrastructure, devices
and services presents opportunities to create elaborate
collaborative applications [8]. While communication services have become more accessible and the cost of using
these services has become cheaper, the increased number
of services and access methods also increases the complexity for the users of these services. Weiser et al. [50]
noted that traditional computing has become too complex,
too hard to use and too demanding of attention from the
user.
Ubiquitous computing was the paradigm envisioned by
Weiser et al. [50] as a solution to the aforementioned
problem. However, one of the research challenges with this
paradigm is how to maintain user control and provide
simplicity simultaneously. We propose an approach to this
challenge, a dynamically adaptive user-centric approach
that utilizes goal-oriented intent modeling. The work presented in this paper is grounded in the following: (1)
reusability, leveraging the convergence of services and
providers for the user through reuse; (2) simplicity, autonomic adaptation of services to relieve the user of laborious

123

210

and tedious tasks; and (3) controllability, a user-centric

approach that allows the users end-goal to remain central
at all times. We have applied our approach to the domain of
collaborative communication [10, 30, 51] which will be the
focus of the work presented in this paper. Many of the
concepts presented can also be applied to other domains,
such as microgrid energy management [5].
Electronic communication services provide a myriad of
methods to communicate for the user but paradoxically can
make communication more difficult. Users of these services have to manage and adapt their service usage in line
with differences in services across devices, infrastructure
and media. Other users (administrators) tasked with
managing and, where possible, minimizing the costs
associated with the use of the services as a resource have to
ensure that the usage remains consistent with the business
goals and the potential changes of the business model.
Businesses and individuals who wish to take full advantage
of these prices and service quality will have to monitor
these quality of service (QoS) values against cost. A simple
example would be the fluidity in per minute cost and QoS
by providers of VoIP service between two cities.
Some communication service providers deliver a highly
integrated product generally referred to as unified communication (e.g., IBM, Microsoft and Cisco). Unified
communication attempts to integrate electronic communication media while providing a consistent user interface
and user experience across multiple devices and media
types. The provider-centric one-size-fits-all nature of this
integration approach can result in more tools than the
organization or individual user needs to accomplish their
goals, potentially negating some of the complexity reduction while requiring more expert knowledge.
Other communication service providers [14, 17, 33, 43]
provide a variety of communication tools and communication services (communication frameworks) for creating
synergistic collaborative communication applications.
Products such as Skype [43], ooVoo [33] and GoogleTalk
[14], which provide commercial-off-the-shelf (COTS)
communication APIs, have been made available by their
respective companies and support the development of more
sophisticated communication applications by third parties.
While these communication frameworks support the creation of specialized collaborative communication applications, not all communication frameworks offer the same set
of services or quality of service [6]. Increasing the number
of available communication frameworks will potentially
increase the burden to the users. They may become overwhelmed with the details of choosing and configuring
services per tasks, becoming less inclined to use the services or even stop completely.
We propose a novel approach to the aforementioned
challenge [50] through the amalgamation of multiple

123

Pers Ubiquit Comput (2016) 20:209227

communication frameworks at the lower level, provideragnostic integration of communication services at the user
level and an autonomic concepts to bridge the two levels.
We leverage this approach in the Network Communication
Broker (NCB) layer of the Communication Virtual
Machine (CVM), a model-driven paradigm for realizing
collaborative communication.
The CVM, developed by Deng et al. [10], interprets
user-defined communication models created using the
Communication Modeling Language (CML) [51], a
domain-specific modeling language. The NCB layer of the
CVM has been extended to support self-* properties and is
the main area of focus in this paper. The approach is
supported by a goal-oriented methodology for the allocation and self-configuration of communication resources.
The approach supports the convergence of multiple communication frameworks as well as methodologies for
selecting the most appropriate services as requested by the
users communication models. Models defined by the users
as their intent are executed on the CVM platform and
provide services that are guided by user-defined policies. In
this paper, we extend the work of Allen et al. [3] with the
following major contributions:
1.

2.

3.
4.

Development of methodologies for selection of services based on user intent and automated reconfiguration of services and communication frameworks.
Development of the definition and evaluation techniques for user-centric communication (UCC) policies,
useful for describing user intent in the domain.
Design an extensible architecture that supports seamless integration of communication frameworks.
Results of evaluation of the proposed approach.

We argue that the proposed autonomic support for

dynamic adaptation is a feasible approach for solving this
class of problems.
The rest of this paper is organized as follows. Section 2
provides background on supporting technologies and concepts, and Sect. 3 presents an overview of our approach.
Section 5 describes our autonomic framework and Sect. 4
the user-centric communication polices used in the
framework. Section 6 describes the experimental evaluation, and Sect. 7 compares our work to similar research in
the literature. Section 8 presents our conclusion and future
work.

2 Background
2.1 Autonomic computing
Autonomic computing (AC) [16, 21] refers to computing
systems characterized by one or more of the self-

Pers Ubiquit Comput (2016) 20:209227

management behaviors which include: self-configuration,

self-optimization, self-protection and self-healing. This
self-management is achieved by automating low-level
tasks while allowing administrators to specify the goals of
the system as high-level policies. A key concept in autonomic computing is the use of closed control loops for selfmanagement. The closed control loops are generally
implemented as Monitor, Analyze, Plan and Execute
(MAPE) functions. The monitor function collects state
information from the managed resource and correlates
them into symptoms for analysis. If analysis determines
that a change is needed, a change request is generated and a
change plan is formulated for execution on the managed
resource.
2.2 User-centric communication services
The convergence of various multimedia communications
that includes voice, video and data presents many opportunities for enabling unified communication [49].
There are, however, several challenges presented by this
model of communication. One such challenge is that with
each new communication channel and application, a new
way of contacting other parties is introduced. This
increases the complexity for the user who is tasked with
managing and adapting the communication. Complexity
can hinder rather than enhance communication [24], and
research is under way in academia and industry to find
solutions to such challenges of unified communication.
The user-centric approach [24, 48] is one such research
direction. This solution aims to reduce the complexity and
offer operating simplicity to users of these unified communication services [24]. To be user-centric requires
knowledge of the actual context of a user. A context
defines a certain relationship of a human being to a particular number of objects of its communication space at a
fixed moment of time [25, 48]. The user-centric communication (UCC) approach is therefore about matching the
communication resources with the individuals needs at a
particular point in time, and adapting accordingly, thereby
reducing the complexity to the user.
There has been an upsurge in research in the area of
user-centric communication service creation and use.
Wang et al. [49] identified several goals and requirements
in the creation of communication services for unified
communication which are applicable to our work. These
goals and requirements include: (1) simplicity and userfriendlinessprovides the user with the ability to customize the service, (2) flexibilitythe underlying system
must be able to provide a wide variety of services, (3)
extensibility and completenessthe underlying system
must be able to easily integrate new services since it is
difficult to support a complete set of services, and (4)

211

service portabilitymust be able to support systems built

by other vendors. The definition we use for user-centric
communication services falls inline with the goals and
requirements defined by Wang et al. [49] but is more
narrow in scope than the work by Sienel et al. [42].
2.3 Communication virtual machine
Figure 1 shows the layered architecture of the Communication Virtual Machine (CVM). Deng et al. [10] developed
the notion of the CVM, which enables the realization of
models defined using a Communication Modeling Language1 (CML). CML is a domain-specific modeling language (DSML) used to create models for user-centric
communication applications. Unlike many DSMLs that
generate code before the application is executed, CML
models are directly interpreted by CVM. This class of
DSMLs is referred to as interpreted DSMLs or i-DSMLs
[9]. CVM has a layered architecture and lies between the
communication network and the user (or application). The
key components of the CVM are:
User Communication Interface (UCI) provides a modeling environment for users to specify their communication
requirements using CML. CML can be used to describe a
communication schema or schema instance, analogous to an
object-oriented class and object. In order to realize a communication application, two types of communication models
are required: a control schema (or instance) that defines the
configuration of the connections in a communication and a
data schema (or instance) that defines the media being
transferred across a connection. We use the term media to
refer to both streaming media, e.g., video, and data, e.g., files.
During a communication, schemas (user-defined models) are
shared with the parties in the connection.
Synthesis Engine (SE) implements a set of algorithms
responsible for (1) automatically synthesizing schema
instances into executable communication control scripts,
(2) negotiating the schema instances with other participants
in the communication and (3) realizing media transfer
between participants in the communication. The semantics
to support the interpretation of CML models are based on
changes to models (schemas) at runtime and defined using
state machines. As the state machines for schema negotiation and media transfer are executed, the appropriate
control scripts are generated for processing in the UCM
[51].
User-centric Communication Middleware (UCM) executes the communication control script and manages the
delivery of media to participants in the communication,
independent of the underlying network configuration.
Based on the control script received by the UCM, macros
1

http://www.cis.fiu.edu/cml/.

123

212
Fig. 1 Layered architecture of
the CVM

Pers Ubiquit Comput (2016) 20:209227

User / Application (local)

User / Application (remote)

CVM

CVM

User Comm. Interface

(UCI)

User
Communication

User Comm. Interface

(UCI)

Synthesis Engine (SE)

Communication
Management

Synthesis Engine (SE)

User-Centric Comm.
Middleware (UCM)

Network Comm. Broker

(NCB)

User-Centric Comm.
Middleware (UCM)

Realization of
Comm. Services

Network Comm. Broker

(NCB)

Communication Networks

Communication Networks
Legend
Control and Data Flow

are loaded and executed either synchronously or asynchronously. Managing the delivery of media requires the
UCM to store data in temporary locations, retrieve data
from remote UCMs on-demand, enforce security policies
associated with media, among other tasks. Additional
details of the UCM implementation are provided by Morris
et al. [30].
Network Communication Broker (NCB) provides a
network-independent API to the UCM that masks the
heterogeneity and complexities of the underlying network
to support the realization of the communication services.
The NCB interacts with the underlying communication
frameworks to ensure that the requests from the UCM are
realized, including request negotiation between participants, delivery of media and the enforcement of low-level
policies. Additional details of the NCBs functionality will
be provided in subsequent sections.
2.4 Network Communication broker
The initial design of Network Communication Broker
(NCB) as proposed by Zhang et al. [52] is a user-centric
middleware that encapsulates the networking complexity

123

Virtual Communication

and heterogeneity of basic multimedia and multi-party

communication for upper-layer collaborative applications.
NCB conceptually is a horizontal abstraction, separating
and isolating the complexities of network-level communication control and media delivery from the diversity of
application-dependent collaboration logic. Zhang et al.
exploited the concept of user-level sessions, as opposed to
network-level sessions used by existing protocols, as a key
component for the design of a flexible NCB interface
that supports various next-generation collaborative
communications.
While NCB alleviated the burden of low-level programming for upper-layer collaborative application developers, NCB suffered some of the limitations of more
traditional approaches. The addition and validation of new
build from scratch communication services and the
enhancement and revalidation of existing services in NCB
during the maintenance phase proved to be tedious and
time-consuming. The NCB proposed by Zhang et al. [52]
and implemented in the CVM by Deng et al. [10] becomes
an additional communication framework in our new
design, which we refer to as NCBNative in the new design
presented in this paper.

Pers Ubiquit Comput (2016) 20:209227

3 Overview of approach
In this section, we present our approach for the development of a user-centric self-configuring system of reusable
communication services.
3.1 Proposed solution
The purpose of the NCB is to provide a network-independent API for services to the upper layers of CVM,
where the upper layers of CVM simply describe the services needed. It was hypothesized that the integration of
multiple communication frameworks would be a feasible
solution for expanding the services. However, utilizing this
method in isolation raises the complexity for users and
application developers of CVM who will now have to
become fully aware of each communication frameworks
service listings and limitations. The redesigned NCB must
therefore provides the upper layers with the set of available
communication services without burdening the user with
the complexity of deciphering which framework has what
services. Our new design tries to address the following
questions:
1.

2.
3.

How can more services be provided to the users of

collaborative communication without significant
increases in development time and cost?
How can the selection of services by the end user be
powerful but not burdensome?
How can the previously outlined questions be
answered while still supporting the core concepts
CVM?

The solution should allow users to simply model their

desired communication, stating what services are needed.
The redesigned NCB then configures the appropriate
communication framework to deliver the services, producing an agnostic service providers view to the user.
Users of CVM would be able to use existing communication models or create new communication models that are
realizable on current or future communication frameworks.
The integrated communication services offered by NCB
would therefore reflect the communication services available from the incorporated communication frameworks.
We propose an architecture that is provider-agnostic and
mechanisms for the user to declare goals. The abstract
architecture for the approach is shown in Fig. 2 and is
composed of the following functional components from top
to bottom: upper-layer CVM Applications that reuses the
collaborative communication services; Middleware API
that provides a high-level network-independent abstraction
to users; Mapping Layer that associates a high-level communication intent (user connection) to low-level communication session; Selection Layer that selects the

213

communication services framework that best serves a

users intent; and Convergence Layer that aggregates the
communication frameworks that provide the services. To
the left is a horizontal layer, the Knowledge Repository,
that handles repository and registry services for the connecting layers. Details on the architecture is provided in
Sect. 5.
The Knowledge Repository also contains user-centric
communication policies to support the decision making for
dynamic self-configuration of the NCB as well as mechanisms for policy evaluation and enforcement. In more
traditional areas that utilize handover, such as cellular
networks, the switching decision is generally based on
Relative Signal Strength and on call drop rate. The complexity is elevated in this situation. In addition to QoS-type
metrics, other criteria such as cost which will be based on
the network, location and time of day of the called party
become factors that affect the decision as well. Based on
the switching metrics mentioned earlier, the decision about
when and how to switch the intent model to which communication services framework will be made.
How to switch will need to tackle complexities such as
ordering (destroy old session first or create new session
first?) and impacting constraints (limited resources to
support old session and new session at the same instance).
Trade-offs may need to be made in such cases. When a
remapping for an intent model is required, a transfer from
one communication framework to another may occur. All
peer users involved in the communication need to correctly
switch communication services framework and do so in a
timely, ordered way. Peer notification is therefore critical
in ensuring all peers are provided the correct next
framework. The state of the session may also need to be
preserved and recreated to ensure substantive continuation
of the communication. All points discussed previously will
need to be balanced against user preferences which may
dictate priorities and weights for some set of metrics. We
discuss our work on UCC policies in Sect. 4.
3.2 NCB control flow
Figure 3 shows the flow of control for the new approach
used in the NCB. A users communication model would be
accepted and transformed by the upper layers of the CVM
into a series of requests (example: create new connection,
add party) for the NCB as in step 1 in Fig. 3. The requests
are inserted into a priority queue where the highest priority
request is evaluated against stored policies and the current
operating environment state (steps 2 and 3). The result of
the evaluation is an identified communication framework
that satisfies the users request and does not violate the
active policies. If the evaluation process returns a new
framework for the connection (that is, one that is different

123

214

Pers Ubiquit Comput (2016) 20:209227

Fig. 2 Abstract architecture for

proposed NCB

Applications

Middleware API
Mapping Layer
Knowledge
Repository
Selection Layer
Convergence Layer

Skype

Smack

SIP

ooVoo

GVoice

TCP/IP Stack

1. User
request

11. Response
12. Reactive Events

Touchpoint AC
Manager

UCI
4. Issue AC
re-configuration

SE
UCM

5. Prepare
framework for use

6. Update
knowledge

OAM

NCB Manager

Queue
2. Prioritized
request

Evaluation
3. Evaluate against
policies

Shared Knowledge

8. Get connection to
framework mapping

7. Issue connection
command
10. Communication
events and exception

Communication
Frameworks

9. Enable
communication

Communication
Manager

Fig. 3 NCB control flow diagram. OAM orchestrating autonomic manager; AC autonomic computing

from the current one in use), the TouchPoint Manager

(TPM) issues commands to setup the new framework for
use and updates the framework-to-connection mapping
table (steps 4, 5 and 6). Details on policy definition and
interpretation are provided in Sect. 4.
The evaluation is one subcomponent of the Orchestration Autonomic Manager (OAM), which is also
responsible for usage synchronization of the communication frameworks. OAM blocks the Communication
Services Manager (CSM) while these reconfiguration
steps are in progress, then issues the connection commands (step 7) to the CSM. The CSM looks up the

123

framework for the connection in the framework-to-connection mapping table, step 8, and executes the command
on the specific framework (step 9).
Any resulting events or exceptions are passed to the
NCB Manager, step 10. Any out-of-band or reactive
events that cannot be handled by the TPM are encapsulated and forwarded to the OAM (see step 12). The OAM
processes this event and directs the TPM appropriately.
This effectively provides a stacked approach for the
autonomic design with the OAM performing the role of
manager for the TPM. The details of this design are
provided in Sect. 5.

Pers Ubiquit Comput (2016) 20:209227

4 UCC policies
The interfacing of multiple communication frameworks
expands the available communication services, thus requiring a way to express high-level business goals to simplify
the management of the system. Separating the rules from the
implementation facilitates dynamic modification of these
rules, yielding flexibility to change the management strategy
of the system and hence modify its behavior without
changing its underlying implementation [44]. In this section,
we define user-centric communication policies and present a
structural design for representing these policies.
4.1 Policy definition
Policies are rules that define the choices in the behavior of
a system [29]. Agrawal et al. [1] define a systems behavior
to be a continuous ordered set of states where the order is
imposed by time. Let B(S) be the set of all possible
behaviors that the system S can exhibit. There should exist
some set of constraints C such that when C is applied to
B(S), it maps to a subset of desired behaviors Bdesired S.
Then for goal function g,
g : C; BS ! Bdesired S
The goal function g is effected as a policy P, where
policy P characterizes conditions and actions that reduces
B(S) to some subset Bdesired S; that is, it defines a subset of
B(S) of acceptable behaviors for S.
Policies can be defined using only a small number of
attributes of system state and do not require the determination of the complete state a priori [1]. In the case of
collaborative communication, we define policy P as a
4-tuple hPS ; PC ; PV ; PA i where:

PS : Scope of the policy, identify subcomponents of S to

which the policy is applied. A second attribute indicates
the status of the policy as being active or not;
PC : Condition(s) or event(s) under which the policy
action is triggered. Attributes include: (1) featurethe
carrier (medium) of the intended information to be
communicated; (2) operationthe action to be performed on the proposed medium; and (3) an optional
literal tag for additional supporting information;
PV : Value, facilitates the ranking of multiple applicable
actions based on some expected business value or
utility; and
PA : associates a condition PC with an action to achieve
some desired behavior. It is expressed as a triple
(consisting of parameter, operation and value) that
specifies the criteria that the communication must
satisfy, e.g., select communication framework whose
medium supports at least the connections users count.

215

The goals can be provided through one of two options.

Firstly, design time goals can be created using the tools in [6].
The second option is at runtime via the models in the upper
layer of the CVM. In both cases, the goals are converted to
the policy structure defined previously. Figure 4 is an
example of the XML version of a user-defined policy that
guides the establishment of video conferences.
4.2 Policy interpretation
While policy definition describes the what, policy interpretation represents the how that ensures stated goals of
the policies are met. The IETF/DMTF policy architecture
identifies four core elements to support a policy framework
(see Fig. 5a). These four elements are (1) the policy management tool, used to create and define the policies for the
system; (2) the policy repository, which provides storage
and retrieval mechanisms for policies; (3) the policy decision point (PDP), which has logical entities that decide
applicability of policies and what is needed to comply with
the policies; and (4) the policy enforcement point (PEP),
which consists of logical entities charged with enforcing the
policy decisions. This architecture represents the fundamental model supporting much of the standards work in this
area [1, 31, 32]. As such our approach for supporting policies in the NCB was influenced by this architecture.
Recall from Sect. 4.1 that a user-centric goal is defined
as: characterized as:
G : C; BS  BS
where constraint C can be characterized using policy P
4-tuple
hPS ; PC ; PV ; PA i
Policy interpretation of user-centric communication policies in this regard is defined as:
PS ^ PC ) PA
which can be further refined as:
PS () sc 2 S ^ p Active
that is: PS implies subcomponent sc exists in System S at
runtime and Policy P is active; and
PC () e 2 T ^ estate 2 Rstates
that is: PC implies Event e is of the monitored type T and
the state estate of Event e is such that it lays within the
bounds of some predefined thresholds Rstates . We also note
that PA describes goal states for some set of variables in
subcomponents of PS . Refinement of this conceptual view
of policy interpretation is the basis for the policy evaluation
mechanism used in the NCB.

123

216

Pers Ubiquit Comput (2016) 20:209227

Fig. 4 XML representation for

user-centric communication
policy

Policy
Management
Tool

Policy
Repository

<csmPolicy policyName ="selectComm _Video_01">

<scope>
<service >Communication Object </service >
<active >true</active>
</scope>
<condition >
<feature >Video</feature >
<operation >request </operation >
<literal ></literal >
</condition >
<businessValue >
<businessGroup >general </businessGroup >
<value>96</value>
</businessValue >
<decision >
<param>Enabled </param>
<operation >equalTo </operation >
<value>conID.enabled</value>
</decision >
</csmPolicy >

Request
Event

Policy
Designer
Supported
Policies

(i) Scope
Analysis

Policy
Repository

Components
@
Runtime
Environment

Policy
Decision
Point

Policy
Enforcement
Point

(a)

Monitored
State
Events

(ii) Condition
Analysis

Manage /
Enforce
State

(iii) Decision
Analysis

Relavant
Policies

(b)

Fig. 5 a IETF/DMTF policy architecture. b Runtime policy evaluation

Figure b presents an overview of our lightweight policy

evaluation mechanism used in satisfying the users communication needs. User policies are created with the Policy

123

Designer [6], a simplified policy management tool that

supports the policy definition presented in Sect. 4.1, and
stored in the policy repository. At runtime policies are

Pers Ubiquit Comput (2016) 20:209227

retrieved from the policy repository as a first step in

selecting applicable policies. The policy decision point, as
identified in Fig. 5a, is logically divided into the three
analysis processes shown in Fig. 5b and identified as (i, ii,
iii). The policies and the available components at runtime
are input for scope analysis (Fig. 5b(i)), where all policies
with scopes that match the active components are selected,
resulting in a subset of supported policies. In the context of
NCB the components are the frameworks and the state of
their services.
Events such as user requests or monitored state (reactive
events) trigger further refinement of the supported policies
via condition analysis (Fig. 5b(ii)). Policies with matching
conditions to the event or environment state are selected to
create the set of relevant policies. The decisions of the set
of relevant policies (Fig. 5b(iii)) are the goals or range of
states that the system should support. Policy enforcement is
provided by the Orchestration Autonomic Manager (OAM)
which is included in the representation of the environment
shown in Fig. 5b. The details of the OAM are discussed in
Sect. 5.
In Fig. 6 we outline the algorithm for policy selection,
this can be viewed as the algorithmic equivalent of
Fig. 5b(i) and (ii). Each round of policy selection begins
with an empty policy set, step 2 of Fig. 6, to which relevant
policies are added. Policies are deemed relevant if the
request attributes (encapsulated in an event as described in
Fig. 6s input) match the policy values for service, feature
or operation (steps 45 of Fig. 6). When relevant policies
are looked up and retrieved from the repository, an
equivalent object representation is built with all the tags
and values extracted and stored as object attributes. Policies are stored as XML in the policy repository (recall from
Fig. 5b).
For a set of relevant policies, they are processed in the
order of their business values. Since UCC policies define
how a users request is mapped to an underlying communication framework, it would be straightforward to go
through all the currently available frameworks and use the
1: createPolicySet(evt, commFWSet, polRepos)
/*Input: evt - events from reactive or user requests
polRepos -available policies in the repository
commFWSet - available comm. frameworks
Output: policySet- set of policies ranked by Value */
2: policySet {}
3: for all pol polRepos do
4:
if pol.scope(commFWSet) = true then
5:
if pol.condition(evt) = true then
6:
policySet policySet {pol}
7:
end if
8:
end if
9: end for
Fig. 6 Algorithm to select applicable policies

217

policy to decide which one satisfies the request. In its

simplest form, this set reduction technique is equivalent to
the naive set theory for intersection [11]: start with a full
set, and gradually reduce it until all policies are processed.
The input for the set reduction technique includes the
policy set resulting from the policy selection described
earlier, a set of available communication frameworks and
the request encapsulated in an event.
As with almost all non-trivial policy-based approaches,
there exists the possibility of policy conflicts. Approaches
for the static detection and resolution of policy conflicts
have been proposed [20, 28]. The area of dynamic detection and resolution of policy conflicts at runtime is still
fertile ground for research, although recent work [7] has
suggested renewed interest in this area. Implementation of
these techniques will be considered for addressing the
policy conflicts concern in the evaluation mechanism to
adequately support correct interpretation.

5 UCC autonomic framework

In this section, we present the architectural approach. We
also highlight some of the significant components with a
detailed design.
5.1 Architecture
The list of self-management properties continues to expand
as researchers identify new behavior [22] for systems that
will either directly or indirectly support the autonomic
concepts. The expanding and evolving nature of self-*
behaviors reinforced the need for an extensible design
horizontally (to add other self-* behavior) and vertically (to
extend self-management to the upper layers of CVM). Our
approach for supporting horizontal extensibility is by laterally stacking components that share a managed resource.
Liu et al. [27] specifies an autonomic components
interface as three ports: Functionaltraditional program
inputs and outputs; Controlsensors and effectors; and
Operationalrule injection and rule management. We
utilize this concept in our design of the NCB autonomic
architecture shown in Fig. 7. At the top right of Fig. 7 is
the Communication Services Manager (CSM) which utilizes the functional port of the communication frameworks
(bottom of Fig. 7) to provide communication services such
as creating a connection or enabling a particular medium.
The communication frameworks also include a control
port, indicated as Management Interface shown above the
frameworks in Fig. 7, which is used by the Touchpoint
Autonomic Manager (TPM). TPM directly interacts with
the sensors and actuators of the communication frameworks providing low-level management to the resource.

123

218

Pers Ubiquit Comput (2016) 20:209227

Communication
Requests

Policy
Authoring

NCB API
API Calls

NCB Manager

events / exceptions

policies
Reactive Calls
Call Queue

Communication Services
Manager

CSM
Commands

Request
Decomposition

Get
State

Request
Evaluation
OAM

Policy
Repository

Knowledge
Source

Framework
Select

Policy Evaluation

Touchpoint Autonomic
Manager

AC
Commands
Management Interface

NCBNative

Skype

Smack

Android

New
Communication
Framework

Comms Interface

Fig. 7 NCB architecture showing how various communication frameworks are coordinated using an autonomic framework

It is acknowledged that conflicts can occur between

standard application execution and adaptive behavior [27].
For highly multi-threaded and asynchronous systems such
as communication, coordination becomes even more
challenging. Our approach reduces the potential for such
conflicts through the use of a high-level coordinator which
we refer to as the Orchestration Autonomic Manager
(OAM). The OAM (left in Fig. 7) provides safe access to
the shared managed resources by monitoring the states of
the CSM and TPM components. The OAM can delay
sending commands to a component as well as cause the
component to suspend pending actions while the other
completes a non-concurrent task.
The OAM also has responsibility for evaluating
requests, retrieved from the call queue (top left of Fig. 7),
with respect to stated policies. The OAM is the main policy
decision point in the NCB (recall Fig. 5b(i) and (ii)) with
requests triggering the evaluation process. A request is one
of the two forms. The first is a users explicit desire for
service such as video conference with Bob, Mary and
me. The second form can be out-of-band events that fall
outside the scope of the TPM.
An example of such an event would be Failure in
Skype framework. The TPM detects the failure, but it
would be the responsibility of the OAM to identify all the
connections that were using this framework, select an
alternative and restore the state on the new framework.
Session creation and addition of parties lie in the functional
port, so OAM will need to regenerate the required

123

commands (based on the connections previous state) for

CSM to restore the service for the connection. With the
TPM escalating these events to the OAM, the OAM
therefore serves as a high-level autonomic manager.
5.2 Detailed design
Figure 8 shows the core components of our NCB Design, a
refinement of King et al. [23] Reusable Autonomic Manager design. At the bottom left of Fig. 8 is the package
edu.fiu.cvm.ncb.tpm which contains CommTPManager, a
specialization of the GenericManager. We parametrize
CommTPManger with a communication-specific touchpoint, CommFWTouch, which includes monitor methods
such as checkFWwhich iterates through the set of
frameworks, polling each for error state; and execute
methods such as resetFrameworkwhich reinstantiates a specific framework. Out-of-band events that cannot
be handled by the CommTPManager are encapsulated and
sent out asynchronously via ACSignal, to be handled by the
OrchestrationManager.
We show at the top right of Fig. 8 the package edu.fiu.cvm.ncb.cs which has the components responsible for
managing the communication services (CSM). The
ComObject interface defines the operations for the communication framework such as createConnection,
which creates a new communication framework session for
a specific connection identifier, and addParty, which
adds a new member to a communication session. The

Pers Ubiquit Comput (2016) 20:209227

signal
ACSignal
in NCBCall

interface
KSInterface
+setFeatureList()
+getFeatureList()
+setMapTable()
+getMapTable()
+...()

219

edu.fiu.cvm.ncb.cs

OrchestrationManager
csManager
interface
ComObject
+createConnection()
+addParty()
+enableMedium()
+...()

PolicyEvalManager
ComObjectMgr

*
1

edu.fiu.cvm.ncb.tpm
Touchpoint
GenericManager

CommFWTouch

edu.fiu.cvm.ncb.adpt

CommTPManager
1

CommFWTouch

CommFWResource
1

signal
ACSignal
out NCBCall

NCBBridge

interface
ACManagement
+hasFailed()
+resetFramework()
+...()

SkypeAdapter

SmackAdapter

NCBNative

Fig. 8 NCB detailed design diagram

ComObjectMgr maintains the set of available communication frameworks, while the csManager handles the highlevel coordination to effect the communication.
Package edu.fiu.cvm.ncb.adpt at the bottom right in
Fig. 8 includes the adapter classes for the communication
frameworks. For black-box communication frameworks,
such as Skype, the adapter classes function as managed
resource wrappers. SmackAdapter is the managed resource
wrapper that reuses the open source Smack libraries, and
NCBNative is the original NCB as proposed by Zhang
et al. Each adapter class implements the common sensor,
effector and communication methods of the NCBBridge
interface. The NCBBridge is an amalgamation of the
functional and control ports defined by the ComObject
interface of the edu.fiu.cvm.ncb.cs package and the
ACManagement interface of the edu.cvm.ncb.tpm package.
The OrchestrationManager, shown at top center of
Fig. 8, coordinates the use of the shared resources by
autonomic (TPM) and non-autonomic (CSM) components.
Additionally, the use of the knowledge source by the two
components (specifically the limits on the access to the
MappingTable as a reader-writer lock pattern) adds to the
safeness. CSM uses the MappingTable (getMapTable
method of the KSInterface, at the top left of Fig. 8) as readonly via indirection through the OAM, allowing the OAM
to monitor and queue when necessary the access to the
shared resource. Tthe TPM is responsible for updating the
table using locks when writing to the table. The PolicyEvalManager, below the OrchestrationManager in Fig. 8, is
the high-level policy decision point. Implementations of
the algorithms described in Sect. 4.2 are utilized in the
PolicyEvalManager to produce a candidate communication
framework.

5.3 Implementation
The architecture and designs for the autonomic NCB
described in the previous sections have been implemented. A
subset of the API2 for the autonomic NCB is presented in
Table 1 representing the interface available to the upper
layers of the CVM. The login method returns an object
(UserObject) containing profile information such as user
roles, saved schemas and contact lists. The profile information is reused by the upper layers of CVM including the
population of the displayed user interface. The createSession method creates a connection-to-session
object, providing a mapping to the high-level concept of a
connection to one or more communication framework sessions. The addParty method adds persons from the users
contact list to a previously created session. Streaming media
or non-streaming data are sent to members of a session by the
enableMedium method, while policies are introduced by
the applyPolicy method. Each method invocation is
added internally to a priority call queue and applied to a
specific connection object during the evaluation process to
produce a best-fit selection of communication framework.
Table 2 shows some of the static metrics from the
implementation which was collected using the Eclipse
Metrics 1.3.8 plugin. As discussed in Sect. 5.2, the autonomic NCB exploits the reusable autonomic manager of
King et al. [23] (referred to as ACSTF in Table 2). The
reusing of ACSTF meant NCB needed only 4 additional
classes to support self-configuration, the collection of
communication frameworks (CommFWResource) that
2

The full API is available as JAVADocs at http://www.cis.fiu.edu/

cml/.

123

220

Pers Ubiquit Comput (2016) 20:209227

Table 1 Sampling from NCB

JavaDocs

Method summary
void

addParty(String? sessionID, String? participantID)

This function adds the participants specified to the specific session

void

removeParty(String? sID, String? participant)

This method removes the list of participants from the given session

void

createSession(String? sessionID)
This function creates a session with the specific session ID

void

destroySession(String? sessionID)
This function destroys the specified session ID

void

disableMedium(String? connectionID, String? mediumName)

Stop sending the specified medium to all the participants in the connection

void

enableMedium(String? connectionID, String? mediumName)

Start sending the specified medium to all the participants in the connection

UserObject

login(String? userName, String? password)

This method will attempt login of the given user

void

logout(String? userName)
?Logs the user out

void

resetNCB()
Resets the ncb instance

VOid

applyPolicy(String? policy)
Add and apply specified policy to the NCB

Table 2 Metrics for NCB and ACSTF

Total lines of code

Number of packages
Number of interfaces
Number of classes

NCB

ACSTF

Total

9461

1091

10,552

27

32

156

17

173

extends AbstractResource; the touchpoint that uses

the resource and extends CommFWTouch; and the entity
responsible for the management of the touchpoint, the
CommTPManager which extends the GenericManager class. Additionally, the OrchManager also
extends the GenericManager class as it manages the
CommTPManager and the CSManager as discussed in
the previous section. Subsequent self-* behavior can easily
be included with the addition of another extension of the
GenericManager class. Of the 156 classes in NCB, 47
are within the adapter package and an additional 28 relates
to events and event handling. Total lines of code for the full
autonomic NCB inclusive of the ACSTF was 10,552.

6 Evaluation
We have implemented the autonomic NCB as a demonstration of the feasibility of the approach and incorporated
the designs discussed in the previous sections. The

123

evaluation of the implementation was based on the following hypotheses (1) the autonomic NCB has a sufficiently small overhead over baseline communication
frameworks and (2) at a maximum, the selection algorithm
employed scales linearly. The implementation was evaluated with respect to its efficiency (compared to previous
versions of CVM) and the scalability of the selection
mechanism. The policy shown in Fig. 4 was used in all
experiments.
We used three implementations of the NCB during the
experimental runs, where each run was composed of ten
iterations of the specific scenario. Two implementations
were based on a single-framework NCB without self-configuring behavior: One implementation was configured to
only use the Skype version 5.10 communication framework
API, and the other was configured to only use the Smack
version 3.0.4 communication framework API. The third
implementation was the new autonomic NCB with Skype
5.10 API and Smack 3.0.4 API as the supporting communication frameworks. A common driver application was
used to simulate CVM-type requests for all experimental
sets.
All computers used during the experiments met the
following specifications: Pentium 4 3 GHz, 1 GB RAM,
web camera and microphone with 100 Mb Ethernet
Adapters. Windows XP SP3, Java 1.6.0_18 and Eclipse
Version 3.5.2 were installed on all computers. TPTP version 4.6 [13], a Java profiling tool, was the data gathering
tool used during the evaluation process.

Pers Ubiquit Comput (2016) 20:209227

221

6.1 Audio to audiovideo conferencing setup

The three scenarios (2-way, 3-way and 4-way) measured
the time to setup the configuration to serve a users request
for an initial audio conference and then switch the configuration to video conferencing.
Figure 9 shows the average time for completing each
scenario in the experiment. The cluster of bars represents
the performance of the non-autonomic (Skype only and
Smack only) variants and the autonomic variant of the
NCB. The y-axis is the measured time in seconds for the
experiment. The bar representing the non-autonomic variant includes the times for starting the Skype version of
NCB initially, stopping and starting the Smack version of
NCB if necessary. The x-axis shows the three scenarios (2way, 3-way and 4-way), while the y-axis shows the time to
complete the switch and setup of a video conference. The
non-autonomic implementations of NCB performed better
than the autonomic variant for two-way audio conferencing
to video conferencing. From our analysis, this was due to
Skypes support for two-way video conferencing. Therefore, there was never a need to switch frameworks. The
autonomic version of NCB, however, had the additional
overhead of the AC framework threads.
It is shown in Fig. 9 that as the number of participants
increases the autonomic NCB scales better than the nonautonomic NCB. Skype video conferencing support is
limited to two way. As such, the Skype implementation of
NCB required a switch to the Smack implementation of
NCB. For the single-framework implementation, this
requires conference disconnection, shutdown and a restart
with the new framework implementation. We averaged the
time taken to manually stop and start an implementation to
compensate for differences in the speed of users in the
Fig. 9 Audio to video
conferencing setup times

experiments. We also noted from the data that the AC

framework accounted for noticeably less of the overall
execution time as the conferences participant count
increased.
6.2 N-way audio conferencing setup
The scenarios (n-way and n 1-way audio up to 5-way)
measured setting up the configuration to serve a user
request for an initial audio conference and to switch to
N 1 way for the experimental implementations. A fourth
implementation (Asterisk-only) was added to the initially
described three implementations (Skype-only, Smack-only
and AC NCB).
The averages for each scenario in the experiment are
displayed in Fig. 10. The graph shows the average time
inclusive of startup, negotiation and establishment of the
streams. The implementation with the best responsive time
was Asterisk-only. Our investigations revealed that this
was a result of the client-server nature of the implementation compared to the peer-to-peer architecture of the
other implementations. Negotiation time was minimal, as
the initiator simply created a room on the asterisk server
and then sent invitations with the room number to the other
parties. The AC NCB times included the initialization
times for all communication frameworks, which is
responsible for the significant difference compared to the
lighter Asterisk-only implementation times shown in
Fig. 10a. Figure 10b shows the results for starting a conference and then the subsequent addition of one other party
to the conference. A steady-state period of 40 s was
included to simulate a conversation before requesting the
additional user. As with the N-way conferences, the
AC NCB implementation mirrored the Asterisk-only

140

Set-up Time (seconds)

120

100

80
without AC Framework
with AC Framework
60

40

20

0
2 way

3 way

4 way

Audio to Video Conference

123

222
40
35

Pers Ubiquit Comput (2016) 20:209227

AC NCB

Asterisk

Smack

140

Skype

Asterisk

Smack

Skype

100

25
Seconds

Seconds

AC NCB

120

30

20
15

80
60

10

40

20

0
2 way

3 way

4 way

5 way

2 ->3 way

3 -> 4 way

4 -> 5 way

N to N + 1 Way Audio Conference

N Way Audio Conference

(a)

(b)

Fig. 10 Analysis of audio configuration times

100%

Fig. 11 Breakdown of
autonomic components versus
frameworks

90%

Active Time (sec)

80%
70%
60%

50%
40%
30%
20%
10%
0%

2 way

4 way

5 way

Average %

AC Components

3.723

4.657

5.511

5.446

26.463

Frameworks

11.138

12.894

13.700

16.748

73.537

implementation in the N 1-way conferences. Asteriskonly was the framework candidate selected to be used by
the AC NCB based on the policies used in these scenarios.
The Smack-only and Skype-only were linear with respect
to the number of parties involved in the conversation as
these implementations incrementally added the parties.
The results were further analyzed to see what was the
impact of the autonomic components in the time analysis.
Figure 11 indicates the proportion of time dedicated to the
autonomic processes as compared to the communication
framework processes. This is on average 26 % of the
processing time consumed by autonomic processes. A
detailed inspection of the results showed the monitor
threads responsible for a significant portion of the consumed time. The current implementation of the monitor
threads poll at specified intervals. Optimized alternatives to
the naive polling implementation can further reduce the
time consumed by the autonomic components.
6.3 Analysis of candidate selection algorithm
We evaluated the technique for selecting the candidate
communication framework using the new autonomic NCB.

123

3 way

We measured the elapsed time from receiving a users

request to the returning of a candidate communication
framework. Varying numbers of communication frameworks were included in the pool for selection during the
experimental runs, and each run was composed of ten
iterations of a specific pool size. The experimental runs for
each pool size was then averaged and tabulated.
The pool sizes range from 2 to 16, and the averages for
the runs are shown in Fig. 12. The graph represents the
average time for the selection process with respect to the
number of communication frameworks available. The x
axis shows the number of communication frameworks
available at the start of the selection process, while the y
axis shows the time taken to complete the policy evaluation
and return a candidate communication framework. The
graph shows a nonlinear increase in the selection times
with respect to the increase in the communication framework pool. The predicted increase was a typical linear
increase based on the time complexity analysis of 2n  1
for the recursive algorithm. However, a detailed review of
the data shows that six was the maximum combination of
feature attributes used in the experiments. Therefore,
multiple communication frameworks are guaranteed to be

Pers Ubiquit Comput (2016) 20:209227

223

Time to Select Candidate Framework

(seconds)

0.6

0.5

0.4

0
3
0.3

0.2

0.1

0
2

10

11

12

13

14

15

16

Number of Communication Frameworks

Fig. 12 Average times to select candidate communication framework

removed at this threshold. On average a reduction in the set

of communication frameworks occurs with each feature
attribute evaluated. We note, however, that a request that
can be satisfied by all communication frameworks in the
set may not exhibit this behavior.
6.4 Discussion
Our implementation of the NCB is a proof of concept for
the introduction of extensible services to the CVM. The
autonomic NCB currently includes four communication
frameworks, Skype, Smack, Asterisk and NCBNative. For
Sect. 6.3 experiments, additional communication frameworks were created as stubs to support the simulation.
This, however, does not reflect a limitation of the
implementation as additional communication frameworks
can be interfaced in the future. The number of active
communication frameworks will be dependent on the
limitation of the specific communication device. While it
may seem unrealistic to support that many frameworks on
a device, we view this exercise as a proof of concept
where different elements of concern that may impact the
final configuration maybe selected from such a large pool
of options.
The experimental sets used a polling interval of 250 ms
for the monitoring thread of the MAPE functions for the
autonomic framework. This value was derived from earlier
experiments aimed at finding a balance between minimizing the effects of the MAPE polling and adequately evaluating system changes. Work on more resource friendly
methods such as event driven signaling may provide an
alternative to the current implementations use of polling.
Tools for performance evaluation generally do not
introduce significant overhead to the monitored environment. For real-time systems this tends not to be the case as

the sampling period can influence the application performance. In our evaluation process, Eclipse Test and Performance Tools Platform was used for monitoring and
profiling the implementation. This introduced additional
memory and computation overhead, which in turn introduced delays in the participants negotiation process. We
compensated for this overhead by reducing the sampling
period and focused the profiling and monitoring based on
the criteria of the specific experiment.
6.5 Future directions
The design of the broker layer presented in this paper is
specific to the user-centric communication, hence the
Network Communication Broker (NCB). Recent work
done on the CVM involves the transformation to a more
generic virtual machine for interpreting i-DSMLs, this
class of virtual machines are referred to as a DomainSpecific Virtual Machine (DSVM) [9]. The idea is to
separate the generic model of execution (GMoE) from the
domain-specific knowledge (DSK). Combining the GMoE
and the DSK produces a DSVM for the specific domain;
e.g., the CVM would be instantiated using the GMoE
and the domain-specific knowledge for user-centric
communications.
To date there has been work on transforming the upper
layers of the CVM into GMoE and DSK in order to easily
instantiate DSVMs for new domains. Alison et al. [4]
describe an approach that instantiates the synthesis engine
(SE) for energy management in smart microgrids from the
GMoE and the DSK to produce the Microgrid Virtual
Machine (MGridVM). Morris et al. describe an approach
that instantiates the middleware from the GMoE and DSK
for the user-centric communication middleware (UCM)
[30].

123

224

The future work with respect to the NCB involves the

separation of the GMoE and the DSK for the NCB, and to
determine the effectiveness of instantiating the broker in
other DSVMs, such as the broker in MGridVM for energy
management in smart microgrids. The initial work in this
direction was done by Sousa et al. [45] in developing a
metamodel for the broker layer for the CVM. This metamodel describes various aspects of the broker that may be
applicable to other DSVMs, and these include: interface,
signal handling mechanism, resource management, state
management, autonomic management and policies. Sousa
et al. also described how the NCB may be instantiated from
the metamodel and provided some preliminary results.

7 Related work
The diversity of media capacity, service provider and user
preference and the increasing demand for collaborative
work requires multimedia middleware to provide seamless
integration of various system components. Proposals such
as the Next-Generation Network (NGN) as envisioned by
the International Telecommunication Union Standardization Sector (ITU-T) [18] aims to provide the infrastructure
necessary for meeting these challenges. The challenges of
such middleware include: the independence of specific
communication systems, the interoperability between different devices and media, the support for QoS-aware
adaptation during runtime and the common and easy
interface to configure, navigate and monitor the
environment.
7.1 Communication APIs
Many of the APIs that support communication over the
Internet use the H.323 [19], SIP [39] and RTP [41] protocols. Other protocols have since been created based on
the aforementioned protocols such as JAIN SIP [35] and
Java Media Framework (JMF) [36], among others. Stiller
et al. [47] developed the Da CaPo?? system, a framework
embracing both low-level communication subsystems and
high-level APIs to support distributed multimedia applications based on a formal description of protocol graphs to
configure, validate and execute different media flows at
each participating peer system. The OSA/Parlay by Open
API Solutions [34] is a suite of open, standard, APIs
designed to facilitate easier access to core network capabilities from outside of the network. The OSA/Paraly APIs
support the creation of telecommunications services by
developers. The communication API we provide in our
implementation of the NCB is at a higher level of
abstraction than the APIs previously mentioned. The NCB

123

Pers Ubiquit Comput (2016) 20:209227

API to the User-Centric Middleware (UCM) was previously described in Sect. 5.3.
7.2 User-centric communication services
There has been an upsurge in research in the area of usercentric communication service creation and use. Lasserre
and Kan [24] reported on the fragmented customer and
employee experience when people try to contact each other
using the myriad of available technologies. As a result of
the study Alcatel developed an enterprise communication
architecture with the following key principles: user-centricfocusing on the benefits to the user and offering
operating simplicity to mask the complexity of the underlying technology; opennessis the basis for choice, which
extends from the users choice of device, to product
components, to the deployment model; and unifiedunifying voice and data, fixed and wireless, and applications,
enables services to be delivered seamlessly across different
media.
More recently there has been a major initiative to mix
traditional telecommunication services and web capabilities to provide so-called web ? telco mash-ups. Sienel et al.
[42] describes the Open Platform for User-centric service
Creation and Execution (OPUCE) service architecture that
supports the interoperation of telecommunications (telco)
and information technology (IT) applications. The OPUCE
platform integrates the following: a service creation environment, a service life-cycle manager and a service execution environment (SEE). The SEE seamlessly integrates
the orchestration of services running on top of several
technologies, including Java 2 Enterprise Edition (J2EE),
Java API for integrated networks service logic execution
environment (JAIN SLEE), SIP servlets [39], .NET or
client-side widgets. The approach presented in this paper is
more lightweight since we do not employ a server during
the realization of the communication applications, instead,
we indirectly use the servers provided by the communication frameworks.
7.3 Autonomic communication services
There is a plethora of research in the area of autonomic
communications. Dobson et al. [12] provide a comprehensive survey of the current state of autonomic communications research and identify significant emerging trends
and techniques. Most of the research in the autonomic
communication area focuses on applying autonomic capabilities to the network infrastructure including self-management of the topology, load, task, physical and logical
characteristics of the networks. In our work we instead
focus on the layer of the middleware that interacts with the

Pers Ubiquit Comput (2016) 20:209227

network infrastructure, more specifically the communication frameworks that interact with the network layer.
Gu et al. [15] describes the Architecture of Network
Autonomy (ANA) system, where high-level abstractions
are achieved through the interface of a policy-based management to provide autonomic multimedia communication
with minimum human administration. We use a conceptual
approach similar to Gu et al. when applying policies to the
self-management of the communication frameworks in
NCB. Sousa et al. [46] described a task-aware system
where users explicitly specified goals and quality attributes
through a set of user interfaces. Based on that, the underlying self-managing system dynamically queried the task to
trigger reconfiguration if needed. Our policy application
mechanism combines the approaches used by Gu et al. [15]
and Sousa et al. [46]. That is, the user defines the high-level
policies based on the communication tasks to be performed
at runtime and the gap between business (high-level)
policies and their technical counterparts are bridged
through the collaboration between the autonomic managers
and the policy refinement system.
7.4 Dynamic adaptation
Rasche et al. [38] presents a framework for dynamic component configuration and reconfiguration based on Microsoft.NET. Their work is similar to ours in that an XML-based
configuration description language is designed and used to
instantiate the component, or generate reconfiguration
actions such as the addition, removal or modification of a
component, if necessary. However, their reconfiguration
algorithm, once chosen, remains fixed at runtime while our
design is inherently more flexible since reconfiguration
algorithms could be wrapped as internal policies. Lewis et al.
[26] present an approach for the management of user-centric
adaptive services. This work shares some similar traits with
our autonomic framework in its adaptive service composition and policy-based management of adaptive system
behavior. However, a centralized system is used to compose
the services needed. Our approach is based on a peer-to-peer
model, with the flexibility to change this model.
Another approach for dynamic reconfiguration of distributed multimedia middleware and applications is proposed in [37], where models are used at runtime as a means
to structure the reflection mechanisms used for adaptation.
Similarly to our work, Provensi et al. [37] proposes the use
of an autonomic loop and policies for the monitoring of
applications and their environment and for directing the
reflection mechanisms. In our work, however, we emphasize the user-centric aspect and provide a comprehensive
solution for policy definition and interpretation, which are
not considered in [37].

225

King et al. [23] present a reusable object-oriented design

for developing self-testable autonomic software. Their
design provides a generic manager that can be instantiated
to provide both autonomic and testing services based on
high-level policies. King et al. [23] apply their design to a
small autonomic prototype simulation. Our approach borrows from the manager design in [23]. However, due to the
high safety requirements of the NCB, we extended the
work in [23] by incorporating additional mechanisms for
suspending and resuming the generic manager. Furthermore, our autonomic NCB design applies the generic
manager design to the implementation of a real autonomic
system rather than a simulation.
7.5 Evolution of NCB
The initial NCB was developed by Zhang et al. [52], and
the focus was to provide a higher level of abstraction that
encapsulated the complexity of the underlying network.
The NCB also provided some self-management capabilities
such as dynamic adaptation in response to changes in the
network conditions. Sadjadi et al. [40] provided more
details on the design and implementation for the initial
version of the NCB focusing on how the internal network
addresses were mapped to the globally accessible network
addresses. Sadjadi et al. [40] described how the Network
Address Translation (NAT) method and Simple Traversal
of User Datagram Protocol through NATs (STUN) were
used during self-configuration to realize end-to-end communication. As previously stated, the new implementation
of the NCB uses the initial version of the NCB referred to
as NCBNative.
The initial idea for self-configuring user-centric communication services was presented by Allen et al. [2] and
further refined with the concept of policy-driven self-configuration [6]. The latter paper describes the conceptual
designs for the architecture along with a policy authoring
tool for UCC. The work by Allen et al. [3] is most closely
related to the work presented in this paper.
That paper presented an initial design and a prototype of
the autonomic NCB including an initial definition for UCC
policies, and a simple technique for evaluating the policies
as well as preliminary experimental evaluations of the
prototype. The contents of this paper (1) presents a formal
policy definition and provides a more comprehensive
solution for policy interpretation; (2) provides high-level
architectural design and detailed refinements of the NCB
implementation, including the API that exposes the usercentric communication services to the UCM; and (3)
extends the experiments to include a broader set of scenarios and increase the number of communication frameworks used in each scenario.

123

226

8 Conclusion
In this paper, we presented a new design of the NCB that
supports the use of multiple communication frameworks
and an approach for dynamic adaptation of communication
services to reduce the complexity of reusing multiple
communication frameworks. To support this dynamic
adaptation, we defined user-centric communication policies
and outlined the technique for their interpretation, which
was one of the several enhancements made with respect to
previous work. Details of the design of our autonomic
framework were discussed and evaluation of the autonomic
framework presented.
We plan in the future to further extend the NCB to
include self-healing properties to provide recovery options
for a collaborative communication session. We will also be
investigating extending NCB to other domains through the
separation of domain knowledge and development of a
generic model of execution. Additionally, we will be
investigating the use of models to further improve the
performance of the evaluation and generation of new
configurations at runtime.

References
1. Agrawal D, Calo S, Lee KW, Lobo J, Verma D (2008) Policy
technologies for self-managing systems. IBM Press, Indianapolis
2. Allen AA, Leslie S, Wu Y, Clarke PJ, Tirado R (2008) Selfconfiguring user-centric communication services. In: ICONS
2008. IEEE, pp 253259
3. Allen AA, Wu Y, Clarke PJ, King TM, Deng Y (2009) An
autonomic framework for user-centric communication services.
In: CASCON 2009. ACM, New York pp 203215
4. Allison M (2014) A generic model of execution for synthesizing
domain-specific models. Ph.D. thesis, Florida International
University, FIU Electronic Theses and Dissertations (2014).
http://digitalcommons.fiu.edu/etd/1563
5. Allison M, Morris KA, Costa FM, Clarke PJ (2014) Synthesizing
interpreted domain-specific models to manage smart microgrids.
J Syst Softw 96:172193
6. Boettner P, Gupta M, Wu Y, Allen AA (2009) Towards policy
driven self-configuration of user-centric communication. In:
ACM-SE 47. ACM, New York, pp 35:135:6
7. Charalambides M, Flegkas P, Pavlou G, Rubio-Loyola J, Bandara
A, Lupu E, Russo A, Sloman M, Dulay N (2006) Dynamic policy
analysis and conflict resolution for diffserv quality of service
management. In: Network Operations and Management Symposium, 2006. NOMS 2006. 10th IEEE/IFIP, pp 294304 (2006).
doi:10.1109/NOMS.2006.1687560
8. Chung KY (2014) Recent trends on convergence and ubiquitous
computing. Pers Ubiquitous Comput 18(6):12911293. doi:10.
1007/s00779-013-0743-2
9. Clarke PJ, Wu Y, Allen AA, Hernandez F, Allison M, France R
(2012) Towards dynamic semantics for synthesizing domainspecific models. In: Mernik M (ed) Formal and practical aspects
of domain-specific languages: recent developments., Chap. 9. IGI
Global, pp 242269

123

Pers Ubiquit Comput (2016) 20:209227

10. Deng Y, Masoud Sadjadi S, Clarke PJ, Hristidis V, Rangaswami
R, Wang Y (2008) CVMa communication virtual machine.
J Syst Softw 81(10):16401662. doi:10.1016/j.jss.2008.02.020
11. Devlin K (1993) The joy of sets: fundamentals of contemporary
set theory, 2nd edn. Springer, New York
12. Dobson S, Denazis S, Fernandez A, Gati D, Gelenbe E, Massacci
F, Nixon P, Saffre F, Schmidt N, Zambonelli F (2006) A survey
of autonomic communications. ACM Trans Auton Adapt Syst
1:223259
13. Eclipse Test and Performance Tools Platform Project: Eclipse
Test and Performance Tools Platform (2010). http://www.eclipse.
org/tptp/
14. Google: GoogleTalk (2010). http://www.google.com/talk/
15. Gu X, Strassner J, Xie J, Wolf L, Suda T (2008) Autonomic
multimedia communications: Where are we now? Proc IEEE
96(1):143154. doi:10.1109/JPROC.2007.909880
16. IBM Autonomic Computing Architecture Team (2006) An
architectural blueprint for autonomic computing. Tech. rep, IBM,
Hawthorne, NY
17. Ignite Realtime: Smack api 3.1.0 (2009). http://www.igniter
ealtime.org/
18. ITU-T: Y.2001 General overview of NGN. International
Telecommunication Union (2004)
19. ITU-T Recommendation: Packet-based Multimedia Communications Systems (2009). Tech. rep., Network Working Group.
H.323 v7
20. Kamoda H, Broda K (2005) Policy conflict analysis using free
variable tableaux for access control in web services environments. In: In policy management for the web workshop, pp 512
21. Kephart J, Chess D (2003) The vision of autonomic computing.
Computer 36(1):4152
22. King TM, Babich D, Alava J, Clarke PJ, Stevens R (2007)
Towards self-testing in autonomic computing systems. In: ISADS
07: Proceedings of the eighth international symposium on
autonomous decentralized systems, pp 5158. IEEE Computer
Society, Washington, DC, USA (2007). doi:10.1109/ISADS.
2007.75
23. King TM, Ramirez AE, Clarke PJ, Quinones-Morales B (2008) A
reusable object-oriented design to support self-testable autonomic
software. In: SAC, pp 16641669
24. Lasserre P, Kan D (2005) User-centric interactions beyond
communications. Alcatel Telecommunications Review, 1st
Quarter
25. Lei H, Ranganathan A (2004) Context-aware unified communication. In: Proceedings of the 2004 IEEE international conference
on mobile data management, 2004, pp 176186 (2004). doi:10.
1109/MDM.2004.1263064
26. Lewis D, ODonnell T, Feeney K, Brady A, Wade V (2004)
Managing user-centric adaptive services for pervasive computing.
In: ICAC 2006. IEEE Computer Society, pp 248255
27. Liu H, Parashar M (2006) A programming system for autonomic
self-managing applications. In: Parashar M, Hariri S (eds)
Autonomic computing: concepts, infrastructure, and applications.
CRC Press, Boca Raton, pp 211235
28. Lupu E, Sloman M (1997) Conflict analysis for management
policies. In: Proceedings of the fifth IFIP/IEEE international
symposium on integrated network management V: integrated
management in a virtual world. Chapman & Hall Ltd, London,
UK, pp 430443
29. Masullo MJ, Calo SB (1993) Policy management: an architecture
and approach. In: IEEE first international workshop on systems
management, pp 1326
30. Morris KA, Allison M, Costa FM, Wei J, Clarke PJ (2015) An
adaptive middleware design to support the dynamic interpretation
of domain-specific models. Inf Softw Technol 62:2141

Pers Ubiquit Comput (2016) 20:209227

31. Network Working Group: The COPS (Common Open Policy
Service) Protocol: Request for Comments: 2748 Category:
Standards Track (2000)
32. Network Working Group: Policy Core Information Model
(PCIM) Extensions: Request for Comments: 3460 IBM Updates:
3060 Category: Standards Track (2003)
33. ooVoo LLC: ooVoo Developers (2010). http://www.oovoo.com/
Developers.aspx?pname=DevelopersMain
34. Open API Solutions: OSA/Parlay (2010). http://www.open
apisolutions.com/brochures/OSAParlayOverview.pdf
35. Oracle: JAIN-SIP-1.2 (2010). https://jain-sip.dev.java.net/
36. Oracle: Java Media Framework API (JMF) 2.1.1.e (2010). http://
www.oracle.com/technetwork/java/javase/tech/index-jsp-140239.
html
37. Provensi LL, Costa FM, Sacramento V (2009) Management of
runtime models and meta-models in meta-ORB reflective middleware architecture. In: Proceedings of the 4th International
Workshop Models@Run.time, CEUR Workshop Proceedings,
vol 509, pp 8188. CEUR-WS.org, Denver
38. Rasche A, Polze A (2003) Configuration and dynamic reconfiguration of component-based applications with Microsoft.NET. In:
IEEE sixth international symposium on object-oriented real-time
distributed computing, p 164
39. Rosenberg J, Schulzrinne H, Camarillo G, Johnston A, Peterson J,
Sparks R, Handley M, Schooler E (2002) SIP: session initiation
protocol. Tech. rep., Network Working Group (2002). RFC 3261
40. Sadjadi S, Kalayci S, Deng Y (2008) A self-configuring communication virtual machine. In: IEEE international conference on
networking, sensing and control, 2008. ICNSC 2008, pp 739744
(2008). doi:10.1109/ICNSC.2008.4525314
41. Schulzrinne H, Casner S, Frederick R, Jacobson V (2003) SIP:
session initiation protocol. Tech. rep., Network Working Group
(2003). RFC 3550
42. Sienel J, Martn AL, Zorita CB, Goix LW, Reol AM, Martnez
BC (2009) OPUCE: A telco-driven service mash-up approach.
Bell Lab Tech J 14:203218. doi:10.1002/bltj.v14:1

227
43. Skype Limited: Skype (2010). http://www.skype.com/intl/en-us/
home
44. Sloman M (1994) Policy driven management for distributed
systems. J Netw Syst Manag 2:333360
45. Sousa GCM, Costa FM, Clarke PJ, Allen AA (2012) Modeldriven development of DSML execution engines. In: Proceedings
of the 7th Workshop on Models@Run.Time, MRT 12, pp 1015.
ACM, New York (2012). doi:10.1145/2422518.2422521
46. Sousa J, Poladian V, Garlan D, Schmerl B, Shaw M (2006) Taskbased adaptation for ubiquitous computing. IEEE Trans Syst Man
Cybern Part C Appl Rev 36(3):328340. doi:10.1109/TSMCC.
2006.871588
47. Stiller B, Class C, Waldvogel M, Caronni G, Bauer D (1999) A
flexible middleware for multimedia communication: design,
implementation, and experience. IEEE J Sel Areas Commun
17(9):15801598. doi:10.1109/49.790483
48. van der Meer Stephan Steglich SAS (2001) User-centric communications. In: IEEE international conference on telecommunications, pp 425444. Special Sessions
49. Wang H, Morlang A, Katz R (2001) A personal communication
service creation model for internet-based unified communication
systems. In: Proceedings of IEEE international conference on
communications, pp 13251329. doi:10.1109/ICC.2001.936919
50. Weiser M, Gold R, Brown JS (1999) The origins of ubiquitous
computing research at parc in the late 1980s. IBM Syst J
38(4):693696. doi:10.1147/sj.384.0693
51. Wu Y, Allen AA, Hernandez F, France R, Clarke PJ (2012) A
domain-specific modeling approach to realizing user-centric
communication. Softw Pract Exp 42(3):357390
52. Zhang C, Sadjadi M, Sun W, Rangaswami R, Deng Y (2006) A
user-centric network communication broker for multimedia collaborative computing. In: International conference on collaborative computing: networking, applications and worksharing, 2006.
CollaborateCom 2006, pp 15 (2006)

123