Toward Network-Slicing-Enabled Edge Computing: A Cloud-Native Approach for Slice Mobility

Network slicing is a key enabler for 5G and beyond networks that permits operators to provide scalable, flexible, and dedicated networks over a common physical infrastructure. To cope with the rising demand for ultrareliable and low-latency communication (URLLC) in beyond 5G networks, the provision of dedicated secure networks closer to the users is essential. Multiaccess edge computing (MEC) is a promising technology that provides data and computational resources closer to mobile users. However, MEC servers are resource-constrained, and offering dedicated service-specific network slices at the edge in a highly dynamic and mobile environment is challenging. Network slicing and MEC are being evolved by two different standardization bodies that limit their integration and raise mobility challenges that deserve more attention. We propose a cloud-native microservices architecture for network slice mobility management in MEC that permits each MEC slice to be distributed as stateless and independently deployable microservices. The proposal separates the MEC slice operational data and the user context, as each network function in a MEC slice stores the context in a separate shared database. The proposed architecture leverages new SDN extended federation modules in compliance with the ETSI requirements for inter-MEC system coordination. The federation modules support a more flexible and scalable creation of network slices at MEC servers, efficient resource utilization, and mobility of network slices across MEC servers. The simulation results show that our proposed architecture outperforms the existing SDN-based approaches for network slicing in MEC by achieving high slice acceptance rates and reduced slice migration delay.

Toward Network-Slicing-Enabled Edge Computing: A Cloud-Native Approach for Slice Mobility Syed Danial Ali Shah , Mark A. Gregory , Senior Member, IEEE, and Shuo Li , Member, IEEE Abstract-Network slicing is a key enabler for 5G and beyond networks that permits operators to provide scalable, flexible, and dedicated networks over a common physical infrastructure.To cope with the rising demand for ultrareliable and low-latency communication (URLLC) in beyond 5G networks, the provision of dedicated secure networks closer to the users is essential.Multiaccess edge computing (MEC) is a promising technology that provides data and computational resources closer to mobile users.However, MEC servers are resource-constrained, and offering dedicated service-specific network slices at the edge in a highly dynamic and mobile environment is challenging.Network slicing and MEC are being evolved by two different standardization bodies that limit their integration and raise mobility challenges that deserve more attention.We propose a cloud-native microservices architecture for network slice mobility management in MEC that permits each MEC slice to be distributed as stateless and independently deployable microservices.The proposal separates the MEC slice operational data and the user context, as each network function in a MEC slice stores the context in a separate shared database.The proposed architecture leverages new SDN extended federation modules in compliance with the ETSI requirements for inter-MEC system coordination.The federation modules support a more flexible and scalable creation of network slices at MEC servers, efficient resource utilization, and mobility of network slices across MEC servers.The simulation results show that our proposed architecture outperforms the existing SDN-based approaches for network slicing in MEC by achieving high slice acceptance rates and reduced slice migration delay.

I. INTRODUCTION
N ETWORK slicing and multiaccess edge computing (MEC) are two key enablers for 5G and beyond networks [1], [2].Several use cases and services are expected to rely on the integration of network slicing and MEC [2].In particular, the integration of these two key technologies can empower new ultrareliable and low-latency communication (URLLC) services, e.g., vehicle-to-everything (V2X) [3].The programmable MEC infrastructure is used to offer dedicated network slices, i.e., self-contained dedicated virtual networks, tailored for diverse service requirements.The emerging services and applications have stringent and diverse performance requirements, e.g., URLLC requirements for V2X communication [2].The provision of URLLC for emerging services demands dedicated network slices to be deployed at the network edge.
MEC is being standardized as a promising technology that brings computational and storage resources closer to the devices that have low-latency service requirements [4], [5].Though several emerging use cases and services for 5G and beyond networks rely on the integration between network slicing and MEC, the development of the technologies required for network slicing-enabled MEC is still in its early stages [1], [2].Network slices are provisioned with dedicated resources to meet service-specific performance requirements; however, due to the limited computational capacity of the MEC servers, the dedicated network slices are not readily available on each MEC server [6].Therefore, it is essential to develop effective resource allocation policies and new methods to deal with network slice mobility (NSM).The integration of the two technologies also introduces new NSM challenges where some of the network slice resources should be migrated from one MEC server to another to ensure service continuity.NSM across MEC servers may be triggered by user mobility, resource availability, or network connectivity issues.
Effective NSM techniques need to be developed to ensure service continuity in a highly dynamic and mobile environment, e.g., V2X, where dramatic variations to the network topology occur as the vehicles move across the MEC coverage areas [7].Full slice mobility that includes migration of all of the resources associated with the network slice causes inefficient use of sparse system resources and increases slice migration delay.With this motivation, we designed new NSM patterns, e.g., full slice mobility, partial slice mobility, and no slice mobility.The proposed approach includes mechanisms that allow only some of the network slice's identified resources to migrate when mobility is triggered.The proposed NSM patterns reduce slice migration delay, reduce MEC resource utilization, and maximize the slice acceptance rates.
The cloud-native microservices architecture supports the notion of new slice mobility patterns for network slicing in MEC.The creation of network slices as virtual network functions (VNFs) can be problematic as the conventional virtualization techniques do not provide the required scalability, portability, modularity, and flexibility [8], [9], [10], [11].The cloud-native approach is emerging as a promising candidate being actively adopted by the mobile network operators (MNOs) that redefine the working principles of network functions (NFs) and MEC services [8], [9], [10].The shift from legacy infrastructure to cloud-native infrastructure involves applying a new modular design, minimal hardware dependencies, a stateless and distributed model, and loosely coupled microservices.In this article, we leveraged the characteristics of the cloud-native approach to define a new architectural framework for NSM management in MEC.

