FTM/measurement APIs

[Johannes Berg <johannes@sipsolutions.net>]

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