<figure><img src="image_1.png" /></figure>

HAL
open science

# Mobile Edge Slice Broker: Mobile Edge Slices Deployment in Multi-Cloud Environments

Samia Boutalbi, Nizar Kheir, Remous Aris Koutsiamanis, Mario Südholt, Yann Dan Moussa

► To cite this version:

Samia Boutalbi, Nizar Kheir, Remous Aris Koutsiamanis, Mario Südholt, Yann Dan Moussa. Mobile Edge Slice Broker: Mobile Edge Slices Deployment in Multi-Cloud Environments. ICFEC 2023: 7th IEEE International Conference on Fog and Edge Computing, May 2023, Bangalore, India. pp.1-6, 10.1109/ICFEC57925.2023.00016 . hal-04052250

HAL Id: hal-04052250

https://hal.science/hal-04052250

Submitted on 1 Apr 2023

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_2.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Mobile Edge Slice Broker: Mobile Edge Slices
## Deployment in Multi-Cloud Environments

1st Samia Boutalbi

R&D Center, Ericsson

Massy, France

samia.boutalbi@ericsson.com

2nd Nizar Kheir

Amazon Web Services

Nanterre, France

nizar.kheir@gmail.com

3rd Remous-Aris Koutsiamanis

STACK team, IMT Atlantique

Nantes, France

remous-aris.koutsiamanis@imt-atlantique.fr

4th Mario Südholt

STACK team, IMT Atlantique

Nantes, France

mario.sudholt@imt-atlantique.fr

5th Yann Dan Moussa

R&D Center, Ericsson

Massy, France

yann.dan.moussa@ericsson.com

**Abstract**—Harnessing the network slicing feature of the 5G architecture and the mobile cloud computing capabilities offered by Mobile Edge Computing (MEC), mobile edge communication systems are emerging that contribute to the convergence of telecom and cloud services. In this scenario, mobile edge slices can be created and deployed by leveraging multi-cloud infrastructure. However, it becomes difficult for potential users, such as mobile edge slice tenants, to evaluate and select the Cloud Infrastructure Provider (CIP) which best meets their heterogeneous requirements. Therefore, mobile edge systems require slice brokering to mediate with resource and infrastructure providers, so that mobile edge slice tenants can specify a single set of network and cloud service Key Performance Indicator (KPI) requirements. In this paper we present a new type of broker, the Mobile Edge Slice Broker, that allows designing, provisioning, and orchestrating the deployment and operation of end-to-end mobile edge slices over edge and multi-cloud environments, while maintaining dynamic monitoring, reconfiguration and optimization capabilities.

**Index Terms**—5G Mobile Communications, Network Slicing, Mobile Edge Computing, Mobile Edge Slice Broker, Multi-Tenancy, Multi-Cloud.

# I. INTRODUCTION

With the softwarization and programmability of mobile networks, the infrastructure of telecommunication systems evolves into a set of interconnected radio resources, cloud-based networking and computing resources [1]. This profound transformation is being fostered by new network design patterns that allow the deployment of a set of logically independent networks running over a same and shared physical infrastructure [2]. The instantiated logical network, commonly called a network slice, consists of a set of Virtual Network Functions (VNFs) which are purpose-built and tailored to fulfill dedicated needs for particular services, for instance, in the healthcare, automotive, augmented/virtual reality domains [3].

Network slicing enables customized network operations by supporting a wide range of tenants with a diverse set of performance and Quality of Service (QoS) requirements. With network slicing, mobile systems are evolving towards multi-tenant environments [4], where multiple actors such as network operators, infrastructure and service providers, as

well as ordinary users have to manage resource allocation, provisioning, and exploitation tasks. However, network slicing brings new technical challenges regarding the orchestration and management of these diverse operations. These challenges must be addressed to enable flexible orchestration of resource allocation and to meet the requirements of tenants [5].

