2005-11-27, 5:15 pm(1) Grammars and rephrase some unclear statements – feedbacks from Mani

2005-11-26, 12:00 pm(1) Grammars and rephrase some unclear statements – feedbacks from Julan

2005-11-26, 12:00 pm(1) Minor Modifications

2005-11-25, 5:40 pm(1) Complete Evaluation (link)(2) Integrated feedbacks from Arun(3) Shorten Framework Section

2005-11-24, 10:50 pm(1) Add Conclusion (link)

2005-11-24, 8:00 pm(1) Add explanation to Figure 9 (link) – earlier feedbacks from Saurabh

2005-11-24, 5:45 pm(1) Add explanation to Figure 7 (link) – earlier feedbacks from Saurabh

2005-11-24, 5:00 pm(1) Add explanation to Figure 5 and Figure 6 (link) – earlier feedbacks from Saurabh

2005-11-24, 10:30 am(1) Strengthen Rapid Deployment and Scalability (link) – feedbacks from Laura

2005-11-24, 9:50 am(1) Rename some Subsection Titles in Introduction section(2) Add dual radios to reduce the cost (besides multi-resolution) (link)

2005-11-24, 8:00 am(1) Rewrite Abstract (link)

2005-11-24, 6:45 am(1) Some grammar errors - feedbacks from Laura

2005-11-23, 5:00 pm(1) Compare 802.11 and GSM (link) – new add(2) Argue Multi-Resolution Point (link) - feedbacks from Saurabh

2005-11-23, 2:40 pm(1) Add security discussion (link) – feedbacks from Saurabh(2) Add Comparison with CodeBlue (link) – feedbacks from Saurabh

2005-11-23, 5:45 pm(1) Rephrase Open Platform (link) - feedbacks from Saurabh

2005-11-23, 4:10 pm(1) Add P2P arguments (link) – feedbacks from Saurabh and Simon

Revision in Introduction Section - feedbacks from Ram

A Remote Medical Monitoring and Interacting SystemDavid Jea and Mani Srivastava

Department of Electrical EngineeringUniversity of California, Los Angeles

Los Angeles, CA 90095, USA

{dcjea & mbs}@ee.ucla.edu

Abstract - In this paper, we present the implementation of a remote monitoring and interacting system for medical applications. Recent advances in medical platforms have been focused on continuous and constant remote monitoring of a patient. Compared to existing solutions, our system has placed emphasis on remote interaction between a patient and a physician. We provide in this system capabilities to perform diagnosis and treatment over-the-air. Such system is valuable in instant reacting to emergency health alerts. Today, this emergency process of monitoring and feedback actuation is done by a self-contained device (such as an implantable cardioverter-defibrillator), which provides treatment automatically when detecting abnormalities. We believe that it is very important to involve the physician into this process of actuated treatment.

We accomplish this goal by virtually connecting a patient and a physician anytime anywhere. We propose a mixed two- and three- tier infrastructure that extends current three-tier architecture with a GSM/GPRS peer-to-peer channel. We present a working system that is built on top of commercial cellular phones and wireless sensor nodes. In our system, a physician can create and subscribe to ”interests” provided by a body sensor network deployed on a patient. An interest is defined as the useful information acquired from applying a series of computations to collected vital signals. Profiles of interests can be periodically delivered in the form of health status reports, or they can be used to trigger emergency health alerts immediately when abnormalities are detected. The advanced interactive capabilities of our system allow a remote physician to further query for detailed information, to create and subscribe to new interests, to set sensors parameters, and to trigger actuators for over-the-air treatment. Additionally, we introduce a concept of multi-resolution to help a physician identifies useful information from a huge amount of sensor data collected by the body sensor network on a patient and hence to reduce communication costs. This paper describes why our proposed infrastructure suits novel medical scenarios and outlines the design and implementation of our system.

I. INTRODUCTION

Medical monitoring applications have kept developing for decades in healthcare industry. These platforms come with constraints, for example, they may be closed-source platforms or provide service only in limited locations. To achieve a ubiquitous computing environment where patients can be monitored anywhere in the world through wearable sensors and network infrastructures, People have envisioned a wearable sensor system to be flexible in its customized configuration to suit unique attributes of each patient. Such a system should be able to monitor regular

vital signals and generate reports periodically to a server in a medical service network. Physicians are able to query these real-time reports or historical data through medical service networks to provide adequate and correct treatment accordingly. It is also made possible to identify abnormal signals and send out emergency alerts directly. Some emergency situations require instantaneous treatments. Such situations are identified by devices carried by (implanted in) patients, and treatments are triggered automatically.

1. State of the ArtRecently, many research groups and companies have

shown interest in applying body sensor networks (BSN) to remote medical monitoring services. They have described medical scenarios in which it is possible to attach sensor nodes to a patient. The small-sized sensor nodes can be worn by humans to perform sensing tasks and form a wireless body sensor network. Designated sensors are chosen to monitor different vital signals depending on the personal needs of a patient. Sensor nodes collect vital signals, and the preprocessed and stored information is then transmitted to a portable mobile device (PDA-class) that will further fuse the data to examine the patient’s health. Status reports are generated periodically; emergency alerts are triggered asynchronously whenever a pre-specified event occurs. These reports or alerts are uploaded to a server that is on the internet and belongs to the medical service network. When an emergency event takes place, the system proceeds to notify physicians. A physician can then track and diagnose patients by accessing the acquired information online. This is a three-tier architecture, in which the mobile device becomes a personal mobile hub [3] and manages interactions between wearable devices (body sensor networks) and medical service servers.

In the domain of commercialized products, the current state of the art has been centered on the development of self-contained sensor nodes. A typical modern device is a pacemaker or an implantable cardioverter-defibrillator (ICD) that contains multiple sensors, a microprocessor, a telemetry transceiver circuit (that allows monitoring and programming over-the-air), a pulse generator, and a power supply. Once an arrhythmia is detected by sensors, previously downloaded therapy algorithms are run to deliver electrical signals to the heart and pace the heartbeats properly. Commercial interests in integrating the infrastructure into medical systems have just started to

emerge. Some services currently allow patients to upload implanted cardiac device information to a clinic through the internet.

2. Our VisionWe envision that physicians should be virtually

connected to patients at all times. Not only routine checks, but appropriate and promptly triggered treatments need to be made possible to physicians through the employment of wearable actuators at the time of emergency. We believe that each patient is unique, software is error prone, and occasionally ambiguous situations are hard for machines to make a decision. Thus mechanisms provided by devices like ICD should be expanded by involving physicians in the remote treatment process. Physicians should be able to interact with the deployed system carried on a patient to query real-time information or historical data and provide adequate treatments over-the-air. Most current systems are dedicated to monitoring patients, and mechanisms for responding to emergency conditions are still lacking. In contrast, our presented system offers the capability of spontaneous interactions between physicians and patients. Figure 1 demonstrates this extension.

Figure 1. The Illustration of Extending Current Infrastructure with the Proposed Peer-to-Peer Extension

3. Limitations of Existing Systems and Our Solutions

