Hi,=

This is Sajeev, interested in = whitespace protocols, and an observer of this group. Reading through the ch= arter I would like to clarify the following.

In the = below paragraph radio device discovers whitespace channel availability time= to time. What happens when the radio device does not find any channels ava= ilable to initiate transmission, or if it happen during a session? Will the= communication be broken, or the radio devices use this as a secondary mean= s of communication? Would like to get some clarity..

Once the device learns of the available white space (e.g., in a TV
white space implementation, the list of available channels at thatlocation), it can then select one of the bands from the list and
begin= to transmit and receive on the selected band. If the device's
par= ameters have changed (e.g., if some amount of time has passed or if
the = device has changed location beyond a specified threshold), it might
need= to query the database again to determine what white space is still
avai= lable.

Sajeev Manikkoth
Mob= ile: +919663311378

Email: mksaji@ieee.org
http://www.l= inkedin.com/in/mksajeev

From: Peter Saint-Andre <stpeter= @stpeter.im>
To: "pa= ws@ietf.org" <paws@ietf.org>
Sent: Friday, 3 June 2011, 7:56
Subject: [paws] updated charter

Here is = the charter the emerged from discussions among IESG members and
with the= BoF chairs.

###

Protocol to Access White Space database (paw= s)
------------------------------------------------
Current Status: P= roposed Working Group
Last updated: 2011-06-02

Chairs:
TBD
=
Applications Area Directors:
Pete Resnick <p= resnick@qualcomm.com>
Peter Saint-Andre <stpeter@stpeter.im>

Appli= cations Area Advisor:
Peter Saint-Andre <stpeter@stpet= er.im>

Mailing lists:
General Discussion: paws@ietf.o= rg
To Subscribe: https://www.ietf.org/mailman/listinfo/p= aws
Archive: http://www.ietf.org/mail-archive/web/paws/<= /a>

Description of Working Group:

Background

Radio spe= ctrum is a limited resource. National and international
bodies ass= ign different frequencies for specific uses, and in
most cases license t= he rights to use these frequencies. Locally
unused spectrum is com= monly called "white space" and may be made
available to other services on a b= asis of non-interference with
the primary user of the frequencies concer= ned (if any). This
technique can help "unlock" existing spectrum, for ex= ample to
enable the wireless communications industry to provide more
= services over frequencies associated with unused television
channels.&nb= sp; An obvious requirement is that white space uses must
not interfere w= ith the primary use of the spectrum. This is
achieved through spat= ial and/or temporal separation of the
primary user and whitespace user w= ith due consideration made to
the radio characteristics of the two uses.=

Problem Statement

The fundamental problem is enabling a radi= o device to determine, in
a specific location and at specific time, if a= ny white space is
available for secondary use. There are two parti= es to such an
interaction:

1. A database containing records about the protected contours (in
space and time) of primary spe= ctrum users. Typically, such databases
will be populated and opera= ted by the appropriate spectrum regulation
bodies in a given locale.
=
2. A radio device that wishes to query such a database. Typically, the<= br>the nature of the query will depend on the needs of the device.

T= he contents of white space databases, and the needs of radio devices,
ar= e being defined elsewhere. However, these parties need a protocol
= for communication that will enable radio devices to find out what white
= space is available at a given time in a given location.

It is expect= ed that white space databases will be reachable via the
Internet, and th= at radio devices too will have some form of Internet
connectivity, direc= tly or indirectly. Therefore, it is appropriate
to define an Inter= net-based protocol for querying white space databases
and receiving responses from such databases.

In rough outline, such a p= rotocol would enable a radio device that
knows its location to complete = the following tasks:

1. Determine the relevant white space database = to query.

2. Connect to the database using a well-defined access met= hod.

3. Provide its geolocation and perhaps other data to the databa= se
using a well-defined wire format for querying the database.
4. Receive in return a list of currently available white space
&nb= sp; using a well-defined wire format for returning information.

Onc= e the device learns of the available white space (e.g., in a TV
white sp= ace implementation, the list of available channels at that
location), it= can then select one of the bands from the list and
begin to transmit an= d receive on the selected band. If the device's
parameters have ch= anged (e.g., if some amount of time has passed or if
the device has changed location beyond a specified threshold), it might
need to qu= ery the database again to determine what white space is still
available.=

Objectives

The overall goals of this working group are to:
1. Standardize a mechanism for discovering a white space database.
2. Standardize a method for accessing a white space database.

3= . Standardize wire formats to be carried over the database
access method= (i.e., formats for queries and responses).

4. Ensure that the disco= very mechanism, database access method,
and wire formats have appropriat= e security levels in place.

By "standardize" is not meant that the w= orking group will necessarily
develop new technologies. In complet= ing its work, the group will:

- Evaluate existing discovery mechanis= ms to determine if one of
them provides the necessary application= features and security
properties (or can be extended to do so) for discovering a
white space database. Examples mi= ght include DNS.

- Evaluate existing application-layer transport pro= tocols to
determine if one of them provides the necessary applica= tion
features and security properties (or can be extended to do s= o)
for use as a building block for communication between location= -
aware devices and white space databases. If such a method=
exists, the group will reuse it; if not, the group will develop<= br> one. Examples might include HTTP.

- Develop a method= for querying a white space database. Such
a method will ut= ilize, so far as possible, the features of
the application-layer = transport protocol and not re-implement
them in the new protocol.= It will include mechanisms to verify
that the requests and respo= nses come from authorized sources,
and that they have not been modified in transit. Examples might
include LDAP.
=
- Define extensible wire formats for both location-specific queries
= and location-specific responses for interaction with radio white
= space databases. The group will consider whether existing data=
formats can be reused.

The protocol must protect both the= channel enablement process and the
privacy of users. Robust priva= cy and security mechanisms are needed
to prevent: device identity spoofi= ng, modification of device requests,
modification of channel enablement = information, impersonation of
registered database services, and unauthor= ized disclosure of a device's
location. The group will consider wh= ether existing privacy and
security mechanisms can be reused.

The= task of defining the structure and contents of the databases
themselves= is out of scope. The group will standardize wire formats
for communication between devices and databases, but not the in= formation
models for the databases, since those models are likely to be<= br>country-specific or application-specific. In addition, the particu= lar
data exchanged between a device and a database might depend on theranges of radio spectrum that are to be used, the requirements of the
= database operators and their governing regulations, and other factors.
T= herefore, the database access method and the query/response data
formats= that are exchanged using that method need to be designed for
extensibil= ity rather than being tied to any specific spectrum, country,
or phy/mac= /air interface. For example, the working group should define
exten= sion points for the database access method and the wire formats
that are= used to query a database and respond to queries, so that use
cases othe= r than those currently envisioned can be addressed in the
future if a community of interest wishes to do so. However, the
access m= ethod and wire formats will incorporate relevant aspects of
the paramete= rs needed for the currently envisioned use cases to ensure
proper operat= ion.

In accordance with existing IETF processes, the group will comm= unicate
and invite participation with other relevant standards bodies an= d
groups, and if necessary reuse existing liaison relationships or
re= quest the establishment of new liaison relationships, including but
not = limited to IEEE 802.11af and IEEE 802.22. In order to ensure that
= it takes into account a broad range of possible use cases and
requiremen= ts, the group should also reach out to other potential
"customers" for a= white space database access method and consider input
from regulatory e= ntities that are involved in the specification of the
rules for secondar= y use of spectrum in specific radio bands.

Deliverables

1. A description of the relevant use cas= es and requirements. This
document shall be Informational. S= ubject to working group consensus,
draft-probasco-paws-overview-usecases= and draft-patil-paws-problem-stmt
might be used as a starting point.
2. A specification of the mechanism for discovering a white space
d= atabase, the method for accessing a white space database, and the
wire f= ormat for querying and receiving responses from a white space
database.&= nbsp; This document shall be Standards Track.

Milestones

Oct = 2011 Submit 'Use Cases and Requirements for Accessing a Radio White
Spac= e Database' to the IESG for publication as Informational

Apr 2012 Su= bmit 'Accessing a Radio White Space Database' to the IESG
for publicatio= n as Proposed Standard

###

______________________= _________________________
paws mailing list
paws@ietf.o= rg
https://www.ietf.org/mailman/listinfo/paws

--0-1974052181-1307183235=:1524-- From scott.probasco@nokia.com Mon Jun 6 02:32:11 2011 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB12511E80E7 for ; Mon, 6 Jun 2011 02:32:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fKxv8D2rjUtk for ; Mon, 6 Jun 2011 02:32:10 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id DFE4511E80D3 for ; Mon, 6 Jun 2011 02:32:09 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p569VTwc031454; Mon, 6 Jun 2011 12:32:07 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 6 Jun 2011 12:31:24 +0300 Received: from 008-AM1MMR1-002.mgdnok.nokia.com (65.54.30.57) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 6 Jun 2011 11:31:23 +0200 Received: from 008-AM1MPN1-021.mgdnok.nokia.com ([169.254.1.188]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.01.0289.008; Mon, 6 Jun 2011 11:31:23 +0200 From: To: , , Thread-Topic: [paws] updated charter Thread-Index: AQHMIZW5XxXLw3+lW0G8ZPdPMB68Z5Ss3z+AgAMysuA= Date: Mon, 6 Jun 2011 09:31:22 +0000 Message-ID: <88BE24FD9280884487DEAE0CE1FD3A5B0319B242@008-AM1MPN1-021.mgdnok.nokia.com> References: <4DE8466C.9010201@stpeter.im> <205283.1524.qm@web34508.mail.mud.yahoo.com> In-Reply-To: <205283.1524.qm@web34508.mail.mud.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-version: 3.3.8.1 x-tituslabs-classifications-30: TLPropertyRoot=Trial License;Classification=Personal; x-putclassificationandsendinfointox-header: Classification: Personal Project: Subject: RE: [paws] updated charter Sender Name: Probasco Scott (Nokia-CIC/Dallas) Sender Email: scott.probasco@nokia.com Send Date: Monday, June 06, 2011 Send Time: 4:31:22 AM x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7Impg+JeSc+lISYAkH6dnOLqzr7Rmj/XdR2/ORg+Pl4AmrIIrkvyWZ/i2LOcua/KZladIRCLtTkU1f3y2167jm+G+gVnxYYYqf1Tx7jK3LYYi6S9OajKDKj72fyCovA+NYepfs9C7NldiMj2tCSo4UMPpWc1K8F08En/nk9a7+T4ciKNXoAmt5stP1f7p8LXqaw== x-originating-ip: [212.213.221.214] Content-Type: multipart/alternative; boundary="_000_88BE24FD9280884487DEAE0CE1FD3A5B0319B242008AM1MPN1021mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 06 Jun 2011 09:31:24.0071 (UTC) FILETIME=[808BD370:01CC242C] X-Nokia-AV: Clean Subject: Re: [paws] updated charter X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database $PAWS$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 09:32:12 -0000 --_000_88BE24FD9280884487DEAE0CE1FD3A5B0319B242008AM1MPN1021mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sajeev, If the database replies with an empty channel list (no channels available) = then the white space radio must not transmit. Once a channel list is received with at least one available channel, the wh= ite space radio may transmit on one of the available channels. Typically, t= he white space radio must contact the database regularly to ensure channel = availability. If the white space radio is not able to contact the database,= then the radio must cease transmission in white space within some period o= f time. The specific details are specified by the local regulator (e.g. FCC= in the US, Ofcom in the UK, etc). The white space communication will ultimately be broken if contact with the= database is lost. Your question about using white space as a secondary mea= ns of communication is a reasonable question, but beyond the scope of the d= atabase interface. For example, a device may use cellular radio, WiFi and w= hite space radios, switching radios based on some arbitrary decisions (such= as power consumption, QoS, subscription rate, etc). However this type of s= witching scenario is beyond the scope of the database interface and therefo= re PAWS. IMHO, these are good questions about typical system operation, but have no = impact to the charter text. Regards, Scott From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext= M.K.Sajeev sajeev Sent: Saturday, June 04, 2011 5:27 AM To: Peter Saint-Andre; paws@ietf.org Subject: Re: [paws] updated charter Hi, This is Sajeev, interested in whitespace protocols, and an observer of this= group. Reading through the charter I would like to clarify the following. In the below paragraph radio device discovers whitespace channel availabili= ty time to time. What happens when the radio device does not find any chann= els available to initiate transmission, or if it happen during a session? W= ill the communication be broken, or the radio devices use this as a seconda= ry means of communication? Would like to get some clarity.. Once the device learns of the available white space (e.g., in a TV white space implementation, the list of available channels at that location), it can then select one of the bands from the list and begin to transmit and receive on the selected band. If the device's parameters have changed (e.g., if some amount of time has passed or if the device has changed location beyond a specified threshold), it might need to query the database again to determine what white space is still available. Sajeev Manikkoth Mobile: +919663311378 Email: mksaji@ieee.org http://www.linkedin.com/in/mksajeev _____ From: Peter Saint-Andre To: "paws@ietf.org" Sent: Friday, 3 June 2011, 7:56 Subject: [paws] updated charter Here is the charter the emerged from discussions among IESG members and with the BoF chairs. ### Protocol to Access White Space database (paws) ------------------------------------------------ Current Status: Proposed Working Group Last updated: 2011-06-02 Chairs: TBD Applications Area Directors: Pete Resnick > Peter Saint-Andre > Applications Area Advisor: Peter Saint-Andre > Mailing lists: General Discussion: 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: Background Radio spectrum is a limited resource. National and international bodies assign different frequencies for specific uses, and in most cases license the rights to use these frequencies. Locally unused spectrum is commonly called "white space" and may be made available to other services on a basis of non-interference with the primary user of the frequencies concerned (if any). This technique can help "unlock" existing spectrum, for example to enable the wireless communications industry to provide more services over frequencies associated with unused television channels. An obvious requirement is that white space uses must not interfere with the primary use of the spectrum. This is achieved through spatial and/or temporal separation of the primary user and whitespace user with due consideration made to the radio characteristics of the two uses. Problem Statement The fundamental problem is enabling a radio device to determine, in a specific location and at specific time, if any white space is available for secondary use. There are two parties to such an interaction: 1. A database containing records about the protected contours (in space and time) of primary spectrum users. Typically, such databases will be populated and operated by the appropriate spectrum regulation bodies in a given locale. 2. A radio device that wishes to query such a database. Typically, the the nature of the query will depend on the needs of the device. The contents of white space databases, and the needs of radio devices, are being defined elsewhere. However, these parties need a protocol for communication that will enable radio devices to find out what white space is available at a given time in a given location. It is expected that white space databases will be reachable via the Internet, and that radio devices too will have some form of Internet connectivity, directly or indirectly. Therefore, it is appropriate to define an Internet-based protocol for querying white space databases and receiving responses from such databases. In rough outline, such a protocol would enable a radio device that knows its location to complete the following tasks: 1. Determine the relevant white space database to query. 2. Connect to the database using a well-defined access method. 3. Provide its geolocation and perhaps other data to the database using a well-defined wire format for querying the database. 4. Receive in return a list of currently available white space using a well-defined wire format for returning information. Once the device learns of the available white space (e.g., in a TV white space implementation, the list of available channels at that location), it can then select one of the bands from the list and begin to transmit and receive on the selected band. If the device's parameters have changed (e.g., if some amount of time has passed or if the device has changed location beyond a specified threshold), it might need to query the database again to determine what white space is still available. Objectives The overall goals of this working group are to: 1. Standardize a mechanism for discovering a white space database. 2. Standardize a method for accessing a white space database. 3. Standardize wire formats to be carried over the database access method (i.e., formats for queries and responses). 4. Ensure that the discovery mechanism, database access method, and wire formats have appropriate security levels in place. By "standardize" is not meant that the working group will necessarily develop new technologies. In completing its work, the group will: - Evaluate existing discovery mechanisms to determine if one of them provides the necessary application features and security properties (or can be extended to do so) for discovering a white space database. Examples might include DNS. - Evaluate existing application-layer transport protocols to determine if one of them provides the necessary application features and security properties (or can be extended to do so) for use as a building block for communication between location- aware devices and white space databases. If such a method exists, the group will reuse it; if not, the group will develop one. Examples might include HTTP. - Develop a method for querying a white space database. Such a method will utilize, so far as possible, the features of the application-layer transport protocol and not re-implement them in the new protocol. It will include mechanisms to verify that the requests and responses come from authorized sources, and that they have not been modified in transit. Examples might include LDAP. - Define extensible wire formats for both location-specific queries and location-specific responses for interaction with radio white space databases. The group will consider whether existing data formats can be reused. The protocol must protect both the channel enablement process and the privacy of users. Robust privacy and security mechanisms are needed to prevent: device identity spoofing, modification of device requests, modification of channel enablement information, impersonation of registered database services, and unauthorized disclosure of a device's location. The group will consider whether existing privacy and security mechanisms can be reused. The task of defining the structure and contents of the databases themselves is out of scope. The group will standardize wire formats for communication between devices and databases, but not the information models for the databases, since those models are likely to be country-specific or application-specific. In addition, the particular data exchanged between a device and a database might depend on the ranges of radio spectrum that are to be used, the requirements of the database operators and their governing regulations, and other factors. Therefore, the database access method and the query/response data formats that are exchanged using that method need to be designed for extensibility rather than being tied to any specific spectrum, country, or phy/mac/air interface. For example, the working group should define extension points for the database access method and the wire formats that are used to query a database and respond to queries, so that use cases other than those currently envisioned can be addressed in the future if a community of interest wishes to do so. However, the access method and wire formats will incorporate relevant aspects of the parameters needed for the currently envisioned use cases to ensure proper operation. In accordance with existing IETF processes, the group will communicate and invite participation with other relevant standards bodies and groups, and if necessary reuse existing liaison relationships or request the establishment of new liaison relationships, including but not limited to IEEE 802.11af and IEEE 802.22. In order to ensure that it takes into account a broad range of possible use cases and requirements, the group should also reach out to other potential "customers" for a white space database access method and consider input from regulatory entities that are involved in the specification of the rules for secondary use of spectrum in specific radio bands. Deliverables 1. A description of the relevant use cases and requirements. This document shall be Informational. Subject to working group consensus, draft-probasco-paws-overview-usecases and draft-patil-paws-problem-stmt might be used as a starting point. 2. A specification of the mechanism for discovering a white space database, the method for accessing a white space database, and the wire format for querying and receiving responses from a white space database. This document shall be Standards Track. Milestones Oct 2011 Submit 'Use Cases and Requirements for Accessing a Radio White Space Database' to the IESG for publication as Informational Apr 2012 Submit 'Accessing a Radio White Space Database' to the IESG for publication as Proposed Standard ### _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws --_000_88BE24FD9280884487DEAE0CE1FD3A5B0319B242008AM1MPN1021mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Sajeev,

<= /p>

If the database replies w= ith an empty channel list (no channels available) then the white space radi= o must not transmit.

<= /p>

Once a channel list is re= ceived with at least one available channel, the white space radio may trans= mit on one of the available channels. Typically, the white space radio must contact the database regularly to ensure channel availabi= lity. If the white space radio is not able to contact the database, then th= e radio must cease transmission in white space within some period of time. = The specific details are specified by the local regulator (e.g. FCC in the US, Ofcom in the UK, etc).

<= /p>

The white space communica= tion will ultimately be broken if contact with the database is lost. Your q= uestion about using white space as a secondary means of communication is a reasonable question, but beyond the scope of the databa= se interface. For example, a device may use cellular radio, WiFi and white = space radios, switching radios based on some arbitrary decisions (such as p= ower consumption, QoS, subscription rate, etc). However this type of switching scenario is beyond the scope of= the database interface and therefore PAWS.

<= /p>

IMHO, these are good ques= tions about typical system operation, but have no impact to the charter tex= t.

<= /p>

Regards,

Scott

<= /p>

From: paws-bou= nces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext M.K.Sajeev sajeev
Sent: Saturday, June 04, 2011 5:27 AM
To: Peter Saint-Andre; paws@ietf.org
Subject: Re: [paws] updated charter

Hi,

This is Sajeev, interested in whitespace protocols, and an observer of t= his group. Reading through the charter I would like to clarify the followin= g.

In the below paragraph radio device discovers whitespace channel availab= ility time to time. What happens when the radio device does not find any ch= annels available to initiate transmission, or if it happen during a session? Will the communication be broken, or the= radio devices use this as a secondary means of communication? Would like t= o get some clarity..

Once the device learns of the available whi= te space (e.g., in a TV
white space implementation, the list of av= ailable channels at that
location), it can then select one of the b= ands from the list and
begin to transmit and receive on the selec= ted band. If the device's
parameters have changed (e.g., if some amo= unt of time has passed or if
the device has changed location beyond a s= pecified threshold), it might
need to query the database again to determ= ine what white space is still
available.

Sajeev Manikkoth
Mobile: +919663311378

Email: mksaji@ieee.org
http://ww= w.linkedin.com/in/mksajeev

<= span style=3D"font-size:10.0pt;font-family:"Arial","sans-ser= if";color:black">From: Peter Saint-A= ndre <stpeter@stpeter.im>
To: "paws@ietf.org" <paws@ietf.org>
Sent: Friday, 3 June 2011, 7:56
Subject: [paws] updated charter

Here is the charter the emerged from discussions among IESG members and
with the BoF chairs.

###

Protocol to Access White Space database (paws)
------------------------------------------------
Current Status: Proposed Working Group
Last updated: 2011-06-02

Chairs:
TBD

Applications Area Directors:
Pete Resnick <pre= snick@qualcomm.com>
Peter Saint-Andre <s= tpeter@stpeter.im>

Applications Area Advisor:
Peter Saint-Andre <s= tpeter@stpeter.im>

Mailing lists:
General Discussion: paws@iet= f.org
To Subscribe: https://www.ietf.org/mailman/listinfo/paws
Archive: http://www.ietf.org/mail-archive/web/paws/

Description of Working Group:

Background

Radio spectrum is a limited resource. National and international
bodies assign different frequencies for specific uses, and in
most cases license the rights to use these frequencies. Locally
unused spectrum is commonly called "white space" and may be made<= br> available to other services on a basis of non-interference with
the primary user of the frequencies concerned (if any). This
technique can help "unlock" existing spectrum, for example to
enable the wireless communications industry to provide more
services over frequencies associated with unused television
channels. An obvious requirement is that white space uses must
not interfere with the primary use of the spectrum. This is
achieved through spatial and/or temporal separation of the
primary user and whitespace user with due consideration made to
the radio characteristics of the two uses.

Problem Statement

The fundamental problem is enabling a radio device to determine, in
a specific location and at specific time, if any white space is
available for secondary use. There are two parties to such an
interaction:

1. A database containing records about the protected contours (in
space and time) of primary spectrum users. Typically, such databases<= br> will be populated and operated by the appropriate spectrum regulation
bodies in a given locale.

2. A radio device that wishes to query such a database. Typically, the
the nature of the query will depend on the needs of the device.

The contents of white space databases, and the needs of radio devices,
are being defined elsewhere. However, these parties need a protocol for communication that will enable radio devices to find out what white
space is available at a given time in a given location.

It is expected that white space databases will be reachable via the
Internet, and that radio devices too will have some form of Internet
connectivity, directly or indirectly. Therefore, it is appropriate to define an Internet-based protocol for querying white space databases
and receiving responses from such databases.

In rough outline, such a protocol would enable a radio device that
knows its location to complete the following tasks:

1. Determine the relevant white space database to query.

2. Connect to the database using a well-defined access method.

3. Provide its geolocation and perhaps other data to the database
using a well-defined wire format for querying the database.

4. Receive in return a list of currently available white space
using a well-defined wire format for returning information.

Once the device learns of the available white space (e.g., in a TV
white space implementation, the list of available channels at that
location), it can then select one of the bands from the list and
begin to transmit and receive on the selected band. If the device's parameters have changed (e.g., if some amount of time has passed or if
the device has changed location beyond a specified threshold), it might
need to query the database again to determine what white space is still
available.

