What Brian and I were saying is that we need a mechanism to deal with changes to spectrum availability and that push is only one option. I like the description Brian gave: "At this stage, we should say that we have a requirement to change availability of spectrum on a short notice"
On FriJan/20/12 Fri Jan 20, 12:59 PM, "[email protected]" <[email protected]> wrote: > >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 _______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
