SDPs Services Made Easy

Document Sample
SDPs Services Made Easy Powered By Docstoc
					Service Delivery Platforms:
“New Services Made Easy”
      A MetaSwitch White Paper
 Daniel Marcus, Director of Marketing
1.    Introduction: Why the need for SDP ................................................................................................ 3
2.    SDP Defined: Services Made Easy ................................................................................................. 4
3.    SDP defined: Key Functional Areas ................................................................................................ 5
4.    SDP Benefits: Changes the Services Game ................................................................................... 7
5.    History: The Technology Evolution .................................................................................................. 9
6.    Transition to IMS: Plumbing for Convergence ................................................................................10
7.    What a Service Entails and Some Examples .................................................................................11
8.    SDP Components...........................................................................................................................12
9.    Building Blocks On Top of Building Blocks: SIP and Java Libraries ...............................................16
10. Service Oriented Architecture and Operational Building Blocks .....................................................17
11. Capital and Operational Expenditure Savings ................................................................................19

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.

“Data Connection” and “MetaSwitch” are trademarks of Data Connection Limited and Data Connection
Corporation in the United States and other countries. Other brands and products referenced herein are
the trademarks or registered trademarks of their respective holders.

Copyright © 2007 MetaSwitch, a division of Data Connection. All rights reserved.

                                                              Service Delivery Platforms (SDPs) – "New Services Made Easy" | 2
Today's 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.
•    An SDP includes tools that allow very easy definition          An SDP allows service providers
     and development of new services.                               to define, develop and deploy new
•    It also provides a single environment within which             services far faster than they have
     network integration occurs once, so new services do            historically been able to.
     not require major new IT integration.
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 cost-effectively 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.
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.

                                                Service Delivery Platforms (SDPs) – "New Services Made Easy" | 3
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
                                                                                   An SDP is more than a
This flexibility allows carriers of all sizes to tailor services to all of their
                                                                                   single product, or
customers in way once reserved only for their largest. In addition,
                                                                                   component within the
carriers can now develop service suites more conducive to customer
                                                                                   network. It is a suite of
self-care and tightly integrated with web interfaces.
                                                                                   interconnected products
SDPs combine commercial off the shelf (COTS) hardware (industry-                   that enable flexible
standard servers) with interoperable libraries of common function code,            service creation,
or “software building blocks.” These building blocks shortcut                      modification and
development and allow fairly junior IT professionals to make the kinds             subscriber
of modifications to services that once could only be made by                       personalization.
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 industry’s trending toward open architecture computing systems
•    advances in low-cost COTS computing platforms.

                                                   Service Delivery Platforms (SDPs) – "New Services Made Easy" | 4
The key functional areas addressed by an SDP include the Service Creation Environment, the Service
Execution Environment and the Common Service Support Functions.

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                An SDP’s software
accesses the SCE via a Graphical User Interface (GUI) that simplifies           building blocks shortcut
the process for locating and utilizing the appropriate service logic by         development and allow
representing it graphically. Via the GUI, the SCE pulls in code (typically      fairly junior IT
Java) and allows the service developer to string the service logic              professionals to make
together. This simple approach is used to make modifications to:                the kinds of
•    the telephony services themselves                                          modifications to services

•    the corresponding Telephone User Interface (TUI) – the menu                that once could only be

     prompts a user accesses through dial tones on his phone.                   made by experienced
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.

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.

                                                Service Delivery Platforms (SDPs) – "New Services Made Easy" | 5
•   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.

3.3 Common Service Support Functions
These refer to the basic software elements used to construct a service. The Service Creation
Environment presents the Common Service Support Functions to the developer in a simple 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.
•   Servlets are protocol- and platform-independent components written in Java. They provide linkages
    between Java servers that are critical for distributed computing. Common Service Support
    Functions provide a library of SIP servlets, enabling a developer to transparently incorporate them
    into the service logic without requiring that he or she have an intimate understanding of servlet
    technology. This renders the traditional concern of scaling a popular service to meet demand a
    non-issue because the underlying logic for distributing the application widely throughout the network
    is built-in.
•   The Session Initiation Protocol (SIP) is an application-layer control (signaling) protocol for creating,
    modifying, and terminating sessions with one or more participants. These sessions include “Internet
    telephone calls, multimedia distribution, and multimedia conferences.".

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

                                               Service Delivery Platforms (SDPs) – "New Services Made Easy" | 6
SDP changes the nature of service providers’ businesses. By developing applications quickly and
inexpensively, SPs can focus on service differentiation through subscriber personalization. Increased
subscriber interaction creates a sticky personalized experience that complements different subscriber
lifestyles. This encourages customer loyalty and creates a powerful channel for trialing and selling new
•    By enabling SPs to extend new services through the same web and telephone interfaces with which
     existing subscribers are already familiar, SDP ensures that each new service appears to belong to a
     continuum of services.
•    The subscriber investment in time learning to operate one service simply extends to each
     subsequent service.

                                  Figure 1: Sample Subscriber Web Interface

Powered by SDP, services easily share common function keys, interfaces,
prompts and announcements across a growing variety of devices,                     Subscribers learn to use
applications and interfaces. For example, subscribers used to pressing #6          each additional
to fast forward a voicemail message, could also reasonably anticipate              application with growing
pressing #6 to fast forward a recorded conference call or any recorded             ease and become used to
message or announcement across services system-wide. This means that               a system rather than an
subscribers learn to use each additional application with growing ease and         individual service.
become familiar with a system rather than an individual service.

                                              Service Delivery Platforms (SDPs) – "New Services Made Easy" | 7
Service customization is extended to service providers and their customers.
•   Service providers can easily and quickly customize services to the needs of its enterprise
    customers, offering a unique and differentiated business solution as opposed to a canned service.
    They might even extend the ability to customize services to the enterprises themselves.
•   Business users can access and personalize their business services from home, blurring the wall
    between home and business applications.
•   Both home and business users enjoy an unprecedented level of service selection, preference
    setting, and personalization through a tightly integrated web self-care component of SDPs.

The ability to build new services very quickly means that SPs can also kill off unpopular services without
losing investment. This changes the very nature of how SPs look at services.

With an SDP in place, SPs can afford to experiment, trialing new services without fear of choosing
incorrectly. This allows SPs to
•   leverage one of their most valuable business resources, namely knowledge of their own subscriber
    preferences and behaviors
•   customize their offering based on demographics, providing multiple alternative language options or
    custom applications to high density ethnic enclaves
•   provide niche services geared toward the elderly, university students, business travelers, and many
    more specific customer types.

In a new competitive era in which differentiation is critical, SPs can now respond instantly to subscriber
trends, potentially reaping the benefit of picking the next killer application with very little risk for having
made the effort.

SDPs also offer SPs a new sales channel for targeted marketing. Subscribers of one service that are
likely to adopt a related additional service are easily identified. Information about the additional service
can then be relayed via informational prompts, announcements and visual media in conjunction with the
existing service. Via flow-through provisioning and customer self service activation, that subscriber can
then elect to initiate the new service and be billed for it.

For example, an SP may elect to place an advertisement on the web page or welcome prompt of the
TUI, stating, “We are pleased to offer our business Unified Messaging (UM) customers a free trial of our
new conferencing service. Press #3 for more information.”

                                                 Service Delivery Platforms (SDPs) – "New Services Made Easy" | 8
This is not the first time the industry has attempted to build a flexible, open framework for building new
services. The 1990s witnessed the rise of Advanced Intelligent Networking (AIN), which was supposed
to enable rapid service creation over circuit switched networks. While AIN was widely deployed – for
example to enable toll-free calling – the full promise of a flexible environment for service creation and
customization was unfulfilled. There are several reasons for this.
•    At that time network convergence was more of a prediction than a reality, with service providers
     routinely maintaining multiple network architectures in parallel combined with multiple service silos
     specific to each network.
•    The hardware required to implement AIN services was costly, requiring dedicated digital signal
     processor (DSP) and digital trunk (E1/T1) interfaces.
•    The AIN protocols, while openly available, were complex to implement and challenged even the
     most experienced programmers.
•    Competition, while much touted, was still in its infancy. Established carriers were not yet feeling the
     pressure of competing providers driving them to introduce truly innovative services.

In contrast, today we see all of these factors reversed.
•    The turn of the century witnessed the rise of VoIP, and today truly converged networks are being
     built based on IP and Ethernet.
•    The price / performance ratio of COTS hardware and general-purpose processors has been steadily
     driven downwards by Moore’s law and the standardization on Ethernet.
•    Recent standards such as XML and SIP and the wide availability of open source implementations
     have made it much easier to develop applications quickly.
•    The competitive environment is very real for carriers of all sizes. With the emergence of “over the
     top” voice (and video) services, communications alternatives such as instant messaging, the
     success of alternative providers’ VoIP offerings, and the inexorable rise of cellular, SPs can no
     longer pretend that competition is something that might happen in the future. It is here today, and it
     will be unforgiving to SPs who cannot adapt to the new environment.

                                               Service Delivery Platforms (SDPs) – "New Services Made Easy" | 9