A. Contribution
We propose an SDN-based cloud-native microservices architecture to address the mobility challenges emerging with dedicated network slicing when utilizing MEC resources in a highly dynamic and mobile environment, e.g., V2X.Our proposed solution implements new control functions, i.e., algorithms and modules, to manage MEC NSM effectively.The main contributions of this article are summarized as follows.
1) The proposed novel cloud-native microservices architecture for MEC network slicing leverages microservice modularity and portability characteristics to instantiate network slices.Service-specific dedicated network slices are deployed as a set of independently operating and loosely coupled microservices that the proposed SDN controller chains to complete a network slice.2) A stateless approach is proposed for network slices in MEC by separating the NF/MEC service operational data and the user application state.The separation provides a more flexible and scalable architecture where the network slices can be migrated across MEC servers more efficiently.3) In compliance with ETSI requirements for new inter-MEC system coordination modules in [12], we propose SDN-based modules and algorithms that allow federation between multiple MEC orchestrators (MECOs).The proposed modules allow the MECO to coordinate with the neighboring MECOs to offer resources, i.e., microservices.The coordination allows more efficient utilization of resource-constrained MEC servers by reducing the slice migration delay and maximizing the slice acceptance rate.4) To validate our proposed solution, we conducted Proofof-Concept (PoC) experiments in a highly dynamic and mobile environment, i.e., V2X.Most of the existing approaches in the literature that integrate network slicing and MEC do not consider the dynamic and mobile environment as compared in Table II.We also provided performance analysis comparisons with existing SDN-based approaches for NSM management in MEC.

B. Related Works and Research Gaps
Network slicing and MEC are two key enablers of 5G and beyond networks, and their integration is essential to support new services, e.g., URLLC for V2X.However, network slicing and MEC are the focus of two different standardization bodies, i.e., ETSI and 3GPP, thus, limiting integration efforts and idea cross-pollination [2].Several related works have covered network slicing and MEC integration and the proposals aim to solve challenges that have emerged during the integration efforts, e.g., resources management, slice selection, admission control, and NSM.Another focus has been proposals for new frameworks and architectures for network slicing and MEC integration, and slice resource management.However, network slice initiation and mobility challenges introduced by their integration in a highly dynamic and mobile environment demand further exploration.
Additionally, SDN is gaining traction not only as a mechanism to manage and control network traffic but also as a means to manage the tightly coupled network resources, such as network slicing in a MEC environment.Further research is ongoing into the role that SDN can play with network slicing and MEC integration.Our research focuses on the SDN-based integration of network slicing and MEC in a highly dynamic and mobile environment, e.g., V2X, where we aim to provide solutions for the slice initiation and mobility challenges.This research presents an SDN-based cloud-native microservices approach for network slicing in MEC.A summary of selected works found in the literature is shown in Table II.A comparison with our proposal is provided.
Addad et al. [13] and Shah et al. [15] proposed SDN and Kubernetes-based approaches, respectively, for parallel migration of containerized services within a network slice from one MEC server to another.However, the authors do not consider different aspects of NSM, e.g., MEC slice federation.They lack PoC experiments in a dynamic and mobile environment, e.g., vehicular networking.Cominardi et al. [1] and Ksentini and Frangoudis [2] proposed novel frameworks focusing on the importance of new control functions that are required to evolve the current MEC framework toward end-to-end network slicing support in 5G and beyond.However, the approaches do not consider mobility challenges.Addad et al. [6] proposed a reinforcement learning approach for the selection of optimal actions to refine the slice mobility decisions and network slice resources.Mlika and Cherkaoui [3] proposed a deep reinforcement learning-based solution to deal with the resource allocation problem in MEC-enabled vehicular networks.Du et al. [14] proposed an intelligent network slicing architecture that integrates edge computing and uses deep learning to classify and route the incoming packets from different applications toward MEC servers for applicationspecific processing.However, the author's mobility solution fails to consider some aspects, e.g., interslice resource federation and NSM, based on the resources available on the MEC server.D'Oro et al. [16] proposed a unified MEC slicing framework that supports heterogeneous slice services on MEC servers; however, the proposed approach does not consider the mobility aspects of network slicing in a MEC environment.Tang et al. [17] proposed a novel SDN-based network slicing architecture for UAV-enabled MEC that supports the creation of customized multidimensional resource slices and MEC services.The research highlights the importance of new  NSM patterns, i.e., partial and full slice migration, needed to realize network slicing at the MEC effectively.However, the research presents no practical mechanisms and methods to support the NSM patterns in highly dynamic scenarios such as the V2X.
Hejja et al. [18] proposed an algorithm implementing a centralized control plane and virtualized infrastructure to balance the load between various slices in one or multiple MEC servers.In [19], a novel end-to-end slicing architecture is envisioned that spans multiple domains, including the radio access network (RAN), core, and MEC.Jošilo and Dán [20] proposed an edge computing system under network slicing that supports the dynamic assignment of low-latency computational tasks from wireless devices to network slices at the MEC servers.
The proposed method jointly optimizes the computational offloading tasks assignment and radio resource management across network slices at MEC.A deep reinforcement learning approach is proposed for joint optimization of communication, computing, and cache resources in network slicing at the MEC environment in [21].Hossain and Ansari [22] proposed using network slicing at the MEC to efficiently utilize the limited MEC resources facilitating different types of applications and services requirements.The authors aim to reduce users' energy consumption in wireless networks by adapting optimal computational offloading decisions to network slices at the MEC servers.A two-level RAN slicing approach is proposed in [23] that uses a deep reinforcement learning algorithm to optimize the communication and computation of RAN Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.resources to meet the ultralow-latency requirements of end devices.Gong et al. [24] proposed a deep reinforcement learning approach for network slicing-based resource optimization in MEC that takes into account the diversity of the service requirements requested by the mobile users and dynamically optimizes the MEC resource allocation to meet the dedicated service requirements and maximize the profit achieved by the MNOs.
However, all the relevant research works [18], [19], [20], [21], [22], [23], [24] do not consider the NSM challenges that arise from network slicing and MEC integration.Unlike the recent state-of-the-art proposals, our proposed method focuses on a cloud-native approach for network slicing at the MEC and leverages novel SDN networking solutions to address the associated mobility challenges.Works found in [25], [26], [27], and [28] propose SDN-based solutions focusing on mobility aspects of service-specific dedicated slices across MEC servers while also considering a highly dynamic vehicular network environment.However, the SDN controller only triggers full slice mobility from one MEC server to another.The authors do not propose mechanisms where selected resources within a network slice are migrated across MEC servers for reduced network slice migration delay and more efficient utilization of the limited resources.Additionally, the existing approaches do not consider algorithms that allow resource sharing between the migrated network slice and the existing network slices in a MEC server.
In contrast to the conventional state-of-the-art approaches, we propose an SDN-based cloud-native microservices architecture for NSM management in MEC.The proposed solution leverages microservices functionalities, e.g., modularity and portability, to instantiate service-specific dedicated slices.The proposed SDN-based algorithms coordinate with neighboring MEC servers to minimize the resources that need migration and support interslice resource sharing to reduce slice migration delay and maximize slice acceptance rates.

