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

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 13 Aug 2012 09:24:21 -0400

<as individual>
I would prefer to not use the word "channel" in our documents at all except for the term "channel identifier".  I proposed "spectrum unit", although any other term will do.  "Channel" has too much baggage,  A simple editorial change like this is simple, and it's much better to do it now.

I think we need power in both the query and the response.  In some domains, it may be that you specify what power you want to use and the DB tells you what spectrum you can use at that power.  In other, a US-like rule may be in place.  Also in either the query or the registration, we need a device type, which should be an entry from an IANA registry.  This is how you get the US "Mode II" information.

With regard to schedule, I would like to see two mechanisms
1) a time by which the database should be queried again (which could represent the next change in schedule)
2) start/stop times for each spectrum unit available

Both these should be optional in the response.

My text

The data model must support specifying spectrum availability.  Spectrum units are specified by low and high frequencies and may have an optional channel identifier.

The data model must support a schedule for spectrum unit availability.  Two mechanisms must be supported.  The response to spectrum availability query may include a time by which the database must be requeried.  Each spectrum unit mentioned in the response may be annotated with start and stop time/date.  

 -----Original Message-----
From: 	Eric Chu [mailto:[email-masked]]
Sent:	Saturday, August 11, 2012 11:43 AM Eastern Standard Time
To:	Teco Boot
Cc:	Rosen, Brian; [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?

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-masked]> 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-masked]> <[email-masked]> het volgende geschreven:

								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
				_______________________________________________
				paws mailing list
				[email-masked]
				https://www.ietf.org/mailman/listinfo/paws

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

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

---

From: <[email-masked]>
Date: Mon, 13 Aug 2012 17:11:32 +0000

Hi All,

Given that we have completed two Working Group Last Call cycles and this
next version will go to the IESG, I hope we could agree on minimal changes
to the document, i.e. changes only to D.7 for this topic. This will ensure
the proper requirements are established for the developing PAWS protocol.
I believe Brian's proposed text captures the essential requirements.

Kind Regards,
Scott

On 8/13/12 8:24 AM, "ext Rosen, Brian" <[email-masked]> wrote:

><as individual>
>I would prefer to not use the word "channel" in our documents at all
>except for the term "channel identifier".  I proposed "spectrum unit",
>although any other term will do.  "Channel" has too much baggage,  A
>simple editorial change like this is simple, and it's much better to do
>it now.
>
>I think we need power in both the query and the response.  In some
>domains, it may be that you specify what power you want to use and the DB
>tells you what spectrum you can use at that power.  In other, a US-like
>rule may be in place.  Also in either the query or the registration, we
>need a device type, which should be an entry from an IANA registry.  This
>is how you get the US "Mode II" information.
>
>The data model must support specifying spectrum availability.  Spectrum
>units are specified by low and high frequencies and may have an optional
>channel identifier.
>
>The data model must support a schedule for spectrum unit availability.
>Two mechanisms must be supported.  The response to spectrum availability
>query may include a time by which the database must be requeried.  Each
>spectrum unit mentioned in the response may be annotated with start and
>stop time/date.  
>
>
>
>*    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"
>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
>
>
>
>        ³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
>
>
>        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]>
><[email-masked]> het volgende geschreven:
>
>
>                                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: <[email-masked]>
Date: Thu, 16 Aug 2012 22:45:40 +0000

It seems we have an agreement on the requirement to identify the spectrum, by using the start/stop frequencies, with optional channel identifiers.

Wrt to the schedule, we have so far two proposals, one from Brian proposing the use of start/stop times for each spectrum unit available, and one from Vincent proposing to use of Unix Epoch time in seconds. We need to decide on this, so please send your preference on this topic to the list.

- Gabor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Probasco Scott (Nokia-CIC/Dallas)
Sent: Monday, August 13, 2012 10:12 AM
To: [email-masked]
Subject: Re: [paws] use cases and requirements document

Hi All,

Given that we have completed two Working Group Last Call cycles and this next version will go to the IESG, I hope we could agree on minimal changes to the document, i.e. changes only to D.7 for this topic. This will ensure the proper requirements are established for the developing PAWS protocol.
I believe Brian's proposed text captures the essential requirements.

