A Dual-channel Routing Protocol for Wireless Body Area Networks

Wireless Body Area networks (WBANs) are a subset of wireless sensor networks that interconnect miniaturized nodes with sensor or actuator capabilities in, on, or around a human body. WBANs can operate over a number of different frequency bands such as MICS (Medical Implant Communications system), 2.4 GHz ISM (Industrial Scientific and Medical), UWB (Ultra Wideband), HBC (Human Body Communications) bands. Most WBANs utilize only one of these wireless bands for routing, network access, etc. Fading conditions can result in poor network performance in terms of node energy and throughput. With recent interest in multi-band devices for WBANs such as multi-band antennas and transceivers effective utilization of multiple bands requires an equally effective routing protocol. In this paper we develop a multi-channel extension to the Ad Hoc on Demand Distance Vector (AODV) routing protocol for use in multi-channel WBANs that chooses the next hop channel that has the best Received Signal Strength Indicator (RSSI) value. Our extensions to AODV were implemented by modifying the single-band Castalia model built on the OMNeT++ network simulator. We compared our dual channel AODV protocol with RSSI channel selection against a dual channel AODV with random channel selection and single channel AODV. Our simulation experiments showed that in terms of packet delivery dual channel AODV with RSSI performs equally with single channel AODV but with a lower overhead of AODV control packets, better routing stability and slightly better energy per bit efficiency. General Terms


INTRODUCTION
Wireless Body Area (WBAN) technology utilizes wireless communications to interconnect miniaturized devices with sensor or actuator capabilities in the space of a human body [1].These devices, especially designed for the human body, may be placed on the body surface, worn on clothing or implanted, and are able to communicate regular and critical physiological parameters to the rest of their infrastructure.For medical applications, WBANs used for medical monitoring, medical intervention and patient management in the clinic, at-home and out-of-home promise greater patient convenience and mobility and improved outcomes at lower cost.Key requirements for WBAN applications include low power consumption (because the battery capacity in each node is limited), low latency and high reliability of communications.The IEEE 802.15 Task Group 6 (TG6) communication standard [2] was released in 2012 for low power devices and operation on, in, or around the human body including physical layer and medium access control (MAC) components.WBANs are distinguished from other kinds of networks such as wireless sensor networks, ad-hoc networks and wireless mesh networks by their stringent requirements and their particular channel characteristics.A comprehensive review of WBANs is given by [3].
To date, most WBANs have utilized a single wireless band for communication that can be either narrowband wireless (including MICS (Medical Implant Communications system) and ISM (Industrial Scientific and Medical) bands), UWB (Ultra Wideband) wireless or the HBC (Human Body Communications) band.However, there has been an increasing interest in multichannel 1 communication for WBANs to improve robustness, connectivity and performance.Most research to date on multichannel WBANs has been on developing the core enabling technologies such as antennas, radio system architectures and simple protocols for link data transfer.Examples include the following: [4] developed a 433/868 MHz dual-band node with the aim of alleviating the effects of congestion and failure on reliability and QoS.[5] developed a wireless device that used an alternative HBC link if the main RF link (ISM) became unreliable or blocked; [6] developed an on-body repeater for implant (MICS) to external communication (2.4 GHz); [7] developed a dual-band device that used UWB for data transmission and narrowband communications to receive control signals in order to avoid the complexity of a UWB receiver in a small WBAN device.Dualband antenna designs for WBAN applications have been reported by [8] [9] [10] and others.
To obtain the most out of these developments to support WBAN applications over a full WBAN network of devices including a Body Network Controller (BNC) requires the development of routing protocols and MAC protocols that are tailored towards multi-channel operation.In this paper we focus on the development of a multi-channel routing protocol.Most research to date on WBAN routing protocols has been for single band communications.To the authors' knowledge, this paper is one of the first to investigate multi-channel routing protocols for WBANs.
A multi-channel WBAN device may use a single radio or multiple radios.The device may also have a single antenna or multiple antennas.A simple device architecture is to use multiple radios with each radio having its own antenna as it avoids the complexity of switching between radios.This was the approach used in the paper because it was the easiest way to incorporate multiple channels into a simulation model, although in practice there is an additional cost and size involved with multiple radios and antennas.We also used separate MAC modules for each band to avoid the problem of two nodes trying to find a common channel to send and receive data -the rendezvous problem.Our work thus concentrated mostly on the routing protocol.
We developed a multi-channel version of the Ad hoc On-Demand distance Vector (AODV) routing protocol [11] and tested it using the Castalia WBAN simulation model [12] that is built on the OMNet++ simulation platform [13].A key aspect of our protocol is the development of a channel selection algorithm that chooses which channel to use between two nodes.We used the hop count metric to determine the best route.We tested our protocol using simulation over two channels in the ISM 2.4 GHz band (2.400~2.485GHz).Simulation results showed that our multi-channel AODV protocol gave comparable, if not better, performance to single channel AODV in terms of packet delivery but with less AODV control messages needing to be sent, better routing stability and slightly better energy efficiency.
Section 2 describes related work on multi-channel routing.Section 3 describes the WBAN system.Section 4 describes our proposed multi-channel AODV protocol.Section 5 describes the Tunable MAC protocol that we used in our simulations.Section 6 describes the WBAN wireless channel models used.Section 7 presents the result of our simulation experiments along with discussion.Section 8 presents conclusions.

