5 techniques making MEC a 5G a proven solution.

I would like to write a few words about the MEC solution, which in my opinion will revolutionize mobile network services.

What is MEC (Multi-access Edge Computing)

Multi-access Edge Computing (MEC) is a computing system with processor power, storage, and interfaces located on a virtual/cloud platform. It gives new in that sector, the possibility to develop applications by software developers and content providers based on a cloud-computing system with IT service. All of it is on the edge of the mobile network, which means closest to the base station and User Equipment (UE).

This environment can offer ultra-low latency and gives the possibility to deliver high bandwidth data service including something new. Real-time access to radio network information that can be used by applications. This is a revolution in a sense. It is not anymore just a “fast data pipe” concentrating whole traffic from all customers in the country, it is a localized and very specialized “data service” for singular or massive customers. MEC provides a new ecosystem and value chain that mobile operators and 3rd party providers will be able to use to create new revenue streams.

Access to Radio Access Network (RAN) for applications will allow flexible and rapidly deploy innovative applications and services. It could be serviced for mobile subscribers, enterprises, and vertical segments, which until now were limited only to OTTs or mobile operators themselves.

The MEC initiative is an Industry Specification Group (ISG) within ETSI and the purpose of the ISG is to create a standardized, open environment ready for development based on RESTfull OPEN API definitions.

MEC applications gain contextual information and real-time awareness of their local radio environment and parameters over defined APIs. It consists of Radio Network Information API – RNIS, Location API, UE Identity API, Bandwidth Management API, and UE Application Interface API.

MEC architecture and location

MEC is an Application Function (AF), one of many which can coexist in new 5G SBA architecture. It can be an application authorized by the 5G operator and cooperate directly with other 5G NFs or not authorized application and then connected via Network Exposure Function (NEF) element as not trusted 3rd party application.

MEC is complementary to Virtual Network Function (VNF) concepts. MEC applications can be located on a distributed cloud of the MEC system and can belong to one or more network slices. The MEC standard architecture is designed so its components are very similar to NFV components. It allows replacing some MEC components with ones from NFV that manage similar functions.

The MEC system itself is not a target solution but only distributed cloud of MEC systems on the edge of a network, with different levels of computing (Central Cloud, Regional cloud, and finally most critical for mMTC and URLLC – local Cloud).

MEC system according to the standard is connected over the N6 interface, in the 5G network seen as external. This way of defining reference points allows locating MEC in a different place in the network, with different impacts on service quality.

MEC system can be deployed e.g. at cases as, but not only:

1. Radio Node together with UPF (MEC is a natural development of mobile base stations). From the mMTC and URLLC application provider point of view, this is the most valuable case, but not necessary from an economical point of view. The cost of MEC architecture shall not follow the cost of Radio Unit (RU) deployment, but more of Central Unit (CU) – referring to the C-RAN concept.

2. Transmission point possibly with UPF, could be the CU node.

3. Aggregation Point with local UPF, could be CU node.

4. On the Core network location (this case today is suggesting a Central Cloud location which may be useful for the eMBB case).

This flexibility is a mandatory change, as please remember further 5G networks must deliver low latency services for mMTC (massive Machine Type Communication) and URLLC (Ultra-Reliable and Low Latency Communication). Specially case 1 and 2 will be critical for that services as case 1 is suggesting the direct coexistence of C-RAN and MEC systems on the same servers, in the same location. This gives the operator the possibility to save on infrastructure but also demands the operator to follow the radio development after industry/services demand.

We can imagine the football zone, or complex automotive factory requiring dense local coverage and an EDGE system. It will however not follow the coverage needs of eMBB (enhance Mobile BroadBand) services, as in that case economics of the EDGE location may be in conflict with customers’ needs.

Anyway, this is clear, flexibility in deploying other MEC nodes gives a lot of possibility for the development of small zone density services like V2X, IoT, EDGE gaming, 8K TV, etc.

Key capabilities of MEC standard

I. Traffic steering

MEC has the capability to route traffic to the targeted application in a distributed cloud. This AF is able to give the routing criteria and destination to UPF (routing instance), which plays a central role in routing traffic to desired applications and network functions. MEC can also interact with the Policy Control Function (PCF) to modify/interact with quality parameters.

The traffic steering can be performed based on many different parameters like traffic identifier (DNN, S-NSSAI, AF-Service-Identifier, 5 tuples, etc), a reference ID, a list of DNA, information about target UE(s), application relocation possibilities, temporal validity condition (time frame for routing validity), spatial validity conditions (location of UE, geographic area), notification type for user plane management notifications and AF transaction ID.

A wide variety of parameters opens a possibility for application providers to create new types of products.

II. UE and application mobility

MEC is an environment that includes computing power and networking capabilities both on the edge of the network, and close to the radio network. More MEC systems will be deployed in an area e.g. 2-5 MEC servers in a big city, and the system needs to track and synchronize UE(s) context and applications. We can use this as an example of V2X vehicles moving around the city.

MEC application needs to keep the exact locations of all surrounding vehicles/pedestrians and keep the context in case of changing MEC zones. MEC application mobility feature is one of the most needed functions for the future, e.g. detection of UE movement to a new cell. The mobility feature is a new function for software providers to be considered and implemented in applications of future 5G networks.

III. Capability exposure

