1. Introduction

This paper is an extended version of work published in [1]. We are making this version available in order to have more results and discussions in comparison to its short version.

The 6LoWPAN was introduced by IETF to support a huge number of IP-based embedded devices that are connected to the Internet with a low power network capability. Moreover, the rapid development of the Internet of Things (IoT) ecosystem in multiple areas [2] such as healthcare, smart building automation [3], vehicle [4], etc. had made the embedded device to be in high demand [5]. The embedded devices are categorized as limited power usage, limited cost, limited bandwidth, and small memory usage [6]. Meanwhile, the development of IoT devices become a serious problem to enable interoperability and scalability among devices and systems [7,8]. Thus, the 6LoWPAN protocol was designed to complete and complement the technological constrain as an essential part of the IoT development application and ecosystem.  6LoWPAN that enables the ED which are mainly sensor nodes to connect to the Internet over IEEE 802.15.4 in Physical (PHY) layer and Medium Access Control (MAC) sublayer. Figure 1 presents the 6LoWPAN stack where the adaptation layer was added between the data link physical layer and network layer. 6LoWPAN is a wireless embedded internet [9] that integrates IPv6 with WSN [10] that allows the IP-based ED to connect and exchange information directly with other devices on the Internet [9].  Due to this matter, the energy used for connectivity will save, and for this condition, 6LoWPAN network becomes an essential part of the IoT deployment [11].

Figure 1: 6LoWPAN Stack

However, the infrastructure of IPv6/6LoWPAN and how IPv6 can integrate heterogeneous technology (system, tool, application, etc.) towards a new embedded application protocol (6LoWPAN) for IoT ecosystem become a challenging issue. This because the current standard of 6LoWPAN is limited to 250 kbps, and 127 bytes of frame length compared to IEEE 802.15.4 packet size is 1280 bytes. As a result, it is critically affected for the routing algorithm to optimize the path formation. Indirectly, it will degrade the interoperability of 6LoWPAN devices/applications. Besides, the implementation, integration and evaluation for large scale deployments of sensors networks in buildings, the potential heterogeneous combination of wireless and wired need to optimize the energy consumed by the system itself.

In addition, the 6LoWPAN protocol develops to optimize the routing scheme for converging cast traffic patterns for low power nodes [12]. One of the 6LoWPAN routing protocols is Protocol Over Low-Power and Lossy Networks (RPL) as defined in RFC6550 [13]. Based on previous research, the RPL protocol in 6LoWPAN is effective in terms of delay and Packet Delivery Rate (PDR). But, it can be further improved in terms of overhead as the original value is very high [14] [15]. According to Feschel, Huhn, & Schwetlick in 2012, the fragmentation of the frames should minimize the routing overhead and power consumption in order to save network lifetime that is a critical parameter to 6LoWPAN nodes. On the other hand, to optimize network performance, the routing overhead must be reduced. At the same time, the 6LoWPAN system offers the scalability and as well as interoperability between nodes. Therefore, this research project addresses algorithmic, networking, and application development using the 6LoWPAN CC2538 module in improving the 6LoWPAN protocol to achieve efficient performance QoS of the network in terms of PC. The proposed algorithm is implemented and tested using a simulation study and validated with the experimental approach by developing the 6LoWPAN Smart Home testbed (6LoSH). The initial phase of this study focused on a literature review that has been done in  [17] to address the two (2) following challenges: i) Comparative analysis of existing systems and solutions and ii) Comparative analysis of existing standards and protocols. As a reminder of this paper, we present our work as follows. We describe a methodology used in Section II follows by Section III present the experiment setup. Then, Section IV describes the evaluation results. Finally, we emphasize the contribution of this paper and future works.

2. Methodology

The methodology is divided into three parts, as presented in Figure 2. The first part is the development process, followed by implementation, and the last part is testing and validity.

Figure 2: The Methodology Design

2.1.  Development

The development of 6LoSH involves three (3) important aspects. First, the integration between the 6LoWPAN system requirement and building infrastructure with different technologies like sensors, actuators, and mobile devices. Figure 3 presents the proposed 6LoSH network design, which implements a simple node architecture [11], [9], [18].   6LoWPAN nodes communicated with each other through border router, and share a backbone link to connect to the Internet. This allows all the 6LoWPAN nodes remain the same as the IPv6 prefix. Besides, 6LoWPAN connects to another IP network via a border router. At the same time, the border router is handling the 6LoWPAN compression and Neighbor Discovery (ND) for 6LoWPAN nodes. According to [11] the power consumption usage using simple architecture remain low when the intelligent objects are idle, and increases the data rate in both host and router mode. The end-users will be able to interact with the system by running several applications from their PCs, mobile phones, notebooks, and voice. These applications will make use of the services provided by the building system. They will allow end-user to obtain information about the state of the building and switched off/on the application over the Internet.

