# A Novel Framework for Cross-Cluster Scaling in Cloud-Native 5G NextGen Core
## 2 Related Work  
The existing body of literature around network slicing is divided between virtualization achieved in the MANO framework with a dedicated orchestration function and Kubernetes deployments that cover the full stack, including the flexibility of network functions, service recovery, and monitoring. The MANO framework handles dynamically  
Figure 1: Proposed framework for network slicing in cloud-native 5G core. the onboarding, instantiating, scaling, and terminating of network slices, while OSS/BSS (Operations and Business Support Systems) is responsible for the static provisioning and de-provisioning of network slices in a virtualized environment. From a virtualization point of view, a classification encountered in the literature consists of two categories of testbeds that address the deployment of network slices: the first category is limited to a set of functionalities; the second one addresses the end-to-end capabilities. Initiation of the network slicing is present in many of the existing open-source systems, such as OSM [4] and ONAP [3], SONATA [20], OpenStack Tracker [21], and Cloudify [22]. However, both OSM and ONAP systems offer mechanisms to track and restore the services. The authors [PERSON] et al. are addressing in paper [23] the challenges and gaps of the OSM and ONAP in terms of missing full stack functionality. The authors propose several benchmarks for both functional and operational KPIs that are validated in their test scenarios. The first category we address does not tackle the E2E network slicing [14; 24; 25; 26]. For instance, [PERSON] et al. are deploying in paper [24] the network function instantiation and management based on OPNFV [27], with OpenStack [28] as VIM (Virtualized Infrastructure Manager) and VMware [29] as a hypervisor. This approach shows the capability of NFVO (NFV Orchestrator) to serve as a network service and resource orchestrator. The second kind of virtualization testbeds encompasses the full stack capabilities of MANO for management of E2E network slicking [30; 31; 32; 33; 34; 35; 36; 37; 38; 39]. In this regard, the authors [PERSON] et al. introduce in paper [33] a slightly different architecture where the network slices are coordinated at both MANO and OSS/BSS levels. A qualitative comparison of three systems is conducted: Tracker, standalone OpenStack, and free5 GMANO [40] in terms of configuration and fault management of the network slices. In regards to Kubernetes deployments, there are also several tools available that leverage the DevOps capabilities of Kubernetes. An open-source tool of this kind in which network slicing initiation occurs at both MANO and OSS/BSS layers is Aether [37]. The design consists of a set of centralized components named _Aether Central_, which manages several edge sites. Other tools such as 5G-Berlin [38] and 5 Genesis [39] present a 5G network to deploy and run applications of verticals on top of NFV infrastructure. Network slicing capabilities as well as mobile edge computing are addressed in a cloud-native NFV MANO implementation. The cloud-native deployments can also be categorized in two different directions: the first one presents the standalone deployments enhanced with monitoring capabilities, whereas the second category looks at multi-cluster deployments that can be monitored and observed through service-mesh solutions. Currently, no Kubernetes-native standard is defined, but some popular standards have emerged (such as Prometheus [41] and OpenTelemetry [42]) for monitoring and collecting metrics purposes, where KPI solutions can be configured. A significant amount of papers envision the mobile 5G core as a cloud-native application orchestrated in a standalone Kubernetes cluster [43; 44; 45; 46]. In paper [47], the authors [PERSON] et al. describe in depth the CI/CD provisioning workflow of the 5G mobile core and introduce a customized Kubernetes operator called Kube5G-Operator. This operator aims to provide both reconfiguration and reconciliation in case of service failure based on the CR (custom resources).