Gabor, Yes, I am suggesting that you separate the spectrum data model from the business process data model. This loose coupling can be very powerful in the long term. Think of a very simple type of transaction where a device requests spectrum but fails to provide sufficient information in their request. The business process part might allow the WSDB to reply and identify the additional information that is needed. Developing that type of request now with the constraint of separate data models will cause that work to be reusable for whatever expansion or revision occurs to the data models in the future. This might not be the case if you combine data models. You may end up with a lot of separate request for different types of data elements. If you expand or change the spectrum data model, you would have to create multiple new messages. This is not so, if the design starts with the two separate data models.
If this is not motivation, you may consider a long term outcome where large users of spectrum, think U.S. Department of Defense, which has its own business process might be willing to relinquish spectrum for reuse if managed by a WSDB system. The DoD does not use its spectrum everywhere in the US. A shared spectrum data model can support this sharing but it is highly unlikely that the WSDB systems and the DoD would share the same business process. Yes, P2 could be expanded for this purpose. Here is a suggestion. The protocol MUST support regulatory domain discovery and in that discovery agreement on the spectrum data model to be used. In the near term there may only be different data models between regulatory domains but in the long term I could see even regulatory domains having multiple data models as new ways of sharing are defined. John -----Original Message----- From: [email protected] [mailto:[email protected]] Sent: Tuesday, February 07, 2012 4:49 PM To: Stine, John A.; [email protected] Subject: RE: Separating business process data from spectrum use data 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