Figure 3: Simple 6LoWPAN Nodes (CC2538 Module) Architecture for 6LoSH

Second, the 6LoWPAN node, other hardware, and software requirements towards a new embedded application in developing 6LoSH. Table 1 shows the list of the equipment required for the implementation of the 6LoSH physical deployment. We used the TI CC2538 module [19] as a 6LoWPAN node and border router because it is a very low power wireless module for IoT applications [20], Figure 4. In contrast, Raspberry Pi 3 Model B is used for running the 6LoWPAN Border Router (6LBR). We observed 6LoWPAN packets by using a CC2531 traffic sniffer and the Wireshark packet capture tool with baud rate 115200. Besides, the Contiki OS [21] [22] by performed COOJA simulator is used to set up the CC2538 program and running simulation of the 6LoWPAN network.

Table 1: The equipment required for the implementation of the 6LoSH physical deployment

Hardware and Software Requirement
Equipment	Count	Types, and Description
Node	10	·          The CC2538 Texas Instrument
Border Router	1
Sniffer	1	·          CC2531 USB Dongle
Raspberry Pi 3	1	·          Running 6LoWPAN Border Router (6LBR) ·          Model B (Debian OS)
Contiki OS (Cooja Simulator)		·          Perform simulation testing ·          Writing a program for CC2538 module
Wireshark		·          Packet capturing and analyzing the OTA packet

Figure 4: CC2538 Board

Finally, a novel algorithmic models and scalable solutions for the 6LoWPAN system. The on/off an application for embedded devices has been designed and flashed onto the CC2538 board, namely 6Node. The real-time arrangement of the 6Node setup is shown in Figure 5. Table 2 presents the proposed 6Node protocol parameter setup. The default trickle algorithm [15] is used to control the amount of DIO message in routing traffic by setting the parameter of DIO Interval Min as 12ms and DIO interval doublings as 16ms. To achieve the best Packet Delivery Ratio (PDR), the Minimum Rank with Hysteresis Objective Function (MRHOF, RFC6719) with Expected Transmission Count (ETX, RFC 6551) metrics are used as path selection mechanism [23]-[24].

Figure 5: Real-Time Arrangement of CC2538 setup

Table 2: System Parameter for CC2538 Protocol

Parameter	Algorithm/Coding
Trickle Algorithm	case RPL_TRICKLE_T_TIMEOUT: rpl_trickle_handle_t_timeout(); break; case RPL_TRICKLE_I_TIMEOUT: rpl_trickle_handle_i_timeout(); break;
Nodes rank	#define RPL_OCP_OF0     0 In #define RPL_OCP_MRHOF   1
RPL_Dio Interval Min	#ifdef RPL_CONF_DIOINTERVALMIN #define RPL_DIOINTERVALMIN        RPL_CONF_DIOINTERVALMIN #else #define RPL_DIOINTERVALMIN        12 #endif
DIO interval doublings	#ifdef RPL_CONF_DIOINTERVALDOUBLINGS #define RPL_DIOINTERVALDOUBLINGS RPL_CONF_DIOINTERVALDOUBLINGS

2.2.  Implementation

The implementation process involves the deployed hardware infrastructure, physical network, and integrated with software services for managing and controlling the hardware. Dealing with devices and technologies, it has explored existing platforms and solutions that could be relevant for 6LoSH to achieve effective communication (interoperability) between the nodes and systems [7], [8].  The home appliances are connected to nodes through a relay which in turn is connected to another digital pin of the board as illustrated in Figure 6.  Figure 7 present the 6Node prototypes and Figure 8 show the development of 6Node prototype activities.

Figure 6: The Block Diagram of CC2538 Application (6Node)

2.3.  Testing and validity

The performance of the 6LoSH platform has been evaluated and validated through simulation and calibrate the simulation result using an experiment to ensure the 6Node reach the efficiency of QoS. The HRPL protocol introduced in [1] and RPL standard was used to assess the effectiveness of 6Node in reducing routing overhead toward new embedded applications for the 6LoWPAN environment.

Figure 7: The 6Node Prototypes

Figure 8: The development of 6Node Prototype Activities

3. Experiment Setup

