# Building SDN-Based Agricultural Vehicular Sensor Networks Based on Extended Open vSwitch
## 4 Experimental Evaluation
### Experiment Results
#### 4.2.2 Basic Performance  
As shown in Table 1, our proposed methodology needs to perform stateful matching, self-learning and forwarding. However, in Table 2, the compared traditional methodology only needs to execute the first rule whose action is Normal under the unavailable controller scenario. Besides, our proposed methodology is based on the designed architecture with extended OVS. The comparison traditional methodology is still based on the original OpenFlow Switch OVS. To prove whether the proposed architecture based on extended OVS maintains some of the basic performance of the original OVS, this section shows the basic performance features of our proposed methodology, such as RTT, throughput, CPU usage, _etc._[20]. For convenience, the result of our proposed methodology is marked Approach-A. The result of the comparison traditional methodology is marked Approach-B. We used Netperf's TCP_STREAM and UDP_STREAM to test TCP and UDP throughput [25]. Then under the same test conditions, we also tested round-trip time (RTT). The obtained results are presented in Table 3.  
As shown in Table 3, our proposed methodology's performance is basically the same as the original OVS's performance, which indicates that the speed of lookup and matching using our proposed connection state field is not reduced. The self-learning module is not only triggered flexibly by extended OpenFlow action, but also keeps as good throughput as the original OVS.  
To further measure the packet processing performance using our proposed architecture, we use Netperf's TCP_CRR and TCP_RR test. TCP_CRR repeatedly establishes a TCP connection, sends and receives one byte of traffic and disconnects. TCP_RR only establishes one TCP connection from the beginning. The results are reported in transactions per second (tps).  
Table 4 shows that the number of TCP transmissions and CPU usage is kept in the same level as in the original OVS. In general, our architecture based on extended OVS won't reduce the basic performance.  
Therefore, the results from the above two parts show that our proposed methodology has relatively low failure recovery time, less packet loss and stable throughput. The measured number of throughput and TCP transmissions show our proposed architecture maintains the same basic performance of packet processing and forwarding as the original OVS. Therefore, these results show that the proposed architecture can improve the stability and survivability of a vehicle sensor network in agriculture.  
More importantly, different connection scenarios in the agriculture field may have different vehicle sensor network topologies. In our methodology, packets can match against the corresponding rules in flow tables according to different scenario states, which can prevent the old rules from being used continuously and incorrectly, so in a SDN-based vehicle sensor network, what will not happen is that sensor data packets will be forwarded incorrectly because of the old rules. Besides, the flow table can drop specific packets, such as the packets with a specific IP or Port, to improve the security of the network when SDN controller communication is not reliable enough. This enhances the controllability of the vehicle sensor network under unavailable SDN controller conditions.  
\begin{table}
\begin{tabular}{c c c c} \hline \hline
**Approach** & **TCP RR (ktps)** & **TCP CRR (ktps)** & **CPU (\%)** \\ \hline Approach-A & 57.2 & 10.6 & 63.1 \\ Approach-B & 56.9 & 10.5 & 63.2 \\ \hline \hline \end{tabular}
\end{table}
Table 4: The measured number of Netperf TCP_CRR, Netperf TCP_RR and CPU usage.  
\begin{table}
\begin{tabular}{c c c c} \hline \hline
**Approach** & **RTT (ms)** & **TCP Throughput (Gbps)** & **UDP Throughput (Gbps)** \\ \hline Approach-A & 0.41 & 2.91 & 6.24 \\ Approach-B & 0.43 & 2.92 & 6.12 \\ \hline \hline \end{tabular}
\end{table}
Table 3: The measured numbers of RTT Netperf TCP_STREAM and Netperf UDP_CRR.