mobisys2006-draft-v03a.doc.doc
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
977
On Slideshare
977
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
0
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. 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
  • 2. A Remote Medical Monitoring and Interacting System David Jea and Mani Srivastava Department of Electrical Engineering University of California, Los Angeles Los Angeles, CA 90095, USA {dcjea & mbs}@ee.ucla.edu Abstract - In this paper, we present the implementation service networks to provide adequate and correct treatment of a remote monitoring and interacting system for medical accordingly. It is also made possible to identify abnormal applications. Recent advances in medical platforms have been signals and send out emergency alerts directly. Some focused on continuous and constant remote monitoring of a emergency situations require instantaneous treatments. patient. Compared to existing solutions, our system has Such situations are identified by devices carried by placed emphasis on remote interaction between a patient and a physician. We provide in this system capabilities to (implanted in) patients, and treatments are triggered perform diagnosis and treatment over-the-air. Such system is automatically. valuable in instant reacting to emergency health alerts. Today, this emergency process of monitoring and feedback 1. State of the Art actuation is done by a self-contained device (such as an Recently, many research groups and companies have implantable cardioverter-defibrillator), which provides shown interest in applying body sensor networks (BSN) to treatment automatically when detecting abnormalities. We remote medical monitoring services. They have described believe that it is very important to involve the physician into medical scenarios in which it is possible to attach sensor this process of actuated treatment. nodes to a patient. The small-sized sensor nodes can be We accomplish this goal by virtually connecting a patient worn by humans to perform sensing tasks and form a and a physician anytime anywhere. We propose a mixed two- wireless body sensor network. Designated sensors are and three- tier infrastructure that extends current three-tier architecture with a GSM/GPRS peer-to-peer channel. We chosen to monitor different vital signals depending on the present a working system that is built on top of commercial personal needs of a patient. Sensor nodes collect vital cellular phones and wireless sensor nodes. In our system, a signals, and the preprocessed and stored information is physician can create and subscribe to ”interests” provided by then transmitted to a portable mobile device (PDA-class) a body sensor network deployed on a patient. An interest is that will further fuse the data to examine the patient’s defined as the useful information acquired from applying a health. Status reports are generated periodically; series of computations to collected vital signals. Profiles of emergency alerts are triggered asynchronously whenever a interests can be periodically delivered in the form of health pre-specified event occurs. These reports or alerts are status reports, or they can be used to trigger emergency uploaded to a server that is on the internet and belongs to health alerts immediately when abnormalities are detected. the medical service network. When an emergency event The advanced interactive capabilities of our system allow a remote physician to further query for detailed information, to takes place, the system proceeds to notify physicians. A create and subscribe to new interests, to set sensors physician can then track and diagnose patients by parameters, and to trigger actuators for over-the-air accessing the acquired information online. This is a three- treatment. Additionally, we introduce a concept of multi- tier architecture, in which the mobile device becomes a resolution to help a physician identifies useful information personal mobile hub [3] and manages interactions between from a huge amount of sensor data collected by the body wearable devices (body sensor networks) and medical sensor network on a patient and hence to reduce service servers. communication costs. This paper describes why our In the domain of commercialized products, the current proposed infrastructure suits novel medical scenarios and state of the art has been centered on the development of outlines the design and implementation of our system. self-contained sensor nodes. A typical modern device is a I. INTRODUCTION pacemaker or an implantable cardioverter-defibrillator Medical monitoring applications have kept developing (ICD) that contains multiple sensors, a microprocessor, a for decades in healthcare industry. These platforms come telemetry transceiver circuit (that allows monitoring and with constraints, for example, they may be closed-source programming over-the-air), a pulse generator, and a power platforms or provide service only in limited locations. To supply. Once an arrhythmia is detected by sensors, achieve a ubiquitous computing environment where previously downloaded therapy algorithms are run to patients can be monitored anywhere in the world through deliver electrical signals to the heart and pace the wearable sensors and network infrastructures, People have heartbeats properly. Commercial interests in integrating envisioned a wearable sensor system to be flexible in its the infrastructure into medical systems have just started to customized configuration to suit unique attributes of each emerge. Some services currently allow patients to upload patient. Such a system should be able to monitor regular implanted cardiac device information to a clinic through vital signals and generate reports periodically to a server in the internet. a medical service network. Physicians are able to query these real-time reports or historical data through medical 2. Our Vision
  • 3. We envision that physicians should be virtually decentralized topology. The presented peer-to-peer connected to patients at all times. Not only routine checks, connectivity provides a direct connection between a but appropriate and promptly triggered treatments need to physician and a patient. This design improves interactive be made possible to physicians through the employment of messaging latency by avoiding going through upper tier, wearable actuators at the time of emergency. We believe and such latency reduction is crucial for emergency that each patient is unique, software is error prone, and treatment. The proposed architecture also has better occasionally ambiguous situations are hard for machines to scalability and can be deployed in disaster circumstances make a decision. Thus mechanisms provided by devices (earthquake, etc) where we do not have the luxury of central like ICD should be expanded by involving physicians in the server and where time to deployment is critical. Notice that remote treatment process. Physicians should be able to we use the “peer-to-peer” terminology since our interact with the deployed system carried on a patient to interactivity between two mobile devices is achieved query real-time information or historical data and provide through underlying SMPP (Short Message Peer-to-Peer adequate treatments over-the-air. Most current systems are Protocol). 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. Service Networks Figure 1 demonstrates this extension. Server Server Server Peer-to-peer Personal Personal Personal Connection Mobile Mobile Mobile Hub Hub Hub ASYNCHRONOUS Body Body Body FETCH Sensor Sensor Sensor Networks Networks Networks Body Sensors Network Figure 2. Extended Three Tier Architecture UPLOAD Second, most platforms connect personal mobile hub and medical service server through 802.11 standard. The Person major benefits of employing 802.11 are the high bandwidth Mobile Hub and the readily available mature technology. However, the Patient Physician Person Mobile Hub incurred disadvantages of limited access and roaming incapability have prohibited its use in instantaneously PROPOSED EXTENSION responding emergency situations. Considering that our cellular phones have generally way better connectivity than Person Mobile Hub our laptops while travelling, we suggest that not only 802.11 but also the cellular system should be used to Person maximize the freedom of a patient. The continuous Mobile Hub Body Sensors Network 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 Patient through the GSM network to maximize possibilities that Physician both the physician and the patient are “online”. Third, one of the key limitations of a commercial REAL-TIME INTERACTION system is the closed system. A Quote from the Medtronic Figure 1. The Illustration of Extending Current website says it all -“The First-and-Only Remote Monitoring Infrastructure with the Proposed Peer-to-Peer Service for People with Medtronic Cardiac Devices”. We Extension believe that a successful eco-system should be a system that 3. Limitations of Existing Systems and Our Solutions benefits more people, and is built around open standards. First, instead of the conventional three-tier architecture, Our project works toward this goal by exploring interfaces we extend the three-tier infrastructure (Figure 2) by adding in between and within each tier. For example, any MIDP a peer-to-peer connection layer beneath the middle tier, so it (Mobile Information Device Profile) 2.0 [47] enabled GSM is flexible in terms of its mixed two- and three- tier device can install a MIDlet program that has been structure. This infrastructure is similar to LionShare [45] developed to interact with our system through open P2P network infrastructure (proposed by Penn. State interface standards that we provide. And through University), which has a combination of centralized and standardizing the packet format, the sensor nodes are
  • 4. 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 Solution Previous 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 Figure 3. The Prototype of Proposed System the patient. Multi-resolution is necessary for identifying 6. The Goals valuable information among the stored huge data sample The goals of our system are as follows. arrays. Blindly transmitting every single raw data sample Simple and Easy: We want to build a practical not only induces high transmission cost but confuses the medical service system with interfaces for accessing the physician. Additionally, since one physician usually has personal mobile hub and body sensor networks. Such many patients, our suggested filtering techniques and system is easy to operate and requires no excessive multi-resolution data reports are essential for practical technical training. realization. Accessibility and Multi-Resolution: We envision that physicians and patients should be virtually connected at all 5. Our Proposed System times. Meanwhile, they should still enjoy their privacy and In this paper, we investigate an extended three-tier freedom to travel. The physical connection only becomes hierarchical infrastructure for the purpose of integrating active when emergency health conditions arise. Also, the body sensor networks, portable mobile devices, and system should provide patient information through a multi- medical service networks. The portable system carried by resolution mechanism that effectively reduces a patient provides multi-resolution information of communication cost for patients. Short overview underlying body sensor networks and peer to peer summaries are being periodically sent and detail reports interaction capabilities, including sensor-data pushing, can be checked upon request. sensor-data retrieving, body network parameter setting, and Interaction and Low Latency: The system should actuator triggering. The infrastructure allows report emergency immediately. These health alerts usually physicians/patients to diagnose/be diagnosed anywhere in have a constrained time window within which to react. the world that is covered under GSM networks. Our Physicians should be able to retrieve further information approach exploits the combinatory advantages of wireless for detailed diagnosis and trigger necessary treatments in sensor networks, SOS (Sensor Operating System) [5], time. Therefore, it is essential for the system to yield low personal mobile hub, J2ME [6] platform, GSM/GPRS communication latency in both directions. technology, and internet web server (prototype system is Rapid Deployment and Scalability: To help people shown in Figure 3). We incorporate them and embed the even in developing countries, the system should utilize whole package seamlessly in the current infrastructure of minimum efforts to setup. Fast deployment usually relies cellular networks. In summary, we present a modular on existing networks configured as a backbone. Mobile design and implementation of a medical monitoring and phone prevails over land-line telephones in many interacting system. This system extends beyond countries, and some developing countries have extensive conventional solutions in two dimensions: it provides peer- mobile phone usages and only little fixed-line to-peer interaction and multi-resolution data presentation, infrastructure [46]. Our proposed infrastructure guarantees both of which are shown to comply with current scalability from two people (pure peer-to-peer) to a huge technology development. 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-
  • 5. defined interface. Thus companies with their own domain popularity of this system, the demand for these services of knowledge can focus on improving products. We expect will also expand accordingly. the modular components will bring the cost of the system down to an affordable price. And through a 8. The Contributions of this paper standardization process, companies in different industries This paper has the following three contributions. can be profitable. First, it specifies the design and implementation of our work, in which we use commercial off-the-shelf products 7. Realization of Goals to demonstrate the feasibility of our proposed In this paper we describe implementation of a body infrastructure. Second, it proposes an extended three-tier sensor network, a personal mobile hub, and the peer-to- architecture for medical service scenarios by adding a peer interactivity described in the proposed infrastructure. parallel peer-to-peer layer underneath the mid layer. Such The system is implemented with Mica2 and Mica2dot [1] an architecture enhances scalability of our system and as body sensor network nodes and the Motorola V600 shortens response time to critical events. Finally, it mobile phone as personal mobile hub. We present a peer- proposes a fully interactive, multi-resolution model that is to-peer interactive system that transports multi-resolution simple and intuitive to operate while being well suited for data and has a simple command interface. current GSM/GPRS/3G technologies. Our system meets the above goals by building on top of wireless sensor networks and GSM/GPRS technologies. 9. Paper Organization The personal mobile hub uses MIDlet, a Java program for This paper is organized as follows. Section 2 embedded device running J2ME virtual machine, to describes a variety of related works on wearable provide a graphical user interface that is simple enough to computing, body sensor networks, personal mobile hub, operate. The underlying communication medium relies on medical service networks, and current commercial Short Message Service (SMS) [7] and Multimedia products. Section 3 provides a general framework for body Messaging System (MMS) [8], both of which most users sensor networks and personal mobile hub. Section 4 are already familiar with. When both patients and explains in detail our implementation. Evaluation results physicians are covered by GSM/GPRS networks, we call are presented in section 5. Section 6 discusses some of the them virtually connected. The GSM/GPRS cellular issues that are relevant to a complete infrastructure. network is by far the most popular mobile network in the Section 7 concludes the paper. world and thus provides a broad coverage area. Multi- Henceforth, we will use these acronyms. BSN for resolution data naturally fit with SMS (2G), MMS (2.5G, body sensor networks, PMH for personal mobile hub, ICD 3G) protocols, each of which has its own limitation and is for implantable cardioverter-defibrillators. best suited for different resolution requirements. II. RELATED WORKS Interactions between patients and physicians are achieved mainly through SMS, which has a low latency on the order This section discusses related researches in the context of seconds. In 2005, GSM had more than 2 billion of conventional three-tier hierarchy infrastructure, subscribers and 76.2% technology market share [9]; and examines current commercial products, and addresses had nearly 40% growth rates in Africa, 35% in Americas differences between these works and our proposed system. and Eastern Europe, 30% in Middle East, and 20% in Asia We note that the lowest layer (as shown in Fig. 2) in the Pacific. The maturity of GSM enables rapid deployment of three-tier architecture is the wearable computing platform a system with even only two users (a physician and a or BSN. The PMH lies in the middle layer, and it is patient). In addition, our system does not conflict with, but responsible for communicating with servers. Servers sit in extends existing complicated medical service networks. the top layer and connect with each other to form medical Our system uses "mote"-class devices [1] to construct service networks. wireless body sensor networks. Wearable sensors are connected through Analog or I2C interfaces [34]. Through A. Body Sensor Networks modular software design, the platform can be re-configured The Mica family of sensor nodes [1], developed by the for hardware characteristics and new monitoring or therapy University of California, Berkeley and manufactured by algorithms can be installed. Both hardware and software Crossbow, has been widely used in sensor network related are replaceable and open-architectured, resulting in a cost- academic researches and has been applied to many reasonable system. The system is helpful to patients as it practical projects. Motes are supported with software provides real-time health care from physicians, beneficial environments such as Berkeley’s TinyOS [10], an event- to physicians for enabling a convenient and a ubiquitous driven operating system for sensor nodes, and UCLA’s way to diagnose patients, profitable to companies that SOS [5] that supports dynamic reconfigurability of manufacture hardware, profitable to software companies software on motes. for providing integrated systems, and profitable to cellular Body Sensor Networks have been studied in the area networks operators by increasing messages traffic. of healthcare and clinical applications. CustoMed [11,12], Although our system can bypass medical service network a mobile medical monitoring and analysis system, companies through peer-to-peer channels, better services developed at UCLA, constructs a body sensor networks (historical data storage, interdisciplinary diagnosis, etc.) using TinyOS/MICA2 platform. The collected vital signals can only be achieved through medical networks. With the are transmitted to and stored in PDA for examination. The
  • 6. UbiMon [13] project at Imperial College London also that provides Enchantment API for communication establishes its BSN on top of TinyOS and Berkeley motes purposes, and Inference Engine for modeling and platforms. A Bayesian framework for robust distributed classification of sensor data. sensing is proposed in [14]. A sensor Body Area Network developed at ETH Zürich [15] has been designed for C. Medical Service Networks context sensing. They argued that a combination of Extensive research efforts have been put to improve wireless and wired interface provides the best suite for the infrastructure of medical service networks. CodeBlue wearable computing. MIT Media Lab has designed and [4], developed by Harvard University, is a Sensor Network implemented a modular platform for compact wireless for medical care and is customized as an emergency sensing [16] and real-time transmission of sensor data from message delivery system. It proposes a publish/subscribe wearable sensors. multi-hop routing framework and provides device A generic body sensor network established by wireless discovery protocols. A simple query interface tailored for sensor nodes differs from a traditional wearable computing medical applications is also presented. Codeblue is system in four fundamental ways. First, by replacing wired designed for ad hoc deployment in a disaster scenario connections with a wireless interface, a body sensor setting, and does not enforce any tier architecture. Their network improves in system robustness. The fact that new Pluto node is a mote-class device based on Telos mote disconnected wires may lead to malfunctioning of a design, and previous experiments were conducted in a traditional system makes wireless transmission interface a homogeneous MicaZ mote network. Our system, in better choice. Second, customized wearable systems have contrast, focuses on a daily medical scenario. It builds on a high manufacturing and maintenance costs. Wireless mixed two- or three-tier architecture. We have integrated sensor nodes can be bulk manufactured through standard the publish/subscribe framework and query interface, but industry process at an affordable cost, and can provide left the discovery protocol and location tracking. We extra flexibility in system configuration. Third, in a bypass their practical considerations in multihop routing wireless sensor network, nodes are smart enough to process and mobility by relying on the existing GSM network. and store information, thus applications are inherently In the UbiMon project [19], the system architecture distributed through the collaboration among the nodes. consists of five components: the BSN nodes, the local Finally, wireless links that connect the wearable sensor processing unit, the central server, the patient database and nodes are expected to be fairly dynamic. Human daily the workstation. This project focuses on monitoring the activities take place in diverse environments, in which patients, and our proposed infrastructure completes their channel characteristics might vary drastically within system by integrating actuators such as ICD into BSN and seconds. Reliable and efficient communications thus adding ability to interact with the system. AMON [20] is a depend on the real-time adaptivity to link quality variations wearable multi-parameter medical monitoring and alerting system developed by ETH Zürich. This system is based on B. Personal Mobile Hub a two-tier infrastructure where a wrist-worn unit is Usually, either Wearable Computing or BSN contains connected to stationary unit through the GSM networks. an on-body base station or hub node in its architecture. MobiHealth [21] is a project led by University of Twente. This base station collects data from sensors, and then It consists of a vital signals' monitoring system, which reports the sensed information back to remote server for utilizes a Body Area Network and an m-health service processing. This device serves as the central intelligence platform based on the UMTS and GPRS networks. Their unit for all the devices worn by the user, and supports results in [22] indicate that one major issue will be high multiple wireless protocols. The concept of this device has communication costs. Our proposed multi-resolution data been explored earlier in Intel Personal Server [17], a presentation is a solution to this issue since the detail smaller than PDA-class device that a) holds personal information is only transmitted when needed. The information and personalized applications, and b) forms commercial medical service networks are covered in the wireless connections to existing infrastructure while next. providing seamless interactions. The Intel Personal Server D. Commercial Products aims to become a natural part of everyday computing A typical commercial example of a self-contained platforms. The IBM Personal Mobile Hub [3] acts as the sensor/actuator node is the Implantable Cardioverter- proxy for wearable devices. This device plays several Defibrillators (ICD). This device automatically identifies roles including data hub, mobile internet router, personal abnormal events through sensors and then triggers a mild agent, personal repository, aggregator and service extender. electrical shock for cardioversion or a strong electrical It proposes a three-tier architecture and is designed from shock for defibrillation of the heart. Companies such as the start to be an open and extensible platform. The IBM Guidant [23], Philips [24], Medtronic [2], St. Jude [25] project has received overwhelming responses from have been manufacturing the product. ICD device is error- healthcare and pharmaceutical industries since its prone [26]. The reasons are software complexity, product prototype demonstration. Our paper extends IBM’s three quality and stability issues, and uniqueness of each patient. tier architecture and adopts the name "Personal Mobile To reduce risks, we argue that specialists like physicians Hub". The MIThril LiveNet system [18] is a flexible should also get involved in this process, and be able to distributed mobile platform designed for healthcare assist the system to make decisions when ambiguous applications. The main core of the system is a PDA device conditions or critical events take place. This interaction
  • 7. process should induce low latency, and the system can take that some components are required on both PMH and BSN. over automatically if a decision does not get back in a Our framework is integrated from AT&T Media Alerting prescribed time window. Services Framework [30], WearNET [31], CodeBlue [4] There are currently few commercial medical service plus multi-resolution component we proposed, and interests networks [27] in the market. In this study, we limit profile we redesigned. 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 Wearable patient's electrocardiogram to a special PDA via the 900 Sensors Interests Profile MHz wireless link. The PDA evaluates and stores the waveform, sends to a monitor center over a cellular Context network, where physicians are staffed around the clock. Data Data Awareness Acquisition Processing The Medtronic CareLink [2] network is established by a Computing similar architecture. However, its Medtronic monitor (PMH) and Pacemaker (BSN) are only loosely coupled and Location require patients to put an antenna over the chest to fetch Data Storage data. Also, data is uploaded to a website server through a phone line, which limits the freedom of traveling. Multi-resolution Biotronik Home Monitoring Service [29] provides similar Query Data Presentation services as CardioNet does. A special cell phone, CardioMessenger, receives messages from ICD via the 402 Time Publisher / Synchronization to 405 MHz wireless link and forwards these messages to Power Subscriber Biotronik Service Center through the cellular network. Management E. Comparing the Proposed System to previous works Device Therapy None of the previous works propose the multi- Algorithm Communication resolution data presentation concept. Multi-resolution can help dramatically reduce the communication costs, and Peer-to-peer Personal more patients can thus afford the technology. We include Mobile actuators such as ICDs in our BSN scenario and extend the Wearable Hub current three-tier architecture with a peer-to-peer Actuators Server communication layer that is fully interactive with low Medical Service Server induced latency. Combined with underlying machine Networks 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 Figure 4. Framework of Proposed System interfaces between hardware and software components. We believe more people can be benefited and more companies Figure 4 shows the blocks diagram of a high-level can profit in this way. Our work can co-exist with existing general framework for medical monitoring and responding works, and thus increase the feasibility and practicability services provided by PMH and BSN. This includes a set of of the infrastructure proposed in this paper. wearable sensors that are used for monitoring. The III FRAMEWORK FOR PERSONAL MOBILE HUB AND acquired data is stored in to data storage or is processed BODY SENSOR NETWORKS directly. The processing algorithm evaluates data based on interests profile to determine if abnormality or specific The three-tier infrastructure described in Section 1 events arise. The generated results, together with context consists of the server in medical service networks, the information, location, and time, are then sent to multi- PMH, and the BSN. In this paper, we skip medical service resolution data presentation component to generate a networks, which ought to be addressed separately, and suitable report format. The publisher component gets these focus on the design of the bottom two layers, PMH and reports and delivers to subscribers. The query component BSN. Wireless sensor nodes nowadays are "smart" enough takes user queries from communication component, and to perform in-network processing [43], but PMH itself is responds data messages or setups system parameters usually a PDA-class device with tremendous computation accordingly. The device therapy algorithm component and communication power. In this section, instead of takes command from communication component, selects falling into the long debate over centralized system versus algorithm, and then triggers actuator accordingly. We now distributed systems, we consider a general medical describe in detail the components that enable this monitoring and responding services framework that both framework. Note that we skip some components which are PMH and BSN collaborate to achieve. We believe that beyond the scope of this paper. placements of these components should be based on the trade-off matrix with different considerations. Also notice 1. Data Acquisition Component
  • 8. The numerous sensor sources in market connect to or progression [37]. More importantly, this component is a sensor node platform using three basic interfaces, analog requirement for medical actuator. For example, all ICDs in [32], Serial Peripheral Interface (SPI) [33], and Inter- market have an embedded accelerometer to sense Integrated Circuit bus (I2C) [34]. Analog interface is the movements of patient's body, and some ICDs are also easiest for software since most microcontrollers have built- equipped with minute ventilation sensor, which responds to in Analog to Digital Converter (ADC) is needed. changes in respiration. These sensors construct the context However, care must be taken in matching sensor output of a patient, determine the correct therapy algorithm, and voltage span to ADC input voltage span. SPI is a standard deliver appropriate pacing rates. This component interacts established by Motorola, and devices communicate through with publisher component and device therapy algorithm a master/slave mechanism. I2C was invented by Philips. component to provide context information. Its ten-bit addressing scheme makes it possible to have over 1000 devices co-exist on the same bus and 5. Multi-Resolution Component communicates at a 400 kbps fast mode. The data In MobiHealth [22] research, the main barrier acquisition component has two main functionalities, preventing the popularity of the system is high managing low level interfaces to connected sensors and communication cost. Our solution to this problem is acquiring data from these sensors. The goals are to provide "Multi-Resolution", whereby the information is transmitted a unified interface and a ‘plug-and-play’ easiness for other in coarse grain and fine-grain data is pulled in only when software components. disired. In 1995, C. Jacobs, A. Finkelstein and D. Salesin first apply multi-resolution for image query [38] that 2. Data Processing Component searches database by using a low-resolution image. D. The Data Processing component provides all the Ganesan also used wavelet-based techniques to explore required computation services for all other components. A multi-resolution storage and drill-down search in sensor complicated design reference would be MIThril Inference networks [39]. Medical reports or alerts are generated in Engine [35] that applies statistical machine learning multi-resolution manner and summaries of coarse techniques to model and classify wearable sensor data. For resolution are transmitted. The fine resolution information example, N. Hughes proposed using Markov models for can be requested by sending a drill-down query. ECG interval analysis [36]. The unique spectral Comparing with prior works, we address this problem from characteristics of an ECG waveform transformed through the different aspect of not only generating multi-resolution wavelet methods are more useful than raw time series data summaries of sampled data but also considering their when interpreting a new previously unseen waveform. Our presentation. In 2 (GSM), 2.5 (GPRS), 3G cellular prototype provides simple mathematical library modules networks, messages have different presentations, ranging and the data processing is accomplished through wiring from SMS (text) to MMS (image, video) to future these modules based on interest profile. protocols (3D model). For example, the physician receives following text message "patient: John, avg. heart rate:90, 3. Interests Profile Component peak heart rate:162, in past hour". He decides to check out Interests profile is basically a database that contains for John, so he requests a finer resolution version of this users' interests, users can be patients or physicians or message and receives an image that shows how heart rate medical service providers. The two types of interests changes in the past hour associate with the activity include normal interested physiological signals and (walking, running) context information. He selects a abnormal medical alerts. Both should be identified specific time segment and requests for further details. The automatically by system. The interests profile should be full ECG video is returned for inspection. Traditional customized for a patient who wears the system. Physicians multi-resolution approaches consider only one medium, can subscribe to interests through communication and we take additional consideration of different component. After collecting data, the data processing communication mediums. Therefore, one original message component first evaluates if any condition matches against has several multi-resolution forms within each interests profile. An urgent medical alert will pass communication medium. This is an ongoing aspect of our immediately to the publisher component when needed. If research. there is nothing critical, the system signals the interested information as a regular report to the publisher component. 6. Publisher Component / Subscriber Component The main design difficulty of this component is how to The publisher/subscriber component is inherited from describe users' interests. It should be simple for user, Harvard CodeBlue framework. Physician or medical powerful to capture interests, efficient for storage, and service provider can subscribe to sensor information on suitable for machine processing. patients, while PMH will publish reports based on subscribed interests. Besides the routing layer described in 4 Context Awareness Computing Component CodeBlue, we include a simplified scenario by adding a In our system, context awareness is the ability to know peer-to-peer channel. The publisher component assumes the activities of the patient(standing or walking) and that outer world, GSM/GPRS networks or internet, will environment states (weather condition) in addition to handle routing once the destination is specified. The sensors sampling physiological signals. This context discovery protocol provided in CodeBlue is used for end- information can help clinical judgment on disease causes user to know which sensors are deployed. A simplified and
  • 9. reasonable usage is that physicians will manually record feasible on BSN and theoretically can lower the sensors deployed on a patient into medical service communication cost. But our previous experimental results database. Borrowed from [30], the publisher component [42] suggest that when deploying nodes on human body, a publishes three types of reports/alerts. First, scheduled small step-up of RF power can reduce packet loss rate reports are sent out periodically and are suitable for regular greatly. Thus there are no clear benefits brought by multi- health status reports. Second, immediate alerts arise when hop routing. However, a link quality aware MAC protocol urgent health issue is detected by data processing should be developed to dynamically tune radio component and require immediate diagnosis from transmission power. physicians. The system attempts to deliver this alert with IV. IMPLEMENTATION minimum latency due to possible required in time treatment (defibrillation, etc.). However, device therapy 1. Overview algorithm component will take in charge automatically if Our implementation realizes the medical scenario that in time response is not available from physicians. Third, combines continuous remote monitoring, immediate predictive alerts are triggered when the progression of a emergency alerts, real-time interaction for querying details monitored disease is turning worse or any predicted health and triggering treatments (Figure 1). We described in this issues rise. section the interaction commands our system supports, this interact ability is achieved through an underlying short 7. Query Component message peer-to-peer channel. We also demonstrate in the The query component provides simple mechanisms for initialization phase the capability of initializing our system physician to request for more information or setup sensor from an internet website through a GPRS connection. Note parameters. The component takes query request and that our proposed system should not be treated as a dispatches to related components such as multi-resolution replacement of other similar works, but rather an extension component or data acquisition component. We use a query to the existing medical application platforms. structure and query interface that is similar to CodeBlue, We used off-the-shelf Motorola V600 mobile phone as Directed Diffusion [40], and TinyDB [41]. Personal Mobile Hub (PMH) device, and Crossbow Mica2 and Mica2dot wireless sensor nodes to construct Body 8. Device Therapy Algorithm Component Sensor Networks (BSN). We choose Motorola V600 The device therapy algorithms usually are proprietary because the author uses this model, and it supports standard to medical companies, and designed by professionals, Java J2ME platform, and allows the developer to access evaluated through careful clinical studies. The component serial port. Serial port is one of the commonly used triggers actuators to deliver an emergency or proper methods to connect to sensor nodes. We choose Mica2 and treatment. For example, most ICD devices incorporate Mica2dot because they are popular in sensor networks anti-tachycardia algorithms to control the output electrical research, and numerous open-source software package signals. support them. To implement the software architecture described in previous section, we wrote a Java MIDlet that 9. Wearable Actuators runs on mobile phone serving as PMH. MIDlet is a Java Actuators are devices that transform an input electrical program that runs on J2ME virtual machine usually in signal into motion, here we use a loose definition and call a embedded devices. We expect that natural portability device actuator if it reacts to user commands and acts. supported by Java will allow us to migrate PMH to Besides ICDs, examples of medically relevant actuators different hardware platform with minimum effort. We include wearable drug injection pumps and electrically chose SOS for sensor node operating system. SOS has controlled transdermal patches for drug delivery. As been developed at UCLA’s Networked and Embedded another example, consider a new cochlear implant that Systems Laboratory, and is motivated by need of UK's National Physical Laboratory is developing to help supporting dynamic reconfigurability of sensor nodes in a deaf people. The device vibrates when hearing sound, and disruption-free manner. There are two advantages of using generates a small voltage to stimulate auditory nerve. SOS in BSN. First, its modular system development Speakers and LEDs are common actuators that can be perfectly matches to the framework we proposed in found on a sensor node, which can be used in warning a previous section. Second, BSN highly desires the ability to user when abnormal signals are detected. reconfigure a deployed system. Device therapy algorithm needs to be customized to suit progression of individual 10. Communication Component illness. New sensor nodes may be added in BSN to gain This component handles input and output messaging to further insight of a patient, and new coordination algorithm upper server layer for a PMH or BSN device. It also needs to be updated on existing nodes. Also, disruption- supports communication channels for peer-to-peer free reconfiguration ability is extremely important when connection. Users can specify their desired considering the implanted medical devices. Simply look at communication mechanism in subscriber component, and recalls and lawsuits in ICD product and anyone will agree. publisher component will select the most appropriate We have implemented an initial version of our communication medium for subscriber while publishing. proposed system (Figure 3). The prototype system covers Communication component on a BSN node communicates components that are related to contributions of this paper with PMH, and forms a star topology. Multi-hop routing is and are part of system integrity. Other components
  • 10. described in the framework are still in progress. We focus Setup node 3, sensor 0 is on Analog interface using channel 1. It has a sampling rate 200 milliseconds. 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. The buffer size between two modules Connect to the Apache website server Interest ID Report size Interest ID What are the How does it interface with sensors used in the the system and which system? channel does it use? 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. Specify sensor sampling rate 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). Who is this subscriber and his A subscription that will send to 3106009321. It is generated when contact information receives an Interest 3, a 4, and a 2. AND describes all the Specify Interests (1) Regular status report conditions must fulfil. *1 means “always true”. Specify Interests Figure 6. Result of Initialization Commands as a (2) Emergency Alerts Initialization Script, Generated by Perl after Physician / Specify conditions Patient selects Choices Online. that will trigger alert to subscriber 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 Figure 5. Internet Website Provides a Friendly and capabilities including sensors that will be used, their Easy Interface for System Initialization Process. connection interfaces, and their sampling rates. "Subscriber Setups" describes the contact information of a 1. Initialization subscriber. "Interests Setups" section allows a physician to Our system supports three initialization methods: (1) setup his interests to a patient's vital signals. A regular manually fetching an initialization script from a website report is triggered periodically, and emergency alerts are through GPRS connection, (2) locally operating the PMH triggered immediately when specified condition is met. on a patient, and (3) remotely setting the system through a This interface is provided by an Apache server running on peer-to-peer Short Message channel. These three methods a Windows XP platform. We create a webpage to provide issues a series of commands to the system, and all the used user interface. A Perl program sits on server translates the commands are from the same commands set which will be user choices into a series of commands (Figure 6), and described later through this section. The three initialization stores into a script file. A physician then operates the methods differ in user interface and the ways of delivering PMH (the one that will be deployed to a patient) to open a these commands to the system. This is the scenario where http socket to connect to the website using GPRS. The a physician manually selects desired sensors and PMH fetches this initialization script and setups the system customizes the initial system requirements for the patient accordingly (Figure 7). right before deployment. We here describe the first initialization method, initialized through a website. This We list the supported setup commands and optional method is not a “must” requirement, a peer-to- corresponding interpretation here, peer can be used to initialize the system, but it provides e (num) (nid) easy batching of setup commands, and has a user friendly : set (num) sensors on node (nid) interface. 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)2c unit: (D)ay, (H)our, (M)inute, (S)econd, (m)illisecond
  • 11. 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 Which module should this module The packet used to wire to? What’s the buffer size in exceeds a given threshold. setup sensor between interface and Sensors channel of node 3 The packet used to setup Module B Module C sampling rate of node 3 Module A Buffer 1 Buffer 2 Figure 7. Snooping Raw Results of Initialization Packets. Screen Snapshots of V600. A series of Packets (1) Sensor pushes Samples into Buffer (4) Module B releases Buffer 2 have been sent to Sensor Node 3 through Wireless to next Module when it is Full Interface. Module A Module B 2. Interests Profile Setups Buffer 1 A fair amount of design effort has been focused on Module n describing and implementing interests. An interest (2) Module A releases Buffer 1 to combines a series of computation modules by wiring one to next Module when it is Full Report another to form a linear dataflow graph. An interest setup command has following format and interpretation, Buffer n Module B (i) The Last Module reports to Computation Buffer 2 a (nid) (sid) (interest) [(delta)|(comp)|(insize)]+ Algorithm PMH when buffer is Full : add interest for (nid) node, (sid) sensor, (interest) is (Avg, etc.) [when input buffer (insize) is full, perform (comp) on input data buffer, output results to next layer buffer, clean oldest Buffer 1 (3) Module B performs Computation on (delta) input data buffer]+ Buffer 1 and push results to Buffer 2 It is implemented as a mechanism that wires FIFO Figure 8. Interests Wiring Mechanism queues in a module (Figure 8). The sensor is sampled at a Instead of Java on PMH, we implemented the given frequency (specified by commands described computation modules using SOS on sensor nodes for earlier), thus generating input data samples at a fixed rate. following reasons. First, we would like to minimize The incoming samples fill into a buffer which upon filling reliability problems caused by unstable wireless links. If is delivered to the computation module. The computation all BSN nodes dump their sensors samples to PMH, the results are stored in an output buffer (which also serves as congested traffic will easily lose packets, which increases the input buffer for computation module in next layer). design complexity to handle discontinuous data samples. Then the system creates a new buffer that has contents Second, we would like to investigate customized copied from input buffer. It cleans the oldest data region configuration capabilities of sensor nodes. Third, our of the newly created buffer to provide enough requested interest model wires various computation modules and amount (delta) room for future coming input data. This SOS’s ability to tranfer ownership of dynamically allocated provides a sliding window over the input sample stream. memory between modules simplifies implementation. When the input buffer of next layer module fills, it again Figure 9 shows a backend snooping of raw result repeats above compute-store-create-clean actions. packets after sending three interest setup commands. For example, "a 3 0 1 8|AVG|8 2|RPT|2" Every 64 data samples generates one MAX interest, one means that interest 1 performs average computation on MIN interest, and one AVG interest. Each interest every eight samples collected by sensor 0 of node 3, the contains eight values. Note that some data packets are lost resulting average value is pushed into report module, and due to congestion with interests. reports back every time when it has two average values in (1) a 3 0 4 8|MAX|8 8|RPT|8 the buffer. Another example, "a 3 0 2 8|AVG|16 4| (2) a 3 0 3 8|MIN|8 8|RPT|8 MAX|8 1|RPT|1" describes interest 2 as performing (3) a 3 0 2 8|AVG|8 8|RPT|8 average computation on every 16 samples collected by
  • 12. The minimum of these 8 The maximum of these 8 samples is 0x19a, and this samples is 0x1aa, and this result is stored into MIN result is stored into MAX interest report 4 interest report 3 MIN MAX Figure 10. Sending and Receiving Subscription AVG 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 Use PC to snoop data results. Then following subscription command will send a samples report to the provided contact every time the PMH receives each of three interests. The subscribed Interests is b 3 0 MAX|MIN|AVG 3106009321 AND 1*1:2*1:3*1 Missing samples due to TX now transmitted back every buffer contention. Two This subscription command describes that 64 data samples. (we data samples packets "3106009321" subscribes to a report on BSN node 3, specified in the commands were drop every eight data sensor 0. A report will be sent out when PMH receives that each interest has 8 sample packets interests 1, 2, and 3. The "*1" after interest id means results, each result is calculated from 8 samples) always true, and sets up whenever PMH receives the interest. "AND" condition requires that PMH receives Figure 9. Snooping Results after sending Three Interest each interest 1, 2, 3 at least once. The result of continuous Setup Commands (MAX, MIN, AVG) to MICA2. The monitoring example is shown in Figure 11. Received Interests are computed from Data Samples Another example triggers an alert whenever the received average temperature samples less than 36 degree 3. Subscription or greater than 39 degree. The above mechanism does not yet complete b 3 0 TempAlert!! 3106009321 OR 3<36:3>39 implementation of an interest. We also provide a command "OR" condition requires sending out the alert to for setting conditions while subscribing to these interests "3106009321" when any of the condition arises. "3" refers (Figure 10). Besides continuously monitoring, these filters to interest 3 which is the average temperature samples can remove unnecessary information and only report the setup up earlier. Note that PMH receives 8 average values interested information to the subscriber (physician). If at a time. As long as one value among the eight fulfills necessary, the subscriber can then conduct detailed any of two conditions (<36 or >39), the alert will be sent inspection through query command. This reduces out. The result of emergency alert example is shown in information overload on physician while keeping him Figure 11. 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 (conditions) fulfill, report to (contact) with the (description) op: <, >, =, *1(always true) conditions: AND, OR
  • 13. 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 11. The Subscriber receives Periodic Report (left) and Emergency Alert (right) 4. Multi-Resolution Query Our work focuses on issuing queries over recent historical data. The system supports a simple query format, q (nid) (sid) (contact) (interest) (start) (end) Figure 12. Fine Resolution Query Results (resolution) (medium) 5. Actuation : query (interest) from node (nid) sensor (sid) between Our system currently supports following command and (start,end) using (resolution) with (medium) presentation, its interpretation for triggering actuator nodes in BSN, and send to (contact) t (nid) (aid) (n) (algorithm) (parameter lists) The query command asked for stored information of : trigger node (nid), actuator (aid) for (n) times, using an interest between a given time period, and specifies the (algorithm) with parameters (parameter lists) desired resolution level and communication medium. A special interest id 0 refers to plain data stream. Our current As discussed earlier, the treatment algorithms usually implementation supports retrival of plain data streams. are proprietary and require numerous clinical studies to be This data stream contains original data samples, and is designed. Therefore, for testing purposes, we use a simple transmitted to the subscriber (physician) when he/she asks LED blinking to demonstrate this ability, where the for details. Figure 12 shows that after querying, the PMH algorithm choose the LED specified in parameter 1, and on the patient sends fine resolution data report to the triggers a blinking pattern indicated by the binary code of physician using long SMS. The receiving phone parameter 2. For example, reassembles these message segments and plots the graph of t 3 0 5 BLINK R D received data points, which is then displayed on physician's handset. The command will trigger node 3 and its actuator 0 Previous sampled data can be stored in distributed (LEDs). The selected algorithm is BLINK, the given BSN or centralized PMH, but our implementation does not parameters are RED and 'D'. So the node 3 will blink RED include storing data in file system. This is because our led 5 times, and follows a blinking pattern 1101(D), where testing device Motorola V600 does not support J2ME File '1' has a longer turn-on time than '0'. The patient will see Connection API. The JSR (Java Specification Request) 75, the red led on node 3 starts with two long blink, followed which introduces ability to access file system, was by a glimpse, then another long blink. This pattern will finalized in June 2004. Also the SOS Flash File System repeat 5 times in our given example. In real usage, the support on sensor nodes is still under development. actuator example will be ICD or pacemaker that delivers Therefore, we have not fully investigated the tradeoff voltage impulses to regulate the beating of the heart. between the two choices. V. EVALUATION Using a peer-to-peer channel in GSM/GPRS cellular network, the message can be carried in different forms With our implementation, we performed stress testing (text, image, etc.). We currently support standard SMS to the system. This was evaluated in four aspects, the (Short Message Service) and long SMS (or concatenated number of patients, the number of subscriptions, the SMS). The regular report or alert described earlier is sent number of interests, and the number of wiring modules. through standard SMS. The fine-resolution query described here carries larger content and is sent segmented 1. Number of Patients over multiple messages (long SMS). The receiving phone
  • 14. It is expected that our system scales well with an only a total of four 128 bytes memory blocks can be increasing number of patients, since rather than storing all allocated. data on physician's end, the information is distributed on Each sensor node can at most support four interests, each patient's own storage or onto medical service the reason being these interest objects are stored in the networks. The physician performs query actions to the main control module together with other data, and their individual patient (or network server) and pulls back total allocated size has to be less than 128 bytes (the information. Such action is not affected by the number of biggest memory block size). All these limitation can patients. Note that it is possible that more than one patient however be optimized by tuning SOS memory push reports (alerts) to the physician at the same time. configuration file or redesigning the modules. However, SMS operates on a store-and-forward schema that usually guarantees delivery. We prove this by 4. Number of Wiring Modules consecutively sending out 10 short messages, and all the We here tested how many modules can be wired messages are received successfully seconds later. within one interest. We created several pseudo modules to bypass data samples, and successfully wired six modules 2. Number of Subscriptions for one interest. We have not yet tested the maximum A subscription represents a report or an alert that will number of modules can be wired, since that also depends deliver to the subscriber. It is composed by operating the on the complexity of a computation module. Note that our interests and sends out a report or an alert when specified current implementation is limited to allowing each module condition is met. Our implementation stores subscription be wired at most once for one interest. information on the PMH, and the received interests are VI. DISCUSSION stored in the corresponding subscription objects for comparison against specified conditions. The system Our work does not address practical issues that arise handles increasing number of subscriptions quite well. due to safety, security and privacy, and confidentiality. This is due to plenty of resources on PMH (examples as Our prototype system relies on SMS technology to achieve 100 KB heap size on Motorola V600). We tested the limits interaction between physicians and patients. However, by continuously allocating subscription objects. We SMS protocol does not support any form of encryption, and interchanged following two subscription commands until the plain-text sessions are completed over TCP/IP. Also, the system crashes. The first subscription involves three the proposed extended three-tier architecture provides a interests while the second one involves two interests. direct connection between two peers, this tunnel should be (1) b 3 0 MAX|MIN|AVG 3106009321 AND constructed only when they trust each other. To deal with 3*1:4*1:2*1 these issues, a platform should refer to the Secure SMS (2) b 3 0 TempAlert!! 3106009321 OR 2<36:2>39 Messaging [44] proposed by Nokia to communicate We ran the experiment using simulator (to avoid securely between two J2ME MIDlets. damaging testing device) and allocated ~200 subscription VII. CONCLUSIONS objects before system crash. With advances in hardware (the Motorola V1050 released in 2005 supports a 512 KB We have built a medical remote monitoring and heap size), we expect one patient will never exceeds this interacting system that connects a physician and a patient. limitation for a BSN size network. Ous system provides remote capabilities such as sensor parameter setting, interests profile creating, reports (alerts) 3. Number of Interests subscribing and publishing, details querying, and treatment An interest is defined by user through wiring the actuation. Using this physicians can perform diagnosis computation modules and specifying the buffer size in and treatment over-the-air in an emergency. Our system between. This is implemented on sensor node using SOS uses an extended three-tier infrastructure that incorporates platform, and naturally expected to run into the scarce peer-to-peer channels. We introduced the concept of resources on the Mica motes. We are aware that this is not multi-resolution to filter trivial information and reduce the only design option, and that an alternative would be to communication cost while being presenting information to move these computations to the PMH level with the BSN the user in a form suitable for the selected resolution. We nodes taking responsibility for maintaining a reliable data presented a realistic implementation using commercial off- stream channel to PMH in the presence of increased traffic the-shelf products. Our implementation spans three congestion from the BSN to PMH. However, it is of platforms (sensor nodes, mobile phone, PC) and three interest to explore the limitation of our current partitioning. languages (C, Java, Perl). Our work integrated wireless We first tested buffer allocation inside a computation sensor networks, GSM/GPRS cellular networks, and module. We allocated a maximum available SOS memory internet. We hope that this paper motivates different block (128 bytes) for one MIN module, and successfully research communities and attracts different industries. find the minimum data samples stored in the buffer. In a ACKNOWLEDGEMENTS three computation modules case, we can only at most allocate a 32 bytes buffer for each module for one interest. Many thanks to Arun Somasundara, Julan Hsu, Laura This is due to the "malloc" implementation inside SOS that K Balzano, Ram Kumar Rengaswamy, Saurabh Ganeriwal, has only three block sizes (16, 32, 128 bytes), and there are and Simon Han for their valuable comments and revisions.
  • 15. REFERENCES [39] D. Ganesan, B. Greenstein, D. Perelyubski, D. Estrin, J. Heidemann, An Evaluation of Multiresolution Storage for Sensor Networks, SenSys’03, [1] J. Polastre, R. Szewczyk, C. Sharp, D. Culler, The Mote Revolution: Nov. 2003 Low Power Wireless Sensor Network Devices, Hot Chips 2004, Aug, 2004 [40] C. Intanagonwiwat, R. Govindan, and D. Estrin. Directed diffusion: A [2] Medtronic, http://www.medtronic.com/ scalable and robust communication paradigm for sensor networks. [3] D. Husemann, C. Narayanaswami, M. Nidd, Personal Mobile Hub, Proc MobiCOM ‘00, Aug. 2000. of 8th Intl Symposium on Wearable Computers (ISWC) 2004 [41] S. Madden, M. Franklin, J. Hellerstein, and W. Hong. The Design of [4] CodeBlue, http://www.eecs.harvard.edu/~mdw/proj/codeblue an Acquisitional Query Processor for Sensor Networks. SIGMOD, June [5] S. Han, R. Rengaswamy, R. Shea, E. Kohler, M. Srivastava, A Dynamic 2003 Operating System for Sensor Nodes, Mobisys, June 2005. [42] D. Jea, M. B Srivastava, Packet Delivery Performance for On-Body [6] J2ME, http://java.sun.com/j2me/ Mica2dot Wireless Sensor Networks, SECON 2005, September 2005 [7] GSM 03.40 and GSM 03.41 [43] D. Culler, D. Estrin, M. Srivastava, Overview of Sensor Networks, [8] TS 22.140 and TS 23.140 2004 IEEE, Aug. 2004 [9] http://www.gsmworld.com/roaming/GSM_WorldPoster2005C.pdf [44] A Brief Introduction to Secure SMS Messaging in MIDP, Nokia, Sep. [10] TinyOS, http://www.tinyos.net 2003 [11] R. Jafari, A. Encarnacao, A. Zahoory, P. Brisk, H. Noshadi, M. [45] LionShare: Connecting and Extending Peer-to-Peer Networks, A Penn Sarrafzadeh, Wireless Sensor Networks For Health Monitoring, The State Proposal to the Andrew W. Mellon Foundation, Sep. 2003 Second ACM/IEEE International Conference on Mobile and Ubiquitous [46] http://en.wikipedia.org/wiki/Mobile_phone Systems, July 2005, San Diego. CA. [47] Mobile Information Device Profile for J2ME, Version 2.0, JSR118 [12] R. Jafari, F. Dabiri, P. Brisk, M. Sarrafzadeh, CustoMed: A Power Expert Group 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.