Figure 6 shows the testing design and Table II describes a summary of the evaluation parameter setting for both experiments that was adapted from the existing model in [25] [26,27]. The comparative study in terms of power consumption has been done by using standard HRPL and RPL protocol to investigate the scalability and interoperability communication between devices (6LoWPAN appliances) and network performance. To be fair, the open-source implementations run on the same operating system (OS) which is Contiki OS. The HRPL and RPL protocol was simulated using the Cooja simulator [28,29] (Testing 1). Then, we compared the simulation results with the evaluation of HRPL and RPL through testbed experiments (testing 2). We created similar scenarios for both experiments. Lastly, we evaluated the performance of the HRPL protocol based on defined metrics. Figure 10 present the real-time arrangement of 6LoSH testing.

3.1.  Simulation (Testing 1)

Tmote Sky CC2420 was used as a platform. The set of simulation scenarios (4, 6, 8 and 10 nodes) used in this study as shown in Figure 11. Firstly, the implementation of the RPL protocol from the standard examples of RPL collects file that contains source code of sink and sender nodes are simulated. We set a sink node in the middle of the network and deploy the sender node randomly. We set a transmission range (Tx) to 20m and interference range (INT) to 20m at Unit Disk Graph Model (UDGM) [30]. The radio messages were enabled to capture the traffic and saved as a pcap file.  The saved pcap file would be used to analyze the network using Wireshark network analyzer. Then, the standard RPL collect file is modified by changing RPL library to HRPL library, in both source codes of sink and sender nodes. Next, the HPRL protocol is simulated in the same scenario.  Lastly, the result between RPL and HRPL is compared with four types of power consumption: CPU Power, Transmit Power, Listen Power, and Low Power Mode (LPM). The simulation results will be evaluated for the different number of nodes (4, 6, 8, and 10 nodes).

Figure 9: The 6LoSH Testing Design

Table 3: The Summary Parameter Seting for 6LoSH Testing

Method	Testbed (6LoSH)	Simulation
Protocol	HRPL	HRPL
Transport	UDP/IPv6	UDP/IPv6
Mote Type	CC2538 Module	Tmote Sky
Reception Ratio (Rx)  and Transmission ratio (Tx)	–	100% & 100%
Packet Size	160bytes	160bytes
Queue	150 packets	250 packets
Transmission Power	-17dBm	0dBm
Transmission range	20m	20m
Network Scale	4, 6, 8, 10 nodes	4, 6, 8, 10 nodes
Length	60 minutes	60 minutes
Packet Capturing	Pcap (Wireshark)	Pcap (Wireshark)

Figure 10: The Real-Time Arrangement of 6LoSH Testing

Figure 11: The Set of Simulation Scenario

3.2.  Testbed (Testing 2)

The testbed results are used to calibrate the simulation results and also to validate the performance of HRPL in a real-scenario. In this scenario, one border router (6LBR) is located in the center and the different number of applications (4, 6, 8, and 10 nodes) were deployed randomly on the first floor in one of the houses in Malaysia, as presented in Figure 12.

Figure 12: The 6Node Deployment

3.3.  Performance Metric

The power consumptions are monitor in both experiments through the development of the Powertrace application in the Contiki operating system. There are four types of power are measured:

• CPU Power,
• Low Power Mode (LPM) Power
• Transmit Power and
• Listen Power.

CPU power refers to the power of computation required by the node in active mode while LPM power refers to the power used by the nodes in CPU sleep mode. Meanwhile, the energy used by each node to transmit the data package to the neighbors is called transmit power, and listening power refers to the energy required by each node in ready mode to receive the data package.

4. Results and Discussion

We assumed our experiment a random topology where the nodes were deployed randomly in an area of 20m x 20m (simulation) and 20m x 20m (testbed). We put the sink node in the center of the network. In order to enable interconnection between all the sender nodes, we set up each node with multi-hop transmission distances from the border router. For both experiments, we considered the DAG root at the border router. Then we set up the nodes to generate packets 1 packet/min randomly in a fixed interval time. We derived this analysis using a script to determine when all nodes had printed to the simulator output (simulator) and web interface (testbed) that they joined the DAG.

Table 4: Analysis of Total Power Consumption

Number of Nodes	Testing 1 (Simulation)			Testing 2 (6LoSH)
	RPL (mW)	HRPL (mW)	%	RPL (mW)	HRPL (mW)	%
