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 Switch Service Logic 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