MEC Questions Answers

General questions

Q1: What does MEC acronym stand for?

A1: At the initial creation of Industry Specification Group (ISG) MEC in 2014, the acronym meant Mobile Edge Computing. Since MEC Phase 2 work (2017 onwards) this was expanded to Multi-access Edge Computing, to include not only cellular networks but also other access networks (e.g., WLAN, fixed access networks). MEC is access network agnostic and can be deployed on various networks for which specific supports may be needed for the full exploitation of these access networks.

Q2: What makes ETSI MEC unique?

A2: ETSI MEC focuses on the standardization of the necessary APIs to enable application and service providers to utilize computing capabilities present at the edge of the network (e.g. 3GPP 3G/4G/5G networks, WLAN, fixed access networks), thus bringing edge computing as close as possible to the end users without it being in the user devices. This is critical in establishing a unified and truly scalable and inter-operable edge computing eco-system. ETSI MEC specifies the essential elements that are required to enable applications to be hosted in a multi-vendor multi-access edge computing environment, ensuring service continuity and assisting seamless application layer mobility, both intra- and inter-MEC.

Q3: What are the main use cases targeted by ETSI MEC?

A3: ETSI MEC targets several main categories of use cases, including but not limited to:

·        Consumer oriented services: these services generally benefit the end-user directly. Examples include gaming, remote desktop applications, augmented and assisted reality, and cognitive assistance.

·        Operator and third-party services: these are innovative services that take advantage of computing and storage facilities close to the edge of the operator's network. These services are usually not directly benefiting the end-user, but can be operated in conjunction with third-party service providers. Examples include active device location tracking, security and safety, enterprise services.

·        Network performance and QoE improvements: these services are generally aimed at improving the performance of the network, either via application-specific or generic improvements. The user experience is generally improved, but these are not services provided to the end-user directly. Examples include content / DNS caching, network performance optimization, video delivery optimization.

Over 40 use cases of these categories, including their description and related requirements, are given in Annex A of ETSI GS MEC 002.

Q4: Where can I find the official list of common terms used in ETSI MEC?

A4: Common terms and abbreviations are defined in ETSI GR MEC 001.

Q5: What are the MEC requirements defined in ETSI MEC?

A5: ETSI GS MEC 002 specified the requirements for MEC with the aim of promoting interoperability and deployments, including

·        Generic requirements such as the requirement on framework, application lifecycle, applications environment, support of mobility

·        Service requirements for platform essential functionality (MEC services, connectivity, storage, traffic routing, DNS support, timing) and optional features

·        Operation and management requirements, and

·        Security, regulation and charging requirements

Q6: What is ETSI MEC service and which services are required to fulfill the given requirements?

A6: ETSI MEC service is a service provided via the MEC platform either by the MEC platform itself or by a MEC application. There are several MEC services specified in ETSI MEC, including:[AL1]

·        Radio Network information: when available, provides authorized applications with radio network-related information.

·        Location: when available, provides authorized applications with location-related information

·        Traffic Management Services: when available, allows the MEC applications to register for specific bandwidth allocation or/and multi-access traffic steering requirement.

Q7: Is it possible to ensure service continuity between applications running in the mobile edge and an external cloud environment?

A7: ETSI MEC has defined procedures to ensure service continuity when the application instance is relocated from an external cloud environment to the MEC system. The procedure describes how to relocate the application instance to the target MEC host. This procedure is based on using the information provided by the 5G network as an example, i.e., UPF and DN connected to the ETSI MEC host, in order to identify the target ETSI MEC host.

Architecture questions

Q8: How can the ETSI MEC system be deployed?