II. SDN-BASED CLOUD-NATIVE ARCHITECTURE
FOR MEC NETWORK SLICING This section describes the SDN-based cloud-native microservices architecture for NSM management in MEC.The design of our proposed architecture can be seen in Fig. 1.

A. System Model
We considered vehicular networks as a scenario for our proposed architecture.A vehicular network provides a dynamic and complex environment with strict performance requirements.Our scenario consists of sets of OpenFlow capable eNodeBs/RAN/RSUs e ∈ E, each equipped with its own MEC server m ∈ M, and an SDN controller.The MEC servers offer a number of service-specific dedicated slices s ∈ S, where each slice contains a set of microservices i ∈ I, as shown in Fig. 1.There are U users, i.e., vehicles, u ∈ U, where each vehicle requests access to one service-specific dedicated slice running at the closest MEC.The microservices are executed as lightweight Docker containers chained by the SDN controller to provide a service-specific dedicated slice.Time is divided into T time slots, where at each time slot t ∈ T, the mobile user u ∈ U requests the service-specific dedicated slice from a MEC server m ∈ M. For ease of reference, the list of commonly used acronyms in this research is provided in Table I, and a list of key notations is summarized in Table III.

B. Computation Model
We consider that each mobile user has computational tasks with strict latency requirements.Therefore, the user needs access to the service-specific dedicated slice from the MEC server to meet its stringent performance requirements via computational offloading.The computational model can be defined in three steps following the models introduced in other related works [29], [30], [31].First, the mobile users request the service-specific dedicated slice by uploading a specific size of data that needs to be processed by the MEC server through the RAN.The RAN forwards the data for processing to its respective MEC server.Then, the proposed approach allocates a part of the total MEC computational resources to the mobile user by instantiating a service-specific dedicated slice.Finally, the processed results from the MEC server are returned to the mobile user.Accordingly, the computational model could be defined by the processing delay of all these steps, e.g., the transmission delay or MEC communication delay, the processing delay or the MEC slice computation delay, and the downloading delay of the processed result.
1) MEC Communication Delay: When the mobile user u requests a service-specific dedicated slice s from the MEC server m, the communication delay is dependent upon the achieved data rate, the wireless channel conditions, and size of the requested service [32].The channel gain between the mobile user u and MEC server m at time t is represented by g t um , and the signal-to-noise ratio can be defined as where p m represents the MEC server transmit power, σ 2 represents the noise power, and I M represents the accumulated interference from neighboring MEC servers [33], [34].The achieved data rate can be defined as where b m is the bandwidth allocated by the MEC server m.
The communication delay between the MEC server m and the mobile user u requesting a service-specific dedicated slice at time t can be defined as where s u represents the size of the service requested by the mobile user u.The downloading delay of the processed service requests, also largely depends upon the size of the processed results and the download data rate of the mobile user u [29], [30], [31].

2) Slice Computation Delay:
The slice computation delay depends upon the resources allocated to the service-specific dedicated slice within a MEC server by the proposed SDN controller, and the required computation capacity of the mobile user u at time t [32], [35].The computation delay between the service-specific dedicated slice s in MEC server m and the mobile user u at time t can be defined as where c t us represents the requested computation capacity in [CPU cycles] for MEC slice s by vehicle u at time t, RS max sm represents the maximum computation capacity allocated to the slice s within a MEC server m, and L t sm represents the current computational load on the slice s within a MEC server m, i.e., the number of mobile users using the same service-specific dedicated slice s at time t.

C. Slice Migration Delay
The slice migration delay represents the service downtime when the slice mobility is initiated between multiple MEC servers.The slice migration delay is the time taken to complete the slice mobility, i.e., the microservices required for a service-specific dedicated slice, in-memory state, and configuration files are transferred to the candidate MEC server.A new slice is instantiated upon migration of slice resources containing the microservice and associated configurations.The slice migration delay can be defined as The slice migration delay is 0 when the service-specific dedicated slice is located at a MEC server and does not require migration.Here, s md represents the slice migration delay when the dedicated slice needs mobility from the current MEC server toward the candidate MEC server.In our Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.
proposed cloud-native microservices architecture for network slicing, dedicated slices are initiated at MEC servers containing one or more microservices.Therefore, the slice migration delay depends on the number of microservices within a slice that needs migration toward the candidate MEC server, the size of the microservices, and the system capacity, i.e., system bandwidth and resources of the candidate MEC system.The slice migration delay s md can be represented as (6) where I i=1 MS s i represents the sum of the sizes of all the microservices I within a MEC slice s that require mobility, and CP a m c represents the available capacity of the candidate MEC server m c , i.e., bandwidth and computation resources.
Our proposed cloud-native microservices architecture leverages SDN federation modules that allow inter-and intra-MEC system coordination to reduce the number of microservices within a slice that needs migration.The coordination between MEC systems allowed by the proposed federation modules reduces slice migration delay.

