No full-text available
To read the full-text of this research,
you can request a copy directly from the authors.
End-to-End Network Slicing in Support of Latency-Sensitive 5G Services
Abstract
Network slicing has been taking a major role in upcoming 5G network implementations. However, in order to provision and maintain end-to-end slices, the management and orchestration among different network segments is required. As a result, techniques and components have risen to fulfil these tasks. In this work, we present latency-aware slicing, which is enabled by the provisioning of network slices equipped with an end-to-end latency sensor. This sensor is added to the service chain, allowing for real time monitoring and eventually actuation upon latency requirements violations. Moreover, we introduce an architecture capable of handling the deployment of such sensors while also coordinating the provisioning of the slice across optically interconnected DCs. To experimentally demonstrate the deployment of a slice with latency sensing we set up a multi-segment testbed connecting client VMs. The presented results demonstrate the behavior of the latency sensor and how it enables latency optimization through path reconfiguration.
... With our work presented in [8], we covered latency awareness at the provisioning stage considering the deployment of slices along with the use of an introduced latency sensor. Moreover, we presented an architecture capable of orchestrating all required actions and a testbed to experimentally prove the sensor provisioning. ...
... In this paper, we follow up the work presented in [8], to put the focus on the real-time maintenance of slices/services, considering latency constraints. In this sense, we emphasize on the gathering of latency data from a running service and how this data is used to validate agreed service policies. ...
... In this case, one of the NSSIs corresponding to the service must be modified at runtime. The details at how the NFV-C modules help in coordinating the latency sensor provisioning are furtherly given in our previous work in [8]. ...
Network Slicing appears as one of the enabling technologies for 5G networks to accommodate services with different requirements and availability. The present work seizes the use of network slicing and focuses on the deployment and maintenance of services which are sensitive to latency constraints. For this purpose, the design and use of a VNF latency sensor are presented, considering its aggregation to the internal chain of services and the retrieval of latency data from the sensor. In this way, and by making use of such data, the expected service performance can be guaranteed. A multi-level orchestration and control architecture is then introduced to provide all the required functionalities for this mechanism. In order to assess this method experimentally, an emulated multi-segment testbed, considering specific 5G network segments (i.e., Access, Metro and Core), is used. The experimental results demonstrate the correct latency sensing of a particular slice and the process of service maintenance through the triggering of proper network actuations such as path reconfiguration or slice reallocation.
... Latency is identified in 5G as one of the most crucial requirements, considering service demands with times below 1 ms. In this regard, we have presented in [22] a mechanism based on the use of a latency sensor, to test and gather the end-toend latency between two VNFs with working traffic between them. The sensor is deployed in the form of a VNF and its strategically placed between the service VNFs to be measured. ...
... The work presented in [22], follows this same model criterion to test the datapath switching based on the collection of up-to-date latency information. In this case, VM1-Sensor-VM2 are connected via internal data networks, so the sensor can measure work traffic latency. ...
The current deployment of 5G networks in a way to support the highly demanding service types defined for 5G, has brought the need for using new techniques to accommodate legacy networks to such requirements. Network Slicing in turn, enables sharing the same underlying physical infrastructure among services with different requirements, thus providing a level of isolation between them to guarantee their proper functionality. In this work, we analyse from an architectural point of view, the required coordination for the provisioning of 5G services over multiple network segments/domains by means of network slicing, considering as well the use of sensors and actuators to maintain slices performance during its lifetime. We set up an experimental multi-segment testbed to demonstrate end-to-end service provisioning and its guarantee in terms of specific QoS parameters, such as latency, throughput and Virtual Network Function (VNF) CPU/RAM consumption. The results provided, demonstrate the workflow between different network components to coordinate the deployment of slices, besides providing a set of examples for slice maintenance through service monitoring and the use of policy-based actuations.
... In this regard, the authors in [36] rely on analytical performance models to develop a solution that guarantees smooth communications for E2E service delivery when there is a wide variety of Quality of Service (QoS) classes in each network domain. It shall be noted that alternative approaches such as real-time delay sensing [37] can complement analytical models in many use cases through reactive solutions, i.e., real-time performance monitoring and actuation in case of any performance requirement violation. On the other hand, analytical models serve to fast and effectively verify, for example, whether a network architecture and built-in features meet the target performance requirements. ...
Fifth Generation (5G) is expected to meet stringent performance network requisites of the Industry 4.0. Moreover, its built-in network slicing capabilities allow for the support of the traffic heterogeneity in Industry 4.0 over the same physical network infrastructure. However, 5G network slicing capabilities might not be enough in terms of degree of isolation for many private 5G networks use cases, such as multi-tenancy in Industry 4.0. In this vein, infrastructure network slicing, which refers to the use of dedicated and well isolated resources for each network slice at every network domain, fits the necessities of those use cases. In this article, we evaluate the effectiveness of infrastructure slicing to provide isolation among PLs in an industrial private 5G network. To that end, we develop a queuing theory-based model to estimate the E2E mean packet delay of the infrastructure slices. Then, we use this model to compare the E2E mean delay for two configurations, i.e., dedicated infrastructure slices with segregated resources for each PL against the use of a single shared infrastructure slice to serve the performance-sensitive traffic from PLs. Also we evaluate the use of TSN against bare Ethernet to provide layer 2 connectivity among the 5G system components. We use a complete and realistic setup based on experimental and simulation data of the scenario considered. Our results support the effectiveness of infrastructure slicing to provide isolation in performance among the different slices. Then, using dedicated slices with segregated resources for each PL might reduce the number of the production downtimes and associated costs as the malfunctioning of a PL will not affect the network performance perceived by the performance-sensitive traffic from other PLs. Last, our results show that, besides the improvement in performance, TSN technology truly provides full isolation in the transport network compared to standard Ethernet thanks to traffic prioritization, traffic regulation, and bandwidth reservation capabilities.
... However, the implementation of the concept of orchestrating a service slice within this standardized network architecture is still in a development phase. In this sense, there are some independent initiatives as [3,6,7,9] that are contributing to the creation of modules that complement the current MANO capabilities in order to orchestrate E2E slices. ...
The challenge of deploying mission critical services upon virtualised shared network models is the allocation of both radio and cloud resources to the critical actors who require prioritized and high-quality services. This paper describes the design and deployment of an intelligent orchestration cycle to manage end-to-end slices on a NFV architecture. This novel tool includes the monitoring of the network elements at different levels and the processing of the gathered data to produce the corresponding alert mitigation actions.
Network functions virtualization (NFV) is a new network architecture framework where network function that traditionally used dedicated hardware (middleboxes or network appliances) are now implemented in software that runs on top of general purpose hardware such as high volume server. NFV emerges as an initiative from the industry (network operators, carriers, and manufacturers) in order to increase the deployment flexibility and integration of new network services with increased agility within operator's networks and to obtain significant reductions in operating expenditures and capital expenditures. NFV promotes virtualizing network functions such as transcoders, firewalls, and load balancers, among others, which were carried out by specialized hardware devices and migrating them to software-based appliances. One of the main challenges for the deployment of NFV is the resource allocation of demanded network services in NFV-based network infrastructures. This challenge has been called the NFV resource allocation (NFV-RA) problem. This paper presents a comprehensive state of the art of NFV-RA by introducing a novel classification of the main approaches that pose solutions to solve it. This paper also presents the research challenges that are still subject of future investigation in the NFV-RA realm.
This demonstration showcases the open-source Net2Plan tool optimally computing and provisioning Service Chain requests with latency considerations by interfacing to an ONOS-controlled metro network and an ETSI-OSM instance orchestrating a set of OpenStack VIMs.