Actually, the response says (added the missing timestamp parameter) protocolInfo: [ 'version': '1.0', 'messageType' : 'AVAIL_SPECTRUM_RESP'] timestamp: '1971-01-01T14:00:00' responseInfo: [ big blob-o-stuff ] deviceId: [me! Hey, thats me!] spectumSchedue: [ 'eventTime' : '1971-01-01T14:22:19Z', 'bandwidth': '10000', 'frequencyRange': '14420000' …]
There's a timestamp for the response, so it can be used as reference for the times in the Schedule. The device can choose to do either: - Notice that the event start time is 22 minutes after the response timestamp, so decide to turn on 22 minutes later - Decide to trust the DB's clock and update its own internal clock to match, then use the absolute event time values. On Wed, Feb 13, 2013 at 7:15 AM, Warren Kumari <[email protected]> wrote: > > On Feb 12, 2013, at 12:24 PM, Vincent Chen <[email protected]> wrote: > > > Chris, > > > > Good suggestion. In the JSON encoding of AVAIL_SPECTRUM_RESP (6.4.2) and > AVAIL_SPECTRUM_BATCH_RESP (6.5.2), there is a "timestamp" field that is the > "Generated time". > > > > Looks like I forgot to add them to the data models in Section 4. > > > > The intent of this field is, indeed, for the device to determine any > clock skew. > > Great! But I'm a little confused as to what I, as a poor little device > actually *does* with this information… > > I wake up one morning and look at my clock. it is now 9:34AM on Feb 13th, > 2013… > Being a good and diligent little radio I contact the WSDB and ask if I can > pretty please have some spectrum. > > I get back a response that says: > protocolInfo: [ 'version': '1.0', 'messageType' : 'AVAIL_SPECTRUM_RESP'] > responseInfo: [ big blob-o-stuff ] > deviceId: [me! Hey, thats me!] > spectumSchedue: [ 'eventTime' : '1971-01-01T14:22:19Z', 'bandwidth': > '10000', 'frequencyRange': '14420000' …] > > What do I do? > Do I assume that the WSDB must know what time it is better than me and > adjust my clock? > Do I say "Hang on a tick, thats in the past, can't be right, I'll just > assume his clock is 42 years, 1 month, 12 days off and automagically add > that to all times from him…"? > Do I only allow offsets of X minutes and Y seconds? > Do I care if the messages are coming to my from the future (instead of the > past)? > Nasal Demons? > > > So, lets assume we have a "This allocation is for now" concept. What do I > do if the allocation starts "now", but ends yesterday? > Hmmm... Maybe absolute times are not the answer -- so, what if we just > make allocations be: start "now", end in "now"+8h. > > This looks potentially much simpler, but what happens if a messages is > somehow delayed for a long time… Still seems better, but…. > > W > > > > > > I will add the field to the next draft. > > > > -vince > > > > > > On Tue, Feb 12, 2013 at 9:09 AM, Chris Lowe <[email protected]> wrote: > > We have recently come across a problem with a similar system to PAWS, > where a small amount of clock drift between the WSD and the WSDB affects > the validity of channel allocations. In some cases the problem causes the > WSDBs to be repeatedly queried. > > > > > > > > WSDBs might return allocations which have a start time set to the WSDB’s > current time, i.e. starting immediately. Start times on allocations are a > good thing, since a device can receive a frequency plan for the a > significant duration without hitting the servers. > > > > > > > > But if the device’s internal clock is running behind the WSDB’s clock, > there is a potential problem: the WSDB is likely to serve up allocations > which, from the device’s point of view, are in the future. If the > discrepancy is small, then the device might sensibly remain silent until > its clock has caught up with the SpectrumSchedule’s start time. Or more > pathologically, the device might query the WSDB repeatedly in the hope of a > better allocation, each time receiving allocations that seem to always be > in the future. We have seen this phenomenon in the wild. > > > > > > > > A possible solution to this problem would be to somehow indicate that > the allocation is for ‘now’. > > > > > > > > This could be handled with a ‘Generated’ timestamp on the > AVAIL_SPECTRUM_RESP. In this way, the device can deduce that the WSDB’s > clock disagrees with the its own clock, and can see that a SpectrumSchedule > is valid with immediate effect. The device could use the clock discrepancy > as a trigger to adjust its internal clock, perhaps using NTP. > > > > > > > > Another possible change: any SpectrumSchedules that start with immediate > effect should be reported as “valid immediately” by a new flag in the > EventTime structure. > > > > > > > > Would it make sense to alter the PAWS spec in light of this problem? > > > > > > > > Cheers, > > > > > > > > Chris Lowe. > > > > > > > > -- > > > > Chris Lowe > > > > Neul Ltd. > > > > Suite 42 Innovation Centre, Unit 23 Science Park, Milton Road, > Cambridge, CB4 0EY, UK > > > > http://www.neul.com > > > > Tel: 01223 437022 > > > > > > > > > > _______________________________________________ > > paws mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/paws > > > > > > > > > > -- > > -vince > > _______________________________________________ > > paws mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/paws > > -- > Consider orang-utans. > In all the worlds graced by their presence, it is suspected that they can > talk but choose not to do so in case humans put them to work, possibly in > the television industry. In fact they can talk. It's just that they talk in > Orang-utan. Humans are only capable of listening in Bewilderment. > -- Terry Practhett > > > -- -vince
_______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
