Biomedical application of wireless sensor 2

0
BIOMEDICAL APPLICATION OF WIRELESS SENSOR
BY
ADU-AJIKAN, JOHNSON OLUYEMI
MATRICULATION NO: NOU060341250
MSC- INFORMATION TECHNOLOGY
SCHOOL OF SCIENCE AND TECHNOLOGY
NATIONAL OPEN UNIVERSITY OF NIGERIA
LAGOS, NIGERIA
DATE………………….

1
BIOMEDICAL APPLICATION OF WIRELESS SENSOR
BY
ADU-AJIKAN, JOHNSON OLUYEMI
MATRICULATION NO: NOU060341250
IN PARTIAL FULFILMENT OF THE REQUIREMENTS
FOR THE AWARD OF
MSC- INFORMATION TECHNOLOGY
SCHOOL OF SCIENCE AND TECHNOLOGY
NATIONAL OPEN UNIVERSITY OF NIGERIA
LAGOS, NIGERIA
DATE………………..

2
CERTIFICATION
This is to certify that the project work was prepared and submitted by Adu-Ajikan, Johnson Oluyemi
(NOU060341250) to the School of Science and Technology, National Open University of Nigeria, Lagos
in agreement with the requirements for the award of Master of Science (M.sc) in Information Technology.
.......................................................... ………………………………..
MR.OLAYANJU TAIYE
Project Supervisor DATE
....................................................... ……………………………….
EXTERNAL SUPERVISOR DATE

3
DEDICATION
This project is dedicated to the Almighty God, My Ebenezer (Rock of Help), the Ancient of Days. Lord,
you are the source of my living.
Also to my dearly Wife, my dream carrier- Augustina for believing in my dreams.
Lastly, to my parent- Mr. and Mrs. Adu-Ajikan, My brothers, sisters and friends. Thanks for your un-
ending supports

4
ACKNOWLEDGEMENT
I am so grateful to my Supervisor- Mr. Olayanju Taiye for his fatherly advice and understanding. May
the good God continue to be with you and your family. (Amen)
My Sincere appreciation also goes to all the staffs of National Open University of Nigeria both in Akoka
study centre and Headquarter offices in any way they might have contributed to the success of this project.
I also want to express my sincere appreciation to these people: My dear Brother, Mr. Ajikan Issac for his
financial support and to my course mates for their loving heart and co-operation throughout the program.
Once again, my appreciation is incomplete if I do not regard the help of my El-Shaddai God for his
sufficiency to the success of this project.
I am however, responsible for all shortcomings that might arise from the write-up and not those whose
names have mentioned above.

5
ABSTRACT
Recent technological advances in sensors, low-power integrated circuits, and wireless communications
have enabled the design of low-cost, miniature, lightweight, and intelligent physiological sensor nodes.
These nodes, capable of sensing, processing, and communicating one or more vital signs, can be
seamlessly integrated into wireless personal or body networks (WPANs or WBANs) for health
monitoring. These networks promise to revolutionize health care by allowing inexpensive, non-invasive,
continuous, ambulatory health monitoring with almost realtime updates of medical records via the
Internet.
Though a number of ongoing research efforts are focusing on various technical, economic, and social
issues, many technical hurdles still need to be resolved in order to have flexible, reliable, secure, and
power-efficient WBANs suitable for medical applications.
This paper discusses implementation issues and describes my preferable prototype sensor network for
health monitoring that utilizes off-the-shelf 802.15.4 compliant network nodes and custom-built motion
and heart activity sensors. The paper presents system architecture and hardware and software organization,
as well as the solutions for time
synchronization, power management, and on-chip signal processing.
Keywords
Wireless Sensor Networks, Health Monitoring, Hardware, Software, Signal Processing, Time
Synchronization, Energy Efficiency.
THE SPECIFIC AIM OF MY PROJECT
The aim/objective of my project topic (Biomedical Applications of Wireless Sensor Network) is to
‘discuss wireless sensor network as a wearable health monitoring device in Personal Health Monitoring
Implementation Solution’
Wearable health monitoring systems allow an individual to closely monitor changes in her or his vital
signs and provide feedback to help maintain an optimal health status. If integrated into a telemedical
system, these systems can even alert medical personnel when life-threatening changes occur.

6
LIST OF FIGURES
PAGE
Figure 1: Code Blue Wireless Sensor Node (Mote). 11
Figure 2: Components of a Wireless Sensor Node. 12
Figure 3: WeC (1999) 14
Figure 4: Rene (2000) 14
Figure 5: Dot (2001) 14
Figure 6: MICA (2002) 14
Figure 7: Speck (2003) 14
Figure 8 Berkeley MICA Mote 14
Figure 9: Vehicle Tracking 15
Figure 10: Habitat monitoring – Great Duck Island 15
Figure 11: Patient Monitoring 16
Figure 12: Mass Casualty Event Monitoring 17
Figure 13: Health Monitoring System Network Architecture 22
Figure 14: Data Flow in the Proposed Healthcare Monitoring System 24
Figure15: prototype WBAN. From left to right 25
Figure16: Block Diagram of Software Components in a WBAN 26
Figure 17: Simplified sensor node interface connection (actiS). 26
Figure 18: Communication super Frame and Activity of Sensor #2 27
Figure 19 ActiS current consumption during 5 seconds of operation 28
Figure 20: Battery life as a function of channel utilization 29
Figure 21: Events are generated and queued for transmission at timeslot 31
Figure 22: Data flow in prototype WBAN 32
Figure 23: ActiS session initialization and event detection 34
Figure 24: Arrhythmic event followed by real-time streaming data. 35

7
TABLE OF CONTENTS
PAGES
TITLE 2
CERTIFICATION 3
DEDICATION 4
ACKNOWLEDGEMENT 5
ABSTRACT 6
LIST OF FIGURES 7
TABLE OF CONTENTS 8
CHAPTER ONE
1.0 INTRODUCTION 10-11
CHAPTER TWO 11-19
2.0 LITERATURE REVIEW
2.1 HISTORY OF WIRELESS SENSOR NODE
2.2 COMPONENTS OF WIRELESS MEDICAL SENSOR NETWORKS
2.3 SENSOR NETWORKS
2.4 TYPICAL APPLICATIONS
2.41 POTENTIAL MEDICAL APPLICATIONS
2.5 SENSOR NETWORK CHALLENGES
2.6 WIRELESS SENSOR NETWORK PROTOCOLS
2.61 OVERVIEW OF ZIGBEE MONITORING AND SENSOR SOLUTION

8
CHAPTER THREE 20-35
3.0 METHODLOGY
3.1 SYSTEM ARCHITECTURE
3.2 CASE STUDY
3.3 HARDWARE ARCHITECTURE
3.4 SOFTWARE ARCHITECTURE
3.41 SENSOR NODE SOFTWARE
3.42 PERSONAL SERVER SOFTWARE
3.43 REFERENCES

