Subject: [paws] proposed charter

From: <[email-masked]>
Date: Fri, 11 Mar 2011 01:36:54 +0000

Here's the proposed charter of the WG to be formed (if approved):

Governments around the world continue to search for new pieces of radio spectrum which can be used by the expanding wireless communications industry to provide more services in the usable spectrum.  The concept of allowing secondary transmissions (licensed or unlicensed) in frequencies allocated to a primary user 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. Often, in a given physical location, the primary user(s) may not be using the entire band allocated to them.  The available spectrum for a secondary use would then depend on the location of the secondary user.  The primary user may have a schedule when it uses the spectrum, which may be available for secondary use outside that schedule.  The fundamental issue is how to determine for a specific location and specific time, if any of the primary spectrum is available for secondary use. One simple mechanism is to use a geospatial database that records protected contours for primary users, and require the secondary users to check the database prior to selecting what part of the spectrum they use.  Such databases could be available on the Internet for query by secondary users.

In a typical implementation of geolocation and database to access TV white space, a radio is configured with, or has the capability to
determine its location in latitude and longitude.   At power-on,
before the device can transmit or use any of the spectrum set aside for secondary use, the device must identify the relevant database to query, contact the database, provide its geolocation and receive in return a list of  unoccupied or "white space" spectrum (for example, in a TV White space implementation, the list of available channels at that location).
The device can then select one of the channels from the list and begin to transmit and receive on the selected channel. The device must query the database subsequently on a periodic basis for a list of unoccupied channels based on certain conditions, e.g. a fixed amount of time has passed or the device has changed location beyond a specified threshold.

The proposed working group will :
   - standardize a protocol for querying the database, which includes  a location sensitive database discovery mechanism and security for  the protocol, and application services.

The databases are expected to be reachable via the Internet and the devices querying these databases are expected to have some form of Internet connectivity, directly or indirectly. The databases  may be country specific since the available spectrum and  regulations may vary, but the fundamental operation of the protocol should be country independent. The solution will not be tied to any specific spectrum, country, or phy/mac/air interface but may incorporate relevant aspects of these as needed for proper operation.

Since the location of a user device is involved, privacy implications arise, and the protocol will have to have robust security mechanisms.
Existing IETF location data structures and privacy mechanisms may be considered for use. Database discovery may also make use of existing IETF work including, possibly, LoST (RFC5222).

Milestones

Sep 2011        Submit 'Requirements and Framework' to the IESG for
               publication as Informational
Apr 2012        Submit 'Protocol for Querying a Whitespace Database'
               to the IESG for publication as Proposed Standard

Let us know if you have any comments
-Gabor

---

From: <[email-masked]>
Date: Fri, 11 Mar 2011 05:14:58 +0000

Hi Gabor,

You may also mention in the charter that the WG will establish liaisons
with IEEE 802 (as needed) to not only obtain any requirements for specific
air interfaces being developed therein for use in such spectrum but to
also keep them updated on the scope of the work done here.

-Raj

On 3/10/11 7:36 PM, "ext [email-masked]" <[email-masked]>
wrote:

