Earlier this week, I was having lunch with a marketing guy from one my favorite small cell vendors. The topic of RAN-based applications (aka - RAN servers or RAN-based intelligence) came up and, like any good marketer, he talked up the work his company had been doing in the space along with the value this was delivering to his customers. Then, like any good AND responsible marketer, he noted that he had no interest in positioning this type of application work in terms of Network Functions Virtualization (NFV). He didn't find a need to ride the NFV hype. More importantly, since what his company was doing might not technically qualify as NFV, he didn't want to run the risk of freaking out anyone who feels that strict, definitional accuracy is key to keeping the world in order. We finished our BLTs and went our own ways.
By now, many of you probably know what precipitated this conversation. No, it wasn't the BLTs. It was the recent formation of an ETSI Industry Specification Group (ISG) around "Mobile Edge Computing," supported by IBM, Intel, Huawei, Nokia Networks, NTT DoCoMo and Vodafone. Announcing the launch, Nokia positioned Mobile Edge Computing (MEC) in terms of its own Liquid Applications solution which built compute capabilities into the RAN, "allowing for the rapid deployment of new services and the optimization of service delivery from the mobile edge." A few days later, Daryl Schoolar over at Ovum did a decent job of explaining the value in terms of driving the market for RAN-based services when he argued in a blog post, "With standardization, it means other vendors will be developing similar solutions, which creates competition. Mobile operators benefit from this."
Yet, as good as this all sounds, there's a fundamental problem here. As much as we might all love standardization, it's only meaningful if everyone is on board. And this is where you can almost come to appreciate an NFV-induced freak out.
You see, the concept of siting computing resources and service delivery at the edge of the mobile network isn't new; the folks behind ETSI's MEC work aren't alone in promising RAN server solutions--built on broader industry specifications…or not.
- Early Movers. While their brands may not carry the clout of MEC players like Nokia, IBM, or Huawei, start-ups have been talking up the idea of RAN-based applications and even telecom functions for years. Quortus was founded on this notion. Saguna was too (it's actually been rumored to be at the heart of Nokia's Liquid Applications). SpiderCloud's services node is positioned as a SON manager but also--as the name implies--a services platform. Before getting acquired by Cisco, small cell specialist Ubiquisys drove this concept with its Smart Cell concept. Oh, if you're wondering why I didn't call out Intel at the start of this bullet, there's a reason; they've also been intimately involved in working with Ubiquisys, SpiderCloud and Saguna. Fancy that.
- Cisco's Fog. When Cisco introduced the concept of "fog computing" as a counterpart to "cloud," there were pundits who mocked the term as little more than marketing. At its heart, though, the fog concept is simple and logical. It argues that many different types of data--Internet of Things data, in particular--will need to be processed at the network edge, given latency and network resource requirements. Sound familiar?
- NFV. By now, we all know at least something about NFV including the basic promise of software portability to general purpose computing platforms. In many cases, the thinking around NFV has been focused on network functions delivered from a data center. This need not be the case. RAD, for example, was early in evangelizing the concept of Distributed-NFV as a way to take applications all the way into the enterprise. Major NFV vendors have been telling a similar story of late, including the idea of venue-based packet core or CDN resources. And, if you can take applications into the enterprise or stadium, you can put them at a base station, right?
Don't take any of this as downplaying the importance of edge-based applications. I'm probably one of the concept's biggest fans; there's a PPT presentation out there from last year's Mobile World Congress that attests to the fact. My colleague, Ed Gubbins, was arguing for standardization around Nokia's Liquid Apps long before the MEC work kicked off. Beyond the value in supporting new operator services (and any vendor's aspirations), I've even been including RAN-based applications in my discussion of 5G lately, given 5G use cases requiring super-low latency.
The problem, however, reflects a well-worn cliché around standards; the nice thing about them is that there are so many to choose from. To be fair, the various concepts and solutions outlined above aren't all interchangeable…much less actual standards. They are similar enough in what they're trying to achieve that operators just trying to figure out where their interests lie are likely to be left confused--likely to throw in their lot with whichever has the most momentum. Could that explain why the MEC Introductory Technical White Paper frames MEC work as complementing work on NFV, with the MEC ISG promising to "align and liase" with NFV specification groups? Maybe. Could it explain why the initial MEC supporters will need to quickly recruit new members and show some momentum around their work? Definitely.
Come to think of it, this all might be worth a good freak out.
Peter Jarich is the VP of Consumer and Infrastructure at Current Analysis. Follow him on Twitter: @pnjarich.