9
CHAPER ONE
1.0 INTRODUCTION
Current health care systems -- structured and optimized for reacting to crisis and managing illness -- are
facing new challenges: a rapidly growing population of elderly and rising health care spending. According
to the U.S. Bureau of the Census, the number of adults age 65 to 84 is expected to double from 35 million
to nearly 70 million by 2025 when the youngest Baby Boomers retire. This trend is global, so the
worldwide population over age 65 is expected to more than double from 357 million in 1990 to 761
million in 2025. Also, overall health care expenditures in the United States reached $1.8 trillion in 2004
with almost 45 million Americans uninsured. In addition, a recent study found that almost one third of
U.S. adults, most of whom held full-time jobs, were serving as informal caregivers – mostly to an elderly
parent.
It is projected that health care expenditures will reach almost 20% of the Gross Domestic Product (GDP)
in less then 10 years, threatening the wellbeing of the entire economy [1]. All these statistics suggest that
health care globally needs a major shift toward more scalable and more affordable solutions.
Restructuring health care systems toward proactive managing of wellness rather than illness, and focusing
on prevention and early detection of disease emerge as the answers to these problems.
Wearable health monitoring systems allow an individual to closely monitor changes in her or his vital
signs and provide feedback to help maintain an optimal health status. If integrated into a telemedical
system, these systems can even alert medical personnel when life-threatening changes occur. In addition,
patients can benefit from continuous long-term monitoring as a part of a diagnostic procedure, can achieve
optimal maintenance of a chronic condition, or can be supervised during recovery from an acute event or
surgical procedure. Long-term health monitoring can capture the diurnal and circadian variations in
physiological signals. These variations, for example, are a very good recovery indicator in cardiac patients
after myocardial infarction . In addition, long-term monitoring can confirm adherence to treatment
guidelines (e.g., regular cardiovascular exercise) or help monitor effects of drug therapy. Other patients
can also benefit from these systems; for example, the monitors can be used during physical rehabilitation
after hip or knee surgeries, stroke rehabilitation, or brain trauma rehabilitation.
During the last few years there has been a significant increase in the number of various wearable health
monitoring devices, ranging from simple pulse monitors , activity monitors, and portable Holter monitors,
to sophisticated and expensive implantable sensors].
However, wider acceptance of the existing systems is still limited by the following important restrictions.
Traditionally, personal medical monitoring systems, such as Holter monitors, have been used only to
collect data. Data processing and analysis are performed offline, making such devices impractical for
continual monitoring and early detection of medical disorders. Systems with multiple sensors for physical
rehabilitation often feature unwieldy wires between the sensors and the monitoring system. These wires
may limit the patient's activity and level of comfort and thus negatively influence the measured results [9].

10
In addition, individual sensors often operate as stand-alone systems and usually do not offer flexibility and
integration with third-party devices.
Finally, the existing systems are rarely made affordable.
Recent technological advances in sensors, low-power integrated circuits, and wireless communications
have enabled the design of low-cost, miniature, lightweight, and intelligent physiological sensor nodes.
These nodes, capable of sensing, processing, and communicating one or more vital signs, can be
seamlessly integrated into wireless personal or body networks (WPANs or WBANs) for health
monitoring. These networks promise to revolutionize health care by allowing inexpensive, non-invasive,
continuous, ambulatory health monitoring with almost real-time updates of medical records. via the
Internet. Though a number of ongoing research efforts are focusing on various technical, economic, and
social issues, many technical hurdles still need to be resolved in order to have flexible, reliable, secure,
and power-efficient WBANs suitable for medical applications. My project paper discusses implementation
issues.
In this paper a general description of WWBAN architecture as well as prototype WWBAN designed
using Telos motes and application-specific signal conditioning modules. The prototype consists of several
motion sensors that monitor the user’s overall activity and an ECG sensor for monitoring heart activity.
This paper details our hardware and software platforms for medical monitoring, discusses open issues, and
introduces our solutions for time-synchronization, efficient on-sensor signal processing, and an energy-
efficient communication protocol.

11
CHAPTER TWO
2.0 LITERATURE REVIEW
During the last few years there has been a significant increase in the number of various researched work
on application of wireless sensor networks as a result of recent technology advances in integration and
miniaturization of physical sensors, embedded microcontrollers and radio interfaces on a single chip;
wireless networking; and micro-fabrication have enabled a new generation of wireless sensor networks
suitable for many applications. For example, they can be used for habitat monitoring, machine health
monitoring and guidance, traffic pattern monitoring and navigation, plant monitoring in agriculture, and
infrastructure monitoring. One of the most exciting application domains is health monitoring. A number of
physiological sensors that monitor vital signs, environmental sensors (temperature, humidity, and light),
and a location sensor can all be integrated into a Wearable Wireless Body/Personal Area Network
(WWBAN) .
2.1 HISTORY OF WIRELESS SENSOR NODE
History of the development of sensor nodes dates back to 1998 in Smart dust project [3]. Smart dust is a
hypothetical network of tiny wireless MEMS sensors, robots, or devices, installed with wireless
communications that can detect (for example) light, temperature, or vibration. Below is diagram of one of
the first wireless sensors designed in the School of Engineering and Applied Sciences, Harvard University
(Figure 1). This sensor is tagged Code Blue Wireless Sensor Mote and it is designed for health care, (i.e..
collection of vital signs from a patients body). One of the objectives of the project reported in this paper is
to create autonomous sensing and communication in a cubic millimeter. Though this project ended early
on, it has given birth to a few more research projects. They are Berkeley NEST and CENS. It was at this
period that the researchers involved in these projects coined the term 'mote' to refer to a sensor node.
Figure 1: Code Blue Wireless Sensor Node (Mote).
Traditional Health Monitoring Systems have been based upon using point-to-point real-time
videoconferencing connections between locations to replace in-person visits. Due to the cost and
complexity of the equipment, telemedicine contacts were mostly used for consultations between special
telemedicine centers in hospitals and clinics in the past. More recently, however, providers have begun to
experiment with telemedicine contacts between healthcare providers and patients at home to monitor
conditions such as chronic diseases. The approaches to home monitoring range from low-cost and easy to
use touch-tone telephone systems to more expensive systems that mimic the real-time videoconferencing
approach in traditional telemedicine and web-based systems that allow access to patient data from
anywhere an Internet connection is available. The telephone has proven to be an effective means of

12
monitoring congestive heart failure patients at home where patients enter their blood pressure, weight,
pulse, and symptoms into an automated answering system. The advantages of this system are the
telephone is a simple device that patients already know how to use, and telephones are inexpensive and
nearly ubiquitous. One disadvantage is difficulty in expanding the system to accommodate data that
cannot be easily entered by hand, or at least eliminating the manual data entry step as a source of error and
inconvenience. To address this need, some manufacturers of videoconferencing systems designed for
home telemedicine provide interfaces to various instruments, such as glucometers, blood pressure meters,
pulse oximeters, stethoscopes, and scales. The measured data are sent to providers using the data channel
in the H.32x videoconferencing standards. Videoconferencing using these units over Plain Old Telephone
Service (POTS) and higher speed lines has been shown to be useful in some cases. Although synchronous
videoconferencing with patients at home has been effective, asynchronous messaging could be more
convenient for routine monitoring and non-urgent questions. In recent times, the store-and-forward
sensing model has been noted to be more practical than videoconferencing because it eliminates the need
to schedule the telemedicine contact. This type of asynchronous sensor has also been extended to home
monitoring over the Internet. The system collects blood glucose levels in a PC application separate from
the web browser and transmits the data to the central storage server using TCP/IP over the Internet.
However, data collection is in an external application and the data are transferred using a separate FTP
server. Now developed is a system that bridges home monitoring via the web with patient-accessible
medical records and secure asynchronous messaging. The primary design goal of this system was to
streamline the process of adding data to patients’ medical records from various instruments that can be
used in the home. The task of acquiring data from an instrument, such as wireless sensors, and adding it to
their medical record should not require the user to open multiple applications and transfer data between
them. We present a system where all the resources required are embedded in a single device. This system
provides more information than a simple e-mail and to reduce the workload of physicians’ patient’s
management.
2.2 COMPONENTS OF WIRELESS MEDICAL SENSOR NETWORKS
Sensor Network Nodes used in health care are made up of the following components; microcontroller,
transceiver, external memory, power source and one or more sensors. The diagram below shows the
relationship between the components of a sensor node
Figure 2: Components of a Wireless Sensor Node.

