MESON: A Platform for Optimized Cross-Slice Communication on Edge Computing Infrastructures

In the dawn of the 6G era, evolving service ecosystems raise the need for cross-service interactions. Existing resource/service orchestration frameworks are oblivious to such cross-service interactions, since they tend to orchestrate services independent to each other. In this respect, we stress on the need for optimized crossservice communication, and more specifically, for optimized cross-slice communication (CSC). To this end, we present a CSC orchestration platform, namely MESON, which fulfills all main CSC requirements, such as the discovery of CSC-enabled services, the selection of the most suitable (edge) computing infrastructure, and also the establishment and configuration of CSC in a secure and policy-compliant manner. MESON has been designed and built as an extension of the ETSI NFV MANO framework. Relying on MESON as a proof-of-concept for CSC, we present evaluation results from various performance and scalability tests, and further uncover significant gains from optimized CSC in relation to video streaming and Industry 4.0 use cases.

the end-users. Such services could be deployed on separate slices, which may be co-located in the same (edge) cloud infrastructure.
Such interactions among co-located services are hindered by the prevailing way of network slice instantiation. More specifically, the strong isolation between slices within the same datacenter (DC) inevitably stretches the communication path between two co-located slices, enforcing the traffic to exit the boundaries of the DC. This implication is more severe in edge computing infrastructures, due to the distance between the edge cloud and the (mobile) network core. Such unoptimized cross-slice communication (CSC) will potentially lead to latency inflation, with an adverse impact on the applications deployed on top of edge computing facilities, commonly being latency-sensitive. Furthermore, more bandwidth will be consumed from the backhaul and transport networks, which, besides the undesired implications for network operators, may also increase the expenditure of slice tenants.
Along these lines, we stress on the need for optimized CSC, such that will not introduce penalties in terms of latency or bandwidth consumption, incentivizing slice tenants to consume other services present in the same physical infrastructure [9]. In particular, we perceive optimized CSC as a form of peering between co-located slices, ensuring that CSC traffic does not exit the boundaries of the DC and also that any latency inflation is minimal. Note that by no means does optimized CSC impair resource and traffic isolation. On the contrary, CSC should be attained in a secure and controlled manner, i.e., providing access to co-located services based on established agreements between the slice tenants.
Optimized CSC raises various requirements in terms of service and resource orchestration. So far, slice resource orchestration operations, such as the instantiation and scaling, solely pertain to resource and communication demands based on the service specification. Now, optimized CSC introduces inter-slice dependencies that should be carefully taken into account before the placement or the scaling of a slice that has requested or established CSC. A first step towards this direction has been taken in [10], where slice placement is being optimized based on both resource and CSC requirements. Furthermore, CSC establishment requires functionality not available at existing slicing orchestrators (e.g., [3]), such as CSC service advertisement and discovery, as well as Point-of-Presence (PoP) selection. Although PoP selection is supported by certain NFV and slice orchestration frameworks [3], [7], [11], [12], it is oblivious to CSC.
To fulfill these requirements for CSC establishment, we present a platform for optimized CSC orchestration, namely MESON. Our main goal is to foster cross-service interactions and business-to-business (B2B) synergies, exploiting any CSC opportunities stemming from multi-tenancy and service co-location. To this end, we refrain from introducing CSC functionalities in a disruptive manner; instead, we introduce a CSC orchestration layer on top of the NFV MANO reference architecture, maintaining compatibility with state-of-the-art NFV orchestrators, such as OpenSourceMANO (OSM) [5]. The MESON platform comprises a fully-fledged orchestration system that has evolved from the CSC orchestration architecture in [9].
In particular, the main contributions of this paper are the following: • We articulate the notion of optimized CSC in the context of edge computing and elaborate on two use cases that highlight the potential benefits from cross-service interactions.
• We present the design and implementation of a CSC orchestration platform that encompasses all required features for CSC-enabled operations, such as CSC service advertisement and discovery, CSC-optimized PoP selection, as well as CSC establishment. In this respect, we discuss in detail the interactions among the MESON components for the aforementioned operations, as well as the cross-layer interactions for CSC establishment coordinated by the CSC Optimizer MESON component.
• Coupling the MESON platform with OSM and Open-Stack as a proof-of-concept, we conduct a feasibility study on CSC instantiation, assessing the timescales for CSC-enabled service discovery, PoP selection and CSC establishment. We further perform a range of microbenchmarks on MESON-layer interactions in order to gain insights on the various CSC operations and identify potential performance overheads.
• Based on two use cases, we quantify the gains of optimized CSC in terms of service-level performance indicators based on two use cases related to video streaming and Industry 4.0.
The remainder of the paper is organized as follows. In Section II, we elaborate on the notion of optimized CSC and introduce the main primitives related to CSC. In Section III, we provide an overview of the MESON orchestration architecture and the envisaged roles within an evolved service ecosystem that fosters CSC. Section IV provides a detailed description of the MESON CSC orchestration platform, with emphasis on the functionality of the platform components and their interactions. Section V describes two use cases for CSC. In Section VI, we discuss our experimental results and assess the performance of the MESON platform, as well as the gains stemming from optimized CSC. Section VII discusses related work. Finally, in Section VIII we highlight our conclusions and outline directions for future work.

II. CROSS-SLICE COMMUNICATION
We hereby discuss the notion of CSC and stress on the need for optimized CSC in the context of edge computing. In this respect, we distinguish between two types of services: (i) consuming services, and (ii) providing services. CSC enables a consuming service to enhance its functionality by gaining access to service elements or functions offered by a providing service. Such services may be co-located in the same (edge) computing infrastructure, opening up an opportunity for peering between the two services [9]. Thereby, a consuming service can be empowered to consume another (i.e., providing) service with very low latency, enhancing its functionality and the experience offered to the end-users.
Various cross-service interactions, benefiting from CSC, can be envisaged. For instance, consider an augmented reality (AR) service co-located with a social media (SM) service. The AR service retrieves user preferences from the SM service in order to offer an enhanced personalized AR experience to users. In this example, the AR is the consuming service, whereas the SM fulfills the role of the providing service. In Section V, we elaborate on two use cases for CSC: (i) video streaming, where CSC is utilized for peering between video caches deployed in co-located slices, and (ii) robotics in the context of Industry 4.0, where establishing synergy between robotics applications can accelerate mission-critical operations, such as inventory loading/unloading. Such cross-service interactions cannot be established efficiently, primarily because of the strong resource isolation enforced among co-located network slices (which inhibits unauthorized access to resources granted to other slice tenants) [13]. The impact of network slice isolation is more severe for edge computing, hindering opportunities for synergies among slice tenants. We explain this limitation using Fig  1, which illustrates two slices co-located within an edge computing facility (e.g., micro-DC). Routing policies mandated by the need for resource and traffic isolation will enforce a detour of the CSC traffic through the mobile core, prolonging the communication path, which is illustrated by the red dotted line in Fig. 1 [14]. Note that as service deployment is pushed towards the network edge (i.e., in order to better satisfy the needs of latency-sensitive services), the stretching of the CSC path will be substantial.
To alleviate this limitation, we seek the establishment of direct peering between co-located slices, which we term as optimized CSC. Our main goal is to confine the CSC traffic within the boundaries of the DC that hosts the two communicating slices. As such, there will be no need for the CSC traffic to traverse the entire mobile network infrastructure. The optimized CSC is illustrated by the green line in Fig. 1. We emphasize that the establishment of optimized CSC should not be at the expense of lower isolation (i.e., we do not wish to compromise isolation for more efficient CSC). In Section IV, we will exemplify how the proposed CSC orchestration platform enables optimized CSC in a secure and controlled manner, and based on the agreement established between the slice tenants.
Optimized CSC is expected to bring significant benefits both for slice tenants and network operators. First of all, the experience from cross-service interactions will be enhanced, since CSC traffic will traverse a short communication path with potentially minimal latency. As such, latency-sensitive applications will not have to tolerate additional delays stemming from the need to access other services in co-located slices. Furthermore, slice tenants acting as Service Providers will be in position to expand their customer base, due to the enhanced service offerings compared to similar services from other providers. At the same time, the Service Providers will benefit from lower expenditure, since optimized CSC will obviate the need to purchase additional bandwidth from the backhaul and transport network. This will be very critical for bandwidth-intensive services, which become more prevalent in the 5G (and beyond) era. Alleviating the traffic load from the network will be also beneficial for network operators, who could use this spare capacity for other services, which, in turn, can generate additional revenues.

