3rd International Workshop onSmart Appliances and Wearable Computing

Internal Report ISSN 1432-7864Universität Karlsruhe

Adjunct Workshop ProceedingsHeld at 23rd International Conference on

Distributed Computing Systems (ICDCS 2003),May 19-22, 2003, Providence, Rhode Island USA

Michael Beigl

II

III

Table of Contents

V Preface

VII Program Committee

Papers

1 A-Life - Increasing Survival Chances in Avalanches byWearable SensorsFlorian Michahelles, Timo Ahonen and Bernt Schiele

7 RF Data Link for a Smart Clothing ApplicationTimo Vuorela, Kari Kukkonen, Jaana Rantanen, TeroAlho, Tiina Järvinen, and Jukka Vanhala

13 Wireless Community Support for Community NetworkLu Xiao

19 Exploiting Mobile Computing in Health-careUsman Arshad, Cecilia Mascolo, Marcus Mellor

25 Sticky Editor: A Visual Coordination Technique forSmart ApplianceYuu Furuichi, Aiko Shiwaki,Masayuki Iwai, HideyukiTokuda

30 A Ubiquitous Computing Infrastructure Created withSmart TagsAlfred Chioiu, Dominique Barthel, Pascal Le Menn

IV

V

Preface

3rd International Workshop onSmart Appliances and Wearable ComputingMay 29, 2003

http://www.teco.edu/iwsawc

held as part of the ICDCS 2003 Conference

Michael Beigl,michael@teco.eduTecO, University of Karlsruhe,

Today's world is more and more equipped with ubiquitously accessible computer,information and communication technology. Applications require enabling softwareand hardware technologies, including new kinds of embedded devices, networks,infrastructure, software architectures and security models. For the third time, theInternational Workshop on Smart Appliances and Wearable Computing (IWSAWC)brings together researchers from academia and industry to discuss state-of-the artdevelopment in this area. In this year's workshop, findings from research and industrywill not be limited to oral presentations; additionally, a demonstration and postersession invites authors to directly demonstrate and discuss work with workshopattendees.

This adjunct proceedings contains six papers selected for the demonstration andposters of the IWSAWC workshop. The five selected peer-reviewed papers show apractical, hands-on view on last breaking results in applications, middleware andnetworks in smart appliances. Application domains range from Wearable computers -where computing and sensing devices are embedded into clothes - to smartenvironments - where computing is embedded into walls and everyday objects - toapplications based on handheld computers.

VI

VII

Program Commitee

Christian Becker, University of Stuttgart, GermanyMichael Beigl, University of Karlsruhe, GermanyRoy Campbell, University of Illinois at Urbana-Champaign, USASpyros Lalis, University of Thessaly & ICS-FORTH, GreeceMike Little, Telcordia, USAMarkus Lauff, CEC, SAP AG, GermanyPeter Ljungstrand, Play Research Group, Interactive Institute, SwedenRyusuke Masuoka, Fujitsu Lab. of America, USABernt Schiele, ETH Zuerich, SwitzerlandAlbrecht Schmidt, Lancaster University, UKYoshito Tobe, Tokyo Denki University, JapanKazunori Takashio, Keio University, JapanHideyuki Tokuda, Keio University, JapanLars Wolf, University of Braunschweig, GermanyKinuko Yasuda, University of Electro-Communications, Japan

VIII

A-Life - Increasing Survival Chances in Avalanches by Wearable Sensors

Florian Michahelles, Timo Ahonen and Bernt SchielePerceptual Computing & Computer Vision Group, ETH Zurich

michahelles, schiele@inf.ethz.ch, tahonen@iki.fi

Abstract

Avalanches are one of the major threats to life in highmountain terrain. Once buried by an avalanche, survivalchances dramatically drop from 92% after 15 minutes toonly 30% after 35 minutes mostly due to the lack of oxygen.It is therefore extremely important to rescue any victims asfast as possible in order to maximize survival chances. To-day’s technology, so called electronic avalanche beacons,only allow to localize buried victims. In this paper we pro-pose a novel avalanche rescue system enhanced with wear-able sensors. Those sensors provide information about thevital state of buried victims such as heart rate, respirationactivity, and blood oxygen saturation, as well as the ori-entation of the victim. We believe that this knowledge canempower non-professional companion rescuers with a toolto perform triage, i.e. sorting victims into categories of pri-ority for treatment. Better allocation of resources can helpto maximize survival chances of avalanche victims.

1. About Avalanches and Avalanche Rescue

In the 17 European and North-American countries of theInternational Commission for Alpine Rescue (ICAR) on av-erage 146 avalanche fatalities have been registered per yearbetween 1975 and 1995 [23]. In 90% of all avalanche ac-cidents, the victim or someone in the victim’s party trig-gers the slide [14]. Recreationists go beyond their limits,underestimate the danger of avalanches and risk their liveswithout the appropriate awareness of avalanche risks [16].Accordingly, non-profit organizations and mountain clubs,such as theSwiss Alpine Clubor the CanadianMountainRescue Association, put enormous efforts into educationalprograms on avalanche awareness and companion rescueoperations. The key element of companion rescue is theso-called avalanche beacon. Worn by mountaineers, thiselectronic device allows to localize avalanche victims.

In this paper we propose to enhance existing avalanchebeacons with wearable sensors. Thus, rescuers obtain quickand early access to valuable information on the avalanche

victims, such as vital sign functions. The aim is to enablerescuers to better allocate resources to the most urgent vic-tims. It could also be used as a blackbox device, that recordsthe sequence of events during an avalanche release for acci-dent analysis or even legal actions.

The two next subsections highlight two significant issuesfor avalanche rescue: importance of time and need for com-panion rescue. Section2 shows how sensing technology canimprove avalanche rescue. In Section 3, ways of interpret-ing sensor measurements are given. Section 4 poses con-straints for a user interface of an enhanced avalanche bea-con and section 5 summarizes technical challenges. Section6 reviews our A-Life prototype. Finally in section 7, wesummarize our ideas and provide an outlook on further im-provements of our approach.

1.1. Importance of Time

Avalanche statistics show that time is the most criticalissue during rescue [13]. Figure1 shows that the chancesfor finding a buried victim alive decrease rapidly with time:92% of avalanche victims survive the first 15 minutes, from15 to 35 minutes survival chances decline from 92% to 30%,the majority dies by asphyxiation. So-called “air pockets”,closed air bubbles in the snow in front of mouth and nose,can save lives until 90 minutes. After 130 minutes only 3%survive with big air pockets or air channels to the outside.Consequently, successful avalanche rescue has to aim at res-cuing victims within the first 15 minutes. It is noteworthythat three quarters of all avalanche victims die from asphyx-iation, only one quarter is killed from trauma. Whereas thelatter group usually has no chances for recovery, air-pocketsand fast companion rescue provide the best chances for sur-viving an avalanche accident.

1.2. Companion Rescue

The standard companion rescue procedure - as it is ad-vertised today - comprises three steps. First, the victimshave to be localized in the avalanche. With avalanche bea-cons search should take no longer than 3 to 5 minutes. As

Figure 1. Survival function (taken from [ 13])

a second step, extricating a localized victim with shovelsshould not take more than 10 to 15 minutes. Extrication hasnot only to be quick, but also to be performed with care: vic-tims could be injured by the shovels, and air-pockets, vic-tims’ protection against asphyxiation, could be destroyed.Rescuers today do not know how victims are oriented inthe snow. The third step is to execute first aid: openingrespiratory tracts and avoiding hypothermia. At this pointprofessional aid should take over.

The entire rescue process has to be as fast as possiblein order to maximize survival chances. This puts rescuersunder immense pressure, as in practice rescue resources arealways limited. However, if immediate search of buried vic-tims is performed properly by survivors or witnesses of anavalanche, survival chances are 4 times as high as in case oforganized rescue [22].

2. How sensors may improve the rescue process

This section starts with a review of today’s avalanchebeacon technology. Thereupon, phenomena and indicatorsare derived, which determine the rescue process but are notavailable today. Finally, it is shown how sensing technologycan reveal those phenomena.

2.1. Today’s Avalanche Beacons

Today, beacon technology only assists during search.Beacon devices operate on 457 kHz long wave frequency,which has become an international standard. Microproces-sors on the devices can calculate distance and direction to asingle victim from the emitted dipole flux pattern [17]. Bythat, the devices can guide the rescuer to the victim eitherthrough arrows on a display or sounds with rising volumeas the rescuer approaches the victim. Usually, a range of80m can be achieved. Batteries last up to 300h. By default,

devices operate in sending mode and can be switched to re-ceive mode to initiate rescue operations.

2.2. Phenomena of Interest to sense

Our vision is to provide rescuers and mountaineers withinformation that goes far beyond location by including valu-able information on the victim’s state of emergency. Ac-cordingly, in the following we outline important phenomenaand indicators pertinent to efficient and successful rescue.

Direction and a rough estimation of the distance is allbeacons provide today. However, more support would bedesirable:

• knowledge about the state of the victims, survivalchances, urgency, vital sign functions

• support for rescuing multiple people

• orientation of the victim in the snow

• burial depth of the victim

Knowledge about a victim’s physical situation is a richsource of information for rescuers. Vital sign functions,such as heart rate, respiration activity, consciousness andcore temperature are the key elements for initial assessmentand provision of basic life support [1]: Missing heart raterequires manual chest compression, absence of respirationactivity demands rescue breathing, unconsciousness has tobe treated by anti-shock therapy, and low temperature re-quires treating hypothermia [15]. As rescue operations dif-fer in rescue resources, e.g. chest compression requires twotrained rescuers, anti-shock therapy only one low-skilledrescuer, knowledge on victims’ vital sign functions enablesrescuers to foresee upcoming rescue procedures and allo-cate rescuers among victims more properly. Evidence oflife signs may also motivate rescuers and drive rescue of re-maining victims even under harsh conditions. Last but notleast, vital sign functions of victims can also be communi-cated to professional rescue service already before havingaccess to victims.

As discussed in section1 the existence of an air pocketcan help buried victims to survive under snow up to 90 min-utes. Victims with air pockets can be considered less urgentthan others without. Rescuers can be instructed to focuson those victims first, as their survival time will be muchshorter. Equally, rescuers can be reminded not to destroythis life saving source. Finally, air pockets are a very goodindication of working respiration tracts, which is importantto know for emergency physicians. Currently, air pocketdetection is very difficult; rescuers do not know whether avictim has or does not have an air pocket.

Orientation of an avalanche victim in snow determinesfrom which direction rescuers should approach the victim,

so that they do not step on top and destroy an air pocket. Forextrication today’s rescuers are instructed to drive a chan-nel sidewards in direction to the victim. As rescuers todayonly can localize a victim without knowing the orientation,a starting point for digging is hard to define. Awarenessof orientation could help to preserve air pockets, speed upaccess to the victim’s head for first aid. Giving rescuers ac-cess to different relevant sources of information can lead toa more efficient and better scheduled rescue.

2.3. Available Sensing Technology

This section shows, how sensors worn by mountaineerscan give rescuers access to valuable information, that is be-yond the human senses.

Oximeters, which have a firm place in everyday clini-cal practice, offer an unobtrusive way of measuring heartrate and blood oxygen saturation. Attached to one’s finger,toe, or forehead, the ratio of the fluctuation of red and in-frared light caused by hemoglobin – the oxygen carrier inhuman blood – is used to calculate the heart rate and oxy-gen blood saturation (%SpO2). Body core temperature isanother valid vital sign function describing a victim’s phys-ical state. Skin temperature is easy to measure, but it’s sig-nificance is rather low, as skin temperature and body coretemperature are not well correlated. However, [9] reportsa pill-sized thermometer, which can be swallowed and thentransmit measurements wirelessly through the body to an-other device worn outside the body. The existence of airpockets can be indicated by oxygen sensors (e.g. [3]), thatmeasure the oxygen concentration of the environment. Dis-tance sensors, operating on infra-red or ultra sound, can beused for detecting convexity in the snow covering a buriedvictim. Combining results of oxygen sensors and oximetercan give a good indication for a person’s respiration activ-ity. Finally, 3D accelerometers can reveal a victims’ bodyorientation in the snow.

As pointed out earlier, our vision is to augment today’savalanche beacons mountaineers are wearing anyway: col-lected data from the various sensor distributed around thebody is communicated through long wave to rescuers inemergency cases. We discussed how existing sensing tech-nology can add value to today’s avalanche rescue and in-crease survival chances.

2.4. Placement of Sensors

In the following it is described how sensors can be unob-trusively placed on the mountaineers’ bodies, such that themountaineers are minimally disturbed in their activities andthe sensors are protected against loss during avalanches.

We tested different placements of the oximeter: fore-head, finger tips, and toe. Only the toe turned out to be ap-

propriate in mountaineering. Today’s ski and hiking bootsare well isolated and can shelter the sensor from damageand loss. Loss of boots in avalanches is very rare. Oncewrapped around the toe the sensor is not noticed anymoreand does not disturb at all. However, severe cold may causeretreat of blood from the extremities, such that measure-ments at the toe may get unreliable under harsh conditions.But victims under snow cover are very well isolated andhypothermia is not the dominant factor during the first hourafter the avalanche [13]. The placement of an oxygen sensordetecting air pockets is more difficult: it has be worn veryclose to the mouth as air pocket usually are only a few cen-timeters wide [21]. We propose to integrate the oxygen sen-sor into the collar of the jacket. Notwithstanding the dangerof loss in an avalanche, we prefer the collar, as other loca-tions, such as glasses seem even weaker. The accelerome-ters for measuring orientation can be embedded directly intotoday’s avalanche beacons. As those beacons are fixed wellon the human body, loss during avalanches is almost impos-sible. As mountaineers are used to wearing those devices,they do not feel disturbed.

3. Visualization of Sensor Readings

Knowledge on victims’ physical state enables rescuersto foresee upcoming rescue procedures and to better planon-going rescue. Today, triage [10] - the principle of sort-ing casualties in disaster into categories of priority for treat-ment - is reserved for professional aid, as triage is rathercomplex and requires medical experience. Automation oftriage through sensors would also provide companion res-cuers with a tool to support decision that helps to focus onmost urgent victims first.

3.1. The Curse of Information

Avalanche rescue is a cognitively demanding situation.Rescuers must not be flooded with sensor measurements,but data has to be pre-processed and presented in a conciseway: translations to the rescuer’s language such as “up-right”, “horizontal”, “upright down”, “air pocket”, “no airpocket” are more meaningful than the actual sensor mea-surements. Thresholds for oximeter values used in medi-cal practice [19] are more tailored to rescuers’ understand-ing than the actual values. Further, sensor measurementsshould be double checked whenever possible, e.g. respira-tion activity should only be inferred if both an air pocket isdetected and the oxygen blood saturation is over 80%. Onlyif those two conditions are satisfied, reasoning about respi-ratory activity is valid. Proper placement of the oximeter,can be detected by the sensor itself: it reports whether itsmeasurements are valid or not. Putting all available sensorinformation of multiple victims at once is too much: We

propose separation in location and urgency. First, visualpresentation of the victims’ spatial distribution enables toselect victims close-by to keep paths short. Secondly, sep-aration in urgency provides rescuers with a global view onthe emergency, automation of triage, which allows to rescueurgent victims first.

Figure 2. Urgency Measure

3.2. Urgency Measure

We developed a global measure that integrates all sensorreadings, referred to asurgency measure. Figure2 depictsthe decision tree we use to assign an urgency measure toeach victim. Motivated by triage, as performed by emer-gency physicists, we take heart rate as the primary crite-rion. If heart rate cannot be detected, we assume the high-est urgency, as reactivation will have to take place imme-diately. On the other hand, rescuers could also reason thatthis victim has already died due to a fatal injury. We wantto leave this decision with the rescuers, as they as witnessesstill have additional knowledge about the accident they canintegrate into their decision process.

If heart rate can be detected, we take the existence ofan air pocket as the secondary criterion for determining ur-gency. As outlined in section1.1, air pockets may helpto survive up to 90 minutes in contrast to only 15 min-utes without. Accordingly, the latter group is in a moreurgent state than the first. We use oxygen blood saturationas a third criterion of urgency determination. We adopt thecategories from [19] for obtaining urgency from oximetermeasurements. Finally, we take orientation as the fourthattribute of urgency. We assume that orientation can givehints about injuries occurred to the victim. Further, one canassume that different orientations may also constrain a vic-tim’s self-rescue capabilities. We rate “upside down” as theworst case, “vertical” as intermediary and “upright” as thebest condition. However, we do not judge orientation as avery strong criterion for urgency, so orientation has the low-est impact in the decision tree.

This urgency measureprovides rescuers with a globalview of the emergency. Each victim can be described byone value, which allows to align multiple victims on a one-dimensional scale. Multiple victims can thus be comparedmuch easier. Hence, theurgency measureallows to rea-son about allocating resources to victims according to thesevereness of their situation. Nevertheless, rescuers are notdistracted from their rescue, as the system integrates all rel-evant sensor values into one view and takes away the cog-nitive load of interpreting too many sensor values.

Another improvement over pure sensor values is observ-ability over time and deriving predictions for future devel-opments. Apart from only presenting the victims’ sensorvalues, a system can also derive tendencies and guide atten-tion to critical parameters.

4. User Interface

In order to address usability and to achieve user accep-tance, our system has to be light, small and robust. Sensorshave to operate in an unobtrusive manner. Their activityshould be transparent to the users. This obviously holds foroximeters, oxygen sensors and accelerometers.

(a) (b)

Figure 3. (a) User Interface of the Prototype(b) IPAQ based platform with sensors

Moreover, the device has to be easy to use, as rescuersare in an emergency situation. We propose to limit pre-sented information to heart rate, air pocket detection, oxy-gen saturation, orientation and anurgency measure, as pre-sented in the previous section. Figure3 depicts the userinterface we developed to represent this data to the user. Inthe upper left corner all victims are aligned from left to rightrelatedurgency measure. As most people are used to readfrom left to the right, we start with the most urgent at theleft, such that those are noticed first, and continue with lessurgent victims in decreasing order of urgency to the right.Each box on the display represents one victim. Addition-ally, we use the color spectrum from red to green to indi-

cate the state of urgency. The boxes are both informationdisplay and interaction buttons. Clicking on them displaysthe victim’s heart rate, air pocket existence, oxygen bloodsaturation and orientation. As figure3 depicts, we use intu-itive graphical elements: increasing heart size with increas-ing heart rate (67), air-bubble in front of mouth indicatingair-pocket existence (none), circulating arrows representingoxygen blood saturation (47%), and a stick-man showing2D-orientation (upright). The map displays a centered viewof the spatial distribution of buried victims. Our intentionis to take advantage of location information, which is al-ready available from today’s digital avalanche beacons, andto integrate it into one view. Rescuers can relate better be-tween beacon signal and reality, so that they obtain a betterimagination of the spatial distribution of victims. The mapis also clickable, such that single victims can be selected foraccessing their sensor values. Finally, at the bottom of thedisplay the user is guided to the selected victim. This func-tionality has been adopted from today’s avalanche beacons.

Generally, we propose to present the vital functions inan anonymous manner, such that one cannot relate displayvalues to a person’s identity. We want to prevent that emer-gency rescuers may get distracted by personal emotions butonly base their decisions on the values in a more rationalmanner.

5. Technical Challenges

Augmenting avalanche beacons with sensors poses sev-eral technical challenges which are discussed in this section.

One challenge is to unobtrusively connect distributedsensors around the body to the central beacon unit. Thecurrent approach, is to use wires that connect the oxime-ter at the toe and the oxygen sensor at the collar with thecentral unit worn on the chest. Wires can be kept insidetrousers and jacket, such that they do not disturb the moun-taineer. Emerging technologies as fibers embedded into tex-tiles [8] open new opportunities and can make wires invis-ible. Body area networks [2] establish a local wireless net-work around the body, which replaces physical wires com-pletely. Another challenge is the connectivity among bea-cons, i.e. rescuers can receive data from buried victims.Common technology, such as WLAN or Bluetooth is notsufficient, as those signals are not able to penetrate snow.We propose to modulate the sensor information onto a long-wave frequency signal which is able to penetrate snow .Power, as always in wearable applications, is an impor-tant issue in our system design. Today’s avalanche beaconscan run up to 300h [4] with continuous signal broadcaston two AA batteries. Considering that an oximeter con-sumes 60mA, an oxygen sensor 20mA, an accelerometer1mA and a micro-controller for signal processing with RFunit 20mA, an avalanche beacon enhanced by those compo-

nents could last up to 10h. At least for a day trip this sys-tem’s life-time is sufficient. However, for this calculationwe have assumed, that all sensors are continuously running,sensor readings are constantly processed and broadcastedwirelessly throughout the entire run-time. Clearly, systemlifetime can be increased by keeping several components,such as oximeter and oxygen sensor, on a power-savingstand-by mode. The challenge is to minimize the numberof continuously running components. One approach couldbe to make use of characteristics of an avalanche trigger:significant deviations from usually skiing behavior, such ascaused noise, turbulence of snow or acceleration, [12] re-ports about an observed avalanche with 450km/h, could bemeasured through low-power sensors, e.g. accelerometersor humidity sensors. Those low-power sensors can be usedto trigger and wake up power consuming components, suchas oxygen sensors, for achieving longer system life-time.Though we are aware of the costs and vulnerability to haz-ardous conditions of color displays, the design helped usto explore visual representations more thoroughly and willguide us to develop a more lightweight design tailored forLCD devices, as partly embedded into today’s avalanchebeacons already.

6. Prototype: A-Life

The current A-Life prototype includes the followingthree sensors: oximeter, oxygen sensor and accelerometer.We use a finger pulse oximeter [11], that can be easily at-tached to one’s toe in a ski boot. The evaluation kit ofthe sensor itself can detect whether the sensor is mountedproperly and the measurements are valid. The oxygen sen-sor [3] measures oxygen concentration in the environmentin per mil accuracy range [5]. For orientation, we use anADXL202 accelerometer attached to a Smart-Its sensor-board [7] with a PIC micro-controller processing unit. Allthree sensors have been connected via a PCMCIA/4 serial-port adapter card [6] to an IPAQ device. The system it-self is implemented on the IPAQ device. The colored touchscreen interface enables to explore the user interface as pro-posed in section4. Clicking on the touch screen (figure3)allows one to select companions in order to receive theirheart-rate, air-pocket availability, oxygen blood saturationand orientation. Further, we implemented the urgency mea-sure as outlined in section3. A rescuer’s device switchedto search wirelessly receives the sensor values of surround-ing victims. This does not require more than two bytes: 1byte for an unique identifier, another byte for coding heartrate, air pocket evidence and orientation (up-right, vertical,upside down) and calculated urgency. An update rate of tenseconds is sufficient. Standardization of today’s avalanchebeacons does not permit data modulation on the 457kHzsignal. Because of backward compatibility to older devices

the standard must not be changed, but rather an additionalfrequency as a data carrier should be considered. In theprototype connectivity among different parties is providedby wireless LAN in peer to peer mode.

The running prototype with implemented sensing andcommunication functionality enabled us to demonstrate andevaluate the concept of wearable sensors in rescue with ex-perts from the field, see [18] for details.

7. Conclusion and Future Work

In this paper we motivated the use of sensors inavalanche rescue by the importance of time duringavalanche rescue and the black box view on buried vic-tims today. We discussed and described how sensor tech-nology can be used to provide rescuers with a valuable toolto enhance their decision ability on how to allocate their re-sources during rescue. An overview of meaningful sensorsprovided the basis for our system design. Furthermore, weemphasized that displaying raw sensor measurements willnot be appropriate and sufficient. Therefore we introducedan urgency measureto provide an integrated view of theurgency of all victims involved in an accident. A first pro-totype underlined the feasibility of our approach. Finally,we outlined how we will improve our prototype in orderto make it deployable for practical use. We see a varietyof possibilities to extend our system. Enhancing our sys-tem by an avalanche warning capability could help to avoidavalanches. Integrating access to avalanche warning bul-letins, as proposed in [20], and tailoring those to the user’slocation, could add more value to the mountaineer. Sensingtechnology could also trigger avalanche airbags or releasean emergency call including vital sign functions automati-cally. Further, depth of burial could give hints on how manyrescuers have to be assigned to one victim in order to exca-vate them in time. In general, it would be a great achieve-ment if A-Life could save at least some of the 150 lethalavalanche victims yearly.

Acknowledgments

This work is part of the Smart-Its project and is fundedin part by the Commission of the European Union undercontract IST-2000-25428, and by the Swiss Federal Officefor Education and Science (BBW00.0281).

References

[1] BASIC LIFE SUPPORT - Resuscitation Guidelines. Resus-citation Council (UK). http://www.resus.org.uk/pages/bls.htm .

[2] Body Area Network. Fraunhofer Institute for Integrated Cir-cuits. http://www.iis.fraunhofer.de/ec/wc/body_com/ .

[3] Fujikura.http://www.fujikura.co.jp/sensor/ .[4] Ortovox. http://www.ortovox.com .[5] Pewatron.http://www.pewatron.com .[6] Quatech.http://www.quatech.com .[7] Smart-Its.http://www.smart-its.org .[8] SnowTex.http://www.snowtex.ch .[9] The Media Lab Goes to Everest.http://classic.

mountainzone.com/everest/98/mit.html .[10] World Medical Association Statement on Medical Ethics

in the Event of Disasters.http://www.wma.net/e/policy/17-z_e.html .

[11] XPOD Pulse Oximetry Module.http://www.nonin.com/xpod.html .

[12] D. Atkins. Report on the meeting of the AVALANCHECOMMISSION OF CISA-IKAR. Technical report, Inter-national Commission for Alpine Rescue, September 1999.

[13] H. Brugger and M. Falk. Le quattro fasi del seppellimentoda valanga.Neve e Valanghe, 16:24–31, 1992. (Italian).

[14] M. Burtscher. Wie gefahrlich ist Bergsteigen?Jahrbuch´90 der Osterreichischen Gesellschaft fur Alpin- undHohenmedizin, pages 92–107, 1990. (German).

[15] D. Danzl.Emergency medicine: concepts and clinical prac-tice, chapter Accidental hypothermia. Mosby, 1988.

[16] J. Fredston and D. Fesler. The Human Factor - Lessons ForAvalanche Education. InInternational Snow Science Work-shop, November 1994.

[17] J. Hereford and B. Edgerly. 457kHz Electromagentism andthe Future of Avalanche Transceivers. InInternational SnowScience Workshop (ISSW 2000), Big Sky MT, Oct. 2000.

[18] F. Michahelles, A. Schmidt, and B. Schiele. Applying Wear-able Sensors to Avalanche Rescue: First Experiences with aNovel Wearable Avalanche Beacon. InAssistance, Mobil-ity, Applications (IMC Workshop), Rostock, Germany, June17-18 2003. (to be published).

[19] K. Miller. Pulse Oximetry.http://www.co.alameda.ca.us/PublicHealth/organization/divisions/ems/Resource/Pulse_ox.pdf .

[20] B. Signer, M. Norrie, P. Geissbuehler, and D. Heiniger. Tele-phone Interface for Avalanche Warnings based on Informa-tion Server for Adaptable Content Delivery. InInternationalConference on Pervasive Computing, Zurich, Switzerland,August 2002.

[21] SLF. Davos (1981 - 1998).Winterberichte 46-62. (German).[22] F. Tschirky, B. Brabec, and M. Kern. Avalanche rescue sys-

tems in Switzerland: experience and limitations. InProceed-ings International Snow Science Workshop, pages 369–376,Big Sky MT, USA, October 2000.

[23] F. Vala.Report of the Avalanche Subcommission on the gen-eral meeting of the International Commission of Alpine Res-cue, 1995. Geiranger, Norway.

Abstract—As a research of smart clothes goes forward, therehas come up a need for a wireless data transfer between differentmodules in smart clothing and many smart clothing systems. Thispaper describes the testing of four different short range radiotransceivers and an implementation of a wireless data link. Fortesting the RF (Radio Frequency) circuits a test system was build.And to test a fully functional data link, two properly workingprototypes of each RF circuit were implemented. Powerconsumption, transmission power and range of the link were thenmeasured from each link. According to the measurements, one RFtransceiver was selected to be used in a wireless data link. Thislink was then implemented and applied to a smart positioning vesttargeted for fishermen.

1 IntroductionNowadays people carry many electronics equipment

with them. One person can for example have a cell phone,walkman and a laptop computer. When we take a closer lookon these devises we note that there are three displays, differentkind of keyboards and many processors. If all these could bechanged to one devise, we could get rid of the overlappingparts, but efficiency of the system would not decrease. This ispartly the idea behind smart clothing. Electronic devices areintegrated into the clothes so that they are unnoticeable andeasy to carry with.

When more and more electronic parts are integratedaround the clothing, a method for transferring data betweendifferent modules is needed. This kind of solution is called aPAN (Personal Area Network) [10].

Nowadays a most common techniques for transferring adata in smart clothing are normal wires, conductive fibers,infra red links and both capacitive and inductive methods.All of these have some disadvantages. Wires are not veryflexible and they easily make clothes inflexible. Conductivefibers are flexible but they get broken easily. Infrared links arewireless but they require a line of sight for a properfunctionality. Capacitive and inductive methods are interestingbut they are already researched elsewhere [6],[10] so this workwas focused on short range radio devices (SRD).

Short range radio devices are radio circuits operating onlicense free ISM (Industrial, Scientific, and Medical)bands. ISM bands are in Europe 433.05 – 434.79 MHz and

868 – 870 MHz [7] and in Americas 902 – 928 MHz. On thesebands there is no need for license but the transmission powerand the duty cycle of the transmitter are restricted. Deviceswithin the ISM band must also tolerate the harmfulinterference caused by other ISM applications using the samefrequency band.

2 RF TesterFor testing RF circuits, a test system was needed. In thissection the implemented RF tester is presented. First thehardware of the tester is looked through and then the softwareof the tester is shortly discussed.

2.1 RF Tester HardwareFor testing the RF transceivers two RF testers were built. RF

tester is a device, which contains all the electronics needed tocontrol the RF transceivers. RF testers made the tests mucheasier, because with testers it was possible just to build simpleprototypes of RF transceivers without any control logic. Also,when same testers were used in every test, the powerconsumption of the testers was easy to compensate from finalmeasurements.

Fig. 1. Block diagram of RF tester

RF tester consists of few components. Most important one isthe AT90S8515 [1] microcontroller manufactured by AtmelCorporation. As a user interface of the tester there are a LCD(Liquid Crystal Display) and a simple push button. Used test

RF Data Link for a Smart Clothing ApplicationTimo Vuorela, Kari Kukkonen, Jaana Rantanen, Tero Alho, Tiina Järvinen, and Jukka Vanhala

Tampere University of TechnologyInstitute of Electronics

P. O. Box 692, 33101 Tampere, FinlandPhone int. +358 3 3115 5350

Fax +358 3 3115 2620Email timo.vuorela@tut.fi

packets are saved on an EEPROM (Electric ErasableProgrammable Read Only Memory) size of 32 KB. For acommunication with the RF circuit under test, the RF testercontains a simple 17-wire interface, and the communicationwith a PC is handled through a normal asynchronous serialinterface. Block diagram of RF tester hardware is presented infigure one.

2.2 RF Tester SoftwareIn figure two is a presentation of the RF tester software. For

every tested RF circuit the RF tester software had to be writtenseparately. Many modules of the RF tester software werewritten so that it was possible to use the same module in everyversion of the software. Only the manchester module and theRF circuit driver module had to be written separately fordifferent RF circuits. This was because control interfaces ofRF circuits were different from circuit to circuit.

Fig. 2. Block diagram of the RF tester software

3 RF circuitsDuring this research four RF transceivers were tested;

nRF401 [5] from Nordic VLSI, XE1201 [9] from Xemics SA,CC900 [3] and CC1000 [4] from ChipCon. XE1201 andnRF401 are operating on the lower ISM band around434MHz. CC900 operates on the upper ISM band around868MHz. CC1000 is very configurable and it is possible to useit over a wide range of frequencies from 300MHz to1000MHz.

