Service Creation Model and Framework

• Focus: control, redirection services

• Challenges:– Simplicity, user-friendliness– Flexibility– Robustness (e.g., feature interactions)– Extensibility and completeness– Service portability

Intelligent Network• Separate service logic from basic call processing

– service subscription = trigger activiation, unit of billing

SwitchServiceLogic

Trigger

Limitation of the IN

• No explicit spec for the co-relation and interactions among different features (e.g., voice mail, call forwarding upon busy) -- feature interactions

• No user-level service introduction; coarse-grained service

• Lacks support for users to convey their current status or wishes.

• Service portability

Our Approach: Generic, High-level State Machines

• Generic: endpoint/network independent• High level: coarse-grained and high level events

(yields simpler state machines)• Three ways of service manipulations

– Simple preference specification (simple redirection services)

– Extending the basic state machines through more complex preference specification (sophisticated redirection services)

– Introduce new service endpoint through unified IAP interface (e.g., billing agent to achieve pay-per-view)

Formal Verification of the State Machines and Protocol

• Model checking: given a transition system, written in some system description language (Esterel, I/O automata), whether satisfy certain system invariants or progress properties in some formal languages (temporal logic).

• Use Mocha (a model checker): components represented in final-state models in Reactive Modules

• Property checked: progress.

System Interface for Service Creation

• Customizable event handler in the basic call state machine (trigger point in IN)

• Parameters for condition spec at each customizable event handler (e.g., caller ID, callee ID, calling time, location)

• System primitives: invite, leave, put-on-hold, indicate urgency, send(msg)

• Registration of new events in terms of parameters, new event handlers in terms of system primitives (must understand the basic call state machine to insert state machine)

Preference Specification

• Condition-action pairs– condition in terms of system parameters

• all system parameters categorizable, mostly set operations

– action in term of system primitives

• An principle: callees specify incoming communication preferences, callers indicate wishes.

Preference Specification Issues

• When to specify: offline

• How to specify: a preference spec tool as a web service or an application.

• Feature interaction: – single user feature interaction at specification

time easier to detect in our system than in the IN– non-intrusive feature interaction resolution

challenging, under investigation

Multi-endpoint Services

• New technique of constructing complex services: encapsulating various services behind the IAP interface and participate or monitor ICEBERG communication

• An example: pay-per-view– authentication, billing and distribution agent

(AA, BA, DA) behind IAP– user calls AA, upon success of authentication,

AA invites BA and DA

IN Service Realization in ICEBERG:

An Evaluation• First class services:

– multi-way call, consultation calling, meet-me conference, service handoff (generalized call transfer), one number, personal numbering

• Services through simple preference spec:– call forwarding, originating/terminating call

screening, follow-me diversion

IN Service Realization in ICEBERG:

An Evaluation, Cont.• Services through state machine insertion– call queuing, call gapping, call limiter, call

distribution

• Services through encapsulated applications in IAP:– billing (premium charging, split/reverse

charging), user prompter, customer recorded announcement, call hold with announcement, authentication, authorization