The BikeNet Mobile Sensing Systemfor Cyclist Experience Mapping

S. B. Eisenman,† N. D. Lane,∗ E. Miluzzo,∗ R. A. Peterson,∗ G-S. Ahn,† A. T. Campbell∗

∗Computer Science, Dartmouth College, {campbell,niclane,miluzzo,rapjr}@cs.dartmouth.edu†Electrical Engineering, Columbia University, {ahngang,shane}@ee.columbia.edu

AbstractIn this paper, we describe our experiences de-

ploying BikeNet, an extensible mobile sensing sys-tem for cyclist experience mapping leveraging op-portunistic sensor networking principles and tech-niques. BikeNet represents a multifaceted sensingsystem and explores personal, bicycle, and environ-mental sensing using dynamically role-assigned bikearea networking based on customized Moteiv TmoteInvent motes and sensor-enabled Nokia N80 mobilephones. Among bicycles that rendezvouz en routewe explore inter-bicycle networking in the followingforms: resource sharing; in situ data sharing both di-rectly, and indirectly via static location-specific stor-age/aggregation entities; bike-to-bike networking viadata muling; and real-time and delay-tolerant up-loading of data via a number of sensor access points(SAPs) to a networked repository. The repositoryprovides a cyclist with data archiving, retrieval, andvisualization services. BikeNet promotes the so-cial networking of the cycling community throughthe provision of a web portal that facilitates backend sharing of real-time and archived cycling-relateddata from the repository. Furthermore, we designand build the sensing system to collect the data tofeed into this portal. In this paper, we present: a de-scription of the system architecture and implementa-tion; an evaluation of sensing and inferencing thatquantifies cyclist performance and the cyclist envi-ronment; a study of the potential for data and re-source sharing between cyclists en route; a report onnetworking performance in an environment charac-terized by bicycle mobility and human unpredictabil-ity; as well as describing BikeNet system-user inter-faces. Visit [5] to see how the BikeNet system visual-izes a user’s rides.

Categories and Subject Descriptors:C.2.1 [NetworkArchitecture and Design]: Wireless Communications;J.3 [Life and Medical Sciences]: Health.

General Terms: Design, Experimentation, Perfor-mance, Reliability.

Keywords: Applications, Bicycling, Recreation, Sys-tem design.

1 IntroductionThere is substantial interest in the cycling commu-

nity in collecting data quantifying various aspects of thecycling experience. For example, current and aspiring

professional bicyclists are interested in measurementsquantifying bicycle, body posture and clothing aerody-namics and are willing to pay $1000 per wind tunnel ses-sion to collect and analyze this data [35]. Professionalsand serious amateurs are interested in determining theirmaximum sustainable performance capacity via lactatethreshold testing ($150 per test [10]), and inferring aer-obic potential via respiration efficiency (VO2) testing($150 per test [10]). These sophisticated measurementscan accurately characterize cyclist fitness, and are inte-gral parts in the successful training regimen of the com-petitive cyclist. However, these laboratory tests are ex-pensive and disruptive, and target a narrow segment ofthe bicycling population. In this paper, we focus on de-veloping a system to quantify cycling performance as-pects and environmental conditions that the mainstreamrecreational cyclist can appreciate and afford, akin to theNike + iPod system [9] for recreational runners.

Existing commercial systems targeting this demo-graphic are designed to measure and report (e.g., viaLCD display) simple data such as wheel speed, and pro-vide simple inferencing such as distance traveled andcalories burned; these have become increasingly moresophisticated and miniaturized. More recently, severalcompanies (e.g., [18] [11]) have begun to offer prod-ucts that integrate data from multiple sensors on a sin-gle user display, including biometric, advanced cyclo-performance and GPS location data. These range fromrather limited $40 devices to very capable $500 de-vices [11]. Products with a slightly different focus offerintegrated hardware and software solutions (e.g., [17])to help cyclists with pre-ride route planning, and in-ride navigation cues via pre-downloaded maps com-bined with real-time GPS data. Others (e.g., [20]) of-fer offline planning software packaged with an onlineGPS tracking service available via a select set of cellularproviders.

While some products allow uploading of logged tripdata via a wired connection at the completion of a ride,a limitation of the currently available products is theinability to share data with others (e.g., nearby riders,interested family members) in real-time. Further, real-time performance analysis of locally collected data is of-ten limited to local display of simple statistics like min,max and mean over the entire trip. When the road ter-rain is highly non-uniform and uphills can last a longtime, comparing current speed against a trip-wide av-erage loses significance. Also, even the most sophis-

ticated existing systems focus exclusively on sensingor inferring cyclist performance (power efficiency, ca-dence, etc.) while ignoring other environmental factorsthat might be more important to the recreational cyclist.

Even among recreational cyclists there is a spread inthe level of interest about various characteristics of aride. Some are competitive with their friends for the sakeof bragging rights, and may want to initiate challenges toset up virtual competitions among geographically sepa-rated cyclists a la Nike+ iPod [9]; some focus on health-related aspects such as personal fitness; many view bi-cycling as a time to relax while getting some moder-ate exercise and are most interested in finding routesthat are safe and quiet; others want to simply archivestatistics about their rides for later analysis [8]. A sys-tem is needed that targets the interests of mainstreamrecreational cyclists, including characteristics measuredor inferred by current commercial systems (e.g., currentspeed, average speed, total calories burned), but that alsomeasures important environmental attributes of the ridethat often dictate whether or to what extent a given routeis enjoyable (e.g., amount of automobile traffic, amountof pollution). In the following we outline the system re-quirements necessary to realize such a system.

• Cyclist Performance Measurement. The systemshould be able to collect and store data about the follow-ing baseline cycling performance characteristics: cur-rent speed, average speed, distance traveled, caloriesburned. These are the metrics commonly available inmany existing commercial products. In addition, thesystem should be able to collect and store the follow-ing advanced metrics, some of which are available fromhigher end commercial products: path incline, heart rate,galvanic skin response (a simple indicator of emotionalexcitement or stress level). The data collection sam-pling rate and duty cycle should be sufficient to capturea faithful representation of the cyclist’s ride. Sensed datashould be stamped with time and location metadata.

• Environment/Experience Mapping. The systemshould be able to provide quantitative guidance to cy-clists about the that affect the enjoyment factor of a givenroute. This means collecting and storing data about pol-lution levels, allergen levels, noise levels, and roughnessof the terrain. These measurements, together with datafrom cyclist performance measurements, can be corre-lated to create a holistic picture of the cycling experi-ence. Sensed data should be stamped with time and lo-cation metadata.

• Real-time Cooperative/Comparitive Sharing. Cy-clists should be able to set preferences for selective shar-ing of specified data with other cyclists or other indi-viduals encountered en route. Shared data could be ei-ther related to cyclist performance or environment, e.g.,as a benchmark of comparison to other riders trying toachieve the best performance on a given hill, or as an in-dicator to a cyclist seeking to avoid rough steep routes,or roads with higher volumes of automobile traffic. Fur-thermore, a cyclist may wish to share certain data during

a ride with certain remote individuals, e.g., sharing pe-riodic location information with friends or family mem-bers tracking the cyclist’s progress to get a rough esti-mate of arrival time.

• Long Term Performance Trend Analysis.Collecteddata should persist beyond the ride on which it is col-lected. The system should enable the upload of datatraces into a personal repository that can be selectivelyshared with other individuals, or into a public database.The data should be archived in such a way as to facilitatespatio-temporal trend analysis.

• Data Collection and Local Presentation. Cyclistsshould be able to specify what data the system collects,when it is collected (e.g., a timed experiment), whereit is collected (e.g., a distance interval experiment), andunder what correlated conditions sensor data capture oc-curs (e.g., increase the sampling rate of the heart ratewhen the path incline is above a threshold). Further, datashould be made available for real time local display tothe cyclist (e.g., via an LCD mounted on the handle bar,via a mobile phone display) and the selection of whatdata appears should be customizable by the system user.

• Data Query and Remote Presentation.The systemshould provide a web-based portal on the back end asa means for querying against and displaying collecteddata. The portal can also be used as a means to injectqueries into the system to request particular bicycling-related data of interest to the back end system user. Fi-nally, the portal can be used as a place to publish/sharedata with friends/competitors in the same interest group,similar to the Nike+ iPod group challenge feature [9].

• Disconnected Operation.Because of the mobility in-herent in all cycling activities, in situ data sharing re-quires a wireless networking solution for communica-tions. Also, since some sensors might be embedded inthe bicycle, it may be inconvenient to remove possiblymany devices for direct wired upload to a centralizeddata repository. Therefore, it is appropriate to rely onwireless communication for data upload as well. It isexpected that cyclists will eventually complete their rideand can use wireless upload protocols to deliver data toa back end repository in a delay-tolerant manner. Whatabout transporting data to the back end while en route?The cyclist may or may not have access to a means ofreal-time data upload while on the trail (e.g., via cellularphone). Muling [6] between bicycles can increase theprobability that sensed data in a sparse and mobile net-work environment can be delivered in a more timely butstill delay tolerant manner.

• General Purpose/Modular Design. The systemshould be extensible beyond the sensors included in theinitial implementation, and should provide a mechanismfor general purpose tasking via the back end user in-terface. New sensors should be “plug-and-play” to thesystem architecture. If a cyclist specifies a given sen-sor as required by his or her preference profile then thesensor will be included in the data collection. The sys-

tem should have application beyond cyclist experiencemapping, and should provide a general purpose sensingsystem environmental mapping.

We design and implement a customized system thatmeets this set of requirements, addressing the limitationsof existing systems. Our BikeNet implementation usessensors embedded or interfaced with the Moteiv TmoteInvent [15] platform as well as camera and microphonesensors available on the Nokia N80 [36] platform. AllTmote Invent and N80 platforms are networked over acommon IEEE 802.15.4 short range radio channel. TheN80 additionally possesses IEEE 802.11g, BlueToothand GSM cellular radio interfaces. With these additionalradios the N80 can act as a mobile sensor gateway (i.e.,a mobile SAP [12]) to support both real-time data up-loading to the back end and real time queries from theback end, over the wide area cellular network while thecyclist is en route. This paper also contributes to thedevelopment of a general purpose people-centric systemfor mobile sensing.

With BikeNet, we provide a web portal that allowscyclists to publish quantitative data about themselvesand the paths they traverse for real-time or delayed dis-play; also we provide the sensing system to collect thisdata. In so doing, we hope to provide a useful toolto network members of the cycling community throughdata of mutual interest. We investigate two data sharingapproaches: direct bicycle-to-bicycle sharing via shortrange radios, or indirect sharing through neutral third-party entities calledrocks. Rocks are untethered storageand aggregation devices that are placed along roads andtrails frequented by cyclists; they store location-specificperformance data on per-cyclist and aggregate bases. Wehave designed and tested a communication protocol bywhich cyclists interface with rocks.

BikeNet goes beyond characterizing the cyclist per-formance, and provides a quantitative discription of theenvironment local to the cyclist. This is done not only toprovide additional context to cyclist performance data,but also because environmental data is important in itsown right, having a direct impact on the perceived en-joyability of a bicycling experience.

BikeNet allows the user to customize, via a profileof preferences, what data is collected by the system andwith whom to share selected data. The profile also in-dicates how data is to be presented, both locally on thebicycle whenen routeand through BikeNet data accessand presentation methods once the data has been deliv-ered to the back end repository.

In addition to sensor data sharing between cyclists,as part of our opportunistic sensing system we investi-gate resource sharing between two or more bikes travel-ing within a common local radio range. That is, giventhat each bicycle is equipped with a subset of all possi-ble sensors, all members of a group can possibly benefitfrom the most capable and most expensive sensors at-tached to any member of the peloton through resourcesharing. For example, if cyclistA’s bicycle has a partic-ulate sensor, but cyclistB’s bicycle does not, cyclistB’s

bicycle canborrow the data from the particulate sensorof cyclist A’s bicycle, with only a small loss in fidelity.We perform a preliminary experimental feasibility studyof resource sharing using a number of sensing resourcespresent on BikeNet’s Invent- and N80-based sensing andcommunication platforms.

BikeNet utilizes an opportunistic networkingparadigm, whereby data is shared, muled or uploadedaccording to the opportunities that arise as a result ofthe uncontrolled mobility of the cyclists themselves.BikeNet adopts a MetroSense-style [12] architecture toaddress the challeges of the mobile environment, whileoptimizing the design for the application domain. Thischoice allows us to experiment with a more general pur-pose mobile people-centric sensor network wherein thedata collected is not only of use/interest to the cyclistsbut can be queried against by other system users via aback end web portal. In this context, we consider howdata sharing extends to a query- or pull-based paradigm,and how other applications might ride transparently onthe back of the system deployed for cyclist experiencemapping.

In the following sections, we describe our experi-ences deploying a sensing system for cyclist experi-ence mapping, leveraging opportunistic sensor network-ing principles and techniques [12]. We discuss the sys-tem architecture and design in Section 2. In Section 3,we detail the sensing and communication equipment inuse in the BikeNet prototype implementation, and theBikeNet software system implementation. Section 4 de-scribes an extensive evaluation of our cyclist experiencemapping application, including sensing accuracy and in-ferencing techniques, communication protocol perfor-mance, and feasibility results. Related work is discussedis Section 5 before we conclude with a summary and adiscussion of future work in Section 6.

2 System Architecture and DesignBikeNet is a network characterized by mobile sens-