D. Slice Acceptance Rate
The slice acceptance rate represents the percentage of the network slice requests including both the new slice instantiating and slice mobility requests accepted by the MEC server.It could be defined as the ratio of the number of network slice requests accepted by the MEC server to the total number of requests received by the MEC server where SA m represents the slice acceptance rate of the MEC server m, N m represents the number of network slice requests accepted by the MEC server m, and N total m represents the total number of network slice requests received by the MEC server m.

E. MEC Resources Availability and Slice Utilization
MEC provides limited network resources that can be insufficient to deal with a massive increase in traffic due to the advent of IoT and the rising demands for the provision of low-latency dedicated network slices.Therefore, it is essential to optimize the resource availability of MEC servers by offering the maximum number of service-specific dedicated slices to the users.Our proposed solution leveraged cloud-native microservices functionalities for slice initiation and mobility and implemented practical algorithms to ensure inter-MEC systems federation, slice resources sharing, effective distribution of network slices, and MEC resource utilization.The MEC resource availability and slice utilization function is represented as where S s=1 RS t sm represents the sum of the system resources, e.g., bandwidth, being used by all the slices S within MEC server m at time t, and RS max m represents the maximum system resources, i.e., the system capacity of MEC server m.
The optimization goal is Our proposed solution aims to ensure inter and intra-MEC system coordination for sharing slice resources and optimizing MEC resource utilization.The objective is to maximize the availability of resources on MEC servers to support the initiation and mobility of new slice requests while fulfilling the dedicated slice-specific performance requirements, i.e., latency and throughput.This is achieved by utilizing the modularity, portability, and independently deployable microservices functionalities that the proposed cloud-native approach offers.Constraint C1 means that the resources allocated to slice s in MEC server m are greater than or equal to the minimum resources required, i.e., minimum threshold bandwidth requirement, to achieve the required performance of that dedicated slice.Constraint C2 means that the sum of the resources allocated to all the network slices in MEC server m at time t cannot exceed the maximum system capacity of the MEC server.

III. SDN-BASED MEC SLICE MOBILITY MANAGEMENT
This section explains the working principles of our proposed SDN-based cloud-native microservices architecture for NSM management in MEC, as shown in Fig. 1.

A. Inter-/Intra-MEC System Slice Federation Manager
The current MEC architecture does not include a system entity that can communicate with other MEC systems to support the federation of network slice deployment and mobility management [12].ETSI specifies the importance of new entities in the MEC architecture to facilitate inter-MEC coordination for network slice federation scenarios [12].The federation manager should support inter-MEC system communication with security, flow control, application life cycle management, resources, and services availability discovery and publishing.In the case of user mobility, the proposed SDNbased federation module establishes communication with the SDN-based federation manager of neighboring MEC systems closer to the user position as determined by the RSSI indicator and requests slice migration.The SDN-based federation module uses the mobility management function of AMF to maintain information about user location within the network.The periodic registration updates completed by the user are used to track the user's location and coverage zone.The SDN controller uses the location updates from the AMF mobility management function and MEC radio network information service to select the optimal UPF and MEC server closer to the user position for maximum performance.
The source federation module sends the network slice selection assistance information (NSSAI) to the neighboring members of the federation.The federation manager of the neighboring MEC system collects the topology information and returns a list of available resources (ARs) and microservices.The source federation manager receives a response from the federated MEC systems and performs comparisonbased sorting to get the candidate MEC system prioritizing partial slice mobility and no slice mobility patterns.Partial and no slice mobility patterns are designed to support scenarios where the microservice(s) required to complete the NSM is already running and available to the neighboring federated MEC systems.Selected slice resources are migrated to reduce slice migration times, as shown in Fig. 2. Partial slice mobility patterns allow for more efficient use of candidate MEC system resources.If the source federation manager does not identify a candidate MEC server with microservices availability, it selects the candidate MEC server with the most resources available to facilitate full slice mobility.The detailed information analysis on the procedure is provided in Algorithms 1 and 2 and can be seen in Fig. 2.

