# A Study of 5G Edge-Central Core Network Split Options
## 5 Testbed Implementation and Evaluation Results
The satellite link was simulated using the Linux Netem tool which we configured for a relevant delay of 580 ms, as measured for the core network split and with a limited network capacity of 2 Mbps in uplink and 26 Mbps in downlink. These values are consistent with the values measured over the real satellite link as used in the functional split testbed as described above. To have a faster testing process, we have chosen a second testbed with virtual links for this network's management. Additionally, the normal variations of the backhaul network have a minimal impact on the measurements as the evaluated procedures have a significantly larger measurement scale, as presented in the evaluation section. The two nodes were based on OpenStack (Stein release) [13] enabling the dynamic deployment and the scaling of the different components. Virtual machines brought the necessary network dynamicity which was not included within the packet core testbed previously described. As a proof-of concept for the management operations, the deployment of the core network was considered. For the other operations related to fault, performance or security management, similar considerations can be made as most of the steps would be the same, as presented in the assessment below. For the deployment an ETSI Network Functions Virtualization (NFV) Management and Orchestration (MANO) orchestration function [14] was deployed based on the Fraunhofer FOKUS OpenBaton toolkit [15]. To showcase the distributed network management scenario, an additional End-to-End Orchestrator (ETEO) was implemented. As illustrated in Figure 6, for the ETEO a hierarchical approach was taken. It manages the multiple NFV MANO functions which manage different areas of the network, in our case the edge and the central network. From the network administration perspective, it is seen similar to an ETSI MANO exposing the same API for the management of the deployed system. The added value is the underneath API where it communicates commands to the NFV MANO orchestrators and coordinates their responses to provide a unitary system. It was assumed that the ETSI MANO components would not be aware of each other, to use already existing network management functions, without requiring any modifications, simplify the number of interfaces and at the same time to maintain the locality of their management operations. A second setup was also deployed on top of the testbed described. It establishes a direct management of the edge infrastructure following the current ETSI MANO indications. In this setup, only the OpenBaton Orchestrator located at the central network is used which interacts with the two OpenStack installations as it is expected from the interaction between OpenStack and Virtual Infrastructure Managers (VIMs). The measurements performed for the evaluation focus on the total deployment time of a Virtual Network Function (VNF). This is the time span from the moment the user  
Figure 6: Network management testbed implementation. starts the deployment process for a network service from a pre-downloaded VNF image up to the point at which the VNF is considered as deployed by the NFV orchestrator. In the distributed setup, the NFV orchestrator, which acts as the start and endpoint of the deployment, is the ETEO and in centralized setup it is Open Baton.