Appel (Adaptable and Programmable Policy Environment and Language)

Introduction
Approach
Examples
Tool Support
Future Plans
Publications

Introduction

Appel (Adaptable and Programmable Policy Environment and Language) was originally developed on the Accent project for control of Internet telephony. The acronym therefore originally stood for 'Accent Project Policy Environment/Language'. The name also derives from the French word for a call, so the stress is on the second syllable: Appel. Subsequently, Appel has been extended into new domains: home care management (Match project) and sensor network/wind farm management (Prosen project).

The development of Appel and its supporting tools is currently being undertaken by Ken Turner. Previous contributors have included Lynne Blair, Gavin Campbell, Tingxue Huang, Stephan Reiff-Marganiec and Feng Wang.

Approach

Appel is a language for defining goals (i.e. high-level objectives) and policies (i.e. rules) for how a system should automatically react to certain stimuli in certain situations. It is an example of a general class of policy languages called ECA (Event-Condition-Action). Appel differs from other policy languages in a number of distinctive ways:

• it supports user-oriented goals and their automatic refinement into policies
• it is designed for use by non-technical end users, rather than for developers or system administrators
• it is readily extended into new application domains by defining new schemas and ontologies
• it is intended for novel application domains where policy-based management has not previously been used
• it has built-in support for detecting and resolving conflicts among policies.

So far, Appel has been demonstrated in the following application areas: call control for telephony, management of sensor networks, management of wind farms, and managing technical aspects of home care services.

The following diagram shows how Appel is extended for new domains. The core language is domain-independent and defines common aspects such as goal, policies, variables, timers and histories. This is then extended for regular policies (that perform actions in response to events) and resolution policies (that detect and resolve conflicts among policy actions). Each of these is then specified for some application domain such as call control.

Appel is defined through XML schemas supported by OWL ontologies. The latter are also defined in a modular and hierarchical fashion, allowing ready extension into new application domains. See the online schemas and ontologies for more details.

The key structural elements of Appel are as follows:

Policy Document

This is the highest level at which one or more goals, prototype policies, regular policies, resolution policies or policy variables may be defined.

Goal

A goal is a high-level, declarative objective. Syntactically a goal resembles a policy, but has no trigger (as goals always apply) and has just one action (to maximise or minimise a goal measure). The degree to which a goal is achieved is assessed by a numerical measure. This is defined in terms of controlled variables (managed by the policy system), uncontrolled variables (external and environmental), and derived variables (defined in terms of other variables). Since there are usually multiple (and often conflicting) goals, an overall evaluation function is defined in terms of individual goal measures.

Prototype

A prototype is a predefined policy that contributes towards goals by affecting variables (and therefore affecting goal measures). When goals and prototypes are defined, the relationship among goals and prototypes is statically determined. At run time, when triggers occur, the prototypes that best contribute to the goals are selected dynamically. Prototypes may also have parameters that are optimised dynamically. The result is a flexible and completely dynamic approach to refinement of goals into policies (or, more precisely, the selection of policies to achieve goals). The numerical approach means that goals are achieved as far as possible (and not in some absolute sense). The dynamic approach means that refinement takes account of current circumstances (which may change as the system and its environment evolve).

Policy

A policy is the main element in Appel.

Policy Modality

A policy may contain a modality in the form of a preference, principally for use by the conflict resolution engine.

Policy Rules

A policy rule group is either a single policy rule or a composite of subsidiary policy rules. Policy rules can optionally be combined in pairs with a number of operators.

Triggers

A trigger group is either a single trigger or a composite of subsidiary triggers. A trigger has a name and optional arguments. One or more triggers might enable a policy. The and and or combinations require both or either of the triggers to be active. If the combination of actual trigger events permits the policy rule, then its condition is considered. Goals (which have no triggers) are always implicitly activated.

Conditions

A condition group is either a single condition or a composite of subsidiary conditions. A composite list of conditions is normally used when an operator governs these conditions. However groups with just one condition may be nested within each other if desired. Conditions may be combined with the usual boolean and, or and not operators.

Actions

An action group is either a single action or a composite of subsidiary actions. An action has a name and optional arguments. Operators can be used to define the order in which pairs of actions are applied.

Variables

