Subject: Re: [paws] combined problem statement, use cases & requirements

From: Teco Boot <[email-masked]>
Date: Fri, 2 Sep 2011 08:06:27 +0200

I think the doc is a good starting point. I support adoption.

I suggest reordering: specifying problem statement after introducing the use cases.

Some asked for the ad hoc network scenario. This includes me :-). This is important, because it demonstrates the need for "proxy".
BTW, I wonder why similar scenario doesn't pop up from WiFi deployments. Usage of controllers in large sites is not uncommon. Not to mention 11s.

The requirements is left open. I'm looking forward see some draft text.

Thanks, Teco

Op 30 aug 2011, om 19:42 heeft <[email-masked]> <[email-masked]> het volgende geschreven:

> I sent this email to the list one week ago, asking for feedback on 
> http://www.ietf.org/id/draft-probasco-paws-problem-stmt-usecases-rqmts-00.txt
> but there was not one feedback received. I take that as people have no comments to the draft at this time.
> 
> And I am asking again: is there any objection in adopting the above draft as a wg document?
> 
> -Gabor
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of ext [email-masked]
> Sent: Monday, August 22, 2011 2:43 PM
> To: [email-masked]
> Subject: Re: [paws] combined problem statement, use cases & requirements
> 
> During the Quebec session, we had presentations of the PS and the use cases drafts. The wg then decided it wants to see these drafts merged into one. Scott just did that and posted the merged draft:
> http://www.ietf.org/id/draft-probasco-paws-problem-stmt-usecases-rqmts-00.txt
> 
> Now I would like to ask if the wg feels like this document is ready to be adopted as a wg document. Please send your feedback and hum to the list by this time next week.
> 
> -Gabor
> 
> -------------------------------------------------------------------------------------------------------
> From: Probasco Scott 
> Sent: Monday, August 22, 2011 9:18 AM
> To: [email-masked]
> Subject: combined problem statement, use cases & requirements
> 
> Hi,
>  
> According to the results of the face-to-face meeting, we have combined the problem statement I-D and use case & requirement I-D into a single I-D.  Your comments are welcomed.
>  
> Regards,
> Scott
> 
> URL: http://www.ietf.org/id/draft-probasco-paws-problem-stmt-usecases-rqmts-00.txt
> 
> 
> Abstract:
>    Portions of the radio spectrum that are allocated to a licensed,
>    primary user but are unused or unoccupied at specific locations and
>    times are defined as 'white space'.  The concept of allowing
>    secondary transmissions (licensed or unlicensed) in white space is a
>    technique to 'unlock' existing spectrum for new use.  An obvious
>    requirement is that these secondary transmissions do not interfere
>    with the primary use of the spectrum.  One approach to using the
>    white space spectrum at a given time and location is to verify with a
>    database available channels.
> 
>    This document describes the concept of TV White Spaces.  It also
>    describes the problems that need to be addressed for enabling the use
>    of the primary user owned white space spectrum for secondary users,
>    without causing interference, by querying a database which knows the
>    channel availability at any given location and time.  A number of
>    possible use cases of this spectrum and derived requirements are also
>    described.
> 
> _______________________________________________
> 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: <[email-masked]>
Date: Fri, 2 Sep 2011 21:19:09 +0000

Teco, Gerald,

Thanks for the feedback. I'd suggest that we make this draft a WG item, with Gerald's proposed changes in it. Regarding the order of the problem statement vs use cases, my preference would be to leave it as it is (but we can always change it, if that is what the WG wants).

So, I'd ask Scott to submit a WG version of this draft, then have someone come up with text for this ad-hoc network scenario, have the WG agree with the text and include it in one of the subsequent versions. Teco, would you write up some text for this ad-hoc use case the WG could discuss?

We'll also send an initial version of a list of requirements to the list next week.

- Gabor

-----Original Message-----
From: ext Teco Boot [mailto:[email-masked]] 
Sent: Thursday, September 01, 2011 11:06 PM
To: Bajko Gabor (Nokia-CIC/SiliconValley)
Cc: [email-masked]
Subject: Re: [paws] combined problem statement, use cases & requirements