First, instead of the conventional three-tier architecture, we extend the three-tier infrastructure (Figure 2) by adding a peer-to-peer connection layer beneath the middle tier, so it is flexible in terms of its mixed two- and three- tier structure. This infrastructure is similar to LionShare [45] P2P network infrastructure (proposed by Penn. State University), which has a combination of centralized and decentralized topology. The presented peer-to-peer connectivity provides a direct connection between a physician and a patient. This design improves interactive messaging latency by avoiding going through upper tier, and such latency reduction is crucial for emergency treatment. The proposed architecture also has better scalability and can be deployed in disaster circumstances (earthquake, etc) where we do not have the luxury of central server and where time to deployment is critical. Notice that we use the “peer-to-peer” terminology since our interactivity between two mobile devices is achieved through underlying SMPP (Short Message Peer-to-Peer Protocol).

Figure 2. Extended Three Tier Architecture

Second, most platforms connect personal mobile hub and medical service server through 802.11 standard. The major benefits of employing 802.11 are the high bandwidth and the readily available mature technology. However, the incurred disadvantages of limited access and roaming incapability have prohibited its use in instantaneously responding emergency situations. Considering that our cellular phones have generally way better connectivity than our laptops while travelling, we suggest that not only 802.11 but also the cellular system should be used to maximize the freedom of a patient. The continuous monitoring information should be stored in Flash memory and uploaded when an 802.11 network is available (or alternatively use a 2.5/3G cellular network with a higher fee). The emergency health alerts should be delivered through the GSM network to maximize possibilities that both the physician and the patient are “online”.

Third, one of the key limitations of a commercial system is the closed system. A Quote from the Medtronic website says it all -“The First-and-Only Remote Monitoring Service for People with Medtronic Cardiac Devices”. We believe that a successful eco-system should

be a system that benefits more people, and is built around open standards. Our project works toward this goal by exploring interfaces in between and within each tier. For example, any MIDP (Mobile Information Device Profile) 2.0 [47] enabled GSM device can install a MIDlet program that has been developed to interact with our system through open interface standards that we provide. And through standardizing the packet format, the sensor nodes are capable of communicating with each other regardless of the operating system they run (e.g. SOS [5] or TinyOS [10]).

4. Excess Costs and Its SolutionPrevious work [22] has observed that 10 MB of vital

signals are generated per day per user, and suggested that a major barrier of their project is the communication cost. The 2.5 (GPRS) and 3G (UMTS) cellular networks are chosen as the sole transmission medium between patients and a server. We consider the twofold solutions to reduce the communication cost: dual radios and multi-resolution data presentation. Devices with both GSM and 802.11 radios are already widely available in the market. 802.11 networks are high bandwidth and generally low-cost. Therefore, mass data generated from continuous monitoring are stored in Flash memory and uploaded whenever an 802.11 link is available. A GSM network, on the other hand, is used for higher priority transmissions, such as periodic summary reports or emergency alerts. We further introduce the concept of multi-resolution. A physician receives a summary report or emergency alert, and only pulls-in desired details to help remotely diagnose the patient. Multi-resolution is necessary for identifying valuable information among the stored huge data sample arrays. Blindly transmitting every single raw data sample not only induces high transmission cost but confuses the physician. Additionally, since one physician usually has many patients, our suggested filtering techniques and multi-resolution data reports are essential for practical realization.

5. Our Proposed SystemIn this paper, we investigate an extended three-tier

hierarchical infrastructure for the purpose of integrating body sensor networks, portable mobile devices, and medical service networks. The portable system carried by a patient provides multi-resolution information of underlying body sensor networks and peer to peer interaction capabilities, including sensor-data pushing, sensor-data retrieving, body network parameter setting, and actuator triggering. The infrastructure allows physicians/patients to diagnose/be diagnosed anywhere in the world that is covered under GSM networks. Our approach exploits the combinatory advantages of wireless sensor networks, SOS (Sensor Operating System) [5], personal mobile hub, J2ME [6] platform, GSM/GPRS technology, and internet web server (prototype system is shown in Figure 3). We incorporate them and embed the

whole package seamlessly in the current infrastructure of cellular networks. In summary, we present a modular design and implementation of a medical monitoring and interacting system. This system extends beyond conventional solutions in two dimensions: it provides peer-to-peer interaction and multi-resolution data presentation, both of which are shown to comply with current technology development.

Figure 3. The Prototype of Proposed System

6. The GoalsThe goals of our system are as follows.Simple and Easy: We want to build a practical

medical service system with interfaces for accessing the personal mobile hub and body sensor networks. Such system is easy to operate and requires no excessive technical training.

Accessibility and Multi-Resolution: We envision that physicians and patients should be virtually connected at all times. Meanwhile, they should still enjoy their privacy and freedom to travel. The physical connection only becomes active when emergency health conditions arise. Also, the system should provide patient information through a multi-resolution mechanism that effectively reduces communication cost for patients. Short overview summaries are being periodically sent and detail reports can be checked upon request.

Interaction and Low Latency: The system should report emergency immediately. These health alerts usually have a constrained time window within which to react. Physicians should be able to retrieve further information for detailed diagnosis and trigger necessary treatments in time. Therefore, it is essential for the system to yield low communication latency in both directions.

Rapid Deployment and Scalability: To help people even in developing countries, the system should utilize minimum efforts to setup. Fast deployment usually relies

on existing networks configured as a backbone. Mobile phone prevails over land-line telephones in many countries, and some developing countries have extensive mobile phone usages and only little fixed-line infrastructure [46]. Our proposed infrastructure guarantees scalability from two people (pure peer-to-peer) to a huge connected complex medical service networks (Figure 2).

Modular Components to achieve Affordability: Each hardware and software component of the system is loosely combined through a layered design with pre-defined interface. Thus companies with their own domain of knowledge can focus on improving products. We expect the modular components will bring the cost of the system down to an affordable price. And through a standardization process, companies in different industries can be profitable.

7. Realization of GoalsIn this paper we describe implementation of a body

sensor network, a personal mobile hub, and the peer-to-peer interactivity described in the proposed infrastructure. The system is implemented with Mica2 and Mica2dot [1] as body sensor network nodes and the Motorola V600 mobile phone as personal mobile hub. We present a peer-to-peer interactive system that transports multi-resolution data and has a simple command interface.

Our system meets the above goals by building on top of wireless sensor networks and GSM/GPRS technologies. The personal mobile hub uses MIDlet, a Java program for embedded device running J2ME virtual machine, to provide a graphical user interface that is simple enough to operate. The underlying communication medium relies on Short Message Service (SMS) [7] and Multimedia Messaging System (MMS) [8], both of which most users are already familiar with. When both patients and physicians are covered by GSM/GPRS networks, we call them virtually connected. The GSM/GPRS cellular network is by far the most popular mobile network in the world and thus provides a broad coverage area. Multi-resolution data naturally fit with SMS (2G), MMS (2.5G, 3G) protocols, each of which has its own limitation and is best suited for different resolution requirements. Interactions between patients and physicians are achieved mainly through SMS, which has a low latency on the order of seconds. In 2005, GSM had more than 2 billion subscribers and 76.2% technology market share [9]; and had nearly 40% growth rates in Africa, 35% in Americas and Eastern Europe, 30% in Middle East, and 20% in Asia Pacific. The maturity of GSM enables rapid deployment of a system with even only two users (a physician and a patient). In addition, our system does not conflict with, but extends existing complicated medical service networks. Our system uses "mote"-class devices [1] to construct wireless body sensor networks. Wearable sensors are connected through Analog or I2C interfaces [34]. Through modular software design, the platform can be re-configured for hardware characteristics and new monitoring or therapy

algorithms can be installed. Both hardware and software are replaceable and open-architectured, resulting in a cost-reasonable system. The system is helpful to patients as it provides real-time health care from physicians, beneficial to physicians for enabling a convenient and a ubiquitous way to diagnose patients, profitable to companies that manufacture hardware, profitable to software companies for providing integrated systems, and profitable to cellular networks operators by increasing messages traffic. Although our system can bypass medical service network companies through peer-to-peer channels, better services (historical data storage, interdisciplinary diagnosis, etc.) can only be achieved through medical networks. With the popularity of this system, the demand for these services will also expand accordingly.

8. The Contributions of this paperThis paper has the following three contributions.

First, it specifies the design and implementation of our work, in which we use commercial off-the-shelf products to demonstrate the feasibility of our proposed infrastructure. Second, it proposes an extended three-tier architecture for medical service scenarios by adding a parallel peer-to-peer layer underneath the mid layer. Such an architecture enhances scalability of our system and shortens response time to critical events. Finally, it proposes a fully interactive, multi-resolution model that is simple and intuitive to operate while being well suited for current GSM/GPRS/3G technologies.

9. Paper OrganizationThis paper is organized as follows. Section 2

describes a variety of related works on wearable computing, body sensor networks, personal mobile hub, medical service networks, and current commercial products. Section 3 provides a general framework for body sensor networks and personal mobile hub. Section 4 explains in detail our implementation. Evaluation results are presented in section 5. Section 6 discusses some of the issues that are relevant to a complete infrastructure. Section 7 concludes the paper.

Henceforth, we will use these acronyms. BSN for body sensor networks, PMH for personal mobile hub, ICD for implantable cardioverter-defibrillators.

II. RELATED WORKS

This section discusses related researches in the context of conventional three-tier hierarchy infrastructure, examines current commercial products, and addresses differences between these works and our proposed system. We note that the lowest layer (as shown in Fig. 2) in the three-tier architecture is the wearable computing platform or BSN. The PMH lies in the middle layer, and it is responsible for communicating with servers. Servers sit in the top layer and connect with each other to form medical service networks.

A. Body Sensor NetworksThe Mica family of sensor nodes [1], developed by the

University of California, Berkeley and manufactured by Crossbow, has been widely used in sensor network related academic researches and has been applied to many practical projects. Motes are supported with software environments such as Berkeley’s TinyOS [10], an event-driven operating system for sensor nodes, and UCLA’s SOS [5] that supports dynamic reconfigurability of software on motes.

Body Sensor Networks have been studied in the area of healthcare and clinical applications. CustoMed [11,12], a mobile medical monitoring and analysis system, developed at UCLA, constructs a body sensor networks using TinyOS/MICA2 platform. The collected vital signals are transmitted to and stored in PDA for examination. The UbiMon [13] project at Imperial College London also establishes its BSN on top of TinyOS and Berkeley motes platforms. A Bayesian framework for robust distributed sensing is proposed in [14]. A sensor Body Area Network developed at ETH Zürich [15] has been designed for context sensing. They argued that a combination of wireless and wired interface provides the best suite for wearable computing. MIT Media Lab has designed and implemented a modular platform for compact wireless sensing [16] and real-time transmission of sensor data from wearable sensors.

A generic body sensor network established by wireless sensor nodes differs from a traditional wearable computing system in four fundamental ways. First, by replacing wired connections with a wireless interface, a body sensor network improves in system robustness. The fact that disconnected wires may lead to malfunctioning of a traditional system makes wireless transmission interface a better choice. Second, customized wearable systems have high manufacturing and maintenance costs. Wireless sensor nodes can be bulk manufactured through standard industry process at an affordable cost, and can provide extra flexibility in system configuration. Third, in a wireless sensor network, nodes are smart enough to process and store information, thus applications are inherently distributed through the collaboration among the nodes. Finally, wireless links that connect the wearable sensor nodes are expected to be fairly dynamic. Human daily activities take place in diverse environments, in which channel characteristics might vary drastically within seconds. Reliable and efficient communications thus depend on the real-time adaptivity to link quality variations

B. Personal Mobile HubUsually, either Wearable Computing or BSN contains

an on-body base station or hub node in its architecture. This base station collects data from sensors, and then reports the sensed information back to remote server for processing. This device serves as the central intelligence unit for all the devices worn by the user, and supports multiple wireless protocols. The concept of this device has

been explored earlier in Intel Personal Server [17], a smaller than PDA-class device that a) holds personal information and personalized applications, and b) forms wireless connections to existing infrastructure while providing seamless interactions. The Intel Personal Server aims to become a natural part of everyday computing platforms. The IBM Personal Mobile Hub [3] acts as the proxy for wearable devices. This device plays several roles including data hub, mobile internet router, personal agent, personal repository, aggregator and service extender. It proposes a three-tier architecture and is designed from the start to be an open and extensible platform. The IBM project has received overwhelming responses from healthcare and pharmaceutical industries since its prototype demonstration. Our paper extends IBM’s three tier architecture and adopts the name "Personal Mobile Hub". The MIThril LiveNet system [18] is a flexible distributed mobile platform designed for healthcare applications. The main core of the system is a PDA device that provides Enchantment API for communication purposes, and Inference Engine for modeling and classification of sensor data.

C. Medical Service NetworksExtensive research efforts have been put to improve

the infrastructure of medical service networks. CodeBlue [4], developed by Harvard University, is a Sensor Network for medical care and is customized as an emergency message delivery system. It proposes a publish/subscribe multi-hop routing framework and provides device discovery protocols. A simple query interface tailored for medical applications is also presented. Codeblue is designed for ad hoc deployment in a disaster scenario setting, and does not enforce any tier architecture. Their new Pluto node is a mote-class device based on Telos mote design, and previous experiments were conducted in a homogeneous MicaZ mote network. Our system, in contrast, focuses on a daily medical scenario. It builds on a mixed two- or three-tier architecture. We have integrated the publish/subscribe framework and query interface, but left the discovery protocol and location tracking. We bypass their practical considerations in multihop routing and mobility by relying on the existing GSM network.

In the UbiMon project [19], the system architecture consists of five components: the BSN nodes, the local processing unit, the central server, the patient database and the workstation. This project focuses on monitoring the patients, and our proposed infrastructure completes their system by integrating actuators such as ICD into BSN and adding ability to interact with the system. AMON [20] is a wearable multi-parameter medical monitoring and alerting system developed by ETH Zürich. This system is based on a two-tier infrastructure where a wrist-worn unit is connected to stationary unit through the GSM networks. MobiHealth [21] is a project led by University of Twente. It consists of a vital signals' monitoring system, which utilizes a Body Area Network and an m-health service

platform based on the UMTS and GPRS networks. Their results in [22] indicate that one major issue will be high communication costs. Our proposed multi-resolution data presentation is a solution to this issue since the detail information is only transmitted when needed. The commercial medical service networks are covered in the next.D. Commercial Products

