June 2024 Open RAN requirements from Vodafone, Telefonica, Deutsche Telekom, Tim and Orange

 As is now customary, the "big 5" European operators behind open RAN release their updated requirements to the market, indicating to vendors where they should direct their roadmaps to have the most chances to be selected in these networks.

As per previous iterations, I find it useful to compare and contrast the unanimous and highest priority requirements as indications of market maturity and directions. Here is my read on this year's release:

Scenarios:

As per last year, the big 5 unanimously require support for O-RU and vDU/CU with open front haul interface on site for macro deployments. This indicates that although the desire is to move to a disaggregated implementation, with vDU / CU potentially moving to the edge or the cloud, all the operators are not fully ready for these scenario and prioritize first a deployment like for like of a traditional gnodeB with a disaggregated virtualized version, but all at the cell site. 

Moving to the high priority scenarios requested by a majority of operators, vDU/vCU in a remote site with O-RU on site makes its appearance, together for RAN sharing. Both MORAN and MOCN scenarios are desirable, the former with shared O-RU and dedicated vDU/vCU and the latter with shared O-RU, vDU and optionally vCU. In all cases, RAN sharing management interface is to be implemented to allow host and guest operators to manage their RAN resource independently.

Additional high priority requirements are the support for indoor and outdoor small cells. Indoor sharing O-RU and vDU/vCU in multi operator environments, outdoors with single operator with O-RU and vDU either co-located on site or fully integrated with Higher Layer Split. The last high priority requirement is for 2G /3G support, without indication of architecture.

Security:

The security requirements are sensibly the same as last year, freely adopting 3GPP requirements for Open RAN. The polemic around Open RAN's level of security compared to other cloud virtualized applications or traditional RAN architecture has been put to bed. Most realize that open interfaces inherently open more attack surfaces, but this is not specific to Open RAN, every cloud based architecture has the same drawback. Security by design goes a long way towards alleviating these concerns and proper no trust architecture can in many cases provide a higher security posture than legacy implementations. In this case, extensive use of IPSec, TLS 1.3, certificates at the interfaces and port levels for open front haul and management plane provide the necessary level of security, together with the mTLS interface between the RICs. The O-Cloud layer must support Linux security features, secure storage, encrypted secrets with external storage and management system.

CaaS:

As per last year, the cloud native infrastructure requirements have been refined, including Hardware Accelerator (GPU, eASIC) K8 support, Block and Object Storage for dedicated and hyper converged deployments, etc... Kubernetes infrastructure discovery, deployment, lifecycle management and cluster configuration has been further detailed. Power saving specific requirements have been added, at the Fan, CPU level with SMO driven policy and configuration and idle mode power down capabilities.

CU / DU:

CU DU interface requirements remain the same, basically the support for all open RAN interfaces (F1, HLS, X2, Xn, E1, E2, O1...). The support for both look aside and in-line accelerator architecture is also the highest priority, indicating that operators havent really reached a conclusion for a preferable architecture and are mandating both for flexibility's sake (In other words, inline acceleration hasn't convinced them that it can efficiently (cost and power) replace look aside). Fronthaul ports must support up to 200Gb by 12 x 10/25Gb combinations and mid haul up to 2 x 100Gb. Energy efficiency and consumption is to be reported for all hardware (servers, CPUs, fans, NIC cards...). Power consumption targets for D-RAN of 400Watts at 100% load for 4T4R and 500 watts for 64T64R are indicated. These targets seem optimistic and poorly indicative of current vendors capabilities in that space.

O-RU:

