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

[Bob McMahon <bob.mcmahon@broadcom.com>]

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

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@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@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
>>
>> _______________________________________________
>> Bloat mailing list
>> Bloat@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/bloat
>>
>

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