A typical commercial example of a self-contained sensor/actuator node is the Implantable Cardioverter-Defibrillators (ICD). This device automatically identifies abnormal events through sensors and then triggers a mild electrical shock for cardioversion or a strong electrical shock for defibrillation of the heart. Companies such as Guidant [23], Philips [24], Medtronic [2], St. Jude [25] have been manufacturing the product. ICD device is error-prone [26]. The reasons are software complexity, product quality and stability issues, and uniqueness of each patient. To reduce risks, we argue that specialists like physicians should also get involved in this process, and be able to assist the system to make decisions when ambiguous conditions or critical events take place. This interaction process should induce low latency, and the system can take over automatically if a decision does not get back in a prescribed time window.

There are currently few commercial medical service networks [27] in the market. In this study, we limit ourselves in referring medical service networks to only those which connect to patient-worn sensors. Among those networks, CardioNet [28] has the complete three tier architecture. The ECG monitor continuously transmits the patient's electrocardiogram to a special PDA via the 900 MHz wireless link. The PDA evaluates and stores the waveform, sends to a monitor center over a cellular network, where physicians are staffed around the clock. The Medtronic CareLink [2] network is established by a similar architecture. However, its Medtronic monitor (PMH) and Pacemaker (BSN) are only loosely coupled and require patients to put an antenna over the chest to fetch data. Also, data is uploaded to a website server through a phone line, which limits the freedom of traveling. Biotronik Home Monitoring Service [29] provides similar services as CardioNet does. A special cell phone, CardioMessenger, receives messages from ICD via the 402 to 405 MHz wireless link and forwards these messages to Biotronik Service Center through the cellular network.

E. Comparing the Proposed System to previous worksNone of the previous works propose the multi-

resolution data presentation concept. Multi-resolution can help dramatically reduce the communication costs, and more patients can thus afford the technology. We include actuators such as ICDs in our BSN scenario and extend the current three-tier architecture with a peer-to-peer communication layer that is fully interactive with low induced latency. Combined with underlying machine intelligence, we believe this extension can reduce risks

through consulting physicians in real-time. Our work aims to building an open infrastructure and open standard interfaces between hardware and software components. We believe more people can be benefited and more companies can profit in this way. Our work can co-exist with existing works, and thus increase the feasibility and practicability of the infrastructure proposed in this paper.

III FRAMEWORK FOR PERSONAL MOBILE HUB AND BODY SENSOR NETWORKS

The three-tier infrastructure described in Section 1 consists of the server in medical service networks, the PMH, and the BSN. In this paper, we skip medical service networks, which ought to be addressed separately, and focus on the design of the bottom two layers, PMH and BSN. Wireless sensor nodes nowadays are "smart" enough to perform in-network processing [43], but PMH itself is usually a PDA-class device with tremendous computation and communication power. In this section, instead of falling into the long debate over centralized system versus distributed systems, we consider a general medical monitoring and responding services framework that both PMH and BSN collaborate to achieve. We believe that placements of these components should be based on the trade-off matrix with different considerations. Also notice that some components are required on both PMH and BSN. Our framework is integrated from AT&T Media Alerting Services Framework [30], WearNET [31], CodeBlue [4] plus multi-resolution component we proposed, and interests profile we redesigned.

Figure 4. Framework of Proposed System

Figure 4 shows the blocks diagram of a high-level general framework for medical monitoring and responding services provided by PMH and BSN. This includes a set of wearable sensors that are used for monitoring. The acquired data is stored in to data storage or is processed directly. The processing algorithm evaluates data based on interests profile to determine if abnormality or specific events arise. The generated results, together with context information, location, and time, are then sent to multi-resolution data presentation component to generate a suitable report format. The publisher component gets these reports and delivers to subscribers. The query component takes user queries from communication component, and responds data messages or setups system parameters accordingly. The device therapy algorithm component takes command from communication component, selects algorithm, and then triggers actuator accordingly. We now describe in detail the components that enable this framework. Note that we skip some components which are beyond the scope of this paper.

1. Data Acquisition ComponentThe numerous sensor sources in market connect to

sensor node platform using three basic interfaces, analog [32], Serial Peripheral Interface (SPI) [33], and Inter-Integrated Circuit bus (I2C) [34]. Analog interface is the

easiest for software since most microcontrollers have built-in Analog to Digital Converter (ADC) is needed. However, care must be taken in matching sensor output voltage span to ADC input voltage span. SPI is a standard established by Motorola, and devices communicate through a master/slave mechanism. I2C was invented by Philips. Its ten-bit addressing scheme makes it possible to have over 1000 devices co-exist on the same bus and communicates at a 400 kbps fast mode. The data acquisition component has two main functionalities, managing low level interfaces to connected sensors and acquiring data from these sensors. The goals are to provide a unified interface and a ‘plug-and-play’ easiness for other software components.

2. Data Processing ComponentThe Data Processing component provides all the

required computation services for all other components. A complicated design reference would be MIThril Inference Engine [35] that applies statistical machine learning techniques to model and classify wearable sensor data. For example, N. Hughes proposed using Markov models for ECG interval analysis [36]. The unique spectral characteristics of an ECG waveform transformed through wavelet methods are more useful than raw time series data when interpreting a new previously unseen waveform. Our prototype provides simple mathematical library modules and the data processing is accomplished through wiring these modules based on interest profile.

3. Interests Profile ComponentInterests profile is basically a database that contains

users' interests, users can be patients or physicians or medical service providers. The two types of interests include normal interested physiological signals and abnormal medical alerts. Both should be identified automatically by system. The interests profile should be customized for a patient who wears the system. Physicians can subscribe to interests through communication component. After collecting data, the data processing component first evaluates if any condition matches against interests profile. An urgent medical alert will pass immediately to the publisher component when needed. If there is nothing critical, the system signals the interested information as a regular report to the publisher component. The main design difficulty of this component is how to describe users' interests. It should be simple for user, powerful to capture interests, efficient for storage, and suitable for machine processing.

4 Context Awareness Computing ComponentIn our system, context awareness is the ability to know

the activities of the patient(standing or walking) and environment states (weather condition) in addition to sensors sampling physiological signals. This context information can help clinical judgment on disease causes or progression [37]. More importantly, this component is a

requirement for medical actuator. For example, all ICDs in market have an embedded accelerometer to sense movements of patient's body, and some ICDs are also equipped with minute ventilation sensor, which responds to changes in respiration. These sensors construct the context of a patient, determine the correct therapy algorithm, and deliver appropriate pacing rates. This component interacts with publisher component and device therapy algorithm component to provide context information.

5. Multi-Resolution ComponentIn MobiHealth [22] research, the main barrier

preventing the popularity of the system is high communication cost. Our solution to this problem is "Multi-Resolution", whereby the information is transmitted in coarse grain and fine-grain data is pulled in only when disired. In 1995, C. Jacobs, A. Finkelstein and D. Salesin first apply multi-resolution for image query [38] that searches database by using a low-resolution image. D. Ganesan also used wavelet-based techniques to explore multi-resolution storage and drill-down search in sensor networks [39]. Medical reports or alerts are generated in multi-resolution manner and summaries of coarse resolution are transmitted. The fine resolution information can be requested by sending a drill-down query. Comparing with prior works, we address this problem from the different aspect of not only generating multi-resolution summaries of sampled data but also considering their presentation. In 2 (GSM), 2.5 (GPRS), 3G cellular networks, messages have different presentations, ranging from SMS (text) to MMS (image, video) to future protocols (3D model). For example, the physician receives following text message "patient: John, avg. heart rate:90, peak heart rate:162, in past hour". He decides to check out for John, so he requests a finer resolution version of this message and receives an image that shows how heart rate changes in the past hour associate with the activity (walking, running) context information. He selects a specific time segment and requests for further details. The full ECG video is returned for inspection. Traditional multi-resolution approaches consider only one medium, and we take additional consideration of different communication mediums. Therefore, one original message has several multi-resolution forms within each communication medium. This is an ongoing aspect of our research.

