Technical Information Service Oriented Architectures for

Technical Information

Service Oriented Architectures for convergent Service

Delivery Platforms

Applying Service Oriented Architectures to Service Delivery Platforms

Authors:

Nuno Silva, Marco Monteiro, Sancho Rego,

Herlander Jorge

Atsuyoshi Shirato

Portugal Telecom Inovação

NTT Japan

Ferenc Telbisz, Balázs Gódor

Sune Jakobsson

Alan Ryan

Sophie Cherki, Benoît Pillet, Pierre-Arnaud Muller France Télécom Group

Editor:

Pierre-Arnaud Muller, France Télécom Group

Magyar Telekom Telecommunications Plc.

Telenor ASA eircom

Abstract

SDP is a new architectural approach intended to enable the rapid development and deployment of new converged multimedia services in a less expensive and simpler way. SDPs should typically provide a service creation environment, service execution and management environment, and abstractions for media control, presence/location, integration, and other low-level communications capabilities. The telecommunications industry has recognized the need for an SDP, particularly, one that conforms to industry standards and is built on a standard architecture.

SOA will radically change the way business processes are automated and implemented in software, how migration of physical world processes are turned into digital services. SOA is much more than implementing an “Integration bus” or some other means of distributed deployment of software.

SDP’s will play a key role in this landscape, by providing the execution environment for a lot of the processes involved.

After an overview of what an SDP is, this document goes into details regarding the applicability of

SOA to SDPs.

EDIN

Project

0532-1652

P1652

For specified purposes

December 2006

Eurescom participants in project P1652 are:

• Portugal Telecom Inovação

• Magyar Telekom Telecommunications Plc.

• Telenor ASA

• NTT Japan

• eircom

• France Télécom Group

[Project title] Service Oriented Architecture for convergent Service Delivery Platforms

[Document title] Applying Service Oriented Architectures to Service Delivery Platforms

Editor: Pierre-Arnaud Muller, France Télécom Group

Project leader: Nuno Silva, Portugal Telecom Inovação

Project supervisor: Anastasius Gavras

Eurescom published project result; EDIN 0532-1652

 2006 Eurescom participants in project P1652

Disclaimer

This document contains material, which is the copyright of certain Eurescom PARTICIPANTS, and may not be reproduced or copied without permission.

All PARTICIPANTS have agreed to full publication of this document. However this document is being released to support the work of the TC5 committee in 3GPP/ETSI.

The commercial use of any information contained in this document may require a license from the proprietor of that information.

Neither the PARTICIPANTS nor Eurescom warrant that the information contained in the report is capable of use, or that use of the information is free from risk, and accept no liability for loss or damage suffered by any person using this information.

Eurescom project report page 3 (80)

Preface

Along with the IP Multimedia Subsystem (IMS), one of the most recently talked about topics within the Telecom/IT industry community is the subject of Service Delivery Platforms (SDPs).

These platforms aim to enable telecom operators providing a complete environment for creation, deployment, execution, management and billing for a wide range of value added content and services. Services deployed using these platforms will be agnostic to the underlying network technology. In addition, SDPs aim to open up the operators’ network in a secure robust manner such that 3rd party application developers can provide a potentially vast array of content and services to the operators subscribers.

Many of the capabilities needed to build these new services are scattered among different Service

Delivery Platforms (SDPs): real-time charging, location, presence, buddy list management, streaming, etc. The challenge we face is how to expose these capabilities of the different platforms, and access them in a uniform way to compose new services. From the perspective of a developer

(internal or 3rd party), the problem can be viewed as the need to integrate the different architectures that govern enterprise and communication environments, an important consideration, given the convergence of content and the traditional telecom environment.

This requires a new, more flexible, architecture and a common communication framework that will support interoperability between these two diverse worlds. A leading approach is to use a Service

Oriented Architecture (SoA), with XML/WSDL as the underlying communication framework. SoA is a software architecture involving loosely coupled, location independent services generally using the so-called "find-bind-execute" paradigm for the communication between SoA service providers,

SoA service users and a SoA service registry. Any given service may assume a client or a server role with respect to another service, depending on situation. An essential characteristic of an SoA is that it provides published contract-based, platform and technology neutral service interfaces. This means that the interface of a service is independent of its implementation. In practice, interfaces are defined using ubiquitous IT standards such as XML, HTTP, SOAP, and WDSL. Major goals of an

SoA in comparison with other software architectures used in the past are to enable faster adaptation of software to changing business needs, cost reduction in the integration of new services, as well as in the maintenance of existing services.

From this background this study aims at reviewing the important enabling role that Web Services technologies play in an SoA implementation, and examine how an SoA can change the way new services are created, both from the technical and business perspectives. Furthermore the study examines how service orchestration enables operators to easily bring together components in SDPs and external systems intelligently to deliver services to the users and finally to identify the challenging issues and impacts of introducing an SoA at the Service Layer;

The study P1652 “Service Oriented Architectures (SoA) for convergent Service Delivery Platforms

(SDPs)” started in June 2006 and concluded in December 2006. The study was executed with an overall resources of 14 person-months and the participants were Portugal Telecom Inovação, SA,

France Télécom, eircom Ltd., Telenor R&D, Magyar Telekom Telecommunications Ltd. and NTT

Japan. Mr. Nuno Silva from Portugal Telecom Inovação, SA, was leading the study.

This document is the second of two study deliverables.

No Deliverable Title Issue date

D1 – EDIN 0531-1652 Service Oriented Architectures and Telcos December 2006

D2 – EDIN 0532-1652 Applying Service Oriented Architectures to Service

Delivery Platforms

December 2006

 2006 Eurescom participants in project P1652 EDIN 0532-1652

page 4 (80) Eurescom project report

Executive Summary

The telecommunications industry used to be responsible for service development and service deployment, where organizations were effectively controlling how, where and when new valueadded services were created and what kind of technology was used. Services were highly proprietary, often relied on the organizational technology and manageable and understood by a small amount of qualified personnel. This non-efficient method of service development was sufficient for modest times, where the diversity of services was not the main issue, only the capacity of delivering to high numbers of subscribers was important.

The new business model requires that network operators develop new value added services, such as innovate text services, voice and data services, location services, triple play and others, for attracting new subscribers, maintain the existing ones and consequently increase revenues.

Network operators must launch the line of most updated services technology faster than the competition, in a cost-effective and low time-consuming manner. Operators need to be able to quickly deploy an enormous selection of new value-added services, or to provide the means to offer third party developers the capability to interfere or develop new services.

These requirements are met by SDPs (Service Delivery Platforms), entirely based on the principles of SOA (Service Oriented Architecture) and reusability, which aim to provide a highly automated environment that can be reused by all services, providing a single platform for service creation, provisioning, deployment and control. It should shield service developers from the complexities of one type of network, making service bundling easier where voice, data and video services can be combined into compound multimedia services.

This document describes the challenges SOA will bring to the SDP area, and how new actors are already taking this into use. SOA will radically change the way business processes are automated and implemented in software, how migration of physical world processes are turned into digital services. SOA is much more than implementing an “Integration bus” or some other means of distributed deployment of software. SDP’s will play a key role in this landscape, by providing the execution environment for a lot of the processes involved.

EDIN 0532-1652  2006 Eurescom participants in project P1652


Table of Contents

Preface ............................................................................................................................................................... 3

Executive Summary........................................................................................................................................... 4

Table of Contents............................................................................................................................................... 5

List of Figures.................................................................................................................................................... 6

Abbreviations..................................................................................................................................................... 7

1 Introduction................................................................................................................................................ 8

2 Service Delivery Platforms – concepts and principles............................................................................... 9

2.1

SDP Market drivers............................................................................................................................ 9

2.1.1

SDP and IMS ............................................................................................................................. 9

2.1.2

Current state and industry trends.............................................................................................. 11

2.2

SDP Standards point of view ........................................................................................................... 13

2.2.1

OMA ........................................................................................................................................ 13

2.2.2

3GPP ........................................................................................................................................ 19

2.2.3

TISPAN ................................................................................................................................... 21

2.2.4

Web Services Interoperability – WSI ...................................................................................... 23

2.2.5

Liberty Alliance ....................................................................................................................... 25

2.2.6

ITU-T ....................................................................................................................................... 27

2.3

SDP reference architecture............................................................................................................... 28

2.3.1

Service enablers ....................................................................................................................... 28

2.3.2

Service orchestration................................................................................................................ 30

2.3.3

Policy management .................................................................................................................. 33

2.3.4

Service interaction ................................................................................................................... 35

2.3.5

Identity management................................................................................................................ 37

3 Applying SOA to SDPs ........................................................................................................................... 40

3.1

Business Requirements .................................................................................................................... 40

3.1.1

Business objectives .................................................................................................................. 41

3.1.2

Overall benefits of Service Oriented Architecture ................................................................... 42

3.2

SOA Applicability ........................................................................................................................... 42

3.2.1

Service creation........................................................................................................................ 43

3.2.2

Service provisioning ................................................................................................................ 44

3.2.3

Service execution ..................................................................................................................... 47

3.2.4

Service migration ..................................................................................................................... 50

3.3

SOA@SDP use cases....................................................................................................................... 51

3.3.1

IPTV......................................................................................................................................... 51

3.3.2

CRBT ....................................................................................................................................... 52

4 Conclusion / Recommendation ................................................................................................................ 55

References........................................................................................................................................................ 56

Annex A OMA Enabler Releases................................................................................................................ 57

A.1

Candidate Enabler Releases ............................................................................................................. 57

A.2

Approved Enabler Releases ............................................................................................................. 62

Annex B SDP vendor's point of view.......................................................................................................... 69

B.1

Oracle............................................................................................................................................... 69

B.2

IBM.................................................................................................................................................. 70

B.3

BEA ................................................................................................................................................. 70

B.4

Microsoft.......................................................................................................................................... 71

B.5

OpenCloud ....................................................................................................................................... 72

B.6

Mobicents......................................................................................................................................... 73

Annex C Software operators SDP ............................................................................................................... 75

C.1

Google.............................................................................................................................................. 75

C.1.1

Introduction to Google Talk..................................................................................................... 75

C.2

Skype ............................................................................................................................................... 76

C.2.1

Introduction.............................................................................................................................. 76

C.2.2

Technology .............................................................................................................................. 76

C.2.3

Business Offering..................................................................................................................... 77

C.2.4

3 rd

Party Service Development (APIs) ..................................................................................... 77

C.3

MSN................................................................................................................................................. 79

C.3.1

Introduction.............................................................................................................................. 79

C.3.2

Other Features.......................................................................................................................... 80

C.4

Open Source alternatives ................................................................................................................. 80



List of Figures

Figure 1 – Web Services architecture .............................................................................................................. 12

Figure 2 – OSE architecture elements and interfaces ...................................................................................... 13

Figure 3 – PEEM Enabler Architecture ........................................................................................................... 15

Figure 4 – Logical Flows for the PEEM proxy usage pattern.......................................................................... 16

Figure 5 – Logical Flow for PEEM callable usage pattern .............................................................................. 17

Figure 6 – Logical Flow for PEEM policy management ................................................................................. 17

Figure 7 – The main components of the IMS architecture in relation to enablers ........................................... 17

Figure 8 – SIP Interfaces for enablers.............................................................................................................. 19

Figure 9 – Functional architecture for service provision support in the IMS .................................................. 20

Figure 10 – NGN Overview............................................................................................................................. 22

Figure 11 – IMS Core ...................................................................................................................................... 23

Figure 12 – Positioning EAI and SOA ............................................................................................................ 31

Figure 13 – BPM technology for service orchestration in business processes ................................................ 32

Figure 14 – BPM technology for service orchestration in composite services ................................................ 33

Figure 15 – Application Triggering Architecture ............................................................................................ 36

Figure 16 – Identity model............................................................................................................................... 39

Figure 17 – Service Provisioning Architecture................................................................................................ 44

Figure 18 – SC/A algorithm............................................................................................................................. 45

Figure 19 – Caller ID on IPTV ........................................................................................................................ 52

Figure 20 – CRBT architecture........................................................................................................................ 53

Figure 21 – Common Scenario ........................................................................................................................ 59

Figure 22 – Larger Scenario ............................................................................................................................ 59

Figure 23 – Architectural diagram of MLS, its components and interfaces .................................................... 60

Figure 24 – on-board key generation and registration process ........................................................................ 60

Figure 25 –The Push Framework..................................................................................................................... 61

Figure 26 –UserPlane Location Protocol (ULP).............................................................................................. 61

Figure 27 – Functional Elements of Wireless Village Server.......................................................................... 64

Figure 28 – MMS Network Representation..................................................................................................... 65

Figure 29 – Presence Specification Layers ...................................................................................................... 65

Figure 30 – Example of a PoC 1-to-many Group Session (voice transmission).............................................. 66

Figure 31 – UAProf end-to-end architecture ................................................................................................... 67

Figure 32 – BEA WebLogic Communication Platform (WLCP) .................................................................... 71

Figure 33 – Elements of the Rhino Core Platform........................................................................................... 73

Figure 34 – Mobicents ..................................................................................................................................... 74

Figure 35 – JEMS ............................................................................................................................................ 80



SMTP

SOA

SOAP

UDDI

W3C

WSDL

WSFL

XHTML

XML

XSD

YAML

VoIP

GTDD

ITU

CORBA

FTP

HTTP

IETF

IT

JSON

MQSeries

OASIS

REST

RPC

RSS

SGML

OAM&P

ATIS

TMF

ITU-T

OSS/BSS

MVNO

VNO

IPTV

Abbreviations

Common Object Request Broker Architecture

File Transfer Protocol

Hypertext Transfer Protocol

Internet Engineering Task Force

Information Technology

JSONJavaScript Object Notation

An IBM software family (middleware)

Organization for the Advancement of Structured Information Standards

Representational state transfer

Remote Procedure Call

RDF Site Summary

Standard Generalized Markup Language

Simple Mail Transfer Protocol

Service Oriented Architecture

Simple Object Access Protocol

Universal Description, Discovery and Integration

World Wide Web Consortium

Web Services Description Language

Web Services Flow Language

XML (version of) HTML

Extensible Markup Language

Extensible Schema Definition (Language)

Yet Another Markup Language

Voice over IP

Global Telecommunications Data Dictionary

International Telecommunication Union

Operations, Administration, Maintenance and Provisioning

Alliance for Telecommunications Industry Solutions

Telecommunication Management Forum

The International Telecommunications Union – Telecommunications Sector

Operations And Business Support Systems

Mobile Virtual Network Operator

Virtual Network Operator

Internet Protocol Television



1 Introduction

The telecommunications industry is currently suffering a significant transformation, creating challenges and new opportunities for network operators. Network operators are now facing a new architectural concept, a platform for service delivery that is entirely decoupled from the network infrastructure and is built on top of Service Oriented Architectures (SOA) and web services concepts, where services are no longer dictated by network architects, instead, networks will be defined and driven by services. The network treated as a plain resource is the new idea in this new concept of a service driven architecture.

The world of telecommunications has realized the need of a new potential model for service development and delivery. As always, the economic impact is the main driver for this transition, the promising of outstanding revenues is the main pusher for such change. Operators now comprehend the necessity of Service Delivery Platforms (SDP) to reduce the cost and the complexity of providing new value-added services, by integrating and unifying existing customer and operational systems. Judging by the level of effort among operators, and despite the obstacles needed for the change (lack of information by SDP vendors, lack of standardization, no reference model, and some others) operators are disposed to integrate new SDPs in their systems. The promise of extraordinary benefits is the key factor in this new movement of change.

The Service Delivery Platform is the key solution for the next generation telco operators. The pressure is on network operators to deliver:

• new services faster, cheaper and with less risk

• address niche subscribers groups with rich set of services

• leverage common service resources to create rich end-user services

SDP is a new architectural approach intended to enable the rapid development and deployment of new converged multimedia services, from the basic POTS (Plain Old Telephony Services) phone services to complex audio/video conferencing for multiplayer games. The Service Delivery platform is the service domain’s blueprint for developing, provisioning, and deploying standardsbased end-user across fixed and mobile networks. SDPs should typically provide a service creation environment, service execution and management environment, and abstractions for media control, presence/location, integration, and other low-level communications capabilities. The telecommunications industry has recognized the need for an SDP, particularly, one that conforms to industry standards and is built on a standard architecture.

This document describes the changes SOA will bring to the SDP area, and how new actors are already taking this into use. SOA will radically change the way business processes are automated and implemented in software, how migration of physical world processes are turned into digital services. SOA is much more than implementing an “Integration bus” or some other means of distributed deployment of software. SDP’s will play a key role in this landscape, by providing the execution environment for a lot of the processes involved.

Initially this document discusses the concepts and principles of Service Delivery Platforms. It first stresses the market drivers. Then it provides an overview of what an SDP is, based on several standards (OMA, 3GPP, TISPAN), followed by the analysis of some key technologies and enablers for a SDP reference architecture.

SOA applicability in the lifecycle of services and some use cases are also described, ending up with some recommendations and conclusions.



2 Service Delivery Platforms – concepts and principles

A Service Delivery Platform (SDP) is intended to enable rapid development and deployment of new converged multimedia services. Essentially, the SDP concept was created to depict an IT solution which can be deployed by fixed and mobile network service providers to deliver next generation value added voice and data services to consumers and enterprises.

An SDP is part of the IT infrastructure of the service provider, interworking with the IT infrastructure (CRM, BSS, OSS, etc) and with the communication (softswitches, IVRs, etc) and service networks (MMS-C, SMS-C, presence and location servers, etc).

SDPs typically provide a service creation environment, a service execution environment, and abstractions for media control, presence/location, integration, and other low-level communications capabilitities. Main requirements for SDPs include the support of multipartner service value chains, network convergence and on-demand self-service.

This chapter gives an overview of the concepts and principles around SDPs, starting with the market drivers and active bodies in the SDP arena, and finishing with the main functions which should be part of a SDP reference architecture.

2.1 SDP Market drivers

Enormous diversity, quick development and instant deployment of new and innovate services are the new business tendency for the next generation operators network. The implementation of this kind of technology provides a flexible and rapid development of services and a point of convergence involving information technology (IT) and wireless/fixed networks. The SDP is the solution and the market is reaching a critical phase, many vendors, specially in the mobile sector are in the process of implementing or already have implemented service delivery platforms. The investment is difficult and very costly, there are too many challenges to overcome, but the outcome is very promising.

What is influencing the market?

The demand of more and more services – The SDP is a common and open framework that allows the rapid development and deployment of the next generation services, but without services, the SDP is worthless. The demand of more and more services is influencing SDP vendors, for procuring compelling new services, or to find ways to provide third-party communities the means for building such services. A challenge has been declared to the SDP vendors, which will force them to search and acquire the most competitive service scenario they can provide in order to gain the market share.

Common and Open Standards should not compromise Security – It is clear that SDP vendors should adopt an open-garden approach, however, that same approach should not compromise the security of the network infrastructure. Operators are looking for more services, more control, more functionalities, more policy, but that should be accomplished without compromising security. The operator’s network must be well protected from the third-party outsource service development community.

Granularity – Easy integration and easier disintegration of SDP components is something that network operators desire. The better technique for accomplish this is to adopt SOA concepts and

SOA compliant technologies, such as Web Services, or other interoperable and decoupled technology. Modularity allows mobile operators to quickly integrate new functionalities into their

SDP, and by quickly, means less expensive, and less expensive is the type of language that operators like to hear.

2.1.1 SDP and IMS

Service Delivery Platforms can be seen as the ancestor of IP Multimedia Subsystem (IMS). The mobile industry is the cradle for both projects: The SDP origin comes from the necessity of mobile operator to deliver services in a more flexible and cost-effectively manner, across complex and


page 10 (80) Eurescom project report proprietary network infrastructures; IMS was developed by the 3 rd

Generation Partnership Project

(3GPP) to meet the needs of GSM operator in the search to deploy IP applications in new 3G networks.

The tendency is that both technologies will coexist as crucial components, in a service provider effort to deliver the next-generation services to consumers and enterprises. Together, SDP and IMS have been developed with a common goal in mind: the deliverance of application-level services from silo delivery mechanisms. Service Delivery Platforms are a vital IT infrastructure for telecom organizations if they are to play in the service market with superior services than the ones provided today (e.g., Google, eBAy, Skype now eBay).

Many SDP vendors are currently labelling their solution as IMS compliant. Early adopters of SDP technologies are today reengineering parts of their products to incorporate new requirements being defined in the IMS domain. For a positive and healthy coexistence between SDP and IMS, there shouldn’t be any functionality in the SDP domain that potentially overlaps with IMS.

IMS combines a set of more sophisticated services than the ones offered by today mobile operator

SDPs, often the basic message and content downloading services. A number of mobile operators are realizing the advantages of real-time multimedia services, raising the investment in new technology solutions.

The telecommunications industry is perhaps the world’s most dynamic industry at present.

Unfortunately, many operators do not have the right infrastructure to delivery new valued-added services in a timely and cost-effective manner. Even today, the deployment of a simple ring tone service can become very expensive and time consuming. Operator comprehend that there are better ways for doing this.

