Metaswitch White Paper Service Delivery Platforms R1

SERVICE DELIVERY PLATFORMS: “NEW SERVICES MADE EASY”

2

AN INTRODUCTION TO IMS

© 2011 METASWITCH NETWORKS. ALL RIGHTS RESERVED.WWW.METASWITCH.COM

CONTENTS

Introduction: Why The Need For SDP 3

SDP Defined: Services Made Easy 4

SDP Defined: Key Functional Areas 4 3.1 Service Creation Environment (SCE) 4 3.2 Service Execution Environment 4 3.3 Common Service Support Functions 5

SDP Benefits: Changes The Services Game 5

History: The Technology Evolution 7

Transition to IMS: Plumbing for Convergence 7

What a Service Entails and Some Examples 8

SDP Components 9 8.1 Service Creation Environment 9 8.2 Subscriber Web Interface/Portal 11 8.3 Media Server 11 8.4 SIP Servlet Library 11 8.5 Virtual Home Subscriber Service 11

Building Blocks on Top of Building Blocks: SIP and Java Libraries 11

Service Oriented Architecture and Operational Building Blocks 12

Capital and Operational Expenditure Savings 13

About Metaswitch 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.

3



INTRODUCTION: WHY THE NEED FOR SDP

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 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.

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 applica-tions as well. The latter is arguably unwieldy for the needs of the telecommunications service provider.

1

2

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

4



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.

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 ser-vice 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 industry’s trending toward open architecture computing systems

• advances in low-cost COTS computing platforms.

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.

3.1 Service Creation Environment (SCE)

The SCE provides the service developer with an easily acces-sible menu of pre-built blocks of service logic. The service devel-oper 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.

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.

An SDP’s 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.

5



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.

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.

• 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 devel-opers 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 SERVICE PROVIDERS’ BUSINESSES. BY DEVELOPING APPLICATIONS QUICKLY AND INEXPENSIVELY, SPS CAN FOCUS ON SERVICE DIFFERENTIATION THROUGH SUBSCRIBER PERSONALIZA-TION. 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 SERVICES.

• By enabling SPs to extend new services through the same web and telephone interfaces with which existing subscrib-ers 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

6



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

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.”

Subscribers learn to use each additional application with growing ease and become used to a system rather than an individual service.

7



HISTORY: THE TECHNOLOGY EVOLUTION

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.

TRANSITION TO IMS: PLUMBING FOR CONVERGENCE

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 elim-inates 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.

8



WHAT A SERVICE ENTAILS AND SOME EXAMPLES

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).

Any SDP utilized for a telephony service needs to account for both legs of the service and coordinate them in a sensible manner. This holds true for traditional services like Voicemail, Unified Messaging, Auto-Attendant and Find Me / Follow Me, as well as entirely new services that allow for greater personalization. Some examples of 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.

While some people have framed the difference between IMS and SDPs as an “either/or” question, in reality they are complementary.

9



SDP COMPONENTS

SDPS COMPRISE THE FOLLOWING COMPONENTS.

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.

Figure 2: Sample SDP Architecture

Figure 3: Service Creation Environment Client

A service creation environment (SCE) is used to rapidly create new services, or improve and customize existing services.

10



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.

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).

Figure 4: Subscriber Interface to SCE

Figure 5: Eclipse IDE

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

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

11



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,

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.

BUILDING BLOCKS ON TOP OF BUILDING BLOCKS: SIP AND JAVA LIBRARIES

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 em-ploying 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 (APIs).

12



• 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 ORIENTED ARCHITECTURE AND OPERATIONAL BUILDING BLOCKS

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-browsers

• 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.

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.

13



CAPITAL AND OPERATIONAL EXPENDITURE SAVINGS

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.

ABOUT METASWITCH

METASWITCH IS A PRIVATELY OWNED TECHNOLOGY COMPANY BASED IN LONDON, UK. WE HAVE US OFFICES IN ALAMEDA, CA, RESTON, VA, AND BOXBOROUGH, MA.

Our Network Protocols Division is the leading developer and supplier of (G)MPLS, OSPF(-TE), ISIS(-TE), BGP, VPN, RIP, PIM, IGMP, MLD, ATM, MGCP, Megaco, SCTP, SIP, VoIP Conferenc-ing, Messaging, Directory and SNA portable products. Custom-ers include Alcatel, Cisco, Fujitsu, Hewlett-Packard, Hitachi, IBM Corp., Microsoft, Nortel and Sun.

Our company culture focuses on building software of consistently high quality, developed and supported by engineers who are with Metaswitch for the long term

• Founded in 1981, we have over 450 employees, of whom 280 are engineers. The average length of service of engineers at Metaswitch is 8 years, and the annual attrition rate is 3%.

• Throughout this period, Metaswitch has been consistently profitable with profits exceeding 15% of revenue. 2007-2008 revenues were $118m with $22m profit.

• Over 90% of revenue is generated from exports and 80% is from customers in the US (so we are very used to working with American companies).

• The company is privately held by top-tier investment firms Francisco Partners and Sequoia Capital, as well as the Employee Benefit Trust (EBT). As part of this ownership structure, Metaswitch distributes a share of profit to all employees, equitably rewarding them for their contribution and encouraging long-term commitment.

• As a private company with an emphasis on long-term stability, we are not driven by the short-term requirements of quarterly profit statements. This means that we can concentrate on providing software as we would like – that is, developing high quality implementations of complex technologies.

Our routing protocols are designed from the ground up to address next generation networking issues such as massive Internet scalability, optical routing at multiple layers, virtual routing, MPLS and TE/CSPF, and VPNs.

DC-MPLS, DC-VPN Manager, DC-BGP, DC-OSPF, DC-ISIS, DC-IGMP, DC-PIM and DC-LMP provide a complete set of solutions for optical and packet control plane requirements. These include integrated VPN solutions for BGP/MPLS VPNs and Martini.

All of the Metaswitch protocol implementations are built with scalability, distribution across multiple processors and fault tolerance architected in from the beginning. We have developed extremely consistent development processes that result in on-time delivery of highly robust and efficient software. This is backed up by an exceptionally responsive and expert support service, staffed by engineers with direct experience in developing the protocol solutions.

CONTACT US

METASWITCH NETWORKS 100 Church Street, Enfield EN2 6BQ, UK Phone +1 888 755 1793 or +44 (0)20 8366 1177 Email [email protected]

Documents

Metaswitch White Paper Service Delivery Platforms R1