Click here to load reader

Metaswitch White Paper Service Delivery Platforms R1

  • View
    18

  • Download
    3

Embed Size (px)

DESCRIPTION

Metaswitch White Paper Service Delivery Platforms R1

Text of Metaswitch White Paper Service Delivery Platforms R1

SERVICE DELIVERY PLATFORMS:NEW SERVICES MADE EASY

AN INTRODUCTION TO IMS

CONTENTS Introduction: Why The Need For SDP SDP Defined: Services Made Easy SDP Defined: Key Functional Areas 3.1 Service Creation Environment (SCE) 3.2 Service Execution Environment 3.3 Common Service Support Functions SDP Benefits: Changes The Services Game History: The Technology Evolution Transition to IMS: Plumbing for Convergence What a Service Entails and Some Examples SDP Components 8.1 Service Creation Environment 8.2 Subscriber Web Interface/Portal 8.3 Media Server 8.4 SIP Servlet Library 8.5 Virtual Home Subscriber Service Building Blocks on Top of Building Blocks: SIP and Java Libraries Service Oriented Architecture and Operational Building Blocks Capital and Operational Expenditure Savings About Metaswitch 3 4 4 4 4 5 5 7 7 8 9 9 11 11 11 11 11 12 13 13

ABOUT THIS DOCUMENT Anyone considering the deployment of a Service Delivery Platform needs to understand what benefits it brings and its relationship to the legacy technologies it is designed to augment or replace. Unfortunately, there is no clear consensus about exactly what an SDP is, because there are many different types of solutions available, all targeting different problem domains, and all marketed under the same SDP moniker. This white paper provides the background to SDPs, and gives a basic introduction to the architecture and characteristics of SDPs specifically designed for telephony applications.

WWW.METASWITCH.COM

2011 METASWITCH NETWORKS. ALL RIGHTS RESERVED. 2

AN INTRODUCTION TO IMS

INTRODUCTION: WHY THE NEED FOR SDP TODAYS SERVICE PROVIDERS ARE FACING WELL-KNOWN CHALLENGES. ARPU erosion as voice becomes a commodity. Aggressive competitors offering a broad range of services.

In response, they must deliver new high-revenue services. Unfortunately, there is a major obstacle barring their path: their traditional network integration and marketing processes mean that new service development takes a very long time and costs a huge amount. The SDP has been developed as a solution to this problem. An SDP allows service providers to define, develop and deploy new services far faster than they have been able to in the past. This is achieved in two ways.

So how does an SDP achieve these very attractive goals? Here we must address the technology, and the main components of an SDP. By way of warning, remember that SDP is not a toolset exclusively for telephony networks, although some SDPs have been developed specifically with this in mind. We will be focusing on the requirements of an SDP specifically targeting the concerns of telecommunications rather than the all-encompassing model designed to enable unrelated applications as well. The latter is arguably unwieldy for the needs of the telecommunications service provider.

1 2

An SDP includes tools that allow very easy definition and development of new services. It also provides a single environment within which network integration occurs once, so new services do not require major new IT integration.

An SDP allows service providers to define, develop and deploy new services far faster than they have historically been able to.

Once the cost of service deployment has been massively reduced, it allows the service provider to take an entirely different perspective on return on investment/business planning. In the old world (pre-SDP), the cost of deployment meant that any new service had to have an extremely robust business case and if it failed in the market, that was a big black mark against its champions in the marketing product definition team, or even against the network engineering team responsible for selecting a specific vendor. In the new world of SDPs, the service provider can costeffectively deploy a number of new services in limited areas. Some will succeed while others will fail. The latter are culled from the suite, but the business case for the former is much stronger. This supports far more imaginative approaches from the marketing team, without fear of tying the company to an unpopular service offering that is difficult to abandon. In the old world, services had to be developed for a large, horizontal market, as large numbers of subscribers were required to pay back the high implementation costs. In the new world, services can be introduced that target narrow, vertical market segments (for example, a service might be designed specifically for real estate brokers). The significantly lower implementation costs can be recouped over a smaller potential subscriber base.

WWW.METASWITCH.COM

2011 METASWITCH NETWORKS. ALL RIGHTS RESERVED. 3

AN INTRODUCTION TO IMS

