Hi all, It turns out that somehow I left Silvana's email address off "To" list of my summary if the conference call with the ROLL chairs.
Since this might interest others, I am copying the contents below. Y(J)S Call between Yaakov and David - 28 Jan 2009 (JP out of office, Stewart couldn't make the call). The point of the call was to try to fill in the tables needed for the section on sensor networks in the TICTOC requirements document. David started by emphasizing the main constraint of all sensor network applications, namely the low power consumption requirement. This constraint is so over-riding that it defines the problem. For the timing questions it means that the crystal is the only active element that stays powered up over time, everything else is usually sleeping and only wakes up for critical functions. In particular, the time between timing updates (whether NTP or otherwise) is always going to be relatively long. Similarly, it is also a good strategy to piggyback time information on routing advertisements that are being sent in any case. With that in mind, there are several different applications for sensor networks, each with distinctive features. A basic application is lowrate monitoring, e.g., automated metering, reading of thermostats for climate monitoring, etc. Here the sensors send a timestamped data reading, and thus need to have their local clocks automatically calibrated by an NTP-like mechanism about once every 10 - 20 minutes. Typical transaction rates are once per 5 minutes (once per minute is considered very fast, once per 15 minutes relatively slow). Thus the update rate for this application is in the range of one per 100-1000 sec, i.e. the sampling rate is 1 - 10 milliHertz. The required time of day accuracy is on the order ot 1 sec (or possibly a few seconds) i.e. about 1 part per hundred. Since the data is sent with a timestamp, we can accomodate several seconds of "jitter| on the transaction times, but this jitter must not accumulate to more than a few seconds. YJS - note that since the sampling is done once per 100-1000 seconds, the dividing line between jitter and wander is at a frequency of one in 100-1000 seconds, and not the 10 per second conventionally used in telecom applications. There is a holdover requirement since the data may only collected once a day, and the application should be able to sustain 1 day to 10 days without more than 1-2% wander. Wander can be considered over a year integration period, and percentile is a useful mechanism. The local oscillator crystal is a $1 - $2 item (which is a significant percentage of the BOM) with 15ppm accuracy. The sensors must be plug-and-play. Link-level AES-128 is a common security mechanism - note that even if the data is correct, having incorrect timestamp can be bad - e.g. forcing the collector to believe that a temperature reading is from last night instead of this afternoon. The expected network characteristics are specific to wireless sensor networks - a typical number of hops between the sensor to the collector is 15, but can even be up to 75 hops. A second application is acceleration sensors distributed in a structure, e.g. a building or bridge. The point of this is to measure the amount of energy in the various vibrational modes, by collecting temporal-spatial data. This can help detect material fatigue, predict failures in machinery, etc. The sensors are placed at various known positions in the structure, and the inaccuracies in positioning are yet another source of error. Update rates are 100 Hz - 1KHz instead of the milliHertz of the previous application. For this application, determining the power spectrum is not enough, since we need to separate the 3D modes of vibration, and 1 - 2% accuracies are about right. In this application one is allowed to work hard at calibrating at the beginning and end of the run, and temperature data may be available for the duration of the run to help predict crystal drift. The accuracy is driven by family of error terms including jitter, A/D noise, accelerometer transducer noise, lack of knowledge of physical position, etc. In this application the plug-and-play and security aspects are less important, and the cost is less constrained (e.g., can use more expensive crystals). Two more applications are: timing for the communication infrastructure itself - i.e. the timing needed to maintain routes and power efficiency (wake up) remote monitoring (tanks) - here the data is sent back once per day or even once per week. These will be discussed in another call.
_______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