13
MICROCONTROLLER: Microcontroller performs tasks, processes data and controls the functionality
of other components in the sensor node. Other alternatives that can be used as a controller are: general
purpose desktop microprocessor, digital signal processors, and application-specific integrated circuits.
Microcontrollers are most suitable choice for sensor node. Each of the choices has their own advantages
and disadvantages. Microcontrollers are the best choices for embedded systems. Because of their
flexibility to connect to other devices, programmable, power consumption is less, as these devices can go
to sleep state and part of controller can be active. In general purpose microprocessor the power
consumption is more than the microcontroller; therefore it is not a suitable choice for sensor node. Digital
Signal Processors (DSPs) are appropriate for broadband wireless communication. But in Wireless Sensor
Networks, the wireless communication should be modest (i.e., simpler, easier to process modulation and
signal processing tasks of actual sensing of data is less complicated). Therefore, the advantage of DSP’s is
not that much of importance to wireless sensor node.
TRANSCEIVER: Sensor nodes make use of ISM band which gives free radio, huge spectrum allocation
and global availability. The various choices of wireless transmission media are radio frequency, optical
communication (laser), and infrared. Lasers requires less energy, but need direct line of sight for
communication and are also sensitive to atmospheric conditions. Infrared, like lasers, need no antenna but
are limited in its broadcasting capacity. Radio Frequency (RF) based communication is the most relevant
that fits to most of the Wireless Sensor Network applications. WSN’s use the communication frequencies
between about 433 MHz and 2.4 GHz. The functionality of both transmitter and receiver are combined
into a single device know as transceivers are used in sensor nodes. The operational states are Transmit,
Receive, Idle, and Sleep.
EXTERNAL MEMORY: From an energy perspective, the most relevant kinds of memory are on-chip
memory of a microcontroller and FLASH memory - off-chip. RAM is rarely if ever used. Flash memories
are used due to its cost and storage capacity. Memory requirements are very much application dependent.
Two categories of memory based on the purpose of storage a) User memory used for storing application
related or personal data. b) Program memory used for programming the device. This memory also
contains identification data of the device.
POWER SOURCE :Power consumption in the sensor node is for the sensing, communication, and data
processing. More energy is required for data communication in sensor node. Energy expenditure is less for
sensing and data processing. The energy cost of transmitting 1 Kb a distance of 100 m is approximately
the same as that for the executing 3 million instructions by 100 million instructions per second/W
processor. Power is stored either in batteries or capacitors. Batteries are the main source of power supply
for sensor nodes. Namely two types of batteries used are chargeable and non-rechargeable. They are also
classified according to electrochemical material used for electrode such as NiCd (nickel-cadmium), NiZn
(nickel-zinc), Nimh (nickel metal hydride), and Lithium-Ion. Current sensors are developed with the
ability to renew their energy from solar, thermogenerator, or vibration energy. Two major power saving
policies used are Dynamic Power Management (DPM) and Dynamic Voltage Scaling (DVS) [5]. DPM
takes care of shutting down parts of sensor node which are not currently
used or active. DVS scheme varies the power levels depending on the non-deterministic workload by
varying the voltage along with the frequency.
(The Pacific Journal of Science and Technology –313– Volume 10. Number 1. May 2009 (Spring)
http://www.akamaiuniversity.us/PJST.ht

2.3 SENSOR NETWORKS
Fig 3: WeC (1999) Fig 4: Rene (2000) Fig 5: Dot (2001)
Exciting emerging domain of deeply networked systems
● Low-power, wireless “motes” with tiny amount of CPU/memory
● Large federated networks for high-resolution sensing of environment
Drive towards miniaturization and low power
● Eventual goal - complete systems in 1 mm3, MEMS sensors
● Family of Berkeley motes as COTS experimental platform
Fig 6: MICA (2002) Fig 7: Speck (2003)
2004 Matt Welsh etal – Harvard University, Steve Moulton-Boston University School of Medicine
The Berkeley MICA Mote
● ATMEGA 128L (7.3 Mhz 8-bit CPU)
● 128 KB code, 4 KB data SRAM
● 512 KB flash for logging
● 433 or 916 Mhz, 76.8 Kbps radio (100m max)
● Sandwich-on sensor boards
● Powered by 2AA batteries
Fig 8

15
Great platform for experimentation (though not particularly small)
● Easy to integrate new sensors & actuators
● 15-20 mA active (5-6 days on 2 AAs)
● 15 μA sleeping (21 years, but limited by shelf life of battery!)
2.4 TYPICAL APPLICATIONS
Vehicle tracking
● Sensors take magnetometer readings, localize object
● Communicate using geographic routing to base station
● Robust against node and radio link failures
Fig 9: Vehicle Tracking
Habitat monitoring – Great Duck Island
● Gather temp, IR, humidity, and other readings from bird nests on island
● Determining occupancy of nests to understand breeding & migration behavior
● Live readings at www.greatduckisland.net
Fig 10: Habitat monitoring – Great Duck Island
2.41 Potential Medical Applications

16
Real-time, continuous patient monitoring
● Pre-hospital, in-hospital, and ambulatory monitoring possible
● Replace expensive and cumbersome wired telemetry systems
Home monitoring for chronic and elderly patients
● Collect periodic or continuous data and upload to physician
● Allows long-term care and trend analysis
● Reduce length of hospital stay
Collection of long-term databases of clinical data
● Correlation of biosensor readings with other patient information
● Longitudinal studies across populations
● Study effects of interventions and data mining
Fig 11: Patient Monitoring
Mass Casualty Events
Large accidents, fires, terrorist attacks
● Normal organized community support may be damaged or destroyed
● Large numbers of patients, severe load on emergency personnel
Manual tracking of patient status is difficult
● Current systems are paper, phone, radio based
Sensor nets have potential for large impact
● Real-time, continuous vital monitoring
● “Electronic triage tag” to store patient data
● Immediate alerts of changes in patient status
● Relay data to hospital, correlate with pt. records

17
Fig 12: Mass Casualty Event Monitoring
2.5 Sensor Network Challenges
Low computatoinal power
● Current mote processors run at < 10 MIPS
● Not enough horsepower to do real signal processing
● DSP integration may be possible
● 4 KB of memory not enough to store significant data
Poor communication bandwidth
● Current radios achieve about 10 Kbps per mote
● Note that raw channel capacity is much greater
● Overhead due to CSMA backoff, noise floor detection, start symbol, etc.
● 802.15.4 (Zigbee) radios now available at 250 Kbps
● Not clear how much bandwidth available to applications
Limited energy budget
● 2 AA motes provide about 2850 mAh
● Coin-cell Li-Ion batteries provide around 800 mAh
● Solar cells can generate around 5 mA/cm2 in direct sunlight
● Must use low duty cycle operation to extend lifetime beyond a few days
Sensor Net Challenges
Radio connectivity is highly volatile!
● Packet loss not well correlated with distance
● Affected by receiver sensitivity, wall attenuation, antenna orientation, etc.
● Many links are asymmetric!

18
motelab.eecs.harvard.edu
Sensor Net Challenges
2.6 WIRELESS SENSOR NETWORK PROTOCOLS
While mainstream computers have an abundance of standards, the only official standards that have been
adopted for wireless sensor networks are ISO 18000-7, 6lowpan, ZigBee, Wibree, and Wireless HART
(WSN, Wikipedia). The network of the sensors that will be described in the course of this project will be
based on the Zigbee and IEEE 802.15.4 standards and protocols. ZigBee and 802.15.4-based networks
consist of many devices (mainly sensors) working together supporting sensing and control applications.
Several standards are currently either ratified or under development for wireless sensor networks. ZigBee
is a mesh-networking standard intended for uses such as industrial control, embedded sensing, medical
data collection, building automation. Zigbee is promoted by a large consortium of industry players i.e.
manufacturers of wireless sensors.

19
2.61 Overview of ZigBee Monitoring and Sensor Solutions
“As of October 2008, end user application solution commitments to deploy ZigBee-enabled solutions
topped 25.3 million units.”2
ZigBee technology is the standard of choice among other wireless technologies due to its efficient low-
power connectivity and ability to connect a large number of devices into a single network. ZigBee
technology uses the globally available, license-free 2.4GHz frequency band. It enables wireless
applications using a standardized set of high level communication protocols sitting atop cost-effective,
low-power digital radios based on the IEEE 802.15.4 standard for wireless personal area networks.
ZigBee uniquely offers low-latency communication between devices without the need for network
synchronization delays as required by Bluetooth®, for instance.
IEEE 802.15.4 defines robust radio PHY (physical) and MAC (medium access control) layers. ZigBee
defines the network, security and application framework for an IEEE 802.15.4-based system. These
capabilities enable a network to have thousands of devices on a single wireless network. ZigBee creates
robust self-forming, self-healing wireless mesh networks.
The ZigBee mesh network connects sensors and controllers without being restricted by distance or range
limitations. ZigBee mesh networks let all participating devices communicate with one another, and act as
repeaters transferring data between devices.
The ZigBee Alliance’s focus on the healthcare space has resulted in the development of the ZigBee Health
Care public application profile. ZigBee Health Care was designed for use by assistive devices operating
in non-invasive health care. ZigBee Health Care provides an industry-wide standard for exchanging data
between a variety of medical and non-medical devices. Public application profiles are agreements for
messages, message formats, and processing actions.
They enable developers to create interoperable, distributed application entities residing on separate
devices. These applications (written by the device manufacturer) send commands, request data, and
process commands and requests over the ZigBee network.
1 McCreadie & Tinker 2005
2 ZigBee Alliance Chairman Bob Heile’s October 2008 ZigBee Alliance Member Meeting Presentation

20
CHAPTER THREE
3.0 METHODOLOGY
Wearable systems for continuous health monitoring are a key technology in helping the transition
to more proactive and affordable healthcare. They allow an individual to closely monitor changes in
her or his vital signs and provide feedback to help maintain an optimal health status. If integrated into
a telemedical system, these systems can even alert medical personnel when life-threatening changes
occur. In addition, the wearable systems can be used for health monitoring of patients in ambulatory
settings . For example, they can be used as a part of a diagnostic procedure, optimal maintenance of
a chronic condition, a supervised recovery from an acute event or surgical procedure, to monitor
adherence to treatment guidelines (e.g., regular cardiovascular exercise), or to monitor effects of drug
therapy.
One of the most promising approaches in building wearable health monitoring systems utilizes
emerging wireless body area networks (WBANs). A WBAN consists of multiple sensor nodes,
each capable of sampling, processing, and communicating one or more vital signs (heart rate, blood
pressure, oxygen saturation, activity) or environmental parameters (location, temperature, humidity,
light). Typically, these sensors are placed strategically on the human body as tiny patches or hidden in
users’ clothes allowing ubiquitous health monitoring in their native environment for extended periods
of time.
A number of recent research efforts focus on wearable systems for health monitoring. Researchers
at the MIT Media Lab have developed MIThril, a wearable computing platform compatible with both
custom and off-the-shelf sensors. The MIThril includes ECG, skin temperature, and galvanic skin
response (GSR) sensors. In addition, they demonstrated step and gait analysis using 3-axis
accelerometers, rate gyros, and pressure sensors]. MIThril is being used to research human
behaviour recognition and to create context-aware computing interfaces]. CodeBlue, a Harvard
University research project, is also focused on developing wireless sensor networks for medical
applications. They have developed wireless pulse oximeter sensors, wireless ECG sensors, and triaxial
accelerometer motion sensors. Using these sensors, they have demonstrated the formation of adhoc
networks. The sensors, when outfitted on patients in hospitals or disaster environments, use the
ad-hoc networks to transmit vital signs to healthcare givers, facilitating automatic vital sign collection
and real-time triage .
C. Otto, A. Milenkovic, C. Sanders, and E. Jovanov 309
This chapter presents the methodology in describing a general WBAN architecture and how it can be
integrated into a broader telemedical system. To explore feasibility of the proposed system and address
open issues a prototype WBAN that consists of a personal server, implemented on a personal digital
assistant (PDA) or personal computer (PC), and physiological sensors, implemented using off-theshelf
sensor platforms and custom-built sensor boards was designed . The WBAN includes several motion
sensors that monitor the user’s overall activity and an ECG sensor for monitoring heart activity. The
hardware and software organization of the WBAN prototype is described.
The rest of the paper is organized as follows. Section 2 outlines the general WBAN architecture,
defines the role of each component, and describes its integration into a broader telemedical system.
Section 3 presents a case study, walking through a typical system deployment and its use. Section 4
describes the hardware architecture. Section 5 details the software architecture of the personal server
and sensor nodes, and introduces energy-efficient WBAN communication protocol. Section 6