The radio situation is still messy and my statements from last year still mostly stand: "While all operators claim highest urgent priority for a variety of Radio Units with different form factors (2T2R, 2T4R, 4T4R, 8T8R, 32T32R, 64T64R) in a variety of bands (B1, B3, B7, B8, B20, B28B, B32B/B75B, B40, B78...) and with multi band requirements (B28B+B20+B8, B3+B1, B3+B1+B7), there is no unanimity on ANY of these. This leads vendors trying to find which configurations could satisfy enough volume to make the investments profitable in a quandary. There are hidden dependencies that are not spelled out in the requirements and this is where we see the limits of the TIP exercise. Operators cannot really at this stage select 2 or 3 new RU vendors for an open RAN deployment, which means that, in principle, they need vendors to support most, if not all of the bands and configurations they need to deploy in their respective network. Since each network is different, it is extremely difficult for a vendor to define the minimum product line up that is necessary to satisfy most of the demand. As a result, the projections for volume are low, which makes the vendors only focus on the most popular configurations. While everyone needs 4T4R or 32T32R in n78 band, having 5 vendor providing options for these configurations, with none delivering B40 or B32/B75 makes it impossible for operators to select a single vendor and for vendors to aggregate sufficient volume to create a profitable business case for open RAN." This year, there is one configuration of high priority that has unanimous support: 4T4R B3+B1. The other highest priority configurations requested by a majority of operators are 2T4R B28B+B20+B8, 4T4R B7, B3+B1, B32B+B75B, and 32T32R B78 with various power targets from 200 to 240W.

Open Front Haul:

The Front Haul interface requirements only acknowledge the introduction of Up Link enhancements for massive MIMO scenarios as they will be introduced to the 7.2.x specification, with a lower priority. This indicates that while Ericsson's proposed interface and architecture impact is being vetted, it is likely to become an optional implementation, left to the vendor's s choice until / unless credible cost / performance gains can be demonstrated.

Transport:

Optical budgets and scenarios are now introduced.

RAN features:

Final MoU positions are now proposed. Unanimous items introduced in this version revolve mostly around power consumption and efficiency counters, KPIs and mechanisms. other new requirements introduced follow 3GPP rel 16 and 17 on carrier aggregation, slicing and MIMO enhancements.

Hardware acceleration:

a new section introduced to clarify the requirements associated with L1 and L2 use of look aside and inline. The most salient requirement is for multi RAT 4G/5G simultaneous support.

Near RT RIC:

The Near Real Time RIC requirements continue to evolve and be refined. My perspective hasn't changed on the topic. and a detailed analysis can be found here. In short letting third party prescribe policies that will manipulate the DU's scheduler is anathema for most vendors in the space and, beyond the technical difficulties would go against their commercial interests. operators will have to push very hard with much commercial incentive to see xapps from 3rd party vendors being commercially deployed.

E2E use cases:

End-to-end use cases are being introduced to clarify the operators' priorities for deployments. There are many  but offer a good understanding of their priorities. Traffic steering for dynamic traffic load balancing, QoE and QoS based optimization, to optimize resource allocation based on a desired quality outcome... RAN sharing, Slice assurance, V2x, UAV, energy efficiency... this section is a laundry list of desiderata , all mostly high priority, showing here maybe that operators are getting a little unfocused on what real use cases they should focus on as an industry. As a result, it is likely that too many priorities result in no priority at all.

SMO

With over  260 requirements, SMO and non RT RIC is probably a section that is the most mature and shows a true commercial priority for the big 5 operators.

All in all, the document provides a good idea of the level of maturity of Open RAN for the the operators that have been supporting it the longest. The type of requirements, their prioritization provides a useful framework for vendors who know how to read them.

More in depth analysis of Open RAN and the main vendors in this space is available here.

FYUZ 2023 review and opinions on latest Open RAN announcements

 

Last week marked the second edition of FYUZ, the Telecom Infra Project's annual celebration of open and disaggregated networks. TIP's activity, throughout the year, provides a space for innovation and collaboration in telecoms network access, transport and core main domains. The working groups create deployment blueprints as well as implementation guidelines and documentation. The organization also federates a number of open labs, facilitating interoperability, conformance and performance testing.

I was not there are for the show's first edition, last year, but found a lot of valuable insight in this year's. I understand from casual discussion with participants that this year was a little smaller than last, probably due to the fact that the previous edition saw Meta presenting its Metaverse ready networks strategy, which attracted a lot of people outside the traditional telco realm. AT about 1200 attendees, the show felt busy without being overwhelming and the mix of main stage conference content in the morning  and breakout presentations in the afternoon left ample time for sampling the top notch food and browsing the booth. What I found very different in that show also, was how approachable and relaxed attendees were, which allowed for productive and yet casual discussions.