III. MESON ARCHITECTURE OVERVIEW
In this section, we provide an overview of the MESON CSC orchestration architecture, onto which the MESON orchestration platform is based. More specifically, we outline the main roles involved in CSC, present the MESON architecture components, and also exemplify their main interactions. We will also take the opportunity to introduce the notion of CSC slice, which is instrumental in the establishment of CSC.
Since we aim at fostering cross-service interactions, we introduce additional business roles, as beneficiaries of CSC. More specifically, we consider the following roles: Infrastructure Provider, who owns the (edge) cloud infrastructure and offers resources under lease basis for slice deployment.
CSC-enabled Service Provider (CSC-SP), who is the tenant of a slice leased by the Infrastructure Provider. The CSC-SP deploys services onto certain PoPs, which are available for consumption via means of CSC by other slice tenants.  CSC-enabled Service Consumer (CSC-SC), who is a slice tenant that consumes services from co-located slices (i.e., operated by a CSC-SP) via CSC.
The MESON architecture fulfills all the main requirements for the discovery of CSC-enabled services and the establishment of CSC between two slice tenants (i.e., CSC-SP and CSC-SC). More precisely, MESON supports the following functionalities: • The advertisement of services (by a CSC-SP), which can be consumed by another slice tenant (i.e., a CSC-SC) via CSC.
• The expression of interest (by a slice tenant and potential CSC-SC) for the consumption of a CSC-enabled service.
• The matching of CSC interests with advertised CSCenabled services for the identification of the most suitable CSC pair, based on service requirements and peering policies.
• The selection of the most appropriate PoP for the deployment of a CSC-enabled service, given that a CSC-SP may have deployed a CSC-enabled service on multiple PoPs.
• The establishment of a communication path for a crossservice interaction between two slice tenants.
These functionalities stem from the following two CSC establishment scenarios, both of which are supported by MESON: • Uncoordinated CSC. This scenario involves the establishment of CSC after both slices have been in place. As such, CSC establishment is decoupled from the placement and deployment of the slice of CSC-SC. In this scenario, opportunities for CSC establishment are investigated within the particular edge PoP that the slice of CSC-SC has been deployed. Consequently, uncoordinated CSC entails less complexity, since there is no need to look up services on other PoPs, and, subsequently, select the PoP that best meets the needs of the service that will be consumed.
• Coordinated CSC. In this scenario, CSC is established alongside the placement of the slice of CSC-SC. As such, both operations need to be coordinated which requires more care in comparison to the previous CSC scenario. Coordinated CSC raises additional requirements, such as the ability to select the most suitable edge PoP for the placement of the slice, and, subsequently, the establishment of communication with a CSC-SP. In this respect, a service offered by the MESON architecture, namely Edge PoP Selection, is particularly tailored to the needs of this scenario.
The MESON architecture extends the ETSI NFV MANO reference architecture [5] in order to facilitate the discovery and consumption of CSC-enabled services in a controlled manner, exploiting service co-location. MANO provides NFV management and orchestration functionality, spanning the following two layers: (i) the Virtualized Infrastructure Manager (VIM), which is responsible for the management of the virtualized infrastructure across all resource types (i.e., compute, storage, network), and (ii) the NFV orchestration (NFVO) layer, which provides support for VNF life-cycle management, as well as VNF state management.
MESON introduces a CSC orchestration layer on top of the two-layer MANO architecture, as illustrated in Fig. 2. More specifically, the MESON layer encompasses the following components: • Service Registry, which is responsible for CSCenabled service discovery. The Service Registry allows a CSC-SP to advertise services which can be consumed by other slice tenants via CSC. A CSC-enabled service offering encompasses specifications of the service and the CSC policy. The latter contains the highest computing and network resources that can be allocated for the service offering, as well as any scale-out scheme supported by the CSC-SP in order to cope with increased service demands. This information can be conveyed to the Service Registry using MEC application descriptors (AppD) [9]. Likewise, a CSC-SC can submit requests to the Service Registry for the consumption of services via CSC. To this end, the Registry performs a lookup across the registered service instances in order to identify suitable CSC-enabled services. In the case of Coordinated CSC, the search space may encompass a wide range of edge PoPs. Eventually (in this scenario), the Service Registry will return a list of all edge PoPs with CSCenabled services that match the CSC-SC request and also comply with the CSC policy expressed by the CSC-SP.
• Edge PoP Selection, which identifies the most suitable edge PoP for the deployment of a CSC-enabled service on behalf of a CSC-SC. PoP Selection is only relevant to the Coordinated CSC scenario, where the slice of the CSC-SC has not been yet instantiated, and, thereby, its placement needs to be optimized jointly with CSC establishment. Edge PoP selection comes into play after the Service Registry has identified the service instances that match the service requested by the CSC-SC. In particular, edge PoP selection receives the corresponding list of PoPs (i.e., of the matching service instances), and is entitled with the task of PoP ranking, based on hard and soft requirements from CSC-SP. The hard requirements are associated with attributes, such as the location (availability zone) of the PoP, whereas the soft requirements are related to computing and network performance indicators (e.g., service response time), cost parameters, and technical support. In order to generate the PoP ranking, the edge PoP selection module employs a multi-criteria decision making (MCDM) approach, which is exemplified in [15].
• MESON Agent, which performs the following main tasks: (i) exposes an interface to slice tenants for the expression of CSC-enabled service advertisements and interests (by CSC-SPs and CSC-SCs, respectively) and (ii) coordinates the CSC service discovery and instantiation workflows within the MESON layer. The MESON Agent is also responsible for interoperability with the underlying MANO layers via API calls directed to the NFVO. After the edge PoP Selection has generated the edge PoP ranking (in the case of Coordinated CSC), the MESON Agent configures a network slice description with all required instantiation parameters, which is, in turn, conveyed to MANO for the deployment of the CSC-SC's slice. After both slices (i.e., of CSC-SP and CSC-SC) are in place, the MESON Agent triggers CSC setup. To this end, MESON handles CSC establishment through the instantiation of an intermediate slice, dedicated to CSC. The benefits of this approach are two-fold: (i) CSC traffic remains isolated from the rest of the traffic within the edge PoP and (ii) the CSC slice facilitates the deployment of network processing functionality (e.g., in the form of VNF chains), such as packet inspection and monitoring for the purpose of CSC policy control and enforcement, especially from the side of CSC-SP.
• CSC Optimizer, which is responsible for the lifecycle management of the CSC slice. More precisely, this module collects all required information (e.g., network IDs, IP addresses, etc.) in order to instantiate the CSC slice and, subsequently, generates the required packet forwarding entries for secure communication between the CSC-SP and CSC-SC slice. Upon the preparation of CSC slice specification with all required instantiation parameters, the CSC optimizer conveys this specification to the VIM for the CSC slice deployment. In contrast to the CSC-SC slice, the instantiation of the intermediate CSC slice is handled directly by the VIM, without any intervention from the NFVO layer. This raises the need for interoperability between the MESON and the VIM layers, which we further explain in the MESON platform description (Section IV). For a more elaborate description of the CSC discovery and instantiation workflows, we direct the interested reader to [9]. The same work also provides further details about the MESON descriptors (e.g., AppD).

IV. MESON ORCHESTRATION PLATFORM
In this section, we describe in detail the features and implementation of the MESON platform, which realizes all the CSC orchestration operations of the MESON architecture specification (Section III) [9]. To this end, we delve into the system implementation and internal architecture of each component of the MESON layer (i.e., Agent, Optimizer, Edge PoP Selection, and Service Registry). Furthermore, we shed light into the interaction of modules that comprise each MESON component. We also discuss the various cross-layer interactions invoked in order to deploy and configure network slices towards the establishment of CSC.