According to the flexibility of CC1000 it would have beenpossible to test it on both ISM bands. Anyhow, due to theschedule this was not possible and the CC1000 was tested onlyon the lower band.

Tested circuits were selected mainly according to fewcriteria. Perhaps the most important one was the availability.There are many short-range radio circuits on the market andsome of those had already been purchased for other projectsbefore this research started, so it was obvious to test at leastthese circuits. Another criterion for choosing circuits for testswas of course the power consumption of the circuit to test.Power consumption’s were compared from the manufacturesdata sheets. As the test went on the markets were alsofollowed, and if an interesting circuit was revealed it was triedto get it into the tests. This was the way, in which the CC1000was chosen.

From all RF transceivers two prototype circuits were built.Otherwise it would not have been possible to test a RF-link in

action. RF circuit prototypes were designed strictly accordingto the manufactures application notes. In this way a designingof the layout was easier and there was the biggest probabilityof getting a properly working layout on the first attempt.

4 MeasurementsIn this section the measurements are discussed. First the test

arrangements are looked through and then the measurementresults are presented.

4.1 Measurement arrangementsFrom the tested RF circuits transmission power, consumed

DC (Direct Current) power and range of the created link weremeasured. Transmission power was measured with spectrumanalyzer straight from antenna connectors of built prototypetransceivers. Consumed DC power was measured in laboratorywith accurate DC power supply. Range of the created RF linkwas measured outdoors on a test track.

Reason for selecting these parameters to be tested was quitesimple. Power consumption was measured because in wearableand mobile applications the consumed power is a veryimportant criterion. Range of the link was then measuredbecause the first idea behind this research was to use short-range radio links in both data transmission inside the smartclothing and data transmission between many smart clothingsystems.

In the range test one end of the link was placed in the zeropoint of the track, and the other end was moved along thetrack. After the test circuit had been moved about five meters atest packet was send. If the RF circuit located in the zero pointof the track received the packet, it echoed the packet back tothe sender. If the sender then received the unchanged packet,the link was still in range and the sender circuit was movedfurther away along the track. If the packet was not received,the sender was moved a little bit towards the zero point of thetrack and the test packet was sent again. As soon as the senderwas again able to receive an echoed data packet, the range ofthe link was measured. Principle of the range measurements ispresented in figure three.

In the range test CC900, CC1000 and XE1201 were testedwith the same whip antenna so these measurements are verycomparable. nRF401 was a ready made module with PCBantenna so this antenna was used in tests. Although thefrequencies and antenna are not exactly the same in every test,the result can be considered to be comparable due to quite lowa frequency used.

Fig. 3. Arrangement of the range test

4.2 Measurement ResultsIn figure four the measured ranges of the tested links arepresented. From figure four it is obvious that CC1000 obtainsthe longest range. Even with the minimum transmitting powerCC1000 obtains a range over twenty meters. Also the othercircuits obtain fairly good ranges, but not with as lowtransmitting powers as CC1000. One curious thing is that therange of the CC1000 does not increase linearly when thetransmission power is increased. It is still a little bit uncertainwhat caused this kind of behavior, but it may have somethingto do with the layout of the prototype PCB.

0

5

10

15

20

25

30

35

40

45

50

-25 -20 -15 -10 -5 0 5 10 15

programmed transmitting power / dBm

ran

ge

of

the

link

/ m

CC1000CC900XE1201nRF401

Fig. 4. Measured range of the links

In figure five the measured DC power consumption of theRF transceivers is presented. From figure five it can be seenthat power consumption of CC900 is much greater than powerconsumption of any other circuit. This is easily explained withthe higher operating frequency of the CC900.

According to the transmission power and consumed powermeasurements the efficiencies of the RF transceivers werecalculated. Results were not very promising. Efficiency ofCC1000 was a little bit over one percent on the higherprogrammed transmission powers. Efficiencies of othercircuits were much lower than 0.5 percent over the whole scaleof transmission powers.

0

50

100

150

200

250

300

350

-25 -20 -15 -10 -5 0 5 10 15

programmed transmitting power / dBm

con

sum

ed D

C p

ow

er /

mW

CC1000CC900XE1201nRF401

Fig. 5. Consumed DC power in transmitting mode

To make the difference between RF-circuits more clear, anew parameter was calculated. This parameter indicates the

consumed DC power per one meter of obtained range.Calculated values are presented in figure six.

From figure six one advantage of the CC1000 can be clearlyseen. Over the whole scale of transmitting powers the CC1000consumes less than five milliwatt per one meter of obtainedrange. Worst case is with CC900, which consumes nearlysixty-milliwatt per meter, when the transmitting power is-20dBm. From figure six it can also be seen that around thetransmission powers from –8 dBm to 0 dBm all the testedcircuits, but the CC1000, are quite close to each other.

0

10

20

30

40

50

60

70

-25 -20 -15 -10 -5 0 5 10 15

programmed transmitting power / dBm

con

sum

ed D

C p

ow

er/r

ang

e o

f th

e lin

k m

W/m

CC1000CC900XE1201nRF401

Fig. 6. Consumed DC power divided with the range of the link

5 RF linkIn this section the implementation of the wireless data link is

discussed. First the criteria for choosing the RF circuit arehandled and then the hardware, software, and protocol of thelink are presented.

5.1 Criteria for chosen RF circuitWhen selecting the RF transceiver for a smart clothing

application, the most important criterion is the powerconsumption of the link. This is because the link is to beapplied to a mobile system, in which the amount of batteries islimited and the less power the link consumes, the moreoperating hours it will gain.

Almost as important as the power consumption of the link,is the reliability. Reliability is directly lead to the powerconsumption. If the transmission of the data does not succeedon the first attempt, one or more new attempts are to be madeand more power is consumed. So if the link is very reliable andall transmission are to succeed on the first attempt the powerconsumption is remarkably decreased.

During the measurements it became clear that measuringthe reliability of the link is very difficult. So the easiest way tocompare the reliability, is to compare the ranges of the links.The longer the range of the link is, the more reliable it will beover shorter ranges.

Efficiency of the link is also a criterion, which is quiteclearly lead to the power consumption of the link. The betterthe efficiency of the link is, the higher transmission power itwill gain with less consumed DC power. If the range of the

link is to be constant, and a specific transmission power isneeded to obtain that range, the link with the highest efficiencywill consume the least power.

Price of the transceiver IC (Integrated Circuit) is of course avery important criterion, especially if there is going to be avery large series of the application to be manufactured. In ourprototype application the more important criterion is the easeof use. When designing only one prototype, the biggestexpense is the salary of the designer. So the easier the RFtransceiver is to use, the less time it will take to get theapplication running, and so less it will cost.

When manufacturing large series of application, amount ofexternal components is also an important criterion. The lessexternal components the circuit requires, the cheaper it will be,and the easier it will be to manufacture. Also if the circuit doesnot need a large amount of components it will be possible topack the application in the smaller case.

According to these criteria, the CC1000 RF transceiver waschosen for implementation of the wireless data link. CC1000 isthe most efficient of the tested circuits, it has clearly thelongest range, and it is also quite easy to use.

5.2 RF link hardwareIn figure seven the block diagram of the created RF link is

presented. Hardware is very simple, even the serial interfacewas implemented on TTL-voltages so no RS-232 transceivercircuit is needed. Heart of the RF link is AT90S4433 [1]microcontroller. AT90S4433 was chosen, because it isphysically a little bit smaller than AT90S8515, which was usedin the RF tester. The power supply part of the link was alsodesigned to be very simple. Operating voltage of the link waschosen to be 3.0 volts, so it is possible to use link for examplewith two AA or AAA size 1.5 volt batteries. Reset circuit wasadjusted so that it will reset the link if the supply voltage dropsbelow 2.7 volts. This is the lowest voltage with which theAT90S4433 and CC1000 are guaranteed to function properly.

Link was designed to be fully transparent so no userinterface is needed. Only thing that user will notice when thelink is applied to a system is that delays in data transfer willincrease a little bit.

Fig. 7. Block diagram of the RF-link hardware

Some impedance matching and signal filtering wasimplemented between CC1000 and the antenna. Impedancematching is important if maximum efficiency is wanted.Without impedance matching the transmission power willreflect from mismatched impedance interface and therebydecrease the power radiated from antenna. Filtering is needed

to filter out the noise from RF signal and in that way toimprove the link’s reliability.

5.3 RF link softwareA Block diagram of RF link software is presented in figure

eight. The software consists of eight modules. On the right sideof the figure eight, are modules that take care of the serialcommunication with the application the RF link is workingwith. On the left side of the figure are then the modules, whichtake care of the communication over the radio frequency.

Fig. 8. Block diagram of RF link software

Writing the software was very challenging, because thechosen microcontroller AT90S4433 is quite small bothphysically and electrically. AT90S4433 has only 4096 bytes ofprogram memory, but every instruction in controllersinstruction set takes space of two bytes, so there is only roomfor 2048 instructions in controllers memory. RF-link softwarewas written using C-language and shortly calculating, there areabout 1800 lines of code in software. Approximately half ofthose lines are comments and another half is actual code. Sothere are at least 900 lines of code. If implementation of eachlines of C code takes two or three instructions, the limit of2048 instructions is very quickly reached. Due to this thesoftware was optimized many times and some of the designedproperties had to be dropped out from the final software.

5.4 RF link protocol

Fig. 9. Data packet of RF-link

In figure nine the data packet of the RF link is presented.Data packet starts with ten preamble bytes. As a preamble thebit pattern “…10101010…” is used. During these bytes, thereceiver is supposed to achieve a bit level synchronization.After the bit level synchronization bytes, there are two bytesynchronization bytes. The byte synchronization bytes are 81h.

During these bytes the receiver achieves the byte levelsynchronization. It would be possible to achieve the byte levelsynchronization with only one byte synchronization byte, butto increase the reliability of the link and to separate the packetfrom noise easier, the second byte synchronization byte wasadded.

After the full synchronization is achieved, there are fourcontrol bytes in the data packet. First control byte implies thenumber of incoming bytes. The second control byte specifiesthe meaning of this packet. Possible packet types are a datapacket and a control packet. Data packet is used to transferdata in the link and control packets function is to control thelinks behavior. The third and the fourth control bytes imply thepackets receiver and sender addresses. These are used if theRF link is expanded to a RF network.

After the first four control bytes there are the data bytes.Amount of the data was restricted to forty bytes. This wascaused by the restrictions in the controller’s memory. Thechosen microcontroller has only 128 bytes of memory forvariables and stack. Due to this it was not possible to handlebigger than forty bytes long data tables. If bigger data tableshad been generated there would have been quite a bigpossibility for the stack to be written over the variables anddue to that the software to lose the track of running.

After the data section there are three more control bytes inthe data packet. First byte is the CRC (Cyclic RedundancyCheck) calculated from the first four control bytes and thedata. CRC is an error detection method based on a division ofthe bit string with a known number. Remainder of this divisionis then used as a check sum [2].

After the CRC there is a number of the packet. This is afree running number generated by the sender. Number of thepacket is needed because the data packet needs to beacknowledged by the receiver after the packet is receivedcorrectly. Last byte is a Sender ID (Identification) number. Inthe RF link this byte was used to specify the cell of the link.

Fig. 10. Control packet of RF-link

In the figure ten, there is a presentation of the control packetused in the RF link. Structure of the control packet has verymuch in common with the data packet. Only difference is inthe data section of the packet. Control packet contains onlytwo data bytes; Function and A. Function field is used tospecify the operation of the packet. In RF link there are twooperations specified for the control packet, acknowledgement,and request for a data retransmission. In both cases the A fieldcontains the number of the data packet to be acknowledged or

requested.If the control packet is used to acknowledge a data packet, it

means that the data packet was received successfully and CRCshowed that no errors have occurred during the transfer. If thecontrol packet is used to request a data packet it means that thepacket was received, but it contains errors and needs to besend again.

In the implemented RF link the only type of control packetis the acknowledgement packet. Retransmission request wasdiscarded because the instruction memory of themicrocontroller ran out of space and in this way it was alsopossible to decrease the amount of communication on radiofrequency. In the RF link, the retransmission is implemented asa time based operation. If a sent data packet is notacknowledged after the timeout time has elapsed, the samedata packet is automatically sent again.

RF-link was designed to operate in radio frequency with atransmission speed of 9600 Baud/s . The used CC1000 radiocircuit would make it possible to use the link with transmissionspeeds as high as 76800 Baud/s, but because the timing in theapplication is quite critical, a lower transmission speed waschosen. Anyway because the manchester coding is used, thebitrate of the link is only half of the baudrate.

6 Personal Position Manager (PPM)Smart position vest is an application prototype implemented

in TESC (Technologies Enabling Smart Clothing) projectduring summer 2001. Vest contains an integrated GPS (GlobalPositioning System) receiver and all the electronics needed tocontrol the GPS receiver module. A user interface of the vestconsists of a capacitive button and a HandSpring Visorpalmtop computer. Push button is also equipped with avibration feedback. The vest is intended for fishermen, berriesand mushroom pickers and everybody who needs a quicksaving of a current location [8].

Operation of the vest is quite simple. When the capacitivebutton is touched, the current location is read from the GPSreceiver and saved to memory of the electronics in the vest.After the location is saved, the vest will activate the feedbackby vibrating the button. So the user will notice that the locationis saved. Afterwards the saved locations can be transferredfrom the vest to the HandSpring for further analysis. Systemcan also act as an ordinary GPS receiver. In this mode thelocation is constantly read from GPS and shown on thepalmtop computers screen [8].

In the first phase of development the HandSpring wasattached to positioning vest with a normal serial cable. Thecable is very unhandy and it greatly restricted the usage of theinterface. So the goal of this work was to replace the cablewith a wireless data link.

Because the RF link was made to be fully transparent, it waseasy to attach the link to the vest. Only difficulties occurredwith the timeout times in the HandSpring’s software. Timeoutswere set to be about 250 ms and it turned out to be a little bittoo short a time. When the timeout times were increased about

four times longer, the system started to work properly.Power consumption of the implemented link was also

measured. The achieved results are sown in the table one.

Table 1. Power consumption of RF link in smart position vest

RF-link Idle / mW Transmission /mW

Receive /mW

InHandSpring 32.36 70.58 70.34

In Smartposition vest 37.78 85.56 86.86

From measured power consumption results it can be seenthat the power consumption of the link electronics placed inthe vest is about fifteen to twenty percent higher than thepower consumption of the link electronics placed in theHandSpring. This is easily explained. Because the operationvoltage of the vest is 3.3 volts and the operation voltage of thelink is only 3.0 volts, must the RF link’s operating voltage beregulated from vest’s operating voltage with a low dropoutlinear regulator. Regulating will always cause some powerlosses in the regulator and that is why the power consumptionincreases. The link electronics attached to HandSpringcontains no regulator, but the operating voltage is takenstraight from batteries. Thereby there is no power loss causedby voltage regulation.

When the power consumption of the link is compared to thepower consumption of rest of the electronics in the PPM, it canbe seen that the RF link does not limit the operation time of theapplication. Link electronic in the HandSpring can operatecontinuously, with duty ratio of 10 %, about three and halfdays if powered from two AAA size 1.5-volt batteries. Thelink electronic in the positioning vest is powered from thesame batteries with rest of the electronics in the vest and it wascalculated that these batteries would be empty after eighteenhours of continuos operation.

Most limiting part of the system is however the HandSpringVisor palmtop computer. With full batteries HandSpring canoperate continuously only one hour. The rest of the positioningsystem is not dependent on the HandSpring and is still capableof operating as a stand-alone application if the palmtopcomputer has run out of batteries. So without the palmtopcomputer, it is still possible to save locations to the vest’smemory, but in this mode it is not possible to see thecoordinates of the current location in real time.

