Hi Ben, This is an important point. The protocol has a AVAIL_SPECTRUM_BATCH_REQ query, with which the master can request spectrum by specifying multiple locations, and the response to the request needs to specify the available channels for each location separately. Now, assuming a master wants to operate in an area which covers 1000m. That means that it has to specify ~ (1000/50)^2=400 different locations in the AVAIL_SPECTRUM_BATCH_REQ. Is that feasible? We discussed this issue last year, I was asking the protocol to include a query type which would allow the master to specify a location and a radius of operation, and ask for available spectrum for the specified location, but folks in the meeting argued the master should receive the available spectrum for each location, then figure out itself the channels available for the given area.
-Gabor From: [email protected] [mailto:[email protected]] On Behalf Of ext Benjamin A. Rolfe Sent: Thursday, October 17, 2013 12:47 PM Cc: [email protected] Subject: Re: [paws] Support for including Slave Device location There needs to be a way for a "master" (I truly dislike that term on many levels) to be able to request information for multiple locations on behalf of other devices. This may *not* be a problem with the protocol and may only be a problem of my understanding, but it is *not* safe to assume that all "slave" devices (I dislike 'slave' even more) are within a 50m sphere of the master device geolocation where the channel availability information is valid (per FCC). A very likely use case is there is are internet connected devices at the "edge" of a network (fixed, mains powered) communicating with a number of devices without direct internet connection, or possibly a complete IP stack. Think M2M over low data rate links, with resource constrained nodes operating from batteries and, possibly, moving about. They may be fixed with location per-configured at install or, more likely, using some means of radio location to determine a position relative to the internet-connected peer that can source channel information. The internet-connected edge device may serve as a proxy source of channel availability information. Such a use case is supported by FCC rules, and last time I looked OfCom and elsewhere as well. It may be that the protocol already supports this via multiple requests made by the internet-connected node. In which case I apologize for the diversion. Ben On 10/17/2013 12:28 PM, Vincent Chen wrote: Ben, No. The Database only returns spectrum for the primary device descriptor. The "master device descriptor" is for reference only when the primary device is a slave. I.e., When the Master requests spectrum for itself, it will use the primary device descriptor. -vince On Thu, Oct 17, 2013 at 12:23 PM, Benjamin A. Rolfe <[email protected]<mailto:[email protected]>> wrote: Then the database returns two channel lists, one for each location? It is feasible that they would be different at least by FCC rules. B On 10/17/2013 11:57 AM, Don Joslyn wrote: 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]<mailto:[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]<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
_______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
