> The distance matrix defines signal attenuations/loss between pairs. It's > straightforward to create a distance matrix that has hidden nodes because > all "signal loss" between pairs is defined. Let's say a 120dB attenuation > path will cause a node to be hidden as an example. > > A B C D > A - 35 120 65 > B - 65 65 > C - 65 > D - > > So in the above, AC are hidden from each other but nobody else is. It does > assume symmetry between pairs but that's typically true.
That is not correct, symmetry in the RF world, especially wifi, is rare due to topology issues. A high transmitter, A, and a low receiver, B, has a good path A - > B, but a very weak path B -> A. Multipathing is another major issue that causes assymtry. > > The RF device takes these distance matrices as settings and calculates the > five branch tree values (as demonstrated in the video). There are > limitations to solutions though but I've found those not to be an issue to > date. I've been able to produce hidden nodes quite readily. Add the phase > shifters and spatial stream powers can also be affected, but this isn't > shown in this simple example. > > Bob > > On Mon, Aug 2, 2021 at 8:12 PM David Lang <da...@lang.hm> wrote: > > > I guess it depends on what you are intending to test. If you are not going > > to > > tinker with any of the over-the-air settings (including the number of > > packets > > transmitted in one aggregate), the details of what happen over the air > > don't > > matter much. > > > > But if you are going to be doing any tinkering with what is getting sent, > > and > > you ignore the hidden transmitter type problems, you will create a > > solution that > > seems to work really well in the lab and falls on it's face out in the > > wild > > where spectrum overload and hidden transmitters are the norm (at least in > > urban > > areas), not rare corner cases. > > > > you don't need to include them in every test, but you need to have a way > > to > > configure your lab to include them before you consider any > > settings/algorithm > > ready to try in the wild. > > > > David Lang > > > > On Mon, 2 Aug 2021, Bob McMahon wrote: > > > > > We find four nodes, a primary BSS and an adjunct one quite good for lots > > of > > > testing. The six nodes allows for a primary BSS and two adjacent ones. > > We > > > want to minimize complexity to necessary and sufficient. > > > > > > The challenge we find is having variability (e.g. montecarlos) that's > > > reproducible and has relevant information. Basically, the distance > > matrices > > > have h-matrices as their elements. Our chips can provide these > > h-matrices. > > > > > > The parts for solid state programmable attenuators and phase shifters > > > aren't very expensive. A device that supports a five branch tree and 2x2 > > > MIMO seems a very good starting point. > > > > > > Bob > > > > > > On Mon, Aug 2, 2021 at 4:55 PM Ben Greear <gree...@candelatech.com> > > wrote: > > > > > >> On 8/2/21 4:16 PM, David Lang wrote: > > >>> If you are going to setup a test environment for wifi, you need to > > >> include the ability to make a fe cases that only happen with RF, not > > with > > >> wired networks and > > >>> are commonly overlooked > > >>> > > >>> 1. station A can hear station B and C but they cannot hear each other > > >>> 2. station A can hear station B but station B cannot hear station A 3. > > >> station A can hear that station B is transmitting, but not with a strong > > >> enough signal to > > >>> decode the signal (yes in theory you can work around interference, but > > >> in practice interference is still a real thing) > > >>> > > >>> David Lang > > >>> > > >> > > >> To add to this, I think you need lots of different station devices, > > >> different capabilities (/n, /ac, /ax, etc) > > >> different numbers of spatial streams, and different distances from the > > >> AP. From download queueing perspective, changing > > >> the capabilities may be sufficient while keeping all stations at same > > >> distance. This assumes you are not > > >> actually testing the wifi rate-ctrl alg. itself, so different throughput > > >> levels for different stations would be enough. > > >> > > >> So, a good station emulator setup (and/or pile of real stations) and a > > few > > >> RF chambers and > > >> programmable attenuators and you can test that setup... > > >> > > >> From upload perspective, I guess same setup would do the job. > > >> Queuing/fairness might depend a bit more on the > > >> station devices, emulated or otherwise, but I guess a clever AP could > > >> enforce fairness in upstream direction > > >> too by implementing per-sta queues. > > >> > > >> Thanks, > > >> Ben > > >> > > >> -- > > >> Ben Greear <gree...@candelatech.com> > > >> Candela Technologies Inc http://www.candelatech.com > > >> > > > > > > > > > > -- > This electronic communication and the information and any files transmitted > with it, or attached to it, are confidential and are intended solely for > the use of the individual or entity to whom it is addressed and may contain > information that is confidential, legally privileged, protected by privacy > laws, or otherwise restricted from disclosure to anyone else. If you are > not the intended recipient or the person responsible for delivering the > e-mail to the intended recipient, you are hereby notified that any use, > copying, distributing, dissemination, forwarding, printing, or copying of > this e-mail is strictly prohibited. If you received this e-mail in error, > please return the e-mail to the sender, delete it from your computer, and > destroy any printed copy of it. [ Charset UTF-8 unsupported, converting... ] > _______________________________________________ > Starlink mailing list > starl...@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/starlink > _______________________________________________ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
