Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [STDS-802-11-TGAZ] FW: RE: [STDS-802-11-TGBD] TGbd and positioning



Hello Dick:

 

Your messages are interesting (as always).

 

In .11az (as in REVmc Fine Timing Measurement Protocol) our positioning was always relative to ‘known’ geo-spatial co-ordinates of the AP(s) against which the positioning protocol is executed. If the positioning protocol is executed against 3 or more APs (which have been administratively configured with their LCI co-ordinates), we could triangulate and estimate the LCI co-ordinates of the STA that executed the protocol against each of the AP(s).

 

That is how the protocol works; and we have verified that it works as expected by testing with conformant (IEEE802.11-2016) implementations.

 

Cheers --

ganesh

“It is amazing what you can accomplish if you don’t care who gets the credit.” – Harry Truman

 

 

From: *** 802.11 TGaz - NGP - Next Generation Positioning *** <STDS-802-11-TGAZ@xxxxxxxxxxxxxxxxx> On Behalf Of Dick Roy
Sent: Friday, November 6, 2020 12:39 PM
To: STDS-802-11-TGAZ@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGAZ] FW: RE: [STDS-802-11-TGBD] TGbd and positioning

 

Thought some TGaz folks might find this interesting and perhaps even relevant  :^)))

 

RR

 


From: Dick Roy [mailto:dickroy@xxxxxxxxxxxx]
Sent: Friday, November 6, 2020 11:54 AM
To: 'STDS-802-11-TGBD@xxxxxxxxxxxxxxxxx'
Cc: 'dickroy@xxxxxxxxxxxx'; 'mark.hamilton2152@xxxxxxxxx'
Subject: RE: [STDS-802-11-TGBD] TGbd and positioning

 

Hi all,

 

Just wanted to take this opportunity to make a few suggestions that might impact the .11bd work on “positioning” going forward.  (PS.  If you are short on time or are not into state-of-the-art stochastic signal processing, just look at the highlighted items below :^)))

 

Before I do that, there are a few things that are important/interesting to remember/know so the context can be clearly understood.  These are:

 

  1. If you do not know “what time it is”, you can not know “where you are”.
  2. The speed of light in a vacuum is a constant (approx. 1ft/ns) and it matters. It essentially means that all time is “relative”.  (It’s also interesting to note that one’s location in a gravitational potential field is of importance if for no other reason than we “live in one”.  It (aka General Relativity) has a direct impact on all global navigation satellite systems (GNSSs)!)
  3. ALL measurements of quantities, including times, are random variables with probability distributions (PDFs) governing the observations/measurements.  (NB: Often we argue by the CLT (Central Limit Theorem) that these PDFs area Gaussian so a mean and a (co-)variance tell us all we need to know, however this is not required.)
  4. Generally we make measurements of quantities because they contain some information of value, otherwise we wouldn’t bother. The challenge is to extract what we want to know from what we measure and “we want it all”!  We don’t want to through any information into dev/null.
  5. The process of information extraction usually is complex and generally relies on many other “external factors” such as what other measurements are relevant and available, and what assumptions are made (e.g. what is the “model of the system” under consideration).
  6. NB:  There is an information theoretic analog to the thermodynamic law that states the entropy of the universe is a non-increasing function of time. This law is called the “data processing inequality” and it basically states that “no (pre-)processing of measurements/data can increase the amount of information contained in those measurements/data”. So, while the best you can hope for is that pre-processing does no damage, generally it does! The point is you want to minimize the damage!

 

At this point, you are probably wondering where this is all headed.  Well, this is where. 

 

  1. Q: What do we want to know? A: Where the heck am I … now!
  2. Q: How do I go about this given that I may be “moving” (in some frame of reference, but that’s a story for another day)? A: I make measurements of quantities using a variety of means that contain information relevant to answering Q1.  By 1) above, that means I also need to know “what time it is”! I then decide on a “model of the system under consideration” which in this case is a model of my kinematic (and possibly attitude) state as a function of time.  Using this dynamical (generally a state-space) model, appropriate “measurement models” are derived, models that describe what I expect to measure given what “state I am in”.  While not critical, it is generally the case that the dynamical models are “continuous” (in time) and the measurement models are “discrete” (in time).  That is, I move in continuous time and make measurements at specific times “along the way”.  This has a direct impact on the choice of information processing techniques at my disposal, generally leading in problems such as this to a “continuous-discrete stochastic filter” as the “engine of choice”.  These stochastic filters take measurements and probabilistic information associated therewith (e.g measurement error variance) along with some other inputs (to be discussed another day) as inputs and (hopefully optimally) produce as outputs estimates of the things I want to know, in this case my kinematic (and perhaps attitude) state as a function of time which interestingly turns out to also be a state that must be estimated (see 1) above)!  

 

This all may sound a bit complicated, I realize, however as mentioned on the call this morning, this entire process has been used for decades in “all walks of our lives”, including landing men on the moon over 50 years ago … AND getting them back safely!  Every aircraft on the planet today uses some form of what is describe above to safely transport people all over the world.  (Yes, all of this has a direct relationship to the 737 max-8 debacle, however that’s a story for another day :^)))

 

So how could any of this possibly impact the work in .11bd?  Glad you asked:^))  Here’s how:

 

  1. The overall objective is to estimate (aka figure out) “where I am” (which of course begs the question “with respect to what?”, which is yet another a very interesting story for yet another day.)
  2. .11 bd’s job is to modify an existing MAC/PHY with one of the goals being to “allow/enhance” (aka not obviate) the ability achieve this objective.
  3. In this regard, anything other than “making measurements of MAC/PHY parameters” is “out of scope” of .11bd.
  4. Any attempt by .11bd to (pre-)process those measurements can at best only be a waste of time, and unfortunately more often than not, will do harm (aka destroy valuable information). As a simple example, making TOA measurements of two streams and “subtracting them” to yield a TDOA (or Time-Difference-of-Arrival) actually “destroys valuable information” and is not recommended if it can be avoided.
  5. CONCLUSION: If .11bd decides that modifications to .11 related to the making of measurements relevant for kinematic state estimation (aka “positioning”) is warranted, they should take the above into consideration and do as little pre-processing as possible, AND ensure that the appropriate probabilistic information (e.g. measurement error (co-)variance) and all relevant metadata associated with the measurements are made available.

 

Hope you find this useful.  If you have any questions, don’t hesitate to ask!  

 

Cheers and stay safe out there!

 

RR

 

 


To unsubscribe from the STDS-802-11-TGAZ list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAZ&A=1


To unsubscribe from the STDS-802-11-TGAZ list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAZ&A=1