Subject: [paws] Support for including Slave Device location

From: Don Joslyn <[email-masked]>
Date: Thu, 17 Oct 2013 11:34:14 -0400

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

---

From: "Benjamin A. Rolfe" <[email-masked]>
Date: Thu, 17 Oct 2013 09:29:32 -0700

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-masked]
> https://www.ietf.org/mailman/listinfo/paws

---

From: Vincent Chen <[email-masked]>
Date: Thu, 17 Oct 2013 10:26:01 -0700

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-masked]>wrote:

> 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
>
>
>
> 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 [email-masked]://www.ietf.org/mailman/listinfo/paws
>
>
>

-- 
-vince

---

From: Don Joslyn <[email-masked]>
Date: Thu, 17 Oct 2013 13:50:00 -0400

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-masked] [mailto:[email-masked]] On Behalf Of Vincent Chen
Sent: Thursday, October 17, 2013 1:26 PM
To: Benjamin A. Rolfe
Cc: [email-masked]
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-masked]<mailto:[email-masked]>> 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

Thank you,
Don

paws mailing list

[email-masked]<mailto:[email-masked]>

_______________________________________________
paws mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/paws

--
-vince

---

From: Vincent Chen <[email-masked]>
Date: Thu, 17 Oct 2013 11:53:06 -0700

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-masked]>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-masked] [mailto:[email-masked]] *On Behalf
> Of *Vincent Chen
> *Sent:* Thursday, October 17, 2013 1:26 PM
> *To:* Benjamin A. Rolfe
> *Cc:* [email-masked]
> *Subject:* Re: [paws] Support for including Slave Device location****
>
> ** **
>
> Thanks Don,****
>
> ** **
>
> capability.****
> sense.****
> Master's device descriptors.****
>
> ** **
>
> -vince****
>
> ** **
>
> ** **
>
> ** **
>
> On Thu, Oct 17, 2013 at 9:29 AM, Benjamin A. Rolfe <[email-masked]>
> wrote:****
>
> 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
>  ****
>  ****
> _______________________________________________****
>
> paws mailing list****
>
> [email-masked]****
>
> https://www.ietf.org/mailman/listinfo/paws****
>
> ** **
>
>
> https://www.ietf.org/mailman/listinfo/paws****
>
>
>
> ****
>
> ** **
>
> --
> -vince ****
>

-- 
-vince

---

From: Don Joslyn <[email-masked]>
Date: Thu, 17 Oct 2013 14:57:37 -0400

Yes, that makes sense to me.

From: Vincent Chen [mailto:[email-masked]]
Sent: Thursday, October 17, 2013 2:53 PM
To: Don Joslyn
Cc: [email-masked]
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-masked]<mailto:[email-masked]>> wrote:
Thanks Vince,

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Vincent Chen
Sent: Thursday, October 17, 2013 1:26 PM
To: Benjamin A. Rolfe
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [paws] Support for including Slave Device location

Thanks Don,

-vince

FWIW.
Ben

Thank you,
Don

paws mailing list

--
-vince

--
-vince

---

From: "Benjamin A. Rolfe" <[email-masked]>
Date: Thu, 17 Oct 2013 12:23:53 -0700

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:
> *From:*Vincent Chen [mailto:[email-masked]]
> *Sent:* Thursday, October 17, 2013 2:53 PM
> *To:* Don Joslyn
> *Cc:* [email-masked]
> *Subject:* Re: [paws] Support for including Slave Device location
>
> On Thu, Oct 17, 2013 at 10:50 AM, Don Joslyn 
> <[email-masked] <mailto:[email-masked]>> 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-masked] <mailto:[email-masked]> 
> [mailto:[email-masked] <mailto:[email-masked]>] *On 
> Behalf Of *Vincent Chen
> *Cc:* [email-masked] <mailto:[email-masked]>
> *Subject:* Re: [paws] Support for including Slave Device location
>
> Thanks Don,
>
> 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
>
>     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.
>
>     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
>
>       
>
>     [email-masked]  <mailto:[email-masked]>
>
> [email-masked] <mailto:[email-masked]>

---

From: Vincent Chen <[email-masked]>
Date: Thu, 17 Oct 2013 12:28:05 -0700

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-masked]>wrote:

>  Yes, that makes sense to me.****
>
> ** **
>
> *From:* Vincent Chen [mailto:[email-masked] <[email-masked]>]
> I think, for consistency, the SPECTRUM_USE_NOTIFY should also have a
> "slave location".****
>
> ** **
>
> In other words:****
>
> 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-masked]>
> wrote:****
>
> Thanks Vince,****
>
>  ****
>

-- 
-vince

---

From: "Benjamin A. Rolfe" <[email-masked]>
Date: Thu, 17 Oct 2013 12:46:44 -0700

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:
> 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-masked] <mailto:[email-masked]>> wrote:
>
>>      - Whether or not the slave has geo-location capability,
>>     "location" continues to be the Master device location
>>
>>     <[email-masked]
>>     <mailto:[email-masked]>> 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
>>
>>     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.
>>
>>     On Thu, Oct 17, 2013 at 9:29 AM, Benjamin A. Rolfe
>>     <[email-masked] <mailto:[email-masked]>> 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
>>
>>         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
>>         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
>>
>>           
>>

---

