# Context-Based Dynamic Meshed Backhaul Construction for 5G Heterogeneous Networks
## 3 SDN-Based Implementation As A Proof-Of-Concept
### MmWave Mesh Backhaul Resiliency  
Due the physical properties of mmWave links, often a network can suffer from temporary link failures due to loss of connectivity, caused by obstacle blockage, for example. While long-lasting link failures can be detected and repaired by the SDN controller (by computing a new network path and re-routing the traffic, for example), short failures might not be able to be promptly detected by the controller or, by the time the controller detects the failure and computes a new network configuration, the disruption caused by the failure can already be over. \begin{table}
\begin{tabular}{c c c} \hline \hline
**Path** & **Throughput (Gbps)** & **RTT (ms)** \\ \hline N1-N2 & 1.51 & 0.835 \\ N1-N2-N4 & 1.51 & 1.088 \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Baseline latency and maximum throughput values. Figure 10: Photo of mmWave meshed network testbed. For short-lasting link failures, the network should be able to react locally and re-route its traffic to an active link. OpenFlow (OF) groups allow the specification of different instruction sets to deal with a single forwarding rule (action buckets). In addition, it is possible to choose different group types, allowing different criteria for selecting the used bucket. As a solution to provide resiliency when multiple links are available, a fast-failover (FF) group type can be used. When using FF, a packet is sent to the first live bucket. The criteria for deciding the liveness state of each bucket is then implementation-specific. OVS allows the usage of the Bidirectional-forwarding detection (BFD) protocol [37] to monitor the managed links' states. With BFD, the link status can be monitored by sending probe packets on each link periodically. The port is considered down if 3 packets are not received. The probing time can be adjusted, taking around 3 times the configured interval to notify a port as down. Thus, a shorter BFD monitoring interval yields a faster detection of down states, at the cost of increased traffic and processing overhead. In opposite, a high interval is not suitable to promptly detect a failure [38; 39]. [PERSON] et al. [40] explored the robustness in OF-based Software-defined Wireless Networks. This work proposed a multi-path aware solution for the OF controller channel. Experimental work with SDN in wireless and fast-failover using BFD had been reported in [41], where the recovery times of IEEE 802.11 ac links is measured, by using different BFD intervals. Resiliency with BFD over mmWave bands is covered within emulated environments in [39; 42], and with testbed measurements in [26]. In order to investigate the behavior of BFD with different monitoring intervals, we evaluate its behavior when applying different amounts of data traffic in the used links (between 10 Mbps and 1.5 Gbps), while varying the BFD interval between 1 ms and 20 ms. For that, we generate traffic from N1 to N4 by using an internal OVS network interface, using iperf[43] as a traffic generator, by creating an UDP flow with 7882 byte packets with the desired bitrate during 10 s. The evaluation of TCP (Transmission Control Protocol) over mmWave links brings additional set of parameters to configure (e.g., congestion control protocol), increasing the evaluation' s complexity, which is out of the scope of this work. The used topology allows the usage of 2 different link-disjoint paths, N1-N2-N4 (path 1) and N1-N3-N4 (path 2). To monitor the link state, we configure BFD between the interfaces connecting N1-N2 and N1-N3, respectively. In addition, the network throughput is measured with tshark, by capturing incoming traffic on both its mmWave interfaces. The results for the different measured throughput values in the traffic client are presented in Figure 11. For all the used UDP flow rates, it is possible to observe a significant throughput degradation when using 1, 3 and 5 ms BFD monitoring intervals. Contrariwise, the throughput always reached the desired values with the 10, 15 and 20 ms intervals.