Resource Orchestration Strategies With Retrials for Latency-Sensitive Network Slicing Over Distributed Telco Clouds

The new radio technologies (i.e. 5G and beyond) will allow a new generation of innovative services operated by vertical industries (e.g. robotic cloud, autonomous vehicles, etc.) with more stringent QoS requirements, especially in terms of end-to-end latency. Other technological changes, such as Network Function Virtualization (NFV) and Software-Defined Networking (SDN), will bring unique service capabilities to networks by enabling flexible network slicing that can be tailored to the needs of vertical services. However, effective orchestration strategies need to be put in place to offer latency minimization while also maximizing resource utilization for telco providers to address vertical requirements and increase their revenue. Looking at this objective, this paper addresses a latency-sensitive orchestration problem by proposing different strategies for the coordinated selection of virtual resources (network, computational, and storage resources) in distributed DCs while meeting vertical requirements (e.g., bandwidth demand) for network slicing. Three orchestration strategies are presented to minimize latency or the blocking probability through effective resource utilization. To further reduce the slice request blocking, orchestration strategies also encompass a retrial mechanism applied to rejected slice requests. Regarding latency, two components were considered, namely processing and network latency. An extensive set of simulations was carried out over a wide and composite telco cloud infrastructure in which different types of data centers coexist characterized by a different network location, size, and processing capacity. The results compare the behavior of the strategies in addressing latency minimization and service request fulfillment, also considering the impact of the retrial mechanism.


