In order to set a context for RINA in 5G we have had to consider concrete and relevant 5G scenarios from selected 5G studies. There are of course a large variety of 5G studies available. In this blog post we have selected one for discussion a “View on 5G Architecture” from the European 5G PPP Architecture Working Group (as per July 2016). This report was selected because it provides a view on a 5G architecture framework developed and thus relevant within the European context of ARCFIRE.

The 5G Architecture Working Group as part of the European 5GPPP initiative is “looking at capturing novel trends and key technological enablers for the realisation of the 5G architecture”. Its report “View on 5G Architecture” provides a consolidated view on technical directions for the architectural design in the 5G era. While the scope of the WG as well as of their study is not limited to 5G PPP projects, the main focus is in the results of the first year of those 5G PPP projects and thus they did not include any RINA related project into their considerations. However, they have identified a number of important architectural design decisions for which RINA can (and does) provide solutions.

The main uses cases addressed are massive mobile broadband, machine type communication and critical machine type communication. So we are looking at recommendations for large scale operations, both in terms of participating elements as well as geographic coverage. This makes this study an ideal consideration for the ARCFIRE project.

The 5G key requirements are introduced top-down, and are very much aligned with other 5G studies. For instance, the starting point are the support of vertical markets (also known as 5G verticals as in supported application domains, for instance logistic, smart cities, etc.) and the acceleration of service delivery. The 5G eco-system is described by means of layers: infrastructure (RAN and wireless backhaul, optical and satellite access, optical metro, optical core), network function (for wireless, optical and cloud) and Orchestrator (including the required network function repository) followed by the top layers business function (with vertical functions and repositories) and business service (with vertical services). RINA as a recursive network architecture can be most certainly applied to the lower layers (infrastructure, network and orchestrator) and provide simplified, yet fully functional interfaces towards the top layers.

In the overall (network) architecture, the following use cases are characterised as mandatory to provide for a future proof architecture:

1. implementing network slicing in cost efficient way,
2. addressing both end user and operational services,
3. supporting softwarisation natively,
4. integrating communication and computation, and
5. integrating heterogeneous technologies (incl. fixed and wireless technologies).

A fundamental concept for the first characteristic is naming and addressing, in particular the change of address of elements in a network slice. A system should support frequent address changes without service impact. This concept has been shown by the ARCFIRE renumbering demo (and PRISTINE) at the 2016 SDN World Congress. The characteristics 2, 3, and 5 are discussed in detail in the [ARCFIRE D22 section 2.4] with regard to RINA. Finally, the characteristic 4 is an original design aspect of RINA, reflected in the statement that “networking is IPC and IPC only”.

For the mobile network in 5G, the report recommends a classic separation into data plane (with data layer functions), control plane (with control layer functions) and management & orchestration plane (with management and orchestration functions). New is that the data plane is a set of Virtualised Network Functions (VNFs) forming a set of data layer functions and a similar set (then subset) as a network slice with dedicated control layer functions. The control plane then is a duplication of this setup for realising control. Using RINA, this setup is drastically simplified without the duplication (or mirroring) of functions in both planes. There is no concept of a VNF in RINA. A VNF can be realised in RINA as an application, a set of VNFs would form a Distributed Application Facility (DAF). A network slice then is the same construct, a DAF, but with independent configuration characteristics. All network slices are supported by the same underlying Distributed IPC Facility (DIF). The important aspect in RINA is not the creation of multiple functions but the coordinated configuration of the DIFs (underlying, shared data layer functions and network slices). The management plane then is a combination of Operation Support System (OSS), Element Managers (EMs) and VNF related management functions. RINA already provides a simplification in terms of eliminating the EM (it is not required using RINA) and eliminating the VNF management functions (they are simply one of the RINA management functions).

The overall network softwarisation and programmability also uses a plane-oriented design in terms of (from top to bottom): application and business service, multi-service management, integrated network management & operations, infrastructure softwarisation, control plane and forwarding/data planes. RINA already provides the required simplification (and completeness) for the lower planes (infrastructure softwarisation, control, forwarding/data).

For the higher planes, RINA can be used to drastically simplify the required functionality. This can be seen first in the management & operation plane, where the DMS developed in PRISTINE, with its focus on management strategies, provides for integrated management. The other planes go beyond the scope of RINA as a network architecture, but they provide for a set of requirements that RINA will need to address (or show to address) in its application to 5G. For instance, the multi-service management function plane deals with aspects such as slice and service mapping, domain and service orchestration, service information management network discovery. The latter one is already supported by RINA, while the other aspects will require the definition of related strategies to enable the DMS to cover them.

The service & infrastructure management and orchestration provides for some challenges regarding the current state of RINA (and RINA implementations). The described service framework separates physical from virtual infrastructure, which provide north-bound interfaces to software network functions, which in turn support a multi-service platform. All those layers are supported vertically by autonomic network management (lower layers) and autonomic service management (upper layers). Both management aspects are further supported by a large set of common components, as diverse as user rights management, federation management, end-to-end service inventory for higher layers and infrastructure identities, slice lifecycle management and passive & active resources, to name a few of them.

RINA’s strength lies naturally in providing integrated (and simplified yet complete) lower layers (infrastructure, and software network functions). However, RINA will also need to support higher layer functionality (multi-service platform, service management) with at least appropriate strategies and interfaces. The boundary seems to be lower/higher layers in the presented framework, with RINA being able to substitute the lower layers, while supporting the higher layers with significant simplification, while APIs between them remain an open issue.