Programmable Architecture for the Creation and Seamless Control of Hybrid Services

1. Programmable Architecture for the Creation and Seamless Control of Hybrid Services Constant Gbaguidi Swiss Federal Institute of Technology (Lausanne)

2. Outline • Problem Statement • Need for a creation and control architecture, with well-defined service components • Our approach • Service-centricity, as opposed to network- and end-system-centricity • Programmability: changing the behavior of a system through an API • Smooth migration from existing infrastructures to more “futuristic” ones • Use of tools that can be understood by Telecom as well as Internet people • Case studies • Voice-Access-to-Content, Closed User Group (CUG) • Related Work • Conclusion

3. Scope of Hybrid Services Internet services Telecommunication services • Hybrid services are not re-implementations of existing services • They allow access to services already implemented on either telecommunication or IP networks • They allow unique implementation of services, which can still be accessed from any network • They pave the road to the provision of future services that do not rest on only one network Hybrid Services Conference Internet VPN Email and Voicemail Chat (IRC) Content services (Web) Electronic commerce Conference IN VPN Voice Mail Call Forwarding Mobility Voice Access to Content Telecommuting Teleconference Integrated VPN

4. Freephone service logic IP network PSTN Callee H.323 gateway Caller Problem Statement • How to create and control hybrid services? • Control: • Provision of a service binding layer that permits passing service control information across networks (Today we have interoperability at the media transfer and media control layers) • Creation: • Specification of components out of which services can be built (The components must make sense to both Telecom and Internet communities) • Mapping of the components onto the service system elements

5. An Overview of Our Solution Service Creation Environment Java Service Layer Programmability API Internet Cellular Network PSTN (and N-ISDN) API: Application Programming Interface

6. Service Creation Environment An Overview of Our Solution (cont’d) Java Service Layer Programmability API Gateway Terminal Network Node Control Server IN Service Ctrl Point H.323 gatekeeper DHCP server DNS Switch Router Wireless LAN Node GSM Base Station H.323 gateway Firewall Workstation Smart phone API: Application Programming Interface

7. SS SS SS SC/S1 SC/S2 ST/S1 ST/S2 SN/S1 SG/S1 Service binding Service binding Service binding Service binding Architecture of Our Solution CT/Si: Subsystem on Terminal for Service #i CN/Si: Subsystem on Network node for Service #i CC/Si: Subsystem on Control server for Service #I CG/Si: Subsystem on Gateway for Service #i SS: Service Subsystem Beans Archive Service Creation Environment Service Factory 1. Identify service components Service Instance 2. Download the components Controller Controller Controller Controller Java Service Layer 3. Build the binding layer Gateway Terminal Network Node Control Server

8. Key: Object class Service Customer defines * Inheritance Composition Association class Feature interacts with involves User Interaction Call control Charging Connectivity Security Address Translation 1. Service Modeling: A Way to Identify Components • A Service is composed of features, each of which is associated with an object model. Classes in the models are the sought components

9. End-system 1. Example: Address Translation Key: • End-system is a generic concept that embraces terminals, gateways, information converters, multipoint control units, etc. • The user makes use of a device (e.g., a Smart Card) that has an address • The user may have a higher level address (e.g., email address) • The user can bind addresses with one another Object class Inheritance Device Address Device Composition has 1 1 Association class * uses 1 Address Binding User Address 1 * manages 1 1 has Device Address User Address * User Address

10. SS SS SS SC/S1 SC/S2 ST/S1 ST/S2 SN/S1 SG/S1 Service binding Service binding Service binding Service binding Architecture of Our Solution CT/Si: Subsystem on Terminal for Service #i CN/Si: Subsystem on Network node for Service #i CC/Si: Subsystem on Control server for Service #I CG/Si: Subsystem on Gateway for Service #i SS: Service Subsystem Beans Archive Service Creation Environment Service Factory 1. Identify service components Service Instance 2. Download the components Controller Controller Controller Controller Java Service Layer 3. Build the binding layer Gateway Terminal Network Node Control Server

11. 0. put persistent component c: C on server Web server 2. Component Download Service instance 1. execute(C c, URL url) 2. get c Controller 3. configure underlying element