The range of the link was not accurately measured, but itwas noticed that the range is remarkably shorter than the rangemeasured with the CC1000 prototype. This is probably causedby the location of the antenna in the link. RF link in smartposition vest uses small loop antennas drawn directly on thePCB (Printed Circuit Board) and located inside the same casewith the link. The case attached to the HandSpring has ametallic back plane, which is likely to absorb some of theenergy radiated from the antenna. A fully plastic case wouldhave been a better choice, but unfortunately that kind of caseswere not available.

Another reason for the poor range, is probably the mismatchin impedance between the antenna and the RF transceiver’soutput. This mismatch will again cause a reflection of energyand therefor decrease the radiated energy and efficiency of thelink.

7 ConclusionsIn this research four RF transceivers were tested and from

each, DC power consumption, transmission power, and rangeof the link were measured. Upon to these measurements oneRF circuit was chosen for implementation of a wireless datalink. The wireless link was then implemented and integratedinto the smart positioning vest, targeted for fishermen.

During the research it was noticed that the some of thetested circuits are quite difficult to use and all of them are alsovery complex and therefor expensive. Efficiency of the RFtransceivers was also measured to be very poor. Despite of thedifficulties, wireless data transmission grants a great advancein smart clothing compared to regular wires. With wirelessdata transfer it is possible to make smart clothes much morelike ordinary clothing. Without wireless methods it is almostimpossible to make data transfer between different layers ofclothing unnoticeable.

Under these circumstances it is clear that there is a need fora simple, cheap and reliable wireless data transmission methodin smart clothing. Perhaps the techniques based on the radiofrequencies are not the best choice at the moment, but as thetechnology goes on, prices of the RF transceivers come down,and the power consumption of radio links decreases, the radiofrequencies are coming more and more attempting.

8 AcknowledgementWe like to thank Nokia research center, Clothing+, Suunto,

and Technology Agency of Finland for their financial support.

References[1] AVR microcontrollers see, http://www.atmel.com 27.11.2002[2] Atmel Application Note. 2002. AVR236: CRC Check of Program

Memory. Atmel Corporation9 p.[3] ChipCon Datasheet. 2000. Single Chip High Performance RF

Transceiver CC900. ChipCon AS. 19 p.[4] ChipCon Datasheet. 2001. Single Chip Very Low Power RF Transceiver

CC1000. ChipCon AS. 48 p.[5] Nordic VLSI Datasheet 2000. 433MHz Single Chip RF Transceiver

nRF401. Nordic VLSI ASA. 18 p.[6] Hum, A. 2001. Fabric area network – a new wireless communications

infrastructure to enable ubiquitous networking and sensing onintelligent clothing. Computer Networks. 35, pp. 391-399.

[7] ERC Report 25. 2002. The European Table of Frequency Allocationsand Utilisations Covering the Frequency Range 9 kHz to 275 GHz.European Radio Communication Office, pp. 179.

[8] Rantanen, J.; Alho, T; Kukkonen, K.; Vuorela, T; Vanhala, J. 2002Wearable Platform for Outdoor Positioning. Proceedings of the 4th IEEEInternational Conference on Machine Automation. Tampere Finland,September 11 – 13, IEEE, pp.347-357.

[9] Xemics Databook. 2001. XE1201 Transceiver. Xemics SA. 25 p.[10] Zimmermann, T.G. 1996. Personal Area Networks: Near-field Intrabody

Communication. IBM System Journal, No. 3&4, pp. 609-617.

Wireless Community Support for Community Network

Lu Xiao, John M. Carroll Center of Human-Computer Interaction, Virginia Polytechnic Institute & State University,

Blacksburg, VA 24060 U.S.A

Abstract—The implementation of wireless community networks is becoming more and more attractive to computer scientists, communication engineers and sociologists recently. With wireless community networks, local residents can access Internet through mobile devices. Closely tightened to the local community, a community network website provides lots of local information that local mobile users may be interested in. Current community networks’ websites provide same appearance and contents to all users regardless their access means. To provide wireless community support for community networks, we present a place-based system prototype in a wireless community network environment, with our community network—Blacksburg Electronic Village (BEV) as an example. There are three applications in our design: map application, local events calendar, and local MobileMessenger. GPS-equipped Palm PDAs are considered in our user interface design for each application.

1 Introduction Since Cleveland Free-Net [1], one of first community

information systems in the United States, went on line in 1986, community networking has been an Internet phenomenon for almost two decades. Community networks provide local information such as local housing, local education, and local events/news. There are also sections such as free speech, member website, and discussion boards on community networks to improve social interactions.

Increasingly popular in modern information technology, personal mobile devices such as mobile phones, Personal Digital Assistants (also widely known as PDAs) are in common use nowadays. When Internet connectivity becomes available to such devices, wireless community networks become more and more attractive among computer scientists, communication engineers and sociologists. Based on IEEE 802.11b specifications, Toronto Wireless Community Network (TWCN) supports a multi-tier and Toronto-wide public network [2]. New York City Wireless and Seattle Wireless are typical Wireless Community Network examples in United States. They have started to establish permanent nodes. NYC Wireless has even developed a number of useful tools, e.g., node mapping software. As of June 27th 2002, there were 189 Wireless Community Networks worldwide listed on PersonalTelCo.net and the number keeps growing geometrically [3]. In Blacksburg, there is currently no wireless

community network implemented, but researchers in the Center of Human-Computer Interaction of Virginia Tech have started looking into this field. For example, Farooq et al. presents a system architecture called MOOsburg++ that expands a community-oriented collaborative environment, MOOsburg, to support wireless end users [4][5][6][7].

Increasing popularity of PDAs in recent years indicates that users are willing to bear small screen display, limited memory capacity and battery life in order to gain the mobility feature of information. As most current wireless community networks do not provide a wireless social infrastructure for local communities, mobile subscribers need to access community network websites in order to obtain local information. Current community networks’ websites have the same appearance and contents to all users regardless their access means. Considering the fact that current websites are designed for much larger screen display, e.g., desktops’ screen, while a Palmi705 has 160×160 pixel resolution while a desktop has 800×600 at least nowadays) and the increasing number of websites access through mobile devices, is it appropriate to keep the same user interface and provide the same amount of information on community network websites for mobile residents?

