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]>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]] *On Behalf > Of *Vincent Chen > *Sent:* Thursday, October 17, 2013 1:26 PM > *To:* Benjamin A. Rolfe > *Cc:* [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]> > 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]**** > > https://www.ietf.org/mailman/listinfo/paws**** > > ** ** > > > _______________________________________________ > paws mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/paws**** > > > > **** > > ** ** > > -- > -vince **** > -- -vince
_______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
