w Is It Configured? The SCL has been designed to be configurable by users who undertake one of two distinct roles. These roles are loosely referred to that of a technical expert and that of a business expert. The former will typically be someone who is familiar with the proto- col-level semantics of a service, while the latter will be concerned with implementing business policy and how a given service should be controlled or enhanced, for example, for a particular user or group of users. The two roles provide an important distinction Service Delivery Platforms in the modeling of rules within the SCL. Some configurations are deemed to be design time, that is, pertains to tailoring a service behavior and would require code to accommodate the same (e.g., integration of a new business capability like Internet Protocol Television (IPTV)). This change would need to be facilitated by the techni- cal expert, and would typically involve the use of design-time tooling. Other configu- rations could be deemed as being runtime. These changes could be achieved through simple configuration of business rules (which are consulted by the Rules Engine), and would typically be undertaken through an intuitive UI. The design of the SCL has been mindful of the distinction of the two roles, and wherever possible, has provided a layer of abstraction SO that (multiple) business policies can be implemented flexibly and transparently from protocol-level details of a service implementation. The CEP is configured ideally by the external business service vendor who has knowledge about all the possible state transitions that the service can go through. This is captured in the state machine in the CEP, which accepts input from the SCL facing interface and sends directives to the external service through the service- specific interface. The timer module is also instantiated SO that any asynchronous event can be fired or captured for possible state transition in the state machine. 1.3.3 Related Literature IP service control is an active area of re