Softswitch Fever

One of the more pervasive new convergence buzzwords over the past 6 months has been “softswitch.” Vendors from Lucent and Cisco to Hewlett-Packard, Sun Microsystems and Telcordia are supporting this technology, which essentially provides an open, software-based switch. With softswitches, providers can deploy IP services with the reliability of traditional Class 5 telephony switches but at much lower cost and implementation time.

Because traditional, proprietary voice switches can require years for new applications to be added and deployed, softswitches present a distinct advantage for developers to quickly write new applications and for providers to roll them out to customers.

Faster to Market

A softswitch is sometimes referred to as a “virtual switch” because, unlike its Class 5 counterpart that is forced into a cage in a central office, it does not necessarily have to be at a CO. Softswitches can be considered an extension of the intelligent network (IN) movement, which saw some intelligence taken off the circuit switch and made creating new applications less painful.

“While creating new services or applications on an IN platform was much faster than on a traditional circuit switch, the fastest time is still about 9 months; we’re taking that model much further,” says Ramesh Ratan, executive director of Lucent Technologies’ Communications Software Group.

A carrier—whether an established IXC, ILEC or a CLEC in a greenfield environment—can use softswitch technology when they want to bring up new features quickly that can then be bundled or packaged with other services. Examples of new services include voice over IP or streaming video. “A lot of what’s been done in the area of converged services has been packaging these services from a marketing and customer care/billing point of view, but it doesn’t mean you actually have converged service,” Ratan says. “You still use your cellular phone for wireless and use your home phone for wireline—they are still different networks.”

Ratan adds that a new model needs to present a much more seamless way of creating and offering bundled services. A softswitch can offer one way to do that, because it interconnects the PSTN to IP-based services.

Rising Momentum

The frenzy around this technology has been rising since May last year, when the International Softswitch Consortium (www.softswitch.org) was created with the intent of focusing on a standard way for IP networks and traditional telephony networks to interconnect. The group, which now includes more than 50 members, is developing standards to promote interoperability among hardware and software systems that support standard protocols, such as Media Gateway Control Protocol, Session Initiation Protocol, Real-Time Transport Protocol and H.323. In August the group held its first interoperability event, and a second was held this January.

Since the formation of the group, a number of companies have come forward with softswitch announcements that will make it hard for carriers to ignore.

Lucent Technologies is particularly active, signed on the dotted line with several high-profile providers to deliver softswitch goods. Since last summer, the company has joined up with Level 3 Communications, Frontier Communications and NTT Communicationware (NTT Comware), all of which will test and deploy Lucent’s softswitch technology.

Level 3 plans to use the Lucent product on its voice over IP implementation, which it aims to make as simple as placing a traditional circuit-switched phone call, rather than having end users dial long strings of numbers to get an IP connection. Frontier is also planning to build an IP telephony network to offer voice services. And NTT Comware, a Japanese telecom systems designer and operator, is building a facility to test Lucent’s softswitch and will eventually market the technology to service providers in Japan.

More recently, Lucent entered into an agreement with Sun Microsystems, in which Lucent’s softswitch would run on Sun’s Netra line of servers.

Another active company, Telecom Technologies, created its own softswitch initiative last November. Although Telecom Technologies is a member of the International Softswitch Consortium, it launched its INIP (which stands for the company’s IntelligentIP softswitch product) Powered Partner Program to promote interoperability of different softswitch products and hardware with its own. While this effort is fairly exclusive, since it involves Telecom Technologies’ softswitch, it is a start at real compatibility testing.

Because softswitches are open in nature, third-party developers can more easily create applications for services like voice and video without worrying about the constraints imposed by proprietary voice switches.

What about CDRs?

But when a carrier brings a software-based switch into its infrastructure, what does that do to its billing model? Will billing systems that are accustomed to receiving data from Class 5 switches have to be modified to accept information from a softswitch? These are significant questions that most service providers will want answers to before they look seriously at the technology.

Much like a Class 5 switch, a softswitch collects a lot of data about services that are taking place. It usually collects call-related data and generates CDRs for each session. “The softswitch collects information, such as the parties involved in a call, how long they were on the line and when someone went off the hook, and combines them into event blocks,” Ratan says. “These blocks form the basis of CDRs.”

At the same time, raw data may also be collected on a gateway or other device for disaster recovery purposes, says Pedro Colaco, director of IP telephony at Unisphere Solutions. In December Unisphere announced its SRX-3000 softswitch, which is currently in beta testing. “The softswitch is the main repository for CDRs, but in case we lose information in the softswitch we’re able to recreate the records from the raw information on a gateway,” Colaco says.

In some cases, the softswitch will not store CDRs, but rather pass them in real time to a gateway. Then a mediation platform or a billing system can pull the records off at intervals.

Interoperability Issues

The format of the CDRs can vary depending on the softswitch vendor or the back-end systems. In many cases, the CDRs will be in a flat ASCII file or some kind of proprietary format. Sometimes they can even be put into AMA format, but it is generally left up to the carrier to ensure that, whatever their format, the softswitch outputs can be handled by existing mediation and billing systems.

“How softswitch CDRs are mapped into billing, especially proprietary billing systems, involves more busy work than anything right now,” Colaco says. Because the softswitches are designed to be open systems, doing that conversion to the appropriate format for a specific situation shouldn’t be that difficult, he says.

“In theory the softswitch was designed to work with anyone’s billing system and anyone’s mediation system,” Ratan says. He adds that although that might be true, in a practical sense it may be up to the mediation and billing vendors to ensure that their platforms can work well with softswitches.

Ratan also adds that the type of data a softswitch collects can be extremely granular. For example, the data can be in a transaction format, which would produce a CDR that could be billed for. But it can also produce a more general session detail record, with more about the type of information that was used or exchanged during that service. This could also include information about the actual application being utilized, making it possible to price and bill in a variety of ways. Ratan points out that no one is billing at this fine level of detail yet, but with softswitch technology it’s just a matter of time.

Data collected by a softswitch could also be used by a number of other OSS systems, such as to detect fraud or verify service level agreements.

Currently there’s no effort underway to promote interoperability among softswitches and various billing and mediation platforms. Perhaps once the basic issues surrounding the development of softswitches themselves are resolved and interoperability testing has produced positive results, then the attention will turn to the OSS side. Until then, service providers should keep their back-end systems in mind when deploying softswitches. Although this new technology holds a lot of promise for rolling out new services, providers need to be able to translate that into real revenue.