Skip to content

MEC Platforms – the state of the art; current developments of the scientific community on the example of the SYMEC project

MEC (Multi-access Edge Computing) has been developed as a solution for network operators, enabling the extension of telecommunications infrastructure with servers offering computing resources to users and service providers (including cloud service providers). The relevant standards are developed by the ETSI standardization organization within the ISG MEC (Industry Specification Group on Multi-access Edge Computing) working group. The ETSI MEC solution is now an integral part of the 5G network infrastructure, but it can also be used in LTE networks and other access networks. It should be emphasized that the MEC technique is a significant step in the development of telecommunications infrastructure towards a future, integrated communication and computing infrastructure.

Parallel to the standardization work, research is carried out on the specification of mechanisms and algorithms for MEC systems. In particular, as part of projects related to the implementation of NFV systems or orchestration in cloud systems, working groups were established to implement extensions of these systems and to support the computing technique at the network edge. Examples of such initiatives are: Open NFV Edge[1], Edge Automation through ONAP[2], OpenStack Edge[3], or LinuxFoundation Edge[4]. The solutions proposed by the above projects are usually extensions of the architecture of orchestration systems developed for NFV backbone networks or cloud applications that offer the possibility of orchestrating applications at the edge of the network. Therefore, these solutions are not fully compatible with the ETSI MEC architecture.

In addition, research projects aimed at developing prototypes of MEC systems fully compliant with ETSI standards have been developed[5],[6]. In particular, the SYMEC[7], implemented an ETSI- compliant MEC platform on the low-energy ARM architecture.

Polish SLICES representatives have been involved in implementation of the SYMEC platform. The SYMEC architecture is presented on the figure below. The architecture is modeled on the architecture of the network edge computing system proposed by the ETSI MEC standardization group[8].

Figure 1 The SYMEC architecture

The SyMEC architecture includes six core components:

  1. System for controlling and managing SyMEC applications and services, which consists of: the MEC orchestrator responsible for handling signaling used in the process of handling requests from service providers and users, selecting the appropriate location of the MEC instance, as well as managing the MEC infrastructure resources, using its abstract model; MEC platform manager – MEPM (MEC Platform Manager) responsible for coordinating the start / stop of MEC application instances in a distributed MEC infrastructure, as well as translation of the request format to the form required by the applied virtualization platform; and the Virtual Infrastructure Manager (VIM), which executes the MEPM Manager’s requests and directly runs the MEC application instances on the previously selected server.
  2. MEC server, which, together with the virtualization platform implemented on the server, provides computing resources, i.e. the computing power of CPUs and GPU accelerators, operating and mass memory, and enables the launch and provision of MEC application instances for users, MEC platform services and control system modules . In addition, the MEC server includes a network switch that allows you to create a reliable and secure network of MEC servers, ensuring communication between 1) SyMEC system components, 2) running MEC application instances and their users connected to access networks, and 3) environment elements, e.g. selected addresses in the operator’s network or the Internet.
  3. The MEC application repository is responsible for managing the MEC application images. The repository stores these images and makes them available to SyMEC users for installation on the server. The repository status is updated in the processes of registration, sharing and deletion of the application image. An important function of the repository is also the management and storage of MEC application descriptors containing a full description of the application requirements. In particular, these descriptors contain a unique application identifier, metadata describing the application, a description of the resources required to run the application instance (including the required processor architecture), data transfer and user attachment requirements, incl. type of protocol used, numbers of ports used, preferred DNS (Domain Name System) symbolic name. Application descriptors are used by the system, e.g. to select the appropriate server and configure the running application.
  4. The MEC platform is a set of services offered within the SyMEC computing cluster that support the operation of running MEC application instances, offering functions of automatic registration and detection of application instances, authentication and security certificate management, management of access to MEC applications by users, and registration and broadcasting of addresses domain names for shared MEC applications. In addition, the MEC platform provides secure channels for the exchange of messages in the “publish / subscribe” mode directly between instances of the MEC application, and between applications and the SyMEC system, within which, in accordance with the granted authorizations, information about the state of the system and access network or contextual information related to with the location of users.
  5. Modules for cooperation with WLAN, 4G and 5G access networks collect information about the status of the access network and connections made and transfer this information to the MEC platform. The platform provides this information in a standardized form in the form of API functions triggered by MEC applications. It should be noted that it is necessary to develop specialized cooperation modules for each of the access network techniques due to significant differences in the sets of parameters that characterize them. These modules should also be adapted to the capabilities of devices used in the access network. In this context, an important function of the collaboration modules is also to ensure the possibility of data transfer and to adjust the format of the sent messages between the user terminal connected to the point of service and the MEC application running on the SyMEC server.
  6. The SyMEC management system includes a set of modules that enable the full integration of the SyMEC system as a subsystem offering MEC services and applications in the operator’s OSS / BSS ecosystem. For this reason, the management modules have been developed ensuring their full compliance with the TeleManagement Forum (TMF) standards[9]. The following modules were developed: i) a resource management module that enables the collection and storage of information about the computing resources of SyMEC servers, the location of access points and connection topology along with the characteristics of data transmission between servers and access points, ii) a monitoring module that collects and provides information about the status of servers, their load and usage, and the status of running MEC applications.

