Wireless Sensor Networks with QoS for e-Health
and e-Emergency Applications
Óscar Gama
, Paulo Carvalho
, J. A. Afonso
and P. M. Mendes
Informatics Dept., University of Minho, Braga, Portugal
Industrial Electronics Dept., University of Minho, Braga, Portugal
Abstract. Most body sensor networks (BSN) only offer best-effort service de-
livery, which may compromise the successful operation of emergency health-
care (e-emergency) applications. Due to its real-time nature, e-emergency sys-
tems must provide quality of service (QoS) support, in order to provide a per-
vasive, valuable and fully reliable assistance to patients with risk abnormalities.
But what is the real meaning of QoS support within the e-emergency context?
What benefits can QoS mechanisms bring to e-emergency systems, and how
are they being deployed? In order to answer these questions, this paper firstly
discusses the need of QoS in personal wireless healthcare systems, and then
presents an overview of such systems with QoS. A case-study requiring QoS
support, intended to be deployed in a healthcare unit, is presented, as well as an
asynchronous medium access TDMA-based model.
1 Introduction
An e-health system consists of a group of sensors attached non-invasively to a patient
in order to sense the physiological parameters. It has been used in hospitals during the
last decades using conventional wired equipment, hence not allowing the patient to
move around freely. However, recent advances in wireless sensors technology are
changing this scenario by permitting mobile and permanent monitoring of patients,
even during their normal daily activities [1].
An e-health system should be able to accomplish at least one crucial aim: to moni-
tor a patient and, when an emergency occurs, to trigger immediately an event to alert
the patient and/or to warn a remote caregiver. In this way, both the patient and the
caregiver can take timely the right procedure in accordance with the clinical episode.
The system should also be able to trigger an alert anticipating the case where the
patient is unaware of his/her health gravity. When a patient´s clinical state turns from
a non-critical situation into a critical one, a context change occurs and consequently
the healthcare network should adapt its performance requirements to the new situa-
tion. For instance, higher monitoring activity and lower delay transmission of the vital
signals might be required when the patient´s clinical situation changes from non-
critical to critical. Hence, healthcare networks should provide QoS facilities for e-
Gama Ó., Carvalho P., A. Afonso J. and M. Mendes P. (2008).
Wireless Sensor Networks with QoS for e-Health and e-Emergency Applications.
In Proceedings of the 2nd International Workshop on e-Health Services and Technologies, pages 60-69
DOI: 10.5220/0001899500600069
emergency services, since these clearly demand for high reliability, guaranteed band-
width, and short delays.
2 Vital Signal Monitoring
e-Emergency requires monitoring of several vital signals simultaneously. For exam-
ple, a patient in an ambulance is monitored for blood pressure, heart and respiration
rates, and temperature. Besides these primary signals, other information may be cap-
tured to help diagnosis and medical decision, such as electrocardiogram (ECG), blood
glucose level, blood oxygen saturation (SpO
), heart and breathing sounds, or even an
image in cases of trauma. Table 1 presents the electrical characteristics of the vital
signals usually used in emergency medical care [2] [3]. If some signal exceeds the
defined threshold, the local supervisor node should trigger an alarm to inform a care-
giver or the patient himself.
At non-emergency medical situations, ECG and SpO
signals are usually transmit-
ted in bursts, while signals such as body temperature and blood glucose are transmit-
ted in single packets to the BS [4]. In fact, to reduce the traffic load and the power
consumption of a BSN, the current trend in telemedicine systems is to enhance sensor
node intelligence, available memory, processing power, and enabling on-line solicited
requests only for results. In this way, continuous and bulk data transfer is sporadic,
occurring only in intermittent occasions [4]. However in emergency cases, this should
not be the rule, since patient´s life is priceless and above any other consideration.
Continuous and bulky data transfer in real-time might be prevalent here.
Table 1. Vital Signal Electrical Characteristics.
Vital signal (Hz) Freq. range (Hz) Sampling rate (Hz) Resolution (bit)
ECG (per lead) 0.01…60-250 120-500 16
Temperature 0…0.1-1 0.2-2 12
Oximetry 0 … 30 60 12
Blood pressure (BP) 0 … 60 120 12
Respiration rate 0.1 … 10 20 12
Heart rate (HR) 0.4 … 5 10 12
3 QoS Needs in e-Health
Some authors argue that differentiation based on data priority is inherent to wireless
sensor networks (WSN), since it is normal to have sensors to monitor distinct physi-
cal parameters simultaneously, just as in BSNs. Here, the importance of the collected
information is necessarily distinct, and so the network must prioritize the transmission
of critical data when occurs a sudden clinical change in the patient. For example, in
patients with cardiac diseases, heart activity information is more important than body
temperature data. Also, depending on the patient´s clinical condition, the priority
assigned to a vital signal can change dynamically. For instance, glucose data might be
assigned a low priority when readings are in the normal range, but a higher priority
might be reassigned to it when readings indicate hypo or hyper-glycemia.
Most current BSNs only offer best-effort service [5], which is limitative for e-
emergency support. In these networks, the QoS provision is required to assist critical
cases conveniently. This will enable, for instance, guaranteed bandwidth to higher
priority streams for an efficient data delivery, even in case of interference or fading.
QoS mechanisms are usually deployed in networks to guarantee consistent service
levels concerning certain parameters, such as packet loss ratio, transmission delay,
jitter, and available bandwidth. These are traditional end-to-end QoS parameters used
to characterize the performance of communication infrastructures, including BSNs.
For instance, the total delay of an ECG signal being displayed in the monitor should
be less than 3 s for useful real time analysis by the cardiologists [6]; ECG signals
require a minimum sampling rate of 250 Hz to guarantee that jitter does not affect the
estimation of the R-wave fiducial point, which modifies considerably the spectrum
[7]. No significant difference between ECG traces are detected by sampling the signal
at rates between 250 and 500 Hz, but significant reduction in peak amplitude values
and inaccurate interval measurements are obtained at 125 samples/s [4].
However, QoS in BSNs may not be fully described using only those parameters,
because of its context-aware nature. For example, at application level, QoS may be
regarded as guaranteeing the right number of sensors for monitoring the vital signals
in accordance with the patients´ emergency state.
The available energy in the BSN is another very important parameter to take into
account. In fact, if energy is carelessly consumed, the BSN may rapidly become com-
pletely useless due to lack of power. To prevent such failure, energy should be care-
fully saved using different approaches. For example, if the patient is in normal state
then the sampling rate of sensors can be reduced to save power, or if the battery
charge becomes low then its energy should be reserved to the more vital tasks of the
patient. That is to say, the monitoring activity should adapt in accordance with the
patient clinical state for energy saving. To save further energy, communication proto-
cols should be simple, and data should be aggregated, eventually compressed, and
transmitted in full-loaded packets, since computing demands much less energy than
transmission. Attention must also be paid to delay, as it tends to increase linearly with
the packet length.
Additionally, prioritizations may be used to provide QoS. For example, for effi-
ciency reasons a large packet length may be chosen for non-critical situations. But as
soon as an emergency occurs, the packet size can be reduced to meet the low delay
QoS requirement, and signals considered irrelevant to this emergency episode are
sampled at a lower rate, or not sampled at all.
Moreover, the computation power may be lowered to a minimum as all data must
be forwarded, in opposition to the regular operation where, to save energy, the car-
dio-respiratory rhythm can be computed on-board before sending it. Or else, an ECG
signal can be processed in the sensor itself to extract its relevant features. In this way,
only information about an event is transmitted (e.g., QRS features and the corre-
sponding timestamp of R-peak), hence reducing the traffic load and saving energy.
A BSN does not transmit only measurement data packets. Other packets may be
present, such as those carrying control or alerting data. In this way, it is suggested
that a high-priority level should be assigned to data packets carrying alarming notifi-
cation and measurements, and acknowledgement of correctly received packets; a
medium priority level should be assigned to scheduled transmissions of data packets,
and primary control packets (e.g. sensor configuration); and a low priority level
should be given to periodic polling of nodes for network integrity check, and secon-
dary control packets (e.g. link) [4].
The vital signals captured from the patient body must be delivered to a remote di-
agnosis and decision centre, through some available communication infrastructure
such as the Internet or a 3G mobile communication network. As a result, the deliv-
ered QoS depends necessarily on the network infrastructure chosen for the delivery of
mobile health services. Therefore, to meet the required QoS, the mobile health ser-
vices platform needs to be able to acquire and use contextual information about the
QoS offered by communication network infrastructures available at the patient’s
current location and time [5]. High availability and reliability are the most desirable
characteristics that these network infrastructures should offer, as well as QoS guaran-
tees for bandwidth, end-to-end delay, jitter and loss.
4 e-Health Wireless Systems with QoS
Despite the number of e-health systems already developed [1], only a few encompass
QoS support. In order to assess how QoS support is being deployed in e-health
WSNs, some representative projects were analyzed, as well as the QoS requirements
that the respective authors have considered important to incorporate in their imple-
mentations. Based on the related literature, QoS projects for e-health can be grouped
according to the following topics: frameworks with QoS; QoS through reconfigura-
tion; and algorithms for QoS enhancement.
Frameworks with QoS. She et al. [8] propose an infrastructure for remote medical
applications using ZigBee and commercial 3G networks. In order to improve the
delay and the transmission time of critical vital signals (so improving the overall QoS
in terms of latency, bandwidth, and power consumption), a differentiated service
based on priority scheduling and data compression is presented. In this model, a pa-
tient server receives instructions from a remote hospital server and configures the
patient´s BSN accordingly. The wireless sensors transmit the signals to the patient
server. Here, each type of vital signal receives a priority level and then is transmitted
to the hospital server according to their priorities. By example, for a cardiac disease
patient, a higher priority level is assigned to ECG signals than to body temperature.
Thus ECG signals will be processed and sent earlier than body temperature if both
arrive at the personal server at the same time. High data rate and delay tolerant signals
will be compressed and stored in local memory for later transmission. The physician
analyses the incoming data and will act accordingly to the clinical episode.
Vergados et al. [9] propose a wireless DiffServ infrastructure for mobile telemedi-
cine. Formed by several e-health DiffServ domains, the network can reliably handle
both normal and life-critical medical applications under extreme traffic conditions.
Assigning different priority levels according to the specific medical application
needs, and according to the urgency of the medical incident, causes the network to
intelligently drop and/or delay the packets, in order to achieve a high service level.
QoS through Reconfiguration. Usually a WSN is reconfigured based on common
parameters, such as traffic load, node failures, channel utilization, energy drainage,
etc. Gondal et al. [10] suggest that the reconfiguration also takes into account the
physician’s recommendations for patient monitoring schedule, the condition of the
physiological parameters being sensed by the network, and the disease diagnosis
outcome from an automated or manual system. This information will be fed back into
the body area network so that it can self-reconfigure to monitor the patient with the
required intensity, while concomitantly tries to maximize the network reliability,
throughput and lifetime. This operation of translating the clinical operations into
network sensing schedules and reconfiguration decision, providing in this way a
service with the required monitoring quality, is the key focus of this framework.
MiLAN [11] is a middleware system targeted for reconfiguring centralized net-
works with few sensors and no mobility, particularly body area networks. It assumes
that a vital signal may be read from different sensors with different reliabilities. For
instance, ECG sensors and SpO
sensors can provide heart rate with reliability of 1
and 0.7, respectively. In this way, MiLAN uses graphs provided by the application,
together with information about the current application state, to decide how to con-
figure and manage both the network and sensors in order to meet the QoS application
requirements, for instance, the reading of a vital signal with a defined reliability. At
the same time, it tries to maximize the application lifetime, instead of the sensors
lifetime. However this kind of approach seems unsuitable for e-emergency systems,
as full reliability is required.
Algorithms for QoS Enhancement. The common way to recover the lost or cor-
rupted data in connectionless transmissions is through retransmission processes.
However common automatic requests mechanisms are unable to guarantee data re-
covering in a bounded transmission delay, as required in e-emergency systems. To
tackle this problem, Henrion et al. [12] use restoration algorithms to recover the ECG
missing packets that do not arrive to the monitoring equipment within an acceptable
delay. Simulations results showed that, even for 8% of packet loss in transmission of
ECG data during 30 s, the restoration scheme allow reconstructing a more functional
signal for a medical expertise.
Coelho Jr. et al. [13] apply the concept of QoS to power management in a real-time
remote physiological monitoring system. The authors present a power management
model so that an application can adapt dynamically to particular situations, generating
less requests from the devices, and therefore saving energy. The model is based on an
extended power state machine whose transitions are associated with application
events, beyond the energy model of the resource being allocated. In the case of ECG
monitoring, examples of possible states can be a patient with a normal ECG, a patient
with low risk abnormalities, and a patient with high risk abnormalities; examples of
events can be loss of communication channel, ECG abnormal for the last five min-
utes, or patient signaling that is not feeling well.
According to the e-health projects herein surveyed, QoS support provided in each
approach is varied. Despite all this variety, e-health systems should always support
QoS in order to provide a pervasive, valuable and totally reliable assistance to any
patient. This is the main goal of the case-study presented in the following section.
5 Case-Study
Aware of the different QoS approaches presented above, we are implementing an
experimental testbed to deploy QoS solutions based on a real clinical scenario. The
scenario under study is based on a hospital room containing six beds with one patient
per bed. Each patient is monitored by a personal BSN, and one base-station (BS)
collects the vital signals of all patients. The signals being monitored are temperature
(T), oximetry (OXI), arterial pressure (ART), respiration rate (RR), and ECG data, as
shown in Figure 1. Each signal is collected by a dedicated wireless sensor. Patient´s
vital signals are analyzed and/or correlated at BS. Our goal is to develop a solution
which guarantees that every signal is delivered to the BS with the appropriated QoS,
as specified next.
Fig. 1. Hospital room with a patient being monitored in each bed.
According to IEEE 1073 group, a wireless ECG electrode should generate 4 kbps
of data, and the latency introduced by framing the data samples and the transmission
delay should be below 500 ms. Since ECG signals are the most demanding in terms
of QoS, we take this value as the maximum delay that any vital signal should have.
Continuous healthcare monitoring normally uses a three leads ECG device, composed
of two active electrodes plus one of reference. Since research is being done to elimi-
nate the reference electrode, we assume that each active electrode is implemented by
a wireless sensor (ECG0, ECG1). So, according to Table 1, each BSN produces a
maximum aggregated rate of 10.424 kbps, hence resulting that the maximum total
traffic inside the hospital room is 62.544 kbps. Besides guaranteeing this minimum
goodput and latency below 500 ms, the e-health system must also guarantee low
packet loss to every vital signal, low energy consumption and balanced energy drain-
age in every BSN.
In the present case-study we have initially considered Bluetooth and ZigBee tech-
nologies. As Bluetooth specifications allow a maximum of seven active slaves (i.e.
sensors) to be controlled by one master (i.e. BS), it was not considered an acceptable
ZigBee is a short range, low power, and low data rate standard for WSNs that sup-
ports a maximum rate of 250 kbps in the 2.4 GHz band. Therefore, a ZigBee WSN is
able to handle the whole traffic generated inside the hospital room without congest-
ing. Nevertheless, other factors which may affect QoS significantly have to be con-
sidered, such as the wireless channel access and transmissions errors. It is shown next
why ZigBee is unsuitable for this case-study.
If traffic is to be sent within the same ZigBee PAN and short addresses are used,
then a payload of 928 bits per packet is available to the applications. Ideally, all pack-
ets should be sent full-loaded in order to minimize the overhead, and so saving en-
ergy. Thus, to achieve the minimum required rate of 4 kbps, one packet carrying ECG
data must be generated every 0.232 s. In addition, according to Table 1, each BSN
should generate one full-loaded packet of temperature data every 38.66 s, of oximetry
data every 1.28 s, of arterial pressure data every 0.64 s, and of respiration data every
3.86 s. Since delivery delay must be below 500 ms, it is clear that only ECG data
packets may be transmitted full-loaded.
Simulation results have shown that ZigBee is not adequate for several sensors to
transmit ECG signals to a BS with full efficiency [14]. Either in acknowledged or in
unacknowledged mode, the efficiency starts to drop when three or more ECG devices
operate in the same RF channel. This is because ZigBee relies on CSMA-CA, a con-
tention-based MAC protocol that is vulnerable to collisions. In acknowledged mode,
lost packets may be retransmitted, but there is a maximum number (5) of retries al-
lowed by ZigBee before declaring channel access failure. ZigBee seems to be more
adequate for BSNs that do not have large amounts of data to transfer, only several
small data packets per hour, like implanted medical sensors [15].
Another approach is using the beacon-enabled PAN mode described at IEEE
802.15.4 standard. The BS sends regularly beacons which bound the superframes.
These structures are divided into 16 identical slots. Any device wishing to communi-
cate during the contention access period (CAP) shall compete with other devices
using the slotted CSMA-CA. For low-latency applications or applications requiring
specific bandwidth, the coordinator may dedicate portions of the active superframe to
that application. These portions are called guaranteed time slots (GTSs). The GTSs
form the contention-free period (CFP). The PAN coordinator may allocate up to
seven of these GTSs, and a GTS may occupy more than one slot period. No transmis-
sions within the CFP shall use a CSMA-CA mechanism to access the channel. The
GTSs should be allocated dynamically to sensors accordingly with the QoS needs of
the BSN. This TDMA-based transmission technique using slots is presently not avail-
able within any ZigBee profile.
Each full-loaded packet transmitted at 250 kbps needs 4.256 ms to be completely
transmitted. Assuming that every packet is transmitted in individual slots, the beacon
transmission interval must be above 4.256*16=68.096 ms. This means that the bea-
con order (BO) should be 3, implying a beacon interval (BI) of 122.88 ms
bits, 0BO14). Note that the next BO (4) implies a BI of 245.76 ms,
hence making impossible to transmit a packet every 232 ms. There is a significant
waste of bandwidth because the packet never occupies the whole slot duration. With
BO=3, only 55.4% of the slot period is used to send a full-loaded packet.
Since twelve ECG sensors are in the hospital room, and ignoring the maximum
number (7) of GTSs imposed by the standard, only 4 slots would be available for the
other sensors to send data. A CAP having four slots and 55.4% of slot period utiliza-
tion may transmit at most 34625 bps. Comparing this value with 2424*6=14544 bps
of data sent by all the remaining sensors in the room, it is expected a large number of
collisions during the CAP, hence degrading seriously the QoS of the system.
5.1 An Hybrid Beacon-based Protocol
Considering the case-study described above, we propose a beacon-based protocol in
order to meet QoS requirements. In this protocol, beacons are transmitted at irregular
time intervals in order to guarantee the delivery of the patient´s physiological data
with the required QoS in presence of bandwidth constraints.
Fig. 2. Illustration of the asynchronous beacon-based protocol (variable mode).
The BS sends beacons to each WSN following a round-robin pattern, specifying
which data should be received from its sensors. For example, suppose a BS send one
beacon carrying this information: {dst 3, ecg0 2, ecg1 2, art 1, oxi 1, slp 150}. All
sensors belonging to BSN 3 receive the beacon and read that information. Then,
ECG0 sends immediately two consecutive packets, next ECG1 sensor sends two
packets, ART sensor sends one packet and, finally, the oximetry sensor sends one
more packet. All these packets are sent consecutively. After transmitting, each sensor
may sleep for 150 ms. The BS can estimate this time, because it can preview the data
it is going to request from the other BSNs before returning again to BSN 3. After
receiving all packets, the BS sends a beacon with a new set of requirements to the
next BSN to get the data of its sensors, as shown in Fig. 2. With this scheme, the
channel is guaranteed to be free whenever a sensor is about to transmit. For this rea-
son, a CSMA-CA mechanism to access the channel is not required and the hidden
node problem is absent. If there are in the surroundings other similar e-health WSNs
causing interferences over each other, then distinct operating channels should be
selected for each WSN (16 channels are available at 2.4 GHz band). The packet
transmission should respect the long inter-frame spacing period specified at IEEE
802.15.4 (0.64 ms) to guarantee that the MAC sub-layer of the BS is able to process
all incoming packets. The BS may send periodically a special beacon to allow the
association of a BSN newly arrived at the room. The association should be allowed
by the BS only if the allocation of resources to the new BSN does not compromise
the overall QoS of the system already established. Beacons may eventually carry the
clock time of the BS for synchronizing the network for timing measurements. Note
that the BS only polls the BSN, and not each one of its sensors. In this protocol, the
slots may be efficient and dynamically used, unlike the slotted IEEE 802.15.4, where
the fixed duration of the slots in each superframe leads necessarily to poor bandwidth
efficiency. The maximum time a sensor can wait for sending data again is about 176
ms, which verifies the condition of ECG sensors sending at least a packet every 232
ms. A BS may ask for two packets from a sensor (e.g. ecg0 2). This need occurs if the
BS did not receive a packet from a sensor in a BSN. Then, in the next polling to that
BSN, it requests that sensor for sending the present data as well as the packet lost in
the previous transmission. In order to respect the maximum delay, only one retrans-
mission attempt is scheduled in case of transmission failure. This simple ARQ
mechanism is able to control the transmission errors.
Two modes of operation are available in the proposed protocol: variable and con-
stant. In variable mode, data packets are sent in contiguous variable time-slots. In
this asynchronous operating mode, each sensor knows the right time to send data by
counting the number of transmitted packets after the beacon reception. A default slot
period needs to be defined to prevent the system from hanging, due to a transmission
failure in a sensor. As soon as a beacon addressed to its BSN is received, a sensor
must always be in listening state until it is scheduled to transmit. In order to balance
the energy drainage of the BSN, the vital signal requiring the highest sampling rate
should be the transmitted firstly, while that one requiring the lowest sampling rate
should be transmitted lastly. In constant mode, data packets are sent in contiguous
fixed time-slots. The slot duration should be long enough to hold a full-loaded packet
and a guard period to avoid adjacent transmissions overlapping. So, after receiving a
beacon, each sensor is able to calculate the time it may sleep before transmitting.
Because sensors are not required to stay in listening state before transmitting, a WSN
is more efficient energetically using constant mode than variable mode, at the cost of
a less efficient bandwidth utilization of the channel.
We have been considering that all sensors are monitoring the patients at the highest
sampling rates. However, such scenario should only occur in critical clinical epi-
sodes. In non-critical clinical situations, the sensors should monitor the patient at
lower sampling rates in order to save battery energy and channel bandwidth. Such
policy would also improve the scalability of the system. Therefore, self-reconfiguring
each BSN in accordance with the patients´ clinical state is an important paradigm to
follow. We believe that the proposed protocol associated with the self-reconfiguration
of the BSNs may produce very interesting results in terms of QoS and scalability.
6 Conclusions
Since patient´s life is priceless, emergency healthcare networks should be totally
reliable and efficient. These networks must support QoS as they clearly demand for
reliability, guaranteed bandwidth, and low delays due to their real-time nature. En-
ergy consumption should also be optimized to extend the lifetime of the BSN.
According to representative e-Health projects herein surveyed, it was observed that
QoS support provided in each approach is varied and targets different QoS levels. In
this context, (i) differentiated service provision based on priority scheduling and data
compression; (ii) wireless DiffServ infrastructure for mobile telemedicine; (iii) send-
ing feedback information into a BSN so that this can be self-reconfigured to monitor
properly the patient; (iv) restoration algorithms to recover the ECG missing packets,
or (v) extended power management models to save energy, all are illustrative exam-
ples of specific QoS deployments in e-health and e-emergency systems. Notwith-
standing all this variety, healthcare systems need to support QoS at multiple protocol
levels in order to meet a common and final goal: to provide a pervasive, valuable and
totally reliable assistance to any patient with risk abnormalities.
We have concluded that neither Bluetooth nor IEEE 802.15.4/ZigBee standards are
able to satisfy the QoS requirements demanded by the case-study herein presented.
To tackle this limitation, a hybrid medium access beacon-based model has been pro-
posed to fulfill such QoS requirements. Currently, we are testing and improving this
model in an experimental testbed.
1. E. Kyriacou et al., “e-Health e-Emergency systems: current status and future directions”,
IEEE Antennas and Propagation Magazine, vol. 49, nr. 1, Feb. 2007.
2. M. Paksuniemi et al., "Wireless sensor and data transmission needs and technologies for
patient monitor. in op. room and int. care unit", Proc. 27
IEEE EMBC, China, 2005.
3. S. Arnon et al., “A comparative study of wireless communication network configurations
for medical applications” IEEE Wireless Communications, 10(1), 2003.
4. I. E. Lamprinos et al., “Communication protocol requirements of patient personal area
networks for telemonitoring”, Technology and Health Care; vol. 14, nr. 3 : 171-187, 2006.
5. K. Wac et al., “Context-aware QoS provisioning in an m-health services platform”, Inter-
national Journal of IP Tech., 2 (2) pp.102-108, ISSN 1743-8217, 2006.
6. A. Iglesias et al., “Performance study of real-time ECG transmission in wireless networks”,
ITAB´06, Ioannina, Greece, 2006.
7. G. Pinna et al., “The accuracy of power-spectrum analysis of heart-rate variability from
annotated RR list generated by Holter systems”, Physiol. Meas., nr.15: pp. 163-179, 1994.
8. H. She et al., “A network-based system architecture for remote medical applications”, in
Asia-Pacific Advanced Network, China, Aug. 2007.
9. Vergados et al., “Applying wireless DiffServ for QoS provisioning in mobile emergency
telemedicine”, IEEE GlobeCom, Nov. 2006.
10. I. Gondal et al., “Integrated sensing and diagnosis – the next step in real time patient health
care”, 6th IEEE/ACIS ICIS, Melbourne, July 2007.
11. W. B. Heinzelman et al., “Middleware to support sensor network applications”, IEEE
Network, 18(1):6–14, 2004.
12. S. Henrion et al., “Transmitting critical biomedical signals over unreliable connexionless
channels with good QoS using advanced signal processing”, proc. WSEAS, Athens, Jan 04
13. Coelho Jr. et al., “A biomedical wearable device for remote monitoring of physiological
signals”, Proc. IEEE ETFA, vol. 2, pp.708–713, Sept. 2003.
14. N. Chevrollier et al., “On the use of wireless network technologies in healthcare environ-
ments”, Proc. 5
IEEE Workshop AWSN, Paris, France, Jun 2005.
15. N. F. Timmons et al., “Analysis of the performance of IEEE 802.15.4 for medical sensor
body area networking”, Proceedings of the IEEE SECON, Oct. 2004.