FTM/measurement APIs

FTM/measurement APIs

[Johannes Berg]

Hi all,

After much delay on our side (don't ask), I'm contemplating upstream
APIs for FTM again.

Luca tells me that there are also other things to take into
consideration, notably angle of arrival. Or CIR/CFR but I have no idea
what those are, unless they're "Channel Impulse/Frequency Response" and
then perhaps that's what's used for angle measurement?

Anyway, I'll use the angle measurement as an example here.

In building the APIs for this, I'm wondering how much "generics" make
sense. We could build an API that's structured like this:

Measure(
 - [timeout]
 - [MAC randomization]
 - FTM
   - <FTM settings like TSF request?>
   - targets
     0: - MAC address
        - channel
        - ...
     1: - MAC address
        - channel
        - ...
 - Angle
   - <common settings>
   - targets
     0: - MAC address
        - channel
        - ...
)

This is very generic, so you could add something like

  - my_other_measurement
    - param1
    - param2

that's in no way connected to the target list.

However, note the duplication of MAC/channel.

You could also have only partially overlapping (or entirely disjoint)
target lists, in which case the concurrency no longer makes much sense.
The driver would have to build a combined target list, and then execute
the measurements. This implies more logic is needed.


The other option is to restrict this new API to doing "peer-related"
measurements, and build the list like this:

Peer-Measurement(
  - [timeout]
  - [MAC randomization]
  - global FTM options
    - ...
  - global angle options
    - ...
  - peers
    0: - MAC address
       - channel
       - FTM
         - ... [FTM settings]
       - Angle
         - ... [Angle settings]
    1: - MAC address
       - channel
       - ...
)

This is less generic, since it's restricted to a list of MAC/channel
pairs as the list of targets, and you can't add any other non-target
measurements to do simultaneously, at least not directly in this
structure. We could possibly still add it, but it would be more complex.

(And maybe the global options aren't really needed, for FTM the only one
I can think of is "request associated AP TSF" but that could be a per-
peer setting too.)


In a way, I prefer the second option. It's far simpler to start out
with, technically could be extended to non-peer measurements (though not
as cleanly perhaps), and matches the various location use cases far
better.


Any thoughts? Is anyone aware of any other measurements that are coming
up to be used in products that we'd want to cover here?


johannes

Re: FTM/measurement APIs

[Lior David]

Hi Johannes,

On 8/20/2018 3:03 PM, Johannes Berg wrote:
> Hi all,
> 
> After much delay on our side (don't ask), I'm contemplating upstream
> APIs for FTM again.
> 
I appreciate the effort. I had a discussion with Luca on the previous API a long
time ago and gave some comments, mainly to ensure it fits 11ad use cases, but
sadly I also moved to other tasks...

> Luca tells me that there are also other things to take into
> consideration, notably angle of arrival. Or CIR/CFR but I have no idea
> what those are, unless they're "Channel Impulse/Frequency Response" and
> then perhaps that's what's used for angle measurement?
> 
Yes AOA (angle of arrival) is based on CIR(channel impulse response) or CFR
(channel frequency response). Our 11ad chip can do CIR but most other chips do
CFR (I think). AOA finds azimuth and elevation from CIR by running some
algorithm in user space and using a database. Not sure how easy it is to offload
to FW. Anyhow I suggest calling the measurement CIR or CFR and not mentioning
AOA, since the CIR/CFR can be useful for other stuff.

> Anyway, I'll use the angle measurement as an example here.
> 
> In building the APIs for this, I'm wondering how much "generics" make
> sense. We could build an API that's structured like this:
> 
> Measure(
>  - [timeout]
>  - [MAC randomization]
>  - FTM
>    - <FTM settings like TSF request?>
>    - targets
>      0: - MAC address
>         - channel
>         - ...
>      1: - MAC address
>         - channel
>         - ...
>  - Angle
>    - <common settings>
>    - targets
>      0: - MAC address
>         - channel
>         - ...
> )
> 
> This is very generic, so you could add something like
> 
>   - my_other_measurement
>     - param1
>     - param2
> 
> that's in no way connected to the target list.
> 
> However, note the duplication of MAC/channel.
> 
> You could also have only partially overlapping (or entirely disjoint)
> target lists, in which case the concurrency no longer makes much sense.
> The driver would have to build a combined target list, and then execute
> the measurements. This implies more logic is needed.
> 
> 
> The other option is to restrict this new API to doing "peer-related"
> measurements, and build the list like this:
> 
> Peer-Measurement(
>   - [timeout]
>   - [MAC randomization]
>   - global FTM options
>     - ...
>   - global angle options
>     - ...
>   - peers
>     0: - MAC address
>        - channel
>        - FTM
>          - ... [FTM settings]
>        - Angle
>          - ... [Angle settings]
>     1: - MAC address
>        - channel
>        - ...
> )
> 
> This is less generic, since it's restricted to a list of MAC/channel
> pairs as the list of targets, and you can't add any other non-target
> measurements to do simultaneously, at least not directly in this
> structure. We could possibly still add it, but it would be more complex.
> 
> (And maybe the global options aren't really needed, for FTM the only one
> I can think of is "request associated AP TSF" but that could be a per-
> peer setting too.)
> 
> 
> In a way, I prefer the second option. It's far simpler to start out
> with, technically could be extended to non-peer measurements (though not
> as cleanly perhaps), and matches the various location use cases far
> better.
> 
I also prefer the second option. It is both simpler and allows the driver to
better organize the measurements (for example, in our implementation we always
do CIR at the beginning or end of FTM burst).

> 
> Any thoughts? Is anyone aware of any other measurements that are coming
> up to be used in products that we'd want to cover here?
> 
We had some "exotic" measurements that we wanted to support but none are
critical as far as I remember...
I can provide more detailed comments when you send actual nl80211 API (I think I
gave most comments to Luca but can find them again).

Thanks,
Lior

Re: FTM/measurement APIs

[Johannes Berg]

Hi Lior,

> Yes AOA (angle of arrival) is based on CIR(channel impulse response) or CFR
> (channel frequency response). Our 11ad chip can do CIR but most other chips do
> CFR (I think). AOA finds azimuth and elevation from CIR by running some
> algorithm in user space and using a database. Not sure how easy it is to offload
> to FW. Anyhow I suggest calling the measurement CIR or CFR and not mentioning
> AOA, since the CIR/CFR can be useful for other stuff.

Right.

> > The other option is to restrict this new API to doing "peer-related"
> > measurements, and build the list like this:
> > 
> > Peer-Measurement(
> >   - [timeout]
> >   - [MAC randomization]
> >   - global FTM options
> >     - ...
> >   - global angle options
> >     - ...
> >   - peers
> >     0: - MAC address
> >        - channel
> >        - FTM
> >          - ... [FTM settings]
> >        - Angle
> >          - ... [Angle settings]
> >     1: - MAC address
> >        - channel
> >        - ...
> > )
> > 
> > This is less generic, since it's restricted to a list of MAC/channel
> > pairs as the list of targets, and you can't add any other non-target
> > measurements to do simultaneously, at least not directly in this
> > structure. We could possibly still add it, but it would be more complex.
> > 
> > (And maybe the global options aren't really needed, for FTM the only one
> > I can think of is "request associated AP TSF" but that could be a per-
> > peer setting too.)
> > 
> > 
> > In a way, I prefer the second option. It's far simpler to start out
> > with, technically could be extended to non-peer measurements (though not
> > as cleanly perhaps), and matches the various location use cases far
> > better.
> > 
> 
> I also prefer the second option. It is both simpler and allows the driver to
> better organize the measurements (for example, in our implementation we always
> do CIR at the beginning or end of FTM burst).

I don't think it matters much to the driver - to organize them in a
certain way, it could walk both lists first and build a combined list.

However, come to think of it, it's also more obvious in this (second)
way that this will actually happen, i.e. that the measurements are more
or less simultaneous. If you organize it like the first way, you could
argue more that you just requested two measurements, nothing about their
relative time, whereas here you're at least requesting two measurements
for each peer.

> We had some "exotic" measurements that we wanted to support but none are
> critical as far as I remember...

If you remember any, let me know, but I guess it doesn't matter all that
much for this discussion if we already agree :)

> I can provide more detailed comments when you send actual nl80211 API (I think I
> gave most comments to Luca but can find them again).

I think what Luca gave me was your comments, but I'll double-check.

johannes