12. SS SS SS SC/S1 SC/S2 ST/S1 ST/S2 SN/S1 SG/S1 Service binding Service binding Service binding Service binding Architecture of Our Solution CT/Si: Subsystem on Terminal for Service #i CN/Si: Subsystem on Network node for Service #i CC/Si: Subsystem on Control server for Service #I CG/Si: Subsystem on Gateway for Service #i SS: Service Subsystem Beans Archive Service Creation Environment Service Factory 1. Identify service components Service Instance 2. Download the components Controller Controller Controller Controller Java Service Layer 3. Build the binding layer Gateway Terminal Network Node Control Server

13. 3. Service Binding Layer Element { openConnection, pauseConnection, resumeConnection, releaseConnection, bindConnections, transferConnection, handleEvent } Binding components (e.g., security, download) Java RMI Enterprise components (e.g., RMI<->CORBA, EJB) System element interface e.g., TAPI, CallPath API, SS7 API, IN API Element

14. Inheritance Element Network Node Gateway Terminal Control Server 3. A Way to Interface with Elements Java Service Layer Interruptions, APIs, SNMP, H.323, IN Element Trigger-Event-Listener (implements methods to handle the events caught) Trigger-Event-Source

15. 3. A Way to Interface with Elements (cont’d) 3. fires TriggerEvent Listener CnxAttempt Event 7. goes to 4. goes to 8. creates ConnectionBinding CnxCompleteEvent ConnectionFactory Java Service Layer 6. fires 5. creates 7. goes to 6. fires Connection CnxFailEvent 2. goes to TriggerEvent 1. fires Service component Event Source Element Event

16. SS SS SS SC/S1 SC/S2 ST/S1 ST/S2 SN/S1 SG/S1 Service binding Service binding Service binding Service binding Architecture of Our Solution CT/Si: Subsystem on Terminal for Service #i CN/Si: Subsystem on Network node for Service #i CC/Si: Subsystem on Control server for Service #I CG/Si: Subsystem on Gateway for Service #i SS: Service Subsystem Beans Archive Service Creation Environment Service Factory 1. Identify service components Service Instance 2. Download the components Controller Controller Controller Controller Java Service Layer 3. Build the binding layer Gateway Terminal Network Node Control Server

17. Java Service Layer PABX controller Term. controller GK controller H.323 GK Siemens Hicom 112 IP Network ISDN BRI PABX H.323 GW RADVision Elemedia H.323 stack Implementation Test-bed • + Most elements of the test-bed can detect special services, by detecting prefixes in the numbers dialed • - APIs existing on the elements are not easily customizable from an application

18. Voice-Access-to-Email Java Service Layer Server controller PABX controller GK controller H.323 GK Siemens Hicom 112 IP Network ISDN BRI PABX H.323 GW Accommodating server RADVision Email server

19. Voice-Access-to-Email (cont’d) • Start retrieving the mails : Email Retriever • As long as nothing has come • play waiting message : User Interaction • Parse the received mail : Email Parser • remove useless header fields (e.g., route information) • remove useless tags (<FONT>, <BODY>, etc.) • Convert the parsed file into speech: Microsoft Speech API (Java wrapper, JNI) • Play the speech file over the network: Elemedia H.323 stack • ~30s to read an email

20. Voice-Access-to-Email (cont’d) Application H323 Call factory User Interaction Incoming H.323 messages Email Retriever Email Parser Email Server Outgoing H.323 messages Text-to- speech Converter Call instances

21. Voice-Access-to-W3 Application H323 Call factory User Interaction Incoming H.323 messages Web site Retriever HTML Parser Web Server Outgoing H.323 messages Text-to- speech Converter Call instances

22. Voice-Access-to-W3: HTML Parser • Replace a link by an announcement like “Press 234 if you wanna learn more about this topic” • Remove applet information • Remove scripts • A dedicated language would be a suitable solution but then all pages would have to be re-written!

23. Closed User Group Feature: Confidential information passing between F and C while in a session with A, B, D and E Java Service Layer Term. controller CUGS controller H.323 GK IP Network Siemens Hicom 112 ISDN BRI PABX H.323 GW RADVision CUG Server F E C D A B

24. Learnings • The proposed architecture can be used to enhance the service offerings of current platforms • To fully take advantage of the architecture, we need APIs for the platform elements • Service composability within the architecture has been illustrated • Java is a good candidate

