Following my previous article about 5G SBA architecture and benefits of 5G SA core network.
I would like to write few words about MEC solution, which in my opinion will revolutionize the 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 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 it 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 “fast data pipe” concentrating whole traffic from all customers in the country, it is a localized and very specialised “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 flexibly and rapidly deploy innovative applications and services. It could be services for mobile subscribers, enterprises and vertical segments, which until now were limited only to OTTs or mobile operators itself.
The MEC initiative is an Industry Specification Group (ISG) within ETSI and purposes 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 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 application authorized by 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 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.
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 N6 interface, in the 5G network seen as external. This way of defining reference point allows locating MEC in a different place in the network, with different impact of 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 mMTC and URLLC application provider point of view, this is the most valuable case, but not necessary from an economical point of view. Cost of MEC architecture shall not follow the cost of Radio Units (RU) deployment, but more Central Unit (CU) – referring to C-RAN concept.
2. Transmission point possibly with UPF, could be CU node.
3. Aggregation Point with local UPF, could be CU node.
4. On the Core network location (this case today is suggesting Central Cloud location which may be useful for eMBB case).
This flexibility is a mandatory change, as please remember further 5G network 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 direct coexistence of C-RAN and MEC systems on the same servers, in the same location. This gives operator the possibility to save on infrastructure but also demands from 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 EDGE system. It will however not follow the coverage needs of eMBB (enhance Mobile BroadBand) services, as in that case economics of 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 capabilities 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 the 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 tuple, etc), a reference ID, a list of DNAi, 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.
Wide variety of parameters open a possibility for application providers to create new types of products.
II. UE and application mobility
MEC is an environment which includes computing power and networking capabilities both on the edge of the network, close to the radio network. More MEC systems will be deployed in an area e.g. 2-5 MEC servers in a big city, more the system needs to track and synchronize UE(s) context and applications. We can use as an example of V2X vehicles moving around the city. MEC application needs to keep 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 a future, e.g. like 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 network.
III. Capability exposure
5G SA architecture includes Network Exposure Function (NEF), which allows the Core network to exposure 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 behaviour 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 are the ability to leverage network capabilities information exposed by 5G RAN.
The whole system was created by 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 its 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 host 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, provide 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 to traffic rules to be applied to some group of Ues in some C-RAN/MEC zone without affecting 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 application. For the MEC application mobility, it may be used to assist MEC in application/context relocation.
Exposing of RAN services in MEC give s 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 which “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 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 application, 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 MEC ecosystem
The standard is very interesting and very open towards 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 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 5G road map for most of the operators, due to economic reasons. It will be, as long as the application development industry do not start to push operators for the MEC infrastructure/interface localised delivery, “chicken and egg” case :-).
I am happy to read what MEC standards prepared by 3GPP and ISG within ETSI offers to the market. It is a FINAL STEP into 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 provides, but using external system and services mostly on their own solutions.
New 5G SBA architecture opens a door for application developers to implement new feature and services with an impact on the quality of connection, user behaviour 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 group of Location-based services independent from A-GPS or terminal information taken from the external positioning system.
We can observe today development of Edge Gaming based on Google Cloud solution, but it is easy to verify that local EDGE of Google finishes today in some places some cities of Europe, 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 that OPEN API mobile interface offered five years ago by the mobile industry (RESTfull based access to messaging, authorisation, call services for authorised software providers).
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 first Proof of Concept (POC) but even more, for a 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.
- If you like the text – share it with your friends.
- Please leave a comment. It is a source of guidance for me.
- You can follow me on LinkedIn and Facebook.