Carrier-Class InfrastructureA Service Provider’s

PerspectiveJoel Maloff, PhD.

Fusion, Inc.Jmaloff@fusiontel.com

Conference Program

• Service providers are focused on quickly and cost-effectively bringing differentiated services to market; addressing their customers’ needs, while supporting the provider’s current network architecture and evolution strategies. For developers, this means there is no uniform or ideal architecture being adopted by service providers across the board. Many providers discover that to rapidly deliver advanced VoIP-based applications; multi-function platforms can offer substantial benefits. Deploying such platforms enables service providers to rapidly deliver new offerings while reducing CapEx and OpEx, enabling providers to build cost-effective networks. This session will briefly examine the alternative architectures available to providers and analyze the advantages and disadvantages of each.

Objectives

• To provide insight from an actual carrier seeking to deploy Carrier-Class Infrastructure.

• To share the processes and experiences of this effort

• to help guide developers out of the lab and into the field.

Overview

• Defining the Carrier’s Requirements up front

• The definition of “Carrier-Class Infrastructure” according to Fusion

• Identifying Network Elements and Potential Providers

• Recognizing Fact from Vaporware• Assuring that what was developed

achieves what is required

Background

• Fusion is an international carrier focused on emerging markets in Asia, Latin America/Caribbean, the Middle East, and Africa.

• Fusion had a Class 4 TDM switch installed and was seeking alternatives that would support the migration to IP in an elegant and evolutionary manner.

• Our solution was a detailed Request for Proposals (RFP) Process.

Defining Requirements

• Moving from a traditional TDM switch and entirely separate Internet infrastructures to an integrated VoIP environment requires substantial thought on the part of the carrier before investigating various network element alternatives.

• No two carriers are identical – the differences in approach, services, frequency of route modifications, report requirements, and investment strategies may be greater than the similarities.

o Vendors tend to think in terms of Call Models rather than unique carrier characteristics.

Defining Requirements

• The Request for Proposal (RFP) Processo The carrier documents their perceived requirements

with as much granularity as possible.• Anticipated growth requirements – number of ports, number

of concurrent calls, number of physical switching locations, number of media gateways, transport interface (T-1, E-1, OC-x, et al), etc.

• Signaling requirements – SS7, ANSI, ETSI, et al• CODEC interface Requirements (G.711, G.723, G.729, et al)

– Vendors presume G.711; because of bandwidth requirements, G.723 or G.729 are often preferred.)

• Specific features and functions• Routing requirements – manual, bulk loading, frequency• Reporting requirements and interface with OSS

– Ability to monitor health of network in real-time.• Redundancy and Availability• Anything else that is important

The definition of “Carrier-Class Infrastructure” according to Fusion

• Delineating carrier-class from IT-based infrastructure like ISPso - 48v DC power vs 120v AC power

standardo NEBS-compliance – Intel-based solutions

that are cheaper and may perform better may not be NEBS compliant

o No single point of failure• Dereferencing through a Null pointer• Transient States that become permanent

o Hot swappableo No maintenance window

• 99.999% Availability

Identifying Network Elements and Potential Providers

• Potential providers are identified by:o Prior knowledgeo Media coverage and web searcho Conferences and trade showso Word of mouth

• Potential providers are invited to respond to the RFP

• The RFP identifies the carrier’s objectives; Responses to the RFP indicate how the provider will meet them.

Recognizing Fact from Vaporware

• Traditional “Big Iron” infrastructure providers vs. “New Age” vendorso BI knows telephony; NA knows IP; nobody

knows it all.

• Research – articles, analyst reports, etc.

• Direct reference checkso Sometimes useful, sometimes noto Sometimes what is not said is as

important as what is.

• Trial Period

“Plan Meet Need”• Normally, potential buyers investigate

possible vendors in great detail before buying.

o In the case of Carrier-Class Infrastructure, the network element vendor MUST investigate the carrier before committing to deliver service.

• Salespeople are insufficient.• Sales Engineers may not be enough.• Do you REALLY understand how THIS carrier functions?• Have you REALLY met their most pressing needs

previously?• Have your developers EVER been on-site at carriers of

various size and scope? Have they ever talked to a real customer or provided Level One or Two support?

• Do you develop your products based on live carrier requirements or do you base your development on what your competitors are offering?

Conclusions• For developers, there is no uniform or ideal

architecture being adopted across the board by service providers, which therefore requires insight and innovation on your part.

• Multi-function platforms can offer substantial benefits to service providers but ONLY if they truly meet the needs of the carrier.

o As developers, how well do you really understand your customer’s needs? How open and willing are you to learn from your customers?

• As a carrier and service provider, our interest lies in the details rather than just the high-level architecture.