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.

 

The subsystems are modelled according to three phases. These phases represent stages in the lifecycle of a service: development, verification & validation, and operation. Although these phases may overlap, they typically happen at different timescales and are performed by different actors:

  1. Phase 1: Development of a network service, and publishing of that network service in a catalogue;
  2. Phase 2: Testing, validation, and verification of a network service with a V&V platform, and publishing of the results in a catalogue;
  3. Phase 3: Selecting a network service from a catalogue, deployment and operation of that network service using the service platform orchestration capabilities such as placement, monitoring, scaling, etc.

These phases are typically executed by different stakeholders, which may or may not belong to the same entity. The following roles exist and can be mapped to persons, companies, departments, etc.:

  • Developer: Develops network service, tests it, and publishes it.
  • V&V Provider: Provides testing environment, executes tests, returns signed results, and maintains the results in catalogues.
  • Operator: Selects existing network service, and deploys it.

Development of 5GTANGO components is based on a number of guiding principles. These principles were selected to ensure evolvability, reusability, maintainability, and stability of the platform. The two main principles are:

  • Simplicity. Components in the 5GTANGO platform should follow the Unix philosophy of doing only one thing and doing it well. More elaborate functionality emerges from combining multiple components. This guideline is designed to foster maintainability of the developed components. As the components focus on realizing a specific functionality, it is easier to grasp that functionality. Complexity is reduced and the implementation is expected to have fewer bugs than large components with varied functionality would have.
  • Loose coupling. The principle of loose coupling was selected to ensure the development of a modular system which allows independent development and evolution of the individual components. Aspects of loose coupling include avoiding APIs which exhibit implementation-specific details, such as data structures and functional decomposition. Instead, APIs are designed to resemble the application domain as much as possible. Implementation details, such as the use of a relational database, are to be hidden from users of a component. Loose coupling is designed to allow for the independent evolution of servers and clients. In particular, additional functionality on the server side should not render existing clients unusable or incompatible. Similarly, servers should not be restricted to being used by a specific set of clients. Rather, servers should be agnostic to its clients and the set of clients and their purpose should be unrestricted and changeable over time. One important result of loose coupling is the associated replaceability of components. If the API is not exposing internal implementation details, server components providing that API can be replaced with functionally equivalent components without the clients noticing. Similarly, clients can be replaced with new ones fulfilling the same or different functions than before without the server noticing or needing to be changed. The software lifecycle of creating, deploying, running, and retiring software components is supported by loose coupling and component independence.

The 5GTANGO platform is to be implemented by micro-services. Micro-services are small, independently deployable components which are realizing the principle of loose-coupling. They are also fostering the use of the simplicity principle, as they are geared towards small, dedicated components, which are typically functionally specific ("do one thing") and comprehensive ("do them well").

The initial architecture is sufficiently detailed in order to start implementing the 5GTANGO system. Nevertheless, as there are many unknowns due to the novelty and innovativeness of many features, a lot will be learned during the implementation of the components and their testing with the selected vertical use cases. This experience will be fed back to create a second, more complete version of the 5GTANGO architecture.