Subject: [paws] PS I-D: draft-patil-paws-problem-stmt-00.txt

From: <[email-masked]>
Date: Tue, 22 Feb 2011 15:23:22 +0000

Hello,

Just wanted to let you know that we have posted the Problem statement I-D.

I-D: Protocol to Access White Space database: Problem statement and
                              Requirements

http://www.ietf.org/id/draft-patil-paws-problem-stmt-00.txt

Please review and provide comments to further improve the I-D.

-Basavaraj

---

From: Chang-woo Pyo <[email-masked]>
Date: Wed, 23 Feb 2011 13:48:56 +0900

Appreciate the quite available document for the problem statement and 
requirements.
I would want to state one more thing about the problem statement,
which is the service overlapping from the different databases.

FCC allows several operators can manage their databases.
It means that a specific geographical service area can be overlapped by 
the different operators (databases).
Within the overlapping area, white space devices may interfere with the 
primary devices
without obtaining available channels from each database managed by the 
different operators.

Thanks,
Pyo

---------------------------------------------------
Chang-Woo Pyo
Researcher,
Ubiquitous Mobile Comm. Group, NICT,
3-4, Hikarino-oka, Yokosuka, 239-0847, Japan,
Tel: +81-46-847-5120
---------------------------------------------------

(2011/02/23 0:23), [email-masked] wrote:
> _______________________________________________
> paws mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/paws

-- 
---------------------------------------------------
Chang-Woo Pyo
Researcher,
Ubiquitous Mobile Comm. Group, NICT,
3-4, Hikarino-oka, Yokosuka, 239-0847, Japan,
Tel: +81-46-847-5120
---------------------------------------------------

---

From: <[email-masked]>
Date: Wed, 23 Feb 2011 11:57:32 +0000

Hi Pyo,

I don't quite understand the problem you are describing.

The regulatory requirement from FCC is that a database must have exact information on the available white space channels in any location that it serves. Below a snippet from the FCC final rules.

A TV bands database will be required to contain information on:

(1)     All of the authorized services that operate in the TV bands using fixed transmitters with designated service areas, including full service and low power TV stations,

(2)     the service paths of broadcast auxiliary point-to-point facilities,

(3)     the geographic regions served by PLMRS/CMRS operations on channels 14-20,

(4)     regions served by the Offshore Radiotelephone Service, and

(5)     the locations of cable headends and low power TV receive sites that are outside the protected contours of the TV stations whose signals they receive.
In addition, a TV bands database will be required to contain the locations of registered sites where wireless microphones and other low power auxiliary devices are used on a regular or scheduled basis

This information must be identical regardless which database is queried. For example, the TV channel data is in FCC's own databases which the WS databases have to access. Information on registered wireless microphones is more dynamic in nature than TV broadcast towers, but again should be in one repository that all the databases can access. Should there be different information from one database to another, one or more databases are not up-to-date or have altered the original frequency availability information. This would be a failure on the part of the database administrator to provide service on the terms required by the regulator and not related to the interface standard we are to address here.

The regulatory requirements on WS databases will be somewhat different in other countries, but in an analogous fashion each database must have identical information when it is queried.

If we refer to Figure 1 in the problem statement, it should not matter whether the WS device connects to database X or database Y. It must receive exactly identical information on available channels from each one.

Kind regards,
Jussi

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Chang-woo Pyo
Sent: 23 February 2011 04:49
To: [email-masked]
Subject: Re: [paws] PS I-D: draft-patil-paws-problem-stmt-00.txt

Appreciate the quite available document for the problem statement and requirements.
I would want to state one more thing about the problem statement,
which is the service overlapping from the different databases.

FCC allows several operators can manage their databases.
It means that a specific geographical service area can be overlapped by the different operators (databases).
Within the overlapping area, white space devices may interfere with the primary devices
without obtaining available channels from each database managed by the different operators.

Thanks,
Pyo

Chang-Woo Pyo

Researcher,

Tel: +81-46-847-5120

(2011/02/23 0:23), [email-masked]<mailto:[email-masked]> wrote:

Hello,

                              Requirements

-Basavaraj

paws mailing list

[email-masked]<mailto:[email-masked]>

--

Chang-Woo Pyo

Researcher,

Tel: +81-46-847-5120

---

From: Peter Stanforth <[email-masked]>
Date: Wed, 23 Feb 2011 08:41:30 -0500

Just to help the conversation below. Each Database Administrator in the US has a nationwide franchise, so there are no boundary conditions between database providers.
Devices can query one, or possibly more databases and, for a given location will get exactly the same results in terms of a channel map.
Peter Stanforth
CTO
Spectrum Bridge Inc.

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Wed, 23 Feb 2011 06:57:32 -0500
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [paws] PS I-D: draft-patil-paws-problem-stmt-00.txt

Hi Pyo,

I don’t quite understand the problem you are describing.

(3)     the geographic regions served by PLMRS/CMRS operations on channels 14–20,