Thanks, Teco

Op 30 aug 2011, om 19:42 heeft <[email-masked]> <[email-masked]> het volgende geschreven:

> http://www.ietf.org/id/draft-probasco-paws-problem-stmt-usecases-rqmts
> -00.txt but there was not one feedback received. I take that as people 
> have no comments to the draft at this time.
> 
> URL:

---

From: Nancy Bravin <[email-masked]>
Date: Sat, 3 Sep 2011 15:41:08 -0700

Dear Gabor and All, 

I think it is appropriate to put the use cases before the PS for obvious reasons, and including the "proxy" need in the first draft. I support including both
Gerald's suggestions and Teco's proposal in the original draft and not waiting until a later time. It is the proper order, inclusive and needed in the initial
draft in my opinion. I believe with the talent in the group it will not take long to accomplish this and you will have a more cohesive draft.

SIncerely, Nancy

On Sep 2, 2011, at 2:19 PM, <[email-masked]> <[email-masked]> wrote:

>> -00.txt
>> -00.txt

---

From: <[email-masked]>
Date: Wed, 7 Sep 2011 20:32:22 +0000

Ok, let's try that then.
Scott, can you put use cases before PS, and add the ad-hoc use case. I just scanned through the list and spotted that Teco indeed provided a description for that use case on Aug 3rd.
And submit the draft as a wg item, unless there are still objections.

-Gabor

-----Original Message-----
From: ext Nancy Bravin [mailto:[email-masked]] 
Sent: Saturday, September 03, 2011 3:41 PM
To: Bajko Gabor (Nokia-CIC/SiliconValley)
Cc: Teco Boot; Gerald Chouinard; [email-masked]
Subject: Re: [paws] combined problem statement, use cases & requirements

Dear Gabor and All, 

I think it is appropriate to put the use cases before the PS for obvious reasons, and including the "proxy" need in the first draft. I support including both Gerald's suggestions and Teco's proposal in the original draft and not waiting until a later time. It is the proper order, inclusive and needed in the initial draft in my opinion. I believe with the talent in the group it will not take long to accomplish this and you will have a more cohesive draft.

SIncerely, Nancy

On Sep 2, 2011, at 2:19 PM, <[email-masked]> <[email-masked]> wrote:

>> http://www.ietf.org/id/draft-probasco-paws-problem-stmt-usecases-rqmt
>> s -00.txt but there was not one feedback received. I take that as 
>> people have no comments to the draft at this time.
>> 
>> ---------------------------------------------------------------------
>> -
>> ---------------------------------
>> From: Probasco Scott

---

From: Gerald Chouinard <[email-masked]>
Date: Wed, 07 Sep 2011 20:00:30 -0400

Gabor,

Can I ask that the text modifications that I have submitted to scott and 
copied to the paws reflector in my email dated 8 August be included as well?

Thank's,

Gerald

