-----Original Message----- From: Stine, John A. Sent: Monday, February 27, 2012 5:03 PM To: 'Peter Stanforth' Subject: RE: [paws] Further explanation of partitioned data models
Peter, Thank you for the response. I fully understand the groups intent to get something done right away so that the TVWS market can start moving. I made this suggestion thinking it would be a very mild change not really contributing to a lot of work. I am not advocating adding capabilities outside the scope of this initial effort, just promoting the division of the data model to make later expansion easier. The only additional effort I can think of would be to provide the means within PAWS for a database administrator to specify the particular schemas to use. That is it. Your opinion that the PAWS work would not affect your business model carries a lot of weight. It would be interesting to know the amount of communications you would have with customers that would not involve PAWS at all. Considering your overlay view of building on top of PAWS, if coexistence management were found to be necessary for effective use of whitespace, would your approach allow you to collaborate with the other database administrators for that objective. John -----Original Message----- From: Peter Stanforth [mailto:[email protected]] Sent: Monday, February 27, 2012 4:26 PM To: Stine, John A.; [email protected] Subject: Re: [paws] Further explanation of partitioned data models John, I may be guilty of being one of those panelists you mention, and we also run a secondary marketplace for spectrum, so I speak as someone who has a vested interest in what happens beyond TVWS. I agree with your insight on the potential, both for access to additional spectrum as well as for different business models. I also agree with your summary of the type of negotiation that is likely. Speaking for Spectrum Bridge we can see a way to address those opportunities within the current PAWS construct and don't necessarily need to break anything out. I would want to understand this proposal better as I have two concerns. First it seems difficult to achieve this without significantly complicating the process. Second I am not sure that the result may be worse than where we are today, in that it might confine me to certain modes of operation or not. The only quick, and simple, analogy I can give is Boingo. They have a revenue generating service offered on top of unlicensed WiFi. They do so without any impact on the underlying WiFi MAC/PHY protocols. Our (SBI) concern has been that the PAWS protocol/requirements do not preclude us from being able to offer enhanced and differentiated services and so far we have not been able to identify an issue. I would be happy to continue the discussion in parallel to the initial PAWS effort and would not rule out such a breakup in the future but I think the majority are hoping to get something finished to address TVWS without too much expansion. Regards Peter Stanforth CTO Spectrum Bridge Inc. On MonFeb/27/12 Mon Feb 27, 4:13 PM, "Stine, John A." <[email protected]> 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
