Subject: Re: [paws] Updated use case and requirements I-D: draft-probasco-paws-overview-usecases-01.txt

From: Gerald Chouinard <[email-masked]>
Date: Tue, 12 Jul 2011 10:57:52 -0400

Scott,

Thank you for including the use case for rural area networks in the 
document.  I have reviewed it carefully and have attached a Word version of 
the document with 'track change' indicating my suggested changes as well as 
comments in square brackets.

The main points are:

- Figure 1: TV White Space will be below 700 MHz in North-America since TV 
channels 52 and above will be auctioned.
- The 802.22 WRAN standard was developed primarily for independent 
operators rather than operation under a single entity since, being 
unlicensed, one cannot plan the operation in these TV White Space for a 
single operator and competing operators can come up in an area.  The 802.22 
Standard has included all tools necessary to allow automatic 
self-coexistence through detection of other nearby networks and 
interference avoidance through dynamic spectrum allocation and TDM 
techniques (i.e., allocation of different frames to different BSs) if 
co-channel operation is needed.
- Being point-to-multipoint, 802.22 operation will be centrally controlled 
by the BS.  There is no reason for the slave/user terminal to get the 
available channel list and decide on its own on whether it can use a 
channel or not.  The list of available channels for all slave/user devices 
associated to a BS should be handled by the BS so that the BS can find the 
set of channels that intersects the lists for all its slave/user devices to 
select the right operating channel.  If the list is sent to the device, it 
does not allow the BS to change its operating channel to accommodate a new 
slave/user devices.  These lists of available channels (or the list of 
maximum EIRP) should stay at the BS.

Hope this is helpful.

Gerald

At 23:20 11-07-11 +0000, [email-masked] wrote:

>Hi,
>
>
>
>We have updated the use case and requirements I-D.  Your comments are welcome.
>
>
>
>Regards,
>
>Scott
>
>
>
>URL: 
><http://www.ietf.org/id/draft-probasco-paws-overview-usecases-01.txt>http://www.ietf.org/id/draft-probasco-paws-overview-usecases-01.txt
>
>
>
>Abstract:
>
>    Wireless spectrum is a commodity that is regulated by governments.
>
>    The spectrum is used for various purposes which include entertainment
>
>    (eg. radio and television), communication (telephony and Internet
>
>    access), military (radars etc.) and, navigation (satellite
>
>    communication, GPS).  Portions of the radio spectrum that are unused
>
>    or unoccupied at specific locations and times are defined as white
>
>    space .  TV White space refers to those unused channels, within the
>
>    range allocated for TV transmission, that can be used without
>
>    interfering with the primary purpose for which it is allocated.
>
>
>
>    This document describes examples of how a radio system might operate
>
>    using TV white space spectrum and associated requirements.  Not only
>
>    does it describe the operation of a radio system, but also how the
>
>    radio system including a white space database enables additional
>
>    services.
>
>
>_______________________________________________
>paws mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/paws

---

From: Paul Lambert <[email-masked]>
Date: Tue, 12 Jul 2011 13:31:48 -0700

Seems like we should add 802.11af to the references also ...  I suspect it will have more adoption than 802.22 and has more interesting use cases that we need to consider (like mobility, P2P, etc.)

Paul

Paul A. Lambert |  Marvell  | +1 650 787 9141

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Gerald Chouinard
> Sent: Tuesday, July 12, 2011 7:58 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [paws] Updated use case and requirements I-D: draft-
> probasco-paws-overview-usecases-01.txt
> 
> Scott,
> 
> document.  I have reviewed it carefully and have attached a Word
> version of the document with 'track change' indicating my suggested
> changes as well as comments in square brackets.
> 
> The main points are:
> 
> - Figure 1: TV White Space will be below 700 MHz in North-America since
> TV channels 52 and above will be auctioned.
> single operator and competing operators can come up in an area.  The
> 802.22 Standard has included all tools necessary to allow automatic
> - Being point-to-multipoint, 802.22 operation will be centrally
> controlled by the BS.  There is no reason for the slave/user terminal
> to get the available channel list and decide on its own on whether it
> can use a channel or not.  The list of available channels for all
> slave/user devices associated to a BS should be handled by the BS so
> that the BS can find the set of channels that intersects the lists for
> all its slave/user devices to select the right operating channel.  If
> the list is sent to the device, it does not allow the BS to change its
> operating channel to accommodate a new slave/user devices.  These lists
> of available channels (or the list of maximum EIRP) should stay at the
> BS.
> 
> Hope this is helpful.
> 
> Gerald
> 
> 
> ><http://www.ietf.org/id/draft-probasco-paws-overview-usecases-
> 01.txt>ht
> >tp://www.ietf.org/id/draft-probasco-paws-overview-usecases-01.txt
> >
> >
> >
> >Abstract:
> >