A8: Logically ETSI MEC hosts are deployed in the edge or central data network and it is the User Plane Function (UPF) that takes care of steering the user plane traffic towards the targeted MEC applications in the data network. The locations of the data networks and the UPF are a choice of the network operator and the network operator may choose to place the physical computing resources based on technical and business considerations such as available site facilities, supported applications and their requirements, measured or estimated user load etc. The MEC management system, orchestrating the operation of MEC hosts and applications, may decide dynamically where to deploy the MEC applications. In terms of physical deployment of MEC hosts, there are multiple options available based on various operational, performance or security related requirements. The figure below illustrates examples of the physical deployment of MEC in a 5G network. For more detailed information, one can refer to ETSI WP “MEC in 5G networks (June 2018)”, ETSI WP “MEC Deployments in 4G and Evolution Towards 5G (February 2018)”.

1. MEC and the local UPF collocated with the Base Station.

2. MEC collocated with a transmission node, possibly with a local UPF

3. MEC and the local UPF collocated with a network aggregation point

4. MEC collocated with the Core Network functions (i.e. in the same data center)

Q9: Is there a reference architecture for ETSI MEC?

A9: The following is the generic architecture for ETSI MEC:

The multi-access edge system consists of the MEC hosts and the MEC management necessary to run MEC applications within an operator network or a subset of an operator network.

·        The MEC host is an entity that contains a MEC platform and a Virtualisation infrastructure which provides computation, storage, and network resources, for the purpose of running MEC applications.

·        The MEC platform is the collection of essential functionalities required to run MEC applications on a particular Virtualisation infrastructure and enable them to provide and consume MEC services. The MEC platform can also provide services.

·        MEC applications are instantiated on the Virtualisation infrastructure of the MEC host based on configuration or requests validated by the MEC management. MEC application can potentially provide and/or consume MEC services.

·        A MEC service is a service provided and consumed either by the MEC platform or a MEC application. When provided by an application, it can be registered in the list of services to the MEC platform.

More details about the functions of each of the aforementioned entities can be found in ETSI GS MEC 003 “MEC Framework and Reference Architecture”. In addition, the following reference architecture variants are defined in ETSI GS MEC 003.

- Reference architecture variant for MEC in NFV: allows to instantiate MEC applications and NFV virtualised network functions on the same Virtualisation infrastructure, and to re-use ETSI NFV MANO components to fulfil a part of the MEC management and orchestration tasks.

- Reference architecture variant for MEC federation: enables the establishment of a MEC federation and, through that, interworking between a MEC system and another MEC system or non-MEC system.

Q10: What features that ETSI MEC may support?

A10: ETSI MEC may support the following optional features:

·        RadioNetworkInformation: if supported, the MEC service exposes up-to-date radio network information regarding the current radio network conditions

·        LocationService: if supported, the MEC service provides information about the location of specific UEs currently served by the radio node(s) associated with the MEC host

·        UEIdentity: if supported, the MEC platform provides functionality for a MEC application to register a tag (representing a UE) or a list of tags

·        BandwidthManager: if supported, the MEC service enables an authorized MEC application to register statically and/or dynamically its bandwidth requirements and/or priority .

·        WLANInformation: if supported, the MEC service provides up-to-date WLAN information regarding the current WLAN conditions

·        V2Xservice: if supported, the MEC service provides feedback information from the network to the vehicle in support of V2X functions

More features can be found in ETSI GS MEC 002.

API related questions

Q11: Is MEC Application registration supported in ETSI MEC?

A11: Yes, MEC application registration related procedures are specified in ETSI GS MEC 011. This set of procedures is optional, and it is up to application developer to decide if registration is necessary. The application registration procedure allows an authorized MEC application instance to provide its information to the MEC platform. For the application instance that is not instantiated by the MEC Management, the registration can ensure the application instance is discoverable. If there is a change in the requirements or to the information of an MEC application instance, the authorized MEC application instance uses the application registration update procedure to update the MEC platform.

Q12: What is the application lifecycle management in ETSI MEC?

A12: The MEC Orchestrator is the core functionality in MEC system level management, which is responsible for the following application lifecycle management related functions:

•    on-boarding of application packages, including checking the integrity and authenticity of the packages, validating application rules and requirements and if necessary adjusting them to comply with operator policies, keeping a record of on-boarded packages, and preparing the Virtualisation infrastructure manager(s) to handle the applications;