Even before FYUZ, the previous incarnation of the show, the TIP forum was a landmark show for vendors and operators announcing their progress on open and disaggregated networks, particularly around open RAN.

The news that came out of the show this year marked an interesting progress in the technology's implementation, and a possible transition from the trough of disillusion to a pragmatic implementation.

The first day saw big announcements from Santiago Tenorio, TIP's chairman and head of Open RAN at Vodafone. The operator announced that Open RAN's evaluation and pilots were progressing well and that it would, in its next global RFQ for RAN refresh, affecting over 125,000 cell sites see Open RAN gain at least 30% of the planned deployment. The RFQ is due to be released this year for selection in early 2024, as their contracts with existing vendors are due to expire in April 2025.

That same day, Ericsson’s head of networks, Fredrik Jejdling, confirmed the company's support of Open RAN announced earlier this year. You might have read my perspective on Ericsson's stance on Open RAN, the presentation did not change my opinion, but it is a good progress for the industry that the RAN market leader is now officially supporting the technology, albeit with some caveats.

Nokia, on their side announced a 5G Open RAN pilot with Vodafone in Italy, and another pilot successfully completed in Romania, on a cluster of Open RAN sites shared by Orange and Vodafone (MOCN).

While TIP is a traditional conduit for the big 5 European operators to enact their Open RAN strategy, this year saw an event dominated by Vodafone, with a somewhat subdued presence from Deutsche Telekom, Telefonica, Orange and TIM. Rakuten Symphony was notable by its absence, as well as Samsung.

The subsequent days saw less prominent announcements, but good representation and panel participation from Open RAN supporters and vendors. Particularly, Mavenir and Juniper networks were fairly vocal about late Open RAN joiners who do not really seem to embrace multivendor competition and open API / interfaces approach.

I was fortunate to be on a few panels, notably on the main stage to discuss RAN intelligence progress, particularly around the RICs and Apps emergence as orchestration and automation engines for the RAN.

I also presented the findings of my report on the topic, presentation below and moderated a panel on overcoming automation challenges in telecom networks with CI/CD/CT.

Open RAN technical priorities release 3

The Open RAN technical priorities release 3, was published in March 2023 by Deutsche Telekom, Orange, Telefonica, TIM and Vodafone as part of the Open RAN MoU group at the Telecom Infra Project.

A review of the mandatory, highest priority unanimous requirements shed lights on what the big 5 operators consider essential for vendors to focus on this year, and more importantly highlights how much efforts are still necessary by the industry to meet markets expectations.

Scenarios

In this section, the big 5 regard virtualized DU and CU with open Front Haul on site as a must, for Macro and indoor / outdoor small cell deployments. This indicates that 7.2.x remains the interface of choice, despite recent attempts by other vendors to change its implementation. It also shows that as a first step, at least, they are looking at deploying Open RAN in the conventional fashion, replacing traditional e/g Node  B with like-for-like O-RU, DU. CU on site. The benefits of resource pooling due to disaggregation and virtualization, enabling either CU or CU and DU to be centralized is the highest priority by the majority of operators, but not all yet. Network sharing of O-RU and vDU/CU is also a highest priority for the majority of operators.

Security

The security requirements have increased dramatically in this latest version, with the vast majority of the requirements (166 out of 180) considered highest priority by al the MoU operators. This evolution marks the effort that have been dedicated to the topic over the last 24 months. Open RAN has been openly criticized and accused of lax security and the O-RAN alliance has dedicated a working group to assess and shore up criticism in that space. My assessment is that most of the security concerns of Open RAN are either linked to virtualization / O-Cloud implementation or just mechanically a result of having more open interfaces, providing more attack surfaces. Open RAN is not inherently more or less secure than 3GPP implementation and the level of security by design necessary to satisfy the criticisms we have seen in the media is not today implemented by traditional RAN vendors either. Having said that, the requirements now spell out exhaustively the level of admission control, authentication, encryption, certification necessary for each interface, for each infrastructure block and for their implementation in a cloud native containerized environment.

