Mobile video monetization: the need for a mediation layer

Extracted from my latest report, mobile video monetization 2015. 

[...] What is clear from my perspective, is that the stabilization of the value chain for monetizing video  content in mobile networks is unlikely to happen quickly without an interconnect / mediation layer. OTT and content providers are increasingly collaborating, when it comes to enabling connections and to zero rate data traffic; but monetization plays involving advertising, sponsoring, price comparison, recommendation, geo-localized segmented offering, is really in its infancy.

Publishers are increasing their inventory, announcers are targeting mobile screens, but network operators still have no idea how to enable this model in a scalable manner, presumably because many OTT whose model is ad-dependant are not willing yet to share that revenue without a well-defined value.

Intuitively, there are many elements that today reside in an operator’s network that would enrich and raise the value of ad models in in a mobile environment. Whether performance or impression driven, advertising relies on contextualization for engagement. A large part of that context could/should be whether the user is on wifi, on cellular network, whether he’s at home, work or in transit, whether he is a prepaid or postpaid subscriber, how much data or messaging is left in  its monthly allotment, whether the cell he is in is congested, or whether he is experiencing impairments because he is far from the antenna or because he is being throttled because he is close to the end of his quota,  whether he is roaming or in his home network… The list goes on and on in term of data points that can enrich or prevent a successful engagement in a mobile environment.

On the network front, understanding whether a content is an ad or not, whether it is sponsored or not, whether it is performance or impression-measured, whether it can be modified, replaced or removed at all from a delivery would be tremendously important to categorize and manage traffic accurately.

Of course, part of the problem is that no announcer, content provider, aggregator or publisher want to have to cut deals with the 600+ mobile network operators and the 800+ MVNO  individually if they do not have to.

Since there is no standard API to really exchange these data in a meaningful, yet anonymized fashion, the burden resides on the parties to, on a case by case basis, create the basis for this interaction, from a technical and commercial standpoint. This is not scalable and won’t work fast enough for the market to develop meaningfully.

This is not the first time a similar problem occurred in mobile networks, and whether about data network or messaging interconnection, roaming, or inter-network settlements, IPX and interconnect companies have emerged to facilitate the pain of mediating traffic, settlements between networks.

There is no reason that a similar model shouldn’t work for connecting mobile networks, announcers and OTT providers in a meaningful clearing house type of partnership. There is no technical limitation here, it just needs a transactional engine separating control plane from data plane integrated with ad networks, IPX and  a meaningful API to  carry on the control plane subscriber together with session information both ways (from the network to the content provider and vice versa). Companies who could make this happen could be traditional IPX providers such as Syniverse, but it is more likely that company with more advertising DNA such as Opera, Amazon or Google would be better bets. [...]

NFV world congress: thoughts on OPNFV and MANO

I am this week in sunny San Jose, California at the NFV World Congress where I will chair Thursday the stream on Policy and orchestration - NFV management.
My latest views on SDN / NFV implementation in wireless networks are published here.

The show started today with a mini-summit on OPNFV, looking at the organization's mission, roadmap and contribution to date.

The workshop was well-attended, with over 250 seats occupied and a good number of people standing in the back. On the purpose of OPNFV, it feels that the organization is still trying to find its mark a little bit, hesitating between being a transmission belt between ETSI NFV and open source implementation projects and graduating to a prescriptive set of blueprints for NFV implementations in wireless networks.

If you have trouble following, you are not the only one. I am quite confused myself. I thought OpenStack had a mandate to create source code for managing cloud network infrastructure and that NFV was looking at managing service in a virtualized fashion, which could sit on premises, clouds and hybrid environments. While NFV does not produce code, why do we need OPNFV for that?

Admittedly, the organization is not necessarily deterministic in its roadmap, but rather works on what its members feel is needed. As a result, it has decided that its first release, code-named ARNO will be supporting KVM as hypervisor environment and will feature an OpenStack architecture underpinned by an OpenDaylight-based SDN controller. ARNO should be released "this spring" and is limited in its scope as a first attempt to provide an example of a carrier-grade ETSI NFV-based source code for managing a SDN infrastructure. Right now, ARNO is focused on VIM (Virtual Infrastructure Management), and since the full MANO is not yet standardized and it is felt it is too big a chunk to look at for a first release, it will be part of a later requirement phase. The organization is advocating pushing requirements and bug resolution upstream (read to other open source communities) to make the whole SDN / NFV more "carrier-grade".

This is where, in my mind the reasoning breaks down. There is a contradiction in terms and intent here. On one hand, OPNFV advocates that there should not be separate branches within implementation projects such as OpenStack for instance for carrier specific requirements. Carrier-grade being the generic analogy to describe high availability, scalability and high performance. The rationale is that it could be beneficial to the whole OpenStack ecosystem. On the other hand, OPNFV seems to have been created to implement and test primarily NFV-based code for carrier environment. Why do we need OPNFV at all if we can push these requirements within OpenStack and ETSI NFV? The organization feels more like an attempt to supplement or even replace ETSI NFV by an opensource collaborative project that would be out of ETSI's hands.

More importantly, if you have been to OpenStack meeting, you know that you are probably twice as likely to meet people from the banking, insurance, media, automotive industry as from the telecommunications space. I have no doubt that theoretically, everyone would like more availability, scalability, performance, but practically, the specific needs of each enterprise segment rarely means they are willing to pay for over-engineered networks. Telco carrier-grade was born from regulatory pressure to provide a public infrastructure service, many enterprises wouldn't know what to do with the complications and constraints arising from these.

As a result, I personally have doubts for the success of the Telcos and forums such as OPNFV to influence larger groups such as OpenStack to deliver a "carrier-grade" architecture and implementation. I think that Telco operators and vendors are a little confused by open source. They essentially treat it as a standard, submitting change requests, requirements, gap analysis while not enough is done (by the operators community at least) to actually get their hands dirty and code. The examples of AT&T, Telefonica, Telecom Italia and some others are not in my mind reflective of the industry at large.

If ETSI were more effective, service orchestration in MANO would be the first agenda item, and plumbing such as VIM would be delegated to more advanced groups such as OpenStack. If a network has to become truly elastic, programmable, self reliant and agile, in a multi vendor environment, then MANO is the brain and it has to be defined and implemented by the operators themselves. Otherwise, we will see Huawei, Nokialcatelucent, Ericsson, HP and others become effectively the app store of the networks (last I checked, it did not work very well for operators when Apple and Android took control of that value chain...). Vendors have no real incentive to make orchestration open and to fulfill the vendor agnostic vision of NFV.