At 20:32 07-09-11 +0000, [email-masked] wrote:
>Ok, let's try that then.
>Scott, can you put use cases before PS, and add the ad-hoc use case. I 
>just scanned through the list and spotted that Teco indeed provided a 
>description for that use case on Aug 3rd.
>I think it is appropriate to put the use cases before the PS for obvious 
>reasons, and including the "proxy" need in the first draft. I support 
>including both Gerald's suggestions and Teco's proposal in the original 
>draft and not waiting until a later time. It is the proper order, 
>inclusive and needed in the initial draft in my opinion. I believe with 
>the talent in the group it will not take long to accomplish this and you 
>will have a more cohesive draft.
>
>SIncerely, Nancy
>
>
> > Thanks for the feedback. I'd suggest that we make this draft a WG item, 
> with Gerald's proposed changes in it. Regarding the order of the problem 
> statement vs use cases, my preference would be to leave it as it is (but 
> we can always change it, if that is what the WG wants).
> >
> > So, I'd ask Scott to submit a WG version of this draft, then have 
> someone come up with text for this ad-hoc network scenario, have the WG 
> agree with the text and include it in one of the subsequent versions. 
> Teco, would you write up some text for this ad-hoc use case the WG could 
> discuss?
> >
> > Some asked for the ad hoc network scenario. This includes me :-). This 
> is important, because it demonstrates the need for "proxy".
> > BTW, I wonder why similar scenario doesn't pop up from WiFi 
> deployments. Usage of controllers in large sites is not uncommon. Not to 
> mention 11s.
> >
> > Op 30 aug 2011, om 19:42 heeft <[email-masked]> 
> <[email-masked]> het volgende geschreven:
> >
> >> During the Quebec session, we had presentations of the PS and the use 
> cases drafts. The wg then decided it wants to see these drafts merged 
> into one. Scott just did that and posted the merged draft:
> >> s
> >> Now I would like to ask if the wg feels like this document is ready to 
> be adopted as a wg document. Please send your feedback and hum to the 
> list by this time next week.
> >>
> >> -Gabor
> >>
> >> According to the results of the face-to-face meeting, we have combined 
> the problem statement I-D and use case & requirement I-D into a single 
> I-D.  Your comments are welcomed.
> >>
> >> Regards,
> >> Scott
> >>
> >> URL:
> >> s

---

From: ZhuLei <[email-masked]>
Date: Thu, 08 Sep 2011 01:35:06 +0000

Hi all,

I think that we do some works on improving original use case draft by adding three additional use cases, including indoor coverage, ad hoc network and lte mbms issue.

Now, I am asking to add indoor coverage scenario which is necessary for PAWS protocol to consider in next stage. The proposed use case is seen below. The updated version of this draft is to be submitted soon by adding some wording modifications. So, I don't think we are to skip the additional use cases even the problem statement, use case and requirement proposal have been integrated now.

======================================================
x.x.  Indoor usage of TVWS

   At present, the indoor wireless coverage equipments consist of Wi-Fi-
   like access points and micro cells, all of these utilize segments of
   frequency, former at about 2.4GHz or 5Ghz and the latter, for
   example, 802.11n at about 2.4GHz.  As a result of the block of
   buildings and other obstruction and interferece, it may not be that
   optimistic when 802.11 devices examine the status of wireless

Zhu                     Expires February 2, 2012                [Page 3]

Internet-Draft               PAWS use cases                  August 2011

   interferes.  This use case takes the benefit of TV White Space to
   provide additional capacity to indoor coverage and reduce channel
   interferece.

   The figure below shows an example deployment of this scenario.

               +--------------------------------+
               |            indoor              |
               |                                |
               +--------------------------------+
               |                                |
               |    +------+   white space      |   +-------------+
               |    |Device| - - - - - - - - - -|- -| Micro cell  |
               |    +------+  \                 |   +-------------+
               |    +------+   \white space     |     (-----)
               |    |Device|    \ +------------+|    /       \
               |    +------+      |access point||===( Internet)
               |        o       / +------------+|    \       /
               |        o      /                |     (-----)
               |        o     /                 |
               |                                |
               +--------------------------------+

                       Graph 1 Indoor usage of TVWS

   The access point could be a WI-FI router, and the micro cell is a
   short range wireless coverage(e.g. in range of 0-50m) base station,
   both of them act as master devices, querying the internet connected
   database for available white space spectrum based on its geo-
   location, and providing TVWS access to indoor user.

   The TVWS spectrum has different propagation characteristics compared
   to higher frequency band, for example, the transmission distance
   using TVWS can be several times longer than those in the higher band.
   In this case, good penetration characteristic of TVWS makes it
   difficult to lock the signals in the room, then difficult to localize
   and differentiate signals, and finally cause interferes among
   neighboring networks.  Requirements to indoor WS datebase usage would
   be:

   1.  A frequency protection gap between neighbors(particular spectrum
       allocation algorithm is needed here).

   2.  lower output power of AP/micro cell, it seems that only certain
       pico or femto cells be feasible here.

   3.  PAWS must not be tied to a specific frequency band.

   4.  PAWS must response the proper frequency band list to particular
       coverage white space devices.

   5.  Master devices should support power control.

   6.  Slave devices should support power control.