A policy variable is just a name for a value. Policy variables can be defined by a policy document, can be defined implicitly when an external trigger occurs, and can be defined by a policy action. Variables may hold boolean, numeric (integer, floating point) or string values. Within certain policy elements, variable names can appear individually, in ranges or in lists. The value of a variable is substituted when a policy is executed, not when it is defined. When used in an expression, the name of a variable is prefixed by ':' to obtain its value.

Expressions

Expression may be used as a value or when setting a variable. Variable names inside an expression are replaced by their current values.

Timers

Policies may make use of interval (count-down) timers. A timer becomes active when it is started, and ceases to exist when it counts down to zero. At this point, an expiry event occurs for the timer identifier. An active timer may be restarted or stopped. In addition to explicit timers, policies with time conditions imply internal timer triggers.

History

External triggers are automatically recorded by the policy server as they are received. Similarly, external actions are also automatically recorded. This allows policies to depend on past inputs and outputs.

Examples

The following examples illustrate the use of Appel in various domains. (Although XML is used here, a policy wizard allows a non-technical user to express goals and policies in a natural way.)

Call Control - Regular Policy

The following policy states that calls to ken@cs.stir.ac.uk should be forwarded to bob@cs.stir.ac.uk if there is an incoming call while Ken is busy. The empty argument for unavailable means the current user is unavailable, i.e. busy.

      <policy owner="ken@cs.stir.ac.uk" applies_to="ken@cs.stir.ac.uk"
       id="Forward if busy" enabled="true" changed="2004-08-02T11:20:05">
	<policy_rule>
	  <triggers>
	    <and/>
	    <trigger>connect_incoming</trigger>
	    <trigger arg1="">unavailable(arg1)</trigger>
	  </triggers>
	  <action arg1="bob@cs.stir.ac.uk">forward_to(arg1)</action>
	</policy_rule>
      </policy>
    

Call Control - Regular Policy

The following policy states that incoming calls should be forwarded to voicemail when I am busy or don't answer within 5 rings. This policy has two combinations of trigger events but does not specify any conditions.

      <policy owner="ken@cs.stir.ac.uk" applies_to="ken@cs.stir.ac.uk"
       id="Voicemail on Busy or No Answer" enabled="true"
       changed="2004-08-02T11:19:00">
	<policy_rule>
	  <triggers>
	    <or/>
	    <trigger arg1="">unavailable(arg1)</trigger>
	    <trigger arg1="5">no_answer_incoming(arg1)</trigger>
	  </triggers>
	  <action arg1="http://voicemail.co.uk/~ken">forward_to(arg1)</action>
	</policy_rule>
      </policy>
    

Home Care - Regular Policy

Logging everyday activity in the home can be valuable to determine long-term trends. However, the nature of the logging should vary according to the circumstances and preferences of the individual. The following policy receives a logging request that specifies two lists of sensors: those whose logging should be started (parameter_values[0]), and those whose logging should be stopped (parameter_values[1]). These values are obtained implicitly from the trigger through the parameter_values environment variable.

      <policy owner="admin" applies_to="@raploch.org.uk"
       id="Logging of everyday activity" enabled="true"
       changed="2007-12-19T22:12:00">
	<policy_rule>
	  <trigger arg1="logging_request">device_in(arg1)</trigger>
	  <actions>
	    <and/>
	    <action arg1="start" arg2="logging_service" arg5=":parameter_values[0]">
	      device_out(arg1,arg2,,,arg5)
	    </action>
	    <action arg1="stop" arg2="logging_service" arg5=":parameter_values[1]">
	      device_out(arg1,arg2,,,arg5)
	    </action>
	  </actions>
	</policy_rule>
      </policy>
    

Home Care - Regular Policy

