SDP offering a Web Services SOA

Providing IT-using enterprises with applications and services is an untapped revenue stream for the telco [12]. Consequently, a requirement for the SDP is to promote the integration be- tween enterprise and telco infrastructures, that is, support telecom-IT convergence. Hence, the SDP plays a role in generating revenue from enterprises for the telco. To enable this integration, the SDP offers one of its GSOA’s to enterprises. This offered GSOA is the open GSOA. As a result, enterprises may outsource application or service development tasks to the telco. These applications and services are hosted by the SDP. Thus, the telco benefits from promoting itself as a SOA compliant outsourcer to enterprises [119]. The open GSOA must be implemented using web services, such that IT-using enterprises easily integrate with the telco infrastructure. However, the lower GSOAs of the SDP may be implemented using various other technologies. Thus, the open GSOA hides the underlying implementation of the SDP and telco infrastructure from these IT-using enterprises.

Figure 7.7summarises the above scenario of SDP and SOA integration. The figure illus-

trates the SDP integrating the legacy IN Service Control Point (SCP) and new solutions op- erating over packet based telco networks. Also, the SDP provides an “enterprise SOA-like”

PSTN SOA SOA SCP Telco Domain Enterprise Domain Abstraction Complexity IP IP SDP

Figure 7.7: Telco and Enterprise Convergence

environment that enables telco and enterprise integration. The figure illustrates integration of networks being most complex, since they require integration via protocols. However, the figure illustrates integration of SOAs being least complex, since they use simple software- based web services, web service interfaces and ESBs. The figure also illustrates the increase of abstractions from networks to SOA. These abstractions represent services that simplify access and usage of telco infrastructure functions.

7.6

Summary

In this chapter we presented contributions of current a enterprise platform standard to the SDP and its framework. We reused generic concepts from the SOA standard. These con- cepts where extracted from the web services and enterprise SOAs. By reusing these con- cepts we defined a SDP business model, reference model and architecture. In both SDP business model and reference model we separated telco infrastructure according to its func- tions. We also defined reference points to formalise integration of these functions with ex- ternal IT-using enterprises. We defined a SDP architecture from both SDP business model and reference model. The SDP architecture represents the collective of diverse services. Each of the services expose interfaces that implement reference points. To structure the architecture’s services and interfaces across layers and domains, we use the GSOA. We defined the GSOA by extracting technology independent concepts from the various SOAs, such that implementation technologies and distribution mechanisms may be chosen and not imposed. The GSOA represents containers for services and applications. Applications or- chestrate service interfaces. The GSOA abstracts service and application distributions by using its distribution plane as middleware. Therefore, by reusing generic SOA concepts we presented technology neutral abstractions and an architecture that contributes to the SDP framework.

Chapter 8

Perspective on the SDP from a Converged

Standard: IMS

The telco network is a complex and distributed mass of transport links, service platforms, management systems and business solutions. Many network parts are implemented using telecoms’ standards and technologies. Also, network parts may be proprietary solutions obtained from vendors. With progressive changes in technologies, standards, vendor so- lutions, customer requirements and telco business requirements the telco network continu- ously evolves. This evolution occurs within stages that define specific requirements. The result of satisfying each stage and its requirements is the decomposition of the telco net- work into various functional entities [120]. The evolution of the telco network is illustrated in Figure 8.1.

The telco network started with processor controlled PSTN switches. The switching hard- ware was tightly couple with service logic. This coupling limited service creation and pro- vision. As a result, the first evolution stage required quick service creation and provisioning. As a result, the IN and CAMEL standards are defined. These standards define a distributed service platform, containing generic and reusable service building blocks used in service creation. Also, the standards define network functions required to support these building blocks. The network functions abstract the underlying network resources and capabilities. The second stage aims to overcome IN/CAMEL limitations, so as to further improve ser- vice creation and provisioning. As a result, standards-based service platforms such as TINA were defined. TINA defines generic reusable software-based components that are used for customer service development. Also, TINA offers managed access of their components to external 3rd parties. Thus, both telco and external partners may host customer services. TINA components operate across middleware that was implemented by computing plat- forms. These computing platforms abstract access to network resources and capabilities.

E v o lu ti o n ( S e rv ic e P la tf o rm s ) Time IN TINA Softswitch Parlay Parlay X (SOA)

IMS Service Layer

SDP Not Standardised

Manage telecom-IT Convergence

Figure 8.1: Evolution of Telco Network