6. Publisher Component / Subscriber ComponentThe publisher/subscriber component is inherited from

Harvard CodeBlue framework. Physician or medical service provider can subscribe to sensor information on patients, while PMH will publish reports based on subscribed interests. Besides the routing layer described in CodeBlue, we include a simplified scenario by adding a peer-to-peer channel. The publisher component assumes that outer world, GSM/GPRS networks or internet, will handle routing once the destination is specified. The

discovery protocol provided in CodeBlue is used for end-user to know which sensors are deployed. A simplified and reasonable usage is that physicians will manually record the sensors deployed on a patient into medical service database. Borrowed from [30], the publisher component publishes three types of reports/alerts. First, scheduled reports are sent out periodically and are suitable for regular health status reports. Second, immediate alerts arise when urgent health issue is detected by data processing component and require immediate diagnosis from physicians. The system attempts to deliver this alert with minimum latency due to possible required in time treatment (defibrillation, etc.). However, device therapy algorithm component will take in charge automatically if in time response is not available from physicians. Third, predictive alerts are triggered when the progression of a monitored disease is turning worse or any predicted health issues rise.

7. Query ComponentThe query component provides simple mechanisms for

physician to request for more information or setup sensor parameters. The component takes query request and dispatches to related components such as multi-resolution component or data acquisition component. We use a query structure and query interface that is similar to CodeBlue, Directed Diffusion [40], and TinyDB [41].

8. Device Therapy Algorithm ComponentThe device therapy algorithms usually are proprietary

to medical companies, and designed by professionals, evaluated through careful clinical studies. The component triggers actuators to deliver an emergency or proper treatment. For example, most ICD devices incorporate anti-tachycardia algorithms to control the output electrical signals.

9. Wearable ActuatorsActuators are devices that transform an input electrical

signal into motion, here we use a loose definition and call a device actuator if it reacts to user commands and acts. Besides ICDs, examples of medically relevant actuators include wearable drug injection pumps and electrically controlled transdermal patches for drug delivery. As another example, consider a new cochlear implant that UK's National Physical Laboratory is developing to help deaf people. The device vibrates when hearing sound, and generates a small voltage to stimulate auditory nerve. Speakers and LEDs are common actuators that can be found on a sensor node, which can be used in warning a user when abnormal signals are detected.

10. Communication ComponentThis component handles input and output messaging to

upper server layer for a PMH or BSN device. It also supports communication channels for peer-to-peer connection. Users can specify their desired

communication mechanism in subscriber component, and publisher component will select the most appropriate communication medium for subscriber while publishing. Communication component on a BSN node communicates with PMH, and forms a star topology. Multi-hop routing is feasible on BSN and theoretically can lower communication cost. But our previous experimental results [42] suggest that when deploying nodes on human body, a small step-up of RF power can reduce packet loss rate greatly. Thus there are no clear benefits brought by multi-hop routing. However, a link quality aware MAC protocol should be developed to dynamically tune radio transmission power.

IV. IMPLEMENTATION

1. OverviewOur implementation realizes the medical scenario that

combines continuous remote monitoring, immediate emergency alerts, real-time interaction for querying details and triggering treatments (Figure 1). We described in this section the interaction commands our system supports, this interact ability is achieved through an underlying short message peer-to-peer channel. We also demonstrate in the initialization phase the capability of initializing our system from an internet website through a GPRS connection. Note that our proposed system should not be treated as a replacement of other similar works, but rather an extension to the existing medical application platforms.

We used off-the-shelf Motorola V600 mobile phone as Personal Mobile Hub (PMH) device, and Crossbow Mica2 and Mica2dot wireless sensor nodes to construct Body Sensor Networks (BSN). We choose Motorola V600 because the author uses this model, and it supports standard Java J2ME platform, and allows the developer to access serial port. Serial port is one of the commonly used methods to connect to sensor nodes. We choose Mica2 and Mica2dot because they are popular in sensor networks research, and numerous open-source software package support them. To implement the software architecture described in previous section, we wrote a Java MIDlet that runs on mobile phone serving as PMH. MIDlet is a Java program that runs on J2ME virtual machine usually in embedded devices. We expect that natural portability supported by Java will allow us to migrate PMH to different hardware platform with minimum effort. We chose SOS for sensor node operating system. SOS has been developed at UCLA’s Networked and Embedded Systems Laboratory, and is motivated by need of supporting dynamic reconfigurability of sensor nodes in a disruption-free manner. There are two advantages of using SOS in BSN. First, its modular system development perfectly matches to the framework we proposed in previous section. Second, BSN highly desires the ability to reconfigure a deployed system. Device therapy algorithm needs to be customized to suit progression of individual illness. New sensor nodes may be added in BSN to gain further insight of a patient, and new coordination algorithm

needs to be updated on existing nodes. Also, disruption-free reconfiguration ability is extremely important when considering the implanted medical devices. Simply look at recalls and lawsuits in ICD product and anyone will agree.

We have implemented an initial version of our proposed system (Figure 3). The prototype system covers components that are related to contributions of this paper and are part of system integrity. Other components described in the framework are still in progress. We focus on following domains that most medical monitoring system have not yet addressed: a peer-to-peer interactive channel, a multi-resolution data presentation, and actuation.

Figure 5. Internet Website Provides a Friendly and Easy Interface for System Initialization Process.

1. InitializationOur system supports three initialization methods: (1)

manually fetching an initialization script from a website through GPRS connection, (2) locally operating the PMH on a patient, and (3) remotely setting the system through a peer-to-peer Short Message channel. These three methods issues a series of commands to the system, and all the used commands are from the same commands set which will be described later through this section. The three initialization methods differ in user interface and the ways of delivering these commands to the system. This is the scenario where a physician manually selects desired sensors and customizes the initial system requirements for the patient right before deployment. We here describe the first initialization method, initialized through a website. This optional method is not a “must” requirement, a peer-to-peer can be used to initialize the system, but it provides easy batching of setup commands, and has a user friendly interface.

What are the sensors used in the system?

Specify sensor sampling rate

Who is this subscriber and his contact information

How does it interface with the system and which channel does it use?

Connect to the Apache website server

Specify Interests(1) Regular status report

Specify conditions that will trigger alert to subscriber

Specify Interests(2) Emergency Alerts

Figure 6. Result of Initialization Commands as a Initialization Script, Generated by Perl after Physician / Patient selects Choices Online.

