# Routing Protocols for Low Power and Lossy Networks in Internet of Things Applications
## 5 Discussion, Lessons Learned, and Open Issues
* Seek a satisfactory trade-off among the network aspects: As mentioned in the course of this work, the requirements of the 6 LoWPAN routing protocol can vary according to the applications. Some applications can demand reliability, while others want energetic efficiency. However, the requirements of applications are frequently concurrent among them. As an example, the improvement of the network load balancing can affect the end-to-end delay negatively. Thus, routing solutions must seek a satisfactory trade-off among the concurrent requirement of the applications. * Robust solutions with low complexity: The approaches currently presented seek to cover drawbacks, improve the weaknesses of an existent solution, or attend to as many requirements as possible. However, the design of an enhanced or \"perfect\" solution can generate unexpected results. With the increment of algorithm complexity, devices can be overloaded, causing a decrement to the network performance. With this, the approach needs to be robust to consider all the relevant requirements in the scope of the applications and, at the same time, be simplistic and light for execution in devices with low computational power. * Consider the IETF's recommendations: Although the consideration of the IETF specifications is not mandatory, several efforts were demanded to define the routing requirements for the different types of IoT/6 LoWPAN applications. When considering the study approaches in the overview of this work, the routing solutions developed for specific applications do not consider IETF's recommendations. The consideration of IETF's guidelines can allow the proposal for a satisfactory behavior, high acceptability, and the future standardization of the solution. * Interoperability with base protocols: The majority of studied routing solutions are based on already existent routing protocols. Thus, they use almost all the structure of the base protocols as RPL and AODV. However, a small number of current approaches provide support and interoperability with the protocol on which they are based. This gap makes the adoption of these new solutions difficult in an already functioning IoT network, because it would require updating the firmware of the nodes. Thus, it is recommended that new solutions can interact with the base protocols, allowing the coexistence of both in the same network. A way to attend to this requirement is by avoiding significant changes in the fields and processing the mode of control messages. * Compatibility of existent OSs and boards: The current state-of-the-art presents a large set of boards (Arduino, WSN430 open node, M3 open node, TelosB, Zolertia Z1) that are constantly used in IoT scenarios. In recent years, several Operation Systems (OS) [104; 105] were especially developed for the IoT context, e.g., Contiki OS [70] and RIOT OS [106]. It is desired that the new routing solution can be executed by the most recent adopted boards and OS for IoT. To this end, the proposal should be exhaustively tested through emulation, simulation, and real testbeds (although this can be expensive). The RENODE\({}^{\text{TM}}\)[107] can be helpful to reach these features. * Make available and reproducible proposals: Although it is possible to find several routing proposals in the literature, the number of these that can be entirely reconstructed and studied is low. Commonly, the routing solution proposals are superficially described, and many details are suppressed. Thus, it is difficult to perform an accurate reproduction of the presented approaches. Providing flowcharts, algorithms, message structures, and mathematical equations helps the proposal to be better understood and makes it implementable. Because of this, the approach can be considered for comparison with another proposal or utilized for real IoT application. It is also essential to show a full description of the testbed or simulation parameters to allow a fair comparison among the solutions.