Up to now, only a small amount of fixed-network operators have integrated SDPs in their systems, the effort is usually focussed in the rationalization of the OSS/BSS structures, to guarantee enhanced and automated service provisioning and billing. Fixed network operators are facing the battle towards convergence, in order to support voice/data services and mobile/fixed networks, there is a continuous reengineering process of the network architecture. The market is growing, new actors are entering the market, such as eBay and Google, with new business oriented models that compete against existing network owners. This new actors can provide a rich set of services and produce high revenues only using the Internet, over any operator’s fixed or mobile network.

Fixed operators are now recognizing the need to support IMS in their next-generation architectures if they want to stay in the competition. IMS is influencing the way that fixed-network operators are thinking, driving operators towards services architectures and service composition concepts, both primary concepts of SDPs.

IMS and SDP are overlapping at the control layer, there are some functionalities portrayed in the

IMS control layer that exist in the SDP domain, such as policy control, profile management and accounting. There is a generalized understanding that IMS is not ready for mass deployment, some effort still needs to be focused in the IMS domain. This circumstances are beginning to influence operators, in the recognition, that the SDP is the right short-term investment to be made, enabling legacy network support in a cost-effectively manner and, eventually, a migration to an IMScompliant service delivery platform.

IMS implies an open and standards-based architecture based on the IP protocol that is common and understandable world wide. This open and flexible approach is already sustained in the IT domain, where service developers are joining efforts to develop new valued-added services using an open and flexible development framework. Operators are already picturing new business opportunities, they realized the potential benefits to turn themselves into service providers and gain the community trust and motivation for service creation and launch the most compelling services technology. For this, operators need to adopt concepts like open-based architectures for service development, and integrate an infrastructure capable of exposing their network facilities in a secure and controlled way, that is, the service delivery platform.


Eurescom project report

2.1.2 Current state and industry trends page 11 (80)

The telecommunications industry used to be responsible for service development and service deployment, where organizations were effectively controlling how, where and when new valueadded services were created and what kind of technology was used. Services were highly proprietary, often relied on the organizational technology and manageable and understood by a small amount of qualified personnel. This non-efficient method of service development was sufficient for modest times, where the diversity of services was not the main issue, only the capacity of delivering to high numbers of subscribers was important.

The new business model requires that network operators develop new value added services, such as innovate text services, voice and data services, location services, triple play and others, for attracting new subscribers, maintain the existing ones and consequently increase revenues.

Network operators must launch the line of most updated services technology faster than the competition, in a cost-effective and low time-consuming manner. Operators need to be able to quickly deploy an enormous selection of new value-added services, or to provide the means to offer third party developers the capability to interfere or develop new services. This new business approach must leverage and somehow extend the existing OSS/BSS infrastructure.

• The Service Delivery Platform is the solution

To achieve these business goals, the next generation of the telco industry must consider the introduction of a new domain – the service domain, where services are created, executed and managed independently of the network operator’s entire legacy infrastructure. The network needs to be seen at a high level of abstraction, hiding the underlying complexities and allowing a rapid development and deployment of new applications and services. The use of IT technologies is crucial in this service domain, so that business can remain in control of the service domain.

The Service Delivery Platform is a realization of the service domain. An SDP provides an open, common, service delivery and deployment framework across the entire network infrastructure. The

SDP is responsible for translating the information from the high-level service domain and the lowlevel network protocols. At the same time, the SDP is in charge of supplying the OSS/BSS infrastructure with all the business domain critical information, such as, charging, policies, and so forth. This high level layer of abstraction accelerates the development phase, because developers now see the network as a resource, and not as a complex and highly proprietary infrastructure.

Any experienced IT developer can now access the operator’s system and rapidly develop and deploy new value added services. To accomplish that, network operators need to establish a set of common rules and open access policies to their systems. With the deployment of rich and common set of functionalities, operators can quickly attract a significant number of potential third-party developers, bringing new services, new applications and consequently more business opportunities.

• SDP is an IT solution

The idea that an SDP is an IT solution is well established throughout the community. There is a common understanding that while network infrastructures are highly technical at the network level, the delivery of services will be through an IT rather than a network infrastructure.

Concepts like layered architectures, levels of abstraction, Service Oriented Architectures have been embraced in the IT domain for some time, to create new business opportunities and to facilitate the creation of business valued applications from existing technologies.

There is a generalized idea that the essential key for successfully SDP deployments is the combination of service-oriented techniques. The adoption of SOA concepts, like levels of abstraction, layered architectures, etc, have been already sustained in the IT world and is a inevitable piece of IT technology to include in successfully SDP deployments.

At the present time, nearly all telco business processes are information-based, rising the importance of the mechanisms that control and manage that same information. The information needs to be managed in a flexible and responsive method and IT systems are a vital piece for that success.

Operator’s network infrastructure is still an essential component in the system, but the idea that services should be delivered through the business level must be adopted by the telecommunications


page 12 (80) Eurescom project report industry. Abstracting the technical systems from the business level and delivery value-added services in a business orientation model is crucial for the rapidly deployment of new services.

Service Oriented Architectures are meant to support the business strategies and enable a positive arrangement of components in a loosely coupled mode. The key is to provide constructive and agile business collaboration, between different components, to permit the rapid creation and/or reconfiguration of new business processes in response to business drivers.

SOA techniques are important in the SDP arena, as they allow a collaborative effort between different sources of knowledge. SDPs are a common ground for application developers, network operators and service developers, all different skilled specialists that need to productively collaborate together, to bring new and richer services to customers.

• Web Services are emerging

Techniques, concepts and principles are vital strategies for the SDP success. SOA techniques are recognized to be the right path for the evolution of the next generation service delivery platform, although, at some point in time, some technology decisions have to be made. What kind of technologies can be adopted? Are they service oriented compliant?

There are several technologies that are so called “SOA compliant”, such as J2EE, CORBA, and others, but none have gained broad industry acceptance as web services. Web services have definitely gained the market attention has the most appropriate and effective service oriented technology at the moment. Web services are widely spread and adopted in this new era of telecommunications, where information is everything and everything is information.

Service Registry

(UDDI)

Find

W

SD

L

W

S

D

L

Publish

SOAP

HTTP

Service Requestor Service Provider

Bind

Figure 1 – Web Services architecture

Web services use a program-to-program communication architecture, using standard technologies like,

• HTTP: The World Wide Web transfer protocol

• XML: The language that describes data

• SOAP: An XML-based, extensible message envelope format, with "bindings" to underlying protocols (e.g., HHTP, SNMP)

• WSDL: An XML format that allows service interfaces to be described

• UDDI: A protocol for publishing and discovering metadata about Web services

Web services are a straightforward and cost-effective approach to application integration.

Interoperability is the key for integration and web services are all about interoperability.

Internet is the communication vehicle for WS, where SOAP messages are typically transmitted over HTTP , a very good quality for network policies, since HTTP traffic is usually allowed without restrictions.



There are concerns about performance because WS use XML based message styles. The appearance of high-quality and rapid XML tools (parsers) is increasing the performance for acceptable values, and the idea that web services do have the necessary performance is rapidly growing in the market. New service exposure layers based on web services like Parlay-X are already being applied these days.

2.2 SDP Standards point of view

2.2.1 OMA

Open Mobile Alliance is one of the Standardization Development Organization where more than

300 companies, representing mobile operators, device and network suppliers, information technology companies, and content providers, are participating in order to specify “OMA enablers”, which provide standardized components to create an environment in which services may be developed and deployed. For instance, Push-to-talk on cellular (PoC) service may be realized by three kinds of enablers, PoC Enabler, Presence Enabler and XDM enabler. The OMA enablers, the decomposition into these components and the interactions between them comprise “OSE;OMA

Service Environment” and are basically independent from the underlying network control and transport layer technologies. The interactions between enablers are the interfaces exposed by the enablers in an abstracted and secured manner and could also be used by applications provided by operators or 3rd party service providers.

As you may notice, the concept of OSE may be overlapped with that of SDP. The following sections describe OSE’s concept and what has been specified there.

2.2.1.1 OMA Service Environment – OSE

OSE is a flexible and extensible architecture that offers support to a diverse group of application developers and Service Providers. The primary intention of the OSE is to promote common architectural principles, across the whole OMA, for how OMA Enablers are specified and how they interact with one another whilst ensuring architecture integrity, scalability and interoperability, all of which strive to reduce architecture silo design and hence reduce integration and deployment complexity. [The term silo is used for expressing every network architectures which have been built for each specific service, which means there could be many overlapped functions among those architectures and never be re-used by each other].

Figure 2 shows OSE Architecture. OSE Architecture is the set of architecture elements and the interfaces between these elements.

Applications

I0+ P

Applications

I0+ P

Service Provider or

Terminal Domain

Policy Enforcer

Execution

Environment

(Software Life

Cycle Mgmt,

Load balancing, caching, O&M, etc.)

I1

I0

Enabler implementation

I2



To Resources in

Operators, terminals, Service Providers


Figure 2 – OSE architecture elements and interfaces



Each architecture element is described below.

• Enablers – A technology intended for use in the development, deployment or operation of a Service; defined in a specification, or group of specifications, published as a package by

OMA. An enabler should specify one or more public interfaces. Examples of OMA enablers include Location or Device Management.

• Enabler implementations – An element in the OSE and word for representing an implementation of an enabler, e.g. either in a Service Provider domain or in a terminal domain. An enabler implementation can be viewed as a template that represents an implementation of any enabler (e.g. MMS) as defined by OMA.

• Enabler interface bindings – Interfaces must be specified in a neutral language manner.

However, specifications may also define language specific bindings for the interfaces.

