For comparison with a PBX

NEC’s PBX: EAX2400 IMX - Integrated Multimedia eXchange, model ICS IMGdxh uses a Pentium control process and the claimed^† BHCA is 25,600.
Tekelec’s softswitch^‡ "VXiTM Media Gateway Controller" claims^§a capacity which scales from 250,000 to over 1 million BHCA - a Class 5 exchange.
Lucent’s 5E-XC™ Switch High Capacity Switch - supports 4 million BHCA, 250K trunks, and 99.9999% availability [Lucent]
Frank D. Ohrtman Jr. says that a Class 4 Softswitch should handle 800,000 BHCA, support 100,000 DS0s (i.e., 100K 64 bps channels), with a reliability of 99.999%, and MOS of 4.0 (i.e., high quality voice)[Ohrtman 2002].
- His pricing data shows that softswitches are about 1/4 the price per DS0 of Class 4 exchanges (e.g., Nortel DMS250 and Lucent 4ESS vs. Convergent Networks’s ICS2000 and SONUS GSX9000) -- additionally the softswitches are physically much smaller.
- Many claim that softswitch and VoIP reliability already exceeds that of central office exchanges; because with VoIP it is cheaper to implement redundancy and easier to build physically distributed systems; plus more features {sooner}, while also providing potentially better quality (i.e., better than "toll" quality)!

Radcom’s MegaSIP test software generates 3,500,000 BHCA calls per server.

^† Was available from http://www.stfi.com/STF_part3e.html

^‡ "A softswitch is the intelligence in a network that coordinates call control, signaling, and features that make a call across a network or multiple networks possible."[Ohrtman 2002]

§ Was available from http://www.tekelec.com/productportfolio/vximediagatewaycontroller/

Slide Notes

Lucent, 5ESS Switch High Capacity Switching Applications, 5E-XCi v1, Sept. 2003 http://www.lucent.com/livelink/090094038004f536_Brochure_datasheet.pdf Links to an external site.

Frank D. Ohrtman Jr., Softswitch: Architecture< for VoIP, McGraw-Hill Professional, 2002, ISBN: 0071409777.

Radcom, MegaSIP data sheet, Bristol, England was available from http://www.radcom.com/radcom/test/pdf/ds_pa_megasip.pdf Links to an external site.

Transcript

[slide521] In fact, if we compare it to a typical reasonably sized switch like NEC's PBX, it only supported 25,600 call hours attempts. This is a device built to be a PBX in a small business. If we look at Lucent's 5E switch, this is a switch that's designed for a large municipality. It can support 4 million busy hour call attempts. That's enough for 250,000 trunks. And then we go up to class 4 switches. Class 4 switches are the interconnect switches between class 5 switches. And they could now support in that neighborhood nearly a million hours, very high reliability, high voice score. But the fascinating thing is that with these PC class machines, things that you could run in a rack in a cloud, you're getting performance comparable to the very, very top PBXs and switches, but at a very different price point. But what turned out to be one of the difficulties, what actually turned out to be hard to test these systems, because there were no test equipment around that could generate calls into the system fast enough to challenge the performance once you started to get to large numbers of servers. That's really an interesting area. When you start to get beyond your test instruments, how can you ensure it's going to behave? So there's actually a thesis done by a student who tries to look at how do you manage to place a call load on the home subscriber server in an IMS system or a 3G network at extremely high loads. It turns out there are actually no commercially available traffic generators that would generate enough load. So he had to go to cloud-based systems running open loop to generate sufficient loads that they would start to see problems in the performance of the home subscriber server. This is for a commercial one at Ericsson. And the fascinating thing is he couldn't even check all of the responses to each of these session setups, because he didn't have enough processing capacity. But the cool thing is the fact that since the switch doesn't know which one of these I'm monitoring, I only need to statistically look at the answers I'm getting back as long as I'm providing lots of load on it. Because then I just look at 10% or 1% or whatever the responses is. If they're correct, then the system's behaving. And so he was able to produce a system that scaled up to extremely high loads.