This information must be identical regardless which database is queried. For example, the TV channel data is in FCC’s own databases which the WS databases have to access. Information on registered wireless microphones is more dynamic in nature than TV broadcast towers, but again should be in one repository that all the databases can access. Should there be different information from one database to another, one or more databases are not up-to-date or have altered the original frequency availability information. This would be a failure on the part of the database administrator to provide service on the terms required by the regulator and not related to the interface standard we are to address here.

Kind regards,
Jussi

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of ext Chang-woo Pyo
Sent: 23 February 2011 04:49
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [paws] PS I-D: draft-patil-paws-problem-stmt-00.txt

Thanks,
Pyo

Chang-Woo Pyo

Researcher,

Tel: +81-46-847-5120

Hello,

                              Requirements

-Basavaraj

paws mailing list

--

Chang-Woo Pyo

Researcher,

Tel: +81-46-847-5120

---

From: <[email-masked]>
Date: Wed, 23 Feb 2011 15:09:47 +0000

Hello Pyo,

Thanks for the update.
Can you elaborate on what the implication of the issue that you raise below would mean for the device-database interface?

-Raj

From: ext Chang-woo Pyo <[email-masked]<mailto:[email-masked]>>
Date: Wed, 23 Feb 2011 13:48:56 +0900
To: <[email-masked]<mailto:[email-masked]>>
Subject: Re: [paws] PS I-D: draft-patil-paws-problem-stmt-00.txt

Thanks,
Pyo

Hello,

                              Requirements

-Basavaraj

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

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

---

From: Robert Wu <[email-masked]>
Date: Wed, 23 Feb 2011 07:25:01 -0800 (PST)

Thanks Peter and all! How frequent the database is updated? For wireless microphones, is there any "pushed" implementation consideration in your database. 
 
Best regards, 
Robert Wu 
6Harmonics Inc. 

--- On Wed, 2/23/11, Peter Stanforth <[email-masked]> wrote:

From: Peter Stanforth <[email-masked]>
Subject: Re: [paws] PS I-D: draft-patil-paws-problem-stmt-00.txt
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Received: Wednesday, February 23, 2011, 7:41 PM

From: "[email-masked]" <[email-masked]>
Date: Wed, 23 Feb 2011 06:57:32 -0500
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [paws] PS I-D: draft-patil-paws-problem-stmt-00.txt

Hi Pyo,

 

 
 
Kind regards,
Jussi

Thanks,
Pyo

---------------------------------------------------Chang-Woo PyoResearcher,Ubiquitous Mobile Comm. Group, NICT,3-4, Hikarino-oka, Yokosuka, 239-0847, Japan,Tel: +81-46-847-5120---------------------------------------------------

Hello, 
  
Just wanted to let you know that we have posted the Problem statement I-D. I-D: Protocol to Access White Space database: Problem statement and  
                              Requirements 

  
-Basavaraj     _______________________________________________paws mailing [email-masked]://www.ietf.org/mailman/listinfo/paws

-- ---------------------------------------------------Chang-Woo PyoResearcher,Ubiquitous Mobile Comm. Group, NICT,3-4, Hikarino-oka, Yokosuka, 239-0847, Japan,Tel: +81-46-847-5120---------------------------------------------------

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 23 Feb 2011 11:13:04 -0500

FYI here is the exact FCC order appointing the administrators. 

http://www.fcc.gov/Daily_Releases/Daily_Business/2011/db0126/DA-11-131A1.pdf

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Peter Stanforth
Sent: Wednesday, February 23, 2011 8:42 AM
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [paws] PS I-D: draft-patil-paws-problem-stmt-00.txt

Just to help the conversation below. Each Database Administrator in the US
has a nationwide franchise, so there are no boundary conditions between
database providers.

Devices can query one, or possibly more databases and, for a given location
will get exactly the same results in terms of a channel map.

Peter Stanforth

CTO

Spectrum Bridge Inc.

Hi Pyo,

The regulatory requirement from FCC is that a database must have exact
information on the available white space channels in any location that it
serves. Below a snippet from the FCC final rules.

(1)  All of the authorized services that operate in the TV bands using fixed
transmitters with designated service areas, including full service and low
power TV stations, 

(3)  the geographic regions served by PLMRS/CMRS operations on channels
14-20, 

(5)  the locations of cable headends and low power TV receive sites that are
outside the protected contours of the TV stations whose signals they
receive. 

In addition, a TV bands database will be required to contain the locations
of registered sites where wireless microphones and other low power auxiliary
devices are used on a regular or scheduled basis

This information must be identical regardless which database is queried. For
example, the TV channel data is in FCC's own databases which the WS
databases have to access. Information on registered wireless microphones is
more dynamic in nature than TV broadcast towers, but again should be in one
repository that all the databases can access. Should there be different
information from one database to another, one or more databases are not
up-to-date or have altered the original frequency availability information.
This would be a failure on the part of the database administrator to provide
service on the terms required by the regulator and not related to the
interface standard we are to address here. 

The regulatory requirements on WS databases will be somewhat different in
other countries, but in an analogous fashion each database must have
identical information when it is queried.