Enabler interface bindings provide the specific formats (i.e. syntax and protocols used to access enablers using particular programming languages (e.g. Java or C) or network protocols (e.g. web services).

• Policy Enforcer – An OSE architectural element that provides a policy-based management mechanism to protect resources from unauthorized requests and to manage the use of these requests, for instance, through appropriate charging, logging and enforcement of user privacy or preferences.

• Applications – An implementation of a related set of functions that performs useful work, often enabling one or more services. It may consist of software and/or hardware elements.

Table 1 contains a list of the OSE interface categories including their definition and additional comments.

Table 1 – Interface Categories of the OSE Architecture

Interface category

I0

Definition

I0+P

I1

I2

Comments

I0 is the category of interface to an enabler's intrinsic functions.

I0 interfaces are exposed to applications and enablers when the policies that are to be enforced do not require any additional parameters or when no policy is associated to the request to this enabler.

I0 interfaces are specified by OMA.

I0 may encompass interfaces to what in some areas are called “service building blocks” like location and messaging, as well as to traditional “business support functions” like subscriber management.

I0+P is the category of interfaces that combines I0 and P as required to satisfy existing policies that are to be enforced when exposing the I0 interface of the enabler.

I0+P are exposed to applications and enablers when the policies that are to be enforced require additional parameters.

The Policy Enforcer may require additional parameters ( P ) that must be provided along with the request to the enabler’s interface (I0), based on policies specified by any principal who is authorized to do so; i.e. typically the owner or administrator of the OSE domain where the enabler is located.

I1 is the category of interfaces between enablers and the Execution Environment (e.g. software life cycle management process and monitoring etc.).

The I1 interfaces may be specified by OMA.

I2 is the category of interfaces used by enablers to describe how to invoke an underlying resource's function.

I2 may encompass interfaces to underlying networks (i.e. mobile operator’s network) as well as to backend resources (i.e. BSS, O&M)

Such interfaces are not defined by OMA.



2.2.1.2 Policy Evaluation, Enforcement and Management (PEEM) page 15 (80)

The Policy Enforcer (PE) is an OSE architectural element that provides a policy-based management mechanism to protect resources from unauthorized requests and to manage the use of these requests for instance through appropriate charging, logging and enforcement of user privacy or preferences. The Policy Enforcer function allows the domain owner to extract and separate their policy rules from architectural elements. The OSE architecture does not describe how the PE is realized. The PE may be realized in several ways, one of which is the PEEM enabler.

Architecture Diagram

Figure 3 illustrates PEEM enabler implementation and interfaces with other entities in the OSE.

Figure 3 – PEEM Enabler Architecture

The PEEM enabler exposes the following interfaces:

• PEM-1 (PEEM specified callable interface).

• PEM-2 (PEEM specified management interface).

• Proxy interface (used for intercepting requests to target resources).

In addition to PEEM components and interfaces, there are other elements represented in Figure 3.

The following is a list of other elements identified in Figure 3 that interact with PEEM.

• Target Resource Requestor

Target Resource Requestor represents a resource (e.g. application, enabler) that issues a request to a target resource.

• Target Resource

Target Resource represents the destination resource for a request made by another resource.

• Delegated Resource

Delegated Resource represents the resource to which PEEM may delegate certain policy actions during the policy processing process.

• Evaluation Requestor

Evaluation Requestor represents a resource (e.g. application, enabler) that issues a request for policy processing to PEEM.

• Management Requestor

Management Requestor represents a resource (e.g. application, enabler) that issues a request for policy management to PEEM.

Flows

This section describes the high-level logical flows for the PEEM proxy usage pattern and the

PEEM callable usage pattern.



• PEEM Proxy Usage Pattern Flow

Figure 4 illustrates the logical flows of the PEEM enabler in the proxy usage pattern.

In the PEEM proxy usage pattern the Target Resource Requestor issues a request to the

Target Resource (flow #1).

The request is intercepted by the PEEM enabler (acting as a Target Resource proxy in the proxy usage pattern). Upon interception of the request the PEEM enabler identifies the relevant policy and starts the process of evaluating and enforcing it. In that process it may issue requests to one or more Delegated Resources that perform certain expected functions (flow#2) and deal with the results of the delegated functions that are returned to the PEEM enabler (flow#3). Based on a policy that evaluates the returned results, the

PEEM enabler may again issue requests to one or more Delegated Resources (flow#4) and deal with the results (flow#5).

The Target Resource returns a result (flow#7), which is intercepted by the PEEM enabler

(acting as a Target Requestor proxy in the proxy usage pattern). Upon interception of the result, (flow#7) the PEEM enabler identifies the relevant policy and starts the process of evaluating and enforcing it. In that process, it may issue requests to one or more

Delegated Resources that perform certain expected functions (flow#8) and deal with the results that are returned to the PEEM enabler (flow#9). Based on the policy that evaluates the returned results the PEEM enabler may again issue requests to one or more Delegated

Resources (flow#10) and deal with the results (flow#11).

The PEEM enabler passes the result, if appropriate, on to the Target Resource Requestor

(flow#12).

Req ues tTo

Del ega ted

3

Res our ce(

) ult(

)

Requ estTo

Dele gated

Reso

Resu urce() lt()

Figure 4 – Logical Flows for the PEEM proxy usage pattern

• PEEM Callable Usage Pattern Flow

Figure 5 illustrates the logical flows of the PEEM enabler in the callable usage pattern. In the PEEM callable usage pattern the Evaluation Requestor issues a request for Policy processing (flow #1) to the PEEM enabler using the PEM-1 interface. Upon reception of the request the PEEM enabler identifies the relevant policy and starts the process of evaluating it. In that process, it may issue requests to one or more Delegated Resources that perform certain expected functions (flow#2) and may deal with the results (flow#3) that are returned to the PEEM enabler. Such delegated resources can be enablers or other resources. A decision is reached when the policy evaluation completes. The PEEM enabler then returns the decision (flow #4) to the Evaluation Requestor or performs enforcement itself, possibly without returning a value to the requester. Upon reception of the decision, the Evaluation requestor executes its own actions as dictated by the decision.



1 RequestDecision() page 17 (80)

Figure 5 – Logical Flow for PEEM callable usage pattern

• PEEM Policy Management Flow

Figure 6 illustrates the logical flows of the PEEM enabler for management of policies.

In the PEEM management flow the Management Requestor issues a request for Policy

Management (flow #1 in Figure 6) to the PEEM enabler, through the PEM-2 interface.

Upon reception of the request the PEEM enabler identifies the type of policy management request (e.g. create, delete, view, modify), executes the appropriate function and returns the results to the Management requestor (flow #2 in Figure 6).

Figure 6 – Logical Flow for PEEM policy management

OSE and IP Multimedia Subsystem defined by 3GPP/3GPP2 2.2.1.3

Within the framework of the OMA Service Environment (OSE), a set of capabilities within the IP

Multimedia Subsystem (IMS) defined by 3GPP and 3GPP2 can be utilized for the OMA service enabler implementations. In the OMA specification, the interoperability and/or inter-working of

OMA enablers realized on IMS with other OMA enablers (either IMS realized or not) are described. In particular, how OMA service enabler implementations interface with an underlying IP

Multimedia Subsystem (as specified by 3GPP/3GPP2) is described in order to ensure the interoperability. OMA enabler implementations may make use of IMS capabilities, e.g. charging, authentication, service management, etc. IMS related applications/enablers can use OSE capabilities in addition to IMS capabilities through I2 interface. The set of IMS interfaces that correspond to I2 are described in Figure 7. The I2 type of interfaces to the IMS as shown in the figure, represents a wide variety of functionalities and capabilities that are standardized by 3GPP and 3GPP2.

Application

I0

I0/I2

Ut

I0

ESI A (AS)

Dh Sh

I2 type of interfaces

Mb ISC Rf

ESI B (AS)

Ro

I0/I2

Ut http proxy

SLF S-CSCF OCS http proxy

HSS

P-CSCF

CCF

ETI

(UE)

Gm

IMS Core

Gm ETI

(UE)

Mb Mb

Figure 7 – The main components of the IMS architecture in relation to enablers

The Enabler Terminal Implementation, abbreviated ETI in Figure 7, can communicate with the

Enabler Server Implementation (ESI ~ Application Servers (AS)). Any SIP-based service enabler must have at least a SIP-based interface towards endpoints. Specifically, it is the IMS core that provides the ability for these endpoints to be reached. Therefore, SIP-based service enablers



SHALL interface with the IMS core, using the IMS Service Control (ISC) interface. The definitions of the interfaces are described below.

ISC interface

The ISC interface is between the enabler server implementation and the IMS core. The ISC interface provides the OMA service enabler with SIP/SDP call control, SIP event related subscription and notification, SIP messaging, etc. The ISC interface is based on SIP and is specified in [7] or [8].

The protocol used on the ISC interface is SIP, as specified in [24] and [25], respectively.

Sh interface

The Sh interface is between the enabler server implementation and the HSS in the IMS core. The

Sh interface provides the OMA service enabler with read and write operations of user data related to IMS. It also provides with functionality for subscription and notification of changes in the user data related to IMS. The Sh interface is specified in [7] or [8].

The protocol used on the Sh interface is DIAMETER, as described and specified in [26] and [27], respectively.

Dh interface

The Dh interface is between the enabler server implementation and the Service Locator Function

(SLF) in IMS core. The Dh interface is quite similar to the Sh interface and is used by the enabler implementations to obtain the address of the HSS that handles a particular user in the network, where there are several HSS. The Dh interface is specified in [7] or [8]. The protocol used on the

Dh interface is DIAMETER, as described and specified in [26] and [27], respectively.

Ut interface

The Ut interface is between the enabler implementation in the terminal and the enabler server implementation. The Ut interface provides the UE with a set of operations that allow configuring user specific data in the OMA service enabler servers. The user specific data comprises, but it is not restricted to configuration management, such as configuration of presence lists and presence authorization rules. The Ut interface is specified in [7] or [8]. The protocol used on the Ut interface is being specified in 3GPP and is based on XCAP.

Ro interface

The Ro interface provides the OMA service enabler with an event based charging interface to the online charging system in the IMS core. The protocol used on the Ro interface is DIAMETER and the Ro interface is specified in [28] and [29].

Rf interface

The Rf interface provides the OMA service enabler with an interface to the offline charging system in the IMS core. The protocol used on the Rf interface is DIAMETER and the Rf interface is specified in [28] and [29].

Gm interface

The Gm interface is between the enabler implementation in the terminal and the IMS core. The Gm interface provides the OMA service enabler with SIP/SDP call control, SIP event related subscription and notification, SIP messaging, etc. The Gm interface is specified in [7] or [8].

Mb interface

The Mb interface provides the OMA service enabler with user plane packet media streams over IP via the IMS core. The transport protocols for packet switched multimedia applications are standardized in [30].

2.2.1.4 IMS connectivity and signalling support for enablers

Figure 8 shows a simplified view of how enabler interactions in principle, can be split in two layers, in this case named “SIP connectivity layer” and “enabler layer”. The “SIP connectivity


Eurescom project report page 19 (80) layer” comprises the basic SIP proxy and registrar functions that allow end-to-end point connections based on addressing conventions using IMS Session Control functionality, as well as service-based routing and hop-by-hop security. IMS offers SIP infrastructure capabilities in the network and in the terminal and the “SIP connectivity layer” is common to all applications. So,

“SIP connectivity layer” functionality SHALL NOT be developed for the individual OMA enablers.

Enabler imp- lemention

Enabler interaction


SIP UA

Terminal or

Server

SIP

IMS core

SIP

Connectivity

SIP

SIP UA

Server or Terminal

SIP (not I2 type)


SIP UA

SIP

Non-IMS

SIP networks

Server or

Terminal

SIP (I2 type)

Enabler interactions (I0 type)

Figure 8 – SIP Interfaces for enablers

The OMA service enabler realizations using IMS are specified in the enabler layer of OSE on top of the connectivity layer in the underlying network. The IMS connectivity layer looks completely transparent to the enabler layer, even though there may be a need to define some service-specific routing rules inside the IMS. Such definitions are seen to be part of the enabler configuration settings. At the enabler layer, it SHALL NOT make a difference if the underlying infrastructure is

IMS, or some other similar SIP network.

Similar layering exists for XCAP signalling. Below XCAP, there is HTTP in the underlying network that offers transport capabilities, routing and security capabilities and addressing conventions, while XCAP on the enabler layer offers definitions of, for example, content type (or data format) and other definitions specific for a single XCAP application usage.

Figure 8 shows some possible interfaces between enabler implementations (I0 type of interfaces) and the enabler interfaces with the SIP connectivity layer of IMS and non-IMS SIP networks (I2 type of interfaces). The figure also shows interfaces between different implementations of the same enabler, e.g. used in a client-server configuration of the enabler. IMS can be connected to other

SIP-based networks. OMA enabler implementations using IMS can therefore be connected to

OMA enabler implementations that use non-IMS SIP-based networks as shown in Figure 8.

2.2.2 3GPP

2.2.2.1 Application servers in IP Multimedia Subsystem

In the specification of 3GPP IMS; IP Multimedia Subsystem, three kinds of application servers are defined to realize IMS services, which are SIP Application Server, IM-SSF, OSA SCS provided by network operators or 3rd party service providers. Those application servers are connected to S-

CSCF and HSS in the IMS core network via the IP multimedia service control (ISC) interface and

Sh interface, respectively (see Figure 9). All the Application Servers behave as SIP application servers on the ISC interface.



AS AS

SCIM

SIP Ap plicatio n

Serv er

Sh

ISC

HSS

Cx

S S CSCF

ISC

OSA service cap ability server cap ability server

(SCS)

OSA API

OSA app lication server

ISC

Si

IM -

SSF

M AP

CAP

Camel Service

Environment

Figure 9 – Functional architecture for service provision support in the IMS

Table 2 shows the characteristics of those three application servers.

Table 2 – Application servers defined in IMS

(*1) The service capability interaction manager (SCIM), which performs the role of interaction management between other application servers, is defined in SIP application server.

(*2) The OSA service capability server (OSA SCS) interfaces to the OSA framework Application

Server and provides a standardized way for third party secure access to the IM subsystem. The

OSA reference architecture defines the OSA Application Server as an entity that provides the service logic execution environment for client applications using the OSA/Parlay API as specified in 3GPP TS 29.198.

2.2.2.2 Service Interaction of Application Server with IMS

In IMS specification, the protocol to be used on the ISC interface is SIP as defined by RFC 3261, other relevant RFCs and the extensions to SIP at this interface shall be avoided but are not expressly prohibited.

The ISC interface is used to provide value-added services in the AS and support subscription to event notifications between the Application Server and S-CSCF to allow the Application Server to be notified of the implicit registered Public User Identities, registration state and UE capabilities and characteristics in terms of SIP User Agent capabilities and characteristics. The S-CSCF shall


Eurescom project report page 21 (80) decide whether an Application Server is required to receive information related to an incoming initial SIP request to ensure appropriate service handling. The decision at the S-CSCF is based on

(filter) information received from the HSS. This filter information is stored and conveyed on a per

Application Server basis for each user. The name(s)/address(es) information of the Application

Server (s) are received from the HSS. For an incoming SIP request, the S-CSCF shall perform any filtering for ISC interaction before performing other routing procedures towards the terminating user, e.g. forking, caller preferences etc.

Once the IM SSF, OSA SCS or SIP Application Server have been informed of a SIP session request by the S-CSCF, they shall ensure that the S-CSCF is made aware of any resulting activity by sending messages to the S-CSCF.

From the perspective of the S-CSCF, the "SIP Application server", the "OSA service capability server" and the "IM-SSF" shall exhibit the same interface behaviour.

If a S-CSCF receives a SIP request on the ISC interface that was originated by an Application

Server destined to a user served by that S-CSCF then, the S-CSCF shall treat the request as a terminating request to that user and provide the terminating request functionality as described above. Both registered and unregistered terminating requests shall be supported.

It shall be possible for an Application Server to generate SIP requests and dialogs on behalf of users. Such requests are forwarded to the S-CSCF serving the user, and the S-CSCF shall perform regular originating procedures for these requests.

Table 3 shows the possible high-level interactions envisioned between the S-CSCF and the

Application Server.

Table 3 - Interaction between S-CSCF and Application Server

From: X

To: Y

To: Y

Call-ID: Z

To: Y

Call-ID: Z

2.2.3 TISPAN

2.2.3.1 Introduction on TISPAN

ETSI is the European organization of standardization in the field of telecommunications; it is officially in charge of the standardization of information and communication technologies (ICT) for Europe.

The ETSI brings together manufacturers, vendors, operators, administrations, services providers, research centers and users.

TISPAN (Telecommunication and Internet converged Services and Protocols for Advanced

Networking) is an ETSI initiative that defines the NGN (Next Generation Network) based on 3GPP

IMS.



Although there is no definition of what an NGN is, there is a general agreement on a number of its fundamental characteristics. ITU-T Study Group 13 concluded its meeting in February 2004 on the following definition: "A Next Generation network (NGN) is a packet-based network able to provide services including Telecommunication Services and able to make use of multiple broadband, QoS-enabled transport technologies and in which service-related functions are independent from underlying transport-related technologies. It offers unrestricted access by users to different service providers. It supports generalized mobility which will allow consistent and ubiquitous provision of services to users."

The IMS choice as the underlying architecture of the NGN is due to several reasons:

• open interfaces that allows a wider choice of IMS supplier.

• with 3GPP Release 6, IMS becomes applicable to a range of network types (3G UTRAN,

WLAN).

• thanks to TISPAN and 3GPP works, IMS becomes access technology independent…

TISPAN work is carried out in close cooperation with 3GPP, in charge of the specifications for the mobile network. TISPAN documents refer to 3GPP documents as far as possible.

2.2.3.2 NGN overview

Figure 10 – NGN Overview

As shown in figure above, the NGN functional architecture, described in TISPAN ES 282 001, is structured according to a service layer and IP-based transport layer.

The service layer can be divided in different sub-layers:

• a control layer, composed of the IMS core,

• a PSTN/ISDN Emulation Subsystem (PES),

• an application layer, composed of application servers,

• common elements (i.e. used by several subsystems) such as those required for accessing applications charging functions, user profile management, security management, routing databases, …)



Other multimedia subsystems (e.g. streaming subsystem, content broadcasting subsystem, etc) are outside the scope of TISPAN NGN Release 1.

IP connectivity is provided by the transport layer, under the control of the NAS (Network

Attachment Subsystem) and of the RACS (Resource and Admission Control Subsystem); these subsystems mask the technology of transport used in the access and the core network under the IP layer.

The functional entities, part of a subsystem, can be distributed between a home network and a visited network: it is the case of the NAS, of the RACS and of the subsystems of the service layer which support the roaming.

2.2.3.3 "Core IMS" overview

Figure 11 – IMS Core

The IMS Core component of the NGN architecture supports the provision of SIP-based multimedia services to NGN terminals. It also supports the provision of PSTN / ISDN simulation services.

The Core IMS is a subset of the 3GPP IMS, restricted to the session control functionalities.

Although identical to the 3GPP IMS entities, NGN IMS functional entities might exhibit minor variations in behavior, due to differences in access networks and user equipment. However, the

NGN IMS architecture defined in TISPAN remains compatible with 3GPP-defined IP-connectivity access networks (IP-CAN) and as such, can provide services to user equipment connected to both fixed broadband access and 3GPP IP CANs.

2.2.3.4 Service Architecture

The service architecture described in TISPAN relies on the technical specifications of 3GPP. Thus, the same kind of applications servers and the same interface are described in TISPAN as in 3GPP.

These information are already detailed in chapter 2.2.2.1 Application Servers in 3GPP IMS.

2.2.4 Web Services Interoperability – WSI

Introduction

Web services, at their core, are technologies designed to improve the interoperability between the many diverse application development platforms that exist today. While the reality of Web services interoperability is still less than desired, great strides have been made to move things in the right direction. It is generally recognised that there are some inconsistencies, design flaws and underspecified mechanisms and extensions in the current set of standards. The key point to


page 24 (80) Eurescom project report remember is that over time, interoperability will improve and the current challenges that exist in the process of creating, deploying, and consuming Web services eventually will be resolved.

WS-I, the organisation

Web Services - Interoperability (WS-I) is a organisation that is dedicated to solving these challenges. WS-I is an open industry organisation chartered to promote Web services interoperability across platforms, operating systems and programming languages. The organisation’s diverse community of Web services leaders helps customers to develop interoperable Web services by providing guidance, recommended practices and supporting resources. Web Services Interoperability Basic Profile (WSI-BP), their flagship deliverable, provides a set of guidelines on how to develop interoperable web services. WS-I has resolved more than 200 interoperability issues associated with using the core Web services specifications together.

Any company interested in promoting Web services interoperability is encouraged to join the effort.

Specifically, WS-I creates, promotes and supports generic protocols for the interoperable exchange of messages between Web services. In this context, “generic protocols” are protocols that are independent of any action indicated by a message, other than those actions necessary for its secure, reliable and efficient delivery, and “interoperable” means suitable for multiple operating systems and multiple programming languages.

Reflecting its cross-industry support, the board of Directors has nominees from the following companies: SAP AG, BEA Systems, Fujitsu, Hewlett-Packard, Sun Microsystems, IBM, Intel,

Microsoft, Oracle, and webMethods.

WS-I Deliverables

WS-I’s deliverables provide resources for Web services developers to create interoperable Web services and verify that their results are compliant with WS-I guidelines. Key WS-I deliverables include Profiles, Sample Applications and Testing Tools.

Profiles

They provide implementation guidelines for how related Web services specifications should be used together for best interoperability. So far, WS-I has finalised the Basic Profile, Attachments

Profile and Simple SOAP Binding Profile. Work on a Basic Security Profile is currently underway.

Basic Profile 1.1 covers the following core Web services standards and provides constraints and clarifications to these base specifications, along with conventions about how to use them together, with the goal of promoting interoperability:

• SOAP 1.1

• WSDL 1.1

• UDDI 2.0

• XML 1.0 (Second Edition)

• XML Schema Part 1: Structures

• XML Schema Part 2: Data types

• RFC2246: The Transport Layer Security Protocol Version 1.0

• RFC2459: Internet X.509 Public Key Infrastructure Certificate and CRL

• Profile

• RFC2616: HyperText Transfer Protocol 1.1

• RFC2818: HTTP over TLS Transport Layer Security

• RFC2965: HTTP State Management Mechanism



The Secure Sockets Layer Protocol Version 3.0

• The Attachments Profile adds the following:

• SOAP Messages with Attachments

• RFC2557 MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)

• RFC2045 Multipurpose Internet Mail Extensions (MIME) Part One: Format of internet

Message Bodies

• RFC2046 Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types

• RFC2392 Content-ID and Message-ID Uni form Resource Locators

Guiding Principles

The WS-I Basic Profile was developed according to a set of principles that, together, form the philosophy of the Profile, as it relates to bringing about interoperability. These principles are described in detail and are available in the deliverables section of the WS-I site [7].

Sample Applications

Sample applications serve as working examples for developers looking to follow the WS-I guidelines in their programming environment of choice. So far, WS-I has delivered eleven implementations of the WS-I Sample Application for the Basic Profile.

Testing Tools

They are used to determine whether the messages exchanged with a Web service conform to WS-I guidelines. These testing capabilities are important for developers to ensure that their implementations comply with the current interoperability guidelines for the use of Web services specifications. To date, WS-I has developed tests for developers to verify their conformance with the Basic Profile 1.0, and work on the other WS-I profiles is underway.

Market Success

Since August, 2003, when the WS-I first delivered the WS-I Basic Profile 1.0 as Final Material,

Web services vendors, solution providers, standards development organisations and customers in a variety of vertical industries have adopted the WS-I profiles and support the work of the organisation.

Today, Web services vendors and solution providers have brought to market products and services that enable the development of conformant and interoperable Web services. Today, standards development organisations like the Open Applications Group have incorporated the WS-I profiles into their own specifications, and others such as OASIS and the W3C, are improving how standards are developed with a more critical eye toward true interoperability based on feedback from WS-I and its members. Nowadays, customers are requiring conformance from their vendors and solution providers and considering it a key criterion for vendor selection. Leading industry analyst firms such as Burton Group, Forrester Research and Gartner are advising their clients to enforce the use of the WS-I profiles as part of a company’s core development process to help ensure interoperability and, ultimately success, of their Web services implementations.

2.2.5 Liberty Alliance

The Liberty Alliance [1][2] was founded in September 2001 with the aim of establishing an open standard for federated identity management. Today, Liberty Alliance has grown to nearly 150 members including global technology vendors, consumer-facing companies, educational organizations and governments from around the world, The management board consists of following companies: America Online, Ericsson, Fidelity Investments, France Telecom, GM, HP

Invent, IBM, Intel, Novell, NTT, Oracle, RSA Security and Sun Microsystems. Over 160 organizations are currently members of the Liberty Alliance.



The goals of Liberty Alliance are [1]:

• Provide open standard specifications and business guidelines for federated identity management and identity-based Web services.

• Provide open and secure standards for Single-Sign On (SSO) with decentralized authentication and open authorization.

• Allow consumers/business to maintain personal information more securely, and on their terms.

Liberty Alliance’s work towards interoperable federated identity services has been divided in three phases.

The first phase is the Liberty Identity Federation Framework (ID-FF) which enables identity federation and management through features such as identity/account linkage, single sign-on (and global logout), and simple session management.

The second phase is the Liberty Identity Web Services Framework (ID-WS) which provides the framework for building interoperable identity services, permission based attribute sharing, identity service description and discovery, and the associated security profiles. ID-WS offers functionality to address the security and basic reliable messaging functions of any such web service. Liberty

Alliance released the first version of its Liberty Web Services Framework in 2003.

The third phase is the Liberty Identity Service Interface Specifications (ID-SIS). ID-SIS enables interoperable identity services such as personal identity profile service, alert service, calendar service, wallet service, contexts service, geo-location service, presence service and so on.

Liberty Alliance is expecting well over one billion Liberty-enabled identities and devices by the end of 2006.

Relevant specifications from Liberty Alliance [1]

ID-FF:

• Liberty ID-FF Architecture Overview is a non-normative summary description of the

Liberty ID-FF architecture, including policy and security guidance.

• Liberty ID-FF Implementation Guidelines defines the recommended implementation guidelines and checklists for the Liberty architecture focused on deployments for the service-providing entities: service providers, identity providers, and Liberty-enabled clients or proxies (LECPs).

• Liberty ID-FF Static Conformance Requirements

• Liberty ID-FF Protocols & Schema defines the abstract protocols and XML schemas for

Liberty.

• Liberty ID-FF Bindings & Profiles defines concrete transport bindings and usage profiles for the abstract Liberty protocols.

• Liberty Authentication Context defines the authentication context schema, which is used to communicate information about an authentication event.

• Liberty Metadata describes metadata, protocols for obtaining metadata, and resolution methods for discovering the location of metadata.

ID-WS:

• Liberty ID-WSF Architecture Overview is a non-normative document intended to provide an overview of the features of the Liberty ID-WSF Version 1.0 Specifications.

• Liberty ID-WSF Security & Privacy Overview is a non-normative document providing an overview of the security and privacy issues in ID-WSF technology and briefly explaining potential security and privacy ramifications of the technology used in ID-WSF.

• Liberty ID-WSF Static Conformance Requirements



• Liberty ID-WSF Data Services Template provides protocols for the querying and modifying of data attributes when implementing a data service using the Liberty Identity

Web Services Framework (ID-WSF).

• Liberty ID-WSF Discovery Service describes protocols and schema for the description and discovery of ID-WSF identity services.

• Liberty ID-WSF Interaction Service specifies an identity service that allows providers to pose simple questions to a Principal.

• Liberty ID-WSF Security Profiles specifies security mechanisms that protect identity services.

• Liberty ID-WSF SOAP Binding defines the Liberty Identity Web Services Framework

(ID-WSF) SOAP binding. It specifies simple SOAP message correlation, consent claims, and usage directives.

• Liberty Reverse HTTP Binding for SOAP specifies a binding that enables HTTP clients to expose services using the SOAP protocol, where a SOAP request is bound to an HTTP response, and a SOAP response is bound to an HTTP request.

ID-SIS:

• Liberty ID-SIS Personal Profile describes a web service that provides a Principal's basic profile information, such as their contact details, or name.

• Liberty ID-SIS Employee Profile offers profile information regarding employee.

2.2.6 ITU-T

ITU-T [3] has 13 study groups that cover a wide range of topic related to telecommunication equipment and services. The issues covered include numbering systems, multimedia services and systems, network and service operation, tariff and accounting principles, telecommunication network management systems, signaling, transmission and transport systems, data networks, and new value-added services. Additionally, ITU-T deals with coordinating the development of the systems and technologies which constitute the emerging global information infrastructure. Areas under study include optical networking, IP interworking and ground-breaking technologies related to new multimedia systems, including special protocols and signal processing systems, high-speed modems, digital subscriber line systems (xDSL), network aspects of mobility and new types of multimedia terminal.

The concept of a new, integrated broadband network has been emerging over the last years and has by ITU been labeled "Next Generation Network (NGN)”. ITU-T initiated its standardization activity from 2003 with JRG on NGN (Joint Rapporteur Group on NGN) in SG13. The work continued in the Focus Group on Next Generation Networks (FGNGN) [4] which was created in

2004. From November 2005 this work is carried out under the umbrella of the NGN Global

Standardization Initiative (NGN-GSI) [5].

FGNGN was created to deal with the urgent needs for global standards for Next Generation

Networks (NGN) regarding service requirements, functional architecture and mobility, security, quality of service (QoS), control and signaling capability, evolution and future packet-based bearer network. FGNGN was made-up of seven working groups according to the study area.

FGNGN developed 18 approved deliverables and on-going drafts which will be developed further through relevant Study Groups under the banner of NGN-GSI (Global Standard Initiative). Its final output was a total of 30 documents. A few of them were already approved during the meetings and transferred to the relevant Study Groups for further consideration [6].

NGN-GSI focuses on developing the detailed standards necessary for NGN deployment to give service providers the means to offer the wide range of services expected in NGN. NGN-GSI harmonizes, in collaboration with other bodies, different approaches to NGN architecture worldwide. The first NGN-GSI event was held at Geneva from 16th to 27th January of 2006 as joint group meetings among SG11, SG13, SG19 and part of SG17 (WP2) and SG16.



Relevant work:

Y.2001 General overview of NGN

Next Generation Network (NGN): a packet-based network able to provide telecommunication services and able to make use of multiple broadband, QoS-enabled transport technologies and in which service-related functions are independent from underlying transport-related technologies. It enables unfettered access for users to networks and to competing service providers and/or services of their choice. It supports generalized mobility which will allow consistent and ubiquitous provision of services to users.

Y.2011 General principles and general reference model for Next Generation Networks

Y.2012 Functional requirements and architecture of the NGN

Y.2401 Principles for the Management of the Next Generation Networks

2.3 SDP reference architecture

There is not a standard reference model for the SDP architecture, but some bodies (OMA, 3GPP,

Liberty Alliance, etc) have come up with some technologies and enablers, taking into account some of the control and service layer components of IMS.

This chapter describes these technologies and enablers which should be part of a SDP reference architecture.

Annex B – “SDP Vendor’s point of view” briefly describes the approach of the commercial vendors. The list of commercial vendors described in Annex B is not exhaustive and is only based on partner’s knowledge. New entrants in the Service Layer arena, such as Google, Skype, MSN are briefly addressed in Annex C - “Software Operators SDP”.

2.3.1 Service enablers

2.3.1.1 Open Mobile Alliance

The pursuit for mobile services

The mobile industry is a vital sector in today’s telecommunications - mobile communications are experiencing an extraordinary growth since the last decade and mobile services will be the next source of effort by the mobile industry. The market is anxious for more and more services, as the mobile network increases exponentially. This market trend is rising the need for a new kind of mobile data services that can be used and accepted at a global scale, services that are end-to-end interoperable and agnostic to the underlying infrastructures. To ensure a successful global user adoption of mobile data services, it is important to specify market driven mobile service technologies, or enablers, that ensure service interoperability across devices, geographies, service providers, operators, and networks, while allowing businesses to compete through innovation and differentiation. Successful communications across different terminals, different countries, require end-to-end interoperable transmissions. A common and frequently scenario is where a person gets a message from an advertising operator, for instance in Japan and then the same person should be able to forward the same message to someone else back home. This kind of service enabling technologies based on open global standards, such as MMS, XHTML, will facilitate the creation of new compelling services for the mobile market and as a consequence, will influence the growth of the mobile industry.

Enablers are building blocks that expose a simple northbound API (typically through java or web service technologies), isolating the user from the complexities and underlying network capabilities.

Service enablers are the response for end-to-end interoperable communications across platforms. A service enabler is a technology intended to facilitate the development, deployment and operation of services. Service Enablers are defined in a specification or a group of specifications and published by the Open Mobile Alliance (OMA) [10], the main industry forum responsible for developing market driven, interoperable mobile service enablers. The OMA was founded to address these


Eurescom project report page 29 (80) specific interoperable issues, by establishing a common ground of effort for specification and interoperability.

Who is Open Mobile Alliance?

OMA was formed in June 2002 by approximately 200 companies world wide to drive interoperability of mobile data services. The standards body includes key value sectors such as, the world’s leading mobile operators, device and network suppliers, technology companies, content and service providers. OMA’s approach is to create a common ground for all specification activities, enabling the entire community to consolidate into one organization all specification activities in the service enabler arena.

OMA achieves interoperability by defining a set of requirements, architectures and specifications, enabling seamless mobile services for end users worldwide.

“together we stand, divided we fall”

The main benefit brought by OMA is reflected in the outcome of valuable mobile services and applications. The unparallel extensive cross-industry participation of all parties, is confirmed as be the best way of solving interoperable issues in a quickly and efficient manner. The integration of several specification organizations into one, allows a common place where information and resources are shared, and overlapping efforts are reduced, avoiding isolated technologies specified by separate parties.

Mission

OMA is a vital organization for the creation of mobile service enablers specifications, the valuable starting point needed to support the creation of interoperable end-to-end mobile services. OMA’s effort is to bring into the mobile world new service enablers that are agnostic to underlying wireless networks and platforms, services that are independent of geographic boundaries, operators networks and devices. The effort does not end here, as OMA encourages third party tool development, provides test specifications and activities to facilitate the adoption and the implementation.

Key words behind OMA

• Interoperability across countries, operators and mobile terminals

• Network agnostic

• Voluntary

• Fair, reasonable and non-discriminatory intellectual property rights

The purpose of the OMA is to:

• Bring into market high quality and open-based technical specifications, focused on market requirements, consistency, extensibility and in minimizing the industry implementation effort.

• Guaranteed interoperability across different devices, geographies, service providers and all underlying dependencies.

• To be the consolidation vehicle for standards activities within the mobile data service industry; building a common ground to improve interoperability and decrease operational costs for all involved.

• To provide value and benefits to OMA participants and consequently, rising the wish to participate in the organization.

2.3.1.2 OMA Enablers releases

OMA is focused in delivering enabler releases [11] with guaranteed interoperability and capable of superseding the market needs. OMA has defined a clear path for the development of open technical specifications, the starting-point for interoperable services.



The OMA Release Program consists on two phases:

• Phase 1 – the candidate Enabler Release – that can be a set of open technical specifications.

• Phase 2 – Approved Enabler Release - The enabler has already been submitted to a public period for evaluation and comment and approved.

The lists of the candidate enabler releases and the approved enabler release can be found in the [27]

– OMA Enabler Releases. More detailed information can be observed in Annex A.

2.3.2 Service orchestration

Terminology and concepts

The process management ensures the ordered collaboration between the information system resources, thus contributing to the implementation of business goals.

In this scope:

• The ordered collaboration is the sequence of activities managed by a set of resources according to a predefined scheduling.

• The resources are elements able to manage activities, for example: applications, equipments, human actors …

• The business goals define the enterprise core with respect to the customer and its internal entities.

• The resources provide services , which usage activates a task that will be managed by the resource.

• The services cooperate according to an activity scheduling, so called business process: this is the service orchestration .

• The activity scheduling can be controlled by a business process manager ( BPM ) or developed using a programming language, according to the context 1 .

• The business process manager and the resources application communicate through an

Application Programming Interface ( API ).

• The business process manager and the resources human actor communicate through a work list .

• The communication between the business process manager and the resources relies on a transport infrastructure, so called connectivity layer .

• As the APIs are not standardized with regards to their underlying data model, the communication between the business process manager and the resources also relies on a data transformation and dynamic routing infrastructure, so called brokerage layer .

• The business process manager, the brokerage layer, and the connectivity layer must be provided by an Enterprise Application Integration ( EAI ) solution.

From application integration to service integration

Providing services cannot be reduced to build them. Some tools must also be implemented to manage and administrate services, and guarantee their quality of service. This is where EAI technology reached its limitation and SOA brings added value.

The service concept introduces a higher level of abstraction, hiding the technical constraints and

API limitations. It allows reducing the gap between concepts handled by both business and IT experts. A service can be considered as a set of IS function calls in order to meet a business goal. It

1

In some simple cases, that are not requiring the modelling, monitoring, administration capabilities of a

BPM, it is possible to implement it without any BPM.


Eurescom project report page 31 (80) can also be considered as a business function provided by an organisational entity of the enterprise for which a service contract has been defined (QoS, SLA …).

The following Figure 12 coarsely positions the different architectures. The Business Process

Management (BPM) is also positioned with respect to its usage for the enterprise business process execution. It is however possible to use the Business Process Management (BPM) at the other layers: for example, wrapping of API function calls at the EAI one or service composition at the

SOA one.

Figure 12 – Positioning EAI and SOA

Two levels of service orchestration

As shown in Figure 12, service orchestration appears at two levels, thus dealing with two goals:

• Service composition: elementary services are composed (orchestrated) to provide composite services, so called business services. For example, elementary services as position determination and address book can be orchestrated to provide a business service as road book.

• Business process: business services are orchestrated to meet business goals. For example, business services as customer creation, product book and order creation can be orchestrated to provide a business process as order entry.

With SOA, the composite services are themselves exposed as services that are usable by new services or composite services. In the last case, this leads to some limitations with regards to service orchestration:

• There is not any father/son link between composite services.

• In the same way, there is not any end-to-end view of the service composite execution.



These previous limitations are increasing with the level of nesting and the duration of the internal process related to the composite service.

The Business Process Manager

Traditionally, the business process manager includes the following functionalities:

• A process modeller , that refers to a process repository.

• A process engine , that refers to a persistence base and a log service.

• A work list manager .

• A monitor .

More recently, some functional extensions completed the previous set:

• A business rules engine ( BRE ), to simplify the process graph and improve the flexibility: the process path and/or composition are modified through rules evolution.

• A vertical process framework , providing generic processes that are business specific.

BPM use cases for service orchestration

Several use cases of the BPM technology for orchestration, including service orchestration, can be listed:

• Intra application

To orchestrate the different usages of application resources, those are internal and external to the application.

To orchestrate applications in a SOA, thus creating composite applications.

• Intra Information System (IS)

To implement the business processes, those are transverse to the applications. For example, the order/delivery business process.

To integrate applications in the scope of process management consuming integrations.

To compose services in a SOA, thus creating composite services.

• Inter Information System (IS)

To define scheduling of the exchanges between business partners, so called choreographies.

To focus on BPM technology for service orchestration:

• BPM is used to build business processes relying on the exposed services (see Figure 13).

It requires adequacy between the business process activities and the granularity of the exposed services.

Figure 13 – BPM technology for service orchestration in business processes



• BPM is used to build composite services from elementary services. The composite service brings added value with regards to a separate usage of elementary services, hiding the elementary services evolution and being a service at a higher level of abstraction.

Figure 14 – BPM technology for service orchestration in composite services

BPM products

The following taxonomy allows distinguishing BPM solutions in four software publisher categories:

• Traditional EAI publishers, who add a BPM layer to their traditional EAI solution and increased its level of abstraction 2 : Sun (Java Integration Suite ex Seebeyond), Vitria

(BusinessWare), TIBCO (Tibco Staffware Process Suite), Axway (XPM) …

• Pure players, who add some connectors to their BPM solution: Intalio …

• Application server publishers, who add a BPM layer to their traditional solution: BEA

(WLI & Fuego acquisition for Aqualogic), IBM (Modeler/WPS/Monitor), Microsoft

(Biztalk), Oracle (Oracle Fusion Middleware) …

• Traditional workflow publishers, who extend their solution towards the application integration, providing application connectors: W4 (EntireX by Software AG) …

2.3.3 Policy management

Generally speaking, the term policy is often referred as a set of system constrains, capabilities or requirements that affect the interaction between a consumer and a service. In some cases, the policy could be as simples as being able to decide the use of a service; in others, it could impact the quality of service agreement. Translated to the SDP domain, the policy management should be considered as a type of service gateway that allows partners controlled access to critical network resources with some type of policy enforcement rules.

“SDP opens up the network”

As IT and Network infrastructure are starting to converge within operators and service providers, there is a increasing need for an open and standards-based environment capable of providing converged data service for today’s and tomorrow’s networks. Service Delivery Platform was designed to help providers, network operators and system integrators to migrate from inflexible, silo-based networks to a more modern service oriented architecture that combines emerging technologies with legacy systems. Reuse, delegation, composition and service orchestration are some of the core principles of SOA, and they can be applicable to services developed in a Telecom domain or in an Enterprise/IT domain.

2

At first time, the BPM layer could only be used to orchestrate technical processes versus business ones.



The Service Delivery Platform is the key component of the service domain that should facilitate the creation, execution and management of services. This new service driven approach, should be standards-based and open to third parties, allowing communities to develop new services and, as a result, new business opportunities in the dynamic and rapidly growing market of services.

This new service business trend should never at any circumstance compromise security. Operators are looking for more functionalities, more control, more services, but all this should be done without neglecting security. The SDP opens up the network to an enormous community of services and services developers, but that needs to be done without sacrificing the management, security and control. The Service Delivery Platform must be capable of controlling network access and usage in a simple and highly flexible manner, to provide robust, reliable and rich services to its subscribers.

The Policy Management (PM) is the best alternative for the new service-based platform, an application/component that monitor services at the operation level, performs authentication and authorization, applies security policies, privacy, integrity and ensures service availability using powerful Service Level Agreement (SLA) and enforcement.

The policy management should deliver comprehensive security services including:

• Authentication

• Authorization

• Auditing

• Service Capability Access Control

• Service Capability Usage and or Quality of Service (QoS)

• Network access and protection

• Charging

• Privacy and Integrity

Network Access and Protection

Network usage and access is an important function for the Policy Management (PM); these types of policies define which providers have access to particular network nodes. Certain levels of service are guaranteed by prioritizing network usage, traffic from high priority service providers are always precedence over low priority service providers.

Service Level Agreement

Service Level Agreement is a part of the service contract (not a service contract type) where a certain level of service is agreed. The SLA can be seen as a document which defines the relationship between two parties: the provider and the recipient. A service agreement contract can contain zero or more SLA’s agreements and is an extremely important item of documentation for both parties. If used properly it should:

• Identify and define the customer’s needs

• Provide a framework for understanding

• Simplify complex issues

• Reduce areas of conflict

• Encourage dialog in the event of disputes

• Eliminate unrealistic expectations

Specifically it should embrace a wide range of issues. Amongst these are usually the following:

• Services to be delivered

• Performance, Tracking and Reporting

• Problem Management



• Legal Compliance and Resolution of Disputes

• Customer Duties and Responsibilities

• Security

• Termination

• Others

WS – Policy

Web Services are software systems, design to support interoperable machine-to-machine interaction over a network. One type of service that can be part of an SOA infrastructure, its a web service, defined by a set of technologies, that provide platform-independent protocols and standards used for exchange data between applications.

In the web service domain and because web services are loosely coupled and are forced to make no assumptions about each other, it is widely recognized that one of the major obstacles to prevent full adoption is the lack of features, such as, security, reliability, etc. Policy is considered as the possible solution of security features in web services.

At the present time, the Web Service policy space is cloudy and evolving. There are some proprietary proposals that highlight different aspects of policy requirements. A successfully policy management solution is to achieve a standardized policy framework capable of meeting the industry requirements.

WS-Policy [12] is a specification that allows the WS to use XML data to expose their policies and for WS consumers to specify their policy requirements. WS-Policy was submitted to the W3C on the 13 th

of April 2006.

WS-Policy provides a flexible and extensible syntax language for expressing the capabilities, requirements and general features in an XML based manner. The framework will describe how senders and receivers can specify their requirements and capabilities. WS-P schema will be full extensible and will define limits on the types of requirements and capabilities that can be described.

Subsequent specifications will provide profiles on WS-Policy usage within common Web Service technologies.

The goal of WS-P is to provide the necessary mechanisms to enable WS applications to specify policy information.

2.3.4 Service interaction

This section describes the interaction between Application Servers and IP Multimedia Subsystem specified in [31] and [32]. The interaction is performed through ISC interface. When the S-CSCF receives a SIP event from the UE, the decision at the S-CSCF to which Application Server the event should be sent is made based on iFC (initial Filter Criteria) information. Initial Filter Criteria

(iFC) are stored in the HSS as part of the user profile and are downloaded to the S-CSCF upon user registration, or upon a terminating initial request for an unregistered user if unavailable. They represent a provisioned subscription of a user to an application. After downloading the User Profile from the HSS, the S-CSCF assesses the filter criteria. Initial Filter Criteria are valid throughout the registration lifetime of a user or until the User Profile is changed. Figure 15 shows how S-CSCF handles the SIP event and distributes it using filter criteria. The details of Subsequent Filter Criteria

(sFC) is not specified at the moment.



Application Server

Service Logic

HSS

SIP Interface iFC sFC

SIP

S CSCF

S

SIP Filter Criteria SIP

T

Figure 15 – Application Triggering Architecture

Service Point Triggers (SPTs) are those points in the SIP signalling on which Filter Criteria can be set. The following SPTs are defined:

• any initial known or unknown SIP method;

• registration type – indicates if the REGISTER request is initial registration, reregistration, or de-registration;

• presence or absence of any known or unknown header field;

• content of any known or unknown header field or Request-URI;

• direction of the request with respect to the served user – either UE-originating or UEterminating to registered user; UE-terminating to unregistered user or UE-originating for unregistered user.

• session description information.

A Filter Criteria triggers one or more SPTs in order to send the related request to one specific application server. The set of Filter Criteria that is stored for a service profile of a specific user is called "Application Server Subscription Information". In order to allow the S-CSCF to handle the different Filter Criteria in the right sequence, a priority shall be assigned to each of them. If the S-

CSCF can not reach the Application Server, the S-CSCF shall apply the default handling associated with the trigger (release 6 and following). This default handling shall be:

• to continue verifying if the triggers of lower priority in the list match; or

• to abandon verification of matching of the triggers of lower priority in the list; and to release the dialogue.

Therefore a Filter Criteria shall contain the following information:

• address of the Application Server to be contacted;

• priority of the Filter Criteria providing the sequence in which the criteria shall be applied;

• Trigger Point composed by 1 to n instances of the Service Point Triggers (SPTs). The

SPTs may be linked by means of logical expressions (AND, OR, NOT, etc.);

• default handling ( as described above);

• optional Service Information that shall be added to the message body before it is sent to the Application Server (as an example this may include the IMSI for the IM-SSF).

The same priority shall not be assigned to more than one initial Filter Criteria for a given end user.

The S-CSCF shall request from the HSS the relevant set of iFCs that applies to the end user (i.e., registered, unregistered, or both). If the S-CSCF has a set of iFCs that is deemed valid (e.g., from a previous request), the S-CSCF doesn’t need to request a new set.



In the case that multiple Filter Criteria are sent from the HSS to the S-CSCF, the S-CSCF shall check the filter criteria one by one according to their indicated priority when the S-CSCF receives a message via the Mw interface (interface with another CSCF).

On reception of a REGISTER request, the S-CSCF shall send a third-party REGISTER request to each Application Server that matches the Filter Criteria sent from the HSS for the REGISTER request.

On an event that causes network-initiated deregistration, the S-CSCF shall send a third-party

REGISTER request to each Application Server that matches the Filter Criteria sent from the HSS as if a equivalent REGISTER request had been received from the user deregistering that public user identity, or combination of public user identities.

On reception of any other request the S-CSCF shall:

1. set up the list of filter criteria for that request according to their priority – the sequence of the filter criteria shall not be changed until the request finally leaves the S-CSCF via the Mw interface again

2. parse the received request in order to find out the Service Point Triggers (SPTs) that are included in it

3. check whether the trigger points of the filter criteria with the next highest priority are matched by the SPTs of the request and a) if it does not match, the S-CSCF shall immediately proceed with step 4 b) if it matches the S-CSCF shall: i) add an indication to the request which will allow the S-CSCF to identify the message on the incoming side, even if its dialog identification has been changed e.g. due to the Application Server performing third party call control ii) forward the request via the ISC interface to the Application Server indicated in the current filter criteria. The Application Server then performs the service logic, may modify the request and may send the request back to the S-CSCF via the ISC interface iii) proceed with step 4 if the request was received again from the Application Server via the ISC interface

4. repeat the above steps 2 and 3 for every filter criteria which was initially set up (in step 1) until the last filter criteria has been checked

5. route the request based on normal SIP routing behaviour

If an Application Server decides to locally terminate a request and sends back a final response for that request via the ISC interface to the S-CSCF, the S-CSCF shall abandon verification of the matching of the triggers of lower priority in the list. The final response shall include the indicator defined in step 3 b) i) above, so that the S-CSCF can correlate the messages.

2.3.5 Identity management

SOA provides us possibilities to build business applications that interact with each other at a component or building block level, however the identity management is still a immature part of the process.

Previously, companies built or bought applications and secure access to applications was simply a matter of linking valid users to the applications; providing local access rights, authentication and authorization, or they just simple were installed in a secured walled garden. SOA is about threading multiple applications together, but only using the functionality required. To achieve this, SOA

“abstracts” the business functionality of specific applications allowing them to be “discovered” and used by other applications.

Unfortunately, this presents an information technology security problem. In most organizations some of the business applications involved in any SOA-based application will have different identity mechanisms and security policies. Users will most likely have different privileges for


page 38 (80) Eurescom project report different applications, and thus they will need to be authenticated for each of the applications that are used by the SOA application.

Linking between applications occurs through an abstraction layer that does not provide access to local user identity validation in the applications that are accessed - unless the application itself provides such access, which is unlikely to be the case.

To consider a simple example, a SOA application might access an order entry capability within the order entry system, but the order entry system is unlikely to know whether the connecting application is authorized and has no means of directly checking it, or the security mechanisms might not be compatible or operate on the same level of authentication or use the same set of identities.

The underlying problem is that even when organizations have implemented fairly comprehensive access security, it is fragmented. In some cases user names are used, and in others derived identities or mapped identities are the basis for authentication.

To provide information technology security for SOA requires an end-to-end Identity Management capability – one that is able to determine access rights for every application involved.

Consider the Identity model in Figure 16 where we have a layered model of identities for an individual, but the model can also be used for organizations or groups.

• The 1st or lowest layer may be called the Physical Identity. This is you, without any reference or “handle” that people know you with (e.g., name). Attributes of physical identities are characteristics such as DNA, fingerprints, and retinal patterns: things associated with your physical being.

• The 2nd layer could be called Personal Identity (although this is not the most suitable term): what you experience as “me”. Some attributes of this are a user’s mood (I’m happy), user’s availability (I’m busy now), user’s location (I’m home) or user’s preference (I prefer light coke) etc. The key to this identity layer is that the user alone has the full control on it. This concept, however, is not supported much in modern day business systems, and is likely to remain unsupported. (In fact, software designer may object to the term identity being used for this concept.)

• The 3rd layer could be called Relational Identity. This identity is typically assigned to a user by an interacting party (thus, “issued” identity), and therefore only exists as long as a relationship is maintained. Moreover, it is only partially, if at all, under the user’s control.

Another way of describing this concept is saying that relational identity is a software representation of some one interacting with the user. Examples are driver’s license, passport, social security number, phone number, account ID etc. This kind of identity typically captures some aspect of a user’s personal identity that is relevant to the relationship at hand. This is also the kind of identity most directly supported in business systems (e.g., LDAP directories of employee data, governmental and corporate customer databases).

• The 4th layer might be called Virtual Identity. It is also, like Relational Identity, meant to be a software representation of information about some user(s). The important difference from Relational Identity is that it is meant to allow users to control their software representations just as they control their “personal identity”. Users could create Virtual

Identities on the fly, keep them persistent for as long they liked, and control access to it— and its attributes—by various business systems. This layer of identity is an approach to achieve privacy protection and allows users to fine-tune their personal information to others (which part to reveal, which part to hide), such as the user’s location, the user’s name and address, etc. Again, this is not supported in today’s business systems.



Virtual

Id

Virtual

Id

Virtual

Privacy and/or Federation

Id

Virtual

Id page 39 (80)

Work Identity

(employee Id)

Customer Identity

(C.C. number)

User Identity

(userid, password, email address)

Driver’s

License

Federation

Relational (“Issued”) Identity

Personal (Experiential) Identity

(Attributes: Mood, Location, Behaviour)

Physical Identity (Attributes: DNA, Fingerprint)

Figure 16 – Identity model

So seen from a SOA perspective there are a lot of cross layer issues that there is no simple or feasible solution known today, and the SOA communities still at the end of the day will have to work out the end-to-end identity management for components to truly interoperate, and able to be chained in any fashion.


page 40 (80)

3 Applying SOA to SDPs


3.1 Business Requirements

Current vertical solutions (silo) must migrate to horizontal layered structures, where the new market requirements and NGN service business direction should be taken into account. The key problems with the siloed approach are:

• Duplicate integration work for each service

• Duplicate features and data for most services

• No shared services(at the service layer there are almost no shared services)

• Different management facilities for each deployment

SDP is a model of a horizontal layered solution and from our current analysis we can reasonably conclude that four key elements constitute a comprehensive SDP:

• Service Execution Platform (e.g. Telecom Application Server): a core element of a SDP providing the deployment and execution environment for broad range of voice and data applications

• Network Abstraction Layer (e.g. Parlay GW or SIP GW): a core element of a SDP providing standardised interfaces to core network elements and services

• Service Exposure Layer (e.g. Parlay X GW): an optional element exposing service capabilities (usually via Web Services) to 3rd party service providers and enterprises

• Content Delivery Platform: an optional element usually present in mobile SDPs for the provisioning of multimedia content to mobile devices

General business goals and requirements for a SDP may be summarised as follows:

• Improve ROI over current technology silo-based approach to service delivery

• Provide platform for both content and applications

• support triple & quad play service offerings

• Improve customer retention, minimise churn, increase ARPU & margins

• Provide revenue sharing capability with 3 rd

party suppliers

• improve opportunity to out-source non-core aspects of the business

• Improve speed to market significantly (measured in weeks rather than months)

• Provide greater flexibility in processes and in applications/ functions

• Enable timely/ cost effective integration of new systems developed on open standards

• Enable delivery of personalised media and one-to-one advertising /communication

• Provide a capability to own certain classes of data e.g. location, identity, calendar

• Provide 3 rd

party service development/ deployment capability

• Enable the exposure of network capabilities and value-added services to enterprises

Considering these goals and requirements let’s then take the generally accepted principles that underpin SOA and apply them to the SDP. Our expectation is that we should get a more flexible environment that gives the telecoms operator a higher level of agility than otherwise achievable through traditional siloed and point integration means. However, as none exists today we can only surmise how this might actually look.



An SOA-based implementation should have the following additional attributes that would differentiate it from the ‘more traditional’ implementations. The following can be read or interpreted as requirements.

• Services are reusable

Services are designed to be extensible, with design standards that promote reuse and are standardised.

Services are easily discovered by developers (Service creation environment) and at runtime (Service execution environment).

• Formal contracts exist among services

Formal definitions exist for endpoints, operations, rules, service characteristics, inputs and outputs.

• Services are loosely coupled

Services limit dependencies to the service contract with interaction allowed within predefined parameters only.

• Services are abstracted

Services provide an abstract representation of the underlying logic with the appropriate level of operation granularity.

• Services are Autonomous

Services have control over the logic they encapsulate, that is, upon execution the service has governance over the underlying application logic.

• Services are composable

Services can be coordinated and assembled to form composite services, that is, they can participate as effective members of other services.

• Services are stateless

Services should minimise the amount of state information they manage and the duration for which they hold it. Statelessness is the preferred condition as it promotes scalability and reuse.

It is fair to assume that SDPs for Telecom Service Providers will develop into a multi-tiered, loosely coupled architecture that will interoperate in near ‘real-time’ with the network. As services migrate from connection based proprietary technologies to packet based open IT technologies the role of applications such as Service Delivery Platform will evolve and grow to the extent that these components will form an integral part of the base service and customer experience and thus will have to exhibit similar ‘carrier grade’ characteristics as the network itself.

Therefore a SOA based SDP should, where necessary, provide ‘carrier grade’ capabilities in line with the network services it exposes. Carrier grade can be summarised as an implementation that exhibits particular qualities beyond regular IT reliability, availability, serviceability and manageability (RASM) features enabling its mission critical use in a service provider’s offering.

This subject is examined in much greater detail in Eurescom Project P1552.

3.1.1 Business objectives

Enterprises are looking to eliminate as much delay and business process friction as possible, and

SOA is a path to do this. SOA enables more flexible and reusable services that may be reconfigured and augmented more swiftly than traditional construction of applications systems. Hence, SOA can accelerate time-to-business objective, resulting in better business agility.

Achieving this business agility is a key tenet of improved competitiveness. Enterprises are looking to SOA to maximize return by reducing complexity and cost of change. SOA can mitigate the risk of technological and business change since SOA platforms offer standards-based services that can


page 42 (80) Eurescom project report be reused. SOA increases business agility and responsiveness by increasing reuse of components and services, reducing new code creation and associated cost. Finally, enterprises are looking to improve business performance including customer satisfaction and improved value chain execution.

SOA is an approach for building distributed systems that deliver application functionality as loosely-coupled services. SOA provides a standard way to represent and interact with application functionality by leveraging open standards. This is critical to improve interoperability and integration across an enterprise and value chain. Standards also reduce business process friction by enabling the reuse of services. Developers can create new applications from existing components more quickly than building functionality variations from scratch. SOA allows the developer to focus on application assembly which speeds time to implementation.

Successful service-oriented architectures, however, begins with process modelling and careful collaboration between IT architects and business stakeholders. Before enterprises deploy SOA on a large scale, getting these teams together in a disciplined planning exercise can unlock the business value. The true value of Service Oriented Architecture is achieved when Business Architecture is joined with IT Architecture

3.1.2 Overall benefits of Service Oriented Architecture

• Increased Revenue

Creates new routes to market, new value from existing systems

• Increased Flexibility

Flexible business enabled models by increased granularity of IT processes, called

‘services’

Allows easier development and maintenance of large-scale, distributed applications and services involving unpredictable and/or asynchronous occurrences

• Increased speed and quality of development

Offers the potential to combine and reuse pre-built service components for rapid application development and deployment in response to market change

Promotes component and service reuse, therefore enabling a more agile and higher quality development environment

• Increased efficiency

Integrates historically separate systems, facilitates mergers and acquisitions of enterprises

Reduced cycle times and costs for external business partners by moving from manual to automated transactions

• Services

Enables the possibility of offering new services to customers without having to worry about the underlying IT infrastructure

• Decreased cost

Eliminates duplicate systems, build once and leverage

• Decreased risk

Improves visibility into business operations

3.2 SOA Applicability

Business processes have traditionally been built in a bottom up fashion, where either a data model or individual elements or sub-systems have been integrated together to provide larger systems. This integration process and huge replication and scattered data distribution, makes it difficult to add or


Eurescom project report page 43 (80) change existing systems. Hugh amounts of specialized equipment and other legacy systems in the telecommunication domain, makes changes to business processes especially hard.

With the SOA approach, the interactions between modules are streamlined and organic growth is possible. Existing legacy can be wrapped with a SOA approach, and made available as SOA components. SOA enables flexible and reusable services that can be reconfigured and augmented more swiftly than traditional applications, accelerating time-to-business objective and improving business agility.

Achieving this business agility is a key tenet of improved competitiveness. Enterprises are looking to SOA to maximize return of investment, by reducing complexity and cost of change. SOA can mitigate the risk of technological and business change because SOA platforms offer standardsbased services that can be reused. SOA increases business agility and responsiveness by increasing reuse of components and services, reducing new code creation and associated costs. Finally, enterprises looking to improve business performance, including customer satisfaction and improved value chain execution, will experience improvement in both areas.

3.2.1 Service creation

The Service Creation scenario is taken from the IBM redbook [13] and (service provider and service consumer) is used to demonstrate exposing application functionality of an existing application or new business logic as a service. The services can then be consumed by other services or client applications within an enterprise and between enterprises.

3.2.1.1 Business context

For example, a customer has a core set of IT or business functions which offer value to a variety of internal and external clients. The customer wants to enable a wider use of these functions without incurring the complexity of point-to-point integration with each of its customers. By exposing the application functionality as services, client applications internal and external to the enterprise can consume these common services. This SOA approach simplifies the integration challenges and leverages the business value of existing systems.

3.2.1.2 Business Value

The Service Creation scenario solution domain includes the following defining elements that provide business value:

• Ease integration challenges

• Provide a modern, industry standards-based posture to EIS (for example, CICS or IMS) systems

• Leverage the business value of existing applications

• Enhance responsiveness to business demands

• Increase reliability through reuse and fewer connections

3.2.1.3 Service creation scenario realizations

There are many possible examples to illustrate the Service Creation scenario. The list gives some suggestions for Service Creation scenario:

• Directly expose existing applications as services

• Indirectly expose existing applications with service components

• Create an EJB Web service from WSDL

• Consume services from third-party service providers



The realizations are representative of the service architecture and the method in which the service is created. The service architecture describes whether the application functionality will be exposed directly as a service, or indirectly using a middle-tier service component. The realization examples include different approaches to creating services such as bottom-up and top-down. There is a wide range of existing application types such as EIS (for example, CICS and IMS), J2EE, SAP, and so forth.

3.2.2 Service provisioning

A proof of concept has been elaborated by France Telecom in the context of the studies relating to the interface between Information System and Service Platforms.

The objectives of the prototype were:

• The definition of the functional architecture for delivery, including evaluating the interest of adding one more layer in the delivery architecture: the adapter layer

• The definition of a generic process for the activation of Service Platform

3.2.2.1 Architecture

The architecture that has been defined is composed of 3 levels:

• Exchange system

• Service Configuration and Activation (SC/A)

• Adapter layer

End user

Self

Service

EDIN 0532-1652

CRM

Rating

Technical

Nomenclature

Technical park

Référential

Databases

Order

Exchange

System Expansion into partial fractions

Scheduling

1st level n Actions

Activation Interface for

Commercial Services

SC/A m Opérations


Technical Services

Expansion into partial fractions

Optimisation

Scheduling

2nd level

Adaptation

Update technical Park

Technical nomenclature for Enablers

Référential

Databases

Expansion into partial fractions

Optimisation

Scheduling

3rd level

Notification

Functions

Adaptation

( Transformation)

Localisation of the

Platform instances and Routage


Platforms and Enablers

Internet

Service

Platform

Mobile

Service

Platform

Enablers

...

Adapter

Layer

Identity

Enabler

Network

Figure 17 – Service Provisioning Architecture

 2006 Eurescom participants in project P1652


3.2.2.2 Process page 45 (80)

The generic process for activation:

• the customer subscribes to a commercial offer, related to one or several commercial services

• the Customer Relationship Management (CRM) sends an activation order to the

Exchange System

• the Exchange System routes the order to the Service Configuration and Activation (SC/A)

• the SC/A translates commercial services into technical services and begins the activation process of the SC/A (scheduling of the activation orders –Work Order- sent to the

Adapter Layer, update of the technical park, sending of an acknowledgement back to the

Exchange System)

• the Adapter Layer gets the Work Order (WO), interprets it, exchanges information with referential data bases (Identity enabler 3 for the identification of the users), sends an acknowledgement back to the SC/A.

3.2.2.3 Components of the architecture

3.2.2.3.1 SC/A layer

The SC/A layer is responsible for configuration and activation of commercial services on service platforms. The SC/A interface allows the five following operations: activate / change / cancel / suspend / reactivate

Figure 18 – SC/A algorithm

3

An enabler is a shared element (for example an application or composition of applications) which facilitates the construction of a user service. It is provided for the environment in which the user services can be developed and deployed. It is not visible by the user. It has a clearly identified functional scope.



The SC/A algorithm consists in two sub levels.

The algorithm of higher level manages commercial services; it consists in the following steps:

• Order line reception

• Generate and execute the scheduling of commercial services (activations are dynamically scheduled related to precedence rules)

• Invocation of the sub process managing technical services

• Sending of an acknowledgement to the Exchange System

A sub part of the algorithm manages technical services; it consists in the following steps:

• Translating commercial services into (several) technical services (using the technical nomenclature)

• Determine actions to produce on technical services depending on the technical park

• Generate the corresponding work order

• Update of the technical park

• Sending of an acknowledgement

The generic sub part of the lower level is responsible for sending the work order, consisting in:

• Querying the technical park

• Sending the work order

• Returning an acknowledgement

3.2.2.3.2 Adapter layer

The Adapter Layer component hides the complexity of the architecture of the Services Platforms to the Information System (especially the distinction between atomic or composite logical services, provided by one or several Service Platform).

It takes part in the logical separation of different problematical: linked to customer, user, service instance, etc.

It abstracts both the fact that the service is provided by one or several platforms, and the fact that the service is composite or basic: introducing the concept of composite or atomic logical service.

The Adapter Layer manages the following cases

• The service is provided by one single platform

• The platform needs an enabler to provide the service

• The service is made of several combined services, provided by different platforms

• The service is provided by several service platforms, developed by different handlers

Activation interface of the Adapter Layer

The Adapter Layer interface allows 5 operations: activate/change/cancel/suspend/reactivate

Generic process for activation, concerning the Adapter Layer

• Determine the logical service type

• Query the Identity enabler

• Identify the concerned platform

• Query the technical nomenclature referential for service platform

• Generate the activation sub processes for service platform that need enablers



• Activate the user or administrator on the service platform

• Analyse of the work order

• Sending back an acknowledgement to the Service Configuration and Activation

3.2.2.3.3 Referential databases

The referential databases define the following entities: Customer, Contract, Technical Park

Element, Technical Service, User, Service Platform, Account, Resource, Basic Logical Service,

Logical Service, Composite Logical Service, and Enabler.

3.2.3 Service execution

Silos based Service Architectures

Service Architectures specified today are developed by standards bodies and are focused on particular services. Services are delivered though separate, silo based implementations and implemented by integrating different components vertically and per-service. All the implementation and integration work made for one particular service cannot be reused for another.

Independent services are delivered through independent platforms:

• Entertainment based services are commonly delivered by satellite, CATV systems, etc;

• Mobile telecommunications services are delivered via base-stations;

• Fixed telecommunications services are usually delivered over the leased line.

This vertical nature of standards and products are holding back the adoption of today’s market requirements. Silo based implementations tend to raise the costs and delay deployment of new and innovative services. Vertical solutions (silo) must migrate to horizontal layered structures, where the new market requirements and NGN service business tendency should be taken into account.

From a service provider perspective, vertical solutions tend to:

• Duplicate integration work for each service

• Duplicate features and data for most services

• No shared services(at the service layer there are almost no shared services)

• Different management facilities for each deployment

The result in a non-satisfactory time-to-market and inconsistent user interfaces across multiples services. This monolithic approach has an extremely debilitating effect on service provider’s capability of developing new sets of value-added services and revenues.

99,999% Execution Environment

Today’s SDP are intended to enable the rapid development and deployment of new converged multimedia services. The service execution environment is a fundamental component in the NGN

SDP, designed to support services for today and tomorrow networks. An execution environment that is the heart of a service delivery platform must be flexible, carrier grade.

A carrier grade SEE (Service Execution Environment) key requirements:

• Performance/ Low Latency – services need to be executed with sufficient performance and low latency, the high throughput should not significantly affect performance

• High Availability – services need to be available whenever needed. The service platform should be tolerant to system failures, overload situations and capable of quickly solve and isolate problems, ensuring continuously availability

• Reliable – the execution environment is a consistent and stable environment where service execution is guaranteed to be constant in many different situations



• Service Portability – “ Write Once, Run Anywhere ” is the philosophy behind portability.

Services should be developed and deployed on any compliant execution environment with the least effort. There should be no need for re-architecture, recompilation or any other alteration

• Enabler technology - network independence – the execution environment should be agnostic to any particular underlying network protocol. The programming model should be abstracted from all the network details. Enablers are building blocks that expose and facilitate the usage of underlying network capabilities

• Industry Standard – the execution environment specification should be the outcome of any standards organization, having the potential to attract more industry support than any proprietary execution environment

• Open, Easy and Rapid Development – By adopting an open-garden approach and easyto-use development APIs, services can be developed by third-party communities, enhancing and accelerating new service development and revenues

• Manageability – easy configuration, maintenance, monitoring should be taken into account. The service execution environment should provide some management APIs that can be extended to existing management infrastructures

• EDA (Event Driven Architecture) – Telecom services are by nature event driven, the execution environment must support such programming model

A SEE is a flexible and extensible architecture that offers support to application developers and

Service Providers. One of the intentions of the execution environment is to support business application integration, where new and enhanced services are integrated to bring new business applications, increasing business processes automation in a very flexible manner.

SOA is the key to bring composition, reusing, orchestration and delegation to the execution environment. Operators or service providers can now compose bundles of services as the market requires, reusing basic service capabilities. A service can be used in multiple scenarios without changing the underlying implementation, a fundamental SOA principle.

At the present time there are three solutions that can handle the requirements for a highly available execution environment, the J2EE platform, the Sip Servlet API and the JAIN SLEE.

3.2.3.1 J2EE

Java Platform, Enterprise Edition or Java EE (formerly known as Java 2 Platform, Enterprise

Edition or J2EE up to version 1.4), is a development platform for creating and running distributed multitier architecture java applications, built in top of modular software components and executed mostly on application servers. Java Enterprise Edition includes several API specifications, like

JDBC, RMI, JMS, EJB, JSF, JSP and so many others.

Over the last years the J2EE platform has been the most popular choice when comes to IT development, building distributed, transactional and highly scalable applications. Application developers can rely on the application server for handling transactions, security, scalability, concurrency and management of the components that are deployed to it, focusing only in the application business logic.

A Telecom environment demands services to be highly available and J2EE is a recognized platform for the development of critical application where availability is needed. Low latency and high throughput are also evident characteristics in the J2EE platform.

Telecommunication services are inherently asynchronous and event driven. The service execution environment must efficiently implement this event driven model to cope with telecom services. The

J2EE platform is capable of implementing an event driven architecture by integrating the JCA architecture and the message oriented model of the ESB (Enterprise Service Bus).

The J2EE Connector Architecture (JCA) defines a standard architecture for connecting the J2EE platform to heterogeneous EIS systems. By defining a set of scalable, secure, and transactional


Eurescom project report page 49 (80) mechanisms, the J2EE Connector architecture enables the integration of EISs (Enterprise

Information System) with application servers and enterprise applications.

The J2EE Connector architecture enables an EIS vendor to provide a standard resource adapter for its EIS. The resource adapter plugs into an application server, providing connectivity between the

EIS, the application server, and the enterprise application. This bidirectional adapter framework allows an application to both send and receive events to and originated from underlying networks.

Multiple resource adapters (that is, one resource adapter per type of EIS) are pluggable into an application server. This capability enables application components deployed on the application server to access the underlying EIS systems.

3.2.3.2 SIP Servlets v1.0

Part of the Java Specification Request (JSR 116), the SIP Servlet API v1.0 defines a high-level extension API for SIP servers, enabling SIP applications to be deployed and managed based on the servlet model. An HTTP servlet is a Java application that runs in a Web server or application server and provides server-side processing, typically to access a database or perform e-commerce processing. It’s the Java-based natural replacement for CGI scripts, Active Server Pages (ASPs) and proprietary plug-ins written in C and C++. Servlets are similar to the CGI concept but, instead of using a separate process, messages are passed to a class that runs within a JVM (Java Virtual

Machine) inside the server.

SIP Servlets are very similar to HTTP Servlets, the main difference is simply the enhanced interface to support SIP functions. Because they are written in Java, servlets are portable between servers and operating systems. The SIP Servlet specification can be found on the IETF site and the specification being developed under the JCP can be found on the Java Community Process web site.

Sip Servlet v1.1 defined in the Java Specification Request 289 is an enhancement to the SIPServlet specification v1.0. The central focus of this JSR is to enhance the existing SIPServlet specification with new requirements determined by the industry.

3.2.3.3 JAIN SLEE v1.0

The JAIN SLEE API specification v1.0 defined in JSR 22, defines a standard service logic execution environment plus a specification on how portable, carrier grade telecommunications services can be built, managed and executed. The JAIN SLEE specification has been designed to support telecommunications services and to enable the implementation of carrier grade call signalling environments.

JSLEE is the only industry standard aimed at portable communications applications, i.e. a communications application can be written once and run on many different implementations of

JSLEE. Application portability is made possible by the combination of a programming language

API (specified using the Java programming language), an unambiguous technical specification, a

Reference Implementation, and a rigorous suite of tests that a vendor must pass before their product is compliant with the JSLEE specification.

JSLEE is the point of integration for multiple network resources and protocols. Applications can use many different external network resources from within the JSLEE environment. As a protocol agnostic application environment it is necessary for a SIP resource adaptor to be used to provide

SIP functionality. By combining JAIN SLEE and JAIN SIP a fully standards compliant based SIP application environment is created.

The JSLEE specification allows developers to write robust components as integrates the well known ACID properties of transactions into the programming model. Components can be composed to solve more complex problems.

Currently, there is a ongoing process (JSR 240) API specification v1.1. This new version is a logical extension to address gaps in JSLEE v1.0 specification. The central area of focus is to specify the Resource Adaptor Architecture API and semantics.


page 50 (80)

3.2.3.4 SIP Servlets vs JAIN SLEE


SIP Servlets JAIN SLEE

Applications Based on HTTP Servlets

Unit of application logic is the servlet

No standard model for composition and reuse

Component based, Object Oriented architecture

Unit of logic is the Service Building

Block (SBB)

Support for composition and reuse

State

Protocols

Supported

Facilities

Servlets are stateless

Shared state may be stored in a separate session Map

SBBs may be stateful

Shared state may be stored in a separate

ActivityContext via a type safe interface

Shared state is visible to all Servlets with access to the session Access to shared state may be specified at deploy time

SIP and HTTP Protocol agnostic

Can be extended to support additional protocols and external resources

Timer Timer

Trace

Alarm

Statistics and Usage

Profiles

3.2.4 Service migration

Existing modules or components can be added to a SOA system, basically by wrapping them into an adapter for the ESB that the enterprise has selected. This is usually done by creating Web

Services out of existing legacy. However one needs to note that WebServices only provide syntactical interoperability, not semantical interoperability. Web Services are fundamentally based on a small number of widely accepted standards, namely XML and XML Schema, SOAP, and

WSDL. XML Schema defines structure and data types and WSDL defines the interfaces, operations, parameters and return values, but XML and WSDL do not define the meaning of data and WSDL does not define what a service does. In order to migrate into SOA one needs to consider:

• Simple standards that define the available interfaces and structure of data that is conveyed across those interfaces

• Platform and language-independent interfaces based on these standards, which allow applications to invoke services operating on any device supporting the SOA regardless of the hardware platform, operating system, or implementation language

• Clear separation of service interface from implementation, thus allowing many service upgrades to occur without impact on service users

• Message-oriented communication allowing distribution across a wide area

• Loose coupling between services, minimizing interdependencies and facilitating reuse

• Mechanisms for discovery of services available and for establishing connections with services

• The cost involved in migrating a service to SOA, opposed to re-engineering it



Clearly, the hallmark of SOA is flexibility. Computing platforms and languages can vary; services can be accessed across a network via simple, well-defined interfaces, and (presumably) without concern for side effects resulting from dependencies between services. This allows applications to use (or be composed of) services efficiently and effectively.

However, migration to SOA is neither easy nor automatic, particularly when the SOA will execute within a tightly constrained environment.

• The Communications and Common Service Infrastructure Provider must identify the network and communications protocols and standards to be employed. He or she must also determine what additional SOA infrastructure capabilities are necessary and provide them as common services (e.g., service registry, service orchestration mechanisms)

• The Application Designer must develop application-specific code and locate/select appropriate services to be used by the application, or develop code to invoke mechanisms to select services. He or she is concerned with whether services invoked by the application meet a full range of capability, quality of service, and efficiency of use expectations

• The Service Provider must identify a needed service, and modify or develop service code to provide a useful capability to the widest range of applications possible

Infrastructure developers have to design, create and maintain these common services for both internal and external use.

There are aspects of the legacy system that could make the effort challenging

• Poor separation of concerns

User interface code is tightly coupled with business function code

• Availability of tools

XML and SOAP libraries are not available for all legacy platforms

• Architectural mismatch

The asynchronous call to the service might be in conflict with legacy system synchronous behaviour

• Operational mismatch

The legacy system is batch-oriented; the service user expects an immediate response

• Dependencies on commercial products

Licensing issues?

3.3 SOA@SDP use cases

This chapter contains two new service examples that are good candidates to be implemented and deployed on a SOA platform. The services are Caller ID on IPTV and Color Ring Back Tone.

3.3.1 IPTV

Recently the converged services which provide communication and broadcasting feature have been emerged. IPTV is the typical service of that. Using IPTV, the service provider can provide various value-added services like caller ID (This service enables a user who is watching the TV receive voice call identification on the TV screen and then provides the option for pausing, and recording the video stream for the duration of the call).



5-3 NotifyCalledNumber

AS

1. createMulticastGroup

2-1. inviteParticipants

3. startNotification

4. playMediaStream

6. getUserPresence

7. getMulticastGroupMember

...

Parlay X gateway

2-2. join the multicast group

2-7. notification of joining

5-2 Query to parlay X gateway

IPTV HeadEnd/ Contents Server

Contents Server

IP Multicast Network

2-3. INVITE

2-6. NOTIFY

B

5-1. A calls B

Edge

2-5. IGMP join

Router

2-4. INVITE

IPTV

IPTV IPTV

A

Figure 19 – Caller ID on IPTV

If the underlying implementation is based on SOA, new providers and new equipments is easily incorporated and able to produce services with a fast time to market. This includes new types of set-top boxes as well as residential GW’s at the end-users premises. Also the network configuration benefits from the SOA approach, as in new network equipment can be added from new vendors as well.

3.3.2 CRBT

"Color Ring Back Tone" (CRBT) has been considered in the scope of the proof of concept developed by France Telecom (see 3.2.2 - Service Provisioning).

"Address Book" and "Color Ring Back Tone" (CRBT) are two optional services, part of the commercial offer "My Telephony". "My Telephony" offer includes both an IP access (ADSL) and a Voice over IP service (VOIP).

Ring back tone is the ringing that is heard by the originating party after dialling and prior to the call establishment.

The CRBT is a service to the called party which diffuses a musical announcement to the caller prior to the call establishment. This announcement replaces the traditional ring back tone.

Address book is the entity that contains a number of records describing the contacts of the user.

Address book is necessary to be able to colour the ring back tone in relation with the caller.

3.3.2.1 CRBT activation process

CRBT commercial service activation process conforms to the process explained in the paragraph

3.2. Service Provisioning:

Users having the service of VOIP can subscribe to CRBT.

In this case, CRBT activation process orchestrates and configures required resources.

• Address Book is activated (account creation for Address Book service, update of Identity

Enabler)

• IMS is activated (user creation on HSS basis)



• CRBT service is activated, user profile on HSS database is modified (a trigger is added on HSS configuration). The received calls will then be routed towards the CRBT application server in order to provide the service, if the configuration of the service by the user requires it

• Identity enabler is updated

3.3.2.2 The defined architecture

The provisioning process is exposed as a web-service, WSDL deployed, which is compliant with an SOA .

Other systems send provisioning requests through the "Adapter Layer". The "Adapter Layer" centralizes authentication, authorization, routing, data conversion and reporting functions.

The architecture that has been defined is composed of:

• Final services

• Proxies expose final services throw web-services or provide other services

• Adapter Layer makes the services provided by enablers, available to customers. It references proposed services into a directory.

• The interface is used by Information System and Service Configuration and Activation

(SC/A) to request provisioning.

3.3.2.3 The CRBT server into the IMS network

SC/A

Adapter Layer

CRBT

Customer care/ Self

Care

(browser

HTML)

"this melod

Media

Server

CRBT

Address

Book

Identity

Enabler

HSS

Activation

Use

SIP Flow

RTP Voice

RTP Melody called

IMS caller

S-SCCF

Figure 20 – CRBT architecture

The CRBT server is interfaced with:

• Serving-Call Session Control Function (S-CSCF) through IMS Service Control (ISC), using SIP protocol

• Media Server using SIP and http/vxml 2.0 protocols

• the CRBT Self Care using http/soap/xml protocol

• administration consol (customer care) using http/soap/xml protocol


page 54 (80)

• the adapter layer (provisioning) using http/soap/xml protocol

CRBT database can be accessed using SQL commands.


3.3.2.4 CRBT API description

Provisioning API:

The provisioning API makes possible to

• Activate (creates a new user for the service of CRBT)

• Modify (modification of CRBT service for a user.)

• Suspend (suspend the service for a user. The parameters of service of the user are preserved on the systems)

• Reactivate (reactivates the service for a user who has been suspended)

• Cancel (removes simply the account user on service CRBT) the CRBT service

• Add or suppress melodies

Service configuration API

CRBT has also an API to configure the service for self care use.



4 Conclusion / Recommendation

In the deregulation era, where voice and data services are commodities and disruptive market entrants provide clever value added services, operators need to turn themselves into service businesses, giving the market a wider choice of sophisticated and blended services and giving the customer an appropriate service experience.

To achieve these goals and moving from an era where services were driven by the networks to one in which networks will be driven by services, operators need a consistent, flexible and automated environment for delivering services to end-users.

In essence, operators need to support efficient service creation and provisioning processes and an adequate service execution environment so services can be adequately billed to the customers.

In the past typically services were built as “stovepipes” running in different parts of the organization, each tied to a particular type of network and each with its own service creation, provisioning and execution environments. This duplication is highly costly and constitutes a barrier to a new and a quick service deployment.

This new “Service Layer” will need to see the underlying infrastructure at a high level of abstraction, hiding the complexity of the network.

These requirements are met by “Service Delivery Platforms” (SDPs) which aim to provide a highly automated environment that can be reused by all services, providing a single platform for service creation, provisioning, deployment and control. It should shield service developers from the complexities of one type of network, making service bundling easier where voice, data and video services can be combined into compound multimedia services.

An SDP is based on the principles of “Service Oriented Architectures” (SOA) and reusability, providing a common set of functions and a common way to view the underlying network.

Increasingly SDP standards are coming into the telco world from the IT sector. For example, SOA promotes a Web Services approach, which is now becoming the de facto standard for communications among the different components of the SDP. In particular, service orchestration technologies (such as BPEL) is becoming part of emerging SOA SDPs, enabling services to be composed from telecom functional blocks and blocks of business logic from the IT domain.

At the same time, the IMS (IP Multimedia Subsystem) architecture standardised by 3GPP, is influencing the way operators think about service architectures decoupled from the network. Early adopters are rethinking and possibly reengineering their SDPs so they can take into account new requirements being defined by IMS.

For example, Service Interaction which takes place in the IMS domain and enables multiple network functions to be blended together in the same session without conflicting with each other, should be addressed by operators in their SDP solution. Other aspects , include

Accounting/Charging aspects, Subscriber and Identity Management and Service Provisioning, just to name a few.

In summary, the next generation of SDPs will be heavily influenced by the well established 3GPP

IMS architecture, and a sound “SOA enabled SDP” will constitute arguably an operator’s greatest source of competitive advantage.



References

[1] The Liberty Project, “Liberty Specs Tutorial”, http://www.projectliberty.org/liberty/content/download/423/2832/file/tutorialv2.pdf

[2] Liberty Alliance web site, http://www.projectliberty.org/

[3] http://www.itu.int/aboutitu/overview/itut-sg.html

[4] http://www.itu.int/ITU-T/ngn/fgngn/index.html

[5] http://www.itu.int/ITU-T/ngn/index.phtml

[6] C. Lee and N. Morita, “Next Generation Network Standards in ITU-T”

[7] 3GPP TS 23.228

[8] 3GPP2 X.P0013.2

[9] Web Services Interoperability site, http://www.ws-i.org

[10] Open Mobile Alliance, http://www.openmobilealliance.org/

[11] OMA Enablers, http://www.openmobilealliance.org/release_program/index.html

[12] WS Policy, http://www.w3.org/Submission/WS-Policy/

[13] Patterns: SOA Foundation Service Creation Scenario, IBM Redbooks http://www.redbooks.ibm.com/redbooks/pdfs/sg247240.pdf

[14] Service-oriented architecture, From Wikipedia, the free encyclopedia, http://en.wikipedia.org/wiki/Service-oriented_architecture

[15] OASIS SOA Reference Model Technical Committee, http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm

[16] RM for SOA Public Review Document (PDF), June 2006. http://www.oasis-open.org/committees/download.php/18486/pr-2changes.pdf

[17] eXtensible Messaging and Presence Protocol (XMPP), http://ww.XMPP.org

[18] The Internet Engineering Task Force (IETF), http://ww.IETF.org

[19] Google, http://ww.google.com

[20] Libjingle, http://code.google.com/apis/talk/about.html

[21] JEMS, http://www.jboss.com/products/soa

[22] LAMP, http://www.lampware.org

[23] SMART: The Service-Oriented Migration and Reuse Technique, Technical Note: CMU/SEI-

2005-TN-029

[24] 3GPP TS24.229

[25] 3GGP2 X.S0013.4

[26] 3GPP TS29.328

[27] 3GPP TS29.329

[28] 3GPP TS 32.225

[29] 3GPP2 X.S0013-008

[30] 3GPP TS 26.236

[31] 3GPP TS 23.002

[32] 3GPP TS 23.218

[33] 3GPP TS 23.271



Annex A OMA Enabler Releases

page 57 (80)

A.1 Candidate Enabler Releases

1) OMA Billing Framework v1.0

In the traditional telecommunications field, charging is merely measuring the connection time or data volume. The concept is completely different in the mobile domain, where charging should be defined by the service usage, and not necessarily, the time or data being used in the transaction.

OMA Billing Framework is a technology that enables billing features for wireless devices using the

Wireless Application Protocol (WAP).

The WAP Billing Framework (WBF) defines the resources necessary to enable charging for transactions taking place in either the proxy or the content server. These transactions are defined as chargeable operations, and used to define the service usage. Measuring the service usage opens a variety of new billing models that can be used in mobile telecommunications.

2) OMA Browsing v2.3

OMA Browsing v.2.3 provides browsing capability for mobile and wireless handheld devices. The

OMA browser Enabler uses the same technology stack used by today’s personal computers to access content on the World Wide Web (WWW), but with some constrains concerning resources and user interfaces.

Backwards compatibility has been considered since version 2.2, allowing new devices conforming to V2.3 accessing legacy content. The collection of specifications gathered in this release, define the application-level protocols, semantics, syntax, content formats, user agent behaviour, and the use of hypermedia transfer protocols required to achieve consistent function and interoperability of services.

3) Browser Protocol Stack v2.1

