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

 SciTePress

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

option.

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

(BI=3840*2

bits, 0≤BO≤14). 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.

References

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.