21
concludes the paper and discusses possible future research directions.
3.1 SYSTEM ARCHITECTURE
The proposed wireless body area sensor network for health monitoring integrated into a broader multitier
telemedicine system is illustrated in Figure 13. The telemedical system spans a network comprised
of individual health monitoring systems that connect through the Internet to a medical server tier that
resides at the top of this hierarchy. The top tier, centered on a medical server, is optimized to service
hundreds or thousands of individual users, and encompasses a complex network of interconnected
services, medical personnel, and healthcare professionals. Each user wears a number of sensor nodes
that are strategically placed on her body. The primary functions of these sensor nodes are to
unobtrusively sample vital signs and transfer the relevant data to a personal server through wireless
personal network implemented using ZigBee (802.15.4) or Bluetooth (802.15.1). The personal server,
implemented on a personal digital assistant (PDA), cell phone, or home personal computer, sets up and
controls the WBAN, provides graphical or audio interface to the user, and transfers the information
about health status to the medical server through the Internet or mobile telephone networks (e.g.,
GPRS, 3G).
The medical server keeps electronic medical records of registered users and provides various
services to the users, medical personnel, and informal caregivers. It is the responsibility of the medical
server to authenticate users, accept health monitoring session uploads, format and insert this session
data into corresponding medical records, analyze the data patterns, recognize serious health anomalies
in order to contact emergency care givers, and forward new instructions to the users, such as physician
prescribed exercises. The patient’s physician can access the data from his/her office via the Internet
and examine it to ensure the patient is within expected health metrics (heart rate, blood pressure,
activity), ensure that the patient is responding to a given treatment or that a patient has been
performing the given exercises. A server agent may inspect the uploaded data and create an alert in
the case of a potential medical condition. The large amount of data collected through these services
can also be utilized for knowledge discovery through data mining. Integration of the collected data
into research databases and quantitative analysis of conditions and patterns could prove invaluable to
researchers trying to link symptoms and diagnoses with historical changes in health status,
physiological data, or other parameters (e.g., gender, age, weight). In a similar way this infrastructure
could significantly contribute to monitoring and studying of drug therapy effects.
The second tier is the personal server that interfaces WBAN sensor nodes, provides the graphical
user interface, and communicates with services at the top tier. The personal server is typically
implemented on a PDA or a cell phone, but alternatively can run on a home personal computer. This
is particularly convenient for in-home monitoring of elderly patients. The personal server interfaces
the WBAN nodes through a network coordinator (nc) that implements ZigBee or Bluetooth
connectivity. To communicate to the medical server, the personal server employs mobile telephone
networks (2G, GPRS, 3G) or WLANs to reach an Internet access point.

