# A Network Architecture and Routing Protocol for the MEDIcal WARNING System
## 5 The MultiPath Routing Protocol for MEDIWARN (MP-RPM)
### Data Exchange Phase  
At the end of the init phase, each node has built its own routing table and the data exchange phase begins.  
In this phase, application messages, such as the ones containing the vital signs of a monitored patient, are sent by the end nodes to the sink. Each application message is encapsulated into an Ethernet frame that contains both the source and the destination addresses. The Ethernet frame is then converted into an IEEE 802.11 frame. The relay nodes encapsulate the message in a specific frame format that contains both a sequence number that, in combination with the source address, uniquely identifies the frame in the network and the message type, i.e., routing message or application message. The application frame is then de-encapsulated at the destination, i.e., the sink node.  
During the data exchange phase, each end node periodically (with a configurable period) acquires the vital parameters of a patient and broadcasts them. The end nodes do not implement any routing mechanism. In fact, running Algorithm 2 is up to the relay nodes that are in charge of forwarding the messages to the destination.  
```
1:while (true) do
2:\(m=rcv\_data\_msg()\)
3:\(fw=check\_forwarded(m)\)
4:if (not\(fw\)) then
5:\(pathSet=rTable\_search\_path(m.dstAddr)\)
6:\(sort(pathSet,criterion)\)
7:for (i = 0; 1 < nPath; i++) do
8:\(msg\_forward(pathSet.pop(),m)\)
9:endfor
10:else
11:\(discard(m)\)
12:endif
13:endwhile
```  
**Algorithm 2** Relay node--data exchange phase  
Upon receiving an application message, a relay node checks if such a message has been already forwarded (in such a case, the \(check\_forwarded()\) function returns _true_). If so, the message is discarded; otherwise, a route selection algorithm is run. In particular, the relay node searches in its routing table for all the possible routes to reach the destination. The routes found are sorted in ascending order according to the number of hops required to reach the destination. Next, the relay node selects the first \(n\_path\) paths through which to forward the message. Note that the MP-RPM implements a multipath routing, i.e., each message is sent to multiple paths, to provide redundancy and increase the protocol reliability. Finally, the message is forwarded to the \(nxtHop\) nodes of the selected routing table entries.  
Once an application message has reached its destination (i.e., the sink), the latter checks if such a message has been already received. If not, the sink passes it to the application. Note that the acknowledgement is transmitted at the application layer from the sink to the source and it will be forwarded to the source node using the same mechanism previously described in Algorithm 2.  
When the relay nodes receive the application messages sent from the end nodes nearby, they know which end nodes can be reached through a single-hop communication. This information is inserted in the routing table, by adding proper entries, and then it is propagated to all the relay nodes through a suitable message. The medical staff handheld devices are supported by the MP-RPM algorithm, as such devices periodically send (with a configurable period) to the sink a request for updates relevant to the conditions of one specific patient or of all the patients. Consequently, the sink sends the latest data collected from the end node(s) relevant to all the patients or to the specific one. The relay nodes will forward these messages to the destination, i.e., the tablet that issued the request.