•    selecting appropriate MEC host(s) for application instantiation based on constraints, such as latency, available resources, and available services;

•    triggering application instantiation and termination;

•    triggering application relocation as needed when supported;

•    coordinating with the OSS the application instantiation lifecycle management operations.

More details about the application lifecycle management can be found in ETSI GS MEC 010-2.

Q13: How is it ensured that the MEC application is running at the optimal/best location?

A13: As defined in ETSI GS MEC 010-2, MEC Orchestrator (MEO) / Mobile Edge Application Orchestrator (MEAO) can choose a good (if not the best) location to host an application, considering the requirements of computation, networking and deployment policies. When the current location no longer meets the requirements, the mobility services may be used. ETSI GS MEC 021 specifies application mobility service APIs in support of service continuity via relocation of a MEC application instance from one MEC host to a different host. More in detail, “Application mobility is a unique feature of MEC system, which supports relocation of user context and/or application instance from one MEC host to another, or between a MEC host and a Cloud, especially when the MEC host is attached to mobile operator’s networks. As a mobile device connected to a mobile network moves around within the network, it can result in the device connecting to the network entity associated to a different MEC host from the serving host. Consequently, there is necessity of relocating the application instance and/or user context associated to the device to a new MEC host to continue offering the best performance of service.”

Implementation related questions

Q14: Is there any open source or reference implementation of MEC systems available including MEC orchestrations, OSS, MEC platforms, MEC host?

A14: All ETSI MEC specified APIs are illustrated in JSON or YAML format with OpenAPI and online available here: https://forge.etsi.org/rep/mec/. There is a list of available open source MEC solutions including MEC platforms, MEC Platform Manager and MEC orchestrator on the MEC wiki (see MEC ecosystem). These solutions are not necessarily ISG MEC compliant but are recognized by MEC ISG MEC.

Q15: What is the ETSI MEC Sandbox? How we can utilize it for development?

A15: ETSI MEC Sandbox is an interactive environment that enables users to learn & experiment with ETSI MEC Service APIs. These standardized RESTful APIs are targeted towards MEC application developers to expose the value-added services offered by MEC, including real time access to network and context information, as well as location awareness. MEC Sandbox provides the user with a choice of scenarios combining different network technologies (4G, 5G, Wi-Fi) and terminal types. Combining these assets in a geolocated environment, a user can gain hands-on experience on the behavior and capabilities of the Location (MEC013), Radio Network Information (MEC012), Traffic Management APIs (MEC015), Application Mobility (MEC021), WLAN Information (MEC028) and V2X Information API (MEC030) service APIs. Such contextual information can offer significant differential performance for edge based MEC applications. MEC Sandbox also provides the support of capabilities described by Edge Platform Application Enablement (MEC011) and Device Application Interface (MEC016).

Q16: Does MEC specify the minimum required computing/storage/network resources to run or deploy MEC host?

A16: No, resources assigned are a deployment choice. Generally, these resources depend on how many services it is providing. As per the ETSI MEC architecture, MEC host contains the MEC platform, MEC applications and virtualization infrastructure. It can also be based on whether MEC infrastructure is spread across multiple locations or sites or is centralized in a single location.

Q17: Is MEC system designed in difference for different vertical application domains, such as automotive, AR/XR, vs. AI custom services, etc.?

For example, if certain MEC applications require the GPU accelerators, how do they know if the MEC platform can support it or not?

A17: ETSI GS MEC 010-2 specifies application Descriptor (AppD), which describes application requirements and rules required by application provider. For example, among the AppD attributes MCIO (Managed Container Infrastructure Object) constraint parameters describes constraints expected to be assigned to MCIOs realizing this application, and GPU is one of the additional capabilities required. Applications would get such info through MEC management. For example, the MEC Orchestrator (MEO) may return with a failure, if the MEC system cannot find any MEC hosts supporting GPU in this case.