Subject: Re: [paws] P.3 Requirement (was: next steps for the wg)

From: <[email-masked]>
Date: Thu, 19 Jan 2012 14:25:26 +0000

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.

- Gabor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Rosen, Brian
Sent: Thursday, January 19, 2012 6:09 AM
To: Peter Stanforth
Cc: [email-masked]
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-masked]"
> <[email-masked]> 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-masked]> 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-masked] wrote:
>>>> 
>>>> Hi Gabor,
>>>> 
>>>> On 1/12/12 8:26 PM, "ext 
>>>> [email-masked]"<[email-masked]>
>>>> 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-masked]
>>>> https://www.ietf.org/mailman/listinfo/paws
>>>> 
>> 
>> _______________________________________________
>> paws mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/paws
> 
> _______________________________________________
> paws mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/paws

_______________________________________________
paws mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/paws

---

From: Teco Boot <[email-masked]>
Date: Thu, 19 Jan 2012 17:10:42 +0100

> 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

---

From: Rex Buddenberg <[email-masked]>
Date: Thu, 19 Jan 2012 11:26:52 -0800

I think you've disposed of the issue adequately.  The use case covers.

But ... the kind of disaster that requires emergency services to need
more spectrum fall into two categories:

	- forecast events like heavy weather.  We have hours-days of reaction
time.  
	- unforecastable events like earthquakes or airplanes flying into
buildings.  Here the reaction time window is in minutes.

Out of PAWS-scope comments.  Capacity is usually not the critical
commodity for emergency services.  The two most important issues are
	- availability and survivability.  (Whether or not the comms is
internet comms or not).  If the comms is internet comms (labeled
'broadband' over in the emergency services discussions), then breakage
of terrestrial-WAN trunks will force traffic into the radio-WANs.  In
unforecast events, this traffic shift will happen very quickly (routers
responding to outages by pushing traffic to surviving, but higher-cost
routes).
	- geographic coverage.  Specific to the radio-WAN part of the
problem ... and indirectly intersecting the PAWS issues.  I don't
believe many emergency services comms folks see this one coming, but
most of the radio-WAN technologies and rulesets will result in smaller
footprints (eleven high sites for all of Monterey County is an order of
magnitude too few).  This will meet the continued proliferation of the
terrestrial internet (which at least in urban/suburban areas of US) has
the necessary frequency of POPs.