O-Cloud Infrastructure (CaaS)

The O-Cloud requirements are focused on ensuring a cloud-native architecture, while allowing acceleration hardware whenever necessary. As a result, the accent is put on bare metal or IaaS implementations of Kubernetes, with FPGA, eAsic, GPU acceleration support and management. The second theme that is prevalent in O-Cloud unanimous high priority requirements is the lifecycle management features which indicate a transition from the lab to more mature commercial implementations going forward.

CU and DU requirements

First and foremost the big 5 unanimously are looking at virtualized and containerized implementations of O-CU/O-DU with both look-aside and inline acceleration (this is contradictory, but I assume either one is acceptable). The next requirements are the usual availability, scalability, and performance related requirements we find in generic legacy RAN systems. All O-RAN interfaces support are mandatory.

Interestingly, power consumption targets are now spelled out per scenario.

RU requirements

The Radio Units requirements area good illustration of the difficulty to create a commercially viable Open RAN solution at scale. While all operators claim highest urgent priority for a variety of Radio Units with different form factors (2T2R, 2T4R, 4T4R, 8T8R, 32T32R, 64T64R) in a variety of bands (B1, B3, B7, B8, B20, B28B, B32B/B75B, B40, B78...) and with multi band requirements (B28B+B20+B8, B3+B1, B3+B1+B7), there is no unanimity on ANY of these. This leads vendors trying to find which configurations could satisfy enough volume to make the investments profitable in a quandary. There are hidden dependencies that are not spelled out in the requirements and this is where we see the limits of the TIP exercise. Operators cannot really at this stage select 2 or 3 new RU vendors for an open RAN deployment, which means that, in principle, they need vendors to support most, if not all of the bands and configurations they need to deploy in their respective network. Since each network is different, it is extremely difficult for a vendor to define the minimum product line up that is necessary to satisfy most of the demand. As a result, the projections for volume are low, which makes the vendors only focus on the most popular configurations. While everyone needs 4T4R or 32T32R in n78 band, having 5 vendor providing options for these configurations, with none delivering B40 or B32/B75 makes it impossible for operators to select a single vendor and for vendors to aggregate sufficient volume to create a profitable business case for open RAN.

The other RU related requirements helpfully spell out the power consumption, volume and weight targets for each type of configuration.

Open Front Haul requirements

There are no changes in the release 3, which shows the maturity of the interface implementation.

RAN features

The RAN features of the highest priority unanimously required by the big 5 operators remain mostly unchanged and emphasize the need for multi connectivity. Dual connectivity between 4G and 5G is essential for any western european operator to contemplate mass deployment of open RAN or replacement of their Chinese RAN vendor. The complexity does not stop to the support of the connectivity, but also necessitate advanced features such as Dynamic Spectrum Sharing (DSS) and Carrier Aggregation (CA) which is a complexity multiplier when associated with the RU band support requirements. These advanced features are probably some of the highest barriers to entry for new vendors in the space, as they have been developed for years by traditional vendors and require a high level of technological maturity and industrialization.

Near-RT RIC

The requirements for the Near-Real Time RAN Intelligent Controller are extremely ambitious. While they technically would enable better control of a multi-vendor RAN operation, they are unlikely to succeed in the short to medium term, in my opinion, as per previous analysis.

SMO and Non-RT RIC

The requirements for Service Management and Orchestration and Non-Real Time RIC are fairly mature and provide a useful framework for RAN domain automation and lifecycle management. The accent in this release is put on AI/ML support and management, which shows that the operators have been seduced by the promises of the technology, allowing a zero touch, automated, network, relying on historical analysis and predictive algorithms. The requirements are fairly high level, suggesting that the operators themselves might not have yet very clear targets in terms of algorithmics policy, performance and management.

In conclusion, this document provides useful data on Open RAN maturity and priorities. While the release 3 shows great progress in many aspects, it still fails to provide sufficient unanimous guidance from a commercial standpoint on the minimum set of end to end capabilities a vendor could reasonably develop to be selected for deployment at scale in these western european networks.

