Re: [paws] Support for including Slave Device location

Thu, 17 Oct 2013 12:47:58 -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:

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






















					Reply via email to