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 _______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