RELATED WORK
Routing protocols can be classified into three categories, proactive, reactive, and hybrid, depending on how the source finds a route to the destination.In proactive protocols, all routes are computed before they are really needed, while in reactive protocols, routes are computed on-demand.Hybrid protocols use a combination of proactive and reactive methods.Comprehensive reviews of WBAN routing protocols have been conducted by [14] and [15], that include temperature based routing, cluster-based routing, cross-layer routing, cost-effective routing and QoS based routing using proactive and reactive approaches.
Multi-channel routing protocols have been used previously in other kinds of networks such as wireless mesh networks and adhoc networks.In [16] they have proposed a multi-channel version of AODV called CA-AODV.In this protocol, if the source did not yet have a channel to transmit on it randomly picked a channel from the set of all available channels.Any node that received a Route Request (RREQ) packet selected a channel that none of its previous k-hop neighbors had selected.The RREQ message conveyed the node ids and channel numbers that its k preceding nodes were using.This method of channel selection may be practical in wireless mesh networks that have many channels available but in WBANS there is usually a small number of channels available so the approach is less practical there.In [17] they have developed a multi-hop routing protocol to operate over an ad-hoc 802.11 network with nodes equipped with multiple 802.11NICs with the aim of improving performance when deployed in a wireless mesh network.They developed a distributed channel allocation algorithm that used only local traffic load information.In [18] a review of multi-channel MAC protocols and proposed a multi-channel MAC protocol called MMAC.They compared parallel rendezvous, dedicated control channel and split phase multi-channel MAC protocols.They noted that switching penalty could be an important factor in multichannel MAC protocols that use frequency hopping.Sometimes routing functions have been combined with MAC channel functions such as in opportunistic routing.Opportunistic routing has been extended to the multi-channel case by [19].

WBAN SYSTEM
IEEE802.15 TG6 have categorized four scenarios for WBAN communication: on-body to on-body, on-body to around-body, inbody to on-body, and in-body to in-body.This paper focuses on the on-body to on-body scenario.A typical placement of WBAN nodes on the human body is shown in Figure 1.We assume the WBAN consists of K dual-channel nodes as shown in Figure 2.Each node has two antennas with each antenna supporting broadcast communication over a separate frequency channel to other nodes.
The structure of a dual-channel node is shown in Fig. 3.It consists of an Application module, a Communication module and a Resource Manager.The Application module is the source and sink of all application data transmitted.For data monitoring applications the Application module sends sensor data (source) to the BNC (Sink).The Communication module supports the transmission of data between nodes and consists of one Routing Module, two MAC modules and two Radio modules.The Routing module implements the dual-channel AODV protocol developed in the paper.
The two MAC modules each contain an instance of a single band MAC protocol module.In this paper, the MAC protocol used is the Tunable MAC implemented in Castalia.Each of the two radios is a single band radio with a separate wireless connection to separate Wireless channel modules.The Radio module not only transmits and receives signals, accepting signals whose signal strength is above the radio receiver sensitivity, but also provides RSSI (Receive Signal Strength Indication) and LQI (Link Quality Indication) information about channels to higher layer modules.
Each Wireless module operates in a different frequency channel and is responsible for broadcasting wireless signals to other nodes.In the Castalia simulator the wireless channel module implements a channel model to determine received signal levels.The Resource Manager module's main function is to keep track of energy usage in a node and control node start-up and shutdown.

