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]
*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
_______________________________________________
paws mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/paws
