## 4 Experimental Setup and Results
### Analysis and Results of the Algorithm Performance of the SDN Management Layer
Consequently, it can be noticed that the algorithm implemented in the SDN layer shows a fast and stable response according to the contracted Internet plans of residential users. Moreover, it should be noted that DBA algorithms may need extra time to react to changes in the transmission rate of users as well as the OVS. \begin{table}
\begin{tabular}{c c c} \hline \hline
**Interval Time** & \
\begin{tabular}{c} **User Transmission Rate** \\ **(Mbps)** \\ \end{tabular} &
\begin{tabular}{c} **Expected Allocated** \\ **Bandwidth (Mbps)** \\ \end{tabular} \\ \hline
0–60 s & 100 Mbps & 100 Mbps \\
60–360 s & 110 Mbps & 110 Mbps \\
360–660 s & 120 Mbps & 120 Mbps \\
660–960 s & 130 Mbps & 120 Mbps \\
960–1020 s & 100 Mbps & 100 Mbps \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Demanded and received bandwidth for the basic flexible Internet plan. Figure 8: Real-time evolution of the requested bandwidth for the residential user that contract the basic flexible Internet plan. For the Premium Internet Plan, we consider a residential user that contracts an Internet service, which consists of a basic symmetric service of 150 Mbps plus an excess bandwidth of 30% (in that case 45 Mbps or more). However, in that case, the transmission rate of the residential user starts at 150 Mbps for 60 s and after that, it is increased in five min intervals (300 s). It has been considered that in each interval the bandwidth demand is increased by 20 Mbps, so that the evolution of the demanded bandwidth in the different period times is 150, 170, 190, 210, and finally 150 Mbps again. All these levels are reflected in Table 3, which represents the demanded bandwidth by the user in the different time intervals and the expected bandwidth that will be received according to the algorithm's performance. Unlike the previous case, now the residential user has a basic bandwidth higher than 100 Mbps, in which the corresponding Internet Plan may provide an excess bandwidth of 30%, so the maximum bandwidth that could be assigned is 195 Mbps, as observed in Table 3 in the interval 660-960 s. Therefore, the algorithm will create new flows based on the average bandwidth of the window, until reaching the maximum established of 195 Mbps. Figure 10 represents the real-time evolution of the allocated bandwidth for the service of the ONT measured using Wireshark. During the first period of change 60-360 s, in which the requested transmission rate is 170 Mbps, the algorithm shows two small steps and two transition zones between them just after offering this requested bandwidth. As it was mentioned before, the first step corresponds with the time required by the OVS to detect the change in the transmission rate of the user. Meanwhile, the algorithms process the data of the sliding window and send the order to the ODL controller to change the maximum bandwidth. Then, the second step corresponds with the time that the OVS needs to receive, process, and update the new flow sent by the ODL with the new transmission rate (meter) so the OVS becomes unstable during this period of time. Finally, the OVS updates the new maximum permitted bandwidth to 170 Mbps, that is the real- time demanded bandwidth. For the second period of change and the third, the performance of the algorithm is similar. Therefore, it can be noticed that the algorithm is able to dynamically evolve the allocated bandwidth according to the stipulated QoS requirements although the OVS needs a certain time to react to real-time changes in the transmission rate of users. In the same way, typical DBA algorithms inside OLTs probably also take time to deal with real-time changes in the transmitted traffic of residential users.