I-Living: An Open System Architecture for Assisted Living

Abstract

Advances in networking, sensors, and embedded devices have made it feasible to monitor and provide medical and other assistance to people in their homes. Aging populations will benefit from reduced costs and improved healthcare through assisted living based on these technologies. However, these systems challenge current state-of-the-art techniques for usability, reliability, and security. This is a particular challenge for open and extensible systems that combine software and hardware from many vendors and provide information to diverse clinicians. In this paper we present the I-Living architecture for assisted living that allows independent parties work together in a dependable, secure, and low-cost fashion with predictable properties. Our approach is based on an Assisted Living Service Provider (ALSP) who provides a server that collects and maintains encrypted assisted persons (APs)' records. Our ALSP can be a third party distinct from APs, communication providers, and clinicians; or it can be part of an ISP, hospital or similar enterprise. We have explored the architecture by developing a collection of applications and implementing them in a prototype system. Our system shows the feasibility and opportunity of an open approach to assisted living systems.

Full text

Page 1

An Open System Architecture for Assisted Living
Qixin Wang, Wook Shin, Xue Liu, Zheng Zeng, Cham Oh, Bedoor K. AlShebli,
Marco Caccamo, Carl A. Gunter, Elsa Gunter, Jennifer Hou, Karrie Karahalios, and Lui Sha
Department of Computer Science,
University of Illinois at Urbana Champaign,
Urbana, IL 61801
Email: {qwang4, wookshin, xueliu, zzeng2, chamoh, alshebli,
mcaccamo, cgunter, egunter,jhou, kkarahal, lrs}@uiuc.edu
Abstract—The aging of baby boomers has become a social and
economical challenge. According to MIT’s magazine TECHNOL-
OGY REVIEW, July/August 2003, “In the United States alone,
the number of people over age 65 is expected to hit 70 million by
2030, doubling from 35 million in 2000, and similar increases are
expected worldwide”. Along with the increase of population of
elderly people, the expenditures of the United States for health-
care is projected to rise to 15.9% of the GDP ($2.6 trillion) by
2010 (Digital 4Sight’s Health Care Industry Study). Unless the
cost of senior care can be significantly reduced by technological
means, it could bankrupt the already shaky social security and
medicare systems. In this paper, we present a system architecture
for assisted living that allows disparate software, hardware, and
protocol families work together in a dependable, secure, and low-
cost fashion with predictable properties. We first describe the set
of potential applications to be supported, identify the existing
technologies and consumer electronics that can be leveraged to
realize these applications, and outline the functionalities required
in the system infrastructure. Then we present an open system
architecture, and discuss its considerations for flexibility, system
availability and security/privacy.
I. INTRODUCTION
The aging of baby boomers has become a social and
economic challenge. According to MIT’s magazine TECH-
NOLOGY REVIEW, July/August 2003, “In the United States
alone, the number of people over age 65 is expected to hit
70 million by 2030, doubling from 35 million in 2000, and
similar increases are expected worldwide”. Along with the
increase of population of elderly people, the expenditures
of the United States for health-care will grow projecting to
rise to 15.9% of the GDP ($2.6 trillion) by 2010 (Digital
4Sight’s Health care Industry Study). Unless the cost of senior
care can be significantly reduced by technological means, it
could bankrupt the already shaky social security and medicare
systems.
Another social trend that affects senior care is the move
away from the nuclear family household and the increasingly
youth-oriented society. This leaves many people to their own
means in receiving health care and satisfaction from life. They
are increasingly restricted to living alone or in assisted living
facilities. According to a report by National Institute on Aging,
only 10% of elderly people of age 65-85 and 25% of those
of age 85 and above in the United States are institutionalized.
Similarly, it has been reported that the numbers of elderly
people living alone in Korea has increased 100% in the last
ten years. Because of the deteriorating capabilities to sense
and interact with the environment, such as memory, eye sight,
hearing, dexterity and mobility, elderly people often live with
significantly degraded life quality. Many also suffer from
chronic diseases that require medication and clinic visits on a
regular basis. Without assistance, they often cannot keep up
with their schedule and at times are unable to call for help
after a serious fall or illness.
Because of above reasons, researchers at the University of
Illinois at Urbana Champaign have been designing, imple-
menting, and evaluating with testable hypothesis a assisted-
living supportive software infrastructure that allows disparate
technologies, software components, and wireless devices to
work together in a low cost, dependable, and secure fashion
and enables elderly people to regain their capability of in-
dependent living. Specifically, we have designed the assisted
living supportive environment to meet the following require-
ments:
1) Dependability: Critical services will be failure safe, and
delivered in spite of the failures of useful but non-critical
services. Moreover, the system as a whole will have high
availability and robustness.
2) Low Cost and Flexibility: The assisted living in-
frastructure will be open with well defined interfaces,
machine checkable QoS assumptions, and support the
use of low-cost, third-party devices. As incompatible
and incomplete assumptions have been reported to be
a major source of unexpected interactions leading to
high maintenance cost, these attributes will significantly
reduce system integration and deployment time and
promote industry standardization.
3) Security and Privacy: Medical and personal data will
be protected with different levels of information disclo-
sure to different roles (health care providers, medical
team, relatives, and residents). Also, with wireless net-
working being the predominant communicationmedium,
security mechanisms will be built in in these communi-
cation facilities and associated information storage.
4) Quality-of-Service Provisioning: In spite of the exis-
tence of various forms of workload dynamics, ranging
from transmission of reminder messages, monitoring
information, audio commands, to time-critical multime-