4	0.995	0.629	36.8	1.576	1.0405	34.0
6	1.015	0.641	36.9	1.607	1.0515	34.6
8	1.021	0.650	36.3	1.623	1.07225	33.9
10	7.239	3.175	56.1	7.906	4.1099	48.0

Figure 13 shows the results obtained from the analysis of HRPL and RPL power consumption usage in different nodes (4, 6, 8, and 10) for testing 1 and testing 2. By comparing the four different nodes, it is evident that the power consumption usage for Number of Nodes (NoN) = 4 is the lowest followed by NoN = 6 then NoN = 8 while NoN = 10 is the highest power consumption usage. The result shows that HRPL is better in all NoN and managed to reduce the overall power consumption by 36.8% (NoN=4), 36.9% (NoN=6), 36.3% (NoN=8) and 56.1% (NoN=10) lesser than RPL in testing 1. While in testing 2 HRPL has obtained a better result that can reduce power consumption by 34.0% (NoN=4), 34.6% (NoN=6), 33.9% (NoN=8) and 48.0% (NoN=10) lesser than RPL.  In this instance, according to the observation, the HRPL had generated a smaller power consumption, and due to the number of nodes, however it had managed to obtain the increases of power consumption in real time scenario (6LoSH) compared in simulation. It is figured out which the power consumption value would have effect under different platform even used the same scenario and system setting. The cooja simulator enable the node which make a simple network and doesn’t requirement gateway to connect to the internet. But different condition in 6LoSH, raspberry pi (powered by battery) used as a 6LBR to deploy the node for physical network and this condition increase the radio transmission power received by each node. Besides, the retransmission activities detected leading to higher power consumption in real scenario.

Figure 13: The Total Power Consumption for Both Experiment.

Table 5 presents the analysis of each type of power consumption for testing 1 and testing 2. The CPU Power, LPM Power, Listen Power, and transmit Power values obtained for each of the experiments were presented in Figure 14-17. It is observed that for NoN = 4 gave a minimum value of LPM Power, CPU Power, and Transmit Power. However, the value of Listen Power is the highest in comparison with others. Based on observation, the node turns on its radio during all its idle slot when it’s set as a parent. This condition not only becomes the listening power increase but also wastes their energy for the whole network. Interestingly, the computation of each node is increased due to the way the node determines the best route from the source node to the destination node[31]. Meanwhile, the T-Sky CC2420 module that is used in simulation has less power compared to the CC2358 module that is used in 6LoSH.

Table 5: Analyses of Power Consumption for Testing 1 (Simulation) and Testing 2 (6LosH)

Types of Power	Number of Nodes	Testing 1 (Simulation)		Testing 2 (6LoSH)
		RPL (mW)	HRPL (mW)	RPL (mW)	HRPL (mW)
CPU Power	4	0.332	0.209	0.453	0.285
	6	0.349	0.213	0.487	0.309
	8	0.357	0.218	0.514	0.328
	10	0.376	0.228	0.586	0.362
LPM Power	4	0.153	0.101	0.224	0.156
	6	0.153	0.104	0.218	0.143
	8	0.153	0.105	0.224	0.145
	10	1.519	0.988	0.551	0.315
Transmit Power	4	0.092	0.054	0.211	0.132
	6	0.086	0.056	0.214	0.134
	8	0.08	0.056	0.214	0.134
	10	0.88	0.504	2.101	1.211
Listen Power	4	0.418	0.265	0.688	0.468
	6	0.427	0.268	0.688	0.466
	8	0.431	0.271	0.671	0.465
	10	4.464	1.455	4.668	2.222

Figure 14: The CPU Power of HRPL and RPL

Figure 15: The LPM Power of HRPL and RPL

Figure 16: The Transmit Power Of HRPL and RPL

Figure 17: The Listen Power of HRPL and HRPL

5. Conclusion

6LoWPAN system enables the ED to communicate with each other using the IEEE 802.15.4 wireless network.  Due to this matter, 6LoWPAN had become a priority network for IP-based communication for ED. However, the design of the 6LoWPAN system in the real-world scenario has become a challenging issue, such as interoperability, scalability, and integration among the nodes, and network. Thus this study aims to develop the 6LoWPAN smart home system (6LoSH) to evaluate the performance of HRPL and compared the result with RPL. The result of this study shows the PC of nodes reached its most minimum for NoN =4 scenarios, while low link quality is linked to NoN = 10 scenarios respectively for both experiments. These results confirm that the 6Node (6LoSH) reaches an efficiency of QoS and HRPL reliability to reduce the PC. The routing overhead for the number of nodes increases significantly with the increase of the PC. The main contribution of this study, the present result shows that HRPL outperforms the RPL standard of PC in both experiments.  However, these results were derived from a limited number of nodes, the Transmission Range (Tx) is 5m, and it was tested for random topology. Further research should be conducted to investigate large-scale networks in multiple topologies for different distances and metrics.