Buchanan et al. point out how information should be presented and how users interact with the device is affected by the characteristics of the device [8]. Previous study indicates that user interface design for mobile devices should be different from the design for desktops because of mobile devices’ small screen display and poor resolution [9]-[13]. Moreover, the information degradation may occur when transferring Web pages to mobile formats [13]. We believe it is not a long-term solution for mobile subscribers to browse current Community Network websites in order to retrieve local information. Given wireless community network environment, we present a place-based interactive system prototype that provides wireless community support for a community network, with our community network, Blacksburg Electronic Village (BEV, http://www.bev.net) as an example. In this paper, the system design prototype is discussed first, followed by the detailed discussion of the application functionalities as well as user interface design. We want to emphasize here that the applications we discuss are still in early stage, and the figures we provide are PowerPoint prototypes of the applications. Our interest is the social effect of wireless community support on the community network.

2 System Design Prototype Instead of providing another community network website

that contains applications designed for mobile subscribers, we install applications on subscribers’ PDAs as client applications when subscribers register to their wireless community networks. There is an Internet connected server application that listens to requests from the client applications and responds to them through the wireless network. The server obtains information from the community network website. To relieve the computation burden of PDAs, one solution would be to have a gateway between the server and the client (PDA) and let it take some computation duties. Rist et al. has more detailed discussion on the use of gateway components when mobile devices are connected to a central server [14]. Compared to the design of providing all information on a new website for PDA subscribers, our designed architecture saves communication bandwidth by enabling subscribers to execute a specific application directly. Considering the bandwidth constraint of PDAs, this approach is better. Figure 1 illustrates PDAs are connected to the server via gateway components and the register center of the wireless community network.

Figure 1 Architecture of Wireless Community Support System in Wireless Community Network Environment

3 Design Prototype for Applications on PDAs

3.1 Criteria in Choosing Applications from Existing Community Networks

The organization of contents and the purpose of services are key issues in determining PDA services [15]. First, we need to determine the purpose of the site/service. Jones et al. have claimed that one important task in transforming Web pages to mobile formats is to reduce the amount of information [13]. Therefore, to determine which information to be excluded from existing community networks’ websites should be the first step of the application design process. Which criteria should we use in making this decision?

Compared to desktops, the Internet information that mobile users are interested in may be different because of the

inconvenience and poor readability the small screen brings and the mobility feature of the information that mobile users desire. One criteria for deciding which application to be implemented for PDA subscribers is that the mobile feature of the application would bring convenience to PDA subscribers such as saving time in information retrieval and providing communication channel for local subscribers to interact with each other. As each community has its own characteristics and unique culture, particular criteria are needed when choosing applications for a specific community network.

3.2 Applications Design in Our Example—BEV Our application design uses Blacksburg community as an example. Early in 1996, more than 45% of people in Blacksburg have had access to BEV [16]. As of January 2000, more than 90% of the Blacksburg population has network access, compared to about 40% nationally [17]. Considering the fact that Internet access through desktops is in common in Blacksburg, we focus on applications that are desirable at anytime anywhere, more specifically, applications that are desired even when Internet access through PC are just temporarily unavailable. Applications we choose are Map Application, Local Events Calendar, and MobileMessenger.

Our design follows steps of scenario-based design strategy suggested by Carroll and Rosson [18]. For each application, we state the reason we include it in our design, give the scenarios of the application, re-evaluate the interface metaphor of the application on BEV website, and describe the designed application’s functionalities along with its user interface. Our interface design follows the guidelines provided by Kärkkäinen and Laarni [15]. For example, we use 14 pts font as the minimum font size for all text display by default (Kärkkäinen and Laarni suggest that a smaller font size may deteriorate the reading process), and use text links whenever possible instead of image links which are hard to detect. For all applications, users can end current application by clicking the “close” button and go back to the previous display of the application by clicking the “back” button. We consider GPS technology equipped palm PDAs with 320 x 320 reflective TFT color display. With GPS equipped, a mobile user’s location can be obtained through satellite. Map Application

In the Mobile Info Search project where users can obtain distributed and diverse location information from Internet through their mobile devices, Takahashi et al. have found out that map service is most frequently requested, compared to other services such as weather report, based on their statistical results of the number of access to different applications [19]. Maps can be needed anytime anywhere, for example, looking for a friend’s apartment while driving, finding out closest restaurant when in the street.

The map on BEV website is an image map of Blacksburg functioning only as an online representation of Blacksburg geography. Our map is GIS based and is an interactive map. Our map provides following functions: • Display subscriber interested places such as restaurants,

shops, bus stops • Display the subscriber’s current location and locations of

his/her MobileMessenger friends • Display a route given the departure and the destination

Blacksburg is a university town with convenient bus transportation. Many students take buses everyday to school. The report from Blacksburg Transit for fall semester of 2002 shows that the average daily rides is about 14,000 (the population of Blacksburg is about 33,000). Taking this into account, we add bus route information in the map application. With this additional feature, mobile subscribers can find the closest bus stop to his/her current location giving the destination, and can find all bus stops within the covered area.

Scenario 1 gives an example of our map application: Scenario 1 Billy’s roommate Bob gives him a ride to the café. Two hours later, Billy finishes book reading in the café and decides to take bus home. He starts the map application to find out all bus stops that are close to the café. There are four stops shown on the map. Not sure which one he should take, he checks the details of each one and finds out that the bus stop two blocks away from the café on the other side of the street is the one he needs and the next bus will arrive in ten minutes. Unwilling to wait outside in the big heavy snow, Billy finishes his coffee with no hurry and walks out of the café just before the bus arrives. Considered the screen size limit of PDA, map displayed on

PDA screen covers only a portion of Blacksburg map. The subscriber’s location is the center of the map by default. The map displays hospital, police station, and public library if these buildings are within the covered area. To deicide the size of the coverage area, we use the Mobile Info Search project as our reference. In Mobile Info Search project, the map displayed on mobile devices for Tokyo in the project covers about 350m×500m area (http://www.kokono.net). We choose the coverage area of our map to be 500m×800m considering that Blacksburg is much less crowded than Tokyo.

Figure 2 Map interface on PDAs

Figure 2 illustrates our design prototype. The blue spot in the center represents the subscriber’s current location. The

subscriber’s friends’ MobileMessenger IDs are shown at their

Figure 3 Map interface on PDA—restaurants within covered area are displayed

Figure 4 Map interface on PDAs—detailed information of restaurants close to the subscriber’s current location

current locations—if their locations are available and accessible to the subscriber—marked with red triangles. The subscriber can send instant messages to his/her friends’ by clicking red triangles. By clicking the four arrows on the map, he/she can view other portions of the Blacksburg map that are beyond the coverage area. Places such as restaurants, bookstores within the covered area are displayed when the subscriber chooses from four options below the map. Figure 3 shows the screen shot when the restaurants are chosen to display. After the “details” button is clicked, the information of interested places is retrieved in the alphabetical order of their names including their phone numbers. Each place has a link to a route map that provides the route from the subscriber’s current location to that place (Figure 4). To find a route between two places, the subscriber can click the text link “Find a route” (Figure 2) to enter the departure and the destination name and view the route map. The subscriber can find the closest bus stop of a specific route by clicking the link

Mary

“Find a Bus Route” to enter the destination of the Bus Route. Based on the analysis by Fujii et al. [20], we implement the

route map instead of the survey map for route guide and provide route guide sentences that give direction information using spatial word. The relative position between objects is given. Local Events Calendar

Our events calendar provides similar functionality as BEV events calendar except that our design does not allow subscribers to send event post requests through mobile devices. This is because submitting an event post may involve lots of typing for text input, which is inconvenient for mobile subscribers. Therefore, our system does not support this function. BEV uses monthly calendar to display local events. Events titles and time are displayed in the calendar. Users can obtain detailed information of an event by clicking its title. Due to the small screen size and poor resolution of PDAs, we implement a weekly calendar to provide events information and the event title/time are not displayed in the calendar, instead, a link to events of the day is provided. Figure 5 shows the interface of Local Events Calendar application. Current week’s events calendar is displayed by default. Subscribers can check previous/next week’s events calendar. Users can check events’ details by clicking the “View Events” hyperlink. A day without this text link means there is no event on this day (Figure 5).

Figure 5 Display a week events calendar on PDA interface

We illustrate our local events calendar application with this scenario:

Scenario 2 Tony wants to know if there are entertainment events this weekend while he is eating in the cafeteria on campus. He checks local events calendar with his PDA and finds out that there are four events on Sunday. Only interested in entertainment events and free on Sunday afternoon from 1:00pm to 5:00pm, he chooses to show events that meet these requirements. There are two such events from the calendar. Finding out that both events finish before 5:00pm and he has no time preference to either one, he decides to

check details of both events. He finds out that one event is about a local band performance, and the other is about an exhibit presented by a local painter. He decides to go to the exhibit and he adds it to his PDA calendar.

Figure 6 Interface of PDA after the “View Events” button clicked

The “clock” in Figure 6 has the same time scale of a clock in our daily life. Each spot on the “clock” represents an event that is scheduled to start at that time. The shape of spots indicates whether events start in the morning or in the afternoon/night. Subscribers can choose to view only interested events by specifying event type (e.g., church events, outdoor activity events) and/or time constraint (e.g., events in the morning, events within a time interval). The start and end time of an event are displayed below the clock when the corresponding spot is clicked. If the subscriber then clicks the “Event Details” button, detailed information of the event is retrieved and displayed, including the event title, event place, and event notes (Figure 7). Subscribers can add an event to their PDA calendar automatically by clicking the “Add to My Calendar” button (Figure 7). The distance between the spot and the center of the clock could provide more information.

Figure 7 Event information details presented on PDA

MobileMessenger—Location-Awareness Enhanced Instant Messenger

MobileMessenger is an Instant Messenger for PDA subscribers with location-awareness enhanced in our design. Instant Messenger has been popular over the past couple of years. For example, within five years, the number of registered users of ICQ has grown from zero to more than 100 million [21]. More than 10 million ICQ users login everyday. With MobileMessenger, subscribers’ locations can be available to each other when they send instant messages. Below is a scenario that mobile subscribers use MMessenger to communicate instantly:

Scenario 3 Mary starts MobileMessenger to send a message to Luke. A dialog pops out asking Mary if she is willing to reveal her location from Luke. Mary chooses “yes”. Luke was asked the same question when he receives the message from Mary and he decides to hide his location from her, as this is the first message he received from Mary. After they chat for a while, Luke decides to ask Mary to have lunch together. Noticing that Mary is only two blocks away from him, he suggests a nearby restaurant to meet. Mary finds the location of the restaurant on her map and confirms the lunch event. Subscribers are notified when there are new emails in their

BEV Email address. Friends who are online are listed, and other people the mobile subscriber is chatting with are listed as well. For security purposes, subscribers need to log in to use MMessenger. Figure 8 presents the interface after the subscriber with MMessenger ID “johnld” logs in. The interface provides links to retrieve profiles of friends or people the subscriber is “chatting with”. A subscriber can add people to his/her friends list.

Figure 8 Interface of MobileMessenger

Considering that mobile subscribers sometimes may not want to provide their current locations (privacy issue), our designed system allows mobile subscribers to hide/expose their current locations at any time. When logging in to start using

Figure 9 PDA screen display when users “chat” with MM

the MMessenger application, the subscriber can choose whether to hide his/her current location from his/her friends or not. Figure 8 show that johnld let his/her current location available to his/her friends. By doing so, johnld’s location is shown on his/her friends’ map. “johnld” can hide his/her location anytime by clicking the “Hide My Location” button (When the location is known, the button is named as “Hide My Location”. When the location is hidden currently, the button’s name is “Show My Location”). When initiating/receiving a message to/from someone who is not on the friend list, the subscriber will be asked whether he/she is willing to provide current location information. Figure 9 shows that both of the subscribers’ current locations are not hidden from each other, and each person can choose to hide his/her location to the other one anytime by clicking the “Hide My Location” button. To show subscribers’ locations in such a small screen display, we implement a technology that applies fisheye technology to a GIS map developed by Schafer et al. [22]. An analogy of the technology would be using a magnifier to view subscribers’ locations on the map. The map in Figure 9 is obtained from Schafer et al. paper. To view locations better, mobile users can use the zoom slider of the map.

4 Conclusion We propose a system design prototype supporting

community networks when their physical communities are in wireless environment. To illustrate our design prototype, we use Blacksburg Electronic Village (BEV) as an example. We hope our design prototype provide guidelines for future similar system design. Our future work includes introducing local mobile users to our design for their opinions on our application design, modifying applications if necessary, and implementing applications on PDAs. We will use the wireless environment provided by Virginia Tech to test our applications and perform experiments. We plan to fulfill Blacksburg Wireless Community Network with our community network support, study and compare the social

impact it brings to the community with that BEV brings. There are lots of technical and social issues we haven’t

considered in our design prototype. For example, does the bandwidth of current PDAs support these complex applications, such as map application? How different will it be in terms of usability if we put these applications to a new website for mobile users? Our design assumes that PDAs are GPS-equipped. However, current GPS hardware/software is still pricey (e.g., as of the time this paper is written, an Navman GPS m Series for Palm™ handhelds can cost around $200), is our assumption appropriate? We will look into these issues in more depth.

References [1] National Research Council, Global Networks and Local Values: A

Comparative Look at Germany and the United States, October 2001 [2] Toronto Wireless Community Network.

http://www.esoterraka.com/twcn/about.html [3] Building a Wireless Community Network.

http://www.personaltelco.net/index.cgi/PersonalTelco http://dingo.uwaterloo.ca/~ihoward/papers/WirelessCommunities.html

[4] Carroll, J.M., Rosson, M.B., Isenhour, P.L., Ganoe, C.H., Dunlap, D.R., Forgarty, J., Schafer, W.A., Van Metre, C.A. Designing Our Town: MOOsburg, International Journal of Human-Computer Studies, 2001, Vol. 54, No. 5, pp. 725-751.

[5] Carroll, J.M., Rosson, M.B., Isenhour, P.L., Van Metre, C.A., Schafer, W.A., Ganoe, C.H. MOOsburg: Supplementing a Real Community with a Virtual Community. Proceedings of the Second International Network Conference.:INC2000, pp. 307-316.

[6] Carroll, J.M., Rosson, M.B., Isenhour, P.L., Van Metre, C., Schaefer, W.A., Ganoe, C.H. MOOsburg: Multi-user domain support for a community network. Internet Research, 11(1), pp. 65-73 2001.

[7] Farooq, U., Isenhour, P.L., Carroll, J.M., Rosson, M.B. MOOsburg++: Moving Towards a Wireless Virtual Community. Proceedings of the International Conference on Wireless Networking. ICWN02, Las Vegas, Nevada, June 24-27. 2002

[8] Buchanan, G., Farrant, S., Jones, M., Thimbleby, H., Marsden, G., Pazzani, M. Improving Internet Usability. http://citeseer.nj.nec.com/buchanan01improving.html 2001

[9] Dillon, A., Richardson, J., McKnight, C. The effect of display size and text splitting on reading lengthy text from the screen. Behavior and Information Technology, 9(3) (1990) 215-227.

[10] Duchnicky, R. L., Kolers, P. A., Readability of text scrolled on visual display terminals as a function of window size. Human Factors, 25 (1983), 683-692.

[11] Shneiderman, B., User Interface Design and Evaluation for an Electronic Encyclopedia. In Salvendy, G. (Ed.): Cognitive Engineering in the Design of Human-Computer Interaction and Expert Systems, Elsevier Science Publishers (1987), pp. 207-223d

[12] Laarni, Jari. Searching for Optimal Methods of Presenting Dynamic Text on Different Types of Screens. NordiCHI, October 19-23, 2002.

[13] Jones, M., Marsden, G., Mohd-Nasir, N., Boone, K., Buchanan, G. Improving Web Interaction on Small Displays. http://www8.org/w8-papers/1b-multimedia/improving/improving.html

[14] Rist, T., Brandmeier, P., Herzog, G., André E. Getting the Mobile Users in: Three Systems that Support Collaboration in an Environment with Heterogeneous Communication Devices. Proceedings of the Working Conference on Advanced Visual Interfaces May 2000. http://delivery.acm.org/10.1145/350000/345331/p250-rist.pdf?key1=345331&key2=1697388301&coll=portal&dl=ACM&CFID=6016491&CFTOKEN=37377141

[15] Kärkkäinen, L., Laarni, J. Designing for Small Display Screens, NordiCHI, October 19-23rd, 2002, pp. 227-230.

[16] Carroll, J.M., Rosson, M.B. Developing the Blacksburg Electronic Village. Communications of the ACM, December. 1996, Vol. 39, No. 12, pp. 69-74.

[17] Carroll, J.M., Rosson, M.B. Better Home Shopping or New Democracy? Evaluating Community Network Outcomes. CHI 2001, Vol. 3, Issue No. 1.

[18] Carroll, J., Rosson, M.B. Usability Engineering, Scenario-based development of Human-Computer Interaction, Academic Press, 2002.

[19] Takahashi, K. Miura, N., Yokoji, S., Shima, K-I. Mobile Info Search: Information Integration for Location-Aware Computing. IPSJ Journal, Vol 41, No. 4, April. 2000.

[20] Fujii, K., Nagai, S., Miyazaki, Y., Sugiyama, K. Navigation Support in a Real City Using City Metaphors, Ishida, T., Isbister., Eds.: Digital Cities. Lecture Notes in Computer Science 1765, pp. 338-349, 2000.

[21] ICQ. http://www.icq.com/press/press_release_100m_users.html [22] Schafer, W., Bowman D.A. Enhancing Radar Views Using Fisheye

Techniques. In Interactive Posters section of Conference Supplement for Computer Supported Cooperative Work 2002. pp. 147-148.

Abstract—In this paper we report about our experience inusing mobile computing middleware in context of health-care.The dynamicity and variability of context and conditions makethis environment very suitable for the use of mobile and wearablecomputing techniques. The use of small and portable devices canbe very beneficial in terms of efficiency and vital support topatients. However, the many challenges that this environmentpresents need to be addressed, possibly by a general mobilecomputing framework that could be used in different mobilesettings. We will discuss these issues in the paper along with thedescription of the prototype we have developed.

1 IntroductionSmall and portable devices, such as mobile phones, PDAs

and the like, have recently been pushed on the marked andhave allowed for complex cooperation and communicationpatterns that were not foreseeable some time ago. The abilityto carry these devices, share the content using communicationnetworks, possibly wireless, and synchronize their content withmore standard devices have been seen as essential features.However, these technologies still come with some limitationsand differences with respect to the standard computingplatforms we have used for years. Resources (such as battery,bandwidth, memory) are by orders of magnitude smaller, andpatterns of use change depending on the network availabilityand on the location of users.

Applications have begun to be developed for these devicesin order to allow data synchronization, Internet browsing, andcooperation. The most targeted domains have been MobileCommerce and E-shopping, however it is becoming clear thatthe use of mobile technologies will become quite pervasive inour lives and that we need to support development ofapplications in different areas.

In particular, we have recently been involved in the use ofmobile computing in health care setting. The healthcareenvironment is quite unique in that it brings with it severalconstraints and requirements that any deployable applicationwould have to adhere to. The most obvious issues are those ofpatient confidentiality and doctor- patient relationship. It isvital that medical data is kept confidential via the use ofpotentially several vertical layers of security.Healthcare data is mission critical and errors introduced by anapplication can have potentially fatal consequences. Forexample, in the case of a medical prescribing tool, a

miscalculation or misprint in the dosage of any particular drugto be administered could have serious consequences for thepatient. Hence, it is important that some kind of data integrityassurance is supported by the application.

The clinical health-care working environment is ‘highlymobile’, with clinicians constantly moving around from patientto patient while performing their duties. This constrains theshape and performance of computing devices that can be usedin such an environment. Many organizations have attempted toimplement computing solutions to aid clinicians with theirevery day duties using a networked desktop environment. Inpractice, such solutions have failed to reach their target users,and instead simply served as administration systems. Thereason behind this is the fact that in such a highly mobileenvironment, clinicians make decisions at the ‘point of care’i.e., the patients bedside, and they do not have the time toleave and potentially queue up to refer to a desktop basedapplication. Hence, the ideal platform for use in such anenvironment is the PDA or tablet PC platform, which theclinician can carry around and use wherever necessary.

In this paper we will introduce the platform we havedeveloped for use in health-care scenarios and show thegeneral principles that have driven our design decisions. Wewill show how the platform is planned to be used, and how itcan improve the efficiency of patient care.

The paper is structured as follows: Section 2 describes themobile computing environment and the challenges it presents.Section 3 introduces our case study, looks at the motivationand describes our adopted architecture. Section 4 describes theimplementation in details. Section 5 discusses the interestingoutcomes of our work and shares some of the experiencegained from working in a mobile computing environment.Finally, Section 6 concludes the paper and outlines ourplanned future work.

2 Mobile ComputingPoint of care delivery is vital for the success of any

application in the clinical healthcare environment. Hence, theuse of a PDA platform utilizing wearable technology is idealand is adopted by the work described in this paper. Wearableand mobile technologies introduce considerations andconstraints that have to be dealt with when developingsoftware. This section highlights some of these and explainshow they impact upon development.

2.1 Network Model Mobile networks can be roughly classified into two types,

ad-hoc or nomadic. An ad-hoc network is one that is formed

Exploiting Mobile Computing in Health-careUsman Arshad*$, Cecilia Mascolo* and Marcus Mellor$

*Dept. of Computer Science, University College London, Gower St, WC1E 6BT London UK$Capula Elan, Palmerston Court, Palmerston Way, London, SW8 4AJ London UK

by two or more mobile enabled devices that are in reach ofeach other and can form a compatible network. This model issuited to a peer-to-peer scenario there is no guarantee of anydevice remaining available or indeed being available at all. Itprovides no guarantee of resources or services, and has to dealwith changing conditions such as disconnections, and resourceavailability.

A nomadic network is one that includes a fixed networkinfrastructure of base stations. Mobile devices are able to relyon the resources made available on the fixed infrastructure aslong as they remain within reach of network coverage. Thismodel is suited to a client-server approach where client wouldbe the mobile device and the server would be available via thefixed infrastructure. This model still has the problem ofdisconnections to the network when mobile devices go out orrange. The work described in this paper is based on a nomadicmodel using a client server approach, although the applicationwe are developing has extensions of use in emergency areaswhere base stations are not in reach: we will speak more aboutthis extension in the future work section at the end of thepaper.

2.2 Mobile communications Mobile communications are weak and prone to

disconnections. This means that traditional applications thatrely on network access will not work unless they use analways-on technology, and even then, they could encounterpockets of no coverage. In our view it is important forapplications to take temporary disconnections into account,and adapt accordingly. This involves the use of reflection todetect network availability and the ability of an offline modeof operation when disconnected. This marks a move towardsthick client devices with embedded intelligence.

The situation is complicated further when potentially manyconcurrent users have access to the same piece of data. In sucha situation if some people are working offline on locallycached copies the data while others are working online,inconsistencies can quickly develop. Hence, there is a clearneed to be able to identify such inconsistencies and deal withthem accordingly. With weak communications, data transferrates have to be taken into account. Application developersneed to consider the time it takes to download data to a deviceor to upload from it and whether this time delay makes theapplication unusable. Of course, data rates depend on the typeof mobile technology that is to be used, but is even moresignificant in cases where a user is charged for connection tonetwork on a time basis.

2.3 ResourcesMobile devices such as PDA’s are extremely resource-

constrained in terms of memory, processing power, batterylifetime and screen size. Applications for such devices need tobe resource conserving and lightweight enough to achieve alevel performance deemed usable. The application developeralso needs to take into account the strain put on theseresources during runtime, and there are often tradeoffs to bemade as to where to execute processes and store information,whether it be locally on the mobile device or remotely on a

more powerful device. More details on these issues can befound in [6] and [7].

The way we address these issues is discussed in Section 4.The fact that PDAs have a very small screen and a differentmeans of navigation than traditional systems means thatcareful consideration needs to go into the development of ausable user interface.

In the next section we will describe our approach to the useof mobile computing in health-care.

3 Our approach

3.1 ScenarioThe motivation behind the work described in this paper is to

aid the clinician by empowering him/her with mission criticalinformation at the point of care. This is achieved bydeveloping a PDA based application that uses mobiletechnology in a Client-Server Nomadic setting. Theapplication being developed combines an Electronic PatientRecord (EPR) system with an e-prescribing application. Thepurpose of an EPR system, is to replace traditional paperbased methods of documenting patient records with electronicrecords that are available to multiple users concurrently. Therecords are dynamic in that they change on a regular basis, andglobal consistency is important. One example of the dynamicnature of patient records is current medication that isprescribed to a patient. The e-prescribing application providesthe clinician with a database of drug information including thecomplexities of drug interactions and contra-indications. Theclinician is able to prescribe drugs to his patients and theapplication flags up potential problems caused by druginteractions.

3.2 ArchitectureFigure 1 shows the architecture we have adopted: a client-

server architecture separated by a mobile network. The serverconnects to a central data-store, which contains data shared bythe client PDA devices. The communication between the clientand the server is via a packet based communication protocol.A session is initiated by a clinician logging in to the system viathe client User Display. This initiates the Downloadercomponent to contact the server and retrieve patient recorddata from the database. Once downloaded the clinician is ableto navigate the data via the application. If data are modified bythe clinician, the Updater component ensures that the changesare reported to the server and that the data-store is updatedaccordingly. It also makes sure that the change iscommunicated to all other clients logged onto the system.

One of the key aspects of our approach is ability of theclient to work offline, i.e., if the client PDA is out of reach ofthe network any changes made by the clinician are cachedlocally until such a time at which the network is once againavailable. To enable this the client needs to be network aware.This is achieved by the server Presence Broadcaster regularlybroadcasting one-way messages on the network, which arepicked up by the Presence Receiver on the client. As long asthe client receives these messages, it assumes it is stillconnected to the network. This information is fed into the

updater, which makes the decision as to whether to cache thechanges or send them to the server.

While offline, a client may miss updates made by otherclients. A process to receive these missed updates once theclient is again online is put in place. Further to this, whileoffline, the clinician may make updates that conflict withupdates made by other clients. The Conflict Dectector andResolver component and the Logging component take care ofthis. Further details are provided in Section 4.5.

4 ImplementationWe now describe the details of the platform we have

developed. The server is a Java application that providesaccess to an Oracle database. The client device is also a Javaapplication. The server retrieves data via an API that returnsthe data in the form of an XML document. Similarly changesto the data are committed to the database by passing the APIan XML document representing the changed data. The reasonsfor choosing XML are discussed in Section 4.4. The Serverexists as part of a fixed network infrastructure that is extendedto the mobile clients using an 802.11b wireless LAN.

4.1 Presence InformationIn order to be network aware, the platform needs a

mechanism to gain presence information. The clients use twoapproaches to gain this information1) Active approach – The clients are responsible for

checking if the network is accessible to them. The clientwould send something similar to a ping command to theserver expecting a response to indicate accessibility. Thisapproach is efficient, as minimal messages have to be sentover the network. However the client has to do morework.

2) Passive approach – In this approach the Server is theactive component and continually broadcast a messageover the network attempting to reach clients. The clientssimply listen for this message continually and as long as itis received on a regular basis, they assume the network is

