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