The previous version of the Browser Protocol Stack Enabler was intended to address low bandwidth characteristics and session capabilities to the wireless environment. This release was also suitable for a very wide range of wireless networks, including non-IP networks. The Browser

Protocol Stack Release 2.1 inherits all previous capabilities and adds a new stack, the Internet

Stack, based on wireless profiles of IETF-defined protocols. This is suitable for use on top of IP network only, but provides greater interoperability for services, which are designed both for

Internet and wireless access.

4) OMA Client Provisioning v1.1

The Client Provisioning Enabler is a technology that allows WAP clients to be configured with the minimum user interaction. The current release is a backwards compatible extension of the client provisioning functionality included in WAP 2.0. Support was added to the current release for direct access and application access provisioning.

5) Client Side Content Screening Framework v1.0

The Client Side Content Screening Framework defines the framework interfaces used by OMA or non-OMA enablers on the mobile terminal side. The enabler provides content scanning functionality to detect and screen malicious content. This technology also defines how enablers should interact with the content scanning functionality through the framework interfaces.

6) OMA Email Notification v1.0

OMA Email Notification Enabler supports a notification mechanism that allows e-mail servers to invoke the e-mail client on the mobile side, by using the WAP Push framework. The enabler defines a unique format for e-mail notification (EMN) in the form of a new content type that can be pushed to any mobile device supporting WAP Push. The specification is extensible to the clientside agent that handles the notifications and forwards it to the e-mail client.



