113 CHAPTER 5 OPTIMIZATION OF CONTIKIRPL 5.1 INTRODUCTION The WSN network-link reliability and best link selection depends upon the routing protocol objective function and routing protocol parameters. The Internet Engineering Task Force (IETF) has standardized the Routing Protocol for Low Power and Lossy Networks (RPL) to be used in WSN. The overall network metrics like packet delivery ratio, battery consumption depends upon the routing protocol network response and control packets overhead. The RPL parameters influence the performance of WSNs. The current work analyzes the contribution of RPL parameters to the routing link quality and to obtain the optimized values using regression based mathematical modelling concept. In order to deploy WSN for any particular application, the RPL parameters have to be analyzed and optimized. The optimal value must be used in deployment. The Contiki OS with RPL implementation is suitable for deployment in real-time practical scenario. In the current project RPL protocol operation is briefly studied, and simulated using COOJA Simulator, a Java based real-time simulator. The actual application layer code is used to analyze the network metrics using COOJA Simulator. These optimal values can be used in the deployment of Arduino board, a low cost efficient mote. The route selection and other parameters can be studied using passive probing mechanisms. The passive probing is a recent trend deployed in WSN analysis.
114 The current work will provide a good understanding and optimization for WSN before deployment and in reconfiguration of objective function. Optimization of network and battery efficiency is the primary concern for the deployment of WSN. The RPL parameters decide battery consumption, network efficiency, routing-tree convergence time, routing table correction and data collection rate. Battery consumption depends on the overhead due to the transmission of control packets. Optimization of network and battery efficiency is the primary concern for the deployment of wireless sensor network to any specific case. RPL parameter impacts on network efficiency and overhead are obtained by the simulation of WSN environment using COOJA simulator and MATLAB curve fitting tool is applied to find the optimum RPL parameter value for a particular implementation. Traditional Zigbee based mesh networking require royalty fee for commercial deployments and the code may lack compatibility with future versions of motes. The ultimate goal of the work is to provide a real-time royalty free Contiki OS based WSN for future implementation. Indigenous solution of wireless sensor motes is needed in the atomic radiation monitoring and military applications. The open source software console is available to monitor, control and tweak every parameter of the network. No malware or spyware can hide in the open source code. For any practical deployment, the complete stack can be thoroughly analyzed. The network monitoring console with Java based front end will be helpful in monitoring the node activities with its remaining battery power and RSSI among each parent. Multiple parent selection in each node to ensure the safe delivery of the packets can be accomplished in RPL with slight changes in MAC layer protocol. The current work is a base work for many upcoming valuable projects to the society satisfying the practical requirements.
115 5.2 CHOICE OF OPERATING SYSTEM The Operating System in case of WSN is a very challenging one, as it demands high memory and processing power constrained environment with a need for conservation of battery power also. The selection of a particular operating system depends on parameters listed in Table 5.1 below. Table 5.1 Comparison of various available WSN OS Parameters Scheduling Dynamic Reprogramming WSN Operating Systems (OS) Contiki Tiny OS MANTIS SOS Pre-emptive Non Preemptive Pre-Emptive Non Preemptive YES YES NO YES Thread Stack Memory Shared Stack Individual Individual Individual Programming Language C NesC C C Active Development Yes Partial No No The Contiki OS, with event driven mechanism, also with support for proto-thread based execution with active developers is the ideal candidate. Contiki 2.7 version was released in November 2013 with vast improvement in areas of IPv6 mesh networking and lot of bugs are fixed, with a neat code flow. Apart from TI, Atmel, AVR, ST, Arduino platforms, TI CC2538 802.15.4 System-on-a-Chip, PIC32 platforms are also added to the supported platforms list. The advantage lies in the real time simulation of the above platforms in COOJA simulator, with a new regression framework. The competitor TINY OS with NesC framework (steep learning curve) and static only compilation modules makes it a slow runner in terms of
116 the competitive WSN market (Gay et al 2003). Almost most developers in this area switched to Contiki OS due to its structured framework written in C and availability of real time simulation, direct hardware support (Tsiftes et al 2010). The code written need not be altered for the deployment purposes. The code analyzed and debugged in simulator will work in the field hardware, most of the times, reducing development time, time to market and also facilitating cost-effective application development. The real hardware is not mandatory during application development phase. Thus analyzing all the above parameters Contiki OS is being opted for the long term use in precision agriculture, with no royalty fee. The custom application framework of zigbee framework is not reliable, due to the following reasons; new versions may not be compatible with older version like the case with Microsoft development framework and royalty fee for commercial agricultural deployment. 5.3 CONTIKI OS Contiki is an open source, multi-tasking operating system for memory-efficient network embedded systems and memory constrained wireless sensor networks which are highly portable. Contiki is especially designed to adapt the microcontrollers with small amount of memory. A Contiki configuration typically consumes 2 KB of RAM and 40 KB of ROM. Contiki supports IP communication with both IPv4 and IPv6. The uipv6 embedded IP stack, is used by a large number of companies (Dunkels 2004; 2012). Contiki introduced the idea of using IP communication in low-power sensor networks. This subsequently led to an IETF standard and the IPSO Alliance, an international industry alliance. Contiki is developed by a group of developers and experts from industry and academia. The Contiki
117 team currently consists of sixteen developers from various organizations such as SICS, SAP AG, Cisco, Atmel, NewAE and TU Munich. Contiki contains two communication stacks: uipv6 and Rime. uipv6 is a small RFC-compliant TCP/IP stack that creates the possibility of communication with internet. Contiki runs on a variety of platforms ranging from embedded microcontrollers such as the MSP430 and the AVR to low configuration computers. The footprints of the code occupy several kilobytes whereas the memory utilization is configured to be as low as few bytes. Contiki is written in the C programming language and is freely available as open source under a BSD-style license. 5.3.1 Contiki Folder Structure The folder structure of Contiki OS is shown in Figure 5.1 and the entire code for RPL routing protocol is present in /Contiki- 2.6/core/net/rpl/rpl-icmp6.c. RPL timer logic is present in rpl-timers file. The formation of DODAG tree is present in rpl-dag file. Figure 5.1 RPL and its related folders
118 The complete logic of the routing protocol RPL and its corresponding code is available in these folders. The macros in RPL configuration are declared in rpl.conf. The rpl.c file contains the routing logic and objective function calculation functions. The rpl-icmp6.c file contains coding for routing wrapper functions. The rpl-private file contains data structure specific to RPL layer. The UDP socket program is used to run the real time application with a Border router and several motes. 5.3.2 COOJA Simulator A COOJA simulation environment is used for the evaluation of the Optimized ConitkiRPL protocol using Contiki Operating System. COOJA is an extensible java based cross level real time simulator for the Contiki OS. It simulates actual working of the wireless sensor nodes and provides bit level accuracy timing between different nodes. COOJA is a user friendly simulator as it is implemented in JAVA. It allows the interfacing of JAVA native interface with the sensor node software which is written in C language. This makes the software extensible to the users. COOJA has high flexibility as well as allowing the simultaneous simulation of all levels of the system; sensor node platforms, operating system software, network level protocol, radio transmission model and radio transceiver. The performance of COOJA is evaluated in terms of efficiency, scalability, flexibility and extensibility. Many factors affect the efficiency of the simulator such as number of nodes, radio model allocation and number of concurrent observers. During simulation, COOJA has the flexibility in allowing the usage of a range of radio models and the evaluation of the performance of the Optimized ContikiRPL protocol is done using unit disk graph model with distance loss. The network size is varied as 30, 50,100 nodes of same type with the native code. This radio model creates a loss in packet transmission if the radio range of a particular mote is greater than it
119 communication range threshold. There are four interfaces namely position interface, ID interface, clock interface and LED interface for each simulated node. The LEDs of the nodes are toggled periodically 10times/sec. The serial logs generated from the nodes can be viewed in the mote output window, which is stored in the file for later analysis. The following are the steps to simulate the Wireless Sensor Network on COOJA simulator, Start the COOJA simulator by entering following commands in the path /Contiki-2.6/tools/COOJA $cd /Contiki-2.6/tools/COOJA $ant run The above command shows the COOJA simulator default window, from the file menu, create a new simulation. Save the simulation in file system with a file name. type of mote. Add motes from Motes menu->add Mote drop down->choose the Choose the program file that has to be compiled or create a new simulation. Choose the advanced settings parameters During compilation, choose the number of motes and its arrangement. Important Note: Increase the buffer size from tools->buffer size. The buffer size denotes the buffer memory allocated for the number of log output lines generated.
120 The flow chart of execution in the COOJA simulator environment is shown in Figure 5.2. Start Create new simulation Add WSN mote Compile program Correct Errors Compilation Errors? Run Simulation Analyze log files Stop Figure 5.2 Flow Chart of Simulation using COOJA The simulation is carried out using 2.4 MHz Pentium processor with 512MB RAM running on Ubundtu. The sample screen shot of COOJA simulator environment is shown in Figure 5.3 and its flowchart is shown in Figure 5.2. The screen shot illustrates the radio interaction among WSN motes. The log messages from the individual motes are shown in milliseconds in the mote output window. There exists a linear relationship between the simulation time and processing power. As the number of active interfaces and plug-ins increases the execution time and processing power has a gradual increase as well.
121 Figure 5.3 COOJA Simulator Screen Shot 5.3.3 Network Performance Metrics Calculation Among the various network metrics, convergence time, control overhead and packet delivery ratio is computed using the following formulas. The necessary debug prints are included in the Contiki RPL layer code. The log messages generated during simulation of WSN motes are stored in a log file. The log file is analyzed using the PERL script. The PERL script is developed to act on a set of files and the result is collected in result.log file. The formulas for calculating network performance metrics is shown below Formulae: Convergence time = Last Dag Joined First Dio Sent Control Overhead = (Control Packets / Data Packets) *100; Packet Delivery Ratio = (Successfully Received/ Transmitted Packets) *100;
122 5.4 REGRESSION ANALYSIS In order to investigate the relationship between the input and output variables, Regression analysis is a suitable statistical tool (Brown 2001). This analysis ascertains the effect of one variable over the other variable. The unbiased nature of estimation about causal variables of interest over other variables is explored obviously. An estimator is said to be unbiased if the mean of the variable is equal to the true value of the parameter. If it is biased, then the consistency of the variable for accurate estimation is checked. An estimator is said to be consistent, if it utilizes the additional information of the variable such as variance and verifies for zero, as the sample size is enlarged to a large value. This means the estimate is equal to the true value with a limit of infinite sample space. An estimator is said to be efficient or best if the variance of that variable is very low. 5.4.1 Regression Analysis Mathematical Models used In any Industrial situation, to predict the output from several input parameters, prediction of appropriate mathematical model for the system under consideration is a foremost task. The mathematical modeling using linear and non linear equations can be predicted by using regression analysis (Orlov 1996). Traditional examples for regression analysis are Tar Output from Industry based on input fuel temperature Engine Mileage The concept of regression analysis deals with finding the best relationship between output and input parameters by quantifying the strength of relationship and finding the best mathematical model. Upon identifying the suitable model, prediction of future response is made possible.
123 The linear and non-linear models used in regression analysis and their application areas are shown in Table 5.2. Table 5.2 Mathematical models comparison table Name Model Equations Best Usage n+1 Polynomial Model y = p i x n+1 i Exponential Model Fourier Series i=1 y = ae bx y = ae bx + ce dx n y = a 0 + i=1 a i cos nwx + bisinnwx n Gaussian Model y = a i e x b 2 i c i i=1 *Simple Empirical Model *Interpolation *Extrapolation *Rate of change of quantity is proportional to the initial quantity *Periodic Signal analysis *Peak Fitting Process *Spectral peaks Modeling 5.4.2 Best fit Analysis RPL Optimization Models The best model suited for mathematical prediction can be judged from fit parameters namely, Error Sum of Squares (SSE), Coefficient of Determination (R 2 ), Root-mean-square-error (RMSE). The Error Sum of Squares SSE value is variation due to error, or variation unexplained. If SSE= 0, all variations are explained. SSE = n i=1 yi yi 2 (5.1) equation, The total corrected Sum of Squares SST is given by the following SST = n i=1 yi yi 2 (5.2)
124 The SST represents the variation in response that ideally would be explained by the model. The quantity and the Coefficient of Determination R 2 is a factor to determine correctness of fit. If fit is correct and all the residuals are zero then R 2 will be = 1. If fit is not proper, worst case R 2 will be = 0. Maximum value of Coefficient of Determination states the correctness of fit. R 2 = 1 SSE SST (5.3) The lack of fitness can be predicted using S 2 fit parameter. Lesser the value of S 2, means better is the fitness of model. S 2 = k i=1 n i i si 2 n k = k i=1 n i j =1 n k y ij yi 2 (5.4) The next fitness parameter Root-mean-square-error (RMSE) is a measure of differences between the values predicted by a model and simulation results. The individual differences are called residuals. The RMSE is a good measure of accuracy but useful only to compare various mathematical models. The results obtained from real-time simulation can be used to predict an appropriate mathematical model to identify the impact of routing protocol parameters. The Routing protocol parameters are optimized based on the predicted mathematical model. The suitable mathematical model for routing parameters was found by goodness of fit. The goodness of fit was analyzed by statistical metrics such as R 2, RMSE values. Mathematical function for different parameter impact was found and applied in maxima and minima algorithm to get optimal values. The surface fit models will be helpful to analyze multi-variable optimization. The interpolated model with bi-harmonic function and
125 polynomial function is shown in Figure 5.4 & 5.5. Figure 5.4 shows, surface fitting of DIO Interval Minimum rate and DIO Doubling rate versus network convergence time using interpolate bi-harmonic function model. Figure 5.5 shows surface fitting of DIO Interval Minimum rate and DIO Doubling rate versus network convergence time using polynomial function. Figure 5.4 Surface Fitting Interpolated bi-harmonic function Figure 5.5 Surface Fitting Interpolated polynomial function
126 5.5 PROPOSED METHOD OF OPTIMIZATION OF RPL 5.5.1 Impact of RPL Parameters The RPL protocol has trickle timer mechanism for routing table formation, stabilization and repairing. The three RPL parameters such as DODAG information Object (DIO) Interval minimum rate, DIO Doubling rate, DIO Redundancy rate decides network response in terms of convergence time and energy efficiency in-terms of control overhead ratio. Impact analysis of the above said parameters to network performance was carried out, and plotted in a graph. Using Regression analysis, the mathematical model is obtained for different experimental graphs. The Regression analysis provides co-efficient of mathematical models for RPL optimization. The Mathematical functions obtained were optimized using second-degree differentiation techniques such as maxima and minima functions, with constraint limits. 5.5.2 Steps to Optimize RPL Routing Protocol Step 1: Devise Experimental Setup and Research methods. i.e decide parameters selected for analysis and environmental parameters was also standardized. Step 2: Implant debug log messages in application and Contiki OS routing code. Step 3: Run Simulation for different experimental setup. Step 4: Collect the log files with specific name and simulation time. Step 5: Devise PERL script to analyze the log files.
127 Step 6: Obtain relation between RPL parameter and network performance metrics. Step 7: Apply regression analysis and obtain the mathematical mode. Step 8: Plot and validate goodness of mathematical model. Step 9: Apply Optimization algorithm upon obtained mathematical functions. Step 10: Tabulate the optimum values. Step 11: Use optimum values for hardware deployment. Proposed optimization method is carried out for RPL routing using COOJA network simulator and results are plotted in Simulation Results. The optimum values are discussed in Table 5.14. 5.6 IMPLEMENTATION 5.6.1 DIO Interval Minimum Rate - Variation The DIO INTERVAL MINIMUM is an important RPL parameter that determines the frequency of control packets being sent from the parent nodes to children nodes in a DODAG Graph. If the DIO INTERVAL MINIMUM time is very short, then a large number of control packets will flood the network, this will lead to collision and packet loss. The short DIO INTERVAL MINIMUM RATE time value will lead to faster network convergence. The routing path will get stabilized in a short time-span. If any node is lost, then local repair and global repair will also take place in as faster rate. DIO INTERVAL MINIMUM will have impact on following network quality parameters,
128 Convergence time Control Overhead in turn leads to energy loss Packet delivery ratio Energy consumption due to control overhead data Hence DIO INTERVAL MINIMUM value has to be optimized. The default value specified in RPL draft is 3 seconds. This leads to large control overhead. The Contiki OS has set a default value of 12 seconds. The simulation results are shown in Table 5.3. Table 5.3 RPL simulation for DIO interval minimum variation RPL Simulation for DIO Interval Minimum RPL Parameter - Convergence Control Data Ctrl/Data DIO Interval Min Time (s) Packets Packets Packets Ratio 6 3.876 2816 1400 201.14286 8 4.948 985 1500 65.666667 10 5.873 1046 4960 21.08871 12 33.762 356 1420 25.07044 14 69.925 295 1740 16.95402 18 764.518 113 900 12.55556 22 2474 1066 4360 24.44954 Simulation Setup: 20 Nodes & 1 Border Router Simulation Time 10000 ms
129 Figure 5.6 Convergence time variation for DIO Interval Minimum The convergence time for the DIO Interval Minimum variation is shown in Figure 5.6. The lower convergence time is better for the network stabilization and network repair. The figure is drawn using Microsoft Excel. It is obvious that the convergence time increases with various values of DIO Interval Minimum. Figure 5.7 Control Overhead variation for DIO Interval Minimum
130 For the lower values of the DIO Interval Minimum, the control overhead is very high. To find the optimal value of DIO Interval Minimum rate, the mathematical model for experimental value should be obtained. The MATLAB curve fitting tool is used to determine the goodness of the fit. The fitness of mathematical model is shown in Table 5.4 and Table 5.5. Table 5.4 RPL DIO Interval Minimum Convergence Time Analysis RPL DIO Interval Min vs Convergence Time : Model Fitness Table S.No Model name R 2 RSME SSE 1 Polynomial Deg 1 0.7232 593.1 1.412exp6 2 Polynomial Deg 2 0.9773 170.2 1.59 exp 5 3 Polynomial Deg 3 0.9997 23.16 1609 4 Polynomial Deg 4 0.9997 28.35 1607 5 Exponential - 1 term 0.9997 73.81 2.7exp4 6 Exponential - 2 term 0.9977 62.38 1.168exp4 7 Fourier Series - 1 term 0.9973 196.6 1.159exp5 8 Fourier Series - 2 term 0.9999 17.09 292.1 9 Power Series - 1 term 0.9981 44.14 9741 10 Power Series - 2 term 0.9984 44.83 8038 11 Gaussian Model - 1 term 0.9999 10.14 411.1 12 Gaussian Model - 2 term 0.9999 23.41 547.8 13 Rational Polynomials 1 term 0 - - 14 Rational Polynomials 2 term 0.9986 49.65 7394 15 Sum of Sines - 2 term 0.9665 168.9 2.851exp4 16 Weibull Distribution 0 - -
131 Table 5.5 RPL DIO Interval Minimum Control Packet Analysis RPL DIO Interval Min vs Ctrl Packet Overhead : Model Fitness Table S.No Model name R 2 RSME SSE 1 Polynomial Deg 1 0.4108 57.08 1.629exp4 2 Polynomial Deg 2 0.8218 35.1 4927 3 Polynomial Deg 3 0.9449 22.53 1523 4 Polynomial Deg 4 0.9963 7.125 101.5 5 Exponential - 1 term 0.9552 15.74 1239 6 Exponential - 2 term 0.9953 6.614 131.2 7 Fourier Series - 1 term 0.8218 40.53 4927 8 Fourier Series - 2 term 0.9963 10.08 101.5 9 Power Series - 1 term 0.969 13.1 858.6 10 Power Series - 2 term 0.9922 7.362 216.8 11 Gaussian Model - 1 term 0 - - 12 Gaussian Model - 2 term 0 - - 13 Rational Polynomials 1 term 0.06306 80.48 2.59exp04 14 Rational Polynomials 2 term 0.4619 70.43 1.488exp04 15 Sum of Sines 0.410 63.82 1.629exp04 16 Weibull Distribution 0 - - The default value of DIO Interval Minimum rate in Contiki OS is 12 seconds and optimized value using mathematical modeling is 11 seconds. The predicted model curve and the experimental data points are shown in Figure 5.8.
132 Figure 5.8 DIO Interval Minimum Curve fitting Results 5.6.2 DIO Doubling Rate - Variation DIO Doubling rate time is used to decrease frequent firing of DIO messages in case of a stable network. If link metrics are same and no update occurrs in RPL DODAG Tree, then the DIO Doubling timer is increased. Next DIO message will be transmitted after the expiry of DIO Interval Minimum. New DIO Interval Minimum = Original DIO Interval Minimum + DIO Doubling Rate
133 Table 5.6 RPL Simulation for DIO Doubling Rate RPL Simulation for DIO Doubling Rate RPL Parameter - DIO Doubling Rate Convergence Time (s) Control Packets Data Packets Control/Data Packets Ratio 8 1.982 407 857 47.491 10 1.982 401 820 48.902 12 1.982 403 840 47.976 14 1.982 401 800 50.125 16 1.982 411 893 46.025 18 1.982 447 1060 42.170 20 1.982 421 924 45.563 Simulation Setup: 20 Nodes & 1 Border Router Simulation Time 10000ms Figure 5.9 Convergence Time variation for DIO Doubling Rate
134 Figure 5.10 Control Overhead variation for DIO Doubling Rate From the results of the graph shown in Figure 5.9 and 5.10, one can clearly see that the DIO Doubling rate has no impact on the convergence time but the control overhead decreased considerably with increase in DIO Doubling rate. The default value is 12 seconds and manual optimal value obtained from simulation is 18 seconds as evident from Table 5.6. Table 5.7 RPL Simulation - DIO Doubling Rate vs Convergence Time S.No Model name R 2 RSME SSE 1 Polynomial Deg 1 0.7143 1.404exp-16 9.86 exp-32 2 Polynomial Deg 2 Not fit 3 Polynomial Deg 3 0.7143 1.8 exp-16 9.86 exp -32 5 Exponential - 1 term 1 0 0 6 Exponential - 2 term 1 0 0 7 Fourier Series - 1 term 1 0 0 8 Fourier Series - 2 term 1 0 0 9 Power Series - 1 term 1 0 0 10 Power Series - 2 term 1 0 0
135 The goodness of the mathematical model to fit the experimental results is shown in Table 5.7 and Table 5.8. From the tables, the best mathematical model for convergence time and control overhead is obtained. Table 5.8 RPL Simulation - DIO Doubling Rate vs Control Overhead S.No Model name R 2 RSME SSE 1 Polynomial Deg 1 0.393 2.227 24.79 2 Polynomial Deg 2 0.4796 3 Polynomial Deg 3 0.6658 2.133 13.65 4 Polynomial Deg 4 0.8765 1.588 5.043 5 Exponential - 1 term 0.3878 2.236 25.01 6 Exponential - 2 term 0.4616 2.708 21.99 7 Fourier Series - 1 term 0.7074 1.996 11.95 8 Fourier Series - 2 term 0.993 0.5335 0.2846 9 Power Series - 1 term 0.325 2.348 27.57 10 Power Series - 2 term 0.4494 2.371 22.49 11 Gaussian Model - 1 term 0.4879 2.287 20.92 12 Gaussian Model - 2 term 0.4879 4.573 20.92 13 Rational Polynomials 1 term 0.6684 1.84 13.55 14 Rational Polynomials 2 term 0.7517 1.839 10.14 15 Sum of Sines 0.5653 4.214 17.76
136 Figure 5.11 DIO Doubling Rate - Curve fitting Results The DIO Doubling Rate has a default value of 20 seconds and optimized value is 18 seconds. The optimization helps to reduce control overhead and improved battery efficiency. The predicted curve using regression analysis is shown in Figure 5.11. 5.6.3 DIO Redundancy Rate - Variation The RPL DIO Redundancy rate parameter does not affect the convergence time but it will affect the control overhead data. The simulation data is tabulated and shown in Table 5.9.
137 Table 5.9 DIO Redundancy Rate Convergence Analysis RPL Simulation for DIO Redundancy Rate RPL Parameter - Convergence Control Data Control/Data DIO Redundancy Time (s) Packets Packets Packets Ratio 10 1.982 395 800 49.375 12 1.982 409 840 48.690 14 1.982 395 800 49.375 16 1.982 395 800 49.375 18 1.982 488 960 50.833 20 1.982 407 860 47.325 22 1.982 403 840 47.976 Simulation Setup: 20 Nodes and 1 Border Router, Simulation Time 10000 ms Figure 5.12 Convergence Time variation for DIO Redundancy Rate
138 Figure 5.13 Control Overhead variation - DIO Redundancy Rate The experimental data is plotted using the line chart as shown in Figure 5.12 and Figure 5.13. The control overhead minimum occurs at DIO Redundancy Rate of 20 seconds as per manual calculation. The best fit analysis for experimental data is shown in Table 5.10 and Table 5.11. Table 5.10 Model Fit Parameters for DIO Redundancy Rate Convergence Time S.No Model name R 2 RSME SSE 1 Polynomial Deg 1 0.7143 1.404 exp -16 0 2 Polynomial Deg 2 Not fit 3 Polynomial Deg 3 0.7143 1.813 exp -16 9.861 exp -32 4 Polynomial Deg 4 Not fit 5 Exponential - 1 term 1 0 0
139 Table 5.11 Model Fit Parameters for DIO Redundancy Rate Control Overhead S.No Model name R 2 RSME SSE 1 Polynomial Deg 1 0.1381 1.154 6.663 2 Polynomial Deg 2 0.3372 1.132 5.124 3 Polynomial Deg 3 0.3852 1.259 4.753 4 Polynomial Deg 4 0.6111 1.226 3.006 5 Exponential - 1 term 0.137 1.155 6.671 6 Exponential - 2 term 0.3185 1.325 5.268 7 Fourier Series - 1 term 0.5479 1.079 3.495 8 Fourier Series - 2 term 0.7256 1.457 2.121 9 Power Series - 1 term 0.1039 1.177 6.927 10 Power Series - 2 term 0.3093 1.155 5.34 11 Gaussian Model - 1 term 0.3373 1.132 5.123 12 Gaussian Model - 2 term 0.4621 2.039 4.158 13 Rational Polynomials 1 term 0.0232 1.374 7.551 14 Rational Polynomials 2 term 0.9618 0.3138 0.2955 15 Sum of Sines 0.3372 1.132 5.124 16 Weibull Distribution Not fit Figure 5.14 MATLAB Curve Fitting - DIO Redundancy Rate
140 The default value is 20 seconds and optimum value from the model fitted curve is 18 seconds. The MATLAB curve fitting graph is shown in Figure 5.14. 5.6.4 Node Count Based - Metrics Variation The number of nodes per border router is an important parameter to determine the required number of border routers for a particular deployment. If the number of nodes per border router is increased then large number of control packets will be required to settle the network and more number of hops is required to reach root node. The simulated values for node count variation are tabulated in Table 5.12. Table 5.12 RPL Simulation for Node Count Variation RPL Simulation for DIO Redundancy Rate RPL Parameter - Convergence Control Data Ctrl/Data DIO Redundancy Time (s) Packets Packets Packets Ratio 10 1.982 395 800 49.375 12 1.982 409 840 48.690 14 1.982 395 800 49.375 16 1.982 395 800 49.375 18 1.982 488 960 50.833 20 1.982 407 860 47.326 22 1.982 403 840 47.976 Simulation: 20 Nodes and 1 Border Router Simulation Time 10000 ms The experimental data is plotted in Microsoft Excel as shown in Figure 5.15 and Figure 5.16. The control overhead has to be minimized for long battery life. In order to find the optimum value, mathematical modeling has to be done.
141 Figure 5.15 Convergence Time variation for Node Count Variation Figure 5.16 Control Overhead variation for Node Count Variation The convergence time variation with respect to the number of nodes deployment is shown. The optimal value of 20 nodes per border router will be taken up during the real time simulation. The packet delivery ratio of the different nodes is given in the graph. Some nodes are having very low packet deliver ratio as 30 %. The nodes closer to the end gateway router node
142 has 100% packet delivery ratio. The packet delivery ratio with respect to node ID is shown in Table 5.13 and also plotted in Figure 5.17. Table 5.13 Packet delivery ratio for Different Nodes Node ID Packets Transmitted Packets Received Packets Delivery Ratio 1 40 40 100 2 40 40 100 3 40 28 70 4 40 40 100 5 40 26 65 6 40 40 100 7 40 39 97.5 8 40 40 100 9 40 27 67.5 10 40 40 100 11 40 39 97.5 12 40 28 70 13 40 13 32.5 14 40 21 52.5 15 40 31 77.5
143 Figure 5.17 Packet Delivery Ratio for Different Node IDs Table 5.14 RPL Optimized values S.No. Parameter 1 DIO Interval Minimum rate 2 DIO Doubling rate 3 DIO redundancy rate 4 No. of Nodes Optimum values of RPL Parameters Optimization Criteria Convergence Control data Overhead Convergence Control data Overhead Convergence Control data Overhead Convergence Control data Overhead Model used Gauss Model Degree 1 Polynomial Degree 4 Exponential Model 1 Term Fourier Series Model Degree 2 Exponential Model 1 Term Polynomial Degree 4 Polynomial Degree 4 Fourier Series Model Degree 1 Default value (Sec) Optimum Value (Sec) 12 3 11 20 30 18 22 22 30 None 39 10
144 The simulation results were used to get the mathematical model using regression analysis. The optimal value for both energy efficiency and network response using different mathematical models are tabulated in Table 5.14. Among several mathematical models, the best fit model for individual RPL parameter with respect to energy optimization was selected and tabulated. 5.7 SUMMARY The ultimate objective of the current project is to develop Wireless Sensor Network (WSN) motes with energy efficiency, royalty-free, open-source and cost-effective hardware and software for ready deployment. In order to get energy efficiency, the control packets transmitted per unit-time must be reduced. RPL is IETF designed routing protocol for WSN motes. In the current project RPL protocol performance in large deployments upto 60 motes per border router with multi-hop transmission is analyzed with respect to RPL parameters such as DIO Interval minimum rate, DIO Doubling rate and DIO Redundancy rate. The mathematical model was obtained using regression analysis and the optimum values were determined with respect to energy efficiency for long battery life. The hardware specification and feasibility analysis show that Contiki OS loaded into Arduino UNO board will be an optimal and cost-effective solution.