---

From: Gerald Chouinard <[email-masked]>
Date: Tue, 12 Jul 2011 16:39:44 -0400

Paul,

Is 802.112af covered by one of the use cases described in the document? If 
not, 802.11af should submit something to the IETF-PAWS to make it as 
complete as possible.

Gerald

At 13:31 12-07-11 -0700, Paul Lambert wrote:
>Seems like we should add 802.11af to the references also ...  I suspect it 
>will have more adoption than 802.22 and has more interesting use cases 
>that we need to consider (like mobility, P2P, etc.)
>
>Paul
>
>
> > ><http://www.ietf.org/id/draft-probasco-paws-overview-usecases-> 01.txt>ht

---

From: Paul Lambert <[email-masked]>
Date: Tue, 12 Jul 2011 13:47:07 -0700

Gerald,

Yes - I agree, PAWS should make sure that the use cases and requirements apply to "Wi-Fi" technologies.  They miss in a few points currently and are a little WRAN centric.

For example - master devices may not always know or care about their antenna height.  Clearly a fixed master perspective ...  

Paul

> From: Gerald Chouinard [mailto:[email-masked]]
> Sent: Tuesday, July 12, 2011 1:40 PM
> To: Paul Lambert
> Cc: [email-masked]; [email-masked]; Apurva Mody
> Subject: RE: [paws] Updated use case and requirements I-D: draft-
> > > >We have updated the use case and requirements I-D.  Your comments
> are
> > > welcome.
> > > >
> > > >
> > > >
> > > >Regards,
> > > >
> > > >Scott
> > > >
> > > >
> > > >
> > > >URL:
> > > >    space .  TV White space refers to those unused channels,
> within
> > > the
> > > >
> > > >    using TV white space spectrum and associated requirements.
> Not
> > > > only
> > > >

---

From: Gerald Chouinard <[email-masked]>
Date: Tue, 12 Jul 2011 17:11:38 -0400

Paul,

The WRAN case is documented because I provided some input to that 
effect.  You can do the same for 802.11af.  Like many other groups, PAWS 
will rely on contributions to support their work.

Gerald

At 13:47 12-07-11 -0700, Paul Lambert wrote:
>Gerald,
>
>Yes - I agree, PAWS should make sure that the use cases and requirements 
>apply to "Wi-Fi" technologies.  They miss in a few points currently and 
>are a little WRAN centric.
>
>For example - master devices may not always know or care about their 
>antenna height.  Clearly a fixed master perspective ...
>
>Paul
>
>

---

From: <[email-masked]>
Date: Tue, 12 Jul 2011 21:44:29 +0000

Are there specific use cases resulting from the radio technology being
802.11af?
Use cases that highlight specific requirements for the protocol would be
worthwhile to discuss.

-Raj

On 7/12/11 4:11 PM, "ext Gerald Chouinard" <[email-masked]> wrote:

>> > Is 802.112af covered by one of the use cases described in the
>>document?
>> > If
>> > > > >    does it describe the operation of a radio system, but also
>>how
>> > the
>> > > > >

---

From: <[email-masked]>
Date: Tue, 12 Jul 2011 21:52:31 +0000

Hi Gerald,

Thank you for the comments. In updating the draft we've tried to keep the
text 'neutral' of any specific country or radio technology. In this way we
hope to that unlicensed use of white space spectrum becomes widely used.

Indeed the frequency range of the TV band in the US is a bit lower than in
some other parts of the world -- Figure 1 is only meant to be a high-level
example, but perhaps changing the frequency axis to be lower by 100 MHz
would make sense.

I am glad to know that 802.22 supports coexistence, not all radios do. It
would be nice to see a use case for coexistence on its own. Do I
understand correctly from your text below that the BS does not pass the
full list of available channels to the slave? I get your point why
operationally this is beneficial, however I believe that in the case of
the US, the FCC rules specifically require the slave to receive a full set
of channels. My only point here is to support the concept that PAWS
remains neutral to radios and country-specific regulations.

Thanks,
Scott