If we refer to Figure 1 in the problem statement, it should not matter
whether the WS device connects to database X or database Y. It must receive
exactly identical information on available channels from each one.

Kind regards,

Jussi

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext
Chang-woo Pyo
Sent: 23 February 2011 04:49
To: [email-masked]
Subject: Re: [paws] PS I-D: draft-patil-paws-problem-stmt-00.txt

FCC allows several operators can manage their databases. 
It means that a specific geographical service area can be overlapped by the
different operators (databases).
Within the overlapping area, white space devices may interfere with the
primary devices 
without obtaining available channels from each database managed by the
different operators.

Thanks,
Pyo

Hello, 

                              Requirements 

-Basavaraj

---

From: Chang-woo Pyo <[email-masked]>
Date: Thu, 24 Feb 2011 10:58:09 +0900

Hi, Raj

I raise the issue about the interface among databases under different 
administrators.
On wireless fashion, the service coverages shall be overlapped, but the 
overlapped area shall not be assigned by the same channel.
For this, channel information shall be shared among the databases which 
may serve the same geographical area.
I am not sure whether the issue of database-database interface is 
insight of PAWS.

Best regards,
Pyo

(2011/02/24 0:09), [email-masked] wrote:
>
> Hello Pyo,
>
> Thanks for the update.
> Can you elaborate on what the implication of the issue that you raise 
> below would mean for the device-database interface?
>
> -Raj
>
> From: ext Chang-woo Pyo <[email-masked] <mailto:[email-masked]>>
> To: <[email-masked] <mailto:[email-masked]>>
> (2011/02/23 0:23), [email-masked] 
> <mailto:[email-masked]> wrote:
>>
>> Hello,
>>
>> [email-masked]  <mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/paws
>
>
> -- 
> _______________________________________________ paws mailing list 
> [email-masked] <mailto:[email-masked]>

---

From: Chang-woo Pyo <[email-masked]>
Date: Thu, 24 Feb 2011 11:18:19 +0900

Hi, Jussi

Thank you for your kind explanation.
What I  want to say in the previous my comment is related in channel 
information exchange between databases under the different administrators.
I am not sure how much well cooperate between database administrators, 
but I really believe that the channel information shall be exchanged and 
synchronized among databases.
A geographical area may be overlapped by the different database 
administrators, within the overlapped area, then unexpected interference 
may happen.
It is necessary somewhat to define the interface between databases.
Do you think the above issue is out of sense.

Best regards,
Pyo

(2011/02/23 20:57), [email-masked] wrote:
> information on the available white space channels in any location that 
> it serves. Below a snippet from the FCC final rules.
>
> (1)All of the authorized services that operate in the TV bands using 
> fixed transmitters with designated service areas, including full 
> service and low power TV stations,
>
> (2)the service paths of broadcast auxiliary point-to-point facilities,
>
> (3)the geographic regions served by PLMRS/CMRS operations on channels 
> 14--20,
>
> (4)regions served by the Offshore Radiotelephone Service, and
>
> (5)the locations of cable headends and low power TV receive sites that 
> are outside the protected contours of the TV stations whose signals 
> they receive.
>
> In addition, a TV bands database will be required to contain the 
> locations of registered sites where wireless microphones and other low 
> power auxiliary devices are used on a regular or scheduled basis
>
> This information must be identical regardless which database is 
> queried. For example, the TV channel data is in FCC's own databases 
> which the WS databases have to access. Information on registered 
> wireless microphones is more dynamic in nature than TV broadcast 
> towers, but again should be in one repository that all the databases 
> can access. Should there be different information from one database to 
> another, one or more databases are not up-to-date or have altered the 
> original frequency availability information. This would be a failure 
> on the part of the database administrator to provide service on the 
> terms required by the regulator and not related to the interface 
> standard we are to address here.
>
> The regulatory requirements on WS databases will be somewhat different 
> in other countries, but in an analogous fashion each database must 
> have identical information when it is queried.
>
> whether the WS device connects to database X or database Y. It must 
> receive exactly identical information on available channels from each 
> one.
>
> Kind regards,
>
> Jussi
>
> *From:[email-masked] [mailto:[email-masked]] *On Behalf 
> Of *ext Chang-woo Pyo
> *Sent:* 23 February 2011 04:49
> *To:* [email-masked]
> *Subject:* Re: [paws] PS I-D: draft-patil-paws-problem-stmt-00.txt
>

---

From: <[email-masked]>
Date: Thu, 24 Feb 2011 10:44:20 +0000

Hi Pyo,

I remain with the understanding that from the FCC requirements point of view the WS device does receive exactly identical information from each database, and coordination is not needed in order to fulfil the minimum criteria of avoiding interference. However, your concern does have a point when we consider country borders where cross-coordination issues exists as we expect will be the case in Europe. The available channels in country A will be different from those in country B, but both will be relevant for a device near the border area. Rather than require the device to figure out that it needs to coordinate between two regimes it makes much more sense for the relevant databases to coordinate and then have one of them provide the combined information to the device,

