# SRv6-Based Edge Service Continuity in 5G Mobile Networks +
## 6 Testbed and Performance Evaluation
### Performance Evaluation
#### 6.2.1 Scalability Analysis  
Firstly, we conducted measurements on the time required to install rules on network devices for both path allocation and path migration. In our setup, the ONOS sends write operations in a specific order. Operations directed toward a particular switch are not mixed with those for other switches. Furthermore, these operations are sent sequentially, and the ONOS does not wait for one operation to finish before sending the next one. We evaluated scalability across the network topologies explained above. Additionally, we compared our SRv6-based solution with a non-SRv6 one, relying on the standard IPv6 routing mechanism. In the latter mechanism, each router forwards packets solely based on the IPv6 address of either the client or the server. Figure 15 demonstrates the consistent superiority of our solution over the non-SRv6 approach; the most significant disparities are observed in the case of the path allocation procedure. Specifically, under the non-SRv6 method, the configuration of all core network devices is necessary; thus, the effect of the number of core layers is evident. Our approach, instead, needs the configuration of only the ingress and egress edge nodes. However, the number of core layers influences the outcomes because its increase results in the ONOS  
Figure 14: Proposed high-level testbed architecture. being topologically more distant from the egress edge device. The higher the distance between the ONOS and the target device, the higher the latency for the rule installation. Regarding path migration, discrepancies between the two methods are less pronounced, as a similar number of devices necessitate reconfiguration in both cases. The characteristics of the network and the positions of the source and target MEC Hosts with respect to the client impact the number of devices to be reconfigured in the non-SRv6 approach. As stated previously, the distance between the ONOS controller and the target devices impacts the rule installation time. Moreover, the ONOS controller sends the requests sequentially without waiting for a response. Based on that, the outcomes in Figure 15 are influenced by the order in which the ONOS sends the operations. We now analyze the worst-case scenario, i.e., where the ONOS sends the last write operations to the farthest device, which also has the longest processing time. Figure 16 shows the worst-case rules installation overhead across all the involved switches, decomposed to underlying the different contributions. Assuming \(J\) to be the number of network nodes in the system and the number of operations sent to the last node, we define the time at which the ONOS sends operation \(i\) to node \(j\) as \(s_{ij}\). Then, we define \(r_{ij}\) as the time at which that operation enters its destination. Finally, \(d_{ij}\) is the processing time of the above-mentioned operation. We suppose that operations \(i\) and \(i+1\) addressed to node \(j\) are separated, both at transmission and reception by an interval \(\tau_{ij}\). Subsequently, \(\rho_{ij}\) is the time required by node \(j\) to process operation \(i\). To conclude, we suppose that, once the node terminates the execution of operation \(i\), the subsequent operation is already available, as stated by the following formula:  
\[\tau_{ij}\leq\ \rho_{ij}\ \forall\ i,\ j. \tag{1}\]  
The decomposition of the rule installation overhead is also shown in Figure 17, where the worst-case scenario is considered. The first component, the green one, is the interval of the time between the dispatch of the first instruction to the first node and the dispatch of the first operation to the last node, called the request interval. Then, we have the latency, which is the time between the dispatch and delivery of the first instruction to the last node. Figure 16: Worst-case network configuration timeline. Figure 15: Network nodes installation overhead. Finally, we have the computation time, which is the interval of the time required by the last and slowest node to satisfy all the received requests.