Network slicing is a 5G cutting-edge technology, which is able to create multiple types of virtual networks, tailored to accommodate different requirements for several use cases and verticals, on top of a common physical infrastructure.
Currently, operators need to build completely independent and siloed networks for different purposes. As an example, operators providing LTE for Internet broadband services cannot accommodate properly the requirements for IoT devices (e.g., smart meters), and they need to create IoT specific networks, such as Sigfox, preventing synergies among them.
In the future, using network slicing technologies, operators will be able to rely on a shared physical infrastructure to create multiple network slices that fit with the characteristics required by different use cases and vertical industries. For instance, an IoT slice does not need large bandwidth or mobility support, but it requires low signaling levels to reduce energy consumption. On the other hand, augmented reality requires highly distributed network nodes to reduce latency, ensuring a correct overlapping of virtual objects over real images.
Virtualization technologies are underpinning the 5G network slicing concept, fostering the ability to create networks in a very flexible manner. The slice life-cycle can be managed as any other virtualized networking entity (e.g., NFV), allowing operators to easily create end-to-end networks by combining virtualized network components.


After 6 months of intense work, 5GTANGO has released the first version of its system architecture. It forms deliverable D2.2 and can be found at http://5gtango.eu/documents/D22_v1.pdf. The architecture is based on the requirements identified before (see previous blog post at http://5gtango.eu/blog/28-5gtango-requirements.html) and it serves as a reference framework to guide the developments of the 5GTANGO project.

This first release starts out with presenting a high-level structure of the 5GTANGO system to be created within the project. The structure of the system is described in terms of interacting software artefacts. The descriptions include purpose, functionality and behaviour of the components, as well as the interactions between them. The component descriptions abstract from their actual implementation. In fact, the implementation of the components can change over time, while the architecture stays the same. This approach provides maximum freedom to developers who can choose on their own how to implement a specific component while still ensuring interoperability with the remaining system.

The high-level architecture is shown in the figure below. It is split into the three large subsystems Service Development Kit, &V& Platform, and Service Platform. These subsystems are further broken down into individual components realizing their specific functionality.

5GTANGO proposes an integrated vendor-independent platform applied to the three pilot scenarios where the outcome of the SDK (i.e., service packages), are automatically tested in the V&V platform and stored in the Catalogue for their posterior deployment with the Service Platform. 5GTANGO system will be demonstrated in three vertical pilots: advanced Manufacturing, immersive Media, and real time Communications.

This post describes the functional and non-functional requirements of the four main functional blocks considered in 5GTANGO: catalogue (data store, decision support and optimization), V&V platform, NFV-enabled SDK, and extended service platform. It aims to provide inputs to derive functions as well as the overall architecture of the system, and to assess the outcomes of work packages with respect to completeness and functional correctness.

One of the biggest challenges in the Telecommunications DevOps environments is the Validation and Verification (V&V) of Virtual Network Functions (VNF) and Network Services (NS) against different execution platforms. The V&V process allows service operators to have some level of confidence in third-party hosted code so they can be sure that VNFs and NSs will behave as expected immediately after they are deployed and put into production.

Similarly to the DevOps process, V&V is well-established in the software industry, where verification relates to compliance of the System Under Test (SUT) to the requirements (functional or not), whereas validation relates to testing whether it can address a (business) need.

As the issue of validation is critical, ETSI NFV ISG has released a number of documents approaching the need and the framework for pre-deployment validation and testing, as well as interoperability and portability. The issue of verification of NFV NSs is also addressed by NFV Research Group. The current outcomes of the working group mainly focus on the problem statement and the challenging issues that the verification of NSs faces. In addition to the above, standardisation/specification groups and open source initiatives are also addressing verification and validation, such as, for example, OPNFV. In the industry sector, validation frameworks for NFV environment and VNFs have already been proposed, with some organisations offering a portfolio of products addressing this topic.