On the Rollout of Network Slicing in Carrier Networks: A Technology Radar

Network slicing is a powerful paradigm for network operators to support use cases with widely diverse requirements atop a common infrastructure. As 5G standards are completed, and commercial solutions mature, operators need to start thinking about how to integrate network slicing capabilities in their assets, so that customer-facing solutions can be made available in their portfolio. This integration is, however, not an easy task, due to the heterogeneity of assets that typically exist in carrier networks. In this regard, 5G commercial networks may consist of a number of domains, each with a different technological pace, and built out of products from multiple vendors, including legacy network devices and functions. These multi-technology, multi-vendor and brownfield features constitute a challenge for the operator, which is required to deploy and operate slices across all these domains in order to satisfy the end-to-end nature of the services hosted by these slices. In this context, the only realistic option for operators is to introduce slicing capabilities progressively, following a phased approach in their roll-out. The purpose of this paper is to precisely help designing this kind of plan, by means of a technology radar. The radar identifies a set of solutions enabling network slicing on the individual domains, and classifies these solutions into four rings, each corresponding to a different timeline: (i) as-is ring, covering today’s slicing solutions; (ii) deploy ring, corresponding to solutions available in the short term; (iii) test ring, considering medium-term solutions; and (iv) explore ring, with solutions expected in the long run. This classification is done based on the technical availability of the solutions, together with the foreseen market demands. The value of this radar lies in its ability to provide a complete view of the slicing landscape with one single snapshot, by linking solutions to information that operators may use for decision making in their individual go-to-market strategies.

OpenDaylight and OpenNebula integration: Testing traffic management

Software-Defined Networking (SDN) and Cloud Computing are now two of the most adopted technologies, on which many organizations are working to enhance every day. For instance, SDN is particularly emerging to solve networking complexity in cloud data centers, so we see many attempts to integrate Network and Cloud Managers. In this paper, we address an integration of these two technologies, particularly a yet undiscussed combination of two popular frameworks: OpenNebula and OpenDaylight. These open source solutions are widely used for cloud management and network management, yet there are no developed modules for communication between the two. Therefore, we propose a simple way for OpenDaylight to manage OpenNebula's compute nodes, using a common component they both support: OpenvSwitch. We compared OpenNebula with the popular OpenStack cloud manager, as it is attracting more attention in both academia and industry, by evaluating some relevant time metrics and discussing the differences of the proposed technologies. Then, we deployed a test topology to conduct some traffic management techniques in this integration. Our results show that OpenNebula's deployment time as well as clean-up time is significantly lower than OpenStack, but OpenStack takes less time to the running state, besides proving the simplicity of traffic management in OpenNebula using OpenDaylight.