More and more these days, talking about softswitches means talking about what you might call an ecosystem. You're talking about ecology of public converged networks, where there are lots of gateways into the central cloud, mostly via small, edge-oriented boxes that are controlled by that mysterious entity, the softswitch (see What Makes a Softswitch a Softswitch).
Conceding that the boundaries are fuzzy, vendors inside this ecosystem have largely agreed on an overarching architecture to explain how all of these pieces fit together.
This architecture is three tiered. At the bottom, there's transport. Lots of gateways converting between TDM and packets. In the middle, there's a control plane for routing calls through the transport layer. Up top, there are all those enhanced service platforms, supporting the offerings that are tasked with pulling CLECs out of the dot-com dumpster. The top tier, in other words, is an application layer -- potentially a layer populated by a lot of different boxes, some running application building blocks like media services (so that you can separate voice resources from the applications themselves), and others running boxes that monitor and enforce business rules for corporate accounts, and so on.
In this architecture, it's the middle layer that's the softswitch. The ideal softswitch uses standard, open protocols for communications between the layers. Perhaps somewhat surprisingly, there's a consensus about what those protocols should be. For talking to upper-layer applications, SIP seems to be the protocol that everyone agrees a softswitch has to support. There's also SIP-T for communication with other softswitches. For controlling gateways, H.323 may be required for "legacy" IP telephony, but the future belongs to MGCP (and the Megaco that's destined to replace it). The layers are thus separated at well-documented boundaries, except (there's always an exception) for some vendors, who prefer to see the softswitch and the apps as one layer.
If the boundaries start to get blurry here, there's a good reason for it. It's because most vendors want to leave some room to wiggle between those customers who want to build networks from scratch and those customers who cling to large parts of their huge, costly, and still remarkably effective circuit-switched architecture. In the latter case, a softswitch is what gets us started with forward-looking use of converged networks.
Internet Offload
The first and most practical use of a softswitch is simply to prevent modem calls to the local ISP from tying up ports on the local exchange switches. If you consider that the typical Class 5 switch was designed with average call duration of two minutes in mind, and you consider that the typical dialup user is barely past "You've got mail" at the two-minute mark, you can see the problem. A Lucent white paper pegs Internet calls at an average of 30 to 35 minutes.
To date, it's in this arena where most of the softswitch action has been. Use a softswitch to reroute PRI traffic before it reaches a Class 5 and you free up 18% of your ports, according to Lucent. But Internet offload is a market with limited long-term growth potential, at least if broadband Internet access is going anywhere. Dialup access will peak over the next couple of years, then will inevitably level off for several years as new dialup users are offset by those migrating to cable and DSL.
Tandem Bypass
Dan Manglesdorf, vice president of carrier VoIP at Nortel, says tandem bypass answers the question: "What do we do when we max out a Class 4 trunking switch?" And that answer is to front-end the switch with a softswitch that culls traffic off the circuit-switched trunks and onto IP or ATM networks.
"Imagine 30 end-office, Class 5 switches," says Manglesdorf, "that have inter-machine trunks creating a big mesh -- each switch connected to each switch. Then there are some tandem overflow switches that each of the switches are connected to as well, so that if no direct inter-machine trunk is available say from switch 1 to switch 12, traffic will take an alternate path to the tandem switch and from there to switch 12. We were dealing with one carrier that was reaching exhaust on a tandem switch and so they bought a 112,000-port tandem switch to add incremental capacity, but they really only gained about 20,000 ports, because the remaining ports had to be used to interconnect it to the remaining mesh. It's just not efficient to keep adding circuit switches. That's the advantage of moving to a packet infrastructure - we create virtual paths when we need them."
There's a savings in capital costs here, but "the primary driver," notes Manglesdorf, "is actually operational savings. That's because in a circuit environment, we need network engineers to create the trunk groups that they set up between the different switches, to engineer and monitor the amount of traffic going over these fixed trunk groups, and to plan when new trunks need to be added. If you take a hundred Class 5 switches and interconnect them to the mesh, you wind up with 9,900 trunk groups. But if you were to take those hundred switches and use an ATM cloud and a gateway between the cloud and each of the 100 switches, you can do it with 99 trunk groups. It's just a much simpler environment and consequently, there's a great operational savings."
Offloading and replacing tandem switches requires Class 4 functionality, which is to say that it requires a considerably smaller feature set than a Class 5 switch, and is therefore a more manageable and verifiable development project.
Class 5 Replacement
Replacing the large, somewhat nebulous, and decidedly quirky feature sets found at end-office switches may be a good deal trickier than replacing Class 4 functionality, but there are very compelling economic incentives to do so. This is in part because end-office equipment is, as the name suggests, at the outer perimeter of carrier equipment and there is, therefore, exponentially more of it. Tom DeCanio, Taqua's product manager, puts it succinctly: "Everybody knows the golden goose is Class 5."
It's easy to see the advantages of a softswitch scenario over, say, a Nortel DMS-100. A Class 5 fits into the form factor of a semi truck trailer; a concentrated and converged solution like Taqua's fits on a single rack with room to spare (indeed, you can get something on the order of 25,000 ports onto that rack). A DMS-100 is heavy enough to require additional girders in plenty of buildings you might want to house one in, plus 600-amp power service in a world of 200-amp feeds. A highly detailed Aberdeen Group white paper (available at Taqua's website and highly recommended) estimates that deploying the DMS-100 costs $14 million more than Taqua's offering, based on a scenario in which a CLEC has one hub city and seven tertiary markets.
