At this stage, we should say that we have a requirement to change availability of spectrum on a short notice, we need a use case that would motivate some decision on what "short" means, and we should not worry about which mechanism we should choose to achieve it.
Push, fast poll, and notice broadcast (i.e. a single bit sent to all clients telling them to "phone home" soon) are all reasonable mechanisms to meet the requirements. Brian On Jan 19, 2012, at 8:40 AM, Peter Stanforth wrote: > I would like to suggest that we back up and ask the question. How do we > pre-empt a device if the primary spectrum user needs it back? The use case > I can think of is public safety, where they don't generally need the > spectrum until there is an emergency. They do not know when or where that > will happen so they would need a mechanism to clear the spectrum in a > specific location quickly. > A push mechanisms only one way to do this. Another, off the top of my head > is to only give channel permissions for time durations less than the time > they need to clear the channels. There may be other options and there are > clearly advantages and disadvantages to all. > Peter S. > > On WedJan/18/12 Wed Jan 18, 11:38 AM, "[email protected]" > <[email protected]> wrote: > >> >> Hi Joel, >> >> The proposal to include unsolicited Push notifications from the white >> space database to a master device is different from the Request/Response >> mechanism itself. >> A master device making a request for available channels expects a response >> in some time window. Not proposing we change that. >> However the white space database knows of devices which have registered >> with it. And hence can send push notifications at will without necessarily >> having to react to a request. >> >> -Raj >> >> On 1/17/12 8:03 PM, "ext Joel M. Halpern" <[email protected]> wrote: >> >>> While responses have time windows, as far as I know, requests do not >>> specify when the response will be acted upon, if ever, or for how long. >>> >>> As such, this seems to imply either that we add significantly more >>> information to requests, or that any change in anything that has ever >>> been asked for gets pushed? >>> That does not sound like a good design. >>> >>> Yours, >>> Joel >>> >>> On 1/17/2012 6:08 PM, [email protected] wrote: >>>> >>>> Hi Gabor, >>>> >>>> On 1/12/12 8:26 PM, "ext [email protected]"<[email protected]> >>>> wrote: >>>> >>>>> P.3 currently says: The protocol between the master device and the WS >>>>> Database MUST support pushing updates in channel availability >>>>> changes >>>>> to subjects. >>>>> There were comments that this requirement involves a mechanism, we >>>>> should >>>>> reformulate to be mechanism agnostic. >>>>> There was a suggestion to "make the requirement "quick way to change >>>>> availability" rather than imply a mechanism.". >>>>> The use case is that if the channel availability changes in the DB, >>>>> the >>>>> client has to be able to detect it and get the new availability list >>>>> within a time period set by the regulator. >>>>> Can someone send suggested text on how to reformulate this >>>>> requirement? >>>> >>>> The requirement to enable Push notifications to be sent to a white >>>> space >>>> device which has registered with a database is important especially in >>>> the >>>> context of Ofcom requirements (I believe). The reasons for such push >>>> notifications could be for purposes that go beyond just channel >>>> availability updates. A proposal for the requirement is as follows: >>>> >>>> Requirement: A white space database should be able to send unsolicited >>>> messages to a master device which has registered with it. The protocol >>>> between the WS database and master device MUST allow for push >>>> notifications to be sent from the database to the master device. >>>> >>>> -Raj >>>> >>>> _______________________________________________ >>>> paws mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/paws >>>> >> >> _______________________________________________ >> paws mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/paws > > _______________________________________________ > paws mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
