I wrote previously about the goodness of dividing data models into at least two halves, the data that describes the spectrum use and the data that is necessary for the business processes of resolving what spectrum a device may use. On further thought, I believe we should divide the data into three parts, the data required for messaging and trust, the particular administrative data required by a regulatory domain, and the data defining the spectrum. The purpose of separating these data models is to allow growth of the whitespace concept.
The motivation for separating out the messaging data is to allow the messaging data to be very broadly applied to all types of whitespace management for all regulatory domains. This part of the standard would be expanded as new capabilities are added. The purpose for separating out the administrative data is to allow each regulatory domain to specify and to modify their data requirements without having international ramifications. We may want this data model to convey particular regulatory requirements obtaining and keeping authorization to use channels. The purpose for separating out the spectrum data is to make it independent of any particular business processes. This is very important for expansion where the spectrum data model is used to trade spectrum, arbitrate coexistence, or give policy to cognitive radios. The spectrum models may be changed in whole based on whether and how spectrum coexistence is managed. Using the requirements sent out earlier this week in http://www.ietf.org/mail-archive/web/paws/current/msg00775.html this is my take on how the requirements would affect the different data models. The data requirements D2, D3, and D4 would be part of the messaging data model. The data requirements D5, D6, and D8 would be part of the administrative data. The data requirements D1, D7, D9, and D10 would be part of the spectrum use model. The data elements implied by the protocol requirements, P1, P2, P3, P4, P5, P6, P7, P8, P9, P11, P15, P16, and P18 would be included in the messaging data model. The data implied by the protocol requirement P12 (less location), P14 (less location), P17, and P19 would be included in the administration data models. The data implied by the protocol requirements p13, P19, and P20 would be included in the spectrum data model. Location would be defined in the spectrum data model. The data implied by the operational requirements O1, O2, O4, O5, and O20, would be part of the messaging data model. The data implied by the operational requirements O6, O7, O10, O11, O12, O13 (the response code), O14, O15, O16, O17, O18 (less location), O19 (less location) and O22 would be part of the administration data model. The data implied by the operational requirements O2, O8, O9, O11, O13 (the channel list) and O21 would be part of the spectrum data model. To clarify the use of three data models I would make changes to the requirements. Data Requirements <Add> "D11: The Data Model MUST be subdivided into three parts, messaging, administration, and spectrum. There shall be one schema for the messaging part. There may be multiple schemas for the administration and spectrum parts differentiated by regulatory domain." I would modify all the data requirements, less D2, D3, and D4, to explicitly state "as required by the regulatory domain." Also some data requirements might be softened and listed as examples, for example in D1, I doubt that the North American Datum of 1983 would be relevant to European administrations. Protocol Requirements In general, I would add to the requirements an explicit mention of the different data schemas and would specify messaging to resolve the schemas that are used. Possibly before P3, I would add the requirement: P.X The protocol MUST support the use of multiple administrative and spectrum data models. And, then extend P.3 as follows: P.3 The protocol MUST support determination of the regulatory domain governing its current location and the administration and spectrum data models that are to be used. Other protocol requirements may be softened to acknowledge that requirements vary by regulatory domain. There would likely be some additional changes in the operational requirements but before I suggest any I would prefer to get some feedback. If this is acceptable, I would be glad to prepare a revised list of requirements with the tweaks to support the separate data models and differentiation by regulatory domain. John Stine _______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
