# Validating a 5G-Enabled Neutral Host Framework in City-Wide Deployments
## 6 Validation of Use Cases
### Results Analysis  
To demonstrate the benefits of the proposed framework, we deploy three slices over the neutral host infrastructure and measure the required SDT as expressed in Equation (1). The composition of such slices consists of one compute chunk, one network chunk and one radio chunk with radio nodes to provide cellular access to the end-users. Additionally, we deploy an NS with a \"moderate\" level of complexity (composed of four VNFs and two VLs) over such slices and, afterwards, we scale out one of the involved VNFs. The corresponding time performance results, averaged over 30 iterations, appear in Figure 5 considering each one of the involved operations over the three city pilots. In Figure 5, we can appreciate that, in the considered scenarios, the slice deployment takes on average less than 37 s. For the sake of completeness, the associated SCT and SAT values are also included in the figure to better illustrate the impact of both operations on the resulting SDT. Meanwhile, the instantiation of the four VNFs composing the considered service is completed in around \(84,96\), and \(123\) s over the Barcelona, Bristol and Lucca pilots, respectively. In terms of scaling, average SSTs of less than 45 s are also observed. Although obtained results in most of the cases are very well aligned with the expected KPI outcomes, some differences in performance are observed when comparing the three city testbeds. In particular, higher SDT, SIT, and SST are experienced in the Lucca pilot, which is mainly due to the smaller capabilities of the servers deployed in that city. Nevertheless, observed differences between the three pilots are not significant, and in overall, this analysis demonstrates the good performance, in terms of deployment times, of the proposed neutral host solution to be deployed in city-wide 5G infrastructures. To evaluate the impact of using the proposed framework for service orchestration, we compare the obtained results for SIT and SST considering as baseline the standalone use of OSM to perform the instantiation and scaling operations. Figures 6 and 7 illustrate the performed comparison at a more granular level by depicting each one of the 30 iterations considered in this evaluation, over the Barcelona testbed. The motivation behind this analysis is to quantify the time overhead incurred by the proposed platform during the instantiation (Figure 6) and scaling (Figure 7) actions that are not directly introduced by the underlying NFVO. Figure 6 shows that the overhead in terms of SIT remains acceptable, with values around 10 s in the performed evaluation. This overhead is due to the time required by the two first tasks listed before during the definition of the SIT KPI (i.e., networking setup and placement computation, see Section 6.1.4), which are performed by the proposed platform before conducting the third task, which directly corresponds to the service instantiation executed through OSM. Likewise, Figure 7 evidences low overhead values in terms of SST, which are around 3 additional seconds. In this case, the observed overhead is a result of the automated reaction management that is done by the Slice Manager to retrieve the associated information  
Figure 5: Deployment times of neutral host platform. Figure 6: Time overhead against standalone OSM for Service Instantiation Time. Figure 7: Time overhead against standalone OSM for Service Scaling Time. (such as scaling type and identifier of the involved VNF) that is needed to handle this request, before actually conducting the service scaling via OSM. Summing up, Table 1 compiles the average results obtained for each one of the five KPIs considered in this evaluation during the trials conducted in the three city pilots. In addition to the previously discussed results in terms of SDT, SIT, and SST, the User Experienced Data Rate and Data Plane Delay measurements are also outlined in this table.