22
Figure 13: Health Monitoring System Network Architecture
The interface to the WBAN includes the network configuration and management. The network
configuration encompasses the following tasks: sensor node registration (type and number of sensors),
initialization (e.g., specify sampling frequency and mode of operation), customization (e.g., run
userspecific
calibration or user-specific signal processing procedure upload), and setup of a secure
communication (key exchange). Once the WBAN network is configured, the personal server manages
the network, taking care of channel sharing, time synchronization, data retrieval and processing, and
fusion of the data. Based on synergy of information from multiple medical sensors the PS application
should determine the user’s state and his or her health status and provide feedback through a user-friendly
and intuitive graphical or audio user interface.
The personal server holds patient authentication information and is configured with the medical
server IP address in order to interface the medical services. If the communication channel to the
medical server is available, the PS establishes a secure communication to the medical server and sends
reports that can be integrated into the user’s medical record. However, if a link between the PS and
the medical server is not available, the PS should be able to store the data locally and initiate data
uploads when a link becomes available. This organization allows full mobility of users with secure and
near real time health information uploads.
A pivotal part of the telemedical system is tier 1 – wireless body area sensor network. It comprises a
number of intelligent nodes, each capable of sensing, sampling, processing, and communicating of
physiological signals. For example, an ECG sensor can be used for monitoring heart activity, an EMG
sensor for monitoring muscle activity, an EEG sensor for monitoring brain electrical activity, a blood
pressure sensor for monitoring blood pressure, a tilt sensor for monitoring trunk position, and a breathing
sensor for monitoring respiration, while the motion sensors can be used to discriminate the user’s status
and estimate her or his level of activity.

23
Each sensor node receives initialization commands and responds to queries from the personal server.
WBAN nodes must satisfy requirements for minimal weight, miniature form-factor, lowpower
consumption to permit prolonged ubiquitous monitoring, seamless integration into a WBAN,
standards based interface protocols, and patient-specific calibration, tuning, and customization. The
wireless network nodes can be implemented as tiny patches or incorporated into clothes or shoes. The
network nodes continuously collect and process raw information, store them locally, and send
processed event notifications to the personal server. The type and nature of a healthcare application
will determine the frequency of relevant events (sampling, processing, storing, and communicating).
Ideally, sensors periodically transmit their status and events, therefore significantly reducing power
consumption and extending battery life. When local analysis of data is inconclusive or indicates an
emergency situation, the upper level in the hierarchy can issue a request to transfer raw signals to the
next tier of the network.
Patient privacy, an outstanding issue and a requirement by law, must be addressed at all tiers in the
healthcare system. Data transfers between a user’s personal server and the medical server require
encryption of all sensitive information related to the personal health]. Before possible integration
of the data into research databases, all records must be stripped of all information that can tie it to a
particular user. The limited range of wireless communications partially addresses security within
WBAN; however, the messages can be encrypted using either software or hardware techniques. Some
wireless sensor platforms have already provided a low power hardware encryption solution for ZigBee
communications.
3.2 CASE STUDY
In this section a hypothetical case study to illustrate the usefulness of my proposed system is presented.
The patient presented is fictitious, but representative of common issues a recovering heart attack
patient would face. The issues are analyzed, discussed and described how proposed system can be used to
both address the problem and provide advantages over typical present day solutions.
Adekola Juwon is recovering from a heart attack. After the release from the hospital he attended
supervised physical rehabilitation for several weeks. His physicians prescribed an exercise regime at
home. During the physical rehabilitation it was easy to monitor Juwon and verify he completed his
exercises. Sadly, when left to his own self-discipline, he does not rigorously follow the exercise as
prescribed. He exercises, but is not honest to himself (or his physician) as to the intensity and duration
of the exercise. As a result, Juwon’s recovery is slower than expected which raises concerns about his
health prognosis, and his physician has no quantitative way to verify Juwon’s adherence to the program.
My proposed health monitoring system offers a solution for Juwon. Equipped with a WBAN, tiny sensors
provide constant observation of vital statistics, estimate induced energy expenditure, and assist Juwons’s
exercise. Tiny electronic inertial sensors measure movement while electrodes on the chest can measure
juwon’s heart activity. The time, duration, and level of intensity of the exercise can be determined by
calculating an estimate of energy expenditure from the motion sensors. Through the Internet, his physician
can collect and review data, verify Juwan is exercising regularly, issue new prescribed exercises, adjust
data threshold values, and schedule office visits. Juwan’s physician need not rely on Juwon’s testament,
but can quantify his level and duration of exercise. In addition, Juwon’s parameters of heart rate
variability provide a direct measure of his physiological response to the exercise serving as an in-home
stress test. Substituting these remote stress tests and data collection for in-office tests, Juwon’s physician
reduces the number of office visits. This cuts healthcare costs and makes better use of the physician’s
time. In urgent cases, however, the personal server can directly contact Emergency Medical Services
(EMS) if the user subscribes to this service. Figure 14 illustrates one possible data flow.

