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

[Rex Buddenberg <[e-mail]>]

On Tue, 2011-04-19 at 12:47 -0700, 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.

While the DNS analogy works, I was thinking more a parallel -- or
extension -- of SNMP.  

Still remain within 'applications', Joel?

> 
> 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: [e-mail] [mailto:[e-mail]] On Behalf Of
> > Joel M. Halpern
> > Sent: Tuesday, April 19, 2011 10:50 AM
> > To: [e-mail]
> > Cc: [e-mail]; 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 ([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
> > >
> > _______________________________________________
> > paws mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/paws
> _______________________________________________
> paws mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/paws