<As chair>
Discussions of spectrum coexistence is explicitly out of scope, and we have a
big enough job to do without increasing scope.
The scope is also limited to the problem of a device requesting spectrum, and
discussions of provisioning ("releasing new spectrum") is out of scope. Only
the device-to-database query and its response is in scope.
<as individual>
If we ever get to coexistence work, the additional messaging is some form of
<DB to device>"use this explicit spectrum, I'm suggesting that you use it, even
if you could use other spectrum" or <device to db>"of the choices you gave me,
I'll use this part, and please try and keep other users out of my way". Either
is a simple expansion of the basic query (location and band in, spectrum
choices out). As such, I don't think we have to do anything in anticipation of
such a future capability.
I do think the notion of authentication of the device and the database is in
scope, and I certainly think exchange of credentials or equivalent precedes
spectrum query, so I suspect we're separating that part anyway. I certainly
think we're trying to return spectrum choices that depend on location, device
characteristics and things like time of day, and we're trying to design a
protocol that will work for any country that decides to open spectrum for
whitespace use and on any band they decide to do so. So long as we have enough
data elements in the query to allow any of the algorithms that the regulators
decide on to determine the available spectrum from the input query and
provisioning information in the database, as well as have sufficient
flexibility in the response of available spectrum to cover all the limits the
regulators want to have, we should be okay. So far, I don't see any problems
staying within the model we have been talking about.
Brian
On Feb 27, 2012, at 4:13 PM, Stine, John A. wrote:
> From the lack of response to my email last week, I assume folks just don't
> understand why I am recommending the division of the data model. Please let
> me explain in a different way.
>
> Last December, at the SDR Forum, Julius Knapp, the Director of the OET at the
> FCC, hosted a panel attended by five of the ten database administrators. In
> that panel, he asked the panelists what was in it for them. Several
> responded that they hoped they could provide a service to those looking for
> spectrum and to help broker these arrangements.
>
> This is not the model of TVWS. At present, the urgency of the paws effort
> surrounds a narrower goal of enabling TVWS devices to obtain channels they
> can use. I do not want to make any suggestions that would prevent us from
> achieving this goal first. I do want to make an effort to prevent what is
> done from becoming an impediment to a bigger role for whitespace database
> administration in the future, one of managing coexistence and brokering
> spectrum reuse.
>
> In all methods of using a database where a device negotiates with a database,
> the types of messages that will be used are likely to be similar:
> - This is who I am, what rules should I apply in negotiating for spectrum?
> - This is the spectrum I am looking for, what do you have?
> - This is the spectrum that meets your query criteria.
> - etc.
> The methods developed for trust are also reusable. This is the reason for
> having a portion of the data model remain the same for all expansions.
>
> The differences between a TVWS scenario and a brokering scenario are likely
> to be additional messaging and different data, both for the business of
> brokering and for defining the spectrum authorization. For example, in the
> brokering use case there needs to be a spectrum data model that allows a
> primary spectrum user to release spectrum into the market, (e.g., provide
> their contours ) and to specify the terms of use. My concern is that if the
> data model of TVWS comingles the data of messaging, administration, and
> spectrum; that this sort of expansion of paws would require increasing the
> size of the data model and would make expanding its capability more difficult
> both because of the impact of this expansion on legacy uses and because of
> the confusion of using large schemas that have similar but different data
> elements.
>
> My solution is to divide the data model into three parts. The data document
> of messages would use the namespace of three schemas. In the TVWS edition,
> this would also allow different administrative and spectrum schemas for
> different regulatory domains. In end, the data for TVWS management would not
> be any different, it would just be defined in three schemas
>
> In the initial exchanges between a device and a database, there would be
> agreement on which schemas to use. This is equivalent to resolving the
> regulatory domain. The messaging that follows would be the exact same, with
> the exact same data as the messaging if a comingled data model were used.
>
> If the division is done well, then, in the long term, others can create
> schemas for administration and spectrum definition that meets their business
> needs without having to do so through paws. They would be able expand the
> way the paws protocol is used without having to revise paws.
>
> I hope this better explains my intent. It would also be helpful to
> understand why anyone thinks this should not be done.
>
> John
> _______________________________________________
> paws mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/paws
_______________________________________________
paws mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/paws
