## 2 A Generic Multi-Path and Multi-Channel Proposal for HWMP
### Multipath Proposal and Implementation
#### 2.1.1 Route Management
\begin{table}
\begin{tabular}{c l} \hline \hline
**Parameter** & **Description** \\ \hline
**preq or prep** & PREQ or PREP element received in the node. \\
**read** & Function that extracts the main fields of the **preq** or **prep** elements. \\
**OA\({}_{\mathbf{C}}\)** & Originator address of the current element received. \\
**OA\({}_{\mathbf{P}}\)** & Originator address of the previous element received. \\
**SN\({}_{\text{OA}}\)** & Sequence number of the current element received by **OA\({}_{\mathbf{C}}\)**. \\
**SN\({}_{\text{PA}}\)** & Sequence number of the previous element received by **OA\({}_{\mathbf{P}}\)**. \\
**DA\({}_{\mathbf{C}}\)** & Destination address of the element. \\
**m\({}_{\mathbf{1}-\mathbf{n}}\)** & Cumulative metrics of each path. \\
**f\({}_{\mathbf{f}}\)** & Retransmitter node. \\
**PathID** & Path identifier. \\
**updateMetric** & Calculate and update the airtime link metric according to the received **preq** or **prep** message. \\
**isValid** & Verify if the element received has updated information (sequence numbers), \\  & or if it has a better metric, or different \(f_{r}\). \\
**updateTable** & Update or add a new route if the **isValid** function is true. \\
**RouteSelection** & Request a route to the destination (next hop), taking into account the application. \\
**createPrep** & Create the PREP message according to the parameters of the PREQ message. \\
**sendPrep** & Send the PREP unicast message to **OA\({}_{\mathbf{c}}\)**. \\
**forward\({}_{\text{control}}\)** & Retransmit the **preq** broadcast message through all interfaces. \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Definition of the variables and functions for the PREQ and PREP mechanisms. The main modifications for the reception, processing and forwarding of a PREP message are similar to those explained for the PREQ messages and are detailed in Algorithm 2. On the other hand, the criteria for the retransmission of the PREP messages towards the node that originated the PREQ message must consider the multiple paths created and not take erroneous paths. In other words, each PREP message must know which was the path that its corresponding PREQ message took. To this end, a field has been added both to the PREQ-PREP messages and to the routing table (\(PathID\)), which allows the nodes to obtain the correct path (destination address) for each PREP message that must be generated or forwarded. For instance, in the example shown in Figure 3, \(N_{3}\) makes use of this field to route \(PREQ_{1}\) and \(PREQ_{2}\) to their corresponding nodes correctly. Figure 3: Modification to the acceptance criteria when the destination node receives a PREQ message. (**a**) HWMP. The destination node replies with a unicast PREP message to the source node. (**b**) MPC-HWMP. The destination node replies to all received PREQ with unicast PREP messages to the source node through its different paths. Figure 2: Modification to the acceptance criteria when the intermediary nodes receive a PREQ message. (**a**) HWMP. \(N_{3}\) receives, processes and forwards the \(PREQ_{2}\) message if and only if it has a better metric than \(PREQ_{1}\). (**b**) Multi-Path Multi-Channel (MPC)-HWMP. \(N_{3}\) receives, processes and forwards \(PREQ_{2}\) to maintain multiple paths.