And of course, when we consider potential database services that go beyond the barebones needs of avoiding interference there may be benefits in databases talking to one another. So, I am not saying that such interface is not needed, only that for the available channel information a device must get it from any database in an identical manner without any need for the databases to exchange channel lists.

So, yes, the database-to-database interface will also be there but maybe Peter or someone else could share views on that, too.

Best regards,
Jussi

--- original message ---
From: "ext Chang-woo Pyo" <[email-masked]>
Subject: Re: [paws] PS I-D: draft-patil-paws-problem-stmt-00.txt
Date: 24th February 2011
Time: 3:18:31

Hi, Jussi

Thank you for your kind explanation.
What I  want to say in the previous my comment is related in channel information exchange between databases under the different administrators.
I am not sure how much well cooperate between database administrators, but I really believe that the channel information shall be exchanged and synchronized among databases.
A geographical area may be overlapped by the different database administrators, within the overlapped area, then unexpected interference may happen.
It is necessary somewhat to define the interface between databases.
Do you think the above issue is out of sense.

Best regards,
Pyo

(2011/02/23 20:57), [email-masked]<mailto:[email-masked]> wrote:

Hi Pyo,

Kind regards,

Jussi

Thanks,
Pyo

Chang-Woo Pyo

Researcher,

Tel: +81-46-847-5120

Hello,

                              Requirements

-Basavaraj

paws mailing list

--

Chang-Woo Pyo

Researcher,

Tel: +81-46-847-5120

---

From: <[email-masked]>
Date: Thu, 24 Feb 2011 21:27:59 +0000

Hi All,

One additional thing which I think is relevant to Pyo' comment. When a WS device receives a list of channels for use from a database, this only means the channel is not in use by a licensed, primary user, such as TV broadcaster or perhaps a wireless microphone. It is possible the channel is being used by another WS device. WS devices cannot cause interference to primary users, but also WS devices cannot expect any protection from interference. Some additional coexistence capability for WS devices is desirable, e.g. compatible multiple access scheme (as in Wi-Fi), or something else.

Regards,

Scott

From: [email-masked] [mailto:[email-masked]] On Behalf Of Kahtava Jussi (Nokia-CIC/Southwood)
Sent: Thursday, February 24, 2011 4:44 AM
To: [email-masked]; [email-masked]
Subject: Re: [paws] PS I-D: draft-patil-paws-problem-stmt-00.txt

Hi Pyo,

Best regards,
Jussi

--- original message ---
From: "ext Chang-woo Pyo" <[email-masked]>
Subject: Re: [paws] PS I-D: draft-patil-paws-problem-stmt-00.txt
Date: 24th February 2011
Time: 3:18:31

Hi, Jussi

Best regards,
Pyo

Hi Pyo,

Kind regards,

Jussi

Thanks,
Pyo

Hello,

                              Requirements

-Basavaraj

---

From: Rex Buddenberg <[email-masked]>
Date: Thu, 24 Feb 2011 14:19:33 -0800

Which leads to the requirement for a whitespace device to self-register
in the database, ad hoc.  Part of the power-on initialization process.

On Thu, 2011-02-24 at 21:27 +0000, [email-masked] wrote:
> Hi All,
> 
>  
> 
> One additional thing which I think is relevant to Pyo’ comment. When a
> WS device receives a list of channels for use from a database, this
> only means the channel is not in use by a licensed, primary user, such
> as TV broadcaster or perhaps a wireless microphone. It is possible the
> channel is being used by another WS device. WS devices cannot cause
> interference to primary users, but also WS devices cannot expect any
> protection from interference. Some additional coexistence capability
> for WS devices is desirable, e.g. compatible multiple access scheme
> (as in Wi-Fi), or something else.
> 
>  
> 
> Regards,
> 
> Scott
> 
>  
> 
> but I really believe that the channel information shall be exchanged
> and synchronized among databases.
> administrators, within the overlapped area, then unexpected
> interference may happen.
> (1)     All of the authorized services that operate in the TV bands
> using fixed transmitters with designated service areas, including full
> (5)     the locations of cable headends and low power TV receive sites
> that are outside the protected contours of the TV stations whose
> signals they receive. 
> 
> queried. For example, the TV channel data is in FCC’s own databases

---

From: <[email-masked]>
Date: Thu, 24 Feb 2011 22:28:38 +0000

Hi,

White space device registration with the database does bring some nice opportunities for value-added service. I am not aware of any white space implementation (trial, demo) which use registration in the database as a means to mitigate interference between white space devices.

There is a similar capability under development in IEEE 802.19.1 as part of a coexistence mechanism. A coexistence management ability allows devices which do not share compatible multiple access schemes to coexist in the same channel.

Regards,
Scott

---

From: Marc Emmelmann <[email-masked]>
Date: Fri, 25 Feb 2011 11:53:41 +0100

I would disagree. Requiring *all* white space devices to register
in a database is only one possible option which imposes a more or 
less (locally) centralized database architecture.