Kind Regards,
Scott

On 8/13/12 8:24 AM, "ext Rosen, Brian" <[email-masked]> wrote:

>domains, it may be that you specify what power you want to use and the 
>DB tells you what spectrum you can use at that power.  In other, a 
>US-like rule may be in place.  Also in either the query or the 
>registration, we need a device type, which should be an entry from an 
>IANA registry.  This is how you get the US "Mode II" information.
>
>units are specified by low and high frequencies and may have an 
>optional channel identifier.
>
>Two mechanisms must be supported.  The response to spectrum 
>availability query may include a time by which the database must be 
>requeried.  Each spectrum unit mentioned in the response may be 
>annotated with start and stop time/date.
>
>
>
>On what's the best generic label for the words "channel numbers", 
>channel identifier might be the most accurate and neutral "label".  Thoughts?
>
>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 
>channel identifiers. The Data Model MUST support a 
>spectrum-availability schedule and maximum power levels for each frequency range."
>
>
>Thoughts?
>Eric
>
>
>
>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.²
>    
>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.
>
>            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
>
>
>http://www.ietf.org/id/draft-ietf-paws-problem-stmt-usecases-rqmts-06.t
>xt,  to make channel numbers optional to be supported. Ie, change the 
>current
>D.7
>Data Model MUST support a channel availability schedule and maximum 
>power level for each channel in the list.²
>                to
>numbers. The Data Model MUST support a channel availability schedule 
>and maximum power level for each channel in the list.²
>                 
>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, 17 Aug 2012 09:08:37 -0400

Uh, the difference is representation of start/stop times.  We both propose
to send start/stop times.  Vincent proposes that the representation of
time be a long integer seconds since an epoch.  He would send two such
long integers.  I propose it be an ISO 8601 time string.  Specifically, I
would propose an ISO 8601 interval limited to start/end, e.g.
2011-03-01T13:00:00Z/2012-05-11T15:30:00Z.

On 8/16/12 6:45 PM, "[email-masked]" <[email-masked]> wrote:

>It seems we have an agreement on the requirement to identify the
>spectrum, by using the start/stop frequencies, with optional channel
>identifiers.
>
>Wrt to the schedule, we have so far two proposals, one from Brian
>proposing the use of start/stop times for each spectrum unit available,
>and one from Vincent proposing to use of Unix Epoch time in seconds. We
>need to decide on this, so please send your preference on this topic to
>the list.
>
>- Gabor
>
>next version will go to the IESG, I hope we could agree on minimal
>changes to the document, i.e. changes only to D.7 for this topic. This
>will ensure the proper requirements are established for the developing
>PAWS protocol.

---

From: Vincent Chen <[email-masked]>
Date: Fri, 17 Aug 2012 09:01:29 -0700

Comments:
- The proposal for long-integer seconds was to gauge preference from the
device folks

- If we use ISO 8601, could we restrict it to be only in UTC? :)

-- 
-vince

---

From: <[email-masked]>
Date: Fri, 17 Aug 2012 16:13:18 +0000

FWIW, I would prefer to use the seconds since epoch approach.

-Raj

From: ext Vincent Chen <[email-masked]<mailto:[email-masked]>>
Date: Friday, August 17, 2012 11:01 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [paws] use cases and requirements document

Comments:
- The proposal for long-integer seconds was to gauge preference from the device folks

On Fri, Aug 17, 2012 at 6:08 AM, Rosen, Brian <[email-masked]<mailto:[email-masked]>> wrote:

On 8/16/12 6:45 PM, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>> wrote:

>From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of
>Probasco Scott (Nokia-CIC/Dallas)
>To: [email-masked]<mailto:[email-masked]>
>On 8/13/12 8:24 AM, "ext Rosen, Brian" <[email-masked]<mailto:[email-masked]>> wrote:
>
>><as individual>
>>From:     Eric Chu [mailto:[email-masked]<mailto:[email-masked]>]
>>Cc:    Rosen, Brian; [email-masked]<mailto:[email-masked]>
>>        On Aug 10, 2012, at 2:37 AM, Teco Boot <[email-masked]<mailto:[email-masked]>> wrote:
>>
>>
>>            (somewhat late response)
>>
>>            Op 9 aug. 2012, om 21:55 heeft <[email-masked]<mailto:[email-masked]>>
>><[email-masked]<mailto:[email-masked]>> het volgende geschreven:
>>
>>
>>                                Folks,
>>
>>                [email-masked]<mailto:[email-masked]>
>>            [email-masked]<mailto:[email-masked]>
>>    [email-masked]<mailto:[email-masked]>
>>[email-masked]<mailto:[email-masked]>
>[email-masked]<mailto:[email-masked]>
>[email-masked]<mailto:[email-masked]>

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

--
-vince

---

From: Warren Kumari <[email-masked]>
Date: Fri, 17 Aug 2012 13:20:42 -0400

> FWIW, I would prefer to use the seconds since epoch approach.

Seconds since epoch is much simpler to deal with on small / embedded type devices, right up until you overflow -- can we suggest / remind implementors that this number may exceed 32 bits?

ISO <foo> is easier to read for humans, and libraries exist to deal with parsing it in basically all languages, etc...

My personal preference is ISO 8601, unless we think that really small devices are going to have to parse this for any reason?

W

> -Raj
> 
> From: ext Vincent Chen <[email-masked]>
> To: "[email-masked]" <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> On Fri, Aug 17, 2012 at 6:08 AM, Rosen, Brian <[email-masked]> wrote:

--
She'd even given herself a middle initial - X - which stood for "someone who has a cool and exciting middle name".

    -- (Terry Pratchett, Maskerade)

---

From: "Benjamin A. Rolfe" <[email-masked]>
Date: Mon, 20 Aug 2012 08:15:10 -0700

Thanks for the clarification.
There are also two notions of what "schedule" means, at least in the FCC
rules. There is the notion that the current channel availability data
has a expiration time, and thus there is a time in the future when
updating will be necessary. This is at most a day. Based on FCC rules,
this could be a local time determined by the device using the channel
data, and if that device is acting as a source for dependent device
"using" includes providing it to other dependent devices (and it would
have to provide the "valid until" time). I can imagine that other
regulatory bodies (and perhaps the FCC in the future) will require that
channel availability data provided by the data base also be tagged with
the "valid until" information. This does not require a start time, as
"now" is implied.

The other notion of schedule time is that the database contains a
predictive guess as to what channels will be available for the next 48
hours into the future. This is required by FCC (though the device must
still check at least once a day if what it is using is still valid). A
start/stop pair is required for this.

I think either format can be used to represent time in both cases. It is
also possible that the 48-hour schedule is all that PAWS needs to
provide to meet the regulations and the "valid until" can be derived
from that by the using device.

Hope that helps.
-Ben

---

From: "Benjamin A. Rolfe" <[email-masked]>
Date: Mon, 20 Aug 2012 08:29:54 -0700

One "device folk" persons opinion:

Comments:

- The proposal for long-integer seconds was to gauge preference
from the device folks

For some TVWS devices bandwidth will be scarce and compact
representations will be essential. In such cases over the air
protocols will be developed with this optimization focus and we
won't see IP and PAWS all the way to the device. In such cases there
will be a compression and conversion process in between. Either
representation is easily parsed. The device doing this process will
typically have the resources to run a full PAWS/HTTP/TCP/IP stack so
the extra processing to go from ISO date time to binary form is not
a major impact, so either works as well. For the case where
bandwidth is less scarce and all devices are capable of running PAWS
end to end, is there actual complexity savings from one over the
other? Will ISO 8601 be required as part of the HTTP/TCP stack
and/or for security anyway?

- If we use ISO 8601, could we restrict it to be only in UTC?
:)

That seems like a good idea to me.  And more easily implemented than
flattening the earth to put everyone in the same timezone (though
the latter would simplify my teleconference scheduling problem  ;-).

On Fri, Aug 17, 2012 at 6:08 AM, Rosen,
Brian <[email-masked]>
wrote:

Uh, the difference is representation of
start/stop times.  We both propose

to send start/stop times.  Vincent proposes that the
representation of

time be a long integer seconds since an epoch.  He would
send two such

long integers.  I propose it be an ISO 8601 time string.
Specifically, I

would propose an ISO 8601 interval limited to start/end,
e.g.

On 8/16/12 6:45 PM, "[email-masked]"
<[email-masked]>

>From: [email-masked]
[mailto:[email-masked]]
On Behalf Of

>>1) a time by which the database should be
queried again (which could

>>represent the next change in schedule)

>>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

>>channel identifier might be the most accurate
and neutral "label".

>>spectrum-availability schedule and maximum power
levels for each

>>frequency range."

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

paws mailing list

[email-masked]

--

-vince

---

From: Peter Stanforth <[email-masked]>
Date: Mon, 20 Aug 2012 12:59:21 -0400

Ben,
FCC rules do assume that a channel assignment if from now until some time
in the future, the current default is 24 hours - unless the device moves.
It is same to assume that the duration will become much shorter
eventually. So "Valid until" is a reasonable proposition.  However the FCC
does not preclude a radio from getting a channel list in advance. In many
ways it makes more sense for a device to ask for a new channel list before
it's current list expires so start time might be relevant in this case.

I don't think the FCC was proposing a "predictive guess". The actual FCC
rule is that a channel list is valid for 24hours, but if a device cannot
contact a database at that time it has permission to keep using the
channel list for a further 24hours (48hours total) I don't think this is a
good idea as it precludes a broadcaster reserving channels inside that
window, and, as mentioned above there is some discussion about making the
window much shorter to accommodate situations where broadcasters cannot
plan 24, or worst case 48 hours, in advance. Personally I prefer that the
device get a channel list that is good for some period, without any ifs
buts or maybes, and then it has to query again. This is much simpler than
trying to map matrices of start/stop times for various channels (maybe
with variable power limits) over an extended period.
Peter S.

On MonAug/20/12 Mon Aug 20, 11:15 AM, "Benjamin A. Rolfe"
<[email-masked]> wrote:

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

---

From: Don Joslyn <[email-masked]>
Date: Mon, 20 Aug 2012 13:14:09 -0400

I agree with Brian's suggestion to use ISO 8601 interval format. This plain text representation makes it easier to debug messages, and it includes timezone information.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rosen, Brian
Sent: Friday, August 17, 2012 9:09 AM
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [paws] use cases and requirements document

Uh, the difference is representation of start/stop times.  We both propose to send start/stop times.  Vincent proposes that the representation of time be a long integer seconds since an epoch.  He would send two such long integers.  I propose it be an ISO 8601 time string.  Specifically, I would propose an ISO 8601 interval limited to start/end, e.g.
2011-03-01T13:00:00Z/2012-05-11T15:30:00Z.

On 8/16/12 6:45 PM, "[email-masked]" <[email-masked]> wrote:

>Given that we have completed two Working Group Last Call cycles and 
>this next version will go to the IESG, I hope we could agree on minimal 
>>simple editorial change like this is simple, and it's much better to 
>>do it now.
>>
>>The data model must support specifying spectrum availability.  
>>Spectrum units are specified by low and high frequencies and may have 
>>an optional channel identifier.
>>
>>the complete list so far:
>>
>>
>>
>>corresponds to the "shortest available".  The word "schedule" should 
>>be sufficient to capture this intent?
>>
>>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.²
>>    
>>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.
>>
>>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.
>>
>>http://www.ietf.org/id/draft-ietf-paws-problem-stmt-usecases-rqmts-06.
>>t xt,  to make channel numbers optional to be supported. Ie, change 
>>the current
>>D.7

---

From: "Benjamin A. Rolfe" <[email-masked]>
Date: Mon, 20 Aug 2012 12:55:02 -0700

Peter makes a good point. The rules will allow a device to use channel
availability data for as much as 48 hours - it allows that the device
must access the database at least once per day, but if it tries and
fails it can use the data until 11:59pm of the follow day.

That wasn't the 48 hours I was thinking about though, I was thinking
about the paragraph before that:
§ 15.711 (b)(3)(i)
... Fixed TVBD must adjust their use of channels in accordance with
channel availability schedule information provided by their database for
the 48-hour period beginning at the time of the device last accessed the
database for a list of available channels.

So in addition to providing what is available now, plus how things are
expected to change over the next 48 hour period. I shouldn't have said
"guess" since the requirements for notice from the priority users are
greater than 48 hours.

Having now discussed it "out loud" so to speak, it really does not need
to be two distinct notions. The The "start/end" on a per channel basis
provides what you need; and the database has to provide a schedule at
the time of request that shows everything from now until now + 48 hours.

I also agree enthusiastically with Peter that we should expect changes
in the requirements (and that is a guess, but an educated one ;-).

Ben

>>>> this
>>>>> do
>>>>> Spectrum
>>>>> information
>>>>> interoperability

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 20 Aug 2012 16:11:18 -0400

<as individual>
I think you get a set of start/stop times for a given spectrum unit.  That's all you need.

There is a tradeoff in the complexity of a schedule received and how often you have to come back to the database.  The US rules provide one set of tradeoffs.  It's not clear to be they are great, but they are what they are.

Imagine a device surrounded by lots of temporary use wireless microphones.  The U.S. rules may result in a response of dozens of schedule items, as the use comes and goes on multiple channels.  It could theoretically be huge - hundreds if not thousands of schedule items.  While I doubt this would happen very often, I think it will be very difficult to put any kind of upper bound on the number of schedule items (spectrum unit, start and stop times) a device may have to contend with.

That makes for a complex implementation.  We are no doubt stuck with it in terms of what the protocol must be able to do.

A better design would limit the number of schedule items to either a fixed limit, or some limit expressed by the client.  The client would then have to get back to the database sooner, to get more schedule.

It may be that clients prefer to do that (that is, limit schedule in exchange for shorter time to requery).  That would not violate rules as long as the device didn't use channels for which it did not have accurate schedule.

I think there might be a requirement there: the ability to limit the number of schedule items returned, as well as a requirement to return when the returned schedule ends (i.e. when the database must be required to get more schedule).

Brian

---

From: "Benjamin A. Rolfe" <[email-masked]>
Date: Mon, 20 Aug 2012 17:10:50 -0700

I agree there is a requirement there. I also agree that the US rules are
... what they are (and the rest :-).

I think the wireless microphone example is an interesting situation. The
scenario with a lot of microphones is likely at a large event. My
understanding is that microphones are narrow band device, with a lot of
sub-channels in a single TV channel (makes sense - can do a lot of audio
channels in 6 MHz0). I'm still fuzzy on the granularity of the database
information - what I have seen just gives the availability in TV channel
resolution, in which case a lot of microphones might translate into a
couple TV channels. But like I said, I'm not at all sure, can someone
elaborate?

Thanks

---

From: <[email-masked]>
Date: Tue, 21 Aug 2012 04:26:13 +0000

Let's conclude this topic with agreeing on using start/stop times for each spectrum unit available in ISO8601 format.
I'll ask the editor to implement the two points we agreed on, namely:

Requirement to identify the spectrum, by using the start/stop frequencies, with optional channel identifiers; and
Requirement to use start/stop times for each spectrum unit available in ISO8601 format

and submit a new version of the use cases and requirements I-D, which the chairs will send to the iesg.

- Gabor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Rosen, Brian
Sent: Monday, August 20, 2012 1:11 PM
To: Benjamin A. Rolfe
Cc: [email-masked]
Subject: Re: [paws] use cases and requirements document

<as individual>

Brian

On Aug 20, 2012, at 3:55 PM, Benjamin A. Rolfe <[email-masked]> wrote:

> channel availability schedule information provided by their database 
> for the 48-hour period beginning at the time of the device last 
> accessed the database for a list of available channels.
>
> Having now discussed it "out loud" so to speak, it really does not 
> need to be two distinct notions. The The "start/end" on a per channel 
> basis provides what you need; and the database has to provide a 
> schedule at the time of request that shows everything from now until now + 48 hours.
>
>> FCC rules do assume that a channel assignment if from now until some 
>> time in the future, the current default is 24 hours - unless the device moves.
>> eventually. So "Valid until" is a reasonable proposition.  However 
>> the FCC does not preclude a radio from getting a channel list in 
>> advance. In many ways it makes more sense for a device to ask for a 
>> new channel list before it's current list expires so start time might be relevant in this case.
>>
>> I don't think the FCC was proposing a "predictive guess". The actual 
>> FCC rule is that a channel list is valid for 24hours, but if a device 
>> cannot contact a database at that time it has permission to keep 
>> using the channel list for a further 24hours (48hours total) I don't 
>> think this is a good idea as it precludes a broadcaster reserving 
>> channels inside that window, and, as mentioned above there is some 
>> discussion about making the window much shorter to accommodate 
>> situations where broadcasters cannot plan 24, or worst case 48 hours, 
>> in advance. Personally I prefer that the device get a channel list 
>> that is good for some period, without any ifs buts or maybes, and 
>> then it has to query again. This is much simpler than trying to map 
>> matrices of start/stop times for various channels (maybe with variable power limits) over an extended period.
>> Peter S.
>>
>>> There are also two notions of what "schedule" means, at least in the 
>>> FCC rules. There is the notion that the current channel availability 
>>> data has a expiration time, and thus there is a time in the future 
>>> when updating will be necessary. This is at most a day. Based on FCC 
>>> rules, this could be a local time determined by the device using the 
>>> channel data, and if that device is acting as a source for dependent 
>>> device "using" includes providing it to other dependent devices (and 
>>> it would have to provide the "valid until" time). I can imagine that 
>>> other regulatory bodies (and perhaps the FCC in the future) will 
>>> require that channel availability data provided by the data base 
>>> also be tagged with the "valid until" information. This does not 
>>> require a start time, as "now" is implied.
>>>
>>> predictive guess as to what channels will be available for the next 
>>> 48 hours into the future. This is required by FCC (though the device 
>>> must still check at least once a day if what it is using is still 
>>> valid). A start/stop pair is required for this.
>>>
>>> I think either format can be used to represent time in both cases. 
>>> It is also possible that the 48-hour schedule is all that PAWS needs 
>>> to provide to meet the regulations and the "valid until" can be 
>>> derived from that by the using device.
>>> Hope that helps.
>>> -Ben
>>>
>>>> Uh, the difference is representation of start/stop times.  We both 
>>>> propose to send start/stop times.  Vincent proposes that the 
>>>> representation of time be a long integer seconds since an epoch.  
>>>> He would send two such long integers.  I propose it be an ISO 8601 
>>>> time string.  Specifically, I would propose an ISO 8601 interval 
>>>> limited to start/end, e.g.
>>>>> spectrum, by using the start/stop frequencies, with optional 
>>>>> channel identifiers.
>>>>>
>>>>> proposing the use of start/stop times for each spectrum unit 
>>>>> available, and one from Vincent proposing to use of Unix Epoch 
>>>>> time in seconds. We need to decide on this, so please send your 
>>>>> preference on this topic to the list.
>>>>>
>>>>> - Gabor
>>>>>
>>>>> From: [email-masked] [mailto:[email-masked]] On 
>>>>> Behalf Of Probasco Scott (Nokia-CIC/Dallas)
>>>>> Given that we have completed two Working Group Last Call cycles 
>>>>> and this next version will go to the IESG, I hope we could agree 
>>>>> on minimal changes to the document, i.e. changes only to D.7 for 
>>>>> this topic. This will ensure the proper requirements are 
>>>>> established for the developing PAWS protocol.
>>>>>> I would prefer to not use the word "channel" in our documents at 
>>>>>> all except for the term "channel identifier".  I proposed 
>>>>>> "spectrum unit", although any other term will do.  "Channel" has 
>>>>>> too much baggage,  A simple editorial change like this is simple, 
>>>>>> and it's much better to do it now.
>>>>>>
>>>>>> I think we need power in both the query and the response.  In 
>>>>>> some domains, it may be that you specify what power you want to 
>>>>>> use and the DB tells you what spectrum you can use at that power.  
>>>>>> In other, a US-like rule may be in place.  Also in either the 
>>>>>> query or the registration, we need a device type, which should be 
>>>>>> an entry from an IANA registry.  This is how you get the US "Mode II" information.
>>>>>>
>>>>>> 1) a time by which the database should be queried again (which 
>>>>>> could represent the next change in schedule)
>>>>>> availability query may include a time by which the database must 
>>>>>> be requeried.  Each spectrum unit mentioned in the response may 
>>>>>> be annotated with start and stop time/date.
>>>>>>
>>>>>>
>>>>>>
>>>>>> 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.
>>>>>> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>>
>>>>>> 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
>>>>>>
>>>>>>
>>>>>>               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-rqmt
>>>>>> s-06.t xt,  to make channel numbers optional to be supported. Ie, 
>>>>>> change the current
>>>>>> D.7
>>>>>> 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 
>>>>>> 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: "Stine, John A." <[email-masked]>
Date: Tue, 21 Aug 2012 09:45:23 +0000

Given a start and stop frequency, what are the constraints on the power spectral flux density of out-of-band emissions?  What is the criteria for a start and a stop frequency?

Given start and stop times how would you convey periodic availability?  Being available every day from say 12 to 6 AM may be perfect for a M2M applications, for example meter reading.

John

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, August 21, 2012 12:26 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [paws] use cases and requirements document

- Gabor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Rosen, Brian
Sent: Monday, August 20, 2012 1:11 PM
To: Benjamin A. Rolfe
Cc: [email-masked]
Subject: Re: [paws] use cases and requirements document

<as individual>

Brian

---

From: "Benjamin A. Rolfe" <[email-masked]>
Date: Tue, 21 Aug 2012 08:37:57 -0700

Based on the FCC rules, the isn't a need for "every day at" since the WS 
device must access the database at least once per day (with the 
exception mentioned).  My reading of the OfCom recommendation has 
similar requirements to check with the database and what I have seen 
presented for work by other regulatory domains it will be more 
frequently still.     The transitory protected users (wireless 
microphones) may, though, have a scheduled time of use that may be less 
than a day.  If we specify when the channel IS available, you could see 
the need for multiple times: if there is an event makes the TV channel 
unavailable for 4 hours out of a 24 hour period, the inverse (available) 
would be two blocks around that 4 hour period.  So perhaps for each 
channel we have a spectrum unit definition and a list of available times 
which spans the scheduled period required by the regulatory domain (48 
hours in the US, probably less elsewhere in the future).

For a device that may be active once a day for a period as John 
describes,  it would have to refresh it's channel data at each "wake up" 
if it's been sleeping for a day or more. This is very likely in M2M 
applications.  When we look at this scenario, the assumption we have 
made that the process for acquiring channel availability schedule will 
be "infrequent" becomes false from the perspective of the sleepy device, 
as it will have to be done every time it wakes up.  In some M2M 
applications, it is quite likely that the device may wake up once per 
day, exchange a handful of octets of data, and then resume sleeping.  In 
this scenario the PAWS exchange would be the majority of time on air.    
I don't think this is the dominant use case for PAWS though, and other 
protocols are being developed specifically to address this sort of 
situation effectively (and assume an intermediate device does the 
internet access).

just another two cents worth...

> On Aug 20, 2012, at 3:55 PM, Benjamin A. Rolfe<[email-masked]>  wrote:
>
>>>>> On 8/16/12 6:45 PM, "[email-masked]"<[email-masked]>
>>>>> wrote:
>>>>>
>>>>>> On 8/13/12 8:24 AM, "ext Rosen, Brian"<[email-masked]>  wrote:
>>>>>>
>>>>>>> <as individual>
>>>>>>>        On Aug 10, 2012, at 2:37 AM, Teco Boot<[email-masked]>  wrote:
>>>>>>>
>>>>>>>
>>>>>>>            (somewhat late response)
>>>>>>>
>>>>>>>            Op 9 aug. 2012, om 21:55 heeft<[email-masked]>

---

From: Vincent Chen <[email-masked]>
Date: Fri, 24 Aug 2012 12:50:40 -0700

Although I contributed to the confusion by bring up timestamp format, it
seems the exact format of the timestamp is too detailed for the
Requirements doc. The requirements should just describe capabilities.
Specific encoding/format should be reserved for the Protocol-specification
document.

Taking this into account, the proposed text for D.7 might be:

"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."

The term, schedule, I believe, captures the intent of the various
discussions, e.g., allowing for multiple time-intervals of operation.