A Bidirectional Adaptive Multihop Routing Algorithm for Wireless Body Area Networks

Wireless Body Area Networks are composed of sensor nodes that may be implanted in the 1 body or worn on it. A node is composed of a sensing unit, a processor and a radio unit. One of the 2 nodes, the sink, acts as a gateway between the body area network and other networks such as the 3 Internet. We propose a routing protocol that constructs paths between nodes such that the final network 4 topology is a tree rooted at the sink. The protocol’s aim is to increase network lifetime and reliability, 5 and to adapt to network conditions dynamically. Moreover, the protocol enables communications 6 between nodes and sink both in the upstream direction, from nodes to sink, and in the downstream 7 direction from sink to nodes. When the network tree is constructed, a node chooses its parent, i.e., next 8 hop to sink, by using one of various criteria. Namely, these are the number of hops between parent 9 and sink, energy level of parent, received signal strength from parent, number of current parent’s 10 children, and a fuzzy logic function that combines multiple criteria. Moreover, as time progresses the 11 tree structure may dynamically change to adapt to conditions such as the near-depletion of a routing 12 node’s energy. Simulation results show improvements in network lifetime and energy consumption 13 over the older version of the protocol. 14

near depletion may save energy by not forwarding traffic from its children which become "orphaned". 48 Orphan nodes are able to rejoin the network by choosing a new parent. 49 By modifying the design of the AMR protocol, we were able to improve its performance and extend 50 its functionality. The first modification is to change the route selection process by adding a new metric 51 that a node uses when joining the network. This metric is the number of current children of the potential 52 parent node. In more detail, a node, when joining the network's tree, chooses the parent with the least 53 number of children. This is to prevent a situation where some nodes are overloaded with children and 54 others have few or no children. Overloaded nodes suffer premature "death" which deteriorates network 55 lifetime. The second modification is related to the sink, where the original protocol gives priority to the 56 sink to become parent even against the logic of the route selection criterion. For instance if the criterion is 57 reliable communication, then a node should choose as parent the node with the highest received signal 58 strength even if it is not the sink. The third and final modification is to extend the protocol by adding 59 support for bidirectional flow of data. The original protocol, as many other WBAN routing protocols, 60 supports a unidirectional flow of data; upstream from nodes to sink. This is the prevalent direction since 61 this is how sensing data are collected. However, some data need to travel downstream from sink to 62 nodes such as network management data, e.g., configuration commands.

63
In Section 2, we present our design of the protocol. We start by introducing the design of the original 64 protocol as a Finite State Machine (FSM). We follow that by an analysis of this design based on careful 65 inspection of the protocol's specification and simulation results. Finally, we describe our modifications 66 and additions to the original design. Section 3 includes both the analysis and simulation results of 67 our proposed protocol. Results are discussed in order to provide a better understanding the protocol's 68 behavior. Finally, the paper is concluded in Section 4.

70
In the original protocol [12], the main objective is to construct a tree topology. The sink is the root of 71 tree at level 0. Level 1 includes all nodes that are one hop from root, i.e., the root's direct children. In 72 general, if a node is at level i (i hops from root) then all of its direct children are at level i + 1. Tree construction in the original protocol follows the following steps:

75
• The node configured as sink sends a broadcast Hello message.

76
• When a node receives the sink's Hello, it replies by a Join message.

77
Submitted to Sensors, pages 2 -11 www.mdpi.com/journal/sensors • When the sink receives a join message from node i, it replies to i by an Accept message. Node i 78 then updates its routing table to list the sink as its parent.

79
• When a node becomes the sink's direct child, it sends a broadcast Hello message.

80
• Nodes that receive one or more Hello messages that are not from sink, wait for an h-wait time 81 period. The value of h-wait is a protocol parameter that is configured in a timer.

82
• The function of the h-wait time period is to enable a node to potentially receive more than one 83 Hello message. The node then uses a metric to decide which Hello sender to choose as potential 84 parent.

85
• When the h-wait period has passed, the node sends a Join message to the parent it has chosen.

86
Then, the node waits for an a-wait time period expecting to receive an Accept message.

