Subject: [paws] use cases and requirements document

From: <[email-masked]>
Date: Thu, 9 Aug 2012 19:55:01 +0000

Folks,

During the last F2F meeting, there was an agreement to make a slight update to requirement D.7 in http://www.ietf.org/id/draft-ietf-paws-problem-stmt-usecases-rqmts-06.txt, to make channel numbers optional to be supported. Ie, change the current D.7
"The Data Model MUST support specifying a list of available channels. The Data Model MUST support specification of this information by channel numbers and by start and stop frequencies. The Data Model MUST support a channel availability schedule and maximum power level for each channel in the list."
to
"The Data Model MUST support specifying a list of available channels. The Data Model MUST support specification of this information by start and stop frequencies and MAY include channel numbers. The Data Model MUST support a channel availability schedule and maximum power level for each channel in the list."

I'd like to confirm this change on the list. If anyone has any objections, let me know. Otherwise I'll plan to send the document to the iesg after this change is implemented.

-          Gabor

---

From: Peter McCann <[email-masked]>
Date: Thu, 9 Aug 2012 19:57:48 +0000

I think "MAY include channel numbers" is somewhat ambiguous.  I would
prefer "MAY support specification of this information by channel number".

-Pete

[email-masked] wrote:
> Folks,
> 
> 
> 
> During the last F2F meeting, there was an agreement to make a slight 
> update to requirement D.7 in http://www.ietf.org/id/draft-ietf-paws-
> problem-stmt-usecases-rqmts-06.txt <http://www.ietf.org/id/draft-ietf-
> paws-problem-stmt-usecases-rqmts-06.txt> , to make channel numbers 
> optional to be supported. Ie, change the current D.7
> 
> "The Data Model MUST support specifying a list of available channels.
> The Data Model MUST support specification of this information by 
> channel numbers and by start and stop frequencies. The Data Model MUST 
> support a channel availability schedule and maximum power level for 
> each channel in the list."
> 
> to
> 
> "The Data Model MUST support specifying a list of available channels.
> The Data Model MUST support specification of this information by start 
> and stop frequencies and MAY include channel numbers. The Data Model 
> MUST support a channel availability schedule and maximum power level 
> for each channel in the list."
> 
> 
> 
> I'd like to confirm this change on the list. If anyone has any 
> objections, let me know. Otherwise I'll plan to send the document to 
> the iesg after this change is implemented.
> 
> 
> 
> -          Gabor

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 9 Aug 2012 18:24:44 -0400

<as individual>
I would like to suggest a more radical change

I would like to define the term: spectrum unit as a unit of spectrum defined by a low and high frequency and optionally a channel identifier.  Then I would like to use "spectrum unit" wherever the word "channel" would occur throughout the document.   In the definition, I would observe that while it is common to have "channels" that are defined with some identifier, the protocol does not depend on such an arrangement, but can manage any swath of spectrum defined by an upper and lower frequency.

I'm not attached to the specific term "spectrum unit" but I don't want to use "channel" as that implies something that we are not limited by.

Brian

On Aug 9, 2012, at 3:57 PM, Peter McCann <[email-masked]> wrote:

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

---

From: Peter Stanforth <[email-masked]>
Date: Thu, 9 Aug 2012 18:37:42 -0400

I suggest we take a look at the work MITRE has been doing on Model-Based
Spectrum Management (MBSM). A lot of this is related to defining a
spectrum commodity which is, I think, the basis of what we are trying to
do here.
http://www.mitre.org/work/tech_papers/2011/11_2071/

On the same text I have a question, Where it says "The Data Model MUST
support a channel availability schedule and maximum power level for each
channel in the list." What does this mean?  The reason I ask is the FCC
does not allow for variable power and some Regulators are suggesting
channel allocation duration only be as long as the shortest available,
negating the need for an availability map.  Does the current wording allow
for these two cases?
Peter S.

On ThuAug/9/12 Thu Aug 9, 6:24 PM, "Rosen, Brian"
<[email-masked]> wrote:

