Integrating Multi-Access Edge Computing (MEC) into Open 5G Core

Abstract

Multi-Access Edge Computing (MEC) represents the central concept that enables the creation of new applications and services that bring the benefits of edge computing to networks and users. By implementing applications and services at the edge, close to users and their devices, it becomes possible to take advantage of extremely low latency, substantial bandwidth, and optimized resource usage. However, enabling this approach requires careful integration between the MEC framework and the open 5G core. This work is dedicated to designing a new service that extends the functionality of the Multi-Access Traffic Steering (MTS) API, acting as a strategic bridge between the realms of MEC and the 5G core. To accomplish this objective, we utilize free5GC (open-source project for 5G core) as our 5G core, deployed on the Kubernetes cluster. The proposed service is validated using this framework, involving scenarios of high user density. To conclude whether the discussed solution is valid, KPIs of 5G MEC applications described in the scientific community were sought to use as a comparison parameter. The results indicate that the service effectively addresses the described issues while demonstrating its feasibility in various use cases such as e-Health, Paramedic Support, Smart Home, and Smart Farms.

1. Introduction

The fifth generation of networks (5G) is considered the main platform for future wireless applications, aiming to provide peak data rates of up to 20 Gb/s, average rates exceeding 100 Mb/s, and connectivity for a large number of Internet of Things (IoT) devices per unit area [1]. Additionally, reduced device battery usage, lower energy consumption, and the ability to connect an extremely high number of devices are also part of the objectives [2].

In the future, the 6G networks will continue to advance to manage growing data rate demands, increased numbers of instantiated slices, the densification of devices, and connected sensors [3]. This will require 6G to operate on a very large scale and in a hyper-connected and autonomous way, seeking to merge the digital and real worlds in all dimensions and ubiquitously, strongly integrating space and terrestrial networks, as well as making extensive usage of the location, sensing, and artificial intelligence technologies [4].

Recent studies in 6G networks highlight MEC as an essential enabler to be consolidated in 6G to fulfill the requirements of such dense network edges [3,4,5], e.g., MEC can guarantee ultra-low transmission delay and satisfy flawless 4k/8k video broadcast by processing computation-intensive data or caching ultra-high-definition (UHD) videos at the edge [3].

Standardized by 3rd Generation Partnership Project (3GPP), the 5G mobile network has various releases that define aspects of the network. One of these aspects is a new architecture that introduces separation between the Data Plane (DP) and Control Plane (CP) called SBA [6]. Additionally, a new generation of services has been proposed for 5G, including (i) eMBB: maximizing data transfer rates; (ii) URLLC: minimizing latency and ensuring high reliability; (iii) mMTC: supporting a large number of devices in the same area [7,8].

The advent of 5G networks has opened up various possibilities for implementing new applications and services, such as virtual reality, augmented reality, autonomous vehicles, and IoT. These applications demand substantial network resources, requiring the network to support increasing data volumes. Features like ultra-low latency, wide bandwidth, and efficient resource consumption need to be delivered by a 5G network [9]. One effective approach is to deploy these applications at the network edge, bringing them closer to users and taking advantage of edge computing and reduced physical transmission times. This is where Multi-Access Edge Computing (MEC) becomes crucial [10].

Edge computing has emerged as a promising evolution of cloud computing, offering benefits such as improved scalability, particularly for large volumes of data, and lower latencies enabling critical real-time services like remote sensing and actuation or distributed gaming, as well as preserving privacy and contextual information [11]. MEC, standardized by the ETSI ISG, brings services closer to the data source at the network edge [12]. This standard encompasses a comprehensive framework and architecture [13]. Furthermore, there is a suite of MEC APIs designed in accordance with general principles of RESTful API design [14].

MEC is mostly accessed through mobile networks, such as 4G LTE-Advanced [15] and the growing 5G network [16], although it is access mode-neutral [11]. Rather than being a standalone solution, MEC is designed to complement 5G, particularly in addressing requirements such as ultra-low latency that are critical for URLLC [17]. In this context, the integration between 5G networks and MEC frameworks becomes essential and can be implemented through MEC services as defined by the ETSI reference architecture.

Furthermore, carriers can leverage facilities at the edge of mobile networks, opening up the RAN to third parties, enabling flexible deployment of innovative services for mobile subscribers and businesses [11]. When implementing MEC in mobile networks, hosts are positioned at the network edge (near the 4G or 5G radio access network), supporting MEC applications and utilizing APIs such as the Radio Network Information (RNI) and location APIs. Other APIs are exposed following RESTful design principles, ensuring the interoperability and portability of MEC applications across different domains [11].

