## 3 LOADng Protocol Overview
### LOADng Route Discovery  
When a node wants to send a data message, it should look for a route to the message destination on its Routing Set. If the path is found, the node should forward the message to its destination through the next hop node. The message forwarding process is described in detail in Section 3.4. However, if the wanted destination is not found, the node should start a new route discovery process.  
In the routing discovery process, the node generates a new RREQ message, defining itself as originator and the address of the desired destination in the destination field. It should also set a unique seq-num to the RREQ and define the other message fields. Then, the node should broadcast the generated RREQ to its neighbors.  
Each receiver of the RREQ message should execute its processing according to the flowchart presented in Figure 2a. In the first verification that checks the length of addresses and other details, the message, if considered valid, is subjected to the common processing used both for RREQ and RREP messages. In the common processing (presented in the flowchart in Figure 2c), the node should update the fields of hop-count, hop-limit, and route-metric from the message. In sequence, the node should search for a route entry for the message originator on its Routing Set. If the route is not found, a new route entry for the message originator is created. Then, the created or found route entry is compared with the fields of the received message to verify whether or not the message can be used to update the route entry. If the message is valid, the route entry is updated, the common processing is finished, and the message returns to its specific processing. In contrast, if the message is not used to update the route entry, the node should verify the message type, send an RREP_ACK if required, and drop the message. When the message returns to the specific RREQ processing, the node should check whether it is a message destination. If negative, the node should verify whether the message is valid to be forwarded (checking the hop-count and hop-limit), updating its fields, and forward it using broadcast. Otherwise, if the node is the RREQ destination, it should generate an RREP message to answer the request from the RREQ originator.  
The generated RREP message should have the address of the RREQ originator as destination, the address of its originator in the originator field, and a unique seq-num. After being generated, the RREP should be sent in unicast to its destination. Thus, the RREP originator should look for a route entry to the destination on its Route Set and forward the message to the R_next_hop node. Note that the route entry should be found after it has been created by the RREQ message being received. A node that receives the RREP message should perform its processing as described in the flowchart in Figure 2b. After the first validation, the message is submitted to the common message processing (similar to an RREQ message and following the flowchart in Figure 2c). After this processing, the RREP receiver should verify the necessity of generating and sending an RREP_ACK message. In sequence, the node should check whether it is the message destination. If not, the node should consult whether the message is valid to forwarding, verify its Routing Set looking for an entry to the RREP destination and send the message to the R_next_hop node using unicast. Otherwise, if the node is the RREP destination, the route discovery process is completed, and the data message can be sent using the constructed path.