7) OMA External Functionality Interfaced v1.1

OMA External Functionality Interface (EFI) defines the means through which components or entities with embedded applications, that execute outside of the Wireless Application Environment

(WAE) user agent, can be utilised via these user agents. Basically, the EFI enabler facilitates an uniform connection between the application running in a user agent, and the new functionality exposed to and usable by the user agent via the EFI. The EFI application interface is a high level interface capable of handling various applications. External functionalities are grouped in classes that offer the same type of functions across various types of mobile terminals.

8) Firmware Update Management Object v1.0

The OMA Firmware Update Management Object (FUMO) offers firmware updates for mobile terminals. The updates are managed by specifying the location in the management tree from where the update packages should be downloaded. The enabler also supports specific commands that need to be executed on specific nodes of the management tree to initiate update activities. The enabler covers all the technical aspects regarding specifications for download protocols, management tree objects model and Device Management (DM) commands.

9) OMA Games Services v1.0

OMA Games Services Enabler addresses the portability and interoperability issues in the mobile gaming space. The enabler will facilitate the development and deployment of mobile games, increasing portability across multiple gaming platforms and wireless networks.

10) OMA Games Services Client Server Interface v1.0

The gaming market is growing and the mobile gaming sector is not an exception, increasing the need for game services in the mobile industry. OMA Games Services CSI enables the interaction between the client and the gaming server in a standard manner. This enabler is the outcome of a continuous work in trying to define an industry-wide specification for developing game applications that operate over wireless communications networks. The scope of the program is to define all the protocols, messages and the necessary mechanisms to enable operators, service operators and manufacturers to face the challenge of creating advanced mobile gaming services.

