!

"

Development of MEC system for indigenous 5G

Test-Bed
Arzad Alam Kherani1, Gaurav Shukla1, Shashvat Sanadhya1, Neha Vasudev1, Muneeb Ahmed1,
Ashish Singh Patel1, Rashi Mehrotra1, Brejesh Lall1, Huzur Saran1,
Mythili Vutukuru , Abhishek Singh2, Sushila Seshasayee3, Vinodh R Viswakumar3, Kishore Loganathan3
2
2021 International Conference on COMmunication Systems & NETworkS (COMSNETS) | 978-1-7281-9127-0/20/$31.00 ©2021 IEEE | DOI: 10.1109/COMSNETS51098.2021.9352907

1
Bharti School of Telecommunication Technology and Management, IIT Delhi, India
2
Department of Computer Science and Engineering, IIT Bombay, India
3
Centre of Excellence in Wireless Technology, Chennai, India

Abstract— Multi-access Edge Computing (MEC) is an comprise the MEC system and the reference points
evolving technology and considered as one of the critical (interfaces) between them. A MEC host is usually deployed
enablers for technologies to meet the IMT definition of 5G in the network edge; it contains MEC platforms and performs
communications. It integrates the service provider's network computation and storage of applications in VMs or containers
with the high-performance computation facility to cater to
[3]. MEC platform provides a secure environment where
various applications such as augmented reality, vision
applications, etc., at the network edge. Thus, reducing the MEC applications may, via Restful APIs, discover, advertise,
overall latency and preserving the bandwidth to send the consume, and also offer services.
complete data to the centralized data centers for processing
instead. Furthermore, MEC opens up tremendous business
opportunities for telecommunication companies by offering a
service platform for deploying various services specific to
consumers and industry at the network edge. In this work, we
have demonstrated a full-fledged MEC architecture, including
its entities, and integrated with 5G core following ETSI 5G
specification with an application deployment use-case. The
various MEC and 5G core components are instantiated in the
virtual machine as a guest; the complete data path and control
path is established between all core components following a
service-based architecture. The MEC system developed is a part
of the indigenous 5G Test-Bed project and follows the ETSI
architecture. The developed system is suitable for executing Fig. 1. Overview of application deployment in MEC environment [2]
various applications that require data offloading, extensive
storage, and computing resources. Thus, our working MEC The MEC system architecture and functional design consist
system establishes a proof of concept and closely resembles a of two major components. The first component involves the
real-world deployment of MEC system in 5G environment. deployment of MEC components, while the second
component details the communication and information flow
Keywords—5G core, MEC, Edge Computing, 5G Test-Bed
among its components. Our experimental setup demonstrates
I. INTRODUCTION and defines all MEC core components with a working model,
which is further integrated with 5G core. We have validated
MEC is an emerging technology, evolved from cloud our software design and architecture by running various
computing, has paved the way for the 5G mobile applications involving processing at the edge. In one such
communication, which can support low latency with mission- application, a client runs the video streaming application,
critical IoT services. The various application services may which is processed at the edge and forwarded to the cloud
include augmented reality, data analytics for security, safety server based on the event trigger generated at the edge
as well as for Industrial IoT requires intensive computation application running at MEC host.
and massive storage. Furthermore, the MEC system
establishes a service platform at the network edge leading to II. FUNCTIONAL DESIGN AND OVERALL ARCHITECTURE
new business opportunities for the telecommunication
The overall MEC system consists of key architectural
service providers as well. However, such systems must be
components and information flow between the components.
deployed uniformly across multiple operators and must be
standardized. In this direction, ETSI has published various A. MEC Architecture
industry-standard specifications to deploy the MEC The MEC architecture comprises the reference points and
environment [1]. The 3GPP 5G system specification defines MEC entities. The reference architecture describes the
the key entities, enabling the routing and policy control functional elements that comprise the MEC system and the
function between the 5G and MEC system and further lead to reference points between them, as shown in Fig. 2.
a robust edge computing environment. 1) MEC Entities
We have developed a MEC system as a part of the We have considered the following MEC entities:
Indigenous 5G Test-Bed based on the ETSI specification [1]
a) Edge Orchestrator (MECO)
while following the broad application development
guidelines [2]. The ETSI reference architecture for the MEC It is responsible for the overall MEC system, deployed MEC
platform in Fig. 1 shows the functional elements that hosts, resources, MEC services, and topology. It also
manages the onboarding of application packages, selecting

#$%&&$%&#$&''()* 131
Authorized licensed use limited to: University of Canberra. Downloaded on May 21,2021 at 14:47:12 UTC from IEEE Xplore. Restrictions apply.
               !"

optimal MEC host, and triggering application instantiation,

