[Bloat] [Make-wifi-fast] [Cerowrt-devel] closing up my make-wifi-fast lab
Bob McMahon
bob.mcmahon at broadcom.com
Mon Aug 27 03:39:09 EDT 2018
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/8260ae4c/attachment-0002.html>
More information about the Bloat
mailing list