Based on the experience of designing the SyMEC system, it should be noted that the ETSI MEC architecture is only an abstract model of the edge computing system. This model requires significant modifications and additions, which results from the fact that the MEC system is one of the subsystems of the complex ecosystem of the operator’s infrastructure and must be fully integrated with other subsystems of this infrastructure, such as the OSS / BSS subsystem or the management subsystem. Moreover, the use of an abstract resource model is advantageous for the operation of the orchestrator or the user interface as it allows to hide the physical realization of the objects, which simplifies the control methods used in a heterogeneous system composed of different computing clusters. However, the specification and implementation of the MEC platform manager, VIM manager, application repository or modules for cooperation with access networks largely depends on the virtualization platform used and network techniques used. The basic element that maps the world of abstract objects used in the model to their physical representation is the MEC platform manager together with the management system modules. It should also be emphasized that the container virtualization platform based on Docker[10] and Kubernetes (k8s)[11] tools used in the prototype also forced the extension of the MEC application descriptor in relation to the description defined by ETSI and influenced the application image repository.

In order to ensure cooperation with other operator systems, the SyMEC architecture maintains full compliance of external contacts with the ETSI MEC and TMF standards. In particular, the Mm1 interface between the orchestrator and the OSS / BSS system is compatible, which allows initiating the start / stop of an MEC application instance or registration / deletion of a new MEC service / application. The SyMEC asset description is also compliant with TMF standards, allowing easy integration of SyMEC with operator management systems. In addition, the MEC application API program interface is compliant with ETSI[12] standards to allow easy implementation of MEC applications developed by third party developers. The remaining contacts were defined using the open REST APIs or, as in the case of the Mm6 contact, the API defined in the Kubernetes tool was used.

To sum up, the SyMEC architecture, compared to the ETSI MEC architecture, has been extended with the following elements:

  1. modules for cooperation with the operator’s systems, incl. with the OSS / BSS system, as well as with the operator’s network management system;
  2. a repository of MEC application images registered in the system,
  • software-controlled network modules that ensure safe and reliable communication in a distributed computing cluster created by MEC servers located directly on the edge of the network (far edge), but also in local computing centers (near edge) ) and regional / central computing centers of the operator, and
  1. modules for ensuring communication between the user terminal connected to a given access point of the access network and a dedicated MEC application instance running on the selected distributed computing cluster server.

The developed prototype of the SyMEC system was implemented in the nationwide research network PL-LAB 2020, which made it possible to integrate MEC nodes with various access networks and conduct tests in conditions similar to those prevailing in operating networks. The prototype was installed in four locations, i.e. in Gdańsk (Gdańsk University of Technology), Poznań (Poznań Supercomputing and Networking Center), Wrocław (National Communications Institute – Research Institute) and in Warsaw (Warsaw University of Technology), as presented on the figure below.

Figure 2 Implementation of the SyMEC system in the nationwide research network PL-LAB 2020

Two MEC servers were installed at each site. One of them is the MEC server developed in the project with an ARM64 processor, and the other MEC server was built using a typical x86 server. The heterogeneous environment of the computing cluster allowed for the installation, operation and interoperability of MEC applications designed for ARM64 and x86 systems. In particular, the SyMEC node in Gdańsk was integrated with the extensive WLAN network installed on the campus of the Gdańsk University of Technology. The SyMEC node in Wrocław has been integrated with experimental LTE (4G) and 5G networks built with the use of open-source software[13]. In this case, due to restrictions on the licensed frequency band, the base stations and terminal terminals were installed in the anechoic chamber. In addition, in the nodes located in Warsaw and Poznań, SyMEC servers were integrated with LAN / WLAN local networks, making MEC applications and SyMEC system resources available to users of these networks for research on MEC technology.

The developed installation includes the full functionality of the developed SyMEC system, which enables research on the MEC technique. It should be emphasized that the developed prototype and pilot installation include the full functionality of the developed SyMEC system, integrate MEC servers developed as part of the project (based on arm64 processors), as well as servers based on x86 processors, enable MEC applications to use hardware acceleration and parallelize calculations based on o GPU processors.

 

[1] OPEN NFV edge project , https://wiki.opnfv.org/display/EC/Edge+ cloud.

[2] ONAP Project: Edge automation through ONAP, https://wiki.onap.org/ display/DW/Edge+Automation+through+ONAP.

[3] OpenStack project: Edge computing, https://www.openstack.org/edge- computing/.

[4] LF EDGE project: Building an open source framework for the edge, https://www.lfedge.org/.

[5] 5G City Project, https://www.5g.eu/.

[6] Openness Project, https://www.openness.org/.

[7] SYMEC Project, https://www.symec.com.pl/.

[8] ETSI,  Multi-access  Edge  Computing (MEC);  Framework  and  Reference  Architecture, ETSI GS MEC 003 V3.1.1, March 2022.

[9] TeleManagement Forum: https://www.tmforum.org  

[10] Docker: https://www.docker.com/

[11] Kubernetess “Production-Grade Container Orches-tration”, https://kubernetes.io

[12] ETSI,  Multi-access  Edge  Computing (MEC); General principles, patterns and common as-pects  of  MEC  Service  APIs,  ETSI  GS  MEC  009 V3.1.1, June 2021

[13] Open Air Interfeces, https://openairinterface.org/oai-5g-ran-project/