Leaving coexistence to the technology operating in white spaces
is IMHO the approach which has a long history of engineering experience
behind it (see Scott's example on the 802 protocol family).

I would like to clearly separate requirement into those coming from

	a) using white spaces

and

	b) enabling / guaranteeing coexistence (and interference
		reduction) among secondary users.

(b) has in my opinion nothing in particular to do with white space usage.

Best,

Marc

---

From: Warren Kumari <[email-masked]>
Date: Fri, 25 Feb 2011 10:10:19 -0500

Hi all,

Apologies if these questions don't make much sense -- this is a new  
topic for me (I'm usually on the DNS / security side of things)...

First off I'd like to say that I found the draft clean and easy to  
read...

I wanted to get a better idea of the required data and how dynamic it  
is likely to be, for example:
A: is time important? Do we need to worry about cases where a local  
station transmits from 6AM to 9PM on weekdays, freeing up the space  
during the rest of the time? Or is this an unrealistic scenario?

B: How dynamic is the data likely to be? I'm assuming that the entries  
sucked down by devices will need to have some sort of timeout,  
validity period -- does this need to be an absolute time (like "This  
is good till 2011-03-22 11:35UTC") or something like a TTL? In eaihter  
case, are entries likely to be valid for months? Days? Seconds?  If  
wireless mics are a driver, what sort of mics are these? Are they used  
by production companies / news crews (and so might arrive in an area  
on sort notice) or more like fixed stage mics (and so are relatively  
static)?

Oh, and a doc (very minor) nit:
Section 4 (Problem Statement), diagram.
The WS devices and databases all use 'X' and 'Y' to show "variables"  
-- using different letters for each variable may avoid confusion (hey!  
I did say it was minor)

W

On Feb 22, 2011, at 10:23 AM, <[email-masked]> <[email-masked] 
 > wrote:

---

From: Robert Wu <[email-masked]>
Date: Fri, 25 Feb 2011 08:50:23 -0800 (PST)

IEEE 802.19 has been working on this! 

--- On Fri, 2/25/11, [email-masked] <[email-masked]> wrote:

From: [email-masked] <[email-masked]>
Subject: Re: [paws] PS I-D: draft-patil-paws-problem-stmt-00.txt
To: [email-masked], [email-masked], [email-masked]
Received: Friday, February 25, 2011, 3:27 AM

Hi All,
 
One additional thing which I think is relevant to Pyo’ comment. When a WS device receives a list of channels for use from a database, this only means the channel is not in use by a licensed, primary user, such as TV broadcaster or perhaps a wireless microphone. It is possible the channel is being used by another WS device. WS devices cannot cause interference to primary users, but also WS devices cannot expect any protection from interference. Some additional coexistence capability for WS devices is desirable, e.g. compatible multiple access scheme (as in Wi-Fi), or something else.
 
Regards,
Scott

From: [email-masked] [mailto:[email-masked]] On Behalf Of Kahtava Jussi (Nokia-CIC/Southwood)
Sent: Thursday, February 24, 2011 4:44 AM
To: [email-masked]; [email-masked]
Subject: Re: [paws] PS I-D: draft-patil-paws-problem-stmt-00.txt
 Hi Pyo,    I remain with the understanding that from the FCC requirements point of view the WS device does receive exactly identical information from each database, and coordination is not needed in order to fulfil the minimum criteria of avoiding interference. However, your concern does have a point when we consider country borders where cross-coordination issues exists as we expect will be the case in Europe. The available channels in country A will be different from those in country B, but both will be relevant for a device near the border area. Rather than require the device to figure out that it needs to coordinate between two regimes it makes much more sense for the relevant databases to coordinate and then have one of them provide the combined information to the device,  And of course, when we consider potential database services that go beyond the barebones needs of avoiding interference there may be benefits in databases talking to one
 another. So, I am not saying that such interface is not needed, only that for the available channel information a device must get it from any database in an identical manner without any need for the databases to exchange channel lists.  So, yes, the database-to-database interface will also be there but maybe Peter or someone else could share views on that, too.  Best regards,Jussi  --- original message ---From: "ext Chang-woo Pyo" <[email-masked]>Subject: Re: [paws] PS I-D: draft-patil-paws-problem-stmt-00.txtDate: 24th February 2011Time: 3:18:31   

Hi, Jussi

Best regards,
Pyo  

Hi Pyo, 

  

  
  
Kind regards, 
Jussi 

Thanks,
Pyo

---------------------------------------------------  Chang-Woo Pyo  Researcher,  Ubiquitous Mobile Comm. Group, NICT,  3-4, Hikarino-oka, Yokosuka, 239-0847, Japan,  Tel: +81-46-847-5120  ---------------------------------------------------  

Hello, 

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

--   ---------------------------------------------------  Chang-Woo Pyo  Researcher,  Ubiquitous Mobile Comm. Group, NICT,  3-4, Hikarino-oka, Yokosuka, 239-0847, Japan,  Tel: +81-46-847-5120  ---------------------------------------------------

---

From: Rex Buddenberg <[email-masked]>
Date: Fri, 25 Feb 2011 09:03:59 -0800

Confusing mechanism with policy.  It will not be PAWS' job to require
registration -- that would be an FCC action (in US).  

What PAWS should be doing is providing an appropriate mechanism.

---

From: <[email-masked]>
Date: Fri, 25 Feb 2011 17:17:40 +0000

Agree with your observation below.
Different regulatory bodies may specify varying requirements on the need
for registration.
PAWS should provide an enabler and mechanism for it. But the use of such
depends on its use in different regions.

On 2/25/11 11:03 AM, "ext Rex Buddenberg" <[email-masked]> wrote:

>> >> One additional thing which I think is relevant to Pyo¹ comment. When
>>a
>> >> I remain with the understanding that from the FCC requirements point
>>of view the WS device does receive exactly identical information from
>>each database, and coordination is not needed in order to fulfil the
>>minimum criteria of avoiding interference. However, your concern does
>>have a point when we consider country borders where cross-coordination
>>issues exists as we expect will be the case in Europe. The available
>>channels in country A will be different from those in country B, but
>>both will be relevant for a device near the border area. Rather than
>>require the device to figure out that it needs to coordinate between two
>>regimes it makes much more sense for the relevant databases to
>>coordinate and then have one of them provide the combined information to
>>the device,
>> >> 
>> >> And of course, when we consider potential database services that go
>>beyond the barebones needs of avoiding interference there may be
>>benefits in databases talking to one another. So, I am not saying that
>>such interface is not needed, only that for the available channel
>>information a device must get it from any database in an identical
>>manner without any need for the databases to exchange channel lists.
>> >> 
>> >> So, yes, the database-to-database interface will also be there but
>>maybe Peter or someone else could share views on that, too.
>> >> 
>> >> Best regards,
>> >> Jussi
>> >> 
>> >> --- original message ---
>> >> I don¹t quite understand the problem you are describing.
>> >> 
>> >> 
>> >> 
>> >> (3)     the geographic regions served by PLMRS/CMRS operations on
>> >> channels 1420,
>> >> 
>> >> queried. For example, the TV channel data is in FCC¹s own databases

---

From: Serge Manning <[email-masked]>
Date: Fri, 25 Feb 2011 11:22:53 -0600

Mobile WS devices do not register into the database. The power-on
registration requirement has been dropped by the FCC. Here is an excerpt:

*The Commission will not require Mode II personal/portable devices to
register in the database, because this would substantially increase the
number of registrations in the database, and each of these registrations
would have to be updated as device changes locations, thus substantially
increasing the database traffic. The Commission also sees no need for
registration of these devices as a means to help identify a source of
interference, as the interference range of personal/portable devices is in
general relatively short. In this regard, the Commission is correcting an
error in § 15.713(e)(4) of the rules which incorrectly states that Mode II
devices must register on initialization*

--Serge Manning
Huawei R&D

On Thu, Feb 24, 2011 at 4:19 PM, Rex Buddenberg <[email-masked]> wrote:

> > I remain with the understanding that from the FCC requirements point of
> view the WS device does receive exactly identical information from each
> database, and coordination is not needed in order to fulfil the minimum
> criteria of avoiding interference. However, your concern does have a point
> when we consider country borders where cross-coordination issues exists as
> we expect will be the case in Europe. The available channels in country A
> will be different from those in country B, but both will be relevant for a
> device near the border area. Rather than require the device to figure out
> that it needs to coordinate between two regimes it makes much more sense for
> the relevant databases to coordinate and then have one of them provide the
> combined information to the device,
> >
> beyond the barebones needs of avoiding interference there may be benefits in
> databases talking to one another. So, I am not saying that such interface is
> not needed, only that for the available channel information a device must
> get it from any database in an identical manner without any need for the
> databases to exchange channel lists.
> >
> > So, yes, the database-to-database interface will also be there but maybe
> Peter or someone else could share views on that, too.
> >
> > Best regards,
> > Jussi
> >
> > --- original message ---
> > channels 14–20,

-- 
--Serge

---

From: Serge Manning <[email-masked]>
Date: Fri, 25 Feb 2011 11:32:37 -0600

On Fri, Feb 25, 2011 at 9:10 AM, Warren Kumari <[email-masked]> wrote:

> I wanted to get a better idea of the required data and how dynamic it is
> likely to be, for example:
> A: is time important? Do we need to worry about cases where a local station
> transmits from 6AM to 9PM on weekdays, freeing up the space during the rest
> of the time? Or is this an unrealistic scenario?
>

[Serge] According to the FCC requirements, it is not really that dynamic. WS
devices are required to query the database once every 24 hours. At the time
of querying, the channel information provided should indicate the time used.
So in your example, above, it would indicate 6AM to 9AM. But this channel
use information from the database must be provided out to a 48 hour window.
This is because WS devices are allowed to operate until the end of the day
(11:59pm) since their last query. So a WS device might continue to operate
another 24 hours before it shuts down due to inability to access the
database.

> sucked down by devices will need to have some sort of timeout, validity
> period -- does this need to be an absolute time (like "This is good till
> 2011-03-22 11:35UTC") or something like a TTL? In eaihter case, are entries
> likely to be valid for months? Days? Seconds?  If wireless mics are a
> driver, what sort of mics are these? Are they used by production companies /
> news crews (and so might arrive in an area on sort notice) or more like
> fixed stage mics (and so are relatively static)?
>

[Serge] A small number of mics do not have to register in the database at
all. There are at least two channels dedicated for wireless mics where WS
devices are not allowed to operate.  Large events that might use a large
number microphones and must venture outside the two channels need to
register just like a fixed WS device ahead of time. So, this usage will be
in the database.

> The WS devices and databases all use 'X' and 'Y' to show "variables" --
> using different letters for each variable may avoid confusion (hey! I did
> say it was minor)
>
> W
>
>
>
>
> On Feb 22, 2011, at 10:23 AM, <[email-masked]> <
> [email-masked]> wrote:
>
>  Hello,
>>

-- 
--Serge Manning
Huawei R&D

---

From: <[email-masked]>
Date: Fri, 25 Feb 2011 17:53:33 +0000

The dynamism is again very regulator dependent. For example, in the UK there are plans for a two-hour channel validity time in maximum which is much shorter than the FCC requirement. The background is of course wireless microphones. This is not yet a binding rule but does give an idea of the wide range on WS parameters out there. So again, the mechanism needs to provide room for different timing etc requirements.

Kind regards,
Jussi

--- original message ---
From: "ext Serge Manning" <[email-masked]>
Subject: Re: [paws] PS I-D: draft-patil-paws-problem-stmt-00.txt
Date: 25th February 2011
Time: 6:32:54

On Fri, Feb 25, 2011 at 9:10 AM, Warren Kumari <[email-masked]<mailto:[email-masked]>> wrote:
I wanted to get a better idea of the required data and how dynamic it is likely to be, for example:
A: is time important? Do we need to worry about cases where a local station transmits from 6AM to 9PM on weekdays, freeing up the space during the rest of the time? Or is this an unrealistic scenario?

[Serge] According to the FCC requirements, it is not really that dynamic. WS devices are required to query the database once every 24 hours. At the time of querying, the channel information provided should indicate the time used. So in your example, above, it would indicate 6AM to 9AM. But this channel use information from the database must be provided out to a 48 hour window. This is because WS devices are allowed to operate until the end of the day (11:59pm) since their last query. So a WS device might continue to operate another 24 hours before it shuts down due to inability to access the database.

B: How dynamic is the data likely to be? I'm assuming that the entries sucked down by devices will need to have some sort of timeout, validity period -- does this need to be an absolute time (like "This is good till 2011-03-22 11:35UTC") or something like a TTL? In eaihter case, are entries likely to be valid for months? Days? Seconds?  If wireless mics are a driver, what sort of mics are these? Are they used by production companies / news crews (and so might arrive in an area on sort notice) or more like fixed stage mics (and so are relatively static)?

[Serge] A small number of mics do not have to register in the database at all. There are at least two channels dedicated for wireless mics where WS devices are not allowed to operate.  Large events that might use a large number microphones and must venture outside the two channels need to register just like a fixed WS device ahead of time. So, this usage will be in the database.

Oh, and a doc (very minor) nit:
Section 4 (Problem Statement), diagram.
The WS devices and databases all use 'X' and 'Y' to show "variables" -- using different letters for each variable may avoid confusion (hey! I did say it was minor)

W

On Feb 22, 2011, at 10:23 AM, <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>> wrote:

Hello,

-Basavaraj

--
--Serge Manning
Huawei R&D

---

From: <[email-masked]>
Date: Fri, 25 Feb 2011 17:58:59 +0000

And the dynamism may also depend on device types that are querying the database as well as current location in addition to what Jussi mentioned.
Hence the work needs to consider the requirements from a broader perspective than just those specified by FCC.

-Raj

From: Kahtava Jussi (Nokia-CIC/Southwood)
Sent: Friday, February 25, 2011 11:54 AM
To: ext Serge Manning; Warren Kumari
Cc: [email-masked]; Patil Basavaraj (Nokia-MS/Dallas)
Subject: Re: [paws] PS I-D: draft-patil-paws-problem-stmt-00.txt

Kind regards,

Jussi

--- original message ---

Date: 25th February 2011

Time: 6:32:54

W

-Basavaraj

--
--Serge Manning
Huawei R&D

---

From: Peter Stanforth <[email-masked]>
Date: Fri, 25 Feb 2011 15:57:47 -0500

I would suggest that using the FCC as a reference will lead to a lowest common denominator solution. While the FCC only requires that a WSD acquire a channel list every 24 hours I would argue that the scenarios below could justify solutions that check more often – and databases and devices could easily support within the FCC rule. In a simplification of the scenario where a channel is off limits from 6am to 9pm on Tuesday. A device that requests a channel list up to 24 hours in advance would not be permitted access to this channel (presuming it would not request for another 24 hours). But a simple tag that says "your channel list is only valid until 6am Tuesday " would let devices have access to that channel during the 24 hour period prior to the reserved slot. In urban areas where channels will be at a premium this could lead to a significant improvement. Note that even the FCC rules expect the WSD to request a new channel list inside the 24hours. The exception case is for it to keep operating for longer only if it cannot contact the database, which likely means it has no internet access and is effectively useless.

On the issue of microphones the FCC is very specific, but quite different from, Ofcom. The FCC explicitly distinguishes between licensed (Part 74) wireless microphones and unlicensed wireless microphones. Licensed microphones are registered in the ULS and are permitted to register individual and recurring time/location/channel events to be provided protection in a DB.   The FCC requires at least 2 channels be reserved for unlicensed wireless microphones, but if you add the adjacent channels below 20 (which are off limits to fixed WSDs and personal portable WSDs) then wireless microphones have at least 4 or 5 dedicated channels and typically 6 or 7. These unlicensed microphones can also act like a WSD and use the other white space channels, albeit while accepting interference from WSDs. The FCC does allow for unlicensed wireless microphones operators to make a case for  having more reserved channels, with no guarantee that they will be permitted, and the FCC will inform the DB operators of a successful application similar to a licensed microphone registration.

From: Serge Manning <[email-masked]<mailto:[email-masked]>>
Date: Fri, 25 Feb 2011 12:32:37 -0500
To: Warren Kumari <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "<[email-masked]<mailto:[email-masked]>>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [paws] PS I-D: draft-patil-paws-problem-stmt-00.txt

W

Hello,

-Basavaraj

--
--Serge Manning
Huawei R&D

---

From: Serge Manning <[email-masked]>
Date: Fri, 25 Feb 2011 16:14:46 -0600

Just to clarify, I am in complete agreement that the FCC requirements are
one of the *minimal *regional inputs that we should consider here. Even the
FCC is encouraging value added services by database administrators (and with
multiple administrators around, this seems like a necessary requirement to
stay in business) as well offering opportunities to enhance the efficiency
of spectrum operation in the future. The tool set developed here should
support that.

On Fri, Feb 25, 2011 at 2:57 PM, Peter Stanforth
<[email-masked]>wrote:

> I would suggest that using the FCC as a reference will lead to a lowest
> common denominator solution. While the FCC only requires that a WSD acquire
> a channel list every 24 hours I would argue that the scenarios below could
> justify solutions that check more often – and databases and devices could
> easily support within the FCC rule. In a simplification of the scenario
> where a channel is off limits from 6am to 9pm on Tuesday. A device that
> requests a channel list up to 24 hours in advance would not be permitted
> access to this channel (presuming it would not request for another 24
> hours). But a simple tag that says "your channel list is only valid until
> 6am Tuesday " would let devices have access to that channel during the 24
> hour period prior to the reserved slot. In urban areas where channels will
> be at a premium this could lead to a significant improvement. Note that even
> the FCC rules expect the WSD to request a new channel list inside the
> 24hours. The exception case is for it to keep operating for longer only if
> it cannot contact the database, which likely means it has no internet access
> and is effectively useless.
>
> On the issue of microphones the FCC is very specific, but quite different
> from, Ofcom. The FCC explicitly distinguishes between licensed (Part 74)
> wireless microphones and unlicensed wireless microphones. Licensed
> microphones are registered in the ULS and are permitted to register
> individual and recurring time/location/channel events to be provided
> protection in a DB.   The FCC requires at least 2 channels be reserved for
> unlicensed wireless microphones, but if you add the adjacent channels below
> 20 (which are off limits to fixed WSDs and personal portable WSDs) then
> wireless microphones have at least 4 or 5 dedicated channels and typically 6
> or 7. These unlicensed microphones can also act like a WSD and use the other
> white space channels, albeit while accepting interference from WSDs. The FCC
> does allow for unlicensed wireless microphones operators to make a case for
>  having more reserved channels, with no guarantee that they will be
> permitted, and the FCC will inform the DB operators of a successful
> application similar to a licensed microphone registration.
>
>
> From: Serge Manning <[email-masked]>
> To: Warren Kumari <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>, "<[email-masked]>" <
> [email-masked]>
>> station transmits from 6AM to 9PM on weekdays, freeing up the space during
>> the rest of the time? Or is this an unrealistic scenario?
>>
>
> [Serge] According to the FCC requirements, it is not really that dynamic.
> WS devices are required to query the database once every 24 hours. At the
> time of querying, the channel information provided should indicate the time
> used. So in your example, above, it would indicate 6AM to 9AM. But this
> channel use information from the database must be provided out to a 48 hour
> window. This is because WS devices are allowed to operate until the end of
> the day (11:59pm) since their last query. So a WS device might continue to
> operate another 24 hours before it shuts down due to inability to access the
> database.
>
>
>>

-- 
--Serge