Acknowledgment

The authors would like to thank the Ministry of Higher Education Malaysia and Universiti Teknikal Malaysia, in support the  Fundamental Research Grant Scheme (FRGS) with reference number (FRGS/2018/FTMK-CACT/F00392).

1. N.H. Mohd Yusoff, N.A. Zakaria, A. Sikora, J.S. Sebastian, “6LoWPAN Protocol in Fixed Environment: A Performance Assessment Analysis,” Proceedings of the 2019 10th IEEE International Conference on Intelligent Data Acquisition and Advanced Computing Systems: Technology and Applications, IDAACS 2019, 2, 1142–1147, 2019, doi:10.1109/IDAACS.2019.8924283.
2. H. Yadav, C. Agrawal, “A Review of Enhancing Energy Efficiency of Wireless Sensor Network,” International Journal of Electrical, Electronics and Computer Engineering (IJEECE), 8(1), 46–49, 2019.
3. V.C. Thang, N. Van Tao, “A performance evaluation of improved IPv6 routing protocol for wireless sensor networks,” International Journal of Intelligent Systems and Applications, 8(12), 18–25, 2016, doi:10.5815/ijisa.2016.12.03.
4. T. Abdelkader, K. Naik, A. Nayak, N. Goel, V. Srivastava, “A performance comparison of delay-tolerant network routing protocols,” IEEE Network, 30(2), 46–53, 2016, doi:10.1109/MNET.2016.7437024.
5. J.A. Alzubi, R. Manikandan, O.A. Alzubi, N. Gayathri, R. Patan, “A Survey of Specific IoT Applications,” International Journal on Emerging Technologies, 10(1), 47–53, 2019.
6. S.N.S. Vishalakshi R, Chaithra P, “6LoWPAN Routing Issues,” International Journal Of Engineering And Computer Science, 3(7), 2014.
7. J. Lin, W. Yu, N. Zhang, X. Yang, H. Zhang, W. Zhao, “A Survey on Internet of Things: Architecture, Enabling Technologies, Security and Privacy, and Applications,” IEEE Internet of Things Journal, 4(5), 1125–1142, 2017, doi:10.1109/JIOT.2017.2683200.
8. S. Li, L. Da Xu, S. Zhao, “The Internet of Things: A Survey,” Information Systems Frontiers, 17(2), 243–259, 2015, doi:10.1007/s10796-014-9492-7.
9. Z. Shelby, C. Bormann, 6LoWPAN: The Wireless Embedded Internet, 2009.
10. P. Pongle, G. Chavan, “A survey: Attacks on RPL and 6LoWPAN in IoT,” in 2015 International Conference on Pervasive Computing: Advance Communication Technology and Application for Society, ICPC 2015, 0–5, 2015, doi:10.1109/PERVASIVE.2015.7087034.
11. S.N. Han, Q.H. Cao, B. Alinia, N. Crespi, “Design, implementation, and evaluation of 6LoWPAN for home and building automation in the Internet of Things,” Proceedings of IEEE/ACS International Conference on Computer Systems and Applications, AICCSA, 2016-July, 2016, doi:10.1109/AICCSA.2015.7507264.
12. A.J. Albarakati, J. Qayyum, K. a. Fakeeh, “A Survey on 6LowPAN & its Future Research Challenges,” International Journal of Computer Science and Mobile Computing, 3(10), 558–570, 2014.
13. T. Winter, P. Thubert, A. Brandt, J. Hui, R. Kelsey, P. Levis, K. Pister, R. Struik, J. Vasseur, R. Alexander, “RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks Abstract Low-Power,” IETF RFC6550, doi:10.1017/CBO9781107415324.004.
14. H. Xie, G. Zhang, D. Su, P. Wang, F. Zeng, “Performance evaluation of RPL routing protocol in 6lowpan,” in Proceedings of the IEEE International Conference on Software Engineering and Service Sciences, ICSESS, 2014, doi:10.1109/ICSESS.2014.6933646.
15. P. Levis, T.H. Clausen, J.W. Hui, O. Gnawali, J. Ko, “The Trickle Algorithm,” IETF RFC6206, 2011, doi:http://dx.doi.org/10.17487/RFC6206.
16. M. Feschel, A. Huhn, H. Schwetlick, “Routing protocols for 6LoWPAN,” International Conference on IT Revolutions, 82 LNICST, 71–83, 2012, doi:10.1007/978-3-642-32304-1_7.
17. N.H. Mohd Yusof, N.A. Zakaria, N. Harum, “Design of Smart Building Automation System for 6LoWPAN Network: The Platform Structure,” in Procedings National Symposium on Human Computer Interaction, 2019, 35–37, 2019.
18. E. Toscano, L. Lo Bello, “Comparative assessments of IEEE 802.15.4/ZigBee and 6LoWPAN for low-power industrial WSNs in realistic scenarios,” 9th IEEE International Workshop on, IEEE, 2012.
19. CC2538 Powerful Wireless Microcontroller System-On-Chip for 2.4-GHz IEEE 802.15.4, 6LoWPAN, and ZigBee ® Applications 1 Device Overview.
20. G.A. Naidu, J. Kumar, V. Garudachedu, P.R. Ramesh, “6LoWPAN Border Router Implementation for IoT Devices on RaspberryPi,” SSRN Electronic Journal, 316–323, 2018, doi:10.2139/ssrn.3166729.
21. The Official Contiki OS Blog: Contiki 3.0 Released, New Hardware from Texas Instruments, Zolertia, Jun. 2020.
22. A. Velinov, A. Mileva, “Running and Testing Applications for Contiki OS Using Cooja Simulator,” International Conference on Information Technology and Development of Education, 279–285, 2016.
23. N. Pradeska, Widyawan, W. Najib, S.S. Kusumawardani, “Performance analysis of objective function MRHOF and OF0 in routing protocol RPL IPV6 over low power wireless personal area networks (6LoWPAN),” Proceedings of 2016 8th International Conference on Information Technology and Electrical Engineering: Empowering Technology for Better Future, ICITEE 2016, (7863270), 7863270, 2017, doi:10.1109/ICITEED.2016.7863270.
24. O. Gnawali, P. Levis, “The Minimum Rank with Hysteresis Objective Function,” IETF RFC6719,.
25. J. Vasseur, M. Kim, K. Pister, N. Dejean, D. Barthel, “Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks,” IETF RFC6551, doi:10.1017/CBO9781107415324.004.
26. Y. Tahir, S. Yang, J. McCann, “BRPL: Backpressure RPL for High-throughput and Mobile IoTs,” IEEE Transactions on Mobile Computing, 2(c), 1–1, 2017, doi:10.1109/TMC.2017.2705680.
27. C.-A. La, M. Heusse, A. Duda, “Link reversal and reactive routing in Low Power and Lossy Networks,” IEEE International Symposium on Personal, Indoor and Mobile Radio Communications, PIMRC, 3386–3390, 2013, doi:10.1109/PIMRC.2013.6666733.
28. E. Ancillotti, R. Bruno, M. Conti, E. Mingozzi, C. Vallati, “Trickle-L2: Lightweight link quality estimation through Trickle in RPL networks,” Proceeding of IEEE International Symposium on a World of Wireless, Mobile and Multimedia Networks 2014, WoWMoM 2014, 2014, doi:10.1109/WoWMoM.2014.6918951.
29. A. Dunkels, B. Gronvall, T. Voigt, “Contiki – a Lightweight and Flexible Operating System for Tiny Networked Sensors,” Proceedings of the 29th Annual IEEE International Conference on Local Computer Networks (LCN’04), (January), 2010, doi:10.1109/LCN.2004.38.
30. Y. Bin Zikria, M.K. Afzal, F. Ishmanov, S.W. Kim, H. Yu, “A survey on routing protocols supported by the Contiki Internet of things operating system,” Future Generation Computer Systems, 82, 200–219, 2018, doi:10.1016/j.future.2017.12.045.
31. L. Sitanayah, C.J. Sreenan, S. Fedor, “A Cooja-based tool for coverage and lifetime evaluation in an in-building sensor network,” Journal of Sensor and Actuator Networks, 5(1), 1–22, 2016, doi:10.3390/jsan5010004.
32. L. Lassouaoui, S. Rovedakis, F. Sailhan, A. Wei, “Evaluation of energy aware routing metrics for RPL,” 2016 IEEE 12th International Conference on Wireless and Mobile Computing, Networking and Communications (WiMob), 1–8, 2016, doi:10.1109/WiMOB.2016.7763212.

(Click Here)

(Click Here)