|By Esmeralda Swartz||
|October 7, 2013 09:45 AM EDT||
In just a few short recent years the idea of software-defined networks (SDN) has moved from a theoretical academic concept to a real-life practical proposition for making the world's telecommunications networks more efficient, cost-effective, easier to manage and resilient. The SDN concept really started to take shape around 2008 , Google and Facebook have already implemented important features of SDN in their own networks. Now most major carriers are planning to move in the SDN direction, for example Deutsche Telekom [2, 3] and more recently AT&T  to reduce high operational costs while the over-the-top providers (e.g., Google, Amazon, etc.) impede the carriers' ability to grow their revenues.
Put simply, the SDN idea is to separate out the control functions of the network into a cloud-like management layer leaving network elements in a data-forwarding layer. This means the smart component of networks can be made more efficient and less expensive by making use of the concepts of abstraction, modularity and virtualization that are already common in the IT world. At the same time the basic network building blocks - essentially the bit-carrying hardware - can be less expensive because they will become simpler and dumber.
SDN is a great example of what we now call "cloud" computing: it illustrates that "cloud" is not just a vague bundle of computers and storage in the sky. We are moving towards the evolution of multiple special-purpose clouds, some with a very specific purpose aimed at the needs of a rather specialist user group. SDN will create exactly that.
SDN is another step forward in the ongoing process of turning traditional concepts inside out as we design rational new large-scale architectures that will deliver order-of-magnitude improvements in performance and cost-effectiveness.
I like to keep tabs on what's going on in the communications industry as these customers have been a proving ground for many new billing and compensation concepts we've implemented and deployed in the MetraTech platform. Comms was where we learned to handle millions of chargeable transactions per day. Comms was the sector that led the way in setting the challenge of slicing and dicing those millions of charges across complex multi-dimensional enterprise hierarchies. Comms insisted on being able to implement and bill for new services rather quickly - in minutes rather than weeks and months, please. Today we enjoy having communications companies as customers, but we serve enterprises across many other industries including financial services, cloud, transportation and concessions. Those other companies have benefited from the groundbreaking work in comms, which inevitably proves useful for other sectors before too long.
So people in all industries should be interested in what the communications industry are doing in SDN today, because those concepts, one way or another will ripple through to other industries too: finance, insurance, transportation, etc.
One of the cool things about the SDN revolution is that everyone seems to be on board already: everyone is going to be an early adopter, carriers and vendors too. Why so? Because everyone has realized already that traditional networks are running out of steam. It's not just traffic volumes that will become unmanageable with existing network architectures, but the increasing volatility in traffic patterns, driven by new apps, new business models, and the rapid rise (and sometimes decline) of new service providers.
The concept is evolving fast; the practicalities of making this work are now well understood. What's missing? No surprise here, as there is a pattern in the evolution of technology concepts that follows these steps: bright idea; architecture; technology building blocks; implementation plan; oops how do we charge for all this? Who will keep track? The end user gets the tangible benefits such as bandwidth on-demand made possible with SDN. While it is true that SDN is mostly under the covers (network level) and doesn't touch the user directly, it is key to delivering the end-to-end customer experience. In order to take advantage of the flexibility and manageability of SDN networks, the operational and billing support systems must be as flexible in how they manage and bill for services.
I've written before about how monetization is so often an afterthought in the process of technology innovation. We can moan about this, but it won't change the nature of the super-smart people caught up in the excitement of making all this stuff work. At MetraTech, we don't complain, because we have already taken this all-too-human characteristic into account. If you can define a billable event, and capture it, we can bill for it. Whatever it is.
SDN will open the portals to create network-borne services and bundles of services that in some cases no one has even thought of yet. It will also enable service mash-ups with multiple vendor contributions that must be tracked no matter how many or how small. It also raises the traditional telco concept of "interconnection" to an order of magnitude greater level of complexity. Those carriers who go down the SDN route early will need a billing and compensation system that is just as flexible, versatile and capable as the SDN architecture itself. It's going to be tough to re-purpose a traditional telecom, interconnect, or Internet services billing system to handle these new requirements.
What carriers will need is a truly service-agnostic system that can flexibly bill for any event that can be captured. Did I mention that MetraNet can already do this and that we've proven it across vertical industries? In Part 2 we'll explore Network Function Virtualization (NFV).