ing and sparse radio network connectivity. Given thesecharacteristics, and the application requirements for thesystem, we design the BikeNet system as an instanti-ation of the MetroSense architecture [12]. The Met-roSense architecture is a people-centric paradigm forlarge-scale sensing at the edge of the Internet based onthe use of an opportunistic sensor networking approach.Generally, opportunistic sensor networking leveragesmobility-enabled interactions and provides coordinationbetween people-centric mobile sensors, static sensorsand edge wireless access nodes (i.e., SAPs) in supportof sensing, tasking, and data collection. The BikeNetarchitecture represents the first realistic application ofthe MetroSense principles and design, including opti-mizations for the bicycling application domain. Figure 1shows a pictorial overview of the BikeNet system, Fig-ure 3 shows a custom-built sensor-enabled bicycle, andFigure 2 shows a logical representation of the bike areanetwork (BAN).

StaticSAP

Sensors

(direct sharing)

Rock

StaticSAP

MobileSAP

Sensors

(uploading)

(muling/direct sharing)

StaticSAP

Sensors

(uploading)

Rock

Rock

Rock

GSM/GPRS

Back End Servers

Internet

Client BikeNet Portal (uploading)

Figure 1: BikeNet System Overview. Sensors collect cyclistand environmental data along the route. Application taskingand sensed data uploading can occur when the sensors comewithin radio range of a static sensor access point (SAP) or viaa mobile SAP along the route or at the route endpoints (seeSection 2.1 for the BikeNet hardware architecture description).Sensed data muling and direct sharing can occur when cyclistscome within mutual radio range. Indirect sharing can occurwhen when cyclists and rocks are within mutual radio range.We collect data about the cyclist (heart rate, galvanic skinre-sponse), about the cyclist’s performance (wheel speed, pedal-ing cadence, frame tilt, frame lateral tilt, magnetic heading),and about the cyclist’s surroundings (sound level, carbon diox-ide level, ferromagnetic objects, e.g., cars).

2.1 Hardware ArchitectureThe BikeNet system hardware is organized into three

tiers, the back end server tier, the sensor access point(SAP) tier and the sensor tier (includingrocks). The sen-sor tier incorporates a number of bicycle-mounted andhuman-mounted sensor platforms (e.g., Tmote Invent),with possibly multiple sensor types installed per plat-form, that gather data concerning cycling performance,cyclist health and fitness, and the environment surround-ing the cyclists’ routes. The sensor platforms mountedto a particular bicycle, along with the sensor platformsmounted to the human riding the particular bicycle, con-stitute abicycle area network(BAN). Sensor platformswithin the BAN have opportunity to communicate viashort range radio (e.g., IEEE 802.15.4). The BAN archi-tecture is designed in a modular way such that sensingcomponents can be added or substracted simply accord-ing to user preferences (dynamically) set in software.Further, the BikeNet system allows for resource sharingbetween BANs such that it is not strictly necessary thata given BAN “own” all the sensing components (e.g.,expensive or specialized sensors) that it uses. Figure 2illustrates the design of the BAN in our BikeNet system.

Rocks are deployed along roads and trails and sharethe same short range radio as BAN sensor platforms.Rocks interact with passing BAN members to facil-itate indirect data sharing between cyclists who ei-ther can not interact directly or desire to maintain ahigher level of anonymity, while still participating ina location/activity-oriented group. Rocks provide stor-age capacity for small amounts, per cyclist, of location-specific data (e.g.,≤ 1kB per cyclist) on-location. Rockscan also offer a temporary (due to their limited mem-

2(10) CO meter

BAN B

Odometer

Speedometer

Heart Monitor

(01) Microphone

− Camera− Display− Speaker− Microphone

(02) Magnetometer

(05) 802.15.4/BlueTooth

(11) GPS

(08) Display

(04) Inclinometer

(09) Speedometer

(07) Stress Monitor

(08) Mobile Phone

BlueTooth 802.11

GSM/GPRS

BAN A

(04) Accelerometer

(09) Odometer

Figure 2: Logical representation of bicycle area networking.Sensors share a common IEEE 802.15.4 channel. BAN B canshare the resources of BAN A in order to fulfill the sensingpreferences of the user without the resource residing physi-cally on the the BAN B’s bicycle. A mobile phone plays adual architectural role depending on whether its cellular radiois active/connected. If connected to the cellular backend themobile phone acts as a mobile sensor access point (SAP) fa-cilitating real-time sensing; else it acts as a local memberof aBAN engaged in delay tolerant sensing.

Figure 3: Physical implementation of the BikeNet system.Numbered sensors installed on the bicycle map to the sensortypes labeled in the logical representation in Figure 2.

ory and the priority given to their primary function oflocation-specific storage) mailbox to improve the prob-ability of successful data routing in a disconnected net-work.

The SAP tier offers high performance, high reliabil-ity, and secure gateway access from the sensor tier tothe back end servers. This access allows sensed data toflow to the system repositories, and provides a point ofcommand for the architecture to task available sensorswith user application requests/queries. When possible,these gateways are symbiotically implemented [12] onthe back of existing network infrastructure by plugginga short range radio module into the exising network el-ement (e.g., IEEE 802.11 access point), allowing it tocommunicate with the sensor tier. SAPs can be static and

wired directly to the Internet, or can be mobile and usea data service over a wide area radio access network toprovide connectivity to the back end (e.g., mobile phonewith GSM/GPRS). For example, the Nokia N80 can useboth IEEE 802.11g (as in the CarTel architecture [3]) orGPRS to connect to the back end, and IEEE 802.15.4 tocommunicate with the sensor tier. We study both task-ing and uploading via both static and mobile SAPs inour implementation. SAPs also can be equipped withsensors to provide context and validation for uploadeddata [12].

Members of the back end are Ethernet-connectedservers equipped with practically unboundedstorage andcomputational power. These provide a number of ser-vices to the architecture, some of which are describedin Section 2.2.6. In particular, it is to the back endservers that system users connect to submit applicationrequests/queries for execution in the sensor tier, and toretrieve and visualize collected sensed data.

2.2 Software ArchitectureFigures 4(a), 4(b) and 4(c) shows how the BikeNet

software system maps to the three tier hardware architec-ture, respectively defining the bike sensor platform, SAPand back end software sub-architectures. The defaultTinyOS software architecture [21] at and below the localcommunications networking stack is used for commu-nication between the sensor and SAP sub-architectures;the default TCP/IP architecture is used for communica-tion between the back end communications networkingstack in the SAP and back end sub-architectures. In thefollowing, we focus on those software components weadd to meet the particular BikeNet system requirementsoutlined in Section 1.

2.2.1 BikeNet VM/Role AssignmentFor purposes of modularity the functional require-

ments within a BAN are divided intoroles. To stream-line role assignment to BAN members all motes are pro-grammed with a BikeNet virtual machine (an applica-tion specific virtual machine (ASVM) approach [19])by default. This virtual machine supports role-specificfunctions such as query handling and sensing parame-terization, and supports the assignment of the BikeNetrole(s) themselves to each sensor platform. Assignmentis carried out via a resource discovery protocol based onthe capabilities of a mote to provide the required sensorreadings. Though a physical sensor platform can, de-pending on sensing capabilities, take on more than oneof BikeNet roles, for our current work we allow onlyone role per sensor platform (e.g., Tmote Invent or othermore capable platform) to increase the design, deploy-ment and evaluation parallelism in the BikeNet, and tostress the bike area network (BAN) radio communica-tion protocols. The design will evolve to integrate asmany roles as possible on each platform to minimize thenumber of sensing platforms in a BAN and the associ-ated costs (i.e., monetary, radio congestion).

A number of BikeNet roles are defined. ThePed-alSensorandWheelSensorroles measure the angular ve-

locity of the pedal and front wheel, respectively. Fromthese the current and average speed, distance traveled,pedaling cadence and gear ratio is measured or inferred.TheTiltSensorrole measures the angle of incline of thebicycle frame with respect to the gravitational force vec-tor, allowing for real time slope calculation and a map-ping of the terrain along a cyclist’s route. TheLater-alTiltSensorrole measures the lateral angle of incline ofthe bicycle frame. TheCompassSensorrole measuresthe instantaneous direction of motion of the bicycle withrespect to the Earth’s magnetic field, allowing for a formof dead reckoning when used in combination with speedand distance information obtained from the WheelSen-sor role. TheMetalDetectorrole measures magnetic de-viation from the Earth’s magnetic field caused by nearbyferromagnetic metals, allowing inference of the amountof passing automobile traffic. TheSyncSprinklerroleprovides a common absolute notion of time and loca-tion to all members of the bike area network via pe-riodic short range broadcasts. TheLocalDisplay roleprovides a means to display data sensed locally in thebike area network, and data shared from other cyclistsvia inter-BAN communication (either direct or indirect)to the cyclist. TheCO2Sensorrole measures the car-bon dioxide content in the atmosphere surrounding thebicycle, allowing the system to infer whether the cyclistis passing through an urban area (more CO2 from autoexhaust) or a rural area (less CO2 due to plant respira-tion). The SoundSensorrole measures the volume ofnoise in the environment surrounding the cyclist, and isused for voice triggered sensing and audio annotation ofa cyclist’s ride. TheCameraSensorrole provides trig-gered capture of an image, or a video clip of specifiedduration. These captures provide ground truth context tothe measurements or inferences provided by other sen-sor roles. TheGSRSensorrole measure the galvanic skinresponse of the cyclist, allowing the system to infer thestress level of the cyclist. ThePersonalNoderole doesnot directly involve sensing, but rather it provides con-trol via short range radio over the other sensing roles, in-cluding executing user preferences within the BAN (e.g.,required sensors, sensing parameterization), and signal-ing the start and stop of a cycling trip. Each cyclist nec-essarily possesses a PersonalNode, but all other roles areoptional, depending on the sensing preferences of thecyclist (reference the role assignment implementation inSection 3.2.2). In the rest of the paper, unless the dis-tinction is necessary, we treat the role and the platformto which the role is assigned as synonymous.2.2.2 Intra-BAN and Inter-BAN Management

Localization and Synchronization.The SyncSprin-kler exists to provide, via a broadcast within the BAN,periodic samples of the instantaneous absolute time andlocation obtained from a GPS unit. Besides GPS, theSyncSprinkler has other potential implementations thatmay have lower cost and good accuracy. In Section 4.3,we evaluate the comparative accuracy of using the com-bination of a magnetometer reading from a mote serv-ing the CompassSensor role, and distance traveled as

Local Comm. Networking Stack

...

BikeNet VM

BikeNet Roles Data Exchange Services

Tasking Exchange

Uploading Exchange

Muling Exchange

Sharing Exchange

Management and ControlIntra− and Inter−BAN

(a) Bike sensor platform architec-ture.

Data Exchange Services

Uploading Exchange

Tasking Exchange

Back End Comm.Networking Stack

Local Comm.Networking Stack

Sensing Resource

Query Management

Sensing

Ground Truth

SelectionSensing Resource

Discovery

(b) Sensor access point (SAP) architecture.

Back End Comm. Networking Stack

Que

ry S

ubm

issi

on P

orta

l

Sys

tem

Sta

te D

atab

ase

Sen

sor

Dat

a R

epos

itory

Sen

sor

Dat

a M

inin

g

Sen

sor

Dat

a V

isua

lizat

ion

(c) Back end architecture.

Figure 4

inferred from a mote serving the WheelSensor role, as-suming a known starting location. Time synchronizationis most important among motes in the same BAN. Toachieve this, a simple beacon-based approach is used tomaintain a consistent view of relative time. When a BANuses a non-GPS implementation of the SyncSprinkler,both the estimated location and estimated time are cor-rected any time a BAN member overhears a GPS-basedSyncSprinkler broadcast message from another BAN.

Event Triggered Sensing vs. Continuous Sensing.Sensing is set up to occur either continuously or onlywhen triggered by other events. In the continuous case,the user preferences executed by the PersonalNode pa-rameterize the sensing capture (e.g., sampling rate, du-ration, local processing functions) that takes effect im-mediately upon receiving thestartmessage (see Section3.2.3 for the control protocol) , indicating the start ofthe ride, from the BAN’s PersonalNode. Continuoussensing in BikeNet is appropriate for roles such as theTiltSensor where terrain mapping should be continuous.On the other hand, some sensing operations may be tooexpensive for the platform to do continuously, or maynot have meaning except under certain contexts. As anexample of the latter case, if the user preference is tocapture wheel speed when going down hill, then sam-pling by the WheelSensor should only take place whenthe TiltSensor registers a negative slope. Alternatively,the user may wish to activate, or increase the samplerate of, the heart monitor when going uphill. Triggerscan be arbitrarily complex, requiring thresholds, etc., onany number of sensing roles, time or location. Triggers,like sensing parameterization, are defined by user pro-files executed by the PersonalNode that specify the con-ditions under which sensing should occur. Both continu-ous and triggered sensing are alternatively set up by sys-tem user queries that enter the BAN through a static ormobile SAP. As these queries enter the BAN through thePersonalNode (sensor roles are not tasked directly fromthe SAP), the origin of the continuous or triggered sens-ing request is transparent to the execution of the sensingrequest on the sensors themselves. Both continuous andtriggered sensing requests can be embedded in resourcesthat are either native to the PersonalNode’s BAN (i.e.,associated with the PersonNode), or are shared from an-other BAN.

Resource Sharing.The sensor roles that are neces-sary to collect the data preferred by the user may notbe available within the BAN. In such cases, BikeNetallows for the sharing of resources (e.g., sensors, dis-plays, long-range radio, a speaker, large storage) be-tween BANs, where resources are said to be native toone BAN and borrowed by another; a GPS beacon canbe viewed as a form of always-on sharing since the bea-cons are broadcasted. Resource sharing also takes placesbetween BANs and SAPs, where for example a BANmight share a mobile SAP’s camera or microphone).While a BAN most often consists of the sensor platformsmounted on a single rider/cyclist pair, and thus the BANmight often be equipped to meet all the sensing rolesrequired by the rider, resource sharing is helpful in thecase that the riderprefersdata from more sensors thanhe or sherequires. Resource sharing is also useful inthe case of queries that enter the BAN via mobile orstatic SAPs after the start of the ride, and that ask fordata from sensing roles that are not native to the BAN.In such cases, the requested sensors might be found inother BANs along the route (e.g., riding with a friend,participating in a cycling group, competing in a race).Resource sharing can be continuous or triggered.2.2.3 Data Exchange Services