11) OMA Mobile Location Enablers

Mobile Location Services constitute an essential segment in the mobile sector, and the proof of that is the ongoing subject of study for many different organizations, such as the Location

Interoperability Forum (LIF).

The LIF has consolidated into the Open Mobile Alliance (OMA) and no longer exists as an independent organization. The new OMA Location Working Group (LOC) continues the work originated in the previous Location Forum (LIF) and Location Drafting Committee of the former

WAP Forum. The change of responsibilities from one organization to another has not been in vain, since all the previous effort took by the LIF (Location Interoperability Forum) and the former Wap

Forum will be adopted by the current OMA Location Working Group, intended to converge existing specifications and add future and relevant industry initiatives as needed.

The OMA Location Working Group (WG) was created to develop specifications to ensure interoperability of Mobile Location Services on an end-to-end basis.

OMA Mobile Location Protocol v3.20

The OMA Mobile Location Protocol (MLP) is an application-level protocol that enables getting the position of mobile stations (mobile phones, wireless PDA, etc) independent of the underlying network technology and infrastructures. The OMA (MLP) enabler serves as an interface between the Location Server and a location-based application. This specification, details the core set of operations supported by the Location Server, characterizing the technical specifications between a

Location Server and a MLS client.



Figure 21 – Common Scenario

This simple scenario portraits a LCS (Location Services) client initiating the service location dialogue by sending a query to the location server and the server response to the query. A possible realization of the application-level querying protocol is the Gateway Mobile Location Centre

(GMLC), the location server defined in GSM and UMTS.

The level of success of OMA’s Location WG success is measured by:

• Wide-scale adoption of the OMA Location WG specifications in the industry.

• Timeliness in identifying and solving problems, conflicts, and challenges.

• Timeliness in integration of already existing input from organisations, as they are consolidated, to ensure an effective and speedy migration path.

• Timeliness in initiating appropriate new activities.

• Conducting interoperability testing for Location.

• Work along the work splits agreed with external organizations.

Roaming Location Protocol v1.0

The Roaming Location Protocol (RLP), also known as Inter-Location Server Mobile Location

Protocol, specifies the mechanisms for enabling the communication among different Location

Servers. In the 3GPP arena, the RLP v1.0 is an instantiation of the stage 3 specification for the Lr reference point [23.271].

The picture below describes the general arrangement for a typical scenario where both applicationto-LocationServer and LocationServer-to-LocationServer communication occurs, for 3GPP type networks.

Figure 22 – Larger Scenario

OMA Mobile Location Service (MLS) v1.0

The OMA Mobile Location Service v1.0 (MLS) consists of a set of location specifications compliant with the 3GPP Release 6 LCS Specification [33].

The primarily used indented for MLS 1.0 was the 3GPP environment, but the specification has in several cases been extended to facilitate the use for different environments.



The Mobile Location Service v1.0 specifications consist of two major protocols:

• Mobile Location Protocol (MLP) v3.2 describes the protocol between an MLS client and a Location Server

• Roaming Location Protocol (RLP) v1.0 describes the protocol between two Location

Servers

Le - Interface between Location Server and LCS Client in 3GPP mobile networks

Lg - Interface between Location Server and Core Network in 3GPP mobile networks

Lr - Interface between Location Servers

Figure 23 – Architectural diagram of MLS, its components and interfaces

12) On-Board Key Generation v1.0

The On-Board Key Generation Enabler was defined to provide the generation and registration of keys into a Public Key Infrastructure (PKI). This enabler depends on the candidate version (v1.1) of the Wireless Application Protocol Public Key Infrastructure (WPKI) definition.

OB Key Generation aims to introduce on-board key generation and remote key enrolment functionality by defining additional ECMA (European Computer Manufacturer Association) scripts and functions in the WIM (Wireless Identity Module). These functionalities will allow on a first stage, a remote invocation of on-board key generation in the WIM and second, remote key enrolment for getting (new) user certificates. Both functions are implemented as ECMA scripts that are embedded in an xHTML page.

Figure 24 – on-board key generation and registration process

13) OMA Online Certificate Status Protocol Mobile Profile v1.0

Online Certificate Status Protocol (OCSP) defines a protocol used to determine the current status of a digital certificate as an alternative of using standard Certificate Revocation Lists (CRL’s). OCSP is intended to replace the CRL concept, with a simple certificate status request and response protocol to a central server (also known as OCSP responder). Although CRL’s are in use in many environments, they have some properties that make their use in mobile environments unattractive.

In particular, the use of CRL’s demands additional processing by the client that may be difficult to achieve in a resource limited mobile device. In addition, CRL’s are often quite large in size and thus raise network latency and bandwidth issues.

14) OMA Push v2.1

The Push enabler release defines the application level protocols, syntax and behaviours of client and server for the fulfilment of push services. The Push service is defined as a communication of content toward a client without an explicit request.

A push operation in OMA is accomplished by allowing a Push Initiator (PI) to transmit push content and delivery instructions to a Push Proxy Gateway (PPG), which then, forwards the push content to the WAP client according to the delivery instructions.



Typically, the PI is an application that executes on an ordinary web server and communicates with the PPG using the Push Access Protocol (PAP). The PPG uses the Push Over-The-Air (OTA)

