Body Area Network PDF

Copyright 2004 Freeband AWARENESS project partners
Personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for creating new collective
works for resale or redistribution to servers or lists, or to reuse any copyrighted component of this work in other works must be obtained from or via AWARENESS
Project Management (http://awareness.freeband.nl).

D4.7: Modelling of Body Area Networks

From Technologi es to Model s to Components

Tom Broens, Aart van Hal teren, Val Jones, Boris Shi shkov, Ing Widya

{broens, hal t eren, j ones, shi shkov, wi dya}@ewi . ut went e. nl

Uni versity of Twente

December 2005

Freeband/ AWARENESS/ D4. 7
ht t p: / / awareness.f reeband. nl

Keywords: Body Area Network, Model, UML, SDBC
Abstract:
This paper describes a conceptual model of a Body Area Network (BAN). With this model we aim
to provide a design for BAN management functionality. We take a top down approach using
currently available modelling techniques. We develop higher level technology independent models
which are the basis for implementation. The final part describes a prototype using the BAN model
as foundation.

Freeband/AWARENESS/D4.7 2

1 Introduction
This paper discusses a conceptual model of a Body Area Network (BAN). In this section we start this
discussion by providing the motivation and scope of this research, and showing the structure of the rest of
this paper.
1.1 Motivation
Advances in computer technology (for example, increased processing power and memory, low cost and
miniaturisation of devices, explosion of types and number of applications) together with developments in
communication technologies (e.g. GPRS, UMTS), has resulted in almost universal dependency of
business and society on increasingly complex distributed systems. Additionally, wireless and mobile
technologies have brought ubiquitous access: today we may access all kinds of systems from anywhere
and at any time. To be able to manage the complexity of engineering and deploying these highly complex
distributed and heterogeneous systems, we need to apply sound software engineering principles at all
stages of the software lifecycle. One method for managing complexity and do reasoning is to capture the
design about it by using modelling techniques.
The AWARENESS project aims to exploit the evolutions in computer science and develops a service
infrastructure that supports context-aware and pro-active applications. Telemonitoring and teletreatment
applications are used to show the added value of context awareness. At the centre of telemonitoring and
teletreatment applications is the Body Area Network (BAN), which is a network of devices worn on, around
and/or in the body. Examples of these BAN devices are sensors, actuators, front-ends and communication
gateways.
Body Area Networks are complex systems which, for instance, deal with:
Reading, storing, processing and transmission of health data coming from sensors.
Control of actuators.
Configuration of BANs for particular patients.
Discovery of BANs, or BAN components, as they come online.
In the AWARENESS application infrastructure, we strive to help the application developer in creating m-
health applications that need BAN management functionality. To be able to robustly implement these
functionalities we need a model of a BAN as foundation.
A model is a simplified representation of a system that accounts for some of its known, inferred or
desired characteristics while purposely abstracting from other characteristics with the intent to
further study or define system characteristics [1].
This model should capture the invariants (i.e. never changing properties) of such a BAN to provide a
realistic and robust building block for application developers. In this paper we develop a BAN model which
is general enough for future developments, however, also practical enough to develop a useful building
block for the AWARENESS application architecture (see Figure 1). For further details on the application
architecture see AWARENESS deliverable D4.5 [2].

Container
Generic container
functions
Application
components
Domain specific
functions
Service infrastructure
Network infrastructure
BANManagement
Healthcare manager Healthcare customer
Healthcare
professional

Figure 1: BAN Management functionality in the AWARENESS infrastructure
The technology used to realize the AWARENESS telemonitoring and teletreament applications is an
evolution of the technology used in the MobiHealth project [3]. However, in the MobiHealth project the
configuration of a BAN took place at deployment time [4]. As a result, once a BAN was handed out to a
patient the configuration of sensors and other devices in the BAN was fixed and could not be configured at
runtime. In addition, the MobiHealth technology uses an XML schema (the latest version of this schema
can be found at: http://www.mobihealth.org/schema/BANDescription.xsd) that is closely tied to one specific
set of sensors available from Twente Medical Systems International (TMSi).
In previous AWARENESS deliverables (D4.2 [5]), we considered the MobiHealth technology and took a
practical approach to get some hands-on experience implementing a BAN configuration model for
AWARENESS. Given that experience, we now take a more rigorous approach in this paper by first
developing a model that will then be used to derive software components.
Summarizing, this paper describes a conceptual model of a Body Area Network (BAN). With this model we
aim to provide a design of BAN management functionality. We take a top-down approach using currently
available modelling techniques. We develop higher level technology independent models which are the
basis for implementation. The final part describes a prototype using the BAN model as a foundation.
1.2 Scope
The scope of this paper relates to the acquisition system used for collection of medical data from body
worn medical sensors. The purpose of the acquisition part is to enable remote monitoring and assessment
of patients by health care professionals. The patient assessment process can be analysed in terms of
tasks and resources [6].
In general, a healthcare professional assesses a patients condition by considering data collected from
different sources, by forming one or more hypotheses. By seeking further information (resources) the
doctor narrows the hypothesis set to achieve the clinical task in hand (arrive at a diagnosis). In face to face
consultations, initial data is gathered from observation of the patient, and consideration of the signs and
symptoms the patient presents with. This information may be augmented with measurement of vital signs
(e.g. ECG, EMG, EEG, temperature) or other physiological parameters and by ordering laboratory tests.
The data is taken together with the medical history of the patient (the doctor may take a history or consult
the patients health record, which may be an electronic health record (EHR), also known as electronic
patient record (EPR). If measurements are taken the required set of physiological measurements depends
on the clinical specialty and the task of the healthcare professional. This set contains coherent vital signs
which together form a unit of healthcare interpretation, suitable to check the diagnostic hypothesis of the
professional. That is, these signs may collectively indicate a certain medical condition of the patient. This

means that vital signs are in general (tightly) coupled and may have an order of importance when
determining a diagnosis. However, acquisition of vital signs does not need to consider this coupling
between signs. However, the acquisition of some of the components of a vital sign may be characterized
by dependencies between these components, for example in the case of acquiring the signals from the
several leads of an ECG.
Additionally, a patient may have multiple morbidities and may therefore be receiving treatment from
different medical specialists. Each specialty may require its own set of vital signs suitable as resources for
the medical tasks of that clinical specialty. Repeating vital sign measurement sessions for different
specialists is inefficient, if, as is often the case, there is overlap in the required sets of measurements.
Figure 2, expressed in information processors and information flows, elaborates the previously discussed
issues with a situation of a patient that is enrolled in three care programs: (i) Cardio-care of cardiologists of
a care centre, (ii) Epilepsy and (iii) Pain-treatment care programs of a rehabilitation institute which shares
an M-health portal with the care centre. The measured vital signs of the patient are for example ECG (5
leads), (s)EMG, Oxygen saturation (O2Sat), Blood pressure (BP), temperature and also the patients
physical activity (e.g. walking, lying). These measured data will be transferred to and optionally processed
at the M-health portal (left part of Figure 2). An m-health portal is a functional entity that transforms raw
vital signs to signs relevant for the task of the specialist. This corresponds with the concept of back-end
system used in the remainder of this paper (e.g. see Figure 7). When the specialist finds it convenient, he
can retrieve the appropriate sets of measurements to use as resources in his assessment tasks (right part
of Figure 2).

M-Health
Portal

5-ECG,
BP,O2sat,
BP, EMG
temperature,
activity -
movement,
activity movement
ECG (5leads), O2sat,
EMG, BP, temperature
pain-treatment-care:
<EMG, movement,..>
cardio-care:
atomic set :
<5-ECG, BP,O2Sat, ..>
cardiologist
vital signs
acquisition part
processing &
communication
shared vital sign
task-oriented part
specialty specific
task-oriented part
patient
epilepsy-care:
<3-ECG, EMG, movement>
neurologist
fysiotherapist
D4.7 scope

Figure 2: Acquisition of vital signs and vital signs as task resources [7].

To further elaborate the difference between the task and acquisition process, we show a vital sign
dependency model in Figure 3. This model reflects the different perspectives of vital signs: (i) the
acquisition perspective (left side) and (ii) the task-resource perspective (right side).


Figure 3: Vital sign dependency model [7].

At the right side of the figure, the class TaskResource represents the resources needed for a medical task
in respect of the care program (e.g. a diagnostic task of a cardiologist) [8]. The class t_VitalSignSet
represents the set of vital signs required as task resource and is a compositional aggregation (i.e. black-
diamond symbol at the association end-point) of the vital signs (t_VitalSign). At the left side of the figure,
the class a_VitalSignSet represents the set of measured vital signs of a patient, which possibly is enrolled
in several care programs. This class is a shared aggregation (white diamond symbol) since its existence
does not depend on the completeness of the measured vital signs, represented by the class a_VitalSign.
The association class Assignment specifies the filtering (i.e. the configuration makings) of vital signs that
are considered (not) relevant as resource for the specialists task of the care program. Refinements and
details of the UML class diagram shown in the figure can be found in [7].
The BAN model addressed in this paper focuses on the acquisition-oriented part of the model at the left
side of Figure 2 and is closely related to the classes at the left side of Figure 3. We consider BAN models
for the task-oriented part as future work.
1.3 Structure
The rest of this paper is structured as follows:
Section 2 presents three BAN application scenarios to get a feeling of the usage of BANS. The first
two indicate the role that BANs play in telemonitoring and teletreatment applications. The third
scenario indicates the subject of usage of our BAN model: configuration, instantiation and
management.
Section 3 gives a state of the art on BANs. It discusses the history of BANs and gives related work.
The final section presents our definitions of BAN terminology.
Section 4 discusses the business process modelling of BANs. This is the foundation for the further
software model to ensure that the application-to-be, based on the model, operates according to the
business environment in which it should be integrated.

Section 5 discusses the developed BAN model. It presents high-level UML models together with
some examples of instantiations based on the scenarios presented in chapter 2.
Section 6 presents the developed prototype based on the BAN model discussed in chapter 5.
Section 7 presents conclusions and future work.
2 BAN application scenarios
This section describes three scenarios that clarify the role of BANs in telemonitoring and teletreatment
applications. The first two (see section 2.1 and 2.2) show how BANs are used for monitoring and treating
patients (patient-centric view). While the last one (section 2.3) focuses on how professionals use BAN
(professional-centric view). Further, these scenarios are used as running examples throughout this paper.
The first two scenarios are adapted from the scope and scenarios from AWARENESS [9].
2.1 Telemonitoring scenario
Mr. Janssen is a 46-year-old man who suffers from epilepsy. Epilepsy is a disorder in which nerve cells of
the brain, from time to time, release abnormal electrical impulses; so-called seizures. Caused by his
illness, Mr. Janssen is unemployed, home-bound and has to make sure that someone is nearby to contact
a healthcare professional in case of a seizure.

Currently, Mr. Janssen wears a 24-hours seizure monitoring system (coined Epilepsy Safety System
ESS). This enables him to live a more normal life. He is wearing a body area network on which the ESS is
running. He attached sensors such that the ESS can measure his vital signs. Further, Mr. Janssen is
connected to the healthcare support network which can contact healthcare professionals.

Recently Mr. Janssen found a job to which he is travelling this morning. Suddenly, the ESS detects a
possible seizure. The ESS tells Mr. Janssen to stop his car at the side of the road. In this way, it provides
more safety to him and possible bystanders. Further, a healthcare professional is notified to start
monitoring his vital signs. Then Mr. Janssen experiences a severe seizure which the healthcare
professional is witnessing remotely. The system searches for available healthcare teams and directs them
to the location of Mr. Janssen such that they can help or even possibly safe his life.
2.2 Teletreatment scenario
Jitske is a 28 years old woman with serious chronic complaints in her neck and shoulder. After consulting
her specialist, she volunteered to take part in a new teletreatment programme. At a visit to the
rehabilitation centre she received the portable equipment. This means a Body Area Network which
consists of a garment with integrated sensors which can be invisibly worn under her clothes. A portable
computer is connected to these sensors and is able to collect the biosignals, to process them and to send
them to the rehabilitation centre. In addition Jitske gets continuously feedback about her health status and
how she should behave. It provides her with crucial information how to behave in the tight balance
between under activity and over activity which are both harmful may have negative consequences for her
experienced pain intensity level. At the rehabilitation centre, the specialists are able to monitor her health
status and to adapt her treatment according to her particular abilities and progress she is making.
2.3 BANs in practise scenario
Doctor Johnson is a general practitioner responsible for treating Mr. Janssen and Jitske. Therefore, he
collaborates with a neurologist to treat Mr. Jansen, and a rehabilitation specialist to treat Jitske. As
traditional treatment did not have the expected effect, both Mr. Jansen and Jitske are equipped with a
BAN. Before the BAN can be made operational, Dr. Johnson and the other specialists have to decide the
treatment plan. Based on the treatment plan, they have to determine the appropriate signs to monitor (i.e.
assignment, see Figure 3). For Mr. Johnson this is a 5-lead ECG and activity sensor and for Jitske this is a
4-lead EMG and activity sensor. This is modelled in a BAN template for epilepsy and chronic pain
monitoring. A nurse is instructed to position the sensors correctly on the patients body and activate the

acquisition system. Both the nurse and the doctor complement the corresponding template of the patients
disease with patient specific information (e.g. name, base heart rate etc). Remotely the monitoring session
can be started and stopped and the vital signs can be viewed. Also, the doctor can change the patient
specific parameters like increasing the sample frequency when it is needed for a better treatment.
3 State of the Art in Body Area Networks
This section gives a general overview of BANs. It discusses the history of BANs and BAN concepts as
used in this paper and AWARENESS in general. Section 3.1 discusses previous work on BANs and also
illustrates some of the different ways of defining BANs. Furthermore, it gives reasons for distinguishing
BANs from Personal Area Networks (PANs). Section 3.2 presents a description and definition of BAN
concepts as used in the AWARENESS project and in the remainder of this paper. Section 3.3 shows how
AWARENESS extends the work on BANs and the BAN service platform in new directions not addressed
by our predecessor, the MobiHealth project [3]. Section 3.4 discusses the reasons for applying a modelling
approach in the further development of Body Area Networks and the BAN service platform within the
AWARENESS project.
First, we show in Figure 4 a simple schematic diagram of a Body Area Network, illustrating that a BAN
consists of a number of communicating devices worn on the body. The devices within a BAN may be of
different kinds. As well as communicating among themselves, the BAN devices may communicate
externally, usually via wireless links.

Figure 4: a BAN is a network of body worn devices
3.1 Previous work on Body Area Networks
The concept of Body Area Networks (BAN) arose out of recognising the possibilities offered by combining
several technologies: short-range and long-range wireless communications, miniature wearable (or
pocketable) computing devices (PDAs and mobile phones) and other wearable devices such as MP3
players and medical sensors. Historically, the concept was first discussed under the topic of Personal Area
Networks (PAN) and only later distinguished by a separate term Body Area Network. The most important
communications standards for PANs and BANs are Bluetooth, the IEEE 802.11 Wireless LAN standard,
IEEE 802.15 Wireless Personal Area Network (WPAN) standard and Zigbee.
First it may be helpful to give a short explanation of Personal Area Networks. A Personal Area Network is a
network of devices which are used by an individual. The devices are fairly close to the person. A PAN is
usually taken to be wireless, although IEEEs qualification of Wireless PAN implies the possibility of wired
(or partially wired) PANs. A typical application of a PAN would be communication between the devices
someone might use in their (home) office, such as a computer, printer, phones and fax machine, wireless
audio, keyboards and mice. Several different definitions of PANs have been made. PANs may be defined
by (i) distance or range (some sources cite tens of feet, or even more specifically, 10m) or by (ii) bandwidth
(with PANs distinguished by having a lower data rate than WLANs) or by (iii) usage (a PAN is a network of
devices used by a person).
One problem with the first and second options for defining PANs (by range or bandwidth) is that the limits
are arbitrary or technology specific and new technologies will alter the boundaries. For example, with use
of UWB the prospect of high data rate PANs opens up, and the distinction between PANs and LANs
because of data rate blurs. The problem with the third way of defining PANs, that is by usage, lies in the

problem of how to define a persons ownership of devices, for example in a home or office where some of
the devices and appliances may be shared, leading to overlapping PANs.
BANS also relate to a single individual user but are in some sense smaller than PANs and relate to the
body of the user. In the next sections, we will see that there are also other ways of defining BANs.
Work at MIT and IBM
Zimmerman is credited with inventing the concept of Body Area Networks based on his work at MIT Media
Laboratory in collaboration with Mike Hawley and Neil Gershenfeld, and later at IBM [10, 11]. In [11] he
discussed the combination of portable computing devices and wireless short-range links as providing a
new paradigm for computing and communication. This article is about Personal Area Networks (PANs),
but he discusses combining devices worn or carried on the body with wireless personal area networks. In
one example of a PAN he refers to his work with Gershenfeld on a PAN which uses the body itself as a
wireless transmission medium for information. He says electronic devices placed on and near the body
modulate an electric field that induces small currents throughout the body. Communication between
individuals can be made by direct touch or by close proximity (within 2 m) and can be established through
touch or handshakes. In [10] he had already described one application of this technology namely the
exchange of electronic business cards via a handshake. He proposed that the PAN device be mounted in
a shoe. This solution provides low impedance paths from the device to the body and to the ground and
permits self-powering of the PAN by kinetic energy generated by walking. Zimmerman thus referred to
the concept of BANs as far back as 1996, without however using the term BAN. He gives the range of a
PAN as 10m (coinciding with the range of certain Bluetooth profiles).
Philips and Zigbee
Philips and other partners developed the Zigbee standard [12] to support low power, low cost, reliable
short range communications. Zigbee was intended to interoperate with IEEE 802.15.4 and was seen as
especially applicable for wireless sensor networks and control applications and for PAN and BAN
communications in general. Different groups within Philips have participated in PAN and BAN research in
the context of the WWRF and a number of projects including MobiHealth and BASUMA [13]. Range is
defined as 2m, to accommodate the tallest wearer! Philips are one of a number of companies who are
currently integrating BANs into clothing and bringing products to the market in the areas such as
entertainment and health monitoring (intelligent biomedical clothing) and for communication functionality
for specific industry groups (eg. Industrial Clothing Divisions ICD+).
WWRF
From the initiation of the Wireless World Research Forum in 2001, WWRF members, including Philips [14]
and University of Twente [15, 16] were working, amongst other things, on research into PANs. The
multisphere model of wireless communications in the first version of the WWRF Book of Visions [17]
showed PANS as the innermost sphere, nearest to the user. Work by Philips and University of Twente
brought the term BAN into the picture and the PAN-BAN distinction was introduced the following year into
the Book of Visions. There Jones and Bults defined a BAN as a collection of (inter) communicating
devices which are worn on the body, providing an integrated set of personalised services to the user [17].
University of Twente
Thomas Zimmermans definition related to the use of the body as a conduit for information. At the
University of Twente Jones et al proposed an alternative definition of a BAN: We see a BAN as a network
which is literally worn on the body, as opposed to a PAN (Personal Area Network) which links devices
close to the user but not necessarily (all) physically worn by him [18]. In other words, the wearer is the unit
of roaming. This pragmatic definition of a BAN relates only to physical location on the body, in contrast with
Zimmermans and others definition of a BAN as using the body as a transmission medium. Furthermore
we focus on BANs in healthcare applications since they provide the basis for total mobility for the patient.
In a PAN at least some of the devices are part of a fixed environment and therefore the user may only use
the PAN while they are in that environment. In a BAN all the nodes in the network are on the body of the
user, therefore the whole network moves around with the user.

An architecture for a generic BAN was developed prior to the start of the MobiHealth project. In [18] we
had described a BAN as consisting of a network of devices which, as well as a hub, might include
sensors, audio video devices and actuators. The hub, later named MBU (Mobile Base Unit), takes care of
computation and communication functions. Sensors measure some physical value (e.g. temperature or
pressure) whilst actuators have some mechanical or electromechanical effect (e.g. operating a pump or a
valve). In early modelling efforts this was expressed mathematically as:
BAN = pair(MBU, set(Device))
Device = Sensor | Actuator | MMDevice|
This has to be read as a BAN consists of an MBU and a set of devices, where Sensors, Actuators and
MM-device are sub classes of Device. This early definition of an abstract BAN hardware configuration
does not explicitly include communication channels.
The generic BAN concept was specialized for the healthcare domain to give the concept of a generic
health BAN. First applications explored were a trauma patient BAN, a paramedic BAN and a BAN for
homecare for patients recovering from trauma. These represent further specialisations of a health BAN.
This vision of BANs applied to healthcare applications was developed as concept before the beginning of
MobiHealth. Later the concept was realised in the form of a prototype system when the MobiHealth project
began in May 2002. Development of the BAN and supporting system by the University of Twente and
partners was followed by a number of specializations of health BANs for different clinical applications
during the course of the MobiHealth project [3, 8, 16, 19, 20].
Fraunhofer
Fraunhofer exhibited their BAN at CeBIT in 2002. They describe a BAN as a system which surrounds the
patient with an aura of data" [21] and define BANs as having exclusively wireless IntraBAN communication.
Body Area Network is standing for wireless communication between various components attached to the
body, such as data spectacles, earphones, microphones or sensors [22].
Medical applications include in-hospital telemetry for intensive care patients. The advantage there is to
avoid the inconvenience of wired systems which can get entangled when the patient moves in their sleep;
as well as being uncomfortable this can trigger alarms. Please see [23] for more information.
Other work
There is a huge literature on work related to BANs. Here we mention some interesting examples.
Over the past few years there has been much work in the healthcare domain on telemonitoring
applications using wearable communicating devices. Although in many cases these applications are similar
to Body Area Network not all of these developments make explicit reference to this term. In some cases
they refer simply to remote telemonitoring. Other related terms are: HAN (Human Area Networks), IBN
(Intra Body Networks) and as we have already seen, Zimmerman talked about Intra-Body Communication
in the context of PANs. These are not domain specific terms but in most cases healthcare is among the
application areas cited.
The term Intra Body Networks has been used (e.g.[24]) to mean a BAN where all the devices are
implanted and communicate wirelessly through tissue with an external PDA .
NTT used the term Human Area Networking to refer to the same concept as Zimmermans, namely body
worn networks using of the electric field emitted on the surface of the human body as a high-speed intra-
BAN transmission path [25]. Data is transmitted over the surface of the human body at speeds up to 10
Mbps between any two points on the body. The transmission starts as and when Extra-BAN transmission
paths are established via special transceivers, e.g. when the person touches a surface or device in the
environment carrying a transceiver. Transceivers can be embedded in doorknobs, appliances, floors etc. or
embedded in devices carried by the person. Thus the human body becomes a physical transmission path
within a human centric LAN (yielding another definition of PAN?). Example medical applications cited
include: Alert and contact records at medical, long-term care, and childcare facilities; and preventing a
patient accidentally taking the wrong medicine. If the user touches the wrong medicine pack, an alarm is
triggered on the terminal he is carrying.

These kinds of devices have been dubbed Wrist Ware, reminiscent of the so-called Wrist-Worn Device of
the AMON project, which could be described as an early specialty-specific body worn monitoring device for
cardiac patients and as such a precursor of health BANs. In AMON we see a body worn device which
incorporates several sensors into one device so it cannot strictly be called a BAN as no network is involved
(unless we include single node networks as networks).
Another group in Italy is working on a similar concept to MobiHealth and AWARENESS, focusing on
network and middleware layer support for sensor networks used for remote monitoring of mobile patients.
Information from a body worn sensor network is transmitted via an external network such as the patient's
domotic network to a hospital network [26].
A further networking innovation to consider in relation to BANs is Mobile ad hoc networking (MANETs).
(See the book by Conti referenced at [27]).
3.2 The AWARENESS Body Area Network
In AWARENESS, the starting point for Body Area Networks is the MobiHealth BAN system. Our initial
definition of a generic BAN in the AWARENESS corresponds and is: a network which is literally worn on
the body. Further, a BAN incorporates a set of devices which perform some specific functions and which
also perform communication, perhaps via a central controlling device. Devices may be simple devices such
as sensors or actuators, or more complex multimedia devices such as cameras, microphones, audio
headsets or media players such as MP3 players. The central controlling device (the MBU) performs
computation, coordination and communication functions. Communication amongst the elements of a BAN
is called intra-BAN communication. If the BAN communicates externally, i.e. with other networks (which
may themselves be BANs), this communication is seen (from the point of view of the BAN itself) as extra-
BAN communication" [28]. Figure 5 shows the architecture of the AWARENESS/MobiHealth BAN.
Figure 6 shows the components used in one of the MobiHealth BAN configurations, namely electrodes for
measuring ECG, an activity sensor and a sensor front end (the gray box). Here the MBU is implemented
on a PDA a Compaq iPAQ.

Sensors
Acfuofors
M8U
Exfro 8AM
communicofion
Infro 8AM
communicofion
8AM boundory

Figure 5: BAN architecture Figure 6: Some BAN components
The BAN operates in a service environment with two main categories of users: the patient users and the
professional users. Patients are equipped with Body Area Networks which are customized to their needs. A
patient wearing a BAN has a set of services available to them, varying with their current set of needs and
their clinical conditions(s). Some of the services may be transparent to the patient and fully automatic (e.g.
telemonitoring, automatic alarms) others are patient driven (e.g. patient initiated alarms). Some patients
may be unable to interact with the BAN at all (e.g. a patient with dementia or an unconscious patient).
Patients families and other members of their informal network of carers may also be involved but can be
classed as patient users. Patient BANs may have many different specialisations having different
functionality sets, hardware and applications.

The professional users are the consumers of BAN captured data such as biosignals and alarms. They may
be health professionals or other categories of professional care providers. The (health)
professional/(health)care provider interacts with their patients BANs via a client running on their own
professional system. The client gives access to BAN specific services. In future the health professional
systems may also exchange BAN data with the healthcare providers system such as a GP practice
administrative system or clinical information system (CIS) or a Hospital Information System (HIS), possibly
including linking to the EMR. The health professionals system may itself be a mobile system (e.g. running
on a laptop or PDA.) Services for professionals include access operations (e.g. retrieving and viewing
biosignals) but also control operations such as remotely activating a BAN, or a BAN device, or altering
sampling frequencies of sensors.
The BAN services are supported by a BAN server known as the Back End System. Together we refer to
the BANs and the Back End System as the BAN system.
The BAN system
A great many individual patient BANs and professional BAN systems may be in operation out in the field at
any time. These components are supported by a server which knows about management of BANs and
BAN applications and mediates between the patients and the professional users. We refer to this server as
the BAN Back End System BESys. Together the BANs and the BESys comprise a distributed system
which we refer to as the BAN system. Communication between the components is effected by
communications channels. At the most abstract level we do not distinguish further (e.g. into wired/wireless
channels). Figure 7 illustrates these components. The components to the right hand side of the dotted line
are in the domain of the healthcare provider and are outside the scope of the BAN system, but interface to
it.

Figure 7: Physical components of the BAN System and its interface to the healthcare service
provider domain.
In the next section we examine the main differences between the MobiHealth and AWARENESS projects
and show how AWARENESS addresses important aspects which were outside the research domain of the
MobiHealth project.
3.3 Innovation in AWARENESS BAN development
The objective of the MobiHealth project was to explore the potential of 2.5 and 3G technologies to support
useful mobile applications and services. It was therefore a communications project rather than an ehealth
project per se. Mobihealth chose to perform this exploration of 2.5/3G technologies in relation to the
domain of healthcare. The outcomes of the project included a prototype BAN (several variants for different
clinical applications) and a prototype system to support a population of BANs in the field. Several
Patient BANs

Health
Professionals
mobile systems
BAN
Back End System
(BESys)
Health
call
centre
Hospital
MBU
BAN System Access Systems
BAN

development cycles were completed and the system was used and evaluated by patients and health
professionals during a series of multi-centre trials. Development of end user applications was not an
objective of MobiHealth, although of course some application functionality had to be developed in order to
conduct the trials. In contrast the AWARENESS project aims to research and design a service and network
infrastructure to support context-aware and proactive mobile applications. In relation to further
development of BANs and the BAN system, the AWARENESS project goes beyond the goals of
MobiHealth by:
focusing on application development rather than on wireless communications.
adding context awareness to enable intelligent applications.
extending the portfolio of clinical applications to include epilepsy, spasticity and management of
chronic pain.
addressing not only telemonitoring but also teletreatment.
re-engineering with attention to software engineering methodologies utilizing modelling.
In the next section we examine the motivation for the use of modelling in AWARENESS.
3.4 Motivation for the use of modelling
The modelling activity described in this paper is part of the systematic software engineering methodology
being applied in AWARENESS. The use of modelling in design and development is aimed at making the
design process clear, formal, explicit and transparent such that high quality components may be designed
and integrated and so reuse may be facilitated. High-level modelling at an abstract level allows a generic
design and architecture to be developed. High-level models may then be refined towards conformant
implementations. The high level design, because it is a technology independent model, is also intended to
be future proof and to be re-used in future evolutions of the BAN and BAN system. Modelling also enables
reasoning about the design in a platform independent way and formal expression of designs enables
testing of equivalence between the models and the many possible implementations now and in future,
even if different technology platforms are used. The following sections describe our BAN modelling efforts.
The scope of the modelling effort in this paper is the BAN, specifically the acquisition system. However we
first discuss the overall system and the business model.
4 Business Process Modelling
Among the challenges concerning current application development is the (frequently observed) mismatch
between the original (business/user) requirements and the actual functionality of the delivered application
[29]. We actually observe two opposite phenomena [30]: either software is designed without prior adequate
consideration of the business processes to be supported by it, or business-modelling-driven software
specification takes place where the business modelling output is inadequately transformable into an input
for the specification of software.
Therefore, the two tasks: the business process modelling and the specification of applications for the
support of the business processes, need to be better aligned. They should be considered as one
integrated task [31].
This is particularly valid for the modelling of Body Area Networks (BANs). Since, as discussed in previous
chapters, a BAN comprises hardware, software, netware, and middleware aspects which are to be
coherently reflected in models that are consistent with the BANs business environment.
For brevity, we will not discuss in detail some hardware/netware/middleware issues (we will refer readers
instead), putting the stress on the essential BAN-related challenges in specifying the BAN software-driven
automation.
Therefore, this section will firstly elaborate on the difference between business process modelling and
software specification (section 4.1), secondly consider a relevant business-software alignment approach
(section 4.2), and finally we will build a business process model of the BAN, using that approach (section

4.3), and reflect it (on high level) in corresponding (BAN-related) functional blocks (section Error!
Reference source not found.).
4.1 Business Process Modelling and Software Specification
It is widely acknowledged that:
business process modelling is about the business context in which the software application-to-be
would operate.
software specification is about the functionality of the application.
Both these aspects are usually considered from three perspectives, namely structure, dynamics, and data:
What are the statics of the system under study (entities and their inter-relationships)?
What are the dynamics of the system under study (the events flow)?
What are the data types and instances concerning the studied system?
However, software systems are not as simple as they were 10 years ago and it is therefore essential to
properly integrate them within the broader business context. In order to achieve this, we need a sound
business process modelling background. With respect to this, we argue that the semantic and pragmatic
richness of a business system could not be grasped just by considering entities, events, and data.
Information, for example, is insufficient as a modelling notion since usually meanings are based also on
signs [32]. Consider a bank note. It is actually more than just coloured paper with digits on it. It stands for a
persons ability to pay, for the authority of an issuing institutions, and so on. Thus, reflecting only the
information would lead to significant loss of modelling representativeness.
Further, the way in which entities relate to each other in reality is also much more complex than often
modelled. The Semantic Analysis Method [32] indicates on this and relates agents/roles on the basis of
their affordances (this is a term coined by Gibson [33], which indicate the characteristics of an object or
device that present its uses) abilities of conducting particular behaviour patterns. To illustrate: a book
affords to be borrowed (in the context of a library). We have a potential for a behaviour pattern. If realized,
it creates other such potentials a borrowed book affords to be returned. And again, if we follow modelling
steps that lead to oversimplification of such issues, we would ignore, for sure, essential information
concerning the business context.
And finally, the language and actions should be grasped adequately. We argue that language is not only
used for exchanging information, as in reports, for example, but also to perform actions, as in promises
and orders, for instance [34]. If we consider the delivery of a pizza to a client, it is obvious that it is
insufficient capturing only the fact that a pizza has been delivered; it actually might be that negotiations had
taken place prior to this fact: We are closing now, only Prosciutto is possible, is that OK?; Yes, it is OK;
Here we go, this is your pizza; No, Sir, in my opinion it is insufficiently baked, could you put it for several
more minutes in the oven?, and so on. Hence, we cannot oversimplify such issues because our
application would need to adequately operate in a business environment.
For this reason, we consider also the so called Communication perspective which is about the
semantics, pragmatics, and related communication actions. This perspective concerns the business
process modelling and (although) partially - the software specification. In software systems, we have rules
rather than real-life communication. However, in order to adequately base a software specification on a
business process model and also to allow for a proper integration of the application-to-be in its
corresponding business environment, we have to keep (even in our software specification and realization)
attention on the semantic/pragmatic/communication aspects, as above discussed. All this is summarized in
Figure 8:


Communicaton
Perspective

Structural
Perspective

Dynamic
Perspective

Data
Perspective
S o f t w a r e s p e c i f i c a t i o n l a y e r

B u s i n e s s P r o c e s s m o d e l i n g l a y e r

Figure 8: High-level modelling perspectives [30]
About the software specification layer, we have one additional perspective, however. This perspective
does not concern the business process modelling background and for this reason is not depicted in the
figure above. It is the Realization perspective (user requirements and design constraints).
Further, taking a slightly different vision on the Business process modelling layer, considering it as
concerning the environment of the application-to-be rather than a source of deriving its structure and
behaviour, we identify another perspective, namely the Business context perspective. Hence, we arrive at
Figure 9 that depicts the specification viewpoints of a software (application) component.
software
application/component
statics
dynamics information
communication
realization context

Figure 9: Specification viewpoints of an application component
Our viewpoints are thus:
Statics: entities and their interrelationships.
Dynamics: events flow, provided/required interfaces with constraints and coordination-related
aspects.
Information: semantics, statics, and dynamics of information the component deals with.
Communication: related communication actions which concern semantic and pragmatic aspects.
Realization: user-defined requirements and technology (project-driven) constraints.
Context: purpose, scope, and policies of the system in context as well as issues on integration of
the application-to-be in its business environment.
The viewpoints Information and Context are marked because we present them in a way which is
consistent with the way in which ODP considers the so called Information and Enterprise viewpoints,
respectively. However, in addition to our perspectives, ODP considers also implementation-related
perspectives. For this reason, the Engineering and Technology viewpoints in ODP partially overlap with
the Realization viewpoint on Figure 9. Hence, for the purpose of this paper, we propose to consider an
integrated realization + implementation modelling layer that addresses: the issues specified in the

Realization viewpoint on Figure 9; the distribution of system components (if we view our component as a
system); the implementation mechanisms and constraints.
Therefore, we propose the following viewpoints in the paper:
Business process modelling viewpoint.
Statics viewpoint.
Dynamics viewpoint.
Information viewpoint.
Realization & Implementation viewpoint.
Actually, because of their indirect influence on the software specification activities (Figure 8), the
communication aspects have their indirect effect within the business process modelling viewpoint; thus, we
have put together context and communication, forming a Business process modelling perspective. This
is illustrated in Figure 10:
c o m p o n e n t
dynamics
realization & implementation
information
business process modeling
statics

Figure 10: Viewpoints - the AWARENESS ODP-driven view
The Business process modelling viewpoint is highlighted because it is being addressed in the current
section. As already discussed, in a business process study, we would provide structural/dynamic
/factual/communicative elicitation regarding the environment in which the application-to-be is to operate.
The Static viewpoint as well as the Dynamics viewpoint and the Information viewpoint are highlighted as
well because, by considering at the business process modelling level the statics, dynamics, and
information aspects, we would achieve the actual foundations of the software application-to-be.
Information is not bold on the figure, indicating that we will not elaborate on information modelling aspects
in this paper. The reason is that another AWARENESS deliverable is eliciting this [35]. A possible
approach for accomplishing this is the SDBC approach. It is going to be considered in the following section
as the approach of our choice not only because it soundly aligns business process modelling and software
specification, but also because of its consistency with current relevant design methods and techniques,
referred to as 'Generative Programming (GP) [36].
4.2 The SDBC Approach
The SDBC approach concerns a business process-modelling-driven software specification; SDBC stands
for Software Derived from Business Components. Introducing the approach is beyond the scope of the
current paper; for information about SDBC interested readers are referred to [30]. Nevertheless, we will
just mention the 4 essential SDBC fundaments:
Integrated view over business process modelling and software specification.
Business process modelling embracing the communication perspective (see the previous section).
Component-based business-software alignment.

Re-use.
However, we will use SDBC only partially in our current work. We will benefit from the approach, in
particular, in building up a sound foundation for the further application design (addressed in the following
section). We will briefly present the approach outline below.
Outline of SDBC
The outline of SDBC will be presented with the help of Figure 11. We have used the following
abbreviations there: bc Business Component (a business sub-system that comprises exactly one
business process); bk Business CoMponent (a model of a Business Component, which is elaborated in
terms of structure, dynamics, communication, and data); glbk general Business CoMponent (which is re-
usable by extension); gcbk generic Business CoMponent (which is re-usable by parameterization); ssm
software specification model; sc Software Component (an implemented piece of software, representing a
part of an application); sk Software CoMponent (a conceptual specification model of a Software
Component). For more information on these concepts, the reader is referred to [37].

Figure 11: The SDBC approach outline [30]
The figure shows that SDBC is about a business-process-modelling-driven specification of software. The
starting point is a consideration of a business system. Business Components are identified from it. This is
done by applying an OS-driven analysis [32] leading to the derivation of the so called SCI modelling
output [30, 31]. The Business Components should be then reflected in corresponding Business
CoMponents, in supplying an adequate modelling foundation for the further software specification
activities. Another way for arriving at a Business CoMponent is by applying re-use: either extending a
general Business CoMponent or parameterizing a generic Business CoMponent. DEMO [38] and other
LAP-driven modelling tools [34] are relevant as far as Business CoMponents are concerned. Each
Business CoMponent should be then elaborated with the domain-imposed requirements, for the purpose of
adding elicitation on the particular context in which its corresponding Business Component exists within the
business system (from which it has been identified). Then, a mapping towards a software specification
model should take place, driven by a DEMO-UML transformation mechanism [29, 30]. The mentioned
requirements as well as the user-defined requirements are to be considered here, since the derived
software model should reflect not only the original business information but also the particular user
demands towards the software system-to-be. The (UML-based) software specification model [39] would
then need a precise elaboration so that it provides sufficient elicitation in terms of structure, dynamics,
data, and coordination [31, 37]. The model needs also to be decomposed into a number of Software
CoMponents reflecting functionality pieces. Then these Software CoMponents are to undergo realization
and implementation, being reflected (in this way) in Software Components. The final set of components
might consist of such components which are implemented (using software component technologies, such

as .NET or EJB, for instance) based on corresponding Software CoMponents and (possibly also) such
components which are purchased. Finally, the (resulting) component-based application would support
informationally the target business system, by automating something that concerns the initially considered
Business Component(s) identified from the system.
Modelling process
We will partially re-use the design trajectory proposed in [30], according to which:
We first conduct an information structuring and requirements study.
On this basis, we identify a multi-aspect Business CoMponent; in our case this would be the BAN
Business CoMponent elaborated just in terms of structure and dynamics.
We elaborate these (in our case structural and dynamic) business process models with the user
requirements (which often do not relate directly to the business modelling foundation) and the
design constraints (which are usually project-driven).
We reflect these inputs (the business process modelling input, the requirements input and the
design constraints input) in the derivation of corresponding software specification models, in this
case these are to be static and dynamic software specification models; however, since such
behavior aspects are considered by AWARENESS and A-Muse together (in studies on aligning
SDBC and ISDL), we are going to address in this paper just the software specification statics,
which would be expressed in the notations of UML (see the next chapter).
An finally, we face the realization and implementation (Chapter 6).
4.3 Modelling the BAN
Following SDBC, and relying also on other relevant theories and tools, such as DEMO, Petri Net, LAP,
Semantic Analysis, and so on, we will apply the above outlined modelling process, by limiting ourselves to
just the identification of the BAN Business CoMponent, elaborated in terms of statics and dynamics.
Hence, our first task is to identify roles as the output of our initial business/requirements analysis.
Roles
We identify user roles and technology roles. The user roles include Patient and Carer. Carer includes
Health Professional (further categorised as doctor, nurse etc) and Informal Carer. Figure 12 shows
possible distributions of user roles related to the high level system components shown in Figure 7.


Figure 12: Business User Roles
We can see from Figure 12 that at certain times the health professionals may be co-located with the
patient (eg a home visit by a nurse) or they may be monitoring their patient remotely, either from a fixed
healthcare location such as a hospital, or when they are on the move and equipped with a mobile system.
The User roles and some of the associated functionalities are listed below.

User roles:
Patient (be monitored, start BAN, stop BAN, press alarm).
Nurse (fit BAN(co-located), verify operation of BAN, view BAN data (co-located or remotely
located), start BAN, stop BAN, press alarm).
Doctor (fit BAN (co-located), verify operation of BAN, view BAN data (co-located or remotely
located), start BAN, stop BAN, press alarm).
Other carer (e.g. informal carer) (start BAN, stop BAN, press alarm).
We can also identify roles associated not with human actors but with different elements of the technology.
Technology element roles:
Data acquisition (BCDSs).
E.g. Biosensors measuring physiological measurements from patients body.
E.g. Positioning devices registering location info from external source.
Data store (MBU).
Data management (MBU).
Signal Processing (Mobi).
Signal conditioning: ADC, sampling, filtering.
Signal synchronization (Mobi or MBU?).
Processing (MBU).
BAN
Back End System
(BESys)
Health call
centre
Hospital
MBU
Doctor Patient Nurse Informal
caregiver

Signal interpretation (e.g. auto detect pattern indicating emergency) (running on MBU).
Encryption.
User application functions.
(For Local application functions - see user manual).
Local feedback of info to patient or co-located carer (eg nurse, family member).
E.g. Signal viewer (viewer application on BAN).
Alarm ..
Communicate with remote network (extra BAN) (MBU)
(see BANIP (BAN Interconnect Protocol)).
Communicate locally (intra BAN) (MBU, Mobi, BCDSs).
Hence, we identify the essential BAN role types as follows:
1. Patient.
2. Carer an aggregated role type (doctors, nurses, and other carers have the same attitude towards the
BAN).
3. Data acquirer gets vital sign data and location data, delivering it for further processing.
4. Data acquisitor biosensors measuring physiological measurements from patients body, and the
corresponding sampling.
5. Locator positioning, registering location information from external source.
6. Processing Unit processing the data (which is delivered by the Data Manager) and also adding user
management and security aspects.
7. Synchroniser synchronizing the processed data.
8. Interpreter responsible for the delivery (to the Carer) of appropriately interpreted data concerning the
Patient.
The first two role types are of course external for the BAN. The other 6 role types are shown on the Figure
13:
R o l e
types
D.NANAGER
manage and control data
D.ACQS-TOR
measuring 8 sampling

* signal processing
* encryption
* user management
SYNCHR-ZATOR
synchronize data
PR. UN!T
!NTERPRETER
* interpret data
* deliver data
register location
LOCATOR

Figure 13: Basic role types within the BAN
Then we continue with the identification of LAP-driven Transactions, the elementary business process
modelling building blocks in SDBC [30]. Due to the limited scope of the current paper, we will not elaborate
on the identification of transactions and will instead present just the set of our identified 7 Transactions, in
consistency with the discovered role types, Figure 13. These Transactions, together with their
corresponding fact types, are presented below:
T1 (Interpret and) Deliver data; F1 data <D> is delivered
T2 Perform processing; F2 processing concerning data D is made

T3 Synchronize data; F3 data D is synchronized
T4 Manage data; F4 inputs regarding data D are managed and handled accordingly
T5 Register location; F5 location information regarding data D is provided
T6 Acquire data; F6 acquisition and sampling concerning data D is realized
T7 Provide biodata; F7 inputs concerning data D are provided.
Based on the identified Transactions, we build a coordination structure model, using the notations of
DEMO [38]. Our BAN DEMO coordination structure model is depicted in Figure 14:

S02

Carer

T7

T4

A02

Processing Unit

T3

T5

T1

T2

A01

Interpretor
S01: BAN System

A03

Synchronizator

A05

Locator

A04

Data Manager

A06

Data Acquisitor

T6

S03

Patient

Figure 14: Coordination structure model of the BAN
As seen from the figure, there are 8 role types (which have been identified (6 of which are internal with
respect to the system under study (the BAN). These role types concern the 7 Transactions (which have
been identified as well). The black boxes indicate which is the Transaction executing role.
Following the Transaction concept [37], we straightforwardly reflect the model (consider the above figure)
into a process-step one, as depicted on Figure 15, offering elicitation on the particular Transaction
performance:


Figure 15: Process step model of the BAN
On the figure, 4 abbreviations reflect the essential communication illocutions used: rq (request), pm
(promise), st (state), and ac (accept).
And finally, by adding dynamic elicitation based not only on the (above-presented) model but also on a
further consideration of the BAN Telemonitoring case, we build a Petri Net workflow model (Figure 16), as
a reflection of a possible scenario:


Start
End
Carer (C): Request data
System: Conduct security check
C: Submit request specification
access not allowed
System: Check submitted information
information insufficient
BAN: Conduct sampling BAN: Search to locate P
Patient (P): Provide data
BAN: Generate location inf.
BAN: Deliver location inf.
information unprecise
BAN: Handle the data inputs
BAN: Conduct synchronization
result unsatisfactory
BAN: Deliver data to D
BAN: Perform processing

Figure 16: Process step model of the BAN
4.4 Mapping of roles to functional blocks
The discovery of roles should provide the foundation for the identification of the pieces of functionality
characterizing the system-to-be. What role types represent is the abstract, technology-independent
competences that correspond to any future technical realization. In that sense, the core of the built
business process model reflects invariance.

We are to consider now a particular technical realization of the business process model (elaborated in 4
aspects) that has been presented in the previous sections. This realization concerns the MobiHealth-BAN
technological heritage which was discussed in previous chapters.
From the BAN perspective: the Interpretor, between transactions 1 and 2 (Figure 13), is to be about the
preparation of the data distribution, using a network channel; the Processing Unit, between transactions 2
and 4, should be about the actual data processing; the Synchronizator, concerning Transaction 3, must be
about the activity of joining of several data streams and synchronizing them; the Locator, concerning
Transaction 5, is to be about identifying location; the Data Manager, between transactions 4 and 6, should
be not only for collection, sampling, and serialization of data but also about its storing in repositories; the
Data Acquisitor is about the capturing of vital signs. We have depicted all this in the following table.
Table 1: Roles
Role types BAN-related competences Pieces of functionality

Interpretor Preparation of the data
distribution, using a network
channel
COMMUNICATOR
Processing Unit Processing of the data PROCESSOR
Synchronizator Joining of several data
streams (vital signs) and
synchronization of the data
JOINER
Collection, sampling, and
serialization of sense data
AGGREGATOR Data Manager
Storing the data in repositories STORE
Locator Identifies the location of a
person or other entity
Data Acquisitor Captures vital signs

SENSOR

As seen from the table, it is possible that:
more than one technology-driven functionality pieces are derived based on one role.
more than one roles are combined in one technology-driven functionality piece.
That is because the bottom line in identifying role types is a pure business-driven study that has nothing to
do with the eventual possibilities to apply IT automation to the business system, while the derived
technology-driven pieces of functionality that concern the IT system-to be, are specified on the basis of a
consideration of one (possible) technical realization or another.
In Chapter 5, we continue with a further elaboration regarding the identified BAN-driven pieces of
functionality. We are going to study their statical/structural interrelationships, with the help of UML in
general, and the UML Class Diagram, in particular.
5 BAN models
This chapter discusses the developed BAN models using a UML profile [39] to address families of BANs. It
starts with a basic description of the BAN model in terms of UML stereotype classes. It continues then with
refined descriptions of parts of the basic model.

5.1 Basic BAN model
Detailed properties of BANs in M-Health typically dependent on the problem domain specialty (e.g.
neurology, cardiology or obstetrics); however these BANs also share common features. In this chapter, we
derive a generic device BAN model that captures and expresses the invariant properties of healthcare
BANs for vital sign sensing and actuator-based treatment feedback. We express the generic model in UML
stereotyped class diagrams to get correct (by construction) refinements of specialty specific device BAN
models, which are expressed in UML class diagrams [39, 40].
As a network of devices worn on the body, a device BAN has the general structure of a graph, which itself
is a generalization of a network. Figure 17 shows a UML (stereotyped) class diagram of a graph, defined
by nodes (represented by the (stereotyped) class Node) and associated by the association class Edge.
stereotype
Node
stereotype
Edge
*
*

Figure 17: A graph defined by nodes Node and edges Edge.
As was discussed earlier, the nodes of an M-health device BAN can be categorized into two kinds. The
devices of the first kind are the simple end-devices like vital sign sensors or medical actuators (if
appropriate, including the more complex multimedia end-devices like cameras). The devices of the second
kind are for example intermediary processing, aggregating, storing or communication devices that facilitate
applications by bringing sensed vital signs to healthcare tasks or by bringing control commands from
healthcare tasks to the actuators (see e.g. Section 5.2 for the descriptions of these devices). These
intermediating devices will be represented by intermediary nodes and analogously the end-devices by end-
device nodes (see e.g. Figure 20).
In the M-Health domain, we may further constrain the graph due to the following observed properties:
Nodes adjacent to end-device nodes are intermediary nodes. That is, sensors are not
interconnected in a producer-consumer sense and neither are actuators. In healthcare moreover,
attaching a sensor directly to an actuator is not considered appropriate due to healthcare safety
constraints. For interface matching and safety reasons, at least one intermediary node goes
between a sensor and an actuator.
Since our M-Health applications target for use in a wide-area by using (third-party) network
infrastructures, we typically have to put processing and computing intelligence on the end-nodes of
the distributed environment rather than within the (third party) network infrastructures.
Consequently, the nodes of the graph represent the devices (both the end and the intermediary
devices) rather than resources in general, like for example network resources.
We further have the option to allow a hierarchy of intermediary nodes in our BAN model, but we
may also constrain the model to one level intermediary nodes.
The previous discussions yields the following generic device BAN models:
generic BAN model for one-level intermediary nodes: If the intermediary nodes are not
hierarchically related, the graph associated to a device BAN is bipartite (also called a bigraph, see
e.g. Figure 18).

stereotype
Node
stereotype
Edge
-intermediate
*
-end-device
*
End-device = sensory or actuator device node types.
Intermediate = intermediary node type.

Figure 18: Bigraph model of a generic device BAN
generic device BAN model for hierarchical intermediary nodes: If intermediary nodes may form a
hierarchy (e.g. Front-ends connected to MBUs), we have to relax the bipartite property of the
generic device BAN model. In this case, adjacent nodes of intermediates may either be sensory or
actuator end-device nodes or (another) intermediary nodes. In the latter case, a constraint will be
needed to prevent self referring intermediates, which is not relevant in healthcare (cf. the
constraint in Figure 20).The model of these BANs (Figure 19) is a relaxed form of the model shown
in Figure 18. Subtle difference is the role of one of the association end-points.
stereotype
Node
stereotype
Edge
-intermediate
*
*

Figure 19: Model of a generic device BAN enabling nested intermediaries.
A further refined form of the model shown in Figure 19 but which includes end- and intermediary- nodes is
shown in Figure 20.
stereotype
Edge
stereotype
Node
stereotype
End-device
stereotype
Intermediate
-son
1 *
-son-edge *
-father
1
End-device = sensory or actuator device node types.
{context Intermediate
inv: not(self.son-edge.son -> includes(self)
}

Figure 20: A refined model of a generic device BAN enabling nested intermediaries.

5.2 Constraints and refinements
We may include additional design choices for our M-Health BAN model, each of them influences the class
diagram shown in Figure 20:
We may specialize an edge (i.e. class Edge) into the following:
o an edge representing intermediary intermediary relation (e.g. called II_Edge in Figure 21),
o an edge representing a sensor (set) - aggregator relation (e.g. called SI_Edge in Figure 22),
and
o an edge representing a controller actuator relation (e.g. called IA_Edge in Figure 24).
We also may constrain the graph to prevent that aggregators become father nodes of other
intermediary nodes. This is relevant if an aggregator is strictly defined as a collector of sensed
data; that is, the son nodes of an aggregator are only sensors. In this case, we may have the
following OCL constraint (Figure 21):
{context II-Edge
inv: not father.oclisTypeOf(Aggregator)}.
In M-Health, we may add the constraint that vital sign sensors should not be shared by multiple
intermediary nodes. In this perspective, sensed vital signs may only be collected by one
aggregator, for instance to enable vital sign data distribution in a controlled way. That is, devices
that distribute vital sign data need to have (adjacent father node) processing resources for
example to enable the computation of the distribution conditions (e.g. expressed by policies). In
this case, we have two options to model vital sign sensors and to specify this constraint. The first
option is to specify the attribute sensor type of enumerated data type (e.g. vital-sign, location, etc.)
and to constraint (e.g. using OCL) the multiplicity of the association to the class SI_Edge to [0..1]
(cf. Figure 22). For readability, we define the class VitalSignSensor in Figure 22 explicitely.
Similarly, we also may model wired-sensors by class wiredSensor as a specialization of class Sensor
Figure 23).
5.3 Attributes of the generic BAN model
The attributes of the nodes of the generic device BAN model identified so far are:
node_id : to denote the serial number of AWARENESS intermediary device or the factory version
or serial number of sensors or actuators;
node_subtype
1
: to discriminate between sensor types (e.g. ECG, finger clip, etc.) or intermediary
device types or versions (e.g. Mobi4 aggregator, QTec HS24 R2.0 communicator, etc.);
node_characteristics: this is a collection of attributes that denote the characteristics of the nodes
including the input and output characteristics. Characteristics identified so far are for example:
o node_stubs_in: the set of input interface signatures of intermediary nodes. Stubs may be
simple signatures (e.g. specifying the jack of a wire end point), or complex ones which
specify the (wireless) technology and parameters (e.g. the slots, throughput and other
relevant QoS parameters), the access providers and their parameters (e.g. subscription
identifier and type). Examples are <Vodafone,UMTS(args)>. <KPN,GPRS(2,4) /-- 2 slots
uplink, 4 slots downlink --/>, <Hs24,BTooth(serial mode)>);
Note: an associated method is for instance
IsInterconnectStubCompatible(..,..,..) which arguments also refer to
edge_stub attribute of edges;
o node_stubs_out: the set of output interface signatures of intermediary nodes;
o node_specref: the (location) reference to the specification definition of the intermediary
node;

1
Node types are the intermediary and end-device.

o node_spec: to denote the specification definition of the intermediary node;
o sensitivity: to denote the sensitivity of sensor nodes;
o precision: to denote the precision of sensor nodes;
o priority: to denote the priority of the sensed data of this sensor;
o state: to denote the state of the node, e.g. the state of an actuator;
The edge attributes identified so far are:
edge_stub: see e.g. node_stub description;
edge_ISP: the communication service provider (This attribute may be combined with the stub
attribute);
edge_agent: the role/agent that makes the attachment (auditable aspect) or the component that
establishes the edge or instructs the creation of the edge;
edge_epoch: the period of being an edge, typically represented as a tuple of start and end dates
and times.

The attributes discussed previously are further elaborated in the class diagrams shown in the next figures.
5.4 Edge types
In Section 5.2, we discuss about edges which associate exactly two nodes and edges which represent
1:many or many:1 relations between son and father nodes. Edges which represent 1:1 relations are more
simple and suitable to represent the various choices of network connectivity (including the different ISPs or
cellular providers).
On the other hand, sensed data are typically collected as a set by an aggregator. In M-Health moreover, a
controller may govern a set of actuators. In the next sections, we investigate 1:1 edges in M-Health device
BAN models. Models with 1:1 typed edges but combined with the notion of sensor sets is a possible topic
of study. However, the concept of a 1:N typed edge is more complex and applying these type of edges will
result in a more complex UML class diagram. In this paper, we therefore use 1:1 typed edges.
5.5 Generic BAN model with 1:1 edges
This section refines the generic device BAN model shown in Figure 20. In this section, we address edges
which associate exactly two nodes. First we specialize edges by edges which associate two intermediary
nodes, then we include edges which represent sensors to aggregator relations. We also specify wired
sensors and refine the model with actuator relations.
Generic BAN model with intermediate-intermediate edges
As was discussed in Section Error! Reference source not found., we may distinguish between the
following intermediary nodes (Figure 21 and Figure 22):
joiner: a functional entity which joins (i.e. serialize or marshall) several data streams. An
aggregator is a specialized joiner which collects sensed data (e.g. vital signs) from
sensors. An aggregator typically includes pre-conditioning filters (e.g. vital sign bandpass
filters) to enable correct data processing in the sequel of the BAN data provisioning chain.
processor: a functional entity which processes actuator related data or sensed data. In the case of
vital sign processors, the input and output formats of the data should fulfil the format
specification described in AWARENESS D4.9 deliverable [41].
An Acontroller is a specialized processor that controls actuators.
communicator: a functional entity which prepare the data for distribution using network channels,
which typically are pipes that stream bits or ASCII characters. Multiplexing and
demultiplexing of sensed data (sets) or splitting and joining of streams are elements of a

communicator. A network gateway is for example a specialized communicator device that
bridges two networks.
We may further refine nodes, for example to specify classes to represent surrogate objects; however, this
level of details is considered beyond the scope of this paper.
Figure 21 shows a refined device BAN model that the previously described intermediary nodes. The class
II_Edge represents the earlier mentioned specialized edges between two intermediary nodes (cf. Section
5.2).
+IsStubsCompatible() : bool
+edge_agent : Agent
+edge_epoch : Epoch
stereotypeEdge
+node_id : NodeId
+node_subtype : NodeSubType
stereotypeNode
*
-son
1
-node_stubs_in : StubArray
-node_stubs_out : StubArray
stereotypeIntermediate
-father 1
*
-manufacturer : string
-manufacture_id : string
-priority : int
stereotype
End_device
+edge_stub : Stub
-edge_ISP : EnumIsp
stereotypeII_Edge
-son
1 *
-sensitivity
-precision
stereotype
Sensor
-ctrl_setting
-state
stereotype
Actuator
-userprofileref : URL
-userprofile : UPSpec
stereotype
Communicator
-demuxspecref : URL
-demuxspec : MxSpec
stereotypeStore
-procspecref : URL
-procspec : PrSpec
stereotype
Processor
-transcode : TrSpec
stereotype
Gateway
derived
{context II-Edge
inv: not father.oclisTypeOf(Aggregator)}
-muxjoinspecref : URL
-muxjoinspec : MxSpec
stereotypeJoiner
-node_stubs_in : ChanArray
stereotypeAggregator

Figure 21: Generic device BAN model with 1:1 edges including II-Edge class
Generic BAN model with sensor-intermediate edges
Figure 22 includes the class SI_Edge which represents the sensor to aggregator edges described in
Section 5.2.
We specify the following additional constraints in the class diagram:
In line with the given description of aggregators, aggregators may only have sensors as son nodes. In
this case, we have to exclude aggregators as father intermediary nodes of II_Edge.
In M-Health applications, it is considered not appropriate to share sensors (cf. discussion in Section 5.2).
This means that in the context of the VitalSignSensor class the multiplicity of the association endpoint to
the SI_Edge should be set to 0..1 (instead of *). As discussed earlier, an alternative is to specify a sensor
type in the class Sensor and to constrain the endpoint multiplicity using OCL instead of introducing the
class VitalSignSensor. This alternative is more flexible from an implementation point of view, but we
choose to use the class VitalSignSensor for clarity.

+node_id : NodeId
+node_subtype : NodeSubType
stereotypeNode
+edge_agent : Agent
+edge_epoch : Epoch
stereotypeEdge
-son
1
*
-priority : int
stereotype
End_device
*
-father 1
stereotypeJoiner
+IsStubsCompatible()
+edge_stub
stereotype
SI_Edge
*
-father
1
-sensitivity
-precision
stereotype
Sensor
*
-son 1
-type : EnumVS
stereotype
VitalSignSensor
-son
1
0..1
derived
derived
derived

Figure 22: Generic device BAN model with SI edges
Wired-sensor model
In line with the discussion in Section 5.2, we may model non-shareable wired and dumb sensors as shown
in Figure 23. The classes dumbSensor and wireSI_Edge are specializations of the classes Sensor and
SI_Edge, respectively. Stub definition and compatibility checking is overridden and adapted to the jacks of
the sensor and Mobi4 specified by the manufacturer.

+edge_stub[1]
stereotype
wireSI_Edge
stereotype
dumbSensor
1 1 *
-father
1
-sensitivity
-precision
stereotype
Sensor
+edge_stub
stereotype
SI_Edge
*
-son
1
*
-father 1
derived derived

Figure 23: Wired Sensor specification in the generic device BAN model
Actuator model
In case of a wired and dumb actuator, we may use the model shown in Figure 24. In this model, a
controller (class AController) may control several (dumb) actuators, but an actuator may only be controlled
by one controller. The stereotype class IA-Edge is a specialization of the abstract stereotyped class Edge
and discussed in Section 5.2.

+edge_agent : Agent
+edge_epoch : Epoch
stereotypeEdge
+edge_stub
stereotype
IA_Edge
stereotype
dumbActuator
1 1
-state
stereotype
AController
*
-father
1
-procspecref : URL
-procspec : PrSpec
stereotype
Processor
derived
-ctrl_setting
-state
stereotype
Actuator
derived
-priority : int
stereotype
End_device
-son
1
*
<<derived>>
*
-father
1

Figure 24: Actuator specification in the generic device BAN model
M-health Mobi4-based example:
Figure 25 illustrates the use of the generic device BAN model (shown in Figure 21, Figure 22 and Figure
23). Sensors are wired and have a 1:1 relation to the wired-si-edge MHMb4Attach. Besides an aggregator,
the Mobi4 also deploys a store (represented by class MHLocalAreaStore) and communicator (represented
by class MHMb4Com). The class MHGtway is deployed on the MBU and the class MHRemoteStore is
deployed on the Back-End system. The class MHConnect represents internal connections within the

Mobi4s, MBUs and Back-End system and also the network channels, like the BlueTooth connection
between the Mobi4s and MBUs, the cellular link and the Internet connectivity between the MBUs and the
Back-End system.
The association end point of the class MHMb4Attach to the aggregator is limited to 5 sensors and is
ordered due to the different stub-jacks of the Mobi4.
Additionally, this model enables the registration of the agent (or role) that attaches the sensors to the
Mobi4 aggregator in the operational phase.
dumbsensor
EMG
dumbsensor
SpO2 intermediate
MHInterm
dumbsensor
MHSensor
dumbsensor
ECG
aggregator
MHMb4Agg
si_edge
MHMb4Attach
-son
1 1
0..5
{ordered}
-father
1
ii_edge
MHConnect
gateway
MHGtway
store
MHLocAreaStore
store
MHRemoteStore
*
-father
1
*
-son
1
{in MobiHealth:
fixed multiplicity
& no-sharing}
communicator
MHMb4Com
processor
MHmedProc

Figure 25: M-health device BAN model based on Mobi4
The deployment of the M-health BAN model (Figure 25) onto the components and the M-health system
nodes is illustrated in Figure 29 and Figure 30.
6 Implementation
This section describes the software design of the MBU-BANware. As indicated in section 3.2 the MBU is
the central controlling device of the AWARENESS BAN that performs computation, coordination and
communication functions. The BANware is a software layer, which corresponds with our notion of
BANManagement, deployed on the MBU that is responsible for coordinating the BAN configuration and
manages communication sessions with the back-end system.
Section 6.1 positions the MBU-BANware layer as a coordinator between the Mobile Service Platform
(MSP), the graphical user interface and the physical sensor devices. Section 6.2 discusses the structure of
the MBU-BANware in more detail and identifies the responsibilities of the key Java classes involved.
Section 6.3 describes the implementation of MBU measurement profiles. These profiles provide a partial
implementation of the models defined in chapter 5.

6.1 The role of MBU-BANware
The MBU-BANware layer is a software layer that coordinates between the graphical user interface (GUI),
the sensor devices and the Mobile Services Platform (MSP) [42]. Figure 26 depicts the coordinating role of
the MBU-BANware.
GUI layer
MBU-BANware layer
MSP layer
Sensor Devices

Figure 26: MBU-BANware acts as a coordinator

Decoupling the BANware from the GUI, sensors and MSP allows for independent developments in each of
these parts of the system. The GUI can be tailored to specific needs of the patient that uses the BAN.
Sensor devices can communicate with the MBU using an application protocol that is specific, and possibly
optimized, for a specific sensor device. The MBU-BANware layer allows specific device drivers to be
plugged into the system. The MSP layer provides an abstraction of the underlying network and offers
support for request/response and streaming (i.e. continuous data flow) interactions.

6.2 MBU-BANware structure
Figure 2 shows a more detailed picture of the structure of the MBU-BANware software. The squares with a
bold title inside depict Java classes. The grey squares indicate a group of related classes. Arrows with a
solid line indicate an owner-creator relation. Arrows with a dotted line indicate the flow of commands and
channel data through the system. We discuss the responsibility and interactions of the most relevant
classes of this structure below.


ChannelSet service provider
Transcoding Chain
Signal Monitoring
MBUController
system
setup/teardown

Data source(s)
DeviceManager
centralized device
subscr. / broadcasting
Device Monitors
buffering /
basic filtering
Device
Impls
proxy
MBUServiceManager
services setup

Interconnect service provider
SurrogateHostConnection

SurrogateConnection

StorageManager
disk record /
playback
active
channels
MBU System Configuration
MBUDesc
top level XML
element, modified
with patient ID
MBU Measurement
Profiles

SignalMonitorManager
centralized monitor
creation / notification
system creation
message
exchange
GUIInteraction
identifiers and utility
methods (e.g.
queueing)
GUI layer
MBU-Banware layer
GUICommandListener

MBU-Banware layer
MSP layer
signal processing
input
SignalMonitors
monitoring /
GUI
notification
SignalProcessors
utility filters for
monitoring /
channel data
generation
responsibility
link
flow of commands/channel data

Figure 27: Structure of MBU-BANware Java implementation
The MBUController is a singleton class that is responsible for the MBU system configuration and creates
the data sources, the signal monitoring classes and the ChannelSet service provider. It is the main system
control component that knows how to boot up and shut down measurement sessions, and knows how to
translate events that occur during measurement sessions to (external) GUI events / user notifications.
The MBUDesc is the top-level class of a Java representation of the BAN configuration. This configuration
is discussed in more detail in the next section.

The data sources of the MBU are the software representations physical devices, such as the TMSi Mobi5.
DeviceImpls are proxies to specific devices. These proxies implement a Device interface and can be seen
as a driver that encapsulates the specific (application) protocol needed to interface with a physical device.
The DeviceManager provides centralized access and control of Devices in the system. All known devices
(specified in a XML configuration file) are instantiated during initialization time. A device implementation is
activated when another object in the system subscribes to the channel data it produces.
Every Device receives its own DeviceMonitor that buffers incoming data and filters out all non-active
channels. This information is then passed on by a consumer thread to all subscribers.
Channel data then flows to the signal monitors and the ChannelSet service provider. The next section
discusses this provider in more detail. The SignalMonitorManager creates SignalMonitor objects. A
SignalMonitor subscribes to channel data that the DeviceMonitor objects produce and maps this to GUI
output / actions.
The StorageManager is responsible for recording all device channels for a given channel set to disk and is
also able to playback previously stored data. The method used for storage is periodic blocks of
compressed data, whereby a separate header file indicates for each period the data location in the data file
for quick access.
6.3 MBU Measurement Profiles
The relation between the data that physical sensor devices produce and the data that eventually flows from
the MBU to the back-end system is captured in a measurement profile. A measurement profile is created
by a healthcare professional. Each device produces data for one or more channels. These channels may
run at different sampling frequencies. The purpose of a measurement profile is to indicate which of the
device channels must be forwarded to the back-end and also which channels must be processed locally
(e.g. to drive the GUI). Figure 28 shows the Java classes that are used to construct a run-time
representation of a measurement profile on the MBU.

MBU Measurement Profiles
(one ChannelSet is
one profile)
ChannelSetDesc
subscribeable
element
DeviceDesc
device config
ChannelDesc
channel format
*
*
*
SignalProcessorDesc
signal analysis &
output
SignalMonitorDesc
monitor device
output for
GUI/alarms
*
*
0..1 0..1

Figure 28: Java structure of measurement profiles
The ChannelSetDesc is the top-level class of a measurement profile. It may contain one or more
DeviceDesc objects and one or more SignalMonitorDesc objects.

The DeviceDesc class represents a physical device. This corresponds to an End_device in chapter 5. A
DeviceDesc object knows specific details of a physical device, such as type, number of channels, number
of active channels and number of bytes in a sample.
A ChannelDesc object provides configuration details of a single channel. This corresponds to the Sensor
stereotype in chapter 5. Typical configuration information is the sample frequency of the channel, the
resolution, the byte length of a sample and unit of measurement.
A SignalMonitorDesc object represents the list of SignalMonitors attached to a set of channels. A
SignalMonitor uses the input of one or more channels to drive the GUI.
A SignalProcessorDesc object represents a list of signal processors. A signal processor uses the input of
one or more channels to produce a derived signal. For example, derive the heart rate from a set of ECG
channels. A signal processor corresponds to a Processor stereotype in chapter 5.
6.4 Relation with the BAN models
This section presents the relation of the implementation with our developed the BAN models.
The bottom part of Figure 29 shows the relations between these subcomponents and the classes
described in Section Figure 30.
Data
sources
executable
FrontEnd
processor
MHmedProc
system
creation
GUI
command
listener
GUI
display
MBU
storage
MBU
Data
sources
/*local*/
monitor
controller
MBU
SysConfig
ChannSet
SP
input from
FrontEnd
output to
BEsystem
monitor
controller
MBU
SysConfig
MBU
storage
ChannSet
SP
gateway
MHGtway
communicator
MHMb4Com
store
MHLocAreaStore

Figure 29: MBU represented in sub-components.
Figure 30 illustrates how the classes described in Section 5.5 have been deployed in the Mobihealth
telemonitoring system [8] (see also Figure 7; the component Front End is however not shown in this
figure). In AWARENESS, the component Network1 represents the BlueTooth serial mode channel and
Network2 represents the communication channel to the BackEnd system over GPRS, IEEE 802.11 or
UMTS.

executable
MBU
PDA
executable
FrontEnd
ECGSensor BESystem
Mobi4 Backend server Sensornode
dumbsensor
ECG
si_edge
MHMb4Attach
aggregator
MHMb4Agg
-father
communicator
MHMb4Com
processor
MHmedProc
gateway
MHGtway
store
MHLocAreaStore
store
MHRemoteStore
ii_edge
MHConnect
Network1 Network2 wires

Figure 30: AWARENESS nodes, networks, components and associated classes.
7 Conclusions
This paper presents a conceptual model of a Body Area Network (BAN). This model enables the
implementation of robust BAN management functionality.
We started this paper with a state of the art of BANs. We indicate that the difference between a PAN and a
BAN lies in the limited target scope of BANs. A BAN focuses on devices worn on the body of single patient
or devices in very close proximity to single patients. BANs are researched by different parties, ranging from
Philips, WWRF to Fraunhofer and the University of Twente. The University of Twente did its first
(pragmatic) BAN research in the Mobihealth project. In AWARENESS we extend this BAN research by
shifting some of our core focus to BANS, increasing our target applications and incorporating context-
awareness. Furthermore, we create a robust BAN model by using software engineering modelling
approaches.
The second part of this paper researches the business context of BANs. This is the foundation for our BAN
software model to ensure that the application-to-be, based on this model, operates according to the
business environment in which it should be integrated. The business process modelling is performed using
the SDBC approach which concerns a business process-modelling-driven software specification. This
analysis resulted in a definition of BAN roles and corresponding pieces of functionality which are
incorporated in our BAN model.

The third part of this paper presents our BAN model, expressed in UML profiles. This model is build up
from the fact that a BAN is a kind of network (i.e. devices are connected with connections) which is a kind
of graph (i.e. nodes are connected with edges). Increasingly this model is detailed to incorporate all the
invariants posed by BANs. Figure 31 presents our basic BAN model. This model states that a BAN is a
graph of nodes connected by edges. These nodes can be intermediate nodes (e.g. processor, storage) or
end-devices (e.g. sensors, actuators). The model constraints that end-devices can not connect to other
end-devices, only to intermediate devices. Some of the invariants are encapsulated by the model, when
this was not possible OCL constraints are added.
stereotype
Edge
stereotype
Node
stereotype
End-device
stereotype
Intermediate
-son
1 *
-son-edge *
-father
1

Figure 31: Basic BAN model
Finally, the last part of this paper presents an implementation based on our BAN model. This
implementation is the BANware implementation for AWARENESS BANs, which resides between the GUI
and the supporting infrastructure. We indicate the structure of this BANware and clarify the relation of our
BAN model with this implementation
7.1 Future work
The defined BAN model provides a sound foundation for BAN management implementations. However,
there are some aspects we want to explore further in the future:
Task oriented BAN models: Our model focuses on the acquisition part of the overall patient
treatment process. Also models on the task part of the treatment process are needed. These
models should incorporate the fact that different types of vital signs form a coherent set for making
a diagnosis. Furthermore, if a patient has multiple morbidities which may imply overlapping vital
sign types, sub-sets of vital signs become relevant. Additionally, quality of signs becomes
important. Integration of the task-oriented model with the, here discussed, acquisition model is also
considered future work (see Section 1.2).
1:N edges: Our current model consists of 1:1 relations between sensors/actuators and
intermediate devices. This is a simple representation that is suitable for BANs. However, real
BANs also consist of 1:N relations (see Section 5.4).
Implementation: The current implementation is a static implementation based on our BAN model.
We plan extend this implementation such that BANs can be managed dynamically at run-time (see
Section 6.2).
Acknowledgements
We like to thank Alfons Salden for his useful comments in creating the foundations for this paper. Also, we
are grateful for the guiding remarks of Anneke Kleppe on the UML modelling techniques and our modelling
approach. Furthermore, we want to thank Liu PuMing and Bert Jan van Beijnum for their information on the
task oriented vital sign viewpoint. Finally, we want to thank the reviewers of this paper, Gerlienke Voerman
and Johan de Heer, for their quality improving comments.
This work is part of the Freeband AWARENESS project (http://awareness.freeband.nl). AWARENESS
stands for Context AWARE mobile NEtworks and ServiceS. The Freeband AWARENESS project focuses

on service and network infrastructures that are needed to support context aware and pro-active
applications on heterogeneous mobile networks. Particular attention is paid to mobile health applications
for tele-monitoring and tele-treatment. The following organizations participate in Freeband AWARENESS:
Lucent Technologies, Centre for Telematics and Information Technology, Telematica Instituut, Roessingh
R&D, Ericsson, Twente Institute for Wireless and Mobile Communications, Yucat and TMS International.
Freeband AWARENESS is part of the Freeband program (www.freeband.nl). Freeband is a large national
research program in the field of 4G telecommunication, in which fixed, mobile and wireless connections are
integrated. Key research questions take place in three main themes: (1) enabling technology, (2) service
provisioning, networking and access, and (3) society, users and applications. Freeband comprises over 30
organizations and is sponsored by the Dutch government under contract BSIK 03025."
References
1. van Halteren, A., Towards an adaptable QoS aware middleware for distributed objects. 2003,
Univesity of Twente: Enschede.
2. Broens, T. and R. Huis in't Veld, Tele-monitoring and Tele-treatment applications: problems and
the awareness approach, in Freeband AWARENESS D4.5, T. Broens, Editor. 2005.
3. Mobihealth, Mobihealth project webpage, 2004, Available from: http://www.mobihealth.org.
4. Bults, R., et al., Trial specific Mobihealth BAN, in IST Mobihealth D2.3, A. Halteren, Editor.
5. Broens, T., et al., Context-aware application components, in Freeband AWARENESS D4.2. 2004.
6. Hobsley, M., Pathways in Surgical Management. 1979, London: Edward Arnolds Pub. Ltd.
7. Liu, P., SLA's in the Healthcare Domain. 2005, University of Twente: Enschede.
8. Widya, I., et al., Telematic Requirements for a Mobile and Wireless Healthcare System derived
from Enterprise Models, in Proceedings IEEE ConTel 2003: 7th International Conference on
Telecommunications. 2003: Zagreb, Croatia.
9. Batteram, H., et al., AWARENESS Scope and Scenarios, in Freeband AWARENESS D1.1v2, M.v.
Sinderen, Editor. 2005.
10. Zimmerman, T., Personal Area Networks: Near-field intrabody communication. IBM System
Journal, 1996. 35(3/4): p. 609.
11. Zimmerman, T., Wireless networked digital devices: A new paradigm for computing and
communication. IBM System Journal, 1999. 38(4).
12. Zigbee Alliance, Wireless control that simply works, Available from:
http://www.zigbee.org/en/index.asp.
13. Basuma, Body Area System for Ubiquitous Multimedia Applications, Available from:
http://www.basuma.de/.
14. Dam, K.v., S. Pitchers, and M. Barnard, Body Area Networks: Towards a Wearable Future, in
Proc. WWRF kick off meeting. 2001: Munich, Germany.
15. Jones, V., et al., Body Area Networks for Healthcare, in Wireless World Research Forum. 2001:
Stockholm.
16. Jones, V., R. Bults, and P. Vierhout, Virtual Trauma Team, in Wireless World Research Forum.
2001: Helsinki.
17. Wireless World Research Forum, The Book of Visions 2001: Visions of the Wireless World, 2001,
Available from: http://www.wireless-world-research.org/.
18. Jones, V., et al., Healthcare PANs: Personal Area Networks for trauma care and home care, in
Proceedings Fourth International Symposium on Wireless Personal Multimedia Communications
(WPMC). 2001: Aalborg, Denmark.
19. Konstantas, D., et al., MobiHealth - Wireless mobile services and applications for healthcare, in
International Conference On Telemedicine - Integration of Health Telematics into Medical Practice.
2002: Regensburg, Germany.
20. Dokovski, N., A.v. Halteren, and I. Widya, BANip: Enabling remote healthcare monitoring with
Body Area Networks, in FIDJI'03. 2003.
21. Fraunhofer, BAN - Body Area Network, Available from:
http://www.iis.fraunhofer.de/pub_rel/presse/2002/cebit/ban.html.
22. Fraunhofer, BAN - Wireless communication between man and machine, Available from:
http://www.iis.fraunhofer.de/ec/drahtlos/body_com/index.html.

23. Fraunhofer, Body Area Network.
24. Baskiyar, S., A Real-Time Fault Tolerant Intra-Body Network, in 27th Annual IEEE Conference on
Local Computer Networks (LCN'02). 2002: Tampa, Florida.
25. Redtacton, Redtacton, Available from: http://www.redtacton.com/en/index.html.
26. Amato, G., et al., Health Care Monitoring of Mobile Patients, Available from:
http://www.ercim.org/publication/Ercim_News/enw60/amato.html.
27. Conti, M., Body, personal, and local ad hoc wireless networks, 2003, Available from:
http://portal.acm.org/citation.cfm?id=989713.
28. Jones, V., et al., Remote Monitoring for Healthcare and for Safety in Extreme Environments, in M-
Health: Emerging Mobile Health Systems, R. Istepanian, S. Laxminarayan, and C. Pattichis,
Editors. forthcomming.
29. Shishkov, B. and J. Dietz, Aligning Business Process Modeling and Software Specification in a
Component-Based Way, The Advantages of SDBC, in Proceedings of the 6th International
Conference on Enterprise Information Systems (ICEIS). 2004: Porto, Portugal.
30. Shishkov, B., Software specification based on re-usable business components. 2005, Delft
University.
31. Shishkov, B. and J. Dietz, Design of Software Applications Using Generic Business Components,
in Proceedings of the 37th Hawaii International Conference on System Sciences (HICSS). 2004:
Big Island, Hawai.
32. Lui, K., Semiotics in Information Systems Engineering. 2000, Cambridge, UK.
33. Gibson, J., The Ecological Approach ot Visual Perception. 1979: Boston: Houghtpn Miffin.
34. Winograd, T. and F. Flores. Understanding Computers and Cognition: A Foundation for Design. in
Ablex, Norwood, NJ. 1986.
35. Shishkov, B., et al., Information architecture, in Freeband AWARENESS D1.4v2. 2005.
36. Czarnecki, K. and U. Eisenecker, Generative Programming: Methods, tools, and applications.
2000: Addison-Wesley.
37. Shishkov, B. and J. Dietz, Applying Component-Based UML-Driven Conceptual Modeling in
SDBC, in proceedings of the 7th International Conference on Enterprise Information Systems
(ICEIS). 2005: Miami, Florida.
38. Dietz, J., Understanding and Modeling Business Processes with DEMO, in Proceedings of the
18th International Conference on Conceptual Modeling (ER'99). 1999: Paris, France.
39. Fowler, M., UML Distilled Third Edition. 2004: Addison-Wesley.
40. Booch, G., J. Rumbaugh, and I. Jacobson, The Unified Modelling Language User Guide. 1999:
Addison-Wesley.
41. Mei, H., I. Widya, and A.v. Halteren, Vital Sign Model, in Freeband AWARENESS D4.9. 2005.
42. Halteren, A.v. and P. Pawar, Mobile Service Platform: a Middleware for Nomadic Mobile Service
Provisioning, in Freeband AWARENESS D2.19. 2005.

Body Area Network PDF

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Body Area Network PDF

Enviado por

Direitos autorais:

Formatos disponíveis

Copyright 2004 Freeband AWARENESS project partners

Você também pode gostar