24
Figure 14: Data Flow in the Proposed Healthcare Monitoring System
3.3 Hardware Architecture
In the spirit of the system architecture presented in Section 2, a prototype healthcare monitoring system is
designed. Figure 15 shows a photograph of the prototype components. The fully operational prototype
system includes two activity sensors (ActiS), an integrated ECG and tilt sensor (eActiS), and a personal
server. Each sensor node includes a custom application specific board and uses the Tmote sky platform]
for processing and ZigBee wireless communication. The personal server runs either on a laptop computer
or a WLAN/WWAN-enabled handheld PocketPC. The network coordinator with wireless ZigBee
interface is implemented on another Tmote sky that connects to the personal server through a USB
interface. For an alternative setting this paper presented a custom network coordinator that features the
ZigBee wireless interface, an ARM processor, and a compact flash interface to the personal server (Figure
15).
The Tmote sky from Moteiv acts as the primary embedded platform for all sensors in the system. Each
Tmote sky board utilizes Texas Instrument’s MSP430F1611 microcontroller and Chipcon’s CC2420 radio
interface. The microcontroller is based around a 16-bit RISC core integrated with 10 KB of RAM and 48
KB of flash memory, analog and digital peripherals, and a flexible clock subsystem.
It supports several low-power operating modes and consumes as low as 1 µA in standby mode; it also has
very fast wake up time of 6 µs. The CC2420 wireless transceiver is IEEE 802.15.4 compliant and has
programmable output power, maximum data rate of 250 Kbps, and hardware support for error correction
and 128-bit encryption. The CC2420 is controlled by the MSP430 microcontroller through the Serial
Peripheral Interface (SPI) port and a series of digital I/O lines with interrupt capabilities. The Tmote sky
platform features a 10-pin expansion connector with one Universal Asynchronous Receiver Transmitter
(UART) and one I2C interface, two general-purpose I/O lines, and three analog input lines.
The activity sensor, ActiS, consists of the Tmote sky platform and an Intelligent Activity Sensor (IAS),
implemented as a daughter card. The IAS monitors motion using two dual-axis accelerometers arranged to
provide three orthogonal motion axes (X, Y, Z). The IAS utilizes an on-board MSP430F1232
microcontroller for pre-processing and filtering of sampled data. The IAS connects to the Tmote sky

25
platform via the extension header and sends digital sensor data using a simple serial communication
protocol.
Figure15: prototype WBAN. from left to right:
the personal server with network coordinator ECG sensor with electrode, and a motion sensor.
Similarly, the integrated ECG and tilt sensor (eActiS) consists of the Tmote sky platform and an
intelligent signal processing module (ISPM). The ISPM is similar to the ActiS IAS board, but includes
a single-channel bio-amplifier for three-lead ECG/EMG. Electrodes are connected and placed on the chest
for monitoring heart activity. When the sensor is worn on the chest, it also serves as an upper body tilt
sensor.
3.4 Software Architecture
In this section I describe the software architecture of the prototype WBAN system, illustrated in Figure
16. It encompasses software modules running on the IAS/ISMP, the Tmote sky platform, the network
coordinator, and the personal server. Our focus has been on developing solutions for realtime on-sensor
processing, WBAN communications, time synchronization, maximizing battery life, managing data and
events, and an easy to use user interface. These issues relate to the lower tiers of the network, and as such
we describe our prototype software for the WBAN.
3.41 Sensor Node Software
The sensor node software samples and collects physiological data, analyzes the signals in real-time, and
transmits the results wirelessly to the personal server. In prototype this software runs on the Tmote sky
platform and custom application specific daughter cards. I have presented software for two types of
sensors. An Activity Sensor (ActiS) samples three-axis accelerometers to determine orientation, type of
activity (walking, sitting, etc.), estimates activity induced energy expenditure (AEE) based on an
algorithm proposed by Bouten, et. al., and performs step detection in real-time. An ECG and tilt sensor
(eActiS) monitors heart activity and samples a two-axis accelerometer for orientation (upper body tilt).
Sensor node and network coordinator software is implemented in the
TinyOS environment.

26
figure16:Block Diagram of Software Components in a WBAN.
TinyOS components
TinyOS is a lightweight open source operating system for wireless embedded sensors. It is designed to
use minimal resources and its configuration is defined at compile time by combining components from
the TinyOS library and custom-developed components. Well-defined interfaces are used to connect and
define the data flow between components. A TinyOS application is implemented as a set of component
modules written in nesC. The nesC language extends the C language with new support for task
synchronization and task management. This approach results in a natural modular design, minimal use of
resources, and short development cycles.
TinyOS fully supports the Tmote sky platform and includes library components for the Chipcon CC2420
radio drivers and other on-chip peripherals. Radio configuration, MAC layer communications, and generic
packet handling are also natively supported. Figure 17 depicts the ActiS software architecture using the
TinyOS component model. The components in yellow are those reused from the TinyOS library.
GenericComm provides generic packet handling and basic SendMsg, ReceiveMsg interfaces using TinyOS
messages. A TinyOS message is a generic message structure with a reserved payload for application data.
GenericComm would also interface to low-level platform specific TinyOS hardware drivers. The ActiS
application layer consists of custom components shown in blue.
Figure 17: Simplified sensor node interface connection (actiS).

27
Communication Protocol and Time Synchronization
The communication protocol was designed to minimize resources and uphold the spirit of the ZigBee
star network topology]. Figure 18 shows communication super frame. All communications are between a
sensor node and the network coordinator. Each communication super frame is divided into 50ms timeslots
used for message transmissions. Each sensor uses its corresponding timeslot to transmit sensor data,
command acknowledgements, and event messages. The first timeslot, however, belongs to the network
coordinator and is used for transmitting configuration commands from the personal server. The network
coordinator also transmits periodic beacon messages used to synchronize the start of super frames. This
organization also serves as practical collision avoidance, making more efficient use of the available
bandwidth when compared to using only CC2420 Collision Sense Multiple Access (CSMA) scheme.
Time synchronization is crucial in providing a means for network communication protocol, as well as for
event correlation. In the WBAN, sensor nodes are distributed about the user’s body and are only
wirelessly connected; the sensors operate for extended periods, sampling and analyzing physiological
data. It becomes necessary to correlate detected events between sensors within the sampling interval.
A time stamp mechanism can be employed; however, without a global time reference the timestamp
has no meaning outside of the scope of a sensor node. Synchronizing the session start times and
utilizing a local time reference is not sufficient for the problem at hand. Even if two sensors could
precisely agree on the start of a health monitoring session, a running local time would only work for
short session durations. Each sensor in the WBAN has a local clock source with an associated skew.
The skew is a measure of the difference in frequency between the local clock source and an ideal clock
source. As a result of skew, any elapsed time based on a local clock, over time, will differ between
any two sensors. This error is cumulative. Consider two 32 KHz crystals differing by a typical 50
ppm (parts per million). Over the course of a few hours, the sensor clocks can differ by more than
several hundred milliseconds. For an accurate healthcare monitoring system and correlating step and
gait analysis between two sensors this is unacceptable, while the optimization of communication
channel sharing would be impossible.
Figure 18: Communication super Frame and Activity of Sensor #2
This paper address the issue by employing a modified version of the Flooding Time Synchronization
Protocol (FTSP) developed at Vanderbilt University . FTSP generates time synchronization by
dynamically electing a master node. The master node transmits periodic beacons containing global
time stamps. FTSP features MAC layer time stamping for increased precision and skew compensation
with linear regression to account for clock drift. Modified FTSP is used for the paper prototype WBAN.
The modified version exploits the WBAN’s star network topology. Beacon messages, used to
delineate the super frame, also serve to distribute the global timestamps. Sensor nodes in the WBAN
use beacons as a timing reference. For testing of the time synchronization protocol, I developed a

