Telecommunications services like instant messaging or internet telephony bring increased flexibility to communicate at home, in the office or on the move. Their pervasiveness is also a source of disruptions and intrusions. Service providers are therefore looking for personalisation solutions allowing users to control the timing and modalities of their communications. In the case of telephony services, personalisation solutions are built around call control features. Technically, a feature is an increment of functionality that modifies the basic system behaviour. Dozens of call control features have been created to address concerns such as mobility, privacy, presentation, or billing (see Figure 1).
Features are designed as independent separate module and are exposed through feature catalogs (see Figure 2). A user selects from the catalog the set of features that he wants to be active during the session in which he is involved. He may also want to sequence the activation of the selected features in a particular way to better suit his needs (e.g., he may want to filter his incoming calls before diverting them). The features that the user has selected plus the ordering constraints that he has imposed on them constitute the feature subscription of the user.
As features are designed independently, each feature is designed under the assumption that it is the only activated feature during the call. This assumption is what causes the interaction between features. A feature interaction is a way in which a feature modifies or influences the behavior of another feature in generating the system’s overall behavior. Undesirable interactions must be detected and avoided when users configure their subscriptions.
In Figure 3, we show an example of an undesirable interaction: Y has two features in his subscription: a “terminating call screening” feature and a “call forwarding unconditional” feature. Y has requested that the “call forwarding unconditional” feature must be activated before the “terminating call screening” feature. As the “call forwarding unconditional” changes the destination of the call, the “terminating call screening” feature is never activated. So when X calls Y, X will always be re-directed to Z, even if X is the list of banned callers. A simple fix is to inverse the order of activation (as shown in Figure 4).
Key requirements that drive the design of feature-rich telephony systems are: the ability for users to parametrise features (e.g., “Call-Divert to mobile”), address caller and callee scenarios (e.g., “Do-Not-Disturb and Speed-Dial”), combine or sequence features (e.g., “Call-Screen then Call-Divert”), request context-sensitive feature configurations (e.g., “Mute during seminars”), and express preferences or priorities (e.g., call policies imposed on a workforce). Different approaches ranging from scripting to policy enforcement have been proposed to meet these requirements. None, however, provides a comprehensive personalisation solution to: resolve undesirable feature interactions arising due to compositionality; manage conflicting preferences; and handle the uncertainty inherent to context data. To address these issues we designed a system for Context-sensitive Configuration of Call Control features using Rules (4CRules) .
4CRules allows a user to describe the behaviour of the communication service through a set of Feature Configuration Rules (FCRs). Conceptually, a FCR is weighted and associates a context condition to a feature subscription, which is defined to be a set of features, and a set of precedence constraints prescribed by a user and the feature catalogue. Each time a user’s context is updated, the engine of 4CRules infers a sequence of features from his/her set of FCRs. %and a catalogue of precedence constraints. This sequence is free of undesirable feature interactions and it is applied to all calls involving the user until his context changes again.
A set of FCRs that are applicable for a given current context of a user could be inconsistent due to a variety of reasons as explained in . The 4CRules engine computes a maximal subset of the applicable FCRs that is consistent and optimal in some sense. The optimality is based on a strict weak ordering over FCRs, which is obtained by evaluating a value for each FCR by combining priority of the FCR, concreteness of the context condition of the FCR, and probability of applicability of the FCR. The principle of the presented approach is to view FCRs processing as a constraint optimisation task. Overall, the method ensures maximum adherence to user requirements and interaction constraints.
Figure 5 shows a snapshot of the widget-based web interface to the subscription configuration system. The interface exposes the catalogue from which users can pick and sequence features through drag-and-drop operations and the context dimensions. The constraint engine then guides the user towards consistent subscriptions in different ways:
- verification: checking the consistency of the input subscription;
- partial completion: if consistent, extend it with entailed precedence constraints;
- filtering: if consistent, filter out the set of additional features and precedence constraints that would make it inconsistent;
- completion: if consistent, suggest complete and consistent extensions;
- revision: if inconsistent, suggest consistent and optimal relaxations.
To learn more
- Tarik Hadzic, David Lesaint, Deepak Mehta, Barry O’Sullivan, Luis Quesada, and NicWilson. A BDD Approach to the Feature Subscription Problem. In Prestigous Applications of Intelligent Systems (PAIS), Patras, Greece, July 2008. To appear.
- F. Laburthe and N. Jussien. JChoco: A java library for constraint programming.
- David Lesaint, Deepak Mehta, Barry O’Sullivan, Luis Quesada, and Nic Wilson. Context-Sensitive Call Control using Constraints and Rules. In Proceedings of the 16th International Conference on Principles and Practice of Constraint Programming, St Andrews, Scotland, 2010. Springer.
- David Lesaint, Deepak Mehta, Barry O’Sullivan, Luis Quesada, and Nic Wilson. Developing approaches for solving a telecommunications feature subscription problem. Journal of Artificial Intelligence Research (JAIR), 2010.
- Jonathan Rosenberg, Henning Schulzrinne, Gonzalo Camarillo, Alan B. Johnston, Jon Peterson, Robert Sparks, Mark Handley, and Eve M. Schooler. SIP: Session Initiation Protocol. RFC 3261 (standard), IETF, June 2002. Updated by RFCs 3265, 3853, 4320.
- Robert Sparks. SIP: Basics and Beyond. ACM Queue, 5(2):22–33, March 2007.