If open architecture trends create the hardware and software environment necessary for a successful
convergence, IP Multimedia Subsystem (IMS) creates the architecture. IMS is an architectural
framework first designed by the 3GPP standards body to deliver multimedia services over wireless
networks. As service providers transition to IMS, it becomes possible to deliver services seamlessly
across disparate networks. Much of the IMS specifications detail how to register users and designate
from where in the network they’ll be served. This enables SPs to deploy hybrid services like fixed
mobile convergence (FMC), which maintain subscriber media and telephony sessions seamlessly as
they transition between fixed and wireless access.

Similarly, SDPs provide a critical framework that enables SPs to develop services that share subscriber
information and are accessible across both fixed and wireless networks. This eliminates the highly
inefficient structure of the past in which, for example, a voicemail application would need to be designed
and maintained separately for each type of access network. They shared no common hardware or
attributes despite serving the same subscribers with an identical offering. This added considerable
operational complexity and rendered simple modifications to services spanning multiple networks both
cumbersome and cost-prohibitive.

While some people have framed the difference between IMS and SDPs as an “either/or” question, in
reality they are complementary. SDPs can be considered simply as a framework for quickly creating
applications that sit on top an IMS network.

                                               Service Delivery Platforms (SDPs) – "New Services Made Easy" | 10
The vast majority of telephony services may be considered as a “two–legged” in nature:
•    One leg deals with call control (establishing the call, receiving the call, transferring the call etc.).
•    The other leg deals with media control (audio prompts played in response to subscriber actions,
     audio mixing within a conference bridge).
                                                                                While some people have
Any SDP utilized for a telephony service needs to account for both
                                                                                framed the difference
legs of the service and coordinate them in a sensible manner. This
                                                                                between IMS and SDPs
holds true for traditional services like Voicemail, Unified Messaging,
                                                                                as an “either/or”
Auto-Attendant and Find Me / Follow Me, as well as entirely new
                                                                                question, in reality they
services that allow for greater personalization. Some examples of
                                                                                are complementary.
new services combining traditional elements include:
•    Subscriber configured sports updates – Detects subscriber location and pushes subscriber-
     specified sporting event results to any variety of devices depending on the location and session
     activity of the subscriber. The service could ascertain the most appropriate location to push the
     service, whether it was to the subscriber’s handset, computer, or TV, via Set-Top-Box.
•    Subscriber configured weather updates – Customizable service pushes weather updates for pre-
     configured locations as well as in response to the subscriber’s actual location at that time.
•    Subscriber configured news updates – Customizable service pushes news updates for pre-
     configured locations as well as in response to the subscriber’s actual location.
•    Real-time billing and self-subscription – Enables subscribers to determine their current usage plan,
     activate additional services and view their bill in real time.

                                                Service Delivery Platforms (SDPs) – "New Services Made Easy" | 11
SDPs comprise the following components.

                                      Figure 2: Sample SDP Architecture

8.1 Service Creation Environment
Service Creation Environment (SCE), used to rapidly create new services, or improve and customize
existing services. This (typically graphical) interface offers developers an easy way to identify and
combine the appropriate pre-defined software code building blocks required for new service creation.

                                             Service Delivery Platforms (SDPs) – "New Services Made Easy" | 12
                                                                                 A service creation
                                                                                 environment (SCE) is
                                                                                 used to rapidly create
                                                                                 new services, or improve
                                                                                 and customize existing

                                 Figure 3: Service Creation Environment Client

In addition, this same environment executes subscriber service personalization. Subscribers typically
have a much simpler and more limited interface to the SCE, via (for example)
•   an interactive Set-Top-Box (STB) menu
•   web-self care or a customer portal
•   a thin client application.

                                                                                 Subscribers typically
                                                                                 have a simple interface to
                                                                                 the SCE that allows them
                                                                                 to personalize their own
                                                                                 service and modify

                                     Figure 4: Subscriber Interface to SCE
                                              Service Delivery Platforms (SDPs) – "New Services Made Easy" | 13
SCEs vary in terms of their level of graphical sophistication and drag-and-drop service logic. However,
a properly architected SCE enables flexible interaction between its own GUI and external development
environments, such as the Eclipse integrated development environment (IDE).

                                                                             A properly architected
                                                                             SCE enables flexible
                                                                             interaction between its
                                                                             own GUI and external
                                                                             environments, such as
                                                                             the Eclipse IDE.

                                             Figure 5: Eclipse IDE