87
• When the node receives an Accept message, it modifies its routing table by listing the message's 88 sender as parent. Now the node is part of the tree being constructed.

89
• When a node joins the tree at some level, it sends broadcast Hello messages advertising its 90 willingness to become parent. Thus, the tree continues to be constructed.

91
The metric that a node uses to decide which Hello sender to choose as potential parent is one of the 92 following four metrics [12]:

93
• NoH: The node chooses the parent with the least Number of Hops away from root.

94
• RSSI: The node chooses the parent with the highest Received Signal Strength Indicator.

95
• BEL: The node chooses the parent with the highest Battery Energy Level.

96
• FLF: The node uses a Fuzzy Logic Function of the three previous metrics.

97
A node that has joined the network will be able to send data packets to the sink by sending them 98 to its parent. The parent will, in turn, forward packets to its own parent, and so on till packets reach 99 the sink. So, a node needs to store only the address of its parent in its routing table. On the other hand,

109
We studied the operation of the AMR protocol and ran ns-2 [13] simulations in order to analyze 110 its performance and were able to find the following shortcomings. Firstly, when a node hears a Hello 111 message that is sent by sink, it tries to join the sink without waiting to receive other Hello messages.

112
However, when it hears a Hello message from a node that is not the sink, it waits for time period h-wait 113 to receive more Hello messages. It will then choose a parent from one of the Hello senders. This logic 114 favors the sink over other nodes even when the parent choice metric dictates otherwise. Of course, at the 115 start, the sink will always be chosen as parent since it will be the only node broadcasting Hello messages.

116
This is necessary for "bootstrapping" the network. However, after some nodes have joined the sink, they Secondly, it is desirable that parent nodes in the network tree are more or less equally loaded by 125 network traffic. This is because if a node is much more loaded than others, its energy will be depleted 126 prematurely, which well negatively affect the network's lifetime. For nodes to be equally loaded by 127 traffic, the number of children should not vary greatly from one parent node to another, since parent 128 nodes forward traffic received from their children. The original protocol does not attempt to provide an 129 even distribution of child nodes to parent nodes.

130
Thirdly, the original protocol states that a child node should send a Leave message to its parent, 131 whenever the energy level of parent drops below some threshold. However, it is not clear from the 132 protocol's description how the child will know the value of the parent's energy. This is emphasized by 133 the fact that network traffic is sent only in the upstream direction, from child to parent. In this situation,

134
the parent needs to broadcast information about its energy level, either periodically or only when the 135 energy level drops below the configured threshold. Then, child nodes will be able to send the Leave 136 message in ample time. This way parent nodes will consume valuable energy and create more network 137 traffic than needed for collecting sensor data.

138
Fourthly and finally, the original protocol does not account for the need to send data in the 139 downstream direction from sink to nodes. Whereas upstream traffic is needed for collecting data 140 from sensors, downstream messages are necessary to perform network management tasks such as 141 modifying a node's configuration, or sending a command to a node.  Figure 2. The initial sate is called "start", and we have the following states:

145
• w-hlo: In this state, the node waits for "h-wait" time units to collect Hello messages, then it sends 146 a Join message to one of the Hello senders and goes into state "w-acc".

147
• w-acc: In this state, the node waits for an Accept message for "a-wait" time units. If it receives an 148 Accept message it switches to the "data" state, if not, it resends a Join message.

149
• data: In this state, the node sends its own data to its parent and forwards data from its children. If 150 the node's energy drops below a preset threshold (low-E event) it sends a broadcast Leave message 151 and goes into the "send" state. Also, in this state, the node is ready to receive Join messages and 152 send Accept messages.

153
• send: In this sate, the node only sends its own collected data. It does not forward data.

154
• 2-acc: The node goes into this state upon receiving a Leave message from its parent. This state is 155 similar to the "w-acc" state in that the node tries to join a parent to be able to re-enter the "data" (AMR). In AMR, once a Hello message is received from sink, a Join message is sent right away to sink 161 without continuing the "h-wait" time period.

