Subject: [paws] wglc on https://datatracker.ietf.org/doc/draft-ietf-paws-protocol/

From: <[email-masked]>
Date: Tue, 3 Dec 2013 21:39:40 +0000

The editor posted the new draft, version -07.

I'd like to issue another  wg last call on the document. We need reviews and feedback in order to be able to progress the document.

Please read through the draft and send any comments you may have to the list in the next 2-3 weeks.

If you review the draft and have no comments, send a note to the list that the draft is good as it is, we need these notes as much as we need the actual comments.

Without a minimum number of reviews the document won't make progress towards publication. If you care about it, read it please.

Thanks, Gabor

---

From: Eliot Lear <[email-masked]>
Date: Wed, 11 Dec 2013 14:12:14 +0100

Hi Gabor,

I don't think you can call this a full review, but I do have a few
questions/issues.

Two general questions:

Could my cell phone or Wifi-enabled device be a Slave or Master Device
in order to make use of the database or is the intent that only base
stations be the target?

Also, have we liaised this document to the IEEE 802.11 people and
do/would they care (see below about licensed/unlicensed)?

4.1.  Database Discovery (and elsewhere):

> 4.1.  Database Discovery
>
>    Different regulators may have different requirements for the approval
>    and operation of databases, such as:
>
>    o  A regulator may only allow a limited number of certified databases
>       to operate.  It also may require the certification of each device-
>       to-database pairing.
>    o  A regulator may maintain a trusted website that lists all approved
>       databases, known as the Listing Server.  It also may mandate how
>       devices use the listing server.
>
>    o  A regulator may allow each database to define its own terms of
>       use, so that, for example, an approved device may not be able to
>       access all approved databases.
>

The basis of this document is that the regulators are in direct contact
with the Master Device.  I have some concerns about that approach:

1.  It would seem to me computationally intensive on the part of the
regulator to compute a geometry/contour to determine which frequencies
are available.  As much as I would be worried about a single request, I
don't see why regulators would want to take such aggregate load.  Has a
regulator agreed to do so?  Or am I wrong about the computation?

2.  Much of this seems to be predicated on micro-auctions in secondary
spectrum.  Interesting idea and worth pursuing, however, the one week
period below seems to lead us to question what "micro" means in this
context.  See below for that.

3.  I may be demonstrating my parochial nature, but there is a lot of
complexity in this document that is predicated on the assumption that
licensed use will be permitted.  That is- a specific station license is
required to transmit.  Wouldn't this protocol simplify considerably if
it focused on unlicensed use?  In fact, wouldn't it boil down to a file
transfer protocol and a database format as opposed to bouncing all of
these queries back and forth?  My question really is how the authors
came to this approach.  I can imagine some arguments, such as wanting to
track down bad actors, but I raise the issue because of the plethora of
PII that could end up getting shipped to regulators on a regular basis
over this. 

Section 4.1.1:

>    Within a regulatory domain that has a Database Listing Server, a
>    Device MUST use it to determine the URLs of databases for the domain.
>    The URI of the Listing Server for a regulatory domain MAY be
>    preconfigured in the device.  Where allowed by the regulator, the
>    Device MAY save the database list and SHOULD contact the Database
>    Listing Server periodically to update its list.  The time between
>    such updates MUST be no longer than one week, or any update interval
>    required by the applicable regulatory domain, whichever is shorter.

I presume that in this paragraph, when you say "Device" you mean "Master
Device".  going further, it seems to me that the point should not be
whether or not such a device has direct Internet connectivity, but
whether or not it can receive updates.  Those updates could conceivably
come from many sources, including ones in which IP is not used.

Moreover, there seems to have been an arbitrary period of time chosen (1
week).  Why not state that in terms of the EventTime in AVAIL_SPECTRUM_RESP?

Thanks,

Eliot

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 11 Dec 2013 14:14:06 +0000

I’ll take a stab at answering this:

> in order to make use of the database or is the intent that only base
In most regulatory environments, the device that has the radio in the shared spectrum must contact the database.  You could imagine having a whitespace radio in a next get cell phone, but generally the answer to the question is no.  Having said that, a database could, if it wanted to, grant anyone access to the database.