A website (Figure 5) is used to initialize interests profile and subscriber component for patients. In the webpage, "General System Setups" section refers to system capabilities including sensors that will be used, their connection interfaces, and their sampling rates. "Subscriber Setups" describes the contact information of a subscriber. "Interests Setups" section allows a physician to setup his interests to a patient's vital signals. A regular report is triggered periodically, and emergency alerts are triggered immediately when specified condition is met. This interface is provided by an Apache server running on a Windows XP platform. We create a webpage to provide user interface. A Perl program sits on server translates the user choices into a series of commands (Figure 6), and stores into a script file. A physician then operates the PMH (the one that will be deployed to a patient) to open a http socket to connect to the website using GPRS. The PMH fetches this initialization script and setups the system accordingly (Figure 7).

We list the supported setup commands and corresponding interpretation here,

e (num) (nid): set (num) sensors on node (nid)

s (nid) (sid) (interface) (channel) (t) (unit): set sensor (sid) on node (nid) using (interface) on

(channel) with sample period (t) (unit)

interface: (a)nalog or (i)2cunit: (D)ay, (H)our, (M)inute, (S)econd, (m)illisecond

Figure 7. Snooping Raw Results of Initialization Packets. Screen Snapshots of V600. A series of Packets have been sent to Sensor Node 3 through Wireless Interface.

2. Interests Profile SetupsA fair amount of design effort has been focused on

describing and implementing interests. An interest combines a series of computation modules by wiring one to another to form a linear dataflow graph. An interest setup command has following format and interpretation,

a (nid) (sid) (interest) [(delta)|(comp)|(insize)]+: add interest for (nid) node, (sid) sensor, (interest) is

[when input buffer (insize) is full, perform (comp) on input data buffer, output results to next layer buffer, clean oldest (delta) input data buffer]+

It is implemented as a mechanism that wires FIFO queues in a module (Figure 8). The sensor is sampled at a given frequency (specified by commands described earlier), thus generating input data samples at a fixed rate. The incoming samples fill into a buffer which upon filling is delivered to the computation module. The computation results are stored in an output buffer (which also serves as the input buffer for computation module in next layer). Then the system creates a new buffer that has contents copied from input buffer. It cleans the oldest data region of the newly created buffer to provide enough requested amount (delta) room for future coming input data. This provides a sliding window over the input sample stream. When the input buffer of next layer module fills, it again repeats above compute-store-create-clean actions.

For example, "a 3 0 1 8|AVG|8 2|RPT|2" means that interest 1 performs average computation on every eight samples collected by sensor 0 of node 3, the resulting average value is pushed into report module, and reports back every time when it has two average values in the buffer. Another example, "a 3 0 2 8|AVG|16 4|

Setup node 3, sensor 0 is on Analog interface using channel 1. It has a sampling rate 200 milliseconds.

Add interest id 4. It is defined as wiring sample outputs from sensor 0 on node 3 to the computation module ‘MIN’ (minimum). The ‘MIN’ module is then wired back to ‘RPT’ module (report).

The buffer size between two modules

Report size

A subscription that will send to 3106009321. It is generated when receives an Interest 3, a 4, and a 2. AND describes all the conditions must fulfil. *1 means “always true”.

The alert generated when any condition rises (OR). These conditions are (a) when interest 3 less than 36 (b) when interest 3 greater than 39.

Interest ID

InterestID

Which module should this module wire to? What’s the buffer size in between

The packet used to setup sensor interface and channel of node 3 The packet used to setup

sampling rate of node 3

MAX|8 1|RPT|1" describes interest 2 as performing average computation on every 16 samples collected by sensor 0 of node 3, clean oldest 8 samples and push the result average value to maximum computation module. Every time when maximum module has 8 input values (from average module), it finds the maximum value among these 8 averages and then cleans the oldest 4 maximum values. It then reports back this result. Through this wiring mechanism between computation modules, our system provides users a simple but flexible and powerful way to describe their interests. Also, these computation modules are not difficult to design and implement. For proof of concept in the prototype system, we currently support four computation modules, AVG, MAX, MIN, COUNT. Besides the first three most common modules, COUNT module counts the number of times that a signal exceeds a given threshold.

Figure 8. Interests Wiring Mechanism

Instead of Java on PMH, we implemented the computation modules using SOS on sensor nodes for following reasons. First, we would like to minimize reliability problems caused by unstable wireless links. If all BSN nodes dump their sensors samples to PMH, the congested traffic will easily lose packets, which increases design complexity to handle discontinuous data samples. Second, we would like to investigate customized configuration capabilities of sensor nodes. Third, our interest model wires various computation modules and SOS’s ability to tranfer ownership of dynamically allocated memory between modules simplifies implementation.

Figure 9 shows a backend snooping of raw result packets after sending three interest setup commands. Every 64 data samples generates one MAX interest, one MIN interest, and one AVG interest. Each interest contains eight values. Note that some data packets are lost due to congestion with interests.

(1) a 3 0 4 8|MAX|8 8|RPT|8(2) a 3 0 3 8|MIN|8 8|RPT|8(3) a 3 0 2 8|AVG|8 8|RPT|8

Figure 9. Snooping Results after sending Three Interest Setup Commands (MAX, MIN, AVG) to MICA2. The Received Interests are computed from Data Samples

3. SubscriptionThe above mechanism does not yet complete

implementation of an interest. We also provide a command for setting conditions while subscribing to these interests (Figure 10). Besides continuously monitoring, these filters can remove unnecessary information and only report the interested information to the subscriber (physician). If necessary, the subscriber can then conduct detailed inspection through query command. This reduces information overload on physician while keeping him aware of detected health alerts. The subscription takes following format and interpretation,

b (nid) (sid) (description) (contact) (condition) [(interest)|(op)|(threshold)]+

: subscriber interested in [(interest) that (op) (threshold)]+ on node (nid) and sensor (sid). when

The subscribed Interests is now transmitted back every 64 data samples. (we specified in the commands that each interest has 8 results, each result is calculated from 8 samples)

Use PC to snoop data samples

MIN

The minimum of these 8 samples is 0x19a, and this result is stored into MIN interest report 4

The maximum of these 8 samples is 0x1aa, and this result is stored into MAX interest report 3

Missing samples due to TX buffer contention. Two data samples packets were drop every eight data sample packets

MAX

AVG

(conditions) fulfill, report to (contact) with the (description)

op: <, >, =, *1(always true)conditions: AND, OR

Figure 10. Sending and Receiving Subscription Command through Short Message

We present some examples to present a more intuitive understanding of this mechanism. Assume three interests have been setup using commands described earlier, where sensor 0 on node 3 has three interests 1, 2, 3. Each performs MAX, MIN, AVG computation every eight samples, and report back to PMH when collects eight results. Then following subscription command will send a report to the provided contact every time the PMH receives each of three interests.

b 3 0 MAX|MIN|AVG 3106009321 AND 1*1:2*1:3*1This subscription command describes that

"3106009321" subscribes to a report on BSN node 3, sensor 0. A report will be sent out when PMH receives interests 1, 2, and 3. The "*1" after interest id means always true, and sets up whenever PMH receives the interest. "AND" condition requires that PMH receives each interest 1, 2, 3 at least once. The result of continuous monitoring example is shown in Figure 11.

Another example triggers an alert whenever the received average temperature samples less than 36 degree or greater than 39 degree.