available. This approach has the disadvantage of puttingextra load on the network

We use the passive approach in our scenario at the expenseof the increased network load. This method is preferred as itrequires minimal work on the part of the client, and given thescarce resources available on the client it is preferable to pushwork onto the server end. Further to this, it is expected that theclient is likely to require a lot of access to the network, henceincreasing the number of times the ping-like message wouldhave to be sent.

4.2 Working offlineApplications for mobile devices can fall into three maincategories, when dealing with disconnections.1) Always-on Applications – These are dependent on

network availability and require constant interaction withother networked machines, for example web basedapplications. These applications would fail completely ifthe network was unavailable, and hence are only deployedwith always on communications such as GSM, or arelimited to the afforded boundary of coverage.

2) Hot Sync Applications – These are commonplace on PDAplatforms. In hot sync, it is not critical that the network isconstantly available, and the user can continue to use theapplication when disconnected. When the user reconnectsto the network, a synchronisation process takes place tofilter across relevant information generated as a result ofbeing disconnected to the network. The synchronisationprocess often occurs as a result of the user takingaffirmative action to execute the process. A typical syncapplication could be a synchronization of an email inboxbetween a laptop and a PDA.

3) Auto update applications – These applications fall inbetween the other two approaches. Being connected to thenetwork is important in such applications, however theuser is able to work offline when the network is notavailable. Once back in reach of the network anautomatic synchronisation process can take place. Theseapplications appear similar to hot sync applications, butthere are distinct differences. As mentioned, Syncapplications often perform synchronisation as a result ofan affirmative action on the part of the user, whereas inauto update applications, synchronisation remainstransparent to the user. Further to this auto updateapplications often involve data that is shared by multipleusers, hence synchronisation on a regular basis isimportant so modifications made to the shared data isfiltered throughout the system, whereas hot syncapplications usually involve synchronisation between asmall number of devices (usually two) often belonging toa single user.

Our application follows the auto update model, whichexploits transparency as far as possible, including theimplementation of an automatic conflict resolution component(see Section 4.7). Transparency makes the application moreusable, as the target users will not want to worry about whetherthey are working online or offline.

At the time of writing, many applications particularly thosethat depend on network availability, have tended to treat PDAs

Figure 1. Architecture

CentralDatastore

ServerApplication

Updater Downloader

Datastore Connectivity Component

Conflictdetector and

resolver

Loggingcomponent

Packet based communicator

PresenceBroadcaster

Downloader

Packet based communicator

Updater

PDA based Client Application

Mobile Network

PresenceReciever

User Display

as thin clients, i.e., where the PDA is nothing more than abasic IO device. However our approach employs the PDA as athick client with the embedded intelligence to storeinformation locally when it is disconnected from the network.

As explained in Section 4.1 the server continually multicastsa presence message to the clients. In normal (online) operationany modifications made to the data by clients are immediatelycommunicated back to the server, which makes the appropriatemodifications in the central data store, logs the modification,and then multicasts the modifications to filter them throughoutthe system. The offline mode of operation is triggered when apresence message is not received in a given period of time.

Once working offline, the middleware still acceptsmodifications made to the data, but caches them locally. Assoon as the presence messages are again being received, theclient knows that it can once again enter into online mode,however it is vitally important that the following three processare carried out first:• The client needs regain missed updates from the server to

maintain data consistency in the system.• The client needs to commit the changes it has made

locally to the server• A conflict check needs to be carried out to ensure that the

modifications made by the client while it was offline donot conflict with modifications made by other clients.

These processes are achieved by the conflict resolution andlogging components (see Section 4.5).

4.3 Development on PDAs One of the first things that became clear while prototyping

on the PDA platform was the limitation of memory, whichseverely hinders the amount of data that can be downloaded toa device. PDA applications have to work around thislimitation. In order to cope with it we decided to adopt a‘session based download’ approach. For example, in the caseof the EPR application we decided that a doctor would log intothe system, and only the records of the patients assigned to thatdoctor would be downloaded to the device, the session beingthe use of the application by that doctor. We used thisapproach as opposed to downloading all the patients on a wardfor example.

It is also important to consider memory usage at runtime, asthe size of data to be stored is not the only consideration.Some runtime processes can also be memory intensive, forexample, depending on which parser is used, parsing XML canconsume a lot of memory. Further to this, XML parsing itselfcan be a processor intensive process. Since our application iscentered on delivering data in XML, our choice of parserwould have to give us maximum performance.

Another important consideration for PDA like devices isthe extent of multithreading that is used. In our experience, theuse of too many concurrent threads on such a device can soonmake an application unusable. In fact, at time of writing, Palmhave only just added support for multitasking andmultithreading with the release of version 5 of their PDAoperating system PalmOS. Microsoft’s PocketPC operatingsystem has supported multithreading and multitasking sincerelease, however as the number of threads increases, memory

consumption is also increased and the application becomesincreasingly unusable.

Another constraining factor on the PDA platform is thesmall screen size. This has considerable effect on the kind ofapplications that can be deployed on such a device. Thebiggest change is using a stylus as opposed to a keyboard or amouse. This change impacts the UI as many traditional UIwidgets or components are not usable via such an inputmechanism, hence the developer is restricted to simplecomponents such as buttons and dropdown lists. One of theterms that is emerging to describe the desired features of aPDA based user interface is ‘high poke ability’. This includesusing only simple widgets, but also encompasses usabilitymodels such as ensuring that the user does not have tofrequently tap the screen to use the application to the extentthat it requires too much effort to get even a small amount ofwork done. There is a shift from traditional desktopapplications, which strive to provide a complete andcomprehensive application that offers maximum functionalityand, to a system that is centred on the critical workflow of theuser and includes only the core and most importantfunctionality. In fact such restrictive and simple UIs makePDAs intuitively easier to use and easier to learn than desktopsystems for non computer literate personnel.

Battery lifetime is another concern on PDA platforms, andindeed battery technology is one area, which has not seen anysignificant advancement and is not expected to in the nearfuture. Hence application developers will have to accept thatthe workflow of their applications will have to conform to usefor short stints of time followed by a period of recharging thedevice. Application sessions cannot be long lived such thatthey exceed the battery lifetime. This problem is significantlymagnified with the introduction of wireless communication,which can have significant drain on battery power.

Our application is being developed using the Javaprogramming language. Java is emerging as an importantlanguage in the mobile device arena, and much of this is due toits platform independent nature. With the market still growing,a whole host of mobile devices have emerged including mobilephones, PDAs, tablet PCs and laptop computers each beingideal for use in some scenarios but not others. Further to thismany more such devices are likely to emerge which arespecifically designed for a certain environment. Somecompanies such as Intermec already offer specialised PDAs,which could for example be ruggedized for use in an industrialsetting. Another interesting trend at time of writing is the waymobile phones are striving to become more like PDAs,offering more complex applications, whereas PDAs, are tryingto become more like phones trying to offer voice callcapability. Such heterogeneity between different hardware andoperating systems means that platform independence is highlydesirable. With the realisation of this, Sun Microsystems havealready put considerable effort into developing smalllightweight java virtual machines and standards such asPersonal Java and J2ME to aid this. In our application, the useof several of these devices as opposed to just one may well bedesirable. Hence we have made a point of decoupling the UIfrom the core functionality in order to make the application

portable between these different devices by accommodating anappropriate interface given the form factor of the device.

4.4 Use of XMLThe last section discussed how platform independence isdesirable. XML gives us a mechanism to generically representdata, which is instantly transferable between heterogeneousplatforms. Our application takes this one step further with theuse of XSLT to cater for different platforms. For example,consider the difference between a PDA and a tablet PC.Clearly the tablet PC is much more feature rich and has a muchlarger screen hence can present a lot more informationvisually. One way to achieve this would be to pass all theinformation available from the server to the mobile devicewhether it be a PDA or tablet. On receiving the informationthe different user interfaces on the two devices could decide todisplay all the information, or in the case of the PDA, just asmall portion of it. However this clearly violates the concept oftrying to conserve memory and keep processing to a minimum.Hence our application uses XSLT at the point of data retrievalto filter out the information that is not required for the deviceto which the data is to be sent. This is facilitated by simplyspecifying a different XSL style sheet to the transformer.

XML also separates our application into a middleware layerand an application layer. This is achieved as the middlewareonly deals with XML data. The data is retrieved by themiddleware at the server end from the enterprise databasesystem via an API that returns the data as XML document.This document is then sent to the client device, and themiddleware hands off to the application layer by passing it theXML document. Following this, any subsequent changes madeby the client are communicated to the middleware as XML.Again the middleware sends the XML to the server, at whichpoint it hands off to the application layer by passing it theXML, and so on. The point is that the middleware handles alldata as a CLOB of XML only, and does not care about thesemantics of the XML.

4.5 Conflicts and conflict resolution Allowing users to work offline in a system in which data isconcurrently shared between multiple users, introduces severalcomplexities into an application. For example, changes have tobe cached locally until the user is back online at which pointthey need to be filtered throughout the system. Also while theuser is offline he/she may well miss data updates made byother users who were online. As a result the offline client thenhas an inconsistent view of the data, and may well makeupdates that conflict with updates that have already been made.

Our middleware deals with the complexities of workingoffline by using a server administered logging process and auser configurable conflict resolution process. The servermaintains a global version number, which is incremented witheach update to the data. The update, along with the versionnumber, is logged by the server. Each of the clients maintainsa local version number, which corresponds to the last updatethey received from the server. Comparison of the versionnumbers between the server and client reveals whether anyupdates have been missed, and hence resent. The sequence

diagram in Figure 2 and description below depicts how thisworks.

Figure 2. Missed updates As the diagram shows, both client A and B are online to

begin with, and individually download data from the server.At the point of download the server sends the global versionnumber, which is recorded by the client. Client A then goesoffline, and Client B then makes two successive updates. Theserver updates its global version number accordingly andmulticasts the update along with the new version number to allthe clients. Since client A was offline, it does not receive theupdates, and hence its version number remains at 1. Client Athen goes online once more, and on doing so sends a messageto the server which includes its version number. The server isable to compare this to its global number and thus knows thatclient A missed two updates. The server is able to consult itslog and resend the updates to client A.

The conflict resolution process is carried out on a perupdate basis, so each time an update is sent back to the server,it is compared against entries in the log for potential conflicts.If a conflict does occur the resolution process can then bestarted. The definition of a conflict depends on applicationlogic, and hence the middleware needs to provide a way forthe application to specify rules to resolve conflicts. Ourmiddleware achieves this through the use of XML. When theserver receives an update, it takes the XML for that updatealong with the XML for previous updates from the log andpasses them to the conflict resolution module. This modulethen compares the two pieces of XML for conflicts accordingto rules defined by the application. If a conflict occurs themiddleware first tries to automatically resolve them, otherwisethe user can be notified accordingly.

5 DiscussionPerformance is an important consideration for applications onresource-constrained devices. Given the fact that XML is textbased, and the application will deal with transferringreasonable amounts of the data over the mobile network,means that there may well be a considerable delay while thetransfer is being downloaded. Hence, it was decided to employcompression before sending the data over the network.

The disadvantage to this is that we are now imposing on theprocessing power of the mobile device during the

Examinelog

log

Version 1

PDA A PDA BServer

DownloadVersion 1

online

online

online

offline

DownloadVersion 1

Update

Version 2

Version 2

unreachable

log

Update

Version 3

Version 3

unreachable

OnlineVersion 1

Version 3

decompression process. However, the advantage gained wasfar more significant. Using simple zip format, a compressionadvantage in transmission time of the order of ten was seen.This varies according to the content of the XML, howevergiven the data is similar to that of the English language othercompression techniques that exploit the entropy of this type ofdata could show even more improvement.

The other potential overhead with using XML is the parsingof the data. Many of the fully featured parsers in existencewould simply put too much drain on the memory andprocessing power. However there are several ‘small footprint’parsers that are available that offer basic parsing functionality.We opted for NanoXML [3], but other similar parsers existsuch as TinyXML[4] and MinML[5].

One of the notable consequences of working in the mobileenvironment is the different tradeoffs that have to be made.For example consider the location where data should bestored. It could be stored locally on the client device giving theadvantage of fast access. However, clearly this is going toimpact on the limited memory available on mobile devices.Alternatively the data could be store remotely at the server anddownloaded as required, however this would incur a timeoverhead as the data is downloaded to the device. Thus there isa trade-off here between memory consumption andcommunication overhead, and the decision depends on thesemantics of the data in relation to the application. Forexample data that requires frequent accesses would be betterstored on the client then the server.

Another trade-off comes as a result of the weak processingpower on the mobile device. It would often be advantageous tomigrate processes to a more powerful machine such as theserver in our application. This would save time in executingthe process, although it would introduce a communicationoverhead. It would also ease the processing load on the clientdevice. So again we have a trade-off between thecommunication overhead and the load on the device.

The healthcare community is showing a strong trend in theadoption of mobile technology, particularly in the use ofmobile device such as PDAs [1,2]. Hence there are a vastamount of applications being developed for such devices.Most of the established applications are stand alone with themobile devices such as drug databases and patient monitoringtools. However there is currently a lot of work being done intolooking at systems that utilize mobile technology especially inthe area of EPR. These include the systems described by [8],[9] and [10]. However current systems depend on theavailability of the wireless network and do not address theissue of disconnections. Other work includes location awaread-hoc applications such as connecting a PDA to a remotemonitor at a patient’s bedside to explain diagnosis.

6 Conclusions and Future Work In this paper we have identified the complexities introduced

when working in a mobile environment. In particular we havelooked at resource constrained mobile devices such as PDAs,and shared our experience with developing on this platform.Our case study has shown one example of how small portabledevices can be employed to bring significant benefits over

traditional workstation based systems. Introducing mobilecommunications to the devices opens the door to a wholerange of novel application.

We found that in a PDA based development environmentthe application programmer has to be more aware of theimplications of mobile computing and often adapt the usagemodel of the application to accommodate these. Our casestudy has presented a generic architecture that for data sharingclient server applications that could be employed in manyscenarios. In particular we have emphasized the ability of ourapplication to work in an offline mode of operation, andhaving a mechanism to detect and resolve conflicting changesto data using application specific rules.

The future direction of our work is looking to extend theprincipals learned, into an ad-hoc peer to peer setting. This is amore dynamic environment in which the mobile devicescannot rely on resource availability at all. Further to this in anad-hoc setting, all devices may be potentially resourceconstrained. The natural extension of our case study into anad-hoc environment is in the use of ambulatory care. Forexample data may be recorded in an ambulance on the way tothe hospital and on reaching the destination transferred to aclinicians PDA or automatically integrated into the hospitalsystem.

References[1] M. Ancona, E. Coscia, G. Dodero, M. Earney, V. Gianuzzi, F. Minuto,