On 7/12/11 9:57 AM, "ext Gerald Chouinard" <[email-masked]> wrote:

>802.22 
>controlled 
>><http://www.ietf.org/id/draft-probasco-paws-overview-usecases-01.txt>http
>>://www.ietf.org/id/draft-probasco-paws-overview-usecases-01.txt
>>
>>
>>
>>Abstract:
>>

---

From: <[email-masked]>
Date: Tue, 12 Jul 2011 21:57:01 +0000

Hi Paul,

I agree we should have a reference to 802.11af. Good comment on the use
cases, text proposals are much appreciated.

Regards,
Scott

On 7/12/11 3:31 PM, "ext Paul Lambert" <[email-masked]> wrote:

>Seems like we should add 802.11af to the references also ...  I suspect
>it will have more adoption than 802.22 and has more interesting use cases

---

From: <[email-masked]>
Date: Tue, 12 Jul 2011 22:01:31 +0000

Hi,

True some master devices may not care about their antenna height, but some
regulatory domains will require a master device to know about its antenna
height when constructing the channel list request.

Regards,
Scott

---

From: Paul Lambert <[email-masked]>
Date: Tue, 12 Jul 2011 15:07:30 -0700

The requirements currently say "MUST" .... this is not appropriate and should be changed. A mobile phone does not have an "antenna height".  This is a fixed broadcasting antenna notion (e.g per .22 WRAN)

Paul

> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, July 12, 2011 3:02 PM
> To: Paul Lambert; [email-masked]
> Cc: [email-masked]; [email-masked]
> >> > > - Figure 1: TV White Space will be below 700 MHz in North-
> America
> >> since
> >> > > unlicensed, one cannot plan the operation in these TV White
> Space
> >> for a
> >> > > techniques (i.e., allocation of different frames to different
> BSs)
> >> if
> >> > > to get the available channel list and decide on its own on
> whether
> >> it
> >> > > slave/user devices associated to a BS should be handled by the
> BS
> >> so
> >> > > that the BS can find the set of channels that intersects the
> lists
> >> for
> >> > > all its slave/user devices to select the right operating
> channel.
> >> If
> >> > > the list is sent to the device, it does not allow the BS to
> change
> >> its
> >> > > operating channel to accommodate a new slave/user devices.
> These
> >> lists
> >> > > of available channels (or the list of maximum EIRP) should stay
> at
> >> the
> >> > > BS.
> >> > >
> >> > > Hope this is helpful.
> >> > >
> >> > > Gerald
> >> > >
> >> > >
> >> > > >    communication, GPS).  Portions of the radio spectrum that
> are
> >> > > > unused
> >> > > >
> >> > > >    or unoccupied at specific locations and times are defined
> as
> >> white
> >> > > >
> >> > > >    This document describes examples of how a radio system
> might
> >> > > > operate
> >> > > >

---

From: Gerald Chouinard <[email-masked]>
Date: Tue, 12 Jul 2011 18:13:50 -0400

Paul,

I suggest you develop a use case representative of 802.11af rather than 
trying to modify the Wide Area Network WRAN use case.  These are two 
different applications and should be dealt with as such.

Gerald

At 15:07 12-07-11 -0700, Paul Lambert wrote:
>The requirements currently say "MUST" .... this is not appropriate and 
>should be changed. A mobile phone does not have an "antenna height".  This 
>is a fixed broadcasting antenna notion (e.g per .22 WRAN)
>
>
>Paul
>
>

---

From: <[email-masked]>
Date: Tue, 12 Jul 2011 22:27:59 +0000

Classification: Company Confidential

Sure, good point. I take the blame for this. 
We can change the requirement to say "A master device which is fixed, MUST include its antenna height in the query to the WS Database, if so required by the local regulations."
We may then also add definition on when is a master device considered to be fixed and when not.
Other suggestions are welcome.