======================================================

Zhu Lei

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 Gerald Chouinard
发送时间: 2011年9月8日 8:01
收件人: [email-masked]
抄送: [email-masked]
主题: Re: [paws] combined problem statement, use cases & requirements

Gabor,

Thank's,

Gerald

---

From: <[email-masked]>
Date: Thu, 8 Sep 2011 04:44:27 +0000

Zhu Lei,

The charter explicitly states that PAWS is to be kept technology agnostic. Thus, lte mbms use case is out of question. We just agreed to add an ad-hoc network use case, and the -00 version of the draft already has a location based service use case scenario which looks to me to be a superset of the use case you provided below (if I understood your use case correctly).

But I do not want to speak in the name of the editor. Currently the draft is still an individual submission, so it is up to the editor to incorporate any suggestion from the list to its own draft. This would change once the draft is made a wg item. Therefore, I'd propose we make this draft a wg item.

-Gabor

-----Original Message-----
From: ext ZhuLei [mailto:[email-masked]] 
Sent: Wednesday, September 07, 2011 6:35 PM
To: Gerald Chouinard; Bajko Gabor (Nokia-CIC/SiliconValley)
Cc: [email-masked]
Subject: Re: [paws] combined problem statement, use cases & requirements

Hi all,

Zhu Lei

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 Gerald Chouinard
发送时间: 2011年9月8日 8:01
收件人: [email-masked]
抄送: [email-masked]
主题: Re: [paws] combined problem statement, use cases & requirements

Gabor,

Can I ask that the text modifications that I have submitted to scott and copied to the paws reflector in my email dated 8 August be included as well?

Thank's,

Gerald

At 20:32 07-09-11 +0000, [email-masked] wrote:
>I think it is appropriate to put the use cases before the PS for 
>obvious reasons, and including the "proxy" need in the first draft. I 
>support including both Gerald's suggestions and Teco's proposal in the 
>original draft and not waiting until a later time. It is the proper 
>order, inclusive and needed in the initial draft in my opinion. I 
>believe with the talent in the group it will not take long to 
>accomplish this and you will have a more cohesive draft.
>
>SIncerely, Nancy
>
>
> with Gerald's proposed changes in it. Regarding the order of the 
> problem statement vs use cases, my preference would be to leave it as 
> it is (but we can always change it, if that is what the WG wants).
> >
> someone come up with text for this ad-hoc network scenario, have the 
> WG agree with the text and include it in one of the subsequent versions.
> Teco, would you write up some text for this ad-hoc use case the WG 
> could discuss?
> >
> deployments. Usage of controllers in large sites is not uncommon. Not 
> to mention 11s.
> >
> >> http://www.ietf.org/id/draft-probasco-paws-problem-stmt-usecases-rq
> >> mt s -00.txt but there was not one feedback received. I take that 
> >> as people have no comments to the draft at this time.
> >>
> >> secondary transmissions (licensed or unlicensed) in white space is 
> >> a technique to 'unlock' existing spectrum for new use.  An obvious 
> >> white space spectrum at a given time and location is to verify with 
> >> a database available channels.
> >>
> >> describes the problems that need to be addressed for enabling the 
> >> use of the primary user owned white space spectrum for secondary 
> >> users, without causing interference, by querying a database which 
> >> knows the channel availability at any given location and time.  A 
> >> number of possible use cases of this spectrum and derived 
> >> requirements are also described.
> >>

---

From: ZhuLei <[email-masked]>
Date: Thu, 08 Sep 2011 06:37:21 +0000

Hi Gabor,

