![Goals and Conflicts in Telephony
Kenneth J. Turner and Gavin A. Campbell
Computing Science and Mathematics, University of Stirling, Stirling FK9 4LA, UK
e-mail: kjt | gca @cs.stir.ac.uk
Abstract.
Goals are abstract, user-oriented objectives for how a system should behave. To
be made operational, they are refined into lower-level policies that are executed dy-
namically. It is explained how previous work on policy-based management has been
enhanced with a separate goal system that allows goals to be specified, analysed,
refined, and achieved. It is shown how conflicts can arise at several levels among
goals, and how these conflicts are detected and handled. Although the approach is
general, it is illustrated through an application to Internet telephony.
Keywords.
Call Control, Goal, Goal Conflict, Goal Refinement, Policy-Based Management
1. Introduction
Goals are introduced as a high-level, abstract way for users to define system objectives
in a non-technical manner. The concept of goal refinement is explained. In contrast to
other work, which relies on static logical analysis, the approach here views refinement
as a dynamic optimisation task.
1.1. Background
The trend in communications is for people to be always contactable – in the office, at
home, or on the move. As a result, there is an increasing need for users to be able to man-
age their communications flexibly. Traditional telephony features are network-centric,
being designed by the network operator and supported in network equipment. Internet
telephony is becoming increasingly widespread. Following Internet philosophy, func-
tionality tends to be located at the edges of the network. In particular, this means that
customisation of call handling can be placed much more in the hands of end users.
The authors and their colleagues have exploited this trend by developing a policy-
based management system for Internet telephony (e.g. [11]). Policies operate at a higher
level than features, and offer many advantages such as orientation towards user needs,
flexibility, and customisability. A system called ACCENT (Advanced Component Con-
trol Enhancing Network Technologies, www.cs.stir.ac.uk/accent) has been developed for
supporting policy-based management. The ACCENT system was designed for end users,
e.g. policies are formulated through a wizard rather than requiring programming or de-
tailed technical knowledge. Although initially developed for Internet telephony, the ap-
proach is general and has now been extended to other applications such as managing
sensor networks, wind farms and home care systems.
Feature Interactions in Software and Communication Systems X
M. Nakamura and S. Reiff-Marganiec (Eds.)
IOS Press, 2009
© 2009 The authors and IOS Press. All rights reserved.
doi:10.3233/978-1-60750-014-8-3
3
Feature Interactions in Software and Communication Systems X, IOS Press, Incorporated, 2009. ProQuest Ebook Central,
Copyright
©
2009.
IOS
Press,
Incorporated.
All
rights
reserved.](https://image.slidesharecdn.com/100615-250414142610-0ef49a6a/85/Feature-Interactions-in-Software-and-Communication-Systems-X-1st-Edition-M-Nakamura-17-320.jpg)
![Although policies are higher-level and more user-oriented than features, they are
still relatively imperative. What is required is a more abstract way for users to formulate
their needs. This has now been achieved through the design and implementation of a goal
system. Goals are persistent, abstract, user-oriented objectives for how a system should
behave. They are declarative statements of what is required, not operational statements
of how they should be achieved. In fact, they are sufficiently abstract that they cannot
be realised directly. A process of refinement is needed to map the goals onto lower-level
policies that can then be used to achieve them.
The work in this paper describes how goals are specified and statically analysed
to create policies that realise them. Offline analysis is also concerned with appropriate
definition of goals. Support at run time is provided to choose the most relevant policies
according to the dynamically changing state of the system. The approach allows users to
define high-level goals for how the system should behave (e.g. how calls are handled).
The details of how goals are achieved can be largely hidden from the users.
Feature interaction is a long-known phenomenon in telephony. The authors and their
colleagues have investigated policy conflict as the higher-level equivalent in policy-based
systems [10]. The new work reported here has raised the approach to a more abstract
level. Not surprisingly, conflicts also arise with the use of goals. As will be seen, such
conflicts manifest themselves at several levels.
1.2. Goals and Policies for System Management
Goals have a venerable history in artificial intelligence, where they are often used to
define desired states of a system. Goals are typically used by a planning system to build
sequences of actions that achieve them. A similar approach has been adopted in agent-
based systems.
Goals in the context of policy-based management have received little study. Here, the
notion of a goal is an objective for system behaviour. Refinement of goals into policies
is typically treated through logic: policies are identified to meet the goals through a
process of logical entailment. This is essentially a static (offline) analysis. In the work
reported here, goal refinement is viewed as a numerical optimisation problem. The main
advantage is that goals can be supported in a fully dynamic way: as the system and its
environment change, the policies that achieve goals are automatically evolved to give the
best match to current circumstances.
In the formulation adopted, goals are associated with numerical measures (e.g. ‘call
cost’ or ‘multimedia use’) for how well they are achieved. In general, such measures
are maximised (positive goals) or minimised (negative goals). Goal measures are arbi-
trary functions over system variables, though for practical and technical reasons they
are normally weighted sums. Since there are usually multiple (often conflicting) goals,
their measures are combined into an overall evaluation function that assesses how well a
candidate set of policies meets the full set of goals. The evaluation function is again an
arbitrary formula, though normally a weighted sum of goal measures.
Goals are sufficiently high level that they cannot be used directly. Instead, goals are
realised through prototype policies (prototypes for short) that contribute to them. These
prototypes form a library of ‘building blocks’ for accomplishing goals. When goals are
first defined, they are statically analysed against the available prototypes. This identifies
the prototypes that may contribute towards each goal. However, the actual selection is de-
K.J. Turner and G.A. Campbell / Goals and Conflicts in Telephony
4
.
Feature Interactions in Software and Communication Systems X, IOS Press, Incorporated, 2009. ProQuest Ebook Central,
Copyright
©
2009.
IOS
Press,
Incorporated.
All
rights
reserved.](https://image.slidesharecdn.com/100615-250414142610-0ef49a6a/85/Feature-Interactions-in-Software-and-Communication-Systems-X-1st-Edition-M-Nakamura-18-320.jpg)
![ferred until run-time since the most appropriate policies are likely to depend on the actual
circumstances (e.g. the current bandwidth or the cost of a call). Prototypes are therefore
selected and instantiated dynamically as normal policies. In addition, prototypes may
have parameters that are dynamically optimised.
The benefit of this approach is that the existing ACCENT policy server is barely
affected by the new goal system. As far as the policy server is concerned, it handles
policies as usual (except that some policies derive from goals). Other mechanisms such
as handling policy conflicts at run time can therefore operate as normal.
Policies are written in APPEL (Adaptable and Programmable Policy Environment
and Language, www.cs.stir.ac.uk/appel). This is designed to be extensible for new appli-
cation domains. The core policy language has extensions for regular policies and resolu-
tion policies. In turn, these are specialised for each domain: call control is currently one
of several rather different applications. Since policies are internally XML, extensibility
is achieved by defining APPEL through a hierarchy of schemas that build on each other.
Although these schemas define the formal structure of APPEL, this is not sufficient.
The schemas are therefore supplemented by ontologies that define the concepts and re-
lationships in each application domain. Again this is hierarchical, with a core ontology
that is extended for each application.
For the work reported here, the schemas and ontologies have been extended to sup-
port goals and prototypes. The latter are intentionally defined in a very similar way to
policies (both regular and resolution policies). This gives a consistent structure to the
language, and also allows common software support throughout all system components.
1.3. Related Work
Planning in artificial intelligence goes back about 40 years (e.g. the STRIPS system).
Much more recent is work on agent-based systems. As an example, 3APL (Agent Pro-
gramming Language, www.cs.uu.nl/3apl) defines goals and beliefs. Plan revision rules
allow plans to be created from predefined rules, using actions from an action base to
achieve goals. In agent-based approaches, goals are achieved through planning using var-
ious kinds of agents (goal-based, logical, knowledge-based). Goals have also been ad-
dressed in requirements engineering. Systems such as KAOS (originally Knowledge Ac-
quisition in autOmated Specification [12]) aim to build a formal proof that the require-
ments derived for a system meet its goals.
Goals in a policy context are interpreted rather differently. The notion of a policy
hierarchy was first identified in [8]. This led to the idea of refining higher-lever policies
into lower-level ones. [6] extended this notion into a continuum of policies, with goals
being policies at the highest level; however, this is currently just a framework without a
concrete implementation. A formal approach to goal refinement using Event Calculus is
described in [3]. This has been implemented using KAOS, with refinement patterns being
used to decompose goals into subgoals. As another formal approach, [9] uses temporal
logic in a two-stage refinement process from goals to subgoals, and subgoals to policies.
In the context of feature interaction, [7] identified the problem of goal conflict in
telephony. This approach uses agents to negotiate a plan on behalf of end users to avoid
conflicts. This is a different kind of problem from the one tackled in this paper. The User
Requirements Notation for goals [2] complements the current paper, and will be studied
for possible synergy in future. Fuzzy policies with weights [1] are reminiscent of the nu-
K.J. Turner and G.A. Campbell / Goals and Conflicts in Telephony 5
Feature Interactions in Software and Communication Systems X, IOS Press, Incorporated, 2009. ProQuest Ebook Central,
Copyright
©
2009.
IOS
Press,
Incorporated.
All
rights
reserved.](https://image.slidesharecdn.com/100615-250414142610-0ef49a6a/85/Feature-Interactions-in-Software-and-Communication-Systems-X-1st-Edition-M-Nakamura-19-320.jpg)
![merical approach taken here. Although the work reported in this paper has concentrated
on goal refinement as a practical technique, issues of goal conflict have inevitably arisen.
These can be regarded as a high-level form of feature interaction. The related notion
of policy conflict has been investigated in [10]. As will be seen, goal conflicts arise at
various levels as the goals are achieved through refinement and execution.
The work in this paper differs in a number of important respects from other ap-
proaches. Although some offline analysis is performed, the bulk of the analysis happens
at run time. This is intentional as the choice of policies should depend on the prevail-
ing circumstances. Virtually all other work uses offline techniques, and hence cannot
anticipate changes in the system environment.
The approach is based on numerical rather than logical reasoning. This is more flex-
ible in that it does not require any absolute notion of fulfilling goals. Rather, it is possible
to satisfy goals only as far as is possible (which may be the only practical possibility).
Nearly all other approaches are based on strict logic.
A pragmatic rather than a theoretical approach is followed. Requiring use of formal
methods is a considerable barrier for most engineers and designers, and is inappropriate
for end users. The need to perform goal refinement at run time is a particular challenge,
since most formal techniques require considerable computation. Almost all other goal
refinement techniques are formal.
1.4. Paper Outline
Section 2 discusses the goal system architecture, how goals and prototypes are formu-
lated, and the kinds of analysis that are performed to realise goals through policies.
In particular, the nature of goal conflict is investigated. Section 3 illustrates the ideas
through their application to telephony. Section 4 summarises the approach, and indicates
that it has been applied in other application domains.
2. The Goal System
APPEL has been extended to define goals and prototypes. Goal refinement has also been
implemented in a package called OGRE (Optimising Goal Refinement Engine). The new
goal capabilities have required only small changes in the existing policy system.
2.1. System Architecture
The overall system architecture to support goals and policies is shown in figure 1. For
historical reasons, and because the system primarily deals with policies, a number of
components are labelled ‘Policy’. However, apart from regular policies, the system also
deals with goals, prototypes, resolution policies (that deal with conflicts), and variables
(that may be used in goals and policies). The major system components communicate
via socket connections (shown as grey arrows in the figure). This gives flexibility in
distributing them across processors, though they may all run on one physical machine.
The system components have the following functions:
Managed System: the system under control, e.g. a softswitch in Internet telephony [11].
Policy Store: an XML database that stores information about goals and policies [11].
K.J. Turner and G.A. Campbell / Goals and Conflicts in Telephony
6
Feature Interactions in Software and Communication Systems X, IOS Press, Incorporated, 2009. ProQuest Ebook Central,
Copyright
©
2009.
IOS
Press,
Incorporated.
All
rights
reserved.](https://image.slidesharecdn.com/100615-250414142610-0ef49a6a/85/Feature-Interactions-in-Software-and-Communication-Systems-X-1st-Edition-M-Nakamura-20-320.jpg)
![Policy Server
Static
Analyser
Dynamic
Analyser
Ontology
Server
Policy
Manager
Policy
Interface
Policy
Store
Managed
System
Policy
Wizard
Policy
Selector
Conflict
Manager
Context
Manager
End
User
System
Admin
Conflict
Analyser
Goal Server
Figure 1. System Architecture
Policy Server: the heart of the policy system [11]. The policy manager is the interface
to the policy store, isolating the rest of the system from the particular choice of
database. It receives new or updated goals and policies from the policy wizard, and
also contextual information from the context manager. When goals or prototypes
are modified, the static analyser is notified. This may result in changes to the gen-
erated policies. The policy manager is also asked to query the policy store when
event triggers are received. These arrive from the managed system and are passed
to the policy selector. This chooses relevant policies (i.e. those associated with this
trigger and whose conditions are met). If any triggered policies are derived from
goals, the dynamic analyser is notified. This produces an optimal set of policies
that are submitted to the conflict manager. Conflicts among policy actions are de-
tected and resolved. Finally, a compatible and optimal set of actions is sent via the
policy interface to the managed system.
Policy Wizard: a user-friendly interface for defining and editing goals and policies [11].
Besides the original near-natural language wizard, a second wizard has now been
created using interactive voice response, and a third using digital pen and paper.
Context Manager: an interface for providing additional information about the managed
system (e.g. user availability, schedule or work relationships) [11].
Conflict Analyser: a tool to analyse policies offline for conflict-prone interactions [5].
K.J. Turner and G.A. Campbell / Goals and Conflicts in Telephony 7
Feature Interactions in Software and Communication Systems X, IOS Press, Incorporated, 2009. ProQuest Ebook Central,
Copyright
©
2009.
IOS
Press,
Incorporated.
All
rights
reserved.](https://image.slidesharecdn.com/100615-250414142610-0ef49a6a/85/Feature-Interactions-in-Software-and-Communication-Systems-X-1st-Edition-M-Nakamura-21-320.jpg)
![Ontology Server: a generic interface to ontology-based information about each applica-
tion domain [4]. A domain-specific ontology is used by the policy wizard to define
valid goals and policies, by the offline conflict analyser, and by the goal system
both statically and dynamically.
Goal Server: the heart of the goal system. The static analyser is invoked when goals or
prototypes are added, modified or deleted (see section 2.4). The dynamic analyser
is invoked when goal-derived policies are triggered (see section 2.5).
Although there have been extensions to the ontology server and the policy wizard
for the goal system, there has been little change to the other components. The new work
has mainly been on the goal server. Besides this, the APPEL policy language and the
domain ontologies have been extended to support goal refinement.
2.2. Goals
Currently, all goals must be known locally; future work will handle distributed goals.
A goal is a simplified form of policy. There is no trigger because goals always apply.
A goal may have a (compound) condition that uses general information like time of
day or an environment value. Unlike a policy, a goal has a single action of the form
‘maximise(measure)’ or ‘minimise(measure)’. The measure is a numerical assessment
of how well a goal is achieved. Positive goals aim to maximise their associated measure
(e.g. network use), while negative goals aim to minimise their measure (e.g. call cost).
A goal measure is like a sub-goal, but is defined rather than refined. A measure is
a formula over relevant system variables. Some variables are held per user (or entity),
while others are shared across the system.
Uncontrolled Variables: these are variables that are beyond the control of the policy
system, typically ‘environmental’ factors (e.g. the call cost per second, the fre-
quency of incoming calls).
Controlled Variables: these are variables controlled by the policy system (e.g. the allo-
cated bandwidth, the media used by a call).
Derived Variables: these are pseudo-variables defined in terms of (un)controlled vari-
ables (e.g. the call cost as cents/second × duration).
Goal measures and their associated variables are, of course, domain-dependent.
Since they are often relatively fixed for each domain, it makes sense to define them once
in the domain ontology rather than for each individual goal. A goal definition may there-
fore refer to these definitions as derived variables.
As a concrete example, the definition below gives a goal that minimises call cost.
The elements here are also found in policies. A goal has the following attributes: an iden-
tifier (a unique text string), whether it is enabled (allowing deactivation without deletion),
when it was changed (date and time in XML format), an owner (the user who defined it),
and to whom the goal applies (the stir.com domain here). Two goal conditions are given,
combined with ‘and’: the goal applies only on weekdays (1 = Monday, 5 = Friday) when
the call bandwidth exceeds 128 Kbps. At weekends or for low-bandwidth calls, the goal
does not apply. The goal action is to minimise call cost – a derived variable that calcu-
lates the cost of a call. (XML schema rules require arguments to be given as attributes
arg1, etc.) The following is the XML representation of this goal (omitting the obvious
closing tags for brevity):
K.J. Turner and G.A. Campbell / Goals and Conflicts in Telephony
8
Feature Interactions in Software and Communication Systems X, IOS Press, Incorporated, 2009. ProQuest Ebook Central,
Copyright
©
2009.
IOS
Press,
Incorporated.
All
rights
reserved.](https://image.slidesharecdn.com/100615-250414142610-0ef49a6a/85/Feature-Interactions-in-Software-and-Communication-Systems-X-1st-Edition-M-Nakamura-22-320.jpg)
![telephony, for example, only caller and callee policies are selected (plus those for the
domain they belong to); this substantially reduces the number of eligible policies. Tele-
phony policies are triggered only on call setup, mid-call, or on call clear-down; again,
this significantly cuts down on relevant policies. Finally, telephony policies usually have
conditions (e.g. time of day, who the caller is) that further restrict the selection. Other
domains (e.g. home care, sensor networks) work with similarly reduced sets of policies.
The result is that the dynamic analyser usually has to optimise only a modest set of
policies. For up to a dozen policies, say, the simple exhaustive algorithm is more efficient
than more elaborate algorithms that are best for large optimisation problems. However,
if other application domains lead to the need for optimising large sets of policies, then a
different optimisation algorithm could readily be slotted in.
Optimisation deals with one other aspect: prototype parameters. These are left unin-
stantiated when policies are created from prototypes. At run time, the dynamic anal-
yser considers optimal choices for parameters as well as for policies. Exactly the same
mechanism applies: the choice of parameters modifies the effects and therefore the over-
all evaluation. However, parameters have to be optimised in a different way. Given rea-
sonable restrictions on the evaluation function (monotonicity), only the extremal values
of parameters need be considered. If call bandwidth is a parameter, for example, then
only the minimum and maximum permissible bandwidths should be tried: one or other
will achieve the optimal value. The optimisation also allows for parameters being drawn
from a discrete but ordered set (e.g. audio, whiteboard, video) rather than from a range.
Knowledge about extreme values is domain-specific, and is defined in a domain ontology.
Instantiating the parameters of a policy leads to a new temporary policy that ap-
plies only during processing of the current trigger. This policy is created by copying the
parameterised policy, substituting the optimal parameter values, and giving the policy a
unique identifier.
The selection of policies (and parameters) with the highest evaluation determines the
identifiers returned to the policy server for execution. Typically only a subset of the goal-
derived policies is eligible. The subset is combined with the eligible regular policies and
processed as normal by the policy server. This requires the set of actions dictated by these
policies to be checked for conflict. Resolution policies detect conflicts and determine a
compatible set of actions (e.g. disregarding lower-priority policies) [10].
2.6. Identifying Goal Conflicts
Now that the basis of goal refinement has been explained, it is possible to be precise
about the ways in which goals can conflict with each other. Although these have been
mentioned in passing, they are collected here for reference.
Conflicts do not really arise during static goal analysis (i.e. when goals are defined).
However, it is possible to find that a goal cannot be achieved by any prototype (or can
be only partially satisfied). This happens if prototypes cannot be found to affect all the
controlled variables in a goal measure. This is probably not a conflict, though it reflects an
inconsistency between the goals and the prototypes available to achieve them. However
it is an error, and is reported by the static analyser.
Conflicts do arise during dynamic goal analysis (i.e. when goal-derived policies are
processed). It may be found that certain goal-derived policies cannot be considered in
combination (because they affect system variables inconsistently, or they make exclusive
K.J. Turner and G.A. Campbell / Goals and Conflicts in Telephony
12
Feature Interactions in Software and Communication Systems X, IOS Press, Incorporated, 2009. ProQuest Ebook Central,
Copyright
©
2009.
IOS
Press,
Incorporated.
All
rights
reserved.](https://image.slidesharecdn.com/100615-250414142610-0ef49a6a/85/Feature-Interactions-in-Software-and-Communication-Systems-X-1st-Edition-M-Nakamura-26-320.jpg)
![changes to a system variable). This is a conflict that is resolved by excluding the imper-
missible combinations. It may also be found that different combinations of goal-derived
policies yield the same optimal value. This indicates that the prototypes are too weakly
characterised in their effects and cannot be distinguished. This is a kind of conflict, and
is reported by the dynamic analyser.
Following dynamic goal analysis, the resulting policies may be found to have con-
flicting actions. Although this is part of the standard conflict detection performed by
the policy server, it is a consequence of goal refinement and reflects an indirect conflict
among the goals. The authors have developed a technique and tool for filtering conflict-
prone policies [5]. In future work, this will be adapted to offline analysis of goals and
prototypes as well as policies.
There is an interesting relationship among conflicts found through offline filtering,
through dynamic goal analysis, and through online detection of action conflicts. Essen-
tially all three techniques look for incompatibilities. It is possible to detect the same kinds
of conflicts at all three levels. However, this is not normally desirable because it would
require effects to be considered at a low level of abstraction (i.e. the level of individual
policy actions). Both filtering rules and goal measures should be formulated more ab-
stractly, implying that action conflicts will usually be in addition to the kinds of conflicts
detected at higher levels.
3. Application to Internet Telephony
To illustrate how goals are supported, this section gives concrete examples of how
a hypothetical company might wish to optimise its voice communications. For this
application, the managed system is a softswitch such as SER (SIP Express Router,
www.iptel.org/ser). The XML representation of goals and prototypes was illustrated in
sections 2.2 and 2.3. This section uses pseudo-code for readability (and is similar to the
web-based wizard). Triggers are indicated by when, conditions by if, and actions by do.
3.1. Goals
For the telephony system, suppose that the uncontrolled variables are rate (call cost,
cents/second) and quality (a subjective measure, 1 = poor to 10 = best). The controlled
variables are bandwidth (Kbps), duration (typical call length, seconds), handled (calls
handled by the user, per day), and received (calls received by the user, per day).
The company is presumed to have the communications goals shown in table 1.
This is a subset of a larger set of goals that may deal with other factors such as avail-
ability, reliability, security, etc. The textual descriptions of the goals are high-level and
rather woolly. To make them operational, they need to be related to the system variables.
Whether the company’s goals are appropriately formulated here is not relevant. What is
important is that the interpretation of each goal is made explicit and precise.
Each goal is associated with a numerical measure (network use being split into sub-
measures for bandwidth use and call handling). The goal measures are defined as derived
variables. These are combined into an overall evaluation function that is a weighted sum
of the goal measures, again treating network use as two subsidiary measures. Note that
measures to be minimised are preceded by a minus sign. For a discussion of where the
scaling factors and weights here come from, see section 3.5.
K.J. Turner and G.A. Campbell / Goals and Conflicts in Telephony 13
Feature Interactions in Software and Communication Systems X, IOS Press, Incorporated, 2009. ProQuest Ebook Central,
Copyright
©
2009.
IOS
Press,
Incorporated.
All
rights
reserved.](https://image.slidesharecdn.com/100615-250414142610-0ef49a6a/85/Feature-Interactions-in-Software-and-Communication-Systems-X-1st-Edition-M-Nakamura-27-320.jpg)
Feature Interactions in Software and Communication Systems X 1st Edition M. Nakamura
- 1. Feature Interactions in Software and Communication Systems X 1st Edition M. Nakamura pdf download https://ebookname.com/product/feature-interactions-in-software- and-communication-systems-x-1st-edition-m-nakamura/ Get Instant Ebook Downloads – Browse at https://ebookname.com
- 2. Instant digital products (PDF, ePub, MOBI) available Download now and explore formats that suit you... Developing and Evaluating Security Aware Software Systems 1st Edition Khaled M. Khan https://ebookname.com/product/developing-and-evaluating-security- aware-software-systems-1st-edition-khaled-m-khan/ Culture s Software Communication Styles 1st Edition Dorota Brzozowska https://ebookname.com/product/culture-s-software-communication- styles-1st-edition-dorota-brzozowska/ Digital speech coding for low bit rate communication systems 2nd Edition A. M. Kondoz https://ebookname.com/product/digital-speech-coding-for-low-bit- rate-communication-systems-2nd-edition-a-m-kondoz/ Your Limited Liability Company An Operating Manual 5th edition Anthony Mancuso https://ebookname.com/product/your-limited-liability-company-an- operating-manual-5th-edition-anthony-mancuso/
- 3. Son of a Red Devil 1st Edition Lukemba Gelindo https://ebookname.com/product/son-of-a-red-devil-1st-edition- lukemba-gelindo/ Digital Design and Computer Organization 1st Edition Hassan A. Farhat https://ebookname.com/product/digital-design-and-computer- organization-1st-edition-hassan-a-farhat/ Osteoporosis Pathophysiology and Clinical Management 1st Edition Eric S. Orwoll https://ebookname.com/product/osteoporosis-pathophysiology-and- clinical-management-1st-edition-eric-s-orwoll/ Endovascular Therapy Principles of Peripheral Interventions 1st Edition Michael E. Debakey https://ebookname.com/product/endovascular-therapy-principles-of- peripheral-interventions-1st-edition-michael-e-debakey/ The Cold War and the United States Information Agency American Propaganda and Public Diplomacy 1945 1989 Nicholas John Cull https://ebookname.com/product/the-cold-war-and-the-united-states- information-agency-american-propaganda-and-public- diplomacy-1945-1989-nicholas-john-cull/
- 4. First Aid for the USMLE Step 2 CK First Aid USMLE 6th Edition Tao Le https://ebookname.com/product/first-aid-for-the-usmle-step-2-ck- first-aid-usmle-6th-edition-tao-le/
- 5. FEATURE INTERACTIONS IN SOFTWARE AND COMMUNICATION SYSTEMS X Feature Interactions in Software and Communication Systems X, IOS Press, Incorporated, 2009. ProQuest Ebook Central, Copyright © 2009. IOS Press, Incorporated. All rights reserved.
- 6. Proceedings of the International Workshop on Feature Interactions previously published by IOS Press: Feature Interactions in Software and Communication Systems IX Edited by L. du Bousquet and J.-L. Richier Feature Interactions in Telecommunications and Software Systems VIII Edited by S. Reiff-Marganiec and M.D. Ryan Feature Interactions in Telecommunications and Software Systems VII Edited by D. Amyot and L. Logrippo Feature Interactions in Telecommunications and Software Systems VI Edited by M. Calder and E. Magill Feature Interactions in Telecommunications and Software Systems V Edited by K. Kimbler and L.G. Bouma Feature Interactions in Telecommunication Networks IV Edited by P. Dini, R. Boutaba and L. Logrippo Feature Interactions in Telecommunications III Edited by K.E. Cheng and T. Ohta Feature Interactions in Telecommunications Systems Edited by L.G. Bouma and H. Velthuijsen Feature Interactions in Software and Communication Systems X, IOS Press, Incorporated, 2009. ProQuest Ebook Central, Copyright © 2009. IOS Press, Incorporated. All rights reserved.
- 7. Feature Interactions in Software and Communication Systems X Edited by Masahide Nakamura Department of Computer Science and Systems Engineering, Kobe University, Japan and Stephan Reiff-Marganiec Department of Computer Science, University of Leicester, UK Amsterdam • Berlin • Tokyo • Washington, DC Feature Interactions in Software and Communication Systems X, IOS Press, Incorporated, 2009. ProQuest Ebook Central, Copyright © 2009. IOS Press, Incorporated. All rights reserved.
- 8. © 2009 The authors and IOS Press. All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, without prior written permission from the publisher. ISBN 978-1-60750-014-8 Library of Congress Control Number: 2009927529 Publisher IOS Press BV Nieuwe Hemweg 6B 1013 BG Amsterdam Netherlands fax: +31 20 687 0019 e-mail: order@iospress.nl Distributor in the UK and Ireland Distributor in the USA and Canada Gazelle Books Services Ltd. IOS Press, Inc. White Cross Mills 4502 Rachael Manor Drive Hightown Fairfax, VA 22032 Lancaster LA1 4XS USA United Kingdom fax: +1 703 323 3668 fax: +44 1524 63232 e-mail: iosbooks@iospress.com e-mail: sales@gazellebooks.co.uk LEGAL NOTICE The publisher is not responsible for the use which might be made of the following information. PRINTED IN THE NETHERLANDS Feature Interactions in Software and Communication Systems X, IOS Press, Incorporated, 2009. ProQuest Ebook Central, Copyright © 2009. IOS Press, Incorporated. All rights reserved.
- 9. Preface Welcome to the Tenth International Conference on Feature Interactions in Telecom- munications and Software Systems (ICFI2009), which is held in Lisbon, Portugal, 11–12 June 2009. The first event of this kind was a workshop held in St. Petersburg, Florida, in 1992. This was a true workshop, with invited talks, short papers, and fo- cused discussions; no formal proceedings were published. The concept rapidly matured into a series of international workshops and conferences held in North America, Europe, and Japan. Features are additional services or optional add-ons to a basic system. They began to be studied in the 1990s when they arose in the telecommunications domain: at that time, major telephony providers were adding services like “call forwarding” and “ring back when free” to their basic telephone service. Features occur whenever organiza- tions compete by differentiating their products from those of rival organizations. They also occur when products are upgraded. New software releases are typically described in terms of the features added (and the bugs fixed!) since the last release. Unfortunately, adding one feature may break another, or interfere with it in an undesired way. This phenomenon is called feature interaction. “Feature interference” would have been a better term, since interactions can be good as well as bad, but the term “feature interac- tion” has stuck – in the global community. This series of workshops is devoted to exploring ways in which the feature interac- tion problem may be mitigated. This may be done in several ways: • by developing new methods for designing and producing software, which support the introduction of features in a safe and understood way; • by developing tools and techniques for detecting feature interactions once fea- tures have been introduced, but before the software is released (this is called off-line detection); • by developing methods for managing feature interactions when they occur in live systems (this is called on-line detection and resolution). The conference aims to bring together representatives of the telecommunications industry, the software industry, and the research community working on all aspects of feature interactions in order to discuss possible solutions and their practical applica- tions, as well as setting directions for further research. The Programme for the conference includes two invited papers from speakers who were chosen because of their excellent contributions to fields which are related to but outside of feature interaction. Additionally, there are 14 full papers and 7 short papers. Each paper received at least three reviews from members of the Programme Committee. All submitted papers where well in the scope of the conference. Even for papers with weaker evaluation, the Programme Committee positively accepted them as work-in- progress papers. This allows people new to the field in emerging areas to become members of the community. Also it allows the community to continue to have this event and see it as a productive discussion forum for the future. Feature Interactions in Software and Communication Systems X M. Nakamura and S. Reiff-Marganiec (Eds.) IOS Press, 2009 © 2009 The authors and IOS Press. All rights reserved. v Feature Interactions in Software and Communication Systems X, IOS Press, Incorporated, 2009. ProQuest Ebook Central, Copyright © 2009. IOS Press, Incorporated. All rights reserved.
- 10. ICFI2009 is held in conjunction with the Distributed Computing Techniques 2009 (DisCoTec’09), a major cluster of conferences sponsored by IFIP. The collocation with a large conference is the first experience in the ICFI history. We are happy to have such a great opportunity to realize cultural exchange with people in other communities. Acknowledgments: We are grateful to all the authors who have submitted to ICFI, the invited speakers and the panelists for taking part. We thank the Programme Com- mittee for producing thorough reviews to short timescales. Thanks are also due to Prof. António Ravara, Technical University of Lisbon, and Prof. Elie Najm, ENST, for their invaluable support for the collocation with DisCoTec’09. Masahide Nakamura & Stephan Reiff-Marganiec April 2009 vi Feature Interactions in Software and Communication Systems X, IOS Press, Incorporated, 2009. ProQuest Ebook Central, Copyright © 2009. IOS Press, Incorporated. All rights reserved.
- 11. Programme Committee Co-Chairs Masahide Nakamura Kobe University, Japan Stephan Reiff-Marganiec University of Leicester, UK Members Daniel Amyot University of Ottawa, Canada Lydie du Bousquet University Joseph Fourier, Grenoble, France Jan Bredereke University of Applied Sciences Bremen, Germany Rui Crespo Technical University of Lisbon, Portugal Tom Gray PineTel, Canada Jean-Charles Grègoire CNRS-Telecommunications, Canada Gang Huang Peking University, China Hiroshi Igaki Kobe University, Japan Mario Kolberg University of Stirling, UK Wu-Hon Francis Leung Illinois Institute of Technology, USA Fuchun Joseph Lin Telcordia Technologies, USA Luigi Logrippo Universite du Qubec en Outaouais, Canada Evan Magill University of Stirling, UK Andreas Metzger University of Duisburg-Essen, Germany Tadashi Ohta Soka University, Tokyo, Japan Jean-Luc Richier CNRS, LIG, France Mark Ryan University of Birmingham, UK Pierre-Yves Schobbens University of Namur, Belgium Ken Turner University of Stirling, UK Michael Weiss Carleton University, Canada Pamela Zave AT&T, USA vii Feature Interactions in Software and Communication Systems X, IOS Press, Incorporated, 2009. ProQuest Ebook Central, Copyright © 2009. IOS Press, Incorporated. All rights reserved.
- 12. This page intentionally left blank Feature Interactions in Software and Communication Systems X, IOS Press, Incorporated, 2009. ProQuest Ebook Central, Copyright © 2009. IOS Press, Incorporated. All rights reserved.
- 13. Contents Preface v Masahide Nakamura and Stephan Reiff-Marganiec Programme Committee vii FI Detection in Telephony Goals and Conflicts in Telephony 3 Kenneth J. Turner and Gavin A. Campbell Online Detection of Feature Interactions of CPL Services 19 Lixiang Wang, Jiuyun Xu and Stephan Reiff-Marganiec Feature Interaction Detection in the Feature Language Extensions 34 Lei Sun, Lu Zhoa, Yimeng Li and Wu-Hon F. Leung IMS Service Broker Feasibility Study in 3GPP Release 8 (Industrial Report) 42 Fuchun Joseph Lin and Raquel Morera Feature Interaction Testing: An Industrial Perspective (Industrial Report) 50 Jameleddine Hassine Software Engineering Approach to FI Detecting Policy Conflicts by Model Checking UML State Machines 59 Maurice H. ter Beek, Stefania Gnesi, Carlo Montangero and Laura Semini Feature Interactions in Aspect-Oriented Scenario Models 75 Gunter Mussbacher, Daniel Amyot, Thomas Weigert and Thomas Cottenier Feature Interactions in a Software Product Line for E-Voting 91 J. Paul Gibson, Eric Lallet and Jean-Luc Raffy Feature Diagrams for Change-Oriented Programming 107 Peter Ebraert, Andreas Classen, Patrick Heymans and Theo D’Hondt Feature Interactions in Object-Oriented Effect Systems from a Viewpoint of Program Comprehension ((W) work-in-progress paper) 123 Izuru Kume and Etsuya Shibayama FI in New and Challenging Domains Feature Interaction as a Context Sharing Problem 133 Armstrong Nhlabatsi, Robin Laney and Bashar Nuseibeh Software Security Vulnerabilities Seen as Feature Interactions 149 Guy-Vincent Jourdan ix Feature Interactions in Software and Communication Systems X, IOS Press, Incorporated, 2009. ProQuest Ebook Central, Copyright © 2009. IOS Press, Incorporated. All rights reserved.
- 14. Interactions Among Secrecy Models (Work-in-Progress Paper) 160 Waël Hassan and Luigi Logrippo Problem-Solution Feature Interactions as Configuration Knowledge in Distributed Runtime Adaptations 166 Frans Sanen, Eddy Truyen and Wouter Joosen Semantic-Based Aspect Interaction Detection with Goal Models (Position Paper) 176 Gunter Mussbacher, Daniel Amyot and Jon Whittle Service Interaction Research in Emerging IEEE NGSON Standards (Industrial Report) 183 Fuchun Joseph Lin FI in Ubiquitous and Service-Oriented Systems Considering Online Feature Interaction Detection and Resolution for Integrated Services in Home Network System 191 Masahide Nakamura, Hiroshi Igaki, Yuhei Yoshimura and Kousuke Ikegami Service Specification and Validation in the Context of the Home 207 Lydie du Bousquet, Ajitha Rajan, Catherine Oriat, Jean-Luc Richier and German Vega Formal Analysis of Smart Home Policies Using Compositional Verification 220 Narges Khakpour, Marjan Sirjani and Saeed Jalili Feature Interaction Problems in Web-Based Service Composition (Position Paper) 234 Qi Zhao, Jiyu Huang, Xiangping Chen and Gang Huang Web Services Feature Interaction Detection Based on Graph Transformation. A New Interaction Detection Method (Work-in-Progress Paper) 242 Huili Xuan and Jiuyun Xu Subject Index 251 Author Index 253 x Feature Interactions in Software and Communication Systems X, IOS Press, Incorporated, 2009. ProQuest Ebook Central, Copyright © 2009. IOS Press, Incorporated. All rights reserved.
- 15. FI Detection in Telephony Feature Interactions in Software and Communication Systems X, IOS Press, Incorporated, 2009. ProQuest Ebook Central, Copyright © 2009. IOS Press, Incorporated. All rights reserved.
- 16. This page intentionally left blank Feature Interactions in Software and Communication Systems X, IOS Press, Incorporated, 2009. ProQuest Ebook Central, Copyright © 2009. IOS Press, Incorporated. All rights reserved.
- 17. Goals and Conflicts in Telephony Kenneth J. Turner and Gavin A. Campbell Computing Science and Mathematics, University of Stirling, Stirling FK9 4LA, UK e-mail: kjt | gca @cs.stir.ac.uk Abstract. Goals are abstract, user-oriented objectives for how a system should behave. To be made operational, they are refined into lower-level policies that are executed dy- namically. It is explained how previous work on policy-based management has been enhanced with a separate goal system that allows goals to be specified, analysed, refined, and achieved. It is shown how conflicts can arise at several levels among goals, and how these conflicts are detected and handled. Although the approach is general, it is illustrated through an application to Internet telephony. Keywords. Call Control, Goal, Goal Conflict, Goal Refinement, Policy-Based Management 1. Introduction Goals are introduced as a high-level, abstract way for users to define system objectives in a non-technical manner. The concept of goal refinement is explained. In contrast to other work, which relies on static logical analysis, the approach here views refinement as a dynamic optimisation task. 1.1. Background The trend in communications is for people to be always contactable – in the office, at home, or on the move. As a result, there is an increasing need for users to be able to man- age their communications flexibly. Traditional telephony features are network-centric, being designed by the network operator and supported in network equipment. Internet telephony is becoming increasingly widespread. Following Internet philosophy, func- tionality tends to be located at the edges of the network. In particular, this means that customisation of call handling can be placed much more in the hands of end users. The authors and their colleagues have exploited this trend by developing a policy- based management system for Internet telephony (e.g. [11]). Policies operate at a higher level than features, and offer many advantages such as orientation towards user needs, flexibility, and customisability. A system called ACCENT (Advanced Component Con- trol Enhancing Network Technologies, www.cs.stir.ac.uk/accent) has been developed for supporting policy-based management. The ACCENT system was designed for end users, e.g. policies are formulated through a wizard rather than requiring programming or de- tailed technical knowledge. Although initially developed for Internet telephony, the ap- proach is general and has now been extended to other applications such as managing sensor networks, wind farms and home care systems. Feature Interactions in Software and Communication Systems X M. Nakamura and S. Reiff-Marganiec (Eds.) IOS Press, 2009 © 2009 The authors and IOS Press. All rights reserved. doi:10.3233/978-1-60750-014-8-3 3 Feature Interactions in Software and Communication Systems X, IOS Press, Incorporated, 2009. ProQuest Ebook Central, Copyright © 2009. IOS Press, Incorporated. All rights reserved.
- 18. Although policies are higher-level and more user-oriented than features, they are still relatively imperative. What is required is a more abstract way for users to formulate their needs. This has now been achieved through the design and implementation of a goal system. Goals are persistent, abstract, user-oriented objectives for how a system should behave. They are declarative statements of what is required, not operational statements of how they should be achieved. In fact, they are sufficiently abstract that they cannot be realised directly. A process of refinement is needed to map the goals onto lower-level policies that can then be used to achieve them. The work in this paper describes how goals are specified and statically analysed to create policies that realise them. Offline analysis is also concerned with appropriate definition of goals. Support at run time is provided to choose the most relevant policies according to the dynamically changing state of the system. The approach allows users to define high-level goals for how the system should behave (e.g. how calls are handled). The details of how goals are achieved can be largely hidden from the users. Feature interaction is a long-known phenomenon in telephony. The authors and their colleagues have investigated policy conflict as the higher-level equivalent in policy-based systems [10]. The new work reported here has raised the approach to a more abstract level. Not surprisingly, conflicts also arise with the use of goals. As will be seen, such conflicts manifest themselves at several levels. 1.2. Goals and Policies for System Management Goals have a venerable history in artificial intelligence, where they are often used to define desired states of a system. Goals are typically used by a planning system to build sequences of actions that achieve them. A similar approach has been adopted in agent- based systems. Goals in the context of policy-based management have received little study. Here, the notion of a goal is an objective for system behaviour. Refinement of goals into policies is typically treated through logic: policies are identified to meet the goals through a process of logical entailment. This is essentially a static (offline) analysis. In the work reported here, goal refinement is viewed as a numerical optimisation problem. The main advantage is that goals can be supported in a fully dynamic way: as the system and its environment change, the policies that achieve goals are automatically evolved to give the best match to current circumstances. In the formulation adopted, goals are associated with numerical measures (e.g. ‘call cost’ or ‘multimedia use’) for how well they are achieved. In general, such measures are maximised (positive goals) or minimised (negative goals). Goal measures are arbi- trary functions over system variables, though for practical and technical reasons they are normally weighted sums. Since there are usually multiple (often conflicting) goals, their measures are combined into an overall evaluation function that assesses how well a candidate set of policies meets the full set of goals. The evaluation function is again an arbitrary formula, though normally a weighted sum of goal measures. Goals are sufficiently high level that they cannot be used directly. Instead, goals are realised through prototype policies (prototypes for short) that contribute to them. These prototypes form a library of ‘building blocks’ for accomplishing goals. When goals are first defined, they are statically analysed against the available prototypes. This identifies the prototypes that may contribute towards each goal. However, the actual selection is de- K.J. Turner and G.A. Campbell / Goals and Conflicts in Telephony 4 . Feature Interactions in Software and Communication Systems X, IOS Press, Incorporated, 2009. ProQuest Ebook Central, Copyright © 2009. IOS Press, Incorporated. All rights reserved.
- 19. ferred until run-time since the most appropriate policies are likely to depend on the actual circumstances (e.g. the current bandwidth or the cost of a call). Prototypes are therefore selected and instantiated dynamically as normal policies. In addition, prototypes may have parameters that are dynamically optimised. The benefit of this approach is that the existing ACCENT policy server is barely affected by the new goal system. As far as the policy server is concerned, it handles policies as usual (except that some policies derive from goals). Other mechanisms such as handling policy conflicts at run time can therefore operate as normal. Policies are written in APPEL (Adaptable and Programmable Policy Environment and Language, www.cs.stir.ac.uk/appel). This is designed to be extensible for new appli- cation domains. The core policy language has extensions for regular policies and resolu- tion policies. In turn, these are specialised for each domain: call control is currently one of several rather different applications. Since policies are internally XML, extensibility is achieved by defining APPEL through a hierarchy of schemas that build on each other. Although these schemas define the formal structure of APPEL, this is not sufficient. The schemas are therefore supplemented by ontologies that define the concepts and re- lationships in each application domain. Again this is hierarchical, with a core ontology that is extended for each application. For the work reported here, the schemas and ontologies have been extended to sup- port goals and prototypes. The latter are intentionally defined in a very similar way to policies (both regular and resolution policies). This gives a consistent structure to the language, and also allows common software support throughout all system components. 1.3. Related Work Planning in artificial intelligence goes back about 40 years (e.g. the STRIPS system). Much more recent is work on agent-based systems. As an example, 3APL (Agent Pro- gramming Language, www.cs.uu.nl/3apl) defines goals and beliefs. Plan revision rules allow plans to be created from predefined rules, using actions from an action base to achieve goals. In agent-based approaches, goals are achieved through planning using var- ious kinds of agents (goal-based, logical, knowledge-based). Goals have also been ad- dressed in requirements engineering. Systems such as KAOS (originally Knowledge Ac- quisition in autOmated Specification [12]) aim to build a formal proof that the require- ments derived for a system meet its goals. Goals in a policy context are interpreted rather differently. The notion of a policy hierarchy was first identified in [8]. This led to the idea of refining higher-lever policies into lower-level ones. [6] extended this notion into a continuum of policies, with goals being policies at the highest level; however, this is currently just a framework without a concrete implementation. A formal approach to goal refinement using Event Calculus is described in [3]. This has been implemented using KAOS, with refinement patterns being used to decompose goals into subgoals. As another formal approach, [9] uses temporal logic in a two-stage refinement process from goals to subgoals, and subgoals to policies. In the context of feature interaction, [7] identified the problem of goal conflict in telephony. This approach uses agents to negotiate a plan on behalf of end users to avoid conflicts. This is a different kind of problem from the one tackled in this paper. The User Requirements Notation for goals [2] complements the current paper, and will be studied for possible synergy in future. Fuzzy policies with weights [1] are reminiscent of the nu- K.J. Turner and G.A. Campbell / Goals and Conflicts in Telephony 5 Feature Interactions in Software and Communication Systems X, IOS Press, Incorporated, 2009. ProQuest Ebook Central, Copyright © 2009. IOS Press, Incorporated. All rights reserved.
- 20. merical approach taken here. Although the work reported in this paper has concentrated on goal refinement as a practical technique, issues of goal conflict have inevitably arisen. These can be regarded as a high-level form of feature interaction. The related notion of policy conflict has been investigated in [10]. As will be seen, goal conflicts arise at various levels as the goals are achieved through refinement and execution. The work in this paper differs in a number of important respects from other ap- proaches. Although some offline analysis is performed, the bulk of the analysis happens at run time. This is intentional as the choice of policies should depend on the prevail- ing circumstances. Virtually all other work uses offline techniques, and hence cannot anticipate changes in the system environment. The approach is based on numerical rather than logical reasoning. This is more flex- ible in that it does not require any absolute notion of fulfilling goals. Rather, it is possible to satisfy goals only as far as is possible (which may be the only practical possibility). Nearly all other approaches are based on strict logic. A pragmatic rather than a theoretical approach is followed. Requiring use of formal methods is a considerable barrier for most engineers and designers, and is inappropriate for end users. The need to perform goal refinement at run time is a particular challenge, since most formal techniques require considerable computation. Almost all other goal refinement techniques are formal. 1.4. Paper Outline Section 2 discusses the goal system architecture, how goals and prototypes are formu- lated, and the kinds of analysis that are performed to realise goals through policies. In particular, the nature of goal conflict is investigated. Section 3 illustrates the ideas through their application to telephony. Section 4 summarises the approach, and indicates that it has been applied in other application domains. 2. The Goal System APPEL has been extended to define goals and prototypes. Goal refinement has also been implemented in a package called OGRE (Optimising Goal Refinement Engine). The new goal capabilities have required only small changes in the existing policy system. 2.1. System Architecture The overall system architecture to support goals and policies is shown in figure 1. For historical reasons, and because the system primarily deals with policies, a number of components are labelled ‘Policy’. However, apart from regular policies, the system also deals with goals, prototypes, resolution policies (that deal with conflicts), and variables (that may be used in goals and policies). The major system components communicate via socket connections (shown as grey arrows in the figure). This gives flexibility in distributing them across processors, though they may all run on one physical machine. The system components have the following functions: Managed System: the system under control, e.g. a softswitch in Internet telephony [11]. Policy Store: an XML database that stores information about goals and policies [11]. K.J. Turner and G.A. Campbell / Goals and Conflicts in Telephony 6 Feature Interactions in Software and Communication Systems X, IOS Press, Incorporated, 2009. ProQuest Ebook Central, Copyright © 2009. IOS Press, Incorporated. All rights reserved.
- 21. Policy Server Static Analyser Dynamic Analyser Ontology Server Policy Manager Policy Interface Policy Store Managed System Policy Wizard Policy Selector Conflict Manager Context Manager End User System Admin Conflict Analyser Goal Server Figure 1. System Architecture Policy Server: the heart of the policy system [11]. The policy manager is the interface to the policy store, isolating the rest of the system from the particular choice of database. It receives new or updated goals and policies from the policy wizard, and also contextual information from the context manager. When goals or prototypes are modified, the static analyser is notified. This may result in changes to the gen- erated policies. The policy manager is also asked to query the policy store when event triggers are received. These arrive from the managed system and are passed to the policy selector. This chooses relevant policies (i.e. those associated with this trigger and whose conditions are met). If any triggered policies are derived from goals, the dynamic analyser is notified. This produces an optimal set of policies that are submitted to the conflict manager. Conflicts among policy actions are de- tected and resolved. Finally, a compatible and optimal set of actions is sent via the policy interface to the managed system. Policy Wizard: a user-friendly interface for defining and editing goals and policies [11]. Besides the original near-natural language wizard, a second wizard has now been created using interactive voice response, and a third using digital pen and paper. Context Manager: an interface for providing additional information about the managed system (e.g. user availability, schedule or work relationships) [11]. Conflict Analyser: a tool to analyse policies offline for conflict-prone interactions [5]. K.J. Turner and G.A. Campbell / Goals and Conflicts in Telephony 7 Feature Interactions in Software and Communication Systems X, IOS Press, Incorporated, 2009. ProQuest Ebook Central, Copyright © 2009. IOS Press, Incorporated. All rights reserved.
- 22. Ontology Server: a generic interface to ontology-based information about each applica- tion domain [4]. A domain-specific ontology is used by the policy wizard to define valid goals and policies, by the offline conflict analyser, and by the goal system both statically and dynamically. Goal Server: the heart of the goal system. The static analyser is invoked when goals or prototypes are added, modified or deleted (see section 2.4). The dynamic analyser is invoked when goal-derived policies are triggered (see section 2.5). Although there have been extensions to the ontology server and the policy wizard for the goal system, there has been little change to the other components. The new work has mainly been on the goal server. Besides this, the APPEL policy language and the domain ontologies have been extended to support goal refinement. 2.2. Goals Currently, all goals must be known locally; future work will handle distributed goals. A goal is a simplified form of policy. There is no trigger because goals always apply. A goal may have a (compound) condition that uses general information like time of day or an environment value. Unlike a policy, a goal has a single action of the form ‘maximise(measure)’ or ‘minimise(measure)’. The measure is a numerical assessment of how well a goal is achieved. Positive goals aim to maximise their associated measure (e.g. network use), while negative goals aim to minimise their measure (e.g. call cost). A goal measure is like a sub-goal, but is defined rather than refined. A measure is a formula over relevant system variables. Some variables are held per user (or entity), while others are shared across the system. Uncontrolled Variables: these are variables that are beyond the control of the policy system, typically ‘environmental’ factors (e.g. the call cost per second, the fre- quency of incoming calls). Controlled Variables: these are variables controlled by the policy system (e.g. the allo- cated bandwidth, the media used by a call). Derived Variables: these are pseudo-variables defined in terms of (un)controlled vari- ables (e.g. the call cost as cents/second × duration). Goal measures and their associated variables are, of course, domain-dependent. Since they are often relatively fixed for each domain, it makes sense to define them once in the domain ontology rather than for each individual goal. A goal definition may there- fore refer to these definitions as derived variables. As a concrete example, the definition below gives a goal that minimises call cost. The elements here are also found in policies. A goal has the following attributes: an iden- tifier (a unique text string), whether it is enabled (allowing deactivation without deletion), when it was changed (date and time in XML format), an owner (the user who defined it), and to whom the goal applies (the stir.com domain here). Two goal conditions are given, combined with ‘and’: the goal applies only on weekdays (1 = Monday, 5 = Friday) when the call bandwidth exceeds 128 Kbps. At weekends or for low-bandwidth calls, the goal does not apply. The goal action is to minimise call cost – a derived variable that calcu- lates the cost of a call. (XML schema rules require arguments to be given as attributes arg1, etc.) The following is the XML representation of this goal (omitting the obvious closing tags for brevity): K.J. Turner and G.A. Campbell / Goals and Conflicts in Telephony 8 Feature Interactions in Software and Communication Systems X, IOS Press, Incorporated, 2009. ProQuest Ebook Central, Copyright © 2009. IOS Press, Incorporated. All rights reserved.
- 23. <goal id= Minimise call cost enabled= true changed= 2009-01-03T17:18:00 owner= admin@stir.com applies to= @stir.com policy rule conditions and/ condition parameterday operatorin value1..5 condition parameterbandwidth operatorgt value128 action arg1= call cost minimise(arg1) 2.3. Prototypes Goals are not achievable directly as they are abstract. Instead they are realised through sets of policies. Regular policies can contribute to goals. However, the need to manage goal-related policies leads to defining special prototype policies. These are very similar to regular policies, but are considered separately by the goal system: only prototypes are considered in goal refinement. This gives flexibility in that the policy system may use regular policies only, prototype policies only, or (typically) a combination of both. Prototypes have an effect attribute that defines how they modify one or more system variables (and thus how they contribute to goal measures). At definition time, this is used to identify the relationships between goals and prototypes. At run time, this is used to determine the set of policies that optimally satisfy the goals. Prototypes are also allowed to have parameters (prefixed by ‘$’) that are chosen at run time by the goal system. The effect of a prototype is an abstraction of the actions it can perform. More specif- ically, an effect is defined in the same terms as a goal measure (both being described by a domain ontology). As an example, adding video to a call has several effects: increasing bandwidth, potentially increasing cost, decreasing privacy, etc. Which of these effects needs to be stated depends on what a domain expert defines as important to goals. For example, bandwidth and cost may be considered significant, but privacy (in the context of company communications) may not. An individual effect names a system variable, an operator, and an expression (e.g. ‘call bandwidth += 128’). The basic operators are ‘=’ (to set a variable), ‘+=’ (to increase it) or ‘-=’ (to reduce it). These are the operators that have been found most useful, though others would be possible (e.g. ‘*=’, ‘/=’). An interesting situation arises when the effects of multiple prototypes on a goal are considered. Most effects are independent and can be combined (e.g. adding video increases bandwidth, as does adding a digital whiteboard). However, some effects can be permitted only once per execution. For example, forwarding calls reduces the number of calls received, as does rejecting personal calls. If both of these were allowed to contribute to a goal, the number of calls received would be incorrectly reduced twice. There are therefore special ‘exclusive’ forms of the operators: ‘+~’ and ‘-~’. The validity of a set of prototypes is checked against a goal. If their effects are in conflict, that particular combination is not allowed. For example, two prototypes may not fix the same system variable in the same execution. Equally, a prototype making an exclusive change to a system variable (e.g. ‘+~’) is incompatible with any other prototype that affects the same variable. These conflicts are automatically detected by the goal system and are handled by excluding these combinations. As a concrete example, the definition below gives a parameterised prototype that manages call duration. The elements here are also found in policies. The effect of the K.J. Turner and G.A. Campbell / Goals and Conflicts in Telephony 9 Feature Interactions in Software and Communication Systems X, IOS Press, Incorporated, 2009. ProQuest Ebook Central, Copyright © 2009. IOS Press, Incorporated. All rights reserved.
- 24. policy is to limit call duration to the value of the duration parameter. Three policy rules are tried in sequence until one with a matching trigger is found. On initial connection, a call timer is started with length duration. On disconnection, the timer is stopped. When the timer expires, the call is forcibly disconnected. prototype id= Call duration enabled= true changed= 2009-01-03T17:18:00 owner= admin@stir.com applies to= @stir.com effect= duration = $duration policy rules sequential/ policy rule triggerconnect action arg1= call timer arg2= $duration start timer(arg1,arg2) policy rules sequential/ policy rule triggerdisconnect action arg1= call timer stop timer(arg1) policy rule trigger arg1= call timer timer expiry(arg1) actiondisconnect 2.4. Static Analysis Static analysis in the goal system is activated when a goal or prototype is created, mod- ified or deleted. The policy server informs the static analyser of the relevant identifier. When a new goal is defined, the static analyser retrieves existing prototypes and evaluates their effects against the goal measure. (A new prototype is analysed similarly.) Whether a prototype contributes to a goal is determined by comparing its effects with how the goal measure is defined (i.e. which system variables it uses). A prototype is considered to contribute to a goal if it affects one or more system variables involved in the measure. The prototype effect may modify an arbitrarily complex measure. The sense of the effect will therefore not be known until run time, when it may worsen or improve the evaluation of including this prototype. For each prototype, a set of the goals it contributes to is created. This makes use of information in a domain-specific ontology about system variables. Typically a prototype contributes to one or more goals. If this set is empty because there are no relevant goals, this is not an error. A library of useful prototypes is normally created by a domain expert. When goals are defined, only some prototypes may be relevant. But as future goals may require other prototypes, they are all appropriate. The prototype is then instantiated as a regular policy. This is a copy of the prototype, with the prototype tag replaced by policy, and with a unique new identifier de- rived from the original one. To the rest of the policy system, this generated policy looks like any other. The policy server will therefore apply the policy at run time exactly as normal. However, it is necessary to identify such policies through a supports goal at- tribute that only goal-derived policies carry. This allows the static analyser to deal with modification or deletion of a goal or prototype: the policies generated from these may need to be altered with regard to the goals they support, or may need to be deleted if these goals no longer exist. K.J. Turner and G.A. Campbell / Goals and Conflicts in Telephony 10 Feature Interactions in Software and Communication Systems X, IOS Press, Incorporated, 2009. ProQuest Ebook Central, Copyright © 2009. IOS Press, Incorporated. All rights reserved.
- 25. Prototype and goal conditions are normally copied into a policy in a form such as: prototype condition and (goal condition 1 or goal condition 2). This ensures that the generated policy will be triggered only if the prototype conditions are satisfied and also the associated goal conditions. Some goals that a prototype contributes to may not have conditions; these have conditions that are implicitly true. Absence of a goal condition therefore means that the whole set of goal conditions will always hold. In such a case, the goal conditions are not added to the prototype as they are superfluous. When a prototype is instantiated as a policy, it retains any prototype parameters. These become relevant only during dynamic analysis. 2.5. Dynamic Analysis Dynamic analysis in the goal system is activated when an event trigger leads to a set of policies, i.e. those whose triggers match the event and whose conditions are satis- fied. This set may contain goal-derived policies (identified through their supports goal attribute). If no policies are goal-derived, the policy server continues policy execution as normal. However if there are such policies, their identifiers are sent to the dynamic analyser. The dynamic analyser now chooses the subset of these policies that optimises the overall goal evaluation function. This function can refer to any system variables, includ- ing those that vary dynamically (such as the current call bandwidth or the number of calls received so far). This means that the most appropriate set of policies can be selected for the current circumstances. It also means that the selection of policies may vary as the system evolves over time. For example, if the system load increases significantly or the call cost changes on entering a different time period, the goal system will automatically adapt to the changed circumstances. The dynamic approach is much more flexible than the offline, logic-based techniques used in most other approaches. At this point, any optimisation algorithm can be used (e.g. hill-climbing, the simplex algorithm, a genetic algorithm). In optimisation terminology, the evaluation function is the objective or fitness function. The goal system is designed to use any optimisation algorithm that conforms to a defined interface. It is possible during optimisation to discover that more than one combination of poli- cies leads to the same optimal value. Typically this happens when two prototypes have exactly the same exclusive effect: choosing either gives the same numerical evaluation. In fact this is a kind of conflict, and the dynamic analysis reports it as a probable error. A more subtle issue is when the optimal solution is unique, but a number of near-optimal solutions are also available. This is considered further in section 3.5. Currently, and for practical reasons, a simple optimisation algorithm is used: the overall evaluation function is calculated for all possible combinations of policies. This algorithm is exponential in the number of policies, and so is impracticable if there are many policies. However, in practice this has not been found to be a problem. The pol- icy system can handle hundreds or thousands of policies. Even if these are all derived from goals, that is not in itself problematic. What matters is how many such policies are triggered at the same time. From the potentially large number of policies, triggering typically selects only about half a dozen policies. This happens because eligible policies must be for the relevant user (or entity), must have a matching trigger, and must have satisfied conditions. In K.J. Turner and G.A. Campbell / Goals and Conflicts in Telephony 11 Feature Interactions in Software and Communication Systems X, IOS Press, Incorporated, 2009. ProQuest Ebook Central, Copyright © 2009. IOS Press, Incorporated. All rights reserved.
- 26. telephony, for example, only caller and callee policies are selected (plus those for the domain they belong to); this substantially reduces the number of eligible policies. Tele- phony policies are triggered only on call setup, mid-call, or on call clear-down; again, this significantly cuts down on relevant policies. Finally, telephony policies usually have conditions (e.g. time of day, who the caller is) that further restrict the selection. Other domains (e.g. home care, sensor networks) work with similarly reduced sets of policies. The result is that the dynamic analyser usually has to optimise only a modest set of policies. For up to a dozen policies, say, the simple exhaustive algorithm is more efficient than more elaborate algorithms that are best for large optimisation problems. However, if other application domains lead to the need for optimising large sets of policies, then a different optimisation algorithm could readily be slotted in. Optimisation deals with one other aspect: prototype parameters. These are left unin- stantiated when policies are created from prototypes. At run time, the dynamic anal- yser considers optimal choices for parameters as well as for policies. Exactly the same mechanism applies: the choice of parameters modifies the effects and therefore the over- all evaluation. However, parameters have to be optimised in a different way. Given rea- sonable restrictions on the evaluation function (monotonicity), only the extremal values of parameters need be considered. If call bandwidth is a parameter, for example, then only the minimum and maximum permissible bandwidths should be tried: one or other will achieve the optimal value. The optimisation also allows for parameters being drawn from a discrete but ordered set (e.g. audio, whiteboard, video) rather than from a range. Knowledge about extreme values is domain-specific, and is defined in a domain ontology. Instantiating the parameters of a policy leads to a new temporary policy that ap- plies only during processing of the current trigger. This policy is created by copying the parameterised policy, substituting the optimal parameter values, and giving the policy a unique identifier. The selection of policies (and parameters) with the highest evaluation determines the identifiers returned to the policy server for execution. Typically only a subset of the goal- derived policies is eligible. The subset is combined with the eligible regular policies and processed as normal by the policy server. This requires the set of actions dictated by these policies to be checked for conflict. Resolution policies detect conflicts and determine a compatible set of actions (e.g. disregarding lower-priority policies) [10]. 2.6. Identifying Goal Conflicts Now that the basis of goal refinement has been explained, it is possible to be precise about the ways in which goals can conflict with each other. Although these have been mentioned in passing, they are collected here for reference. Conflicts do not really arise during static goal analysis (i.e. when goals are defined). However, it is possible to find that a goal cannot be achieved by any prototype (or can be only partially satisfied). This happens if prototypes cannot be found to affect all the controlled variables in a goal measure. This is probably not a conflict, though it reflects an inconsistency between the goals and the prototypes available to achieve them. However it is an error, and is reported by the static analyser. Conflicts do arise during dynamic goal analysis (i.e. when goal-derived policies are processed). It may be found that certain goal-derived policies cannot be considered in combination (because they affect system variables inconsistently, or they make exclusive K.J. Turner and G.A. Campbell / Goals and Conflicts in Telephony 12 Feature Interactions in Software and Communication Systems X, IOS Press, Incorporated, 2009. ProQuest Ebook Central, Copyright © 2009. IOS Press, Incorporated. All rights reserved.
- 27. changes to a system variable). This is a conflict that is resolved by excluding the imper- missible combinations. It may also be found that different combinations of goal-derived policies yield the same optimal value. This indicates that the prototypes are too weakly characterised in their effects and cannot be distinguished. This is a kind of conflict, and is reported by the dynamic analyser. Following dynamic goal analysis, the resulting policies may be found to have con- flicting actions. Although this is part of the standard conflict detection performed by the policy server, it is a consequence of goal refinement and reflects an indirect conflict among the goals. The authors have developed a technique and tool for filtering conflict- prone policies [5]. In future work, this will be adapted to offline analysis of goals and prototypes as well as policies. There is an interesting relationship among conflicts found through offline filtering, through dynamic goal analysis, and through online detection of action conflicts. Essen- tially all three techniques look for incompatibilities. It is possible to detect the same kinds of conflicts at all three levels. However, this is not normally desirable because it would require effects to be considered at a low level of abstraction (i.e. the level of individual policy actions). Both filtering rules and goal measures should be formulated more ab- stractly, implying that action conflicts will usually be in addition to the kinds of conflicts detected at higher levels. 3. Application to Internet Telephony To illustrate how goals are supported, this section gives concrete examples of how a hypothetical company might wish to optimise its voice communications. For this application, the managed system is a softswitch such as SER (SIP Express Router, www.iptel.org/ser). The XML representation of goals and prototypes was illustrated in sections 2.2 and 2.3. This section uses pseudo-code for readability (and is similar to the web-based wizard). Triggers are indicated by when, conditions by if, and actions by do. 3.1. Goals For the telephony system, suppose that the uncontrolled variables are rate (call cost, cents/second) and quality (a subjective measure, 1 = poor to 10 = best). The controlled variables are bandwidth (Kbps), duration (typical call length, seconds), handled (calls handled by the user, per day), and received (calls received by the user, per day). The company is presumed to have the communications goals shown in table 1. This is a subset of a larger set of goals that may deal with other factors such as avail- ability, reliability, security, etc. The textual descriptions of the goals are high-level and rather woolly. To make them operational, they need to be related to the system variables. Whether the company’s goals are appropriately formulated here is not relevant. What is important is that the interpretation of each goal is made explicit and precise. Each goal is associated with a numerical measure (network use being split into sub- measures for bandwidth use and call handling). The goal measures are defined as derived variables. These are combined into an overall evaluation function that is a weighted sum of the goal measures, again treating network use as two subsidiary measures. Note that measures to be minimised are preceded by a minus sign. For a discussion of where the scaling factors and weights here come from, see section 3.5. K.J. Turner and G.A. Campbell / Goals and Conflicts in Telephony 13 Feature Interactions in Software and Communication Systems X, IOS Press, Incorporated, 2009. ProQuest Ebook Central, Copyright © 2009. IOS Press, Incorporated. All rights reserved.
- 28. Goal Description 1 the company is keen to promote the use of multimedia in its communications if it is a weekday do maximise multimedia use measure 0.03×bandwidth×quality 2 the company wishes to use its communications network to the full do maximise network use measure 0.0008×bandwidth×duration and 6.0×handled 3 call cost can become important so the company wishes to control this if it is a weekday and the call bandwidth exceeds 128 Kbps do minimise call cost measure rate×duration 4 the company wishes to minimise interruptions to staff during lunch breaks if it is 1PM–2PM do minimise interruption time measure 0.02×received×duration Table 1. Sample Goals 3.2. Prototypes The prototype library will include a wide range of policies to meet the company’s likely goals. For the sake of example, suppose that the prototypes in table 2 are those relevant to a call arriving or a call being made. 3.3. Static Analysis As each of the goals in section 3.1 is defined, the prototypes that contribute to it are determined. The prototypes in section 3.2 are a subset of the full library; the table below shows their static analysis. The information in such a table is used to create a goal-derived policy for each prototype, stating which goals a policy contributes to: Prototype Goal 1 2 3 4 5 6 7 1 2 3 4 3.4. Dynamic Analysis As telephony events are received from the softswitch, they trigger the selection of regular policies as well as those generated during static analysis of goals. Suppose that there are only the policies derived from the prototypes in table 2. The weight associated with each goal measure is taken as 1.0 (see later discussion in section 3.5). Imagine that a long-distance call now arrives about a contract, that the call band- width is low, and that the callee is available. The policy server will determine that poli- cies 1 (add lawyer), 2 (add video), 4 (5 minute limit), 5 (parameterised limit) and 7 (re- move whiteboard) are eligible for execution. This will be notified to the dynamic anal- K.J. Turner and G.A. Campbell / Goals and Conflicts in Telephony 14 Feature Interactions in Software and Communication Systems X, IOS Press, Incorporated, 2009. ProQuest Ebook Central, Copyright © 2009. IOS Press, Incorporated. All rights reserved.
- 29. Prototype Description 1 a lawyer must be conferenced into calls about contracts when a call arrives if it is about contracts do conference in a company lawyer effect bandwidth += 64 2 low-bandwidth calls should make use of video when a call arrives if the bandwidth is less than 1 Mbps and the call has no video do add video effect bandwidth += 512 3 if the callee is busy, forward the call to a secretary (note ‘-~’ for an exclusive change) when a call arrives and the callee is busy do forward the call to a secretary effect received -~1 4 expensive calls should be limited to 5 minutes when a call is made if the cost exceeds 0.2 cents/sec do start a timer to limit the call to 300 sec effect duration = 300 5 calls should be limited by a duration parameter that is dynamically optimised when there is a call do start a timer that limits the call to $duration seconds effect duration = $duration 6 if the callee is busy for a personal call, reject the call with a suitable message when a call arrives and the callee is busy if it is a personal call do reject the call and play a busy message effect handled -~1 and received -~1 7 remove a digital whiteboard if it is in use when there is a call if a whiteboard is in use do remove whiteboard effect bandwidth -~96 Table 2. Sample Prototypes yser, which will retrieve the current values of the system variables. Suppose these are bandwidth 64, duration 300, handled 5, quality 8, rate 0.1, and received 5. The dynamic analyser will then report that the optimal set of policies is 1 (add lawyer), 2 (add video) and 5 (duration parameter 600 seconds). The actions from these policies are then checked for conflicts. A resolution policy may determine that conferenc- ing in a third party (policy 1) conflicts with also adding video (policy 2). This is because use of video on an external call may compromise the confidentiality of the workplace. The resolution is to conference in a manager to monitor what is viewed. The actions sent to the softswitch are therefore: include a lawyer (from 1), add video (from 2), run a call timer for 600 seconds (from 5), and include a manager (from the resolution). As can be seen, a substantial number of things happen for a simple event like a call arriving. The entire procedure of selecting policies, optimising goals, resolving conflicts, K.J. Turner and G.A. Campbell / Goals and Conflicts in Telephony 15 Feature Interactions in Software and Communication Systems X, IOS Press, Incorporated, 2009. ProQuest Ebook Central, Copyright © 2009. IOS Press, Incorporated. All rights reserved.
- 30. Other documents randomly have different content
- 31. WALK ON THE WILD SIDE. THE WARRIOR EMPRESS. WATCHA WATCHIN'? WATER SPORTS CHAMPS. A WEEKEND WITH LULU. WE'LL BURY YOU! WHERE ANGELS GO TROUBLE FOLLOWS. WHO WAS THAT LADY? WHO'S MINDING THE MINT. THE WILD WESTERNERS. WINTER A-GO-GO. WOLF HOUNDED. WOLF IN SHEEP DOG'S CLOTHING. WONDERFUL AFRICA. WONDERFUL AUSTRIA. WONDERFUL BEAULIEU. WONDERFUL CARIBBEAN. WONDERFUL GREECE.
- 32. WONDERFUL HONG KONG. WONDERFUL ISRAEL. WONDERFUL NEW YORK. WONDERFUL SARDINIA. WONDERFUL SCOTLAND. WONDERFUL SWITZERLAND. WONDERS OF ARKANSAS. WONDERS OF DALLAS. WONDERS OF KENTUCKY. WONDERS OF MIAMI BEACH. WONDERS OF ONTARIO. WONDERS OF PHILADELPHIA. WORLD WITHOUT SUN. THE WRECKING CREW. THE WRONG BOX. YOU MUST BE JOKING. THE YOUNG AMERICANS. ZOO IS COMPANY.
- 33. ZOTZ! Columbia Pictures Industries, Inc. CASTLE KEEP. Columbia University Press. ALBERTO GIACOMETTI. EERO SAARINEN, ARCHITECT. ERIC BENTLEY. HIDE AND SEEK. TWELVE DANCING PRINCESSES. Columbia University Press. Center for Mass Communication. ONE DAY A WEEK. SMOKE, ANYONE? Columbia World of Sports. RASSLIN' CHAMPS. SWINGING DOWN THE LANES. Columbus (Ohio) Dental Society. Women's Auxiliary. SONNY'S LUCKY DREAM.
- 34. Columbus Productions, Inc. LENNY BRUCE. Comedic Productions, Inc. THE SMOTHERS BROTHERS COMEDY HOUR. Comet Rice Mills, Inc. COMET RICE TELEVISION COMMERCIALS. THE COMET RICE 20 DAY-20 POUND, NO HUNGER DIET, TV COMMERCIAL. Commager, Henry Steele. OUR SCHOOLS HAVE KEPT US FREE. Commercial Industrial Division, Westinghouse Learning Corp. SEE Westinghouse Learning Corp. Commercial Industrial Division. Committee for Scientific Communication in Dermatology, Washington, D.C. COCCIDIOIDOMYCOSIS. CREEPING ERUPTION. CUTANEOUS VASCULAR PHENOMENON ASSOCIATED WITH FUNCTIONING. DEMODEX FOLLICULORUM.
- 35. DERMATOSES OCCURRING MAINLY IN JAPANESE. DISSEMINATED ANERGIC LEISHMANIASIS. EARLY CUTANEOUS LEISHMANIASIS. GENERALIZED KERATOACANTHOMA. GIANT LICHENIFICATION. HYDROA VACCINIFORME WITH REACTIVE PORPHYRINURIA, DWARFISM, PROGRESSIVE FEEBLE-MINDEDNESS, CENTRAL NERVOUS ABNORMALITIES. ICHTHYOSIS LINEARIS CIRCUMFLEXA. KERATODERMIA PALMARIS ET PLANTARIS. LATE CUTANEOUS LEISHMANIASIS. MAL DE MELEDA. MALIGNANT ATROPHYING PAPULOSIS. MYELOMATOSIS WITH CUTANEOUS MANIFESTATIONS. NORTH AMERICAN BLASTOMYCOSIS TREATED WITH AMPHOTERICIN B. ONCHOCERCIASIS. PEUTZ-JEGHERS' SYNDROME. PRETIBIAL MYXOEDEMA WITH ACROPACHY.
- 36. RHINOSCLEROMA. SILICA GRANULOMA. SUBCORNEAL PUSTULAR DERMATOSIS. TUBERCULOSIS CUTIS LUPOSA. URTICARIA PIGMENTOSA. Commonwealth Edison Co. THE WORLD OF ANDREW WYETH. Commonwealth United Corp. CERVANTES. Commonwealth United Entertainment. A FACE OF WAR. Commonwealth United Entertainment, Inc. THE DESPERATE ONES. Commonwealth United Releasing Organization, Inc. A FACE OF WAR. Compagnie Francais de Distribution Cinematographique. LES BICHES.
- 37. Company of Artists, Inc. BELOVED INFIDEL. LET'S MAKE LOVE. THE STORY ON PAGE ONE. WILD IN THE COUNTRY. Compton/Sir Nigel Films Production. A STUDY IN TERROR. Computer Methods Corp. DATA COMMUNICATIONS. Comstock Productions. HOLLYWOOD TALENT SCOUTS. Concepts Unlimited, Inc. ALL THIS AND 702. FUSION. Concordia Films. RECLAIMED. Condon, Richard. THE HAPPY THIEVES.
- 38. THE MANCHURIAN CANDIDATE. Condor Films, Inc. SAINT LOUIS: GATEWAY TO THE WEST. Connaught Productions, Inc. BUONA SERA, MRS. CAMPBELL. Connecticut Films, Inc. LONDON BRIDGE IS FALLING DOWN. TO MARKET, TO MARKET. Connor, Richard M., Sr. EARLY LOGGING SCENES, 1930. Conrad, Joseph. LORD JIM. Conrad, Lawrence H. PATTERNS OF GOOD TEACHING—HIGH SCHOOL LEVEL. Conservation Foundation, Washington, D.C. THE HOUSE OF MAN, PART II: OUR CROWDED ENVIRONMENT. Consortium Pathe.
- 39. LES BICHES. Constantin-Film. HOUSE OF A THOUSAND DOLLS. PER QUALCHE DOLLARO IN PIU. Consumers Power Co. THE DEPENDABLE FLAME. ENERGY FOR A BRIGHTER TOMORROW. HEADSTART ON TOMORROW. MICHIGAN YEAR. NUCLEAR POWER FOR MICHIGAN'S FUTURE. ONLY IF YOU CARE. PIPELINE PEOPLE. THE RIVER THAT CAME BACK. WHAT'S IT GOING TO COST YOU? WHEN MICHIGAN WAS YOUNG. Contemporary Films, Inc. YOUTH DANCES. Contemporary Productions, Inc.
- 40. H.M.S. PINAFORE. THE PIRATES OF PENZANCE. THE YOUNG SAVAGES. Continental Illinois National Bank Trust Co. of Chicago. SELLING TACTICS, INSIDE AND OUT. Continenza, Alessandro. HANNIBAL. Cooga Mooga Films Productions, Inc. JOURNEY TO THE CENTER OF THE EARTH. Cooga Mooga Production. THE YELLOW CANARY. Cook, James A. THE COMPUTER IN THE CLASSROOM. Cook, Peter. BEDAZZLED. Cook, Will. TWO RODE TOGETHER.
- 41. Cooney, Ray. THE HAND. Cooper (Jackie) Productions, Inc. HENNESEY. Cooper (Peter H.) Inc. CONNIE. Coppel, Alec. THE BLISS OF MRS. BLOSSOM. THE GAZEBO. MOMENT TO MOMENT. Coppel, Myra. THE GAZEBO. Corlou Films. SUCCESSFUL BREAST FEEDING. Corman Co., Inc. THE SECRET INVASION. TOBRUK. Corn Products Co. Best Foods Division.
- 42. COLOR FOR JOY. Corning Glass Works. THE WORLD IN YOUR KITCHEN. Corona Film Production. THE WORLD IN MY POCKET. Coronado Productions (England) Ltd. PLAY IT COOL. Coronet Film Museum. TRIUMPH DES WILLENS. Coronet Films. NETHERLANDS: PAST AND PRESENT. Coronet Films. SEE Coronet Instructional Films. Coronet Instructional Films. ACCOUNTING: BASIC PROCEDURES. ACTING WITH MATURITY. ADDITION FOR BEGINNERS. ADJUSTING YOUR READING SPEEDS. THE AEGEAN AGE.
- 43. AFRICAN CONTINENT: AN INTRODUCTION. AFRICAN CONTINENT: NORTHERN REGION. AFRICAN CONTINENT: SOUTHERN REGION. AFRICAN CONTINENT: TROPICAL REGION. THE AGE OF ABSOLUTE MONARCHS IN EUROPE. THE AGE OF ENLIGHTENMENT IN EUROPE. AIRPLANES: PRINCIPLES OF FLIGHT. ALEXANDER HAS A GOOD DAY. ALEXANDER THE GREAT AND THE HELLENISTIC AGE. ALGEBRA: A WAY OF THINKING ABOUT NUMBERS. ALGEBRA: RELATIONS, FUNCTIONS AND VARIATION. AN ALPHABET OF BIRDS. AMERICAN INDIANS BEFORE EUROPEAN SETTLEMENT. ANCIENT PAESTUM: CITY OF THE GREEKS AND ROMANS. ANCIENT PALESTINE.
- 44. ANCIENT PERSIA. ANCIENT WORLD INHERITANCE. ANDREW JACKSON AT THE HERMITAGE. ANGLES AND THEIR MEASUREMENTS. ANIMAL BABIES GROW UP. ANIMAL COMMUNITIES AND GROUPS. ANIMAL HIDE AND SEEK: CAMOUFLAGE FOR BEGINNERS. ANIMALS AND HOW THEY COMMUNICATE. ANIMALS ARE DIFFERENT AND ALIKE. ANIMALS PROTECT THEMSELVES. ANIMALS WITHOUT BACKBONES. THE ANT AND THE DOVE. THE ANT AND THE GRASSHOPPER. THE ANT COLONY THROUGH THE YEAR. APTITUDES AND OCCUPATIONS. AQUATIC INSECTS. ARISTOTLE AND THE SCIENTIFIC METHOD. ARITHMETIC: ESTIMATING AND CHECKING
- 45. ANSWERS. ARITHMETIC IN THE FOOD STORE. ARITHMETIC: UNDERSTANDING THE PROBLEM. ARTHROPODS: INSECTS AND THEIR RELATIVES. ASIA: A CONTINENTAL OVERVIEW. AUSTRIA, PAST AND PRESENT. AUTOMATION: WHAT IT IS AND WHAT IT DOES. THE BAGWORM. BALANCE YOUR DIET FOR HEALTH AND APPEARANCE. BARDELL VS. PICKWICK. THE BARN SWALLOW. BASIC SKILLS. BASKETBALL FUNDAMENTALS. THE BEETLE. BEGINNING RESPONSIBILITY: BEING A GOOD SPORT. BEGINNING RESPONSIBILITY: DOING THINGS FOR OURSELVES IN SCHOOL. BEGINNING RESPONSIBILITY: GETTING
- 46. READY FOR SCHOOL. BEGINNING RESPONSIBILITY: LEARNING TO FOLLOW INSTRUCTIONS. BEGINNING RESPONSIBILITY: LUNCHROOM MANNERS. BEGINNING RESPONSIBILITY: RULES AT SCHOOL. BEGINNING RESPONSIBILITY: USING MONEY WISELY. BEGINNINGS AND GROWTH OF INDUSTRIAL AMERICA. BILLY'S HELICOPTER RIDE. BIOLOGY IN SPACE SCIENCE. BIOLOGY IN TODAY'S WORLD. BIRDS AND THEIR CHARACTERISTICS. BIRDS AND THEIR HOMES. BIRDS: HOW WE IDENTIFY THEM. BIRDS OF THE COUNTRYSIDE. BIRDS OF THE DOORYARD. BIRDS OF THE INLAND WATERWAYS. BIRDS OF THE MARSHES.
- 47. BIRDS OF THE SEA. BIRDS OF THE WOODLANDS. BIRDS THAT MIGRATE. THE BIRTH OF PUPPIES. BOLIVAR: SOUTH AMERICAN LIBERATOR. A BOOK IS TO CARE FOR. BOY OF JAPAN: ITO AND HIS KITE. THE BOYHOOD OF ABRAHAM LINCOLN. THE BOYHOOD OF THOMAS EDISON. THE BRITISH COMMONWEALTH OF NATIONS. BRUSHING UP ON DIVISION. BRUSHING UP ON MULTIPLICATION. THE BUDDHIST WORLD. BUILD YOUR VOCABULARY. BUILDING BETTER SENTENCES. BULGARIA: THE LAND AND THE PEOPLE. THE BUSY AIRPORT. A BUSY DAY AT THE COUNTY FAIR.
- 48. THE BUSY HARBOR. BUTTERFLY AND MOTH LIFE CYCLES. THE BYZANTINE EMPIRE. CAMOUFLAGE IN NATURE THROUGH FORM AND COLOR MATCHING. CAMOUFLAGE IN NATURE THROUGH PATTERN MATCHING. CANADA'S HISTORY: COLONY TO COMMONWEALTH. CARL SANDBURG DISCUSSES HIS WORK. CARL SANDBURG DISCUSSES LINCOLN. CAUSES OF THE SEASONS. CELL BIOLOGY: LIFE FUNCTIONS. CELL BIOLOGY: MITOSIS AND DNA. CELL BIOLOGY: STRUCTURE AND COMPOSITION. CELLS OF PLANTS AND ANIMALS. CENTRIPETAL FORCE AND SATELLITE ORBITS. CHARLEMAGNE AND HIS EMPIRE. CHEMICAL BOND AND ATOMIC STRUCTURE.
- 49. CHEMICAL CHANGES ALL ABOUT US. CHEMICAL PROPERTIES OF WATER. CHEMISTRY LABORATORY SERIES. CHILDREN ON THE MOVE. CHRISTIANITY IN WORLD HISTORY (TO 1000 A.D.) A CHRISTMAS CAROL. CITIZENSHIP AND YOU. CIVIL WAR: BACKGROUND ISSUES. THE CIVIL WAR: 1863-1865. CIVIL WAR: FIRST TWO YEARS. THE CIVIL WAR: POSTWAR PERIOD. CLASSIFYING PLANTS AND ANIMALS. CLEANLINESS AND HEALTH. CLIMATES OF THE UNITED STATES. CLOTHES AROUND THE WORLD. COLONIAL LIFE ON A DUTCH MANOR. COLOR AND LIGHT: AN INTRODUCTION.
- 50. COLOR AND PIGMENT IN ART. COLOR FOR BEGINNERS. THE COLORADO RIVER. THE COLUMBIA RIVER. COMMUNICATION FOR BEGINNERS. COMMUNICATION: STORY OF ITS DEVELOPMENT. COMMUNITIES DEPEND ON EACH OTHER. COMMUNITIES KEEP CLEAN. COMPETITION IN BUSINESS. CONSERVATION FOR BEGINNERS. CONSERVING OUR FORESTS TODAY. CONSERVING OUR MINERAL RESOURCES TODAY. CONSERVING OUR SOIL TODAY. CONSERVING OUR WATER RESOURCES TODAY. CONSERVING OUR WILDLIFE TODAY. CONTINENTS OF THE WORLD. COTTON IN TODAY'S WORLD. THE COUNTRY MOUSE AND THE CITY MOUSE.
- 51. COURTESY FOR BEGINNERS. THE CRANE'S MAGIC GIFT, A JAPANESE FAIRY TALE. CRAYFISH: LIFE CYCLE. CREATING WITH COLOR. THE CRICKET AND GRASSHOPPER. CRYSTALS AND THEIR GROWTH. CURRENT EVENTS: UNDERSTANDING AND EVALUATING THEM. CUTTING AND PASTING. THE DAIRY FARM. DANIEL BOONE IN AMERICA'S STORY. DARWIN AND THE THEORY OF NATURAL SELECTION. DAVID AND BETSEY TROTWOOD. DAVID AND DORA. DAVID AND DORA MARRIED. DAVID AND HIS MOTHER. DAVID AND MR. MICAWBER.
- 52. DAWN OF THE AMERICAN REVOLUTION: A LEXINGTON FAMILY. DENTAL HEALTH: HOW AND WHY. DESERT DWELLERS: PLANTS AND ANIMALS. DEVELOPING READING MATURITY: COMPARATIVE READING. DEVELOPING READING MATURITY: CRITICAL EVALUATION. DEVELOPING READING MATURITY: INTERPRETING MEANING. DEVELOPING READING MATURITY: THE MATURE READER. DEVELOPING READING MATURITY: UNDERSTANDING STYLE. DIFFUSION AND OSMOSIS. DIGESTION IN OUR BODIES. DIVISION FOR BEGINNERS. EARS: THEIR STRUCTURE AND CARE. THE EARTH: CHANGES IN ITS SURFACE. THE EARTH: ITS ATMOSPHERE. THE EARTH: ITS OCEANS.
- 53. THE EARTH: ITS STRUCTURE. THE EARTH: RESOURCES IN ITS CRUST. THE EARTH'S MOVEMENTS. EARTHWORM: ANATOMY AND DISSECTION. EASTERN EUROPE: AN INTRODUCTION. EAT WELL, GROW WELL! ECHINODERMS AND MOLLUSKS. ELECTRICITY FOR BEGINNERS. ELECTRICITY FROM CHEMICALS. ELECTRICITY: HOW IT IS GENERATED. ELECTRICITY: PRINCIPLES OF SAFETY. ELECTROCHEMICAL REACTIONS. ELECTROMAGNETIC INDUCTION. ELECTRONS AND ELECTRONICS: AN INTRODUCTION. ELECTROSTATIC CHARGES AND FORCES. ENERGY AND ITS FORMS. ENERGY DOES WORK. ENGLAND: BACKGROUND OF LITERATURE.
- 54. ENGLISH HISTORY: NINETEENTH CENTURY REFORMS. THE ENGLISH LANGUAGE: HOW IT CHANGES. EQUATIONS: NUMBER SENTENCES. THE EUROPEAN ECONOMIC COMMUNITY. EVERYDAY COURAGE AND COMMON SENSE. EVERYDAY COURTESY. EVOLUTION OF MAN. EXPLORING THE ATOMIC NUCLEUS. FARM ANIMALS IN RHYME. FEDERAL TAXATION. FILING PROCEDURES IN BUSINESS. FILM HIGHLIGHTS OF MODERN HISTORY: THE EARLY 1900'S. FIRE AND OXIDATION. FISH AND THEIR CHARACTERISTICS. FIVE COLORFUL BIRDS. FLOWERS: STRUCTURE AND FUNCTION. FLUTE, CLARINET AND BASSOON.
- 55. FOLK SONGS OF AMERICA'S HISTORY. FOLKSONGS OF THE WESTERN MOVEMENT, 1787-1853. FOLKSONGS OF THE WESTERN SETTLEMENT, 1865-1900. THE FOOD CYCLE AND FOOD CHAINS. FOOD THAT BUILDS GOOD HEALTH. FOODS AROUND THE WORLD. FOODS FROM GRAINS. FORCES: COMPOSITION AND RESOLUTION. FORMS OF MUSIC: INSTRUMENTAL. FRACTIONS: FINDING THE COMMON DENOMINATOR. FRED MEETS A BANK. FRICTION AND ITS EFFECTS. FUN WITH WORDS: WORDS THAT ADD MEANING. FUN WITH WORDS: WORDS THAT NAME AND DO. FUN WITH WORDS: WORD TWINS. GALILEO.
- 56. GENETICS: CHROMOSOMES AND GENES (MEIOSIS). GENETICS: FUNCTIONS OF DNA AND RNA. GENETICS: HUMAN HEREDITY. GENETICS: IMPROVING PLANTS AND ANIMALS. GENETICS: MENDEL'S LAWS. GEOGRAPHY OF SOUTH AMERICA: ARGENTINA, PARAGUAY, URUGUAY. GEOGRAPHY OF SOUTH AMERICA: BRAZIL. GEOGRAPHY OF SOUTH AMERICA: COUNTRIES OF THE ANDES. GEOGRAPHY OF SOUTH AMERICA: THE CONTINENT. GEOMETRY: INDUCTIVE AND DEDUCTIVE REASONING. GERMS AND WHAT THEY DO. GETTING ALONG WITH OTHERS. GETTING INTO COLLEGE. GETTING THE BIG IDEAS. THE GLOBE AND OUR ROUND EARTH. GRAPHING LINEAR EQUATIONS. GRAPHS: UNDERSTANDING AND USING THEM.
- 57. GRASSHOPPER: ANATOMY AND DISSECTION. GRAVITY AND WHAT IT DOES. GROUPING THINGS IN SCIENCE. GROWTH OF BIG BUSINESS IN AMERICA, 1865-1900. GROWTH OF FARMING IN AMERICA, 1865-1900. THE HALOGENS. HANDWRITING FOR BEGINNERS: MANUSCRIPT. HEALTH HEROES: THE BATTLE AGAINST DISEASE. HEART, LUNGS AND CIRCULATION. HEARTS AND CIRCULATORY SYSTEMS. HEAT AND ITS BEHAVIOR. HEAT AND TEMPERATURE. HELPERS AT OUR SCHOOL. THE HELPFUL LITTLE FIREMAN. THE HINDU WORLD. THE HISTORY OF LIVING THINGS. THE HOLY ROMAN EMPIRE.
- 58. HOMES AROUND THE WORLD. THE HOUSEFLY AND ITS CONTROL. HOW AIR HELPS US. HOW FLOWERS MAKE SEEDS. HOW MATERIALS ARE ALIKE AND DIFFERENT. HOW POWER DRIVES MACHINES. HOW SIMPLE MACHINES MAKE WORK EASIER. HOW SOUND HELPS US. HOW SUNSHINE HELPS US. HOW TO READ A BOOK. HOW TO STUDY. HOW WE ELECT OUR REPRESENTATIVES. HOW WHEELS HELP US. THE HUMAN BODY: EXCRETORY SYSTEM. THE HUMAN BODY: MUSCULAR SYSTEM. THE HUMAN BODY: NUTRITION AND METABOLISM. THE HUMAN BODY: RESPIRATORY SYSTEM. THE HUMAN BODY: SENSE ORGANS.
- 59. THE HUMAN BODY: THE BRAIN. THE HUMAN BODY: THE CHEMISTRY OF DIGESTION. HYDROCARBONS AND THEIR STRUCTURES. IMMIGRATION IN AMERICA'S HISTORY. IMPERIALISM AND EUROPEAN EXPANSION. IMPROVE YOUR ORAL REPORTS. IMPROVE YOUR PUNCTUATION. IMPROVE YOUR STUDY HABITS. IMPROVING AMERICA'S HEALTH. IMPROVING YOUR VOCABULARY. THE INCAS. INDIAN INFLUENCES IN THE UNITED STATES. INERTIAL MASS AND THE LAWS OF MOTION. INFECTIOUS DISEASES AND MAN-MADE DEFENSES. INFECTIOUS DISEASES AND NATURAL BODY DEFENSES. INSECT ENEMIES AND THEIR CONTROL.
- 60. Welcome to our website – the ideal destination for book lovers and knowledge seekers. With a mission to inspire endlessly, we offer a vast collection of books, ranging from classic literary works to specialized publications, self-development books, and children's literature. Each book is a new journey of discovery, expanding knowledge and enriching the soul of the reade Our website is not just a platform for buying books, but a bridge connecting readers to the timeless values of culture and wisdom. With an elegant, user-friendly interface and an intelligent search system, we are committed to providing a quick and convenient shopping experience. Additionally, our special promotions and home delivery services ensure that you save time and fully enjoy the joy of reading. Let us accompany you on the journey of exploring knowledge and personal growth! ebookname.com