Four types of data exchange occur with BikeNet sen-sor platforms: tasking exchange, uploading exchange,muling exchange and sharing exchange. The taskingand uploading data exchanges take place between sen-sor platforms and sensor access points. The muling andsharing data exchanges take place only between sensorplatforms. In the BikeNet tasking exchange, a SAP in-teracts with available sensor platforms to first instanti-ate a PersonalNode programmed with a cyclist’s BANpreference profile. Based on this profile, the PersonalN-ode assembles a BAN by tasking other available sensorplatforms with the required sensing roles as discussedin Section 2.2.1. Aside from this BAN bootstrapping,the tasking exchange also includes the handling of userqueries/requests for data by back end system users, re-ceived via the SAP. The PersonalNode responds to thesequeries by invoking the necessary continuous or trig-gered sensing (Section 2.2.2) within its BAN, possiblysharing out-of-BAN resources (Section 2.2.2) to com-plete the task.

In the uploading exchange, when a BAN comeswithin the radio range of a mobile or static SAP, thesensor platforms composing the BAN attempt to uploadsensed data to the back end data repository.

In the muling exchange, sensed data is transferredbetween sensor platforms outside of the radio range ofeither a mobile or static SAP. The aim is to increasethe probability of timely delivery of data as requiredby some application features (e.g., cyclist tracking). Inthe BikeNet system, data muling is done between nativemembers of the same BAN to maximally increase the de-livery probability. The reasoning is that native (i.e., notshared from another BAN) members of the same BANare likely to be affixed to the bicycle and these platformsare likely to all be within range of a SAP for uploadingor none of them will be in range. Generally, muling canbe reliable or unreliable, and can use replication. Withreplication the sensor platform asks other nodes to muler copies of each data record, and keeps the original toupload itself (r is termed the replication degree). In theBikeNet system we investigate replicated reliable mul-ing.

There are two types of sharing exchange, direct shar-ing and indirect sharing. Direct sharing is a push-oriented exchange where data transfer is done BAN-to-BAN. Any authorization, authentication, or encryp-tion is handled directly between the two communicatingBANs. Indirect sharing is done with a two phase ex-change, first BAN-to-rock and then rock-to-BAN to pre-serve anonymity of the data sharers. Data insertion andretrieval to/from the rock is authenticated and protectedby access control to allow controlled sharing of specifieddata between specified cyclists. Aggregate data acrossall cyclists who use a given rock is available to all cy-clists in the group (where the notion of group is mini-mally that of cyclists who ride by a certain location).

2.2.4 Ground Truth SensingIn the BikeNet architecture, SAPs are equipped with

certain sensors to provideground truthmeasurements.In this context of the BikeNet sensing system, groundtruth refers to a trusted, high fidelity, always accessiblestream of data. One use of ground truth data is as a fil-ter applied to data uploaded from a sensor to a SAP be-fore the data is passed to the back end repository. Theground truth filter can be applied to validate or invali-date uploaded data when the uploaded data samples andground truth data samples have a high expected corre-lation (e.g., sampled at the same location, sampled atthe same time, samples triggered by the same set of cir-cumstances). Ground truth sensing can also be used tosatisfy queries coming from a back end system user thatrequire only a coarse view of the geographaphical extentof the deployed BikeNet SAP tier. A final use of groundtruth data is to satisfy queries coming from a BAN in theradio range of a SAP. In this case the BAN can ask forreadings from the SAP’s ground truth sensors as part ofa self-calibration routine or in the course of the resourcesharing routine described in Section 2.2.2.

2.2.5 Query ManagementThe query management component on the SAP han-