>I would like to define the term: spectrum unit as a unit of spectrum
>defined by a low and high frequency and optionally a channel identifier.
>Then I would like to use "spectrum unit" wherever the word "channel"
>would occur throughout the document.   In the definition, I would observe
>that while it is common to have "channels" that are defined with some
>identifier, the protocol does not depend on such an arrangement, but can
>manage any swath of spectrum defined by an upper and lower frequency.
>
>I'm not attached to the specific term "spectrum unit" but I don't want to
>use "channel" as that implies something that we are not limited by.
>
>Brian
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 9 Aug 2012 18:56:22 -0400

Usually when we use the words "MUST support" we imply options.  If we didn't, we would usually say MUST specify or MUST require" or something like it.  So I would say, yes, the protocol must allow no schedule and no power limits, but it must also allow one or both of them.

Brian

---

From: Nancy Bravin <[email-masked]>
Date: Thu, 9 Aug 2012 16:12:57 -0700

Hi Guys 

So then in the section for terms there will be an explanation of when
a Must demands something, or offers one of two solutions, or? 

So it will need to be defined as to not be confusing as to when a "MUST" carries no other choices?

"Must Support" implies options
"Must specify" 
"Must require" , ETC.

Sincerely,

Nancy

---

From: <[email-masked]>
Date: Thu, 9 Aug 2012 23:21:44 +0000

The Data Model MUST support means that the data blob must be able to encode it, but it doesn't say anything about whether the db has to send it or not.
In FCC case, I'd say that the data model would encode the shortest available duration and the allowed power level.

- Gabor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Peter Stanforth
Sent: Thursday, August 09, 2012 3:38 PM
To: Rosen, Brian; Peter McCann
Cc: [email-masked]
Subject: Re: [paws] use cases and requirements document

I suggest we take a look at the work MITRE has been doing on Model-Based Spectrum Management (MBSM). A lot of this is related to defining a spectrum commodity which is, I think, the basis of what we are trying to do here.
http://www.mitre.org/work/tech_papers/2011/11_2071/

On the same text I have a question, Where it says "The Data Model MUST support a channel availability schedule and maximum power level for each channel in the list." What does this mean?  The reason I ask is the FCC does not allow for variable power and some Regulators are suggesting channel allocation duration only be as long as the shortest available, negating the need for an availability map.  Does the current wording allow for these two cases?
Peter S.

On ThuAug/9/12 Thu Aug 9, 6:24 PM, "Rosen, Brian"
<[email-masked]> wrote:

>identifier, the protocol does not depend on such an arrangement, but 
>can manage any swath of spectrum defined by an upper and lower frequency.
>
>I'm not attached to the specific term "spectrum unit" but I don't want 
>to use "channel" as that implies something that we are not limited by.
>
>Brian
>
>>> channel numbers and by start and stop frequencies. The Data Model 
>>> start and stop frequencies and MAY include channel numbers. The Data 
>>> Model MUST support a channel availability schedule and maximum power 
>>> level for each channel in the list."
>>> 
>>> 
>>>

---

From: Manikkoth Sajeev <[email-masked]>
Date: Thu, 9 Aug 2012 20:32:32 -0700 (PDT)

'spectrum unit' is it synonymous to 'band' which is a small section of spectrum?
I too support for the change of wording, as current mobile radio technologies use and switch frequencies, and channels in their regular operation.

Best Regards,
 
Sajeev Manikkoth
Mobile: +918792292002

________________________________
 From: "Rosen, Brian" <[email-masked]>
To: Peter McCann <[email-masked]> 
Cc: "[email-masked]" <[email-masked]> 
Sent: Friday, 10 August 2012, 3:54
Subject: Re: [paws] use cases and requirements document
  
<as individual>

Brian

---

From: Teco Boot <[email-masked]>
Date: Fri, 10 Aug 2012 08:37:23 +0200

(somewhat late response)

A center frequency and channel width is functional equivalent to start/stop frequencies. So is channel number, with ref to channel number assignment scheme. For a requirements document, we just need to specify what is needed. How it is encoded (Hz, wave length, channel ID) is solution space.