5G SA architecture includes Network Exposure Function (NEF), which allows the Core network to expose its capabilities to external Application Function (AF) as the MEC. It allows the MEC Orchestration (Figure 1) to interact with other NF to:

a. Monitoring: request or subscribe to UE-related events of interest, including roaming status, UE loss of connectivity, UE reachability, and location-related events. AMF & UDM are critical here.

b. Provisioning: to provision expected UE behavior to 5G system e.g. predicting UE movement, or communication characteristic

c. Policy and Charging: handling QoS/QoE as well as charging policies in the communication of PCF. It opens the interesting potential to create services with sponsored data services.

One of the more powerful features of MEC and 5G SBA architecture inter-working is the ability to leverage network capabilities information exposed by 5G RAN.

The whole system was created by the ISG standardization body, to allow RESTfull programmers to use ready, standardized, and well-documented interfaces – API.

Here is a list of APIs with a short description of their functions.

API – the power of interaction 5G RAN with MEC applications

MEC defines standardized Application Programming Interfaces (APIs) to support edge computing interoperability:

• Mobile Edge Platform Application Enablement API – GS 011
• Radio Network Information API – GS 012 (radio conditions, user plane-related measurements, radio access bearer information, and corresponding change notifications). It will allow MEC hosts to optimize performance or provide new types of services based on up-to-date radio network information.
• Location API – GS 013 (AP/eNB location, UE location, UEs in a specific area, notifications of UE entering some area, providing UE A-GPS location to MEC application, etc.).
• UE Identity API – GS 014 (allows authorized MEC applications to invoke UE traffic rules within the MEC platform over tagging mechanism). This API allows trafficking rules to be applied to some groups of Ues in some C-RAN/MEC zone without affecting the whole S1 interface by complicated decoupling systems.
• Bandwidth Management API – GS 015 (BWMS API). (Role of that API is effective and timely satisfaction of Bandwidth, which can be used for QoS/QoE applications).
• UE Application Interface API – GS 016 (UE application interface to support interaction with MEC). This API allows the device application to request certain application lifecycle management actions in the MEC system, such as requesting a list of available MEC applications, and installation and termination of new MEC applications. For the MEC application mobility, it may be used to assist MEC in application/context relocation.

Exposing of RAN services in MEC gives a high power to the application developers. It is the first time in the Mobile industry, that so deep level of impact on Quality of Service and Bandwidth management is given to application providers.

Use cases that “open eye” for a future

The real excitement starts when we start to understand what will be possible with these capabilities. To help developers to have, ETSI defined plenty of informative use cases, which I present in the form of a table [ETSI GS MEC 002 V2.1.1].

The use cases are grouped into three categories (Cat):

A. Consumer-oriented services – gaming, augmented and assisted reality, remote desktop applications, etc.

B. Operator and 3rd party services – active device location tracking, big data, security, safety, enterprise services

C. Network performance and QoE improvements – content/DNS caching, performance optimization, video optimization, etc.

I summarized it in Table 1a and Table 1b.

Support for the MEC ecosystem

The standard is very interesting and very open to application developers.

Nothing, however, will happen without the support of mobile operators. Operators must understand the power of that weapon and start the implementation of API interfaces, but what is more critical develop infrastructure supporting that standard. If we look at the infrastructure of the operator in the multi-city country, we can understand the cost behind infrastructure once we want to work on URLLC services or mMTC IoT massive solutions widely available.

I will risk my opinion, that those solutions will be at the end of the 5G road map for most of the operators, due to economic reasons. It will be, as long as the application development industry does not start to push operators for the MEC infrastructure/interface localized delivery, a “chicken and egg” case :-).

Conclusions

I am happy to read what MEC standards prepared by 3GPP and ISG within ETSI offer to the market. It is the FINAL STEP into a real 5G revolution.

For years it was a dream for developers to deliver applications in cooperation with mobile network providers. That dream was partially realized by OTT providers, but using external systems and services mostly on their own solutions.

New 5G SBA architecture opens a door for application developers to implement new features and services with an impact on the quality of connection, and user behavior monitoring in close cooperation with operators.

Reading Table 1, we can observe that most of the initial ideas from ETSI are related to the improvement of QoE and network performance (Cat C). There are however BIG IDEA cases for customer-oriented services (A) like AR, Gaming, Video orchestration support, and a group of Location-based services independent from A-GPS or terminal information taken from the external positioning system.

We can observe today’s development of Edge Gaming based on Google Cloud solution, but it is easy to verify that the local EDGE of Google finishes today in some places some cities in Europe, the United States, etc. This group of services requires external 3rd party application providers to understand the potential but also find the business opportunities by operators and 3rd party providers. Here I can hope it will be more successful than OPEN API mobile interface offered five years ago by the mobile industry (RESTfull-based access to messaging, authorization, and call services for authorized software providers).

What next

I can see also huge potential in MEC solutions for V2X services, which will be the domain of innovative cities as well as “Industry 4.0” providers. These industrial customers require much bigger investments and I can predict its development in 3-5 years.

I am waiting for the first Proof of Concept (POC) but even more, for the first commercial solution based on 5G MEC and 5g RAN networks (I know there are already some 4G LTE cases).

I am very interested in your opinions about the near future of MEC. Do you agree with my enthusiasm? Please leave your comments below the article.

REFERENCES

https://www.etsi.org/technologies/multi-access-edge-computing