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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Clearly, the discussion about whether the application protocol should be XML, plain ASCII/UTF8, binary, or some other encoding needs to take place. But that can take place wherever we place the working group.

There is an argument, which you allude to, which would place this WG in the Internet Area as part of "infrastructure." While that does not resonate with me, I do see that there is some merit in that perspective.

I tend to think we need to focus on transactional application experience (the apps area) or where we have experience with protocols that need to communicate geolocation (RAI).

I would hope, and expect, that the ADs for any area would be receptive to a proper evaluation of any candidate protocol and encoding. (The arguments get complex, and it takes care to avoid religious assertions.)

Yours,
Joel

On 4/19/2011 3:47 PM, Paul Lambert wrote:


How does the area that the group is assigned impact the choices of technology?

I'm an advocate for an efficient solution set for PAWS ... it will be much like DNS for spectrum in the future and should be viewed as a core infrastructural component that needs careful design.  There are good reasons that routing protocols don't use XML.

Applications now days tend to go for the simple, quick to make a web application solutions using XML or the like ...  My concern is that "Applications" imply that efficiency does not matter.

Paul



-----Original Message-----
From: paws-bounces@xxxxxxxx [mailto:paws-bounces@xxxxxxxx] On Behalf Of
Joel M. Halpern
Sent: Tuesday, April 19, 2011 10:50 AM
To: iesg@xxxxxxxx
Cc: paws@xxxxxxxx; IETF discussion list
Subject: Re: [paws] WG Review: Protocol to Access White Space database
(paws)

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 (iesg@xxxxxxxx) 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: paws@xxxxxxxx
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
paws@xxxxxxxx
https://www.ietf.org/mailman/listinfo/paws

_______________________________________________
paws mailing list
paws@xxxxxxxx
https://www.ietf.org/mailman/listinfo/paws

_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]