> do/would they care (see below about licensed/unlicensed)?
We have connected with the 802.22 folks, not 802.11. 

> with the Master Device.  
No.  The database is in contact with the device, not the regulators.  The regulators authorize the database, have access to it, but do not operate or manipulate it directly.  

> I have some concerns about that approach:
> 
The database does the computation.  The contour calculations can be done in advance, but would have to change as protected primary users change their use.  The database operation locates the device within the set of precalculated protected contours to determine which ones reduce the spectrum available to the whitespace device.

> context.  See below for that
You are incorrect.  All secondary users (whitespace devices) in the same location get the same spectrum availability.  There is no mechanism to allocate or share that available spectrum.  There is some desire to provide that kind of service, but it is beyond our charter.

> .
You have an incorrect model.
There is a set of licensed, protected users.  The database knows about them, and calculates contours to assure their use is protected.  There is a set of unlicensed, but type-approved whitespace devices (which includes masters and slaves).  They are secondary users - they can use spectrum if none of the primary, licensed users use it.  The secondary, unlicensed users ask the database what spectrum is available at their location at that time.  The database calculates which primary users would be affected by a secondary transmitter at that location and remove the primary user’s spectrum from the available secondary spectrum.  The database returns what is left (what spectrum is not used by any primary user at that location at that time).

All of this is provided in a regulated environment.  The regulator decides what the protections are, and what the unlicensed devices have to do to use the available spectrum.

> come from many sources, including ones in which IP is not used.
This section is referring to the process by which the device (a master device if there are master/slave devices) locates the database.  Not every use has slaves.  In some countries, there is a listing service of multiple competing database operators.  Only a database on that list may be used.  This is the control the regulator has on de-authorizing databases.

The PAWS protocol is based on IP transports.  We don’t consider models where there are alternatives to IP to access the listing service or the database. 

> week).  Why not state that in terms of the EventTime in AVAIL_SPECTRUM_RESP?
Again, this is the frequency at which the listing service must be requeried, not the database.  The frequency is normally set by the regulatory domain, and devices have to be built for one or more regulatory domains.   It’s much less often than the spectrum query.  This basically determines how quickly a regulator can de-authorize a database.

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

---

From: Eliot Lear <[email-masked]>
Date: Wed, 11 Dec 2013 15:49:43 +0100

Brian,

Thanks for your quick response.  I may have some more questions later,
but let's see how far we get now.

> In most regulatory environments, the device that has the radio in the shared spectrum must contact the database.  You could imagine having a whitespace radio in a next get cell phone, but generally…

ok
> We have connected with the 802.22 folks, not 802.11.

ok
> No.  The database is in contact with the device, not the regulators.  The regulators authorize the database, have access to it, but do not operate or manipulate it directly.  

ok
> The database does the computation.  The contour calculations can be done in advance, but would have to change as protected primary users change their use.  The database operation locates the device…

Ok, so the issue here is the data capacity requirements, in terms of why
the calculation is done by the database and not by the (master) Device?
> You are incorrect.  All secondary users (whitespace devices) in the same location get the same spectrum availability.  There is no mechanism to allocate or share that available spectrum.  There is…

Why then provide DeviceOwner if all secondary users are treated the
same?  That's how I leapt to my conclusion. Also see below.
> There is a set of licensed, protected users.

Right.

>   The database knows about them, and calculates contours to assure their use is protected.  There is a set of unlicensed, but type-approved whitespace devices (which includes masters and slaves).

Sure.

>   They are secondary users - they can use spectrum if none of the primary, licensed users use it.

Right.

>   The secondary, unlicensed users ask the database what spectrum is available at their location at that time.

Ok, and see above about my question as to where the calculation takes place.

>   The database calculates which primary users would be affected by a secondary transmitter at that location and remove the primary user’s spectrum from the available secondary spectrum.  The database returns what is left (what spectrum is not used by any primary user at that location at that time).

ok
> All of this is provided in a regulated environment.  The regulator decides what the protections are, and what the unlicensed devices have to do to use the available spectrum.

The protocol is very well generalized.  But my leap of logic was again
due to DeviceOwner.
> This section is referring to the process by which the device (a master device if there are master/slave devices) locates the database.  Not every use has slaves.  In some countries, there is a list…

ok

> The PAWS protocol is based on IP transports.  We don’t consider models where there are alternatives to IP to access the listing service or the database. 

ok

> Again, this is the frequency at which the listing service must be requeried, not the database.  The frequency is normally set by the regulatory domain, and devices have to be built for one or more…

Got it.  Question: what happens if the database that authorized a device
to use a frequency with some parameters is de-authorized before
EventTime has expired?  Must the device submit a new request?  Is that
something that would be contained within a RuleSet (e.g., external)?

Thanks,

Eliot

---

From: Ray Bellis <[email-masked]>
Date: Wed, 11 Dec 2013 15:06:51 +0000

> the calculation is done by the database and not by the (master) Device?

The calculations are complicated, and rely on the national DTT coverage data - the UK DTT tables alone (in uncompressed form) are expected to be many GBs in size.

In some jurisdictions the calculations also depend on frequently updated tables of other primary users.

It simply wouldn't scale for every "master device" to contain that data, nor keep them up to date.

Furthermore, the telecoms regulators typically only permit contracted (or licensed) database operators to have access to this raw data, perform the calculations, and subsequently assign frequencies and power levels to devices.

Ray

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 11 Dec 2013 16:53:18 +0000

> the calculation is done by the database and not by the (master) Device?
The database is big.  The contour calculation is hard to get right and its an expensive calculation involving a large, accurate topology (height) dataset.  It’s really important that two devices that query from the same place at the same time get the same spectrum to use, so the regulator carefully checks to make sure all the databases get the same answers to the same question.  Much harder.

> same?  That's how I leapt to my conclusion. Also see below.
So an interfering device can be located and turned off. 

> something that would be contained within a RuleSet (e.g., external)?
Time scales work.  The spectrum use expiration is a day or less.  The database expiration is a week or less.  It works.

Brian

---

From: <[email-masked]>
Date: Wed, 11 Dec 2013 21:36:29 +0000

Just a small correction:
I did send the link to 802.11af chairs for distributions to that task group and invited comments from them.
Also, the PAWS progress is presented at every 802.11 plenary meeting, so interested folks should know about the document and its status.

- Gabor

-----Original Message-----
From: ext Rosen, Brian [mailto:[email-masked]] 
Sent: Wednesday, December 11, 2013 6:14 AM
To: Eliot Lear
Cc: Bajko Gabor (Nokia-CTO/SiliconValley); <[email-masked]>
Subject: Re: [paws] wglc on https://datatracker.ietf.org/doc/draft-ietf-paws-protocol/

I'll take a stab at answering this:

> The basis of this document is that the regulators are in direct 
> contact with the Master Device.

You have an incorrect model.
There is a set of licensed, protected users.  The database knows about them, and calculates contours to assure their use is protected.  There is a set of unlicensed, but type-approved whitespace devices (which includes masters and slaves).  They are secondary users - they can use spectrum if none of the primary, licensed users use it.  The secondary, unlicensed users ask the database what spectrum is available at their location at that time.  The database calculates which primary users would be affected by a secondary transmitter at that location and remove the primary user's spectrum from the available secondary spectrum.  The database returns what is left (what spectrum is not used by any primary user at that location at that time).

The PAWS protocol is based on IP transports.  We don't consider models where there are alternatives to IP to access the listing service or the database. 

> week).  Why not state that in terms of the EventTime in AVAIL_SPECTRUM_RESP?
Again, this is the frequency at which the listing service must be requeried, not the database.  The frequency is normally set by the regulatory domain, and devices have to be built for one or more regulatory domains.   It's much less often than the spectrum query.  This basically determines how quickly a regulator can de-authorize a database.

---

From: "Benjamin A. Rolfe" <[email-masked]>
Date: Wed, 11 Dec 2013 21:04:59 -0800

There is also a TVWS amendment to 802.15.4 that is nearing completion, 
for those that are interested.

And an additional remark:   FCC rules and OfCom as proposed allow for a 
device that is not directly connected to the database to operate through 
a cooperating peer that can connect and proxy for the device.

Using the example of a WiFi smart phone, it could perform the role of 
"master" or "slave", although it seems more natural as the "slave" 
(802.11 STA). If my Android had a 802.11af radio, it could with the 
right app act as an  AP while using the 4G network to contact the 
database, thus performing the "master" role.

-B

---

From: [email-masked]
Date: Sat, 14 Dec 2013 11:24:13 +0530

Hi,

Please find few comments based on my review of the new draft spec:

1. In AVAIL_SPECTRUM_REQ all parameters are shown optional. Does that mean
an empty request is ok? As  'Device descriptor' is required in response,
same should be the case in request too.

Also instead of 'location' and 'Master Device location', it will be better
to include 'location' and an optional 'Slave Device location' in case
request is on behave of slave, as Master is the default request entity.
Avail spectrum request can also include an optional time range, so that
database can send a filtered and useful set of spectrum for the given time
range, than the full set.

2. In SPECTRUM_USE_NOTIFY message 'spectra:list' parameter can include the
time range which the device intend to use the spectra, to improve QoS and
avoid too many request/response messages between master and database

3. Diagram in Section 4.5, which shows messages between master and device
can use different message tokens than the tokens used between master and
database. Which will make it explicitly clear that they are not the same.

4. Section 5.2 Device Descriptor can include a parameter to specify 'Mobile'
or 'Fixed' device

5. Section 5.4 Device Capabilities can include Power Range of the device
too.

6. Section 5.9 "The SpectrumSpec element encapsulates the schedule of
available  spectrum for a regulatory domain". Should this also include a
specific location area?

As a regulatory domain may include a large location coverage, and reuse of
licensed spectrum in different locations. Is there a need of location area
coverage parameter in the device descriptor?

7. Section 5.17 - Error codes. As the PAWS protocol is over HTTPS, not using
the same(HTTP) 1xx, 2xx, 3xx status codes looks like a better option. Use of
another range or 4/2 digit codes will avoid confusion.

Best Regards,

Sajeev

From: paws [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, December 04, 2013 3:10 AM
To: [email-masked]
Subject: [paws] wglc on
https://datatracker.ietf.org/doc/draft-ietf-paws-protocol/

I'd like to issue another  wg last call on the document. We need reviews and
feedback in order to be able to progress the document.

Please read through the draft and send any comments you may have to the list
in the next 2-3 weeks.

If you review the draft and have no comments, send a note to the list that
the draft is good as it is, we need these notes as much as we need the
actual comments. 

Without a minimum number of reviews the document won't make progress towards
publication. If you care about it, read it please.

Thanks, Gabor

---

From: Vincent Chen <[email-masked]>
Date: Mon, 16 Dec 2013 11:04:01 -0800

Sajeev,

Thanks for your comments. Answers inline.

> same should be the case in request too.

An empty request is not OK. Each field, independently, may be optional, but
the descriptions describe when they are required.
There are some dependencies between the parameters. For example, if
"requestType" is for getting generic operating parameters,
which may be allowed by ETSI, then the DeviceDescriptor is optional.

In light of this, perhaps Device Descriptor in the response should be
optional.

>  Also instead of 'location' and 'Master Device location', it will be
> better to include 'location' and an optional 'Slave Device location' in
> case request is on behave of slave, as Master is the default request entity.
>

This is a matter of opinion, I suppose. I believe it is more consistent to
have "location" and "deviceDesc" be associated with the
target device and "masterDeviceLocation" and "masterDeviceDesc" be
associated with the "master".

> range, than the full set.

I'm not sure this is consistent with the rules. The Database may be
required to provide the availability for the next N hours.
I'd like to see other opinions on this point.

> avoid too many request/response messages between master and database

 Although it might be a good idea to include the time range which the
device intends to use the spectra, I'm not sure how that improves QoS or
reduce the number of messages?

> database. Which will make it explicitly clear that they are not the same.

It is subtle, but the figure already uses different line styles for the two
cases.

>
>
> 4. Section 5.2 Device Descriptor can include a parameter to specify
> 'Mobile' or 'Fixed' device
>

The regulatory domain defines device types, which, typically, are
associated with mobile or fixed.

> 5. Section 5.4 Device Capabilities can include Power Range of the device

This might be a reasonable extension, but probably would not fit in this
first version of the protocol.
 - Currently, the Database is responsible for informing the device the
maximum allowed power levels, regardless
   of the power-range capabilities of the device.

 - Device Capabilities can be quite complex to express, and it would be
better to tackle this later.

> coverage parameter in the device descriptor?

I believe this is already addressed:

In the current and proposed rules, the Device must request new spectrum if
it moves by more than X distance.
For Databases that support request by region, it is expected that the
Database returns spectrum that is allowed
anywhere within the region.

>
>
> 7. Section 5.17 - Error codes. As the PAWS protocol is over HTTPS, not
> using the same(HTTP) 1xx, 2xx, 3xx status codes looks like a better option.
> Use of another range or 4/2 digit codes will avoid confusion.
>

These define error codes at the protocol level.

When the binding is JSON-RPC over HTTPS, the HTTP error codes at the
transport level still apply.
(e.g., 3xx redirect, 5xx server errors, etc.)

---

From: [email-masked]
Date: Wed, 18 Dec 2013 20:30:05 +0530

Thanks Vincent for the clarifications. Few inline comments below.

Best Regards,

Sajeev Manikkoth 

From: Vincent Chen [mailto:[email-masked]] 
Sent: Tuesday, December 17, 2013 12:34 AM
To: Sajeev Manikkoth
Cc: [email-masked]; [email-masked]
Subject: Re: [paws] wglc on
https://datatracker.ietf.org/doc/draft-ietf-paws-protocol/

Sajeev,

Hi,

[Sajeev>>] Is it going a bit complex this way with parameter dependencies?

I'm not sure this is consistent with the rules. The Database may be required
to provide the availability for the next N hours.

 

 Although it might be a good idea to include the time range which the device
intends to use the spectra, I'm not sure how that improves QoS or reduce the
number of messages?

[Sajeev>>] Secondary user  service disruption due to primary or another user
using the frequency can be reduced if a time range is negotiated and
accepted. Also during the accepted time interval master need not further
query the db on the frequency/channel which negotiated.  

 

The regulatory domain defines device types, which, typically, are associated
with mobile or fixed.

[Sajeev>>] Yes, and in the request master can publish it through a parameter
was my point here. Perhaps this can help db to decide on the available
spectra for the device type.

 

 

 

Best Regards,

Sajeev

---

From: Vincent Chen <[email-masked]>
Date: Fri, 20 Dec 2013 10:31:42 -0800

Sorry for the delayed response.

On Wed, Dec 18, 2013 at 7:00 AM, <[email-masked]> wrote:

> *From:* Vincent Chen [mailto:[email-masked]]
> *Sent:* Tuesday, December 17, 2013 12:34 AM
> *To:* Sajeev Manikkoth
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Re: [paws] wglc on
> An empty request is not OK. Each field, independently, may be optional,
> but the descriptions describe when they are required.
>
> *[Sajeev>>] Is it going a bit complex this way with parameter
> dependencies?*
>

*[vchen] I believe this is a trade-off between adding more fine-grained
"rpc methods" versus fewer methods with more optional parameters.*
*At the end of the day, the complexities are equivalent, if you want to
support the different use cases. *

> *[Sajeev>>] Secondary user  service disruption due to primary or another
> user using the frequency can be reduced if a time range is negotiated and
> query the db on the frequency/channel which negotiated.  *
>

*[vchen] I believe this is already addressed. Certain classes of primary
users (wireless mics) already have the ability to reserve spectrum
(independent of PAWS), and the Database responses to secondary user must
take that into account. The database response is a schedule of available
spectrum that is valid for a specified duration, and the Master does not
have to contact the DB again during that duration.*

*To offer additional coordination between secondary users is out of scope,
but a Database may extend the protocol (as a value add feature).*

> It is subtle, but the figure already uses different line styles for the
> two cases.
>
>
>
>
>
> *[Sajeev>>] Yes, and in the request master can publish it through a
> parameter was my point here. Perhaps this can help db to decide on the
> available spectra for the device type.*
>
>
>

*[vchen] The Database is already supposed to take device type into account.
The regulatory rules require it. That is, the rules prescribe what spectrum
is available and the power levels, based on device type.*

-- 
-vince