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...
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 protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: Tuesday, August 21, 2012 12:26 AM To: [email protected]; [email protected] Cc: [email protected] Subject: Re: [paws] use cases and requirements document 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 protected] [mailto:[email protected]] On Behalf Of ext Rosen, Brian Sent: Monday, August 20, 2012 1:11 PM To: Benjamin A. Rolfe Cc: [email protected] Subject: Re: [paws] use cases and requirements document <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 ;-). BenBen, 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. -BenUh, 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-rqmt s-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 _______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
_______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
