Ericsson contribution to the W3C Workshop on Web Services

Nilo Mitra

Ericsson, Inc.

nilo.mitra@ericsson.com

 

Background & Motivation

It is noteworthy that public telecommunications network operators are not able to provide services at quite the rate that was envisioned when the so-called Intelligent Network (IN) standards were defined. This is in sharp contrast to the scale at which innovative services are available over the Internet/WWW. At the same time, there are third parties that wish to access and make use of the intelligence already available in telecommunications networks to provide innovative services. An example would be the recent surge of interest in location-based services, where new services can be made available if a mobile/wireless end user’s location is made available. Such third parties would provide value-added services built on top of generic services provided by networks, such as the ability to provide end user authentication, usage recording, billing and connection control (e.g., switching, routing, tones and announcements etc.). This provides for quicker, and presumably cheaper service delivery, whilst reassuring network operators that they retain a share of the pie without losing their privileged customer relationship.

Several complementary concerns and trends suggest the need to find alternative techniques for developing services for telecommunications networks of the future. These include:

To alleviate these concerns, a new model for services for telecommunications is being developed which permits the flexible distribution of service control capabilities between end points, the network and third party service providers. Such a model allows a more flexible tri-partite sharing between the needs and capabilities of the end user, the telecommunications network, and third party service providers who need access to network intelligence to offer services to end users.

Rather than design such an infrastructure from the bottom-up using low-level, message-based interfaces, which is the current approach, the newer models for service delivery are designed as a distributed computing platform onto which common capabilities are pushed, and which is accessed by applications using standardized or open interfaces. Web-based access to and delivery of services is, of course, one of the prominent mechanisms that is anticipated. The new paradigm for developing and deploying services in a telecommunications network is shown in Figure 1.

Fig 1. Layered Network Architecture for Future Telecommunications Networks

 

Other Industry Efforts

The PARLAY APIs are designed by the PARLAY consortium [PAR] to provide open but secure and controlled access to network resources. The APIs are not language or platform specific and are actually UML-generated interface definitions, which would make CORBA IIOP, or Java RMI, or indeed W3C’s XML Protocol (when mature) the means to inter-work language and platform dependencies between the 3rd party and the network. The PARLAY APIs abstract away the network-specific details. Thus, an operation from a 3rd party to the network to connect a call to a given address does not require the application to know the underlying signalling mechanisms used in the network.

Fig 2: The PARLAY APIs

 

Open Service Architecture (OSA) is an initiative within the 3rd Generation Partnership Project (3GPP) [3GPP] for defining new services for Universal Mobile Telecommunications System (UMTS), the 3rd generation mobile networks. Ericsson is one of the main drivers behind the OSA concept in this standardization arena.

The basic idea of OSA is that in order to develop "personalized services for the masses" quickly and easily there must be open standardized interfaces that enable third party development of services. In the UMTS network architecture the Service/Application Layer may be realised as a separate network, the Service Network. This Service Network must allow for fast and easy creation and deployment of new and personalised applications/services. Figure 3 shows the architecture of the OSA in UMTS.

 

Fig 3: OSA interfaces for UMTS

At the border between the core network and the Service Network one finds application enablers (Service Capability Servers). The applications (running on Applications Servers) implementing the services offered to end-users are located within the Service Network. The Service Capability Servers and the Application Servers are interconnected over an IP-network, which allows for a distributed deployment these functions. In order to implement this Service Network, a highly flexible and open service architecture is being defined that offers the following capabilities:

In addition, Ericsson in 3GPP is championing the concept and standardization of the Virtual Home Environment (VHE). VHE is defined as a concept for personalised service portability across network boundaries and between terminals. The concept of the VHE is such that users are consistently presented with the same personalised features, user interface customisation and services in whatever network and whatever terminal (within the capabilities of the terminal), wherever the user may be located.

Views on the role of XML Protocols & related areas in Service Networks

The last two sections have outlined recent developments in telecommunications service architectures, an area of utmost importance to Ericsson and its customer base.

Ericsson views the Service Network as a deployment of machines/applications interconnected over an IP-based network with the purpose of providing services to a variety of players, e.g., end users, independent 3rd part service providers , and management and business support systems. A Service Network is owned by a service provider such as a mobile operator, an ISP, a portal etc.

Ericsson expects to see the use of W3C standardized protocols like XML Protocol (XMLP) in Service networks, as one of many interoperability mechanisms that need to be supported. We view XMLP (or its precursor, SOAP) as one of several interoperability mechanism. Others are CORBA’s IIOP or, where appropriate, Java RMI.

XMLP would of course allow third party products/solutions to be integrated into Service Network solutions without as tight a coupling as prescribed by the OSA/Parlay specifications. However, the reason for choosing a CORBA-based approach for OSA/Parlay needs to be emphasised: the portability of applications as enabled by a standardized interface definition (OMG IDL by choice) is as important a motivator as interoperability at the wire-protocol level.

Thus standardized mappings of IDL based interface definitions onto XML schemas would be particularly useful, and the W3C is encouraged to work on this aspect, in close cooperation with the OMG.

Figure 4 shows the role of XMLP vis-à-vis other interoperability mechanisms supported by a common contract description as defined for Service Networks.

Fig 4: XMLP in Service Networks

One of the most important aspects of the Service Network will be the concept of the Home Environment, which will be a convergence point for the user’s telecom services, Internet services and content based services. Thus, an essential part of the Service Network is to host a respository of end user profiles. Data in such repositories would consist of common user-specific information (e.g., names/aliases, various types of contact addresses), lists of subscribed-to services, and terminal profiles. Further servic-specific information would include service preferences (e.g., call forwarding numbers, personal address book). In addition, services may need access to service data to be able to complete the service. Such service data could be content (e.g., bus time tables, TV listings, weather information, maps).

XML-based protocols (and, in particular, XMLP) seems an attractive choice for the personalization of end user services, i.e., accessing and manipulating user data as well as service data. It can also be a tool for end user service discovery/browsing, and subsequent subscription and access to services. Initially, services will be much like traditional telecom services such as updating a user’s inbound call management capabilities, albeit with a more easily manipulable user interface. Soon though, one expects an integration with the Web, such as embedded links in HTML pages to set up calls, or responses to traditional "busy" signals being a web page or email with descriptive (possibly multimedia) information.

The use of XMLP for transfer of profile information needs to be investigated.