Seen our goal to make PAWS somewhat universal (not limited to US TVWS), I do not prefer using channel numbers.

Teco

Op 9 aug. 2012, om 21:55 heeft <[email-masked]> <[email-masked]> het volgende geschreven:

> “The Data Model MUST support specifying a list of available channels. The Data Model MUST support specification of this information by channel numbers and by start and stop frequencies. The Data Model MUST support a channel availability schedule and maximum power level for each channel in the list.”
> to
> “The Data Model MUST support specifying a list of available channels. The Data Model MUST support specification of this information by start and stop frequencies and MAY include channel numbers. The Data Model MUST support a channel availability schedule and maximum power level for each channel in the list.”
>  
> I’d like to confirm this change on the list. If anyone has any objections, let me know. Otherwise I’ll plan to send the document to the iesg after this change is implemented.
>  
> -          Gabor

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 10 Aug 2012 07:57:03 -0400

<as individual>
While I don't care if it's center and width or upper/lower, I do think we will define the format in the protocol for interoperability reasons, but don't need to do that in requirements.  It wouldn't hurt to decide now and use consistent terms, but we don't need to.

I think "band" won't work, as it usually implies a much wider piece of spectrum that has a common purpose.  The TV Band is all the channels.

On Aug 10, 2012, at 2:37 AM, Teco Boot <[email-masked]<mailto:[email-masked]>> wrote:

(somewhat late response)

Teco

Op 9 aug. 2012, om 21:55 heeft <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>> het volgende geschreven:

Folks,

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

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

---

From: Teco Boot <[email-masked]>
Date: Fri, 10 Aug 2012 14:48:45 +0200

What about this:

“The Data Model MUST support specifying a list of available channels. The Data Model MUST support specification of this information by start and stop frequencies, or equivalents such as center frequencies with channel width or channel numbers with channel nummer allocation scheme . The Data Model MUST support a channel availability schedule and maximum power level for each channel in the list.”

More thoughts on channel numbers: we likely run into problems in bands without a channel numbering scheme, or for example sub channels in TV bands.

Teco

Op 10 aug. 2012, om 13:57 heeft Rosen, Brian het volgende geschreven:

> On Aug 10, 2012, at 2:37 AM, Teco Boot <[email-masked]> wrote:
> 
>> (somewhat late response)
>>

---

From: "Benjamin A. Rolfe" <[email-masked]>
Date: Fri, 10 Aug 2012 08:25:41 -0700

"spectrum unit" if it is precisely defined as suggested has the
advantage of being non-obvious enough people may not assume they
know what it means  and so may actually read the definition :-).
Specifying a "spectrum unit" by start and end frequency is adequate,
as it accommodates the current FCC requirements (TV channels), with
flexibility to handle more granular specification which may be
needed in the future.   Alternatively I could offer "chunk of
spectrum" but I suspect that is less appropriate sounding for a
standard ;-).

Avoid the word "channel" without further qualification (like "TV
channel" as in FCC 15.70x), where ever possible, as it is overloaded
so much that people ofte assume a meaning different than what you
mean.

Regards

-Ben

'spectrum unit' is it synonymous to 'band' which is a
small section of spectrum?

I too support
for the change of wording, as current mobile radio
technologies use and switch frequencies, and channels in
their regular operation.

Best
Regards,

Sajeev
Manikkoth

Mobile: +918792292002

From: "Rosen,
Brian" <[email-masked]>

To: Peter
McCann <[email-masked]>

Cc:
"[email-masked]" <[email-masked]>

Sent:
Friday, 10 August 2012, 3:54

Subject:
Re: [paws] use cases and requirements document

<as individual>

I would like to define the term: spectrum unit as a unit of
spectrum defined by a low and high frequency and optionally
a channel identifier.  Then I would like to use "spectrum
unit" wherever the word "channel" would occur throughout the
document.  In the definition, I would observe that while it
is common to have "channels" that are defined with some
identifier, the protocol does not depend on such an
arrangement, but can manage any swath of spectrum defined by
an upper and lower frequency.

I'm not attached to the specific term "spectrum unit" but I
don't want to use "channel" as that implies something that
we are not limited by.

Brian

paws mailing list

[email-masked]

---

From: Eric Chu <[email-masked]>
Date: Sat, 11 Aug 2012 08:43:27 -0700

*Hi everyone,

Gathering all the shared points from everyone... I believe below is the 
complete list so far:

  * What's the best consistent representation of the words "channel
    numbers" for non-TV spectrum
  * Should we update the entire doc on the topic of "channel" or
    "channel numbers"
  * What's the best way to reduce vagueness in whether/how to include
    "channel numbers"
  * Is the reference to variable power required
  * What does channel availability schedule mean

Brian's suggestion of replacing every instance of "channel" is 
technically correctly. However, it is important for us to focus moving 
forward.  I would suggest we only work on the normative part of the 
spec.  The section Gabor is proposing for us to modify...

On what's the best generic label for the words "channel numbers", 
channel identifier might be the most accurate and neutral "label". 
  Thoughts?

On the question whether variable power is required, based on FCC 
adjacent-channel rules, the database may limit the Mode II devices to 
100mW for some channels and 40mW for others. Therefore, the data model 
needs to support specification of maximum power levels.

Lastly, with regards to "schedule", the intent is to have a way of 
informing devices when to operate for each frequency range. As long as 
the data model supports, for example, a list of time ranges, it does not 
prevent an implementation from providing a list with 1 entry which 
corresponds to the "shortest available".  The word "schedule" should be 
sufficient to capture this intent?

We would like to propose the following text to address these points:

"The Data Model MUST support specifying available spectrum. The Data 
Model MUST support specification of this information by start and stop 
frequencies and MAY also support specification of this information by 
channel identifiers. The Data Model MUST support a spectrum-availability 
schedule and maximum power levels for each frequency range."**

**Thoughts?
Eric

*
On 8/10/12 5:48 AM, Teco Boot wrote:
> and stop frequencies, or equivalents such as center frequencies with 
> channel width or channel numbers with channel nummer allocation scheme 
> . The Data Model MUST support a channel availability schedule and 
> maximum power level for each channel in the list."
>
> More thoughts on channel numbers: we likely run into problems in bands 
> without a channel numbering scheme, or for example sub channels in TV 
> bands.
>
> Teco
>
>
>> While I don't care if it's center and width or upper/lower, I do 
>> think we will define the format in the protocol for interoperability 
>> reasons, but don't need to do that in requirements.  It wouldn't hurt 
>> to decide now and use consistent terms, but we don't need to.
>>
>> I think "band" won't work, as it usually implies a much wider piece 
>> of spectrum that has a common purpose.  The TV Band is all the channels.
>>
>>
>>> A center frequency and channel width is functional equivalent to 
>>> start/stop frequencies. So is channel number, with ref to channel 
>>> number assignment scheme. For a requirements document, we just need 
>>> to specify what is needed. How it is encoded (Hz, wave length, 
>>> channel ID) is solution space.
>>>
>>> Seen our goal to make PAWS somewhat universal (not limited to US 
>>> TVWS), I do not prefer using channel numbers.
>>>
>>> Teco
>>>
>>>
>>> Op 9 aug. 2012, om 21:55 heeft <[email-masked] 
>>> <mailto:[email-masked]>> <[email-masked] 
>>> <mailto:[email-masked]>> het volgende geschreven:
>>>
>>>> Folks,
>>>> During the last F2F meeting, there was an agreement to make a 
>>>> slight update to requirement D.7 
>>>> inhttp://www.ietf.org/id/draft-ietf-paws-problem-stmt-usecases-rqmts-06.txt, 
>>>> to make channel numbers optional to be supported. Ie, change the 
>>>> current D.7
>>>> "The Data Model MUST support specifying a list of available 
>>>> channels. The Data Model MUST support specification of this 
>>>> information by channel numbers and by start and stop frequencies. 
>>>> The Data Model MUST support a channel availability schedule and 
>>>> maximum power level for each channel in the list."
>>>> to
>>>> "The Data Model MUST support specifying a list of available 
>>>> channels. The Data Model MUST support specification of this 
>>>> information by start and stop frequencies and MAY include channel 
>>>> numbers. The Data Model MUST support a channel availability 
>>>> schedule and maximum power level for each channel in the list."
>>>> objections, let me know. Otherwise I'll plan to send the document 
>>>> to the iesg after this change is implemented.
>>>> -Gabor
>>>> [email-masked] <mailto:[email-masked]>
>>> [email-masked] <mailto:[email-masked]>

---

From: "Malyar, John P" <[email-masked]>
Date: Sat, 11 Aug 2012 16:10:31 +0000

Eric

Thank you. I agree with your suggested updates. It is consistent with my previous understanding regarding requirements for the interface.

Regards

John Malyar

From: Eric Chu [mailto:[email-masked]]
Sent: Saturday, August 11, 2012 11:43 AM
To: Teco Boot <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [paws] use cases and requirements document

Hi everyone,

Gathering all the shared points from everyone... I believe below is the complete list so far:

  *   What's the best consistent representation of the words "channel numbers" for non-TV spectrum
  *   Should we update the entire doc on the topic of “channel” or “channel numbers”
  *   What’s the best way to reduce vagueness in whether/how to include "channel numbers"
  *   Is the reference to variable power required
  *   What does channel availability schedule mean

Brian's suggestion of replacing every instance of "channel" is technically correctly. However, it is important for us to focus moving forward.  I would suggest we only work on the normative part of the spec.  The section Gabor is proposing for us to modify...

On what's the best generic label for the words "channel numbers", channel identifier might be the most accurate and neutral "label".  Thoughts?

On the question whether variable power is required, based on FCC adjacent-channel rules, the database may limit the Mode II devices to 100mW for some channels and 40mW for others. Therefore, the data model needs to support specification of maximum power levels.

Lastly, with regards to "schedule", the intent is to have a way of informing devices when to operate for each frequency range. As long as the data model supports, for example, a list of time ranges, it does not prevent an implementation from providing a list with 1 entry which corresponds to the "shortest available".  The word "schedule" should be sufficient to capture this intent?

"The Data Model MUST support specifying available spectrum. The Data Model MUST support specification of this information by start and stop frequencies and MAY also support specification of this information by channel identifiers. The Data Model MUST support a spectrum-availability schedule and maximum power levels for each frequency range."

Thoughts?
Eric

Teco

<as individual>

(somewhat late response)

Teco

Folks,

-          Gabor

---

From: "Stine, John A." <[email-masked]>
Date: Mon, 13 Aug 2012 17:26:19 +0000

Sorry I am a little late to this discussion.  As Peter points out we are doing work that attempts to commoditize spectrum.  This work is already in a standards process through the IEEE DySPAN SC 1900.5 WG.  The goal is to create a means to define the boundaries of spectrum use, all types of uses!  The subsequent models enable management of coexistence among multiple database administrators.

I recognized early that the PAWS work would focus on meeting the minimum needs of the regulatory administrations allowing sharing and would not be looking too far forward where WS DB administration will go.  That is the reason that in my previous inputs I have pushed for the separation of the business parts of the data model from the spectrum definition part of the data model. The spectrum consumption models that are used in MBSM are only concerned with defining the boundaries of spectrum use.  It does not cover matters such as which database to use, how frequently the DB should be checked, how to identify the user of the spectrum, and what certificates should be used for authorizations. This narrower focus allows the models to be used for most sharing scenarios such as ad hoc sharing among government and commercial users.

First, I recommend that you elevate the goal of separating the business model and data model to a requirement.   Second, I recommend that you make the requirements for defining spectrum vague, and so "spectrum unit as required by the applicable regulatory administration" may be the best way to go.  Identifying spectrum as a channel or as a start and stop frequency are all naïve.  At some time in the future you will want to change this.  You will do yourself a big favor if you create a standard with that in mind.

John