Older people, especially those with dementia, are prone to waking in the middle of the night and leaving the house. The following policy advises the user to return to bed using synthesised speech (say, of a family member). It applies to domain house3.match-project.org.uk, i.e. house 3 in the trial area of the Match project. When the front door is opened, if the time is 11PM-7AM and the master bed is unoccupied, the message 'It is night time, go back to bed' is synthesised on the hallway loudspeaker. To avoid having to hard-code the policy for the entity instance corresponding to the front door, the policy variable front is used instead. Similarly, master_bed is a policy variable that identifies the master bed occupancy sensor. These are defined separately for the house (whether manually through the policy wizard or automatically through a configuration system). Since parameter values in general take the form of a list, the trigger input carries the list '[open]'. The message period is omitted for both the trigger (i.e. 'trigger just occurred') and the action (i.e. 'perform action now').

      <policy owner="admin" applies_to="@house3.match-project.org.uk"
       id="Night wandering reminder" enabled="true"
       changed="2007-12-19T22:12:00">
	<policy_rule>
	  <trigger arg1="door_status" arg2="door" arg3=":front" arg5="[open]">
	    device_in(arg1,arg2,arg3,,arg5)
	  </trigger>
	  <conditions>
	    <and/>
	    <condition>
	      <parameter>time</parameter>
	      <operator>in</operator>
	      <value>23:00:00..07:00:00</value>
	    </condition>
	    <condition>
	      <parameter>:master_bed</parameter>
	      <operator>eq</operator>
	      <value>unoccupied</value>
	    </condition>
	  </conditions>
	  <action arg1="speak" arg2="loudspeaker"
		  arg3=":hallway" arg5="It is night time, go back to bed">
	    device_out(arg1,arg2,arg3,,arg5)
	  </action>
	</policy_rule>
      </policy>
    

Sensor Networks - Regular Policy

The following policy applies to the myers_hill domain. It deals with a low battery warning from any sensor node. It logs the event and sends a message to 07779-123-456. Note the use of environment variables in the actions.

      <policy owner="admin" applies_to="@myers_hill"
       id="Low battery alert" enabled="true" changed="2007-09-21T11:05:16">
	<policy_rule>
	  <trigger arg1="low_battery" arg2="sensor_node">
	    device_in(arg1,arg2)
	  </trigger>
	  <actions>
	    <and/>
	    <action arg1="Low battery at sensor :entity_instance">
	      log_event(arg1)
	    </action>
	    <action arg1="sms:07779-432-020"
		    arg2="Low battery warning from :entity_name/:entity_instance">
	      send_message(arg1,arg2)
	    </action>
	  </actions>
	</policy_rule>
      </policy>
    

Sensor Networks - Regular Policy

The following policy is triggered by operator input from the default operator console, asking that the power curve agent be retrained. It asks the external agent system to retrain this agent in ten minutes using value 30.

      <policy owner="admin" applies_to="@3.wind_farm"
       id="Retrain power agent" enabled="true" changed="2007-09-22T01:42:17">
	<policy_rule>
	  <trigger arg1="operator_input" arg5="retrain_power_curve">
	    device_in(arg1,,,,arg5)
	  </trigger>
	  <action arg1="retrain_agent" arg2="policy_agent" arg3="power_curve"
		  arg4="10" arg5="30">
	    device_out(arg1,arg2,arg3,arg4,arg5)
	  </action>
	</policy_rule>
      </policy>
    

Call Control - Resolution Policy

Suppose that one party wishes to add video to a call, while the other wishes include a third party in the call (add_caller). This might be considered undesirable, since the third party would be able to view the call parties and their workplaces. The resolution is to allow both actions, but to conference in bob@cs.stir.ac.uk to oversee the call (add_party). Note that the triggers and actions are all of different types. This resolution explicitly deals with only the equal/similar case. Other cases are handled by default.

      <resolution id="Medium add-add conflict"
       owner="admin@cs.stir.ac.uk" applies_to="@cs.stir.ac.uk" enabled="true"
       changed="2007-12-13T20:40:00">
	<policy_rule>
	  <triggers>
	    <and/>
	    <trigger arg1="variable0">add_medium(arg1)</trigger>
	    <trigger arg1="variable1">add_medium(arg1)</trigger>
	  </triggers>
	  <conditions>
	    <and/>
	    <condition>
	      <parameter>variable0</parameter>
	      <operator>eq</operator>
	      <parameter>variable1</parameter>
	    </condition>
	    <condition>
	     <parameter>preference0</parameter>
	     <operator>out</operator>
	     <value>preference1</value>
	    </condition>
	  </conditions>
	  <action>apply_negative</action>
	</policy_rule>
      </resolution>
    

Home Care - Goal