termination, and relocation.
b) MEC Platform Manager (MEPM)
It manages the life cycle of applications, including informing
the MEC orchestrator of relevant application-related events
and service authorizations, traffic rules, and DNS
configuration. In this work, its functionality is included in
MECO.
c) MEC Platform (MEP)
It offers a virtual infrastructure environment where the MEC
applications can discover, advertise, and offer MEC services.
It also receives traffic rules from the MEC platform manager,
Fig. 2. MEC interfaces and entities with information flow
applications, or services and instructs the data place
accordingly. B. Information Flow in the MEC System
d) MEC Host The overall information flow in the MEC system
It consists of the MEC platform and a virtualization architecture, as shown in Fig. 2, is as follows:
infrastructure which provides (MECH) compute, storage, and • UE requests MECO to find an app that goes through
network resources for the MEC applications. UALCM. After authorization, UALCM forwards all
e) MEC Application the requests to MECO and sends the response back
It runs as a virtual machine on the MEC host, interacts with to UE.
the MEC platform to consume and provide MEC services and • MECO informs the 5G core through NEF and shares
support procedures related to the lifecycle of the application. the UE ID tag (IP and port and other) for traffic
f) Operation Support System (OSS) subscriptions, and receives info related to the 5G
It receives requests via the Customer Facing Service portal core. After that, MECO performs appropriate Host
(CFS) from device applications for instantiation or selection to current UE for app instantiation.
application termination. However, in current work, it is not • MECO also informs the selected MECH for running
deployed, but functionality is incorporated in MECO. the requested application.
g) User Application Life Cycle Management (UALCM) • At the time of application life cycle completion,
MECO sends a request to MECH for the termination
It enables the device applications to request onboarding,
of running the app in the platform and also keeps a
instantiation, termination, and relocation of applications
record of all registered MECH and UALCM.
across the MEC system. It also authorizes requests from
device applications in the device and interacts with the OSS III. EXPERIMENTAL SETUP AND WORKING MODEL
and MECO for processing these requests.
Our experimental setup consists of system details, message
h) RANEMULATOR flow details, and integration with the 5G core.
It hosts the UE endpoints with reference to Client App and
Device App. The Client app is the one that initiates
interaction with the rest of the system via the Device app.

2) MEC Interfaces
There are three groups of reference points defined between
the system entities:
a) MEC–system-support interface (mp interface)
Reference points regarding the MEC platform functionality.
The mp1 interface is implemented, which performs service
registration, service discovery, and communication support
Fig. 3. Virtual Machine Setup with MEC system and 5G Core
for services, including registration and updating of DNS and
Traffic rules. System Details
b) Management reference points (mm interface)
The MEC entities are instantiated on an HP workstation
We have implemented mm9 interface in an integrated manner inside a virtual machine. The virtual machine setup is shown
between UALCM and MECO and between MECH and in Fig. 3. Six guest machines are created inside a virtual
MECO. The mm9 combines all the other management machine for RANEMULATOR, 5G core, UALCM, MECO,
interfaces like mm1, mm2, mm3, mm4, mm5, mm6, mm7, MECH, and a server. The RANEMULATOR has one virtual
and mm9. ethernet card, and the 5G core machine has two virtual
c) External Reference Points (mx interface) ethernet cards, which are used to configure two networks.
Reference points connecting to external entities (mx RANEMULATOR and 5G core establish a path to MEC
interface). The mx2 interface between UE and UALCM is system (UALCM, MECO, and MECH) kept in the same
implemented. DNN.

132
Authorized licensed use limited to: University of Canberra. Downloaded on May 21,2021 at 14:47:12 UTC from IEEE Xplore. Restrictions apply.
               !"

A. Message Flow between Device App and MEC System

The communication between the device app and MEC
System is shown in Fig. 4, performing instantiation and
onboarding of MEC app with reference to fetching,
instantiation, and back-propagating the application
information to the device app. It consists of the following
requests and responses:
• GET request to find and retrieve available app List
with given parameters and receive a response
• POST request for the creation of app context and
receive a response.
• PUT request, if any change in callback Reference, Fig. 5. 5G core and MEC Integration
this may be optional.
C. Video Streaming Application Deployment
• DELETE request for termination of running
application. The developed system is suitable for various applications that
require data offloading, intensive storage, and computing
resources. We have Test-Bed the developed system on
various applications such as face recognition, video analytics,
etc. An instance of a video analytics application [3] deployed
at the MEC host is shown in Fig. 6, in which the end-user
streams a video. In this application, a client runs the video
streaming application, which is processed at the edge and
forwarded to the cloud server based on the event trigger
generated at the edge application running at the MEC host.

Fig. 4. Communication between device app and MEC System

B. Integration with 5G Core

The integration between the MEC system and 5G core is
performed with a single UPF and three UPF, as shown in Fig. Fig. 6. An instance of a video streaming application [3]
5. However, a single UPF solution (only Edge UPF) is more
typical in Enterprise type of deployment where whole data Furthermore, we are planning to host a challenge (MEC 5G
goes to a single edge location. The overall steps and challenge) [4] to demonstrate the usage of the MEC system
considerations involved in integration are as follows: (1) as an enabler for different use cases and business objectives,
When a path switch between cloud DNAI <-> edge DNAI helping all stakeholders to develop a diverse, open MEC
needs to happen, the MEC application will notify UE (at the ecosystem.
application level). (2) UE is expected to change the
Destination IP address in the IP flow; UPF will then route this IV. ACKNOWLEDGMENT
to the corresponding DNAI (on the N6 interface) based on the
destination IP address. (3) We can have three UPF(s) setup This work is a part of the Indigenous 5G Test-Bed Project
with a geographically close-to-edge located ULCL UPF and funded by the Department of Telecommunications (DoT) to
Edge UPF to satisfy latency or other MEC requirements. (4) encourage Indian startups and the industry to take an early
The app is aware of the IP address change, so presumably, it lead in 5G.
can also handle connection 'reconfigurations' (if needed) REFERENCES
(e.g., if it is a TCP flow, it can now initiate a new TCP
[1] Sami Kekk, "MEC in 5G Networks," ETSI White Paper No. 28.
connection to a new server). Three UPF option is more viable [2] D. Sabella, "Developing Software for Multi-Access Edge
and generic as it makes routing and connection management Computing," ETSI White Paper 20.
more manageable within the MEC network and allows [3] "Flask streaming Pedestrians detection using python opencv."
separate edge and cloud networks. https://github.com/seraj94ai/Flask-streaming-Pedestrians-
detection-using-python-opencv-
[4] "MEC-5GTest-Bed." https://bhartischool.iitd.ac.in/mec-
5g/index.html.

133
Authorized licensed use limited to: University of Canberra. Downloaded on May 21,2021 at 14:47:12 UTC from IEEE Xplore. Restrictions apply.