Hi John, You bring up interesting points in your email below. We had a hum last meeting on whether to extend the scope to include coexistence requirements, and the group preferred not to do that for the time being. But that should not stop us from designing the solution space in an extensible way to avoid redesigning needs once the scope is extended.
We had a presentation last time on the data model structure: http://www.ietf.org/id/draft-caufield-paws-protocol-for-tvws-01.txt, this initial proposal does not seem to separate the data model into what you call spectrum use relevant and business process relevant parts. Are you for the time being suggesting that we group the requirements as spectrum relevant and eg not-spectrum relevant? What comes to your suggestion to add: > P.14 The master device must identify the spectrum data model schema it uses > to convey its operating parameters and to receive channel availability from > the WS Database. If I understand it correctly, you want to identify first what operating parameters need to be sent to the DB. That was the intention of "P.2: The protocol MUST support regulatory domain discovery.", since each regulatory domain has its own mandate of parameter list. Maybe we should expand P.2 to more explicitly state what you are looking for. - Gabor -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of ext Stine, John A. Sent: Tuesday, February 07, 2012 6:11 AM To: [email protected] Subject: [paws] Separating business process data from spectrum use data I fully understand the intent to limit the scope in this iteration of the paws standard to the items listed in paragraph 1.2.1 but I also believe it is important to look forward and consider what we would like the whitespace database to become and to ensure that anything that is done in this first iteration does not become a hurdle to overcome in the future. The future database roles that I think should be considered are: 1. Spectrum from licensed users can be added to databases allowing their spectrum to be used or reused in some way 2. Database administrators arbitrate coexistence 3. Database managers can convey policy to DSA systems that allow spectrum use based on a radio using a particular behavior. I do not believe consideration of these activities would have an effect on the types of processes and messaging that the current scope prescribes but it could have a very big impact on the data model. I recommend that the business process schemas be kept separate from the spectrum data model schemas and that the standard be written so that spectrum data modeling schemas can be interchanged. The motivation for this separation is three-fold: 1. It allows other enterprises to use their own management methods but to share data models making it easier for them to make their spectrum available. 2. It allows spectrum data models tuned for particular administration regulatory requirements 3. It allows evolution of the data models to support more dynamic and interactive spectrum management without demanding confusing upgrades to schemas that attempt to be backwards compatible. (Backwards compatibility is achieved at the databases that can understand multiple data model schemas. We may want to add messaging that allows devices and databases to agree upon a schema.) Potential changes that may enable this perspective could be to divide the data model into two parts. The first part would include the information necessary for the business process, so D.2 and D.3, and the second part would be data elements that provide the information relevant to spectrum use. In the current data model requirements, this is everything else. The output of this initial standards work would be a paws protocol for the interactions between WS devices and the WS database and a separate standard for a data model that it uses for defining spectrum. I would then add the following to the protocol requirements: P.14 The master device must identify the spectrum data model schema it uses to convey its operating parameters and to receive channel availability from the WS Database. There are likely multiple changes required throughout the document but wanted to instigate a discussion before I try to suggest what they might be. John A. Stine Chief Technology Advisor Operations Research and Systems Analysis The MITRE Corporation email: [email protected], Phone:703-983-6281 _______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
