[Bloat] [Make-wifi-fast] [Cerowrt-devel] closing up my make-wifi-fast lab

Luca Muscariello luca.muscariello at gmail.com
Mon Aug 27 03:51:57 EDT 2018

Hi Bob,

I meant licensed/unlicensed for private/non private.


On Mon, Aug 27, 2018 at 9:39 AM Bob McMahon <bob.mcmahon at broadcom.com>

> Hi Luca,
> What is non private spectrum defined as per  "I don't yet see how a non
> private spectrum can be shared  w/o LBT."
> Thanks,
> Bob
> On Mon, Aug 27, 2018 at 12:24 AM Luca Muscariello <
> luca.muscariello at gmail.com> wrote:
>> Jonathan,
>> Not that giant handwaving though.
>> IEEE 802.11ax makes use of "almost TDM" RTS/CTS and scheduling. The
>> almost is necessary as it operates in 2.4/5Ghz bands.
>> Similar to what you describe, and is coming very soon in shipping
>> products.
>> RTS/CTS is still a LBT to create a window where TDM can be done.
>> I don't yet see how a non private spectrum can be shared  w/o LBT.
>> On the other hand, medium sharing is one thing, the other thing is
>> capacity.
>> There is no way to efficiently share a medium if this is used close to
>> its theoretical capacity.
>> Capacity as #of stations per band including #SSID per band. Today scaling
>> can be achieved
>> with careful radio planning for spatial diversity or dynamic bean forming.
>> When you approach capacity with WiFi you only see beacon traffic and
>> almost zero throughput.
>> Cannot forget Mobile World Congress where you can measure several
>> thousands of SSIDs on 2.4
>> and several hundreds of SSID in 5GHz. But even LTE was very close to
>> capacity.
>> Dave,
>> Having air time fairness in open source is a significant achievement. I
>> don't see a failure.
>> Luca
>> On Mon, Aug 27, 2018 at 8:26 AM Jonathan Morton <chromatix99 at gmail.com>
>> wrote:
>>> > On 27 Aug, 2018, at 9:00 am, Bob McMahon <bob.mcmahon at 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
>>> _______________________________________________
>>> Bloat mailing list
>>> Bloat at lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/bloat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/bloat/attachments/20180827/06c50cab/attachment-0002.html>

More information about the Bloat mailing list