Cesar, Questions and comment inline.
On Fri, May 17, 2013 at 4:02 AM, Cesar Gutierrez < [email protected]> wrote: > Vince and all, > > > > Another issue that has slipped under the radar. > > > > We have the concept of “Generic operational parameters” in ETSI and the > UK. These are the spectrum use parameters that ANY Slave in the coverage > area of a Master can use. The values of these parameters will be > broadcasted by the Master, and a Slave will normally use them to > “associate” and eventually get “specific operational parameters” which will > be tailored to the Slave precise location and device characteristics. > However, it is possible that some Slaves, for instance cheap devices that > cannot geolocate, will continue using the generic operational parameters in > normal operations (after association) > In the PAWS specification, a "Slave" device is defined to be one that does not have its own geo-location capability. If a device does have geo-location capability, then: - It MAY uses the generic operation parameters to establish access to the database via the Master - It makes its own request (as a Master) to the database, providing its own geo location - It MAY change to the operational parmeters I think that satisfies the requirements. > > To be clear, the Generic operational parameters are used by Slaves, > although the database will calculate these parameters on the basis of > information from the Master. The calculation requires the location of the > Master, and the power levels it uses. With this, the database can 1) > calculate the coverage area of the Master, 2) assume that a Slave might be > in any location within that area, and 3) calculate a set of generic > parameters on that could be used anywhere in the coverage area. Note that > the Master must have requested and obtained operational parameters for > itself before engaging in this. Therefore, the database already knows the > Master’s location and intended power (this through the SPECTRUM_USE_NOTIFY > procedure). > > > > I think that a simple way to implement the request for generic operational > parameters could be to re-use the AVAIL_SPECTRUM_REQ procedure, with the > addition of a flag to indicate to the database that the request is for > generic operational parameters and not for operational parameters for the > Master itself, or for a specific slave. > Sounds reasonable. Some regulatory domains, of course, may not allow this mode. > > > Thanks and regards, > > Cesar > > > > >
_______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