A. MESON AGENT
The MESON Agent coordinates the communication within the MESON layer for operations, such as the discovery of CSC-enabled services and CSC establishment. In essence, it functions as a communication hub between the other com- VOLUME 4, 2022 ponents residing in the MESON layer (i.e., Service Registry and Edge PoP Selection).
The MESON Agent comprises several distinct modules and its internal architecture is depicted in Fig. 3. The core component of the MESON Agent is the Request Controller, which handles all the communication among MESON-layer components. The Request Controller acts as an internal orchestrator. The interaction among the components is achieved through API calls using Python's request library. The Request Controller receives the offered services along with the candidate edge PoPs from the Service Registry, and subsequently relays this information to the PoP Selection component. The Request Controller also triggers the process of CSC-SC slice instantiation through a REST API call to the NFVO layer.
Another key component of MESON Agent is the Validator. Exploiting the Cerberus Python library, the main task of the Validator module is to determine whether the uploaded descriptors are in the correct YAML format. This validation is carried out in comparison with a well-defined JSON schema. Furthermore, the Converter module is responsible for the conversion of descriptors from YAML to JSON format.
The MESON Agent has been implemented as REST API in Python using the Flask library. The communication between the rest of the MESON modules is achieved through REST API calls, where all the appropriate information is exchanged in JSON format.

B. CSC OPTIMIZER
All the required procedures for CSC establishment are undertaken by the CSC optimizer. This component utilizes the scheduler filters of the underlying VIM (in our case, Open-Stack), and, based on the NFVO data regarding the involved CSC-SC and CSC-SP slices, performs the optimized placement for the CSC slice. More specifically, the CSC Optimizer seeks to co-locate the CSC slice on the same compute host (i.e, server) where the CSC-SC slice is deployed, towards the optimization of CSC in terms of latency and throughput, as we show in our evaluations (Section VI).
The functionalities of the CSC Optimizer are briefly explained in Table 1. These processes require interaction among  all three layers of the MESON architecture. More specifically, slice tenant information regarding CSC establishment is retrieved from the corresponding AppDs, which are stored in the Service Registry. In addition, the CSC optimizer queries the NFVO layer in order to collect all the required information (i.e., underlying networks, computing hosts, etc.), which is crucial for CSC slice instantiation. Subsequently, the required network configuration takes place within the VIM in order to enable slice connectivity (e.g., service chaining). More precisely, leveraging the cloudinit industry standard, the CSC optimizer conveys all the appropriate forwarding entries to the CSC VNFs during the instantiation, which then undertake the orchestration of the communication between the slices of CSC-SP and CSC-SC. The CSC VNFs route the traffic between the networks of the two communicating slices, as illustrated in the NFVI layer of Fig. 2.
The MESON-layer interactions, as well as the cross-layer interactions with the CSC Optimizer, are realized via REST API calls. The CSC Optimizer is implemented in Python.

C. SERVICE REGISTRY
Service Registry is the component of the MESON layer responsible for storing and retrieving information concerning services offered for CSC and the PoPs where these services are available for consumption. The information for every registered service includes its technical aspects and also the aspects of the infrastructure that the service is offered on.
More specifically, the Service Registry consists of two components: (i) a Web service implemented in Java and based on the Spring Boot framework, and (ii) a MongoDB database instance. The main task of the Web service is to expose a REST API, allowing CSC-SPs to register their respective service offerings. The offered services are submitted in JSON format and contain the same information as their YAML counterparts mentioned previously. Furthermore, the Web service provides the functionality to retrieve and forward service offerings that match certain requirements, such as maximum cost and/or performance given by a CSC-SC. This effectively means that, if a service is offered at several PoPs, each one with its own specification and cost, the Registry will filter the list in order to identify the entries that match the particular requirements of the CSC-SC.
The matching procedure in the Service Registry is utilized for service discovery, which is necessary for the CSC establishment process. Service discovery binds the CSC interests of a CSC-SC with the corresponding offerings from CSC-SPs that are already registered in the database. Both service offerings and interests comprise part of the descriptors sent to the Service Registry, as explained in Section III.
In the MongoDB instance, the information is organized into two collections, i.e., one that contains the available services and one that contains the available PoPs. The latter can be further associated with Key Performance Indicators (KPIs). During the process of registering offered services in the database, this information is enriched with the KPIs of the PoP that each service is offered on. Note that all requests to the Web service are supplied by the MESON Agent, as the Service Registry is not directly accessible by components external to the platform (e.g. a browser). This interaction is illustrated in Fig. 4.

D. EDGE POP SELECTION
In the context of CSC optimization, the selection of the most suitable edge infrastructure for the deployment of CSCenabled services is very critical. Edge PoP Selection (EPS), as part of the MESON architecture, provides this functionality. In particular, the candidate edge infrastructures, as extracted from the matching process of the Service Registry, are evaluated based on specific KPIs advertised by each infrastructure provider, as well as based on the preferences of each slice owner, expressed as weight values for the corresponding evaluation criteria. For the ranking process, we adopt a fuzzy Multi-Criteria Decision Making (MCDM) approach, which are widely used for solving the provider selection problem [16]. The EPS framework has been developed in Python as REST API using Flask. In addition, communication with the rest of MESON layer components is achieved through REST API calls, where the essential information about the EPS internal mechanisms is exchanged. The core component of the EPS framework is the PoP Ranking Mechanism (PRM), which is based on the Fuzzy Analytic Hierarchy Process (FAHP) methodology [15]. This mechanism is able to process different types of data simultaneously, such as boolean, numerical or even linguistic (fuzzy) values. As such, the evaluation of the candidate PoPs can take into account data that is related to both technical and nontechnical characteristics. Specifications about the individual methods of the ranking process, alongside with an analytical description can be found in [15]. The PRM functionalities have been implemented in Python. Specifically, the operations of triangular fuzzy numbers with the corresponding classes, the calculations of the comparison vectors and finally the calculations of the FAHP method are defined. The required data for conducting the evaluation and afterwards the selection of the Edge PoP is obtained from specific REST interfaces. Fig. 5 shows the internal architecture of the EPS framework.
The most critical functionalities of EPS are the following: Hierarchical Structure Definition. As mentioned earlier, the PRM is based on FAHP. This method utilizes a hierarchical structure that consists of (i) KPIs of several types and (ii) attributes, which summarize a group of KPIs. Our EPS implementation provides a SQL database for storing the hierarchical structure with the corresponding interface for initializing or updating it. Further details of the step-by-step ranking process, the weight assignment, and the adjustments on the FAHP in order to meet the functional requirements of the EPS, are available in [15].