162
The second modification is that we add a new metric that nodes use to choose their parent. This is 163 the Count of Children (CoC) metric. A node that uses this metric will choose as parent the Hello sender 164 that has the least number of children. The objective is to make the number of direct children more or less 165 equal between parent nodes, so that the energy depletion rate is almost constant for all parent nodes.

166
The network lifetime is therefore increased by preventing early "death" (total depletion of energy) that 167 happens to overloaded nodes. Consequently, we modified the fuzzy logic function to include all metrics, 168 namely NoH, RSSI, BEL, and CoC. Table 1 is the original one from the AMR protocol, it has three inputs:

169
Number of hops, residual energy in node, and RSSI. The output is the connection metric. The design of 170 our fuzzy logic function is illustrated in Table 2 where the connection metric is an input along with the 171 number of children. The output of Table 2 is the one we use as the new fuzzy metric. The third modification is that the Leave message is sent from a parent node, as opposed to being sent from a child node in the original protocol. In the MAMR protocol, a parent node broadcasts a Leave message, we note here that a parent does not know the addresses of its children. When a node receives this message and if it is a child to the sender, it will delete its parent's address from the routing table and go to the "2-acc" state. It will also, send a Join message to one of the senders of the Hello messages that it previously collected. It chooses this sender to be its new parent according to the same metric that it used for its previous parent (the one that sent a Leave message), except that it now removes the previous parent from the list of senders. The MAMR protocol gives two options for the decision to send a Leave message. In MAMR-E, a Leave message is sent when the parent's energy drops below a particular level.
In MAMR-T, a Leave message is sent when the parent's time till death t d drops below a particular value. The value of t d is estimated from the rate of decrease of energy: In Equation 1 above, E curr is the current energy level, and ∆t is the time it takes for energy to drop by a 173 value of ∆E.
Ideally, all nodes should be able to join the network and send data. However, some factors affect 247 the operation of the protocol and may cause degradation in performance. Namely, these are: Collisions,

261
In the first simulation scenario, the sink is located at the ankle of one leg, and the other 13 nodes are 262 placed the head (2 nodes), shoulders (2 nodes), arms (2 nodes each), waist (2 nodes), and legs (2 nodes at 263 one leg and one node at the other). In the second scenario, one of the waist nodes become sink and the 264 ankle sink becomes a regular node.

265
• Number of transmissions per delivered packet.

266
• Network lifetime, computed as the time that passes till the first node "death" in the network. Death 267 here means total energy depletion. We assume an initial energy of 2 Joules (J) [12].

268
• Normalized residual energy averaged over all nodes. to MAMR. This is because TAMR does not use special routing packets but uses data packets to 276 deduce routing information.

277
• Residual energy: Figure 5   Submitted to Sensors, pages 9 -11 www.mdpi.com/journal/sensors nodes so that the energy depletion rate is almost even across all nodes. Again, TAMR provides 282 performance that is not significantly different than that of MAMR.

283
• Number of transmissions per delivered packet: Finally, In Figure 6 we show the average number 284 of transmissions per delivered packet for 1000 packets sent per node. Of course, when the sink is at 285 the ankle this number is larger than when the sink at the waist, since in general network end-to-end 286 paths will be longer. Also in MAMR the number is smaller. In fact, this shows a drawback in 287 MAMR, since, due to processing delays, a node may still send a packet or more to its parent even 288 after the parent has sent a Leave message. This type of packets will not be forwarded by the parent.

289
Here also we note that TAMR has comparable performance to MAMR.

291
We presented a routing protocol for WBANs that enables communication in both upstream direction, 292 from nodes to sink, and downstream direction from sink to nodes. Most previous protocols in WBANs 293 focus on the upstream direction since it is the direction of data collected by sensors to be sent to a base 294 station or the cloud. This is the dominant direction in the network. However, we may need to send data 295 in the downstream direction to send configuration parameters or other commands to sensors. To this 296 end, our protocol enables a node in the network's tree to store information about its children, in addition 297 to information about its parent. Simulation results show that the protocol leads to increased network 298 lifetime. We intend to extend the this work by investigating the performance of the protocol over the 299