- Access to this full-text is provided by Hindawi.
- Learn more
Download available
Content available from Mobile Information Systems
This content is subject to copyright. Terms and conditions apply.
Research Article
QPRD: QoS-Aware Peering Routing Protocol for Delay-Sensitive
Data in Hospital Body Area Network
Zahoor A. Khan,1Shyamala Sivakumar,2William Phillips,3
Bill Robertson,3and Nadeem Javaid4
1CIS, Higher Colleges of Technology, Fujairah Campus, P.O. Box 4114, Fujairah, UAE
2Saint Mary’s University, Halifax, NS, Canada B3H 3C3
3InternetworkingProgram,FE,DalhousieUniversity,Halifax,NS,CanadaB3H4R2
4COMSATS Institute of Information Technology, Islamabad 44000, Pakistan
Correspondence should be addressed to Zahoor A. Khan; zahoor.khan@dal.ca
Received November ; Accepted January
Academic Editor: Haroon Malik
Copyright © Zahoor A. Khan et al. is is an open access article distributed under the Creative Commons Attribution License,
which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.
Consistent performance, energy eciency, and reliable transfer of data are critical factors for real-time monitoring of a patient’s
data, especially in a hospital environment. In this paper, a routing protocol is proposed by considering the QoS requirements of the
Body Area Network (BAN) data packets. A mechanism for handling delay-sensitive packets is provided by this protocol. Moreover,
linear programming based modeling along with graphical analysis is also done. Extensive simulations using the OMNeT++ based
simulator Castalia . illustrate that the proposed algorithm provides better performance than other QoS-aware routing protocols
in terms of higher successful transmission rates (throughputs), lower overall network trac, no packets dropped due to MAC
buer overow, and fewer numbers of packet time outs in both the mobile and static patient scenarios. e scalability of the
protocol is demonstrated by simulating a -bed real hospital environment with nodes. It is shown that, even in the larger real
hospital scenario requiring the transmission of delay-sensitive data packets with stringent delay requirements, QPRD outperforms
comparable protocols.
1. Introduction
A patient’s real-time health-related data monitoring is pos-
sible with the help of a new emerging eld, Body Area
Networks (BANs). Body Area Network is a small wireless
network which consists of sensors placed inside or outside
of the human body. e body implant or wearable sensors
transmit the data to a central device called Body Area
Network Coordinator (BANC). BANC is computationally
more powerful device then the body sensors. BANC is
responsible for transferring the sensors’ data to the next node
or destination reliably.
Some important issues of BAN data transmission are to
ensure the high reliability, low latency, compatibility with
movable sensors, and low energy consumption. e specic
need of BAN communication is not fullled by the existing
Personal Area Network (PAN) standards []. IEEE task group
was assigned a job in November to suggest a BAN
communication standard .. by the consideration of
short range transmission, reliability and latency requirements
of QoS, and less energy consumption []. e real-time
monitoring of patients requires the transmission of delay-
sensitive data such as video imaging, motion sensing, and
Electromyography (EMG) using BAN. Some projects like
SMART [], CareNet [], AID-N [], and ALARM-NET []
provide dierent methods to monitor the patient data. In
these methods, the transmission of BAN data from body
sensors to the central database is considered and then BAN
data is downloaded and monitored from the central database.
However, these techniques do not monitor or display in
real-time BAN data in hospital environment. e advantages
of using a centralized system are to have better control
and maintain the data privacy of the patient. However,
trac congestion, server failure, or link failure can cause
considerable delays in monitoring the patient data which
can badly aect treatment. On the other hand, distributed
Hindawi Publishing Corporation
Mobile Information Systems
Volume 2015, Article ID 153232, 16 pages
http://dx.doi.org/10.1155/2015/153232
Mobile Information Systems
data approaches help to reduce the trac load and can
better accommodate patient mobility. e ZK-BAN peering
framework proposed in [] suggests a semicentralized system
for reliably monitoring BAN data. e hybrid ZK-BAN uses
bothcentralizedanddistributedtechniques.
e routing protocols EPR, proposed and discussed in
[], resolves the problem of handling ordinary data pack-
ets. e QoS-aware peering routing protocol for reliability-
sensitive data (QPRR) [,]providesamechanismofhan-
dling the reliability-sensitive packets in addition to the ordi-
nary data packets. e requirement of real-time display for
delay-sensitive packets is dierent from those of ordinary and
reliability-sensitive packets. Hence, a new QoS-aware routing
protocol is required to handle delay-sensitive packets. A novel
routing protocol that addresses the issue of handling delay-
sensitive data and displaying in real-time delay-sensitive BAN
data is proposed in this paper. e proposed QoS-aware
peering routing protocol for delay-sensitive packets (QPRD)
isdesignedfortheZK-BANpeeringframeworkdiscussedin
[]. QPRD provides an innovative approach to the reliable
transmission of ordinary packets (OPs) and delay-sensitive
packets (DSPs). e initial results and architecture of QPRD
were presented in IEEE conference proceedings [].
is paper is organized as follows: Section provides the
related work; Section discusses the problem formulation
and modeling; Section provides the proposed QoS-aware
peering routing protocol for delay-sensitive data (QPRD);
Section describes the performance evaluation; Section
discusses the scalability test of QPRD and Section presents
the conclusions.
2. Related Work
A smart monitoring system of BAN data in hospital environ-
ment can resolve the challenges related to the management
of patients’ medical information []. e Scalable Medical
Alert and Response Technology (SMART) [] is designed to
monitor the patient’s data in hospital emergency area. e
datafromsensorsistransferredtothePDAandthenthePDA
sends it to the next tier by using wireless standard .b.
CareNet [] provides an integrated wireless sensor based
solution to monitor the patient’s data from remote hospitals.
e two-tier wireless communication is used in the projects
[,]. A GPS system is used in [] to monitor the patient’s
data only in outdoor BAN communication. A wireless sensor
network for assisted-living and residential monitoring system
with a query based protocol is provided in ALARM-NET
[]. A three-tier communication approach is used in []to
store the BAN data on the server and then make this data
available for the physician to analyze the patient’s data. e
projects [–,] used a centralized approach to monitor
the patient’s data. However, the real-time display of data by
considering the delay requirements of delay-sensitive packets
is not considered. To access the data from a centralized server
may cause delay and even a simple link failure can completely
disconnect the healthcare system from the central server.
In [], an energy-aware peering routing protocol (EPR)
was presented which considers the energy level and geo-
graphic information of the neighbor nodes for choosing the
best next hop. e EPR only considers ordinary packets. It
was shown that EPR has an overall lower energy consumption
than comparable protocols [,–] and provides better
results in terms of reduced overall network trac, reduced
number of packets forwarded by intermediate nodes, and
higher successful data transmission rates. However, EPR does
not provide a mechanism for dealing with delay-sensitive
packets (DSPs). In this paper, delay-sensitive packets are
considered by the proposed QoS-aware peering routing pro-
tocol for delay-sensitive data (QPRD) and their performance
is investigated by comparing it to the existing DMQoS
protocol []. In [], DMQoS categorizes the data packets
into four types: ordinary packets (OPs), critical packets (CPs),
reliability-driven packets (RPs), and delay-driven packets
(DPs). e DMQoS [] provides better results for delay-
driven packets than several previously investigated methods
[,–] in terms of end-to-end path delay. However,
DMQoS employs a hop-by-hop approach to determine the
next hop. DMQoS considers the neighbor device with the
lowest delay, and the next hop then determines the best
next upstream hop with least delay. e disadvantage of this
hop-by-hop delay-driven approach employed in DMQoS is
that only neighboring nodes delay information is considered
bysourcenode.esourcenodeforwardsthepackettoa
particular neighbor node which has lower node delay than
therequireddelay.eneighbornodesendstheacknowl-
edgement of the successfully received packet to the source
node. Now, the packet receiving neighbor node determines
its best upstream node in terms of delay requirement and
forwards the packet to the upstream node if the node delay
of upstream node is less than the required delay. In case the
neighbor node does not nd any upstream node with node
delay less than required delay, then the packet is dropped. In
this case, the packet does not reach the destination, but the
source node assumes that the packet has been successfully
received by the destination. Furthermore, the hop-by-hop
approach used in DMQoS causes an increase in overall
network trac, and the required end-to-end latency may not
be guaranteed. In this paper, the proposed QPRD addresses
these shortcomings by selecting and choosing the next hop
device based on the lowest end-to-end path delay from the
source node to the destination.
3. Problem Formulation and Modeling
e motivation that BAN consists of nodes connected with
each other via wireless links leads us to model it as a directed
graph. is section focuses on two points: (i) to maximize
throughput, and (ii) to minimize the end-to-end delay. ese
two problems are modeled via linear programming [,]
because requirements to these problems could easily be
represented by linear relationships.
3.1. roughput Maximization. We consider BAN as a
directed graph = (,),|| = ,and|| = ;is the set
of nodes and is the set of directed graphs (links). If the
network operations are divided into rounds, each round is
the duration from the network establishment till the death
Mobile Information Systems
ofallnodes;thenlinearprogrammingbasedmathematical
formulation for throughput maximization is as follows:
Max
𝑟(),∀∈, ()
where
()=
𝑖(𝑖,Dst)⋅
(𝑖,Dst)∀ ∈ , ()
(𝑖,Dst)=
1if packet delivery is guaranteed
0otherwise ()
such that
≤
max,(a)
𝑖𝑖≤
0,∀∈, (b)
𝑖
DLpath(𝑖,Dst)≤
𝑖out(𝑖,Dst),∀∈, (c)
𝑖(𝑖,Dst)≤
𝑖𝑡𝑥
𝑖,∀∈, (d)
𝑖(𝑖−1,𝑖) +
𝑖𝑖≤
𝑖(𝑖,Dst),∀∈. (e)
e objective function in () aims to maximize throughput
during each round such that () associates packet delivery
from source to destination Dst with link ag .Equation()
provides details about the status of being raised (=1)
if packet delivery through that link is guaranteed else not
(=0). Constraint in (a) provides the upper bound for
the allocated bandwidth as max. Similarly, constraint in
(b) deals with limited energy constraint; that is, each node
is equipped with an energy source 𝑖such that ∑𝑖𝑖is
upper bounded by 0. Node ceases transmission whenever its
battery is drained out, so, energy ecient utilization is very
important (routing and MAC layer protocols play a critical
role here). Constraint in (c) comes into consideration if
and only if ∃(/) ∈ QoS;path(s) out of total
satises the given quality of service QoS where DLpath is
the end-to-end delay and out is the timeout period. is
means that, as a rst priority, QoS needs to be satised.
Aerwards, if there is more than one QoS path, then as a
second priority end-to-end delay is checked. Transmission
range 𝑡𝑥 constraint in (d) demonstrates that packet delivery
is successful if a source node transmits data to an in-range
destination node where (𝑖,Dst)is the distance between source
and destination. For data generation rate ,(e) constraint
entails ow conservation such that the incoming data ow
(𝑖−1,𝑖) plus the data generated during time should not exceed
the outgoing data ow (𝑖,Dst). Violation of (c),(d),and(e)
leads to packets being dropped which ultimately results in
decreased throughput.
3.2. Delay Minimization. e delay minimization problem,
while routing dynamically such that path for each request
is selected to prevent routing latency for future demands, is
addressed here. e linear programming problem is formu-
lated as follows:
Min
𝑖
DLpath(𝑖,Dst),∀∈, ()
where
DLpath(𝑖,Dst)=
DLnode(𝑖) +DLpath(𝑗,Dst) = Dst
DLnode(𝑖) =Dst, ()
DLnode(𝑖) =DLtrans(𝑖) +DLqueue+channel +DLproc ,
∀ ∈ ()
such that
path(𝑖,Dst)=1,∀∈, (a)
bit ≤
max
bit ,(b)
𝑡max
𝑡=1
≤
cap,(c)
𝑖arrival
𝑖<
𝑖departure
𝑖,∀∈, (d)
0≤
𝑖
node ()≤, ∀∈, (e)
𝑒
bit ≤
proc
bit .(f)
e objective function in () aims to minimize the end-to-
end path delay DLpath(𝑖,Dst),where() depicts the two possible
cases: communication via intermediate node and without
intermediate node, and () denes the node delay DLnode(𝑖)
calculated at the network layer as the addition of packet delays
due to transmission DLtrans(𝑖), queuing DLqueue ,channel
capturing DLchannel,andprocessingDL
proc. Constraint (a)
clearly says that the link through which data is routed must
be established where path is the link ag. Constraint in (b)
provides the upper bound of data rate bit as max
bit such
that bit is inversely proportional to DLtrans according to ()
explained in later Section .. Constraint in (c) says that the
number of transmitted packets in 4 seconds (max =4sec)
should not exceed the packet handling capacity cap because,
at negligible load, there is constant small delay. However,
queuingdelaysoneachnodeareaddedassoonasthenetwork
load increases and when exceeds cap delays increase
without bound. Similarly, constraint in (d) deals with queue
stability meaning that the packet arrival rate arrival
𝑖should be
always less than the packet departure rate departure
𝑖.Violation
of (d) results in nonavailability of buer space leading to
queue instability which in turn leads to congestion and thus
causing increased delay. Constraint in (e) states that the total
number of nodes ∑𝑖node() in the given network is limited
such that has an inverse relation with DLchannel.Inother
words, increasing the number of nodes means that there are
more chances that one of the noncapturing nodes might have
Mobile Information Systems
a lower backo time as compared to that of the capturing
node, thereby increasing the idle time due the backing o of
noncapturing nodes. Constraint in (f) deals with DLproc.It
is obvious that the total bit level errors 𝑒
bit should not exceed
a certain threshold proc
bit ; otherwise increased erroneous bits
wouldincreaseDL
proc and performance of the network wou ld
degrade in terms of processing delays at the nodes.
3.3. Graphical Analysis. Consider the simplied path
B3-B1-NSC where B3candirectlysenddatatoNSCaswellas
via B1(refer to Figure in Section .). Moreover, NSC can
also send data to itself. For typically assumed delay values,
path delay is maximum when B1is involved in forwarding
the data of B3intended for the destination NSC (i.e., 50 ms),
and path delay is minimum when B3directly communicates
with NSC (i.e., 20 ms). Let =DLpath(𝑖,Dst),=DLnode(𝑖),
and =DLpath(𝑗,Dst). e objective function in () can be
reformulated as
Min (),()
where
=+ ()
such that
+≥20,(a)
+≤50,(b)
0≤≤20,
0≤≤30.(c)
e objective function in () aims to minimize end-to-end
delay regarding the selected path, whereas () illustrates
nature of the objective function, that is, two-dimensional
linear programming problem. Constraints in (a) and (b)
provide lower and upper bounds for the selected path,
respectively, whereas constraint in (c) deals with similar
bounds for as well as . For simplicity in calculation,
we replace the inequalities in (a),(b),and(c) with
equalities, respectively. In subject to the given constraints,
Figure shows the set of feasible solutions which is obtained
by the intersection of lines, 1,2,3,and4,andisindicated
by coloured region such that each point in the feasible region
satises each constraint. We can nd the minimum value of
by testing it at each of the vertices (refer to 1, 2, 3, and
4inFigure ) as follows:
at 1(0,0):=0ms,
at 2(20,0):=20 +0=20 ms,
at 3(0,30):=0+30 =30 ms,
at 4(20,30):=20 +30 =50 ms.
e minimum value of is 0 ms at =0and
=0. However, this value indicates self transmission
or communication within NSC. e next minimum value
is =20 ms showing the case of direct communication
0 10 20 30 40 50 60 70 80
0
10
20
30
40
50
60
70
80
x (ms)
y (ms)
L1:x+y=50
P4(20, 30)
P3(0, 30)
L4:x=0
L5:y=0
P1(0, 0) P2(20, 0)
L2:x=20
L3:y=30
F : Feasible region.
between B3and NSC. Similarly, =30 ms when B1directly
communicates with NSC. On the other hand, end-to-end
path delay is maximum when B3communicates with NSC via
an intermediate B1;=50 ms.
4. QoS-Aware Peering Routing Protocol for
Delay-Sensitive Data (QPRD)
Based on the mathematical analysis in Section ,thepro-
posed QoS-aware routing protocol used in an indoor hospital
ZK-BAN peering framework [] is discussed in this section.
e proposed QPRD provides a mechanism to (1) calculate
the node delays and path delays of all possible paths from
thesourcenodetothedestination,(2) determine the best
path, and (3) choose the best next hop NH𝐷based on the
delay requirements of the packet. For each destination, the
routing table contains information about the next hop device
connected to the path with the least end-to-end latency. For
any DSP, if the path delay (DLpath(𝑖,Dst))islessthanorequal
tothedelayrequirement,thesourcenodesendstheDSP
through that path.
e architecture of proposed QPRD, based on the mathe-
matical formulation of the end-to-end path delay problem,
is shown in Figure . It consists of seven modules: MAC
receiver, delay module (DM), packet classier (PC), Hello
protocol module (HPM), routing services module (RSM),
QoS-aware queuing module (QQM), and MAC transmitter.
e modules are discussed below.
4.1. MAC Receiver. e MAC receiver receives the data or
Hello packets from other nodes (BAN, MDC, or NSC). It
checks the MAC address of the packet. It only forwards the
broadcast packets or the packets which have the same node’s
MAC address as destination address to the network layer.
4.2. Delay Module (DM). e delay module monitors the
time required to capture the channel (DLchannel(𝑖)), MAC
layer queuing delay (DLMAC queue(𝑖)), and transmission time
Mobile Information Systems
MAC receiver MAC transmitter
Hello protocol
Packet classier
QoS-aware queuing
Layer 3
Layer 2
Higher priority
To other nodes (i.e. BAN, MDC, or NSC)
Routing services
Path selector
QoS
classier
Routing
table
Neighbor table
Delay module
DSP
Data packets
Hello packet
Data or Hello packets
From other nodes (i.e. BAN, MDC, or NSC)
Hello packets DSPOP
Routing table constructor
Delay algorithm
Energy-aware algorithm
OP
Neighbor table constructor
Delay calculation
From upper layers
Data packets
Data or Hello packets
Data or Hello packets
F : QPRD protocol architecture.
(DLtrans(𝑖)) of a packet. e delay module sends this infor-
mation to the network layer. e network layer uses this
information to calculate the node delay (DLnode(𝑖)).
4.3. Packet Classier (PC). e packet classier (PC) receives
all the packets from the MAC receiver. e data packets and
Hello packets are dierentiated by the PC. e PC forwards
the data and Hello packets to the routing services module and
Hello protocol module, respectively.
4.4. Hello Protocol Module (HPM). e neighbor table con-
structorandtheneighbortablearethetwosubmodulesof
Hello protocol module. e information received from the
delaymoduleoftheMAClayerandtheHellopacketsisused
bytheneighbortableconstructortoconstructtheneighbor
table. Initially, Hello packets are broadcasted by each of type
(NSC) and type (MDC) devices. e node receives
the Hello packet. e neighbor table constructor of node
calculates its own DLpath(𝑖,Dst)based on the information in the
Hello packets. e Hello packet is updated and forwarded by
node to the other nodes. e Hello packet elds of node
are shown as follows.
Hello Packet Structure. Consider
IDDst Dst ID𝑗𝑗(𝑗,Dst)𝑗𝑗DLpath(𝑗,Dst)()
e commonly used notations in this paper and their descrip-
tions are summarized in notations section.
e neighbor table contains elds for both hop-by-hop
delay (DLnode(𝑖)) and end-to-end path delay (DLpath(𝑖,Dst)).
e neighbor table constructor updates the neighbor table
periodically aer receiving every new Hello packet. e
neighbor table structure of node is shown as follows.
e Neighbor Table Structure. Consider
IDDst Dst ID𝑗𝑗(𝑗,Dst)(𝑖,𝑗) 𝑗𝑗DLnode(𝑖) DLpath(𝑖,Dst)()
Mobile Information Systems
e node delay (DLnode(𝑖)) can be found by adding the packet
delays due to transmission, queuing, processing, and channel
capturing:
DLnode(𝑖) =DLtrans(𝑖) +DLqueues+channel +DLproc.()
e node updates its Hello packets periodically; seconds are
used in QPRD for simulation purposes. e time interval
seconds is used because the delay module sends the delays of
MAC queue and channel capture aer every seconds. e
average transmission delay (DLtrans) before sending the Hello
packets is calculated by using
DLtrans =1
bit
∑𝑛
𝑧=1bit(𝑧)
,()
where bit is the data rate and as per BAN requirement
kbpsisusedinthesimulations.bit is the total number
of bits in each packet. is the number of packets transmitted
in seconds.
e delay due to the MAC and network layers’ queues
andcapturingthechannelcanbecalculatedbyusingthe
Exponentially Weighted Moving Average (EWMA) formula
and is given in
DLqueues+channel =1−∗DLqueues+channel +
∗DLqueues+channel,()
where queues are both network and MAC layers’ queues.
Initial values of DLqueues+channel are the delay of the rst
packet sent by the node. is the average weighting factor
that satises 0 <≤1. e selection of value is
heuristic and was chosen based on simulations experience.
e recommended values are 0.2≤≤0.3. e best suited
value of found for QPRD simulations is ..
e path delay between node and destination node Dst
(DLpath(𝑖,Dst))iscalculatedbyusing
DLpath(𝑖,Dst)=DLnode(𝑖) +DLpath(𝑗,Dst),()
where initial value of DLpath(𝑗,Dst)is zero when =Dst.
An example of nding the path delay from node
(B3) to Dst (NSC) is shown in Figure .edelaycal-
culation of two paths B3-B1-MDC2-NSC (path ) and
B3-MDC3-B2-MDC1-NSC (path ) is given for illustrative
purposes.etypicalassumedvaluesarechosenforillus-
tratedpurposes.eindividualnodedelaysusedinthis
example are given below:
DLnode(NSC)=20 ms,(a)
DLnode(MDC2)=40 ms,(b)
DLnode(B1)=30 ms,(c)
DLnode(B3)=20 ms,(d)
DLnode(MDC1)=20 ms,(e)
DLnode(B2)=30 ms,(f)
DLnode(MDC3)=10 ms.(g)
e path delay of destination (DLpath(Dst,Dst))isapproximately
zero, because the time required to receive the packet from
MAC to network layer is negligible. So, in this example initial
path delay is given below:
DLpath(NSC,NSC)=0ms.()
Each node calculates the path delay from itself to the
NSC. First, the calculations of the path delay for path
(B3-B1-MDC2-NSC) are considered.
e path delay of MDC2(DLpath(MDC2,NSC))iscalculated
by using ():
DLpath(MDC2,NSC)=DLnode(MDC)+DLpath(NSC,NSC).()
Using t he values f rom (a) and () in the above equation,
we get
DLpath(MDC2,NSC)=40 +0=40 ms.()
e path delay of BAN B1is calculated below:
DLpath(B1,NSC)=DLnode(B1)+DLpath(MDC2,NSC),
DLpath(B1,NSC)=30 +40 =70 ms.()
e node B3determines the path delay by using the values
from (d) and ():
DLpath(B3,NSC)=DLnode(B3)+DLpath(B1,NSC),
DLpath(B3,NSC)=20 +70 =90 ms.()
In the same manner, the path delay of path
(B3-MDC3-B2-MDC1-NSC) can be calculated as follows:
DLpath(MDC1,NSC)=20 +0=20 ms,
DLpath(B2,NSC)=30 +20 =50 ms,
DLpath(MDC3,NSC)=10 +50 =60 ms,
DLpath(B3,NSC)=20 +60 =80 ms.
()
Equations () and () show that the path delays of path
and path are ms and ms, respectively. It is quite
possible that the path with less delay is longer (has more
hops) than the other paths. As it is observed from the above
example, path includes ve devices and path has four
devices. However, the path delay of path is lower than the
path delay of path .
4.5. Routing Services Module (RSM). e routing services
module is responsible for constructing the routing table,
categorizing the data packets into delay-sensitive packets
(DSPs) and ordinary packets (OPs). It also chooses the best
path(s) for each category (DSPs or OPs) of trac. QoS
classier, routing table constructor, path selector, and routing
table are the submodules of routing services module. e
routing table structure for node is shown as follows.
e Routing Table Structure for QPRD. Consider
IDDst Dst NH𝐸NH𝐷DLpath(𝑖,Dst)()
Mobile Information Systems
DLpath(B3,NSC)=DLnode(B3)+DLpath(B1,NSC)
=20ms +70ms =90ms
DLpath(B1,NSC)=DLnode(B1)+DLpath(MDC2,NSC)
=30ms +40ms =70ms
DLpath(MDC2,NSC)=DLnode(MDC2)+DLpath(NSC,NSC)
=40ms +0ms =40ms
Path1
MDC2
DLpath(B3,NSC)=DLnode(B3)+DLpath(MDC3,NSC)
=20ms +60ms =80ms
DLpath(B3,NSC)=DLnode(MDC3)+DLpath(B2,NSC)
=10ms +50ms =60ms
DLpath(B2,NSC)=DLnode(B2)+DLpath(MDC1,NSC)
=30ms +20ms =50ms
DLpath(MDC1,NSC)=DLnode(MDC1)+DLpath(NSC,NSC)
=20ms +0ms =20ms
B1
B3
MDC1
MDC3
DLpath(NSC,NSC)=0
DLnode(NSC)=20ms
NSC
Path2
B2
F : Example of nding the path delay.
e notations and their descriptions are listed in notation
section. Two next hop entries NH𝐸and NH𝐷are given
for each destination Dst in routing table. e routing table
constructor contains the energy-aware and delay algorithms.
e energy-aware algorithm discussed in []isusedtond
next hop NH𝐸for OPs. Residual energy and geographic
location of the neighbor nodes are considered for choosing
NH𝐸. For DSPs, the new proposed algorithm nds the
best possible path to ensure the minimum required path
delay. e routing table is constructed by using the neighbor
table entries. Neighbor table contains multiple records for
each destination. For example, Figure shows that there
are many paths from B3to NSC. Some of these paths are
B3-B1-MDC2-NSC, B3-MDC3-B2-MDC1-NSC, and so forth.
For each destination, the routing table constructor stores the
next hop (NH𝐷) which has the lowest latency.
Algorithm shows that node identies the next hop can-
didatesbysearchingtherecordswhichhavethesameID
Dst
intheneighbortable.epathdelayhasbeencalculatedby
using the neighbor table constructor and stored in neighbor
table for each next hop candidate, using ().enodestores
the neighbor nodes’ IDs in the variable NH (line ). If NH has
onlyoneentry,thismeansthereisonlyonepathavailable.e
node stores this entry to NH𝐷(line ).
Otherwise, the node sorts the NH entries in ascending
order of delay and then stores the rst entry which has the
lowest path delay in NH𝐷(lines -). e next hop candidate
NH𝐷is then stored with its path delay value (DLpath(𝑖,Dst))in
the routing table. e data packets from both upper layers
andpacketclassierarereceivedbyQoSclassier.eQoS
classier classies the packets into DSP and OP data. For
each data packet, the path selector (PS) checks the QoS
requirement and chooses the most appropriate next hop(s)
by using Algorithm .
e path selector compares the delay requirement (DLreq)
with the path delay (DLpath(𝑖,Dst))ofNH
𝐷which is stored in
the routing table. If the path delay (DLpath(𝑖,Dst))islowerthan
required delay (DLreq), the packet is sent to NH𝐷(lines -).
Otherwise, the packet is dropped (line ).
For ordinary packets, the PS returns the next hop NH𝐸
which is discussed by the EPR (lines -); else the packet is
dropped.
4.6. QoS-Aware Queuing Module (QQM). e routing ser-
vicesmodulepassesthedatapacketstotheQoS-aware
queuing module (QQM) aer choosing the appropriate next
hop(s). e QQM receives the data packets and separates
these packets in two classes (DSP and OP). An individual
queue is used for each class of packets. QQM functions are
thesameasdiscussedin[]. e priority of the DSP queue
is higher than that of the OP queue. By default, the DSP queue
with higher priority sends the packets rst. e packets from
lower priority OP queue will be sent only when the DSP queue
is empty. However, for fair treatment of OP data, a timeout
is used by all the queues. A queue sends the packets to the
MAC layer within the period specied by the timeout for that
queue. QQM changes the control from higher priority queue
to lower priority queue aer the queue timeout occurs or
when the higher priority queue is empty whichever is earlier.
4.7. MAC Transmitter. e MAC transmitter receives the data
and Hello packets from the network layer and stores it in
Mobile Information Systems
INPUT: Neighbor table, ’s neighbor table records NH(𝑖,Dst),∀Dst ∈{MDC, NSC, BAN}
() for each destination Dst ∈{NSC, MDC, BAN}do
() NH = {All neighbor nodes∈NH(𝑖,Dst)}
() if (|NH|==1)then
() NH𝐷←NH
() else if (|NH|>1)then
() Sort NH in ascending order of DLpath(𝑖,Dst)
() NH𝐷=rstneighbornode∈NH;
() end if
() end for
A : Routing table construction algorithm for delay-sensitive packets.
INPUT: Routing table, ’s routing table records NH(𝑖,Dst),∀Dst ∈{MDC, NSC, BAN}
() for each data packet do
() if data packet is delay-sensitive packet (DSP)
() if (DLpath(𝑖,Dst) ≤DLreq)then
() send to NH𝐷
() else
() Drop the packet immediately
() end if
() else if data packet is Ordinary Packet (OP)
() send to NH𝐸
() else
() drop the packet immediately
() end if
() end for
A : Path selector algorithm for delay-sensitive packets.
the queue. e queue works in a First-In-First-Out (FIFO)
fashion. It transmits the packets aer capturing the channel
by using CSMA/CA algorithm.
5. Performance Evaluation
Simulations are performed on OMNeT++ based simulator
Castalia . []. In this section, the proposed QPRD algo-
rithm is compared with the DMQoS [] and noRouting
protocols. In noRouting, the delay-sensitive data packets are
forwarded to random next hop devices instead of algorithm’s
next hop based on end-to-end path delay routes. e network
parameters used in simulations are shown in Table .
ree scenarios are considered for simulation. All the
nodes used in scenario are static, whereas the source node
4is moving in scenario . Scenario is used for the
scalability test of the protocol. e transmit power used in
the simulations is − dBm. e performance of the QPRD is
measured by calculating the throughput, number of packets
forwarded by the intermediate nodes, overall network trac,
packets timeout due to not fullling the required delay
condition,andpacketsdroppedduetothebueroverow.
e better results provided by QPRD are in accordance with
the equations used in Section .ehigherthroughputisdue
totheuseofobjectivefunctioninQPRD,asdescribedin(),
and the least violations of (c),(d),and(e). e simulation
MDC1B1
NSC and MDC4MDC3B3B4
B2
MDC2
(5, 5)
(9, 3)
(3, 3)
(0, 3)
(5, 1)
(6, 3)
(2, 1)
(2, 5)
F : Node deployment for scenario .
results show that the end-to-end path delay mechanism, as
discussed in Sections . and .,usedinQPRDhelpsto
reduce the packets forwarded by intermediate nodes and the
packetsdroppedduetothebueroverow,whichresults
in higher throughput and lower overall network trac. To
achieve a % condence interval for the illustrative results,
the average of three runs is simulated in every experiment
which may introduce a maximum error of 3×10−3,basedon
the error calculation done by Castalia . simulator []. e
results obtained for rst two scenarios are discussed below.
5.1. Scenario 1: Static Nodes. Figure shows the deployment
of the experimental network for scenario . All the nodes are
Mobile Information Systems
0
10
20
30
40
50
60
70
80
90
100
Number of packets sent by source nodes (k)
Successful transmission rate (%)
12 3 4 8 12 16 20
QPRD
DMQoS
noRouting
(a) roughput
0
5
10
15
20
25
30
35
40
45
Forwarded packets (k packets)
Number of packets sent by source nodes (k)
12 3 4 8 121620
QPRD
DMQoS
noRouting
(b) Packets forwarded by intermediate nodes
0
10
20
30
40
50
60
70
Trac load (k packets)
Number of packets sent by source nodes (k)
12348121620
QPRD
DMQoS
noRouting
(c) Overall network trac
0
2
4
6
8
10
12
Number of packets time outs (k)
Number of packets sent by source nodes (k)
12348121620
QPRD
DMQoS
noRouting
(d) Packets timeout
0
1
2
3
4
5
6
7
8
Buer overow (k packets)
Number of packets sent by source nodes (k)
12348121620
QPRD
DMQoS
noRouting
(e) Packets dropped due to MAC buer overow
0
50
100
150
200
250
300
Energy consumption (J)
Number of packets sent by source nodes (k)
12348121620
QPRD
DMQoS
noRouting
(f) Overall energy consumption
F : Performance comparison for dierent parameters when source nodes are static.
Mobile Information Systems
T : Parameters information.
Deployment
Area Scenarios and : m by m
Scenario : m × m
Deployment type
Scenario : all nodes are static
Scenario : movable source node B
Scenario : hospital environment
Number of nodes Scenarios and : nodes ( BANs, MDCs, NSC)
Scenario : nodes ( BANs, MDCs, NSC)
Initial nodes locations
Scenarios and : NSC(,),
MDC(,), MDC(,), MDC(,)
B(,), B(,), B(,), B(,)
Scenario : shown in Figure
Initial node energy J (= AA batteries)
Buer size packets
Link layer trans. rate Kbps
Tra n smit p o wer − dBm
Task
Application type Event-driven
Max. packet size bytes
Tra c t ype CBR (Constant Bit Rate)
MAC IEEE .. Default values
Simulation Time seconds
( seconds are setup time. Simulation results are the
average of three rotations.)
static in this scenario. e type devices (BANCs: B1,B
2,B
3,
and B4) are considered as source nodes, and type devices
(NSC and MDCs) are the destination nodes. B1sends packets
to MDC1,B
2sends packets to MDC2,B
3sends packets to
MDC3,andB
4sends packets to NSC. e data of B4has to
go through the other devices to reach NSC. e source nodes
send a total of k delay-sensitive packets. e throughput,
packets forwarded by intermediate nodes, overall network
trac, number of packets timeout, packets dropped due to
MAC buer overow, and overall energy consumption are
calculated aer every packets until k and then every
packets sent by all BANCs.
From Figure (a),itisseenthatQPRDconsistentlypro-
vides throughput of % or more. In comparison, noRout-
ing provides an average of % transmission rate, whereas
DMQoS has a throughput ranging from % to %. For
low oered data loads of k, DMQoS has a throughput of
% that continues to decrease especially for high oered
data loads of k, when the throughput is %. e low
throughput in DMQoS may be explained by the way it selects
the next hop using the energy-aware geographic forwarding
scheme. Because the best next hop does not guarantee that
it has the smallest latency connection to the destination, the
packet may timeout when it is sent using the “best” next hop.
Moreover, the energy-aware geographic forwarding scheme
used in DMQoS prefers the nearest next hop candidate in
terms of hop count and ignores next hop nodes having a
lower delay. As a result, the network trac is increased and
the packets are dropped due to timeout before reaching the
destination. QPRD resolves these issues by using the end-to-
end path delay.
B2is the closest node to the destination nodes (i.e.,
NSC or MDCs) as shown in Figure .InDMQoS[], B2is
responsible for forwarding the data packets from other nodes
to NSC or MDCs. is results in more energy consumption
for B2and increased trac congestion experienced by B2.
EPR resolves these problems by choosing the most appro-
priate next hop. In the proposed QPRD scheme, the BAN
coordinator does not send data to another BAN coordinator
unless it is absolutely necessary. Figure (b) shows the num-
ber of packets forwarded by the intermediate nodes. It is seen
from Figure (b) that number of data packets forwarded by
intermediate nodes before reaching the destinations in QPRD
areonaverage.timesandtimeslowerthanDMQoSand
noRouting, respectively.
e lower number of forwarded packets by intermediate
nodes helps to reduce the overall network trac. Figure (c)
shows the total network trac generated by QPRD, DMQoS,
and noRouting as a function of the oered trac load. From
this Figure, it is seen that QPRD generates about an average of
%and%lesstracinthenetworkcomparedtoDMQoS
and noRouting, respectively. e path calculation in QPRD
considers the delay of all the nodes and uses the best path
delay information to select the next hop to send the data from
source to destination.
In contrast to the method used in DMQoS which decides
on the immediate next hop based merely on next hop delay
instead of overall path delay, each upstream hop in DMQoS
sends the packet to its next hop and resultant path in DMQoS
may not be the most optimal.
From Figure (d) it is observed that QPRD and noRout-
inghavenopacketsthatweretimedoutforalloered
Mobile Information Systems
MDC1B1
NSC and MDC4
MDC2
MDC3
B2
B3B4
(2, 5) (5, 5)
(0, 3)
(2, 1) (5, 1)
(6, 3) (9, 3)(3, 3)
F : Node deployment for scenario .
trac loads (number of data packets sent by source node
range from k to k). QPRD has better performance in
terms of reduced overall network trac and fewer numbers
of dropped packets due to timeout, because the clear end-
to-end path delay information helps the packet to reach
the destination within the requested delay requirement.
Moreover, the path calculation in QPRD considers the delay
of all the nodes in the network and chooses only those paths
which can guarantee delivering the packet to the destination
before it times out.
Figure (e) shows that there is no packet dropped due to
theMACbueroverowinQPRDprotocol.isisduetono
violation of the model constraints as explained in Sections .
and ..esourcenodechoosesthepathwhichprovides
the maximum throughput and minimum end-to-end path
delay as described in [,]. Only few packets are dropped
in DMQoS, whereas . k packets are dropped in noRouting.
It is seen from Figure (f) that the end-to-end path delay
mechanism used in QPRD does not aect the overall energy
consumption when compared with DMQoS. QPRD and
DMQoS consume the same Joules to Joules of energy
when k to k packets are sent by source nodes. On the
other hand, the energy consumption of noRouting protocol
is . Joules to . Joules when k to k packets are sent by
source nodes. e data packets in noRouting are randomly
forwarded to three neighbor nodes without considering the
delay requirements. e additional computations for delay
in QPRD consume on average times more energy than
noRouting. However, it must be noted that noRouting results
in on average a % higher overall network trac. is
may be attributed to the times more packets forwarded by
intermediate nodes in noRouting resulting in a % lower
throughput as compared to QPRD.
In summary, QPRD outperforms DMQoS and noRouting
whenthesourcenodeisstatic.
5.2. Scenario 2: Mobile Source Node. Inthesecondscenario,
thesourcenodeB
4is moving at the speed of meter per
second vertically as shown in Figure . It is assumed that the
speed of a fast walking patient is meter per second.
Once again, it is observed that QPRD provides better
results than DMQoS and noRouting in case of mobile source
node scenario. Figure (a) shows that the throughput is in
excess of % in QPRD for oered data packet rates less than
k. e throughput reduces slightly at higher oered data
packet rates of k and more and reduces to % when total
oered packets sent by the source are k. In contrast with
DMQoS, it is observed that when the oered data packet load
is increased, DMQoS suers from a much lower successful
data transmission rate that reduces from % to % with
resultant low throughput. Due to node mobility, the source
node moves away from its neighbor nodes resulting in a
connection loss which results in more packets being lost.
QPRD handles this situation much more gracefully than
DMQoS. In QPRD, the mobile nodes resume the connection
more rapidly once the nodes come back into the range of
neighbor node. e overall lower throughput in this scenario
isduetothepacketlostwhenthemobilenodeisoutofrange.
Equation (d) in Section . also supports this behavior.
According to (d), the packet delivery is successful only if a
source node transmits data to an in-range destination node.
e packets are dropped when the movable nodes go out of
range. e noRouting provides the lower throughput with an
average of %.
Figure (b) shows that the number of packets forwarded
by the intermediate nodes in QPRD is on average .
times and times lower when compared to the number of
packets forwarded by intermediate nodes in DMQoS and
noRouting protocols, respectively. e routing mechanism
used in the QPRD protocol helps to send the data directly
to the destination without transferring the packets to the
intermediate nodes in case the destination is in range. It can
be seen in Section . that use of intermediate node results
in larger delay and in Section . that the backo of other
noncapturing nodes also contributes to exacerbating the
problem. e performance of noRouting for this parameter
isworstasitforwardsuptokpacketswhichincreasesthe
overall network trac.
It is observed f rom Figure (c) that the overall network
trac in QPRD is about % and % less than DMQoS
and noRouting protocols, respectively, for all oered network
data loads considered. is is due to the end-to-end path
calculation mechanism used in QPRD. e delay of all the
nodes is considered and QPRD algorithm selects the best next
hop, on the basis of end-to-end path delay information, to
send the data from source to destination.
From Figure (d),itisseenthatQPRDhasnopacketsthat
were timed out for data packet transmissions at k or less.
e selection of minimum end-to-end path delay, given in
[], helps QPRD to send the data through a path where lower
packets time out occurs. For high data packets (above k), the
source node moves out of the neighbors’ radio range which
causes more packets to time out. On the other hand, DMQoS
has more timed out packets than QPRD. Initially for low
oered data packet rates below k, about % of data packets
were timed out, and for higher oered data packets (above
k)the%ofdatapackettimeoutsincreaseto%(approx-
imately). is is because the packets travel through dierent
nodes by using hop-by-hop delay calculation as discussed in
detailinscenario.Equation() in Section . shows that
the delay on each node is the summation of four dierent
delays (i.e., transmission (DLtrans), MAC and network queues
Mobile Information Systems
0
20
40
60
80
100
120
Successful transmission rate (%)
Number of packets sent by source nodes (k)
12 3 4 8 12 16 20
QPRD
DMQoS
noRouting
(a) roughput
0
5
10
15
20
25
30
Number of packets sent by source nodes (k)
12 3 4 8 121620
Forwarded packets (k packets)
QPRD
DMQoS
noRouting
(b) Packets forwarded by intermediate nodes
0
5
10
15
20
25
30
35
40
45
50
Trac load (k packets)
Number of packets sent by source nodes (k)
12348121620
QPRD
DMQoS
noRouting
(c) Overall network trac
0
2
4
6
8
10
12
Number of packets time outs (k)
Number of packets sent by source nodes (k)
12 3 4 8 12 16 20
QPRD
DMQoS
noRouting
(d) Packets timeout
0
1
2
3
4
5
6
7
8
9
10
Buer overow (k packets)
Number of packets sent by source nodes (k)
12 3 4 8 12 16 20
QPRD
DMQoS
noRouting
(e) Packets dropped due to MAC buer overow
0
50
100
150
200
250
300
Energy consumption (J)
Number of packets sent by source nodes (k)
12 3 4 8 12 16 20
QPRD
DMQoS
noRouting
(f) Overall energy consumption
F : Performance comparison for dierent parameters when source node is mobile.
Mobile Information Systems
3mBAN19
(5, 15)
MDC19
(4, 14)
BAN20
(8, 15)
MDC20
(7, 14)
BAN21
(11, 15)
MDC21
(10, 14)
BAN22
(14, 15)
MDC22
(13, 14)
BAN23
(17, 15)
MDC23
(16, 14)
BAN24
(20, 15)
MDC24
(19, 14)
3m
BAN18
(3, 12) MDC18
(4, 11)
BAN13
(8, 10)
MDC13
(7, 11) BAN14
(11, 10)
MDC14
(10, 11) BAN15
(14, 10)
MDC15
(13, 11) BAN16
(17, 10)
MDC16
(16, 11) BAN17
(20, 10)
MDC17
(19, 11)
3mBAN8
(8, 7)
MDC8
(7, 8) BAN9
(11, 7)
MDC9
(10, 8) BAN10
(14, 7)
MDC10
(13, 8) BAN11
(17, 7)
MDC11
(16, 8) BAN12
(20, 7)
MDC12
(19, 8)
(4, 7)
NSC
3m
BAN1
(2, 0)
MDC1
(3, 3) BAN2
(5, 0)
MDC2
(4, 3) BAN3
(8, 0)
MDC3
(7, 3) BAN4
(11, 0)
MDC4
(10, 3) BAN5
(14, 0)
MDC5
(13, 3) BAN6
(17, 0)
MDC6
(16, 3) BAN7
(20, 0)
MDC7
(19, 3)
2m
21 m
2m
2m
2m
3m
3m
3m
16 m
2m
3m
F : Scenario . Node deployment for patient beds in hospital environment.
(DLqueue), channel (DLchannel ), and processing (DLproc). e
calculationsdonebyDMQoSoneachnodeincreasethe
processing delay which causes the increase of overall node
delay. e higher node delay results in packet time out. e
source node mobility makes the packet time out worse than
scenario of Figure (d).
Figure (e) shows that there are no packet drops due
to MAC buer overow in QPRD and DMQoS protocols,
whereas k packets are dropped in noRouting. e perfor-
mance of DMQoS is similar to QPRD in terms of MAC
buer overow; however, DMQoS has on average % lower
throughput and an average of % higher overall network
trac.
From Figure (f), it is observed that the overall energy
consumptions of QPRD and DMQoS are . Joules to
. Joules when k to k packets are sent by source
nodes. e noRouting consumes . Joules to Joules
when k to k packets are sent by source nodes. e
computations for delay in QPRD are almost similar to the
DMQoS but QPRD provides on average % lower overall
network trac, % fewer packets forwarded by interme-
diate nodes, and, more importantly, a % higher success-
ful data transmission rate (throughput) as compared to
DMQoS.
In summary, the overall performance of QPRD is better
than DMQoS and noRouting when the source node is mobile.
6. Scalability Test: Real Hospital Environment
with 24 Beds (49 Nodes)
A real -patient-bed hospital is considered for the scalability
test of QPRD routing protocol, as shown in Figure .e
approximate area covered is m by m which is similar
to the Hematology-Oncology Unit of the Children Hospital
named IWK Health Centre Halifax, Canada. e distance
between two beds is meters which is in accordance with the
recommended transmission range for BAN communication
in hospital environment. e total nodes used in the deploy-
ment area are ( BANs, MDCs, and NSC). Each BAN
transmits the data to its peer MDC. All the BANs and MDCs
are sending or receiving Hello protocols to/from other nodes
and the NSC.
Both MDCs and BANs are movable. Generally, BANs can
move freely anywhere and the movement of a MDC is only
within the room where it is placed. It is assumed that the
MDC of one room has a connection with the MDC of the
next room.
Mobile Information Systems
0
20
40
60
80
100
120
Successful transmission rate (%)
Packets sent by source nodes (k)
3.5
9.5
15.5
21.5
27.5
33.5
39.5
45.5
51.5
57.5
QPRD
DMQoS
noRouting
(a) roughput versus oered load
0
20
40
60
80
100
120
140
160
180
Network trac (k packets)
QPRD
DMQoS
noRouting
Packets sent by source nodes (k)
3.5
9.5
15.5
21.5
27.5
33.5
39.5
45.5
51.5
57.5
(b) Overall network trac
0
5
10
15
20
25
Buer overow (packets (k))
QPRD
DMQoS
noRouting
Packets sent by source nodes (k)
3.5
9.5
15.5
21.5
27.5
33.5
39.5
45.5
51.5
57.5
(c) Packets dropped due to MAC buer overow
0
5
10
15
20
25
30
Packets time out (k)
QPRD
DMQoS
noRouting
Packets sent by source nodes (k)
3.5
9.5
15.5
21.5
27.5
33.5
39.5
45.5
51.5
57.5
(d) Packets timeout
F : Performance comparison for dierent parameters of scenario .
e simulation results show that QPRD performs better
than DMQoS and noRouting even when the number of
nodes is increased to . From Figure (a) it is seen that the
throughput provided by QPRD is in excess of %, whereas
the throughput of noRouting and DMQoS protocols is on
average % and %, respectively. From Figure (b),itis
observed that the overall network trac of QPRD is % and
% less than noRouting and DMQoS protocols, respectively.
Figure (c) shows that the packet drops due to MAC buer
overowinQPRDandDMQoSprotocolsarenegligible,
whereas k packets are dropped in noRouting. Figure (d)
shows that there are no packets timeouts due to not fullling
the delay requirements in QPRD and noRouting. On the
otherhandkpacketsaretimedoutinDMQoS.Fromthese
results it is shown that QPRD is equally eective when the
deployment area is larger, and number of nodes has been
increased to simulate a real hospital scenario with patient
beds.
7. Conclusion
epapermodelsthewirelessBANasadirectedgraphand
derives conditions for throughput maximization and end-
to-end delay minimization. It is shown that ecient energy
utilization is critical to the proper design of the routing
and MAC layer protocols. Similarly, delay is minimized by
formulating the BAN end-to-end path delay as a linear pro-
gramming problem with multiple constraints to be satised
simultaneously.
Basedonthemathematicalanalysis,anovelmodular
QoS-aware routing protocol for hospital BAN communi-
cation is proposed in this paper. e architecture of the
new protocol consists of seven modules: the MAC receiver,
the delay module (DM), the packet classier (PC), the
Hello protocol module (HPM), the routing services module
(RSM), the QoS-aware queuing module (QQM), and the
MAC transmitter. e proposed routing protocol provides
Mobile Information Systems
a mechanism for the end-to-end path delay calculation of
all possible paths from a source to destination and then
decides the best possible path by considering the path delay
requirements of the delay-sensitive packets.
OMNeT++ based simulator Castalia . is used to test
the performance of the proposed protocol (QPRD) and
compare it with DMQoS and noRouting. e simulations
are performed for both the movable source and stationary
scenarios. A scalability test is done with larger deployment
area and by using higher number of nodes. e results show
that the QPRD oers over % successful data transmission
rates for delay-sensitive packets in a stationary patient sce-
nario. QPRD provides about % better results in terms of
successful transmission rate than DMQoS in the movable
patient scenario. e simulation results show that the QPRD
improves the reliability of Body Area Networks by % on
average for each scenario by decreasing the number of packet
time outs with zero and averaging packets for the static
and mobile patient scenarios, respectively. In addition, QPRD
results in an average of % lower overall network trac
for each mobile and static patient scenarios as compared
to similar protocols. e scalability test results prove that
QPRD outperforms DMQoS and noRouting even when a
higher number of nodes are employed in the BAN. QPRD
provides on average % throughput without any packet
being timed out and any packet being dropped due to MAC
buer overow.
Notations for the Proposed Algorithm
Node :Sourcenode
Node : Neighbornodeofsourcenode
Node Dst: Destination node (i.e., NSC, MDC,
BAN)
IDDst: Destination ID
Dst: Destination location
ID𝑗:NeighbornodeID
𝑗:Neighbornodelocation
(𝑗,Dst): Distance between neighbor node and
destination Dst
𝑗:Residualenergyofnode
𝑗:Devicetypeofnode
(𝑖,𝑗): Distance between node to neighbor
node
NH(𝑖,Dst): Next hop between node and
destination Dst
NH𝐸: Energy-aware next hop
NH𝐷: Next hop for delay-sensitive packets
DLpath(𝑖,Dst):Pathdelayfromnodeto destination
Dst
DLnode(𝑖): Time delay within the node
DLreq: Required path delay for delay-sensitive
packets.
Conflict of Interests
e authors declare that there is no conict of interests
regarding the publication of this paper.
References
[] B.Zhen,M.Patel,S.Lee,E.T.Won,andA.Astrin,“---
--tg-technical-requirements,” IEEE Project: IEEE
P. Working Group for Wireless Personal Area Networks
(WPANs), , https://mentor.ieee.org/./dcn//--
---tg-closing-report-march-.ppt.
[] IEEE, “IEEE . WPAN task group (TG) body area net-
works,” IEEE ., , http://ieee.org//pub/TG.html.
[]D.Curtis,E.Shih,J.Watermanetal.,“Physiologicalsignal
monitoring in the waiting areas of an emergency room,” in
Proceedings of the ICST 3rd International Conference on Body
Area Networks (BodyNets ’08), Tempe, Ariz, USA, .
[] S. Jiang, Y. Cao, S. Iyengar et al., “CareNet: an integrated
wireless se nsor networking environment for remot e healthcare,”
in Proceedings of the 3rd International ICST Conference on Body
Area Networks (BodyNets ’08), Tempe, Ariz, USA, March .
[] T. Gao, T. Massey, L. Selavo et al., “e advanced health and
disaster aid network: a light-weight wireless medical system for
triage,” IEEE Transactions on Biomedical Circuits and Systems,
vol. , no. , pp. –, .
[] A. Wood, G. Virone, T. Doan et al., “ALARM-NET: wireless
sensor networks for assisted-living and residential monitoring,”
Tech. Rep. CS--, Department of Computer Science,
University of Virginia, Charlottesville, Va, USA, .
[] Z.Khan,S.Sivakumar,W.Phillips,andN.Aslam,“Anewpatient
monitoring framework and Energy-aware Peering Routing Pro-
tocol (EPR) for Body Area Network communication,” Journal
of Ambient Intelligence and Humanized Computing,vol.,no.,
pp.–,.
[] Z. Khan, S. Sivakumar, W. Phillips, and B. Robertson, “A QoS-
aware routing protocol for reliability sensitive data in hospital
bodyareanetworks,”Procedia Computer Science,vol.,pp.–
, .
[] Z. Khan, S. Sivakumar, W. Phillips, and B. Robertson, “QPRR:
QoS-aware peering routing protocol for reliability s ensitive data
in body area network communication,” e Computer Journal,
.
[] Z.Khan,S.Sivakumar,W.Phillips,andB.Robertson,“QPRD:
QoS-aware peering routing protocol for delay sensitive data
in hospital body area network communication,” in Proceedings
of the 7th International Conference on Broadband, Wireless
Computing, Communication and Applications (IEEE BWCCA
’12), pp. –, University of Victoria, Victoria, Canada,
November .
[] X. Huang and Y. Fang, “Multiconstrained QoS multipath
routing in wireless sensor networks,” Wirel ess Net works,vol.,
no. , pp. –, .
[] S. Agarwal, Divya, and G. N. Pandey, “SVM based context
awareness using body area sensor network for pervasive health-
care monitoring,” in Proceedings of the 1st International Con-
ference on Intelligent Interactive Technologies and Multimedia
(IITM ’10), pp. –, Allahabad, India, December .
[] A. Razzaque, C. S. Hong, and S. Lee, “Data-centric multiob-
jective QoS-aware routing protocol for body sensor networks,”
Sensors, vol. , no. , pp. –, .
[] E. Felemban, C.-G. Lee, and E. Ekici, “MMSPEED: multipath
multi-SPEED protocol for QoS guarantee of reliability and
timeliness in wireless sensor networks,” IEEE Transactions on
Mobile Computing,vol.,no.,pp.–,.
[]M.Chen,T.Kwon,S.Mao,Y.Yuan,andV.C.M.Leung,
“Reliable and energy-ecient routing protocol in dense wireless
Mobile Information Systems
sensor networks,” International Journal of Sensor Networks,vol.
,no.-,pp.–,.
[] M. Razzaque, M. Alam, M. Rashid, and C. Hong, “Multi-
constrained QoS geographic routing for heterogeneous trac in
sensor networ ks,” in Proceedings of the 5th IEEE Consume r Com-
munications and Networking Conference (CCNC ’08),Kyung
HeeUniversity,LasVegas,Nev,USA,January.
[] J. Elias and A. Mehaoua, “Energy-aware topology design for
wireless body area networks,” in Proceedings of the IEEE Interna-
tional Conference on Communications (ICC ’12), pp. –,
Ottawa, Canada, June .
[] N. Ababneh, N. Timmons, J. Morrison, and D. Tracey, “Energy-
balanced rate assignment and routing protocol for body area
networks,” in Proceedings of the 26th IEEE International Con-
ference on Advanced Information Networking and Applications
Workshops (WAINA ’12), pp. –, Fukuoka, Japan, March
.
[] NICTA, “Castalia,” National ICT Australia, , http://castalia
.npc.nicta.com.au/.
[] A. Boulis, “Castalia, wireless sensor network simulator, NICTA,”
, https://forge.nicta.com.au/docman/view.php///
Castalia+-+User+Manual.pdf.