Objectives

The overall goals of this working group are to:

1. Standardize a mechanism for discovering a white space database.

2. Standardize a method for accessing a white space database.

3. Standardize wire formats to be carried over the database
access method (i.e., formats for queries and responses).

4. Ensure that the discovery mechanism, database access method,
and wire formats have appropriate security levels in place.

By "standardize" is not meant that the working group will necessa= rily
develop new technologies. In completing its work, the group will:

- Evaluate existing discovery mechanisms to determine if one of
them provides the necessary application features and security
properties (or can be extended to do so) for discovering a
white space database. Examples might include DNS.

- Evaluate existing application-layer transport protocols to
determine if one of them provides the necessary application
features and security properties (or can be extended to do so)
for use as a building block for communication between location-
aware devices and white space databases. If such a method
exists, the group will reuse it; if not, the group will develop
one. Examples might include HTTP.

- Develop a method for querying a white space database. Such
a method will utilize, so far as possible, the features of
the application-layer transport protocol and not re-implement
them in the new protocol. It will include mechanisms to verify
that the requests and responses come from authorized sources,
and that they have not been modified in transit. Examples migh= t
include LDAP.

- Define extensible wire formats for both location-specific queries
and location-specific responses for interaction with radio white
space databases. The group will consider whether existing data=
formats can be reused.

The protocol must protect both the channel enablement process and the
privacy of users. Robust privacy and security mechanisms are needed to prevent: device identity spoofing, modification of device requests,
modification of channel enablement information, impersonation of
registered database services, and unauthorized disclosure of a device's
location. The group will consider whether existing privacy and
security mechanisms can be reused.

The task of defining the structure and contents of the databases
themselves is out of scope. The group will standardize wire formats for communication between devices and databases, but not the information models for the databases, since those models are likely to be
country-specific or application-specific. In addition, the particular=
data exchanged between a device and a database might depend on the
ranges of radio spectrum that are to be used, the requirements of the
database operators and their governing regulations, and other factors.
Therefore, the database access method and the query/response data
formats that are exchanged using that method need to be designed for
extensibility rather than being tied to any specific spectrum, country,
or phy/mac/air interface. For example, the working group should defin= e
extension points for the database access method and the wire formats
that are used to query a database and respond to queries, so that use
cases other than those currently envisioned can be addressed in the
future if a community of interest wishes to do so. However, the
access method and wire formats will incorporate relevant aspects of
the parameters needed for the currently envisioned use cases to ensure
proper operation.

In accordance with existing IETF processes, the group will communicate
and invite participation with other relevant standards bodies and
groups, and if necessary reuse existing liaison relationships or
request the establishment of new liaison relationships, including but
not limited to IEEE 802.11af and IEEE 802.22. In order to ensure that=
it takes into account a broad range of possible use cases and
requirements, the group should also reach out to other potential
"customers" for a white space database access method and consider= input
from regulatory entities that are involved in the specification of the
rules for secondary use of spectrum in specific radio bands.

Deliverables

1. A description of the relevant use cases and requirements. This
document shall be Informational. Subject to working group consensus,<= br> draft-probasco-paws-overview-usecases and draft-patil-paws-problem-stmt
might be used as a starting point.

2. A specification of the mechanism for discovering a white space
database, the method for accessing a white space database, and the
wire format for querying and receiving responses from a white space
database. This document shall be Standards Track.

Milestones

Oct 2011 Submit 'Use Cases and Requirements for Accessing a Radio White
Space Database' to the IESG for publication as Informational

Apr 2012 Submit 'Accessing a Radio White Space Database' to the IESG
for publication as Proposed Standard

###

_______________________________________________
paws mailing list
paws@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/paws

--_000_88BE24FD9280884487DEAE0CE1FD3A5B0319B242008AM1MPN1021mg_-- From bk@keenerlawgroup.com Mon Jun 6 05:03:28 2011 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9D3C11E8134 for ; Mon, 6 Jun 2011 05:03:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EItoO6QqhTGE for ; Mon, 6 Jun 2011 05:03:21 -0700 (PDT) Received: from p3plsmtpa07-08.prod.phx3.secureserver.net (p3plsmtpa07-08.prod.phx3.secureserver.net [173.201.192.237]) by ietfa.amsl.com (Postfix) with SMTP id 6EA5A11E8128 for ; Mon, 6 Jun 2011 05:03:21 -0700 (PDT) Received: (qmail 1908 invoked from network); 6 Jun 2011 12:03:20 -0000 Received: from unknown (76.118.199.230) by p3plsmtpa07-08.prod.phx3.secureserver.net (173.201.192.237) with ESMTP; 06 Jun 2011 12:03:19 -0000 From: "Barlow Keener" To: , , , References: <4DE8466C.9010201@stpeter.im> <205283.1524.qm@web34508.mail.mud.yahoo.com> <88BE24FD9280884487DEAE0CE1FD3A5B0319B242@008-AM1MPN1-021.mgdnok.nokia.com> In-Reply-To: <88BE24FD9280884487DEAE0CE1FD3A5B0319B242@008-AM1MPN1-021.mgdnok.nokia.com> Date: Mon, 6 Jun 2011 08:03:18 -0400 Organization: Keener Law Group Message-ID: <009301cc2441$ba0ab5c0$2e202140$@keenerlawgroup.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0094_01CC2420.32FE45E0" X-Mailer: Microsoft Outlook 14.0 thread-index: AQMK9DQMb2EFGT4xwJm7eDf0B3jC5gHVd/dKAlN+0YiSEVFZ0A== Content-Language: en-us Subject: Re: [paws] updated charter X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: bk@keenerlawgroup.com List-Id: "Protocol to Access White Space database $PAWS$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 12:03:28 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0094_01CC2420.32FE45E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Scott, I think this presents a good question about WS PAWS: Q "If the database replies with an empty channel list (no channels available) then the white space radio must not transmit." I have wondered about this question because if the WS radio attempts to "contact" the database in order to determine what spectrum/channels are unlicensed in a particular geographical area - by going through or sending out a transmit signal on the various spectrum/channels that are "possible" WS channels to use in all geographies, then by definition the WS radio will "interfere" by using this transmit signal with other licensed spectrum/channels. Correct? How is this problem solved? It is defined in PAWS almost as a question but not answered - at least that is my view. Thanks! Barlow Barlow Keener 617-671-1202 Barlow Keener | Attorney | Keener Law Group Internet and telecommunications law d: 617.671.1202 | m: 781-858-1588 | bk@keenerlawgroup.com Follow me on Twitter http://twitter.com/barlow | LinkedIn http://www.linkedin.com/in/barlowkeener | Blog: www.whydom.com From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of scott.probasco@nokia.com Sent: Monday, June 06, 2011 5:31 AM To: mksaji@yahoo.com; stpeter@stpeter.im; paws@ietf.org Subject: Re: [paws] updated charter Hi Sajeev, If the database replies with an empty channel list (no channels available) then the white space radio must not transmit. Once a channel list is received with at least one available channel, the white space radio may transmit on one of the available channels. Typically, the white space radio must contact the database regularly to ensure channel availability. If the white space radio is not able to contact the database, then the radio must cease transmission in white space within some period of time. The specific details are specified by the local regulator (e.g. FCC in the US, Ofcom in the UK, etc). The white space communication will ultimately be broken if contact with the database is lost. Your question about using white space as a secondary means of communication is a reasonable question, but beyond the scope of the database interface. For example, a device may use cellular radio, WiFi and white space radios, switching radios based on some arbitrary decisions (such as power consumption, QoS, subscription rate, etc). However this type of switching scenario is beyond the scope of the database interface and therefore PAWS. IMHO, these are good questions about typical system operation, but have no impact to the charter text. Regards, Scott From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext M.K.Sajeev sajeev Sent: Saturday, June 04, 2011 5:27 AM To: Peter Saint-Andre; paws@ietf.org Subject: Re: [paws] updated charter Hi, This is Sajeev, interested in whitespace protocols, and an observer of this group. Reading through the charter I would like to clarify the following. In the below paragraph radio device discovers whitespace channel availability time to time. What happens when the radio device does not find any channels available to initiate transmission, or if it happen during a session? Will the communication be broken, or the radio devices use this as a secondary means of communication? Would like to get some clarity.. Once the device learns of the available white space (e.g., in a TV white space implementation, the list of available channels at that location), it can then select one of the bands from the list and begin to transmit and receive on the selected band. If the device's parameters have changed (e.g., if some amount of time has passed or if the device has changed location beyond a specified threshold), it might need to query the database again to determine what white space is still available. Sajeev Manikkoth Mobile: +919663311378 Email: mksaji@ieee.org http://www.linkedin.com/in/mksajeev _____ From: Peter Saint-Andre To: "paws@ietf.org" Sent: Friday, 3 June 2011, 7:56 Subject: [paws] updated charter Here is the charter the emerged from discussions among IESG members and with the BoF chairs. ### Protocol to Access White Space database (paws) ------------------------------------------------ Current Status: Proposed Working Group Last updated: 2011-06-02 Chairs: TBD Applications Area Directors: Pete Resnick Peter Saint-Andre Applications Area Advisor: Peter Saint-Andre Mailing lists: General Discussion: 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: Background Radio spectrum is a limited resource. National and international bodies assign different frequencies for specific uses, and in most cases license the rights to use these frequencies. Locally unused spectrum is commonly called "white space" and may be made available to other services on a basis of non-interference with the primary user of the frequencies concerned (if any). This technique can help "unlock" existing spectrum, for example to enable the wireless communications industry to provide more services over frequencies associated with unused television channels. An obvious requirement is that white space uses must not interfere with the primary use of the spectrum. This is achieved through spatial and/or temporal separation of the primary user and whitespace user with due consideration made to the radio characteristics of the two uses. Problem Statement The fundamental problem is enabling a radio device to determine, in a specific location and at specific time, if any white space is available for secondary use. There are two parties to such an interaction: 1. A database containing records about the protected contours (in space and time) of primary spectrum users. Typically, such databases will be populated and operated by the appropriate spectrum regulation bodies in a given locale. 2. A radio device that wishes to query such a database. Typically, the the nature of the query will depend on the needs of the device. The contents of white space databases, and the needs of radio devices, are being defined elsewhere. However, these parties need a protocol for communication that will enable radio devices to find out what white space is available at a given time in a given location. It is expected that white space databases will be reachable via the Internet, and that radio devices too will have some form of Internet connectivity, directly or indirectly. Therefore, it is appropriate to define an Internet-based protocol for querying white space databases and receiving responses from such databases. In rough outline, such a protocol would enable a radio device that knows its location to complete the following tasks: 1. Determine the relevant white space database to query. 2. Connect to the database using a well-defined access method. 3. Provide its geolocation and perhaps other data to the database using a well-defined wire format for querying the database. 4. Receive in return a list of currently available white space using a well-defined wire format for returning information. Once the device learns of the available white space (e.g., in a TV white space implementation, the list of available channels at that location), it can then select one of the bands from the list and begin to transmit and receive on the selected band. If the device's parameters have changed (e.g., if some amount of time has passed or if the device has changed location beyond a specified threshold), it might need to query the database again to determine what white space is still available. Objectives The overall goals of this working group are to: 1. Standardize a mechanism for discovering a white space database. 2. Standardize a method for accessing a white space database. 3. Standardize wire formats to be carried over the database access method (i.e., formats for queries and responses). 4. Ensure that the discovery mechanism, database access method, and wire formats have appropriate security levels in place. By "standardize" is not meant that the working group will necessarily develop new technologies. In completing its work, the group will: - Evaluate existing discovery mechanisms to determine if one of them provides the necessary application features and security properties (or can be extended to do so) for discovering a white space database. Examples might include DNS. - Evaluate existing application-layer transport protocols to determine if one of them provides the necessary application features and security properties (or can be extended to do so) for use as a building block for communication between location- aware devices and white space databases. If such a method exists, the group will reuse it; if not, the group will develop one. Examples might include HTTP. - Develop a method for querying a white space database. Such a method will utilize, so far as possible, the features of the application-layer transport protocol and not re-implement them in the new protocol. It will include mechanisms to verify that the requests and responses come from authorized sources, and that they have not been modified in transit. Examples might include LDAP. - Define extensible wire formats for both location-specific queries and location-specific responses for interaction with radio white space databases. The group will consider whether existing data formats can be reused. The protocol must protect both the channel enablement process and the privacy of users. Robust privacy and security mechanisms are needed to prevent: device identity spoofing, modification of device requests, modification of channel enablement information, impersonation of registered database services, and unauthorized disclosure of a device's location. The group will consider whether existing privacy and security mechanisms can be reused. The task of defining the structure and contents of the databases themselves is out of scope. The group will standardize wire formats for communication between devices and databases, but not the information models for the databases, since those models are likely to be country-specific or application-specific. In addition, the particular data exchanged between a device and a database might depend on the ranges of radio spectrum that are to be used, the requirements of the database operators and their governing regulations, and other factors. Therefore, the database access method and the query/response data formats that are exchanged using that method need to be designed for extensibility rather than being tied to any specific spectrum, country, or phy/mac/air interface. For example, the working group should define extension points for the database access method and the wire formats that are used to query a database and respond to queries, so that use cases other than those currently envisioned can be addressed in the future if a community of interest wishes to do so. However, the access method and wire formats will incorporate relevant aspects of the parameters needed for the currently envisioned use cases to ensure proper operation. In accordance with existing IETF processes, the group will communicate and invite participation with other relevant standards bodies and groups, and if necessary reuse existing liaison relationships or request the establishment of new liaison relationships, including but not limited to IEEE 802.11af and IEEE 802.22. In order to ensure that it takes into account a broad range of possible use cases and requirements, the group should also reach out to other potential "customers" for a white space database access method and consider input from regulatory entities that are involved in the specification of the rules for secondary use of spectrum in specific radio bands. Deliverables 1. A description of the relevant use cases and requirements. This document shall be Informational. Subject to working group consensus, draft-probasco-paws-overview-usecases and draft-patil-paws-problem-stmt might be used as a starting point. 2. A specification of the mechanism for discovering a white space database, the method for accessing a white space database, and the wire format for querying and receiving responses from a white space database. This document shall be Standards Track. Milestones Oct 2011 Submit 'Use Cases and Requirements for Accessing a Radio White Space Database' to the IESG for publication as Informational Apr 2012 Submit 'Accessing a Radio White Space Database' to the IESG for publication as Proposed Standard ### _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws ------=_NextPart_000_0094_01CC2420.32FE45E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

S= cott,

<= o:p>

I= think this presents a good question about WS = PAWS:

<= o:p>

Q “If the database replies with an empty channel list (no = channels available) then the white space radio must not = transmit.”

I have wondered about this question because if the WS radio attempts to = “contact” the database in order to determine what = spectrum/channels are unlicensed in a particular geographical area = – by going through or sending out a transmit signal on the = various spectrum/channels that are “possible” WS channels to = use in all geographies, then by definition the WS radio will = “interfere” by using this transmit signal with other = licensed spectrum/channels. Correct?

How is this problem solved? It is defined in PAWS almost as a = question but not answered – at least that is my = view.

Thanks!

Barlow

<= o:p>

Barlow Keener

= 617-671-1202

Barlow= Keener | = Attorney | Keener Law = Group =
Internet and telecommunications law

d: = 617.671.1202 | m: 781-858-1588 | bk@keenerlawgroup.comFol= low me on Twitter http:/= /twitter.com/barlow | = LinkedIn http://www.linkedin.com/= in/barlowkeener = ; | = Blog: www.whydom.com =

<= o:p>

From:= = paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of = scott.probasco@nokia.com
Sent: Monday, June 06, 2011 5:31 = AM
To: mksaji@yahoo.com; stpeter@stpeter.im; = paws@ietf.org
Subject: Re: [paws] updated = charter

Hi Sajeev,

If the database replies with an empty channel list (no channels = available) then the white space radio must not = transmit.

Once a channel list is received with at least one available channel, = the white space radio may transmit on one of the available channels. = Typically, the white space radio must contact the database regularly to = ensure channel availability. If the white space radio is not able to = contact the database, then the radio must cease transmission in white = space within some period of time. The specific details are specified by = the local regulator (e.g. FCC in the US, Ofcom in the UK, etc). =

The white space communication will ultimately be broken if contact = with the database is lost. Your question about using white space as a = secondary means of communication is a reasonable question, but beyond = the scope of the database interface. For example, a device may use = cellular radio, WiFi and white space radios, switching radios based on = some arbitrary decisions (such as power consumption, QoS, subscription = rate, etc). However this type of switching scenario is beyond the scope = of the database interface and therefore PAWS.

IMHO, these are good questions about typical system operation, but = have no impact to the charter text.

Regards,

Scott

From:= = paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of = ext M.K.Sajeev sajeev
Sent: Saturday, June 04, 2011 5:27 = AM
To: Peter Saint-Andre; paws@ietf.org
Subject: Re: = [paws] updated charter

Hi,

This is Sajeev, interested in whitespace = protocols, and an observer of this group. Reading through the charter I = would like to clarify the following.

In the below paragraph radio device discovers = whitespace channel availability time to time. What happens when the = radio device does not find any channels available to initiate = transmission, or if it happen during a session? Will the communication = be broken, or the radio devices use this as a secondary means of = communication? Would like to get some = clarity..

= Once the device learns of the available white space (e.g., in a = TV=
white space implementation, the list = of available channels at that
location), it can then select one of the bands = from the list and
begin to = transmit and receive on the selected band. If the = device's
parameters have = changed (e.g., if some amount of time has passed or if
the device has changed location beyond a = specified threshold), it might
need to query the database again to determine = what white space is still
available.

Sajeev Manikkoth
Mobile: = +919663311378

Email: mksaji@ieee.org
http://www.linkedin.com/in/mksajeev

<= hr size=3D1 width=3D"100%" align=3Dcenter>

F= rom: = Peter Saint-Andre <stpeter@stpeter.im>
To: = "paws@ietf.org" <paws@ietf.org>
Sent: Friday, = 3 June 2011, 7:56
Subject: [paws] updated = charter

Here is the charter = the emerged from discussions among IESG members and
with the BoF = chairs.

###

Protocol to Access White Space database = (paws)
------------------------------------------------
Current = Status: Proposed Working Group
Last updated: = 2011-06-02

Chairs:
TBD

Applications Area = Directors:
Pete Resnick <presnick@qualcomm.com>
&n= bsp; Peter Saint-Andre <stpeter@stpeter.im>

Appl= ications Area Advisor:
Peter Saint-Andre <stpeter@stpeter.im>

Mail= ing lists:
General Discussion: paws@ietf.org
To = Subscribe: https://www.ietf.org/mailman/listinfo/paws
= ; Archive: http://www.ietf.org/mail-archive/web/paws/

D= escription of Working Group:

Background

Radio spectrum is = a limited resource. National and international
bodies assign = different frequencies for specific uses, and in
most cases license = the rights to use these frequencies. Locally
unused spectrum is = commonly called "white space" and may be made
available to = other services on a basis of non-interference with
the primary user = of the frequencies concerned (if any). This
technique can help = "unlock" existing spectrum, for example to
enable the = wireless communications industry to provide more
services over = frequencies associated with unused television
channels. An = obvious requirement is that white space uses must
not interfere with = the primary use of the spectrum. This is
achieved through = spatial and/or temporal separation of the
primary user and whitespace = user with due consideration made to
the radio characteristics of the = two uses.

Problem Statement

The fundamental problem is = enabling a radio device to determine, in
a specific location and at = specific time, if any white space is
available for secondary = use. There are two parties to such an
interaction:

1. A = database containing records about the protected contours (in
space = and time) of primary spectrum users. Typically, such = databases
will be populated and operated by the appropriate spectrum = regulation
bodies in a given locale.

2. A radio device that = wishes to query such a database. Typically, the
the nature of the = query will depend on the needs of the device.

The contents of = white space databases, and the needs of radio devices,
are being = defined elsewhere. However, these parties need a protocol
for = communication that will enable radio devices to find out what = white
space is available at a given time in a given = location.

It is expected that white space databases will be = reachable via the
Internet, and that radio devices too will have some = form of Internet
connectivity, directly or indirectly. = Therefore, it is appropriate
to define an Internet-based protocol for = querying white space databases
and receiving responses from such = databases.

In rough outline, such a protocol would enable a radio = device that
knows its location to complete the following = tasks:

1. Determine the relevant white space database to = query.

