# A Study of 5G Edge-Central Core Network Split Options
## 5 Testbed Implementation and Evaluation Results
### End-to-End Network Management Considerations  
For the network management testing, in the testbed illustrated in Figure 6 the deployment of the network service was performed 25 times to get a reasonable number of samples which can be used for calculating statistical properties. The measurement results are shown in Table 5 presenting the average and standard deviation of the total deployment time for both setups and both types of links. As can be seen from the presented results, the VNF deployment time varies between the two types of network management. In the distributed one where we used the ETEO and OpenBaton orchestrators running near the locations of the managed service, the delay of the simulated satellite link is noticeable by a few seconds. However, looking at the total length of the deployment process, the difference due to the delay is not very significant. In contrast, the results of the centralized management option, using one Open Baton orchestrator for managing both locations, show that the satellite link introduced a 60 s additional delay compared to the Ethernet procedure. This increase in deployment time is due to the high number of messages exchanged between the OpenBaton orchestrator and the OpenStack installed at the remote location. In the distributed setup, where the OpenBaton orchestrator resides at the same location as the VNFs, the impact of the satellite link is minimal. The only communication impacted by the delay is the one between OpenBaton and the ETEO and they do not require the same number of exchanges as there are between OpenBaton and the distributed setup. However, considering this, it is still surprising to see such an increase in deployment time, and there may be additional reasons why OpenBaton is affected this much by a high delay connection. Looking at the difference of deployment time, it seems to be better to use the ETEO with OpenBaton deployed at the edge of the network instead of Open Baton alone man \begin{table}
\begin{tabular}{c c c} \hline \hline
**Data Path** & **RTT Delay** & **Control: Backhaul RTT** \\ \hline Edge offloading & 2 & N/A \\ Central with edge offloading & 585 & 582 \\ Central—satellite backhaul & 584 & 582 \\ Central—Ethernet backhaul & 4 & 2.6 \\ \hline \hline \end{tabular}
\end{table} 
Table 4: Average data path delays. \begin{table}
\begin{tabular}{c c c c} \hline \hline
**Setup** & **Backhaul Type** & **Duration** & **Deviation** \\  & & **(s)** & **(s)** \\ \hline Distributed Management & Satellite & 106.051 & 4.24 \\  & Ethernet & 102.823 & 3.562 \\ \hline Centralized Management & Satellite & 161.287 & 4.039 \\  & Ethernet & 94.879 & 3.256 \\ \hline \hline \end{tabular}
\end{table} 
Table 5: Average data path delays. aging the testbed over the satellite link. However, this only hold true if the satellite link is used. The Ethernet connection without the high delay, yields better results when using Open Baton as the only NFV orchestrator. The VNF deployments with the ETEO take about eight seconds longer. This can be explained with the overhead which is introduced by the ETEO which has to process the deployment itself, and most importantly, has to send requests to the Open Baton API for uploading the created VNF packages, NSDs and deployment requests. From these results it can be concluded that in the presented scenario the ETEO can offer an advantage regarding deployment time when used with orchestrators at the network edge while only adding a few seconds of overhead compared to a standalone NFV orchestrator used over a fast connection. A similar set of results is expected to be true for other runtime management operations such as fault, configuration, performance, and security management. However, for these types of management, the local operations are even shorter than in cases of the deployment where multiple virtual machines must boot-up, the effect of the backhaul delay would be proportionally greater.