Protocol to deliver the push content to the client. The protocol framework depends on the protocol stack defined in the Browsing Protocol Stack Enabler.

Figure 25 –The Push Framework

15) OMA Secure User Plane for Location (SUPL) v1.0

Location services based on the location of mobiles devices are becoming increasingly widespread.

Secure User Plane Location (SUPL) employs User Plane data bearers for transferring location information (e.g. GPS assistance), and for carrying position technology-related protocols.

SUPL v1.0 describes the protocol (ULP) between a SUPL Enabled Terminal (SET) and a SUPL

Location Platform (SLP); it’s considered to be an effective mechanism for transferring location information required for serving the SET’s location queries. The underlying protocol used in the

SUPL specification is the UserPlane Location Protocol (ULP), a protocol-level instantiation of the

3GPP equivalent Lup interface.

The SUPL enabler makes use of existing standards whenever possible, but it should be extensible for enabling more positioning technologies as the need arises, allowing the use of the same mechanisms. In the initial phase, SUPL will provide full functionality of Assisted-GPS with minimum changes of current network elements.

Figure 26 –UserPlane Location Protocol (ULP)

The SUPL enabler implies the use of the RLP v1.0, a protocol specification from the OMA MLS

Enabler. RLP is used such that SLP’s from different SUPL providers can exchange information for positioning of roaming subscribers.

16) OMA Standard Transcoding Interface v1.0

The OMA Standard Transcoding Interface (STI) provides a standardized interface between

Multimedia Application Platforms and a Transcoding Platform. The enabler allows the transcoding of media Content files based on the parameter specified by the Application and/or User Equipment capabilities.

STI v1.0 is meant to resolve some of the integration and testing problems when deploying multimedia services towards mobile devices.

17) OMA vObject Minimum Interoperability Profile v1.0

The vObject enabler defines vObject (vCard, vCalendar, vBookmark) minimum interoperability profile and implementation guideline to guarantee consistent and explicit interpretation of the relevant base specifications vCard2.1, vCalendar1.0 and vBookmark1.0.



This specification provides interoperability across different terminals, platforms and user agents for the mobile community. OMA vObject MI Profile is intended to addresses several interoperability issues, such as: vObject physical data formatting and standard schema presentation for data properties.

The vObject minimum interoperability profile is to be used in following use cases:

• vObject exchange between mobile terminals (peer-to-peer) via local interface e.g.

Bluetooth, infrared

• vObject attached to an email or a MMS message

• vObject downloading from a web server

18) OMA Wireless Public Key Infrastructure v1.0

The Wireless Public Key Infrastructure (WPKI) v1.0 allows the establishment of public key security features between clients and servers. Authentication, confidentiality, integrity of exchanged messages and some other security operations are supported by the WPKI enabler.

Security features can be established either in the transport layer, in the application layer, or both. It is also feasible for clients to authenticate themselves into servers using strong public key authentication methods.

A.2 Approved Enabler Releases

1) OMA Data Synchronization v1.2

The OMA Synchronization Enabler v1.2 is a fully compliant client and server data synchronization. Full compliance can only be achieved combining this release with the SyncML

Common Specifications enabler.

The Data Synchronization release defines and promotes a set of universal specifications for symmetric data synchronization over networks and devices. Data can be synchronized between:

• Synchronize networked with any mobile device

• Mobile device with any networked data

The data synchronization protocol would synchronize networked data with many different devices, including handheld computers, mobile phones, automotive computers, and desktop PCs.

A simple scenario is where a user could access and manipulate the same set of data from different devices, i.e., a user could read e-mail from either a handheld or a mobile phone, and still maintain a consistent, updated record of which messages had been read.

2) OMA Device Management v1.1.2

OMA SyncML Common v1.1.2 specifications must be used in conjunction with the OMA Device

Management (DM) Enabler Release (based on SyncML DM), version 1.1.2. for a fully conformant

DM client and DM server implementations.

This enabler defines the technology that allows third parties, typically wireless operators, service providers, etc, to manage and configure mobile devices on behalf of the end user (customer). The

Device Management enabler provides to external parties the means to remotely configure parameters, conduct troubleshooting servicing of terminal, install or upgrade software, and some others. Shortening, device management consists of three parts:

• Protocol and mechanism: The protocol used between a management server and a mobile device

• Data model: The data made available for remote manipulation, for example browser and mail settings

• Policy: The policy decides who can manipulate a particular parameter, or update a particular object in the device



In wireless environments, the vital element for device management protocol is the need to efficiently and effectively address the characteristics of mobile devices including low bandwidth and high latency.

3) OMA Digital Rights Management v2.0

OMA “Digital Rights Management” (DRM) enables the distribution and consumption of digital content in a controlled manner. The content is distributed and consumed on authenticated devices per the usage rights expressed by the content owners. OMA DRM’s effort is to address the various technical aspects of this system by providing appropriate specifications for content formats, protocols, and a rights expression language.

4) OMA Domain Name System v1.0

It is more likely for humans to use names rather than using IP addresses to identify network interfaces. In the TCP/IP world, the Domain Name System (DNS) is the way that Internet domain names are located and translated into IP addresses.

DNS provides the protocol that allows client and server communication. From an application’s perspective, the access to the DNS server is through a resolver - a client of the DNS which seeks information contained in a zone using the DNS protocols.

OMA DNS v1.0 is intended to support IP address resolution within the direct access scenario, as specified in the WAP Architecture specification. From architecture’s point of view, this specification covers the terminal side definition, and not how the DNS server interacts with the

DNS client, therefore Wireless Profiled DNS (W-DNS) clients will be capable of performing DNS lookups with the existing DNS servers.

5) OMA Download over the Air v1.0

The principle behind OMA Download enabler is to provide a service similar to the java based

MIDlet Download. The major difference involving these solutions, MIDlet Download and OMA

Download, is that OMA Download is not designed with intent for the downloading of Java™

MIDlets, or any other specific media type - OMA Download is a general download framework that extends the Basic HTTP Download with two additional steps:

1. Before download , a description of the media object is downloaded. The description is a small file, the download descriptor, containing metadata about the media object and instructions to the download agent in the device, how to download the media object. The media object is downloaded using standard Basic HTTP Download.

2. After download , a status report is posted into a Web site, indicating the outcome of the download. The user can be directed to a Web location provided in the download descriptor .

6) OMA Instant Messaging and Presence Service v1.2.1

The OMA IMPS release provides a set of definitions and specifications for the mobile instant messaging and presence services. The set of specifications are intended to be used for the exchange of messages and presence information between mobile devices, mobile services and Internet-based instant messaging services.

The Wireless Village System Architecture is a client/server-based system, where the server is the

IMPS server and the clients can be mobile terminals/devices, fixed PC clients or other services and applications. The IMPS servers and gateways are connected via a server-to-server protocol (SPP).

The architecture is consistent with 3GPP TS 22.121 Virtual Home Environment and 3GPP TS

23.127 Open Service Architecture.

The Wireless Village Server is the central point in a Wireless Village system. It is composed of four Application Service Elements that are accessible via the Service Access Point. The

Application Service Elements are:

• Presence Service Element

• Instant Messaging Service Element


page 64 (80)

• Group Service Element

• Content Service Element


Figure 27 – Functional Elements of Wireless Village Server

Presence Service Element

The Presence Service Element provides functionality for presence information management, including update, retrieve, set and store presence and location information. The presence information can be manipulated by the user or implicitly by the system. Users are explicitly allowed to subscribe to receive presence information of other users, manage their contact list, among others.

Instant Messaging Service Element

The Instant Messaging Service Element provides functionality for sending and receiving instant messages. An instant message may be sent to, or received from a specific WV-user, or users of other instant messaging systems. It is also possible to send instant messages to a group of WVusers.

Group Service Element

The Group Service Element provides functionality for the use and management of groups. The groups can be private or public. A common usage of the Group Service is a chat room.

Content Service Element

The Content Service Element provides functionality for sharing content such as images and documents between Wireless Village users. The shared content feature allows the IMPS users to share content while sending messages or chatting in a group.

7) IMS in OMA v1.0

The IMSinOMA Enabler specifies how OMA enablers use IMS in an interoperable manner. The IP

Multimedia Subsystem (IMS) is a Session Initiation Protocol (SIP) based IP multimedia infrastructure, that provides a complete architecture and framework for enabling multimedia services, guaranteeing this way, a platform for globally interoperable IP multimedia services - mainly in the mobile environment.

This enabler provides the means on how OMA enablers use the IMS as specified by 3GPP/3GPP2, that is, it indicates how IMS is related to the OMA Service Environment (OSE) and how IMS fits into the OSE context and how OMA enablers shall interface with IMS.

It is important to clarify that is not imperative that OMA enablers are required to use IMS; however, for those enablers that do so, the IMSinOMA specifications provide normative guidance.

8) OMA Multimedia Messaging Service v1.2

Multimedia Messaging Service (MMS) is a system application that enables messaging operations with a variety of media types. It is intended to provide a rich set of content to subscribers in a messaging environment, supporting both sending and receiving of such messages by properly enabled client devices.



It is possible to describe this service considering the actions taken by the MMS Client and its service partner, the MMS Proxy-Relay, a device which operates as an Origin Server for this specialized service.

Figure 28 – MMS Network Representation

The main service goal is to provide non-real-time messaging services to consumers using WAP technologies. It is an application level service that fits into the current WAP architecture.

Additional service aspects are supported by the MMS Server as well as other messaging servers, such as an email server and wireless messaging.

This specification defines application-level protocol activities that take place to realise the MMS service within the OMA environment.

9) OMA Presence Simple v1.0

The OMA Presence SIMPLE Enabler is a service that manages the collection and controlled distribution of presence information over mobile networks.

The IETF has already defined protocols and formats for presence in its SIMPLE (SIP Instant

Messaging and Presence Leveraging Extentions) activity (see [RFC3856]). The work of OMA and others is to leverage these standards into an interoperable Presence Simple enabler.

3GPP and 3GPP2 have defined an aligned Presence Service framework based on the IETF standards, but additionally, there are presence services that exist or can envisaged that do not leverage core network infrastructure as define by 3GPP and 3GPP2. However, those presence services are still relevant to the mobile domain and thus supported by this architecture.

OMA’s role is to remove the number of degrees of freedom left open by 3GPP and 3GPP2 for

Presence Service. These specifications shall be agnostic to the underlying network technology, specified by 3GPP, 3GPP2, or by somebody else.

Figure 29 – Presence Specification Layers

The Presence Enabler provides a variety of services that can be invoked from other Enablers.



Those Enablers can assume one or both of the following roles:

• Presence Source : publishes presence information to the Presence Enabler, i.e., supplies with the presence information.

• Watcher : subscribes to retrieve presence information from the Presence Enabler, and receives the information when changes happen.

This enabler makes use of the implementations of the SIP protocol in the 3GPP IMS (IP

Multimedia Subsystem) and 3GPP2 MMD (Multimedia Domain) for saving and transmitting presence information between the various Presence Sources and their watchers.

10) OMA Push to talk Over Cellular v1.0

The Push To Talk over Cellular (PoC) service is a two-way form of communication that allows users to engage in an immediate communication with one or more users.

Figure 30 – Example of a PoC 1-to-many Group Session (voice transmission)

The PoC service is similar to the familiar “walkie-talkie” application in the way that by pressing a button a talk session with an individual user or a broadcast to a group of participants is initiated. In addition, the PoC service provides 2 models for PoC Session establishment: the Pre-established

Session mode and the On-demand Session mode. The communication is half-duplex, meaning that one person can talk at a time and all other participants hear the speech. The permission for talk right granting is controlled via the floor control mechanism. The PoC service enabler supports the;

• PoC Session which is the basic capability to set up voice communication between two users

• 1-to-many PoC Session which is the capability to enable the setup of a voice communication with a multiple number of other PoC subscribers in an ad-hoc or predefined group manner

• Instant Personal Alert which is the capability to inform about the calling user’s wish to communicate and the request the invited user to “call-back”

11) OMA SyncML Common Specification v1.1.2

The OMA SyncML Common Specification provides support for both OMA Data Synchronization

(DS) and OMA Device Management (DM).

The SyncML solves the problem of having a variety of non-interoperable data synchronization products and the lack of a common data synchronization protocol that is impeding the growth in use of mobile devices, restricting users' ability to access data, and limiting the delivery of mobile data services.

The Open Mobile Alliance SyncML Common v1.1.2 specifications are based on the SyncML

Initiative’s v1.1.1 specifications.



12) OMA User Agent Profile v2.0

The User Agent Profile (UAProf) specification extends WAP 2.0 to enable the end-to-end flow of a

User Agent Profile (UAProf), also referred to as Capability and Preference Information (CPI), between the WAP client, the intermediate network points (proxies and gateways), and the origin server.

Figure 31 – UAProf end-to-end architecture

It interoperates with the emerging standard for Composite Capability/Preference Profile (CC/PP).

UAprof uses the CC/PP model to define a robust, extensible framework for describing and transmitting CPI about the client, user and network.

OMA’s User Agent Profile specification is concerned with capturing classes of device capabilities and preference information. These classes include (but are not restricted to) the hardware and software characteristics of the device as well as information about the network to which the device is connected. The user agent profile contains information used for content formatting purposes. A user agent profile is distinct from a user preference profile that would contain application-specific information about the user for content selection purposes.

13) OMA Web Services v1.1

The OMA Web Services Enabler defines the means by which OMA applications can be exposed, discovered and consumed using Web Services technologies. The purpose of the OWSER is to provide Web Services designers within OMA, solutions to common functionality using Web

Services technologies. Without such a framework, designers of Web Services within OMA would almost certainly try to solve these problems on their own, each in their own way. Such an effort would inevitably lead to fragile implementations, interoperability problems and increased time to market.

The primary goals of the OMA Mobile Web Services (MWS) effort are:

• Provide specifications and guidelines for Web Services (WS) technologies, implementations and deployments to integrate and interoperate within the OMA architecture.

• Ensure interoperability across servers and terminals supporting web services protocols through the use of standardized protocols. As a result of such protocol standardization, one can expect diverse enablers and Internet services to interoperate "on the wire".

14) OMA Web Services Network Identity v1.0

OMA Web Services Network Identity enabler describes the logical entities and interfaces needed to support the discovery and use of Web Services for accessing end-user related attributes in a privacy-protected manner. Attributes are data about or related to an end user, such as, personal information, preferences, capabilities, etc. It is expected that such information about an individual


page 68 (80) Eurescom project report will be distributed amongst different parties (called attribute providers), such as an individual’s bank, employer, personal devices, mobile operator etc.

This enabler provides an overview of the architecture and interfaces necessary to support the requirements related to privacy protected attribute sharing, which is based on the Liberty Alliance

Identity Web Services Framework, as well as additional identity-federation features (e.g., affiliations, chain of authentications) of Liberty Alliance.

15) XDM - OMA XML Document Management v1.0

The XML Document Management defines a common mechanism that allows other service enablers

(e.g., PoC, IM) the access to the user-specific service-related data. Such information should be store in the network and management operations, such as location, access and manipulation, should be supported (create, change, delete).

XDM specifies how such information will be defined in well-structured XML documents, as well as the protocol adopted for managing such XML documents, the XML Configuration Access

Protocol (XCAP) defined by IETF.

The XDM Specification defines two main features:

• The use of XML Configuration Access Protocol (XCAP) for storing and manipulating the service-related data, stored in a network as XML documents.

• The SIP subscription/notification mechanism for notification when changes occur in the

XML documents.



Annex B SDP vendor's point of view

The SDP market is reaching a critical phase; many players are emerging into the market with SDP solutions ready for deployment and many others are already up and running. The marketplace is growing, as more and more talented solutions are rising. The selection is diverse with some solutions better than the others, there are newcomers in the market, some are well established and others are gaining the market’s approval. This section will present some of the most important players in the SDP arena.

There are basically two types of players – the framework providers and the point-solution providers:

• Framework providers are suppliers that have defined complete SDP architectural models and are investing in realizations of those same models. The frameworks can be collections of entirely owned solutions or can be a mix of owned and third-party solutions.

• Point-solution providers are vendors that are implementing a specific SDP component and not a complete SDP architecture. Point-solution vendors often collaborate with one another, contributing to a niche of capabilities in a full-fledged SDP.

Framework providers are gaining the market’s attention, specially the ones with intelligible and clear views of the service delivery platform. SDP providers are bringing the creation, execution and management domain to the business level, so that operators can easily understand the real business value of service platforms.

The SDP market is moving fast, the pursue for new and innovative services is rapidly influencing the market to a new dimension. There are a significant number of players in the SDP playground, but it is still too soon to declare an absolute winner. There is no overall clear winner in the SDP market, so there are still plenty of opportunities for suppliers.

B.1 Oracle

Oracle corporation is one of the major companies developing database management systems, middle-tier software (Fusion Middleware), enterprise resource planning (ERP), customer relationship management (CRM), among other technologies.

Rapid deployment of Telco Services using Open Standards is the new concept for the Oracle communications technology. Oracle Service Delivery Platform (SDP) brings together the flexibility and maturity of Oracle Fusion Middleware and Oracle Database, with strong telecommunication functionality, enabling Telco Operators to quickly and efficiently deploy new data, voice, and multi-media services. In the Enterprise and ISV community, Oracle SDP provides the ideal platform to build new and exciting real-time, media-rich and voice-enabled applications.

The main benefits are:

• Standards-Based SDP

• Rapid Return Of Investment

• A Complete IMS Solution

• A Complete BSS-SDP

• Telco Performance

• A Complete and Proven SOA


page 70 (80)

B.2 IBM


International Business Machines (IBM) is one of the biggest and oldest multinational computer technology corporation today. It is one of the few information technology companies with a continuous history dating back to the 19 th

century.

IBM’s Telecommunications Solutions Group is part of IBM Global Services, with special focuses in BSS/OSS, IP networks, CRM and Service Delivery Platforms. IBM Service Provider Delivery

Environment (SPDE) existence began as an effort of trying to leverage middleware and hardware relations in the Telco industry. The initial objectives were to design an SDP architecture that could:

• Support the industry standards

• Abstracting the execution environment form the network infrastructure

• Easy service development

• Open standards service creation

The first reference architecture was launched in 2002, using web services standards.

Today, IBM’s SDP brings services to market with minimal cost and risk. The SPDE gives wireless and wire-line telecommunications service providers, the flexibility to introduce new services in weeks or even days, enabling to gain and maintain a strong marketplace position, despite the changing market conditions.

The main benefits are:

• Invest in the future by bringing next-generation services, technology, product innovations and service enhancements to your organization.

• Rapidly access revenue-generating services created by third parties.

• Attract new customers and increase loyalty of existing customers.

• Build a new organization or jump-start an existing one – with minimal cost or risk to your business.

• Win a competitive edge through the enhanced ability to quickly introduce new services.

• Gain access to multimedia content - whether text, audio or video.

B.3 BEA

BEA Systems, Inc. (NASDAQ: BEAS) was found in 1995 and is now a world leader in enterprise infrastructure software, delivering unified SOA platforms for business transformation and optimization. BEA provides BEA Tuxedo®, WebLogic®, and AquaLogic™ product lines to help reduce IT complexity and leverage existing resources.

As the convergence of communications and IT is happening and these two critical functions merge, BEA provide the market with WebLogic Communications Platform (WLCP) which is their first converged IT and telecom platform, providing full-service lifecycle capabilities in a carrierclass environment (see Figure 32).



Figure 32 – BEA WebLogic Communication Platform (WLCP)

There are 2 major components included in WLCP. One is BEA WebLogic SIP Server which is a high-performance J2EE-SIP application server which provides an integrated SIP, HTTP, EJB container to enable rapid development and delivery of next-generation, converged, multimedia communication services. The other is BEA WebLogic Network Gatekeeper which provides a carrier-grade, industry standards-based platform for automated partner management, flexible billing management, policy-based network protection, and application access control. This platform is based on IT and telecom industry standards, and protects and manages access to network resources. Operators can leverage its dynamic traffic throttling, policy-based application access control, and strong network protection to enhance performance of application and partner platforms, improve network stability and capacity.

As the business agility is thought to be dependant on free flow of information, services and business processes across the organization, BEA considers that SOA concept is necessary as an architectural approach that enables the creation of loosely coupled, interoperable business services that can be easily shared within and between enterprises even if they are using heterogeneous nature of the typical large enterprise’s IP environment such as IBM, BEA, Microsoft, SAP, and

Oracle. An SOA takes the discrete business functions contained in enterprise applications and organizes them into interoperable, standards-based services that can quickly be combined and reused in composite applications and processes.

BEA AquaLogic is their first family of service infrastructure products built from the ground up to manage SOAs. This new service-infrastructure software adheres to the SOA principles of coarsegrained, loosely coupled, and standards-based services that isolate the complexities of underlying technologies, creating a "neutral container" in which business functions may thrive regardless of underlying infrastructure. One of the key products of BEA AquaLogic family is BEA AquaLogic

Service Bus. It seamlessly delivers the intelligent, high-performance integration and mediation capabilities of an enterprise-class service bus with operational service management and support for service life-cycle governance in a single, unified software product. It has functions for message brokering, dynamic routing, and transformation in support of heterogeneous service end points.