An older person living at home may need encouragement to stay active. The following goal states that user activity should be maximised during weekdays. User activity is defined in terms of factors such as how long the user is awake for, how much television they watch, and how much contact they have with other people. The user_activity measures is defined in terms of these variables, using weights determined by a domain expert (or learned values).

      <goal owner="admin@cs.stir.ac.uk" applies_to="@cs.stir.ac.uk"
       id="Maximise user activity" enabled="true" changed="2009-01-16T17:45:00">
	<policy_rule>
	  <condition>
	    <parameter>day</parameter>
	    <operator>in</operator>
	    <value>1..5</value>
	  </condition>
	  <action arg1="user_activity">maximise(arg1)</action>
	</policy_rule>
      </goal>
    

Tool Support

Appel is supported by a set of tools that allow goals and policies to be defined offline and to be realised in real time:

Managed System

The system under control (e.g. a call control system)

Policy Store

An XML database that stores information about goals and policies

Policy Server

The heart of the policy system. The policy server receives goals and policies from the policy wizard, and also information from the context manager. When goals or prototypes are modified, the goal server is called to statically analyse them. When an event occurs in the managed system, it selects relevant policies (i.e. those associated with this trigger and whose conditions are met). If any triggered policies derive from goals, the goal server is asked to find the optimal set. Conflicts among policies are then automatically detected and resolved. Finally, an optimal and compatible set of actions is sent to the managed system.

Policy Wizard

A user-friendly interface for defining and editing goals and policies

Context Manager

An interface for providing additional information about the managed system (e.g. the home configuration).

Conflict Analyser

A tool to analyse policies offline for possible conflicts

Ontology Server

A generic interface to ontology-based information about an application domain (e.g. call control). Domain-specific ontologies are used by the policy wizard, the conflict analyser and the goal server.

Goal Server

The heart of the goal system. The static goal analyser is invoked when goals or prototypes are altered. The dynamic goal analyser is invoked when goal-derived policies are triggered.

Future Plans

The goal server is currently being integrated more fully into the rest of the policy system. It is planned to develop techniques for capturing stakeholder viewpoints as goals and policies, and for handling conflicts among these.

Publications

The following papers give the technical basis for Appel:

• Stephan Reiff-Marganiec and Kenneth J. Turner. The Accent Project Policy Server. Technical Report CSM-164, Computing Science and Mathematics, University of Stirling, December 2005 (revised).

• Kenneth J. Turner and Gavin A. Campbell. The Accent Policy Wizard. Technical Report CSM-166, Computing Science and Mathematics, University of Stirling, April 2009 (revised).

• Kenneth J. Turner, Stephan Reiff-Marganiec, Lynne Blair, Gavin A. Campbell and Feng Wang. Appel: An Adaptable and Programmable Policy Environment and Language. Technical Report CSM-161, Computing Science and Mathematics, University of Stirling, April 2009 (revised).

The following papers illustrate the use of Appel in various domains:

• Lynne Blair and Kenneth J. Turner. Handling Policy Conflicts in Call Control. In Stephan Reiff-Marganiec and Mark D. Ryan, editors, Proc. 8th. International Conference on Feature Interaction, pages 39-57, IOS Press, Amsterdam, June 2005.

• Gavin A. Campbell. Sensor Network Policy Conflicts, in L. du Bousquet, editor, Proc. 9th. Int. Conf. on Feature Interactions in Software and Communication Systems, September 2007.

• Gavin A. Campbell and Kenneth J. Turner. Policy Conflict Filtering for Call Control, in L. du Bousquet, editor, Proc. 9th. Int. Conf. on Feature Interactions in Software and Communication Systems, September 2007.

• Gavin A. Campbell and Kenneth J. Turner. Ontologies to support Call Control Policies, in N. Meghanathan, D. Collange and Y. Takasaki, editors, Proc. 3rd. Advanced International Conference on Telecommunications, pp. 5.1-5.6, IEEE Press, May 2007.

• Petre Dini, Alexander Clemm, Tom Gray, Fuchun Joseph Lin, Luigi Logrippo and Stephan Reiff-Marganiec. Policy-Enabled Mechanisms for Feature Interactions: Reality, Expectations, Challenges. Computer Networks, 45(5):585-603, August 2004.

• Tingxue Huang and Kenneth J. Turner. Policies for H.323 Internet Telephony. Technical Report CSM-165, Computing Science and Mathematics, University of Stirling, May 2004.

