Yes, that makes sense to me. From: Vincent Chen [mailto:[email protected]] Sent: Thursday, October 17, 2013 2:53 PM To: Don Joslyn Cc: [email protected] Subject: Re: [paws] Support for including Slave Device location
I think, for consistency, the SPECTRUM_USE_NOTIFY should also have a "slave location". In other words: - Whether or not the slave has geo-location capability, "location" continues to be the Master device location - For Slaves that have geo-location capability, the "slave location" would be included Does that make sense? -vince On Thu, Oct 17, 2013 at 10:50 AM, Don Joslyn <[email protected]<mailto:[email protected]>> wrote: Thanks Vince, In addition, It's my current understanding that Ofcom requires slave devices to report "Channel Usage". In PAWS it would be accomplished via master device sending a SPECTRUM_USE_NOTIFY on behalf of the slave device. We might need to add slave device location to that message, or indicate that the location parameter contains the slave device's location whenever etsiEnDeviceCategory is equal to "slave". Does that make sense? Don From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Vincent Chen Sent: Thursday, October 17, 2013 1:26 PM To: Benjamin A. Rolfe Cc: [email protected]<mailto:[email protected]> Subject: Re: [paws] Support for including Slave Device location Thanks Don, The in-progress draft has already changed the definition of "Slave" to match that in the use-case RFC, which does not reference geo-location capability. Adding the optional slave location to the AVAIL_SPECTRUM_REQ seems to make sense. Ben. There is already support in PAWS to include both the Slave and Master's device descriptors. -vince On Thu, Oct 17, 2013 at 9:29 AM, Benjamin A. Rolfe <[email protected]<mailto:[email protected]>> wrote: There is a similar requirement, though not as explicitly stated, in the FCC use case. A device not directly connected to the database works through a connected device. For the connected ("master" in OfCom terms) to provide the data to another, it must verify that the other device is authorized. This can be done by having the connected device make a request using the device identification information of the "slave". I realize that I had *assumed* the protocol as drafted supported this, i.e. the device making the request could fill in the ID information of another device in the request. IF this is not true, then the protocol does not support a very likely use case in the US. FWIW. Ben On 10/17/2013 8:34 AM, Don Joslyn wrote: After reviewing several Ofcom TVWS operational requirements documents, it is my current understanding that Ofcom operation in TVWS includes a use case where the slave device's location may be included in the available spectrum request sent via the master device to the database. It appears that the current PAWS protocol specification (version 6) does not support inclusion of the slave device's location as a parameter in requests, and furthermore the PAWS specification assumes by slave definition that slave devices are without geo-location capability. To support Ofcom's use case that includes slave device location, I would like to suggest that we consider adding an optional parameter for "Slave Device Location", and update the slave definition to support slave devices that include geo-location capability. The new "Slave Device Location" parameter could be added directly to the AVAIL_SPECTRUM_REQ message format, or added via another ETSI-specific parameter. Thank you, Don _______________________________________________ paws mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/paws -- -vince -- -vince
_______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