SDP DEFINED: SERVICES MADE EASY AN SDP IS MORE THAN A SINGLE PRODUCT, OR COMPONENT WITHIN THE NETWORK. IT IS A SUITE OF INTERCONNECTED PRODUCTS, BOTH PHYSICAL AND LOGICAL, THAT ENABLE FLEXIBLE SERVICE CREATION, MODIFICATION AND SUBSCRIBER PERSONALIZATION.

An SDP is more than a single product, or component within the network. It is a suite of interconnected products that enable flexible service creation, modification and subscriber personalization.

This flexibility allows carriers of all sizes to tailor services to all of their customers in way once reserved only for their largest. In addition, carriers can now develop service suites more conducive to customer self-care and tightly integrated with web interfaces. SDPs combine commercial off the shelf (COTS) hardware (industry-standard servers) with interoperable libraries of common function code, or software building blocks. These building blocks shortcut development and allow fairly junior IT professionals to make the kinds of modifications to services that once could only be made by experienced programmers. By employing published open interfaces across the entire SDP landscape, SDPs are designed to easily integrate with existing OSS and Billing systems, minimizing the customization required to enable flow through provisioning. SDPs combine the business imperative to create and enhance services rapidly with: the latest generation of open application servers the industrys trending toward open architecture computing systems advances in low-cost COTS computing platforms.

3.1 Service Creation Environment (SCE) The SCE provides the service developer with an easily accessible menu of pre-built blocks of service logic. The service developer accesses the SCE via a Graphical User Interface (GUI) that simplifies the process for locating and utilizing the appropriate service logic by representing it graphically. Via the GUI, the SCE pulls in code (typically Java) and allows the service developer to string the service logic together. This simple approach is used to make modifications to: The telephony services themselves. The corresponding Telephone User Interface (TUI) the menu prompts a user accesses through dial tones on his phone.

3.2 Service Execution Environment The Service Execution Environment provides the back end for the Service Creation Environment. Together with the SCE, it enables rapid commercial development and deployment of applications. The Service Execution Environment is another way of referring to the native resource pool responsible for implementing changes and enhancements to services. The Service Execution Environment typically comprises either A Java Platform, Enterprise Edition (J2EE) environment optimized across a server farm A purpose-built platform utilizing proprietary software.

SDP DEFINED: KEY FUNCTIONAL AREAS THE KEY FUNCTIONAL AREAS ADDRESSED BY AN SDP INCLUDE THE SERVICE CREATION ENVIRONMENT, THE SERVICE EXECUTION ENVIRONMENT AND THE COMMON SERVICE SUPPORT FUNCTIONS.

An SDPs software building blocks shortcut development and allow fairly junior IT professionals to make the kinds of modifications to services that once could only be made by experienced programmers.

WWW.METASWITCH.COM

2011 METASWITCH NETWORKS. ALL RIGHTS RESERVED. 4

AN INTRODUCTION TO IMS

Of the two approaches, the J2EE environment enjoys some advantages. The open architecture J2EE / server farm model is substantially more flexible. This approach more easily achieves the ideal discussed in the introductory section, in which new services may be easily trialed without fear that they prove unpopular. Equally important, the J2EE environment is well-suited to handle unanticipated demand, in the event a new service proves to be so popular that previous generations of platforms would have been unable to scale to meet the demand. The J2EE model delivers the scalability, accessibility, and manageability that is required for applications that may ultimately grow far beyond initial expectations. By distributing the J2EE environment across a server farm, the SDP weds the industry standard for developing server-side applications (Java), with farms of functionally identical servers. These servers communicate through open-standards: SIP, LDAP, IMAP, VXML, SMTP, HTTP. The use of open-standards simplifies integration with legacy platforms, allowing new servers to be added at any time without requiring system downtime or service interruption. This simplifies both expansions of the service and software upgrades.

and often visual format. This makes it easy to develop services without possessing an intimate understanding of the underlying code. An example would be SIP servlets. A Java Platform, Enterprise Edition (J2EE) environment optimized across a server farm A purpose-built platform utilizing proprietary software.

Thus, the Common Service Support Functions provide developers with a generic library for common underlying software functions that is easily extensible across platforms in the event of great subscriber demand. SDP BENEFITS: CHANGES THE SERVICES GAME SDP CHANGES THE NATURE OF SERV

Search related