25. Internet VideoSvc Hop Store ClientPeer e e e ClientPeer Gate Gate Securetrusted-domainboundary Gate Core Gate ClientPeer Gate Gate Gate Gate Hop ConsumerNetwork Hop TelephoneNetworks Extended Network Related Work in the Internet • GeoPlex (AT&T) • 5 programmable elements: • Cores: mission-critical databases and functions • Hops: e.g., routers • Gates: entrances to the GeoPlex network • Stores: directories, event reports • Peers: GeoPlex-enabled devices • Internet-dependent, although some of the APIs can be re-used for other elements Our solution is more generic and applicable to all technologies

26. SCP SSP SSP Related Work in Telecommunications • Intelligent Network (IN) • dumb terminals • services as compositions of functional building blocks • service logic controlled by Service Control Points (SCP) • no service creation environment standardized • building blocks are heavily defined • limited distribution (functional approach!) (1) We propose a service creation environment based on a platform-independent language (i.e., Java) (2) We use an object-oriented technique to find and specify service components

27. Serv. Sess. Mgr Net. Cnx Mgr Net. Elt. Mgr Net. Elt. Mgr Computational object Related Work in Telecommunications (cont’d) • Telecommunications Information Networking Architecture (TINA) • goal: enhance the IN with distributed processing and integrate service provision and management • heavyweight connection management (connection-oriented networks) • building of service logic not emphasized Our solution provides a simple connection model and a technique to determine generic service components

28. Related Work in Telecommunications (cont’d) Serv. Sess. Mgr • XBIND (Columbia University, NY) • same objectives as TINA, but with a service-centric vision: programmability of end-systems considered • ATM-oriented • lack of a service model Net. Cnx Mgr Device Mgr Net. Elt. Mgr Display Mgr Net. Elt. Mgr Camera Mgr (1) Our solution is both past- and future-proof: no specific technology in mind (2) We provide a service model that helps find service components using an object-oriented technique

29. Related Work on Hybrid Services • Computer-Telephony Integration (CTI) • goal: be able to place and control telephone calls from a computer • “IN” for corporate networks • deployment at the edge of the network, e.g., in enterprise networks: complex services need also to look into the network Our solution enables CTI to look into the network in order to implement sophisticated services CTI Link PABX

30. Web server Internet (HTTP/CGI) IP PSTN SCP SSP SSP PSTN Related Work on Hybrid Services (cont’d) • PSTN and Internet Interworking (PINT) • enable a telephone call from an IP terminal to the PSTN • data is transported over the PSTN • no service control from the initiating IP terminal • (1) Our solution extends data transport to any network, not only the PSTN • (2) Service control can be performed from the IP network

31. Summary • Legacy systems are unlikely to disappear overnight: the future will be hybrid • Main contributions • Thorough assessment of the benefits in integrating Telecoms and Internet • A service-centric and programmable architecture • A method for determining service components • A method for interfacing with service system elements, including existing networks and mechanisms • We provide a unified way to interface with existing networks • Our method enables smooth introduction of new services

32. Summary (cont’d) • Future directions • Inter-provider interface • how to make service control layers of different operators talk to one another? • Management • how to manage the behavior of a service? • how to allocate resources for a service and control this allocation? • how to solve feature interactions? • Performance • what do we need to do in order to build a system that performs as reliably as the PSTN?

33. Summary (cont’d) • Future directions • Extension to wireless networks • what are the effects of the characteristics of wireless networks on the design of the components? Java Service Layer BSS Software Radio

34. References • J. P. Hubaux, C. Gbaguidi, S. Koppenhoefer and J. Y. Le Boudec, “The impact of the Internet on Telecommunication architectures”, Computer Networks, Feb. 1999 • C. Gbaguidi, J. P. Hubaux, G. Pacifici and A. N. Tantawi, “Integration of Internet and Telecommunications: An architecture for hybrid services”, JSAC, Sept. 1999. • C. Gbaguidi, J. P. Hubaux, M. Hamdi and A. N. Tantawi, “A programmable architecture for the provision of hybrid services”, IEEE Comm. Mag., July 1999. • C. Gbaguidi, S. Znaty and J. P. Hubaux, “Multimedia resources: An information model and its application to an MPEG2 video codec”, JNSM, Sept. 1998.