V. USE CASES
In this section, we describe two use cases for optimized CSC in relation to the proposed MESON platform.

A. VIDEO STREAMING
Content Delivery Networks (CDNs) and caching have been used extensively in network infrastructures, as means to handle the increasing load caused by the continuous video streams [17], [18]. Concurrently, by exploiting 5G capabilities, network operators can deploy storage services in virtualized caches (vCaches) close to the end user's location in micro-datacenters (µDC) [14], [19]. This creates an opportunity for multiple virtual network operators (VNOs), co-existing in the same µDC, to establish synergies for exchanging content located in their vCaches, by bypassing the unnecessary traffic routing through the network core.
To showcase such a synergy, we apply a commercial CDN application for IPTV live streaming and Video on Demand (VoD) services, namely fs|cdn™ Anywhere, in this setting. The main components of this application encompass the Edge Cache, which streams the requested content, stored locally, directly to the user's device, and the origin server. The latter is contacted by the Edge Cache to fetch content that does not exist in its local cache. An alternative approach is to let the Edge Cache receive the missing video chunk from another co-located Edge Cache, which is the scenario currently under consideration.
In Fig. 6, each of VNOs A and B are running an instance of the Edge Cache of the CDN application in their slices, which are located on a cloud provider's µDC. Furthermore, each Edge Cache maintains its own virtual cache memory for content storage. Initially, a request for a continuous video stream is dispatched to the cache of VNO A. If not successful, the request is forwarded to the cache of VNO B. Under normal operations, the request of cache A to cache B for content would have been routed through the network core, outside the boundaries of the DC, resulting in latency noticeable by the end user. This can be avoided by establishing CSC between the slices of the VNOs through the MESON platform.
Besides a reduction in bandwidth consumption and more efficient use of the physical infrastructure, there are addi-tional advantages using this approach. From the user viewpoint, the average perceptible latency is reduced, since there is a high chance that the requested content can be found in another Edge Cache. Furthermore, there is a reduction in the load of the origin server, when the content is provided by the Edge Caches. Lastly, network operators stand to gain from the more efficient utilization of underlying infrastructure by being able to minimize the resources allocated in temporary storage services, as well as the cost due to the reduction of traffic.

B. INDUSTRY 4.0
The adoption of modern network technologies in smart manufacturing is an open challenge for 5G community. Edge computing and network slicing aim at enabling the dynamic programmability of the industrial processes and guaranteeing any time and mission requirement. To this end, two main impediments must be overcome [20]. At first, the production workflows rely on heterogeneous and multi-vendor equipment that raise many trust management and interoperability issues. Second, the industrial operators are commonly not expert at networks, service deployment and their life-cycle management. As such, they usually outsource the network management of the factory floor to micro-operators.
Under this complex setting, we demonstrate the capabilities of CSC for Industry 4.0 in the case of industrial robots. In particular, we focus on time/mission critical robotic applications that must be deployed at the network edge, due to the limited computing resource and battery life of the robots [21]. Furthermore, many open-source platforms operating systems (i.e., Robotic Operating System -ROS) facilitate the orchestration of robotic applications on edge PoPs.
In particular, this use case demonstrates how two warehouse robotic services, deployed by different vendors, communicate and benefit from CSC [22]. Fig. 7 shows the deployment of two slices and the CSC establishment leveraging the capabilities of MESON platform. The first robotic slice is responsible for loading commodities in various locations and consists of three individual services in form of VNFs. The Localization (LOC) service is responsible for tracking the position of the robot and informs the other services. The Mission Planner (MP) service computes the route that the robot must follow to deliver the objects in specific locations that the Asset Loading (AL) service dictates. The AL service continuously updates the status of the warehouse and informs the Asset Unloading (AU) service for the availability of specific items through the CSC mechanism. The second slice is responsible for unloading products. The LOC and MP services of this slice have similar functionality with the AL slice. The AU service is invoked by external services and triggers the MP planner for collecting the required items. Furthermore, the AU service communicates with the AL service to keep track of the availability of assets in the warehouse.
The benefits of the CSC are twofold [22]. First, from the vendor perspective, the mission completion time is signifi-  cantly reduced, due to the immediate update of the warehouse status. Second, the infrastructure provider and the network operator benefit from CSC, since fewer computing resources are allocated for the deployment of VNFs and the generated traffic is confined within the edge PoP. In Section VI-E, we quantify these benefits of CSC in terms of computing and network resources.

VI. EVALUATION
In this section, we perform an extensive evaluation of the MESON platform, which takes place in three distinct phases. Initially, we carry out a performance evaluation of the ME-SON platform (Section VI-B). Subsequently, we conduct performance tests in an actual edge infrastructures environment, as described in Section VI-A. These performance tests aim at quantifying the performance overhead of the various operations and interactions within the MESON layer, with respect to CSC establishment and orchestration. In addition, to assess potential issues of scale, we resort to simulations. In this respect, Section VI-C presents simulation results regarding the most critical operations at the MESON layer, i.e., Service Discovery and Edge PoP Selection. Beyond these performance and scalability tests, we further seek to quantify the gains from CSC in terms of service-level metrics. To this end, we present experimental results from CSC use-case evaluations, i.e., video streaming (Section VI-D) and robotics in the context of Industry 4.0 (Section VI-E).

