Are you now saying that the charter text is wrong because regulators will require that there should always be a prior relationship between a master device and the database it can query for channel availability? Even if that's the case with FCC, the question is if this view is shared by other regulators or not. In FCC case, the device will simply not need to make use of discovery, as it knows the db. When we wrote the paws charter, we targeted a global scope, not FCC specific one. Having the discovery in the charter does not mean that we have to have discovery defined as part of the document dealing with the protocol, it could be a separate document, if the wg wishes so. It certainly does not mean that we are *not* done with the ws protocol itself until the discovery part is not finalized; we can certainly cut the apple in smaller pieces if needed. And I think this discussion should be preceded by individual submissions which the wg can adopt as wg document(s).
- Gabor From: ext Peter Stanforth [mailto:[email protected]] Sent: Sunday, April 22, 2012 6:18 PM To: Bajko Gabor (Nokia-CIC/SiliconValley); [email protected] Subject: Re: [paws] Database Discovery Question If you are going to quote the charter get it right (See below). At best task1 and objective 1 are ambiguous, at worst the objective won't address the task. But more to the point, it baffles me that PAWS is perfectly willing to update it's charter on a suggested rule (Ofcom consultation proposing a channel use report) yet not even discuss a violation of the only implemented rules out there (FCC radio certification process does not allow for a database discovery process). Let me be very clear, Spectrum Bridge supports, and desires to have, channel use feedback and database discovery mechanisms. I believe our experience in deploying white space networks, various white space databases and multiple radio/database protocols gives us the credibility to say these two topics raise the complexity of the PAWS task by an order of magnitude. All Don was asking, on our behalf, was that PAWS take a bite out of the apple we can swallow quickly and not a bite that is so big it chokes us to death. I don't think that is unreasonable. .....complete the following tasks: 1. Determine the relevant white space database to query. 2. Connect to the database using a well-defined communication method. 3. Provide its geolocation and perhaps other data to the database using a well-defined format for querying the database. 4. Receive in return a list of available white space spectrum with their characteristics, using a well-defined format for returning information. 5. Report to the white space database spectrum usage at a suitable granularity. Once the device learns of the available white space (e.g., in a TV white space implementation, the list of available channels at that location), it can then select one of the bands from the list and begin to transmit and receive on the selected band. If the device's parameters have changed (e.g., if some amount of time has passed or if the device has changed location beyond a specified threshold), it might need to query the database again to determine what white space is still available. Objectives The overall goals of this working group are to: 1. Standardize a mechanism for discovering a white space database. 2. Standardize a method for communicating with a white space database. 3. Standardize the data formats to be carried over the defined database communication method. 4. Ensure that the discovery mechanism, database access method, and query/response formats have appropriate security levels in place. From: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> To: Don Joslyn <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [paws] Database Discovery Question Don, As chair, I'll have to ask you to stop arguing against a database discovery protocol. That is clearly within the scope for the wg, as the charter says: "Objectives The overall goals of this working group are to: 1. Standardize a mechanism for discovering a white space database." and it doesn't mention the optionality. ietf is contribution driven, if you are not interested in the discovery, then you do not need to contribute to it. But do not try to persuade the wg to not work on a piece which is in charter and folks are willing to do; that is not how ietf works. - Gabor From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of ext Don Joslyn Sent: Friday, April 20, 2012 12:21 PM To: Paul Lambert; Das, Subir; [email protected]<mailto:[email protected]> Subject: Re: [paws] Database Discovery Question See reply below. Don From: Paul Lambert [mailto:[email protected]]<mailto:[mailto:[email protected]]> Sent: Thursday, April 19, 2012 2:36 PM To: Don Joslyn; Das, Subir; [email protected]<mailto:[email protected]> Subject: RE: [paws] Database Discovery Question Paul A. Lambert | Marvell | +1-650-787-9141 From:[email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Don Joslyn Sent: Thursday, April 19, 2012 10:31 AM To: Das, Subir; [email protected]<mailto:[email protected]> Subject: Re: [paws] Database Discovery Question I don't think PAWS should define discovery, I think the protocol should simply start after a device has "found" the correct database to use. I feel this way for many reasons: 1) In the US, a radio is certified to work with one or more specific databases. So the device will be pre-configured to contact specific databases, no need to implement a discovery service. If the device is programmed to work with more than one database provider, the device owner will configure which one to use based on the relationship that they have established with the database provider (for example, which one they are paying to use). When new databases come online, users would likely appreciate an option to connect to a system additional services or perhaps lower prices for the service. [Don - Yes, this may be desired, but can the device immediately take advantage of these new database records and decide on its own to use a new one that has a lower cost? I would think that the device owner still needs to decide to use the lower cost service (may even have to consider why it costs less), pay for the service, and then configure the device to use it. I'm not sure how this can automatically happen between the discovery service and WSD. Will cost considerations be part of the discovery solution? Is it cost per month, year, lifetime, message count, etc? You mentioned cost, but there can be many other parameters that can influence the selection outcome (SLA, features, etc.), where will we stop?] If we go strictly on the preconfiguration model ... we don't even need PAWS. The relationship you describe would have defined all the interfaces. If we are in the business of having open interfaces, we need to provide a means to discocovery and select DBs. [Don - I don't agree with the all-or-nothing argument, using discovery is optional (per PAWS requirements). Establishing a standard protocol between WSDB and WSD is still valuable because, for example, will can still lower the cost to device manufacturers because they will only need to implement code for a single standard defined interface.] Paul 2) Discovery services like LoST are based on location, but the device's relationship with a database service is not known or considered. While it may seem simple to configure LoST or similar service to point to a database service based on location, how do you point to the one that the customer has a relationship with, for example, paid to use? I do realize that this may not be an issue in every country. 3) If PAWS defines a globally applicable discovery process and either picks an existing protocol (like LoST) or designs one, most likely it would include a centrally based discovery service. What entity will be responsible for hosting and configuring the central discovery service? How will PAWS define this as a global solution, and deal with the politics between countries? 4) Some radio manufacturers do not have very much ROM to include even more code on their device. I'm concerned that discovery will consume even more space on the radio, space that they may not even have. 5) I believe that defining discovery will take more time than defining the protocol between the WSDB and WSD. I think that database discovery should be left to each country to define based on their own requirements and Whitespace ecosystem. Regards, Don From:[email protected]<mailto:[email protected]> [mailto:[email protected]]On Behalf Of Das, Subir Sent: Tuesday, April 17, 2012 5:26 PM To: [email protected]<mailto:[email protected]> Subject: [paws] Database Discovery Question During PAWS session in Paris IETF, there were a lot of questions/discussions on 'Discovery' of Database. It was not clear to me except if we are talking about "Database Server Discovery", in particular, the domain name or the IP address of the 'Server" that is hosting the database. OTH, I felt that some folks may have different views and they would possibly like to see more features than just discovering the domain name or IP address of the "Database Server". In some offline discussions, I was told that it may be similar to what LOST (RFC 5222) has defined. I read the LOST protocol and associated architecture and my current understanding is that the LOST use case is different than what we are trying to achieve via PAWS. Here is my understanding of the operating model of PAWS interface (when defined): -"Fixed/Mode II WSD" (per figure 1,<draft-das-paws-protocol-01>) can only query the database -The manufacturer of the "Fixed/Mode II WSD" may be different than owner/operator of this device -"Fixed/Mode II WSD" is certified by the regulatory body of the region that they serve - Either the "Fixed/Mode II WSD" device operator or the device vendor has an a-priori relationship with one or more covering database administrators. This relationship is utilized to either configure or enable the discovery of the proper database to contact in the current location I would like to know the group's view of the above model. To me, finding the emergency services or restaurant information near my location is different than getting to know a server that can provide me with channel/frequency/power and other information in the location where "Fixed/Mode II WSD" is situated. In addition, emergency services do not require a subscription and the service is mandated by the Government/regulatory bodies. Some may argue that 'White Space' service may be free as well, but to my understanding it is not quite the similar model as emergency services. I hope with this thread we can clarify/understand the discovery issue. Regards, _Subir
_______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
