I came across this article on Acme Packet today where Seamus Horihan was defending the SBC as a stand-alone network element commenting: "If you look at the history of communications equipment, while many people have pursued [multi-function, all-in-one] 'God' boxes, none were ever bought or delivered," he said.
I completely agree with Seamus - every IMS operator I have spoken with, and most of the major vendors, are using independant, integrated SBC's in their network. In fact almost all of them are using Acme - independant of who their core provider was (NSN, Ericsson, ALU, etc.). So it seems the SBC's have made a strong foothold in these arly IMS.
However, I found the 'God' box comment interesting - if anything SBC's are becomming 'God' boxes of IMS, encompassing many functions including the A-BGF, C-BGF, I-BGF, IBCF, IWF, P-CSCF, I-CSCF, SEG, PDF/SPDF, and or RACF in many cases. Most SBC vendors offer a distributed SBC architecure that breaks these functions out, but it seems most operators are choosing an integrated approach in these early stages of real deployments.
From a quality perspective this makes implementation easy - fewer components and interfaces means there is less you have to test (see my post on Why Test if I have a SBC from last week for more info on SBC testing). Verifying the configuration of one device is easier than verifying the configurations of 5. But is also means less flexibility for later and more trust in your SBC vendor and system integrator. It is difficult to peer inside the inner workings of the SBC to see what it is really doing, which is fine until something goes wrong. Time will tell how scalable this approach is.
Comments