Finn Overgaard Hansen and Thomas Skjødeberg Toftegaard
Aarhus School of Engineering (ASE), Aarhus University, Aarhus, Denmark
Keywords: Pervasive Healthcare, Wireless Body Area Network (WBAN), Sensor Networks, Healthcare System
Architecture, Body Gateway, Body Area Network (BAN) Requirements.
Abstract: Wireless body area networks enable new opportunities for personal healthcare monitoring and personal
healthcare applications. This paper presents a comprehensive set of requirements and challenges for build-
ing a wireless body area network to support diverse user groups and a corresponding set of healthcare appli-
cations. Based on the identified requirements, the paper presents an architecture for a wireless body area
network and describes how this architecture is connected to an existing it-infrastructure supporting health-
care at home. Finally the paper presents our on-going research with development of an ASE-BAN test bed.
The major goal for this test bed is to be a platform for research and experiments with development of an ul-
tra-low power body area network including sensor, communication nodes, communication protocols and a
body gateway component.
There is a rising need for personal home healthcare
due to a growing population of elderly people (Patel
et. al., 2010) and (Wagner et. al., 2009). To support
the health problems of the elderly population wire-
less communication technologies have enabled new
types of applications for monitoring and controlling
people’s physical parameters.
The first generation of e-healthcare solutions
were more or less replacement of a wire with a wire-
less communication channel i.e. another set of pro-
tocols on top of the new physical communication
media. In the second generation the devices commu-
nicated wireless with a local system host, which re-
layed alarms and possible also data to remote sites.
In the third generation the measuring devices are
wireless connected to a mobile body area network
along with other sensors and actuator.
The development of successful body area net-
work (BAN) infrastructure, sensors and the support-
ing applications involves specifying a set of re-
quirement based on real-life problems of the elderly.
The current work in this field is mainly dominated
by a technology driven perspective but as the suc-
cess of these body near technologies depends very
much on user acceptance of the technologies we
suggest, to use a much more user focused and user
driven innovation process in the future research in-
cluding practical testing with real users using these
new inventions.
In this paper we will present a comprehensive set
of requirements for a BAN-system and the individ-
ual BAN components.
The proposed requirement are based on our cur-
rent work with architecture and network infrastruc-
ture for home healthcare in scope of the OpenCare
project (Wagner et. al., 2009). The focus has initially
been to create an it-infrastructure for connecting
single wireless healthcare sensors typically based on
Bluetooth. In this paper we extend the OpenCare
project with the description of development of a test
bed for a body area network called ASE-BAN.
The paper will first present a definition of ASE-
BAN requirements and based on these develop a
supporting ASE-BAN architecture.
This paper takes the perspective of the user, in
defining the functional requirement as well as the
non-functional system requirements.
More technical requirements are currently being
defined by the IEEE 802.15 WPAN Task Group 6.
(IEEE P802.15, 2008), which defines the require-
ments for a Wireless Personal Area Networks
(WPAN). A short overview of these requirements,
Overgaard Hansen F. and Skjødeberg Toftegaard T..
DOI: 10.5220/0003138601930199
In Proceedings of the International Conference on Health Informatics (HEALTHINF-2011), pages 193-199
ISBN: 978-989-8425-34-8
2011 SCITEPRESS (Science and Technology Publications, Lda.)
current challenges and wireless technologies for
BANs are presented by Patel (Patel et. al., 2010).
A supplementary proposal for technical require-
ments is presented by Drude (Drude, 2007).
There are numerous user scenarios for healthcare
applications (Drude, 2007). In this Section we will
present the four user scenarios we found most inter-
esting in relation to development of a BAN.
2.1 Health Monitoring
Health monitoring is about using technology to
monitor a person remotely and is one of the most
common usages of healthcare applications. An ex-
ample could be for heart diseases, where a sensor
will monitor the person’s ECG signal for detecting
heart arrhythmias, heart attach or for monitoring of a
person’s heart rate variability (HRV). Another typi-
cal scenario includes blood pressure measurements
with remote registration of measurements.
2.2 Closed Loop Applications
In a closed loop application an automatic regulation
loop is closed between a sensor and an actuator e.g.
a sensor measuring glucose level and automatically
controlling an insulin pump actuator. These types of
applications are yet not as common, as they require
very reliable systems and also a very strict approval
procedure from healthcare authorities.
2.3 Rehabilitation from Accidents
In a rehabilitation process after an accident, a per-
sonal healthcare system can give instructions for
exercises and monitor the performance and the pro-
gress. Users for this type of application could be of
all ages. A body area network used for computer
assisted rehabilitation is described by Joanov (Joa-
nov et. al., 2005). Computer assisted home training
have the opportunities to getting people quicker back
to a normal life and also to save the users time and
2.4 Empowerment of Elderly People
With the growing number of elderly and active peo-
ple, these types of application could in the future
help this group be active longer, stay in their homes
and thereby prevent hospitalization. It could be in-
teractive computer games or dedicated training pro-
grams which is controlled by feedback from the
BAN sensor nodes.
This section presents requirements for a wireless
body area network consisting of wireless network
nodes (called motes in Figure 1) and a body gateway
node connected to some kind of host server. The
motivation for this architecture will be given in Sec-
tion 4.
Body Area Network
Sensor A
Actuator B
Figure 1: Wireless body area betwork topology and
components: sensors/actuators, body gateway and host
Requirements in this section are mainly require-
ments which will have an influence on the system
architecture for the BAN and thereby not an attempt
to define a complete set of application oriented func-
tional requirements, which normally are defined
using the use case technique. First, the user related
requirements are described, followed by a set of
more general system requirements. Most of these
requirements have an impact on both the hardware
architecture and partly also on the software architec-
ture. A subset of these requirements is also listed by
Shnayder (Shnayder et. al., 2005).
3.1 User Related Requirements
3.1.1 Diverse User Group
We name the user of the BAN a citizen as a more
inclusive term than patient. Users of the BAN can
for example be elderly persons living at home or in a
nursing home, it can be physical disabled persons at
all ages, it can be persons suffering from dementia, it
can be persons with chronicle diseases at all ages
and it can be athletes. Some of these users have sev-
eral of these characteristics e.g. an elderly physical
disabled person with a chronicle disease.
HEALTHINF 2011 - International Conference on Health Informatics
We have in this way a very diverse user group
spanning from young to very old and in some cases
people suffering from dementia. These different
types of users have very different needs and differ-
ent skill levels for handling new technology, where
the user group with dementia and disabled people
raise the largest challenge for the healthcare devel-
opers. This leads to the first challenge:
Challenge 1: Dealing with very diverse types of
users, with different application needs and differ-
ent skill levels.
Requirements: Adjustable technology, user
friendly, easy installation and configuration of
software and hardware, easy to add new
functionality and sensors.
Development of a BAN system for this diverse
user group will benefit from using a user driven in-
novation and development process.
3.1.2 Citizen Communication
The BAN should support different ways of commu-
nicating with the user. It could be by messages, LED
lamps and sounds; it could be by speech syntheses or
speech recognition, by activating normal buttons or
soft buttons on a touch screen. Another possibility is
communication with hearing-aids or headphones.
Some of these devices can be used to give reminders
to the citizen e.g. a reminder to take medicine or to
exercise or to measure blood pressure.
Challenge 2: User interface design for a diverse
user group.
Requirements: User friendly and easy to use in-
This could be obtained by conducting usability
studies with different user groups and different types
of interfaces supported by incorporating industrial
designers in the design team and process.
3.1.3 Calling for Help
The BAN should support a “call for help” device so
a citizen can call help at any time. This functionality
could be supplemented with a voice-channel so the
caretakers can communicate with the citizen.
Challenge 3: To offer safety and security to citi-
Requirements: Physical design of a reliable call-
device and a reliable system for transferring this
event, as this could be an emergency call.
3.1.4 GPS Outdoor Positioning
The BAN should allow the connection of a GPS-
device for locating people in case of an accident. It
could for example be demented people who left the
nursing home without supervision or a citizen get-
ting a heart attack outside the home. As a GPS-
receiver is a power demanding device, the receiver
should be controlled by the BAN and the connected
system so it only works on demand and therefore
only use power in a short time frame.
Challenge 4: To locate a citizen in case of an ac-
Requirement: Outdoor navigation using GPS.
Ideally, indoor positioning is also relevant, how-
ever this is currently much more challenging and
not part of our current research scope.
3.1.5 Fall Detection
The BAN should support a fall detection device
node with the purpose of sending an automatic call
for help. It could be in situations where the citizen is
unconscious after a fall or it could be a person with
dementia, who couldn’t operate a call button or a
call device.
Challenge 5: Reliable detection of a fall.
Requirement: Physical design of a tiny and reli-
able fall detector node integrated on the person e.g.
in the cloth or in a belt.
3.1.6 Mobility
The citizen should be allowed to move freely around
that means for example a heart ECG monitoring
should take place indoors in a private home or at
work as well as outdoors and in public places.
Challenge 6: To be continuous and everywhere
Requirement: Seamless connectivity over hetero-
geneous networks with automatic roaming sup-
porting indoor as well as outdoor communication
over Wireless-LAN (WLAN) and WWAN.
3.1.7 Physical Constraints
for BAN Components
All the BAN components are connected with wire-
less technology and should be as integrated as possi-
ble in the person’s daily life. This raises specific
requirements for the physical design i.e. it should
have a very small form factor and be lightweight and
have a smart design.
Some of these devices requires skin contact and
could be integrated in a plaster; some could be inte-
grated in the cloth as an intelligent textile and some
should be visible e.g. a device with user interaction
for example integrated in the body gateway.
Challenge 7: Obtaining user acceptance of health-
care technology devices and wearing.
Requirements: Low form factor, low weight and
easy installation, wearing and a nice-looking de-
3.1.8 Power Consumption
With the diverse user group in mind it is difficult for
these users to handle battery exchange and charging
of a number of sensor nodes. For general conven-
ience the devices should be developed as ultra-low
powered devices with either long battery life or util-
izing some kind of energy harvesting energy neutral
technique. This leads to the architectural design with
only a single demanding unit – the body gateway.
Challenge 8: Low powered devices with low
power communication cost.
Requirements: There is a demand for ultra-low
powered devices (nodes) and communication pro-
The body gateway requires more power and
could be charged e.g. by an inductive way or by a
normal power charger with the inconvenience for the
user and problems with being offline.
3.1.9 Economics for a BAN
The technology can help reducing the workload with
care giving, but of course with a price – the cost of
the new healthcare technology. With the high vol-
ume of users there are strict requirements to the so-
lutions to be as cheap as possible both in buying,
installation and operation.
Challenge 9: Obtaining low total system cost and
operation cost.
Requirements: Low system costs, low communi-
cation costs, specific for the mobile communica-
tion part, which currently can be quite expensive.
3.2 General System Requirements
3.2.1 Security and Safety Issues
It is very important that both the BAN and the rest of
the infrastructure are both safe and secure. Personal
related information is normally regulated by national
laws and should be transferred in a safe and secure
manner. Another problem could be external hackers
which could threaten for example a close-looped
application connected to a medicine injection pump.
Personal related information is very sensitive and
confidential and a BAN sets strict requirements to
the handling of this information.
Challenges 10: Obtaining a safe and secure sys-
Requirements: Use of standard encryption tech-
niques and authentication protocols.
3.2.2 Healthcare Application Flexibility
The BAN should support the possibility to place the
application or business logic code on different places
in the architecture. It could be on a sensor node, on
the gateway or on one of the connected servers. Im-
plementing an application on a sensor node doing
pre-processing of the signal can reduce the commu-
nication bandwidth and thereby save power, but at
the cost of a more expensive sensor node.
Challenge 11: Obtaining a flexible software and
hardware architecture with different processing
Requirements: An adjustable SW-framework or
structure for application code and a flexible com-
ponent oriented hardware architecture.
An automatic configuration of the application
and sensor node software is a clear goal.
3.2.3. Monitoring Data Types
Data types can be real-time life-critical application
data: ECG data as well as sporadic event data for
example alarms and emergency call for help.
Challenge 12: Very diverse requirements for sig-
nal monitoring.
Requirements: Support for continuous real-time
monitoring as well as for sporadic events. See
(Patel, 2010) and (IEEE P802.15, 2008) for a
list of technical requirements for different applica-
tions with bitrates from less than 1 kBit/s for drug
dosage and up to 10 MBit/s for video imaging.
3.2.4. Citizen Identification
The BAN should support an identification mean so
the citizen can be unambiguous identified by sup-
porting systems and the identification can be send
with the collected data to remote servers.
Challenge 13: To obtain an unambiguous and se-
cure identification.
Requirement: A secure identification of the citi-
zen is required for the BAN system
HEALTHINF 2011 - International Conference on Health Informatics
3.2.5 Node and Person Matching
The BAN should support a mean for unambiguous
identification of sensor- and actuator nodes on a
given person and connect these devices with the
citizen’s identification code. In this way the sensor
data can be linked to a given person. The problem
occurs when a sensor node connects to nodes on
other persons BAN in near vicinity of the person.
Challenge 14: Matching nodes with the person
wearing the wireless node.
Requirement: For a secure and easy identification
This could for example be obtained by using
Body-coupled communication (BCC) where the
BCC is used to discover an identify sensor nodes on
the same body as presented in (Falck et. al, 2007).
3.2.6 Open Standards and Open Source
The BAN should be based on open international
standards for supporting as many BAN devices as
possible from different vendors and with different
types of functionality. The Continua Health Alli-
ance, a non profit coalition of more than 200 mem-
ber companies, has defined interoperability goals for
wireless systems (Continua Alliance, 2010) and the
(IEEE P802.15, 2008) group is working on an IEEE
standard for wireless personal area networks. The
Continua Alliance material and software are mainly
openly available for members of the alliance.
Challenge 15: Development of open standards for
the BAN.
Requirements: Open standards free to everyone
and optionally also open source software solutions
for BAN components.
3.2.7 Network Topology & Communication
The BAN should work with any kind of network
topology from a star network with bidirectional
communication between gateway and sensors or
actuators, to a meshed network that allows commu-
nication between all nodes. It is critical to have a
network infrastructure and related communication
protocols that minimize the power consumption of
this part of the BAN too.
Challenge 16: Design a network with ultra-low
power, secure and reliable communication.
Requirements: Support for star and mesh topol-
The overall design guideline for the ASE-BAN is to
have a powerful body gateway node acting as the
link to external systems i.e. the host server in Figure
1. and the Central Server or Home Base Station in
Figure 2. This body gateway should be the only
power demanding component with a longer commu-
nication range supporting both wireless LAN and
WWAN communication and with a seamless hand-
over between the two.
The other BAN-nodes should be ultra-low power
sensor or actuator nodes with a limited communica-
tion range less than one meter, where the communi-
cation power level can be adjusted to the minimum
required for getting a reliable on-body communica-
Figure 2 shows a proposal for a domain model
for a complete healthcare system showing the BAN
system which is mounted on the indicated citizen.
When the citizen is at home the communication will
be over WLAN from the body gateway and it can
typically send both alarms and monitored data from
the BAN to the home base station component, e.g. a
touch screen based computer.
If the citizen leaves his or her home the BAN
will automatically stop sending real-time monitoring
data and store them locally on the BAN gateway
component and only communicate alarms and keep
alive signals over the WWAN (e.g. GSM or UMTS).
Figure 2: System domain model including BAN.
This solution is previously proposed in
(Saadaoui, 2007), as it saves communication
cost i.e. both power and money. The principle of
having a Central Server and a Home Base Station is
implemented in the OpenCare project described in
(Wagner, 2009), where the BAN is described
as a Mobile Tier component for communicating a
single physical value from a citizen and not as being
a part of a body area network.
The idea of having a powerful gateway for the
body area network is also described in the work by
Janov (Janov et. al., 2005) and Otto (Otto,
2006), where they describe a three tier system con-
sisting of tier 1. WBAN nodes, tier 2. a Personal
Server and tier 3. Central Systems. On their WBAN
each node communicates in a star network with the
personal server i.e. the gateway. In our work we
have both a star and a mesh network as possible so-
lutions as a mesh configuration enables ultra-low
power communication. Another important differ-
ence, in relation to the work described in (Saadaoui
et. al., 2007), is the introduction of the home base
station component, which gives another level of ser-
vice to the citizens living in a private home; for eld-
erly people normally one or two persons. The home
base station collects monitoring data from the BANs
for the people living in the house and it also supports
shared and non-personal related healthcare devices
in the home, which assist the residents with staying
healthy. This could be a medicine dispenser automa-
ton, a blood pressure meter or a weight, which can
have one or more users. Using a home base station
enables development of healthcare applications
which takes decisions based on inputs from several
different input sources i.e. BAN sensors or from the
shared devices.
Another advantage with the WWAN enabled
body gateway is the extra security obtained by hav-
ing a backup channel for alarms in case of malfunc-
tions in the normal data flow from BAN, to home
base station to central server.
Figure 3: The ASE-BAN ECG Sensor module. The size is
13 mm x 18 mm x 30 mm. The weight is 6 g.
Figure 3 shows an example of a sensor node
used in the ASE-BAN test bed (Madsen et. al.,
2010) consisting of a sensor print with a digital sig-
nal processer connected in a sandwich structure with
a wireless radio print. This gives the flexibility to
experiment with different radio technologies and
components. In our further work we plan to develop
these modules in even smaller scales. Other exam-
ples of ASE-BAN sensor nodes under development
are a fluid balance sensor node for detecting dehy-
dration of elderly people and a fall detector node.
BAN nodes can be body worn sensors or actuators
as well as implantable medical devices (IMD) e.g. a
Our future research will experiment with different
Wireless radio technologies, mesh networks with
power efficient communication protocols and build-
ing a flexible hardware and software architecture for
both the body gateway and the sensor nodes. Cur-
rently we are developing a generic and flexible sen-
sor node platform, where different types of sensors
can be mounted together with different processor
types and radios. We are currently investigating the
body gateway platform, where we are looking on the
possibility of using a standard smartphone or alter-
natively develop an embedded body gateway.
This paper has defined a set of research chal-
lenges and corresponding set of relevant require-
ments for a BAN system to be used in healthcare
application. Based on these requirements a system
architecture proposal for an ASE-BAN has been
presented which is integrated with an infrastructure
in the home and with central servers.
ContinuaAlliance, 2010:
(on line, 2010-07-05)
Drude, S. 2007: Requirements and Application Scenarios
for Body Area Networks. 16th IST Mobile and Wire-
less Communications Summit, Budapest, 2007, pp.1-5.
Falck, T. et. al., 2007: Plug´n play simplicity for wireless
medical body sensors. Mobile Network Applications,
vol. 12. no.2-3, 2007, pp. 143-153,.
IEEE P802.15, 2008: Wireless Personal Area Networks,
TG6 Technical Requirements Document, IEEE P802.
Joanov, E., Milenkovic, A., Otto, C., C de Groen, P. 2005:
A wireless body area network of intelligent motion
sensors for computer assisted rehabilitation. Journal of
NeuroEngineering and Rehabilitation, 2005, Vol. 2,
pp. 6-16.
HEALTHINF 2011 - International Conference on Health Informatics
Madsen J. K., Karstoft H., Hansen F. O., Toftegaard T. S.,
2010: ASE-BAN – a Wireless Body Area Network
Testbed. EMERGING 2010, Florence, Italy, 2010, pp.
Otto, C., Milenkovic, A., Sanders, C., Jovanov, E. 2006:
System Architecture of a wireless body area sensor
network for ubiquitous health monitoring. Journal of
Mobile Multimedia. Vol. 1. No. 4, 2006, pp. 307-326.
Patel, P., Wang, J. 2010: Applications, Challenges, and
Prospective in Emerging Body Area Networking
Technologies. IEEE Wireless Communications,
Feruar 2010, pp. 80-88.
Shnayder, V., Chen, B., Lorincz, K. Fulford-Jones, T. and
Welsh, M., 2005: Sensor Networks for Medical Care.
Proceedings of the 3rd international conference on
Embedded networked sensor system. San Diego, USA,
2005, pp. 314-327.
Saadaoui, S., Wolf L. 2007: Architecture Concept of a
Wireless Body Area Sensor Network for Health Moni-
toring of Elderly People. 4th IEEE Consumer Com-
munications and Networking Conference, 2007.
CCNC 2007, pp. 722-726.
Wagner, S., Nielsen, C. 2009: OpenCare Project: An
Open, Flexible and Easily Extendible Infrastructure
for Pervasive Healthcare Assisted Living Solutions.
Proceedings of the 4th International ICST Conference
on Pervasive Computing Technologies for Healthcare,
London, 2010, pp.1-10.