Op 19 jan. 2012, om 15:25 heeft <[email protected]> het volgende geschreven:
> We have a related use case in the document: > > 4.7. Rapid deployed network for emergency scenario > > Organizations involved in handling emergency operations often have a > fully owned and controlled infrastructure, with dedicated spectrum, > for day to day operation. However, lessons learned from recent > disasters show such infrastructures are often highly affected by the > disaster itself. To set up a replacement quickly, there is a need > for fast reallocation of spectrum, where in certain cases spectrum > can be freed for disaster relief. To utilize free or freed spectrum > quickly and reliable, automation of allocation, assignment and > configuration is needed. A preferred option is make use of a robust > protocol, already adopted by radio manufacturers. This approach does > in no way imply such organizations for disaster relief must compete > on spectrum allocation with other white spaces users, but they can. > A typical network topology would include wireless access links to the > public Internet or private network, wireless ad hoc network radios > working independent of a fixed infrastructure and satellite links for > backup where lack of coverage, overload or outage of wireless access > links occur. > > So it seems we'll need a requirement to free spectrum on a short notice. From > the above use case my reading is that 'short' is close to instantaneous. Related to timescales for current frequency allocation (in years), yes, it is instantaneous. I recommend we leave out-of-scope how & why spectrum is reallocated. A question is: if spectrum is freed, how to inform PAWS master nodes, to get it. In this use case, there is a dedicated channel and applications would make use of it to receive triggers. Triggers could be SNMP. Maybe we work on MIBs some day, and simply define a trigger. Teco > > - Gabor > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of ext > Rosen, Brian > Sent: Thursday, January 19, 2012 6:09 AM > To: Peter Stanforth > Cc: [email protected] > Subject: Re: [paws] next steps for the wg > > 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 > _______________________________________________ > paws mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
