Carrier-Class Infrastructure A Service Provider’s Perspective Joel Maloff, PhD. Fusion, Inc.

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) Process o 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 ISPs o - 48v DC power vs 120v AC power standard o 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 swappable o No maintenance window % Availability

Identifying Network Elements and Potential Providers Potential providers are identified by: o Prior knowledge o Media coverage and web search o Conferences and trade shows o 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” vendors o BI knows telephony; NA knows IP; nobody knows it all. Research – articles, analyst reports, etc. Direct reference checks o Sometimes useful, sometimes not o 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.