2. Connect to the database using a well-defined access = method.

3. Provide its geolocation and perhaps other data to the = database
using a well-defined wire format for querying the = database.

4. Receive in return a list of currently available = white space
using a well-defined wire format for returning = information.

Once the device learns of the available white space = (e.g., in a TV
white space implementation, the list of available = channels at that
location), it can then select one of the bands from = the list and
begin to transmit and receive on the selected = band. If the device's
parameters have changed (e.g., if some = amount of time has passed or if
the device has changed location = beyond a specified threshold), it might
need to query the database = again to determine what white space is = still
available.

Objectives

The overall goals of this = working group are to:

1. Standardize a mechanism for discovering = a white space database.

2. Standardize a method for accessing a = white space database.

3. Standardize wire formats to be carried = over the database
access method (i.e., formats for queries and = responses).

4. Ensure that the discovery mechanism, database = access method,
and wire formats have appropriate security levels in = place.

By "standardize" is not meant that the working = group will necessarily
develop new technologies. In completing = its work, the group will:

- Evaluate existing discovery = mechanisms to determine if one of
them provides the necessary = application features and security
properties (or can be = extended to do so) for discovering a
white space = database. Examples might include DNS.

- Evaluate existing = application-layer transport protocols to
determine if one of = them provides the necessary application
features and security = properties (or can be extended to do so)
for use as a building = block for communication between location-
aware devices and = white space databases. If such a method
exists, the = group will reuse it; if not, the group will develop
one. = Examples might include HTTP.

- Develop a method for querying a = white space database. Such
a method will utilize, so far = as possible, the features of
the application-layer transport = protocol and not re-implement
them in the new protocol. It = will include mechanisms to verify
that the requests and = responses come from authorized sources,
and that they have not = been modified in transit. Examples might
include = LDAP.

- Define extensible wire formats for both location-specific = queries
and location-specific responses for interaction with = radio white
space databases. The group will consider = whether existing data
formats can be reused.

The = protocol must protect both the channel enablement process and = the
privacy of users. Robust privacy and security mechanisms = are needed
to prevent: device identity spoofing, modification of = device requests,
modification of channel enablement information, = impersonation of
registered database services, and unauthorized = disclosure of a device's
location. The group will consider = whether existing privacy and
security mechanisms can be = reused.

The task of defining the structure and contents of the = databases
themselves is out of scope. The group will = standardize wire formats
for communication between devices and = databases, but not the information
models for the databases, since = those models are likely to be
country-specific or = application-specific. In addition, the particular
data = exchanged between a device and a database might depend on the
ranges = of radio spectrum that are to be used, the requirements of = the
database operators and their governing regulations, and other = factors.
Therefore, the database access method and the query/response = data
formats that are exchanged using that method need to be designed = for
extensibility rather than being tied to any specific spectrum, = country,
or phy/mac/air interface. For example, the working = group should define
extension points for the database access method = and the wire formats
that are used to query a database and respond to = queries, so that use
cases other than those currently envisioned can = be addressed in the
future if a community of interest wishes to do = so. However, the
access method and wire formats will = incorporate relevant aspects of
the parameters needed for the = currently envisioned use cases to ensure
proper operation.

In = accordance with existing IETF processes, the group will = communicate
and invite participation with other relevant standards = bodies and
groups, and if necessary reuse existing liaison = relationships or
request the establishment of new liaison = relationships, including but
not limited to IEEE 802.11af and IEEE = 802.22. In order to ensure that
it takes into account a broad = range of possible use cases and
requirements, the group should also = reach out to other potential
"customers" for a white space = database access method and consider input
from regulatory entities = that are involved in the specification of the
rules for secondary use = of spectrum in specific radio bands.

Deliverables

1. A = description of the relevant use cases and requirements. = This
document shall be Informational. Subject to working group = consensus,
draft-probasco-paws-overview-usecases and = draft-patil-paws-problem-stmt
might be used as a starting = point.

2. A specification of the mechanism for discovering a = white space
database, the method for accessing a white space = database, and the
wire format for querying and receiving responses = from a white space
database. This document shall be Standards = Track.

Milestones

Oct 2011 Submit 'Use Cases and = Requirements for Accessing a Radio White
Space Database' to the IESG = for publication as Informational

Apr 2012 Submit 'Accessing a = Radio White Space Database' to the IESG
for publication as Proposed = Standard

###

__________________________________= _____________
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/listinfo/paws

------=_NextPart_000_0094_01CC2420.32FE45E0-- From brian.rosen@neustar.biz Mon Jun 6 05:56:27 2011 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60DEF11E8138 for ; Mon, 6 Jun 2011 05:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B8pd64xtrwdp for ; Mon, 6 Jun 2011 05:56:25 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id A8A4111E8133 for ; Mon, 6 Jun 2011 05:56:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1307364982; x=1622723750; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type; bh=IjB0w7MBpnnWImxBL8BpwVdhTLeeiuem8GUZyNj3t6U=; b=BUzq/z+DoLd4yuGIvT9IIDNnBBACm2PZcHAhiynVuHmgPIHXlbYdGrkJPKIA5u mkzXGUVjUv8m4hkWXWiST4yw== Received: from ([10.31.13.242]) by chihiron1.nc.neustar.com with ESMTP with TLS id 5202942.39819229; Mon, 06 Jun 2011 08:56:20 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Mon, 6 Jun 2011 08:56:19 -0400 From: "Rosen, Brian" To: "bk@keenerlawgroup.com" Date: Mon, 6 Jun 2011 08:56:14 -0400 Thread-Topic: [paws] updated charter Thread-Index: AcwkSSBS76o9MUbRQUmabi1+cKGP/Q== Message-ID: <53093B77-9AA1-4E14-8820-80529414FD4D@neustar.biz> References: <4DE8466C.9010201@stpeter.im> <205283.1524.qm@web34508.mail.mud.yahoo.com> <88BE24FD9280884487DEAE0CE1FD3A5B0319B242@008-AM1MPN1-021.mgdnok.nokia.com> <009301cc2441$ba0ab5c0$2e202140$@keenerlawgroup.com> In-Reply-To: <009301cc2441$ba0ab5c0$2e202140$@keenerlawgroup.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: n1XM6BowHGgamdPkQiLN0A== Content-Type: multipart/alternative; boundary="_000_53093B779AA14E14882080529414FD4Dneustarbiz_" MIME-Version: 1.0 Cc: "paws@ietf.org" , "mksaji@yahoo.com" Subject: Re: [paws] updated charter X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database $PAWS$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 12:56:27 -0000 --_000_53093B779AA14E14882080529414FD4Dneustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable There are several strategies that can be used. One end has to have an inde= pendent Internet access mechanism. It can determine what channels it, and = it's "clients" can use and broadcast them, or use one channel as a beacon, = allow the clients to access it on the beacon channel, and then assign a cha= nnel to the client. There are other strategies. Brian On Jun 6, 2011, at 8:03 AM, Barlow Keener wrote: Scott, I think this presents a good question about WS PAWS: Q =93If the database replies with an empty channel list (no channels availa= ble) then the white space radio must not transmit.=94 I have wondered about this question because if the WS radio attempts to =93= contact=94 the database in order to determine what spectrum/channels are un= licensed in a particular geographical area =96 by going through or sending= out a transmit signal on the various spectrum/channels that are =93possibl= e=94 WS channels to use in all geographies, then by definition the WS radio= will =93interfere=94 by using this transmit signal with other licensed spe= ctrum/channels. Correct? How is this problem solved? It is defined in PAWS almost as a question but= not answered =96 at least that is my view. Thanks! Barlow Barlow Keener 617-671-1202 Barlow Keener | Attorney | Keener Law Group Internet and telecommunications law d: 617.671.1202 | m: 781-858-1588 | bk@keenerlawgroup.com Follow me on Twitter http://twitter.com/barlow | LinkedIn http://www.linkedin.com/in/barlowkeener | Blog: www.whydom.c= om From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of scott.probasco@nokia.com Sent: Monday, June 06, 2011 5:31 AM To: mksaji@yahoo.com; stpeter@stpeter.im; paws@ietf.org Subject: Re: [paws] updated charter Hi Sajeev, If the database replies with an empty channel list (no channels available) = then the white space radio must not transmit. Once a channel list is received with at least one available channel, the wh= ite space radio may transmit on one of the available channels. Typically, t= he white space radio must contact the database regularly to ensure channel = availability. If the white space radio is not able to contact the database,= then the radio must cease transmission in white space within some period o= f time. The specific details are specified by the local regulator (e.g. FCC= in the US, Ofcom in the UK, etc). The white space communication will ultimately be broken if contact with the= database is lost. Your question about using white space as a secondary mea= ns of communication is a reasonable question, but beyond the scope of the d= atabase interface. For example, a device may use cellular radio, WiFi and w= hite space radios, switching radios based on some arbitrary decisions (such= as power consumption, QoS, subscription rate, etc). However this type of s= witching scenario is beyond the scope of the database interface and therefo= re PAWS. IMHO, these are good questions about typical system operation, but have no = impact to the charter text. Regards, Scott From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of ext M.K.Sajeev sajeev Sent: Saturday, June 04, 2011 5:27 AM To: Peter Saint-Andre; paws@ietf.org Subject: Re: [paws] updated charter Hi, This is Sajeev, interested in whitespace protocols, and an observer of this= group. Reading through the charter I would like to clarify the following. In the below paragraph radio device discovers whitespace channel availabili= ty time to time. What happens when the radio device does not find any chann= els available to initiate transmission, or if it happen during a session? W= ill the communication be broken, or the radio devices use this as a seconda= ry means of communication? Would like to get some clarity.. Once the device learns of the available white space (e.g., in a TV white space implementation, the list of available channels at that location), it can then select one of the bands from the list and begin to transmit and receive on the selected band. If the device's parameters have changed (e.g., if some amount of time has passed or if the device has changed location beyond a specified threshold), it might need to query the database again to determine what white space is still available. Sajeev Manikkoth Mobile: +919663311378 Email: mksaji@ieee.org http://www.linkedin.com/in/mksajeev ________________________________ From: Peter Saint-Andre > To: "paws@ietf.org" > Sent: Friday, 3 June 2011, 7:56 Subject: [paws] updated charter Here is the charter the emerged from discussions among IESG members and with the BoF chairs. ### Protocol to Access White Space database (paws) ------------------------------------------------ Current Status: Proposed Working Group Last updated: 2011-06-02 Chairs: TBD Applications Area Directors: Pete Resnick > Peter Saint-Andre > Applications Area Advisor: Peter Saint-Andre > Mailing lists: General Discussion: 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: Background Radio spectrum is a limited resource. National and international bodies assign different frequencies for specific uses, and in most cases license the rights to use these frequencies. Locally unused spectrum is commonly called "white space" and may be made available to other services on a basis of non-interference with the primary user of the frequencies concerned (if any). This technique can help "unlock" existing spectrum, for example to enable the wireless communications industry to provide more services over frequencies associated with unused television channels. An obvious requirement is that white space uses must not interfere with the primary use of the spectrum. This is achieved through spatial and/or temporal separation of the primary user and whitespace user with due consideration made to the radio characteristics of the two uses. Problem Statement The fundamental problem is enabling a radio device to determine, in a specific location and at specific time, if any white space is available for secondary use. There are two parties to such an interaction: 1. A database containing records about the protected contours (in space and time) of primary spectrum users. Typically, such databases will be populated and operated by the appropriate spectrum regulation bodies in a given locale. 2. A radio device that wishes to query such a database. Typically, the the nature of the query will depend on the needs of the device. The contents of white space databases, and the needs of radio devices, are being defined elsewhere. However, these parties need a protocol for communication that will enable radio devices to find out what white space is available at a given time in a given location. It is expected that white space databases will be reachable via the Internet, and that radio devices too will have some form of Internet connectivity, directly or indirectly. Therefore, it is appropriate to define an Internet-based protocol for querying white space databases and receiving responses from such databases. In rough outline, such a protocol would enable a radio device that knows its location to complete the following tasks: 1. Determine the relevant white space database to query. 2. Connect to the database using a well-defined access method. 3. Provide its geolocation and perhaps other data to the database using a well-defined wire format for querying the database. 4. Receive in return a list of currently available white space using a well-defined wire format for returning information. Once the device learns of the available white space (e.g., in a TV white space implementation, the list of available channels at that location), it can then select one of the bands from the list and begin to transmit and receive on the selected band. If the device's parameters have changed (e.g., if some amount of time has passed or if the device has changed location beyond a specified threshold), it might need to query the database again to determine what white space is still available. Objectives The overall goals of this working group are to: 1. Standardize a mechanism for discovering a white space database. 2. Standardize a method for accessing a white space database. 3. Standardize wire formats to be carried over the database access method (i.e., formats for queries and responses). 4. Ensure that the discovery mechanism, database access method, and wire formats have appropriate security levels in place. By "standardize" is not meant that the working group will necessarily develop new technologies. In completing its work, the group will: - Evaluate existing discovery mechanisms to determine if one of them provides the necessary application features and security properties (or can be extended to do so) for discovering a white space database. Examples might include DNS. - Evaluate existing application-layer transport protocols to determine if one of them provides the necessary application features and security properties (or can be extended to do so) for use as a building block for communication between location- aware devices and white space databases. If such a method exists, the group will reuse it; if not, the group will develop one. Examples might include HTTP. - Develop a method for querying a white space database. Such a method will utilize, so far as possible, the features of the application-layer transport protocol and not re-implement them in the new protocol. It will include mechanisms to verify that the requests and responses come from authorized sources, and that they have not been modified in transit. Examples might include LDAP. - Define extensible wire formats for both location-specific queries and location-specific responses for interaction with radio white space databases. The group will consider whether existing data formats can be reused. The protocol must protect both the channel enablement process and the privacy of users. Robust privacy and security mechanisms are needed to prevent: device identity spoofing, modification of device requests, modification of channel enablement information, impersonation of registered database services, and unauthorized disclosure of a device's location. The group will consider whether existing privacy and security mechanisms can be reused. The task of defining the structure and contents of the databases themselves is out of scope. The group will standardize wire formats for communication between devices and databases, but not the information models for the databases, since those models are likely to be country-specific or application-specific. In addition, the particular data exchanged between a device and a database might depend on the ranges of radio spectrum that are to be used, the requirements of the database operators and their governing regulations, and other factors. Therefore, the database access method and the query/response data formats that are exchanged using that method need to be designed for extensibility rather than being tied to any specific spectrum, country, or phy/mac/air interface. For example, the working group should define extension points for the database access method and the wire formats that are used to query a database and respond to queries, so that use cases other than those currently envisioned can be addressed in the future if a community of interest wishes to do so. However, the access method and wire formats will incorporate relevant aspects of the parameters needed for the currently envisioned use cases to ensure proper operation. In accordance with existing IETF processes, the group will communicate and invite participation with other relevant standards bodies and groups, and if necessary reuse existing liaison relationships or request the establishment of new liaison relationships, including but not limited to IEEE 802.11af and IEEE 802.22. In order to ensure that it takes into account a broad range of possible use cases and requirements, the group should also reach out to other potential "customers" for a white space database access method and consider input from regulatory entities that are involved in the specification of the rules for secondary use of spectrum in specific radio bands. Deliverables 1. A description of the relevant use cases and requirements. This document shall be Informational. Subject to working group consensus, draft-probasco-paws-overview-usecases and draft-patil-paws-problem-stmt might be used as a starting point. 2. A specification of the mechanism for discovering a white space database, the method for accessing a white space database, and the wire format for querying and receiving responses from a white space database. This document shall be Standards Track. Milestones Oct 2011 Submit 'Use Cases and Requirements for Accessing a Radio White Space Database' to the IESG for publication as Informational Apr 2012 Submit 'Accessing a Radio White Space Database' to the IESG for publication as Proposed Standard ### _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws --_000_53093B779AA14E14882080529414FD4Dneustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

On Jun 6, 2011, at 8:0= 3 AM, Barlow Keener wrote:

Scott,

I think this presents a good q= uestion about WS PAWS:

Q =93If the database replies with an empty channe= l list (no channels available) then the white space radio must not transmit= .=94

I have wondered about this question because if the WS rad= io attempts to =93contact=94 the database in order to determine what spectr= um/channels are unlicensed in a particular geographical area =96 by g= oing through or sending out a transmit signal on the various spectrum/chann= els that are =93possible=94 WS channels to use in all geographies, then by = definition the WS radio will =93interfere=94 by using this transmit signal = with other licensed spectrum/channels. Correct?

How is this= problem solved? It is defined in PAWS almost as a question but not a= nswered =96 at least that is my view.

Thanks!=

Barlow<= o:p>

Barlow Keener

617-671-1202=

Barlow= Keener | Attorney | Keen= er Law Group
Internet and telecommunications law

d: 617.671.1202 |= m: 781-858-1588 | bk@keenerlawgroup.com
Follow me on&n= bsp;Twitter http://twitter.com/barlow | LinkedIn = http://www.linkedin.com/in/barlowkeener<= /a> | Blog: www.whydom.co= m

&= nbsp;

From:= paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of scott.probasco@noki= a.com
Sent: Monday, June 06, 2011 5:31 AM
To: mksaji@yahoo.com; stpeter@stpeter.im; paws@ietf.orgSubject: Re: [pa= ws] updated charter

Hi Sajeev,

If the database replies w= ith an empty channel list (no channels available) then the white space radi= o must not transmit.

<= /o:p>

Once a channel list is received with a= t least one available channel, the white space radio may transmit on one of= the available channels. Typically, the white space radio must contact the = database regularly to ensure channel availability. If the white space radio= is not able to contact the database, then the radio must cease transmissio= n in white space within some period of time. The specific details are speci= fied by the local regulator (e.g. FCC in the US, Ofcom in the UK, etc).

The white space communication will ultimately be broken if con= tact with the database is lost. Your question about using white space as a = secondary means of communication is a reasonable question, but beyond the s= cope of the database interface. For example, a device may use cellular radi= o, WiFi and white space radios, switching radios based on some arbitrary de= cisions (such as power consumption, QoS, subscription rate, etc). However t= his type of switching scenario is beyond the scope of the database interfac= e and therefore PAWS.

IMHO, these are good questions about = typical system operation, but have no impact to the charter text.

Regards,

Scott

From: paws-= bounces@ietf.org [mai= lto:paws-bounces@ietf.org] On Behalf Of ext= M.K.Sajeev sajeev
Sent:&nb= sp;Saturday, June 04, 2011 5:27 AM
To: Peter Saint-Andre; paws@ietf.org
Subject: Re: [paws] updated charter

Hi,

This is Sajeev, in= terested in whitespace protocols, and an observer of this group. Reading th= rough the charter I would like to clarify the following.<= /div>

In the below paragraph radio device dis= covers whitespace channel availability time to time. What happens when the = radio device does not find any channels available to initiate transmission,= or if it happen during a session? Will the communication be broken, or the= radio devices use this as a secondary means of communication? Would like t= o get some clarity..

white space impl= ementation, the list of available channels at that
location), it can then select one of the bands from the = list and
begin to transmit and r= eceive on the selected band. If the device's
parameters have changed (e.g., if some amount of time ha= s passed or if
the device has ch= anged location beyond a specified threshold), it might
need to query the database again to determine what w= hite space is still
available.

Sajeev Manikkoth
Mobile: +919663311378

Email: mksaji@ieee.org
http://www.linkedin.com/in/mksajeev

P= eter Saint-Andre <stpeter@stpeter.im>
To: "paws@ietf.or= g" <paws@ietf.org>
Sent: Friday, 3 June 2011, 7:56
Subject:<= /b> [paws] updated charte= r

Here is the charter the emer= ged from discussions among IESG members and
with the BoF chairs.

= ###

Protocol to Access White Space database (paws)
--------------= ----------------------------------
Current Status: Proposed Working Grou= p
Last updated: 2011-06-02

Chairs:
TBD

Applications Are= a Directors:
Pete Resnick <presnick@q= ualcomm.com>
Peter Saint-Andre <s= tpeter@stpeter.im>

Applications Area Advisor:
= ; Peter Saint-Andre <stpeter@stpeter.im>

Ma= iling lists:
General Discussion: paws@ietf.org
To Su= bscribe: https://www.ietf.org/mailman/listinfo/paw= s
Archive: = http://www.ietf.or= g/mail-archive/web/paws/

Description of Working Group:

Ba= ckground

Radio spectrum is a limited resource. National and in= ternational
bodies assign different frequencies for specific uses, and i= n
most cases license the rights to use these frequencies. Locally<= br>unused spectrum is commonly called "white space" and may be made
avai= lable to other services on a basis of non-interference with
the primary = user of the frequencies concerned (if any). This
technique can help "unl= ock" existing spectrum, for example to
enable the wireless communication= s industry to provide more
services over frequencies associated with unu= sed television
channels. An obvious requirement is that white spac= e uses must
not interfere with the primary use of the spectrum. Th= is is
achieved through spatial and/or temporal separation of the
prim= ary user and whitespace user with due consideration made to
the radio ch= aracteristics of the two uses.

Problem Statement

The fundamen= tal problem is enabling a radio device to determine, in
a specific locat= ion and at specific time, if any white space is
available for secondary = use. There are two parties to such an
interaction:

1. A dat= abase containing records about the protected contours (in
space and time= ) of primary spectrum users. Typically, such databases
will be pop= ulated and operated by the appropriate spectrum regulation
bodies in a g= iven locale.

2. A radio device that wishes to query such a database.= Typically, the
the nature of the query will depend on the needs of the = device.

The contents of white space databases, and the needs of radi= o devices,
are being defined elsewhere. However, these parties nee= d a protocol
for communication that will enable radio devices to find ou= t what white
space is available at a given time in a given location.
=
It is expected that white space databases will be reachable via the
= Internet, and that radio devices too will have some form of Internet
con= nectivity, directly or indirectly. Therefore, it is appropriate
to= define an Internet-based protocol for querying white space databases
an= d receiving responses from such databases.

In rough outline, such a = protocol would enable a radio device that
knows its location to complete= the following tasks:

1. Determine the relevant white space database= to query.

2. Connect to the database using a well-defined access me= thod.

