In this blog post, we describe the integrated workflow with 5GTANGO's SDK from setting up a workspace to on-boarding a complete package with a desired network service. The SDK supports developers in all these steps through multiple tools that work together seamlessly and are available on public GitHub repositories.

You may have heard that ONAP is preparing for its second release in a few weeks time.Perhaps now is a good time to take another look at the goals of ONAP, its current direction and how ONAP can actually be a part of the final realization of the vision for NFV.

Overview


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.

 

You may have heard ETSI started a few months ago a new ISG, codenamed ZSM, focused on achieving full automation in network service management.

First things first: an ETSI ISG (Industry Specification Group) is a group dedicated to analyse and standardize a particular technology of interest to the telecommunications industry, with a few interesting characteristics: it is widely open to any participant worldwide, it has to renew its mandate every few (typically two years), and it is expected to be focused not only in produce documents, in the form of reports and specifications, but also on demonstrate them by means of experiments (proofs of concept) and interoperability events. This makes an ISG a quite powerful tool to shape the evolution of technologies that are in their initial consolidation stages in the network and telecommunications landscape. ETSI ISGs have defined the NFV framework and the MEC foundations.

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.