Lets make wifi fast again!
 help / color / mirror / Atom feed
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: [Make-wifi-fast] [Cerowrt-devel] closing up my make-wifi-fast lab
Date: Mon, 27 Aug 2018 12:11:08 -0700	[thread overview]
Message-ID: <CAHb6LvpNYdFAc0ZoUw7Hqw3chZaMjthgDBdDF=rwBvZbV0WsjQ@mail.gmail.com> (raw)
In-Reply-To: <CAHb6LvoDkYy29Yt9DaB+1q-P-=QxRu_RqDPJFvfCbbn1bA+t2g@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3748 bytes --]

I guess my question is can a WiFi transmitting device rely on primarily
energy detect and mostly ignore the EDCA probability game and rather search
for (or predict) unused spectrum per a time interval such that its digital
signal has enough power per its observed SNR?   Then detect "collisions"
(or, "superposition cases" per the RX not having sufficient SINR) via
inserting silent gaps in its TX used to sample ED, i.e. run energy detect
throughout the entire transmission?  Or better, no silent gaps, rather
detect if there is superimposed energy on it's own TX and predict a
collision (i.e. RX probably couldn't decode its signal) occurred?  If
doable, this seems simpler than having to realize centralized (or even
distributed) media access algorithms a la, TDM, EDCA with ED, token buses,
token rings, etc. and not require media access coordination by things like
APs.

Bob

On Mon, Aug 27, 2018 at 1:34 AM Bob McMahon <bob.mcmahon@broadcom.com>
wrote:

> Hi Jonathan,
> I think in 802.11ax the AP can schedule STAs to some extent so it looks
> like that technique is coming soon.  It is a bw tradeoff per the RUs per
> user.
>
> Multi-User Uplink Operation
>
> To coordinate uplink MU-MIMO or uplink OFDMA transmissions the AP sends a
> trigger frame to all users. This frame indicates the number of spatial
> streams and/or the OFDMA allocations (frequency and RU sizes) of each user.
> It also contains power control information, such that individual users can
> increase or reduce their transmitted power, in an effort to equalize the
> power that the AP receives from all uplink users and improve reception of
> frames from nodes farther away. The AP also instructs all users when to
> start and stop transmitting. As Figure 10depicts, the AP sends a multi-user
> uplink trigger frame that indicates to all users the exact moment at which
> they all start transmitting, and the exact duration of their frame, to
> ensure that they all finish transmitting simultaneously as well. Once the
> AP receives the frames from all users, it sends them back a block ACK to
> finish the operation.
>
>
>
> *Figure 10. Coordinating uplink multi-user operation*
>
>
>
>
> On Mon, Aug 27, 2018 at 12:52 AM Jonathan Morton <chromatix99@gmail.com>
> wrote:
>
>> > On 27 Aug, 2018, at 10:06 am, Bob McMahon <bob.mcmahon@broadcom.com>
>> wrote:
>> >
>> > How can a centralized device predict the many "end stations'" network
>> demand in its time scheduling?
>>
>> DOCSIS does it by initially giving stations a tiny window into which to
>> send requests for time, which are granted by the head-end.  This introduces
>> some latency.  Further requests for time can be appended to a real
>> transmission, which helps efficiency slightly.
>>
>> Developing from that model, an AP might initially divide time evenly
>> between stations, allowing them to send single large packets or several
>> small packets without an explicit request for time - this is good for
>> latency.  Along with that packet, the station could indicate to the AP that
>> it has a queue of packets waiting, and the AP would take that into account
>> when producing its next schedule.  It would also take into account its own
>> queue.
>>
>> It may be possible to combine TDM with orthogonal coding.  Here the AP
>> monitors the received signal strength of its stations, and instructs them
>> to change power so as to minimise the difference between them.  This
>> maximises the SNR for each, should two transmit simultaneously.  The
>> tradeoff, of course, is that orthogonal coding permits a reduction in
>> waiting to transmit, but requires a reduction in data rate during the
>> transmission.  I'm sure other people have better data on that than I do.
>>
>>  - Jonathan Morton
>>
>>

[-- Attachment #2: Type: text/html, Size: 5915 bytes --]

  reply	other threads:[~2018-08-27 19:11 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-26 12:26 David P. Reed
2018-08-27  6:00 ` Bob McMahon
2018-08-27  6:26   ` Jonathan Morton
2018-08-27  7:06     ` Bob McMahon
2018-08-27  7:52       ` Jonathan Morton
2018-08-27  8:34         ` Bob McMahon
2018-08-27 19:11           ` Bob McMahon [this message]
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:46                 ` [Make-wifi-fast] [Bloat] " Bob McMahon
     [not found]                   ` <alpine.DEB.2.02.1808271750490.2583@nftneq.ynat.uz>
2018-08-28  1:55                     ` Bob McMahon
2018-08-28  2:14                       ` [Make-wifi-fast] deep wifi Dave Taht
     [not found]                         ` <nycvar.QRO.7.76.6.1808272031560.20375@qynat-yncgbc>
2018-08-28  4:44                           ` Dave Taht
2018-08-28  5:43                             ` Bob McMahon
2018-08-30 19:12               ` [Make-wifi-fast] [Cerowrt-devel] closing up my make-wifi-fast lab 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     ` [Make-wifi-fast] [Bloat] " Luca Muscariello
2018-08-27  7:39       ` Bob McMahon
2018-08-27  7:51         ` Luca Muscariello
2018-08-30 19:11 ` [Make-wifi-fast] " bkil
  -- strict thread matches above, loose matches on Subject: below --
2018-08-25 20:04 David P. Reed
2018-08-25 21:22 ` Dave Taht
2018-08-24 20:10 [Make-wifi-fast] " Dave Taht
2018-08-25 18:02 ` [Make-wifi-fast] [Cerowrt-devel] " Michael Richardson

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/make-wifi-fast.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAHb6LvpNYdFAc0ZoUw7Hqw3chZaMjthgDBdDF=rwBvZbV0WsjQ@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