The third stage aims to support interoperability between heterogenous transport networks, such as telco transport networks and the Internet. To fulfil these requirements, the softswitch standards are defined. The softswitch decomposes the traditional switch into functional en- tities that promote protocol and media conversion between telco networks and the Internet. For example, telephony services can originate and terminate on both telco network and In- ternet. The softswitch functional entities also promote the development of standards-based service platforms, such as Parlay and Parlay X. Services supported by service platforms may use softswitch capabilities to invoke common telco network facilities. Also, by using softswitch capabilities services may be delivered across telco networks and the Internet. The fourth stage requires the convergence between telco, Internet and IT-based enterprise networks and services. As a result, the telco deploys packet-based networks that incorporate standard-based Internet protocols, such as IP. Also, [121] defines the IP Multimedia Subsys-

tem (IMS)[24] standard. The IMS further decomposes the telco network and softswitch and

introduces new functional entities that communicate using standard Internet protocols. The functional entities support new, old and current service platforms, such as SIP application servers, IN/CAMEL and Parlay gateways.

The current evolution stage aims to fulfil previous stages’ requirements but centres on ser- vice platforms, like the SDP, that access and use the IMS network functions. Hence, the current evolution stage aims to structure and standardise the SDP while reusing existing network standards. In the following sections we discuss the IMS and its contribution to the definition of the SDP and its framework, with the objective of uncovering abstractions that constitute a technology neutral SDP architecture.

8.1

Requirements

The IMS is standardised by [121] and focuses on the evolution of the mobile telco and its network functions into a multimedia communication system. The IMS also evolves network functions to support mobile telco and Internet interoperability by using Internet protocols. The network functions support call/session signalling, transport network interworking, re- source management and invoking service platforms. The network functions also support the delivery of IP multimedia services across the mobile telco’s packet-switched network. However, by removing some of the network functions and their terminal mobility capabil- ities the IMS may be used in the fixed telco network. Thus, the IMS is applicable across both fixed and mobile telco networks.

The IMS is a packet-based network that is overlayed onto existing packet bearer networks. It integrates with existing telco networks, such as the General Packet Radio Service (GPRS) access network. It uses the GPRS network functions to enable customer access to the IMS. The IMS decomposes most of the remaining telco network functions, to offer more specific functionality. For example, the IMS extracts capabilities from the softswitch and defines additional signalling and media gateway functions. The IMS supports telecom-Internet interoperability by integrating Internet protocols into telco network functions. For instance, SIP, Diameter, HTTP and other Internet protocols are used by the telco network functions. The IMS provides functions to support customer mobility between various circuit-mode networks and packet-based networks that are controlled by different network operators. The IMS functions also support service, customer and network signalling. Other limited IMS mechanisms contribute to end-to-end quality of service negotiations, charging, security and customer service subscription management. Thus, the IMS is considered a signalling overlay network that provides functions contributing to the overall operation of the telco network and delivery of services to customers.

The IMS aims to satisfy customer, service and network requirements [122]. For instance, the IMS supports customer access, registration and mobility. Also, service requirements include subscription management, access control, session control, service interworking and addressing. Network requirements include supporting service requirements, customer mo- bility and network interworking. Other requirements and IMS properties, as defined in [123], include:

• logical separation of signalling transport from bearer transport;

ISC Mi Cx Sh,Si Mg Gm Rf Rf Rf Bi Application Server BGCF HSS MGCF UE CSCF CCF OSS BSS

Figure 8.2: Simplified Portion of the IMS Reference Model

• non standardisation of customer services, rather customer services are developed by numerous external developers;

• multimedia services based on session control over IP;

• logical and physical separation of domains, such as home and visited network do- mains;

• physical mobility management provided by the access network, while the IMS com- ponents manages mobile users seamless access to their home network services; • provide application servers that are internal and external to the telco; and

• online and off-line charging, where a customer may be billed based on various aspects of the service usage, such as service type, session period, media usage and terminating party.

As described in [24], the IMS defines various functional entities by decomposing telco net- work elements and integrating them with Internet technologies. Some of the functional entities are shown in Figure 8.2. We describe these and other functional entities in Sec- tion 8.2.1. The functional entities abstract complexities of using legacy and new transport networks, signalling networks, data stores, service platforms and OSS/BSS. In addition, these functional entities communicate amongst each other to fulfil IMS requirements. The collection of these functional entities and their interactions are structured within a reference model. The reference model formalises complex relationships between functional entities using reference points. The full IMS reference model with reference points is given in [123]. A simplified portion of this reference model with reference points is shown in Figure 8.2. With decomposition of the functional entities and reference points, IMS architectures are defined.

8.2

Architecture

We represent an IMS architecture using two separate models. The first architecture, shown in Figure 8.3, structures all the IMS functional entities defined in [123]. The functional entities include those shown in Figure 8.2. The second architecture, shown in Figure 8.4, structures a service platform architecture for the IMS.