28
test bed where the network coordinator and WBAN sensor nodes are all connected to a common wired
signal. Sensors measured the signal changes in jiffy ticks, where one jiffy is 30.5 µs, determined by
the clock frequency of the on-board crystal (32.768 KHz). In most cases the node’s error was within
±1 jiffy and the average error was approximately 0.1*Tjiffy or 3 µs.
Power Management
Long-life, persistent sensor nodes require efficient power management. Ease of use and the perceived
unobtrusiveness is affected by sensor weight, interval between battery changes, and the level of user
interaction required. Because battery life is proportional to battery size (weight) it is our challenge as
designers to minimize sensor power consumption and thus maximize battery life for a selected battery
size. In designing our prototype we have held low power consumption as a major design goal – both
in processor and technology selection as well as software organization. I have selected the MSP430
microprocessor family for their excellent MIPS/mW ratio and 802.15.4 in part because of its unique fit
for low power, low data rate applications. Beyond this, it is possible to extend each node’s lifetime by
clever network organization and making trade-offs between communication and on-sensor
computation.
Figure 19 ActiS current consumption during 5 seconds of operation. Red arrow marks one super frame cycle.
Power efficiency can be improved by noting that our wireless sensors consume approximately
22mA when the radio is active and about 1mA when the radio is disabled. Therefore, 95% of the
sensors power consumption can be attributed to wireless communications, but it is apparent from our
communication protocol that any given sensor node is actively involved in communications for only two
of the available timeslots (see Figure 19). For a one second super frame, the radio is utilized only
10% of the time. By disabling the radio during inactive timeslots, an average current consumption of
just 3.1mA can be realized, providing 7 times longer battery life.
Highly accurate time synchronization makes this possible. Between active time slots the radio

29
is disabled. Immediately before the beacon arrival time, a scheduled timer wakes the processor in
order to enable the radio. The beacon is received and then the radio is returned to a disabled state.
When a sensor’s scheduled timeslot arrives and queued events or data are waiting for transmission, the
radio can once again be enabled for transmission. Figure 19 shows the power profiles recorded for a
motion sensor using an environment for real time power monitoring
Figure 20: Battery life as a function of channel utilization
It should be noted that the super frame period and timeslot length directly affect power
consumption and battery life. Extending the period between beacons allows the radio to stay in low
power mode longer. This is not without cost, however. Extending the super frame period also
increases the maximum latency between sensor communications and increases the event reporting
latency. Every application will have a practical limit of the tolerable event detection latency.
Detecting a heart attack may be of little use if the sensor delays notification for up to one hour. For an
application specific maximum latency, system designers can make trade offs between battery capacity
(weight) and battery life. For prototype WBAN, a one second super frame period and 50ms
timeslots were selected, defining a one second maximum event latency and support for 20 nodes in the
network (19 sensors and one network coordinator). The chosen timeslot and super frame length will
effectively create a 5% utilization for individual sensors, as represented in Figure19. Smart
implementation, however, allows the radio to be disabled as soon as communications are complete –
even if the entire timeslot has not expired. In this sense, the timeslot length defines the peak channel
utilization for a sensor in the network. Figure 8 shows how sensor battery life can now be described as
a function of the type of battery and effective channel utilization.
Power consumption is also conserved by employing on sensor, real time signal processing.
Consider a modest WBAN consisting of two tri-axis accelerometers operating at a 200Hz sampling
frequency (16-bit samples) and an ECG sensor operating at 1000Hz (16-bit samples). The aggregate
data rate, or minimum bandwidth the system must support, is:
BW = 2 sensors × 200Hz × 3 axes × 16 + 1000Hz × 16 = 35.2kbps
Application bandwidth (radio utilization) directly influences power consumption. Eliminating raw

30
data transmission and instead transmitting pertinent events can save significant bandwidth, but
necessitates an event management scheme.
Event Management
In the WBAN prototype a sensor node generates an event when a characteristic feature has been
recognized. An event is described by event type, timestamp, and context-relevant data. An ECG
sensor processes raw ECG signal and detects R-peak event in QRS complex. A motion sensor can
detect step events, change in user orientation (sitting to standing), or AEE (activity induced energy
estimates) events providing a measure of exercise intensity.
Sensor node software is responsible for detecting the events in real-time. The current
implementation of the prototype supports R-peak detection using a modified version of the algorithm
presented by Pan, et. al. , and user activity (AEE) events based on an algorithm proposed by
Bouten, et. al. . ST segment processing can be implemented using an approach as presented by
Maglaveras [10] and Wheelock [23]. Step detection algorithms are still in development.
For a health monitoring WBAN such as ours, it is imperative that event data can be correlated
among the sensors in the distributed sensor network. Time synchronization addresses this issue. Each
event message contains a 32-bit timestamp in “jiffy” ticks indicating the precise event occurrence
relative to the start of a health monitoring session.
Figure 21 shows how events are processed in a WBAN. Events occur asynchronously relative to a
sensor’s designated timeslot and must be queued for transmission up to one super frame period (one
second for our WBAN). At the precise time of event occurrence, an event message with global
timestamp is constructed and the message is queued for transmission. When the sensor’s scheduled
timeslot arrives, all pending messages are transmitted. Currently, the project has implemented a redundant
data transmission scheme where each event message describes the current event and a previous event,
making the system somewhat resilient to packet loss errors. For particularly critical events, however,
an explicit acknowledgement is desired to ensure arrival at Personal Server. Each packet also includes
a unique frame sequence making it possible to retransmit event messages in the next timeslot if
necessary. This buffering mechanism is limited by available memory; for the Tmote sky platform, up
to 160 messages can be buffered. Although in practice, no more than 25 message buffers are needed
for the events of interest (heartbeat, steps, etc.).
Both the ActiS and eActis platforms require about 25 KB of flash memory for TinyOS and
program space and about 1.1 KB RAM for data and an additional 1.4 KB for message buffering (25
buffers with 56 bytes per message). It should be noted that changing the super frame period (discussed
in section 5) and increasing latency will also define the required number of message buffers for an
320 System Architecture of WBAN for Ubiquitous Health Monitoring
application. This yields 52% flash utilization and 25% RAM utilization for a sensor node
implemented on a Tmote sky platform.

31
Figure 21: Events are generated and queued for transmission during the sensor’s scheduled timeslot.
3.42 Personal Server Software
The Personal Server provides the user interface, controls the WBAN, fuses data and events, and
creates unique session archive files. The software is implemented in Visual Basic using Visual Studio
.NET 2003. It runs on either a Windows CE Pocket PC or a Windows PC. User archive files are
created in real-time using a custom binary file format, and are then converted to a Microsoft Access
database for off-line analysis. Based on our communication protocol and size of the super frame, we
can support as many as nineteen sensor nodes, although in practice our typical WBAN research
involves only three: two motion sensors and one heart rate sensor.
Figure 10 shows the message flow during a typical WBAN health monitoring session. The Personal
Server begins a health monitoring session by wirelessly configuring sensor parameters, such as sampling
rate, selection of the type of physiological signal of interest, and specifying events of interest. For
example, our ActiS motion sensors are capable of step detection if placed on the ankles, upper body tilt if
placed on the chest, and contribute differently to energy estimation depending on location. Sensors in turn,
transmit pertinent event messages to the personal server. The personal server must aggregate the multiple
data streams, create session files and archive the information in the patient database. Real-time feedback is
provided through the user interface. The use can monitor his / her vital signs and be notified of any
detected warnings or alerts.