MULTI-CHANNEL AODV PROTOCOL
In this paper, we extend AODV to the multi-channel case.We first describe how single-channel AODV operates before describing our extensions to the multi-channel case.AODV is an on-demand (reactive) routing protocol that determines routes for transmission only if a node needs to deliver packets to target nodes, thus reducing excessive consumption of network bandwidth and energy [20].It supports both unicast and multicast packet transmissions even for nodes in constant movement [21].Hence, in the presence of human body movements, AODV responds very quickly to topological changes that may affect active routes.
Suppose an AODV source node (source) has application data to send to an AODV destination node (destination).If the source has an active route to the destination it just begins sending the application data using AODV DATA packets to the next hop node in its routing table.If it does not have an active route to the destination, it initiates a route discovery process by broadcasting a Route Request (RREQ) message for that destination.When that RREQ message is received at an intermediate node, a next hop entry back towards the source is created in the intermediate node's routing table using the immediate source of the RREQ message as the next hop back towards the source.If the receiving node has not received this RREQ message before, is not the destination and does not have a current route to the destination, it rebroadcasts the RREQ message.If the receiving node is the destination or it already has an active route to the destination, it generates a Route Reply (RREP) message that is unicast in a hop-by-hop fashion back to the source using the previously stored next hop information in the node routing table.An intermediate node responding in such a way reduces the number of messages sent in the network.As the RREP propagates back towards the source, each intermediate node creates a next hop entry in the routing table towards the destination using the immediate source of the RREP message as the next hop towards the destination.When the initial source receives the RREP message, it records the next hop to the destination in its routing table, records that there is an active route to the destination, responds to the RREP message with an RREP Acknowledgment (RREPACK) message that is sent to the destination, and it begins sending data to the destination using DATA packets.Each time a node receives an RREP message the node updates its routing table if the RREP message indicates a route with less hop counts to the destination has been found.
As data flows from the source to the destination, each node along the route updates the timers associated with the routes to the source and destination.If a route has not used for some period of time, a node cannot be sure whether the route is still valid.A route expiry timer times-out and the node removes the route from its routing table.If data is flowing and a link break is detected, a Route Error (RERR) message is sent to the source of the data in a hop-by-hop fashion.When the source receives the RERR, it invalidates the route and re initiates' route discovery if necessary.
When RREP messages are received by a node it regularly broadcasts HELLO messages so that its neighbor nodes are aware of the node's continued presence.If a node fails to receive several HELLO messages from a neighbor, a link break is detected.

MULTI-CHANNEL AODV
A number of modifications were made to extend AODV to make it into a multi-channel routing protocol.The first modification was to incorporate channel selection so that when a node has a packet to send to a given destination and needs to send a RREQ message it first selects a channel over which to broadcast the RREQ message.To implement this we record RSSI values for all channels on which the node receives incoming packets.New RSSI values overwrite previous values.Each channel also has a max_time parameter that specifies the maximum amount of time that an RSSI value is maintained for the channel.If all channels (two channels in our case) have valid RSSI values then the channel with the largest RSSI value is selected.If one or more RSSI values is out of date then a channel is selected at random.
The second modification was to include in the routing table entry for a given destination the next hop channel along with the address of the next hop node.When an RREQ message is received the immediate preceding node address and incoming channel are stored as the next hop node address and the next hop channel back to the source in the routing table.Later, when the matching RREP message is received this next hop address and next hop channel are used to forward the RREP back to the source.Also the immediate source address and incoming channel of the RREP message are stored as the next hop address and next hop channel for forwarding packets and messages to the destination.Later, when a route has been established all DATA packets are unicast using the next hop next hop address and next hop channel information stored in the routing table.
AODV retransmits RREQ messages if an RREP message has not been received in a given time.We modified the RREQ retransmission queue such that the selected channel a RREQ was transmitted was stored with message so that the RREQ message could be retransmitted on the same channel as previously.For HELLO message we needed to manage each channel separately and each channel has its own HELLO expiry and refresh timers.

