5G-MoNArch: 5G Touristic City

Network slicing

This testbed proves the feasibility and functionality of network slicing in real network operations. Network slices allow achieving greater flexibility and efficiency, as well as supporting different services with different characteristics and requirements. The Touristic city testbed has virtualised several functions in the user-plane (such as the higher layer of the RAN and the UPF) which are moved by the orchestration in order to provide the desired behaviour.

Network Orchestration

5G-MoNArch provides orchestration and management platform and applies customised orchestration algorithms which are demonstrated in both testbeds. This allows flexible deployment of relevant Network Functions (NFs) across the network when needed and according to the network conditions.

NFV

The Touristic city testbed has virtualised several functions in the user-plane (such as the higher layer of the RAN and the UPF) which are moved by the orchestration in order to provide the desired behaviour.

Network elasticity

Network elasticity and efficient use of the resources is a crucial topic that is analysed in context of 5G-MoNAch and poses several technical challenges. The outcome and the result of the investigation concluded in WP4 will be implemented in Touristic City testbed.  The use cases designed for touristic city allow taking the advantage of provided solutions for elastic orchestration and resource allocation strategy.

AI-based data analytics

The orchestration algorithms that are being developed for Touristic City testbed rely on Artificial Intelligence (AI) and Machine Learning (ML) techniques. The goal is to design specific algorithms that would determine the best VNF placement between central and edge clouds and design elastic NFs capable of resource adaptation and utilisation depending on the current network condition

Orchestration-driven Elasticity

This innovation focuses on the ability to re-allocate NFs within the heterogeneous cloud resources located both at the central and edge clouds, considering service requirements, the current network state, and implementing preventive measures to avoid bottlenecks. The algorithms that implement orchestration-driven elasticity need to cope with the local shortage of computational resources by moving some of the NFs to othe.r cloud servers which are momentarily lightly loaded. This is particularly relevant for the edge cloud, where computational resources are typically more limited and more cost efficient than in the central cloud. Similarly, NFs with tight latency requirements should be moved towards the edge by offloading other elastic NFs without such tight timescale constraints to the central cloud servers

Computational Elasticity

The goal of exploiting computational elasticity is to improve the utilisation efficiency of computational resources by adapting the NF behaviour to the available resources without impacting performance significantly. Furthermore, this dimension of elasticity addresses the notion of computational outage, which implies that NFs may not have sufficient resources to perform their tasks within a given time. To overcome computational outages, one potential solution is to design NFs that can gracefully adjust the amount of computational resources consumed while keeping the highest possible level of performance. RAN functions have been typically designed to be robust only against shortages on communication resources; hence, the target should be directed at making RAN functions also robust to computational shortages by adapting their operation to the available computational resources. An example is a function that chooses to execute a less resource-demanding decoding algorithm or number of iterations in case of resource outages, admitting a certain performance loss