dles queries both from the back end system user, andfrom the PersonalNode of a BAN; it invokes a sensingresource discovery protocol to determine what sensingresources are available to meet the sensing request (e.g.,either on-SAP in the case of ground truth sensors [12], orin a BAN within radio range). A sensing resource selec-tion subroutine decides which resources will be taskedin order to satisfy the request and invokes the taskingsubprocess to execute the necessary request (i.e., a sim-ple function call if the resource is on-SAP, or via thetasking exchange (Section 2.2.3) is the resource is in anearby BAN. In the BikeNet implementation, we haveexperimented with handling queries to the SAP both forground truth data from the BAN and from the back end.In particular, using a cellular phone as a mobile SAP, wehave experimented both with event triggered capture ofimages, sound and videos requested by the BAN (e.g.,an audio annotated ride); and with direct request fromthe back end BikeNet web portal for image, sound andvideo samples.2.2.6 Back End Services

Query Submission Portal. The BikeNet back endincludes a web portal containing a graphical represen-tation of the static and mobile SAP deployments, and alisting of which BANs are currently accessible throughthese SAPs. Using a simple mouse click the user can se-lect the SAP or BAN of interest and assemble a query tosubmit to the query manager component of that SAP us-ing a collection of pull down menus. A final mouse clicktransmits the query over the Ethernet directly to the se-lected static SAP or over a wide area wireless networkto the selected mobile SAP.

Sensor Data Storage, Mining and Visualization.The sensor data repository provides a location for thelong term storage of cyclist experience data on a per-cyclist basis and also provides a convenient location forthe aggregration of all long term trace data for all par-ticipating cyclists. Access to particular data is a matterof a the policy that each cyclist registers with the repos-itory (or a separate access control entity). The sensordata mining component provides a set of standard sta-tistical functions and reusable calculations/ data trans-formations that a user (e.g., cyclist) can invoke to con-trol the retrieval and presentation of data. For BikeNetwe use a number of data interpretation and inferencingtools and techniques, including scatter plots to look fordata correlation, Fast Fourier Transforms to look for pe-riodicity, running averages to smooth data to look fortrends, and interpolation to align samples according todistance. Particular examples include a method to filterspurious vibration data from the TiltSensor when cal-culating the slope of the cyclists path, infer gear ratioby combining readings from the WheelSensor and thePedalSensor, and (with knowledge of the starting loca-tion) estimate current location without GPS by combin-ing reading from a WheelSensor and CompassSensor.Further, we have develop scripts to transform data values

into BikeViewvisualizations. With BikeView (see [5])we present summarized collected data sorted by user,and sorted by ride within each user account (akin tothe presentation of “My Runs” on the Nike+ iPod webpage [9]). Detailed sensed data can be obtained by sim-ple mouse hovers and clicks over the graphic reprenta-tions of different rides. Back end sharing between usersis facilitated by dynamic creation of group pages that arevisible to all users in the group and to which all groupmembers can publish data.

System State Database.The system state databasecontains both static state information (e.g., Tmote Inventphysical address and sensing capabilities, PersonalNodehuman custodian information) and dynamic state infor-mation (e.g., last known position of a mobile SAPs, andBANs, SAP load average) about elements in the net-work. In particular, the system state database trackswhich BANs are currently in radio range of mobileand static SAPs. This facilitates proper query routingfrom the back end query submission portal to particularBANs, for BAN-specific user queries. The informationis also valuable more generally for debugging and man-agement of the network.

3 System ImplementationWe implement a complete system in line with the ap-

plication domain requirements, and according to the ar-chitecture presented in Section 2. We build five fullyequipped bicycles, implement all of the aforementionedsensing roles using Tmote Invent and N80 platforms,build a number of static and mobile SAPs, and imple-ment a functional back end web portal offering querysubmission and data retrieval services. The followingpresents the implementation details of the various hard-ware and software components.

3.1 Implementation HardwareBikeNet includes a number of bicycles, each outfitted

with any of a suite of mote-interfaced sensing devicesconnected in a bike area network using the short-rangeradio (CC2420) of the Moteiv Tmote Invent [15]. TheTmote Invents are programmed with TinyOS [21], in-cluding the Boomerang package [15]. Untethered de-vices called rocks communicate via short-range radiowith nearby bike area networks, provide storage and ag-gregation of location-specific sensor data, and facilitatethe sharing of information between cyclists. Static andmobile SAPs act as Internet gateways, providing a pointfor the tasking of the motes in the bike area network,and an entry point for the collection of sensed data toback end data repositories. In the following, we describethe SAPs, bike area network components and rocksin more detail, and include a discussion of ruggediza-tion of the sensing hardware and hardware used to cali-brate/validate BikeNet sensor measurements.3.1.1 Ruggedizing the Hardware

Because of the outdoor nature of the BikeNet testbedwe take steps to protect the sensor platforms from theweather (e.g., rain, snow). We enclose each sensor plat-form in an OtterBox 1600 GPS Case. The OtterBox

Figure 5: Waterproof OtterBox. wires connected to the userbutton of the Invent from the reed relay mounted next tothe pedal go through a hole drilled in the waterproof OtterBox. The hole is then filled with silicone sealant. Wires havecrimped connectors for easy disconnect and removal for moterecharging.

comes with adhesive foam that is customizable to a de-gree that allows us to secure the Tmote Invents insidethe cases without any slipping. A number of sensors re-quire running wires from the Invent out of the OtterBoxto other places on bicycle or cyclist (e.g., the WheelSen-sor’s reed relay is wired to the front fork; the GSRSen-sor’s finger pads are wired to the cyclists finger tips).For these we drill holes through the OtterBox 1600 andfilled the holes with silicone gel after passing through thewires to maintain waterproofing. For these wired in sen-sors, we cut the wires inside the box and crimp/solder onconnectors for quick disconnect of the Invents for whenthey are removed for recharging (see Figure 5).

In addition to waterproofing, the sensor platformshave to be securely fastened to the bicycle, especiallysince bicycling implies often severe vibration and jolt-ing. We are using a system of steel mounting bars affixedto the bicycle frame with steel hose clamps. The Otter-Boxes are then screwed on to these mounting bars andthe screw holes are sealed with silicone gel. In determin-ing the geometry and placement of the mounting barswe have attempted to minimize vibration and unwanteddegrees of freedom for the sensors (Figure 3). This isparticularly important for the TiltSensor and LateralTilt-Sensor which both use carefully oriented accelerometersto obtain their measurements.

Despite our efforts to mount the accelerometers forthe TiltSensor and LateralTiltSensor at perfect right an-gles (in two dimensions) with the ground, we find that acalibration of accelerometers has to be done for each bi-cycle in order to correctly understand the measured val-ues. Even if the error angle of the mounting bracket issmall it can lead to a large skew in the calculated slope.This is true both because the values of slope normallyencountered in cycling on a road are relatively small (<15 degrees), and also because of the non-linear nature ofthe inverse tangent function through which the readingsfrom the two dimensional accelerometer are passed tocalculate the slope. We find that calibration is also nec-essary for the magneto-inductive sensors due to the steelframes of the bicycle, and the steel mounting bars.

3.1.2 Bike Area Network ComponentsWe implement the following hardware, based on the

sensing and communication requirements of the BANroles discussed in Section 2.2.1.

To measure angular velocity of the wheel and pedal,we augment the standard Tmote Invent by attaching amagnet-triggered reed relay mounted across the Invent’suser button. Every time the relay closes a TinyOS [21]interrupt event is generated. For the pedal, the relayand magnet are mounted such that one revolution ofthe pedal around the pedal axle causes one interruptevent. Similarly, for the wheel, the relay and magnetare mounted such that one revolution of the tire aroundthe front wheel axle causes one interrupt event. Further,knowledge of the circumference of the tire allows for thecalculation of distance travelled. Bicycle speed is calcu-lated with knowledge of elapsed time (i.e., the averagenumber of interrupt events per second multiplied by thetire circumference gives the average speed).

To measure the angle of incline, and lateral tilt of thebicycle we use the two dimensional accelerometer inte-grated into the Tmote Invent. With knowledge of theangles the axes of the accelerometer are aligned with re-spect to the bike frame, the the slope of the terrain overwhich the cyclist rides and the side-to-side tilt of the bikeis measured. The accelerometers are calibrated to com-pensate for their mouting characteristics on the bike. Wesample the accelerometer at 160 Hz per channel.

To measure direction and deviation with respect tothe Earth’s magnetic field, we add a dual axis magneto-inductive sensor (Honeywell HMC1052L) to the stan-dard Tmote Invent (Figure 6(a)), connecting the sensoroutput to two ADC channels on the Invent and connect-ing a free I/O pin from the Invent’s MSP430 microcon-troller configured as output to act as a digital control line.The magneto-inductivesensor is powered directly off thebattery voltage of the Invent (Vbatt), while the ADC con-version is driven by a divided reference voltage (Vre f ).This requires that we prescale the output of the sensorbefore it enters the Invent ADC by(Vbatt−Vre f) to avoidsaturating the ADC channels.

To provide a common notion of absolute time and lo-cation within a BAN, we enhance the standard TmoteInvent by interfacing a Garmin Etrex 12 channel GPSunit via the UART0 port of the Invent’s MSP430 mi-crocontroller (Figure 6(b). The Garmin Etrex providestime and location data at the fixed rate of once per twoseconds via its RS232 interface. Note that the rela-tively short range of the low power of the CC2420 radioused by the Tmote Invent confines the propagation of thetime/location beacon broadcasted by the SyncSprinklerto an area on the same order of the positioning uncer-tainly of most price-accessible handheld GPS units [14],maintaining the usefulness of the broadcast for all recip-ients.

When a cyclist pauses his or her ride (e.g., to rest, toeat a snack) it is reasonable that the display of an avail-able N80 mobile phone adopts the LocalDisplay role inthe BAN. However, while in motion it may be unsafe for

the cyclist to hold the N80, and further not every cyclistwould tend to have a mobile phone available to them. Toprovide a mechanism for handlebar-mounted local BANdisplay we interface the standard Tmote Invent (Figure7(a)) with an LCD using a SparkFun interface board andthe Hitachi HD44780 LCD driver, via the UART0 port ofthe Invent’s MSP430 microcontroller. The LCD modulemust have 5VDC to operate so it needs a separate powersupply. For simplicity we use a rechargable NiMH 8.4Vbattery with an LM7805-based 5V voltage regulator cir-cuit. Additionally, to achieve reliable communicationover the serial line, a level conversion from the 3V out-put of the Invent to the 5V input of the LCD is required.

To measure the carbon dioxide levels in the environ-ment surrounding the cyclist, we interface the standardTmote Invent with the Telaire 7001 CO2/TemperatureMonitor, via an ADC port of the Invent’s MSP430 mi-crocontroller. The meter has a 0-4VDC output specifi-cally for data logging. The Telaire 7001 uses a separate9V battery. The Telaire 7001 uses as optical technique(dual beam NDIR) to provide a continuous but delayedmeasurement of the CO2 level, with a response time ofabout sixty seconds.

To measure environmental ambient sound volume weuse the microphone that is integrated into the Tmote In-vent. Interestingly we observe that on the Invent plat-form, use of the LEDs causes a small DC offset in themicrophone capture. This offset should be accountedfor when interpretting the ADC values. In firmware, weconvert the signal to an average power reading after firstrectifying the signal.

To measure the galvanic skin response of the cyclist,we use an ArcherKit Biofeedback Monitor. Wires con-nected to the fingers of the cyclist measure microcur-rents on the skin. The Monitor normally represents thesechanges in resistivity of the skin by varying the pitch ofan onboard speaker. We have re-routed a voltage leveloutput into a spare port of a Tmote Invent ADC. TheMonitor uses a separate 9V battery.

3.1.3 RocksIn our system, we implement rocks using an unmod-

ified Tmote Invent enclosed in a waterproof Otter Box.While this provides somewhat less storage capacity thanwe envision for a final system, it does allow us to vali-date the indirect sharing communication protocols. Theresults of this validation are shown in Section 4.3.1.

3.1.4 Static and Mobile SAPsThe static SAP is implemented using an unmodified

Tmote Invent plugged into the USB port of an ArubaAP-70 IEEE 802.11a/b/g access point. The Aruba is run-ning a customized version of OpenWRT, an embeddedlinux variant. The BikeNet SAP is implemented as anoverlay of tools requiring only user priveleges. Certainkernel module support is needed; modules are loaded atruntime if necessary. Installation of the tools distributionoccurs upon hotplug of a USB memory device makingsymbiotic deployment of a BikeNet SAP on to a stan-dard WiFi access point easy to manage.

(a) Modifications to attach a two-axismagnetometer to a Tmote Invent via theADC.

(b) Modifications to attach an externalGPS unit to a Tmote Invent via theUART0 port.

(c) BikeNet static SAP implementation.

Figure 6

(a) Initial prototype of a BAN local dis-play.

(b) Ground truth video/sound/photo hel-met with four N80s and GPS receiver.Each N80 can act as a mobile SAP.

(c) BikeNet mobile SAP implementa-tion. The Nokia N80 BlueTooth ra-dio associates with a custom-built Blue-Tooth/802.15.4 gateway.

Figure 7

In the BikeNet system the mobile SAP is imple-mented using a Nokia N80 associated to a Blue-Tooth/802.15.4 gateway via its BlueTooth radio. Thegateway is implemented by interfacing a BlueRadiosBR-C40 serial radio modem to the UART0 port of theTmote Invent’s MSP430. The N80 SymbianOS uses aserial device emulation of the bluetooth SPP profile toread and write from the BlueTooth device using serialport semantics. The back end interface of the SAP usesGSM/GPRS to the BikeNet repository and back end ser-vices. This is done with a combination of SMS mes-sages from the back end pushed to the phone, and TCPconnections initiated by the N80 to transmit responses tothe back end. Upon reception of an SMS message, thephone uses a python script to parse incoming SMS mes-sages and acts according to the request. To upload datato the back end, the N80 opens a socket to a web serviceoperating at the back end and uses HTTP POST to trans-mit both ground truth data (e.g., photos, videos, soundclips) and BAN data (e.g., CO2 levels, road slope). Theweb server operates a parser for such incoming submis-sions and constructs SQL statements to insert the datainto the back end user repositories.

The use of a personal device like a mobile cellularphone as a mobile SAP gives rise to an interesting dualrole for the N80 in our system. Architecturally, there is aclean separation between SAP and sensor platform, but

in the case of a mobile phone, the cyclist might own thismobile SAP and thus the BAN to which the cyclist’s Per-sonalNode belongs might have nearly continuous accessto the SAP services and resources. Thus, in our imple-mentation, the N80 can be thought of as simultaneouslycarrying out its SAP role providing uploading, tasking,ground truth sensing, etc. to the BAN, and also actinglike a member of the BAN and offering its sensing re-sources (e.g., camera, microphone, display, speaker). Infact, although in our initial implementation we have keptthem separate, one can easily envision an incarnation ofthe BikeNet system that uses mobile cellular phones asPersonalNodes as well. As a mobile SAP the N80 offersreal-time sensing service and access to the owners BAN.In scenarios where the GPRS service is not available, theN80 is used simply as another member of the BAN, andthe service falls back to that of a delay-tolerant sensingsystem. For example, it can take on the LocalDisplayrole when operating in this disconnected mode, or mightprovide audio cues from its speaker to the cyclist a la thetraining cues given by Nike+ iPod [9] during a run.

3.1.5 Validation HardwareIn order to validate the data collected by the BikeNet

sensing system, we use a number of commercial off-the-shelf (COTS) hardware solutions. In the following, wediscuss how the COTS hardware is applied to increasethe confidence in the data collected by our BikeNet im-

plementation.The magneto-inductive sensor we connect to the

Tmote Invent is used to measure heading and to de-tect distortions of the Earth’s magnetic field caused bynearby ferromagnetic materials. In particular, we inferautomobile sparsity based on signatures observed in themagneto-inductive sensor data. To validate the abilityto determine heading, we simply compare our interpre-tation of the sensor data to known cardinal and ordinaldirections. To validate our ability to detect automobiles,we create a small BAN comprising a GPS-based Sync-Sprinkler, a MetalDetector, and a standard Tmote Inventprogrammed to write the (time, location) 2-tuple to theFlash every time the user button on the Invent is clicked(termedButtonMotefor ease of reference). We bicyclea planned route and manually click the ButtonMote userbutton every time we pass a parked automobile or anautomobile passes us. We compare the time/location-aligned MetalDetector trace with the ButtonMote traceto determine detection accuracy. In principle, the But-tonMote can be used in a similar manner to validate anydetection-based measurement or inference.

To provide richer context for the sensor measure-ments and inferencing we do in the BikeNet, we attachedfour Nokia N80 phones at the cardinal points of a bicyclehelmet, i.e., facing front, back, left and right (see Fig-ure 7(b)). Using continuous video capture (both visualand audio) throughout the ride we are able to validatethat events sensed/inferred by BAN sensors are at leastreasonable/probable and depending on the measurementtype we can definitively validate the data (e.g., car pass-ing the bike or not). In fact, using the audio capture weare able to give context about the rider that is not obvi-ous or at all detectable from a picture. For example, thecyclist describes his or her mental/physical state in re-ponse to car exhaust (“I am dizzy”), steep slope (“I amtired”), or overall cycling experience (“I am bored”).

We infer cyclist fitness level using a combination ofthe lateral tilt, slope, and pedal speed to wheel speedratio. To check our inferencing technique against a moredirect physiological measure of cyclist fitness, we usethe Garmin Forerunner 301 Heart Rate Monitor/GPS. Apositive correlation between our inferred cyclist fitnesslevel, and that indicated by the actual cyclist heart ratevalidates our technique.

In BikeNet, we calculate road slope by taking the in-verse tangent of the ratio the measurements from prop-erly oriented accelerometer axes. To validate the slopemeasurements using the accelerometer (the TiltSensorrole), we measure at 30m intervals the slope of a 0.75kmsection of the road containing slopes from 0 degrees to7 degrees using a laser level (model TUV EPT-97A,650nm). We receive excellent correlation between thetwo methods.3.2 Implementation Software

To address the design requirements derived in the pre-vious subsection, we implemente a number of data stor-age procedures, communication protocols, and data vi-sualizations. In the following, we describe a number

of these software system solutions grouped according tological function.

3.2.1 Impact of Hardware LimitationsBecause of the hardware we use in our implementa-

tion (e.g., the various sensing instruments, the Tmote In-vent) a number of limitations are imposed on the way thehardware can interact, and what software may be writtenon top of it. In the following we discuss the more inter-esting limitations we have encountered.

On the Tmote Invent platform, the Flash storage de-vice, the radio, and the UART all share the same physi-cal lines which can be used for either SPI (radio, Flash)or UART. Device access on this bus is mutually exclu-sive, requiring an explicit time management approachfor communication and storage, and since we use theUART as in interface to a number of external sensorsand display devices these facets of system operation arealso affected. The LCD, the BlueTooth/IEEE 802.15.4bridge used to network the N80, and GPS receiver allface this problem.

Another characteristic of the Tmote Invent is the lim-itation imposed by the number of spare ADC channelsand free GPIO pins on the MSP430 microcontroller. Theresult is that multiple Invents are used in order to sup-port all the required sensing roles in the system. Notonly does this increase cost by requiring several Inventsper BAN, but also increases contention on the wirelesschannel, especially intra-BAN, since not all data acqui-sition devides can be “wired in” to a single controller.With more capable hardware, we will be able to con-dense our current implementation by assigning multipleroles to a single sensor platform.

The Garmin GPS unit we use pushes location over theUART at a non-adjustable rate of once per two seconds.This limitation mandates either a location interpolationscheme, such as using dead reckoning with a combina-tion of data from the CompassSensor and WheelSensor,or accepting a loss of location accuracy of the collecteddata. Given that even recreational cyclists can easilyreach speeds over 50km/hr, especially when going downsteep hills, the location error can be substantial - up to25m or more.

The CC2420 radio used by the Tmote Invent has arelatively high raw bit rate (250 kbps) compared to othermote class platforms, and equivalent transmission power(0 dBm). On the other hand, due to the challenging en-vironment caused by mobilty and by the attenuation andreflections unique to a bicycle area network, radio con-tact time among BANs and SAPs can be limited andvariable. This argues for a maximally efficient trans-port protocol and application of appropriate compres-sion techniques. At the same time, sensed data is oftenunique and reliable upload of data is prefered by systemusers. In the experimental results presented in Section 4we use an acknowleged transport and no compression toget baseline results for the BikeNet system and defer aninvestigation of appropriate transport protocol and com-pression algorithms to future work.

3.2.2 Tasking and Role AssignmentIt is assumed that each cyclist possesses a mobile

personal computing device (e.g., mote, mobile phone)at all times that can be tasked by the SAP. In our sys-tem, each cyclist carries a Tmote Invent implementingthe software architecture shown in Figure 4(a). The SAPtasks the cyclist’s personal Invent to take on the Person-alNode role described in Section 2.2.1. The PersonalN-ode role includes a list of user preferences that dictatewhat additional sensing roles are desired to quantify thecyclist fitness/performance/environment. These desiredsensing roles are split into two lists, required and pre-ferred, represented as 16 bit maps (16 roles are currentlysupported). The bit maps are included into ahello bea-con periodically broadcasted by the PersonalNode. Eachpotential BAN sensor mote in the system running theBikeNet virtual machine (VM) replies to the beacon withahello replyif its sensing capabilities match those of ei-ther a required or preferred role as requested by thehellobeacon, indicating in thehello replywhich role(s) (e.g.,any of those listed in Section 2.2.1) it is offering to fill.If it has already associated with another PersonalNode asensor will not reply to thehello regardless of its fitnessto fill a requested role. Upon receiving ahello reply, thePersonalNode registers the respondant as the provider ofthe role(s) offered in thehello reply, sends ahello replyackto complete the association, and updates the requiredand preferred sensing role bit maps in subsequenthellobeacons to reflect the change. One can imagine a moresophisticated exchange wherein the PersonalNode sendsnot just ahello reply ackbut includes also the requiredsensing parameterization (e.g., sampling rate). In ourimplementation, for simplicity all sensing parameteriza-tion for the sensor that supports a given role is fixed inthe BikeNet VM at compile time. Association is reliablein the sense that if ahello reply ackis not received in re-sponse to ahello reply, thereply is retransmitted up toNtimes. If afterN times theack is not received, then it isassumed that mobility has carried the PersonalNode andpotential sensor apart and the partial association state ispurged.3.2.3 Sensing Control

When the PersonalNode has assigned BikeNet rolesand established an association with sensor platforms tomeet all the roles specified by the user preferences (re-flected in the required bit map descibed in Section 3.2.2),an LED on the PersonalNode indicates a ‘Ready’ state.A button click on the PersonalNode when in this ‘Ready’state sends astart message broadcast from the Person-alNode indicating that the ride is beginning and sensorsshould start collecting data with their prescribed param-eterization. This message is acted on by BikeNet nodesthat have associated with that PersonalNode (see Section3.2.2) and moves both the PersonalNode and the associ-ated sensors into the ‘Started’ state. If associated sensorsdo not receive astart message within a timeout period,the association times out and the sensors are free to as-sociate with another PersonalNode at that time. A sub-sequent PersonalNode button click while in the ‘Started’

state sends astopmessage broadcast, signaling the endof the ride. Thestopmessage is acted on by BikeNetnodes that have associated with that PersonalNode andare in the ’Started’ state, and results in a cessation ofsensing.

3.2.4 Event Triggered SensingSensing triggers and the actions that result when the

requisite conditions are met are both a matter of user pro-file. The BikeNet implementation support of triggeredsensing includes methods to define and submit sensingtriggers and actions to the PersonalNode for executionwithin the BAN. Upon receiving the triggered sensingdefinition, the PersonalNode breaks apart the conditionsthat must be met for the action to take place, and reliablytransmits each condition (e.g., “slope> 5 degrees”) tothe BAN member suited to evaluate the condition (e.g.,the TiltSensor). When a condition evaluates to true,the BAN member signals the PersonalNode. The Per-sonalNode initiates the action when all conditions fora given triggered action are met. We are currently fo-cusing on triggered photograph, video and audio captureusing the camera and microphone on the N80, when cer-tain conditions in the BAN are met, but we have also im-plemented support for a number of other actions such assending data to be displayed on the BAN LCD, sensingsomething at a different parameterization than the cur-rent one, playing a sound on the N80 or Invent speaker,transferring sensed data from one sensor platform to an-other, and trivial actions like blinking an LED on thePersonalNode.

3.2.5 Resource SharingA PersonalNode requests to share the resources of

another BAN if it does not have all the preferred sens-ing roles as required by user profiles. In order to findsensor platforms that can fill the desired roles, the Per-sonalNode executes the same protocol decribed for sen-sor association for native sensor roles in Section 3.2.2.However, each message contains a one byte field that in-dicates whether this is an exchange for native associationor resource sharing. In practice, in our implementation,the difference between native and borrowed resources isthat native associated resources are controllable viastartandstopmessages. Borrowed resources that hear astopmessage from a PersonalNode to whom they are loaneddo not stop their own sensing (only astopmessage fromtheir native PersonalNode can cause this); instead theyterminate the sharing assocation and purge any outstand-ing triggers or streaming data transfers executed solelyon behalf of the sharing BAN.

3.2.6 Synchronization/LocalizationThe SyncSprinkler periodically broadcasts loca-

tion/time data obtained from a GPS receiver to the bikearea network. Each mote in the bike area network keepsa local estimate of its current location and the currenttime. The local time estimate is updated externally withthe values contained in the SyncSprinkler broadcasts,and internally via a local clock to provide higher timeresolution between SyncSprinkler broadcasts. Similarly,

the local location estimate is updated with the valuescontained in the SyncSprinkler broadcasts. In Section4.3.2 we present results on the feasibility of using thecombination of distance value from a WheelSensor anda heading value from a CompassSensor to provide an es-timate of location within a bike area network, as an alter-native to the GPS-driven SyncSprinkler solution. Eachmote in the bike area network stamps its sensed data withits current location and time estimates before storing thedata in its local cache.3.2.7 Indirect and Direct Information Sharing

Indirect information sharing occurs via a Bike-to-Rock protocol, in which any mote in the BAN mayparticipate. The protocol comprises three phases: dis-covery, establishing session context and data exchange.Since a rock is untethered (no line power) we reduce itsenergy burden in the discovery phase by having it pas-sively listen until it overhears intra-BAN messages froman approaching bicycle. Upon overhearing, it becomesactive and begins beaconing rapidly to notify passingBANs of it’s presence. This beaconing times out aftera period of no response, after which it is assumed theBAN has moved out of range or is not interested. BANsthat wish to use the beaconing rock establish a sessioncontext through an authenticated exchange, after whicha meta-data exchange occurs. The meta-data contains in-formation about data that the BAN, based on the cyclistpreferences, aims to store/retrieve to/from the rock. Thesession concludes with the data exchange, an acknowl-edged stream from the rock to the BAN mote. Sessionstime out after a period of inactivity. For example, a cy-clist may store her average speed of the prior 3 km oftrail every time she takes the trail. As she passes therock during the current ride she both inserts her senseddata from the current ride, and retrieves data of the sametype from her personal history, the history of her friend,and the average of all cyclists that have taken the path. Arepresentation of the information retrieved from the rockcan be shown in real time to the cyclist via her LocalD-isplay, if desired.

The Bike-to-Bike communication protocol for directinformation sharing is indentical to that of the Bike-to-Rock communication protocol, though no rock re-sources are used. While indirect information sharing viarocks is done with a focus on sharing location-specificdata, direct information sharing is rendezvous-specific;you share information with a person rather than about aplace.3.2.8 Real-time Feedback/Display

The BAN LCD protocol is used by the LocalDisplayto query nearby sensor platforms for values to display.The LocalDisplay is provided either by an N80 mobilephone, or by a handlebar-mounted LCD. Because theInvent’s hardware design shares the SPI bus betweenradio and flash, and the same physical microcontrollerpins are used for UART0, SPI bus arbitration is nec-essary to write data to the LCD display module. Thesame limitation exists with our N80/mobile SAP imple-mentation since the BlueTooth-to-Serial converter is also

connected to the Invent UART0 port. This precludes si-multaneous radio communication and display updating,and hence BikeNet uses a simple TDMA-like time slotassignment on top of the CC2420’s CSMA MAC to im-prove communication between the sensor platforms andthe LocalDisplay. The LocalDisplay broadcasts a queryfor data and the sensor motes register the first LocalD-isplay they hear a query from as the only LocalDisplaythey will reply to thereafter. This association times outafter a period if no queries are heard from the LocalDis-play. The data that a given sensor role returns is a matterof user policy, but a typical display might include speed,distance traveled, bike frame tilt angle, pedal RPMs, andtime of day. Data from rock motes and debug messagesfrom sensor motes can also be displayed (this is help-ful for troubleshooting in the field). A simple extensionto the protocol allows displaying select data from othernearby BikeNet equipped bicycles. Future work will in-clude adding graph displays of the cyclists performanceand profiles of road characteristics.

3.2.9 Sensed Data Muling and UploadA simple muling protocol is implemented on every

mote, but the option to activate muling (i.e., spend Flashspace to carry others’ data) is by cyclist preference. Theprotocol uses anadvertisement-accept-dataexchange,where theadvertisementspecifies the number of datarecords the data provider has available in Flash for mul-ing, theacceptmessage indicates the number of recordsthe data consumer is willing to mule (based on Flashconstraints) and thedata message represents a burst ofdata packets from the producer to the consumer. In ad-dition, Stop-and-Wait ARQ with a maximum of threeresends provides for reliable transfer of the data packetburst. If a producer still receives no acknowledgementafter three resends of the same packet it will assume thesession established with theadvertisement-acceptex-change is over (most likely due to mobility) and beginsadvertising anew. Our implementation includes supportfor replication of sensed data via the muling process butre-muling (the replication of muled data) is not currentlysupported. Disallowing re-muling allows the data sourceto maintain control over the number of copies of its datathat are circulating and more importantly with whom thedata is been shared. The upload protocol message ex-change is identical to that of the muling protocol. Whena SAP receives data packets, they are forwarded via se-rial port (in both the mobile SAP and static SAP cases)to the back end repository. The decision to accept newupload sessions by the SAP is made based on channelcongestion around the SAP. Results on the muling anduploading protocol efficiency are shown in Section 4.3.

4 System EvaluationIn this section, we present results from several groups

of experiments repectively targeted at: quantifying thecyclist experience by sensing and inferencing fromsensed data collected about a single cyclist and his or herenvironment; investigating the correlations between datacollected by cyclists traveling in a flock (e.g., a group of

41.9

42

42.1

42.2

42.3

42.4

16.8 17 17.2 17.4 17.6 17.8 18

Latit

ude

(dec

imal

min

utes

)

Longitude (decimal minutes)

AB

C

D

GPS trace

Figure 8: The mapped GPS trace of the cyclist route. Theroute comprises roads in the vicinity of Dartmouth College inHanover, NH, USA.

riders); looking at performance aspects of key BikeNetsubsystems; and measuring the real-time performance ofa deployed system across the Dartmouth campus and inadjacent areas of Hanover, NH. For the single bike andflock experiments we use a common path that we callthe ground truth route. This route includes a variety ofurban cycling terrain, including built up busy roads inthe town center with lots of cars and pedestrian trafficand quiet back roads with little or no traffic. The routeexposes cyclists to a variety of flat terrain, gradual downhill and steep uphill sections. Typically the ground truthroute takes 25-30 minutes to ride and is nearly 5 kmlong. The experiments are conducted at rush hour andin the middle of the day when there is less traffic andactivity. We conducted many experiments over the pe-riod August - November 2006 collecting a typical dataset of 0.8 MB per ride per bike. We plan to make thedata traces available [4]. For all experiments we recordthe experiments using video from the video helmet (Fig-ure 7(b)). This allows us to collect 4-directional videoof a ride, and correlate events in the video with sensordata in terms of ground truth - see [5] for an exampleof video-to-sensor correlation that we use as part of ourexperimental methodology.

4.1 Cyclist Experience Mapping4.1.1 Inference and Cyclist Fitness Sensing

In this section we present a series of plots character-izing cyclist behavior and the environmental conditionsencountered during a ride. We collect data from eachof the sensing roles mentioned in Section 2.2.1, and ap-ply data fusion and trend analysis to infer higher levelcontext from the raw data.

Figure 9(a) shows the slope calculated from TiltSen-sor readings versus distance. The slope is measuredby feeding thearctan function with the TiltSensor’s x-and y-channel accelerometer readings. We register ac-curate measurements when the bike is stationary; errorincreases with speed and terrain roughness due to unfil-tered vibrations and cyclist behavior. Figure 9(a) shows

-8

-6

-4

-2

0

2

4

6

8

0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 5 5.5

Tilt

Rea

ding

Distance (Kilometers)

Tilt average angle

(a) Tilt vs. distance

(b) A plot of lateral tilt versus distance. Periods of increasedlateral tilt can be correlated with corner turns expected fromthe mapped GPS trace shown in Figure 8.

Figure 9

the profile of the route with a 90% accuracy when com-pared to ground truth measurements.

Figure 9(b) shows the readings obtained from the Lat-eralTiltSensor versus distance. The lateral tilt is mea-sured by feeding thearctanfunction with the LateralTilt-Sensor’s x- and y-channel accelerometer readings. A cy-clist’s aggressiveness in turning is inferred. From theplot we correlate the increases in lateral tilt shown onthe y-axis, with corner turns expected from the mappedGPS trace shown in Figure 8. Positive increments of thelateral angle indicate a right-side lean whereas negativeangles are for left-side leans. The letters in Figure 9(b)mark the readings corresponding to the turns indicatedwith the same letters in Figure 8, where at A, B, C, andD the biker makes, respectively, a right, a right, a left,and a left turn. The very sharp left tilt (almost -20 de-grees) is due to mounting the bicycle at the beginningof the ride. Figure 9(b) shows that it is possible to in-fer biker’s turns (positive angles for A and B, negativeangles for C and D).

The quantitative aspects of the cyclist fitness includethe slope of the road/trail that the cyclist covers on her

0

50

100

150

200

250

300

0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 5

10

8

6

4

2

0

-2

-4

-6

-8

-10

-12

Rat

io (

%)

Slo

pe a

ngle

(de

gree

)

Distance (km)

Tilt slope angleWheel/Pedal ratio

Figure 10: A plot of road slope and wheel speed to pedal speedratio along the traversed route. Cyclist fitness can be inferredby correlating the gear ratio inferred from the wheel/pedalratioand the measured road slope.

0

50

100

150

200

250

300

0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 5 0

50

100

150

200

250

300

Ped

al R

PM

Whe

el R

PM

Distance (km)

Wheel RPMPedal RPM

Figure 11: A plot of pedal RPM and wheel RPM along thetraversed route. Periods of coasting can be inferred by zeroornear zero pedel RPM with non-zero wheel speed.

ride, the speed profile of the cyclist, the gear used whentraveling up a given slope, and the location of the route.Figure 10 shows a plot of the slope of the road tra-versed on the trip of the cyclist, and the ratio of the thetire/wheel speed, as measured by the WheelSensor, tothe pedal speed, as measured by the PedalSensor. Thisratio infers the approximate gear the bicycle is in at agiven point in the route, or equivalently provides a no-tion of the fitness of the cyclist. This fitness indica-tor is most accurate when the cyclist is going uphill,since when going downhill the pedals may not be movedmuch at all (coasting). A cyclist with strong legs canuse a higher Wheel/Pedal ratio when climbing hills. Onthe other hand, recently the use of a high pedaling ca-dence (which gives a higher aerobic workout) at all timesthroughout a ride has come to prominence [37]. In Fig-ure 10 it is possible to infer intervals where the cyclistchanges gears to climb hills (from roughly 1 to 1.25 kmand from roughly 2 to 2.7 km), where the Wheel/Pedalratio is close to 1.

0

100

200

300

400

500

600

700

0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 5

6

4

2

0

-2

-4

-6

-8

-10

-12

Whe

el R

PM

Slo

pe a

ngle

(de

gree

)

Distance (km)

Tilt slope angleWheel RPM

Figure 12: A plot of road slope and wheel RPM along thetraversed route. Periods of strong braking can be inferred byslowing wheel speed while on a increasing or stable downhillslope.

Knowledge of the sensed path slope combined withthe measured pedal speed and wheel speed allow us toinfer when a cyclist is coasting or braking. On a givenbicycle there is a finite discrete set of allowable pedalspeed to wheel speed ratios when the bicycle chain isengaged with a gear and providing thrust to the bicycle.The cardinality of this set is equal to the number of gearsthe bicycle has. If the measured ratio of pedal speed towheel speed does not match one of the allowable valueswe can infer that the cyclist is coasting. In particular, ifthe pedal speed is zero and the wheel speed is non-zero,we can easily infer the cyclist is coasting. Figure 11shows the pedal speed to wheel speed ratio versus dis-tance. In the figure, from roughly 1.25 to 2 km and 2.7to 3.3 km, the pedal speed is approximately zero whilethe wheel speed is high, indicating coasting.

Braking can be inferred in a similar fashion to coast-ing. It is likely a cyclist is braking if the measured wheelspeed slows while the slope is negative (downhill). Fur-ther, braking is likely when going uphill if the measuredwheel speed slows faster than dictated by the slope of thehill, though this is more challenging to detect. Note thatinference of uphill braking is dependent on knowledgeof the combined mass of the bicycle and the cyclist. Fur-ther, in all cases, but particularly when the slope is flat,inference of braking is complicated by the fact the gener-ally the route surface composition is not known exactlyand thus the appropriate coefficient of rolling friction toassume is also unknown. This fact precludes detectingslight braking, but hard braking can still be detected inmost cases. Figure 12 shows the wheel speed and slopeversus distance along the route shown in Figure 8. Inthe figure, applying the simplest inferencing techniqueof observing decreasing speed when the downhill slopeis increasing or level, we see sharp braking intervals at≈ 1.6 km,≈ 3.3 km and≈ 3.9 km. In these cases, wesee a sharp decrease in wheel speed concurrent with asustained downhill slope.

Aside from route topography and personal perfor-

(a) x-axis magnetometer readings (b) y-axis magnetometer readings

Figure 13

mance metrics, cyclists are interested in the ambience ofa route as a determinant in the overall enjoyment of thecycling experience. We take steps towards quantifyingthe ambience in terms of automobile traffic, air quality,sound level and GSR readings. The presence of vehiclesis often undesirable for cyclists who have concerns aboutsafety, noise, and pollution. To infer automobile trafficalong the cyclist route (Figure 8), each BAN is equippedwith a MetalDetector. When the MetalDetector passesclose to any large metal body the Earth’s magnetic fieldis deformed and is interpreted as an anomaly on the mag-netometer; the time and location of the inferred car pre-sense is stored in Flash. We write embedded softwarethat runs automatically to calibrate the magnetometeronce mounted on the bikes to take into account the effectof the metal of the bike and the rack where it is mounted.The calibration routine stops once the ride data cap-ture starts. To collect ground truth data for comparisonagainst the inference from the MetalDetector, the eventof passing by a car is registered by the cyclist by meansof a ButtonMote click. Each click generates a recordof GPS time and location information, and video cap-tures. The ButtonMote records are stored into its Flashmemory, as well as uploaded once the BAN comes incontact with a SAP. We use the ButtonMote data anddata from the video stream discussed above as groundtruth for car detection. Figures 13(a) and 13(b) show,respectively, the x-channel and y-channel of one Met-alDetector’s magnetometer readings plotted versus thedistance covered along the ride. ButtonMote events areshown overlayed on the same plots for comparison withthe ground truth. To better capture the details of the se-ries, we report in the graphs only a portion that includesthe first kilometer of the ride. It is evident that the mag-netic field anomalies measured by the MetalDetector (asseen by sharp simultaneous spikes on x and y channelsof the magnetometer) occur at the same locations as theButtonMotes events. We have annotated Figures 13(a)and 13(b) with letters to highlight the matches. Despitethe high correlations we see, additional filtering and sig-

nal processing algorithms are needed to detect and elim-inate false positives.

410 420 430 440 450 460 470 480 490 500 510

0 0.5 1 1.5 2 2.5 3 3.5 4 4.5

CO

2 R

eadi

ng (

PP

M)

Distance (Kilometers)

rush hourlow traffic

Figure 14: A trace of the carbon dioxide readings along theroute shown in Figure 8.

To provide a measure of air quality along the cyclist’sroute we conduct experiments using a sensor measuringthe level of carbon dioxide in the air surrounding the cy-clist. Figure 14 shows a trace of the carbon dioxide sen-sor readings along the route shown in Figure 8 for twodifferent cases, namely, rush hour and low traffic. Thepeaks in the rush hour case occur when the biker wascycling on downtown roads with a considerable pres-ence of cars. In fact, variation in carbon dioxide levelsmeasured on roadways is likely to be the result of auto-mobile exhaust. While carbon dioxide has low toxicityat all levels we recorded during our experiments, it canact as a predictor of other noxious automobile exhaustgases such as hydrocarbons, nitrous oxides, and partic-ulate matter. Thus, from readings of the carbon dioxidesensor we can infer how enjoyable the traveled route isfor a cyclist from the standpoint of pollution.

Another way to detect the presence of vehicles is bythe adoption of a microphone. For this purpose we in-

68

70

72

74

76

78

80

0 0.5 1 1.5 2 2.5 3 3.5 4 4.5

Sou

nd v

olum

e [d

b]

Distance (Kilometers)

Sound reading

Figure 15: Sound vs. distance

clude in the BAN a SoundSensor. The readings derivedfrom the SoundSensor are reported over distance in Fig-ure 15 for a ride along the path of Figure 8. As expected,the sound volume is higher as the number of cars in-creases and again this occurs in downtown areas from 1to 1.7 km and 2.7 to 3 km when the biker rode on thesame location twice along her ride.

0.003

0.0035

0.004

0.0045

0.005

0.0055

0.006

0 0.5 1 1.5 2 2.5

GS

R r

eadi

ng

Distance (Kilometers)

GSR reading

Figure 16: GSRSensor readings

By using the GSRSensor we aim to measure the stresslevel of the biker. How tense is the biker when she ridesbetween cars? Is that incline a struggle? We conductone of the experiments by equipping the cyclist with aGSRSensor along the path of Figure 8. The result isshown in Figure 16 where we report only the first 2 kmof the ride to better catch the details of the GSR readingson the y-axis. It is possible to identify three segmentsof the path where the GSR registers the higher values,namely, from 0 to 0.5 km, from 1 to 1.3 km, and from1.6 to 1.7 km. These roads correspond, respectively, toa cars populated urban area, medium steep downhill andmedium steep uphill. From this result we can infer thatthe cyclist was experiencing a certain degree of stresswhile riding in town, possibly because of the presenceof cars, she was tense while traveling downhill being

0 1 2 3 40

0.2

0.4

0.6

0.8

1

Joy

Distance (km)(a) A plot of enjoyment index for a single rider

0 1 2 3 4 5−5

0

5

10

15

Per

form

ance

Distance (km)

bike2bike3bike4

(b) A plot of performance index for three riders with differentpreferences.

Figure 17

carefull given the high speed, whereas her workload washigh during the uphill.4.1.2 Quantifying a Cycling Experience

From the raw values obtained from the magneto-inductive sensor and the carbon dioxide sensor, alongwith sound levels from the microphone and slope valuescalculated from the accelerometer, we derive values forthe enjoyment indexof routes that a cyclist travels. Atthe back end data repository, these index value are thenmapped to colors and routes are visualized as a color-coded playlist (see [5].) We quantify the enjoyment us-ing the following equation:

Joy= 1.0−a1 ∗HillAngle−a2 ∗CO2Level−a3 ∗SoundLevel.

When the HillAngle is positive cycling is more difficult,reducing the Joy of the casual cyclist. When HillAngleis negative the cyclist can coast, a pleasurable experiencefor most people, resulting in an increased Joy index. Ahigher CO2 level implies there are more cars near the cy-clist, creating an unpleasant experience due to exhaust,noise, and increased danger, driving the Joy index down.Similarly an increase in noise level indicates more traf-fic, people, wind, shouting, etc., reducing pleasure and

the Joy index. The selection of weighting factors is cy-clist dependent since each person has different levels ofdislike for these annoyances. Figure 17(a) shows a plotof the Joy index for a given rider over the course of theroute shown in Figure 8. The weighting factors chosenhere werea1 = 0.5,a2 = 0.3,a3 = 0.2, indicating the cy-clist dislikes steep rides the most, is somewhat annoyedby cars, and doesn’t care much about the sound level.Accordingly, the Joy index goes down during the steepand car congested parts of the ride. By aggregating datafrom multiple cyclists over time, the relative The joyindex of paths is computed to predict where the goodcycling is. Optionally, the maximally enjoyable path iscomputed between two endpoints.

Some cyclists primary purpose in riding is for exer-cise or for competition and they may be less interestedin the joy index of a ride. For these riders we calcu-late aperformance index, using the raw values obtainedfrom the WheelSensor, PedalSensor, and TiltSensor. Wecompute a unitless measure of performance (P) using thefollowing equation:

P = a1 ∗HillAngle+a2 ∗WheelSpeed/PedalSpeed+a3 ∗Distance.

When HillAngle is positive the performance index goesup; when it is negative the index goes down. When thewheel/pedal ratio is high this indicates the bike is in ahigher gear (the wheel goes further with fewer pedalturns) and the index increases. The further a rider trav-els (largerDistance) the higher the performance index.The graph in Figure 17(b) shows the comparative per-formance of three cyclists, all traveling the same route atthe same time. Two of the riders perform similarly butthe third rider put his bike in a lower gear when goingup the steep hill and thus has a lower performance be-tween the two and three kilometer marks. The weightingconstants where chosen such that traveling five kilome-ters, a wheel/pedal ratio of 0.1, and a tilt of five degreeswere all considered to have equal effect. Unlike the joyweighting constants, the performance constants shouldremain the same for all riders. By aggregating data frommultiple cyclists over time, the relative performance in-dex of paths a cyclist is considering is computed to pre-dict where the most challenging paths are. Optionally,the most challenging path is computed between two end-points.4.2 Bicycle Flocks

There is a strong social element to bicycling, withmany cyclists often riding in groups or flocks. If all ofthe cyclists have BikeNet sensors then we would expectcertain types of sensors to return very similar readingsfor all the cyclists in the flock. This correlation amongstreadings may have several applications including: auto-matic calibration checks of sensors, noise reduction insample data using shared information, and sharing ofsensor data with those who are missing sensors (e.g., themore expensive ones.)

We examine the correlation between the sensor datain one of the multibike experiments to explore this facetof BikeNet. In this experiment the cyclists usually re-main within about 10 meters of each other, though there

are occasional separations of as much as 50 meters. Theroute taken by the cyclists is the same as shown in Fig-ure 8. We compare results from a representative two bi-cycles in the following plots. Figure 18(a) shows thespeed profile of two bikes, demonstrating a strong corre-lation in speed throughout the experiment. Figure 18(b)shows the tilt profile of the same bikes, again demon-strating a strong correlation in tilt. Figure 19(a) showsthe compass readings from the bikes are strongly corre-lated. (Note that one compass stops reporting data be-tween 0.4 and 0.65km. Note also that one of the cyclistshas a tendency to wander from side to side, especiallynear the 0.9 kilometer mark.)

Figure 19(b) on the other hand shows that the soundsensors on the two bikes are only somewhat correlated.This graph is computed from the sound data from bothbikes, interpolated so that the samples are aligned at theexact same distance along the path. Thus we are com-paring the sounds at the same location (and not neces-sarily at the same time.) The weak correlation is due toseveral factors including multipath reflections of sound,wind noise variations over time, one or the other ridersyelling comments, inverse square fading of volume withdistance, cars passing each cyclist at different times, andphase differences from small differences in each bikespath.

Some sensor data exhibits no correlation at all. Thelateral tilt of each bike is dependent on the way each cy-clist rides and varies a lot from bike to bike. GSR isunique for each cyclist. Gear ratio is loosely correlateddepending on several factors including the strength andcondition of the cyclists, the gear ratios available on eachbike, the wheel size, and the choice of each cyclist as towhen they pedal and when they coast. Pedal speed hasa similar loose correlation for the similar reasons. CO2data is highly correlated between riders in a flock sincethe exhaust of cars becomes well mixed by the turbu-lence created by the cars motion. GPS data is stronglycorrelated between cyclists depending on how close to-gether they ride.

Thus the sharing of some types of sensor data is fea-sible and likely to be quite useful. In the course of thisstudy we learn that the sample rates for several of oursensors reduce the potential usefulness of shared data.For example, we want to try correlating GSR to pedalRPM’s to see if the periodicity of the pedaling shows updue to the shifting pressure the cyclist put on the GSRelectrodes. However the 1Hz sample rate of the GSRoutput is too slow to capture this phenomenon if it ex-ists because people often pedal at somewhere near 1Hz.For future work we are searching for methodologies forexamining the correlation of data that may be skewed intime or location, and which may have only a fuzzy sortof correlation. For example, correlating CO2 concentra-tion with car detections from the magnetometer is com-plicated by the fact that the CO2 sensor reacts slowly tochanges in CO2 concentration, taking about a minute torespond to changes.

0

50

100

150

200

250

300

350

0 1 2 3 4 5 6

Spe

ed (

RP

M)

Distance (km)

Bike 1 Wheel RPMBike 2 Wheel RPM

(a) Comparison of speed profiles of two bikes.

-8

-6

-4

-2

0

2

4

6

8

0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 5

Tilt

(de

gree

s)

Distance (km)(b) Comparison of tilt profiles of two bikes.

Figure 18

0 0.2 0.4 0.6 0.8 1

0

20

40

60

Distance (km)

Hea

ding

(de

gree

s)

(a) Comparison of compass profiles of two bikes.

70 72 74 76 78 8070

72

74

76

78

80

Volume (dB)

Vol

ume

(dB

)

(b) Correlation test of sound data from two bikes.

Figure 19

4.3 Services Performance4.3.1 Data Sharing

In what follows, we evaluate two types of BikeNetdata sharing. We first consider a bike-to-rock experi-ment that analyzes sharing between a mobile bike thatpasses a stationary rock device and attempts to publishevent data. Second, we evaluate a bike-to-bike sharingexperiment where both bikes are mobile, presenting alimited rendevous window for the BANs to interact andshare sensing modalities. Data sharing under these con-ditions is challenging because of multipath conditionsand radio propagation issues, and due to the short rangenature of the radio (between 30m-50m outside), commu-nication opportunities are short lived in many cases (e.g.,on the order of seconds for bikes traveling in oppositedirections that initiate sharing). Therefore, BikeNet isdesigned to quickly assert communications and attemptto complete operations in a timely and reliable manneras discussed in Section 3.2.7.

We first consider the bike-to-rock experiment. The

0 5

10 15 20 25 30 35 40 45 50

-60 -40 -20 0 20 40 60

Pac

kets

Per

Sec

ond

Relative Distance of Separation

Figure 20: Effect of bicycle separation on session packets re-ceived.

0

10

20

30

40

50

60

-60 -40 -20 0 20 40 60

Pkt

s pe

r se

cond

Distance of Separation

Figure 21: Effect of separation between bike and rock on ses-sion packets received.

experimental set up is as follows. The rock is placed0.3 m off the ground at the mid point of a 240 meterlong path that the bicyclist traverses in a straight line atan average speed of 2 meters per second. The BAN at-tempts to detect the rock and upload data. We recordthe time series of the packet reception at the rock forten separate experiments. Figure 21 shows the packetdelivery rate per second against distance for the experi-ment. Distance is interpreted as follows, a negative num-ber indicates that the bike is moving toward the rock,while a positive number means the bike is moving awayfrom the rock along path. Distance zero indicates thatthe bike and rock are at the same point (as measuredby the WheelSensor). From the plot we observe an av-erage packet transfer rate over ten runs of 22.7 packetsper second. This is for reliable ordered data transfer asdiscussed Section 3.2.7. As part of the experiment werecord the contact time between the bike and rock whichrepresents the interval in seconds that bike and rock arecapable of exchanging data. In the experiment the bikeattempts to upload far more data than is possible, mean-ing that the bike always has more data to exchange as-suming that there is an association (i.e., the bike and rockare in radio range). From the results we observe an aver-age contact time across all ten experiments of 9.25 sec-onds. This results in an average transfer of 637 bytesbetween the bike and the rock.

Next, we consider a bike-to-bike sharing experiment.The same experimental setup discussed above is used.We conduct ten independent experiments for two bikesthat start down the same path starting at opposite ends ofthe path. We record the average speed of each bike andthen average each bike’s speed over ten runs. To mea-sure distance between bikes we select one bike as thereference bike from which the distance is computed anduse the same signed distance semantics as in the bike-to-rock experiment. Results for the bike-to-bike experi-ment are shown in Figure 20. The plot shows the reliabledata transfer of the reference bike’s CompassSensor dataoperating at a very high sampling rate to produce suffi-

0

0.2

0.4

0.6

0.8

1

1.2

0 200 400 600 800 1000

Diff

eren

ce fr

om G

PS

(km

)

Time (seconds)

WheelWheel+Compass

Figure 22: Deviation from GPS of measured distance byWheelSensor; deviation from GPS of absolute location byWheelSensor+CompassSensor using dead reckoning from aknown starting location.

cient traffic to share with the other bike. In this scenariothe reference bike always has data to transfer if there isan association between the bikes. The average speed ofthe reference bike and other bicycle are recorded as 3.45meters per second and 2.55 meters per second, respec-tively. The average packet transfer rate recorded for anaverage contact time of 10.75 seconds is 19.8 packetsper second. This results in an average reliable transferof 556 bytes between the bikes.

From both experiments we can make a number ofsimilar observations. We observe asymmetry in through-put performance between the transmitter and receiver inboth experiments (i.e., the bike is the transmitter and therock the receiver in the first experiment, and the datumbike is the transmitter and the other bike is the receiver inthe second experiment). This throughput skew or asym-metry is clearly shown in both plots. We believe thisis an artifact of the placement of sensors on the bikes.The radio transceiver is located on the front of the biketherefore, we conjecture, that the drop is due the the ad-ditional interference presented by the body of the cyclistrather than an other issues (e.g., we discounted doppleras a factor). For future work we will study changing thetransmitter on the fly to use the sensor platform with thebest channel to the receiver to provide increase through-put and to remove this throughput assymentry.

4.3.2 Cyclist LocalizationIn the BikeNet system, each data record is tagged

with location (and time) to provide context. Section2.2.2 describes the BikeNet localization design. WhileGPS is a natural solution for the implementation of theSyncSprinkler role, other lower cost implementationswarrant an investigation given that not every BAN maybe equipped with a GPS receiver, and GPS is limitedin its application since it must have vision of at leastthree satellites. In particular, it is not always functionalin some common bicycling environments (e.g., amongtall buildings in a city, under dense overgrowth (tree

42

42.05

42.1

42.15

42.2

42.25

42.3

42.35

42.4

42.45

16.7 16.8 16.9 17 17.1 17.2 17.3 17.4 17.5 17.6

Latit

ude

(dec

imal

min

utes

)

Longitude (decimal minutes)

A

B

C

Estimated trace

Figure 23: Map of estimated absolute location usingWheelSensor+CompassSensor using dead reckoning from aknown starting location. The skew compared to the actual lo-cation trace shown in Figure 8 is the results of a miscalibratedmagnetometer channel.

canopy)). In the following, we present results determin-ing the accuracy of a WheelSensor in measuring totaldistance traveled by the cyclist. We also present the ac-curacy of using the combination of WheelSensor andCompassSensor for measuring localization (i.e., deadreckoning). In both cases, a known starting location isrequired. Both results are shown with respect to the GPSsolution.

We present the absolute error of these localizationalternatives in Figure 22. As seen from the curve la-beled ‘Wheel’, the deviation from the GPS-derived dis-tance grows continuously over the course of the ride.A closer look at the data shows that WheelSensor inconsistently underestimating the distance traveled. TheWheelSensor technique requires that the circumferenceof the tire be known; we initialized the WheelSensorwith the value we measured with a tape measure. Weconjecture that over the course of a ride, small errorsin this measurement accumulate to cause the continu-ously increasing error. As seen from the curve labeled‘Wheel+Compass’, the deviation in absolute localiza-tion from GPS has a rather symmetric growth and recov-ery shape. We conjecture this is due to a calibration er-rors in one channel of the CompassSensor’s magnetome-ter. Comparing the localization error trace to the routetaken by the cyclist, we see that error always increaseswhen heading west or south, and always decreases whenheading east or north. This is consistent with miscal-ibraion of one of the two analog outputs of the mag-netometer, which have the following trigonometric re-lationship to the heading:arctan(Y/X). We can viewthe manifestation of the compass miscalibration anotherway by mapping the absolute coordinates derived fromthe ‘Wheel+Compass’ solution and comparing the routeto the GPS trace shown in Figure 8. Figure 23 showsthis location trace estimated using dead reckoning.

While the GPS-substitutes we evaluate here may notbe accurate enough to replace GPS, we note that in the

case of both the ‘Wheel’ and the ‘Wheel+Compass’,the deviation from GPS, for example, is relatively smallfrom time 0s to time 200s (e.g.,< 200m). Therefore,we conclude that these GPS-substitutes may be used ascomplementary solution that interpolate between occas-sionally received GPS beacons, e.g., once every 2 min-utes.

The ability to localize a cyclist (via GPS or a Com-passSensor/WheelMote alternative) gives rise to a “lazytracking” feature of BikeNet. Since each data record isstamped with time and location metadata when it is sam-pled, any packet that is delivered to the data repositorycontains information that can be used to reconstruct thetrack of individual cyclists.4.3.3 Data Uploading and Muling

Throughout the conducted experiments, sensed datais always stored in the local Flash memory of the sensingplatform (i.e., Tmote Invent). Ultimately, this data mustbe transferred to the back end data repository. Depend-ing on bicycle and cyclist mobility this transfer may hap-pen directly from BAN to SAP using the upload protocol(Section 3.2.9), or may happen indirectly via the mulingprotocol (Section 3.2.9). There are two main scenariosto consider: (i) the bicycle enters in range of a SAP inwhich case the sensor nodes in the BAN upload theirdata to the SAP directly or (ii) the bicycle is travellingout of range of the SAP, and must rely on probabilisticmobility of other people or BANs to mule the data to aSAP.

Since the Stop-and-Wait ARQ reliable tranfer mech-anism used in the muling and upload protocols is wellknown we omit any evaluation of this mechanism per se.Rather, we aim to characterize the opportunistic sensornetworking environment provided by BikeNet. In Fig-ures 24, 25 and 26, we show results from a multi-bicycleexperiment where each cyclist follows a prescribed path;the paths intersect giving rise to inter-bicycle muling op-portunities. The paths followed by each of the four bi-cycles used in the experiment is around the perimeter ofthe Green field in front of Baker Library at DartmouthCollege. The size of the Green field is approximately150 meters by 100 meters. Two cyclists ride clockwisearound the green field and the other two cyclists ridecounter clockwise. The transmission range of the sensormotes are less than 50 meters so the connections amongthe cyclists are not always present but there are trans-mission opportunities when the cyclists who are mov-ing the oppposite direction pass by each other. After tenminutes of circling around the green field, each cyclistleaves the green field one by one with fifteen minutes in-terval and parks the bicycle within the radio range of theSAP installed at the Sensor Systems Lab in the Com-puter Science building which is 250 meters away fromthe northeast corner of the green field.

In Figure 24, we show the number of data packetsdirectly uploaded and the number of data packets muledto the SAP. The x-axis of the plot is the id of the sensormotes. The node id from 1 to 6 belongs to bike one,11 to 16 belongs to bike two, 21 to 26 belongs to bike

0

500

1000

1500

2000

0 5 10 15 20 25 30 35 40

Num

ber

of p

acke

ts u

ploa

ded

Node id

direct uploadingmuling

Figure 24: The Green. Muling/upload splits.

three, and 31 to 36 belongs to bike four. This x-axis isthe same for Figures 25 and 26 as well. Overall, moredata packets are directly uploaded than muled. However,a considerable amount of data are muled.

0

1000

2000

3000

4000

5000

0 5 10 15 20 25 30 35 40

Late

ncy

(sec

onds

)

Node id

Direct uploadingMuling

Figure 25: The Green. Delivery delay.

Figure 25 presents the latency of the direct uploadingand muling. We measure the latency as the time differ-ence from the time the sensor data packet is generatedto the time the packet is uploaded to a SAP either by theoriginator of the packet or by a mule. The result clearlyshows the benefit of muling. The sensor readings frombike three and four were muled by the motes on bike oneand two which entered within radio range of the SAPearlier than bike three and four. As a result, the sensorreadings from bike three and four gets less latency withmuling than direct uploading. Especially, bike four getson average 1500 seconds less latency with muling thandirect uploading. If we assume one of the bikes neverwent within the radio range of the SAP, the benefit is notonly the improvement in latency but the enabling of thedata acquisition form the bike.

The muling comes with cost. The cost of muling isthat it requires transmission from the origin of the senseddata to a mule, and then from the mule to a SAP. Fig-

0

20

40

60

80

100

0 5 10 15 20 25 30 35 40

Effi

cien

cy (

%)

Node id

direct uploadingmuling

Figure 26: The Green. Delivery efficiency.

ure 26 illustrates the transfer efficiency for both mulingand direct uploading as a function of the packets trans-ferred. Here we define efficiency as the ratio of databytes transferred to the total bytes sent (including datapacket replications and retransmissions). A higher effi-ciency for a given transferred packet reflects a more sta-ble, less congested connection between sender and re-ceiver. The sensed data origin always stores a copy inits local Flash hoping to upload the data to a SAP. It alsocan transfer a copy of the data to another mobile sensorvia the muling protocol. In our experiments, the mul-ing replication degree is one; we do not allow multi-hopmuling. Figure 26 shows that the muling efficiency isless than uploading efficiency as expected. While the up-loading efficiency ranges from 40% to 68%, the mulingefficiency ranges from 12% to 33%. The difference be-tween the muling efficiency and the uploading efficiencyrepresents the cost for improving latency and enablingdata acquisition from the bikes that rarely enter withinthe radio range of a SAP. We are currently studying theeffect of replication degree on performance; we expectto see that more replication leads to improved deliverydelay performance, but also lower efficiency.

4.4 Dartmouth BikeNet TestbedWe built five sensor bikes and implemented a small-

scale BikeNet testbed with seven static SAPs at a num-ber of points across the Dartmouth College campus andin the town of Hanover, as a means to validate and evalu-ate an operational BikeNet system. The system was ini-tially built and debugged in the summer 2006 and is nowoperational [5]. In what follows, we present results fromdata collected by a group of three cyclists on the morningof November 20, 2006. We have collected a significantamount of data from over 50 different BikeNet exper-iments starting in summer 2006 but here only presentdata from a single-shot experiment with the three cy-clists. The three cyclists routes and the times they startedtheir rides is pre-planned. Cyclists 1 and 2 live near eachother and ride much of the way toward Dartmouth Cam-pus from the town together. Before getting to the cam-pus they rendezvous with cyclist 3 before cyclists 1 and

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

1

0 500 1000 1500 2000

Pro

port

ion

of D

ata

Del

iver

y

Time (seconds)

AB

C

directsap augmented

muling agumented

Figure 27: Rider Centric Delivery

0

0.2

0.4

0.6

0.8

1

0 500 1000 1500 2000 2500

Pro

port

ion

of D

ata

Del

iver

y

Time (seconds)

A

BC

cyclist 1cyclist 2cyclist 3

Figure 28: BAN direct Delivery

0

0.2

0.4

0.6

0.8

1

0 500 1000 1500 2000 2500

Pro

port

ion

of D

ata

Del

iver

y

Time (seconds)

A

B1 SAP2 SAP3 SAP4 SAP5 SAP

Figure 29: Multi-SAP Delivery

3 depart toward the library while cyclist 2 heads to theComputer Science building. The longest journey timefor a cyclist is 40 minutes. The results presented in thissection provide insights into how live sensor data col-lected by each of the bikes is either muled or directlyuploaded to a passing SAP, in an opportunistic manner.

We first consider the time taken for each cyclist to up-

load its data into the backend data repository via directupload to a SAP and present the results in Figure 28.Note that in this case the data uploaded to a SAP by acyclist includes its own sensor data and any data muledby it. Figure 28 shows the “proportional data delivery”over the journey time. We define proportional data deliv-ery as the amount of data received by the backend as thejourney proceeds (e.g., at 520 seconds into the experi-ment cyclist 2 has delivered 40% of its data includingany data it may mule on behalf of cyclists 1 and 3). Fromthe plot we can observe that there is a noticeable periodof time before any data is actually delivered. This is dueto the lack of SAPs along the route from the homes ofcyclists 1, 2 and 3. Cyclists 1 and 2 recounter a SAPalong Main Street in Hanover at approximately 520 sec-onds into their ride. Even though only a modest numberof SAPs are deployed we can see from the plot that allbikes are capable of delivering sizable portions of theircollected data before their journeys end. For example,cyclists 1 and 2 deliver approximately 50 % and 40 %of their data to the backend depository before the halfway stage of the route, respectively. From the plot weobserve that data is delivered between bikes and SAPsin a quick burst of data transfer. As discussed beforethe amount of data transfered in strongly influenced bythe short contact times which are a product of the short-range radios used by the BikeNet experiment.

Figure 27 shows the delivery of sensor data that isgenerated by a single cyclist only - in this case cyclist1. We consider three scenarios of possible transfer be-tween cyclist 1 and the data depository:direct, which iswhere cyclist 1 keeps all its data and does not mule andonly uploads it at the final destination SAP in the Com-puter Science building;SAP augmented, which is wherecyclist 1 opportunistically transfers data to SAPs it en-counters along the way but also in this scenario no mul-ing of cyclist 1’s data occurs; and finally,muling aug-mented, which exploits muling and opportunistic use ofSAP to transfer cyclist 1’s data to the depository. Fig-ure 27 shows the performance of these three types ofcommunication. From the plot we can observe directbenefits of muling: cyclist 1 is disconnected for approx-imately 15 minutes between points A and C as shownon the plot but if we look at the “proportion of data de-livery” at the intermediate point B we can observe thatcyclist 1’s delivery performance increases at point B yetit is disconnected. This shows the benefit of muling.

Next, we evaluate the impact of SAP availability(which are opportunistically encountered en-route) onthe data delivery latency of the sensed data from thethree cyclists to the backend data repository. In this ex-periment, we consider the incremental increase in avail-able SAPs (i.e., from one SAP to a maximum of fiveSAPs) that are encountered by the three cyclists. By in-crementally making available SAPs we study the “pro-portion of data delivery against time for five independentruns of the three cyclists from their respective homes tothe Computer Science department. Figure 29 shows theresults for a truncated time series up to the point when

100% of data is delivered by all cyclists for the case of5 SAPs; the plot shows that when the complete data de-livery for five SAPs occurs only 78% and 70% of data isdelivered to the backend for the cases of three SAPs andone SAP, respectively.

Figure 29 shows that when the cyclists return to theComputer Science building they become stationary andupload their remaining data, which, is denoted by steepstep in the curve at point B representing a large de-livery of the final data from the bicycle to the SAP. Incontrast, the flat portions of the curves, e.g., denoted bypoint A, represent a period when cyclists 2 and 3 aredisconnected from the network with no other BikeNetnodes acting as mule data.

From the plot, we can also observe that the additionof a new SAP does not always result in a similar incre-mental improvement in the data delivery performance;for example, it is clear when inspecting the plot that thedifference in the incremental improvement in the “pro-portion of data delivery for each of the curves in non-uniform. The performance increase of adding SAPs ishighly dependent on many factors including the density,location of SAP in relation to routes traveled and the mo-bility of cyclists.

5 Related WorkMobile sensing systems have been proposed in prior

application contexts. Zebranet [1] was one of the firstof these types of systems and was deployed to monitorZebra populations in their natural environment. Morerecently the Cartel project [3] from MIT has deployeda mobile sensing platform based on exploiting cars andopen wi-fi access points in a city. SATIRE [2] presentswork more directly focused on people centric applica-tions by proposing an general software architecture forsmart clothing.

Hobbyists have assembled elaborate sensor-laden bi-cycles for fun, the earliest and most elaborate being theWinnebiko [22] which had multiple embedded and lap-top computers, several VHF and UHF radio modem net-work links, and a variety of onboard sensors includingGPS, security system, video camera, altimeter, batterymonitors, and more. Like the current commercial sen-sor systems for bicycles mentioned in the introduction,the wireless communication in these systems is eitherstrictly local to the bicycle or provides a link to the in-ternet. None of these systems have explored bike-to-bikeor person-to-bike communications.

Wireless sensors have long been used in sports tomonitor performance, for example in training for theOlympics. The UWEN project [23] and the SesameConsortium [24] are bringing new technologies such asUWB localization and advanced sensing, combined withimproved biomechanical models of the human body, intoplay. Wireless sensors are also starting to be used toenforce the rules of contest in the martial arts [25] andother sports contests. These systems focus on the indi-vidual and are not used to network data between individ-uals.

There is much interest in monitoring first respondersat the scene of an emergency using wireless sensors toalleviate some of the difficulties in their working envi-ronment [26]. These systems include peer-to-peer shar-ing of data so that, for example, a medic can follow aSWAT team into action while monitoring their lifesigns.They tend to be intolerant of delay and require high relia-bility, accuracy, and connectedness which comes at highcost.

The BikeNet “rock” has some similarities to collabo-rative augmented reality markup of which Websigns [27]is an example. However BikeNet’s augmentation is vialocally sensed and shared information rather than humanauthored markup.

The Wearable Computing and Personal Area Net-working (PAN) fields have produced numerous exam-ples [28], [29], [30], [31] of wireless networks that oper-ate on and near the human body and which interact withthe wearers surroundings or other peoples PAN’s. Therehas also been much work in delay tolerant network-ing [32], [33], [34] to improve data transfer in networksthat are often disconnected (as BikeNet is). BikeNet isa synthesis of all these ideas, using opportunistic ren-dezvouz of human wearable PAN’s and bicycle PAN’s(both human-to-bike and bike-to-bike) to add new di-mensions to the bicycling experience.

6 ConclusionIn this paper we have presented detailed design, im-

plementation and evaluation of the BikeNet mobile sens-ing system. BikeNet is a first experimental testbed forexploring the opportunistic sensor networking principlesand techniques of the MetroSense people-centric sens-ing architecture. Our initial results are encouraging anddemonstrate some of the value that ubiquitous wirelesssensor networks can bring to our lives. We plan to fur-ther expand BikeNet to more deeply investigate the shar-ing and opportunistic aspects of personal sensing, andalso the effects of radio propagation dynamics causedby mobility and interaction with the human body. Wewill also be exploring the value that BikeNet can bringto a community as a platform for large scale sensing andscalable muling of sensor data. While our current ex-periments have concentrated on sensing for the cyclist,bicycle mounted sensors could also serve a community,using mobility for spatial coverage in urban areas.

AcknowledgmentThe work is funded by the Institute for Security Tech-

nology Studies (ISTS), Dartmouth College, Intel Corp.,and Nokia. The authors thank X. Zheng and H. Lu fortheir help with data collection.

7 References[1] T. Liu, C. Sadler, P. Zhang, M. Martonosi. Imple-

menting software on resource-constrained mobilesensors: experiences with Impala and ZebraNet.In Proc. of MobiSys ’04, pages 259–269, Boston,MA, USA, 2004.

[2] R. Ganti, P. Jayachandran, T. Abdelzaher,J. Stankovic. SATIRE: a software architecture forsmart AtTIRE. InProc. of MobiSys ’06, pages110–123, Uppsala, Sweden, 2006.

[3] B. Hull, V. Bychkovsky, Y. Zhang, K. Chen,M. Goraczko, A. Miu, E. Shih, H. Balakrishnan,and S. Madden. CarTel: A Distributed Mobile Sen-sor Computing System. InProc. of 4th Int’l Conf.on Embedded Networked Sensor Systems, pp.125–138, Boulder, Nov 1-3, 2006.

[4] CRAWDAD: A Community Resource for Archiv-ing Wireless Data At Dartmouth. http://crawdad.cs.dartmouth.edu/.

[5] BikeNet Web Portal.http://www.bikenet.cs.dartmouth.edu/. username: Emiliano, password:bikes

[6] K. Fall. A delay tolerant network architecture forchallenged internets. InProc. ACM SIGCOMM,pages 27–34, Karlsruhe, Germany, Aug. 2003.

[7] The Bio Mapping Tool. http://www.biomapping.net/.

[8] Beating Heart Blog. http://turbulence.org/Works/beatingheart/blog/.

[9] Nike + iPod. http://www.apple.com/ipod/nike/.

[10] Carmichael Training Systems. http://www.trainright.com/folders.asp?action=display&uid=2348.

[11] CicloSport HAC5. http://www.ciclosportusa.com/hac.html.

[12] A. T. Campbell, S. B. Eisenman, N. D. Lane,E. Miluzzo, and R. A. Peterson. People-CentricUrban Sensing. InProc. of the 2nd Annual Int’lWireless Internet Conf., Boston, Aug 2-5 2006.

[13] VeloTrend BikeBrain system. http://www.bikebrain.com/.

[14] R. Grisso, R. Oderwald, M. Alley, and C. Heat-wole. Precision Farming Tools: Global Position-ing System (GPS). Virginia Cooperative Exten-sion, Publication 442-503, 2003.

[15] Moteiv Tmote Invent and TinyOS Boomerangpackage.http://www.moteiv.com/.

[16] ChipCon CC2420 Radio.http://www.chipcon.com/.

[17] Garmin Emap, Garmin International, Inc.http://www.garmin.com/products/emap/.

[18] Garmin Edge 305, Garmin International, Inc.http://www.garmin.com/products/edge305/.

[19] P. Levis, D. Gay, and D. Culler. Active SensorNetworks. In Proc. of 2nd USENIX/ACM Symp.on Networked System Design and Implementation,2005.

[20] Adventure Planner, Trimble Outdoors.http://www.trimbleoutdoors.com/biking.aspx.

[21] TinyOS.http://www.tinyos.net/.[22] Steven Roberts N4RVE. The winnebiko 1,

winnebiko 2, and behemoth expeditions (1983-1991), and microship (1992-2002) expeditions.http://microship.com/index.html, 1983.

[23] I. Oppermann, L. Stoica, A. Rabbachin, Z. Shelby,and J. Haapola. Uwb wireless sensor networks:Uwen - a practical example.IEEE Communica-tions Magazine, pages S27–S32, 2004.

[24] Stephen Hailes, George Coulouris, Andy Hopper,Alan Wilson, David Kerwin, Joan Lasenby, andDipak Kalra. Sesame consortium. Inhttp://www.sesame.ucl.ac.uk/index.html, Started April,2006.

[25] Ed H. Chi, Jin Song, and Greg Corbin. ’killerapp’ of wearable computing: Wireless force sens-ing body protectors for martial arts.In Proc. of17th Annual ACM Symposium on User InterfaceSoftware and Technology, pages 277–285, 2005.

[26] David Malan, Thaddeus Fulford-Jones, MattWelsh, and Steve Moulton. Codeblue: An ad hocsensor network infrastructure for emergency medi-cal care.International Workshop on Wearable andImplantable Body Sensor Networks, 2004.

[27] Salil Pradhan, Cyril Brignone, Jun-Hong Cui, AlanMcReynolds, and Mark T. Smith. Websigns: Hy-perlinking physical locations to the web.Com-puter, 34(8):42–48, 2001.

[28] Mark Feldmeier and Joseph A. Paradiso. Give-away wireless sensors for large-group interaction.In CHI ’04: CHI ’04 extended abstracts on Humanfactors in computing systems, pages 1291–1292,New York, NY, USA, 2004. ACM Press.

[29] Rich DeVaul, Michael Sung, Jonathan Gips, andAlex ”Sandy” Pentland. Mithril 2003: Applica-tions and architecture.ISWC ’03: Proceedings ofthe 7th IEEE International Symposium on Wear-able Computers, 2003.

[30] Thomas Zimmerman. Personal area networks:Near-field intrabody communication.IBM SystemsJournal, 35(No. 3,4), 1996.

[31] B. Gyselinckx, C. Van Hoof, J. Ryckaert, R.F.Yazicioglu, P. Fiorini, and V. Leonov. Human++:autonomous wireless sensors for body area net-works. InCustom Integrated Circuits Conference,2005. Proceedings of the IEEE 2005, pages 13–19,2005.

[32] J. Scott, P. Hui, J. Crowcroft, and C. Diot. Haggle:A networking architecture designed around mobileusers.IFIP WONS, 2006.

[33] A. Kansal, A. A. Somasundara, D. D. Jea, M. B.Srivastava, and D. Estrin. Intelligent fluid in-frastructure for embedded networks. InProc. ofMobiSys ’04, pages 111–124, Boston, MA, USA,2004.

[34] Y. Wang and H. Wu. Dft-msn: The delay fault tol-erant mobile sensor network for pervasive informa-tion gathering. InProc. of INFOCOM 2006, April23-29, Barcelona, Spain, 2006.

[35] San Diego Wind Tunnel Testing.http://www.multisports.com/windtunnel camp.shtml.

[36] Nokia N80 Mobile Device.http://www.nokia.com/nseries/index.html.

[37] Lance Armstrong cycling cadence. http://en.wikipedia.org/wiki/Lance Armstrong#Riding style.