B. Microservices Migration and Service Chaining
The proposed microservices architecture offers improved scalability, independency, and portability of network slices across MEC servers.A service-specific dedicated slice is distributed into a collection of independently deployable and loosely coupled microservices.Microservices allow service developers to break down the complexity of the 5G ecosystem as the NFs and services can be developed independently, scaled, and distributed efficiently.Our proposed architecture uses the microservices features to develop a more effective solution for NSM across MEC servers.The proposed solution reduces the slice migration delay by implementing the following NSM patterns.
1) Partial Slice Mobility (Microservices Chaining): NSM is required when a mobile user served by a service-specific dedicated slice at a source MEC server moves outside the coverage area toward the candidate MEC server.The SDN controller for the source MEC server coordinates with the federated SDN controllers to request slice mobility.The candidate SDN controllers in the federation send the topology information containing a list of the currently active and available slices, i.e., microservices, running on adjacent respective MEC servers.A comparison-based sorting algorithm is used to select a candidate MEC server with a slice that is active that contains one or more of the microservices required for the slice mobility to proceed.This partial slice mobility pattern reduces the slice resources that need to be migrated toward the candidate MEC servers where only the microservices not available on the candidate MEC server are migrated, as shown in Fig. 2. The SDN controller in the MEC system provides a gateway to provide connectivity to the microservices and performs service chaining, i.e., chaining microservices, to create a service-specific dedicated slice.This process can be seen in Fig. 3.
In the proposed architecture, the service-specific dedicated slices are offered in MEC by instantiating containers and dynamically applying the microservices to traffic from the user toward the MEC server.The SDN controller performs microservices chaining by creating a tunnel across the underlay network spanning through the microservices in the chain, as shown in Fig. 3.
2) No Slice Mobility: The no slice mobility pattern is triggered if the comparison-based sorting algorithm results in a candidate MEC server with one or more microservices required for slice mobility but not enough resources to support the migration of the remaining microservices.In this case, the SDN controllers of the corresponding MEC servers coordinate to form service chaining across multiple MEC servers reducing the need for migrating microservices to complete the slice mobility process, as shown in Fig. 3.Alternatively, the no slice mobility pattern is triggered; if the comparisonbased sorting algorithm results in a candidate MEC server with all the required microservices available to complete the slice mobility.In this case, no microservice is migrated, and only the SDN controllers of corresponding MEC systems coordinate to redirect the user traffic from the source MEC server toward the candidate MEC server.
3) Full Slice Mobility: The full slice mobility is a more conventional slice mobility pattern.Full slice mobility is required when the comparison-based sorting results in a candidate MEC server being selected without available microservices (AMSs) required to complete the partial slice mobility but enough unused resources available for full slice mobility.In this case, the microservices required to complete NSM are migrated toward the candidate MEC server closer to the user position.

C. Stateless Architecture for Network Slicing in MEC
The proposed architecture separates NFs and MEC services operational data and user context, i.e., application state, allowing more flexibility, scalability, and portability of servicespecific dedicated network slices in MEC.The separation allows each MEC service and NF to operate independently by storing the user state in a remote central database, i.e., unstructured data storage function (UDSF).The proposed decoupling and adaption of a microservices architecture allows more efficient mobility of network slices across MEC servers as the user moves around the coverage areas of different MEC servers.The implementation of the stateless architecture for 5G NFs and MEC services to support efficient NSM across MEC servers is shown in Fig. 4.
In our proposed solution, the federation manager module, i.e., SDN-based, coordinates with the neighboring federation members and triggers the slice mobility actions using the proposed algorithms.The SDN controller selects the optimal user plane function (UPF) to steer the mobile traffic toward the new slice instantiated at the candidate MEC server.The controller then installs flows to establish connectivity between the NF, i.e., UPF and UDSF, to fetch the user state, ensuring service continuity.The centralized database model for storing application states can provide more flexibility in NSM management and reduce the service migration delay.The brief introduction of functionalities for parameters used in Fig. 4 supporting the stateless architecture for network slicing in MEC is as follows.
1) Store_State_Records_id: The SDN controller uses the parameter to store the Slice ID, corresponding MEC ID, 1) The proposed SDN controller dynamically stores and updates the identification information, e.g., Slice ID, MEC ID, the microservices required per slice, and the application states relevant to these identifiers, in the new centralized database UDSF.The dynamic storage of application states and corresponding identifiers in the centralized database allows all the neighboring SDN controllers and their respective MEC servers participating in the federation to fetch the corresponding application and slice configurations, e.g., microservices and the application states.The centralized architectural approach supports flexible network slice migration across MEC servers.2) As the mobile user moves outside the coverage area of one MEC server to another, the SDN controller of the source MEC server communicates the NSM indicator, i.e., NSM=1, to the candidate SDN controllers and their respective MEC servers.The source SDN controller then triggers the network slice migration, e.g., migration of microservices required to complete slice migration and the corresponding identifiers described in the first step.
3) The candidate SDN controller completes the network slice migration at its respective MEC server.Then, it fetches the corresponding application states relevant to the mobile user from the centralized database UDSF.

D. Interslice Resources Sharing and Slice Scalability
The proposed architecture allows the creation of network slices in MEC servers by instantiating the slice-specific independent and loosely coupled microservices.The cloud-native modular design allows microservices commonly required in one or more slices within a MEC server to be shared, resulting in more effective utilization of MEC resources.We implemented SDN-based federation modules to compute the requirements for new slice creation requests in a MEC server and collect the topology information, e.g., microservices and slices offered.The proposed solution performs comparison-based sorting to determine if microservices are already running that could be shared with the new slice creation request, as seen in Fig. 2. The detailed process is provided in Algorithms 1 and 2. The proposed architecture supports dynamic slice scalability as the federation modules consistently monitor the computational load on microservices within a slice.If the computational complexity exceeds the maximum computational capacity that the microservice can support, the federation modules scale the network slice by instantiating a new microservice instance with similar configurations.In the case of an underutilized microservice instance in a MEC network slice having more than one microservice instances, the federation module scales down the network slice by deleting the microservice instance.

E. Algorithms
The pseudocode for the proposed SDN-based algorithms for NSM management in MEC is provided in Algorithms 1 and 2. The algorithms provide a detailed low-level information analysis of the proposed SDN modules that support inter-and intra-MEC system coordination for effective resources and NSM management.Algorithm 2 enables coordination between Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.the SDN controllers of corresponding MEC systems to determine the optimal candidate MEC server for the mobility of a service-specific dedicated slice.The decision is based on two criteria, i.e., the availability of the required microservices to complete the MEC slice mobility in the candidate federated MEC servers and resource availability on the MEC servers.Algorithm 1 completes the deployment of the service-specific dedicated slices in MEC servers, fetches the slice-specific configuration details from the remote centralized database, UDSF, and updates the centralized UDSF database if new microservices related to slice ID are launched.The selection of optimal UPF based on the location of the MEC server where the slice is instantiated, and the handover of user traffic from the source toward the candidate MEC server, is also a function provided by Algorithm 1.The brief introduction of some of the significant components and parameters used in the algorithms is as follows.
1) Slice_svc_id: A unique ID for a slice that is unique to each service.