This work is based on the advantages of utilizing MEC in the network. These advantages, especially the significant reduction of duplicated content transmissions in backhaul links, enhance Quality of Service (QoS), leading to reduced latency and computational load [9,18,19]. The utilization of mobile data networks is witnessing a global surge. In Brazil, for instance, as per the National Telecommunications Agency (ANATEL), there has been a rise in mobile broadband access, escalating from 211.8 million to 213.7 million within a mere month [20]. It is anticipated that, by 2026, 54% of mobile data traffic will be facilitated through 5G networks, prompting operators to pursue enhancements to cater to this burgeoning demand, both for users and infrastructure [21]. Accordingly, the integration of 5G networks and MEC frameworks benefits both the academic community and the development of new technologies, such as autonomous vehicles, applications for smart cities, healthcare, and the augmented/virtual reality market, as well as the overall market. Amazon found in its research that every 100 ms of latency on its websites cost 1% of its sales, while Google concluded that an additional 0.5 s in the search page loading time resulted in a 20% reduction in user traffic [22]. It is anticipated that certain use cases within 5G networks will become reliant on MEC concepts and frameworks for the provisioning of services to end users [23]. Examples encompass autonomous vehicles, smart cities, healthcare, and the Internet of Things (IoT), all of which exhibit latency sensitivity and stand to derive substantial gains from the adoption of MEC principles in their deployment. These instances, for instance, manifest within the realm of Ultra-Reliable Low Latency Communications (URLLC) services [24].

To achieve the objectives of this work, we began by exploring the specifics of MEC and 5G technology. We analyzed the software components in their architecture, understanding their goals and characteristics. The chosen network core was free5GC (open-source project for 5G core) due to its open-source code, compliance with 3GPP standards, and active community. The selection was reinforced by the use of my5G-core (a 5G standalone core following the 3GPP standards) [17,25] which is a fork of free5GC. Research was conducted to identify MEC platforms that would meet the objectives of this study. However, the lack of documentation and support led to the simulation of an MEC platform using a Kubernetes cluster. The proposed service was developed based on standards and adherence to the objectives of the Multi-Access Traffic Steering (MTS) API. Additionally, a Service Registry (SR) was created to compose the validation environment, along with a test application.