>Governments around the world continue to search for new pieces of radio
>spectrum which can be used by the expanding wireless communications
>industry to provide more services in the usable spectrum.  The concept of
>allowing secondary transmissions (licensed or unlicensed) in frequencies
>allocated to a primary user 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. Often, in a given
>physical location, the primary user(s) may not be using the entire band
>allocated to them.  The available spectrum for a secondary use would then
>depend on the location of the secondary user.  The primary user may have
>a schedule when it uses the spectrum, which may be available for
>secondary use outside that schedule.  The fundamental issue is how to
>determine for a specific location and specific time, if any of the
>primary spectrum is available for secondary use. One simple me
> chanism is to use a geospatial database that records protected contours
>for primary users, and require the secondary users to check the database
>prior to selecting what part of the spectrum they use.  Such databases
>could be available on the Internet for query by secondary users.
>
>In a typical implementation of geolocation and database to access TV
>white space, a radio is configured with, or has the capability to
>before the device can transmit or use any of the spectrum set aside for
>secondary use, the device must identify the relevant database to query,
>contact the database, provide its geolocation and receive in return a
>list of  unoccupied or "white space" spectrum (for example, in a TV White
>space implementation, the list of available channels at that location).
>The device can then select one of the channels from the list and begin to
>transmit and receive on the selected channel. The device must query the
>database subsequently on a periodic basis for a list of unoccupied
>channels based on certain conditions, e.g. a fixed amount of time has
>passed or the device has changed location beyond a specified threshold.
>
>   - standardize a protocol for querying the database, which includes  a
>location sensitive database discovery mechanism and security for  the
>protocol, and application services.
>
>The databases are expected to be reachable via the Internet and the
>devices querying these databases are expected to have some form of
>Internet connectivity, directly or indirectly. The databases  may be
>country specific since the available spectrum and  regulations may vary,
>but the fundamental operation of the protocol should be country
>independent. The solution will not be tied to any specific spectrum,
>country, or phy/mac/air interface but may incorporate relevant aspects of
>these as needed for proper operation.
>
>Since the location of a user device is involved, privacy implications
>arise, and the protocol will have to have robust security mechanisms.
>Existing IETF location data structures and privacy mechanisms may be
>considered for use. Database discovery may also make use of existing IETF
>work including, possibly, LoST (RFC5222).
>
>Milestones
>
>_______________________________________________
>paws mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/paws

---

From: "Richard Shockey" <[email-masked]>
Date: Sat, 12 Mar 2011 16:13:33 -0500

This is a good start .. I would suggest that you add two potential work
items. You mention the solution is not tied to any particular country so I
would add. "extensibility of data structures will be required" 

"Data Structure for White Space Databases"

"Provisioning Mechanisms for White Space Databases"

The basic data in data out issue.

This would fall into line with the bulk of IETF work on various
Registry/Registrar/Registrant protocols.

As for data base discovery .. you don't have a milestone for that and
frankly I'm not sure if you want to bite off that issue in the first round
of chartering. Frankly I'd delete the sentence and put some sort of generic
catch all sentence such as  the WG will investigate other related protocols
to the White Space DB ... as needed .. blah blah. 

You may want to look as some of the deliberately ambiguous language I used
in the ENUM WG charter.

http://datatracker.ietf.org/wg/enum/charter/

3. The working group will continue examine and document various aspects
of White Spaces administrative and /or operational procedures.

5. The Working Group will continue to maintain appropriate contact and
liaison with other standards bodies and groups, specifically IEEE xxx,

In addition the Working Group will continue to encourage the
exchange of technical information within the emerging global White Spaces
community as well as documentation on practical experiences with
implementations, alternate technology uses and the administration and
provisioning of White Spaces databases etc.

Of course you will have the issue of what is the structure of the data
objects. IF IF the WG chooses XML there is coordination with the IETF XML
directorate. There is a considerable body of IETF using JSON as well these
days.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Friday, March 11, 2011 12:15 AM
To: [email-masked]; [email-masked]
Subject: Re: [paws] proposed charter

Hi Gabor,

-Raj

---

From: <[email-masked]>
Date: Mon, 14 Mar 2011 08:29:59 +0000

Hi Richard,

In my opinion, "Data Structure for White Space Databases" is beyond the scope required. The protocol defines data structures for the request/response, but this is different from the data structure for the database. Sure defining the protocol may make some data structures inside the database seem obvious, but how to implement the database is up to vendor choice, right?

If "Provisioning Mechanisms for White Space Databases" means mechanisms for the white space device to enter information to the database, your comment makes sense to me as a good clarification. If it means entering protected entity (TV transmitters, microphones or other primary user data) information to the database, this is beyond my interpretation of the required scope.

Just my two cents.

Regards,
Scott

-----Original Message-----

Hi Gabor,

-Raj

---

From: Peter Stanforth <[email-masked]>
Date: Mon, 14 Mar 2011 07:22:04 -0400

Scott I agree with you about the data structures in the DB. If you compare FCC and Ofcom datasets, that are the input to the DB they are very different. Plus there are differences in the ways that microphone data is provided. 

SBI will be willing to contribute and participate 

Peter Stanforth

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 14 Mar 2011 11:16:56 -0400

Perhaps I wasn't clear .. the core Protocol for White Spaces databases is
actually two elements that generally look like two distinct documents in
IETF terms. One is what is the query/response mechanism the second is the
structure and definition of the data payload. 