Page 2

dia streams supporting tele-medicine, Quality of Service
(QoS) will be provided at different levels to applications
subject to their timing, reliability and criticality require-
ments.
5) Wireless Interference Mitigation: Different wireless
devices of disparate protocol families can interfere with
each other when they are in range, e.g., Bluetooth versus
IEEE 802.11b, and IEEE 802.11a versus microwave. We
will ensure that interference is mitigated to the maximal
possible extent and QoS is provided even in the presence
of wireless interference and medium contention.
6) Light-Weight, Easy-to-Use HCIs: The user interfaces
will be easy-to-use, safe, accommodate with respect to
user mistakes, and provide different control levels of
information disclosure.
7) Thorough Evaluation and User Group Studies: The
assisted living system will be evaluated in terms of the
extent to which these technologies help elder people
with their independent living in the home or assisted
living facilities, their attitudes toward deploying these
technologies in the environment. Different hypotheses
that are amenable to theoretically-grounded tests will
be established, and a detailed, comprehensive evalua-
tion will be carried out by professional, quality-of-care
experts to (in-)validate the hypotheses.
In this article, we focus on our open system architecture for
the assited-living supportive infrastructure.In what follows, we
begin in Section II with a discussion of example applications
that are enabled with the proposed software architecture .
Then we elaborate on the various components in the software
architecture in Section III. Following that, we summarize our
implementation status of the architecture and its associated
applications in Section IV, and give a succinct summary of
related work in Section V. Finally we conclude the paper in
Section VI.
II. EXAMPLE SCENARIOS
We envision an assisted living supportive environment in
which various embedded devices (sensors, actuators, displays,
and bluetooth-enabled medical devices) either operate inde-
pendently or are coordinated under the local intelligence,
referred to as the butler node. The butler can be a specialized
PC, PDA, or a black box equipped with one or more wireless
interface cards (IEEE 802.11, Bluetooth, Ultra Wide Band,
or Infrared). Independent devices and the butler can commu-
nicate with the the Assisted Living Service Provider (ALSP)
server over the Internet. The ALSP server also provides web-
based interfaces to allow caregivers, health care providers and
medical experts, to monitor the environment, retrieve/analyze
measurement data, and issue instructions/feedback. Under
the assisted living supportive environment, we envision the
following assisted living application scenarios:
1) Activity Reminder: The butler obtains from the ALSP
server (to which health care providers have access)
updated prescription and appointment records of the
resident through secure channels. When it is time for the
resident to carry out his/her time driven routines, such as
taking medicine or taking vital signs, the butler locates
active wireless-enabled devices (e.g., TVs, cell phones,
wearable headsets, and/or active badges [1]) in range,
and sends reminder messages to one or more devices
that are in the proximity of the resident. (The resident
can also prioritize the order in which devices will be
used.) For example, if the resident is watching TV at
the time when the reminder message is scheduled, the
TV will be switched to an information channel (with the
use of Infrared remote control) and a reminder message
will be displayed. In this manner, the resident can be
reminded of his/her time driven routines. Whether or
not these routines are followed as advised is detected in
a non-intrusive manner by exploiting sensor localization
technologies such as RFID [2] or Ubisense [3] – the
prescription bottles can be attached with light-weight
RFID or Ubisense tags (with unique barcodes) and one
or more RFID/Ubisense readers in the environment are
activated (by the butler) to track location changes (if
any) of these bottles. Note that each RFID tag costs
approximately 40 cents today, and the cost is expected
to further decrease in the future.
2) Vital Sign Measurement: In the current practice of
glucose monitoring for diabetics patients, a patient mea-
sures his/her glucose level on a daily basis, and brings
the OneTouch [4] device to his/her monthly clinic visits
where the measurements are retrieved and interpreted by
health care providers. With the proposed environment in
place, vital signs (such as the glucose level, blood pres-
sure, heart bit rate, arterial oxyhemoglobin saturation
level) can be measured and transmitted by Bluetooth-
enabled meters [5] to the butler and then to the ALSP
server (through the secure channels established between
the butler and the server). In this fashion, health care
providers can monitor various vital signs at desirable
time granularity. Should the readings suggest any abnor-
mal health situations, medical instructions can be given
before the situations deteriorate.
3) Personal Belonging Localization: Personal belongings
such as eyeglasses, hearing aids, and key chains can
be attached with tags, and located through the use
of RFID/Ubisense readers. When a person cannot find
his/her belongings (because of forgetfulness), he/she can
issue a simple vocal command (through, for example,
a light-weight, Bluetooth-enabled headset) to the butler
which then schedules the RFID/Ubisense readers to scan
the environment and help locate the object.
4) Personal Behavior Profiling: With the same set of
sensor localization techniques, the assisted living en-
vironment can profile the movement of residents in
a privacy preserving manner (e.g., without the use of
surveillance video cameras) and detect early warning
signs for depression (stop taking medicine regularly,
giving up routine activities, or staying in bed for long
periods of time) and/or other chronic diseases such