Validation was divided into three parts. First, the individual functioning of free5GC, the Kubernetes cluster, and the implemented applications/services were validated. Subsequently, the registration of applications/services in the SR was validated. Finally, the third and last part consisted of validating the proposed service and collecting and evaluating the results. More details about the evaluation environment and all source code are publicly available in the GitHub repository (https://github.com/LABORA-INF-UFG/5g-mec-integration, accessed on 25 April 2024).

The contributions of this work are as follows:

• Integration between MEC and 5GC: This study demonstrates the feasibility of integrating 5G and MEC through a communication API.
• Implementation of Integration Service: One approach to realizing the integration between MEC and 5G technology is implementing a specific service. This service can be provided using a dedicated communication API.
• Expansion of MTS API: The original MTS API was not designed to route application traffic to the 5GC. Therefore, to enable traffic transfer between MEC and the 5G network, it is necessary to enhance this API by creating a new specific service.
• Validation of the API in a Test Environment: The proposed API was validated in a testbed environment using a simulated MEC framework and a 5GC.

This article is structured as follows: Section 2 presents the fundamental concepts necessary for understanding this work. Section 3 provides a literature review related to this work. Section 4 describes the proposal of this work, including its architecture, implementation details, and operation. Section 5 presents the use cases used for comparison purposes, the testbed environment, evaluation metrics, and the collected results, discussing their implications. Section 6 concludes the article.

2. 5G System

The so-called 5G system (5GS) encompasses the 5G core network (5GC), a new radio interface known as 5G New Radio, and User Equipment (UE) specifically designed for 5G [17,26]. Fifth-generation systems are in the process of development to establish connections between UE and the 5G network infrastructure [17].

In Release 16, 3rd Generation Partnership Project (3GPP) focused on a comprehensive expansion of the 5GS. This expansion includes satellite-based 5G access, vehicle-to-everything (V2X) communication services, wireless and wired networks integration with 5G, and other advancements [27]. Additionally, functionalities like using NR technology in unlicensed frequencies, integrated access backhaul (IAB) approaches, large-scale multiple-input multiple-output (MIMO) enhancements, segmented resource allocation, and new capabilities for URLLC and industrial IoT, as well as support for non-public network (NPN) implementations, are incorporated [27]. These features are considered crucial to ensure that networks meet essential requirements.

2.1. 5G Core

The 5GC network features an innovative architecture called SBA, which revolves around services and microservices [6]. In this model, the 5GC introduces characteristics such as the separation between the DP and the CP, function virtualization, and Network Slicing (NS) [17].

The SBA offers advantages such as improved development and maintenance efficiency, the association of microservices with dedicated resources and independent lifecycles, and enhanced scalability through on-demand instances [8]. This structure consists of network functions (NFs) that provide services through the Service-Based Interface (SBI), accessed via APIs and protocols like HTTP, REST, and others [17].

The 5GC is an integral part of the 5GS alongside the New Radio (NR) radio interface. Built upon cloud computing concepts, the 5GS features a service-oriented core with SBA architecture, natively supporting NS, virtualization, and edge computing [28]. The architecture of the 5GS is divided into two modes: non-standalone (NSA), where the new radio interface is used in conjunction with an existing core infrastructure (Evolved Packet Core—EPC), and standalone (SA), where the radio interface connects to the newly proposed core architecture for 5G.

2.2. Network Functions

The 5GC leverages the principles of Network Function Virtualization (NFV) and Software Defined Networks (SDNs) to virtualize network functions, including those related to transport, access, and core, which were traditionally run on closed hardware [29]. An example of the interaction between MEC and 5GC is evident in the network function (NF) called User Plane Function (UPF). This function serves as a central point in the user plane of the 5GC, connecting the UE to the data network (DN) and performing tasks like routing, inspection, and Quality of Service (QoS) management [8].

The Session Management Function (SMF) manages the UPF, configuring the connection between the UE and DN, including the allocation of IP addresses and IP PDU sessions [8]. The Access and Mobility Management Function (AMF) is a network function that interacts with the data network and the UE, facilitating registration, authentication, and mobility in the network through secure signaling [8].

The Network Exposure Function (NEF) monitors the 5G network to expose events to authorized applications and other network functions (NFs), allowing the management of QoS rules, priorities, and UE-related information [8]. These functions collaborate to ensure the effective operation of the 5GC, using the virtualization and flexibility offered by the architecture.

Network Slice is a core technology in the context of 5G, enabling the creation of logical networks on top of a shared infrastructure [8]. In essence, network slices aim to meet a customer’s specific needs, resulting in dedicated logical networks where required resources are configured and allocated [8,30].

2.3. Network Interfaces

The mentioned network interfaces refer to the connections between different software modules within the 5GC. In general, each of these connections follows specific protocols and standards. In the core context, four interfaces stand out—$N3$, $N4$, $N6$, and $N9$—each with its standardized functions, while other interfaces are not covered in this context.

• N3—Communication interface between NR and UPF. This interface carries the data encapsulated for routing [8].
• N4—The control exerted by the SMF over the UPF is carried out through this interface, with all their communications taking place exclusively through it [8].
• N6—The UPF connects to external data networks through this interface. Data no longer undergo the encapsulation process at this stage, although implementing a Virtual Private Network (VPN) is feasible [8].
• N9—Within the core infrastructure of 5G, it is possible to deploy UPFs in a sequential configuration. These UPFs are interconnected through the $N9$ network interface, and scenarios involving mobility are examples that use this approach [8].

2.4. MEC Reference Architecture

Similar to the 5GC, MEC is standardized by the European Telecommunications Standards Institute (ETSI), which is dedicated to the continuous standardization and expansion of MEC. Technical documents are regularly released, covering everything from the architecture to developing services within the MEC framework.

The MEC reference architecture serves as the foundation for creating any MEC structure. Figure 1 depicts the MEC reference architecture in a simplified manner, showcasing only the essential components for the purpose of this study. This architecture is defined in the document [13]. Various associated components can be identified within the architectural setup, such as the MEC Platform (MEP), MEC Host, and MEC Platform Manager (MEPM).

The MEC Host plays a comprehensive role in the MEC architecture, encompassing critical elements like the MEP, the Virtualization Infrastructure Manager (VIM), and MEC applications (MEC App). The VIM provides storage, processing, and networking resources for MEC applications. It is also where the DP resides [13]. The MEP plays a central role in management, especially concerning applications. It creates an environment conducive for applications to explore, offer, and use services. Moreover, it facilitates communication with the DP, adjusting it according to the traffic rules received. The MEP also hosts MEC services, including functions like a DNS server [13].

The MEPM holds management-related responsibilities. This includes overseeing the lifecycle of applications and conveying information to the edge orchestrator, the Multi-Access Edge Orchestrator (MEO). Furthermore, the MEPM handles MEP component management, as well as addressing standardization and application needs [13]. The MEO, in turn, performs various functions, such as maintaining a comprehensive view of the MEC system based on deployed MEC Hosts, available services, resources, and the overall topology. The MEO is also responsible for selecting MEC Hosts based on requirements, implementing, transferring (if applicable), and terminating applications [13].

3. Related Work

Tomazewski et al. (2020) [31] presents an architecture for MEC and 5G based on the Distributed Autonomous Slice Management (DASMO) architecture [32]. The proposal is based on a single-domain paradigm; however, it can be extended to a multi-domain scenario with the addition of another software component, as outlined in the paper. Despite the detailed proposal, there is no discussion of the validation of the presented architecture, leaving a gap in the research.

Ksentini and Frangoudis propose a management and orchestration architecture for NS [23]. This architecture divides a complete network slice into smaller parts where Virtual Network Functions (VNFs) can be deployed. They present two models: in-slice and multi-tenancy, differentiated by the MEP instantiation. In the in-slice model, the MEP is instantiated within the slice, while, in the multi-tenancy model, a shared MEP exists outside the slice. The MEP communicates with the 5G network to create traffic steering policies through direct communication with the core network’s Packet Control Function (PCF) or via the Network Exposure Function (NEF). The work aims to enable the MEC architecture to support NS and was validated using OpenAirInterface (OAI) with adaptations to the core network for communication with the MEP via Mp2.

Kekki et al. propose an integration architecture between the 5GS and the MEC architecture [16]. In this structure, the MEC orchestrator can directly interact with the NEF and, in some cases, other functions within the 5GS. The primary focus is integrating the two systems through the N6 interface, which connects to the User Plane Function (UPF). For the MEC, the UPF is considered to be distributed and configurable, and, in some deployments, it can be local and a part of its architecture.

The article by Kuklinski et al. [33] presents an innovative architecture that integrates the O-RAN platform, Self-Organizing Network (SON), MEC, and NS. The proposal is based on the near-Real Time RAN Intelligent Controller (near-RT RIC) from the O-RAN platform, with modifications to unify all these technologies into a single component called Integrated near-RT RIC (I-near-RT RIC). MEC applications are implemented as xApps within the O-RAN platform. Although it is a conceptual proposal, it has not been validated in a testbed.

Table 1. Comparison of this proposal with related work.

Works	5G-MEC Integration Proposal	Integration through Service	Integration through New Architecture	Proposal Validation	5GC SA Validation
[16] MEC in 5G Networks	X		X
[31] A New Approach to 5G and MEC Integration	X		X
[23] Toward Slicing-Enabled Multi-Access Edge Computing in 5G	X		X	X
[33] On O-RAN, MEC, SON and Network Slicing integration	X		X
This Paper	X	X		X	X

represents the comparison between this work and the related works based on the defined criteria:

• Proposal for 5G-MEC Integration—A proposal for integration is presented.
• Integration through Service—Whether the proposed integration is implemented as a service.
• Integration through New Architecture—Whether the integration proposal is made through changes to existing architecture or the creation of new ones.
• Validation of Proposal—Whether the proposal has been validated.
• Validation with 5GC SA—Is there any validation with the 5G-SA network core?

The first aspect examined deals with the central theme of this study, which is also analyzed in the works mentioned above. It is clear that some of these papers are not just limited to integrating MEC with 5G but also consider other technologies, such as SON in [33]. Therefore, all the papers discussed in this analysis present proposals involving 5G-MEC integration, but they are differentiated by their approaches.

The studies evaluated different integration approaches, including proposing new architectures for this integration. This study stands out for proposing a service as a solution, while other works focused on creating new architectures or adapting existing ones. For instance, one study utilized the DASMO architecture as a foundation, reusing key concepts, while another developed a new architecture based on public knowledge of O-RAN [31,33]. Overall, a commonality among all the works is the direct communication of the MEP with the network core’s CP via the MP2 interface.

Finally, we examined whether the proposals in these papers have been validated. Two points are considered: (i) whether the proposal has been validated in any way and (ii) whether the validated proposal uses a 5GC core. In this sense, only one related work has had its proposal validated, which is the work [23]. In this study, validation was conducted in a test environment using different machines as edge servers and an OAI network core. However, when analyzing this study, it is possible to notice elements of the Evolved Packet Core (EPC) architecture of the network cores, such as the Mobility Management Entity (MME) and Home Subscriber Server (HSS). Thus, the study does not employ an autonomous (SA) 5G network core despite the validation. The validation focused on the ability of the proposed architecture to create network slices for the MEC in the context of 5G, facilitating communication between the two technologies.

Thus, from the analysis of the conducted studies, it is evident that our proposal stands out both for its integrative approach and its validation. The proposed integration will be implemented through a service and validated within a test environment utilizing a 5G SA network core. Furthermore, it is notable that only one of the papers with architectural-level proposals has undergone validation, whereas the others remain at the theoretical and conceptual level.

Kekki et al. discuss the possibility of deployment as an application offering a service [16]. This possibility could represent a commercial advantage, considering the launch time and the potential for the service to evolve into an MEC platform as the technology and business models stabilize. This reinforces the proposal presented, providing an academic scenario with an approach different from the others. To the best of our knowledge, there are no open-source solutions in the literature to compare the implementation.

4. A New Service Proposed

The benefits of MEC and how they can positively impact 5G networks have already been presented. However, to make it possible to combine the two technologies, it is necessary to develop a component that allows communication and follows the established standards. One of the possibilities is a communication service implemented through an application or as a service part of an MEC platform, specifying this communication using an application and speeding up the launch and deployment process [16]. Another possibility is to deploy the service as part of the MEC platform. However, integrating the entire service structure into the MEC platform is non-trivial. Thus, this work aims to specify a communication API that provides a communication service deployed as an application.

This service must allow UE applications to interact with their respective server applications isolated internally on the MEC platform. Thus, the service must receive information about the destination and the content to be sent and relay it after validating its existence. The service must then wait for a response and return it to the requester. This flow is repeated in both directions. Information about the destination must be sent in the request’s body so that the service can process it and understand how to carry out this routing. A level of security is implemented by using tokens to access the proposed service. The SR will generate this token. Initially, this work does not aim to transfer media files, which is one of the possible future extensions.

The integration service, deployed as an application, will run on the MEC, specifically on the MEP component. MEP is an internal component of MEC HOST, which also has MEC Applications as part of its scope, so these are the MEC components covered by this work. The communication service run by MEP will provide communication between 5G and MEC Applications via the 3GPP $N6$ interface. The signaling that takes place between UE and 5GC is outside the scope of this work. These components can be seen in the proposal architecture shown in Figure 2.

Figure 2 also shows the structure of the 5GC, with its SMF connected to the UPF via the $N4$ interface. It can be seen that the core has two UPFs and only one SMF, made possible by the SBA architecture model. In order to prevent the transmission of N6 upstream policies to the UPF, which consistently includes the 5GS, a loosely interconnected data plane node (D-Plane) is presumed with one or multiple UPFs [34]. The image shows the gNB radio interface and representations of applications that communicate with the MEC. It is important to note that this study does not consider the internal communication of the core between the NFs and the radio interface.

The implementation of this service will involve two main functions: $postData$ and $makeRequest$. The first of these is the $postData$ function. Its primary function will be to route packets, i.e., when a packet arrives, it will look at the information in its body, identifying the destination of that information and which HTTP method will be used. The data model specified for this function includes receiving the IP address of the destination service, the HTTP method to be used, and the information to be sent.

Having received the above information, the $makeRequest$ function is invoked. This function is tasked with passing the data on to its final destination. With the information received previously, a new request will be made, but this will be made to the final destination of that information, awaiting a response. The response is sent back to $postData$, relaying it to the UE. In addition to these two methods, the service includes a third called $makeRegistry$ to register with the SR. This function contains all the service details, such as IP, port, and endpoints. This information is sent to the SR for registration, allowing interested applications to check and obtain these details.

For this whole flow to work with a higher level of security, a registry service called $ServiceRegistry$ will be implemented. This registry focuses on applications and services on the MEC platform that wish to allow internal or external access through the integration API. To this end, an application/service must register its IP, port, and endpoints with the respective methods. Interested applications will then be able to check this information. A client application in the UE will be able to check whether its respective server is available and, if it is, all the information for communication will be passed on.

In this work, it will be implemented as an application. However, this service can be incorporated into the MEC platform as desired. In this scenario, the service would also be accessible via the MEP and communicate via the N6 interface. This application will be implemented as a RESTful API. By implementing it as an application, there is no need for any communication with the core CP. Therefore, all data traffic will occur through the DP, UPF. Communications take place via HTTP requests.

In addition to the MEC reference architecture, the ETSI technical documents also deal with two APIs: Multi-Access Traffic Steering (MTS) and BandWidth Management (BWM) [13]. BWM is the API that will handle the allocation of bandwidth between applications, as well as the prioritization of specific traffic. The MTS API, on the other hand, is responsible for managing traffic, routing it, splitting it up, and replicating it on various access networks to meet the network requirements requested by the applications [14]. Recognizing that the objectives of the service that is the subject of this work and the MTS API are partially compatible, it is proposed that the MTS API be expanded to provide a traffic-forwarding service for the data network external to the MEC.

4.1. Implementation

The implementation of the proposed API used the Python language associated with the Flask framework [35]. The micro-framework is widely used for developing web applications due to its simplicity, efficiency, and robustness. The Flask associates a function with an endpoint through which information is exchanged.

The implemented functions are connected to an endpoint that responds to HTTP requests. The primary function only accepts requests via the $POST$ method. As a result, requests that do not use this method are disregarded. Once the request has been received, the API calls the $postData$ method. This procedure will check whether the minimum content is required to transmit the data. This check will look in the message content for the destination IP address and the HTTP method that should be used. The content of the message will perform a simple validation so that, if there is content, it will be used as a parameter in the $makeRequest$ function. If any of this information is absent, an error message with code 404 is sent, with the message “Service IP and Method Requested”. All messages are checked for the necessary basic data, so, if several messages are missing data, several error codes will be returned. No specific treatment is necessary as it does not interfere with the communication process.

For the information to be passed on to its recipient, the API will invoke the $makeRequest$ method. The first check will be on the HTTP method to be used. Using $POST$ or $PUT$ indicates an exchange of messages, so the data must be sent to the method. In the case of the others, no information is required other than the mandatory information listed above. After executing the request, the response message goes the other way around, i.e., it arrives at $makeRequest$, is returned to $postData$, and finally arrives at the client, its final destination.

It is important to recognize that, for this work, other methods from the MTS API have not been incorporated. This is because these methods are not essential for the proposed objective. The methods and their respective endpoints implemented in this API are protected, so, for any application/service to be able to use them, it must have a JWT token.

We have implemented the minimum necessary for the Service Registry to meet the requirements. A few functions have been implemented. The first is the $handleRegistryData$ function, which receives information from the applications and services that wish to register. Once the minimum content for registration has been validated, the $handlePost$ function is invoked, which stores the information in the database. Finally, a token is generated for this application/service using the JWT library. The device application is required to provide the access token with each request, in order to assert its permission to access the resource using the specific method invoked [36].

The $handleSpecificData$ function has also been incorporated into the Service Registry. This function is designed to make changing data in the database and retrieving information easier. The PUT and DELETE methods allow the client to modify records. With the GET method, the client can request data stored in the database. In this scenario, the UE will request information via the GET method. Collecting information will follow the same procedure that already provides the user with a token. This token is required to use the integrated service. The $handlePut$, $handleDelete$, and $handleGet$ functions are identical to the abovementioned functions.

4.2. MTS API

The system proposed in this study, implemented using the MTS API, features an access point that facilitates data exchange between two interested parties. This service receives a POST request via the HTTP protocol. The request must contain three elements: (i) the destination to which the data should be sent, (ii) the method to access that destination, and (iii) the information the sender wishes to transmit. Observing the default format of the data model is crucial, as the API interprets the data in the request body in JSON format, using the respective keys to identify the content.

After receiving the data, the $postData$ procedure is activated. This function is tasked with recognizing the end client’s destination and the method used in the HTTP protocol. This is due to the need to make a new request to send the information. The $makeRequest$ method is activated to execute this new request, which separately receives the destination IP address and the data to be transmitted as arguments. Once this new request has been completed, the API obtains the response provided by the server and forwards this response back to the client. This chain of actions can be seen in Figure 3.

The functionality will be accessible via an external port called NodePort using the Kubernetes Kube-proxy service. In this context, Kube-proxy establishes a port linked to the service using NAT [37]. As seen in Figure 3, the expectation is that the client will check the availability of the desired service in the Service Registry and, if available, receive all the relevant information. Consequently, the data format the MTS API expects must contain the full IP address, i.e., the destination IP, port, and endpoint.

The Service Registry task involves receiving data about the applications and services available on the server in question and enabling interested client applications to obtain these details, allowing access to these applications or the ability to direct their data appropriately. To perform this function, SR uses the NoSQL database MongoDB [38].

To make a MEC application accessible to those interested, the application must carry out a registration process with the SR. The SR waits for the application to transmit data, such as its IP address, port number, and the endpoints it offers. The application must establish at least one endpoint. Once the information arrives, the SR checks the validity of this data and stores it in the database.

Service Registry is a service accessible externally by the client to check the existence of registered services. The client uses an access point for searches, receiving a JSON with service information and an authentication token generated with Python’s JWT library using a specific key in the code.

5. Performance Evaluation

This section aims to validate the work proposal by discussing use cases that benefit from MEC, detailing the validation environment, and presenting the results. These results will be compared with the characteristics of applications that benefit from MEC to discuss the solution’s viability.

The proposed work will evaluate the service results using Key Performance Indicators (KPIs) described in the literature. The evaluation scenario will include e-health and IoT use cases. For the health area, scenarios such as remote surgery, remote consultation, paramedic support, critical health events, vital signs, and location tags will be observed, using the minimum KPIs required for each application, based on previous studies [39,40]. For IoT scenarios, characteristics of smart homes, wearable IoT (WIoT), and farms will be analyzed using the information described in [41]. The KPIs considered for comparison will be mainly related to latency, although other information can be used if necessary. The KPIs are presented in

Table 2. KPIs used for comparison.

Application	Latency
Smart Home	1 ms–1000 s
Remote Surgery	200 ms
Remote Medical Consultation	1 ms–100 s
Paramedic Support	200 ms
Critical Health Event	200 ms
Smart Farm	~ hours
Vital Signs Patches	1000 ms
Locatable Tags	1000 ms

.

5.1. Environment

A validation environment was designed for the proposal, looking for a MEC framework and a 5GC to evaluate and validate the final product. Some MEC platforms were initially considered, but a containerized solution was chosen using Kubernetes due to a lack of support from these other solutions. The 5GC chosen was free5GC, which was containerized to facilitate the execution of network functions. Deployments were carried out on virtual machines hosted on a dedicated server.

The Kubernetes cluster proposed to simulate the MEC platform comprises three virtual machines, one for deploying free5GC and the other two for the MEC platform. All virtual machines ran on a server called NECOS-02. VM1, used to deploy free5GC, has 8GB RAM, 100GB disk, 4vCPUs, and Ubuntu Live Server 18.04LTS operating system. VMs 2 and 3 each have 8GB RAM, 120GB disk, and 4vCPUs, with Ubuntu Live Server 18.04LTS operating system. Figure 4 shows the validation structure.

The free5GC architecture used for validation involves three UPFs: Branching UPF (B-UPF), MEC UPF (M-UPF) and Internet UPF (I-UPF). The B-UPF acts as an intermediary between the user’s connection and the destination network and is not associated with any slice.

To validate the proposal, a MEC application was developed to simulate an end-to-end environment where the traffic between the UE and the application uses the integration service. In addition, a SR was created to provide registration tokens for applications wishing to use the MTS API services. Once the applications and services had been developed, they were deployed in a production environment, using the Waitress server to run the Python applications. The deployments were coordinated, with the SR being executed first to allow the applications to be registered. The validation phase was divided into three stages: the first ensured the correct execution of the test environment, the second involved registering the services in the SR, and the third consisted of running the tests and collecting and evaluating the results.

5.2. Evaluation Metrics

The proposal will be validated with a simple application that calculates the Body Mass Index (BMI), using POST requests. It is important to note that the request could be made to any application running in the cluster and duly registered with the SR. Therefore, this application’s use is restricted to confirm the viability of the proposed API.

To do this, three scenarios will be run with different numbers of users (1, 10, 50, and 100), simulating the ability to respond to concurrent requests. Each scenario will be run at different execution times 5, 10, 30, and 60 s.

This variation aims to evaluate performance variations over continuous periods. The Locust tool will make HTTP requests and obtain the average response time and the average number of requests [42].

In addition, the production server will be tested with four and eight threads to evaluate performance. The test sets will be run ten times to obtain reliable results, and a 95% confidence interval will be calculated to assess the variability of the results. The confidence interval ($ci$) is calculated using the equation:

$$ci=\overline{x}\pm \mathcal{Z}·{\displaystyle \frac{\sigma }{\sqrt{n}}},$$

where $\overline{x}$ represents the sample mean response times obtained in 10 executions. $\mathcal{Z}$ is the normal distribution of $1.96$ for a confidence level of $95\%$. $\sigma$ represents the standard deviation of the response times, while n indicates the sample size. The ± indicates the upper and lower result intervals.

End-to-End Communication Test

This test aims to demonstrate the viability of end-to-end communication. To perform this, requests will be made to the application developed using the integration service. The following aspects will be analyzed: (i) the response to the request and whether it corresponds to what was expected; (ii) the time taken to check and send the first response; and (iii) the response time of the requests. In addition, the UPF interface with the application will be monitored to capture the packet for later analysis. For items 1 and 4, only one request will be made, considering that the information observed will not be altered. However, 30 runs will be made for the other items to obtain the average time. Confidence intervals will also be calculated for the times discussed. For this test, no specific testing tools will be used; the request and time measurement will be carried out utilizing native Ubuntu applications.

5.3. End-to-End Validation Test

The End-to-End validation aims to check whether there has been a successful connection between the UE and MEC-App, with traffic passing through the UPF and the MTS-API. The focal point for the analysis was the exchange of messages between the UPF and the API. To this end, during communication, the packets exchanged were captured, and it was possible to validate the path taken by each request.

The analysis also revealed an average response time for requests of 31 ms, with a standard deviation of 1.71. This standard deviation indicates that the response time in the 30 runs showed slight variation and was close to the average. When verifying the service’s existence and receiving a token from the UE, the response time is 26 ms, with a higher standard deviation of 5.21, indicating a more significant variation in response times. When considering the whole process, the average time is 57 ms, with a standard deviation of 5.63 due to the standard deviation of the service existence check.

This result indicates that the solution is viable for e-health use cases. According to [40], which presents KPIs for healthcare scenarios, this solution would be suitable for applications such as paramedic support and critical events (not specified in the paper).

5.4. API Evaluation Results

The results presented are based on the metrics and the use cases presented. The variation in the number of users will allow us to evaluate the behavior of the service in scenarios with competition for the same resources. The tests presented here are experimental. In real scenarios, the numbers may vary.

Figure 5 shows the results for one user. The response times are similar for four and eight threads as expected. It can be seen that the longer the execution time the smaller the standard deviation, reaching 0 in 30 s, thus presenting a smaller confidence interval. The obtained response time meets the requirements in [41] for Smart Home scenarios and even games, which require latencies of 10 ms or less.

When we run a scenario with ten users (Figure 6), the response time increases, reaching 58 ms with four threads and 47 ms with eight threads. This is because, unlike the previous scenario, there is competition for the same resource (use of services). As with the previous one, more extended scenarios have smaller confidence intervals with minor time variations. This result makes the solution viable in scenarios with paramedic support applications or critical health events [40].

For 50 and 100 users (Figure 7 and Figure 8), latency rises considerably, with latencies reaching 520 ms and 1700 ms, respectively, using just four threads. These values drop when we increase the processing power to eight threads, with 250 ms for 50 users and 590 ms for 100.

The results for 50 users indicate the solution’s viability for Smart Farming scenarios, with the transmission of data from sensors and location tags, for example, [39,40]. With 100 users, the results indicate scenarios that accept considerably high response times, such as Smart Home, location tags, and medical remote consultation [40,41].

The results show that the solution performed as expected. The times displayed in the graphs indicate the solution’s viability in various use cases presented in the literature and this work. However, as applications and the network evolve, new use cases may arise, and new demands may be required. Therefore, in the long term, it is necessary to review the viability of this solution within the scenarios and needs that will arise.

6. Conclusions

The existing literature addresses integration between 5G networks and MEC in a limited way, mainly focusing on new conceptual architectures. However, there are gaps related to implementing and validating these proposals in a 5GC.

Hence, we have proposed an implementation as a service to connect 5G and MEC. The service is an extension of the MTS API defined by ETSI, seeking compatibility of objectives. Validation has been performed in a virtualized environment with a 5G network core, simulating UE, gNB, and a Kubernetes cluster as the MEC platform.

The validation results demonstrated the ability of the proposed service to communicate between the UE and application, including performance evaluation, especially for URLLC applications. The proposed solution can be compared with others in the literature and optimized to improve response time, aiming to achieve consistent lower times.

This work achieved its overall objective by enabling 5G-MEC integration through a service deployed as an application. The solution showed satisfactory results in the scenarios evaluated, providing a basis for future studies and optimizations. For future work, we are working on validating the service, including the O-RAN real environment and real multi-tenancy application.