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 -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Peter Stanforth Sent: Thursday, August 09, 2012 6:38 PM To: Rosen, Brian; Peter McCann Cc: [email protected] 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 protected]> wrote: ><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 protected]> wrote: > >> I think "MAY include channel numbers" is somewhat ambiguous. I would >> prefer "MAY support specification of this information by channel >>number". >> >> -Pete >> >> [email protected] 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 >> >> >> >> _______________________________________________ >> 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
