To learn about the latest news on telecom, we sat down with the manager of architecture and planning for Sprint’s network services research and development division.
When we decided to cover telecom in this issue, we were glad to get a chance to talk to Bob Morrill, a key technical planning manager within Sprint’s research and development area. Before a recent reorganization that put him in charge of all wireline planning, Morrill led technical planning for Sprint’s Circuit to Packet initiative. In lay terms, he was in charge of preparing to convert Sprint’s network from plain old telephone service (POTS) to an IP-based network.
IP technology enables incumbent local telecom companies (ILECS, or Baby Bells) and nontraditional telephony providers (such as cable companies) to offer integrated voice, data, and video services. Most of the major telcos are in the process of converting their legacy POTS systems to IP, but it’s a big job that will take several years.
Where is the telecom market going in the integrated voice and data space?
The whole market is moving into IP. In a few years, I expect only remnants of circuit-switched systems as packet-switching takes over. At Sprint, we’re moving into a voice-over IP (VoIP) network architecture. Sprint has long recognized that voice-over packet is a key architecture. As the technology becomes more prevalent, the value increases, and that fuels faster development.
Where is Sprint, relative to other carriers, in the circuit-to-packet conversion?
We lead the field in packet-based systems. A Sprint local network in Gardner, Kan., was the first all-packet-based local telephone service in the country. We’re committed to converting all of our 8 million local lines to a packet-based architecture.
What is Sprint’s overarching strategy for packet?
Sprint is heavily invested in VoIP. We held some of the first trials in packet technology over circuit-switched networks in the mid ’90s. It was originally called the ION project. Our new Circuit to Packet project is a packet-based voice and data architecture that promotes convergence of the disparate overlay networks.
What you have today is a lot of different carriers at different stages of developing packet-based systems. This project aims to help them work together. Going forward, we will provide voice-over packet in our own private IP network. Our first implementation will be ATM-based. Eventually, we’ll move over to a pure IP-based architecture.
Why not go straight to IP now?
We worked very closely with our vendor, and their development was designed to start out in ATM. We needed the ATM service layer to give us the quality of service and other technical advantages that weren’t available over an IP-only system when we started this project. We’ve worked with the standards bodies to give IP the opportunity to handle some of our technical specifications. Once those specs are finalized, we can move to pure IP.
Why are you using a private IP network instead of running your VoIP service over the Internet?
As a class-five provider, we can’t offer service over the Internet and still make the grade with the FCC. I think if you look at other providers that offer voice-over packet, typically they would go over a private IP system. With a private network, you have a managed network, which gives you a lot more control over traffic and helps you to optimize your routes. We have a managed network now over our own backbone and we plan on leveraging that network for the circuit to packet implementation.
Besides performance, what other advantages does a private managed network bring?
One of the concerns we hear a lot from our customers is the ability to restrict security operations. Running both their voice and data over the same network ups the stakes on the security side. We take great steps to make sure the design has redundancy, and that the design can mitigate denial-of-service attacks. With these functions engineered and designed into the network, we can provide a much more secure system. You can’t totally eliminate denial-of-service attacks, but you can minimize them and design systems to mitigate attacks when they occur.
Besides VoIP, what services does Sprint plan on offering over its packet network?
Part of our focus is in providing wireless/wireline integration. There’s a lot of innovative new services that Sprint’s developed on the wireless side that we would like to drive into the wireline service. Take Sprint PCS Vision. Right now when you capture an image, you can only send it to other customers of PSC Vision. We would like to be able to send images to anyone on either the wireless or wireline network.
When you talk about private networks and incomplete standards, it sounds like there will be some interoperability problems. How will carriers work together in the future?
The carrier network hasn’t resolved how we’re going to hand off long-distance voice packets. Packet-based systems will definitely change the nature of the industry. Traditional non-telecom companies, such as cable companies, will offer telephone service. And companies that are used to offering mature voice services will need to do things completely differently than what they’re used to. But like all emerging technology, it will eventually work itself out.
How big will packet-based telephony be in a year?
We have talked with a lot of interested parties. We get a lot of inquiries. But adoption is not happening as fast as some of the marketing hype makes it out to be. I think a lot of companies are in research and wait-and-see mode right now. Security issues have slowed adoption. Economic conditions haven’t helped. The technology is a little bit immature, so large enterprises may not want to hang their hats on it until it matures and the cost/benefit ratio improves. In a year, we’ll see a lot more adoption.
What are the long-term prospects for packet telephony?
Long term, the real market potential is huge. Packet networks will eventually be the only telecom networks. Long term, we will replace every landline phone with VoIP phone. We’re really excited to be on the forefront of this movement.