In Search of a Service Platform for ICEBERG Helen J. Wang ISRG Retreat, January 2000

ICEBERG Service Categorization Category 1: Internet services from any terminals: web access, Jukebox, any automated services (including some 800 services) Category 2: Call processing services: call processing customization such as call forwarding, call waiting, etc.

Service Platform [Gbaguidi, et al.] Platform for service engineering: service design, development, creation, testing, operation, provision, management and termination Platform requirements –network/operating system independence –reusable components –mapping of service components onto the system infrastructure. –User friendly GUI for creation/management/operation –generality and expandability to novel service creation

Intelligent Network Separate service logic from basic call processing (open interface in switches) Triggers in SSP to SCPs SCE: service = f (SIBs) First to view services as interactions among software components Weaknesses: –Standardization of BCSM failed (still closed). ? –Huge, fault tolerant SCPs (mainframe mentality) for millions of subscribers -- a slow rate of deployment and evolution –Poor integration between fixed and mobile telephony services (?) –high cost-of-entry, limited to highly capitalized network operators

Hybrid Services Approach [Gbaguidi, et al. 99] Basic approach same as IN: trigger, SCE, building blocks are Java beans, generic service components SCE: convert services into components to be uploaded into the system infrastructure; support specific protocols uploading to the elements that require specific communication Java service layer: middleware, Java beans + binding and integration of various of Java beans Any new service needs specialization per network per service -- not desirable

HP Service Architecture [Rizzetto, et al. 99] Approach: network independent service environment, service platform provides common functionalities. Network provides the events, users design their service logic (service object) including their preferences or policies (require careful analysis of the language) downloaded from home server Generic net events: need to identify commonalties between existing and emerging communication paradigms: registration, admission, call signaling

SIP “Services are ultimately realized through Internet telephony signaling protocols” -- refer to the call processing services Same trigger approach as IN CGI for trusted user service creation/execution CPL (XML-based) for the untrusted, condition/action pairs. Service logic run on server or else where.

Facilitators for ICEBERG services Signaling basic call service (multi-device call) primitives Automatic Path Creation Preference Registry Personal Activity Coordinator ICEBERG Service Platform: systematic way of interacting with the signaling, APC, PR, and the PAC.

Initial Thoughts Category 1: –virtual IAP (one for all) for the Internet services to make them behave like ICEBERG endpoints. Category 2: –define observable events (customization points or trigger points) from the system (defines when the PR or PAT needs to be checked) –use compiler techniques to eliminate standardization –service logic using the APC