NEC MWC 21 Headlines

Whether you were unable to physically go to Mobile World Congress, or were too busy to catch all the announcements, I figured I would put together a brief overview of what we announced this year.

This is also an excellent explanation to those who have been asking what decided me to come work for NEC. If you read the following, I think you will get a good idea.

Besides working with amazing teams and very smart people, what drawn me to NEC is the continuation of innovation and deployment of open and disaggregated networks I started as an independent analyst at {Core Analysis}, as an executive at Telefonica and as an advisor at Bell Canada.

Our first big announcement was from Vodafone UK, selecting NEC for deployment of our 5G Massive MIMO radio units in the UK. It was promptly followed by Deutsche Telekom announcing NEC 5G open RAN mMIMO in Germany. NEC is proving once again its market leadership in Open RAN with the deployment of Radio Units in dense urban environments at commercial scale. Many vendors have massive MIMO technology, some vendors are Open RAN, we are the first and the only one to have deployed massive MIMO Open RAN in urban networks. This will change and we welcome the competition for this market to grow.

As Open RAN becomes mainstream, the opportunity for cost savings and new savings relies on the optimization of virtual resources. This selection of NEC by NTT DOCOMO to develop their Radio Intelligent Controller (RIC) is another testament of our innovation and pioneering spirit.

To grow, the Open RAN market needs many different configurations, to offer connectivity products for all kinds of environments (public, private, urban, rural, industrial, government...). We did our part announcing 3 new massive MIMO open RAN RUs.

NEC is focusing on providing RUs that are high performance high quality and completely open. We share this philosophy with MTI and that is why we are proud to have announced a strategic partnership with them.

The other important part of Open RAN is the software. NEC has been recognized as a leading solutions integrator of third parties in that space and will continue to do so, but in complement has announced the launch of of its own cloud native high performance open RAN software offering. 5G success depends on a rich ecosystem and an abundance of vendors.

Shifting from Open RAN, 5G's success will be realized through the capacity to create connectivity products that are adapted to the different use cases. A key element for this a core network that is cloud native, capable of being deployed in public or private clouds and that is blazingly fast. We are proud to announce the world fastest 5G Core network deployed in Rakuten's mobile network, in collaboration with Intel. At the same time, we showed off our deployment together with Netcracker on AWS cloud.

Private and enterprise networks are an important part of 5G and we announced our collaboration with NTT data to promote solutions to accelerate its adoption.

By now, you probably understand why I am so humbled to have been invited to join NEC and to support all these products and teams. It is a great privilege to be able to continue contributing to an open, disaggregated, high performance 5G. More to come soon, stay tuned!

Q2 multiscreen video news

I use a service to curate and collate my news. Reading through the last few months, I realized that there are so many subjects worthy of comment that a single post wouldn't begin to address them meaningfully. I reserve in-depth analysis of specific trend or topic for my paying clients, so I decided to review and comment on press clippings and announcements as they become available as a way to illustrate the trends, threats and opportunities surrounding our market.

Here is what caught my attention in the last quarter:

Technology: Is 4K the new 3D?

April of course is synonymous with NAB frenzy. Sifting through the trough of announcements at the show, I have noticed a sharp change of direction in vendor’s announcements and claims from last year. When 2013 was all about HEVC H.265, this year seems to be about 4K. While HEVC licensing terms have been agreed and announced by MPEGLA in February, Google’s royalty-free VP9 has captured some support as well, forcing chipset and platform vendors to contemplate fragmentation and multi codec support. Obviously, the battle for codec and protocol will determine who controls the management and delivery of 4K content going forward. In this race, not surprisingly, YouTube is siding with its parent company with VP9 support, while Netflix is adopting H.265. Both companies agree though, and are adamant, that 4K is a lot easier to manage and deliver for OTT properties than for traditional broadcasting payTV providers. Netflix forecasts mass market for 4K to be five years out at the current rate of TV replacements. My opinion is that 4K adoption will suffer from H265/VP9 fragmentation. We will probably see further delays because of the cost of implementing dual protocol stack throughout the delivery chain.

