## 4 Experimental Setup and Results
### Analysis and Results of the Algorithm Performance of the SDN Management Layer  
To validate and analyze the performance of the algorithm experimentally, we have considered the availability of the two Flexible Internet Plans (Basic and Premium) previously mentioned, and we have assumed that a network subscriber (one ONT in the testbed) contracts a Flexible Internet Plan (Basic or Premium) and changes its real-time bandwidth demand, whereas the remaining four ONTs in the testbed contract a static Internet Plan. The experimental analysis was carried out at both channels, but in this paper, only the results of the upstream channel are presented for lack of space. However, the performance of the downstream channel is similar. This study should be considered as a proof of concept, since a typical PON will have a higher number of ONTs (e.g., 32-64) with varying demands than we have in our testbed. Nevertheless, to the best of our knowledge, this is the first time that a real-time reconfiguration service policy is experimentally tested in a legacy GPON using SDN techniques. The Basic Flexible Internet plan consists of a guaranteed bandwidth of 100 Mbps plus an excess bandwidth of 20% (that is 20 Mbps), and the Premium Flexible Internet plan shows a guaranteed bandwidth of 150 Mbps with a 30% of excess bandwidth (45 Mbps), both symmetric services. Therefore, for the Basic Internet plan, as shown in Figure 8, the subscriber (ONT) that contracts this plan begins to transmit at 100 Mbps (60 s), and during the following intervals of 5 min (300 s) increases the transmission rate first to 110 Mbps, then to 120 Mbps, and finally to 130 Mbps, ending with a final period transmitting again at 100 Mbps. In addition, Table 2 indicates the transmitted bandwidth at the different interval times and the bandwidth expected to be offered to the residential user at each interval, according to the performance of the online service reconfiguration algorithm. Since the basic contracted bandwidth is equal to 100 Mbps (Table 1), the excess bandwidth is expected to increase up to 20% of this value (Basic Flexible Plan), so the maximum  
Figure 6: Test done on the size of the sliding window: (**a**) Five samples; (**b**) 10 samples; (**c**) 20 samples; (**d**) 30 samples. Figure 7: Real-time fluctuations on the average throughput due to a fall in the transmission rates. bandwidth assigned to the user will be 120 Mbps, whenever the user demands it and there is enough available bandwidth. Therefore, in the fourth interval (660-960 s), although the user demands 130 Mbps, the maximum assigned bandwidth is limited to 120 Mbps (Table 2). Then, Figure 9 shows the real-time evolution of the allocated bandwidth for the service of the ONT measured using Wireshark when the algorithm is working. Therefore, in the first Interval (0-60 s) the service is not modified, since the transmitted rate is equal to the basic contracted bandwidth (100 Mbps). In addition, it can be observed that at the beginning of each interval, a short step appears due to the reaction time of the OVS to a change in the user's transmission rate, as the OVS needs a few seconds (around 5-7 s) to notice an increase. If we analyze each interval one by one, in the second (60-360 s), where the residential user demands 110 Mbps, we observe the first step, followed by the time the algorithm needs to process the real-time demanded bandwidth of the sliding window, and then the instant where the algorithm provides the offered bandwidth to 110 Mbps (its bandwidth demand). The third Interval (360-660 s), where the user demands a rate of 120 Mbps, the result is similar and 120 Mbps are given (the maximum excess bandwidth). However, in the fourth interval (660-960 s) the residential user increases its demand up to 130 Mbps, but the algorithm limits this demand, since the maximum bandwidth associated with this Internet plan is 120 Mbps. Finally, in the last interval (960-1020 s), the user decreases its demand to 100 Mbps, so the algorithm assigns this bandwidth instantaneously.