# Building SDN-Based Agricultural Vehicular Sensor Networks Based on Extended Open vSwitch
## 4 Experimental Evaluation
### Configurations  
In order to validate the proposed architecture and proof-of-concept prototype, we design a scenario about controller failure recovery in SDN-based vehicle sensor networks. When a controller connects to switches normally, all switches are controlled by the SDN controller, but the controller carried by a vehicle can disjoin the sensor network any time or the SDN-Apps of the controller can crash. In these scenarios, the controller is suddenly unavailable, and then the switches of sensor nodes will immediately handoff into disaster recovery mode. Switches will continue to execute the packet-processing logic installed by the controller proactively, which maintains the normal communication of a real vehicle sensor network in agriculture.  
by self-learning actions. Besides, flow table 10 can ensure packet-processing and security control in the data plane when the controller is unavailable.  
To understand this application/service about the controller failure recovery, we will describe how to process a packet in the flow table pipeline. In a sensor vehicle agricultural network, sensor data is transmitted by different sensor nodes. When a data packet arrives at a node's OVS ingress port, the packet is first matched against a rule of flow table 0, which tells what to do according to different scenario states. If communication between the controller and the switch is normal, the rule's action explicitly directs the packet to flow table 1. Flow table 1 will perform the processing of the packet, e.g., send the packet to the controller. If the controller node is unavailable and switches enter into disaster recovery mode, the packet can match the first rule of flow table 0, which executes action self-learning, generates a new rule and installs the new rule into flow table 10. Then the packet is sent to flow table 10 for further processing. For security purposes, the third rule in flow table 10 can drop the packet sent to a protected node who has a specific IP, such as 10.0.0.1. Otherwise, the packet can match against rules generated by self-learning action or the flood rule, which can ensure that communication is normal in the sensor network though the controller is suddenly unavailable.  
Through building this proof-of-concept prototype of the disaster recovery service, it not only can ensure two different scenarios handoff fast and communication is normal, but also prevent the old rules from being used continuously when the network topology may change. To compare with our methodology, we introduce a traditional methodology [18] (an existing mechanism named fail-secure mode in OVS and OpenFlow protocol) into experiments whose flow table is shown in Table 2.  
The Hard_Timeout field of the second rule in the above flow table is set to be one second. This rule's priority is higher than the first rule. The controller should maintain this rule at a regular basis, such as one second. Once the controller node is unavailable, packets will match the first rule and be processed by logical port Normal to maintain the network communication. This methodology is named B1s. The Hard_Timeout field of another methodology named B2s is set to be 2 s. B2s's other configuration is the same as that of B1s. Under the controller failure recovery scenario, B1s and B2s are compared with the methodology of the proposed architecture.