ETSI Mobile Edge Computing Industry Specification Group (MEC ISG) has just released three foundation-level Group Specifications which define mobile edge computing terminology, study technical requirements and use cases, and specify the framework and reference architecture of MEC.
GS MEC 001 provides a glossary of terms related to the conceptual, architectural and functional elements of Mobile Edge Computing. The goal here is to spread a consistent use of terminology within ETSI MEC specifications and, beyond the ISG, more widely in industry.
The second document, GS MEC 002, specifies technical requirements enabling interoperability and deployment and describe examples of uses cases of mobile edge computing.
The third specification, GS MEC 003, outlines a framework and reference architecture, describing the functional elements and the reference points between them, and a number of mobile edge services that comprise the solution.
ETSI Mobile Edge Computing ISG is now working on nine new studies related to MEC APIs, management interfaces and essential platform functionality. In addition, it will study mobile edge computing in an NFV environment, and work on end-to-end mobility.
MEC is promoted by its proponents as a key enabling technology for applications that require very low latency, or that otherwise benefit from a close relationship with radio network and base station information – such as edge caching and content optimisation.
MEC’s ability to provide low latency responsiveness could make it suitable for some IoT and mission-critical, vertical applications, and that is one reason why some have tagged MEC as an architecture that will be a key enabler for 5G. The fact that, architecturally, it aligns well with NFV – allowing for the integration of virtual functions very close to the network edge, ties MEC within a second industry mega-trend.
MEC should be seen as separate and complimentary to NFV, however, and the MEC architecture has been designed in such a way that a number of different deployment options of mobile edge systems are possible.
ETSI’s GS MEC 003 says: “With respect to NFV, a mobile edge system can be realised independently from the presence of an NFV environment in the same network, or can be coexisting with it. As both MEC and NFV are based on the use of virtualisation technology, MEC mobile edge applications and NFV virtualised network functions can be instantiated partly or entirely over the same virtualisation infrastructure.”
There are, of course, edge-based computing approaches that do not require conformance to MEC specifications, and not all the industry’s main mobile equipment vendors are currently contributing to MEC within ETSI. The most strident advocate to date amongst the mega-vendors has been Nokia which evolved MEC as a concept from its Liquid Apps solution that it based on its RACS (Radio Applications Cloud Server) design. Huawei has been a less vocal but visible second, with its Services Anchor forming its key edge-based element. Intel, too, has been a major proponent, given the extension for its solutions MEC could offer. Ericsson, however, has been much less sure that MEC is the edge architecture of choice, and Alcatel-Lucent, prior to its acquisition by Nokia, was also not a proponent.
Other vendors, from small cell providers such as SpiderCloud to providers of virtualised core network functionality such as Quortus, have aligned themselves with MEC specifications to take advantage of a standardised edge-intelligence architecture. Still others, such as Vasona Networks, see themselves as platform providers at the edge, being able to enrich edge-based vitualised functions with cell-level network intelligence.
MEC’s advocates tend to argue that having a standardised approach to architecture and implementation will ensure that operators can deploy applications, features and functions from different providers in a common way across multi-vendor networks. These first specs provide the industry a common language and reference architecture with which to do so.