The indoor is still the necessary part of Cognitive Radio and PAWS issue. Comparing with the stated use cases in combined proposed draft, the indoor and ad hoc scenarios may be more important to be incorporated according to my understanding since the working group would likely to avoid that the different frequent bands were used in proper scenario(s). I am not to see a agreed draft without such insurance of indoor coverage and ad hoc scenarios. And, it is of course a need to keep use cases visible when starting protocol developments. 

So, I also think that editor (Scott?) can consider the proposed use cases here as necessary but not waiting for next f2f meeting. 

Best regards,
Zhu Lei

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 
发送时间: 2011年9月8日 12:44
收件人: ZhuLei
抄送: [email-masked]
主题: RE: [paws] combined problem statement, use cases & requirements

Zhu Lei,

-Gabor

-----Original Message-----
From: ext ZhuLei [mailto:[email-masked]] 
Sent: Wednesday, September 07, 2011 6:35 PM
To: Gerald Chouinard; Bajko Gabor (Nokia-CIC/SiliconValley)
Cc: [email-masked]
Subject: Re: [paws] combined problem statement, use cases & requirements

Hi all,

Zhu Lei

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 Gerald Chouinard
发送时间: 2011年9月8日 8:01
收件人: [email-masked]
抄送: [email-masked]
主题: Re: [paws] combined problem statement, use cases & requirements

Gabor,

Thank's,

Gerald

At 20:32 07-09-11 +0000, [email-masked] wrote:
> >> mt
> >> mt

---

From: <[email-masked]>
Date: Thu, 8 Sep 2011 14:58:00 +0000

Hi Gerald,

I have updated the "Wide-Area or Rural internet broadband access" use case
according to your email of August 30. This email proposes different edits
to the same text as your email of August 8. Are you okay with the Aug 30
version?

Thanks,
Scott

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

>>problem 
>>could 
>>to

---

From: Gerald Chouinard <[email-masked]>
Date: Thu, 08 Sep 2011 11:15:41 -0400

Hi Scott,

My apologies; I referred to the wrong email.  The proper modifications are 
the ones contained in my email dated August 30th.

Thank's for including it in your most recent version of the document.

Gerald

---

From: <[email-masked]>
Date: Thu, 8 Sep 2011 15:49:06 +0000

Hello Lei,

I have studied the text below, but I do not understand the use case you
are proposing. It seems to me that you are describing a deployment
scenario (which is fine). I do not understand what is the use case, or how
this case is different from "Hotspot" use case (AP is indoor) with a
"Wide-area or rural" use case deployed in the same general area (microcell
is outdoor).

I am not speaking against the use case, simply saying that I don't
understand it well enough to comment on it. It might help further
discussion if you can describe in more detail the use case, and include
specific actions that each element (microcell, AP, device, database, etc)
must complete in order to deploy this use case.

Regards,
Scott

On 9/7/11 8:35 PM, "ext ZhuLei" <[email-masked]> wrote:

>Hi all,
>
>I think that we do some works on improving original use case draft by
>adding three additional use cases, including indoor coverage, ad hoc
>network and lte mbms issue.
>
>Now, I am asking to add indoor coverage scenario which is necessary for
>PAWS protocol to consider in next stage. The proposed use case is seen
>below. The updated version of this draft is to be submitted soon by
>adding some wording modifications. So, I don't think we are to skip the
>additional use cases even the problem statement, use case and requirement
>proposal have been integrated now.
>

---

From: <[email-masked]>
Date: Thu, 8 Sep 2011 19:56:28 +0000

Zhu Lei,

Note, that Cognitive Radio aspects are not part of the current paws charter. 
I'd now encourage the editor to submit a new version  of the draft as a wg item incorporating the changes agreed so far on the list, then we can continue the discussion on what additional use cases to incorporate into the now wg draft. 
In the meantime, I hope Zhu Lei can put its proposed uses cases into a more understandable format (and in line with the template followed by the other use case descriptions in the draft) and keep them within the scope of the current charter. Then we can debate on the list if the use cases have enough merit to be added to the wg draft. And as you said Zhu Lei, we do not need to wait with that until the next f2f, we can decide here on the list, hopefully before the Taipei f2f.
-gabor

