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) 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. Thanks and regards, Cesar From: [email protected] [mailto:[email protected]] On Behalf Of Vincent Chen Sent: 17 May 2013 03:10 To: [email protected] Cc: [email protected] Subject: Re: [paws] I-D Action: draft-ietf-paws-protocol-04.txt Gabor, There is one more issue that has come to my attention. When the Master Device is requesting the available spectrum on behalf of a Slave Device, the request message should have an optional field for identifying the Master Device (in addition to the one that already identifies the Slave Device). This should be a simple addition. -vince On Thu, May 16, 2013 at 2:35 PM, <[email protected]<mailto:[email protected]>> wrote: Vince, What are the remaining open issues in this latest draft, you or any of the co-authors are aware of? Since there has been not much feedback, if you think there aren't open issues left, we could issue a working group last call. - gabor From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of ext Vincent Chen Sent: Tuesday, May 07, 2013 10:02 PM To: [email protected]<mailto:[email protected]> Subject: Re: [paws] I-D Action: draft-ietf-paws-protocol-04.txt All, I have uploaded a new version that incorporates the items discussed at the previous F2F and on the list. Diff: http://www.ietf.org/rfcdiff?url1=draft-ietf-paws-protocol-03&difftype=--html&submit=Go%21&url2=draft-ietf-paws-protocol-04 Summary of changes: o Expanded the Database Discovery mechanism to describe in more detail pre-configuration with URIs of databases and database- listing services, including mechanisms for updating the configurations when things change * Add database-change field to Available Spectrum Response (Section 4.4.2) o Added fields that are anticipated to be needed by the ETSI harmonized standard for White Space Devices: * Added bandwidth constraints to the Available Spectrum Response (Section 4.4.2) * Updated Available Spectrum Response to return RulesetInfo, rather than just a rule-set identifier * Added optional device-manufacturer and device-model IDs to the DeviceDescriptor (Section 5.2). message. Also moved fccId from this message to the IANA section. * Expanded IANA (Section 9) sections o Clarified restrictions on the specification of the vertices of a Polygon. o Changed default confidence level to 95% for a point with uncertainty o Clarified how devices without absolute time source can use the timestamps in the response messages o Change method names to start with "spectrum.paws." prefix o Added maximum string lengths o Updated author contact info o More typo fixes There are still some TBDs associated with the ETSI additions, but otherwise has addressed all our prior open issues. -vince On Tue, May 7, 2013 at 9:56 PM, <[email protected]<mailto:[email protected]>> wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Protocol to Access WS database Working Group of the IETF. Title : Protocol to Access Spectrum Database Author(s) : Vincent Chen Subir Das Lei Zhu John Malyar Peter J. McCann Filename : draft-ietf-paws-protocol-04.txt Pages : 88 Date : 2013-05-07 Abstract: Portions of the radio spectrum that are allocated to licensees are available for non-interfering use. This available spectrum is called "White Space." Allowing secondary users access to available spectrum "unlocks" existing spectrum to maximize its utilization and to provide opportunities for innovation, resulting in greater overall spectrum utilization. One approach to manage spectrum sharing uses databases to report spectrum availability to devices. To achieve interoperability among multiple devices and databases, a standardized protocol must be defined and implemented. This document defines such a protocol, the "Protocol to Access White Space database" (PAWS). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-paws-protocol There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-paws-protocol-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-paws-protocol-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ paws mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/paws -- -vince -- -vince ________________________________ ****************************************************************************************************************** For more information visit www.ofcom.org.uk This email (and any attachments) is confidential and intended for the use of the addressee only. If you have received this email in error please notify the originator of the message and delete it from your system. This email has been scanned for viruses. However, you open any attachments at your own risk. Any views expressed in this message are those of the individual sender and do not represent the views or opinions of Ofcom unless expressly stated otherwise. ******************************************************************************************************************
_______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