Page 3

as Parkinson’s disease and Alzheimer’s disease. The
resident wears a RFID tag or an active badge (turned
into, for example, a bracelet or a button on his clothes).
The RFID readers installed in the environment will keep
track of his location, and hence will be able to detect
abnormal spatio-temporal movement, without intrusion
of privacy.
5) Emergency Detection: In case of the need for emer-
gency attention (e.g., the blood pressure/sugar has been
dangerously high/low, and/or the person has been de-
tected via localization techniques to be immobile on
the floor for an unreasonably long time), real-time
communication channels can be established to notify on-
site caregivers (in the case of assisted living), health care
providers (in the case of clinical use), and/or designated
relatives, and facilitate transmission of electrocardio-
gram (EKG) and other measures in real-time.
To realize the above scenarios, we have to consider several
design issues. First, the various application scenarios require
effective communication and coordination of disparate em-
bedded hardware, software and communication components.
For example, in the reminder application, the butler has
to coordinate, and effectively transport messages, among a
Bluetooth earplug, Infrared TV, cable-connected projector, and
localization systems such as Ubisense (e.g., to verify the
person has taken the medicine). What makes things more
complicated is that as the system evolves, different embedded
components may be brought into the environment. Therefore,
the assisted living architecture must be flexible enough to
accommodate hybrid embedded systems. Second, several as-
sisted living applications, such as daily reminder of taking
medicines for chronical diseases, monitoring vital signs, and
detecting emergencies and abnormal situations, must operate
all-year-around without disruption. Availability is thus another
important design requirement. Moreover, this requirement has
to be met even when the butler is down or when the resident
is away from home. Finally, as a large amount of medical
data is transported in the proposed infrastructure, security
and privacy is another indispensable concern. The system
must provide means to authenticate distributed entities, protect
communication resources, and preserve user privacy. We have
laid out an open system architecture that meets the above
design requirements and will present in the next section its
various components.
III. SYSTEM ARCHITECTURE
A. Overall Architecture
The basic system architecture is depicted in Figure 1. The
home environment of the resident is covered by a Wireless
Local Area Network (WLAN). Devices in the WLAN connect
to the Internet via the gateway router. One important device
in the WLAN is the butler which acts as the local intelli-
gence and manages passive devices (most of which pertain to
activity reminder and localization services) through its own
peripheral network (e.g., Bluetooth). Several assisted living
Fig. 1. Overall System Architecture – Gateway Mode
client applications reside on the butler and use its various
peripheral devices. A smart or active device, on the other hand,
can also act as an autonomous WLAN node, and does not rely
on the butler. In particular, if the smart device is equipped with
the internet stack, it can connect to the ALSP server directly.
Incorporatingsuch smart devices in the infrastructure promotes
end-to-end security and reduces the number of intermediate
control entities that are subject to potential security leaks.
Moreover, with the peer smart devices in place in addition to
the butler, the system availability will be overally improved,
because the butler will not become a potential single-point-of-
failure.
The design in Figure 1 may still suffer from a single-
point-of-failure: the gateway router. To ensure high availabil-
ity, we propose a backup alternative (Figure 2) in which a
Bluetooth-enabled cellphone (that the resident owns) serves
as the replacement when the gateway router fails or is absent
(e.g., when the resident is away from home). Specifically,
upon detection of the failure/absence of the gateway router,
a smart device (or the butler) triggers the Bluetooth Dial-Up
Networking Profile (DUN) mechanism[6] to turn the cellphone
into a wireless modem for Internet access. For convenience of
discussion, we call the former system architecture the “gate-
way mode”, and the latter the “cellphone mode”. Introducing
the cell phone and its associated DUN mechanism enhances
availability.
B. System Architecture of Butler Node
The butler node serves an important role in the home
environment. Its detailed internal architecture is depicted in
Figure 3. The architecture consists of three layers: OS, mid-
dleware, and application.
The OS layer is equipped with various communication
stacks and corresponding platform-dependentApplication Pro-
gramming Interfaces (APIs). The TCP/IP API and stack is
installed by default, so that the butler can access the Internet.
Depending on the family of peripherals to support, the other
stacks and APIs may include Bluetooth, ZigBee[7], Infrared
etc.
The middleware layer wrapps platform-dependent APIs
with unified Java APIs, and provides standard services to

