Regular readers of our little blog know one thing… Well, OK maybe two things, I guess. First, they realize that there is one author that – unlike the other, more professional, contributors – tends to write rather primitively in run-on sentences which can only be described as a ‘stream-of-consciousness’ that reeks of the interior monologue of an individual who is desperately searching for direction and something significant to say while blatantly padding-out a post and… errr… where was I, again?
Anyway. The second - more important – thing they recognize is that we, here at #KYSBCS, are massive believers in the work of an ETSI Industry Specification Group (ISG) initiative called Network Functions Virtualization, or NFV for short. The above-mentioned readers will already know that this group, original initiated by the carrier community, is charged with creating a user manual, of sorts, that will clearly describe how networks of the future should be built.
Within its charter, the NFV ISG paints a picture of a world where commercial-off-the shelf (COTS) hardware is used to build a resource layer of virtualized network functions that slash capex and opex expenses while reducing time-to-market and adapting more readily and rapidly to service demands. The NFV initiative levels the technology vendor playing field while enabling – no; ‘igniting’ – what more astute industry commentators recognize as the rise of the Software Telco.
That’s why we are passionate about the session border controller as a software element, rather than a proprietary piece of hardware that restricts performance, limits innovation and ultimately increases costs. Hard though it is for us, here, to believe, though, there is more to next-generation wireline and wireless carrier infrastructures than the mighty SBC. Indeed, once our little function has worked its magic and performed its good deeds, call control messages in the form of the Session Initiation Protocol (SIP) make their way northbound into the carrier’s core signaling network – an infrastructure that should be comprised of elements described in the ETSI and 3GPP’s IP multimedia Subsystem (IMS) suite of standards. But while the IMS foundation was laid in these standards bodies a decade ago, the cost and complexity of implementing the many associated functions has limited its adoption, to date. And although IMS promotes openness, a few big vendors generally dominate the space.
At the heart of the IMS core is the call session control function (CSCF). Or perhaps because a call is always a session; but a session is not always a call: C/SCF. Either way, there are three of these entities in the signaling path: The Proxy, Interrogating and Serving CSCF (or P-CSCF, I-CSCF and S-CSCF, respectively). When all said and done, we can also lump in the breakout gateway control function (BGCF) along with elements of a home subscriber server (HSS) and telephony application server (TAS).
Obviously, the previous paragraph was just a thinly veiled attempt to increase the Google keyword rankings for this blog and if you want to know what any of it means, you’ll have to consult the wealth of existing resources that cover this broad topic. That said, before we move on, there is one more thing we would like to say on the subject of search engine optimization: Kim Kardashian.
Now, it would appear that the ETSI NFV ISG has IMS on their minds almost as much as we have K-I-M on ours. Indeed, one of the six (number 1 of the 6, in fact) use cases they have initially outlined is the “Virtualization of Mobile Core Network Nodes (including IMS)“. This is why we – and by initial reactions many others in the industry – are excited to learn about an open source venture called Project Clearwater.
Project Clearwater is an open source implementation of IMS core components that is designed for massively scalable deployments within virtualized cloud computing environments that are capable of delivering voice, video and messaging services to millions of users. Clearwater combines the economics of over-the-top (OTT) style service platforms with the standards compliance expected of classic telco-grade solutions. According to the technical blurb, Clearwater leans heavily on established design patterns for building and deploying massively scalable web applications, adapting these design patterns to fit the constraints of SIP and IMS. We dig.
The Clearwater Architecture (Courtesy of the Project Clearwater Community)
We, for one, are hoping that the software developer community embraces Project Clearwater as a foundation for delivering IMS core components and as a platform for enabling VoIP services that include the key supplemental services defined in ITU-T MMTel and GSMA VoLTE specification IR-92. Naturally, we are a little biased and do recommend that network architects forego the P-CSCF component of Clearwater for an integrated SBC function. But that’s the whole point, isn’t it: A choice, as interworking experts define their application service chains. A chain without an anchor. Now that’s what we call plain sailing.
Learn more at www.projectclearwater.org