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. 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