Page 4

Fig. 2.Overall System Architecture – Cellphone Mode
Fig. 3. System Architecture of Butler Node
assisted living applications. From middleware layer above,
the runnables are Java [8] byte codes, which are platform-
independent.Specifically, the middleware consists of following
components:
1) Device Monitoring Daemons: These daemons monitors
the join/leave of peripheral devices in the environment,
and registers/de-registers the devices in the Device Reg-
istry Service.
2) Device Registry Service: This maintains a database
of peripherals available in the environment. Each entry
is an XML [9] file describing the device. The XML
file specifies at least the following properties: Device
Communication Paradigm, Address, and Application
Protocol. The Device Communication Paradigm can be
(but not limited to): Bluetooth, ZigBee, Wifi, USB,
and Infrared. Address is the unique address of the
device under its communication paradigm. Application
Protocol specifies the application layer protocol that
should be used to interact with the device, for example,
“mp3 player”, “text message display”. Different devices
may comply with the same application layer protocols.
Use of XML allows the standard, human-readable, and
machine-checkable specifications of the above proper-
ties. Note also that with the Device Monitoring Daemons
and the Device Registry Service, applications do not
have to bind with specific devices, but rather locate
proper devices at runtime by querying the Device Reg-
istry Service.
3) UnifiedApplication-Peripheral
APIs: Specificprogramming APIs under various
communication paradigms are different. For example,
the Java API for Wifi is the standard java.net.* package
[10], while the API for Bluetooth is JSR-82 [11].
The Unified Application-Peripheral Communication
APIs abstracts different communication APIs in a
consistent paradigm, which basically
well-known java.net.* APIs. This allows applications to
be developed independently of specific communication
APIs. Another feature of the Unified Application-
Peripheral Communication APIs is the adoption of
QoS request parameters. Users can specify their QoS
demands when establishing communication links, and
the middleware returns approved QoS guarantees.
All QoS related parameters conform to a predefined
extensible XML schema.
4) Other APIs from J2ME/J2SE: Either J2ME[12] (if the
butler is a PDA) or J2SE[13] (if the butler is a PC)
is installed on the butler as the runtime environment.
This means the J2ME/SE APIs are also available to
applications.
5) Internet Heartbeat Daemon: This daemon periodi-
cally checks the availability of Internet access through
gateway router (see Figure 1). When the gateway
router fails/recovers, this daemon activates/deactivates
the Bluetooth cellphone as a wireless modem (by in-
voking/terminating the DUN mechanism) for Internet
access.
6) Butler Main Daemon: This daemon is in charge of
managing (start, suspend, stop, restart etc.) all the appli-
cation daemons and middleware daemons on the butler.
The application layer is where various applications resides.
They are built on top of the unified APIs and services provided
by the middleware. Many of them can be daemons that runs
all-year-around. At the time of writing this article, we have
designed and implemented two applications: daily reminder
of taking medication and vital sign measurement, and will
discuss them in Section IV.
Communication
follows the
C. Security and Privacy Mechanism
The security mechanism currently employed in the assisted
living infrastructure concerns two aspects:
1) protecting information confidentiality;
2) ensuring data integrity in the home WLAN with link-
level authentication and encryption.
Protection of information confidentiality implies the need
to differentiate information visibility to different entities. For
example, when the smart medical device sends a message
that contains vital sign meansurements to the ALSP server,
the content of the message is meant to be interpreted only