A fundamental component of orchestration, namely the 5G Network Slice Broker (NSB), has been proposed by Samdanis et al. [6] to facilitate resource allocation and perform control and management tasks over the network slices. Furthermore, it is responsible for satisfying the heterogeneous slice requirements of tenants in terms of network performance. However, the NSB does not orchestrate or manage cloud services and edge applications, which creates a barrier to deploying end-to-end mobile edge slices: network slices thus do not cover and operate on cloud services. In addition, NSBs rely on a single cloud data center to support virtualized infrastructure, despite the increase in the number of Cloud Infrastructure Providers (CIPs) as well as the enormous growth in cloud services and resources. Consequently, mobile edge slice tenants have problems operating in multi-cloud environments, notably the critical task of selecting appropriate cloud offerings and cloud resources that fulfill their service requirements. In fact, a separate component, the Cloud Broker (CB), performs these types of tasks over multi-cloud infrastructures.

A service that provides access to data gathered through the Internet of Things (IoT), for instance, can be deployed by creating a network slice using the NSB (based on network KPIs, e.g., latency and data throughput); an edge application that uses this data to modify user resources in the cloud has to rely on the CB (based on service KPIs, e.g., scalability and availability). An application that encompasses data gathering, access management and the cloud-side service as part of a full mobile edge slice is desirable in order to be able to optimize end-to-end design, including overall use of resources, global configuration by administrators and users, etc. Since such an application covers both the IoT-Edge network side and the cloud service side, it cannot be managed using either the NSB
or the CB alone. If a problem arises, such as an increase in the traffic load that imposes severe constraints on the overall slice, an appropriate solution cannot be found. It may be more cost-efficient, for example, to automatically scale up a cloud application across multiple near edge sites in order to gain simultaneous distributed management than to reconfigure router settings to increase bandwidth at the network level.

The main objective of this paper is to propose a solution to this kind of problem through mediation of conciliating and orchestrating actions over both the network and cloud parts of complex applications operating the Edge-Cloud continuum. Concretely, we introduce a new type of broker to manage resource provisioning and optimize deployment of end-to-end mobile edge slices spanning heterogenous infrastructures at the Edge and (multiple) Clouds. Our broker is responsible for deploying mobile edge slices, including network functions, services, and supporting edge applications, as well as the configuration of QoS settings. These operations are facilitated through interaction with both the NSB and the CB. Moreover, the Mobile Edge Slice Broker (MESB) allows monitoring performance and other QoS properties over time in order to dynamically reconfigure and adjust the mobile edge slice and application according to the tenants' requirements and evolving system requirements.

The main *contributions* of this paper are:

* A review of the existing work on (3GPP-based) network slicing and multi-cloud environments, aiming at potential improvements for mobile edge slice deployment.

* A design of an extension to the NSB and CB to cover and reconcile both network and cloud service KPIs in the context of mobile edge slices.

* A new notion of MESB that enables the orchestration of provisioning, scaling and configuration of network and edge applications as well as the operation of end-to-end mobile edge slices.

The remainder of this paper is organized as follows. Section II introduces the background covering network slicing, multi-cloud environments, and multi-tenancy environments as well as the advantages and limitations of both NSBs and CBs. Subsequently, the MESB, its architecture and properties, are introduced in Sec. III. Finally, Sec. IV provides a conclusion.

## II. BACKGROUND

### A. Network slicing

Network slicing is a key feature of 5G and beyond network architectures. As introduced by 3GPP [7], it involves transforming the network from a static one-size-fits-all paradigm, to a new paradigm where logical partitions called network slices are created over the same network infrastructure. Particularly, a network slice has been defined by the next-generation mobile networks alliance [2] as a complete instantiated logical network comprising a set of Network Functions (NFs) and all the resources required to serve a particular purpose or a network service. It includes both Radio Access Network

(RAN) functions as well as Core Network (CN) control plane and user plane NFs [8] with all the required resources in terms of compute, storage, and networking. Moreover, network slicing provides end-to-end network slices with dedicated core functions, e.g., the access and mobility management function and even policy control functions. Interestingly, when supported features and service requirements are the same, some core functions can be shared among multiple slices [9].

Network slices deployment is facilitated by the Network Exposure Function (NEF) through listing the available network slice templates, as well as specifying virtual resources and functions to be instantiated for particular service requirements. Moreover, it acts as an interface between Mobile Network Operators (MNOs) and network slice tenants for handling slice requests. A MNO can be seen as a communication service provider that leverages resources, e.g., bandwidth on a network link, forwarding tables in a network element (switch, router), that are exposed by infrastructure providers [10]. A tenant refers to a specific end-to-end slice owner that has specific requirements in order to serve its end users. At this point, an orchestration and management layer is required to address the challenges of heterogeneous tenant requests in terms of resources, requirements, policy conflicts, security, and trust, etc. In this context, Dang et Sivrikaya [10] reviewed the state-of-the-art of network slicing facilities enabling multi-domain slice management. Two main different models according to the level of trust between the stakeholders have been reviewed: federation and brokerage.

In contrast to federated multi-domain models, in this paper, we focus on brokerage approaches that have been first introduced in [6] as a new feature in 5G systems. The main contribution has been the proposal of a multi-tenant network architecture where the new entity referred to as 5GNSB is directly plugged into the 3GPP-compliant architecture. The role of this NSB is to provide admission control for requests received from MNOs, service providers and tenants as well as to manage resource allocation from a host RAN provider, i.e. the CIP. Recently, Sciancalepore et al. [9] discussed related work on network slicing solutions available in the literature to fit the functionalities required by a NSB.

Unlike the reviewed solutions, the brokerage approach that will be presented in this article is, as far as we are aware, the first of its kind to enable a better reconciliation between the KPIs at the network level, which is managed by the MNOs, and at the application level, which is managed by the CIPs.

### B. Multi-cloud environments

As the mobile edge slice covers both network and edge services provisioning and contains a set of NFs and Mobile Edge Computing (MEC) applications with different requirements, deploying it on a single cloud infrastructure has inherent limitations in terms of service performance, availability, reliability and security [11]. Moreover, a slice manager would be limited by the edge locations provided by one CIP, which may lead to network performance-related issues such as low coverage and high latency. Therefore, relying on a single cloud
infrastructure to deploy an end-to-end mobile edge slice may not be practical in the face of these diverse limitations. To overcome these challenges, multi-cloud environments [12] or cloud of clouds offerings like Google Anthos and startups like Vawlt or Multcloud are emerging for end users and enterprises to host their various distributed systems [13]. The idea behind using multiple clouds is to provide a high Quality of Service (QoS), improve user experience as well as security aspects, and mask the failures of some cloud infrastructure. The multi-cloud environments, with their various services, including virtualization and allocation of compute, storage and networking resources, enable both elasticity and flexibility in terms of applications deployment, resources efficiency, and managing client requests. Moreover, they allow moving and distributing workloads to resources deployed over multiple clouds in a seamless manner [14], [15].

However, with the growth in the number of CIPs in the multi-cloud marketplace, application providers are facing many challenges in selecting the most appropriate data centers for deploying their applications. As described by Ramalingam and Mohan [16], in order to satisfy the diverse needs of cloud customers, the multi-cloud environment is attracting new cloud service providers to offer new enablers such as Application Programming Interfaces (APIs) and CBs. The primary role of a CB is to recommend a list of potential cloud services from different CIPs that best meet the resource requirements of application providers [17]. Additionally, a CB enables easy collaboration and migration of applications across multiple CIPs. Furthermore, security-wise, a CB is also important for avoiding security issues that can lead to serious problems for hosted applications and multi-cloud clients [18].

At this stage, mobile edge slice managers can leverage a CB to select the most appropriate CIP in terms of resources and services required to deploy their virtualized applications. Unfortunately, the current network slice specification does not support either CIP or cloud services, which further limits the possibilities of integrating a CB into the network architecture.

In this paper, we propose to add an overlay with the scope of covering both network and cloud services dimensions. This in turn would facilitate the resource provisioning and deployment processes of mobile edge slices while taking advantage of the NSB and the CB.

### C. Multi-tenancy environments

The 3GPP standards [19] defined the concept of a tenant as a group of users in a software and virtualization context. Hence, third party consumers that use communication services (e.g., enterprises that use V2X service) and consume management capabilities can represent tenants. The 3GPP management system provides multi-tenancy support, by associating different tenants with different sets of management capabilities. Every tenant may be authorized to access and consume those management services that the operator makes available to them based on a Service Level Agreement (SLA) [20].

### III. MOBILE EDGE SLICE BROKER

In this section, we provide a complete description of our MESB, by presenting properties and the proposed architecture with its main modules, as well as the overall system workflow.

#### A. Properties

Our brokerage approach presents an overlay between NSB and CB. Particularly, it covers not only the network partitioning, but also the creation of virtual instances in order to provide end-to-end services to clients based on the features and use-cases supported. Furthermore, it addresses the limitations that have not yet been covered by the NSB and the CB. The key properties of this MESB can be summarized as follows:

* It allows for instantiation and orchestration of end-to-end mobile edge slices, starting with resources provisioning to service deployment (a service refers to an end user capability provided through composition or interfacing of multiple network functions and MEC applications).

* It enables reconfiguration of full slices over time by collecting network and cloud service monitoring measurement and then taking actions accordingly.

* It enables full slices redesign and scaling up or down, in a dynamic way, in order to maintain an optimized system within a tenant-set tolerance.

* It manages dependencies and reconciles network and cloud service levels.

#### B. Architecture

Fig. 1 outlines the MESB architecture proposed in this work and also illustrates the roles in the herein presented approach: the tenants, the MESB, the NSB, and the CB. The tenant requests a virtual end-to-end slice from the MESB that interacts with both NSB and CB. These latter present mediation entities with different resources/infrastructure providers (MNOs and CIPs). A detailed description for this scenario workflow is provided in III-C. Below, we describe the main entities that constitute the MESB.

* **Business slice orchestrator:** This component is responsible for receiving and validating the tenant requests as well as storing and orchestrating their specifications and requirements. It presents a one-stop-shop for tenants to interact with the MESB. Furthermore, it offers an optimizer feature that considers all potential possibilities provided by the design module, with regard to the design, reconfiguration and scaling of the slice, and then arbitrates. The optimizer function allows, on the one side, to dynamically select and validate the appropriate choice, e.g., the choice of the more suitable slice design in terms of QoS, performance or cost (as requested by the tenant). On the other side, it keeps a flexibility option by giving the tenants the ability to make a decision regarding the different operations within their slices. Moreover, the business slice orchestrator should also provide a detailed description of the expected reliability, availability, and other performance indicators of the service as well as actions to be taken in the event of a breach of the
<figure><img src="image_3.png" /><figcaption>Fig. 1. MESB proposed architecture.</figcaption></figure>

agreement by one party. This description defines a pre-
negotiated SLA between the tenant and the MESB and
will be forwarded to the slice design module.

* **Slice design module:** This module formulates a full slice blueprint as requested by the tenant based on the network and the cloud offers, i.e. bandwidths, flow throughput, number of possible connections, edge sites, compute and storage capabilities of different edge points, etc. These offer characteristics are provided upon request to the design module by the NSB and the CB via the mediator entity. Indeed, the design module matches the tenant's requirements with the descriptions of the available network resources and cloud services. Meanwhile, it invokes the pricing module to provide an estimated cost for each design. This yields a list of several full mobile edge slice designs with various combinations of suitable network and cloud capabilities in terms of performance and cost. After that, it forwards the ranked list to the orchestrator where the appropriate slice design will be selected.

* **Pricing module:** It gathers the prices of using and allocating the different resources and services selected for the composition of each end-to-end mobile edge slice design in the corresponding description provided by the design module. Indeed, it gets an estimated cost for deploying and using each slice model proposed by the slice design module. This relies on the pay-per-use payment model of

cloud infrastructure that charges based on resource usage.

* **Scheduling module:** It schedules the actions needed to deploy the full slice conceived by the design module.

* **Monitoring module:** This module retrieves business metrics forwarded by the slice design module and extracts related low-level metrics, e.g. CPU load, memory usage, number of requests, to be triggered via the mediator at the NSB and CB level. As well, it allows to set up composed metrics based on the received QoS specifications. In particular, based on the elementary metrics reported by third-party monitoring modules over time from both network and service sides, the monitoring module enables monitoring the properties of the end-to-end slice and detecting any eventual changes. In this case, if a problem is detected, the monitoring module launches an event to be processed by the event stream module.

* **Event stream:** This component is responsible for receiving and filtering the events reported by the monitoring module as well as the mobile edge slice through third-party monitoring services. If the reported event is identified, the event stream forwards it to the event handler to process it and act accordingly. Otherwise, it can operate on the monitoring module to request further information.

* **Event handler:** This component is in charge of handling the events reported by the event stream. Thus, to handle simpler events, it interacts with the scheduling module to handle it at a smaller scale, for example a function that submits a very high traffic load, the event handler acts on the scheduling module for load balancing. Otherwise, for complex events, it interacts with the design module to review or modify, either partly or totally, the slice design.

* **Mediator:** It presents an interface that executes the actions of the different components of the MESB and enables them to interact with both NSB and CB.

## C. System description

To further validate our architecture, in this sub-section we provide a system description with a scenario workflow wherein the MESB is demonstrated in action. A service for massive IoT communications can be designed, for instance, to collect data from 80,000 different devices such as traffic sensors, speeding sensors and crowd control sensors in a 50 km² area. To deploy such a service, the slice owner requests the creation of a mobile edge slice while indicating a set of network and service KPIs, such as latency, network capacity, and an edge application for processing the data broadcast by sensors in real-time with specific CPU, memory and storage capabilities.

The tenant's request will be handled by the business slice
orchestrator and then will be forwarded to the slice design
module. The latter interacts with both NSB and CB via the
mediator functional block to retrieve the different network and
cloud offerings, exposed as templates, that best match the end
service specifications required by the tenant. An example of a
network slice exposed by the NSB might be a slice consisting
of 80 gNB with a network capacity of 220 Mbps and a large
choice of the number of VNFs and bandwidths within a wide
range of prices etc. Likewise, the CB can provide a list of
storage and computing capabilities of a CIP that owns several
edge sites near the area specified by the tenant.

The NSB receives and handles the requests from the MESB for allocating network slices based on specific SLAs, through the NEF. Regarding the CB, it allows interaction with the MESB through the broker service user interface. After interacting with both sides, the slice design module composes end-to-end slice blueprints with different combinations of resources and services taking into account the deployment and utilization cost of each model estimated by the pricing module.

Next, the design module forwards a list of the composed blueprints to the business slice orchestrator to select the most appropriate design. In order to retain flexibility, the decision-making process can be automated through a set of policy rules (e.g., based on cost, sustainability, provider preferences). Alternatively, the decision can be transferred to the tenant.

Upon validating the end-to-end slice blueprint and performing the corresponding admission control decisions, the slice design module sends the selected design to the scheduling module for scheduling all the deployment actions. At this stage, the MESB can take advantage of the APIs towards the NEF (e.g., the open mobile alliance API focusing on sensor and machine type applications) to gain access to configure and control the allocated network slice.

Once the slice is instantiated, the slice design module interacts with the monitoring module to configure the metrics that have to be controlled over time such as latency, throughput, memory load, etc. This is done by enabling reporting low-level monitoring metrics by third-party monitoring services of NSB and CB via the mediator. For example, reporting the network round-robin metric, which measures the round-trip time of a network packet, and the service latency metric, which measures the processing time of a request, and then combining them into a single latency metric. In this way, overloading the network traffic while transmitting a huge amount of performance management data that is not necessarily needed can be avoided. Thus, the MESB can gain insights into the capacity of the network and cloud infrastructure and control monitoring measurements.

In the case that the monitoring module detects a failure or any change such as an overflow in the system capacity, it launches an event to the event stream which serves as a buffer. Additionally, it forwards any event triggered by the third-party monitoring services. At this stage, the event stream can interact with the monitoring module, if needed, for further performance measures or other elementary monitoring metrics. Upon validating the triggered event, the event stream forwards it to the event handler for processing.

The event handler will manage the fluctuating resource needs due to the traffic variability. One option can be on the network side by increasing the network data rates. Another option can be at the service layer by load balancing or distributing computation through auto-scaling the edge application to enable processing of large number of requests simultaneously. In these cases, the event handler interacts

directly with the scheduling module to orchestrate actions for re-configuring the slice by decreasing the latency for large packets or programming load balancing.

The event handler can also interact with the design module for more complex events that needs to take actions over the two layers (through the NSB and the CB) and to again optimize the deployment cost and the business profit. An example of this case might be an event that reports a security vulnerability in an edge cloud platform on which most of IoT applications are hosted. In this scenario, the event handler sends a high-level request to the slice design module to research alternative offers of other cloud providers and redesign the full slice. This operation requires the initiation of a new slice blueprint creation and deployment process.

Another scenario requiring redesign of the full slice is that the current slice has been changed many times and at some point, it is no longer optimal, nor suitable for the initial business constraints. For example, the IoT slice that is initially designed to sustain services for 80,000 devices may no longer be optimized if the number of connected devices increases over time to 450,000 devices. To maintain efficient transmission and management of the generated data, the MESB can dynamically adjust system properties and resources as needed through continuous monitoring and auto-scaling capabilities. Therefore, the MESB allows the tenant to define a set of constraints for the business slice orchestrator with a tolerance range within which the slice can evolve, as it is difficult for the tenant to anticipate all possible system changes that could impact the price ahead of time (i.e. it could be more or less expensive). For example, a tolerance range for the number of possible devices connected or registered simultaneously. Once the monitoring module detects that the tolerance range is no longer in effect, the event handler forwards a request to rescale the end-to-end slice to the slice design module to ensure that the design remains appropriate and optimal over time.

## IV. CONCLUSION

In this paper, we have proposed a new entity that is responsible for orchestrating resource provisioning and service deployment as well as efficiently adjusting the reconfiguration and composition of mobile edge slices in a multi-cloud environment. The intention behind the paper is to reconcile the existing generic models of NSB and CB using the proposed MESB. This resulted in a new system architecture in which network and cloud service KPIs are indirectly coupled. Accordingly, the network slicing and multi-cloud concepts have been highlighted with various research challenges. A proposed intuitive model with the inclusion of MESB and its constitutive modules are described and a detailed use-case scenario is presented which uses the MESB.

## V. ACKNOWLEDGEMENTS

This work was carried out in the context of Beyond5G, a project funded by the French government as part of the economic recovery plan, namely "France Relance", and the investments for the future program.
REFERENCES

[1] J. X. Salvat, L. Zanzi, A. Garcia-Saavedra, V. Sciancalepore, and X. Costa-Perez, "Overbooking network slices through yield-driven end-to-end orchestration." Association for Computing Machinery, Inc, 12 2018, pp. 353-365.

[2] "Description of network slicing concept," https://ngmn.org/wpcontent/uploads/160113 NGMN Network Slicing v1 0.pdf, 2016, accessed: April 2022.

[3] X. Foukas, G. Patounas, A. Elmokashfi, and M. K. Marina, "Network slicing in 5g: Survey and challenges," IEEE Communications Magazine, vol. 55, no. 5, pp. 94-100, 2017.

[4] I. Benkacem, T. Taleb, M. Bagaa, and H. Flinck, "Optimal vnfs placement in cdn slicing over multi-cloud environment," IEEE Journal on Selected Areas in Communications, vol. 36, no. 3, pp. 616-627, 2018.

[5] N. Afraz and M. Ruffini, "5g network slice brokering: A distributed blockchain-based market," in 2020 European Conference on Networks and Communications (EuCNC), 2020, pp. 23-27.

[6] K. Samdanis, X. Costa-Perez, and V. Sciancalepore, "From network sharing to multi-tenancy: The 5G network slice broker," IEEE Communications Magazine, vol. 54, no. 7, pp. 32-39, 2016.

[7] "Study on management and orchestration of network slicing for next generation network standard 3gpp tr 28.801 v0.1.0, 3rd generation partnership project," https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3091, 2016, accessed: April 2022.

[8] "System Architecture for the 5G System standard 3gpp ts 23.501 v0.3.1, 3rd generation partnership project," https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3144, 2016, accessed: April 2022.

[9] V. Sciancalepore, L. Zanzi, X. Costa-Perez, and A. Capone, "Onets: Online network slice broker from theory to practice," IEEE Transactions on Wireless Communications, vol. 21, no. 1, pp. 121-134, 2022.

[10] X.-T. Dang and F. Sivrikaya, "A lightweight policy-aware broker for multi-domain network slice composition," in 2020 23rd Conference on Innovation in Clouds, Internet and Networks and Workshops (ICIN), 2020, pp. 123-130.

[11] M. Pranathi and G. K. Das, "Cloud-of-clouds system for storing and sharing big data with secure mechanism," vol. 12, 2021. [Online]. Available: www.jespublication.com

[12] S. J. A. Hong Jiangshui, Dreibholz Thomas and H. J. Alessia, "An overview of multi-cloud computing," in Web, Artificial Intelligence and Network Applications, X. F. Barolli Leonard, Takizawa Makoto and E. Tomoya, Eds. Cham: Springer International Publishing, 2019, pp. 1055-1068.

[13] A. Niknia, M. Correia, and J. Karimpour, "Secure cloud-of-clouds storage with space-efficient secret sharing," Journal of Information Security and Applications, vol. 59, 6 2021.

[14] O. A. Wahab, J. Bentahar, H. Otrok, and A. Mourad, "Towards trustworthy multi-cloud services communities: A trust-based hedonic coalitional game," IEEE Transactions on Services Computing, vol. 11, no. 1, pp. 184-201, 2018.

[15] P. Jamshidi, C. Pahl, S. Chinenyeze, and X. Liu, "Cloud migration patterns: A multi-cloud architectural perspective," 11 2014.

[16] C. Ramalingam and P. Mohan, "Addressing semantics standards for cloud portability and interoperability in multi cloud environment," Symmetry, vol. 13, no. 2, 2021. [Online]. Available: https://www.mdpi.com/2073-8994/13/2/317

[17] Y. Chen, T. Shi, H. Ma, and G. Chen, "Automatically design heuristics for multi-objective location-aware service brokering in multi-cloud," in 2022 IEEE International Conference on Services Computing (SCC), 2022, pp. 206-214.

[18] J. Zhang, T. Li, Z. Ying, and J. Ma, "Trust-based secure multi-cloud collaboration framework in cloud-fog-assisted iot," IEEE Transactions on Cloud Computing, pp. 1-1, 2022.

[19] "3GPP TR 28.804 V16.0.1 study on tenancy concept in 5g networks and network slicing management," https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3549, accessed: 21-04-2022.

[20] "3GPP TS 28.533 V17.2.0 architecture framework," https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3416, accessed: 05-05-2022.

[21] B. Nour, A. Ksentini, N. Herbaut, P. A. Frangoudis, and H. Moungla, "A blockchain-based network slice broker for 5g services," IEEE Networking Letters, vol. 1, no. 3, pp. 99-102, 2019.