and S. Virtuoso, “Ward-In-Hand: Wireless access to clinical records formobile healthcare professionals.” TEHRE 2001 m-Health Conference,First Annual Conference on Mobile & Wireless HealthcareApplications, November 2001

[2] G. Dodero, V. Gianuzzi, E. Coscia, S. Virtuoso, Wireless networkingwith a PDA: the Ward-In-Hand project, Proc. Workshop on "CORBAand XML: towards a bioinformatics integrated network environment",Genova, 17-18 May 2001. 115-118.

[3] NanoXML http://web.wanadoo.be/cyberelf/nanoxml/[4] TinyXML http://www.gibaradunn.srac.org/tiny/[5] MinML http://www.wilson.co.uk/xml/minml.htm[6] C. Mascolo, L. Capra, W. Emmerich. Mobile Computing Middleware.

In Tutorial Notes of Int. Conf. Networking 2002. LNCS 2497. Springer.[7] C. Mascolo, L. Capra, S. Zachariadis, W. Emmerich, XMIDDLE: A

data-sharing middleware for Mobile Computing. Wireless PersonalCommunications 21:77-103. Kluwer 2002.

[8] O. Portale, Healthcare: the mobile opportunity, 08 November 2002http://www.sun.com/mobility/enterprise/feature_story.html

[9] D. K. Vawdrey, E. S. Hall, C. D. Knutson, A self-adapting, transport-aware mobile patient healthcare insfrastructure.http://www.poketdoktor.com/PoketDoktorArchitecture.pdf

[10] Sybase, Mobile computing in healtcare, http://was.sybase.com/mec/2959healthcare.pdf

Sticky Editor: A Visual Coordination Technique for Smart Appliances

Yuu Furuichi

Aiko Shiwaki Masayuki Iwai

Hideyuki Tokuda

Keio UniversityGraduate School of Media and Governance

Faculty of Environmental InformationEndo 5322, Fujisawa, Kanagawa, Japan

Abstract

In this paper, we developed a Sticky Editor Architec-ture(SEA) which provides intuitive method for defining ap-pliance coordination by using Sticky Editor and ConductorModule which are distributed modules to address change-ability of user requests. By using SEA, users can definecomplex coordination such as a serial coordination and aparallel coordination. Furthermore, Sticky Editor is a com-ponent of SEA provides graphic interface to the users. Con-ductor Module provides an ability to react to user requestsby producing and deleting intermediate node of networkcomponent. By using SEA, users can define appliance coor-dination without programing skills. We evaluated the over-head of SEA and found that if is acceptable to maintain theuseability.

1. Introduction

In the past several years, we have seen an evolution intechnology and development of network devices. Home ap-pliances have been equipped with a network device. We re-fer to these appliances as networked appliances. Networkedappliances can cooperate with each other by communicatingover the network. Some techniques have been developed forappliance coordination. For example we can use HAVi[1],Jini[2] and UPnP[3] to create a new coordination servicebetween networked appliances. In today’s cooperate envi-ronment, we can make a new coordinated service betweennetworked appliances using these techniques.

We developed an appliance coordination system called”Sticky Editor”.Appliance users often does not have skillsto program or use computers . Therefore, appliance coor-dinate system should have a user interface for these inex-perienced users. Sticky Editor provides intuitive techniqueand a visual interface to define coordination of networkedappliances.

In this paper, we first show the problems and require-ments of user interface for appliance coordination in section2. We describe the detail of model and implementation ofSticky Editor in section 3, and section 4 provides an imple-mentation of SEA in SSLAB[4]. In section 5, we providerelated work and evaluation of the Sticky Editor. Finally,

we summarize this paper in Section 6.

2. User Interface for Appliance Coordination

Distributed middleware such as HAVi, Jini and UPnP arebecoming popular. With these techniques, users and appli-cation programmers can coordinate appliances.

But users would need to configure settings such as inputcontrol policy, and write a code or XML files with all of theavobe metioned architectures. We figure out the problemsand requirements of user interface for appliance coordina-tion.

2.1. Problems and Requirements

With the pervasion of networked appliances, not only ap-pliance coordination is defined by application programer.User’s requests change by context. Therefore, in some casesit is preferable to allow users to define coordination of appli-ances. We explain three problems concerning user interfacefor definition of appliance coordination in such cases.

The first problem is complexity involved in connection.Among networked components, establishment of connec-tion require IP address, device name, and network protocol.However, appliance users cannot readily perform these sortsof settings.

The second problem is invisibility of appliance coordi-nation. Appliance connection and their condition usuallycannot be seen in the physical space.

The third problem is unconformity with user interfaceand user behavior. Appliance coordination has to blendwith human action, since appliance coordination is a per-sonal way of computing.

We show hte requirements below.

Brief Connectivity

A user interface for coordination definition needs to pro-vide an intuitive interface to solve complex operations. De-vice naming and network configuration are complex opera-tions for appliance users. By providing user interfaces withintuitive technique such as visual or phonetic interface, thisproblem can be solved.

Visibility

A user interface must provide visibility. Especially, con-dition feedback is an important factor of appliance coordi-

nation. Appliance coordination is defined on invisible plat-form, as in network and computing. The system must showthe condition to users for inspection, so visibility is neces-sary for user interface.

Conformity

When letting users define coordination, computer styleof user interface may not be appropriate. By using suchstyles, users who aren’t used to using computers could findit difficult to define coordination. To solve this problem,user interfaces must have conformity with real-world hu-man action. By keeping resemblance to real-world humanaction, users can difne coordination without specific knowl-edge of programing. For example, tying strings togetherresembles connecting network components, and organizingbooks is similar to manipulating files and databases. In real-world, users are acting in various ways. For example, writ-ing, calling and watching. By embedding these kinds ofactions, user interfaces could enhance usability.

In the next section, we explain an architecture calledSticky Editor Architecture that has brief connectivity, vis-ibility, and conformity.

3. Sticky Editor Architecture

In this section, we explain Sticky Editor Architec-ture(SEA) in detail. First we describe Sticky Model andSticky Editor, and then we describe a model called “Con-ductor Model”.

Figure 1. Concept of Sticky

3.1. Sticky Model

In this section, we describe Sticky Model. Sticky Modelsolves the problem of conformity. Using this model, userswho has less skills to use or program a computer, can de-fine coordination with conformity. In Sticky Editor Archi-tecture, we use Sticky Model to define coordination. Thegeneral concept of Sticky is outlined next.

First , a Sticky is used to simply write down a note andpost it.

Second, by posting a Sticky, users can notice markedinformation easily.

Finally Sticky can be posted and peeled off easily.

Using these concept, users define coordination in StickyModel. Next, we show how to define coordination.

When users try to define coordination using StickyModel, they need to select “Trigger appliance”and “Targetappliance” first. Trigger appliance is a supplier of event

and target appliance is a appliance controlled by users. Af-ter users select each appliance, users decide a trigger eventand appliance control. Trigger event is a state. In thismodel, when an appliance changes a appointed state, ap-pliance throws an event. About appliance control, controlcommands are state too. By receiving a state type appli-ances are controlled. By writing a state after control inSticky , and posting Sticky to state that is a trigger event,users can define coordination.

The case in which users want to define appliances is be-low.

"!$# &% (')!)*'+,.-/!0

Users lay out these factors below.1+2 % 3!$4%46578$9;:<= => 1 4= =

1)? .--@A3! = = > 1+B #33CD- = =1+2 % 3!$4%4 *5E9,$;:F = = > 1+G .-HH! = =

1 5E9C;:F 2 % 3!$4%4= =D> 1+IKJ = =

After lay out, as shown in Figure 1, users write a triggerevent on Sticky and then attach a Sticky to appliance state.After the user conducted this action, coordinations are de-fined. In this case, users attach the Sticky that have “Lightturn on” to “DV Player running” written on them.

Using a number of coordination, SEA enables users todefine more complex coordination. When a user writes twoStickys and post it, the user can define complex coordina-tion. Next, we show a sample of serial coordination andparallel coordination.

Figure 2. Required Condition of Sticky

Linear Coordination

Serial coordination is defined by posting Stickys linearly.Users can define serial coordination by procedures outlinedbelow.

The user uses two Stickys, one Sticky is labeled “DVPlayer run”, and the other Sticky is labeled “Light turnoff”.

First Sticky is posted to “Chair is sat”, second Stickyis posted to “DV Player run”.

L

When chair is sat on, dv player runs and then lightturns off

In this case, where the coordination is defined linearlywith two Stickys, and the user can make a control flow.

2

Parallel Coordination

By posting Stickys in parallel, users can define sufficientcondition and required condition for an action. We showtwo samples below. First, the case in which a user definessufficient condition.

The user uses two Stickys, both Sticky is labeled “DVPlayer run”.

First Sticky is posted to “Chair is sat on”, secondSticky is posted to “Light off”.

L

When the chair is sat on, or the light is turn off, DVplayer starts to run.

In this case, coordination was defined using sufficient con-dition “A chair is sat on” and “Light off” to play DV Player.Next the case in which a user defines required condition.

The user uses four Stickys, first two Stickys are labeled“DV Player run”. Third Sticky is labeled “Light off”.The last Sticky is labeled “Chair is sat on”.

First two Sticky are posted to “Chair is sat on” and“Light off”. Third Sticky is posted on a Sticky that isposted to a chair. And the last Sticky is posted to aSticky that is posted to a light.

L

When the chair is sat on and light is turned off at thesame time, the DV player starts to run.

In this case, coordination is defined using required condi-tion “Chair is sat” and “Light off” to play the DV Player.As shown in Figure 2, the overlapped Sticky become postedto both state “Chair is sat on” and state “Light off”. By do-ing so, the action of overlapping two Stickys define requiredcondition.

As illustrated above, Sticky Editor Architecture enablesusers to define complex coordination linearly and in paral-lel.

Figure 3. Overview of Sticky Editor

3.2. Sticky Editor

We designed Sticky Editor, which satisfies the user in-terface requirements above. Characteristics of Sticky Editorare outlined in this section.

Sticky Editor uses graphics. Figure 3 shows a screenshotof Sticky Editor and Figure 4 shows the target real smartspace in our laboratory. Sticky Editor helps users definingappliance coordination by using a factor of Sticky.

To generate the graphical interface, Sticky Editor obtainssome information such as ID, positional information andcontrol protocol description from each services or devices.ID that is unique, is named by middlewear of Dragon[6] [7]automaticaly. Postitional information is named by appli-ance admin or sensor. Postitional information’s value hasroom name and coordinate value. Using these positionalinformation, Sticky Editor generate graphics. Control pro-tocol description is provided by the vendor of the appliance.In this description, there are control protocols ,type of stateand event. Sticky Editor uses this description to translateevents to control commands. In the next, we show charac-teristics of Sticky Editor.

Figure 4. Target Real Smart Space in keio

3.2.1 Character of Sticky Editor

Brief Connectivity

When coordinating appliances, complexity of definitionis a problem. Sticky Editor solves the problem by graph-ical interface. By using graphical interface, Sticky Edi-tor enables intuitive use. Without graphic interface, usersmust write a configuration. By selecting trigger and con-trol, Sticky Editor connects target appliance and trigger ap-pliance without complected setting.

Visivility of Netowork Conponent

Sticky Editor has a graphical interface. By using graph-ical interface, users can be aware of network conponents.Graphical interface provide 3D graphics that write a tar-get space. In this 3D graphics, some target appliances andSticky are written. In the graphics, shown an appliance thatis shown is an active trigger appliance and Sticky is a co-ordinate definition. From this graphics, users can recognizeappliances and coordinate information. Above, Sticky Edi-tor solves the problem of visivility.

Adaptability for condition

At the edge of coordination system, system and appli-cation programmer need to consider restructuring, recycleand effortless establishment. Sticky Editor provides adapt-ability, so the system can be used in many kinds of placeand condition. We describe this in detail in the next sec-tion. As shown in Figure 5, Sticky Editor is created form anumber of components that is made from files. When Ed-itor starts, these files are first transmitted from appliances.

3

The files are graphic information of appliances. Addition-ally, even if there is no file with a space information, StickyEditor gets appliance information matching their location.As explained above, Sticky Editor correspond to conditionof actual space.

Figure 5. Visual 3D Room Modeling

3.2.2 Actuating Protocol

Next, we describe the procedure of appliance coordina-tion. Figure 6 shows some pop windows that appear duringthe process definition.

1. First, user pushes a button to make a “Sticky”, and thenthe system shows a pop window to the user to selectcontrolled appliance and appliance condition.

2. Next, the user touches an appliance that controls ap-pliance inside a monitor that is showing Sticky Editor.Then, the system shows a message to the user to selectcontrol appliance condition.

3. After selecting the control appliance condition, StickyEditor start defining the coordination.

4. When definition of appliances is completed, Sticky isattached near the control appliance.

Figure 6. Dialogs to define

3.3 Conductor Module

Appliances that exist today usually have their own pro-tocol to connect and control. They need to know other pro-tocols to ensure connection with different appliances. Butto consider extra efforts placed on appliance vendors, this

approach is a tall order. The Conductor Module solves thisproblem by using an intermediate node called Conductor.

Conductor is an intermediate node between control ap-pliances and controlled appliances. The Conductor is madeimmediately after coordination is defined and after handlingcoordination, it is terminated. When Conductor receives in-formation of state changes from control appliance, changescontrolled appliance’s state. Since the Conductor has amodule for each protocol, it can connect to both appliances.

Distribution of Conductor

In Sticky model, users define coordination constantlyand asynchronously. Also, there is no guarantee that thereis only a single user, so the system needs to hold scalabilityand failure resistance for them. Next, we describe character-istics of Distribute Model for Sticky Editor. For this require-ment, the Conductor Module adopts a distributed model.

First of all, by one Conductor existing for one definitionin the model, Conductor can bear a plenty of control com-mand by one appliance. If one conductor controls manycoordination and one appliance changes state at every mo-ment, it becomes difficult to keep the quality.

Second, The Distribute Model for Sticky Editor allowsproduction and deletion in any host. As in Figure 7, a Con-ductor can exist in a host near the control or controlled ap-pliance and some other hosts. By this model, system canhold quality, since separating control host and executionhost brings load distribution.

Using this model, the system can reflect not only net-work condition and host’s specification but also characterof request such as short period coordination and long-termcoordination.

Figure 7. Distribution of Conductor in SSLAB

4. Implementation in SSLABIn this section, we explain the prototype implementation

of SES in Smart Space Laboratory(SSLab)[4]. SSLab is aroom with embedded devices to realize the ubiquitous com-puting environment. First we describe orientation of StickyEditor Architecture. And then we describe Sticky Editorand devices that are used by SEA.

4.1. Orientation and Construction

Currently, SES is built based on a middleware calledDragon[6] [7]. Figure 8 shows Orientation of Sticky Edi-tor Architecture. SES can be built by RMI, UPnP or any

4

other underlying middleware instead of Dragon. In the im-plementation at SSLab, managing Dragon Services, SEShas realized to define appliance coordination. Sticky Edi-tor searches Dragon Service by using JINI Look Up Serviceand get these information.

When Sticky Editor define coordination, first it receivestrigger component and target component from user input.And Sticky Editor obtains the kind of event and the controlprotocol description.(1) By using these information, StickyEditor create a conductor that translate event to controlcommand.(2) After creating, Managerment Unit relays andconnects conductor from trigger to tareget component.(3)By this connection, target component is notified of con-trol commands that are translated from trigger componentevents by conductor.

By these operations, a control appliance becomes capa-ble of controlling a controlled appliance.(4)

4.2. Hardware Devices of Appliances

Devices that can be used by SES to define coordinationare listed in Table 1.

Using these devices, we enable definition of coordinationin SSLab. Some examples are listed up below.

DV and Light : when a DV is played, light turn offautomatically

Watch and Mail Sender : when the time is 2 o’clock,send mail to a user

Button and DV and Light : when button is pushed,DV player is running and then light turns off.

Figure 8. A Button Sensor, A Light Sensor,and A Chair with Sensor

4.3. Dragon: Event Delivering Middleware