A. EXPERIMENTAL SETUP
Our setup for the MESON platform evaluation encompasses three experimental facilities in different locations. More specifically, all MESON-layer components and the NFVO (realized by OSM) are deployed at the testbed of University of Macedonia (UOM). Both MESON and OSM are deployed as virtual machines (VMs), each one assigned with 4 CPU cores, 4 GB of RAM, and 50 GB of storage. All VMs are co-located on the same server. In addition, the experimental facilities of Intracom Telecom (ICOM) and National Technical Univerity of Athens (NTUA) are utilized as edge cloud PoPs for the deployment of the video streaming and Industry 4.0 use cases, respectively. Each of the two edge PoPs are managed by a separate OpenStack instance [23]. NTUA's facility relies on OpenStack v18.3.2 for the management of two servers with 16 Xeon CPU cores, 64 GB RAM, and 1 TB of storage in total. ICOM's infrastructure also utilizes OpenStack (Victoria version), managing 4 CPU cores with 8 GB RAM and 50 GB of storage in one server.

B. PERFORMANCE EVALUATION
Our performance tests are centered around the performance overhead of the MESON layer, with respect to CSC establishment. We further account for the interactions of the MESON layer with the VIM and the NFVO, which entail information retrieval, network configuration, and instantiation process execution. We note that the following performance tests pertain to the coordinated CSC case (see Section III), where the CSC-SC slice is deployed alongside with the establishment of CSC (which requires the instantiation of the intermediate CSC slice).
To quantify the performance overhead of CSC establishment, we measure the delay incurred for the instantiation of a slice with and without CSC. The results are based on requests of three different types, associated with different network services (NSes), as well as with different types of VOLUME 4, 2022 VNF instances, as shown in Table 2. This table further depicts the total resource demands for each slice request. According to Fig. 8, CSC establishment incurs less than 9 secs across all request types. This delay constitutes a small fraction of the overall time required for the instantiation of the CSC-SC slice.
To shed more light into the overhead introduced by ME-SON, we measure the execution time of each individual step for CSC instantiation. The steps and their corresponding delays are shown in Table 3. According to these results, CSC instantiation is dominated (time-wise) by CSC network creation and CSC VNF instantiation. More precisely, the completion of both steps requires around 8 secs on average, which corresponds to 95% of the total CSC instantiation time. Note that both CSC network creation and CSC VNF instantiation comprise processes executed by OpenStack (in other words, these delays are incurred by OpenStack rather than by MESON per se). On the contrary, MESON, and more specifically, CSC Optimizer, handles the information retrieval for the slices of CSC-SP and CSC-SC, and also executes calls to the lower layers (VIM/NVFO) in order to trigger CSC instantiation. As shown in Table 3, all these MESON-related processes incur negligible delays for all types of CSC requests, and, in extension, a minimal overhead on slice instantiation.

C. SCALABILITY TESTS
We perform scalability tests on CSC service discovery (handled by the Service Registry component) and edge PoP  selection (carried out by the respective component at the MESON layer). Both processes are triggered upon a request for the consumption of a service via CSC. Similar to our performance tests (i.e., Section VI-B), we focus on the case of coordinated CSC, which entails a higher degree of coordination, and, thereby, more complexity. In particular, we assess the scalability of these MESONlayer operations with a diverse range of edge PoPs (10 to 100). For these tests, the Service Registry's database is populated with a sufficient number of service instances, stored in the form of AppDs. Furthermore, 100 AppDs, which correspond to CSC-enabled services, are assigned to each registered edge PoP. Fig. 9 illustrates the time spent for service discovery and edge PoP selection across the range of PoPs under consideration. The delay incurred for both operations combined lies in the range of 10 to 40 ms. According to Fig. 9, service discovery and PoP selection exhibit different scaling properties. More precisely, the execution time of the former increases linearly, whereas the time spent for PoP selection yields a polynomial-like increase with a larger number of PoPs. This stems from the MCDM algorithms employed for PoP ranking. Given that slice instantiation is completed in the range of tens of seconds (Section VI-B), the delays incurred for service discovery and PoP selection are deemed insignificant in comparison.

D. VIDEO STREAMING USE CASE EVALUATION
We proceed with the evaluation of optimized CSC applied to the video streaming use case (Section V-A) in order to show the benefits of CSC for CDN video streaming scenarios, in terms of reliably delivering high-quality video streams to a large, geographically distributed and potentially mobile customer base. The main challenge in such video streaming scenarios is that the dimensioning and coverage footprint of a particular CDN provider appears insufficient to deal with cases of spatio-temporal fluctuations in service demand 1 In this direction, we showcase improvement in video files' fetching time and throughput via the employment of CSC and the consumption of a co-located CDN edge caching service that is provided on the same Edge PoP. The throughput increase and delay decrease are automatically "sensed" by the multicast emulation protocols used by the CDN service (HLS 2 or MPEG-DASH) activating mechanisms for maintaining or upgrading the quality of the video chunks being served and, thus, the end-user experience.
Our experimental setup encompasses two interoperating remote testbeds: (i) the MESON-layer components and OSM that are deployed at the premises of UOM and (ii) an OpenStack installation representing an Edge PoP, which is deployed at ICOM cloud facilities in Peania. In particular, a request for the establishment of CSC is conveyed to the MESON Agent, which, in turn, instructs the OpenStack Edge PoP to instantiate an edge cache that will provide video streaming content to end users. This experiment is conducted twice, i.e., once with a CSC link present to route the traffic between this edge cache instance and a colocated edge cache service on the same PoP, and once without CSC. In the first case, a secondary edge cache slice is already present in the infrastructure with the required content for streaming, essentially playing the role of the service provider. In both cases, we measure the throughput and the time required to store content in the edge cache from the adjacent edge cache (i.e., via CSC and without CSC). We conduct a total of ten tests for each case and present the mean values for each metric.
The corresponding results appear in Tables 4 and 5. When the content is fetched towards the edge cache of the CDN with support of a service provider adjacent edge cache via CSC, throughput is 75 Mbps on average (Table 4). In contrast, without CSC, the content is fetched to the edge cache solely through a remote origin server, which leads to diminished throughput (44.72 Mbps on average). Significant gains are also observed in terms of content storage, when CSC is being utilized. In particular, we observe a nearly 100% increase in the time required to store the content, when switching from an edge cache (via CSC) to the origin server (without CSC). We have validated the effect of these technical KPI improvements on the video quality delivered to end-users through a demo [24].

E. INDUSTRY 4.0 USE CASE EVALUATION
We hereby discuss the evaluation of MESON in the context of the Industry 4.0 use case. In analogy to Section VI-D, our objective is to quantify the benefits of CSC in terms of AL/AU service-level performance indicators. Furthermore, we highlight the importance of the placement functionalities of MESON through different deployment scenarios (involving CSC-SC and CSC slice placements). Our experimental setup is as follows: (i) the MESONlayer components and OSM reside at the testbed of UOM and (ii) an OpenStack instance is deployed at the premises of NTUA, alongside the required slices (i.e., AL slice, AU slice, and CSC slice) for the realization of the corresponding use case. Note that the AL slice corresponds to the role of CSC-SP slice. The AppDs of the AL/AU slices are forwarded to the MESON Agent including CSC specifications, whereas Network Service Descriptors (NSDs) and Slice Templates (NSTs) are uploaded to OSM. The SW images required for the deployment of AL and AU services are onboarded into the NTUA's OpenStack instance. Interrelated services are implemented using Python 3.6, while the communication between them is carried out through REST interfaces. The AL and AU slices correspond into two AlphaBot 3 robotic platforms. As mentioned in Section V, each of the two robots follow a circular path of locations in the operating ground, which simulates an industrial environment, in order to perform the automated load and unload system.
In the following, we discuss our results from two experiments aiming at different service-level indicators in relation to the Industry 4.0 use case.
Mission Completion Time. In this experiment, we assess the impact of CSC on a AL/AU mission. To this end, a specific mission is performed from the robot fleet. Concerning the mission, unique type of assets are stored in each one of the k different storage points of the operating ground and they are available for retrieval by the AU robot. The scope of the AU robot is to collect a set of k assets (one from each storage point) following a circular path, and then return that set to the starting point. As assets could become out of stock at some storage points, the aim of the AL robot is to restore the load if needed. This mission initially is performed with the robots operating in an individual manner, where the AU unloads assets on its path and, at the same time, the AL robot checks every storage point for potential low stock. Afterwards, the robots operate in a collaborative manner via CSC. In particular, the AU slice triggers the AL slice only when a shortage is detected, which obviates the need of the AL robot to perform periodical scans for shortages. For these two scenarios, the mission completion time is measured for 25 loops per different number of storage points. Over the course of the experiments, the time required for the robots to move between two locations is considered fixed.
The average mission completion times as a function of the number of storage points are depicted in Fig. 10. The results demonstrate that the collaboration enabled by CSC leads to a significant reduction of the mission completion time. Specifically, it becomes apparent that, even for relatively few storage points, the gains are close to 25%, while this performance gap expands further (approximately 30%) when the number of storage points is in the order of tens.
Transmission Time. We hereby quantify the gains of optimized CSC (as promoted by MESON) in comparison with alternative CSC placements. In particular, we assume the collaboration of the AU and the AL slice, and consider the following three CSC placement scenarios: (i) MESON optimized placement, where the AU, the AL and the CSC slice are deployed within the same edge PoP and server, (ii) the slices are placed on the same edge PoP, but on different servers and (iii) the AU and AL are deployed in different (remote) PoPs. During a mission, data exchange between the slices is required via the CSC slice. The data size varies from 5 to 200 MB. For each data size, the transmission time is measured for each CSC scenario repeatedly for 25 times. The average transmission time for the respective CSC scenarios is illustrated in Fig. 11. The MESON optimized placement leads to a significant reduction in the data transmission time compared to the remote PoP placement, especially for small data sizes (80% reduction). A noticeable margin (in terms of transmission time) is also observed between the two CSC placement scenarios that utilize the same edge PoP. This margin tends to increase (50%) for data sizes beyond 50 MB.