3. Provide its geolocation and perhaps other data to the datab= ase
using a well-defined wire format for querying the database.
4. Receive in return a list of currently available white space
&nb= sp; using a well-defined wire format for returning information.

Once= the device learns of the available white space (e.g., in a TV
white spa= ce implementation, the list of available channels at that
location), it = can then select one of the bands from the list and
begin to transmit and= receive on the selected band. If the device's
parameters have cha= nged (e.g., if some amount of time has passed or if
the device has chang= ed location beyond a specified threshold), it might
need to query the da= tabase again to determine what white space is still
available.

Ob= jectives

The overall goals of this working group are to:

1. S= tandardize a mechanism for discovering a white space database.

2. St= andardize a method for accessing a white space database.

3. Standard= ize wire formats to be carried over the database
access method (i.e., fo= rmats for queries and responses).

4. Ensure that the discovery mecha= nism, database access method,
and wire formats have appropriate security= levels in place.

By "standardize" is not meant that the working gro= up will necessarily
develop new technologies. In completing its wo= rk, the group will:

- Evaluate existing discovery mechanisms to dete= rmine if one of
them provides the necessary application features = and security
properties (or can be extended to do so) for discove= ring a
white space database. Examples might include DNS.
- Evaluate existing application-layer transport protocols to
= determine if one of them provides the necessary application
feat= ures and security properties (or can be extended to do so)
for us= e as a building block for communication between location-
aware d= evices and white space databases. If such a method
exists, = the group will reuse it; if not, the group will develop
one. = ; Examples might include HTTP.

- Develop a method for querying a whi= te space database. Such
a method will utilize, so far as po= ssible, the features of
the application-layer transport protocol = and not re-implement
them in the new protocol. It will include me= chanisms to verify
that the requests and responses come from auth= orized sources,
and that they have not been modified in transit.&= nbsp; Examples might
include LDAP.

- Define extensible wir= e formats for both location-specific queries
and location-specifi= c responses for interaction with radio white
space databases.&nbs= p; The group will consider whether existing data
formats can be r= eused.

The protocol must protect both the channel enablement process= and the
privacy of users. Robust privacy and security mechanisms = are needed
to prevent: device identity spoofing, modification of device = requests,
modification of channel enablement information, impersonation = of
registered database services, and unauthorized disclosure of a device= 's
location. The group will consider whether existing privacy and<= br>security mechanisms can be reused.

The task of defining the struc= ture and contents of the databases
themselves is out of scope. The= group will standardize wire formats
for communication between devices a= nd databases, but not the information
models for the databases, since th= ose models are likely to be
country-specific or application-specific.&nb= sp; In addition, the particular
data exchanged between a device and a da= tabase might depend on the
ranges of radio spectrum that are to be used,= the requirements of the
database operators and their governing regulati= ons, and other factors.
Therefore, the database access method and the qu= ery/response data
formats that are exchanged using that method need to b= e designed for
extensibility rather than being tied to any specific spec= trum, country,
or phy/mac/air interface. For example, the working = group should define
extension points for the database access method and = the wire formats
that are used to query a database and respond to querie= s, so that use
cases other than those currently envisioned can be addres= sed in the
future if a community of interest wishes to do so. Howe= ver, the
access method and wire formats will incorporate relevant aspect= s of
the parameters needed for the currently envisioned use cases to ens= ure
proper operation.

In accordance with existing IETF processes,= the group will communicate
and invite participation with other relevant= standards bodies and
groups, and if necessary reuse existing liaison re= lationships or
request the establishment of new liaison relationships, i= ncluding but
not limited to IEEE 802.11af and IEEE 802.22. In orde= r to ensure that
it takes into account a broad range of possible use cas= es and
requirements, the group should also reach out to other potential<= br>"customers" for a white space database access method and consider input<= br>from regulatory entities that are involved in the specification of therules for secondary use of spectrum in specific radio bands.

Deliv= erables

1. A description of the relevant use cases and requirements.= This
document shall be Informational. Subject to working gr= oup consensus,
draft-probasco-paws-overview-usecases and draft-patil-paw= s-problem-stmt
might be used as a starting point.

2. A specificat= ion of the mechanism for discovering a white space
database, the method = for accessing a white space database, and the
wire format for querying a= nd receiving responses from a white space
database. This document = shall be Standards Track.

Milestones

Oct 2011 Submit 'Use Cas= es and Requirements for Accessing a Radio White
Space Database' to the I= ESG for publication as Informational

Apr 2012 Submit 'Accessing a Ra= dio White Space Database' to the IESG
for publication as Proposed Standa= rd

###

__________________________________________= _____
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/listinfo/p= aws

<ATT00001..tx= t>

= --_000_53093B779AA14E14882080529414FD4Dneustarbiz_-- From gerald.chouinard@crc.ca Mon Jun 6 06:41:37 2011 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90DEA11E813C for ; Mon, 6 Jun 2011 06:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QAW4XJQTorUy for ; Mon, 6 Jun 2011 06:41:36 -0700 (PDT) Received: from mailgw01.crc.ca (mailgw01.crc.ca [142.92.160.200]) by ietfa.amsl.com (Postfix) with SMTP id 79E9911E811E for ; Mon, 6 Jun 2011 06:41:35 -0700 (PDT) Received: from scanner.crc.ca (scanner.crc.ca [142.92.60.102]) by mailgw01.crc.ca (Postfix) with SMTP id 0A1B26B03DE; Mon, 6 Jun 2011 09:41:34 -0400 (EDT) Received: from scanner.crc.ca (localhost.localdomain [127.0.0.1]) by scanner.crc.ca (Postfix) with ESMTP id E30BF6B03BC; Mon, 6 Jun 2011 09:41:33 -0400 (EDT) Received: by scanner.crc.ca (Postfix, from userid 501) id D49E66B03E1; Mon, 6 Jun 2011 09:41:33 -0400 (EDT) Received: from mailhub.crc.ca (mail.crc.ca [142.92.60.201]) by scanner.crc.ca (Postfix) with ESMTP id 646446B03BC; Mon, 6 Jun 2011 09:41:29 -0400 (EDT) Received: from Gerald-2.crc.ca (vpn-03.rem.crc.ca [142.92.171.13]) by mailhub.crc.ca (Postfix) with ESMTP id C84DA6B0DA0; Mon, 6 Jun 2011 09:41:28 -0400 (EDT) Message-Id: <5.1.0.14.2.20110606092059.03d65e28@imap.crc.ca> X-Sender: gchouin@imap.crc.ca X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 06 Jun 2011 09:41:17 -0400 To: "Rosen, Brian" , "bk@keenerlawgroup.com" From: Gerald Chouinard In-Reply-To: <53093B77-9AA1-4E14-8820-80529414FD4D@neustar.biz> References: <009301cc2441$ba0ab5c0$2e202140$@keenerlawgroup.com> <4DE8466C.9010201@stpeter.im> <205283.1524.qm@web34508.mail.mud.yahoo.com> <88BE24FD9280884487DEAE0CE1FD3A5B0319B242@008-AM1MPN1-021.mgdnok.nokia.com> <009301cc2441$ba0ab5c0$2e202140$@keenerlawgroup.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: ClamAV using ClamSMTP Cc: "paws@ietf.org" , "mksaji@yahoo.com" Subject: Re: [paws] updated charter X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database $PAWS$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 13:41:37 -0000 All, This is an interesting discussion that we had in the IEEE 802.22 when we=20 realized this conundrum when a customer premise equipment (CPE) tries to=20 contact a base station (BS) that it has discovered in its area. The BS may= =20 be able to operate because the field strength that it produces is low=20 enough to avoid interference to the nearby DTV operation. However, if a=20 CPE tries to transmit from where it is located, this generates interference= =20 to the close-by DTV receivers (note that in 802.22, the BS is used as proxy= =20 for all its CPEs for the purpose of contacting the database service). The= =20 solution that was selected was to reduce the amout of initial information=20 to be sent to the BS at the time of association (e.g., CPE identification=20 and its geographic location) to reduce the transmit burst length to its=20 minimum to reduce the impact to the close-by DTV receivers as much as=20 possible. This can be done at the PHY and MAC level and would be beyond=20 the scope of the IETF-PAWS. Also, I would like to point out that the option for the database service to= =20 indicate the maximum allowed EIRP that the TVWS can use in its location=20 (e.g., 8 bit data field: range -64 dBm (encoded 0x00) to +63.5 dBm (encoded= =20 0xFF)) should be included rather than only indicating whether the channel=20 is available or not (1 bit field). This option, which automatically=20 includes the go/no-go switch (e.g., 0x00: unavailable), would allow for=20 much smoother transitions at the edge of the DTV coverage areas and more=20 flexibility in the TVWS operation. Gerald At 08:56 06-06-11 -0400, Rosen, Brian wrote: >There are several strategies that can be used. One end has to have an=20 >independent Internet access mechanism. It can determine what channels it,= =20 >and it's "clients" can use and broadcast them, or use one channel as a=20 >beacon, allow the clients to access it on the beacon channel, and then=20 >assign a channel to the client. There are other strategies. > >Brian > >On Jun 6, 2011, at 8:03 AM, Barlow Keener wrote: > >>Scott, >> >>I think this presents a good question about WS PAWS: >> >>Q =93If the database replies with an empty channel list (no channels=20 >>available) then the white space radio must not transmit.=94 >> >>I have wondered about this question because if the WS radio attempts to=20 >>=93contact=94 the database in order to determine what spectrum/channels= are=20 >>unlicensed in a particular geographical area =96 by going through or=20 >>sending out a transmit signal on the various spectrum/channels that are=20 >>=93possible=94 WS channels to use in all geographies, then by definition= the=20 >>WS radio will =93interfere=94 by using this transmit signal with other=20 >>licensed spectrum/channels. Correct? >> >>How is this problem solved? It is defined in PAWS almost as a question=20 >>but not answered =96 at least that is my view. >> >>Thanks! >> >>Barlow >> >>Barlow Keener >>617-671-1202 >> >>Barlow Keener | Attorney | Keener Law= Group >>Internet and telecommunications law >> >>d: 617.671.1202 | m: 781-858-1588 |=20 >>bk@keenerlawgroup.com >>Follow me on Twitter=20 >>http://twitter.com/bar= low=20 >>| LinkedIn=20 >>http://www.linkedin.com/in/barlow= keener=20 >>| Blog: www.whydom.com >> >> >>From: paws-bounces@ietf.org=20 >>[mailto:paws-bounces@ietf.org] On Behalf Of=20 >>scott.probasco@nokia.com >>Sent: Monday, June 06, 2011 5:31 AM >>To: mksaji@yahoo.com;=20 >>stpeter@stpeter.im;=20 >>paws@ietf.org >>Subject: Re: [paws] updated charter >> >>Hi Sajeev, >> >>If the database replies with an empty channel list (no channels=20 >>available) then the white space radio must not transmit. >> >>Once a channel list is received with at least one available channel, the= =20 >>white space radio may transmit on one of the available channels.=20 >>Typically, the white space radio must contact the database regularly to=20 >>ensure channel availability. If the white space radio is not able to=20 >>contact the database, then the radio must cease transmission in white=20 >>space within some period of time. The specific details are specified by=20 >>the local regulator (e.g. FCC in the US, Ofcom in the UK, etc). >> >>The white space communication will ultimately be broken if contact with=20 >>the database is lost. Your question about using white space as a=20 >>secondary means of communication is a reasonable question, but beyond the= =20 >>scope of the database interface. For example, a device may use cellular=20 >>radio, WiFi and white space radios, switching radios based on some=20 >>arbitrary decisions (such as power consumption, QoS, subscription rate,=20 >>etc). However this type of switching scenario is beyond the scope of the= =20 >>database interface and therefore PAWS. >> >>IMHO, these are good questions about typical system operation, but have=20 >>no impact to the charter text. >> >>Regards, >>Scott >> >>From: paws-bounces@ietf.org=20 >>[mailto:paws-bounces@ietf.org] On Behalf Of ext M.K.Sajeev sajeev >>Sent: Saturday, June 04, 2011 5:27 AM >>To: Peter Saint-Andre; paws@ietf.org >>Subject: Re: [paws] updated charter >> >>Hi, >> >>This is Sajeev, interested in whitespace protocols, and an observer of=20 >>this group. Reading through the charter I would like to clarify the= following. >>In the below paragraph radio device discovers whitespace channel=20 >>availability time to time. What happens when the radio device does not=20 >>find any channels available to initiate transmission, or if it happen=20 >>during a session? Will the communication be broken, or the radio devices= =20 >>use this as a secondary means of communication? Would like to get some=20 >>clarity.. >> >>Once the device learns of the available white space (e.g., in a TV >>white space implementation, the list of available channels at that >>location), it can then select one of the bands from the list and >>begin to transmit and receive on the selected band. If the device's >>parameters have changed (e.g., if some amount of time has passed or if >>the device has changed location beyond a specified threshold), it might >>need to query the database again to determine what white space is still >>available. >> >>Sajeev Manikkoth >>Mobile: +919663311378 >> >>Email: mksaji@ieee.org >>http://www.linkedin.com/in/mksajeev >> >>From: Peter Saint-Andre <stpeter@stpeter.im> >>To: "paws@ietf.org"=20 >><paws@ietf.org> >>Sent: Friday, 3 June 2011, 7:56 >>Subject: [paws] updated charter >> >>Here is the charter the emerged from discussions among IESG members and >>with the BoF chairs. >> >>### >> >>Protocol to Access White Space database (paws) >>------------------------------------------------ >>Current Status: Proposed Working Group >>Last updated: 2011-06-02 >> >>Chairs: >>TBD >> >>Applications Area Directors: >> Pete Resnick <presnick@qualcomm.com> >> Peter Saint-Andre <stpeter@stpeter.im> >> >>Applications Area Advisor: >> Peter Saint-Andre <stpeter@stpeter.im> >> >>Mailing lists: >> General Discussion: paws@ietf.org >> To Subscribe:=20 >>= https://www.ietf.org/mailman/li= stinfo/paws >> Archive:=20 >>= http://www.ietf.org/mail-archiv= e/web/paws/ >> >>Description of Working Group: >> >>Background >> >>Radio spectrum is a limited resource. National and international >>bodies assign different frequencies for specific uses, and in >>most cases license the rights to use these frequencies. Locally >>unused spectrum is commonly called "white space" and may be made >>available to other services on a basis of non-interference with >>the primary user of the frequencies concerned (if any). This >>technique can help "unlock" existing spectrum, for example to >>enable the wireless communications industry to provide more >>services over frequencies associated with unused television >>channels. An obvious requirement is that white space uses must >>not interfere with the primary use of the spectrum. This is >>achieved through spatial and/or temporal separation of the >>primary user and whitespace user with due consideration made to >>the radio characteristics of the two uses. >> >>Problem Statement >> >>The fundamental problem is enabling a radio device to determine, in >>a specific location and at specific time, if any white space is >>available for secondary use. There are two parties to such an >>interaction: >> >>1. A database containing records about the protected contours (in >>space and time) of primary spectrum users. Typically, such databases >>will be populated and operated by the appropriate spectrum regulation >>bodies in a given locale. >> >>2. A radio device that wishes to query such a database. Typically, the >>the nature of the query will depend on the needs of the device. >> >>The contents of white space databases, and the needs of radio devices, >>are being defined elsewhere. However, these parties need a protocol >>for communication that will enable radio devices to find out what white >>space is available at a given time in a given location. >> >>It is expected that white space databases will be reachable via the >>Internet, and that radio devices too will have some form of Internet >>connectivity, directly or indirectly. Therefore, it is appropriate >>to define an Internet-based protocol for querying white space databases >>and receiving responses from such databases. >> >>In rough outline, such a protocol would enable a radio device that >>knows its location to complete the following tasks: >> >>1. Determine the relevant white space database to query. >> >>2. Connect to the database using a well-defined access method. >> >>3. Provide its geolocation and perhaps other data to the database >> using a well-defined wire format for querying the database. >> >>4. Receive in return a list of currently available white space >> using a well-defined wire format for returning information. >> >>Once the device learns of the available white space (e.g., in a TV >>white space implementation, the list of available channels at that >>location), it can then select one of the bands from the list and >>begin to transmit and receive on the selected band. If the device's >>parameters have changed (e.g., if some amount of time has passed or if >>the device has changed location beyond a specified threshold), it might >>need to query the database again to determine what white space is still >>available. >> >>Objectives >> >>The overall goals of this working group are to: >> >>1. Standardize a mechanism for discovering a white space database. >> >>2. Standardize a method for accessing a white space database. >> >>3. Standardize wire formats to be carried over the database >>access method (i.e., formats for queries and responses). >> >>4. Ensure that the discovery mechanism, database access method, >>and wire formats have appropriate security levels in place. >> >>By "standardize" is not meant that the working group will necessarily >>develop new technologies. In completing its work, the group will: >> >>- Evaluate existing discovery mechanisms to determine if one of >> them provides the necessary application features and security >> properties (or can be extended to do so) for discovering a >> white space database. Examples might include DNS. >> >>- Evaluate existing application-layer transport protocols to >> determine if one of them provides the necessary application >> features and security properties (or can be extended to do so) >> for use as a building block for communication between location- >> aware devices and white space databases. If such a method >> exists, the group will reuse it; if not, the group will develop >> one. Examples might include HTTP. >> >>- Develop a method for querying a white space database. Such >> a method will utilize, so far as possible, the features of >> the application-layer transport protocol and not re-implement >> them in the new protocol. It will include mechanisms to verify >> that the requests and responses come from authorized sources, >> and that they have not been modified in transit. Examples might >> include LDAP. >> >>- Define extensible wire formats for both location-specific queries >> and location-specific responses for interaction with radio white >> space databases. The group will consider whether existing data >> formats can be reused. >> >>The protocol must protect both the channel enablement process and the >>privacy of users. Robust privacy and security mechanisms are needed >>to prevent: device identity spoofing, modification of device requests, >>modification of channel enablement information, impersonation of >>registered database services, and unauthorized disclosure of a device's >>location. The group will consider whether existing privacy and >>security mechanisms can be reused. >> >>The task of defining the structure and contents of the databases >>themselves is out of scope. The group will standardize wire formats >>for communication between devices and databases, but not the information >>models for the databases, since those models are likely to be >>country-specific or application-specific. In addition, the particular >>data exchanged between a device and a database might depend on the >>ranges of radio spectrum that are to be used, the requirements of the >>database operators and their governing regulations, and other factors. >>Therefore, the database access method and the query/response data >>formats that are exchanged using that method need to be designed for >>extensibility rather than being tied to any specific spectrum, country, >>or phy/mac/air interface. For example, the working group should define >>extension points for the database access method and the wire formats >>that are used to query a database and respond to queries, so that use >>cases other than those currently envisioned can be addressed in the >>future if a community of interest wishes to do so. However, the >>access method and wire formats will incorporate relevant aspects of >>the parameters needed for the currently envisioned use cases to ensure >>proper operation. >> >>In accordance with existing IETF processes, the group will communicate >>and invite participation with other relevant standards bodies and >>groups, and if necessary reuse existing liaison relationships or >>request the establishment of new liaison relationships, including but >>not limited to IEEE 802.11af and IEEE 802.22. In order to ensure that >>it takes into account a broad range of possible use cases and >>requirements, the group should also reach out to other potential >>"customers" for a white space database access method and consider input >>from regulatory entities that are involved in the specification of the >>rules for secondary use of spectrum in specific radio bands. >> >>Deliverables >> >>1. A description of the relevant use cases and requirements. This >>document shall be Informational. Subject to working group consensus, >>draft-probasco-paws-overview-usecases and draft-patil-paws-problem-stmt >>might be used as a starting point. >> >>2. A specification of the mechanism for discovering a white space >>database, the method for accessing a white space database, and the >>wire format for querying and receiving responses from a white space >>database. This document shall be Standards Track. >> >>Milestones >> >>Oct 2011 Submit 'Use Cases and Requirements for Accessing a Radio White >>Space Database' to the IESG for publication as Informational >> >>Apr 2012 Submit 'Accessing a Radio White Space Database' to the IESG >>for publication as Proposed Standard >> >>### >> >> >> >> >>_______________________________________________ >>paws mailing list >>paws@ietf.org >>https://www.ietf.org/mailman/listinfo/paws >> > >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws From brian.rosen@neustar.biz Mon Jun 6 06:52:10 2011 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D09A11E811E for ; Mon, 6 Jun 2011 06:52:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SS92tp3MvvCt for ; Mon, 6 Jun 2011 06:52:07 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 6953611E80F7 for ; Mon, 6 Jun 2011 06:52:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1307368325; x=1622700350; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=JzkAVaXda2JFedHqrFrKJ gZD0wzgLQPrySPNTz2rlrE=; b=MKEGNBIOwCnmeBloJnORNDFYk3/K7zz+OYDVH DevWZnx6NEu/WArxa/1Rb+lAG9C/dP8a/wbYbxipDvTpajxRg== Received: from ([10.31.13.242]) by chihiron2.nc.neustar.com with ESMTP with TLS id 5202415.38150498; Mon, 06 Jun 2011 09:52:04 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Mon, 6 Jun 2011 09:52:03 -0400 From: "Rosen, Brian" To: Gerald Chouinard Date: Mon, 6 Jun 2011 09:52:02 -0400 Thread-Topic: [paws] updated charter Thread-Index: AcwkUOoZmV6XkPiURs6L9maPSuDPSg== Message-ID: <3F9AECC3-823F-4EC9-87B3-28FCEB89BDC4@neustar.biz> References: <009301cc2441$ba0ab5c0$2e202140$@keenerlawgroup.com> <4DE8466C.9010201@stpeter.im> <205283.1524.qm@web34508.mail.mud.yahoo.com> <88BE24FD9280884487DEAE0CE1FD3A5B0319B242@008-AM1MPN1-021.mgdnok.nokia.com> <009301cc2441$ba0ab5c0$2e202140$@keenerlawgroup.com> <5.1.0.14.2.20110606092059.03d65e28@imap.crc.ca> In-Reply-To: <5.1.0.14.2.20110606092059.03d65e28@imap.crc.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: LoibH+nYxe88IeMwZRvuuA== Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" , "mksaji@yahoo.com" Subject: Re: [paws] updated charter X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database $PAWS$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 13:52:10 -0000 Yeah, I should have pointed out that this discussion is beyond the charter. Thank you for the power suggestion on the return. While some nations don't= allow that, I've heard discussions that it might be allowed in some nation= s. Getting a bit ahead of ourselves, what we see in many regulations are "buck= ets" (enumerated values with associated power levels) rather than explicit = values, so the output format would have to have something like a series and= a value, where one of the series options was "dBm". When a regulator has = "bucket" power levels, we can create a new series, with the values the regu= lator specifies. Brian On Jun 6, 2011, at 9:41 AM, Gerald Chouinard wrote: > All, > > This is an interesting discussion that we had in the IEEE 802.22 when we > realized this conundrum when a customer premise equipment (CPE) tries to > contact a base station (BS) that it has discovered in its area. The BS ma= y > be able to operate because the field strength that it produces is low > enough to avoid interference to the nearby DTV operation. However, if a > CPE tries to transmit from where it is located, this generates interferen= ce > to the close-by DTV receivers (note that in 802.22, the BS is used as pro= xy > for all its CPEs for the purpose of contacting the database service). Th= e > solution that was selected was to reduce the amout of initial information > to be sent to the BS at the time of association (e.g., CPE identification > and its geographic location) to reduce the transmit burst length to its > minimum to reduce the impact to the close-by DTV receivers as much as > possible. This can be done at the PHY and MAC level and would be beyond > the scope of the IETF-PAWS. > > Also, I would like to point out that the option for the database service = to > indicate the maximum allowed EIRP that the TVWS can use in its location > (e.g., 8 bit data field: range -64 dBm (encoded 0x00) to +63.5 dBm (encod= ed > 0xFF)) should be included rather than only indicating whether the channel > is available or not (1 bit field). This option, which automatically > includes the go/no-go switch (e.g., 0x00: unavailable), would allow for > much smoother transitions at the edge of the DTV coverage areas and more > flexibility in the TVWS operation. > > Gerald > > > At 08:56 06-06-11 -0400, Rosen, Brian wrote: >> There are several strategies that can be used. One end has to have an >> independent Internet access mechanism. It can determine what channels i= t, >> and it's "clients" can use and broadcast them, or use one channel as a >> beacon, allow the clients to access it on the beacon channel, and then >> assign a channel to the client. There are other strategies. >> >> Brian >> >> On Jun 6, 2011, at 8:03 AM, Barlow Keener wrote: >> >>> Scott, >>> >>> I think this presents a good question about WS PAWS: >>> >>> Q =93If the database replies with an empty channel list (no channels >>> available) then the white space radio must not transmit.=94 >>> >>> I have wondered about this question because if the WS radio attempts to >>> =93contact=94 the database in order to determine what spectrum/channels= are >>> unlicensed in a particular geographical area =96 by going through or >>> sending out a transmit signal on the various spectrum/channels that are >>> =93possible=94 WS channels to use in all geographies, then by definitio= n the >>> WS radio will =93interfere=94 by using this transmit signal with other >>> licensed spectrum/channels. Correct? >>> >>> How is this problem solved? It is defined in PAWS almost as a question >>> but not answered =96 at least that is my view. >>> >>> Thanks! >>> >>> Barlow >>> >>> Barlow Keener >>> 617-671-1202 >>> >>> Barlow Keener | Attorney | Keener Law G= roup >>> Internet and telecommunications law >>> >>> d: 617.671.1202 | m: 781-858-1588 | >>> bk@keenerlawgroup.com >>> Follow me on Twitter >>> http://twitter.com/= barlow >>> | LinkedIn >>> http://www.linkedin.com/in/bar= lowkeener >>> | Blog: www.whydom.com >>> >>> >>> From: paws-bounces@ietf.org >>> [mailto:paws-bounces@ietf.org] On Behalf Of >>> scott.probasco@nokia.com >>> Sent: Monday, June 06, 2011 5:31 AM >>> To: mksaji@yahoo.com; >>> stpeter@stpeter.im; >>> paws@ietf.org >>> Subject: Re: [paws] updated charter >>> >>> Hi Sajeev, >>> >>> If the database replies with an empty channel list (no channels >>> available) then the white space radio must not transmit. >>> >>> Once a channel list is received with at least one available channel, th= e >>> white space radio may transmit on one of the available channels. >>> Typically, the white space radio must contact the database regularly to >>> ensure channel availability. If the white space radio is not able to >>> contact the database, then the radio must cease transmission in white >>> space within some period of time. The specific details are specified by >>> the local regulator (e.g. FCC in the US, Ofcom in the UK, etc). >>> >>> The white space communication will ultimately be broken if contact with >>> the database is lost. Your question about using white space as a >>> secondary means of communication is a reasonable question, but beyond t= he >>> scope of the database interface. For example, a device may use cellular >>> radio, WiFi and white space radios, switching radios based on some >>> arbitrary decisions (such as power consumption, QoS, subscription rate, >>> etc). However this type of switching scenario is beyond the scope of th= e >>> database interface and therefore PAWS. >>> >>> IMHO, these are good questions about typical system operation, but have >>> no impact to the charter text. >>> >>> Regards, >>> Scott >>> >>> From: paws-bounces@ietf.org >>> [mailto:paws-bounces@ietf.org] On Behalf Of ext M.K.Sajeev sajeev >>> Sent: Saturday, June 04, 2011 5:27 AM >>> To: Peter Saint-Andre; paws@ietf.org >>> Subject: Re: [paws] updated charter >>> >>> Hi, >>> >>> This is Sajeev, interested in whitespace protocols, and an observer of >>> this group. Reading through the charter I would like to clarify the fol= lowing. >>> In the below paragraph radio device discovers whitespace channel >>> availability time to time. What happens when the radio device does not >>> find any channels available to initiate transmission, or if it happen >>> during a session? Will the communication be broken, or the radio device= s >>> use this as a secondary means of communication? Would like to get some >>> clarity.. >>> >>> Once the device learns of the available white space (e.g., in a TV >>> white space implementation, the list of available channels at that >>> location), it can then select one of the bands from the list and >>> begin to transmit and receive on the selected band. If the device's >>> parameters have changed (e.g., if some amount of time has passed or if >>> the device has changed location beyond a specified threshold), it might >>> need to query the database again to determine what white space is still >>> available. >>> >>> Sajeev Manikkoth >>> Mobile: +919663311378 >>> >>> Email: mksaji@ieee.org >>> http://www.linkedin.com/in/mksajee= v >>> >>> From: Peter Saint-Andre <stpeter@stpeter.im> >>> To: "paws@ietf.org" >>> <paws@ietf.org> >>> Sent: Friday, 3 June 2011, 7:56 >>> Subject: [paws] updated charter >>> >>> Here is the charter the emerged from discussions among IESG members and >>> with the BoF chairs. >>> >>> ### >>> >>> Protocol to Access White Space database (paws) >>> ------------------------------------------------ >>> Current Status: Proposed Working Group >>> Last updated: 2011-06-02 >>> >>> Chairs: >>> TBD >>> >>> Applications Area Directors: >>> Pete Resnick <presnick@qualcomm.com> >>> Peter Saint-Andre <stpeter@stpeter.im> >>> >>> Applications Area Advisor: >>> Peter Saint-Andre <stpeter@stpeter.im> >>> >>> Mailing lists: >>> General Discussion: paws@ietf.org >>> To Subscribe: >>> https://www.ietf.org/mailma= n/listinfo/paws >>> Archive: >>> http://www.ietf.org/mail-ar= chive/web/paws/ >>> >>> Description of Working Group: >>> >>> Background >>> >>> Radio spectrum is a limited resource. National and international >>> bodies assign different frequencies for specific uses, and in >>> most cases license the rights to use these frequencies. Locally >>> unused spectrum is commonly called "white space" and may be made >>> available to other services on a basis of non-interference with >>> the primary user of the frequencies concerned (if any). This >>> technique can help "unlock" existing spectrum, for example to >>> enable the wireless communications industry to provide more >>> services over frequencies associated with unused television >>> channels. An obvious requirement is that white space uses must >>> not interfere with the primary use of the spectrum. This is >>> achieved through spatial and/or temporal separation of the >>> primary user and whitespace user with due consideration made to >>> the radio characteristics of the two uses. >>> >>> Problem Statement >>> >>> The fundamental problem is enabling a radio device to determine, in >>> a specific location and at specific time, if any white space is >>> available for secondary use. There are two parties to such an >>> interaction: >>> >>> 1. A database containing records about the protected contours (in >>> space and time) of primary spectrum users. Typically, such databases >>> will be populated and operated by the appropriate spectrum regulation >>> bodies in a given locale. >>> >>> 2. A radio device that wishes to query such a database. Typically, the >>> the nature of the query will depend on the needs of the device. >>> >>> The contents of white space databases, and the needs of radio devices, >>> are being defined elsewhere. However, these parties need a protocol >>> for communication that will enable radio devices to find out what white >>> space is available at a given time in a given location. >>> >>> It is expected that white space databases will be reachable via the >>> Internet, and that radio devices too will have some form of Internet >>> connectivity, directly or indirectly. Therefore, it is appropriate >>> to define an Internet-based protocol for querying white space databases >>> and receiving responses from such databases. >>> >>> In rough outline, such a protocol would enable a radio device that >>> knows its location to complete the following tasks: >>> >>> 1. Determine the relevant white space database to query. >>> >>> 2. Connect to the database using a well-defined access method. >>> >>> 3. Provide its geolocation and perhaps other data to the database >>> using a well-defined wire format for querying the database. >>> >>> 4. Receive in return a list of currently available white space >>> using a well-defined wire format for returning information. >>> >>> Once the device learns of the available white space (e.g., in a TV >>> white space implementation, the list of available channels at that >>> location), it can then select one of the bands from the list and >>> begin to transmit and receive on the selected band. If the device's >>> parameters have changed (e.g., if some amount of time has passed or if >>> the device has changed location beyond a specified threshold), it might >>> need to query the database again to determine what white space is still >>> available. >>> >>> Objectives >>> >>> The overall goals of this working group are to: >>> >>> 1. Standardize a mechanism for discovering a white space database. >>> >>> 2. Standardize a method for accessing a white space database. >>> >>> 3. Standardize wire formats to be carried over the database >>> access method (i.e., formats for queries and responses). >>> >>> 4. Ensure that the discovery mechanism, database access method, >>> and wire formats have appropriate security levels in place. >>> >>> By "standardize" is not meant that the working group will necessarily >>> develop new technologies. In completing its work, the group will: >>> >>> - Evaluate existing discovery mechanisms to determine if one of >>> them provides the necessary application features and security >>> properties (or can be extended to do so) for discovering a >>> white space database. Examples might include DNS. >>> >>> - Evaluate existing application-layer transport protocols to >>> determine if one of them provides the necessary application >>> features and security properties (or can be extended to do so) >>> for use as a building block for communication between location- >>> aware devices and white space databases. If such a method >>> exists, the group will reuse it; if not, the group will develop >>> one. Examples might include HTTP. >>> >>> - Develop a method for querying a white space database. Such >>> a method will utilize, so far as possible, the features of >>> the application-layer transport protocol and not re-implement >>> them in the new protocol. It will include mechanisms to verify >>> that the requests and responses come from authorized sources, >>> and that they have not been modified in transit. Examples might >>> include LDAP. >>> >>> - Define extensible wire formats for both location-specific queries >>> and location-specific responses for interaction with radio white >>> space databases. The group will consider whether existing data >>> formats can be reused. >>> >>> The protocol must protect both the channel enablement process and the >>> privacy of users. Robust privacy and security mechanisms are needed >>> to prevent: device identity spoofing, modification of device requests, >>> modification of channel enablement information, impersonation of >>> registered database services, and unauthorized disclosure of a device's >>> location. The group will consider whether existing privacy and >>> security mechanisms can be reused. >>> >>> The task of defining the structure and contents of the databases >>> themselves is out of scope. The group will standardize wire formats >>> for communication between devices and databases, but not the informatio= n >>> models for the databases, since those models are likely to be >>> country-specific or application-specific. In addition, the particular >>> data exchanged between a device and a database might depend on the >>> ranges of radio spectrum that are to be used, the requirements of the >>> database operators and their governing regulations, and other factors. >>> Therefore, the database access method and the query/response data >>> formats that are exchanged using that method need to be designed for >>> extensibility rather than being tied to any specific spectrum, country, >>> or phy/mac/air interface. For example, the working group should define >>> extension points for the database access method and the wire formats >>> that are used to query a database and respond to queries, so that use >>> cases other than those currently envisioned can be addressed in the >>> future if a community of interest wishes to do so. However, the >>> access method and wire formats will incorporate relevant aspects of >>> the parameters needed for the currently envisioned use cases to ensure >>> proper operation. >>> >>> In accordance with existing IETF processes, the group will communicate >>> and invite participation with other relevant standards bodies and >>> groups, and if necessary reuse existing liaison relationships or >>> request the establishment of new liaison relationships, including but >>> not limited to IEEE 802.11af and IEEE 802.22. In order to ensure that >>> it takes into account a broad range of possible use cases and >>> requirements, the group should also reach out to other potential >>> "customers" for a white space database access method and consider input >>> from regulatory entities that are involved in the specification of the >>> rules for secondary use of spectrum in specific radio bands. >>> >>> Deliverables >>> >>> 1. A description of the relevant use cases and requirements. This >>> document shall be Informational. Subject to working group consensus, >>> draft-probasco-paws-overview-usecases and draft-patil-paws-problem-stmt >>> might be used as a starting point. >>> >>> 2. A specification of the mechanism for discovering a white space >>> database, the method for accessing a white space database, and the >>> wire format for querying and receiving responses from a white space >>> database. This document shall be Standards Track. >>> >>> Milestones >>> >>> Oct 2011 Submit 'Use Cases and Requirements for Accessing a Radio White >>> Space Database' to the IESG for publication as Informational >>> >>> Apr 2012 Submit 'Accessing a Radio White Space Database' to the IESG >>> for publication as Proposed Standard >>> >>> ### >>> >>> >>> >>> >>> _______________________________________________ >>> paws mailing list >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws >>> >> >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws > > > From mksaji@yahoo.com Tue Jun 7 09:34:29 2011 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4D1421F846F for ; Tue, 7 Jun 2011 09:34:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.491 X-Spam-Level: **** X-Spam-Status: No, score=4.491 tagged_above=-999 required=5 tests=[AWL=3.890, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, REPTO_QUOTE_YAHOO=2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3djwrkdxihJM for ; Tue, 7 Jun 2011 09:34:25 -0700 (PDT) Received: from nm10-vm0.bullet.mail.sp2.yahoo.com (nm10-vm0.bullet.mail.sp2.yahoo.com [98.139.91.198]) by ietfa.amsl.com (Postfix) with SMTP id 9ED2621F846A for ; Tue, 7 Jun 2011 09:34:19 -0700 (PDT) Received: from [98.139.91.68] by nm10.bullet.mail.sp2.yahoo.com with NNFMP; 07 Jun 2011 16:34:15 -0000 Received: from [98.139.91.34] by tm8.bullet.mail.sp2.yahoo.com with NNFMP; 07 Jun 2011 16:34:15 -0000 Received: from [127.0.0.1] by omp1034.mail.sp2.yahoo.com with NNFMP; 07 Jun 2011 16:34:15 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 224108.87499.bm@omp1034.mail.sp2.yahoo.com Received: (qmail 17624 invoked by uid 60001); 7 Jun 2011 16:34:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1307464453; bh=wArhlSjec2Ep77MxCg6fI3qeuBqZBawINHlZHv1TWw0=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=xrO7SJMPRzLAIdXV5UZH+auAtm6P9lghXRdT4Flum3iCnl8sBTwFz7rav67LMgwsl2rqRfd3y2S3AimFtVfwti2O0MYmE5IByDkh6for8FtrNSCTSkdN9UZCqYPy3KirZWSD+WwwC/emiERC6LqqLmTQh/k8jpOXNIro4MD3bt8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=Yb7zzlfXbnWLHyPGgzr+N6udHlmr68Up8sO41xI3GfDsv8mbQpBRqmWt/6mceoB/T5KGdwmkyx04x+q5NnrAVr2H8l7o4JElhlAIE5jDz9ZD+cl+SRJQqJx+A8HoqZyghdWRImJJaq+7KVUhz+lZtX6U7/in8hiM1kqiUeqI3XQ=; Message-ID: <890030.99516.qm@web34502.mail.mud.yahoo.com> X-YMail-OSG: PsfTNW0VM1nOJbKYSninNrfwxTkv9PRMVOyp7hYux4FLf3V BO.9n9pQx8zSFs5Gt.gNUD6Mw08cqJE2CU0cAKF2hhOirD9S6UOhoT6TjVAA J.RDPvEQMmUbKh5XjFn_w2ZYAaqdvho8Ww41ALRxfEPTBr9CZBkM1uA39aVh 7TjVHzbWd2i6jnCYQTK.ll2AyJmpujT0oLkHsdPGu3cbzh2RoyRgrgQo5igd G420jHjCJfSBGKs_2_Tkpvpn14SwmImBQaKdwtx8QyF9JfgHMQp_kLJuhgRW DxYzpeLmmYwruGGDc9kNGOsd84r3J7oKBn6ESKLqdGIJmDIbxOZT7ntb1gPr GqJUoDSt9pdvSz0OhqhcsHXEEdMOZp5ffo3.6rEcOxtScnaDIp5I9cTafYvY aoTOhs4pkUqaCM85C6XYX4ff_IAbS96FHkdUP9mbT0wKcxq7xarFrq_hsUx2 cUXqPrwLYGVqPFq2lkZ2UFRYxaphTPGgNRs.VYXbcyjsffQ-- Received: from [117.192.14.254] by web34502.mail.mud.yahoo.com via HTTP; Tue, 07 Jun 2011 09:34:13 PDT X-Mailer: YahooMailWebService/0.8.111.304355 References: <4DE8466C.9010201@stpeter.im> <205283.1524.qm@web34508.mail.mud.yahoo.com> <88BE24FD9280884487DEAE0CE1FD3A5B0319B242@008-AM1MPN1-021.mgdnok.nokia.com> Date: Tue, 7 Jun 2011 09:34:13 -0700 (PDT) From: "M.K.Sajeev sajeev" To: "scott.probasco@nokia.com" , "stpeter@stpeter.im" , "paws@ietf.org" In-Reply-To: <88BE24FD9280884487DEAE0CE1FD3A5B0319B242@008-AM1MPN1-021.mgdnok.nokia.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1662526456-1307464453=:99516" X-Mailman-Approved-At: Tue, 07 Jun 2011 09:40:15 -0700 Subject: Re: [paws] updated charter X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "M.K.Sajeev sajeev" List-Id: "Protocol to Access White Space database $PAWS$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 16:34:29 -0000 --0-1662526456-1307464453=:99516 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Thanks Scott.=0A=0AI understand it does not directly relate to the charter,= but reading on, got few technical questions and sharing those.=0A=0A"When = channel is not available radio must not transmit"=0A=0AAs white space offer= s very limited channel space, will the radio device =A0get into no transmis= sion mode very often? When radio changes location during transmission, and = no channel available then the data transmission is=A0interrupted=A0or broke= n. Or should whitespace radio also do GSM like channel allocation, locking,= etc.to ensure uninterrupted transmission?=A0=0A=0AAlso does these spec any= ways relate or scope RDS transmission present in FM Radios?=0A=A0=0ASajeev = Manikkoth=0AEmail: mksaji@ieee.org=0Ahttp://www.linkedin.com/in/mksajeev=0A= =0A=0A=0A________________________________=0AFrom: "scott.probasco@nokia.com= " =0ATo: mksaji@yahoo.com; stpeter@stpeter.im; pa= ws@ietf.org=0ASent: Monday, 6 June 2011, 15:01=0ASubject: Re: [paws] update= d charter=0A=0A=0A =0AHi Sajeev,=0A=A0=0AIf the database replies with an em= pty channel list (no channels available) then the white space radio must no= t transmit.=0A=A0=0AOnce a channel list is received with at least one avail= able channel, the white space radio may transmit on one of the available ch= annels. Typically, the white space radio must contact the database regularl= y to ensure channel availability. If the white space radio is not able to c= ontact the database, then the radio must cease transmission in white space = within some period of time. The specific details are specified by the local= regulator (e.g. FCC in the US, Ofcom in the UK, etc). =0A=A0=0AThe white s= pace communication will ultimately be broken if contact with the database i= s lost. Your question about using white space as a secondary means of commu= nication is a reasonable question, but beyond the scope of the database int= erface. For example, a device may use cellular radio, WiFi and white space = radios, switching radios based on some arbitrary decisions (such as power c= onsumption, QoS, subscription rate, etc). However this type of switching sc= enario is beyond the scope of the database interface and therefore PAWS.=0A= =A0=0AIMHO, these are good questions about typical system operation, but ha= ve no impact to the charter text.=0A=A0=0ARegards,=0AScott=0A=A0=0AFrom:paw= s-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext M.K.Saje= ev sajeev=0ASent: Saturday, June 04, 2011 5:27 AM=0ATo: Peter Saint-Andre; = paws@ietf.org=0ASubject: Re: [paws] updated charter=0A=A0=0AHi,=0A=A0=0AThi= s is Sajeev, interested in whitespace protocols, and an observer of this gr= oup. Reading through the charter I would like to clarify the following.=0AI= n the below paragraph radio device discovers whitespace channel availabilit= y time to time. What happens when the radio device does not find any channe= ls available to initiate transmission, or if it happen during a session? Wi= ll the communication be broken, or the radio devices use this as a secondar= y means of communication? Would like to get some clarity..=0A=A0=0AOnce the= device learns of the available white space (e.g., in a TV=0Awhite space im= plementation, the list of available channels at that=0Alocation), it can th= en select one of the bands from the list and=0Abegin to transmit and receiv= e on the selected band.=A0 If the device's=0Aparameters have changed (e.g.,= if some amount of time has passed or if=0Athe device has changed location = beyond a specified threshold), it might=0Aneed to query the database again = to determine what white space is still=0Aavailable.=0A=A0=0ASajeev Manikkot= h=0AMobile: +919663311378=0AEmail: mksaji@ieee.org=0Ahttp://www.linkedin.co= m/in/mksajeev=0A=0A________________________________=0A =0AFrom:Peter Saint-= Andre =0ATo: "paws@ietf.org" =0ASent: Fr= iday, 3 June 2011, 7:56=0ASubject: [paws] updated charter=0A=0AHere is the = charter the emerged from discussions among IESG members and=0Awith the BoF = chairs.=0A=0A###=0A=0AProtocol to Access White Space database (paws)=0A----= --------------------------------------------=0ACurrent Status: Proposed Wor= king Group=0ALast updated: 2011-06-02=0A=0AChairs:=0ATBD=0A=0AApplications = Area Directors:=0A=A0 =A0 Pete Resnick =0A=A0 =A0 Pe= ter Saint-Andre =0A=0AApplications Area Advisor:=0A=A0 = =A0 Peter Saint-Andre =0A=0AMailing lists:=0A=A0 =A0 Ge= neral Discussion: paws@ietf.org=0A=A0 =A0 To Subscribe: https://www.ietf.or= g/mailman/listinfo/paws=0A=A0 =A0 Archive: http://www.ietf.org/mail-archive= /web/paws/=0A=0ADescription of Working Group:=0A=0ABackground=0A=0ARadio sp= ectrum is a limited resource.=A0 National and international=0Abodies assign= different frequencies for specific uses, and in=0Amost cases license the r= ights to use these frequencies.=A0 Locally=0Aunused spectrum is commonly ca= lled "white space" and may be made=0Aavailable to other services on a basis= of non-interference with=0Athe primary user of the frequencies concerned (= if any). This=0Atechnique can help "unlock" existing spectrum, for example = to=0Aenable the wireless communications industry to provide more=0Aservices= over frequencies associated with unused television=0Achannels.=A0 An obvio= us requirement is that white space uses must=0Anot interfere with the prima= ry use of the spectrum.=A0 This is=0Aachieved through spatial and/or tempor= al separation of the=0Aprimary user and whitespace user with due considerat= ion made to=0Athe radio characteristics of the two uses.=0A=0AProblem State= ment=0A=0AThe fundamental problem is enabling a radio device to determine, = in=0Aa specific location and at specific time, if any white space is=0Aavai= lable for secondary use.=A0 There are two parties to such an=0Ainteraction:= =0A=0A1. A database containing records about the protected contours (in=0As= pace and time) of primary spectrum users.=A0 Typically, such databases=0Awi= ll be populated and operated by the appropriate spectrum regulation=0Abodie= s in a given locale.=0A=0A2. A radio device that wishes to query such a dat= abase. Typically, the=0Athe nature of the query will depend on the needs of= the device.=0A=0AThe contents of white space databases, and the needs of r= adio devices,=0Aare being defined elsewhere.=A0 However, these parties need= a protocol=0Afor communication that will enable radio devices to find out = what white=0Aspace is available at a given time in a given location.=0A=0AI= t is expected that white space databases will be reachable via the=0AIntern= et, and that radio devices too will have some form of Internet=0Aconnectivi= ty, directly or indirectly.=A0 Therefore, it is appropriate=0Ato define an = Internet-based protocol for querying white space databases=0Aand receiving = responses from such databases.=0A=0AIn rough outline, such a protocol would= enable a radio device that=0Aknows its location to complete the following = tasks:=0A=0A1. Determine the relevant white space database to query.=0A=0A2= . Connect to the database using a well-defined access method.=0A=0A3. Provi= de its geolocation and perhaps other data to the database=0A=A0 using a wel= l-defined wire format for querying the database.=0A=0A4. Receive in return = a list of currently available white space=0A=A0 using a well-defined wire f= ormat for returning information.=0A=0AOnce the device learns of the availab= le white space (e.g., in a TV=0Awhite space implementation, the list of ava= ilable channels at that=0Alocation), it can then select one of the bands fr= om the list and=0Abegin to transmit and receive on the selected band.=A0 If= the device's=0Aparameters have changed (e.g., if some amount of time has p= assed or if=0Athe device has changed location beyond a specified threshold)= , it might=0Aneed to query the database again to determine what white space= is still=0Aavailable.=0A=0AObjectives=0A=0AThe overall goals of this worki= ng group are to:=0A=0A1. Standardize a mechanism for discovering a white sp= ace database.=0A=0A2. Standardize a method for accessing a white space data= base.=0A=0A3. Standardize wire formats to be carried over the database=0Aac= cess method (i.e., formats for queries and responses).=0A=0A4. Ensure that = the discovery mechanism, database access method,=0Aand wire formats have ap= propriate security levels in place.=0A=0ABy "standardize" is not meant that= the working group will necessarily=0Adevelop new technologies.=A0 In compl= eting its work, the group will:=0A=0A- Evaluate existing discovery mechanis= ms to determine if one of=0A=A0 them provides the necessary application fea= tures and security=0A=A0 properties (or can be extended to do so) for disco= vering a=0A=A0 white space database.=A0 Examples might include DNS.=0A=0A- = Evaluate existing application-layer transport protocols to=0A=A0 determine = if one of them provides the necessary application=0A=A0 features and securi= ty properties (or can be extended to do so)=0A=A0 for use as a building blo= ck for communication between location-=0A=A0 aware devices and white space = databases.=A0 If such a method=0A=A0 exists, the group will reuse it; if no= t, the group will develop=0A=A0 one.=A0 Examples might include HTTP.=0A=0A-= Develop a method for querying a white space database.=A0 Such=0A=A0 a meth= od will utilize, so far as possible, the features of=0A=A0 the application-= layer transport protocol and not re-implement=0A=A0 them in the new protoco= l. It will include mechanisms to verify=0A=A0 that the requests and respons= es come from authorized sources,=0A=A0 and that they have not been modified= in transit.=A0 Examples might=0A=A0 include LDAP.=0A=0A- Define extensible= wire formats for both location-specific queries=0A=A0 and location-specifi= c responses for interaction with radio white=0A=A0 space databases.=A0 The = group will consider whether existing data=0A=A0 formats can be reused.=0A= =0AThe protocol must protect both the channel enablement process and the=0A= privacy of users.=A0 Robust privacy and security mechanisms are needed=0Ato= prevent: device identity spoofing, modification of device requests,=0Amodi= fication of channel enablement information, impersonation of=0Aregistered d= atabase services, and unauthorized disclosure of a device's=0Alocation.=A0 = The group will consider whether existing privacy and=0Asecurity mechanisms = can be reused.=0A=0AThe task of defining the structure and contents of the = databases=0Athemselves is out of scope.=A0 The group will standardize wire = formats=0Afor communication between devices and databases, but not the info= rmation=0Amodels for the databases, since those models are likely to be=0Ac= ountry-specific or application-specific.=A0 In addition, the particular=0Ad= ata exchanged between a device and a database might depend on the=0Aranges = of radio spectrum that are to be used, the requirements of the=0Adatabase o= perators and their governing regulations, and other factors.=0ATherefore, t= he database access method and the query/response data=0Aformats that are ex= changed using that method need to be designed for=0Aextensibility rather th= an being tied to any specific spectrum, country,=0Aor phy/mac/air interface= .=A0 For example, the working group should define=0Aextension points for th= e database access method and the wire formats=0Athat are used to query a da= tabase and respond to queries, so that use=0Acases other than those current= ly envisioned can be addressed in the=0Afuture if a community of interest w= ishes to do so.=A0 However, the=0Aaccess method and wire formats will incor= porate relevant aspects of=0Athe parameters needed for the currently envisi= oned use cases to ensure=0Aproper operation.=0A=0AIn accordance with existi= ng IETF processes, the group will communicate=0Aand invite participation wi= th other relevant standards bodies and=0Agroups, and if necessary reuse exi= sting liaison relationships or=0Arequest the establishment of new liaison r= elationships, including but=0Anot limited to IEEE 802.11af and IEEE 802.22.= =A0 In order to ensure that=0Ait takes into account a broad range of possib= le use cases and=0Arequirements, the group should also reach out to other p= otential=0A"customers" for a white space database access method and conside= r input=0Afrom regulatory entities that are involved in the specification o= f the=0Arules for secondary use of spectrum in specific radio bands.=0A=0AD= eliverables=0A=0A1. A description of the relevant use cases and requirement= s.=A0 This=0Adocument shall be Informational.=A0 Subject to working group c= onsensus,=0Adraft-probasco-paws-overview-usecases and draft-patil-paws-prob= lem-stmt=0Amight be used as a starting point.=0A=0A2. A specification of th= e mechanism for discovering a white space=0Adatabase, the method for access= ing a white space database, and the=0Awire format for querying and receivin= g responses from a white space=0Adatabase.=A0 This document shall be Standa= rds Track.=0A=0AMilestones=0A=0AOct 2011 Submit 'Use Cases and Requirements= for Accessing a Radio White=0ASpace Database' to the IESG for publication = as Informational=0A=0AApr 2012 Submit 'Accessing a Radio White Space Databa= se' to the IESG=0Afor publication as Proposed Standard=0A=0A###=0A=0A=0A=0A= =0A_______________________________________________=0Apaws mailing list=0Apa= ws@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/paws=0A=0A=0A__________= _____________________________________=0Apaws mailing list=0Apaws@ietf.org= =0Ahttps://www.ietf.org/mailman/listinfo/paws --0-1662526456-1307464453=:99516 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks Scott.

I understand it does not directly relate to the charter, but r= eading on, got few technical questions and sharing those.

"When channel is no= t available radio must not transmit"

As white space offers very limited channel space, will the radio dev= ice get into no transmission mode very often? When radio changes loca= tion during transmission, and no channel available then the data transmissi= on is interrupted&n= bsp;or broken. Or should whitespace radio also do GSM like channel allocati= on, locking, etc.to ensure uninterrupted transmission? <= /div>

Also does t= hese spec anyways relate or scope RDS transmission present in FM Radios?

Sajeev Manikko= th
Email: mksaji@ieee.org
http://www.linkedin.com/in/mksajeev

=
From: "scott.prob= asco@nokia.com" <scott.probasco@nokia.com>
To: mksaji@yahoo.com; stpeter@stpeter.im; paws@ie= tf.org
Sent: Monday, 6 = June 2011, 15:01
Subject: Re: [paws] updated charter

=0A=0A= =0A =0A=0A=0A =0A
=0A
Hi Sajeev,
=0A

=0A
= If the database replies with an empty channel list (no channels available) = then the white space radio must not transmit.
=0A
&n= bsp;
=0A
Once a channel list is received with at leas= t one available channel, the white space radio may transmit on one of the a= vailable channels. Typically, the white=0A space radio must contact the dat= abase regularly to ensure channel availability. If the white space radio is= not able to contact the database, then the radio must cease transmission i= n white space within some period of time. The specific details are specifie= d=0A by the local regulator (e.g. FCC in the US, Ofcom in the UK, etc).
=0A

=0A
The white space c= ommunication will ultimately be broken if contact with the database is lost= . Your question about using white space as a secondary means of=0A communic= ation is a reasonable question, but beyond the scope of the database interf= ace. For example, a device may use cellular radio, WiFi and white space rad= ios, switching radios based on some arbitrary decisions (such as power cons= umption, QoS, subscription=0A rate, etc). However this type of switching sc= enario is beyond the scope of the database interface and therefore PAWS.
=0A

=0A
IMHO, these are g= ood questions about typical system operation, but have no impact to the cha= rter text.
=0A

=0A
Rega= rds,
=0A
Scott
=0A

=0A
=0A
=0A
From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org]=0AOn Behalf= Of ext M.K.Sajeev sajeev
=0ASent: Saturday, June 04, 2011 5:= 27 AM
=0ATo: Peter Saint-Andre; paws@ietf.org
=0ASubject: Re: [paws] updated charter
=0A
=0A
=0A

=0A
=0A
=0A
Hi,
=0A
=0A
=0A
<= /div> =0A
=0A
=0A
This is Sajeev, interested in = whitespace protocols, and an observer of this group. Reading through the ch= arter I would like to clarify the following.
=0A
=0A
= =0A
In the below paragraph radio device discovers whitesp= ace channel availability time to time. What happens when the radio device d= oes not find any channels available to initiate transmission,=0A or if it h= appen during a session? Will the communication be broken, or the radio devi= ces use this as a secondary means of communication? Would like to get some = clarity..
=0A
=0A
=0A

=0A
=0A
=0A
Once the device learns of the available= white space (e.g., in a TV
=0Awhite spac= e implementation, the list of available channels at that
=0Alocation), it can then select one o= f the bands from the list and
=0Abegin to transmit and receive on the selected band. If t= he device's
=0Aparam= eters have changed (e.g., if some amount of time has passed or if=0Athe device has changed loc= ation beyond a specified threshold), it might
=0Aneed to query the database again to determine = what white space is still
=0Aavailable.
= =0A
=0A
=0A

=0A
=0A=0A
Sajeev Manikkoth
=0AMobile: +919663311378=
=0A
=0A
=0A
Email:= =0Amksaji@ieee.org
=0Ahttp://w= ww.linkedin.com/in/mksajeev
=0A
=0A
=0A
=0A=0A=0A=
=0A
=0A
From: Peter Saint-Andre=0A <stpeter@stp= eter.im>
=0ATo: "paws@ietf.org" <paws@ietf.org>
=0ASent: Friday, 3 June 2011, 7:56
=0ASubject: [paws] updated c= harter
=0A
=0AHere is the charter= the emerged from discussions among IESG members and
=0Awith the BoF cha= irs.
=0A
=0A###
=0A
=0AProtocol to Access White Space database = (paws)
=0A------------------------------------------------
=0ACurrent= Status: Proposed Working Group
=0ALast updated: 2011-06-02
=0A
= =0AChairs:
=0ATBD
=0A
=0AApplications Area Directors:
=0A = Pete Resnick <presnick= @qualcomm.com>
=0A Peter Saint-Andre <stpeter@stpeter.im>
=0A
=0AApplicatio= ns Area Advisor:
=0A Peter Saint-Andre <stpeter@stpeter.im>
=0A
=0AMailing lists:<= br>=0A General Discussion: paws@ietf= .org
=0A To Subscribe: =0Ahttps://www.ie= tf.org/mailman/listinfo/paws
=0A Archive: =0Ahttp://www.ietf.org/mail-archive/web/paws/
=0A
=0ADescriptio= n of Working Group:
=0A
=0ABackground
=0A
=0ARadio spectrum is = a limited resource. National and international
=0Abodies assign di= fferent frequencies for specific uses, and in
=0Amost cases license the = rights to use these frequencies. Locally
=0Aunused spectrum is com= monly called "white space" and may be made
=0Aavailable to other service= s on a basis of non-interference with
=0Athe primary user of the frequen= cies concerned (if any). This
=0Atechnique can help "unlock" existing sp= ectrum, for example to
=0Aenable the wireless communications industry to= provide more
=0Aservices over frequencies associated with unused televi= sion
=0Achannels. An obvious requirement is that white space uses = must
=0Anot interfere with the primary use of the spectrum. This i= s
=0Aachieved through spatial and/or temporal separation of the
=0Apr= imary user and whitespace user with due consideration made to
=0Athe rad= io characteristics of the two uses.
=0A
=0AProblem Statement
=0A=0AThe fundamental problem is enabling a radio device to determine, in=0Aa specific location and at specific time, if any white space is
=0Aa= vailable for secondary use. There are two parties to such an
=0Ain= teraction:
=0A
=0A1. A database containing records about the protecte= d contours (in
=0Aspace and time) of primary spectrum users. Typic= ally, such databases
=0Awill be populated and operated by the appropriat= e spectrum regulation
=0Abodies in a given locale.
=0A
=0A2. A rad= io device that wishes to query such a database. Typically, the
=0Athe na= ture of the query will depend on the needs of the device.
=0A
=0AThe = contents of white space databases, and the needs of radio devices,
=0Aar= e being defined elsewhere. However, these parties need a protocol
= =0Afor communication that will enable radio devices to find out what white<= br>=0Aspace is available at a given time in a given location.
=0A
=0A= It is expected that white space databases will be reachable via the
=0AI= nternet, and that radio devices too will have some form of Internet
=0Ac= onnectivity, directly or indirectly. Therefore, it is appropriate
= =0Ato define an Internet-based protocol for querying white space databases<= br>=0Aand receiving responses from such databases.
=0A
=0AIn rough ou= tline, such a protocol would enable a radio device that
=0Aknows its loc= ation to complete the following tasks:
=0A
=0A1. Determine the releva= nt white space database to query.
=0A
=0A2. Connect to the database u= sing a well-defined access method.
=0A
=0A3. Provide its geolocation = and perhaps other data to the database
=0A using a well-defined wi= re format for querying the database.
=0A
=0A4. Receive in return a li= st of currently available white space
=0A using a well-defined wir= e format for returning information.
=0A
=0AOnce the device learns of = the available white space (e.g., in a TV
=0Awhite space implementation, = the list of available channels at that
=0Alocation), it can then select = one of the bands from the list and
=0Abegin to transmit and receive on t= he selected band. If the device's
=0Aparameters have changed (e.g.= , if some amount of time has passed or if
=0Athe device has changed loca= tion beyond a specified threshold), it might
=0Aneed to query the databa= se again to determine what white space is still
=0Aavailable.
=0A
= =0AObjectives
=0A
=0AThe overall goals of this working group are to:<= br>=0A
=0A1. Standardize a mechanism for discovering a white space datab= ase.
=0A
=0A2. Standardize a method for accessing a white space datab= ase.
=0A
=0A3. Standardize wire formats to be carried over the databa= se
=0Aaccess method (i.e., formats for queries and responses).
=0A=0A4. Ensure that the discovery mechanism, database access method,
=0Aa= nd wire formats have appropriate security levels in place.
=0A
=0ABy = "standardize" is not meant that the working group will necessarily
=0Ade= velop new technologies. In completing its work, the group will:
= =0A
=0A- Evaluate existing discovery mechanisms to determine if one of=0A them provides the necessary application features and security=0A properties (or can be extended to do so) for discovering a
= =0A white space database. Examples might include DNS.
=0A=0A- Evaluate existing application-layer transport protocols to
=0A&nbs= p; determine if one of them provides the necessary application
=0A = features and security properties (or can be extended to do so)
=0A = ; for use as a building block for communication between location-
=0A&nb= sp; aware devices and white space databases. If such a method
=0A&= nbsp; exists, the group will reuse it; if not, the group will develop
= =0A one. Examples might include HTTP.
=0A
=0A- Develop a = method for querying a white space database. Such
=0A a metho= d will utilize, so far as possible, the features of
=0A the applic= ation-layer transport protocol and not re-implement
=0A them in th= e new protocol. It will include mechanisms to verify
=0A that the = requests and responses come from authorized sources,
=0A and that = they have not been modified in transit. Examples might
=0A i= nclude LDAP.
=0A
=0A- Define extensible wire formats for both locatio= n-specific queries
=0A and location-specific responses for interac= tion with radio white
=0A space databases. The group will co= nsider whether existing data
=0A formats can be reused.
=0A
= =0AThe protocol must protect both the channel enablement process and the=0Aprivacy of users. Robust privacy and security mechanisms are need= ed
=0Ato prevent: device identity spoofing, modification of device reque= sts,
=0Amodification of channel enablement information, impersonation of=
=0Aregistered database services, and unauthorized disclosure of a devic= e's
=0Alocation. The group will consider whether existing privacy = and
=0Asecurity mechanisms can be reused.
=0A
=0AThe task of defin= ing the structure and contents of the databases
=0Athemselves is out of = scope. The group will standardize wire formats
=0Afor communicatio= n between devices and databases, but not the information
=0Amodels for t= he databases, since those models are likely to be
=0Acountry-specific or= application-specific. In addition, the particular
=0Adata exchang= ed between a device and a database might depend on the
=0Aranges of radi= o spectrum that are to be used, the requirements of the
=0Adatabase oper= ators and their governing regulations, and other factors.
=0ATherefore, = the database access method and the query/response data
=0Aformats that a= re exchanged using that method need to be designed for
=0Aextensibility = rather than being tied to any specific spectrum, country,
=0Aor phy/mac/= air interface. For example, the working group should define
=0Aext= ension points for the database access method and the wire formats
=0Atha= t are used to query a database and respond to queries, so that use
=0Aca= ses other than those currently envisioned can be addressed in the
=0Afut= ure if a community of interest wishes to do so. However, the
=0Aac= cess method and wire formats will incorporate relevant aspects of
=0Athe= parameters needed for the currently envisioned use cases to ensure
=0Ap= roper operation.
=0A
=0AIn accordance with existing IETF processes, t= he group will communicate
=0Aand invite participation with other relevan= t standards bodies and
=0Agroups, and if necessary reuse existing liaiso= n relationships or
=0Arequest the establishment of new liaison relations= hips, including but
=0Anot limited to IEEE 802.11af and IEEE 802.22.&nbs= p; In order to ensure that
=0Ait takes into account a broad range of pos= sible use cases and
=0Arequirements, the group should also reach out to = other potential
=0A"customers" for a white space database access method = and consider input
=0Afrom regulatory entities that are involved in the = specification of the
=0Arules for secondary use of spectrum in specific = radio bands.
=0A
=0ADeliverables
=0A
=0A1. A description of the= relevant use cases and requirements. This
=0Adocument shall be In= formational. Subject to working group consensus,
=0Adraft-probasco= -paws-overview-usecases and draft-patil-paws-problem-stmt
=0Amight be us= ed as a starting point.
=0A
=0A2. A specification of the mechanism fo= r discovering a white space
=0Adatabase, the method for accessing a whit= e space database, and the
=0Awire format for querying and receiving resp= onses from a white space
=0Adatabase. This document shall be Stand= ards Track.
=0A
=0AMilestones
=0A
=0AOct 2011 Submit 'Use Cases= and Requirements for Accessing a Radio White
=0ASpace Database' to the = IESG for publication as Informational
=0A
=0AApr 2012 Submit 'Accessi= ng a Radio White Space Database' to the IESG
=0Afor publication as Propo= sed Standard
=0A
=0A###
=0A
=0A
=0A
=0A
=0A___________= ____________________________________
=0Apaws mailing list
=0Apaws@ietf.org
=0Ahttps://www.ietf= .org/mailman/listinfo/paws
=0A
=0A
=0A
=0A=0A
=0A
=0A =0A=0A

____________________________________= ___________
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/= listinfo/paws

--0-1662526456-1307464453=:99516-- From scott.probasco@nokia.com Tue Jun 7 15:55:33 2011 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F69D11E80CF for ; Tue, 7 Jun 2011 15:55:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id In3EARiXI5J2 for ; Tue, 7 Jun 2011 15:55:25 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id E2BA511E81B2 for ; Tue, 7 Jun 2011 15:55:24 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p57MtHr8007494; Wed, 8 Jun 2011 01:55:23 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 8 Jun 2011 01:55:16 +0300 Received: from 008-AM1MMR1-004.mgdnok.nokia.com (65.54.30.59) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 8 Jun 2011 00:55:16 +0200 Received: from 008-AM1MPN1-021.mgdnok.nokia.com ([169.254.1.188]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.01.0289.008; Wed, 8 Jun 2011 00:55:16 +0200 From: To: , , Thread-Topic: [paws] updated charter Thread-Index: AQHMIZW5XxXLw3+lW0G8ZPdPMB68Z5Ss3z+AgAMysuCAAerUgIAAhEZg Date: Tue, 7 Jun 2011 22:55:15 +0000 Message-ID: <88BE24FD9280884487DEAE0CE1FD3A5B0319BD2C@008-AM1MPN1-021.mgdnok.nokia.com> References: <4DE8466C.9010201@stpeter.im> <205283.1524.qm@web34508.mail.mud.yahoo.com> <88BE24FD9280884487DEAE0CE1FD3A5B0319B242@008-AM1MPN1-021.mgdnok.nokia.com> <890030.99516.qm@web34502.mail.mud.yahoo.com> In-Reply-To: <890030.99516.qm@web34502.mail.mud.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-version: 3.3.8.1 x-tituslabs-classifications-30: TLPropertyRoot=Trial License;Classification=Personal; x-putclassificationandsendinfointox-header: Classification: Personal Project: Subject: RE: [paws] updated charter Sender Name: Probasco Scott (Nokia-CIC/Dallas) Sender Email: scott.probasco@nokia.com Send Date: Tuesday, June 07, 2011 Send Time: 5:55:14 PM x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7Impg+JeSc+lISYAkH6dnOLqzr7Rmj/XdR2/ORg+Pl4AmrIIrkvyWZ/i2LOcua/KZladIRCLtTkU1f3y2167jm+G+gVnxYYYqf1Tx7jK3LYYi6S9OajKDKj72fyCovA+NYepfs9C7NldiMj2tCSo4UMPpWc1K8F08En/nk9a7+T4ciKNXoAmt5stP1f7p8LXqaw== x-originating-ip: [79.134.117.202] Content-Type: multipart/alternative; boundary="_000_88BE24FD9280884487DEAE0CE1FD3A5B0319BD2C008AM1MPN1021mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 07 Jun 2011 22:55:17.0020 (UTC) FILETIME=[F80985C0:01CC2565] X-Nokia-AV: Clean Subject: Re: [paws] updated charter X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database $PAWS$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 22:55:33 -0000 --_000_88BE24FD9280884487DEAE0CE1FD3A5B0319BD2C008AM1MPN1021mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sajeev, > will the radio device get into no transmission mode very often? This depends very much on the specific device, its specific location and th= e specific time of attempted operation. Variables include local regulations= (the rules established by the local regulator), the white space device (ou= tput power, antenna height, etc), spectrum occupancy by primary users at th= e given time & location, etc. Shortly, we cannot know this in advance. >When radio changes location during transmission, and no channel >available then the data transmission is interrupted or broken. Or should >whitespace radio also do GSM like channel allocation, locking, etc.to >ensure uninterrupted transmission? The white space model is that secondary or unlicensed users cannot cause in= terference, and cannot expect any protection from interference. Recognizing= this, I don't know how a white space radio itself will be able to ensure u= ninterrupted transmission. The scenario you describe is an interesting use = case which I hope is discussed by the WG. One possible solution would be so= me 'offloading' algorithm in which a device switches transmission to a diff= erent radio (e.g. cellular, WiFi, etc) in case the white space radio does n= ot have a channel for transmission. IMHO, it is TBD if such a use case fall= s within the scope of the WG charter. > Also does these spec anyways relate or scope RDS transmission present in = FM Radios? I am not aware of any link between white space and FM RDS transmission. Regards, Scott From: ext M.K.Sajeev sajeev [mailto:mksaji@yahoo.com] Sent: Tuesday, June 07, 2011 11:34 AM To: Probasco Scott (Nokia-CIC/Dallas); stpeter@stpeter.im; paws@ietf.org Subject: Re: [paws] updated charter Thanks Scott. I understand it does not directly relate to the charter, but reading on, go= t few technical questions and sharing those. "When channel is not available radio must not transmit" As white space offers very limited channel space, will the radio device ge= t into no transmission mode very often? When radio changes location during = transmission, and no channel available then the data transmission is interr= upted or broken. Or should whitespace radio also do GSM like channel alloca= tion, locking, etc.to ensure uninterrupted transmission? Also does these spec anyways relate or scope RDS transmission present in FM= Radios? Sajeev Manikkoth Email: mksaji@ieee.org http://www.linkedin.com/in/mksajeev _____ From: "scott.probasco@nokia.com" To: mksaji@yahoo.com; stpeter@stpeter.im; paws@ietf.org Sent: Monday, 6 June 2011, 15:01 Subject: Re: [paws] updated charter Hi Sajeev, If the database replies with an empty channel list (no channels available) = then the white space radio must not transmit. Once a channel list is received with at least one available channel, the wh= ite space radio may transmit on one of the available channels. Typically, t= he white space radio must contact the database regularly to ensure channel = availability. If the white space radio is not able to contact the database,= then the radio must cease transmission in white space within some period o= f time. The specific details are specified by the local regulator (e.g. FCC= in the US, Ofcom in the UK, etc). The white space communication will ultimately be broken if contact with the= database is lost. Your question about using white space as a secondary mea= ns of communication is a reasonable question, but beyond the scope of the d= atabase interface. For example, a device may use cellular radio, WiFi and w= hite space radios, switching radios based on some arbitrary decisions (such= as power consumption, QoS, subscription rate, etc). However this type of s= witching scenario is beyond the scope of the database interface and therefo= re PAWS. IMHO, these are good questions about typical system operation, but have no = impact to the charter text. Regards, Scott From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext= M.K.Sajeev sajeev Sent: Saturday, June 04, 2011 5:27 AM To: Peter Saint-Andre; paws@ietf.org Subject: Re: [paws] updated charter Hi, This is Sajeev, interested in whitespace protocols, and an observer of this= group. Reading through the charter I would like to clarify the following. In the below paragraph radio device discovers whitespace channel availabili= ty time to time. What happens when the radio device does not find any chann= els available to initiate transmission, or if it happen during a session? W= ill the communication be broken, or the radio devices use this as a seconda= ry means of communication? Would like to get some clarity.. Once the device learns of the available white space (e.g., in a TV white space implementation, the list of available channels at that location), it can then select one of the bands from the list and begin to transmit and receive on the selected band. If the device's parameters have changed (e.g., if some amount of time has passed or if the device has changed location beyond a specified threshold), it might need to query the database again to determine what white space is still available. Sajeev Manikkoth Mobile: +919663311378 Email: mksaji@ieee.org http://www.linkedin.com/in/mksajeev _____ From: Peter Saint-Andre To: "paws@ietf.org" Sent: Friday, 3 June 2011, 7:56 Subject: [paws] updated charter Here is the charter the emerged from discussions among IESG members and with the BoF chairs. ### Protocol to Access White Space database (paws) ------------------------------------------------ Current Status: Proposed Working Group Last updated: 2011-06-02 Chairs: TBD Applications Area Directors: Pete Resnick > Peter Saint-Andre > Applications Area Advisor: Peter Saint-Andre > Mailing lists: General Discussion: 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: Background Radio spectrum is a limited resource. National and international bodies assign different frequencies for specific uses, and in most cases license the rights to use these frequencies. Locally unused spectrum is commonly called "white space" and may be made available to other services on a basis of non-interference with the primary user of the frequencies concerned (if any). This technique can help "unlock" existing spectrum, for example to enable the wireless communications industry to provide more services over frequencies associated with unused television channels. An obvious requirement is that white space uses must not interfere with the primary use of the spectrum. This is achieved through spatial and/or temporal separation of the primary user and whitespace user with due consideration made to the radio characteristics of the two uses. Problem Statement The fundamental problem is enabling a radio device to determine, in a specific location and at specific time, if any white space is available for secondary use. There are two parties to such an interaction: 1. A database containing records about the protected contours (in space and time) of primary spectrum users. Typically, such databases will be populated and operated by the appropriate spectrum regulation bodies in a given locale. 2. A radio device that wishes to query such a database. Typically, the the nature of the query will depend on the needs of the device. The contents of white space databases, and the needs of radio devices, are being defined elsewhere. However, these parties need a protocol for communication that will enable radio devices to find out what white space is available at a given time in a given location. It is expected that white space databases will be reachable via the Internet, and that radio devices too will have some form of Internet connectivity, directly or indirectly. Therefore, it is appropriate to define an Internet-based protocol for querying white space databases and receiving responses from such databases. In rough outline, such a protocol would enable a radio device that knows its location to complete the following tasks: 1. Determine the relevant white space database to query. 2. Connect to the database using a well-defined access method. 3. Provide its geolocation and perhaps other data to the database using a well-defined wire format for querying the database. 4. Receive in return a list of currently available white space using a well-defined wire format for returning information. Once the device learns of the available white space (e.g., in a TV white space implementation, the list of available channels at that location), it can then select one of the bands from the list and begin to transmit and receive on the selected band. If the device's parameters have changed (e.g., if some amount of time has passed or if the device has changed location beyond a specified threshold), it might need to query the database again to determine what white space is still available. Objectives The overall goals of this working group are to: 1. Standardize a mechanism for discovering a white space database. 2. Standardize a method for accessing a white space database. 3. Standardize wire formats to be carried over the database access method (i.e., formats for queries and responses). 4. Ensure that the discovery mechanism, database access method, and wire formats have appropriate security levels in place. By "standardize" is not meant that the working group will necessarily develop new technologies. In completing its work, the group will: - Evaluate existing discovery mechanisms to determine if one of them provides the necessary application features and security properties (or can be extended to do so) for discovering a white space database. Examples might include DNS. - Evaluate existing application-layer transport protocols to determine if one of them provides the necessary application features and security properties (or can be extended to do so) for use as a building block for communication between location- aware devices and white space databases. If such a method exists, the group will reuse it; if not, the group will develop one. Examples might include HTTP. - Develop a method for querying a white space database. Such a method will utilize, so far as possible, the features of the application-layer transport protocol and not re-implement them in the new protocol. It will include mechanisms to verify that the requests and responses come from authorized sources, and that they have not been modified in transit. Examples might include LDAP. - Define extensible wire formats for both location-specific queries and location-specific responses for interaction with radio white space databases. The group will consider whether existing data formats can be reused. The protocol must protect both the channel enablement process and the privacy of users. Robust privacy and security mechanisms are needed to prevent: device identity spoofing, modification of device requests, modification of channel enablement information, impersonation of registered database services, and unauthorized disclosure of a device's location. The group will consider whether existing privacy and security mechanisms can be reused. The task of defining the structure and contents of the databases themselves is out of scope. The group will standardize wire formats for communication between devices and databases, but not the information models for the databases, since those models are likely to be country-specific or application-specific. In addition, the particular data exchanged between a device and a database might depend on the ranges of radio spectrum that are to be used, the requirements of the database operators and their governing regulations, and other factors. Therefore, the database access method and the query/response data formats that are exchanged using that method need to be designed for extensibility rather than being tied to any specific spectrum, country, or phy/mac/air interface. For example, the working group should define extension points for the database access method and the wire formats that are used to query a database and respond to queries, so that use cases other than those currently envisioned can be addressed in the future if a community of interest wishes to do so. However, the access method and wire formats will incorporate relevant aspects of the parameters needed for the currently envisioned use cases to ensure proper operation. In accordance with existing IETF processes, the group will communicate and invite participation with other relevant standards bodies and groups, and if necessary reuse existing liaison relationships or request the establishment of new liaison relationships, including but not limited to IEEE 802.11af and IEEE 802.22. In order to ensure that it takes into account a broad range of possible use cases and requirements, the group should also reach out to other potential "customers" for a white space database access method and consider input from regulatory entities that are involved in the specification of the rules for secondary use of spectrum in specific radio bands. Deliverables 1. A description of the relevant use cases and requirements. This document shall be Informational. Subject to working group consensus, draft-probasco-paws-overview-usecases and draft-patil-paws-problem-stmt might be used as a starting point. 2. A specification of the mechanism for discovering a white space database, the method for accessing a white space database, and the wire format for querying and receiving responses from a white space database. This document shall be Standards Track. Milestones Oct 2011 Submit 'Use Cases and Requirements for Accessing a Radio White Space Database' to the IESG for publication as Informational Apr 2012 Submit 'Accessing a Radio White Space Database' to the IESG for publication as Proposed Standard ### _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws --_000_88BE24FD9280884487DEAE0CE1FD3A5B0319BD2C008AM1MPN1021mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Sajeev,

<= /p>
> will the radio device get into no transmission mode very oft= en?

This depends very much on= the specific device, its specific location and the specific time of attemp= ted operation. Variables include local regulations (the rules established by the local regulator), the white space device (output = power, antenna height, etc), spectrum occupancy by primary users at the giv= en time & location, etc. Shortly, we cannot know this in advance.<= /o:p>

<= /p>
>When radio changes location during transmission, and no chann= el

>available then the d= ata transmission is interrupted or broken. Or should

>whitespace radio als= o do GSM like channel allocation, locking, etc.to

>ensure uninterrupted= transmission?

The white space model is = that secondary or unlicensed users cannot cause interference, and cannot ex= pect any protection from interference. Recognizing this, I don’t know how a white space radio itself will be able to ensure u= ninterrupted transmission. The scenario you describe is an interesting use = case which I hope is discussed by the WG. One possible solution would be so= me ‘offloading’ algorithm in which a device switches transmission to a different radio (e.g. cellular, WiFi, etc) in c= ase the white space radio does not have a channel for transmission. IMHO, i= t is TBD if such a use case falls within the scope of the WG charter.<= /o:p>

<= /p>
Also does these spec anyways rela= te or scope RDS transmission present in FM Radios?

I am not aware of any lin= k between white space and FM RDS transmission.

<= /p>
Regards,

Scott
<= /p>
<= /p>

From: ext M.K.= Sajeev sajeev [mailto:mksaji@yahoo.com]
Sent: Tuesday, June 07, 2011 11:34 AM
To: Probasco Scott (Nokia-CIC/Dallas); stpeter@stpeter.im; paws@ietf= .org
Subject: Re: [paws] updated charter

Thanks Scott.

I understand it does not directly relate to the charter, but reading on,= got few technical questions and sharing those.

"When channel is not available radio must not transmit"=

As white space offers very limited channel space, will the radio device = get into no transmission mode very often? When radio changes location= during transmission, and no channel available then the data transmission is interrupted or broken. Or should w= hitespace radio also do GSM like channel allocation, locking, etc.to ensure= uninterrupted transmission?

Also does these spec anyways relate or scope RDS transmission present in= FM Radios?

Sajeev Manikkoth
Email: mksaji@ieee.org
http://ww= w.linkedin.com/in/mksajeev

<= span style=3D"font-size:10.0pt;font-family:"Arial","sans-ser= if";color:black">From: "scott.p= robasco@nokia.com" <scott.probasco@nokia.com>
To: mksaji@yahoo.com; stpeter@stpeter.im; paws@ietf.org
Sent: Monday, 6 June 2011, 15:01
Subject: Re: [paws] updated charter

Hi Sajeev,

<= /span>

If the database replies with an empty channel list (n= o channels available) then the white space radio must not transmit.<= span style=3D"color:black">

<= /span>

Once a channel list is received with at least one ava= ilable channel, the white space radio may transmit on one of the available = channels. Typically, the white space radio must contact the database regularly to ensure channel availability. If the= white space radio is not able to contact the database, then the radio must= cease transmission in white space within some period of time. The specific= details are specified by the local regulator (e.g. FCC in the US, Ofcom in the UK, etc).

<= /span>

The white space communication will ultimately be brok= en if contact with the database is lost. Your question about using white sp= ace as a secondary means of communication is a reasonable question, but beyond the scope of the database interface. = For example, a device may use cellular radio, WiFi and white space radios, = switching radios based on some arbitrary decisions (such as power consumpti= on, QoS, subscription rate, etc). However this type of switching scenario is beyond the scope of the databas= e interface and therefore PAWS.

<= /span>

IMHO, these are good questions about typical system o= peration, but have no impact to the charter text.

<= /span>

Regards,

Scott

<= /span>

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext M.K.Sajeev sajeev
Sent: Saturday, June 04, 2011 5:27 AM
To: Peter Saint-Andre; paws@ietf.org
Subject: Re: [paws] updated charter

Hi,

This is Sajeev, interested in whitespace protocols, and an observer of t= his group. Reading through the charter I would like to clarify the followin= g.

In the below paragraph radio device discovers whitespace channel availab= ility time to time. What happens when the radio device does not find any ch= annels available to initiate transmission, or if it happen during a session? Will the communication be broken, or the= radio devices use this as a secondary means of communication? Would like t= o get some clarity..

Once the = device learns of the available white space (e.g., in a TV
white space implementation, th= e list of available channels at that
location), it can then select = one of the bands from the list and
begin to transmit and receive = on the selected band. If the device's
parameters have changed (e.g.,= if some amount of time has passed or if
the device has changed locatio= n beyond a specified threshold), it might
need to query the database aga= in to determine what white space is still
available.

Sajeev Manikkoth
Mobile: +919663311378

Email: mksaji@ieee.org
http://ww= w.linkedin.com/in/mksajeev

<= span style=3D"font-size:10.0pt;color:black">From: Peter Saint-Andre <stpeter@stpeter.im>=
To: "paws@ietf.org" <paws@ietf.org>
Sent: Friday, 3 June 2011, 7:56
Subject: [paws] updated charter

Here is the charter the emerged from discussions among IESG members and
with the BoF chairs.

###

Protocol to Access White Space database (paws)
------------------------------------------------
Current Status: Proposed Working Group
Last updated: 2011-06-02

Chairs:
TBD

Applications Area Directors:
Pete Resnick <presnick@qualcomm.com>
Peter Saint-Andre <stpeter@stpeter.im>

Applications Area Advisor:
Peter Saint-Andre <stpeter@stpeter.im>

Mailing lists:
General Discussion: 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:

Background

Radio spectrum is a limited resource. National and international
bodies assign different frequencies for specific uses, and in
most cases license the rights to use these frequencies. Locally
unused spectrum is commonly called "white space" and may be made<= br> available to other services on a basis of non-interference with
the primary user of the frequencies concerned (if any). This
technique can help "unlock" existing spectrum, for example to
enable the wireless communications industry to provide more
services over frequencies associated with unused television
channels. An obvious requirement is that white space uses must
not interfere with the primary use of the spectrum. This is
achieved through spatial and/or temporal separation of the
primary user and whitespace user with due consideration made to
the radio characteristics of the two uses.

Problem Statement

The fundamental problem is enabling a radio device to determine, in
a specific location and at specific time, if any white space is
available for secondary use. There are two parties to such an
interaction:

1. A database containing records about the protected contours (in
space and time) of primary spectrum users. Typically, such databases<= br> will be populated and operated by the appropriate spectrum regulation
bodies in a given locale.

2. A radio device that wishes to query such a database. Typically, the
the nature of the query will depend on the needs of the device.

The contents of white space databases, and the needs of radio devices,
are being defined elsewhere. However, these parties need a protocol for communication that will enable radio devices to find out what white
space is available at a given time in a given location.

It is expected that white space databases will be reachable via the
Internet, and that radio devices too will have some form of Internet
connectivity, directly or indirectly. Therefore, it is appropriate to define an Internet-based protocol for querying white space databases
and receiving responses from such databases.

In rough outline, such a protocol would enable a radio device that
knows its location to complete the following tasks:

1. Determine the relevant white space database to query.

2. Connect to the database using a well-defined access method.

3. Provide its geolocation and perhaps other data to the database
using a well-defined wire format for querying the database.

4. Receive in return a list of currently available white space
using a well-defined wire format for returning information.

Once the device learns of the available white space (e.g., in a TV
white space implementation, the list of available channels at that
location), it can then select one of the bands from the list and
begin to transmit and receive on the selected band. If the device's parameters have changed (e.g., if some amount of time has passed or if
the device has changed location beyond a specified threshold), it might
need to query the database again to determine what white space is still
available.

Objectives

The overall goals of this working group are to:

1. Standardize a mechanism for discovering a white space database.

2. Standardize a method for accessing a white space database.

3. Standardize wire formats to be carried over the database
access method (i.e., formats for queries and responses).

4. Ensure that the discovery mechanism, database access method,
and wire formats have appropriate security levels in place.

By "standardize" is not meant that the working group will necessa= rily
develop new technologies. In completing its work, the group will:

- Evaluate existing discovery mechanisms to determine if one of
them provides the necessary application features and security
properties (or can be extended to do so) for discovering a
white space database. Examples might include DNS.

- Evaluate existing application-layer transport protocols to
determine if one of them provides the necessary application
features and security properties (or can be extended to do so)
for use as a building block for communication between location-
aware devices and white space databases. If such a method
exists, the group will reuse it; if not, the group will develop
one. Examples might include HTTP.

- Develop a method for querying a white space database. Such
a method will utilize, so far as possible, the features of
the application-layer transport protocol and not re-implement
them in the new protocol. It will include mechanisms to verify
that the requests and responses come from authorized sources,
and that they have not been modified in transit. Examples migh= t
include LDAP.

- Define extensible wire formats for both location-specific queries
and location-specific responses for interaction with radio white
space databases. The group will consider whether existing data=
formats can be reused.

The protocol must protect both the channel enablement process and the
privacy of users. Robust privacy and security mechanisms are needed to prevent: device identity spoofing, modification of device requests,
modification of channel enablement information, impersonation of
registered database services, and unauthorized disclosure of a device's
location. The group will consider whether existing privacy and
security mechanisms can be reused.

The task of defining the structure and contents of the databases
themselves is out of scope. The group will standardize wire formats for communication between devices and databases, but not the information models for the databases, since those models are likely to be
country-specific or application-specific. In addition, the particular=
data exchanged between a device and a database might depend on the
ranges of radio spectrum that are to be used, the requirements of the
database operators and their governing regulations, and other factors.
Therefore, the database access method and the query/response data
formats that are exchanged using that method need to be designed for
extensibility rather than being tied to any specific spectrum, country,
or phy/mac/air interface. For example, the working group should defin= e
extension points for the database access method and the wire formats
that are used to query a database and respond to queries, so that use
cases other than those currently envisioned can be addressed in the
future if a community of interest wishes to do so. However, the
access method and wire formats will incorporate relevant aspects of
the parameters needed for the currently envisioned use cases to ensure
proper operation.

In accordance with existing IETF processes, the group will communicate
and invite participation with other relevant standards bodies and
groups, and if necessary reuse existing liaison relationships or
request the establishment of new liaison relationships, including but
not limited to IEEE 802.11af and IEEE 802.22. In order to ensure that=
it takes into account a broad range of possible use cases and
requirements, the group should also reach out to other potential
"customers" for a white space database access method and consider= input
from regulatory entities that are involved in the specification of the
rules for secondary use of spectrum in specific radio bands.

Deliverables

1. A description of the relevant use cases and requirements. This
document shall be Informational. Subject to working group consensus,<= br> draft-probasco-paws-overview-usecases and draft-patil-paws-problem-stmt
might be used as a starting point.

2. A specification of the mechanism for discovering a white space
database, the method for accessing a white space database, and the
wire format for querying and receiving responses from a white space
database. This document shall be Standards Track.

Milestones

Oct 2011 Submit 'Use Cases and Requirements for Accessing a Radio White
Space Database' to the IESG for publication as Informational

Apr 2012 Submit 'Accessing a Radio White Space Database' to the IESG
for publication as Proposed Standard

###

_______________________________________________
paws mailing list
paws@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/paws

_______________________________________________
paws mailing list
paws@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/paws

--_000_88BE24FD9280884487DEAE0CE1FD3A5B0319BD2C008AM1MPN1021mg_-- From stpeter@stpeter.im Thu Jun 9 08:12:03 2011 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F8A311E80BB for ; Thu, 9 Jun 2011 08:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aMIsu01GenF5 for ; Thu, 9 Jun 2011 08:11:50 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id C277D11E808B for ; Thu, 9 Jun 2011 08:11:50 -0700 (PDT) Received: from dhcp-64-101-72-179.cisco.com (dhcp-64-101-72-179.cisco.com [64.101.72.179]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 4300340066; Thu, 9 Jun 2011 09:11:56 -0600 (MDT) Message-ID: <4DF0E2B4.3060505@stpeter.im> Date: Thu, 09 Jun 2011 09:11:48 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Orit Levin References: <4DE8466C.9010201@stpeter.im> <4DE94191.4090707@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070403050606080804000401" Cc: "paws@ietf.org" Subject: Re: [paws] updated charter X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database $PAWS$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 15:12:03 -0000 This is a cryptographically signed message in MIME format. --------------ms070403050606080804000401 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 6/3/11 11:06 PM, Orit Levin wrote: > Thanks Peter! > Please, see inline, > Orit. >=20 >> -----Original Message----- >> From: Peter Saint-Andre [mailto:stpeter@stpeter.im] >> Sent: Friday, June 03, 2011 1:18 PM >> To: Orit Levin >> Cc: paws@ietf.org >> Subject: Re: [paws] updated charter >> >> On 6/3/11 2:12 PM, Orit Levin wrote: >>> A few more comments: >>> >>> 1. In all (nine) places where "wire format" is used, a more >>> appropriate "protocol format" should probably be used. In any case, >>> in reality many times it will happen over the air and not on the >>> wire. >> >> By "wire format" we don't mean literally sending things over a wire, i= n >> contrast to data that is send over a wireless transport. :) >> > Of course not! It is just hilarious to see this expression being used t= oday in the wireless context. Also, it may be confusing to those who are = not SW developers and have not spent past decades implementing network pr= otocols and/or APIs. Changed in my working copy to "query/response format". Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms070403050606080804000401 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDYw OTE1MTE0OFowIwYJKoZIhvcNAQkEMRYEFO56xSIRs+vACWCQaDaGLpU9juCwMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQCY+TduEG/AuMIC2n2wt7uLoqXgP4Zpz1aT6K7VFKab5c490TegYvslewfX GvLRpItAz7d5vut4TustWyTUHB9KgxeyDidzbt2/+3BERyDRPEP8PliLyT//WesnQi4CFyhe wjG5ktd5yaaDt32IkF4oxFxFU1ads9gC/h0ycS4cF+zH8FIcllnzeoGxy/tt6aoLhChnYAuX ZaM8IObvuhTo8GZMXm+dZpBzFDlM9mp1T/Z6nCwHnzuVrKHtilS+rXOj6ZbaHHfIhdfdH9AB iwFEPVOioogBIg2pURCSpdh8O4Wj2NjhAcfLSqrx0dBWZIxdGlgmusXPABA1PniFlZ50AAAA AAAA --------------ms070403050606080804000401-- From wwwrun@ietfa.amsl.com Tue Jun 14 09:40:51 2011 Return-Path: X-Original-To: paws@ietf.org Delivered-To: paws@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 30) id 2634311E807F; Tue, 14 Jun 2011 09:40:51 -0700 (PDT) From: IESG Secretary To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20110614164051.2634311E807F@ietfa.amsl.com> Date: Tue, 14 Jun 2011 09:40:51 -0700 (PDT) Cc: paws@ietf.org Subject: [paws] WG Action: Protocol to Access White Space Databases (paws) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database $PAWS$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 16:40:51 -0000 A new IETF working group has been formed in the Applications Area. For additional information, please contact the Area Directors or the WG Chairs. Protocol to Access White Space Databases (paws) ------------------------------------------------ Current Status: Active Working Group Chairs: Gabor Bajko Brian Rosen Applications Area Directors: Pete Resnick Peter Saint-Andre Applications Area Advisor: Peter Saint-Andre Mailing lists: General Discussion: 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: Background Radio spectrum is a limited resource. National and international bodies assign different frequencies for specific uses, and in most cases license the rights to use these frequencies. Locally unused spectrum is commonly called "white space" and may be made available to other services on a basis of non-interference with the primary user of the frequencies concerned (if any). This technique can help "unlock" existing spectrum, for example to enable the wireless communications industry to provide more services over frequencies associated with unused television channels. An obvious requirement is that white space uses must not interfere with the primary use of the spectrum. This is achieved through spatial and/or temporal separation of the primary user and whitespace user with due consideration made to the radio characteristics of the two uses. Problem Statement The fundamental problem is enabling a radio device to determine, in a specific location and at specific time, if any white space is available for secondary use. There are two parties to such an interaction: 1. A database containing records about the protected contours (in space and time) of primary spectrum users. Typically, such databases will be populated by information provided by the appropriate spectrum regulation bodies and by spectrum licensees. 2. A radio device that wishes to query such a database. Typically, the nature of the query will depend on the needs of the device. The contents of white space databases, and the needs of radio devices, are being defined elsewhere. However, these parties need a protocol for communication that will enable radio devices to find out what white space is available at a given time in a given location. It is expected that white space databases will be reachable via the Internet, and that radio devices too will have some form of Internet connectivity, directly or indirectly. Therefore, it is appropriate to define an Internet-based protocol for querying white space databases and receiving responses from such databases. In rough outline, such a protocol would enable a radio device that knows its location and the current time to complete the following tasks: 1. Determine the relevant white space database to query. 2. Connect to the database using a well-defined access method. 3. Provide its geolocation and perhaps other data to the database using a well-defined format for querying the database. 4. Receive in return a list of currently available white space using a well-defined format for returning information. Once the device learns of the available white space (e.g., in a TV white space implementation, the list of available channels at that location), it can then select one of the bands from the list and begin to transmit and receive on the selected band. If the device's parameters have changed (e.g., if some amount of time has passed or if the device has changed location beyond a specified threshold), it might need to query the database again to determine what white space is still available. Objectives The overall goals of this working group are to: 1. Standardize a mechanism for discovering a white space database. 2. Standardize a method for accessing a white space database. 3. Standardize query and response formats to be carried over the database access method. 4. Ensure that the discovery mechanism, database access method, and query/response formats have appropriate security levels in place. By "standardize" is not meant that the working group will necessarily develop new technologies. In completing its work, the group will: - Evaluate existing discovery mechanisms to determine if one of them provides the necessary application features and security properties (or can be extended to do so) for discovering a white space database. Examples might include DNS. - Evaluate existing application-layer transport protocols to determine if one of them provides the necessary application features and security properties (or can be extended to do so) for use as a building block for communication between location- aware devices and white space databases. If such a method exists, the group will reuse it; if not, the group will develop one. Examples might include HTTP. - Develop a method for querying a white space database. Such a method will utilize, so far as possible, the features of the application-layer transport protocol and not re-implement them in the new protocol. It will include mechanisms to verify that the requests and responses come from authorized sources, and that they have not been modified in transit. Examples might include LDAP. - Define extensible formats for both location-specific queries and location-specific responses for interaction with radio white space databases. The group will consider whether existing data formats can be reused. The protocol must protect both the channel enablement process and the privacy of users. Robust privacy and security mechanisms are needed to prevent: device identity spoofing, modification of device requests, modification of channel enablement information, impersonation of registered database services, and unauthorized disclosure of a device's location. The group will consider whether existing privacy and security mechanisms can be reused. The task of defining the structure and contents of the databases themselves is out of scope. The group will standardize formats for communication between devices and databases, but not the information models for the databases, since those models are likely to be country-specific or application-specific. In addition, the particular data exchanged between a device and a database might depend on the ranges of radio spectrum that are to be used, the requirements of the database operators and their governing regulations, and other factors. Therefore, the database access method and the query/response data formats that are exchanged using that method need to be designed for extensibility rather than being tied to any specific spectrum, country, or phy/mac/air interface. For example, the working group should define extension points for the database access method and the query/response formats, so that use cases other than those currently envisioned can be addressed in the future if a community of interest wishes to do so. However, the access method and query/response formats will incorporate relevant aspects of the parameters needed for the currently envisioned use cases to ensure proper operation. In accordance with existing IETF processes, the group will communicate and invite participation with other relevant standards bodies and groups, and if necessary reuse existing liaison relationships or request the establishment of new liaison relationships, including but not limited to IEEE 802.11af and IEEE 802.22. In order to ensure that it takes into account a broad range of possible use cases and requirements, the group should also reach out to other potential "customers" for a white space database access method and consider input from regulatory entities that are involved in the specification of the rules for secondary use of spectrum in specific radio bands. Deliverables 1. A description of the relevant use cases and requirements. This document shall be Informational. Subject to working group consensus, draft-probasco-paws-overview-usecases and draft-patil-paws-problem-stmt might be used as a starting point. 2. A specification of the mechanism for discovering a white space database, the method for accessing a white space database, and the query/response formats for interacting with a white space database. This document shall be Standards Track. Milestones Oct 2011 Submit 'Use Cases and Requirements for Accessing a Radio White Space Database' to the IESG for publication as Informational Apr 2012 Submit 'Accessing a Radio White Space Database' to the IESG for publication as Proposed Standard From Basavaraj.Patil@nokia.com Wed Jun 22 15:37:46 2011 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D9501F0C42 for ; Wed, 22 Jun 2011 15:37:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HVN6x7FBKS5f for ; Wed, 22 Jun 2011 15:37:45 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 72BCD1F0C41 for ; Wed, 22 Jun 2011 15:37:45 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-sa01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p5MMbc9M031994 for ; Thu, 23 Jun 2011 01:37:44 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 23 Jun 2011 01:37:34 +0300 Received: from 008-AM1MMR1-006.mgdnok.nokia.com (65.54.30.61) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 23 Jun 2011 00:37:33 +0200 Received: from 008-AM1MPN1-024.mgdnok.nokia.com ([169.254.4.125]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.01.0289.008; Thu, 23 Jun 2011 00:37:33 +0200 From: To: Thread-Topic: Updating I-D draft-patil-paws-problem-stmt-01 Thread-Index: AcwxFmLzoMdYagyhRBiHoyqjbh75UA== Date: Wed, 22 Jun 2011 22:37:32 +0000 Message-ID: <21E7D9BD69CC7241AAE00F4EA183B71905B997@008-AM1MPN1-024.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.74.219.186] Content-Type: multipart/alternative; boundary="_000_21E7D9BD69CC7241AAE00F4EA183B71905B997008AM1MPN1024mgdn_" MIME-Version: 1.0 X-OriginalArrivalTime: 22 Jun 2011 22:37:34.0381 (UTC) FILETIME=[FAD9EDD0:01CC312C] X-Nokia-AV: Clean Subject: [paws] Updating I-D draft-patil-paws-problem-stmt-01 X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database $PAWS$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 22:37:46 -0000 --_000_21E7D9BD69CC7241AAE00F4EA183B71905B997008AM1MPN1024mgdn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, Now that the WG has been approved, its time to actually do the work. We will be updating I-D draft-patil-paws-problem-stmt-01 to include use cas= es as well which are in the I-D: draft-probasco-paws-overview-usecases-00. The combined use-cases/requirements I-D will be submitted before the I-D su= bmission deadline. Your comments/feedback on the current set of use cases captured in I-D: dra= ft-probasco-paws-overview-usecases-00 as well any additional use cases that= we need to cover are welcome. -Raj --_000_21E7D9BD69CC7241AAE00F4EA183B71905B997008AM1MPN1024mgdn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

Now that the WG has been approved, its time to actua= lly do the work.

We will be updating I-D draft-patil-paws-problem-stm= t-01 to include use cases as well which are in the I-D: draft-probasco-paws= -overview-usecases-00.

The combined use-cases/requirements I-D will be subm= itted before the I-D submission deadline.

Your comments/feedback on the current set of use cas= es captured in I-D: draft-probasco-paws-overview-usecases-00 as well any ad= ditional use cases that we need to cover are welcome.

-Raj

--_000_21E7D9BD69CC7241AAE00F4EA183B71905B997008AM1MPN1024mgdn_-- From Gabor.Bajko@nokia.com Fri Jun 24 15:49:22 2011 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DFF311E810A for ; Fri, 24 Jun 2011 15:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aU4mGgrweJfm for ; Fri, 24 Jun 2011 15:49:21 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 9915611E8146 for ; Fri, 24 Jun 2011 15:49:21 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p5OMnJep022981 for ; Sat, 25 Jun 2011 01:49:20 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sat, 25 Jun 2011 01:49:14 +0300 Received: from 008-AM1MMR1-005.mgdnok.nokia.com (65.54.30.60) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.2.255.0; Sat, 25 Jun 2011 00:49:14 +0200 Received: from 008-AM1MPN1-037.mgdnok.nokia.com ([169.254.7.29]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi id 14.01.0289.008; Sat, 25 Jun 2011 00:49:13 +0200 From: To: Thread-Topic: Please help the Nomcom Thread-Index: AQHMMrCJV7/b2MS7ckSI5gOHFfVauZTNHFVQ Date: Fri, 24 Jun 2011 22:49:13 +0000 Message-ID: <7DDB35B005136A4DB9FF33E7E286EF001050E2@008-AM1MPN1-037.mgdnok.nokia.com> References: <20110624183513.7035311E81A8@ietfa.amsl.com> In-Reply-To: <20110624183513.7035311E81A8@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-version: 3.3.7.12 x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Company Confidential;Project=None; x-tituslabs-classificationhash-30: NgLgUAGhIMVcmkVcu9QCA60CUzWcoSI02JmMNiHu84NJXC0YKt3rEbygNmkYlxAAmbNA8ZxWaGOPSufxS3sadUJ4FZkryo7JCYNag/JviQGOTY67dQS/qyz4t/YUAKavMe6AVz+sVXWwg+ZL8TDKs/GrkIY/3Qypml/gnI2FRWVsdoD9wfAmWfxL4lYBaVdG0k7deU9BH6KMbjiUWXRxvdt0Sx0OPTbOJEiSg+ji+Jg= x-headerinfofordlp: None x-originating-ip: [107.3.158.51] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 24 Jun 2011 22:49:14.0388 (UTC) FILETIME=[F0EA0540:01CC32C0] X-Nokia-AV: Clean Subject: [paws] FW: Please help the Nomcom X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database $PAWS$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 22:49:22 -0000 Q2xhc3NpZmljYXRpb246IENvbXBhbnkgQ29uZmlkZW50aWFsDQoNCkZZSQ0KDQotLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogd2djaGFpcnMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRv OndnY2hhaXJzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBleHQgTm9tQ29tIENoYWly DQpTZW50OiBGcmlkYXksIEp1bmUgMjQsIDIwMTEgMTE6MzUgQU0NClRvOiBXb3JraW5nIEdyb3Vw IENoYWlycw0KU3ViamVjdDogUGxlYXNlIGhlbHAgdGhlIE5vbWNvbSANCg0KSGkgV0cgY2hhaXJz LA0KICBXZSBoYXZlIGhhZCBhIGdvb2QgcmVzcG9uc2UgdG8gdGhlIGZpcnN0IGNhbGwgZm9yIHZv bHVudGVlcnMgYnV0IHRoZSByYXRlIGF0IHdoaWNoIG5ldyB2b2x1bnRlZXJzIGFyZSBjb21pbmcg aW4gaXMgc2xvd2luZyBkb3duLiBUaGUgTm9tY29tIHByb2Nlc3MgaXMgYmVzdCBzZXJ2ZWQgYnkg YSBsYXJnZSBwb29sIG9mIHZvbHVudGVlcnMgZHJhd24gZnJvbSBhIHdpZGUgc3BlY3RydW0gb2Yg SUVURiBhdHRlbmRlZXMuIFdoZXJlIGVsc2Ugd291bGQgd2UgZmluZCB0aGlzIHdpZGUgc3BlY3Ry dW0gaWYgbm90IGluIHRoZSBXRyBtYWlsaW5nIGxpc3RzLg0KDQpJIHdvdWxkIHJlYWxseSBhcHBy ZWNpYXRlIGl0IGlmIHlvdSBjYW4gZm9yd2FyZCB0aGUgbWVzc2FnZSBvbnRvIHlvdXIgd29ya2lu ZyBncm91cCBtYWlsaW5nIGxpc3RzLiANCg0KVGhlIGxhdGVzdCB2b2x1bnRlZXIgc3RhdHVzIGFu ZCB0aGUgc2Vjb25kIGNhbGwgZm9yIHZvbHVudGVlcnMgY2FuIGJlIGZvdW5kIGF0IGh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvYW5uL25vbWNvbS8yOTY0Lw0KDQpUaGFua3MgaW4gYWR2YW5j ZSBmb3IgeW91ciBoZWxwLg0KDQpTdXJlc2ggS3Jpc2huYW4NCk5vbWNvbSBDaGFpciAyMDExLTIw MTINCkVtYWlsOiBub21jb20tY2hhaXJAaWV0Zi5vcmcsIHN1cmVzaC5rcmlzaG5hbkBlcmljc3Nv bi5jb20NCg0KQ2xhc3NpZmljYXRpb246IENvbXBhbnkgQ29uZmlkZW50aWFsDQo= From Gabor.Bajko@nokia.com Tue Jun 28 10:16:11 2011 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA8121F8596 for ; Tue, 28 Jun 2011 10:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ij3gOtIfVKd for ; Tue, 28 Jun 2011 10:16:11 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 5862E11E80FD for ; Tue, 28 Jun 2011 10:15:50 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p5SHFaZK017380 for ; Tue, 28 Jun 2011 20:15:36 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 28 Jun 2011 20:15:35 +0300 Received: from 008-AM1MMR1-001.mgdnok.nokia.com (65.54.30.56) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 28 Jun 2011 19:15:35 +0200 Received: from 008-AM1MPN1-037.mgdnok.nokia.com ([169.254.7.29]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.01.0289.008; Tue, 28 Jun 2011 19:15:34 +0200 From: To: Thread-Topic: slot requests for the Quebec meeting Thread-Index: Acw1tlMMpD6vKBkiRXihyx9KDUjyHA== Date: Tue, 28 Jun 2011 17:15:34 +0000 Message-ID: <7DDB35B005136A4DB9FF33E7E286EF0010BE94@008-AM1MPN1-037.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-version: 3.3.7.12 x-tituslabs-classifications-30: TLPropertyRoot=Nokia; Confidentiality=Public; Project=None; x-tituslabs-classificationhash-30: AUkF7AZ/aooHlqC+qifQh2+py5//9BfpsoHfeXlc0QPfmTX9IEWNmQolhsZCJwZ7r5VSXlfnXKQVh9ITKmqE21BpEuUfzbBl3V/QVBAW0to7eOX6JMEk6/xyTn35IrvjmdBQDIRL4KNkYEVvFTgvgrIaLGmJdJp6M4BQzhyr4JrdfG+/ASSca3LXt6QzAyJHru5IghgsmMUYwZVv4DUDByFwjPv1jof1LlA9+HUABFk= x-headerinfofordlp: None x-originating-ip: [107.3.158.51] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 28 Jun 2011 17:15:35.0736 (UTC) FILETIME=[FE852380:01CC35B6] X-Nokia-AV: Clean Subject: [paws] slot requests for the Quebec meeting X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database $PAWS$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 17:16:11 -0000 Classification: Public Folks, PAWS got a 2 hour slot on Tuesday, July 26th from 1pm at the upcoming F2F i= n Quebec city. If you'd like to present, please send slot requests to the c= hairs. -gabor Classification: Public