*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:
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:
<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 protected]
<mailto:[email protected]>> wrote:
(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 protected]
<mailto:[email protected]>> <[email protected]
<mailto:[email protected]>> 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."
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
_______________________________________________
paws mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/paws
_______________________________________________
paws mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/paws
_______________________________________________
paws mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/paws
_______________________________________________
paws mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/paws
