## 6 Methodology  
IoT devices are commonly characterized by constrained resources and limited capabilities which entail the need for customized Operating Systems (OSs). The common choices in this regard are Contiki OS and TinyOS. These are open-source OSs that implement IPv6-based network stacks to support effective IP connectivity. Both come with practical implementations of 6 LowPANs and RPL to provide IP adaptation and IPv6-based network routing, respectively. Additionally, Contiki OS [56] includes the Cooja network simulator which can be effectively utilized to emulate different IoT scenarios while running the real Contiki OS implementation. It enables building IoT setups using different types of virtual IoT motes that can be configured to effectively emulate real-life IoT deployments. The experimentation of this work was carried out using the Cooja simulator of the most recent version of Contiki OS (Contiki 3.0). For the implementation of the different routing attacks, modifications were made to the RPL code base in the network stack of the Contiki OS. Most of the code modifications were carried out to two main source files: \"rpl-dag.c\" and \"rpl-icmp6.c\". This was carried out for the RPL implementation of the attacker nodes only for running a specific attack ten minutes after the simulation start time. The source code was modified to decrease the rank by two, increase the VN by one, copy and resend the neighbor's DIO messages, and select the parent having the highest rank value for implementing the rank, VN, replay, and WP attacks, respectively. For effective analysis, the experiment was designed with three RPL experimental setups referred to as S1, S2, and S3. It was deemed important to implement different setups of varying-scale network topologies and varying complexity levels for realizing a comprehensive analysis. For each setup, an RPL network of a single RPL instance having one DODAG of a single sink was considered. A total of 25, 40, and 65 nodes were the DODAG sizes of S1, S2, and S3, respectively. Figure 2 presents the network topology of S2. Each one of the sink and sensor nodes was emulated as a Zolertia Z1 mote which has an MSP430 16 MHz MCU. It also comes with a 92 KB flash memory, 8 KB RAM, and CC2420 transceiver. Random placement of the nodes in the simulated deployment area of 300 \(\times\) 300 m was considered for all the setups. A multihop network topology was formed among all the nodes in all the setups. In addition, the communication and interference ranges were configured to 25 and 50 m, respectively, for all the nodes. Table 2 provides a summary of the main simulation parameters. The adopted implementation of the Contiki OS runs the two standard OFs. In this work, RPL was experimented with the MRHOF which is based on the routing metric of ETX. Additionally, each RPL sensor node was configured to run a UDP client for the  
\begin{table}
\begin{tabular}{c c c} \hline \hline \multicolumn{2}{c}{**Simulation Parameter**} & \multicolumn{1}{c}{**Value**} \\ \hline Area Size & & 300 \(\times\) 300 m \\ \hline \multirow{3}{*}{Number of Nodes} & S1 & 25 \\  & S2 & 40 \\  & S3 & 65 \\ \hline Topology & & Random \\ \hline \multirow{3}{*}{Note Type} & Zolertia Z1 \\ \cline{2-3}  & \multicolumn{1}{c}{} & \\ \cline{2-3}  & \mul-frequent transmission of IoT data packets. It regularly sends a UDP packet at a \(\pm\)5 s data communication interval. This is received by the sink node which also runs a central UDP server. Furthermore, different plugins of Cooja were configured at each node. These included the \"collect-view\" and \"powertrace\" modules which simplify the collection of overall performance data and energy consumption indicators, respectively. The evaluation methodology was designed to incorporate multiple experimentation stages as shown in Figure 3. The first one was based on running an attack-free scenario for each experimental setup using the original RPL implementation.