-----Original Message-----
From: ext ZhuLei [mailto:[email-masked]] 
Sent: Wednesday, September 07, 2011 11:37 PM
To: Bajko Gabor (Nokia-CIC/SiliconValley)
Cc: [email-masked]
Subject: Re: [paws] combined problem statement, use cases & requirements

Hi Gabor,

Best regards,
Zhu Lei

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]]
发送时间: 2011年9月8日 12:44
收件人: ZhuLei
抄送: [email-masked]
主题: RE: [paws] combined problem statement, use cases & requirements

Zhu Lei,

-Gabor

-----Original Message-----
From: ext ZhuLei [mailto:[email-masked]]
Sent: Wednesday, September 07, 2011 6:35 PM
To: Gerald Chouinard; Bajko Gabor (Nokia-CIC/SiliconValley)
Cc: [email-masked]
Subject: Re: [paws] combined problem statement, use cases & requirements

Hi all,

Zhu Lei

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 Gerald Chouinard
发送时间: 2011年9月8日 8:01
收件人: [email-masked]
抄送: [email-masked]
主题: Re: [paws] combined problem statement, use cases & requirements

Gabor,

Thank's,

Gerald

---

From: ZhuLei <[email-masked]>
Date: Tue, 13 Sep 2011 07:09:24 +0000

Hi Scott and all,

For some reasons, I think that PAWS protocol would be developed with quite stable scenario descriptions of indoor coverage. 

According to previous e-mail discussion in the list, it seems that working group would develop generic and globally applicable spectrum database query protocol which hopely is accepted by other regulators but only FCC. 700MHz-800MHz can be shared to particular wireless access technologies like 802.11, 802.22 and even LTE. Please correct me if something wrong.

The generic use cases could be safe when deciding working group draft. But hotspot and urban internet connection description is still not creditable to develop PAWS protocol for the reason 700MHz has far different propagation characteristics from the needs of indoor coverage and urban hotspot use case. In general, indoor use case says that database should to response proper spectrum if APs request channels for indoor Internet connection. If it is not possible, regulators must to face problems of interference among APs and Micro cell BSs. Then, PAWS now has to recognize scenario description and requirements before develop protocol that other higher frequent bands (at least higher than 2.1GHz) should be considered to indoor coverage. I would like to remind that is different need for indoor coverage from generic hotspot and urban coverage which is still to be divided.

From protocol perspective, it will depend on the conclusion of working group which IEs are reserved for indoor query usages.

Three things are particular for indoor coverage use case if develop PAWS protocol. First one is that the location in a building is different from GPS positioning. Second one is that the database should be able to calculate the proper band for indoor coverage. Third one is that database should be able to consider (or calculate) and avoid unexpected interference among different indoor APs and micro cell BSs.

Best regards,
Zhu Lei

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 
发送时间: 2011年9月8日 23:49
收件人: ZhuLei
抄送: [email-masked]
主题: Re: [paws] combined problem statement, use cases & requirements

Hello Lei,

Regards,
Scott

---

From: Peter Stanforth <[email-masked]>
Date: Tue, 13 Sep 2011 08:26:26 -0400

Regulation of TVWS is currently proposed by 3 Regulators, US, UK and
Canada, with work ongoing in Singapore, Finland and several other
countries. There are subtle differences in approach and requirements but
the basic concept is the same in all cases. PAWS should be able to address
all cases.
All regulators allow for indoor use as well as outdoor use. PAWS should
address all these cases. All regulators propose that a component of the
decision be based on the "device type" allowing for different results
based on the capability and, in some regulation, the maximum power output
of the device. There is no reason PAWS cannot address the requirements for
indoor use as well as outdoor use. At 450-700MHz the issue of co-existence
between 2 apartments is really no different than the co-existence between
2 outdoor access points several hundred meters apart. That said, it was my
understanding that PAWS was also frequency and modulation independent,
which it should be.
Peter Stanforth
Spectrum Bridge Inc.