b 3 0 TempAlert!! 3106009321 OR 3<36:3>39"OR" condition requires sending out the alert to "3106009321" when any of the condition arises. "3" refers to interest 3 which is the average temperature samples setup up earlier. Note that PMH receives 8 average values at a time. As long as one value among the eight fulfills any of two conditions (<36 or >39), the alert will be sent out. The result of emergency alert example is shown in Figure 11.

Figure 11. The Subscriber receives Periodic Report (left) and Emergency Alert (right)

4. Multi-Resolution QueryOur work focuses on issuing queries over recent

historical data. The system supports a simple query format,

q (nid) (sid) (contact) (interest) (start) (end) (resolution) (medium)

: query (interest) from node (nid) sensor (sid) between (start,end) using (resolution) with (medium) presentation, and send to (contact)

The query command asked for stored information of an interest between a given time period, and specifies the desired resolution level and communication medium. A special interest id 0 refers to plain data stream. Our current implementation supports retrival of plain data streams. This data stream contains original data samples, and is transmitted to the subscriber (physician) when he/she asks for details. Figure 12 shows that after querying, the PMH on the patient sends fine resolution data report to the physician using long SMS. The receiving phone reassembles these message segments and plots the graph of received data points, which is then displayed on physician's handset.

Previous sampled data can be stored in distributed BSN or centralized PMH, but our implementation does not include storing data in file system. This is because our testing device Motorola V600 does not support J2ME File Connection API. The JSR (Java Specification Request) 75, which introduces ability to access file system, was finalized in June 2004. Also the SOS Flash File System support on sensor nodes is still under development. Therefore, we have not fully investigated the tradeoff between the two choices.

Using a peer-to-peer channel in GSM/GPRS cellular network, the message can be carried in different forms (text, image, etc.). We currently support standard SMS (Short Message Service) and long SMS (or concatenated SMS). The regular report or alert described earlier is sent through standard SMS. The fine-resolution query

described here carries larger content and is sent segmented over multiple messages (long SMS). The receiving phone then reassembles these segments into one long message. The MMS (Multimedia Messaging System) is supported in JSR 205, Wireless Messaging API 2.0, which was finalized in June 2004. Our implementation does not include sending MMS. This is also due to our testing device V600 does not supporting this functionality. We plan to get a newer device to continuously investigate this multi-resolution query under different data presentation issues.

Figure 12. Fine Resolution Query Results

5. ActuationOur system currently supports following command and

its interpretation for triggering actuator nodes in BSN,

t (nid) (aid) (n) (algorithm) (parameter lists): trigger node (nid), actuator (aid) for (n) times, using

(algorithm) with parameters (parameter lists)

As discussed earlier, the treatment algorithms usually are proprietary and require numerous clinical studies to be designed. Therefore, for testing purposes, we use a simple LED blinking to demonstrate this ability, where the algorithm choose the LED specified in parameter 1, and triggers a blinking pattern indicated by the binary code of parameter 2. For example,

t 3 0 5 BLINK R DThe command will trigger node 3 and its actuator 0

(LEDs). The selected algorithm is BLINK, the given parameters are RED and 'D'. So the node 3 will blink RED led 5 times, and follows a blinking pattern 1101(D), where '1' has a longer turn-on time than '0'. The patient will see the red led on node 3 starts with two long blink, followed by a glimpse, then another long blink. This pattern will repeat 5 times in our given example. In real usage, the actuator example will be ICD or pacemaker that delivers voltage impulses to regulate the beating of the heart.

V. EVALUATION

With our implementation, we performed stress testing to the system. This was evaluated in four aspects, the

number of patients, the number of subscriptions, the number of interests, and the number of wiring modules.

1. Number of PatientsIt is expected that our system scales well with an

increasing number of patients, since rather than storing all data on physician's end, the information is distributed on each patient's own storage or onto medical service networks. The physician performs query actions to the individual patient (or network server) and pulls back information. Such action is not affected by the number of patients. Note that it is possible that more than one patient push reports (alerts) to the physician at the same time. However, SMS operates on a store-and-forward schema that usually guarantees delivery. We prove this by consecutively sending out 10 short messages, and all the messages are received successfully seconds later.

2. Number of SubscriptionsA subscription represents a report or an alert that will

deliver to the subscriber. It is composed by operating the interests and sends out a report or an alert when specified condition is met. Our implementation stores subscription information on the PMH, and the received interests are stored in the corresponding subscription objects for comparison against specified conditions. The system handles increasing number of subscriptions quite well. This is due to plenty of resources on PMH (examples as 100 KB heap size on Motorola V600). We tested the limits by continuously allocating subscription objects. We interchanged following two subscription commands until the system crashes. The first subscription involves three interests while the second one involves two interests.(1) b 3 0 MAX|MIN|AVG 3106009321 AND 3*1:4*1:2*1(2) b 3 0 TempAlert!! 3106009321 OR 2<36:2>39

We ran the experiment using simulator (to avoid damaging testing device) and allocated ~200 subscription objects before system crash. With advances in hardware (the Motorola V1050 released in 2005 supports a 512 KB heap size), we expect one patient will never exceeds this limitation for a BSN size network.

3. Number of InterestsAn interest is defined by user through wiring the

computation modules and specifying the buffer size in between. This is implemented on sensor node using SOS platform, and naturally expected to run into the scarce resources on the Mica motes. We are aware that this is not the only design option, and that an alternative would be to move these computations to the PMH level with the BSN nodes taking responsibility for maintaining a reliable data stream channel to PMH in the presence of increased traffic congestion from the BSN to PMH. However, it is of interest to explore the limitation of our current partitioning.

We first tested buffer allocation inside a computation module. We allocated a maximum available SOS memory

block (128 bytes) for one MIN module, and successfully find the minimum data samples stored in the buffer. In a three computation modules case, we can only at most allocate a 32 bytes buffer for each module for one interest. This is due to the "malloc" implementation inside SOS that has only three block sizes (16, 32, 128 bytes), and there are only a total of four 128 bytes memory blocks can be allocated.

Each sensor node can at most support four interests, the reason being these interest objects are stored in the main control module together with other data, and their total allocated size has to be less than 128 bytes ( the biggest memory block size). All these limitation can however be optimized by tuning SOS memory configuration file or redesigning the modules.

4. Number of Wiring ModulesWe here tested how many modules can be wired

within one interest. We created several pseudo modules to bypass data samples, and successfully wired six modules for one interest. We have not yet tested the maximum number of modules can be wired, since that also depends on the complexity of a computation module. Note that our current implementation is limited to allowing each module be wired at most once for one interest.

VI. DISCUSSION

Our work does not address practical issues that arise due to safety, security and privacy, and confidentiality. Our prototype system relies on SMS technology to achieve interaction between physicians and patients. However, SMS protocol does not support any form of encryption, and the plain-text sessions are completed over TCP/IP. Also, the proposed extended three-tier architecture provides a direct connection between two peers, this tunnel should be constructed only when they trust each other. To deal with these issues, a platform should refer to the Secure SMS Messaging [44] proposed by Nokia to communicate securely between two J2ME MIDlets.

VII. CONCLUSIONS