8.2 Subscriber Web Interface/Portal
Subscriber Web Interface/Portal (Web self care) promotes customer self-care, service selection and
personalization for both existing services and subsequent service enhancements delivered via the SDP.
The great majority of new telephony services that are going to be deployed on SDPs will have some
sort of subscriber personalization component that the web interface enables. An obvious example is a
voice mail service which allows subscribers to change pin codes, select between and record new
greeting options, and review visual voicemail messages. The subscriber web interface is typically
developed using the latest generation web technologies including:
•   XML - Extensible Markup Language (XML) facilitates the sharing of data across different
    information systems, particularly via the Internet.
•   VXML – Enables specification of interactive voice dialogues between people and computers. It
    allows voice applications to be more easily integrated with visual applications.
•   SOAP - is a protocol for exchanging XML-based messages over computer networks,

                                              Service Delivery Platforms (SDPs) – "New Services Made Easy" | 14
8.3 Media Server
Media Server provides an integrated media processing platform utilized by all SDP-developed
applications to support media functions via RTP, including cross-platform announcement generation,
DTMF detection and generation, message play and record, conference recording, and more. In IMS
terminology, this refers to the Media Resource Function (MRF). A number of solution providers offer an
MRF as a standalone platform for IMS networks. However some SDP vendors now incorporate the
functionality as well for even greater flexibility and simplified integration.

8.4 SIP Servlet Library
SIP Servlet Library provides a modular set of pre-integrated telephony service objects, mapped to the
SDP’s SCE and combined to create the service logic for all new applications and features. The library,
in conjunction with the SCE, essentially enables developers to create the service logic for all new
applications without requiring a detailed knowledge of IMS SIP signaling standards.

8.5 Virtual Home Subscriber Service
Virtual Home Subscriber Service (HSS) provides a lightweight directory that flexibly enables
applications to store subscriber and global configuration data locally, or at a centralized external HSS
via a common API. This promotes the sharing of subscriber data between and among different
applications that run on the SDP. While certain subscriber information is utilized network-wide by all
services and therefore resides on a centralized HSS, other information remains exclusively useful to
specific applications. By storing that exclusive-use data locally, the virtual HSS minimizes non-required
network traffic and accelerates service performance. A good example of this type of exclusive-use
service data is a subscriber’s voicemail greetings. These large files need to be accessed rapidly by the
service code and would incur slow service response if stored and accessed via centralized HSS.

                                               Service Delivery Platforms (SDPs) – "New Services Made Easy" | 15
The concept of software building blocks plays prominently in the evolution of the SDP. In order to
develop new services quickly, it’s imperative that developers be able to effectively locate and reuse
common pre-integrated blocks of code. This shortens development times and consequent time to
market. Far less testing is required for root functions when they have already proven stable through
reuse across multiple services. SDP comprises modular blocks of code, making it easy for developers
to locate and combine commercially proven code blocks with a minimal amount of additional code,
typically at a higher level.

This methodology also promotes the sharing of (subscriber) data between and among different
applications that run on the SDP. For example,
•    a common PIN code utilized across multiple services can simply be extended to a new service
•    common function keys or interfaces, prompts and announcements across various devices and
     applications can easily be extended.

Consequently, developers creating new services only need concentrate on the top-level service logic
and yet remain assured of seamless integration with their subscribers’ existing service suites.

Two tiers of building blocks are available to developers via the SCE, the SIP stack back end and the
Java front end.
•    The SIP stack is the lower level building block that handles the aspects of call control required by
     any SIP application within an IMS environment. Developers employing these modular blocks of SIP
     code don’t have to manage the assignment of all the bits and bytes inherent in programming SIP
     flows. Rather, they can rely on the SIP stack for call control and concentrate instead on the
     relatively simple elements exposed typically via Java or C++ application programming interfaces
•    A true telephony-oriented SDP also shortcuts Java development by publishing a modular Java
     building block library that provides for common standardized operations. This way a developer can
     instruct the SDP to, for example, “launch this call leg,” “drop that call leg,” and “transfer the other
     call leg” without having to worry about the details of what needs to be implemented (at both the
     code and the protocol level). This serves to make generic functions that span multiple services
     easily reusable.