On TueSep/13/11 Tue Sep 13, 3:09 AM, "ZhuLei" <[email-masked]> wrote:

>Hi Scott and all,
>
>For some reasons, I think that PAWS protocol would be developed with
>quite stable scenario descriptions of indoor coverage.
>
>According to previous e-mail discussion in the list, it seems that
>working group would develop generic and globally applicable spectrum
>database query protocol which hopely is accepted by other regulators but
>only FCC. 700MHz-800MHz can be shared to particular wireless access
>technologies like 802.11, 802.22 and even LTE. Please correct me if
>something wrong.
>
>The generic use cases could be safe when deciding working group draft.
>But hotspot and urban internet connection description is still not
>creditable to develop PAWS protocol for the reason 700MHz has far
>different propagation characteristics from the needs of indoor coverage
>and urban hotspot use case. In general, indoor use case says that
>database should to response proper spectrum if APs request channels for
>indoor Internet connection. If it is not possible, regulators must to
>face problems of interference among APs and Micro cell BSs. Then, PAWS
>now has to recognize scenario description and requirements before develop
>protocol that other higher frequent bands (at least higher than 2.1GHz)
>should be considered to indoor coverage. I would like to remind that is
>different need for indoor coverage from generic hotspot and urban
>coverage which is still to be divided.
>
>From protocol perspective, it will depend on the conclusion of working
>group which IEs are reserved for indoor query usages.
>
>Three things are particular for indoor coverage use case if develop PAWS
>protocol. First one is that the location in a building is different from
>GPS positioning. Second one is that the database should be able to
>calculate the proper band for indoor coverage. Third one is that database
>should be able to consider (or calculate) and avoid unexpected
>interference among different indoor APs and micro cell BSs.
>
>Best regards,
>Zhu Lei
>
>
>-----邮件原件-----
>>>use

---

From: <[email-masked]>
Date: Tue, 13 Sep 2011 13:18:30 +0000

Hi,

PAWS is independent of any specific spectrum, country, or phy/mac/air
interface. This is stated in the charter.

I agree with Peter that PAWS can address indoor and outdoor use.

>interference among different indoor APs and micro cell BSs.