VII. RELATED WORK
This section provides an overview of studies related to crossservice/slice communication and some of the functionalities of the MESON platform.
Vaquero et al. present a review on next-generation service orchestration focusing on edge/fog and serverless computing [25]. One of the current challenges is the multi-organisation/tenant orchestration, which includes service discovery and customizable service composition that are objectives of the MESON platform. Authors in [20] propose a multi-domain network slicing orchestration architecture that facilitates service management across federated domains. Similar to ME-SON, the Service Broker of this architecture handles slice requests from various stakeholders and is responsible for the management of slice/owner relationships and the scheduling of network slices. A centralized service support repository maintains abstracted service capability information regarding different administrative domains.
Regarding CSC, authors in [10] tackle the challenging problem of CSC-aware network service embedding (NSE), which fits within the scope of the MESON platform. In this case, NSE optimization is not only based on resource and communication demands related to a particular network service specification; instead, it is also dependant on another service that needs to be consumed. To address the intricacies of NSE with other service dependencies, this study proposes a heuristic that utilizes a VNF embedding tree, i.e., a data structure used to generate the most appropriate embedding sequence. The proposed heuristic achieves network service co-location without any perceptible penalty in terms of embedding efficiency.
Dimolitsas et al. present an extension of MESON plat-form for multi-domain edge infrastructure that provides a distributed service discovery [26]. Based on local service registries and caches, a distributed service discovery, based on time-to-live (TTL) values, efficiently discovers the requested CSC-enabled services and evaluates the candidate edge POPs for slice placement. Blockchain technology promises to automate several orchestration processes and enable trust between untrusted entities. Backman et al. introduce the Blockchain Slice Leasing Ledger Concept for Industry 4.0 verticals [27]. The 5G network slice brokering concept relies on the ability of the mobile network operator/service provider to easily and automatically negotiate with external tenants network slice requests based on the current resource availability from the infrastructure provider. It supports on-demand slice placement. The essential information of every slice is stored in the Slice Ledger. After the negotiation and agreement on service terms, smart contracts are used for monitoring the SLA terms and billing. A potential application of smart factory applications is described as well. BUNKER is a blockchain-based VNF package repository that provides individual VNF packages to the end-users [28]. BUNKER is based on Ethereum BC and provides various features, such as service registration and upgrade, licensing, VNF verification and VNF rating. BUNKER is deployed on the Ethereum BC and leverages smart contracts to automate the transactions between the end-users and the repository. Authors in [29] propose a blockchain-based solution for building tailoredmade service chains and establishing cross-service communication. Instead of a centralized repository, a distributed ledger is used for service registration. Smart contracts are used for the negotiation and the establishment of the cross-service communication.
Finally, based on ETSI NFV architecture, authors in [30] present the 5GZORRO architecture that focuses on automated resource orchestration mechanisms. Coupling Blockchain with AI-driven operations, a service provider can select 3rd-party resources and services to automatically reinstantiate its services in a trusted and secure manner across multiple domains.

VIII. CONCLUSIONS
In this work, we presented the architecture, implementation, and experimental evaluation of the MESON platform that facilitates CSC and service interactions among slice tenants. CSC is established in an optimized manner, through service co-location not merely on the same edge PoP but also on the same server, subject to resource availability. A salient feature of the MESON platform is the instantiation of dedicated slices for CSC, a process which is orchestrated jointly with the deployment of the CSC-SC slice.
Our experimental evaluation corroborates that CSC establishment incurs an insignificant performance overhead in comparison with the time spent for slice instantiation within the VIM. Tests at larger scale indicate that service discovery and edge PoP selection combined incur delays in the range of tens of msec for a number of edge PoPs as high as 100. With respect to video streaming, we quantified an average of 49% reduction in the time required by an edge cache to receive the video content from the edge cache of a neighbouring network slice, compared to the time needed for the same content to be fetched from the central CDN server. Significant gains are also identified in the context of Industry 4.0. More specifically, the collaboration among robots, empowered by CSC, reduces mission completion time by up to 30%. At the same time, a significant reduction in the data transmission is also observed with CSC.
Overall, we deem CSC as a key enabler for next-generation Service Marketplaces, where network services will not be restricted to the own functionalities; instead, they will be empowered to consume other potentially co-located service elements, offering an unprecedented quality of experience to users. The ability to discover and consume CSC-enabled services across a wide range of (edge) PoPs can be further enhanced by leveraging on AI/ML methods. This is indeed a direction that we plan to pursue in future work.
ANGELOS PENTELAS obtained a B.Sc. in Mathematics (2015) from the Aristotle University of Thessaloniki, Greece, and a M.Sc. in Applied Informatics (2019) from the University of Macedonia, Greece. Currently, he is pursuing his Ph.D. degree at the same department. His research interests include, among others, the application of optimization and machine-learning methods on NFV orchestration. THEODOROS BOZIOS , PhD, MBA is a Master Research Engineer at Intracom SA Telecom Solutions. He is responsible for the design and implementation of an innovative platform supporting online Marketing and Targeted Advertising services (SmartCampaign). He is working on data analysis and personalization technologies. He is involved in various internal, national or EU research projects. He holds a Computer Science Degree from the University of Crete, a Ph.D. Degree from the Department of Informatics and Telecommunications of the National and Kapodistrian University of Athens and an MBA (Executive MBA) from the Athens University of Economics and Business. Before joining Intracom SA, he was software engineer for IBM AS/400 systems. He has been with Intracom S.A. and Intracom SA Telecom Solutions, first as telecommunication software engineer at the AXE Software Center, and then at R&D where he participated or coordinated Intracoms participation in EU research projects. He was technical manager, assistant project manager or project manager in a number of EU research projects He was the coordinator of the research area Services Delivery Systems (SDS) with important projects. His areas of interest include telecommunication architectures and protocols supporting multimedia, distributed systems, Content Delivery Networks and Internet technologies, data analysis and personalization. From 1995 to 1999, he was a senior technical staff member at AT&T Laboratories, New Jersey. In August 1999 he joined the ECE Dept at the New Jersey Institute of Technology, USA, where he was an associate professor until 2004. He has an established record of publications in his field of expertise, with more than 350 technical journal and conference published papers, while he has received several scientific awards and distinctions. His main research interests lie in the areas of optimization and performance evaluation of mobile and distributed systems, wireless networks and complex systems. VOLUME 4, 2022