Software interoperability in the NGN Service layer Dave Penkler CTO OpenCall, HP 2004 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice
Presentation Outline Why Software Interoperability for NGN Preliminaries NGN Service layer Software Portability versus Interoperability Protocols versus API s APIs and Protocols in the service layer Conclusion 6/26/2007 HP 2
Why Software Interoperability for NGN Interoperability from the user s perspective: Ability to create, use and share information and services on different devices with software from different vendors over multiple networks and service providers. The value is in the applications Application innovation happens elsewhere: Standard developers can hardly anticipate all useful applications and business models The cost, complexity and delay incurred by striving for convergence at the protocol level will likely kill aspiring NGN business cases. Programmability of the network = Application innovation for NGN Clear separation of network and application functionality Defining abstractions of network capabilities as software interfaces The interface specifications are open and implementations testable for interoperability Software functions can be invoked transparently across the network Restore end to end transparency: protocol & SW interoperability 6/26/2007 HP 3
Next Generation Architecture Adapted from ITU-T FGNGN-FRA Common Service Infrastructure (e.g. IMS) Management Customer UNI Application Interface Resources & Capabilities I/F User Profile Access Service stratum Attachment Control Access Access functions stratum Service and Control Edge Control Application Core Core functions Media Handling Service User Profile Gateway NNI Other Other networks networks Access Independence Control Media Management Independence 6/26/2007 HP 4
Software Portability vs Interoperability Software portability Code that can be deployed and executed on different systems with the same behaviour Source code: portability ensured by compiler and libraries Binary code: portability ensured by application binary interface code: (Code that can be sent over a network and executed at the destination) portability ensured by run-time environment (eg: Java, ECMAscript, XML scripts) Software interoperability Code developed to one side of an interface specification that can interact as expected with heterogeneous implementations the of the other side either locally or remotely. 6/26/2007 HP 5
Application Programming Interfaces vs Protocols NGN supports the delivery of end-user services through application servers, rather than directly embedding services as capabilities in the control protocols Protocols define what bits are sent on the wire between 2 entities Technology neutral. APIs are defined in terms of the operations and data-structures exchanged between 2 software entities either locally or remotely. API s are implemented as a service interface to protocols or as a higher level interface usefully combining a number of lower level or remote peer functions. Applications interact with users, network resources and with one another through API s NGN and IMS standards development is primarily done at the protocol level. Adopting all IP and IETF protocol standards is not enough to enable end to end network transparency. SIP protocol specs for IMS are already horribly complicated Web Services: A viable technology neutral way to define interfaces and achieve software interoperability over the network. 6/26/2007 HP 6
API complexity trade-off Level of Abstraction Level of Expressivity of API Number of Programmers Application Programming Simplicity Implementation Complexity of API Application Service Enabler API Service Building Block API High Level Protocol API Low Level Protocol API Protocol Implementation Remote Invocation Application Function Middleware 6/26/2007 HP 7
APIs and Protocols in the Service Layer External ASPs & IT Application Layer Resources applications and capabilities, exposed via XML and Web Service interfaces (e.g. ParlayX, OMA web services). Interactive Voice & Video Applications Media Processing, Media Control, Media Storage Applications in service provider and terminal domains Resources & Capabilities exposed as API s or protocols Identity Management Authentication Authorisation Instant Group Communication Applications Subscriber Profile Management Next-Generation Messaging Applications Billing & Rating User Information Management (presence, contact list, location) Frameworks for Applications Device Capabilities Common frameworks for service provisioning and management Core IMS Core Circuit Switched Core Packet Switched Core 6/26/2007 HP 8
Conclusion To enable innovation the NGN must be programmable from the edge. Expose network resources, capabilities and applications as standard API s End to end network transparency Simple protocols Facilitate protocol and software interoperability User expects things to work the same everywhere Software interoperability is key necessary but not sufficient 6/26/2007 HP 9
6/26/2007 HP 10