From: <[email-masked]>
Date: Thu, 17 Oct 2013 22:13:32 +0000

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-masked] [mailto:[email-masked]] On Behalf Of ext Benjamin A. Rolfe
Sent: Thursday, October 17, 2013 12:47 PM
Cc: [email-masked]
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

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-masked]<mailto:[email-masked]>> 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

In other words:

Does that make sense?

-vince

Thanks Don,

-vince

FWIW.
Ben

Thank you,
Don

paws mailing list

--
-vince

--
-vince

paws mailing list

--
-vince

---

From: Peter Stanforth <[email-masked]>
Date: Thu, 17 Oct 2013 19:12:43 -0400

Gabor,
One reason we chose the method we did was because we discussed examples like trains and ferries that would not need an area but a vector. The approach we have allows for various topologies to be accommodated.
Peter S.

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Thursday, October 17, 2013 6:13 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [paws] Support for including Slave Device location

Hi Ben,

-Gabor

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of ext Benjamin A. Rolfe
Sent: Thursday, October 17, 2013 12:47 PM
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [paws] Support for including Slave Device location

Ben

-vince

In other words:

Does that make sense?

-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-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Vincent Chen
Sent: Thursday, October 17, 2013 1:26 PM
To: Benjamin A. Rolfe
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [paws] Support for including Slave Device location

Thanks Don,

-vince

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

--
-vince

--
-vince

paws mailing list

--
-vince

---

From: Ray Bellis <[email-masked]>
Date: Fri, 18 Oct 2013 08:10:56 +0000

On 17 Oct 2013, at 18:50, Don Joslyn <[email-masked]<mailto:[email-masked]>> wrote:

Thanks Vince,

"Channel Usage" is only required for slaves operating above 0 dBm EIRP / 8 MHz.

However all masters are required to report "data parameters" (e.g. device identifier, emission class, location [optionally]) for every connected slave.

Ray

---

From: Vincent Chen <[email-masked]>
Date: Fri, 18 Oct 2013 01:34:12 -0700

Ray,

On Fri, Oct 18, 2013 at 1:10 AM, Ray Bellis <[email-masked]>wrote:

>
>  On 17 Oct 2013, at 18:50, Don Joslyn <[email-masked]> wrote:
>
>   Thanks Vince,****
>
>  However all masters are required to report "data parameters" (e.g.
> device identifier, emission class, location [optionally]) for every
> connected slave.
>

Yes, both of these are already supported in the draft.
As Don suggested the optional slave location will be added.

Thanks.

-- 
-vince

---

From: Sungjin Yoo <[email-masked]>
Date: Thu, 24 Oct 2013 10:43:30 +0900

Vince,

I suggest to modify 4.4.1 AVAIL_SPECTRUM_REQ as follows to add slave 
location.

<original>
location: The GeoLocation (Section 5.1) for _the Master Device_ is
REQUIRED. The location SHOULD be the current location of the
Device, but more precisely, the location of the radiation center
of the Device's antenna. When the request is made by the Master
Device on behalf of a Slave Device, the location is that of the
_Master Device_. Depending on the regulatory domain, the location
MAY be an anticipated position of the Device to support mobile
devices. If the location specifies a region, rather than a point,
the Database MAY return an error with the UNIMPLEMENTED (Table 1)
code, if it does not support query by region.

<modified>
location: The GeoLocation (Section 5.1) for _the Device_ is
REQUIRED. The location SHOULD be the current location of the
Device, but more precisely, the location of the radiation center
of the Device's antenna. When the request is made by the Master
Device on behalf of a Slave Device, the location is that of the
_Slave Device_. Depending on the regulatory domain, the location
MAY be an anticipated position of the Device to support mobile
devices. If the location specifies a region, rather than a point,
the Database MAY return an error with the UNIMPLEMENTED (Table 1)
code, if it does not support query by region.

And I suggest to add the following parameter.

<new parameter>
masterDeviceLocation: Depending on regulatory rules, when the request is
made by the Master Device on behalf of a Slave Device, the Master
Device MAY be required to provide its own location.

Thanks.

Sungjin

On 10/18/2013 05:34 PM, Vincent Chen wrote:
> Ray,
>
>
>
> On Fri, Oct 18, 2013 at 1:10 AM, Ray Bellis <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>     On 17 Oct 2013, at 18:50, Don Joslyn <[email-masked]
>>     In addition, It's my current understanding that Ofcom requires
>>     slave devices to report "Channel Usage". In PAWS it would be
>>     contains the slave device's location whenever
>>     etsiEnDeviceCategory is equal to "slave". Does that make sense?
>
>     device identifier, emission class, location [optionally]) for
>     every connected slave.
>
>

---

From: Vincent Chen <[email-masked]>
Date: Wed, 23 Oct 2013 22:55:25 -0700

Good suggestion. Thanks!

-vince

On Wed, Oct 23, 2013 at 6:43 PM, Sungjin Yoo <[email-masked]> wrote:

> location: The GeoLocation (Section 5.1) for *the Master Device* is
> of the Device’s antenna. When the request is made by the Master
> *Master Device*. Depending on the regulatory domain, the location
> location: The GeoLocation (Section 5.1) for *the Device* is
> of the Device’s antenna. When the request is made by the Master
> *Slave Device*. Depending on the regulatory domain, the location

-- 
-vince

---

From: Vincent Chen <[email-masked]>
Date: Wed, 23 Oct 2013 23:00:28 -0700

Actually, worded in this fashion, the location becomes OPTIONAL, since a
slave's location may not be available.

-- 
-vince