It is fair to say that it may be easier for an "outdoor device" to
determine its location using GPS than an "indoor device". However, this is
not in the scope of PAWS. A master device must have access to its location
in order to use PAWS, but how the device "knows" its position does not
matter for PAWS. Requirements on the database ('database should be able to
calculate...' & 'database should be able to consider...') are regulatory
requirements (in scope for FCC, Ofcom, Industry Canaday, Ficora, etc) but
are beyond scope of PAWS.

I support PAWS for many use cases, both indoor and outdoor. I am
interested to discuss and consider specific use cases, described in
details which include actions that each element (microcell, AP, device,
database, etc) must complete in order to deploy the use case. Well
described use cases are needed in order to identify, justify and agree the
requirements on PAWS.

Regards,
Scott

On 9/13/11 7:26 AM, "ext Peter Stanforth" <[email-masked]> wrote:

>>>>obvious
>>>>WG
>>>> >> From: [email-masked] [mailto:[email-masked]] On
>>>>Behalf
>>>> >> Of ext [email-masked]
>>>>a

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 13 Sep 2011 09:26:45 -0400

Our charter says that we will develop a protocol which is spectrum independent (different bands), phi independent (different types of devices using different over the air interfaces) and nation independent.

That means, as Peter says, indoor and outdoor use would be covered.

I do think the query will have some kind of "type" which is the phy independence, but also takes into account the regulators rules on power, antenna and other parameters.
The US rules work that way, and I expect many other nations will have similar kinds of rules.  You can imagine rules where more antenna information is needed in the query to determine what spectrum is available, but so far, there are merely limits for each type.

Brian

---

From: ZhuLei <[email-masked]>
Date: Wed, 14 Sep 2011 09:08:02 +0000

Hi,

No doubt that PAWS is spectrum independent, air interface technologies independent and nation independent protocol which would have some essential parameters in query request like "location", "type" and maximum power limits. I used to think that PAWS is even extendable for some additional rule if there is. Such supported or extendable information in a query request would provide information to for database to reply available bands. That is original concept of PAWS when I used to listen.

For interference issue, I think that APs indoor are more flexible to limit the output power, but it is difficult to limit power output of outdoor access points which cover over hundreds meters. So, the database is likely to reply other spectrum to indoor APs if the spectrum is already covered by other outdoor AP(s). The conclusion of the indoor APs could be complicated more since sometimes power control works when interference happens, but interference avoidance is still very useful in a number of cases. 802.11 has "interference avoidance" is basically to use different "channel" in case that more than one APs work in an area. My opinion is that it is very helpful if database would reply some higher bands that radio would not be able to penetrate several walls for the scenarios some APs are just in one building.

Best regards,
Zhu Lei

-----邮件原件-----
发件人: Rosen, Brian [mailto:[email-masked]] 
发送时间: 2011年9月13日 21:27
收件人: Peter Stanforth
抄送: ZhuLei; [email-masked]; [email-masked]
主题: Re: [paws] combined problem statement, use cases & requirements

Brian

---

From: Teco Boot <[email-masked]>
Date: Wed, 14 Sep 2011 12:07:45 +0200

Hi,

Aren't you describing an AP - WiFi Controller setup, and a protocol for such? The controller can optimize spectrum usage for "slave" AP's, and can perform a proxy for the AP's for getting spectrum. This can be done in distributed way also, but I am not aware of such deployment.

Teco

---

From: Peter Stanforth <[email-masked]>
Date: Wed, 14 Sep 2011 08:28:29 -0400

>From the regulator, and other spectrum holder perspective, the sole
responsibility of the white space DB solution is to ensure that the
secondary users do not, in any way, interfere with the primary user of the
spectrum. This has to be the primary focus of PAWS. I would propose that
any co-existence or other capability that assists in the management of the
secondary users is handled by extensible capabilities above and beyond the
basic requirement. While it would be beneficial to specify and standardize
some of these capabilities they are of no interest to the spectrum "owner".
Peter S.

On WedSep/14/11 Wed Sep 14, 5:08 AM, "ZhuLei" <[email-masked]> wrote:

>Hi,
>
>No doubt that PAWS is spectrum independent, air interface technologies
>independent and nation independent protocol which would have some
>essential parameters in query request like "location", "type" and maximum
>power limits. I used to think that PAWS is even extendable for some
>additional rule if there is. Such supported or extendable information in
>a query request would provide information to for database to reply
>available bands. That is original concept of PAWS when I used to listen.
>
>For interference issue, I think that APs indoor are more flexible to
>limit the output power, but it is difficult to limit power output of
>outdoor access points which cover over hundreds meters. So, the database
>is likely to reply other spectrum to indoor APs if the spectrum is
>already covered by other outdoor AP(s). The conclusion of the indoor APs
>could be complicated more since sometimes power control works when
>interference happens, but interference avoidance is still very useful in
>a number of cases. 802.11 has "interference avoidance" is basically to
>use different "channel" in case that more than one APs work in an area.
>My opinion is that it is very helpful if database would reply some higher
>bands that radio would not be able to penetrate several walls for the
>scenarios some APs are just in one building.
>
>Best regards,
>Zhu Lei
>

---

From: ZhuLei <[email-masked]>
Date: Wed, 14 Sep 2011 12:32:03 +0000

Hi,

I think that AP(s) may do this by themselves which is to sense conflict channels and avoid to use them, or controller optimizes it. It is still ok for PAWS even it is not discussed.

Best regards,
Zhu Lei

-----邮件原件-----
发件人: Teco Boot [mailto:[email-masked]] 
发送时间: 2011年9月14日 18:08
收件人: ZhuLei
抄送: Rosen, Brian; Peter Stanforth; [email-masked]
主题: Re: [paws] combined problem statement, use cases & requirements

Hi,

Teco