WBAN MAC LAYER PROTOCOLS
We utilised the Castalia provided Tunable-MAC (TMAC) protocol that normally operates over a single band using a single radio.In our dual-channel system we deployed two Tunable MAC modules, one for each frequency channel.TMAC was designed for broadcast communications and does not include acknowledgements and RTS and CTS control packets.It is a contention based protocol utilising the CSMA (Carrier Sense Multiple Access) mechanism for transmissions.The advantages of a contention based MAC protocol are its simplicity, its infrastructure-free ad-hoc feature and good adaptability to traffic fluctuation especially for low load.It is tunable in the sense that persistence and back-off policies can be adjusted.TMAC can be configured to transmit trains of beacon packets to support wakeups and duty cycle management.The two packet types used by TMAC are DATA for data transfer and BEACON for beacon broadcasting.

WBAN WIRELESS CHANNEL MODEL
At channel bandwidths typical of narrowband BAN systems, the radio channel has been shown to be essentially slow and flat fading, with an insignificant amount of inter-symbol interference from multipath effects.On-body narrowband RF signal transmission in an anechoic chamber without any posture change or movement is primarily by creeping waves over the body surface and line-of-sight transmission, if it exists.Posture change causes small scale fading as waves interact with irregular body structures and in homogenous dielectric structures.Outside of the ideal anechoic environment additional multipath signal transmission occurs due to reflection, scattering and diffraction from the surroundings that causes additional small-scale fading.
The IEEE 802.15.6 standard defines a number of different scenarios communication.Channel models for these different scenarios are given in [22] [23] and include: CM1 (implant-toimplant), CM2 (implant-to-surface or external), CM3 (body surface -to body surface or external).Overviews of these models are given in [24].These models are based on probability distributions whose parameter values have been determined by measurements and physical modeling.
The work by [25] and [26] challenges a number of assumptions used in channel modeling.[26].In particular show that posture changes of human bodies can cause temporal correlations and that many of the WBAN probability models are inaccurate.They proposed a more empirically based model and this has been included in Castalia.In this model, the body is divided into regions called cells using similar concepts to the virtual coordinate system developed by [27].There may be more than one node in a cell.Each source-destination cell pair has a given path loss.When a transmission instance from one cell to another occurs the actual signal loss is the sum of the cell-to-cell path loss plus a fading loss whose value is determined by a random look-up from a look-up table whose values have been determined from measurement studies.Castalia also includes a mobility model that supports simple movement of nodes that involves recalculation of node positions and of path losses.