We have built a medical remote monitoring and interacting system that connects a physician and a patient. Ous system provides remote capabilities such as sensor parameter setting, interests profile creating, reports (alerts) subscribing and publishing, details querying, and treatment actuation. Using this physicians can perform diagnosis and treatment over-the-air in an emergency. Our system uses an extended three-tier infrastructure that incorporates peer-to-peer channels. We introduced the concept of multi-resolution to filter trivial information and reduce communication cost while being presenting information to the user in a form suitable for the selected resolution. We presented a realistic implementation using commercial off-the-shelf products. Our implementation spans three platforms (sensor nodes, mobile phone, PC) and three languages (C, Java, Perl). Our work integrated wireless

sensor networks, GSM/GPRS cellular networks, and internet. We hope that this paper motivates different research communities and attracts different industries.

ACKNOWLEDGEMENTS

Many thanks to Arun Somasundara, Julan Hsu, Laura K Balzano, Ram Kumar Rengaswamy, Saurabh Ganeriwal, and Simon Han for their valuable comments and revisions.

REFERENCES

[1] J. Polastre, R. Szewczyk, C. Sharp, D. Culler, The Mote Revolution: Low Power Wireless Sensor Network Devices, Hot Chips 2004, Aug, 2004[2] Medtronic, http://www.medtronic.com/[3] D. Husemann, C. Narayanaswami, M. Nidd, Personal Mobile Hub, Proc of 8th Intl Symposium on Wearable Computers (ISWC) 2004[4] CodeBlue, http://www.eecs.harvard.edu/~mdw/proj/codeblue[5] S. Han, R. Rengaswamy, R. Shea, E. Kohler, M. Srivastava, A Dynamic Operating System for Sensor Nodes, Mobisys, June 2005.[6] J2ME, http://java.sun.com/j2me/[7] GSM 03.40 and GSM 03.41[8] TS 22.140 and TS 23.140[9] http://www.gsmworld.com/roaming/GSM_WorldPoster2005C.pdf[10] TinyOS, http://www.tinyos.net[11] R. Jafari, A. Encarnacao, A. Zahoory, P. Brisk, H. Noshadi, M. Sarrafzadeh, Wireless Sensor Networks For Health Monitoring, The Second ACM/IEEE International Conference on Mobile and Ubiquitous Systems, July 2005, San Diego. CA.[12] R. Jafari, F. Dabiri, P. Brisk, M. Sarrafzadeh, CustoMed: A Power Optimized Customizable and Mobile Medical Monitoring and Analysis System, ACM HCI Challenges in Health Assessment Workshop in conjunction with CHI 2005, April 2005, Portland, OR[13] UbiMon, http://www.ubimon.org[14] S. Thiemjarus, B. Lo and G. Z. Yang, A Distributed Bayesian Framework for Body Sensor Networks, BSN 2005, April 2005[15] H. Junker, M. Stäger, G. Tröster, D. Blättler, and O. Salama,, Wireless Networks in Context Aware Wearable Systems, EWSN 2004, Jan. 2004.[16] A.Y. Benbasat and J.A. Paradiso, A Compact Modular Wireless Sensor Platform, IPSN 2005, April, 2005, pp. 410-415[17] R. Want, T. Pering, G. Danneels, M. Kumar, M.Sundar, J. Light, The Personal Server: Changing the Way We Think about Ubiquitous Computing. In Proceedings of Ubicomp 2002: 194-209.[18] M. Sung and A. "S." Pentland, MIThril LiveNet: Health and Lifestyle Networking, WAMES'04 at Mobisys'04, Boston, MA, June, 2004[19] J. W.P. Ng, B. P.L. Lo, O. Wells, M. Sloman, N Peters, A. Darzi, C. Toumazou, and G. Z. Yang, Ubiquitous Monitoring Environment for Wearable and Implantable Sensors (UbiMon), Ubicomp, Sep 2004.[20] U. Anliker et al., AMON: A Wearable Multiparameter Medical Monitoring and Alert System, IEEE Transactions on Information Technology in Biomedicine, Vol. 8, No. 4, Dec. 2004[21] MobiHealth, http://www.mobihealth.org/[22] D. Konstantas, A. van Halteren, R. Bults, K. Wac, V. Jones, I. Widya, Body Area Networks for Ambulant Patient Monitoring Over NExt Generation Public Wireless Networks, 3th IST Mobile Wireless Communications Summit 2004, June 2004[23] Guidant, http://www.guidant.com/[24] Philips, http://www.medical.philips.com/[25] St. Jude Medical, http://www.sjm.com/[26] L. Eggertson, Physicians want transparency as Guidant lawsuits grow, CMAJ. 2005 Oct 11;173(8):855-6.[27] P. E. Ross, Managing Care Through the Air, IEEE Spectrum, December 2004[28] Cardionet, http://www.cardionet.com/[29] Biotronik, http://www.biotronik.com[30] B. Wei, B. Renger, Y. Chen, R. Jana, H. Huang, L. Begeja, D. Gibbon, Z. Liu, B. Shahraray, MediaAlert: a broadcast video monitoring and alerting system for mobile users, MobiSys 2005, June, 2005[31] P. Lukowicz, H. Junker, M. Stäger, T. von Büren, G. Tröster, WearNET: A Distributed Multi-Sensor System for Context Aware Wearables, UbiComp 2002

[32] R. Mancini, Sensor to ADC - analog interface design, Texas Instruments, Application Notes SLYT173, May 2000[33] D. Kalinsky and R. Kalinsky, Introduction to Serial Peripheral Interface, Embedded Systems Programming, Feb. 2002[34] D. Kalinsky and R. Kalinsky, Introduction to I2C, Embedded Systems Programming, July 2001[35] Inference, http://www.media.mit.edu/wearables/mithril/inference/ [36] NP Hughes, L Tarassenko, SJ Roberts, Markov models for automated ECG interval analysis, Advances in Neural Information Processing Systems, 2004[37] K. V. Laerhoven et al. Medical Healthcare Monitoring with Wearable and Implantable Sensors, UbiHealth 2004, Sep 2004.[38] C. Jacobs, A. Finkelstein and D. Salesin, Fast Multiresolution Image Querying, Proceedings of SIGGRAPH 1995.[39] D. Ganesan, B. Greenstein, D. Perelyubski, D. Estrin, J. Heidemann, An Evaluation of Multiresolution Storage for Sensor Networks, SenSys’03, Nov. 2003[40] C. Intanagonwiwat, R. Govindan, and D. Estrin. Directed diffusion: A scalable and robust communication paradigm for sensor networks . MobiCOM ‘00, Aug. 2000.[41] S. Madden, M. Franklin, J. Hellerstein, and W. Hong. The Design of an Acquisitional Query Processor for Sensor Networks. SIGMOD, June 2003[42] D. Jea, M. B Srivastava, Packet Delivery Performance for On-Body Mica2dot Wireless Sensor Networks, SECON 2005, September 2005[43] D. Culler, D. Estrin, M. Srivastava, Overview of Sensor Networks, 2004 IEEE, Aug. 2004[44] A Brief Introduction to Secure SMS Messaging in MIDP, Nokia, Sep. 2003[45] LionShare: Connecting and Extending Peer-to-Peer Networks, A Penn State Proposal to the Andrew W. Mellon Foundation, Sep. 2003[46] http://en.wikipedia.org/wiki/Mobile_phone[47] Mobile Information Device Profile for J2ME, Version 2.0, JSR118 Expert Group