[Cerowrt-devel] [Make-wifi-fast] closing up my make-wifi-fast lab
Bob McMahon
bob.mcmahon at broadcom.com
Mon Aug 27 15:11:21 EDT 2018
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 at 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 at gmail.com>
> wrote:
>
>> > On 27 Aug, 2018, at 10:06 am, Bob McMahon <bob.mcmahon at 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
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/cerowrt-devel/attachments/20180827/cd3b896d/attachment-0001.html>
More information about the Cerowrt-devel
mailing list