From: Bob McMahon <bob.mcmahon@broadcom.com>
To: chromatix99@gmail.com
Cc: dpreed@deepplum.com, bloat-announce@lists.bufferbloat.net,
Make-Wifi-fast <make-wifi-fast@lists.bufferbloat.net>,
cerowrt-devel@lists.bufferbloat.net,
bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Cerowrt-devel] [Make-wifi-fast] closing up my make-wifi-fast lab
Date: Mon, 27 Aug 2018 07:06:15 -0000 [thread overview]
Message-ID: <CAHb6LvpcSioG3dhyn4_EtWPxWTtkzYUgTS4wFkobnBZAJEoxrw@mail.gmail.com> (raw)
In-Reply-To: <2282D31E-CBEF-4B42-A6A6-4D6394EE0DF7@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3002 bytes --]
hmm, "going back" to TDM, doesn't that lose the benefits and efficiencies
per statistical multiplexing? How can a centralized device predict the
many "end stations'" network demand in its time scheduling?
Note: I think with 802.11ax this is happening to some extent per uplink
OFDMA but that requires both time scheduling and transmit power setting so
the AP receives the "simultaneous signals" with similar SINRs. This is
supposed to help with LBT but not really completely solve it.
Curious if eliminating LBT is possible per a distributed solution (with
partial network awareness) vs having a centralized scheduler (with "full"
network awareness)?
Bob
On Sun, Aug 26, 2018 at 11:26 PM Jonathan Morton <chromatix99@gmail.com>
wrote:
> > On 27 Aug, 2018, at 9:00 am, Bob McMahon <bob.mcmahon@broadcom.com>
> wrote:
> >
> > Curious to how LBT can be solved at the PHY level and if the potential
> solution sets preserve the end to end principle.
>
> The usual alternatives include TDM, usually coordinated by a master device
> (eg. the AP); full-duplex operation via diplexers and/or orthogonal coding;
> and simply firing off a packet and retrying with exponential backoff if an
> acknowledgement is not heard.
>
> TDM and diplexing are already used by both DOCSIS and LTE. They are
> proven technology. However, in DOCSIS the diplexing is greatly simplified
> by the use of a copper channel rather than airwaves, and in LTE the
> diplexer is fitted only at the tower, not in each client - so the tower can
> transmit and receive simultaneously, but an individual client cannot, but
> this is still useful because there are many clients per tower. Effective
> diplexers for wireless are expensive.
>
> Orthogonal coding is already used by GPS and, in a rather esoteric form,
> by MIMO-grade wifi. IMHO it works rather better in GPS than in wifi. In
> GPS, it allows all of the satellites in the constellation to transmit on
> the standard frequency simultaneously, while still being individually
> distinguishable. The data rate is very low, however, since each
> satellite's signal inherently has a negative SNR (because there's a dozen
> others shouting over it) - that's why it takes a full minute for a receiver
> to get a fix from cold, because it simply takes that long to download the
> ephemeris from the first satellite whose signal is found.
>
> A future version of wifi could reasonably use TDM, I think, but not
> diplexing. The way this would work is that the AP assigns each station
> (including itself) a series of time windows in which to transmit as much as
> they like, and broadcasts this schedule along with its beacon. Also
> scheduled would be windows in which the AP listens for new stations,
> including possibly other nearby APs with which it may mutually coordinate
> time. A mesh network could thus be constructed entirely out of mutually
> coordinating APs if necessary.
>
> The above paragraph is obviously a giant handwave...
>
> - Jonathan Morton
>
>
[-- Attachment #2: Type: text/html, Size: 3418 bytes --]
next prev parent reply other threads:[~2018-08-27 7:06 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-26 12:26 [Cerowrt-devel] " David P. Reed
2018-08-27 6:00 ` [Cerowrt-devel] [Make-wifi-fast] " Bob McMahon
2018-08-27 6:26 ` Jonathan Morton
2018-08-27 7:06 ` Bob McMahon [this message]
2018-08-27 7:52 ` Jonathan Morton
2018-08-27 8:34 ` Bob McMahon
2018-08-27 19:11 ` Bob McMahon
2018-08-27 19:45 ` Jonathan Morton
2018-08-27 19:59 ` Bob McMahon
[not found] ` <alpine.DEB.2.02.1808271431590.2583@nftneq.ynat.uz>
2018-08-28 1:47 ` [Cerowrt-devel] [Bloat] " Bob McMahon
[not found] ` <alpine.DEB.2.02.1808271750490.2583@nftneq.ynat.uz>
2018-08-28 1:56 ` Bob McMahon
2018-08-30 19:12 ` [Cerowrt-devel] " bkil
2018-08-30 19:17 ` Bob McMahon
2018-08-30 20:36 ` bkil
2018-09-03 19:30 ` Bob McMahon
2018-08-27 7:24 ` [Cerowrt-devel] [Bloat] " Luca Muscariello
2018-08-27 7:39 ` Bob McMahon
2018-08-27 7:52 ` Luca Muscariello
2018-08-30 19:12 ` [Cerowrt-devel] " bkil
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/cerowrt-devel.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAHb6LvpcSioG3dhyn4_EtWPxWTtkzYUgTS4wFkobnBZAJEoxrw@mail.gmail.com \
--to=bob.mcmahon@broadcom.com \
--cc=bloat-announce@lists.bufferbloat.net \
--cc=bloat@lists.bufferbloat.net \
--cc=cerowrt-devel@lists.bufferbloat.net \
--cc=chromatix99@gmail.com \
--cc=dpreed@deepplum.com \
--cc=make-wifi-fast@lists.bufferbloat.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox