Subject: [paws] I-D Action: draft-ietf-paws-protocol-04.txt

From: [email-masked]
Date: Tue, 07 May 2013 21:56:26 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Protocol to Access WS database Working Group of the IETF.

	Title           : Protocol to Access Spectrum Database
	Author(s)       : Vincent Chen
                          Subir Das
                          Lei Zhu
                          John Malyar
                          Peter J. McCann
	Filename        : draft-ietf-paws-protocol-04.txt
	Pages           : 88
	Date            : 2013-05-07

Abstract:
   Portions of the radio spectrum that are allocated to licensees are
   available for non-interfering use.  This available spectrum is called
   "White Space."  Allowing secondary users access to available spectrum
   "unlocks" existing spectrum to maximize its utilization and to
   provide opportunities for innovation, resulting in greater overall
   spectrum utilization.

   One approach to manage spectrum sharing uses databases to report
   spectrum availability to devices.  To achieve interoperability among
   multiple devices and databases, a standardized protocol must be
   defined and implemented.  This document defines such a protocol, the
   "Protocol to Access White Space database" (PAWS).

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-paws-protocol

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-paws-protocol-04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-paws-protocol-04

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Vincent Chen <[email-masked]>
Date: Tue, 7 May 2013 22:01:57 -0700

All,

I have uploaded a new version that incorporates the items discussed at the
previous F2F and
on the list.

Diff:
http://www.ietf.org/rfcdiff?url1=draft-ietf-paws-protocol-03&difftype=--html&submit=Go%21&url2=draft-ietf-paws-protocol-04

Summary of changes:

   o  Expanded the Database Discovery mechanism to describe in more
      detail pre-configuration with URIs of databases and database-
      listing services, including mechanisms for updating the
      configurations when things change
      *  Add database-change field to Available Spectrum Response
         (Section 4.4.2)
   o  Added fields that are anticipated to be needed by the ETSI
      harmonized standard for White Space Devices:
      *  Added bandwidth constraints to the Available Spectrum Response
         (Section 4.4.2)
      *  Updated Available Spectrum Response to return RulesetInfo,
         rather than just a rule-set identifier
      *  Added optional device-manufacturer and device-model IDs to the
         DeviceDescriptor (Section 5.2). message.  Also moved fccId from
         this message to the IANA section.
      *  Expanded IANA (Section 9) sections
   o  Clarified restrictions on the specification of the vertices of a
      Polygon.
   o  Changed default confidence level to 95% for a point with
      uncertainty
   o  Clarified how devices without absolute time source can use the
      timestamps in the response messages
   o  Change method names to start with "spectrum.paws." prefix
   o  Added maximum string lengths
   o  Updated author contact info
   o  More typo fixes

There are still some TBDs associated with the ETSI additions, but otherwise
has addressed all our prior open issues.

-vince

On Tue, May 7, 2013 at 9:56 PM, <[email-masked]> wrote:

> _______________________________________________
> paws mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/paws
>

-- 
-vince

---

From: <[email-masked]>
Date: Thu, 16 May 2013 21:35:26 +0000

Vince,

What are the remaining open issues in this latest draft, you or any of the co-authors are aware of?
Since there has been not much feedback, if you think there aren't open issues left, we could issue a working group last call.

-          gabor

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Vincent Chen
Sent: Tuesday, May 07, 2013 10:02 PM
To: [email-masked]
Subject: Re: [paws] I-D Action: draft-ietf-paws-protocol-04.txt

All,

I have uploaded a new version that incorporates the items discussed at the previous F2F and
on the list.

Diff: http://www.ietf.org/rfcdiff?url1=draft-ietf-paws-protocol-03&difftype=--html&submit=Go%21&url2=draft-ietf-paws-protocol-04

Summary of changes:

There are still some TBDs associated with the ETSI additions, but otherwise has addressed all our prior open issues.

-vince

On Tue, May 7, 2013 at 9:56 PM, <[email-masked]<mailto:[email-masked]>> wrote:

Abstract:

_______________________________________________
paws mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/paws

--
-vince

---

From: Vincent Chen <[email-masked]>
Date: Thu, 16 May 2013 19:09:57 -0700

Gabor,

There is one more issue that has come to my attention.

When the Master Device is requesting the available spectrum on behalf of a
Slave Device,
the request message should have an optional field for identifying the
Master Device
(in addition to the one that already identifies the Slave Device).

This should be a simple addition.

-vince

On Thu, May 16, 2013 at 2:35 PM, <[email-masked]> wrote:

>  Vince, ****
>
> ** **
>
> What are the remaining open issues in this latest draft, you or any of the
> co-authors are aware of?****
>
> Since there has been not much feedback, if you think there aren’t open
> issues left, we could issue a working group last call.****
>
> ** **
>
> **-          **gabor****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *ext Vincent Chen
> *Sent:* Tuesday, May 07, 2013 10:02 PM
> *To:* [email-masked]
> *Subject:* Re: [paws] I-D Action: draft-ietf-paws-protocol-04.txt****
>
> ** **
>
> All,****
>
> ** **
>
> previous F2F and****
> on the list.****
> ** **
> ****
> ** **
> Summary of changes:****
> ** **
>    o  Expanded the Database Discovery mechanism to describe in more****
>
>       detail pre-configuration with URIs of databases and database-****
>
>       listing services, including mechanisms for updating the****
>
>       configurations when things change****
>
>       *  Add database-change field to Available Spectrum Response****
>
>          (Section 4.4.2)****
>
>    o  Added fields that are anticipated to be needed by the ETSI****
>
>       harmonized standard for White Space Devices:****
>
>       *  Added bandwidth constraints to the Available Spectrum Response***
> *
>
>          (Section 4.4.2)****
>
>       *  Updated Available Spectrum Response to return RulesetInfo,****
>
>          rather than just a rule-set identifier****
>
>       *  Added optional device-manufacturer and device-model IDs to the***
> *
>
>          DeviceDescriptor (Section 5.2). message.  Also moved fccId from**
> **
>
>          this message to the IANA section.****
>
>       *  Expanded IANA (Section 9) sections****
>
>    o  Clarified restrictions on the specification of the vertices of a****
>
>       Polygon.****
>
>    o  Changed default confidence level to 95% for a point with****
>
>       uncertainty****
>
>    o  Clarified how devices without absolute time source can use the****
>
>       timestamps in the response messages****
>
>    o  Change method names to start with "spectrum.paws." prefix****
>
>    o  Added maximum string lengths****
>
>    o  Updated author contact info****
>
>    o  More typo fixes****
>
> ** **
>
> There are still some TBDs associated with the ETSI additions, but
> otherwise has addressed all our prior open issues.****
>
> ** **
>
> -vince****
>
> ** **
>
> On Tue, May 7, 2013 at 9:56 PM, <[email-masked]> wrote:****
>
>
> https://www.ietf.org/mailman/listinfo/paws****
>
>
>
> ****
>
> ** **
>
> --
> -vince ****
>

-- 
-vince

---

From: Cesar Gutierrez <[email-masked]>
Date: Fri, 17 May 2013 11:02:35 +0000

Vince and all,

Another issue that has slipped under the radar.

We have the concept of "Generic operational parameters" in ETSI and the UK. These are the spectrum use parameters that ANY Slave in the coverage area of a Master can use. The values of these parameters will be broadcasted by the Master, and a Slave will normally use them to "associate" and eventually get "specific operational parameters" which will be tailored to the Slave precise location and device characteristics. However, it is possible that some Slaves, for instance cheap devices that cannot geolocate, will continue using the generic operational parameters in normal operations (after association)

To be clear, the Generic operational parameters are used by Slaves, although the database will calculate these parameters on the basis of information from the Master. The calculation requires the location of the Master, and the power levels it uses. With this, the database can 1) calculate the coverage area of the Master, 2) assume that a Slave might be in any location within that area, and 3) calculate a set of generic parameters on that could be used anywhere in the coverage area. Note that the Master must have requested and obtained operational parameters for itself before engaging in this. Therefore, the database already knows the Master's location and intended power (this through the SPECTRUM_USE_NOTIFY procedure).

I think that a simple way to implement the request for generic operational parameters could be to re-use the AVAIL_SPECTRUM_REQ procedure, with the addition of a flag to indicate to the database that the request is for generic operational parameters and not for operational parameters for the Master itself, or for a specific slave.

Thanks and regards,
Cesar

From: [email-masked] [mailto:[email-masked]] On Behalf Of Vincent Chen
Sent: 17 May 2013 03:10
To: [email-masked]
Cc: [email-masked]
Subject: Re: [paws] I-D Action: draft-ietf-paws-protocol-04.txt

Gabor,

When the Master Device is requesting the available spectrum on behalf of a Slave Device,
the request message should have an optional field for identifying the Master Device
(in addition to the one that already identifies the Slave Device).

-vince

On Thu, May 16, 2013 at 2:35 PM, <[email-masked]<mailto:[email-masked]>> wrote:
Vince,

-          gabor

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of ext Vincent Chen
Sent: Tuesday, May 07, 2013 10:02 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [paws] I-D Action: draft-ietf-paws-protocol-04.txt

All,

Summary of changes:

-vince

Abstract:

--
-vince

--
-vince

________________________________

******************************************************************************************************************
For more information visit www.ofcom.org.uk

This email (and any attachments) is confidential and intended for the use of the addressee only.

If you have received this email in error please notify the originator of the message and delete it from your system.

This email has been scanned for viruses. However, you open any attachments at your own risk.

Any views expressed in this message are those of the individual sender and do not represent the views or opinions of Ofcom unless expressly stated otherwise.
******************************************************************************************************************

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 17 May 2013 12:51:55 +0000

Probably better to have some multi-use type-of-request parameter in the request with a registry of values, one of which would be "Generic Parameters".

Brian

On May 17, 2013, at 7:02 AM, Cesar Gutierrez <[email-masked]<mailto:[email-masked]>> wrote:

Vince and all,

We have the concept of “Generic operational parameters” in ETSI and the UK. These are the spectrum use parameters that ANY Slave in the coverage area of a Master can use. The values of these parameters will be broadcasted by the Master, and a Slave will normally use them to “associate” and eventually get “specific operational parameters” which will be tailored to the Slave precise location and device characteristics. However, it is possible that some Slaves, for instance cheap devices that cannot geolocate, will continue using the generic operational parameters in normal operations (after association)

To be clear, the Generic operational parameters are used by Slaves, although the database will calculate these parameters on the basis of information from the Master. The calculation requires the location of the Master, and the power levels it uses. With this, the database can 1) calculate the coverage area of the Master, 2) assume that a Slave might be in any location within that area, and 3) calculate a set of generic parameters on that could be used anywhere in the coverage area. Note that the Master must have requested and obtained operational parameters for itself before engaging in this. Therefore, the database already knows the Master’s location and intended power (this through the SPECTRUM_USE_NOTIFY procedure).

Thanks and regards,
Cesar

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Vincent Chen
Sent: 17 May 2013 03:10
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [paws] I-D Action: draft-ietf-paws-protocol-04.txt

Gabor,

-vince

What are the remaining open issues in this latest draft, you or any of the co-authors are aware of?
Since there has been not much feedback, if you think there aren’t open issues left, we could issue a working group last call.

-          gabor

All,

Summary of changes:

-vince

Abstract:

--
-vince

--
-vince

******************************************************************************************************************
For more information visit www.ofcom.org.uk<http://www.ofcom.org.uk>

---

From: Ben Ward <[email-masked]>
Date: Fri, 17 May 2013 14:01:24 +0100

Vince,

This is my first post to the PAWS list (and indeed any IETF draft) so
please let me know if I'm not following procedure.

I'm glad draft 04 covers database discovery in more detail. I'm still
curious about the Error Handling section.

I understand a grace period is useful and necessary when no databases are
contactable by the Device for a short period.

Does this also handle the scenario of the Device losing contact with the
regulatory domain's Listing Server? Should Devices trying to update their
database entry from a Listing Server which has gone away have a grace
period/hold timer too? Or does the first failed attempt cause complete
shutdown of the Device?

Thanks
Ben

On 8 May 2013 06:01, Vincent Chen <[email-masked]> wrote:

> otherwise has addressed all our prior open issues.
>
> -vince
>
>

-- 
[email-masked] | http://www.crouchingbadger.com

---

From: Vincent Chen <[email-masked]>
Date: Mon, 20 May 2013 09:41:45 -0700

Cesar,

Questions and comment inline.

On Fri, May 17, 2013 at 4:02 AM, Cesar Gutierrez <
[email-masked]> wrote:

> We have the concept of “Generic operational parameters” in ETSI and the
> UK. These are the spectrum use parameters that ANY Slave in the coverage
> area of a Master can use. The values of these parameters will be
> broadcasted by the Master, and a Slave will normally use them to
> “associate” and eventually get “specific operational parameters” which will
> be tailored to the Slave precise location and device characteristics.
> However, it is possible that some Slaves, for instance cheap devices that
> cannot geolocate, will continue using the generic operational parameters in
> normal operations (after association)
>

In the PAWS specification, a "Slave" device is defined to be one that does
not have its own geo-location capability. If a device does have
geo-location capability, then:
 - It MAY uses the generic operation parameters to establish access to the
database via the Master
 - It makes its own request (as a Master) to the database, providing its
own geo location
 - It MAY change to the operational parmeters

I think that satisfies the requirements.

>
> To be clear, the Generic operational parameters are used by Slaves,
> although the database will calculate these parameters on the basis of
> information from the Master. The calculation requires the location of the
> Master, and the power levels it uses. With this, the database can 1)
> calculate the coverage area of the Master, 2) assume that a Slave might be
> in any location within that area, and 3) calculate a set of generic
> parameters on that could be used anywhere in the coverage area. Note that
> the Master must have requested and obtained operational parameters for
> itself before engaging in this. Therefore, the database already knows the
> Master’s location and intended power (this through the SPECTRUM_USE_NOTIFY
> procedure).
>
>
>
> I think that a simple way to implement the request for generic operational
> parameters could be to re-use the AVAIL_SPECTRUM_REQ procedure, with the
> addition of a flag to indicate to the database that the request is for
> generic operational parameters and not for operational parameters for the
> Master itself, or for a specific slave.
>

Sounds reasonable. Some regulatory domains, of course, may not allow this
mode.

---

From: Vincent Chen <[email-masked]>
Date: Fri, 24 May 2013 19:17:21 -0700

Ben,

I'm sorry about letting this slip through without a response.

Whether there is a grace period for the Listing Server is determined by a
regulator, but it probably makes sense
to allow for that parameter in the protocol.

The question is, can the current grace-period parameter be applied to both
the Database and the
Listing Server? or should we add another parameter to maintain flexibility?

Thoughts?

-vince

---

From: Vincent Chen <[email-masked]>
Date: Tue, 28 May 2013 22:09:38 -0700

Hi Mark,

** **
>
> Apologies for the late comments. In the -04 rev, I noticed that the term
> “listing server” is used before it is defined. I suggest adding an entry
> for “Database Listing Server” to the Terminology section to improve
> readability.
>

Thanks. I'll add this to the Terminology section.

> ****
>
> ** **
>
> I also wanted to check my understanding of the database discovery clauses. In section 4, the draft states that database discovery MUST be supported by Master devices. I understand from the draft that there are two types of database discovery: pre-configured database discovery and dynamic discovery. For the pre-configured database discovery, a Master device would determine its location and consult its local config to find the appropriate WSDB(s). For dynamic discovery, it would use the procedures in section 4.1.1 and contact a Database Listing Server. Is this understanding correct so far?
>
> I would characterize the second as a preconfiguration of a Database
Listing Server, so it's not completely "dynamic".
This is driven by Ofcom (and potentially the ETSI) requirement that a
regulator may dictate that a device MUST contact
a listing server operated by the regulator for an approved list of DBs.
This is behavior that must be built into the device.

For example, a DB can inform the device that it is in the UK, but the
device must map "UK" to the URL of the
listing server specified by the UK regulator.

> ****
>
> ** **
>
> In section 4.1.1 you state “Specific message formats are defined by the regulators”. In some regulatory domains, the regulator has deferred protocol definition to the market participants but I’m taking this to mean that LoST could be one the “specific message formats” selected by a regulator. Is this the correct interpretation?
>
>
I suppose LoST could be one of the formats. One reservation is that it
might result in XML vs JSON discussions again :)