Thanks for the clarification Andy. I agree that the feature could be optional.
-Raj On 1/18/12 11:22 AM, "ext [email protected]" <[email protected]> wrote: >A clarification with regard to the need for push notifications. I am not >aware that this is an Ofcom requirement. In their last consultation >Ofcom's description of a master device says that it must "cease >transmission immediately where the time validity expires or where it >moves outside of the geographic area of validity". The master polls every >x hours (e.g. every two hours), using a periodicity set by regulation, in >order to maintain validity for the TVWS channel it is using, and does not >need to be able to receive pushed information. This works because any >changes to channel availability (due to a local news event requiring >wireless microphones for example) have a lead time, which give the >opportunity for the channel to be cleared. Microphones needing to be >operational more quickly than x hours could be operated in other spectrum >(for example). The same process would enable a network to be turned off >within x hours if Ofcom so desired. > >Having said that, I am in favour of there being a push capability from >the database to masters. I just think it would not be implemented by all >masters if not required the regulator, so would be optional. > >Regards > >Andy > >-----Original Message----- >From: [email protected] [mailto:[email protected]] On Behalf Of >[email protected] >Sent: 18 January 2012 16:51 >To: [email protected] >Cc: [email protected] >Subject: Re: [paws] next steps for the wg > > >An example: >A white space database may decide to withdraw channels that were >previously indicated as being available for use to a set of master >devices (reason being a need for those channels by some emergency >service). >Devices register with the database as part of the initial >authentication/authorization process and hence the database would have >the capability of sending such messages only to the relevant devices and >not to all devices. >It does result in state being maintained at the database. > >The requirement for such capability is needed by Ofcom (AFAIK) and hence >the proposal. > >Solutions will need to consider how to deal with this optimally. > >-Raj > >On 1/18/12 10:43 AM, "ext Joel M. Halpern" <[email protected]> wrote: > >>Sorry to be slow. >>How does the database know which changes are of interest to any >>particular registered client? I would hope that it does not push all >>changes to all clients. But i not, it needs to somehow guess which >>changes matter. Would it keep track of what answers it has sent to >>each such registered clients, and try to track which changes may affect >>actions of that client? >> >>Yours, >>Joel >> >>On 1/18/2012 11:38 AM, [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