IV. PERFORMANCE EVALUATION
We used Mininet-WiFi [36] and containernet [37], two popular forks of mininet that allow simulation of SDNcapable access points (APs), remote side units (RSUs), wireless stations, and docker services and applications, respectively.AP/RSU/eNodeB are modeled by configuring the data rates, signal ranges, and physical channel characteristics.The proposed solution is radio access technology (RAT) agnostic and can be applied to both the Wi-Fi and 5G networks, a requirement defined by the ETSI in [38].The Ubuntu OS system is used for simulation and equipped with a Core i5 CPU and 8-GB RAM.We simulated a vehicular network scenario where vehicles are modeled as SDN-capable wireless stations requesting one or more URLLC network slice(s) from the MEC server of the corresponding APs/RSUs at each time interval t.The MEC servers are executed as Docker container hosts using the capabilities of the containernet emulator [37].The MEC servers are directly connected to the APs/RSUs using a wired connection.
The SDN controllers are deployed following a multicontroller distributed approach where an individual and centralized controller only manages its own network, i.e., RAN, and

Generate_Total_Microservices_Required (TMSR)
The source controller generates a set of microservices required to complete slice mobility 8: Query shared database to get MECF 9:

else if Cand_Sel_MS=0 then
There is no candidate in MECF having one or more required microservices 20:

38:
Storing MSRI in SSMS 39: Algorithm1 to instantiate a new MEC slice 40: end if 41: Back to begin coordinates with the SDN controllers of neighboring networks.The number of SDN controllers and their corresponding edge networks used in this evaluation scenario can be seen in Table IV.An individual SDN controller manages each RAN and its corresponding MEC server, i.e., RYU, that implements the federation modules using the proposed algorithms, i.e., Algorithms 1 and 2 , for effective NSM management in MEC.As Mininet-WiFi [36] supports the emulation of OpenFlow-enabled APs, we used the extended forwarding module proposed in one of our recently published research works [28] to integrate the RANs with the SDN controller.The extended forwarding module supports RANs to capture the network information, i.e., RSSI and network load, and forwards the network performance indicators by generating a packet_in message to its respective SDN controller managing the network.The SDN controller then extracts the information and the network performance indicators using the get_protocol method as defined in [39] to have a global view of the underlying network.More detailed information on the extended forwarding module can be found in [28].
Each slice within a MEC server is modeled as a set of resources implemented as independently operating microservices chained by the SDN controller to complete a network slice.The microservices are independent deployable modular services running as docker containers.The dynamic resource allocation, e.g., bandwidth, to network slices is an optimization problem that has been widely addressed in the literature and is out of the scope of this research [40], [41], [42], [43].We assumed equal bandwidth allocation to all the slices and microservices within a MEC server and MEC slice, respectively.The simulation parameters used in the performance evaluation are summarized in Table IV.

A. Comparison Approaches and Algorithms
We compared our proposal to similar approaches from the literature that use SDN-based solutions for NSM management in MEC.The approach proposed in [13] uses SDN-based migration modules to trigger the slice mobility across different MEC servers.The solution proposed parallel migration of containerized services in a network slice from the source toward the candidate MEC server based on resource availability.SDN manages the path redirection to restore the slice upon migration of the service.The proposed solution only supports full slice mobility and does not provide any practical mechanism to migrate identified resources of a slice for partial slice mobility patterns.In another similar SDN-based approach for NSM management in MEC evaluated in [27], the network slices and their states are migrated to the candidate MEC server before the handover phase.This premigration technique ensures precached configurations to reduce the handover delay and slice migration time.These two approaches are named SDN-based parallel migration (SDN-PRLM) and SDN-based precache (SDN-PCH), respectively.We also compared the proposed approach to the conventional algorithms.The algorithms are defined as follows.
1) SDN-PRLM (Full Slice Mobility): The SDN modules trigger the migration process of the entire network slice and the associated resources in a MEC server toward the candidate MEC server.The approach does not include any mechanisms supporting inter-MEC system coordination for interslice resource sharing and cooperative NSM.Therefore, SDN only triggers full slice mobility toward the candidate MEC server using parallel migration techniques.only selected resources in a network slice supporting partial slice mobility patterns.4) Slice Scalability: This metric compares the capability of approaches under evaluation to dynamically adapt to the increase or decrease in the computational load on the network slice by adding or removing resources.5) Throughput and Latency: This metric compares the throughput and latency achieved by the mobile user upon completion of slice mobility and user relocation from the source MEC server toward the candidate MEC server.

