|Thread Links||Date Links|
|Thread Prev||Thread Next||Thread Index||Date Prev||Date Next||Date Index|
This 30 secodn limit had a serious problem. FCC regulations state that when a licensed microphone enters the scene, license-exemplt devices are to vacate the channel within 2 seconds. So, this means that a coexistence scenario can and must be changeable within 2 seconds. Now, it is unreasoable to have the coexistence scenraio revisited that often. I am not oging to tell you what to do here, but the solution 802.22 has taken is to pre-calculate what needs to be done if the current operating channel for and AP or BS becomes unserviceable. That way, if such an "urgent" situation arises, all devices know exactly what has to be done and can implement it. Then you can re-calculate the next "what if" situation if a channel again becomes unserviceable. This was deemed required so a network (BS or AP) would not be ofrced to "go off the air" until a new coexitence scenario is agreed upon. This was the only acceptable way that was fouind to work so fast as to comply to FCC this requirement without having a continuous magamenet traffic. Ther may be others. As for the limit above, I would also put that one should not make requests to adjoining entities unless there is a compelling reason to do so, like a situation change. On the other hand, I would rather see a system where one would only make requests upon power up and have a system based on event and announcements rather than on "polling" to see if there are changes. That would reduce traffic to a bare minimum. I would then think that the "once every 30 seconds" should go away and be replaced by "upon ??? event and no more than once every second" (yeah, we need it to be allowed down to once every second to be able to react to a spectrum availabiliy chage within 2 seconds) (We also want to limit the number of requests so that if there are 10 changes in a second, you want to limit the number of requests n that case too)
Just my 2 cents worth...