There was a healthy debate regarding the specification of interfaces to the different elements in the MRF – the MRFP and MRFC (both within 3GPP and externally), but there was also a parallel debate concerning the architecture. One camp largely favoured the use of commodity hardware for software-based media processing, while another pushed specialist hardware platforms, optimised for different codecs.

At the time, the specialist platforms seemed to be winning but it seems that, today, software-based deployments are beginning to catch up. Indeed, that seems to be the case with many of the products with which we have been involved over the years. For example, SS7 control has moved into media gateway controllers that are software-based applications, enabled by IP connectivity and SIGTRAN, whereas just a few years ago SS7 interface cards were dominant. While there is still a need for specialist SS7 line cards, increasingly these have been replaced by IP connections with the core SS7 messaging being transported in SIGTRAN wrappers. Of course, SS7 will itself be replaced – by software based Diameter platforms, in many cases running on commodity hardware.

SDPs are also morphing into various software elements, deployed on COTS technologies. Many IMS and OSS elements have gone the same way. We now talk routinely about IMS, RCS and SDP in the cloud – an idea that attracted derision when we raised it at a conference just three years ago. The list goes on.

Which brings us nicely to SDN, a key initiative that virtualises network functions and leverages general purpose computing platforms. Software Defined Networking has attracted significant interest in the last year or so. This is not the place to review SDN in general, but rather to comment on a number of aspects that we think are of interest.

Although SDN has become another buzzword, it’s been an evolving topic for some time. Spearheaded by vendors in the cloud communications arena, traditional telecoms vendors are now positioning around SDN and its applicability for telecoms networks. We met Beau Atwater from Ericsson at the TMW and he provided an update on Ericsson’s “Service Provider SDN” plans, which were also extensively covered at BWF and MWC in recent months.

According to Beau, quite apart from better, more efficient use of network resources, a service provider SDN enables several new opportunities. For example, by moving security deeper into the cloud, service providers can offer security capabilities to manage inventory, service activation and authentication – both for themselves and for others.

This isn’t a new idea – we’ve heard various discussions on the same theme for a number of years – but perhaps it’s now more realistic to imagine how a (network) service provider can take advantage of more efficient network management to introduce such capabilities with the advent of SDN. A central theme of the last couple of years has been that of how service providers can more efficiently leverage their assets, particularly via API exposure to third parties: maybe SDN can show how to achieve this rather than basing such projections on conjecture.

We identified a number of capabilities that could be defined as assets in presentations we made a couple of years ago: network access, voice, QoS / policy, payment and trust. Some capabilities that have been identified as having value, such as location and messaging have become devalued in recent years, thanks to the emergence of alternative providers, which illustrates how rapidly things can change. Others, such as voice, continue to have value eroded through the rise of cloud based voice providers, but there is still value to be found if approached correctly.

Trust could be one such. We could take trust to be synonymous with security here – it’s not too much of a stretch. Security remains a critical issue, particularly in enterprises being flooded with a plethora of new devices and applications. Leveraging more efficient network provisioning and capacity management to deliver QoS and, hence, policies is also a promising area (although it’s not moving as rapidly as we thought it might, despite some encouraging signs from interviews we have conducted).

If Ericsson et al are right, then network service provider SDNs can also help accelerate delivery of these kinds of capabilities in addition to the other benefits that are the main focus of SDN initiatives - which would be very interesting indeed. It may just solidify some of the conjecture around the future role of the network service provider into some solid business models.

Trust has been talked about for years as a sort of vague concept: “users trust their traditional service providers” is an assertion we have heard repeated, time and time again with no solid evidence to support it. For this reason, we never really bought into that, at least not from the perspective of the consumer – we choose service providers for a variety of reasons, but trust never seems to be uppermost in the minds of consumers, at least not in our experience; they are simply choosing the best fit from them from a relatively limited set of options.

But if SDNs can help network service providers to enable better security and actually offer higher degrees of protection than are available elsewhere, then that may well have three direct effects. First, consumers might actually start to think in terms of trust as an attribute to be considered when choosing a provider, the effect of which would be to increase stickiness. That’s rather a long shot, in our opinion, but there may also be consumer services where security becomes more and more important – family protection, digital vaults and so on. Why should BT be more trusted than Apple, for example? Or vice versa – there seems to be no particular reason today, but perhaps there might be tomorrow.

But secondly and more interestingly, enterprises may pay a premium for richer security and authentication services federated and managed by their service providers (which could reduce the increasing costs associated with managing diverse platform and device ecosystems) and, thirdly, OTT players might seek to leverage security capabilities offered by network providers instead of investing in their own.

It’s quite a long way from early initiatives in SDN architectures to reach such a position, but the history of migration towards software based network elements suggests it’s not going to be long before SDN becomes commonplace. The question is really whether network operators will be able to leverage such capabilities and capture value from new propositions before the potential value in doing so is eroded by their competitors elsewhere.