Technology: Cloud, SDN, NFV

At NAB as well, vendors were eager to show off their new acronyms, touting dreams of cloud-based virtualized, self-managed, software-defined networks that would… In reality, most MSOs are still focusing on rolling out HD, improving and automatizing workflows and overall costs reduction. I think we still have 5 years to go before seeing practical, mature implementation of SDN in professional video. Anything else is a science experiment or a proprietary implementation at this point.

Business: MSO to OTT

One of the big news was the announcement from AT&T regarding their intent to invest, jointly with the Chernin Group up to $500million to create SVOD and advertising based web streaming services. Umm... Is it too much or not enough? $500 million goes a long way if you want to build a web streaming service, but it does not seem nearly enough if you want to build an attractive content offering.

HBO, the next day was reported to have signed a multi-year agreement with Amazon. The deal should see some of HBO’s back catalogue series made available to Amazon Prime subscribers. Little by little, HBO nudges the boundaries. You will remember that it signed a deal with Comcast last year to offer HBO Go to Comcast broadband subscribers, without a cable subscription. All signs point that HBO could be a major league OTT provider when they will be ready to cross over.

Business: OTT to Wireless

Almost coincidentally, rumours emerged that Netflix was in discussions with the Vodafone Group to distribute Netflix services on some Vodafone subscriptions. It is likely that these deals will increase in frequency. LTE /4G will see opportunities for cord-never and cord-shavers to access their favourite service and content on cellular networks. That is… if they figure out the charging model (paying 8$ a month for Netflix and $150 in data overage charge to Vodafone wouldn't really work).

Business: OTT to MSO

Netflix has integrated its offering on Atlantic Broadband, Grande Communication and RCN Telecom services set-top boxes, a first in the US after having piloted the concept in Europe. Subscribers will be able to select the service from their PayTV provider. It is an interesting strategy for small MSOs to bundle Netflix in hybrid Set top boxes. It increases reach, provides an attractive offering and good differentiation against market leaders.

Business: M&A

Kaltura bought TVinci to expand its SVOD offering to live and linear programming. Arris bought SeaWell Networks for its advertising insertion and packaging at the edge technology. SeaWell Networks’ strong adaptive bit rate streaming skill set will be invaluable to expand the company’s multiscreen strategy.

That’s all folks for this quarter! I will keep all the good net neutrality commentary for next month, hopefully when the smoke dissipates from the PR battlefield.

The case for sponsored video

 We have all seen the announcement  at CES this January. AT&T is to offer a new plan for its 4G customers, allowing companies to sponsor traffic from specific app or content. The result would be that subscribers would not be charged for data traffic resulting from these interactions, the sponsoring company picking up the bill.

While there is not much detail available on how the offer works and what price would the sponsor be expected to pay for the sponsored content (after all, subscribers all have very different plans, with different charging / accrual models), there has already been much speculation and comments in the press and analyst community about the idea.

I haven't really read anything yet to convince me whether this is a good or bad idea, so I thought I would offer my 2 cents.

Costs are rising, ARPU is declining 

Ralph de la Vega, AT&T's CEO was quoted commenting on the press release that AT&T has seen a 30,000% growth in mobile data in the last 6 years. This growth in traffic resulted in an increase in costs, paving the way for the license bid and roll out of LTE. US ARPU are declining for the first time in history, and with rising costs, network operators must find new revenue streams. Since video now accounts for over 50% of data traffic and growing, it is a good place to start looking.

Mobile advertising is under utilized, but there is appetite

According to KPCB, about 41B$ were mis spent by advertisers in the US alone, on old media (print, radio) if we compare to time spent on new media (internet, mobile). The Internet Advertising Bureau 2013 study (people were interviewed in Australia, China, Italy, South Korea, Brazil, UK, India, Russia, Turkey, the US) shows that a large proportion of users are "ok with advertising if [they] can access content for free". The same study shows that announcers are looking at targeting (45%) and reach (30%) as the most important criteria to select a medium for advertisement. At last, video pre-roll seems to be the preferred format for advertising on tablet and smartphones.

Network operators are not (well) organized to sell advertising

Barring a few exceptions, network operators do not have the means to sell sponsored data efficiently. The technology aspect is sketchy. Isolating specific data traffic from their context can be difficult (think facebook app with a youtube embedded video served by a CDN) and content / app providers do not design their service with network friendliness in mind. On the business front, the challenges are, I believe, bigger. Network operators have failed repetitively in coopetition models. They do not have a wholesale division and mindset (everyone is scared of being only a pipe). On the bright side, Verizon, Vodafone, AT&T are putting forward APIs to start enabling content providers to have more visibility and varying level of control on the user experience.

Regulatory forces are not mature for this model

We have seen the latest net neutrality comments and fear flaring on media. Sponsored data and/or video is going to have to be managed properly if AT&T actually wants to make it a business. I am very skeptical with AT&T's statement "Sponsored Data will be delivered at the same speed and performance as any non-Sponsored Data content." I doubt that best effort will be sufficient, when / if advertisers are ready to put real money on the table. They will need guarantees, service level agreements, analytics to prove that the ad was served until completion in a good enough quality.

In conclusion, sponsored data is going to be difficult to put in place, but there is an appetite for it. Technically, it would be easier and probably more beneficial to limit the experience to video only. Culturally and business-wise, operators need to move in this direction, if they want to compete against companies for whose advertising is the dominant model (Google, Facebook, Linked In...). In order to do so, separating video from general data traffic and managing it as a separate service can go a long way. The biggest challenge will remain. It is one of mindset and organization. I am not sure that sending an email to sponsoreddata@att.com is going to get McDonalds to pay for my 30 minutes of YouTube if I buy a Big Mac combo.

Introducing the Mobile Video Alliance

It was a great and unique chance to be invited at the inaugural meeting of the Mobile Video Alliance in London this week. I would like to thank and congratulate Matt Stagg from EE and Rory Murphy from Equinix, who did a great job of bringing together an amazing panel of participants from Akamai, Amazon, BBC, EE, BT, Lovefilm, Netflix, O2, Qualcomm, Sky, Three UK,Vodafone Global and others.

It was an even greater honor to be able to present my views on the future of mobile video and what the ecosystem should focus on to improve the consumer's user experience.

You can find my presentation and the accompanying video below.






In short, it is my first experience of executives from the whole value chain getting together to discuss strategy, business and technology improvements necessary to enhance the consumer's video quality of experience.
Subjects of discussion ranged widely from adaptive bit rate best practice, to transcoding, caching, roaming and data caps, measuring QoE, mobile advertising... in a refreshing neutral, non-competitive environment without vendors trying to push a specific agenda.

The mobile video alliance is a unique forum for the industry to come and solve issues that are plaguing its capacity to grow profitably. Stay tuned, I will follow and report its progress.

LTE and video elasticity

I often get asked at events such as Broadband Traffic Management 2012, where I am chairing the mobile video stream this afternoon, "How does video traffic evolves in a LTE network? Won't LTE negate the need for traffic management and video optimization ?".

Jens Schulte-Bockum, CEO of Vodafone Germany shocked the industry last week, indicating that Vodafone Germany traffic in LTE is composed of mobile video for 85%.

I think what most people fail to understand is that video, unlike voice or generic data is elastic. Technologies such as adaptive streaming and source based encoding by content providers means that devices and content providers, given bandwidth will utilize all that is available. 

Device manufacturers implement increasingly aggressive versions of video streaming, grabbing as much bandwidth that is available, independently of video encoding, while content providers tend to offer increasing quality if video, moving from 480p to 720p and 1080p and soon 4K. 
This was corroborated this morning by Eric Klinker, president and CEO of BitTorrent. 

Operators need to understand that video must be managed as an independant service, independently from data and voice as it behaves differently and will "eat up" resources as they are made available.

So the short answer is no, LTE will not solve the issue but rather become a new variable in the equation.