In SEA, we use event-driven control model. Basically,SEA uses appliance state to control appliances. So, SEA isbuilt based on a framework of constructing flexible event-driven systems for distributed networked devices and ap-pliances, called Dragon. Dragon enables construction andmodification of an event-driven system easily by usingDragon interface. Dragon is built on top of Jini/Java andcan be executed on any Jini/Java compliant machines. Ad-ditionally, Dragon incorporates soft real-time event deliveryto enhance the predictability of behavior of the constructedsystem.

Figure 9. Orientation of SES

5. Related Work and Evaluation

In this section, we describe some related works that real-izes techniques for defining coordination and evaluation ofSEA.

We quote some techniques that are related to this paper.Universal Plug and Play, Jini,and HAVi are technologicalspecification for connecting network components. By usingthese techniques, we can define appliance coordination. Butthese technologies do not focus on user interface. Thereforeusers need to configure complex operation.

InfoStick[8] is a framework coordination for appliances.This framework provides a specific device called “InfoS-tick”. Using InfoStick, users can carry digital informationbetween appliances. By selecting two appliances, send ap-pliance and receivrer appliance, InfoStick define coordina-tion. However, InfoStick does not correspond to conditionsunlike Sticky Editor. Sticky Editor provides condition ar-chitecture such as serial condition and parallel condition.

Touch-And-Connect[9] is the initiative connectingmethod for wireless devices. By touching two buttons thatare equipped to appliances, users define coordination. Thismethod satisfies conformity with human action. However,not all appliances implement these buttons, so users are un-able to define coordination between different sort of appli-ances such as Light and Dv player.

Figure 10. Evaluation of Overhead

5.1 Evaluation

Response time is one of a big factor for user interface.We evaluated the overall time to coordinate appliances. Fig-

5

Table 1. Device ListDevice State Command Complement

DV Player playing,stopping play,stop connected PC by using IEEE1394PDP on,off on,off connected PC by RS-232C

AMP Selector 1,2,3,4 select source 1,2,3,4 connected PC by using IEEE1394Light on,off on, off directly connect to network

Button Sensor pushing, not – connected PC by RS-232CCup Sensor laying down, not – connected PC by RS-232C

Chair sitting, not – connected PC by RS-232CMail Sender – send mail builded inside of PC

Speaker – ring 4 sounds builded inside of PCWatch hour – build inside of PC

ure 10 shows times for interface creation, connection ofDragon and Producing Conductor. Acoording to the result,even if number of coordinations increases, creation timedoes not increase. System must need to take 5 to 6 sec-onds to create coordination. In detail, connection of Dragonand Producing Conductor are taking major part of the over-all time. This result is shown by adaptability of networkcomponents. In these implementations, network compo-nents register to Look Up Server of Jini. By registeringto server, system can use a number of user interface andfind components quickly. Furthermore, from our experiencewith demonstrations conducted to real users, this overheadis enough for users to use the system without discomfort.But it scalability is taken into cosideration, this result is notenougth to satisfy actualising real-world. So in the future,we need to take scalability into consideration.

6. Conclusion

By developing the Sticky Editor and Conductor Modulein the Smart Space Laboratory, we demonstrated the highusability of the SEA architecture in a ubiquitous computingenvironment. Middleware that exist today are not able tobe managed without complex operation. Also, these mid-dleware does not consider changeability of user’s requests.Therefore, users can not get sufficient benefit. In this pa-per, we developed Sticky Editor Architecture(SEA), whichsolves problems in coordinating appliances.

Sticky Editor provides smooth coordination architectureby using Graphical user interface and single method to co-ordinate appliances to users by using the concept of Sticky.Conductor Module provides a distributed model that con-siders changeability of user’s requests. Users are able tocoordinate appliances smoothly. In ubiquitous computingenvironment, users can use many services in the environ-ment. But if there is a necessary skill to use these services,they can not receive much effectiveness. Considering this ,SEA is a valuable appliance coordination system in ubiqui-tous computing environment.

In our prototype implementation, we assumed a use ina home. In order to take scalability into consideration, adesign not only to fit a home but real environment is needed.

References

[1] Sony, Matsushita, Philips, Thomson, Hitachi, Toshiba,Sharp and Grundig: Specification of the Home Au-dio/Video Interoperability (HAVi) Architecture (1998).http://www.havi.org/home.html.

[2] Sun Microsystems, Inc.: Jini Architecture Specification(1998). http://www.javasoft.com/products/jini/specs/jini-spec.pdf.

[3] Universal Plug and Play Forum: Universal Plug and Play(UPnP) (1999). http://www.upnp.org.

[4] Okoshi, T.: Smart Space Laboratoty Project: Toward the NextGeneration Computing Environment, IWNA2001 (2001).

[5] IEEE: Standard for a High Performace Serial Bus (1999).

[6] Iwai, M., Nakazawa, J. and Tokuda, H.: Flexible DistributedEvent-Driven Programming Framework for Networked Appli-ances and Sensors, The 3rd International Symposium on Dis-tributed Objects and Applications Short Papers Proceedings,pp. 61–68 (2001).

[7] Iwai, M., Nakazawa, J. and Tokuda, H.: Dragon: SoftReal-Time Event Delivering Architecture for Networked Sen-sors and Appliances, The 7th International Conference onReal-Time Computing System and Applications, pp. 425–432(2000).

[8] Kohtake, N., Rekimoto, J. and Anzai, Y.: InfoStick: An Inter-action Device for Inter-appliance Computing, Lecture Notesin Computer Science, Vol. 1707, pp. 246–?? (1999).

[9] Iwasaki, Y., Kawaguchi, N. and Inagaki, Y.: Intutive Con-nection Method for Wireless Devices, DICOMO2002, p. 194(2002).

6

Abstract—In a "ubiquitous" (or "pervasive") computing environment, nomadic users make informed decisions based on contextual information. A major challenge in creating this type of environment is to provide the ability to retrieve and process data associated with - and stored on - real life objects. This report presents an architecture that meets this challenge by building a generic framework that integrates a number of different technologies such as smart tags, RDF/XML, 802.11b, 802.15.4, and Java.

1 Introduction Mark Weiser first used the term “ubiquitous computing” [1], [2] in 1988 with the intent of describing a future reality in which invisible computers, embedded in everyday objects, replace PCs. A number of important developments occurred since. “Pervasive computing”, “context aware computing” [3], “sensor networks” [4], “ad hoc networks” [5] have been topics of research since early 1990s. Our research can be placed within the same general context as HP’s CoolTown [6] or Microsoft’s Easy Living [7]. The work that makes the subject of this paper takes one step further an earlier pervasive computing FT R&D SSF research project on RF-ID tags.1

1.1 Previous work We studied the use of RF-ID tags in a realistic home situation. A pharmacy cabinet was equipped with a RF tag reader. RF-ID tags were attached to medicine bottles placed inside the cabinet within the reader’s range. The reader was interfaced with a PC connected to a LAN. A medicine database reflecting the content of the cabinet is kept up to date on a server. The system reacts in an intelligent manner to events such as medicine bottles being brought in and taken out of the cabinet by notifying the user with informative and/or warning messages (e.g. in the case of unwanted drug interactions).

1.2 Current work Once the initial RF-ID tags project was completed it became apparent to us that the next logical step to be taken in our research would be to use more powerful small devices such as

1 RF-ID tags are small, cheap, inductive passive devices capable of storing static information (such as an ID) that can be read using an RF tag reader.

smart tags2 in order to create a pervasive fabric that allows mobile devices like PDAs or smart-phones to get contextual information from their environment. Each smart tag stores static and/or dynamic data that represents information pertinent to the physical object the tag is attached to. The tag is equipped with sensors that can take readings from their environment and convert them into data that is then stored locally in the smart tag’s memory.

2 General Requirements The basic requirements that we try to comply with when we started this new project were:

1. A PDA is able to retrieve information from all smart tags in radio range and make it available to the user.

2. Since the radio interface on smart tags has a limited range some basic ad-hoc networking capabilities on the smart tags are needed so that a PDA positioned out of the range of a certain tag can retrieve that tag’s data thru a simple multi-hop message relay mechanism if an ad-hoc network3 can be established between smart tags and the PDA.

3. The PDA has to be able to offer the user minimal information without accessing an existing network infrastructure.

4. At the same time the user will be provided with an additional level of detail about certain items by giving him or her access to more complex and powerful web-based services if such services happen to be available at the user’s current location.

5. Last but not least the intent is to build a generic framework that can be re-used for various real life applications.

3 Application Description We focused our efforts into implementing 2 demos on top of a generic infrastructure: a retail application (Deli Shop) and an inventory management application (Construction Site).

3.1 Deli Shop We imagined a Deli Shop in which smart tags are attached to items for sale (such as a cheese box and a bottle of wine). A

2 Smart tags are active devices that have their own CPU and memory. They can also be equipped with sensors and/or actuators. They are capable of exchanging data over a radio interface.

3 A network formed by wireless hosts which may be mobile. It does not use a pre-existing architecture.

A Ubiquitous Computing Infrastructure Created with Smart Tags

Alfred Chioiu, Dominique Barthel, Pascal Le Menn France Telecom R&D, South San Francisco

alfred.chioiu, dominique.barthel, pascal.lemenn@rd.francetelecom.com

customer walks by the shelves of the Deli Shop carrying a PDA. The PDA detects the tagged items and presents the customer with both static (name, description) and dynamic (temperature history) information associated with the item. If the PDA can establish an Internet connection over the 802.11b interface the user is presented with a web link pointing to the web site of the item’s producer.

3.2 Construction Site On a Construction Site smart tags are attached to containers. A foreman carrying around a PDA retrieves information with respect to the content of the containers. The foreman can gain access to information associated with containers situated out of PDA’s radio range using the ad-hoc networking capabilities of the smart-tags.

4 Platforms

4.1 Mica Mote After evaluating a number of hardware platforms to be used as smart tags such as DOS stamps with RF capability we selected the UC Berkeley MICA mote for implementing smart tags behavior. The key factors taken into consideration were computing power and flexibility. The fact that both the hardware and the operating system are under public domain was an additional incentive to use it. The Mica Mote is a 2nd generation mote module developed by UC Berkley running TinyOS [8]. It is used for research and development of low power, wireless, sensor networks. Mica mote uses a single channel radio operating at 916.5 Mhz, on an Atmel Atmega 128L micro-controller running at 4 Mhz, 128 Kbytes of nonvolatile storage and 4 Kbytes of SRAM. In order to minimize the size of the mote we designed an additional daughter board to hold a coin cell that replaces the 2 AA batteries the mote comes equipped with originally from the manufacturer [9]. On the daughter board we also provided the connections to interface our temperature sensors.

4.2 PDA We preferred the COMPAQ iPAQ over less powerful and less expensive devices such as those from PALM mainly because of the advantages offered by Personal JAVA when compared to J2ME. Another factor in selecting this platform was the availability of libraries and development tools. Derived from Requirement 1, we had to provide the PDA with radio capability similar with that of the motes. The easiest way to do this was to mount a mote on the PDA expansion pack and connect its RS232 port to the serial port of the PDA through the cradle connector.

4.3 Server This can be a PC with a wireless 802.11b card configured to communicate with our PDA. Since we wanted the benefits of portability, we use a laptop on which we run a remote display application that mirrors the PDA’s screen, so that the demo can be given to a larger audience. Currently, for historical

reasons, our RDF parser also runs on the server. (Please read the next section for more details on this.)

5 System Architecture and Implementation By using smart tags with CPU and memory there is no need anymore for the centralized architecture of the previous RF-ID tags project where the entire application software was built around a centralized database containing records associated with IDs embedded in the RF tags. So we decided to create a distributed architecture in which the smart tags are independent nodes that behave in a similar manner. The term distributed refers to the fact that the information associated with each item resides on a smart tag and not in a central database record as in our previous RF-ID tag project.

PDA

LEGEND

SERVER

MoteRDF packet

MoteRDF packet

MoteRDF packet

Internet

802.11b802.15.4LAN

Figure 1 System Overview

To assure compliance with Requirement 5, RDF4 ontology was used in order to describe the objects to which smart tags are attached. RDF [10] was an attractive solution because its representation of named properties and property values fits well into relational databases: this would make integration with a legacy infrastructure easier. Also, we foresee that RDF is going to play an important role in the future in e-commerce and web-based transactions. Finally we found a number of RDF tools (such as an RDF parser) available under the GNU license agreement terms. Since object representation study is not within our main interest area we didn’t spend much time evaluating other RDF alternatives (e.g. the Physical Markup Language). A simple protocol was developed on top of the existing TinyOS radio stack. The main reason for doing that was the fact that the RDF packets consist of a few hundred bytes while the size of the payload inside the packets that can be exchanged over radio is 30 bytes (in TinyOS 0.6.1) so a mechanism for segmentation and reassembly of RDF segments transmitted from smart tags to the PDA’s mote was needed. In addition, a simple session management logic dealing with

4 Resource Description Framework provides a lightweight ontology system

to support the exchange of knowledge on the Web.

events such as initial discovery, connect and disconnect was also implemented. A mote can process (transmit, receive) a maximum number of 20 radio packets per second. During testing, the PDA was able to establish and maintain sessions with 6 motes at the same time without any significant impact on the user interface experience. It is clear that there is a scalability limit but we didn’t spend much time trying to find out the maximum volume density of smart tags that can simultaneously be in contact with the PDA while maintaining an acceptable user experience. This will be an interesting topic to explore in the future. The application software on the iPAQ is written in JAVA and runs on top of an Insignia JVM [11]. Since we were developing a prototype, we decided to use a single-threaded software architecture in order to shorten the development time by avoiding any issues created by concurrency. A single-thread processing solution also made testing and debugging easier. At this time, our RDF parser runs on the server, however since the parser is written in JAVA we plan to port it to the iPAQ so that Requirement 3 is satisfied. This should also improve the execution speed of our application by eliminating the need to transmit RDF packets to be parsed over the 802.11b link.

6 Conclusion The main objectives of our project was to prove the feasibility of a functional ubiquitous computing environment that makes use of existing technologies then validate our vision by implementing the two “proof of concept” demos. The most challenging aspect was to quickly integrate existing technologies (UCB motes, RDF, 802.11b, Java) into a framework that is flexible enough to allow deployment of services (shopping, inventory management, etc.), and this with minimal resources.

7 Future Work We would like to continue our initial work by getting involved in the study of theoretical aspects of ad-hoc networking then expanding the ad-hoc network capabilities implemented so far. At this point these capabilities are quite limited (each mote repeats messages received from it’s neighbors and a simple message flagging mechanism prevents infinite loops). Evaluating other platforms suitable to be used as smart tags and various other radio interfaces (Bluetooth, 802.15.4/Zigbee, etc.) is also within our area of interest. Another important new direction we are considering for our future work is the design and implementation of embedded agents on smart tags.

References [1] M. Weiser, “Some Computer Science Issues in Ubiquitous Computing”,

Communications of the ACM, 36(7), 1993 [2] M. Weiser, The Computer of the 21st Century. Scientific American 265,

3, September 1991, pp. 66-75. [3] Bill Schilit, Norman Adams, Roy Want, “Context-Aware Computing

Applications”, Workshop on Mobile Computing Systems and Applications, Santa Cruz, CA, US, 1994

[4] Estrin, L. Girod, G. Pottie, M. Srivastav “Instrumenting the World with Wireless Sensor Networks”, , International Conference on Acoustics, Speech, and Signal Processing (ICASSP 2001), Salt Lake City, Utah, May 2001

[5] Charles E. Perkins, editor, “Ad Hoc Networking”, Addison-Wesley, New York, NY, 2001

[6] HP Cooltown, http://cooltown.hp.com/cooltownhome/index.asp [7] Microsoft Easy Living, http://research.microsoft.com/easyliving/ [8] UCB TinyOS, http://today.cs.berkeley.edu/tos/ [9] Crossbow Technologies, http://www.xbow.com/ [10] Ora Lassila, Ralph R. Swick, eds. “ Resource Description Framework

(RDF) Model and Syntax Specifications“, W3C Recommendation 22 February 1999

[11] Insignia, http://www.insignia.com/