Tuesday, September 30, 2014

NFV & SDN 2014: Executive Summary

This Post is extracted from my report published October 1, 2014. 

Cloud and Software Defined Networking have been technologies explored successively in academia, IT and enterprise since 2011 and the creation of the Open Networking Foundation. 
They were mostly subjects of interest relegated to science projects in wireless networks until, in the fall of 2013, a collective of 13 mobile network operators co-authored a white paper on Network Functions Virtualization. This white paper became a manifesto and catalyst for the wireless community and was seminal to the creation of the eponymous ETSI Industry Standardization Group. 
Almost simultaneously, AT&T announced the creation of a new network architectural vision – Domain 2.0, heavily relying on SDN and NFV as building blocks for its next generation mobile network.

Today, SDN and NFV are hot topics in the industry and many companies have started to position themselves with announcements, trials, products and solutions.

 This report is the result of hundreds of interviews, briefings and meetings with many operators and vendors active in this field. In the process, I have attended, participated, chaired various events such as OpenStack, ETSI NFV ISG, SDN & OpenFlow World Congress and became a member at ETSI, OpenStack and TM Forum.
The Open Network Foundation, the Linux Foundation, OpenStack, the OpenDaylight project, IEEE, ETSI, the TM Forum are just a few of the organizations who are involved in the definition, standardization or facilitation of cloud, SDN and NFV. This report provides a view on the different organizations contribution and their progress to date.

Unfortunately, there is no such thing as SDN-NFV today. These are technologies that have overlaps and similarities but stand apart widely. Software Defined Network is about managing network resources. It is an abstraction that allows the definition and management of IP networks in a new fashion. It separates data from control plane and allows network resources to be orchestrated and used across applications independently of their physical location. SDN exhibits a level of maturity through a variety of contributions to its leading open-source contribution community, OpenStack. In its ninth release, the architectural framework is well suited for abstracting cloud resources, but is dominated by enterprise and general IT interests, with little in term of focus and applicability for wireless networks.

Network Function Virtualization is about managing services. It allows the breaking down and instantiation of software elements into virtualized entities that can be invoked, assembled, linked and managed to create dynamic services. NFV, by contrast, through its ETSI standardization group is focused exclusively on wireless networks but, in the process to release its first standard is still very incomplete in its architecture, interfaces and implementation.

SDN can or not comprise NFV elements and NFV can or not be governed or architected using SDN. Many of the Proof of Concepts (PoC) examined in this document are attempting to map SDN architecture and NFV functions in the hope to bridge the gap. Both frameworks can be complementary, but they are both suffering from growing pains and a diverging set of objectives.

The intent is to paint a picture of the state of SDN and NFV implementations in mobile networks. This report describes what has been trialed, deployed in labs, deployed commercially, what are the elements that are likely to be virtualized first, what are the timeframes, what are the strategies and the main players.

Tuesday, September 9, 2014

SDN & NFV part VI: Operators, dirty your MANO!

While NFV in ETSI was initially started by network operators in their founding manifesto, in many instances, we see that although there is a strong desire to force telecoms appliance commoditization, there is little appetite by the operators to perform the sophisticated integration necessary for these new systems to work.

This is, for instance, reflected in MANO, where operators seem to have put back the onus on vendors to lead the effort. 

Some operators (Telefonica, AT&T, NTT…) seem to invest resources not only in monitoring the process but also in actual development of the technology, but by and large, according to my study,  MNOs seem to have taken a passenger seat to NFV implementations efforts. Many vendors note that MNOs tend to have a very hands off approach towards the PoCs they "participate" in, offering guidance, requirements or in some cases, just lending their name to the effort without "getting their hands dirty".

The Orchestrator’s task in NFV is to integrate with OSS/BSS and to manage the lifecycle of the VNFs and NFVI elements. 

It onboards new network services and VNFs and it performs service chaining in the sense that it decides through which VNF, in what order must the traffic go through according to routing rules and templates. 

These routing rules are called forwarding graphs. Additionally, the Orchestrator performs policy management between VNFs. Since all VNFs are proprietary, integrating them within a framework that allows their components to interact is a huge undertaking. MANO is probably the part of the specification that is the least mature today and requires the most work.

Since it is the brain of the framework, failure of MANO to reach a level of maturity enabling consensus between the participants of the ISG will inevitably relegate NFV to vertical implementations. This could lead to a network with a collection of vertically virtualized elements, each having their own MANO, or very high level API abstractions, reducing considerably overall system elasticity and programmability. SDN OpenStack-based models can be used for MANO orchestration of resources (Virtualized Infrastructure Manager) but offer little applicability in the pure orchestration and VNF management field beyond the simplest IP routing tasks.

Operators who are serious about NFV in wireless networks should seriously consider develop their own orchestrator or at the minimum implement strict orchestration guidelines. They could force vendors to adopt a minimum set of VNF abstraction templates for service chaining and policy management.

Wednesday, September 3, 2014

Strategies for multiscreen monetization

Pay TV and OTT providers are increasingly difficult to tell apart. Both are engaged in a battle to capture retain our interest. Many multiscreen strategies are being enacted on both sides to secure this $400 billion market.

Cord cutting, cord shaving are becoming familiar risks for MSOs as viewers’ habits change from scheduled to on demand and from linear to binge watching .

MSOs are hesitating between becoming OTT, partnering with them or embracing multiscreen, while OTT are experimenting with new charging models and are trying to secure exclusive rights for original programming.

These strategies and more are being analyzed in my latest white paper, co-written with Booxmedia.

As large OTT providers are helping consumer-viewing habits evolve, there are great opportunities for MSOs and content providers to offer OTT and multiscreen services that will strengthen their brand, expand their reach and grow their customer base.

Cloud TV everywhere emerges as one of the most successful strategies to date for customer acquisition, retention and monetization.  Robust recommendation, content discovery and ad management are keys for monetization of multiscreen.