## 4 Proposed LOADng Enhancement for IoT Networks
### Internet Route Discovery Process
Thus, if it is found, the node should use a mechanism similar to SmartRREQ to assist the path creation. Hence, the node changes the RREQ-IoT destination to the found R_destination, updates the other message field and sends the message in unicast to the R_next_hop. If more than one Internet route exists in the Routing Set, the node should select the one that best address the used routing metric. However, if an Internet route entry is not found in the Routing Set, the node should use the IRC mechanism, if it is activated. Considering that the node does not use the IRC, it should update the RREQ-IoT message fields and transmit the message in broadcast. Independent of the transmission mode of the RREQ-IoT (unicast or broadcast), the next receiver of the message should perform the process previously described. Please note that unlike the normal route discovery process, the Internet route discovery process searches for any IN rather than a defined destination address. During the RREQ-IoT message processing, the node does not verify whether it is the message destination, but whether it has an active Internet connection. In addition, it is possible that an intermediate node that knows an Internet route will change the RREQ-IoT destination and redirect the Internet route discovery. Figure 4 explains how this may occur. Consider that node \(A\) needs to send an Internet message and has begun an Internet route discovery process. Node \(B\) has received the RREQ-IoT from \(A\) and begun its processing. \(B\) does not have an Internet connection but finds an Internet route to node \(C\) on its Routing Set. Thus, \(B\) changes the RREQ-IoT destination to node \(C\) and forwards the message in unicast to \(C\). Thus,  
Figure 3: Flowcharts of RREQ-IoT control messages processing. Dotted lines represent the optional flow used when IRC is adopted. inspired by the SmartRREQ, the Internet route discovery process is optimized to reduce the number of broadcast transmissions, thereby contributing to the reduction of energy consumption. As previously explained, a node with an Internet connection that receives an RREQ-IoT should generate a reply message to answer the request. Thus, the node generates an RREP-IoT, defines its own address as originator, and the address of RREQ-IoT originator as destination. The message should also have a new unique seq-num. Then, the node transmits the RREP-IoT message in unicast to the next address in the path to the destination. The node that receives an RREP-IoT should perform its processing, which is very similar to the normal RREP processing, following the flowchart in Figure 2b. Thus, the node verifies whether the message is valid for handling and then executes the common message processing. In the common message processing of an RREP-IoT, all created or updated route entries to the message originator should include the information that R_Internet_conn is TRUE. In addition, the R_valid_time of the Internet route should be, by default, two times greater than the valid time of regular routes. Since only Internet-connected nodes can generate RREP-IoT messages, the intermediate nodes that forward RREP-IoT messages should not be included as R_Internet_conn set as TRUE. Thus, the RREP-IoT message performs the maintenance of routes and creates the path to the Internet nodes. At the end of the common processing, the node can generate an RREP_ACK message, if necessary. In the LOADng-IoT, the RREP_ACK generation, transmission, and processing are equal to the default LOADng. In sequence, the RREP-IoT receiver verifies whether it is the message destination. If false, the node should check whether the message is valid to forward, perform the message update, and transmit it to its destination. Otherwise, if the node is the message destination, the Internet route discovery process is completed, and the node can begin the sending of Internet messages. In the described Internet route discovery process, all nodes that receive an RREQ-IoT should reply using an RREP-IoT.