I believe we have general consensus to include a requirement for unsolicited Push notifications/messages to be sent by the white space device to the master device. Proposal for requirement in I-D:
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 On 1/20/12 11:50 AM, "ext [email protected]" <[email protected]> wrote: >Hi Andy, > >I agree with you the risk of non-delivery of pushed messages is small. > >The kill switch is one method in the protocol to clear secondary users >from specific channels at specific locations. Since Ofcom has included it >in their Implementing Geolocation document I believe this is sufficient >justification to include this feature in PAWS. > >Regards, >Scott > >On 1/19/12 6:33 PM, "ext [email protected]" <[email protected]> wrote: > >>Scott >> >>Regarding time constraints for message delivery from the database, Ofcom >>has moved away from specifying a time limit for a database to respond to >>a request, on the basis that if it is a first request then the master >>will not transmit if it fails to receive a response, and if it is a >>'revalidation' request and the master receives no response, the master >>will cease transmitting anyway when the time validity timer expires. I >>think in principle we need not specify a time limit for delivery of >>pushed information; if received, the master must act on it, but if not >>received, it will continue to transmit until its validity timer expires. >>I think that is reasonable. In practice the risk of non-delivery is tiny, >>as is the likelihood of invoking the kill switch in the first place as a >>method of solving interference issues (even in an emergency). >> >>Regards >> >>Andy >> >>-----Original Message----- >>From: [email protected] [mailto:[email protected]] On Behalf Of >>[email protected] >>Sent: 19 January 2012 19:42 >>To: [email protected] >>Subject: Re: [paws] next steps for the wg >> >>Hi All, >> >>I believe it is relevant to look at Ofcom's Implementing Geolocation >>Summary of consultation responses and next steps. Paragraph 3.42 states: >> >>> >>>Ofcom retains control over the performance of the algorithms used in >>>the databases and will update them if required to manage interference. >>>A kill switch is a useful reactive tool and we believe that it should >>>form a core part of the protocol which describes the information >>>exchange between WSDs and the database. >>> >> >>Following the notion that a kill switch should form a core part of the >>protocol, this could be included in a very basic use case like "Hotspot: >>urban internet connectivity service". I can volunteer to make this >>addition in the use case. >> >>Regarding the requirement we could say the database must be able to >>deliver updated channel information to any registered master device. We >>have not specified elsewhere any time constraints on message delivery, I >>wonder if this is needed in this case either. >> >>Kind Regards, >>Scott >> >>-----Original Message----- >>From: [email protected] [mailto:[email protected]] On Behalf Of >>ext Joel M. Halpern >>Sent: Thursday, January 19, 2012 11:12 AM >>To: Rosen, Brian >>Cc: [email protected] >>Subject: Re: [paws] next steps for the wg >> >>Thanks Brian. That works much better for me. >>Yours, >>Joel >> >>On 1/19/2012 9:08 AM, Rosen, Brian wrote: >>> 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 >>> >>_______________________________________________ >>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