• Tingxue Huang and Kenneth J. Turner. Policy Support for H.323 Call Handling, Computer Standards and Interfaces, 28(2):204-217, November 2005 (pre-publication version, copyright Elsevier Science).

• Ahmed F. Layouni, Luigi Logrippo and Kenneth J. Turner. Conflict Detection in Call Control using First-Order Logic Model Checking. In Lydie du Bousquet and Jean-Luc Richier (eds.), Proc. 9th Int. Conf. on Feature Interactions in Software and Communications Systems, pages 77-92, IOS Press, Amsterdam, Sep 2007.

• Carlo Montangero, Stephan Reiff-Marganiec and Laura Semini. Logic Based Detection of conflicts in Appel Policies. In Ali Movaghar and Jan Rutten (eds.), Proc. Int. Symposium on Fundamentals of Software Engineering, LNCS 4767, pages 257-271, Springer, Berlin, Oct 2007.

• Stephan Reiff-Marganiec. Policies: Giving Users Control over Calls. In Mark D. Ryan, John-Jules Ch. Meyer and Hans-Dieter Ehrich, editors, Proc. Objects, Agents and Features, Lecture Notes in Computer Science 2975, pages 189-208, Springer, Berlin, May 2004.

• Stephan Reiff-Marganiec and Kenneth J. Turner. Use of Logic to describe Enhanced Communications Services. In Moshe Vardi and Doron Peled, editors, Proc. Formal Techniques for Networked and Distributed Systems (FORTE XV), Lecture Notes in Computer Science 2529, pages 130-145, Copyright Springer, Berlin, November 2002.

• Stephan Reiff-Marganiec and Kenneth J. Turner. A Policy Architecture for Enhancing and Controlling Features. In Daniel Amyot and Luigi Logrippo, editors, Proc. Feature Interactions in Telecommunication Networks VII, 239-246, IOS Press, Amsterdam, June 2003.

• Stephan Reiff-Marganiec and Kenneth J. Turner. Feature Interaction in Policies, Computer Networks, 45(5):569-584, Copyright Elsevier Science Publishers, Amsterdam, March 2004.

• Kenneth J. Turner and Lynne Blair. Policies and Conflicts in Call Control, Computer Networks, 51(2):496-514, February 2007 (pre-publication version, copyright Elsevier Science).

• Kenneth J. Turner and Gavin A. Campbell. Goals and Conflicts in Telephony, in Masahide Nakamura and Stephan Reiff-Marganiec (eds.), Proc. 10th Int. Conf. on Feature Interactions in Software and Communications Systems, pp. 3-18, IOS Press, Amsterdam, June 2009.

• Kenneth J. Turner and Gavin A. Campbell. Goals for Telecare Networks, in Abdel Obaid (ed.), Proc. 9th Int. Conf. on New Technologies for Distributed Systems, pp. 270-275, Montreal, ISBN 978-1-60750-014-8, July 2009.

• Kenneth J. Turner, Gavin A. Campbell and Feng Wang. Policies for Sensor Networks and Home Care Networks, in M. Erradi (ed.), Proc. 7th. Int. Conf. on New Technologies for Distributed Systems (NOTERE'07), pp. 273-284, ISBN 9981-9704-7-6, June 2007.

• Kenneth J. Turner, Liam S. Docherty, Feng Wang and Gavin A. Campbell. Managing Home Care Networks, in Robert Bestak, Laurent George, Vladimir S. Zaborovsky and Cosmin Dini (eds.), Proc. 8th Int. Conf. on Networks, pp. 354-359, (C) IEEE Computer Society, ISBN 978-0-7695-3552-4, March 2009.

• Kenneth J. Turner, Stephan Reiff-Marganiec, Lynne Blair, Jianxiong Pang, Tom Gray, Peter Perry and Joe Ireland. Policy Support for Call Control, Computer Standards and Interfaces, 28(6):635-649, June 2006 (pre-publication version, copyright Elsevier Science).

• Feng Wang and Kenneth J. Turner. Policy Conflicts in Home Care Systems, in L. du Bousquet, editor, Proc. 9th. Int. Conf. on Feature Interactions in Software and Communication Systems, September 2007.

Up one level to Ken Turner - Research Projects