| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
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-TGBD list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBD&A=1 |