C. Simulation Scenarios and Results
We simulated a V2X network slicing scenario where vehicles were randomly distributed around the 800 m of urban roadway in Manhattan (NYC), i.e., a map of Manhattan roads generated in SUMO urban mobility simulator [44].The modeling and configuration of vehicle mobility traces are carried out using SUMO, which is an open-source simulator extensively used in V2X research as it provides realistic vehicular mobility traces and applications [7], [45].The vehicles were randomly distributed across the roads to simulate the various MEC server resource availability.The vehicles were configured to move on Manhattan roads following a random waypoint mobility model.A random waypoint mobility model is used to simulate the vehicle's mobility as described in [46], [47], and [48].This mobility model presents one of the most dynamic and complex environments, as it contains a wide range of moving patterns along the path.Each vehicle requests a URLLC slice from the MEC server by sending the NSSAI to the RAN.The RAN requests the MECO, i.e., SDN controller, to compute the resources required, i.e., microservices, to complete the slice initiation or mobility requests.The SDN controller uses the proposed algorithms to complete the vehicle slice requests.In the following cases, vehicle relocation refers to the NSM required when the vehicle moves outside the coverage of its serving MEC server toward the candidate MEC server.
1) MEC Resource Availability and Slice Acceptance Rate: In our proposed solution, the dedicated slices are offered as a chained set of microservices to complete the network slice.The MECO, i.e., SDN controller, receives requests for network slice initiation or mobility from the vehicles and uses the proposed algorithms to enable federation among MEC systems.The federation allows identifying network slice resources, i.e., microservices, that could be shared between multiple network slices to reduce the MEC resource utilization.The modularity and flexibility offered by the proposed cloudnative microservices architecture allows for more effective use of MEC resource utilization, increasing the slice acceptance rate so that more requests for a MEC slice initiation or mobility can be facilitated.In this simulation scenario, we assumed that the MEC slices require four microservices to complete a service-specific dedicated network slice.After deploying the first network slice at the MEC server, the corresponding network slice requests demand common resources, i.e., two microservices in common between the first network slice initiated at the MEC server and the corresponding network slice requests.The assumption is made to evaluate the capability of our proposed solution to identify common resources and share them among multiple network slices increasing the MEC resource availability and slice acceptance rate.Our proposed solution takes full advantage of the modularity the cloudnative microservices approach offers to share the resources among multiple network slices.The interslice resource sharing increases the resource availability at the MEC server and the slice acceptance rate, i.e., more network slices are offered at the MEC server, as shown in Fig. 5(a) and (b).
The SDN-PRLM and SDN-PCH approaches do not offer the same modularity that is enabled by the proposed cloud-native microservices architecture.The approaches do not include any mechanisms to share resources among different network slices in a MEC server.Therefore, the SDN controller completes the slice initiation or mobility process for each request received for the network slice by deploying the required resources.Full slice mobility results in inefficient utilization of MEC resources and reduced slice acceptance rates, as shown in Fig. 5(a) and (b).In contrast to our proposed and the SDN-PRLM approaches, which consider the availability of the required resources before accepting the slice admission requests in mobility scenarios, the SDN-PCH approach does not consider the resources available in slice acceptance Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.decisions.The SDN-PCH approach constantly accepts all the slice admission requests while violating the Quality-of-Service (QoS) requirements for the network slices (URLLC slices) in a MEC server, as shown in Fig. 5(a).

2) Slice Migration Delay:
The proposed solution allows federation among multiple MEC systems, where the federated MEC systems coordinate to share topology information, i.e., network slices offered and resources available.The coordination allows the SDN controller managing the MEC systems to make effective decisions for NSM.The objective of the proposed federation modules is to reduce the migration delay for the slice migration requests.In our simulation SDN controller of the serving MEC system triggers NSM for five slices of variable sizes containing a different number of microservices, e.g., slices 1-5 consist of 1-5 microservices, respectively.We assumed that for NSM requests for slices 2-5, MEC systems are participating in the federation with at least one or a maximum of two microservices already available as a part of dedicated network slices offered at the corresponding MEC servers.This assumption is made to evaluate the capability of our proposed solution to identify an optimal candidate federated MEC system with one or more required microservices available, therefore, reducing the slice resources that need migration.On vehicle relocation in our proposed scenario, the SDN controller of the source MEC system implements the proposed algorithms to determine the optimal candidate federated MEC system that has the most microservices available to complete the slice mobility.The source SDN controller identifies the slice resources that need migration and triggers the migration along with the state parameters, e.g., stateless architecture parameters, required by the candidate SDN controller to fetch the MEC slice service states.Our proposal ensures that a minimal resource migration is required to complete the slice mobility and, hence, reduce the slice migration delay, as shown in Fig. 6(a) and (b).
In SDN-PRLM and SDN-PCH, there are no mechanisms to identify the resources that are to be migrated from the source MEC server to the candidate MEC server to complete the NSM.Therefore, the SDN controller triggers full slice mobility to migrate the slice resources, thus, taking more time to complete the slice mobility as shown in Fig. 6(a) and (b).The impact of varied available system bandwidth on the candidate MEC server can also be seen in Fig. 6(a) and (b), where increasing bandwidth can reduce the slice migration delay.The increase in system bandwidth reduces the latency experienced while provisioning the container images, configuration, and templates, required to complete NSM, e.g., slice resources.
3) Slice Scalability: One of the major advantages of the proposed solution is the network slice scalability offered by cloud-native microservices architecture for network slicing in MEC.As the proposed solution uses the modularity offered by the microservices to enable federation across network slices in MEC servers, i.e., sharing resources among multiple slices, it is essential that the architecture is scalable and can dynamically adapt network slices QoS requirements.In our proposed solution, the MECO, i.e., the SDN controller, consistently monitors the resources offered and shared by the network slices in a MEC server.In the event of a significant increase or decrease of the computational load on the identified resources, i.e., microservices, the controller dynamically scales the network slice resources, which is one or more microservice instances are added or removed.The network slice scalability ensures the QoS requirements are met while minimizing the resource utilization of MEC servers, shown in Fig. 7(a) and (b).
4) Throughput and Latency: A comparison of the throughput and latency metrics, for the approaches under evaluation, was carried out.Our proposed solution triggers NSM from the current serving MEC server toward the candidate MEC server on vehicle relocation.The proposed solution leverages the SDN-based federation modules to trigger two types of NSM decisions, i.e., partial slice mobility and full slice mobility.In partial slice mobility, only selected resources of a network slice are migrated to the candidate MEC server.In contrast, all of the resources are migrated toward the candidate MEC server in full slice mobility.In both cases, upon vehicle relocation, the vehicle can achieve consistent network performance, i.e., throughput and latency, and maintain the QoS requirements as shown in Fig. 8(a) and (b).
In the SDN-PRLM case, the SDN controller triggers full slice mobility, i.e., parallel migration of the services in a slice, toward the candidate MEC server having the most Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.resources available.Upon vehicle relocation, it maintains its QoS requirements, as shown in Fig. 8(a) and (b).However, this approach always triggers the full slice mobility decision that increases the slice migration delay and resource utilization of the candidate MEC server.In the SDN-PCH case, the SDN controller always triggers full slice mobility decisions toward the candidate MEC server without considering resource availability.The network slice is always migrated toward the next available MEC server, e.g., the closest MEC server, which increases the computational load on the candidate MEC server.Therefore on vehicle relocation, the vehicle is unable to maintain its required QoS requirements, as shown in Fig. 8(a) and (b).The network slice is not migrated toward the candidate MEC server in a conventional case.The current MEC server continues to serve the vehicle upon relocation and irrespective of the vehicle location.Therefore, upon vehicle relocation, the network performance, i.e., QoS, achieved by the vehicle continues to degrade consistently as the vehicle moves further away from the current serving MEC server, as shown in Fig. 8(a) and (b).

V. CONCLUSION
This work proposes an SDN-based cloud-native microservices architecture for network slicing in MEC that provides service-specific dedicated slices as independent, loosely coupled, and stateless microservices, chained by the SDN controller.The proposed architecture separates the NFs and MEC services operational data and the user context data, i.e., application state.The modularity, portability, and the stateless characteristics of the proposed cloud-native architecture make it an effective solution for NSM management in MEC.The cloud-native 5G architecture is evolving as a promising candidate solution that allows the networks to adapt to changing demands and support new services dynamically.However, the evolving cloud-native 5G architecture also brings challenges as the microservices are hosted in independent containers or servers.The distributed system model leveraging the microservices increases the operational complexity, e.g., communication and chaining of the microservices to complete a network slice.
The proposed SDN-based federation modules effectively manage resource-constrained MEC servers by offering servicespecific dedicated slices as a set of microservices in a dynamic mobility scenario, e.g., V2X.As the development of the management and control plane for network slices in the MEC is still in its early stages, our proposed solution emphasizes the potential of an SDN and cloud-native microservices architecture in effectively managing the MEC network slices in a highly dynamic and mobile environment.The proposed solution is compared with the existing and conventional SDNbased approaches to analyze the performance in terms of slice Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.
acceptance rate, slice migration delay, MEC resource utilization, and QoS performance indicators.The simulation results show that the proposed solution outperforms the existing SDN-based approaches.

A. Integration With Kubernetes
For future work, we aim to extend the proposal to integrate the functionalities of the container orchestrator platform, i.e., Kubernetes.The integration would allow more effective management of MEC slice resources, e.g., microservices life cycle management, scalability, and availability.The integration can also reduce the computational complexity of the SDN controller managing the MEC system, where the controller would act as a centralized MECO coordinating with the neighboring MEC systems for slice federation and communicating with the Kubernetes orchestrator for slice resources management.The Kubernetes orchestrator would be responsible for microservices resource monitoring and life cycle management.

B. Cloud-Native 5G Core Adaption
The adaption of cloud-native 5G core and the development of NFs and MEC services as microservices is essential to utilize the cloud-native functionalities, e.g., NFs and MEC services modularity, scalability, network flexibility, portability, and efficient use of limited storage and computing capabilities of MEC servers.The core NFs and MEC services should be designed to be fully compatible with the microservices design to adapt to the cloud-native microservices architecture.For example, developing a UPF as a packet processing solution that operates independently as a microservice and steers the traffic from the vehicle toward the dedicated network slices in the MEC server.

C. Slice Recovery and Interslice Communications
Meeting the high-reliability requirements is essential to deal with the massive increase in demands for URLLC services.Fast slice recovery mechanisms should be adapted to overcome slice failures affecting the network infrastructure, and performance [49].The development of such mechanisms becomes more complex and essential in network slicingenabled MEC architectures because of limited resources offered by MEC servers and many slices always competing for resources.Moreover, optimizing interslice communication is a significant research challenge in 5G network slicing [50].In particular, the interslice communication in the network slicing-enabled MEC domain needs further exploration.

26 :
Cand_Sel_RS= Sort max (AR) Sorting algorithm to sort and find the candidate MEC with max AR 27:

Fig. 5 .
Fig. 5. Evaluation of acceptance rate for slice initiation and mobility requests and MEC resource utilization.(a) Slice acceptance rate.(b) MEC resources availability.

TABLE I LIST
OF COMMONLY USED ACRONYMS IN THIS ARTICLE

TABLE II PROPOSAL
COMPARED TO THE LITERATURE

TABLE III NOTATIONTABLE
AMSs and ARs: The parameter AMS contains information about the slice resources, i.e., microservices requiring migration to complete the NSM, readily available on the participating MEC systems in the federation.The parameter AR contains information about the resources offered by the federation members.
The SDN controller determines TMSR when the vehicle moves outside of the coverage area of the current serving MEC server and triggers the mobility of TMSR.If there are no microservices in common between the serving and the candidate MEC server, the microservices are migrated to complete full slice mobility.12) O(M), where m is the number of MEC servers participating in the federation.The candidate MEC selection for NSM or network slice instantiation, depending upon the availability of microservices and resources, takes time O(M log (M)), based on the comparison-based sorting algorithm (Algorithm 2).The selection of optimal candidate UPF and the handover from the source SDN controller to the candidate SDN controller takes time O(1) (Algorithm 1).Therefore, the overall time complexity of the algorithm is O(M log (M)).
Slice Migration Delay: This metric compares the migration delay, i.e., the time taken when the network slices migrate toward the candidate MEC servers from the source.The metric provides performance analysis on the capability of the approaches under evaluation to migrate Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.