32
Figure 22: Data flow in prototype WBAN
Graphical User Interface
User interface has been designed to address both the needs of the research prototype WBAN and support
a deployed WBAN system. The user interface must provide seamless control of the WBAN,
implementing all the necessary control over the WBAN. In designing the user interface the project
identified five design goals that the PS must support:
• Node Identification
• Configuration of sensors
• Calibration of sensors
• Graphical presentation of Events and Alerts
• Visual Real-Time Data Capture (oscilloscope-type function)
Any control or feedback capability provided to the user interface must be implemented using the
WBAN communication protocol. The protocol provides the tools enabling control of the WBAN and
defines what can and cannot be accomplished. We strived to keep a simple set of WBAN message
types and still implement complex user interface functions and application flexibility.
Sensor Node Identification, Association and Calibration
Sensor node identification requires a method for uniquely identifying a single sensor node to
associate the node with a specific function during a health monitoring session. For example, a motion
sensor placed on the arm performs an entirely different function than a motion sensor placed on the
leg. Because two motion sensors are otherwise indistinguishable, it is necessary to identify which
sensor should function as an arm motion sensor and which sensor should function as a leg motion
sensor. In order to make node identification user friendly and intuitive, the paper presented a scheme
taking advantage of the inherit motion sensing capabilities of each sensor. It let the user arbitrarily
place a motion sensor on his arm or leg, and then we are able to identify and associate the sensor with
the proper function through a series of easy to follow instructions. The form instructs the user to
“move the arm sensor” or in a denser WBAN, “move the left arm sensor”. This interface is more
intuitive from a user’s perspective, but was implemented using only WBAN protocol event messages
already implemented for event processing. While the user is moving the sensor, the PS broadcasts an

33
ACTIS_EVENT_MASKMSG requesting all sensors to report activity level estimations. Based on the
largest activity estimate returned, the PS can identify which sensor the user is moving and associate it
with the appropriate function.
The same message can also used be for configuration. Although the user interface presents these
as two distinct functions, they are implemented using the same message. Event mask messages are
also used to determine the degree of signal processing and the specific events of interest during a given
health monitoring session. This approach allowed us to minimize the complexity of the communication
protocol and still provide rich feature set to the application designer and user.
The Personal Server and ActiS nodes support two types of calibration. The first type is a sensor
calibration; its purpose is to accommodate sensor-to-sensor variations and the exact nature of the
calibration is sensor dependent. This is typically a one-time calibration and not expected to be a longterm
function of the user interface, but certainly necessary for sensor preparation. The second type of
calibration is a session calibration, required immediately prior starting a new monitoring session to
calibrate the sensor in the context of its current environment. For example, Activity sensors on the leg
might need an initial calibration of default orientation on the body.
Event Processing
The Personal Sever is solely responsible for collecting data and events from the WBAN. Each sensor
node in the network is sampling, collecting, and processing data. Depending on the type of sensor and
the degree of processing specified at configuration, a variety of events will be reported to the Personal
Server. An event log is created by aggregating event messages from all the sensors in the WBAN; the
log must then be inserted into a session archive file. The Personal Server must recognize events as
they are received and make decisions based on the severity of the event. Normally R-peak or heartbeat
events do not create alerts, and are only logged in the event log. However, the Personal server will
recognize when the corresponding heart rate exceeds predetermined threshold values. The Personal
Server can alert the user that his heart rate has exceeded the target range. In addition to the regular
status report in each super frame, the following events are currently supported:
• STEP (includes timestamp, step length, maximum forces)
• RPEAK – detection of heart beats using recognition of the R phase; the system generates a
precise timestamp and time interval between the current and a previous heart beat or R-R interval
(RRINT)
• Sensor Error (such as unexpected sensor reset)
• Force Threshold Exceeded - above normal accelerations (potential fall condition)
• User’s activity – AEE (one-second integration of the 3D motion vector)
• Triggered user’s activity – generates an event if the AEE exceeds a specified threshold.
Figure23illustrates a typical session and how WBAN protocol messages are used to calibrate
sensors, start a session, and receive events.

34
Figure 23: ActiS session initialization and event detection
Real-time Data Capture
Although all sensors in our system perform on-sensor processing and event detection, there are events
where processed and summary events are not sufficient and real-time raw signal capture is necessary.
During development, it was invaluable to be able to monitor sensor data in real-time. For heart rate
sensors we implemented a single graphical ECG trace; for motion sensors we implemented three traces
representing x, y, and z acceleration components on the same graph, as represented in Figure 21. This
captured data is also stored to a file and can be analyzed off-line to improve step detection algorithms.
In most cases, the algorithms were first developed on sample data sets previously recorded. When the
algorithms worked well on the sample data sets, they were then implemented on the embedded sensors
to run in real-time.
Even in a deployed system where intelligent sensors analyze raw data, process, and transmit
application event messages, there may be cases where it is necessary to transmit raw physiological data
samples. Such cases become apparent when considering a deployed ECG monitor. When embedded
signal processing routines detect an arrhythmic event, the node should send an event message to the PS
which will then be relayed to the appropriate medical server. The medical server, in turn, will provide
an alert to the patient’s physician. However, a missed heart beat can also be caused by electrode
movement. Therefore, it would be useful to augment this event with actual recording of the fragment
of unprocessed ECG sensor data. The recording can be used by a physician to evaluate the type and
exact nature of the event or to dismiss it as a recording artifact. In this case, the embedded sensor
willbegin streaming the real-time data to the personal server during a predefined time period. Figure 24
illustrates how a detected event can trigger a real-time data stream.

35
Figure 24: Arrhythmic event followed by real-time streaming data.

36
3.43: REFERENCES:
3. In Europe,” http://www.iiasa.ac.at/Research/ERD/DB/data/hum/dem/dem_2.htm , accessed:
January 1, 2013.
4. Hsiao, Chun-Chieh, etal., “Towards Long-Term Mobility in NTU Hospital’s Elder Care Center”,
IEEE 2011.
5. Dishman, Eric, http://aging.senate.gov/minority/public/index.cfm/files/serve?File_id=41dbba05-
bc2f-0d59-ea8f-b5ca6f4ed844, accessed on 1/13/2013.
6. Kumar, Pardeep, etall., “E-SAP: Efficient-Strong Authentication Protocol for Healthcare
Applications Using Wireless Medical Sensor Networks, Sensors 2012, 12, 1625 – 1647.
7. Townsend, K., et all, “Recent Advances and Future Trends on Low Power Wireless Systems for
Medical Applications, 2005 Proceedings, Fifth International Workshop on System-on-Chip for
Real-Time Applications, pages 476 -478.
8. Huo, Hongwei,et all, “An Elderly Health Care System Using Wireless Sensor Networks at
Home”, 2009 Third International Conference on Sensor Technologies and Applications.
9. Gaddam, Anuroop, and Subhas Chandra, “Elder Care Based on Cognitive Sensor Network”,
IEEE Sensors Journal, Vol. 11, No. 3, March 2011.

Biomedical application of wireless sensor 2

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Biomedical application of wireless sensor 2

Similar to Biomedical application of wireless sensor 2 (20)

Recently uploaded

Recently uploaded (20)

Biomedical application of wireless sensor 2