No abstract

One of the key features of next-generation mobile networks is the ability to satisfy the requirements coming from different verticals. For satisfying these requirements, 5G networks will need to dynamically reconfigure the deployment of the network functions. However, the current deployments of mobile networks are experiencing difficulties in exhibiting the required flexibility. At the same time, the research on connectivity provisioning in use cases such as after-disaster scenarios or battlefields has converged towards the idea of Network-In-a-Box. This idea revolves around fitting all software and hardware modules needed by a mobile network in a single or a handful of physical devices. A Network-In-a-Box inherently offers a high level of flexibility that makes it capable of providing connectivity services in a wide range of scenarios. Therefore, the Network-In-a-Box concept represents an alternative approach for satisfying the requirements of next-generation mobile networks. In this survey, we analyze the state-of-the-art of Network-In-a-Box solutions proposed by academia and industry in the time frame starting from 1998 up to early 2017. First, we present the main use cases around which the concept has been conceived. Then, we abstract the common features of the Network-In-a-Box implementations, and discuss how different proposals offer these features. We then draw our conclusions and discuss possible future research directions, including steps required to reach an even higher level of flexibility. The aim of our analysis is twofold. On one hand, we provide a comprehensive view of the idea of Network-In-a-Box. On the other hand, through the analysis we present the features that future mobile networks should exhibit to achieve their design goals. In particular, we show how the Network-In-a-Box fosters the transition towards the next-generation mobile networks.

The virtual resources of 5G networks are expected to scale and support migration to other locations within the substrate. In this context, a configuration for 5G network slices details the instantaneous mapping of the virtual resources across all slices on the substrate, and a feasible configuration satisfies the Service-Level Objectives (SLOs) without overloading the substrate. Reconfiguring a network from a given source configuration to the desired target configuration involves identifying an ordered sequence of feasible configurations from the source to the target. The proposed solutions for finding such a sequence are optimized for data centers and cannot be used as-is for reconfiguring 5G network slices. We present Matryoshka, our divide-and-conquer approach for finding a sequence of feasible configurations that can be used to reconfigure 5G network slices. Unlike previous approaches, Matryoshka also considers the bandwidth and latency constraints between the network functions of network slices. Evaluating Matryoshka required a dataset of pairs of source and target configurations. Because such a dataset is currently unavailable, we analyze proof of concept roll-outs, trends in standardization bodies, and research sources to compile an input dataset. On using Matryoshka on our dataset, we observe that it yields closeto-optimal reconfiguration sequences 10X faster than existing approaches.

Network function (NF) developers have traditionally prioritized performance when creating new packet processing capabilities. This was usually driven by a market demand for highly available solutions with differentiating features running at line rate, even at the expense of flexibility and tightly-coupled monolithic designs. Today, however, the market advantage is achieved by providing more features in shorter development cycles and quickly deploying them in different operating environments. In fact, network operators are increasingly adopting continuous software delivery practices as well as new architectural styles (e.g., microservices) to decouple functionality and accelerate development. A key challenge in revisiting NF design is state management, which is usually highly optimized for a deployment by carefully selecting the underlying data store. Therefore, migrating to a data store that suits a different use case is time-consuming as it requires code refactoring and adaptation to new application programming interfaces, APIs. As a result, refactoring NF software for different environments can take up to months, reducing the pace at which new features and upgrades can be deployed in production networks. In this paper, we demonstrate experimentally that it is feasible to introduce an abstraction layer to decouple NF state management from the data store adopted while still approaching line-rate performance. We present FlexState, a state management system that exposes data store functionality as configuration options, which reduces code refactoring efforts. Experiments show that FlexState achieves significant flexibility in optimizing the state management, and accelerates deployment on new scenarios while preserving performance and scalability.

Massive Machine Type Communication (mMTC) has long been identified as a major vertical sector and enabler of the industry 4.0 technological evolution that will seamlessly ease the dynamics of machine-to-machine communications while leveraging the 5G technology. To advance this concept, we have developed and tested an mMTC network slice called Megasense. Megasense is a complete framework that consists of multiple software modules, which is used for collecting and analyzing air pollution data that emanates from a massive amount of air pollution sensors. Taking advantage of the 5G networks, the Megasense will significantly benefit from an underlying communication network that is traditionally elastic and can accommodate the on-demand changes in requirements of such a use case. As a result, deploying the sensor nodes over a sliceable 5G system is deemed the most appropriate in satisfying the resource requirements of such a use case scenario. In this light, in order to verify how 5G-ready our Megasense solution is, we deployed it over a network slice that is totally composed of virtual resources. We have also evaluated the impact of the network slicing platform on the Megasense in terms of bandwidth and resource utilization. We further tested the performances of the Megasense system and come up with different deployment recommendations based on which the Megasense system would function optimally.