-Gabor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Paul Lambert
Sent: Tuesday, July 12, 2011 3:08 PM
To: Probasco Scott (Nokia-CIC/Dallas); [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [paws] Updated use case and requirements I-D: draft-probasco-paws-overview-usecases-01.txt

Paul

> True some master devices may not care about their antenna height, but 
> some regulatory domains will require a master device to know about its 
> antenna height when constructing the channel list request.
> 
> Regards,
> Scott
> 
> 
> >> not, 802.11af should submit something to the IETF-PAWS to make it 
> >> as complete as possible.
> >>
> >> Gerald
> >>
> >>
> >> > > document.  I have reviewed it carefully and have attached a 
> >> > > Word version of the document with 'track change' indicating my
> suggested

Classification: Company Confidential

---

From: Nancy Bravin <[email-masked]>
Date: Tue, 12 Jul 2011 15:36:03 -0700

Hi Paul, 

When do you expect that 11af will be approved as a Standard? 

Thanks, Nancy

---

From: Paul Lambert <[email-masked]>
Date: Tue, 12 Jul 2011 15:39:55 -0700

> From: Gerald Chouinard [mailto:[email-masked]]
...
> trying to modify the Wide Area Network WRAN use case.  

Hi Gerald,

The requirements are NOT WRAN specific.  I am not making comments on the WRAN use case, I'm making very specific comments on the database requirements that will support many different radio types.

A very specific text proposal is attached below to make my comments clear with respect to the exact changes that need to be made (one word ... as in prior note). 

>These are two

No.  The database interface is a single protocol and MUST be the same for different use cases and radio technologies.  As such - we need to have requirements for the protocol that allow it to support devices that may have multiple modes of operation or multiple operating bands.

In this context I just noticed that the requirements are for the end devices and not the protocol ...  seems like we need to design and create requirements for PAWS and not the devices as defined by the FCC.

Paul

---------------------------------------------------------------------------
(1)Text proposal to section 4.1 requirement 1, change :----------

4.  Requirements

4.1.  Master

   1.  A master device MUST include, directly or indirectly, its antenna
       height in the query to the WS Database.

Change To: ------------- (note word change below)

4.  Requirements

4.1.  Master

   1.  A master device MAY include, directly or indirectly, its antenna
       height in the query to the WS Database.
-----------------------------------------------------------------------------
(2)Text Proposal - new requirement

The PAWS protocol MUST be able to support devices that operate in multiple bands and multiple modes of operation.
------------------------------------------------------------------------------

> > > some
> > > >apply to "Wi-Fi" technologies.  They miss in a few points
> currently
> > > and
> > > >> >will have more adoption than 802.22 and has more interesting
> use
> > > cases
> > > >> > > From: [email-masked] [mailto:[email-masked]]
> On
> > > >> Behalf Of
> > > >> > > Gerald Chouinard
> > > >> > > Thank you for including the use case for rural area networks
> in
> > > the
> Word
> > > >> > > single operator and competing operators can come up in an
> area.
> > > >> The
> > > >> > > interference avoidance through dynamic spectrum allocation
> and
> > > TDM
> > > >> > > can use a channel or not.  The list of available channels
> for
> > > all
> > > >> > > ><http://www.ietf.org/id/draft-probasco-paws-overview-
> usecases->
> > > >> 01.txt>ht
> > > >> > > >    (eg. radio and television), communication (telephony
> and
> > > >> Internet
> > > >> > > >

---

From: Paul Lambert <[email-masked]>
Date: Tue, 12 Jul 2011 16:23:34 -0700

> From: Nancy Bravin [mailto:[email-masked]]
...
> When do you expect that 11af will be approved as a Standard?

Next year I assume ..., but the basic CSMA/CD operation of Wi-Fi 
is enough to provide an interesting set of requirements.

Differences from WRAN include:
 - CSMA/CD
 - mobile Masters
 - multimode devices (Client/Master)
 - indoor masters
 - existing definition mechanisms for bands (in .11)
 - existing MAC capabilities and infrastructures for 
    security, handoff, management, etc
 - multi-band operation (e.g. TV band + 2.4 + 5 GHz in one device)
   common MAC over multiple bands,
 - larger deployments with possibility of higher densities of master devices
 - very low power devices (requirements for power conservative
   and efficient protocol)
 - possible applications in non-TV bands (e.g. radar avoidance)
 - built-in coexistence / robust signaling (CSMA/CD, MIMO, etc.)

Note also ... I don't see value in some of the use cases ... there are many words that have very little to do with what we are trying to build (a protocol to access information to enable operation of radios in specific modes of operations).  It may be interesting to invent many ways to use wireless communications ... but if it does not impact the database interface, I'm not sure why we are including the words.  

Hope this helps ....

Paul

> > Seems like we should add 802.11af to the references also ...  I
> suspect it will have more adoption than 802.22 and has more interesting
> use cases that we need to consider (like mobility, P2P, etc.)
> >
> > Paul
> >
> >