RESULTS
We implemented in Castalia a dual-channel version (using channels 1 and 2) of the multi-channel AODV routing protocol we proposed in Section 4.1.Implementing this in Castalia required significant modifications to the existing C++ and network description (.ned) files in the single channel model to add the extra node modules needed (second MAC and second Radio) and implemented the extra multi-channel AODV routing protocol functions into the Routing module.
We considered a network of 6 nodes (0-5) placed on the body front as shown in Figure 1.The sink (BNC) was the node 0 and nodes 1 to 5 transmitted data to that node only.Node 0 did not send any data to the other nodes.We used the 2.4 GHz IEEE 802.15.4/Zigbee-readyCC2420 RF transceiver provided Castalia.The key simulation parameters used are shown in Table 1.The radio parameters has been derived from the Teleos Mote Datasheet [28].We have set the radio to IDEAL modulation in Castalia and used the additive interference collision model.To determine the effect of multi-channel AODV by itself we disabled the mobility module in Castalia and compared the performance between the single channel AODV (SCH) over channel 1, dual channel AODV using RSSI channel selection (DCH RSSI) and dual channel AODV with random channel selection (DCH Rand).
The simulation duration was set to 1400 seconds.Figure 4 shows, for each node, the numbers of packets sent by the application module in a node to the application module in node 0 and the number of packets received by node 0. The labels on the x axis identify the source node of packets.The top plot in the figure is for SCH, the middle plot is for DCH Rand and the bottom plot is for DCH RSSI.Since the simulation was configured for constant packet rate in the application layer all simulations sent around the same number of packets (140,096).The figure shows that SCH and DCH RSSI achieved almost the same packet delivery levels (SCH: total received = 137,687 packets, mean per node= 22,948 packets; DCH RSSI: total received = 138,987 packets, mean per node= 23,165 packets) whereas DCH Rand delivered less packets (total received = 123,192 packets, mean per node= 20,532 packets).If anything, DCH RSSI is slightly better than SCH.
Figures 5 and 6 show the number of AODV DATA packets sent on channels 1 and channel 2, respectively.In a groups of bars above a source node each bar is for a different destination nodes (0-5, left-to-right) (Figure 7 illustrates this the best).To understand how the dynamics of the different forms of AODV affected performance we conducted detailed analyses for each node of the number of AODV messages and packets sent and received.For SCH all DATA packets were sent on channel 1.Most DATA packets were sent from source to node 0 in one hop but there was a small amount of forwarding by other nodes as seen in the received packet counts (right-hand graph).
For both DCH Rand and DCH RSSI some packets were sent on channel 1 and some on channel 2, depending on which channel was selected (Note that both radios in a node can simultaneously send and receive packets with higher layer module operation decoupled by buffers.)For DCH Rand nearly all packets were sent in one hop to node 0. The same was true for DCH RSSI except packets from node 5 were sent to node 0 via node 3, the first hop using channel 2 and the second hop using channel 1.
We then examined how many AODV control messages (RREQ, RREP, RERR, RREPACK (denoted by RACK in the figure) and HELLO) were sent and received by nodes with message counts shown in Tables 2 and 3, respectively, for the 1400 second simulation.RERR message counts are not shown as none were detected.As a reference point the total number of application packets sent in each simulation was around 138,987.The sent message counts are the number of messages sent by a node to all other nodes and the received message counts are the number of messages received by a node from all other nodes.The graphs of MAC DATA packets sent and received per node on each channel is shown in Figures 7 and 8.For SCH there were significant numbers of packets sent between a node and all the other nodes as a result of the high number of AODV control messages being broadcast and then responded to.However, the dominant number of MAC DATA packets sent from a node were to node 0, carrying AODV DATA packets.The MAC DATA packets sent in DCH Rand were nearly all carrying AODV data packets and the transmission pattern was consistent with the AODV packet transmission numbers in Figures 5 and 6.DCH RSSI was similar, except that the number of MAC DATA packets sent from node 3 to node 0 was about double that of the other nodes as it was sending its own AODV DATA packets and forwarding the AODV DATA packets of node 5 as well.
There are several parameters that need to be configured in TMAC and additional studies and analyses showed that the interaction between TMAC parameters and AODV parameters and timer time-outs could be quite complex.For example, increasing the number of allowed RREQ retries also increases the RREQ expiry time-out value.Increasing the number of RREQ retries also leads to more contention in the MAC layer.On the other hand more contention in the MAC layer leads to more failures to deliver RREQ packets and consequent time-outs.The optimum configuration of parameters in dual channel operation is an open issue.In terms of energy usage we found only small differences between actual energy usages in the different simulations (Table 4).However, DCH RSSI gave the best energy efficiency (nJoules per bit) of the three cases.

CONCLUSION
In this paper we developed a multi-channel AODV routing protocol that was implemented in the OMNet++ based Castalia WBAN simulation model.We showed that DCH RSSI gave equal performance to SCH in terms of packet delivery but with less AODV control overhead, better routing stability and slightly better energy efficiency.In future work, we will examine how node mobility affects operation and the use of energy and other metrics such as ETX (Expected Number of Transmissions) and WCETT (Weighted Cumulative Expected Transmission Time) that require additional changes to the Castalia Radio module.We also plan to investigate the use of dual-channel Radio and/or dualchannel MAC modules.

Figure 4 :
Figure 4: Numbers of application packets sent to node 0 (left bar) and received by node 0 (right bar) for each node for SCH, DCH Rand and DCH AODV.

Figure 8 :
Figure 8: Sent and received MAC DATA packets on Channel 2

Table 2 :
Count of AODV control messages sent from a node to all other nodes for SCH, DCH Rand and DCH RSSI AODV.

Table 3 :
Count of AODV control messages received by a node all other nodes for SCH, DCH Rand and DCH RSSI AODV.

Table 4 :
Comparison of total consumed energy (Joules)