These functions are integrated with service life-cycle management and governance capabilities such as service registration and discovery, a configuration framework with built-in service validation and resource-referential integrity, service and system monitoring, reporting, and threshold-defined service level agreement (SLA) and runtime policy enforcement.

BEA expresses the SOA’s nature is applicable for Operators’ NGN, for IMS which is standard network architecture for most of the operators has aligned strongly with IT technologies and architectures: APIs, web services, web applications, IP services etc and using IMS under SOA environment would allow high productivity, low-cost and efficient realization of new communication services, strong reuse of components and capabilities, and in particular, would make external partnering easier.

B.4 Microsoft

The Microsoft Corporation is a multinational computer technology corporation, with astonishing global annual sales and approximately 71 thousand employees all around the world. Microsoft,


page 72 (80) Eurescom project report known as one of the leading drivers of the digital revolution is embracing a new concept in service development and delivery. Existing on top of traditional network control layers, there is a new software powered Service Network layer, which links into existing legacy OSS (Operational

Support Systems) and BSS (Business Support Systems) infrastructure.

Strategy

However, it is not enough to simply add an IP Service Network. To bring some value, Microsoft has brought together its expertise in developing software for voice, data and video solutions into a new delivery and control platform, based on Web services architecture.

The Connected Services Framework (CSF), is an integrated software platform, compliant with

Service Oriented Architectures (SOA), and Web service interfaces, providing the tools to build and manage new applications. In an SOA environment, applications are broken down into processes and functions called services, which are able to communicate with each other, over the open standard Web services interface. Developers can therefore use standard Web services technologies, to create complex composite services, which operators can deliver to any end-user device including televisions, telephones, computers or game consoles.

Until now, most Web services have not been well behaved as distinct and separate applications.

However, Web service technologies are rapidly maturing into the open standards, being capable of connecting applications within and across IP domains, becoming the building blocks for the composite Web applications of tomorrow.

B.5 OpenCloud

OpenCloud develops and inserts innovation software in the telecommunications industry. Together with Sun Microsystems, OpenCloud is the leader in the international specification standard JAIN

SLEE. They developed a SLEE (Service Logic Execution Environment) compliant platform, called

Rhino, which enables operators and service providers to execute new service deployment strategies rapidly, with lower costs and independently from current and future underlying networks, providing an evolutionary path for the delivery of revenue generating services.

Rhino offers a platform where service developers are focused on building business logic rather than implementing complex low-level infrastructure. This approach results in:

• Simpler & less service code;

• More reliable services;

• Reduced costs (Development & maintenance).

Core Platform

The Rhino core platform is a flexible technology that is leveraged in the implementation of the broad Rhino product suite (e.g., Rhino IMS Application Server, IMS SCIM and others). It allows rapid integration with external systems and protocol stacks and is optimised to meet the most demanding performance and fault tolerant today’s requirements.



Figure 33 – Elements of the Rhino Core Platform

• Service Creation - "A network on your laptop" is achieved by taking a federated services development approach

• JAIN SLEE Container - Provides the component and programming model for the platform

• Carrier Grade - Delivers a fault-tolerant infrastructure that provides continuous availability, service logic execution and on-line management even during network outages, hardware failure, software failure and maintenance operations

• Resource Integration - An architecture that provides for multiple network and enterprise technologies to be "plugged into" the platform

• Management Interfaces - Easily integrates the platform into an operators OSS environment

B.6 Mobicents

Mobicents is a highly scalable event-driven application server with a robust component model and fault tolerant execution environment. It’s a project that includes individual contributors, with permission from the following organizations such as Portugal Telecom Inovação, Telecom Italia,

University of Genova, Vodafone R&D, T-Mobile, Lucent Technologies, Open Cloud, Aepona,

NEC Japan, JBoss, Inc. and others.

Mobicents is the first and only Open Source VoIP Platform certified for JSLEE 1.0 compliance.

Mobicents brings to telecom applications a robust component model and execution environment. It compliments J2EE to enable convergence of voice, video and data in next generation intelligent applications.

In the scope of telecom Next Generation Intelligent Networks (NGIN), Mobicents fits in as a highperformance core engine for Service Delivery Platforms (SDP) and IP Multimedia SubSystems

(IMS).

Mobicents enables the composition of Service Building Blocks (SBB) such as call control, billing, user provisioning, administration, and presence sensitive features. The JAIN SLEE specification allows popular protocol stacks such as SIP to be plugged in as resource adapters. The SLEE service building blocks - SBBs have many similarities to EJBs. The extensible standard architecture naturally accommodates integration points with enterprise applications such as Web, CRM or SOA end points.

Monitoring and management of Mobicents components comes out of the box via SLEE standard based JMX and SNMP interfaces. This makes the Mobicent server an easy choice for telecom

Operations Support Systems (OSS) and Network Management Systems (NMS).



Mobicents is applicable to a wider variety of problems demanding high volume, low latency signalling. Examples include financial trading, online gaming, sensor network integration (RFID) and distributed control.

Figure 34 – Mobicents



Annex C Software operators SDP

page 75 (80)

C.1 Google

C.1.1 Introduction to Google Talk

Google Talk is a peer-to-peer VOIP and electronic communications application based on open standards. The Google Talk application uses the standard XMPP Protocol for authentication, presence, and messaging. The eXtensible Messaging and Presence Protocol (XMPP) [7] is an open

XML technology for real-time communications, underpinning other communications and collaborations applications such as instant messaging, presence, media negotiation, white-boarding, collaboration, lightweight middleware, content syndication, and generalized XML delivery. Taking a moment to examine the name XMPP we see it’s Extensible (many extensions do exist) and it also provides Messaging and Presence. XMPP’s beginnings date back to the Jabber community, when in January 1999 Jeremie Miller announced the existence of Jabber, an open technology for instant messaging and presence. In August of the same year Jeremie pledged support for the IETF [7] process and by October 2004 the core RFC’s 3920-3923 of XMPP were published. Compared to competing applications like: AIM Triton, Windows Live or MSN Messenger, Yahoo Messenger,

ICQ, and Skype the Google Talk application is bare-bones in terms of features but similarly it’s a much smaller download, consumes less memory and appeals to minimalists.

Technology

As specified in RFC 3920, the core "transport" layer for XMPP is an XML streaming protocol that makes it possible to exchange fragments of XML between any two network endpoints.

Authentication and channel encryption happen at the XML streaming layer using the IETFstandard protocols for SASL (Simple Authentication and Security Layer) (RFC 2222) and TLS

(Transport Layer Security) (RFC 2246). Google Talk [7] supports XMPP with the beta release.

Support for SIP is planned (including SIP signalling). It’s worth noting that Google has stated commitment to open communications. Google Talk uses extensions to XMPP (known as XEPs) for voice signaling and peer-to-peer communication. Source code and documentation for these extensions is available. These extensions are in the process of being reviewed by the XMPP standards body as official enhancements to the standard. Note that the source code for Google

Talk's current implementation of these extensions varies slightly from the proposed specs. Upon ratification of the specs, Google Talk (and the source code) will be updated to be in full compliance.

Standards voice Codec’s currently supported: PCMA, PCMU, G.723, iLBC, and Speex.

The following codecs from Global IP Sound are also supported: ISAC, IPCMWB, EG711U,

EG711A.

Currently the Google Talk client is only available on Windows but Linux and MacOS clients are planned. Third party tools can be used to connect to the service using other OS’s. Like making a long distance call or sending an email you don’t want to have to worry about the particulars of the foreign PSTN or ISP, similarly Google Talk network supports open interoperability with hundreds of other communications service providers through a process known as federation. Currently this list includes Earthlink, Gizmo Project, Tiscali, Netease, Chikka, MediaRing, and thousands of other

ISPs, universities, corporations and individual users. Service providers need to support the XMPP standard for server-to-server federation. Google publishes API’s and toolkits for developers, an example, is Libjingle [7]. Libjingle is a set of C++ components provided by Google to interoperate with Google Talk's peer-to-peer and voice calling capabilities. The package includes source code for Google's implementation of Jingle and Jingle-Audio, two proposed extensions to the XMPP standard that are currently available in experimental draft form.

The Libjingle library aims to create high quality peer-to-peer sessions over a wide number of network configurations, including firewalls and Network Address Translation (NAT). NAT devices, increasingly popular in homes and offices, allow multiple machines to share a single



Internet address. Consequently, it becomes more and more difficult for applications such as voice chat, which require peers to directly address each other, to make a peer-to-peer connection reliably.

Google Talk uses a proposed extension to XMPP known as Jingle which can traverse many types of NATs, to establish peer-to-peer connections.

C.2 Skype

C.2.1 Introduction

Skype is a proprietary peer-to-peer Internet telephony (VoIP) network founded by Niklas

Zennström and Janus Friis, also founders of the very well known file sharing application Kazaa.

With headquartered in Luxembourg, offices in London and Tallinn, skype has experienced rapid growth in both popular usage and software development since launch, both of its free and its paid services. In October 2005, Skype Group was acquired by eBay, an online auction and shopping website $2.6 billion in up-front cash and eBay stock, plus potential performance-based consideration.

The Skype VoIP protocol competes against open VoIP protocols such as SIP, IAX and H323. The

Skype communications system is notable for its broad range of features, including free voice and video conferencing, and its ability to use peer to peer (decentralized) technology to overcome common firewall and NAT problems.

Skype is criticized for being incompatible with internet telephony standards, for using significant amounts of bandwidth even when users are not talking (via supernodes ), for the use of a largely closed design for the encryption of network traffic, and for the use of closed source software in general.

C.2.2 Technology

The use of Skype is essentially for telephone and video calls, through Skype software available for various platforms like Windows, Mac, Linux and mobile devices. The primary use of the skype system is the free communication between Skype users; however the product also allows communications to PSTN and mobile networks. This software is currently available free of charge and can be downloaded from the company website, but the software is proprietary and the Skype protocol is unpublished.

The main distinction between Skype and other VoIP clients is that Skype operates on a peer-to-peer form, rather than the more conventional server-client model. The Skype user directory is entirely decentralised and distributed among the nodes in the network, which means the network can scale very easily to large sizes (currently just over 100 million users) without a complex and costly centralised infrastructure.

Skype also routes calls through other Skype peers on the network to ease the traversal of

Symmetric NATs and firewalls . This, however, puts an extra burden on those who connect to the

Internet without NAT, as their computers and network bandwidth may be used to route the calls of other users. The selection of intermediary computers is fully automatic, with individual users having no option to disable such use of their resources.

The Skype code is closed source , and the protocol is not standardized but proprietary ; this has raised suspicion and drawn some criticism from third parties.

The Skype client's application programming interface (API) opens the network to software developers. The Skype API allows other programs to use the Skype network to get "white pages" information and manage calls.

The Windows user interface was developed in Pascal using Delphi , the Linux version is written in

C++ with Qt , and the Mac OS X version is written in Objective-C with Cocoa .

[1] Parts of the client use Internet Direct (Indy) , an open source socket communication library.



C.2.3 Business Offering page 77 (80)

Skype has a remarkable pathway of success. Started as a simple internet telephony solution with a peer to peer (decentralized) architecture, overcoming NAT and firewall problems has always been the favourite choice when comes to VoIP clients. Fifty-four million people are registered to use

Skype’s free services, with over 3 million simultaneous users on the network at any one time.

Apart the traditional VoIP client that allows the users to make free calls to other Skype users,

Skype has several value-added services that extend and enhance the platform. These agile extended features turn Skype into a very powerful and flexible data and voice communications service platform.

• SkypeOut – calling ordinary phones cheaply

SkypeOut is a great feature that allows calling landlines and mobiles directly from Skype with good quality and call rate

• SkypeIn – your personal number

SkypeIn is a functionality that allows the Skype user to acquire a personal number that can be used to receive calls from landline and mobile phones on Skype. It is a costeffective and easy way to receive calls from family and friends at local rates independently of the geographical location

• Skype Voicemail – never miss a call again

Skype Voicemail is a voicemail service that allows the Skype user to not miss a call when busy, not available or even offline

• Skype SMS – send text message the cheap way

Skype SMS is a messaging service that allows Skype users to quickly and cheaply send text messages to other Skype users

• Skype Call forwarding – answer your Skype calls on the move

Skype Call forwarding service allows the user to redirect calls. The Skype user can still receive the call even if it’s not currently online on does not have internet access

The previous paragraph points out several out of the box Skype services that extend and bring value to Skype, however, in today’s telecommunication world that is not enough. The competition is hard and constant. Service providers cannot just sit back and enjoy the profits.

The latest Skype’s business approach is to allow third party users or providers, to use the Skype network in order to develop new value-added services. Somehow, Skype has “opened” their network to third party users, so they can architect, create and deploy new services using Skype’s infrastructure.

A developer zone named “Skype Developer Zone” already exists to foment and support the entire community to create new and valuable services. Developers can share ideas, code, documentation and can get all the APIs and SDK support needed to create their applications. The following section describes the most important Skype APIs available for third party developers. Some were developed by Skype and other by the community.

C.2.4 3 rd

Party Service Development (APIs)

Skype APIs allows external developers to create applications that interact with Skype. The APIs are free to use with commercial and non-commercial applications. The APIs are available for

Windows, Max OS X and Linux operating systems.

The Skype API offers the possibility of using Skype’s network for the development of new services. Skype is now an open platform capable of integrating new extended services like voice, messaging, collaboration, business among others. The goal is to create around Skype network, an innovative developer community that integrates the Skype application to extend the potential of


page 78 (80) Eurescom project report global communications. Non-commercial developer communities are free to integrate this new business approach in compliance with the Skype software End User License Agreement (EULA).

The Skype APIs

The Skype API is based on messages, by passing simple text messages between the Skype and client applications or devices. Client applications can be applications extending Skype functionality and devices include hardware or software devices, such as USB phones.

The Skype API is divided into two main components; the Skype Phone API and the Skype Access

API.

The protocol used for communication is the Skype Protocol, a proprietary protocol that is periodically reviewed to enable new communications features. The communication between Skype and any other application or device is always assured, as Skype always uses the correct protocol version to match the one reported by the other end.

Skype Phone API

The Skype phone API provides an interface capable of connecting devices such as USB phones.

The Skype client controls the API and triggers events on the device or applications.

The Skype phone API uses the following commands to communicate with Skype, substituting values and setting indicators as appropriate:

• NAME deviceName

• PROTOCOL version

• AUDIO_IN deviceName

• AUDIO_OUT deviceName

• HOOK ON|OFF

• MUTE ON|OFF

• BTN_PRESSED (0-9,A-Z,#,*,+,UP,DOWN,YES,NO,SKYPE)

• BTN_RELEASED ...

The Skype phone API uses the MUTE ON|OFF command to control the mute function on a device.

Skype Access API

The Skype access API enables access from external applications to control certain Skype functions.

As an example, a third-party application can place a call or get a Skype user profile. Regarding privacy and security, Skype asks the user for permission before an external application can take control.

During the request for control, Skype switches all audio devices to the devices reported by the controlling client.

The Skype access API main characteristics:

• All actions performed using the API are mirrored on the Skype client.

• Multiple applications can use the Skype access API at the same time.

• All times and dates in the API are in UTC (Coordinated Universal Time)

• Transmission over the API is in UTF-8 encoding.

Skype4COM

Skype4COM is an interface that represents the Skype API as objects, with properties, commands, events and notifications. The Skype4COM is an object oriented language that extends the use of the

Skype API to other domains. Skype4COM can be used in any ActiveX environment, such as

Visual Studio or Delphi, and familiar scripting languages like VisualBasic (VB), PHP or Javascript.



Skype4Java

The Skype4Java API is a library that represents the Skype API as objects. It is very similar with the

Skype4COM API but for Java. The Skype4Java API brings the enormous Java community developers to the Skype developer’s arena, allowing multi-platform development over the Skype

API.

Skype Wrapper for .NET

The Skype Wrapper for .NET is another wrapper that allows .NET applications to consume Skype services inside the .NET platform.

This new API is capable of:

Send and Receive Phone Calls

• Easily send and receive calls from Skype users.

• Use the included CallSample sample to learn how to automate calls from your Skype contacts list.

• Create a custom application to track call information using the built-in timestamp, subject, duration, and callerID properties.

Send and Receive Chat Messages

• Easily send and receive chat messages from Skype users.

• Use the included ChatSample sample to learn how to send and receive chat messages from your Skype contacts list.

• Use the built-in ConsoleServerSample sample application to learn how to create an automated server that can be automated based on Skype messages.

The Skype Wrapper for .NET includes the full source code to enable developers to easily take and create customized applications.

C.3 MSN

C.3.1 Introduction

Microsoft originally released its free instant messaging and electronic communications client on

July 22, 1999 (then named MSN Messenger). It is part of Microsoft’s “Windows Live” set of online services. Corporations can integrate the client with Microsoft’s Live Communications

Server and Active Directory for instant messaging with integrated corporate security standards.

Underlying the client is the Mobile Status Notification Protocol (MSNP) running over TCP (or

HTTP which allows the client to better handle proxies) which connects to Microsoft’s .NET

Messenger Service (Port 1863 of messenger.hotmail.com). At the time of writing the latest production release of MSNP is Version 14, version 15 is incorporated in Live Messenger 8.1(beta).

MSNP can be considered a proprietary or closed protocol since only MSNP v2.0 was release as an

Internet Draft in 1999. Only MSNP versions 8 and higher will work with .NET’s Messenger

Service. Authentication up to and including MSNP v14 uses TWN (or “tweener”) authentication to log the client into Microsoft’s Passport service. MSNP v15 introduces RPS (Relying Party Suite) in

Windows Live ID which is the successor to Passport Manager. The most significant rivals of

Windows Live Messenger are AIM and ICQ (both from AOL), Skype, Gaim, and Jabber based clients including Google Talk.

Microsoft has focused on producing a Windows client, leaving the Mac population with a limited client and the Linux crowd without a client. In October 2005, Microsoft and Yahoo agreed to interoperate with each others IM clients resulting in the second largest user base at 40% of the market. AIM currently holds 56%.


page 80 (80)

C.3.2 Other Features


Xbox Live integration has now been included, also PC to PC calls and PC to phone calls. There is also a “sharing folder” feature which comes with built-in anti-virus.

C.4 Open Source alternatives

There are a lot of candidates for open source SOA. However the SOA is based on a component based approach and there are multiple movements and some huge actors in this field. The most notable one is probably JEMS (JBoss Enterprise Middleware Suite), that addresses SOA directly, but earlier projects like LAMP (Linux, Apache, MySQL and PHP) are influencing this movement.

Figure 35 – JEMS

JEMS is built from a number of open source components, and bundled and distributed by the

RedHat organization. JEMS is comprised of category leaders: JBoss Application Server, Apache

Tomcat, and Hibernate. Newer products are rapidly establishing leadership positions in the open source community based on customer and partner adoption. These include JBoss Portal, JBoss jBPM, JBoss Rules, JBoss Transactions, and JBoss Messaging. Together, this middleware suite offers the foundation for SOA and a path to greater business agility. Its modularity enables enterprises to standardize on JEMS at their own pace. Many companies include parts of JEMS such as Hibernate, JBoss Cache, and JBoss Portal to enhance existing application and SOA deployments.

Studies on Open-Source Alternatives for telecom also indicate:

• Although this is a rather novel approach for the Telecom sector, reports exist for other sectors that indicate the application of open source software reducing the total cost of ownership of IT applications by as much as 70%

• The open software market is unexpected large and opens up for new business models, new vendors / actors, new ways of systems development and a well of new solutions and components

• It represents a lower cost alternative in a number of areas

• A number of promising open software systems and components exist, some of which are also widely applied in the telecom arena

• Well known general open software components that merit further evaluation: LAMP

(Linux, Apache, MySQL and PHP), JBOSS and Asterisk

• Open-source Customer Relationship Management and billing systems exist that merit further evaluation: OpenCRX, SugarCRM, AstBill and ParaBill


Technical Information Service Oriented Architectures for

Technical Information

Service Oriented Architectures for convergent Service

Delivery Platforms

Applying Service Oriented Architectures to Service Delivery Platforms

EDIN

Project

0532-1652

P1652

For specified purposes

December 2006

Preface

Executive Summary

Table of Contents

List of Figures

Abbreviations

1 Introduction

2 Service Delivery Platforms – concepts and principles

2.1 SDP Market drivers

2.2 SDP Standards point of view

2.3 SDP reference architecture

3 Applying SOA to SDPs

3.1 Business Requirements

3.2 SOA Applicability

3.3 SOA@SDP use cases

4 Conclusion / Recommendation

References

Annex A OMA Enabler Releases

A.1 Candidate Enabler Releases

A.2 Approved Enabler Releases

Annex B SDP vendor's point of view

B.1 Oracle

B.2 IBM

B.3 BEA

B.4 Microsoft

B.5 OpenCloud

B.6 Mobicents

Annex C Software operators SDP

C.1 Google

C.2 Skype

C.3 MSN

C.4 Open Source alternatives

Related documents

Add this document to collection(s)

Add this document to saved

Suggest us how to improve StudyLib