I. INTRODUCTION
The new radio capabilities of 5G and beyond networks will significantly foster higher communication performance that will enable a new breed of applications in several vertical domains (e.g., multimedia, cloud robotics, autonomous vehicles) featuring stringent yet diverse QoS requirements [1], [2]. For instance, IP multimedia services (e.g., VoIP) demand medium bandwidth, low delays and high CPU requirements; content delivery applications may ask for medium bandwidth, no relevant delay bounds and low CPU requirements (in case of video on demand services) or for The associate editor coordinating the review of this manuscript and approving it for publication was Muhamamd Aleem . high bandwidth requirements, stringent delay bounds and medium CPU demands (in case of live streaming) [3].
A parallel and equally relevant technological shift in 5G networks is network softwarization that exploits softwarebased technologies (i.e., Network Function Virtualization (NFV) and Software-Defined Newtworking (SDN)) to foster increased automation and flexibility in network service deployments [4], [5]. Network functions will be set-up as virtual machines, i.e., Virtualized Network Functions (VNFs) in distributed telco Data Centers (DCs), i.e., telco clouds, and dynamically and programmatically interconnected via software network controllers. A scenario can be envisioned where telco service providers will be able to elastically provision partitions out of their virtualized infrastructure (i.e., network slices) tailored to the specific needs of vertical VOLUME 9, 2021 This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/ applications to address different scenarios or user requirements. A correlated trend is the Mobile Edge Computing, which fosters the deployment of distributed micro-clouds at the network edge (e.g., base stations, telco Point of Presence (PoP)) to run service and network functions closer to the user, i.e., service platforms that need a tighter interaction with users (e.g., content caches, video rendering), network functions properly scaled to assure the quality of experience expected by final users (e.g., user plane packet gateway functions, traffic optimization) [6]. This distributed and decentralized cloud-based 5G network architecture is posing new challenges to (telco) service providers to fully exploit the potentialities offered by network slicing, especially in terms of resource orchestration [7]. In particular, the prominent problem is how to dynamically and coordinately select and allot both (virtual) computational and network resources in telco clouds while effectively addressing diverse vertical QoS requirements in terms of end-to-end latency performance, processing capacity and bandwidth demands [8]. This is both a network and service management problem for telco service providers willing to increase the utilization rate of their (virtual) resources to optimize costs as well as fulfill as many vertical slice requests as possible to increase revenues.
In the light of above considerations, this work addresses the resource orchestration problem while allocating VNFs to establish network slices (i.e., VNF placement problem in a distributed telco cloud infrastructure with an eye to meet both resource management and service delivery targets of telco service providers and minimize end-to-end latency performance for the benefit of vertical applications. More specifically, we analyse a set of orchestration strategies featuring a coordinated selection of both computational and network resources to set-up slices while addressing (i) vertical requirements in terms of computational (e.g., CPU) demand and network (e.g., bandwidth) demand, (ii) effective usage of resources across DCs and the interconnection network, (iii) higher acceptance rate of the slice service requests through attempting a retrial of slice requests processing in case of lack of available (virtual) resources, and (iv) minimization of end-to-end latency performance offered by established slices to 5G vertical applications.
We evaluated the devised strategies based on a comprehensive set of simulations and we identified different performance indicators (e.g., blocking probability of slice requests, end-to-end latency performance) to thoroughly compare the performance offered by each of the strategies in a dynamic scenario of VNFs request generation. Performance are also evaluated when a retrial mechanism is adopted while assessing its benefits in terms of reduced blocking probability as well as its impact in terms of increasing network slice deployment time. We considered as reference scenario a composite yet realistic 5G infrastructure composed of geographically-distributed clouds (i.e., DCs) with different size and capacity (e.g., large cloud DCs in combination with resource-constrained edge DCs) and interconnected through a wide area network spanning from the access/metro segment to the core network. As a representative of such an interconnection network, a flexi-grid optical wide-area network is considered in our evaluation thanks to the flexibility offered by elastic and dynamic allocation of optical link bandwidth [9].
The novel aspects of this work lay in discussing different orchestration strategies as representatives of different categories of policies to support service providers with design guidelines to fulfill network slice requirements from verticals (especially in terms of end-to-end latency minimization) while exploiting at best their resources according to their management and business targets (e.g., consolidating resource usage to reduce costs, performing a fair resource utilization to reduce risks of congestion, maximizing the use of resources to increase revenues at the risk of load peaks). The added value of this work lies in considering (i) a composite yet realistic network and cloud infrastructure to evaluate orchestration strategies extending from access network to the core, and including different types of DCs, (ii) a novel retrial mechanism combined with orchestration strategies, and (iii) twofold latency components, i.e., network and processing latency, that are counter-behaving in a composite cloud and network infrastructure.
The paper is organized as follows. Section II gives an overview of the related works in the literature and highlights the position and the novelties of the proposed research. Section III presents the reference scenario and the resource orchestration framework with dynamic VNF placement decisions. In addition, the challenges of the orchestration process are discussed for the considered scenario. In Section IV, we present the orchestration problem formulation. We also describe the orchestration strategies for the joint selection of computational and network resources and the retrial procedure. Section V presents the simulation design and results. Finally, Section VI provides the concluding remarks for this paper.

II. RELATED WORK
The problem of embedding virtual networks in a substrate network represents the main resource allocation challenge in network virtualization [10]. This is usually referred to as the Virtual Network Embedding (VNE) problem [11]. A wide range of algorithms have been proposed in literature to optimally map virtual networks into substrate infrastructures while assigning resources to provide customized end-to-end guaranteed services to end users [12]. This optimality can be accomplished from different perspectives. More specifically, [13] tackles the embedding problem by providing a solution that simultaneously aims at saving cost, energy and avoiding network congestion. [14] proposes a modified genetic algorithm as a near optimal solution to increase the acceptance ratio and the average revenue of Infrastructures providers (InPs). [15] addresses the survivability of the VNE while improving the network load balance and revenue.
The VNF allocation problem in DC/cloud environments has also been addressed in several works while orchestrating network and computational resources to set-up network slices (i.e., VNF placement problem). VNF placement and scheduling in public cloud networks is addressed in [19] where a cost-efficient algorithm is proposed to achieve a trade-off between computing resource consumption and latency performance. In [20], authors consider a multi-DC environment where they aim at maximizing the number of accepted VNF placement requests while differentiating them in priority levels and focusing on business related objectives. They also try to satisfy users requirements in terms of latency and minimum guaranteed bandwidth, although only considering link propagation latency. Another related work [21] proposes an optimal algorithm that provides enhanced networking services to Internet of Things (IoT) applications in the Edge and Cloud infrastructures while considering the specificities of each infrastructure (i.e., low latency with limited resources in the Edge against high delay and large scale capabilities in the cloud). Mostly, all these works take into account latency as a global metric to be optimized and do not analyze the effect of its different components (i.e., processing latency, propagation latency) on the placement process, as this work does also thanks to a more composite and realistic reference infrastructure scenario.
Several works address the VNF allocation problem in a single DC [22]- [24]. In particular, in [22], authors present a methodology to make effective VNFs placement decisions by (i) leveraging flexible CPU allocation to VNFs, (ii) addressing arbitrary VNF graphs, (iii) assuring to have multiple instances of the same VNF, and (iv) taking into account the available link capacity and link delays. Although in principle the approach can be adapted to a distributed multi-DC scenario, the methodology is conceived to be applied to multiple virtualized hosts within a cloud DC. Moreover, [25] proposes an optimization framework which allows fine-grained resource allocation for slices both in terms of network bandwidth and cloud processing. In [26], authors present a novel framework to manage the orchestration of end-to-end-slices that jointly perform admission control and resource reservation across different domains while exploiting the concept of slice overbooking to maximize the profit of infrastructure providers.
The ETSI MANagement and Orchestration (MANO) architecture provides a reference framework to regulate and automate operations for network slices in the form of Network Service (NS) deployments according to directives specified in the Network Service Descriptor (NSD). Recently, the MANO framework has also been extended to support the management of multi-site (i.e., multi-DC) Network Services [27] and to consider the case of service deployments in distributed DCs. In such a case, connectivity among virtual computing and storage resources, i.e., VNFs, is necessary across wide area transport networks, e.g., optical or access networks. The framework also foresees the capability to perform dynamic and optimized VNF placement and resource allocation [28]. Following such guidelines, a number of orchestration platforms have been developed, such as OpenSource MANO (OSM) [29], Cloudify [30], Open Network Automation Platform (ONAP) [31]. However, the full set of features foreseen for the whole MANO framework is still far to be accomplished due to its high complexity and huge number of features. For this reason, several European Projects have also tackled the resource orchestration issue to provide orchestrator prototypes with more advanced features. More specifically, in [32] the placement of the VNFs is performed according to the real-time profile of the deployed application. If the profile is not a-priori known, the VNF is placed near the edge as a de-facto decision. In [33], resource and service orchestration are tackled to support diverse service requirements of various vertical industries where also orchestration strategies have been embedded and tested [34]. Although a significant progress has been done, a full-fledged ETSI-compliant MANO platform is still far to be demonstrated, including the dynamic orchestration operations.
The above research works address VNFs placement and, more generally, effective resource allocation and orchestration in different scenarios. However, as far as our knowledge, all these approaches reveal the lack of extensive investigations on dynamic orchestration including end-to-end latency-related considerations. Latency is instead an important requirement when deploying network services to properly serve emerging applications as stated in [2].
For a comprehensive analysis of the impact of latency on the embedding decisions, both network and processing latency contributions should be considered. In this regard, in [35], the network and processing latency requirements are checked while allocating VNFs at the edge of a fixed mobile convergent network. However, the placement optimization is carried out in a static way from the service provider's perspective, i.e., in terms of resulting consolidation of VNFs, without assessing the slice request admittance and their latency performance. In [36], authors showcase an optimal provisioning of service chain requests with end-to-end latency considerations in physical hardware appliances distributed in a metropolitan network. Both VNFs' processing time and the propagation time over the transport network are considered for the placement decision. The demo is however limited to 2 datacenters with infinite capacities. In [37], authors propose an algorithm for dynamic VNFs provisioning and investigate how to perform traffic grooming in order to address the latency requirements in metro area networks. The algorithm tries to minimize the number of nodes hosting the VNFs while considering their computational capacity and the end-to-end latency as a sum of propagation delays and fixed processing delays. [38] studies the VNF placement problem on edge and public clouds while satisfying user's delay requirements and minimizing the maximum links load. As the problem is NP-hard, an approximation algorithm is proposed leveraging a randomized rounding technique and assuming that the paths VOLUME 9, 2021 between each node pair are pre-calculated beforehand and given.
Regarding the optical network scenario, several works addressed the allocations of VNFs along with optical network paths. In [39], authors study the deployment of VNF service chains over flexible-grid elastic optical networks tackling several aspects of the problem (traffic grooming, spectrum continuity and contiguity, VNF placement) with the objective of reducing network energy consumption. In [40], authors investigate the VNFs selection problem to achieve joint load balancing of IT and spectrum resources trying to achieve an efficient provisioning of the service requests. Both works do not take into account the DCs peculiarities in terms of location and processing capabilities as this work does. On the contrary, the impact of VNFs location is studied in [41] where authors provide a genetic algorithm to solve the problem of dynamic VNF placement in a metro optical network. The solution takes into consideration the VNF location by looking for available resources first at the MEC nodes then at the central office and finally at the rest of nodes of the network. The aim is to reduce the service blocking ratio while optimizing the use of both the computational and optical resources. As a solution to further minimize the blocking, the authors consider a collaborative method between MEC resources, while in this work we propose a retrial mechanism. Finally, the techno-economic impact of VNFs placement on the optical metro network cost is studied in [42]. Authors perform a comprehensive analysis of several VNF placement strategies considering service chains requirements such as bandwidth and end-to-end latency. They conclude that an efficient strategy can reduce the operational cost in terms of delay and Quality of Experience.
As highlighted in [43], the benefits brought by retrial mechanisms have been demonstrated in several fields, e.g., call centers [44], cognitive networks [45] and cellular networks [46]. In those retrial mechanisms, unsatisfied customers are temporarily stored in a queue and then superimposed on the normal stream of new arrivals. Each blocked customer then generates a source of repeated requests to try to fulfill its service independently of the rest of the other requests which might improve the number of satisfied customers. Motivated by the benefits brought by retrial mechanisms, we applied them to slice service demands to increase requests acceptance rate and, hence, telco service provider's revenues.
To summarize, and, to the best of our knowledge, this work advances the state of the art by considering a sophisticated scenario, characterized by a composite yet realistic reference infrastructure (i.e., wide infrastructure from access to core network and different DCs capabilities based on their network location), different set of parameters (i..e, twofold latency components, specificities of path selection in flexible optical networks) and novel adopted mechanisms in orchestration (i.e., retrial). This paper extends the preliminary work presented by authors in [47], [48] with (i) the proposal of novel orchestration strategies accounting for the end-to-end latency, (ii) a more general reference scenario not only comprising virtualization of mobile network functions, (iii) a more comprehensive evaluation of the orchestration strategies using different performance indicators, and (iv) a comparison with opaque networks (i.e., with optical-electro-optical conversion in each node). This work also extends the analysis carried out by authors in [49] where a subset of the orchestration strategies presented in this paper have been assessed in a laboratory set-up. In particular, we supplement that analysis by extending the set of orchestration strategies considering also resource management targets (i.e., load balancing) and using simulations in a more composite network and DC scenario and with a larger scale, thus coming to more general conclusions.

III. REFERENCE SCENARIO AND CHALLENGES
This section introduces the reference scenario we considered and the building blocks we elaborated to evaluate the resource orchestration strategies. Moreover, the challenges of the orchestration problem are discussed.

A. REFERENCE SCENARIO
The reference scenario is shown on the bottom of Fig. 1 and consists in a typical set-up of a 5G network infrastructure. More specifically, it considers a wide set-up of geographically-distributed clouds (i.e., DCs) interconnected through edge, metro and core network links.
DCs span from large cloud DCs to resource-constrained DCs located at the network edge to address network latency requirements of delay-sensitive 5G applications. According to [50], we can contemplate the scenario in which, in relation to their network locations, the DCs feature not only distinct sizes but also different processing capacities and hence different latencies while processing data. More precisely, DCs can be classified in: • Edge DCs: They are pervasively deployed at the network edge and co-located with telco PoPs in the access segment to exploit the proximity to users and offer minimized network latency performance. They have constrained processing capacity because they are small-sized DCs and typically feature higher processing latency because they deploy low-power computing systems tailored to support only users connected to the access network; • Metro DCs: They are located in the metro or regional network segment and feature average processing capacity and processing latency performance; • Core DCs: They are large-sized cloud DCs, deployed typically in few remote locations beyond core network segments and thus reachable at the expense of increased network latency performance. They have substantial processing capacity because of their large scale and typically feature lower processing latency because they deploy high-powerful computing systems tailored to support a huge amount of users while taking advantage from economy of scale. As a case study, we considered DCs interconnected through a convergent all-optical wide area network, spanning from the access/metro segments to the core network, thereby constituting a telco cloud infrastructure [51], [52]. The optical network connects cloud DCs and arrives up to the access, feeding the mobile networks (i.e., 5G radio access) and the network edge (i.e., telco edge DCs acting as PoPs). The alloptical wide area network supports flexible grid technology to enable the elastic and dynamic allocation of optical network bandwidth for each virtual link connecting VNFs.
''Flexi-grid'' technology or Elastic Optical Network (EON) has been proposed as an interesting deployment option of traditional optical networks with rigid frequency grid to effectively address dynamic and bandwidth intensive traffic demands of Internet-based applications [53]. Optical networks supporting a flexi-grid allow to accommodate data traffic through dynamic allocations of ''just-enough'' optical spectrum leveraging the configurability of sliceable bandwidth variable transponders (SBVTs) [54]. More specifically, the available optical spectrum can be divided into a set of frequency slots (FSs) of a fixed (finer) spectral width, e.g. 25GHz, 12.5GHz or even 6.25GHz, in comparison to the current ITU-T Dense Wavelength Division Multiplexing (DWDM) rigid frequency grid (e.g. 50GHz) [55]. The number of contiguous FSs then depends on the requested bitrate, the modulation technique and the slot width. This allows bandwidth to be dynamically and elastically reserved for each connection with a finer granularity by adding or releasing FSs to accommodate changing requirements of traffic demands [56]. Moreover, flexi-grid optical networks allow for optical grooming techniques to be applied to data traffic thereby offloading the electronic processing burden to the optical layer [57].
Flexi-grid optical networks still allow the adoption of Optical-Electrical-Optical (OEO) conversion at every node in the network, which in some scenarios further improves the blocking and failures detection. More specifically, flexible grid optical networks offer the possibility to setup the connections in two ways: transparent and opaque. For the transparent scenario, the signal propagates all-optically from source to destination throughout the network. On the contrary, in the opaque scenario each optical channel is converted to the electrical domain and then back to the optical at every traversed node in the network. Depending on the scenario in which they are considered, both solutions present benefits (e.g., power savings by eliminating unnecessary optoelectronic conversions in transparent networks versus supporting fault detection, isolation and performance monitoring in opaque networks) [58].
In combination with SDN, the flexi-grid optical networks promise to effectively address the agility and flexibility demanded by NFV-enabled multi-DC scenarios. Indeed, they VOLUME 9, 2021 assure the elastic and dynamic allocation of network bandwidth for each virtual link connecting VNFs while enabling efficient bulk data transfers across DCs and lower latency performance [59]. Hence, orchestration platforms can be effectively put in operation by exploiting the programmability offered by SDN controllers on top of flexi-grid optical networks in distributed DC environments [53].

B. ORCHESTRATION BUILDING BLOCKS AND CHALLENGES
The network softwarization forces a consolidation of the optical and mobile/access network and a convergence of the telecommunication network with the computational resources in the DCs, leading to the challenging task of selecting and coordinating the allocations of both (virtual) network and computational resources to serve slice requests across distributed DCs while meeting requirements specified for network slices. This is the task carried out by the orchestration system (i.e., Orchestrator) shown on top of Fig. 1.
The Orchestrator elaborates slice requests from the Operating/Business Support System (OSS/BSS). The OSS/BSS is in charge of service delivery and business operations to fulfill service requests from customers (e.g., vertical industry). Upon the arrival of a slice set-up request, the Orchestrator (i) selects the appropriate virtual resources across DCs and interconnection network to allocate and deploy VNFs as well as virtual links composing the network slice (i.e., VNF placement decisions) while addressing computational and network requirements (i.e., bandwidth demand at virtual links, number of CPU cores to run the VNFs); (ii) sets-up the virtual machines hosting VNFs in the selected DCs and the network paths (both legacy and SDN-enabled) in the interconnection network while leveraging cloud and network controllers, and (iii) assures the proper operation of VNFs and network slicing during their lifecycle through monitoring.
The VNF placement decisions are made dynamically (i.e., on per-request basis) and different orchestration strategies can be adopted depending on the resource and service management targets of telco service providers . The orchestration strategies run on a system-level view including the current status and load of the underlying resource infrastructure (e.g., infrastructure topology, available resources, offered latency performance) to take appropriate VNF allocation decisions.
In the view of evolved interworking with the OSS/BSS (and ultimately with vertical industry) in highly dynamic 5G scenarios, retrial mechanisms are considered at the Orchestrator in case of not successful VNF deployments due to the lack of virtual resources in order to allow for multiple slice set-up attempts and increase the rate of deployed slices although at the cost of increased deployment time. The strategies and the retrial mechanism are detailed in Section IV.
A number of challenges need to be faced while doing orchestration of cloud and network resources on top of a 5G infrastructure. Toward maximizing the acceptance rate, the challenge is to properly exploit the available resources in the infrastructure to serve as many slice requests as possible while addressing specified requirements. For this reason, the orchestration strategies evaluate load information at both the DCs and the network links interconnecting them. The load information is especially critical in relation to edge DCs featuring highly constrained computing resources and at the same time being strategic for latency-sensitive applications due to their proximity to users. Hence, it is advisable that load information are used as a criteria to select DCs or network paths also in consideration of target management goals of telco operators. For instance, the load can be considered in the orchestration decisions to minimize the risk of congestion (and hence minimize the risk of latency performance degradation) while pursuing a fair resource utilization (e.g., load balancing, proportional allocation).
On the other hand, the load might not be a primary criteria in the orchestration decisions if the operator management goal is to consolidate resource usage (and hence reduce operational costs). In such a case, the latency minimization can be achieved through DC location-based considerations (e.g., selection of the closest DC). However, disregarding load information in the orchestration decisions may come with the risk of DC or network link overburdening (and hence the risk of latency performance degradation). In any case, a check that the DC or link nominal capacity value is not exceeded is advisable before admitting the requests, thus leading to the possibility that requests are blocked. For this reason, the retrial mechanism can be beneficial to reduce the rate of slice request blocking. However, the retrial comes with a higher slice acceptance and deployment time. Hence, the challenge while doing retrial is to mitigate this additional time through much more effective usage of resources in order to resort on retrials as less as possible.
On top of that, the challenge to address end-to-end latency minimization in the considered scenario is also handling twofold latency components and their inter-play depending on considered DC network location. More specifically, for a comprehensive orchestration decision in the presented scenario, the following latency components should be considered, (i) the network latency experienced by data traversing the DCs interconnection network links, and (ii) the processing latency experienced by data at the DCs servers. Such latency components are counter-behaving. Indeed, DCs feature opposite network and processing latency performance based on their location, whether in the access, metro, or core network segments. More specifically, small DCs at the edge network offer higher processing latency due to their lowpower computing systems while being reachable with lower network latency. On the contrary, large DCs beyond the core network offer lower processing latency thanks to their high performance systems but impose higher network latency due to their distant location.
Additional challenges raise up in doing orchestration over flexi-grid optical interconnections. A challenge to efficiently use EON resources for network path set-up is related to the physical layer impairments while applying the routing procedure to interconnect any couple of DCs. More specifically, some metrics such as the transmission distance and the number of traversed nodes should be considered while determining the candidate paths. Some approaches such as the use of k-shortest link-disjoint paths have been proposed, mainly to relax the blocking rate of lightpath requests. More specifically, k alternative candidate routes can be calculated in order to be considered if the shortest path for a given source-destination pair is not available. This approach, along with an efficient orchestration strategy can, in some scenarios, significantly improve the performance of EONs. In fact, having more paths available can have a significant impact on the overall acceptance rate and especially on the inter-DC blocking component, thus alleviating the blocking and improving the performance.
Secondly, flexi-grid networks require high OEO conversion capabilities to be able to perform the switching of channels with variable bandwidth characteristics at a fine granularity [60]. However, the adaptation to the changing traffic and network conditions is limited by the reconfigurations allowed by the optical switches and frequency-tunable lasers. In this context, the key to alleviate the stress on the optical nodes is then to adopt orchestration strategies, which can efficiently assign the available resources while minimizing the OEO conversion cost (e.g., through the adoption of transparent optical networks).
Finally, it is worth mentioning that also bandwidth fragmentation represents a serious issue in the set-up of network paths across elastic optical networks. In fact, the constraint of spectrum continuity (i.e., the same FSs must be used in all links of the path) and contiguity (i.e., the allocated FSs must be contiguous in the spectrum) is hard to respect with the dynamic provisioning and releasing of the optical paths in the network, hereafter called ''lightpaths''. Moreover, in such a context, non-contiguous and non-aligned free FSs are more likely to be created thus increasing the impossibility to satisfy new lightpath requests and hence increasing the blocking rate in the network [61]. Such fragmentation issue can be overcome in two ways: either by using wavelength converters that however bring an additional deployment cost to the service providers, or by adopting proper wavelength/spectrum assignment (WA/SA) strategies that enhance the accommodated resources demands while limiting their fragmentation impact [62]. In this paper, we assume that the number of frequency slots is fixed for all the lightpaths and we choose not to focus on this fragmentation issue leaving it for further insights from network designers in optical networks.

IV. LATENCY-AWARE RESOURCE ORCHESTRATION WITH RETRIAL
This section introduces the latency-aware orchestration problem on top of a distributed telco cloud infrastructure for 5G network slicing. By ''latency awareness'', we mean that the orchestration strategies take into consideration the latency performance offered by the infrastructure (and more precisely, two latency components that are propagation and processing latencies) during the decision process to select the most suitable data center that minimizes the end-toend latency. In the following subsections, we firstly present the formal problem to address when dynamically processing incoming slice requests along with the system model. Then, a description is provided of the three different orchestration strategies we propose in combination with a retrial mechanism.

A. ORCHESTRATION PROBLEM FORMULATION
We modeled the distributed telco cloud infrastructure as a weighted directed graph G(V, E), where V represents the set of network nodes and E represents the network links. Each link in E is defined as a tuple {u, v, dist uv , availBw} where dist uv represents the distance from node u to node v and availBw represents the available bandwidth on the link expressed in terms of FSs.
In a subset of nodes V DC ∈ V, a data center is co-located with the network node. Every data center dc can be described as a tuple {ID, t, cr dc , L dc } where ID is the data center identifier, t indicates the data center type (edge, metro or core), cr dc represents the computational resources that can be allocated for running the virtualized VNFs and L dc represents the processing latency of the data center dc. 1 Upon a slice request, the Orchestrator coordinately selects both the DCs where to allocate the computational resources needed by the VNFs (e.g., required processing or storage capacity) and the network resources needed to interconnect them according to the bandwidth demand (e.g., required FSs in the flexi-grid WAN). 2 We assume a forwarding graph composed of a source VNF connected by a virtual link to a destination VNF. Accordingly, the Orchestrator selects a source DC and then a network link and the destination DC, while addressing the requirements of the request. In such a way, every slice request has two vertices (i.e., two VNFs to allocate in as many source and destination DCs) and one edge (i.e., one VNF interconnection link to allocate across the flexi-grid optical network). The reason for such an assumption lays in our main focus on evaluating the effectiveness of the orchestration strategies in fulfilling slice service requirements while minimizing the end-to-end latency and while considering constraints and inter-dependencies given by the composite yet realistic reference scenario described in Section. III-A. More specifically, the focus is on the impact of the combined selection of (i) the virtual link as result of a complex routing process in the underlying flexible optical network while offering different network latency performance, (ii) the DCs where to deploy the VNFs resulting in different and counter-behaving processing and network latency performance as explained in Section. III-B. In addition, the focus is also on the coupling of the above orchestration key elements with the retrial mechanism that is highly affected by the amount of resource utilization. In such an assumption, the VNF source and VNF destination can represent a cluster of VNFs arbitrary interconnected among each other although still placed in the same DC. The generalization to the case of arbitrary slice requests is left for future work.
Finally, regarding the source DC, we select it under the assumption of location constraints being specified in advance, e.g., the access connection of the users to be served and/or the user location [49].
Accordingly, let R i be the slice request which can be viewed as a tuple {i, s, ξ , β} where i represents the request identifier, s ∈ V DC represents the source DC, ξ the amount of requested computational capacity, and β the required bandwidth expressed in terms of number of FSs. The number of available FSs can be expressed as follows: Following the same logic, each request R i demands a given amount of bandwidth, which can be translated into a number of FSs as expressed in the following equation: The requested number of FSs for each request is equal to the division between the requested bandwidth and the spectral width of a single FS. 3 A request is blocked if the selected destination DC has no available resources, the source DC has unavailable resources or the network resources along all the paths from the source to the selected destination DC are unavailable.
Let B dc be the probability that data center dc does not have any available resource for supporting the request from s. Let P sd be the set of paths computed from s to d for supporting R i and B p sd be the probability that there are no bandwidth available along the paths from the source node s to the selected destination node d. The blocking probability for a request from node s is thus equal to the probability that the DC source does not have any available resources plus the probability that there are no available resources along any network path between the DC source and DC destination: where B s expresses the probability that the DC in s does not have available capacity and if it has it, either a path p with available bandwidth cannot be found (i.e., B p sd ) or the DC in d does not have available capacity (i.e., B d ). In fact, in this paper, we consider two possible blocking components which are, namely, the inter-dc blocking referring to path unavailability between a giving source-destination pair of data centers and the intra-dc blocking referring to resources unavailability on the data center source and/or destination.
The end-to-end latency experienced by a VNF allocated at d and connected to node s (L sd ) is computed as follows: where L is the propagation latency on link from s to d and L DC d is the processing latency of the DC at d. For each data center dc in the network, the processing latency is expressed as follows: where Data refers to the amount of data to be processed and Processing Capacity refers to how many operations can be carried out by the data center dc in a given amount of time.
Regarding the use of retrial mechanisms to increase the acceptance rate of slice set-up requests, the orchestration process can be modeled as a system where blocked customers temporarily leave the service and then try again after some random time. Those blocked customers are ranked in a waiting queue before retrying to be served again. The correspondent retrial queuing model is presented in the following. We consider c servers (i.e., c refers to the number of DCs that might satisfy the request) and no waiting queues before the server. Requests arrive at the system according to a Poisson process with rate λ and the service time for every request has an exponentially distributed duration with mean 1/µ. An arriving request is immediately served if its requirements can be satisfied by one of the data centers in the network. Otherwise, the request is put in the waiting queue and retried again after a retrial interval.
In this M/M/c/c queue model, let m (z) be the generating function of the number of requests in the retrial queue: where π m,j denotes the joint probability that there are m(m = 0, 1, . . . , c − 1, c) not available DCs and j blocked requests (j ∈ Z+) in the retrial queue [65]. As explained in [43], explicit expressions for π m,j and m (z) can be found for the cases c = {1, 2} while it is challenging to obtain analytical solutions for the cases with (c ≥ 3).

B. ORCHESTRATION STRATEGIES AND RETRIAL PROCEDURE
The orchestration strategies run under a common algorithmic approach for VNF placement, but featuring different objectives, i.e., different selection criteria.
The pseudo-code of the algorithmic approach is presented in Algorithm 1. The algorithm takes the graph G(V, E), the request R i and the orchestration strategy as input.

End procedure
Before applying the algorithm, the retrial queue Q, the set of DCs D selected as candidate for deploying the VNFs and the list of candidate paths between the source and destination DCs are empty. Moreover, we select the user location randomly among the set of DCs and we assign it to the source DC. The algorithm starts by selecting the best DC according to the selected orchestration strategy as explained below. For each candidate DC d, the k-shortest paths from s to d are computed considering links length as a metric [66]. The algorithm goes through the list of these k-shortest paths sorted by distance to check the availability of network resources. More specifically, for each path p, the spectrum contiguity and continuity and non-overlapping constraints are checked and if the spectrum is available to accommodate the request, the path is added to the list of candidate paths. If no available FSs are found on any of the k-shortest paths then the request is put on the retrial queue for another attempt later. Otherwise, if FSs are available for the requested requirement, the availability of ξ computational resources is checked in the source DC s and in the destination DC d. If both DCs have sufficient resources, the request is accepted and then the statuses of the resources in the network and in the DCs are updated. Otherwise, the request is put on the retrial queue for another attempt later. Based on the adopted selection targets, we devised three different categories of policies that aim at the minimization of the latency performance while considering the following criteria: (i) DC proximity, (ii) DC end-to-end composite latency capability and (iii) fair resource utilization. Under each category of policies, there might be several algorithms or selection criteria to implement. In this work, we propose one strategy for each category as an example of implementation. More specifically, DC proximity is implemented through the Minimum Distance strategy (MD), which minimizes only the network latency component. The DC end-to-end composite latency capability is implemented through the Minimum Latency (ML) strategy, which minimizes the composition of network and processing latency. Finally, the fair resource utilization is implemented through the Load Balancing (LB) strategy. 4 The idea behind LB is that such a strategy could also have an indirect benefit also in terms of latency offered by the DC systems and interconnections while pursuing a balanced resource usage. More specifically, the three orchestration strategies behave as follows: • Minimum Distance (MD): This is the reference strategy which aims at favouring the closest DCs, thus achieving the lowest propagation latency. It selects the closest DC (in terms of path length) provided that it still has available computational resources and provided there are still available network resources in the WAN to setup a network path to reach it with the required bandwidth demand. This strategy is used as a baseline for comparison.
• Load Balancing (LB): In LB strategy, the goal is to balance the load among the DCs thereby achieving a fair resource management and utilization. The load is defined as the total amount of computational resources reserved for the requests that are currently served by the DC, over the amount of computational resource of the DC. It selects the DC that has the lowest load (i.e., the highest amount of available DC resources) among those with available computational resources and the network paths in the WAN with most available network resources among the k pre-computed paths.
• Minimum Latency (ML): In ML strategy, the aim is to favor the DC which achieves the lowest end-to-end latency and thus optimizes the delay perceived by the user/application. For each candidate destination DC, it computes the sum of the propagation latency and the processing latency. Then, it selects the destination DC that minimizes the sum of the two latency components. In the following, we describe the retrial mechanism. When a request cannot be promptly satisfied, it is further delayed, by storing it in a FIFO queue of waiting requests. Each waiting request has a maximum Waiting Timeout (WT ). Upon expiration of WT , the request is dropped by removing it from the FIFO queue and is considered rejected. When resources are released (e.g., termination of other requests), a retrial procedure is performed on the requests in the queue. This retrial can be repeated until either the request is satisfied or its associated WT expires.

Algorithm 2 Retrial Procedure
Algorithm 2 describes the retrial procedure which takes as input the queue of non-satisfied requests and the current status of the timer for every request in the queue. The retrial procedure starts by updating the timer of all the requests in Q, then for every R i tries to apply Algorithm 1 to check if there are any available resources to accommodate some or all the requests of Q. If any request R i is accepted, it is then removed from Q. Otherwise, the current timer st i of every request R i in Q is checked and compared to WT. If st i is lower than WT, R i is kept in the queue for a check at the next round, otherwise it is removed and the request is permanently rejected.

V. PERFORMANCE EVALUATION
In this section the orchestration process is evaluated. The simulation environment setup is firstly presented, then subsequent subsections illustrate the performance of the orchestration strategies (Section V-A), the additional benefits provided by the adoption of the retrial mechanism (Section V-B), and the impact of design choices in terms of network routing (Section V-C ) and Flexi-grid Network transparency (Section V-D) on the efficiency of the orchestration process.
For the evaluations, we used a custom-made event-driven simulator implemented in Java and running the proposed strategies on top of an infrastructure scenario as described in Section. III-A. The source code of the simulator can be found in [67]. The distributed DC infrastructure is reproduced that consists of six edge DCs, three metro DCs and three core DCs connected according to the network topology shown in Fig. 2.
The considered topology combines both the core and the edge network. The core network interconnections are inspired by a real telco network topology in Germany [68] with 17 nodes and 26 links. The edge network interconnections are inspired by a typical tree-like topology with redundant links among small DCs and medium DCs. Links lengths are reported in km above the connection lines for both edge and core networks.
Moreover, we consider that each edge DC has a specific processing capacity fixed to 7.5 GB/s while the processing capacities of the metro and core DCs are calculated as 2 times and 4 times the value of the edge one, respectively [50].
To obtain the processing latency values, we apply Equation 5. For this purpose, we need to fix the amount of data the application is supposed to process. This value depends on the applications using the deployed network slices. The values might go from few kilobits (e.g., web service use case) to hundreds of megabits when bulk data traffic is considered (e.g., Content Delivery Networks) [69]. In this paper, we consider an average value equal 250Mb for each request, which brings to the following values for the processing latency for each type of DC: 4.16ms for small DCs, 2.08ms for medium DCs and 1.04ms for the largest one.
As for DC network interconnections, an optical network with a flexible grid is considered with fiber link lengths expressed in kilometers as reported in Fig. 2. Each fiber link supports 320 frequency slices of width 12.5GHz. The transmission rate is 100Gbps, requiring 4 frequency slices for each lightpath. Full wavelength conversion capabilities are assumed to be available at each node.
Requests are generated randomly according to a Poisson process. Each request has an exponentially distributed duration. The source DC of each request is uniformly distributed. For symmetry, two types of requests are considered: (i) the source DC is an edge DC and thus, the destination DC should be a metro/core DC; (ii) the source DC is a metro/core DC, whereas the destination DC should be an edge DC. Unless otherwise stated, the waiting timeout WT for the retrial mechanism is equal to 50s, while routing is performed by considering the first 4 shortest paths (i.e., k = 4).
We evaluate the following set of metrics: (i) the blocking probability calculated as the percentage of accepted requests over the total number of received requests; (ii) the processing latency expressed as the average time necessary for a data center to process all the requested data; (iii) the queue time calculated as the average time spent by a rejected request in the retrial queue; and (iV) the number of retrials expressed as the number of times the Orchestrator resorts to the retrial mechanism to try to fulfill a request.
Results are displayed as a function of the network load expressed in Erlang (E). Each graph is the result of the average of 10 simulations executed with the same parameters. In every iteration, 500000 requests are sent. Results are collected with a confidence interval of 5% at a confidence level of 95%. All the simulations parameters and their corresponding values can be found in Table. 1.   Fig. 4 compares the blocking probability of the three orchestration strategies: MD, ML and LB when the value of k is set to 4. MD selects always the closest DC which increases its rejection rate since it is more likely to not find available resources towards/in the selected DC due to the high utilization of only few closer DCs (e.g., typically the metro DCs in the uplink direction) and thus of the adjacent network links. ML strategy slightly improves the performance of MD at low loads thanks to the fact that distant DCs (e.g., core DCs in the uplink direction) can be preferred for their faster processing time, enabling a slight redistribution of the load among DCs. LB strategy achieves the lowest blocking probability as it balances the load among DCs and thus ultimately balances also the load on the network links. Fig. 3 quantifies the two components of the blocking probability, i.e., the intra-DC blocking due to the lack of DC resources in Fig. 3(a) and the inter-DC blocking due to the lack of network resources in Fig. 3(b). Results show that for MD strategy, the intra-DC blocking component is higher since the requests are directed to the closest DC until its resources are exhausted. The same behavior is experienced also in the ML strategy which directs the requests to the DC presenting the lowest overall latency. Since the latency depends on static capabilities, i.e., the distance towards the DC and the DC processing capacity, the results are very similar to those of the MD strategy. On the contrary, in the LB case, the inter-DC component is higher than the intra-DC one, because the LB strategy distributes the load on all DCs which results in a better utilization and a lower consumption of the intra-DC resources. However, spreading the load among different destinations causes also a higher and more fragmented utilization of network resources, leading thus to a significant inter-blocking component in MD and ML. Fig. 5 plots the average processing latency for the three orchestration strategies as a function of the network load. Since the processing latency is strictly related to the power of the computing systems deployed within the DCs, in this graph we show the impact of the proposed strategies by choosing the DCs taking into account their different capabilities. Results show that MD suffers the highest processing delay since it selects the closest DCs (i.e., metro DCs in the uplink direction) which typically deploy low-power computing systems and thus feature a high processing latency. On the contrary, the LB strategy improves the processing latency of about 25% with respect to MD. In fact, it selects the destination DCs according to their current load. Since the core DCs deploy high-powerful computing systems, they are more likely to be less loaded and support a larger amount of users and thus be selected with respect to metro and edge DCs. Such highpowerful capabilities feature a low processing latency which  explains the better performance of the LB strategy. Finally, the ML strategy introduces the lowest processing delay. Such behavior is expected since ML aims at selecting the DC that minimizes the overall latency (i.e., both propagation and processing components). Since the propagation delay is negligible with respect to the processing one, ML always selects the DC that offers the lowest processing latency. It is worth to notice that at high loads, core DCs become congested (i.e., unavailable) and ML starts to select edge/metro DCs thus leading to an increase in the processing delay up to achieve the level of LB.

B. PERFORMANCE OF ORCHESTRATION WITH RETRIAL MECHANISM
The retrial mechanism is adopted to try to increase the service providers revenues by not directly rejecting slices deployments in case of lack of resources. Hence, such a mechanism does not impact the processing latency while it has a significant impact on the requests acceptance rate. In fact, when it is not possible to deploy the slice immediately, the request is kept in a queue and retrials for its fulfillment are achieved within a given interval of time named as the maximum Waiting Timeout (WT ). When WT expires, if the virtual resources are still unavailable, the request is blocked. Fig. 6 plots the blocking probability as a function of the network load for the three orchestration strategies, with and without retrial mechanism. By adopting the retrial mechanism, the blocking rate, as expected, decreases for all the strategies. Indeed, trying to fulfill a blocked request at a later time can be beneficial since the request might be accepted thanks to the release of the needed resources in the meanwhile. The improvement is more marked in LB strategy, which is the best performing in either cases. In fact, since LB distributes the load on all the available DCs and on different network links, it is more likely for the retrial mechanism to be more effective and reduce the number of rejected requests. On the other hand, MD and ML benefit from the retrial mechanism only at low loads, when blocking is still contained. At higher loads, those strategies tend to fully utilize the resources of few selected DCs (typically the metro DCs  which are closer for MD and the core DCs which have faster processing time for ML) which strongly limits the effect of the retrial mechanism. Fig. 7 shows the blocking probability for different values of WT . For the sake of clarity, and considering the results plotted in Fig. 6, only the best-performing strategy (i.e., LB) is analyzed. Results reveal that when increasing WT , the blocking probability of slices deployment decreases. More specifically, we can notice that a low value of WT (e.g., 50ms) has a minor impact on the acceptance rate (around 1% better) especially at high loads since it is more likely that WT expires before resources from other requests are released. On the contrary, for high values of WT , each request has a longer time for being served, increasing the probability of finding available resources and thus improving the acceptance rate. A significant blocking reduction is achieved at medium-low load for WT = 50s. However, such improvement is obtained at the cost of a higher overall slice deployment time.
The time spent in the queue, considering the retrial mechanism, is assessed in Fig. 8 while varying the network load. As previously explained, in order not to reject the request  immediately because of the lack of resources, the request is kept within a queue which introduces an additional delay before deploying the slice. Such delay increases with the increase of the network load since resources become less available and can reach in average tens of seconds as shown in the figure. This raises the necessity for a trade-off between the overall acceptance rate and the time necessary for deploying a slice. Such trade-off mainly depends on the applications requirements in terms of overall delay.
In principle, without considering the resources availability, the time spent in the queue should vary between 0 (i.e., the request is accepted) and WT (i.e., maximum waiting time in the queue after which the request is removed from the queue and is rejected). For comparison purposes, the performance of MD and ML are also reported in Fig. 8. Results show that, LB is the best performing strategy also from the delay point of view. These results are qualitatively similar to the blocking behavior in Fig. 6 since the average waiting time is strictly correlated to the blocking probability. At high loads, the time spent in the queue is almost equal to WT meaning that almost all the queued requests are rejected. In fact, when the network load increases, the arrival rate of the requests becomes very high with respect to the service time. In such conditions, at the arrival of a new request, it is more likely that the resources already assigned are still occupied and then cannot be released to be reused for the new incoming requests.
Finally, in Fig. 9, we show the number of retrials performed to try to fulfill the slice deployment requests that have been rejected because of the lack of resources. The number of retrials is plotted for the three orchestration strategies as a function of the network load. From the results, we can notice that for low loads (i.e., below 200E), the number of retrials is low (i.e., less than 1% with respect to the number of requests sent) and almost the same for the 3 strategies. In fact, when the network is not congested, it is more likely to find the required resources available as previously demonstrated in Fig. 6 by the low percentage of blocking probability, which decreases the necessity to resort to the retrial mechanism and allows to immediately deploy the slices. By increasing the network load, the number of retrials also increases for the 3 strategies in accordance with the blocking probability rate shown in Fig. 6. The increase is however moderate as for the LB strategy since it is also the strategy that presents the lowest blocking probability percentage thanks to its capability to distribute the load among different data centers and links in the topology. On the contrary, ML and MD strategies reach very high values of blocking percentage at medium and high network loads (i.e., starting from 400E) which is also reflected by the high number of retrials they present. However, although MD and ML have almost the similar values of time spent in the queue, the number of retrials for MD at high loads is greater. In fact, also during the retrial, in the MD strategy the closest DCs are always checked first, which are probably saturated at high loads, thus increasing the number of retrials without improving the performance. ML on the contrary enables a slight redistribution of the load by checking the fastest DCs which, considering the same amount of time spent in the queue, might accept few more requests and then allow for performing less retrials.

C. IMPACT OF NETWORK ROUTING
Figs. 10 and 11 plot the blocking probability when considering the MD and LB strategies, respectively, as a function of the network load while varying the number of shortest paths, i.e., k = 1, . . . 4. For k greater than 1, the paths represent alternative solutions that might be longer than the shortest path but have other advantageous properties (e.g., respond to a higher demand, avoid link failures, avoid specific intermediate nodes). In this paper, we computed the alternative routes by expanding the paths in length order while keeping the same source and destination. Other criteria might be considered in the selection of alternative paths such as calculating the similarity between any two paths or applying weights on previously computed paths.
For the MD strategy (Fig. 10), the sensitivity of the blocking probability to k is negligible except for very low loads. The reason is that MD selects the closest DC, exhausting  quickly its computational resources. Since the main cause of blocking is due to the computational resources, searching for alternative paths has a negligible impact on the overall blocking probability. Instead in the LB strategy (Fig. 11), increasing the pool of candidate paths improves the requests acceptance rate. This improvement occurs because LB strategy searches for unloaded DCs independently from their position. Thus, increasing the value of k augments the probability that at least one of the selected paths has available network resources. At high loads, this improvement diminishes due to overall network congestion.

D. IMPACT OF FLEXI-GRID NETWORK TRANSPARENCY
To compensate for the inter-DC blocking, the use of intermediate OEO conversion can be considered to mitigate the impact of the frequency continuity. More specifically, in an opaque network, only the availability and contiguity of the FSs need to be ensured, and no continuity constraint is enforced contrary to transparent networks. The performance of an opaque network with OEO conversion available in any network nodes is compared to the case of transparent optical networks, previously investigated. The blocking components for the opaque and transparent scenarios are reported in Fig. 12(a)-12(c) for the three orchestration strategies. Results show that contrary to the expectations, in both the MD and ML strategies the opaque scenario presents a higher overall blocking mainly due to the intra-DC blocking component (in both cases, the inter-DC blocking component is null). In fact, given a DC source, these two strategies select always the same DC destination (i.e., the closest and the ''quickest'' one, respectively) which highly increases the blocking due to the lack of DC resources. Whereas, in the transparent scenario, the continuity constraint slightly increases the inter-DC blocking component thus preventing from allocating new requests. In the LB strategy, a different trend is noticed. Specifically, at low loads, the opaque scenario presents a lower rejection rate than the transparent one, because in LB the inter-DC blocking is the main component and can be lowered by exploiting OEO conversion. At high loads, the DCs are saturated and then the blocking rate in both scenarios becomes almost equivalent mainly because of the increase in the intra-DC blocking.

VI. CONCLUSION
In the upcoming 5G and beyond network infrastructures and in the context of network slicing deployments, the paper compared three orchestration strategies for dynamically selecting resources for VNFs in a scenario of geographically distributed DCs, interconnected by a flexible optical network. Blocking probability and latency are the two critical parameters that were assessed. Simulation results indicated that the load balancing strategy achieves the lowest blocking and contained latency with respect to the ones that minimize the propagation latency and the overall latency. The better performance of the LB strategy can be explained by the more balanced loads across the DCs and thus across also the optical network, leading to a significant reduction of the inter-DC blocking with respect to the other strategies.
To further improve the performance, two approaches aiming at lowering the blocking probability were assessed: a retrial mechanism in the strategy and the removal of continuity constraints of FSs through OEO conversion in the optical nodes. Results showed that the retrial mechanism is suitable for lowering the blocking at low and medium loads, at the expense of an increased delay for serving the requests. Enabling OEO conversion in the nodes permits also to decrease the blocking probability at low loads, without incurring additional delay, thanks to the possibility to remove the continuity constraints of the FSs. Both approaches are effective in LB. However, the inter-play of the blocking components (inter-DC and intra-DC blocking) and the trade-off between blocking and latency must be carefully evaluated for ensuring the required performance.
As a future work, we plan to replace the simulator by a virtualized testing environment (e.g., FIRE, GENI) to conduct a more realistic performance evaluation. We also envisage to assess the capabilities of other orchestration strategies leveraging, e.g., the proportional allocation criteria.
M. GHARBAOUI received the Ph.D. degree in innovative technologies of information and communications engineering, and robotics from Scuola Superiore Sant'anna, Pisa, Italy, in 2012. She is currently a Technologist at Scuola Superiore Sant'anna. She has been involved in several EU projects. She has coauthored more than 50 papers appeared in international journals and conferences. Her main research interests include software-defined networking, network function virtualization, network orchestration, the development and the implementation of service-oriented architectures, and service management for smart cities.
B. MARTINI is currently the Head of research with the CNIT National Laboratory of Photonic Networks and Technologies (PNT Lab) and an Affiliate Researcher with Sant'Anna School of Advanced Studies, Italy. Before joining CNIT PNT Lab, she worked for two large telco companies, Italtel and Marconi Communications (currently Ericsson). She is an Adjunct Professor with Sant'Anna School of Advanced Studies and the University of Pisa, Italy. She has been involved in several national/EU research projects, the recent ones 5GPPP 5GEX, 5GTRANSFORMER, and 5GROWTH, and in several FIRE projects (OFELIA, FED4FIRE+, TRIANGLE, and 5GINFIRE) with leading roles. She has coauthored more than 100 articles in international journals and conference proceedings. Her research interests include network virtualization and orchestration in SDN/NFV/5G environments, service platforms for nextgeneration networks, network control/management architectures, and security solutions for multidomain IP/optical networks and NFV deployments.
G. CECCHETTI received the master's degree in computer engineering from the University of Pisa, the Ph.D. degree in innovative technologies from Scuola Superiore Sant'anna, and the Ph.D. degree in clinical engineering from the University of Trieste. He is currently a Researcher at TeCIP Institute. His skills and activities are in the ICT sector, where he has gained many years of experience in the field of computer architecture, digital systems, data centers, and embedded systems. He has collaborated on many national and European research projects. He is a Technical Leader of the Communication Platform for Traffic Management Demonstrator (OPTIMA) Project funded by Shift2Rail as part of the H2020 Program. His teaching activity is in the field of computer architecture and digital systems. He has published articles in international journals and conference proceedings. His research interests include the support of quality of service on heterogeneous networks, IEEE 802.11e networks, railway signaling, and communication systems. He has worked as a reviewer for numerous international journals and conferences.