Re: [paws] WG Review: Protocol to Access White Space database (paws)

["Joel M. Halpern" <[e-mail]>]

I think this working group is a good idea.
My inclination would be to place it in the Applications area.  It looks 
like a nice application protocol to me.
There is a reasonable argument for placing it in RAI, as that is where 
the relevant GEOLOC work has been done up till now.

Yours,
Joel M. Halpern

On 4/19/2011 12:56 PM, IESG Secretary wrote:
> A new IETF working group has been proposed.  The IESG has not made any
> determination as yet. The following draft charter was submitted, and is
> provided for informational purposes only. Please send your comments to the
> IESG mailing list ([e-mail]) by Tuesday, April 26, 2011.
>
>
> Protocol to Access White Space database (paws)
> ------------------------------------------------
> Current Status: Proposed Working Group
> Last updated: 2011-04-14
>
> Chairs:
> TBD
>
> Area Directors:
> TBD
>
> Area Advisor:
> TBD
>
> Mailing lists:
> Address: [e-mail]
> To Subscribe: https://www.ietf.org/mailman/listinfo/paws
> Archive: http://www.ietf.org/mail-archive/web/paws/
>
> Description of Working Group:
>
> 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
> 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 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, thus extensibility of data structures will be required. 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.
>
> 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.
> - Standardize the data structure to be carried by the query
> protocol.
>
> The protocol must protect both the channel enablement process and the
> privacy of users. Robust security mechanisms are required to prevent:
> device identity spoofing, modification of device requests, modification
> of channel enablement information, impersonation of registered database
> services and unauthorized disclosure of a users location.
>
> Existing IETF location data structures and privacy mechanisms may be
> considered for use. The WG will also investigate the need for other
> mechanisms and related protocols to the White Space DB.
>
> The Working Group will set up and maintain appropriate contact and
> liaison with other relevant standards bodies and groups, including IEEE
> 802.11af and IEEE 802.22 to begin with. The working group may also
> consider input from regulatory entities that are involved in the
> specification of the rules for secondary use of spectrum in specific
> bands.
>
> Goals and 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
>
> Apr 2012  Submit 'Data Model for Whitespace query protocol' to the
>            IESG for publication as Proposed Standard
> _______________________________________________
> paws mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/paws
>