I guess I think we would extend the query to: Request (with device parameters) Response (with available spectrum) Acknowledge (with chosen spectrum)
It then completely fits in the definition. I don't think the extra message is anything particularly special, and a 3 way is a common transaction sequence. As I understand the Ofcom rules, it's purely informational. Someone can correct me if I am wrong. They want to monitor what is being used. Brian On Mar 7, 2012, at 8:25 PM, Peter Saint-Andre wrote: > <hat type='AD'/> > > On 3/7/12 5:57 PM, Rosen, Brian wrote: >> <as individual> I think that this requirement easily fits in: >> >> In addition, the particular data exchanged between a device and a >> database might depend on the ranges of radio spectrum that are to be >> used, the REQUIREMENTS OF the database operators and their GOVERNING >> REGULATIONS, and other factors. >> >> emphasis added. > > As I understood it, the device would query the database for available > white space, and the database would reply. We thought that the query > would contain at least the device's location: > > 3. Provide its geolocation and perhaps other data to the database > using a well-defined format for querying the database. > > We also envisioned that extension points would be provided in the > protocol so that the "other data" could be provided; the two sentences > in the charter right after the one you just quoted are: > > Therefore, the database access method and the query/response data > formats that are exchanged using that method need to be designed for > extensibility rather than being tied to any specific spectrum, > country, or phy/mac/air interface. For example, the working group > should define extension points for the database access method and the > query/response formats, so that use cases other than those currently > envisioned can be addressed in the future if a community of interest > wishes to do so. > > Correct me if I'm wrong, but what we're discussing here is not a new > field in the database query -- it is a reporting mechanism. I would be > more comfortable if we said something like "to meet Ofcom requirements, > the database query needs to include [FieldX]". > > The charter does say: > > 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. > > I suppose one could envision the following flow: > > 1. Device queries database. > > 2. Database responds with list of available channels. > > 3. Device queries database again, providing a new parameter: the actual > channel it wants to use (which it can't know until it receives the > original list of channels or tries to do something with the original > list of channels, such as transmit/receive). > > 4. Database responds with updated list of available channels (where the > updated list is based on information the device provided in step 3). > > That's a bit of a strange way to look at it, though. > >> It is data exchanged between the device and the database and It >> doesn't significantly alter the design of the protocol, and >> specifically doesn't tread into areas of concern when the charter was >> written. We didn't have the benefit of the OFCOM rules at the time, >> or we could have explicitly included it. >> >> Again, if the whitespace returned somehow depended on this >> information, then I think we would be out of scope. > > But doesn't it? Or is this reporting purely informational? > >> I defer to your decision, of course. > > I am not a special person to whom one must defer. I'm just a member of > the community who happens to be serving in the AD role for a few years. > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ _______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