Page 5

by designated clinicians. The ALSP server itself should not
be able to read the vital sign measurement. Rather, it should
only be able to read administrative information contained in
the message such as the ID of the resident. This requirement
is realized by using Simple Object Access Protocol (SOAP)
[14], an XML-based message format for interoperablemessage
communication among heterogeneous systems. In particular,
we have leveraged partial encryption supported in the encryp-
tion standard of SOAP [15]. For example, we can encrypt
administrative information and vital sign measurements sepa-
rately: we first encrypt only the vital sign measurements using
the encryption key between the smart medical device and the
clinician, and then the entire message (that includes both the
administrative information and the encrypted vital sign mea-
surements) using another encryption key known to the smart
device, the ALSP server, and the clinician. In this fashion,
a third-party cannot decrypt the message, the ALSP server
can only decrypt the administrative information (and knows
to which resident the corresponding vital sign measurement
belongs), and the designated clinician can decrypt the entire
message.
To protect communication in the home WLAN with link-
level authentication and encryption, we enable all the devices
in the home WLAN to share an authentication token (a
specialized encryption key). The gateway router uses this
token to authenticate a device before allowing it to use
the home WLAN. The authentication scheme follows Wi-Fi
Protected Access 2 (WPA2) [16], a subset of IEEE 802.11i[17]
security standard. WPA2 has two authentication modes: WPA2
Enterprise (WPA2-EAP) and WPA2 Personal (WPA2-PSK).
WPA2-EAP leverages IEEE 802.1x framework and authenti-
cates network nodes using Extensible Authentication Protocol
(EAP). In spite of its powerfulness, this mode is, however,
too heavy-weight due to the use of high-cost servers such as
Remote Authentication Dial-In User Service (RADIUS) server
and Certification Authority (CA). WPA2-PSK, on the other
hand, authenticates nodes using a token called the Pre-Shared
Key (PSK). It offers a light-weight solution that fits the need
for authenticating devices in the home WLAN. As such, we
adopt the latter in the software architecture.
Encryption is required for both preserving privacy and
protecting wireless communication from unauthorized use.
Context information such as encryption keys or certificates
have to be delivered to the involved devices. We use a
specialized USB memory stick, called Authentication Manager
for You (AMY), for configuring and managing encryption
contexts. A device (the gateway router, the butler, or a smart
device) is equipped with AMY software to automatically
recognize and install the context information when an AMY
is pluged into the device.
IV. IMPLEMENTATION OF APPLICATIONS ON TOP OF
PROPOSED SYSTEM ARCHITECTURE
With the software architecture in place, numerous applica-
tions can be built to facilitate elder people with their inde-
pendent/assisted living. At the time of writing the article, We
have designed and implemented two demo applications: daily
reminder of taking medication and vital sign measurement.
In the reminder application, events are scheduled by clini-
cians and caregivers for the resident (see Figure 4) through
interfaces provided by the ALSP server. In the home en-
vironment, the reminder daemon that resides on the butler
periodically polls the ASLP server. When it is time for
reminding residents of certain events, the reminder daemon
picks the most appropriate device and sends the reminding
message. For example, if the reminding message is an audio
clip, it may be forwarded to a Bluetooth earplug. On the other
hand, if it is a text message, it may be forwarded to a cellphone
or a TV (if either is active).
In the vital sign measurement application, the resident
measures his vital signs (such as glucose level, blood pressure,
heart bit rate, arterial oxyhemoglobin saturation level) with
Bluetooth enabled medical meters at home (see Figure 5).
The measurement results are then encrypted with the SOSP
technology (either by the device or by the butler if the device
is not smart), and sent to the ALSP server. In the clinic, an
authorized clinician can retrieve the vital sign measurements
of the resident at any time. Note that the personal behavior
profiling application can be readily implemented with the same
set of code, except that Bluetooth-enabled medical devices
have to be replaced by RFID or Ubisense readers.
V. RELATED WORK
The need for new technologies to facilitate assisted living
has recently received increasing attention both in industry and
academic research, and has become the focus of several R&D
projects. In what follows, we summarize existing projects,
and discuss the difference between the proposed and existing
research.
At the Center for Future Health (CFH) at University of
Rochester [18] the smart medical home prototype consists of
infrared sensors, computers, bio-sensors, and video cameras.
The key services to be provided are medical advisory which
provides a natural conversational interface between the pa-
tient and health care expert, motion and activity monitoring,
pathogen detection and skin care, and personal health care
record for consumer-provider decision support. The core sup-
porting technology to achieve the above services is a visual
system for object recognition and tracking. The component
project that comes closest to ours is called Middleware Linking
Applications and Networks (MiLAN), and aims to develop
middleware solutions to adapt applications to a changing
set of available resources in the smart medical home en-
vironment. Our research complements CFH in two aspects.
At the application level, the application domain of CFH is
health care settings such as nursing homes and hospitals. In
contrast, we focus on improving the quality of living in an
assisted living environment. At the infrastructure level, we
focus on laying a robust, dependable, and secure software
infrastructure that allows disparate technologies, software, and
wireless devices (of different protocol families) to be plugged
in a plug-and-play manner and operate with predictability and