Consider the example of the “call transfer” function. Call transfer is utilized by multiple applications. If
each application had to deal with the detailed SIP flows then soon they would become unwieldy and
hard to develop. Those applications would also need to handle all the error cases which can occur (for
example if one of the call legs receives unexpected SIP messages). By encapsulating that function in
high-level Java libraries, however, the application developer can concentrate on developing just the
function needed and use the underlying utilities to handle the majority of the work.

                                               Service Delivery Platforms (SDPs) – "New Services Made Easy" | 16
Modern SDPs utilize a Service Oriented Architecture (SOA), a concept referring to the enabling of
application resources to be linked together easily across a variety of platforms and services. Adherence
to SOA principles enables subscribers to personalize and access services via
•   web browser
•   SIP business phones with XML mini-
•   PDAs
•   Set-Top-Boxes (STBs)
•   a variety of desktop clients.

While SOA is more of a generalized set of
principles than a hard and fast rule set,
successful execution of SOA requires open
Application Programming Interfaces (APIs)
all the way down to the client itself. This
enables web developers to access a kind of
open interface to the underlying services,
making it extremely easy to enhance
existing web pages as well as design
entirely new ones sharing the same underlying service logic.

As one example of what SOAs make possible, by exposing third party call control capabilities through
web services interfaces, developers can easily embed click to dial service logic in their own web pages
and extend this functionality via hyperlinks to other parties’ web pages.

SOA principles are important to successful SDP implementation as they allow complex service logic to
be easily transferable across devices and interfaces. This is accomplished by hiding many of the
interoperability problems associated with next generation telephony services.

Successful SIP-based applications require interoperability with a variety of end-user devices, each with
potentially subtle differences in the way in which they implement SIP call setup and tear down. By
adhering to SOA principles, including published open APIs, SDPs simplify the process of integrating
new devices on the system.

Another important aspect of SOA involves integrating the SDP with existing OSS and BSS systems.
This is important for flow-through provisioning, which refers to the ability to automate billing and network
diagnostics for new services. Integration with OSS and BSS systems is critical for provisioning, billing
and monitoring new users and reallocating network resources instantly in the event of hardware failure.

                                              Service Delivery Platforms (SDPs) – "New Services Made Easy" | 17
For example, once a subscriber selects a new service, flow through provisioning automatically adds that
subscriber’s usage statistics to the Service Provider’s system-wide management view and initiates
integrated billing for that service from the subscriber’s view.

Operational building blocks sit atop an SOA and present developers with libraries of standardized
interfaces useful in connecting new services to existing OSS and BSS systems. This is achieved by
way of a common OSS northbound interface. Examples of operational building blocks include:
•   developer level tracing and logging
•   common management interfaces
•   common ways of performing alerts
•   common ways of performing billing.

                                              Service Delivery Platforms (SDPs) – "New Services Made Easy" | 18
Based on a completely distributed COTS hardware framework, SDPs minimize capital expenditure,
enabling a flexible, low risk pay-as-you-grow model. By abstracting services from hardware, SDPs
essentially create an expandable and contractible hardware resource pool. Hardware from this pool can
be allocated to a new service, further expanded based on service uptake, or repurposed to a more
winning application if a service’s popularity wanes.

For example, a server purchased initially for voicemail can be easily repurposed for conferencing if the
latter enjoys more favorable subscriber adoption.

From an operational expenditure perspective, SDP radically reduces the time it takes to integrate a new
service with existing operational platforms. Since new services will not necessarily be identical to
existing service parameters in the OSS and BSS suite, incremental integration work must necessarily
be done by the OSS vendor to ensure flow through provisioning. Again, the SDP’s published interface
details simplify this integration and allow the OSS and BSS vendors to more effectively accommodate
SP plans for service growth.

                                             Service Delivery Platforms (SDPs) – "New Services Made Easy" | 19
MetaSwitch delivers next generation switching and fully-integrated telephony applications to over 300
service provider and large institutional customers worldwide. MetaSwitch’s products are designed for
TDM, VoIP and IMS networks and include an end-office/tandem (Class 4/5) softswitch, a service
delivery platform (SDP) optimized for telephony, and a suite of commercially proven applications. These
products share a common element management system (EMS) for efficient provisioning and
management. Whether deployed to deliver a single telephony service or many services, MetaSwitch
products are designed to scale and encourage service enhancement while simplifying integration with
existing network elements.

                                           Service Delivery Platforms (SDPs) – "New Services Made Easy" | 20
MetaSwitch, a division of Data Connection
1001 Marina Village Parkway, Suite 100
California 94501
Tel. (510) 748 8230
Fax (510) 748 8236

Shared By: