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 > <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 > > On Aug 20, 2012, at 3:55 PM, Benjamin A. Rolfe <[email protected]> wrote: > >> 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 >> >>> 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 protected]> wrote: >>> >>>> 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 >>>> >>>>> 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 protected]" <[email protected]> >>>>> 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 >>>>>> >>>>>> -----Original Message----- >>>>>> From: [email protected] [mailto:[email protected]] On Behalf Of >>>>>> Probasco Scott (Nokia-CIC/Dallas) >>>>>> Sent: Monday, August 13, 2012 10:12 AM >>>>>> To: [email protected] >>>>>> 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 protected]> 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. >>>>>>> >>>>>>> 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 protected]] >>>>>>> Sent: Saturday, August 11, 2012 11:43 AM Eastern Standard Time >>>>>>> To: Teco Boot >>>>>>> Cc: Rosen, Brian; [email protected] >>>>>>> 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 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]> >>>>>>> <[email protected]> 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.t >>>>>>> xt, 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] >>>>>>> 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 >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> paws mailing list >>>>>>> [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 >>>>> _______________________________________________ >>>>> paws mailing list >>>>> [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 _______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