Scott your clarification on the provisioning issue is accurate.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Peter Stanforth
Sent: Monday, March 14, 2011 7:22 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [paws] proposed charter

Scott I agree with you about the data structures in the DB. If you compare
FCC and Ofcom datasets, that are the input to the DB they are very
different. Plus there are differences in the ways that microphone data is
provided. 

Peter Stanforth

On Mar 14, 2011, at 4:30 AM, "[email-masked]"
<[email-masked]> wrote:

> Hi Richard,
> 
> In my opinion, "Data Structure for White Space Databases" is beyond the
scope required. The protocol defines data structures for the
request/response, but this is different from the data structure for the
database. Sure defining the protocol may make some data structures inside
the database seem obvious, but how to implement the database is up to vendor
choice, right?
> 
> If "Provisioning Mechanisms for White Space Databases" means mechanisms
for the white space device to enter information to the database, your
comment makes sense to me as a good clarification. If it means entering
protected entity (TV transmitters, microphones or other primary user data)
information to the database, this is beyond my interpretation of the
required scope.
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
ext Richard Shockey

---

From: Andrew Gowans <[email-masked]>
Date: Mon, 14 Mar 2011 15:49:26 +0000

All,

I know Gary Clemo has been following this from an Ofcom consultation perspective but I have been more involved in the harmonisation activities within the European regulatory forums. I suppose from my perspective it would be useful to try and get an idea where your work and the work being undertaken in IEEE 802 will impact on the eventual ETSI harmonised standard. This will be the equipment standard that vendors will have declare compliance with in order to place products on the European Market.

Please see attached presentation I did to a webinar organised by ECO last month which hopefully will give you some clarity on the European regulatory process. It also outlines our current thinking regarding who we see as the responsible entities when discussing suitable data elements and/or data structures and their appropriate protocols for the different interactions with the Database providers and their databases. It also tries to highlight some of the areas that are different and still have to be dealt with regarding standardisation within Europe and the rest of the world. In the presentation I highlight the role of standards bodies (particularly ETSI for Europe) on the top right hand side of the diagram and try to identify in slides some of the information that will need to be covered by the standards process but I think these are only the tip of the iceberg.

I know this may raise more questions than answers but I hope it helps to give a view of the regulatory environment in Europe which you may have to consider further in your deliberations. Happy to discuss further and answer any questions or queries for clarification.

Regards

Andy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter Stanforth
Sent: 14 March 2011 11:22
To: [email-masked]
Cc: [email-masked]
Subject: Re: [paws] proposed charter

Peter Stanforth

*****************************************************************************************************************
For more information visit www.ofcom.org.uk

This email (and any attachments) is confidential and intended for the use of the addressee only.

If you have received this email in error please notify the originator of the message and delete it from your system.

This email has been scanned for viruses. However, you open any attachments at your own risk.

Any views expressed in this message are those of the individual sender and do not represent the views or opinions of Ofcom unless expressly stated otherwise.
******************************************************************************************************************

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 14 Mar 2011 12:08:43 -0400

This is helpful, thank you.

I think slide 19 contains useful information.

Certainly, nothing here would change our approach or our charter.  I'd probably edit the problem statement a bit (power levels as a return from the database for example is not discussed).

I do think our proposed work would fit very nicely into the regulatory framework this presentation discusses. Databases and devices built to the resulting protocol ought to be able to function well.

Brian

On Mar 14, 2011, at 11:49 AM, Andrew Gowans wrote:

> <A new challenge – creating a regulatory environment for implementing geo-location databases for White Space Devices v1.1.pptx><ATT00001..txt>

---

From: Andrew Gowans <[email-masked]>
Date: Mon, 14 Mar 2011 18:09:09 +0000

Actually just noticed that I have sent the wrong slide set. You may all be confused from slide 21 onwards as I have sent the next evolution of the original presentation I did that I am still in the process of completing sorry for any confusion. See attached for the original slide set I presented.

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: 14 March 2011 16:09
To: Andrew Gowans
Cc: Peter Stanforth; [email-masked]; [email-masked]; Gary Clemo
Subject: Re: [paws] proposed charter

Brian