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

Cullen Jennings <fluffy@cisco.com> Wed, 20 April 2011 18:23 UTC

Return-Path: <fluffy@cisco.com>
X-Original-To: ietf@ietfc.amsl.com
Delivered-To: ietf@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id DA961E073E; Wed, 20 Apr 2011 11:23:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.585
X-Spam-Level:
X-Spam-Status: No, score=-110.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8OyrxvdSFUpK; Wed, 20 Apr 2011 11:23:06 -0700 (PDT)
Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfc.amsl.com (Postfix) with ESMTP id 1B556E0732; Wed, 20 Apr 2011 11:23:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=6676; q=dns/txt; s=iport; t=1303323784; x=1304533384; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=cKWdl2kHU2VpnLzKGXA0YOivG8TR6L1jmr/qqaZYrbI=; b=L7EX/3xDU9IhWbHFzGX45TeGG40lYliI1q0Z4Vh5H1p6RaIdcUkNmHPH gr11XtroipU52Dn74kneulu6/1kGFZGKoTIYyqU+bOvEhyd8Hnm/Bq5FA 6Sy48kxo4EGy46uKpjauYuJHrT/KY1HAOWj0+JXW1xPMh+Ev/CxOf/LLD Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AkgBAG8jr02rRDoJ/2dsb2JhbACXM44Kd4hvojmcdoJ/AYJxBIV0iC6Df4of
X-IronPort-AV: E=Sophos;i="4.64,247,1301875200"; d="scan'208";a="298657412"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-3.cisco.com with ESMTP; 20 Apr 2011 18:23:03 +0000
Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p3KIN2A6012654; Wed, 20 Apr 2011 18:23:02 GMT
Subject: Re: [paws] WG Review: Protocol to Access White Space database (paws)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Cullen Jennings <fluffy@cisco.com>
In-Reply-To: <4DADCB52.1020309@joelhalpern.com>
Date: Wed, 20 Apr 2011 12:23:01 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <76B1A6A1-F704-45F3-9A82-C590308C60F7@cisco.com>
References: <20110419165634.CD24CE07CF@ietfc.amsl.com> <4DADCB52.1020309@joelhalpern.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>
X-Mailer: Apple Mail (2.1084)
Cc: paws@ietf.org, IETF discussion list <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Apr 2011 18:23:08 -0000

GEOLOC has been a WG that is somewhat on the edge between Apps and RAI. Much of what geoloc was doing, particularly the location for emergency calling, had real time issues and the interested people largely lined up with the the other RAI groups even though geoloc has uses outside anything to do with SIP. PAWS on the other hand does not seem to have real time application issues so it seems like Apps is probably a more appropriate area for it. 

Cullen


On Apr 19, 2011, at 11:50 AM, Joel M. Halpern wrote:

> 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@ietf.org) 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@ietf.org
>> 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@ietf.org
>> https://www.ietf.org/mailman/listinfo/paws
>> 
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf