The news that the two main bodies setting standards for edge computing – ETSI MEC (Multi-access Edge Computing) and the OpenFog Consortium – are working together is more than just another memorandum of understanding between two of the telecoms industry’s innumerable alliances. At least, we have to hope it is more, because warring efforts in this important area of emerging telco architectures could jeopardize the benefits targeted from 5G and the distributed cloud.
Operators are faced with several huge technical challenges, which they need to address in parallel over the next few years in order to transform their ailing business model. Migrating to 5G while supporting a decade of 4G coexistence; virtualizing some or all of the network and making it fully software-defined, programmable and automated; turning the network into a cloud services platform and then distributing that platform right to the edge of the network. For most operators, making these changes will be gradual, but will deliver the greatest efficiencies and new revenues if they are done in an integrated way. But the task is a complex one, and for most will be too daunting if there aren’t plenty of standards to assure interoperability and future-proofing.
Fragmentation, then, is the enemy of the new network, and it has been threatening in some of the most critical areas, including management and orchestration (MANO) of virtualized systems, and in edge computing. Ericsson group CTO Erik Ekudden summed up the views of the industry when he said, at the recent Mobile World Congress Americas event, that open source and standards were both good things, as long as there aren’t too many of them.
“We can’t spread ourselves too thin,” he said. “I think it’s always a risk that you have overlap and I think right now we’re trying to sort it out.”
The agreement between the ETSI MEC Industry Specification Group (ISG) and the OpenFog Consortium is one effort to “sort it out”. They aim to reduce technical overlap in their work across many domains and to share their work in order to drive global standards for a “fog-enabled edge”.
This is a breakthrough because it shows an organization with roots deep in the telco industry finding common ground with one whose primary target is the enterprise (OpenFog is based on technology and ideas initiated by Cisco). But as the telecoms network becomes an IT services platform, and the IT/cloud systems become always-connected, there has to be a meeting of minds between these two sectors. If the basic technologies and standards do not reflect both sides of the coin, there is little hope for operators which need to run their networks like distributed clouds, delivering all kinds of services and content to devices everywhere.
A memorandum of understanding with the OpenFog Consortium brings the key members of that group deeper into ETSI’s orbit. The Consortium was founded in November 2015 by ARM, Cisco, Dell, Intel, Microsoft and Princeton University. It has since grown to 55 members, including AT&T, GE, Hitachi, Sakura Internet, Schneider Electric and Shanghai Tech University (all Contributor members). Its geographic balance has moved significantly towards east Asia – other members include Hon Hai (Foxconn), Fujitsu, Mitsubishi, NEC, NTT and Toshiba.
OpenFog aims to develop an open architecture to support intelligence, analytics and resources close to the edge, specifically to enable the Internet of Things. Its recently published Reference Architecture (see inset) extends the mobile edge with a physical and logical multilayered hierarchy of cooperating fog nodes. These provide the interface between cloud and edge, allowing for interoperability across operators.
ETSI MEC – which originally stood for Mobile Edge Computing but has now extended its remit to all access types – has also focused on IoT use cases, as well as others such as efficient content caching and delivery. It has many similarities to OpenFog in terms of its core ambitions. It has developed an architecture based around multi-access edge hosts, deployed by different operators, which run edge applications collaboratively.
When ETSI initiated phase two of the MEC work in April (all ETSI projects have a two-year lifespan), it stressed its new broad vision, looking beyond MNOs. It said in a statement: “Future work will take into account heterogeneous networks using LTE, 5G, fixed and WiFi technologies. Additional features of the current work include developer friendly and standard APIs, standards-based interfaces among multi-access hosts and an alignment with NFV architecture.” It stressed the links to a broader virtualized network and cloud architecture – an area where MEC will be able to draw heavily on another key ETSI ISG, for NFV (Network Functions Virtualization).
Predictably, its architecture has been tied into mobile network elements such as localized evolved packet cores (EPCs) and the deployment of storage and compute resources alongside small cell sites. However, even MEC luminaries like Nokia have also, recently, been exploring edge-based approaches which are less integrated with the actual RAN, and place the edge resources on localized mini-servers in a variety of locations according to the use case.
There is no doubt that both bodies aimed to inject their respective thinking into a universal platform. OpenFog’s ambitions were clear when chairman Helder Antunes said: “Just as TCP/IP became the standard and universal framework that enabled the internet to take off, members of OpenFog have created a standard and universal framework to enable interoperability for 5G, IoT, and AI applications. While fog computing is starting to be rolled out in smart cities, connected cars, drones, and more, it needs a common, interoperable platform to turbocharge the tremendous opportunity in digital transformation.”
So a clash loomed, which may have been averted, or at least diluted, by the new agreement. The new partners will cooperate on standardization and interoperability requirements by sharing and applying selected technical work in progress. One of their first joint initiatives will be centered on APIs (application programming interfaces) to support edge computing interoperability. Some of these will be based on the ETSI MEC interfaces which were released in July.
By adopting and reusing APIs across the OpenFog and MEC architectures, it will be easier for developers to write single software modules that run on both OpenFog and MEC architectures, and to manage these in a common way.
“This OpenFog-ETSI MOU is a significant step in our efforts to build interoperability for efficient and reliable networks and intelligent endpoints operating along the Cloud-to-Things continuum,” said Helder Antunes, chairman of the OpenFog Consortium and senior director at Cisco.”
“This alignment of a leading industry consortium and a leading standards setting organization in the fog/edge space should make it easier for both application developers and infrastructure solution providers to develop towards a common, open and interoperable edge computing environment,” said Alex Reznik, chairman of the ETSI MEC ISG.
For once, the official statements are not too close to hyperbole. It really is essential that the various approaches to edge computing start to converge. There are others, of course, such as cloudlets (which have been pushed by Microsoft, but the Windows giant now seems firmly behind OpenFog). The most relevant platforms to the mobile and telecoms world are MEC and OpenFog, and so it is a big step forward that they are cooperating. We only have to look at another key ETSI initiative, NFV, to see the danger of a deep split between a standards body approach and an open source movement. Though there was significant consensus around the basic NFV specifications, in the critical area of management and orchestration (MANO), there is damaging overlap and even conflict between ETSI’s OSM (Open Source MANO) offering, and the AT&T-inspired ONAP (Open Network Automation Protocol), among others.
A similar stand-off was looming in MEC, especially since ETSI expanded the remit of its ISG in April. Reznik said at the time: “In phase two, we are expanding our horizons and addressing challenges associated with the multiplicity of hosts and stakeholders. The goal is to enable a complete multi-access edge computing system able to address the wide range of use cases which require edge computing, including IoT.”
The expanded architecture and commercial vision were welcome, reflecting that MEC could be relevant to many sectors beyond MNOs, but it also created overlaps with other initiatives. ETSI knew that, to steal a march on fog computing as the dominant approach to edge computing, MEC needed to be less focused on mobile operators. The initial target use cases focused on MNO concerns – moving high bandwidth services closer to the subscriber, offering a standard process for techniques like video caching, in order to use capacity more efficiently and reduce latency.
But the remit had to expand – not all devices and services requiring low latency are mobile, especially in the IoT; optimally efficient use of network resources can be boosted by supporting seamless access across fixed, cellular and WiFi; operators want MEC to enable new services and revenue streams, not just enhance the performance of old ones. As many telcos try to turn themselves into cloud providers, it becomes increasingly important to know how and where to distribute the cloud resources and services, looking at the network as a whole, not just the cellular element.
It is far more constructive for ETSI and OpenFog to address these common concerns together as far as possible, now their work has started to overlap so much. Otherwise both risked being hampered in their ability to drive standards which will become urgent to many types of operators and enterprises, within the next few years.
For ETSI, there was the risk that MEC would, like NFV before it, become stalled after initial enthusiasm. This year, there has a been a rising tide of concerns that an ETSI approach to edge computing may be slow and cumbersome compared to one driven by an open source effort or by the IT-oriented OpenFog Consortium.
But OpenFog risked losing the interest of telcos, which will be important deployers of edge computing, whether to support their own services, or those of enterprise customers. It is also notable that Chinese heavyweights have put considerable effort into MEC (see inset), and have also been trying to drive convergence of the groups.
There must also be clear coordination with other efforts around SDN and virtualization, as well as the standards bodies defining the next generation of Internet standards themselves (the IoT and Tactical Internet programs, which will be driven by organizations like the IETF and W3C). Virtualization and SDN do not just allow for dynamic sharing of a huge centralized resource. They also make edge-based computing and network processing far more resource-efficient. Hence, they are at the heart of MEC and fog computing.
The OpenFog Reference Architecture:
In February, the OpenFog Consortium unveiled its Reference Architecture design, aimed at providing a universal framework to support emerging IoT, 5G and artificial intelligence applications, which will increasingly rely on distributing cloud capabilities throughout the network and right to the edge.
Its document sums up the intentions of fog computing, to turn data into actionable wisdom. It coins a whole new acronym, DIKW, which it explains thus: “Data gathered becomes Information when stored, and retrievable [information] becomes Knowledge. Knowledge enables Wisdom for autonomous IoT.”
The OpenFog Reference Architecture itself is built on a core set of pillars, which support a horizontal system-level architecture. The pillars are Security, Scalability, Open, Autonomy, RAS, Agility, Hierarchy and Programmability.
For resiliency, the fog nodes can be linked together as a mesh, to provide load balancing, fault tolerance and data sharing, and to minimize communications back to the central cloud. As for hardware, it covers CPUs, GPU accelerators, FPGAs, as well as RAM array storage, SSDs, and HDDs – as well as Hardware Platform Management (HPM) devices.
The document outlines the software side of things too, as well a rather detailed use case examining how the spec would work in and end-to-end airport visual security system (vehicle arrival, baggage, security, transit), as it negotiates and manages the different interactions between the disparate systems.
As for next steps, the group will set about the lengthy process of bringing other standards into the ecosystem – a gargantuan process. With testbeds and APIs, OpenFog certification would denote those systems and standards that are compatible with the spec.
ZTE had the idea first:
Chinese companies are having an increasing influence over edge computing alliances, and have demonstrated a number of MEC applications such as a ZTE smart parking system.
In fact, ZTE was the first to raise the idea of a MEC-Fog convergence in a public forum. Earlier this year, it proposed a system architecture which it dubbed ‘Cloud-Fog Collaboration’ which “unifies the concepts of fog computing and multi-access edge computing, avoiding the bottlenecks of heavyweight cloud computing.”
It submitted its architecture to the ITU-T CTO meeting in Thailand and showed use cases involving online video, augmented reality/ virtual reality (AR/VR), large-scale IoT and other application scenarios.
It argued that there were too many different approaches to edge computing, when in fact, there are broad similarities between fog computing and MEC, and between the requirements for different 5G and IoT applications. Many services, including online video and AR/VR, have strict requirements for cache, delay, policy control and security, which mitigate against an over-centralized cloud. Instead, these services will benefit from “lightweight cloud computing” at the edge, which will be integrated with network slicing, software defined networking, network virtualization and other technologies to support flexibility and responsiveness.
In ZTE’s architecture, edge, regional and central data centers would be unified as components of a common, multilayer framework, enabling “multi-level distributed cloud deployment, on-demand network slicing, sensitive service chains, dynamic scheduling, efficient new function introduction, maximum software and hardware decoupling, as well as strict separation of forwarding and control”.
Meanwhile, its great rival Huawei is spearheading a MEC initiative with the potential to have considerable market impact – a collaboration which will see 13 organizations establish a “collaborative circle” to drive the MEC ecosystem.
All three Chinese operators are in the group, as well as the China Communications Standards Association and China Computer Federation. Also joining are ETSI itself, the GSMA, 3GPP, Industrial Internet Consortium (IIC), Intel, ARM, Trend Micro and iQiyi.
“Currently, there is no industry alliance to promote development of the MEC industry, which is a key challenge for us,” said Long Jiping, VP of Huawei’s cloud core network product line. “All industry players should work together to drive the MEC industry forward and explore edge network capabilities to commercialize MEC and achieve business success.”
Tang Xiongyan, CTO of China Unicom’s Network Technology Research Institute, added: “It is time that MEC applications be developed and used. We need to speed the development of an MEC ecosystem alliance and related standards, while also considering new business models. The goal in all of this is to enable the communications industry to support more industrial internet applications.”
The first ETSI MEC standard APIs:
This summer, the ETSI MEC ISG released its first package of standardized APIs (application programming interfaces) to enable interoperable services at the mobile edge. These include a radio network information API and a location API. The group has also set out general principles for MEC APIs, and for application lifecycle management, while offering an application enablement framework.
Compliance with the design principles should ensure consistency across APIs, ETSI said, flagging that this work was inspired by projects in the TM Forum and Open Mobile Alliance.
The app enablement framework is designed to be applicable to every scenario, opening up the network and exposing information for authorized third party applications. The aim is to impose common practices and interoperability on developers which want to interface with operators’ systems, such as location awareness.
As for the APIs themselves, the RNIS provides RAN-related information to MEC applications and platforms, to optimize existing services and help support new ones which use real time access to radio conditions and related events. The location API leverages the Zonal Presence service developed by the Small Cell Forum and is built upon the OMA specification ‘RESTful Network API for Zonal Presence’.
Additional service APIs, including an API for bandwidth management, are expected to be released later this year.