From: Luca Muscariello <luca.muscariello@gmail.com>
To: bob.mcmahon@broadcom.com
Cc: Jonathan Morton <chromatix99@gmail.com>,
bloat-announce@lists.bufferbloat.net,
make-wifi-fast@lists.bufferbloat.net,
cerowrt-devel@lists.bufferbloat.net, dpreed@deepplum.com,
bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Make-wifi-fast] [Bloat] [Cerowrt-devel] closing up my make-wifi-fast lab
Date: Mon, 27 Aug 2018 09:51:57 +0200 [thread overview]
Message-ID: <CAHx=1M57qfAnWBfhgJoPa5RxdT6R=imJ9WWLmuxQGsRBywRVOw@mail.gmail.com> (raw)
In-Reply-To: <CAHb6Lvqhf5=WiVE_GVAe3bxFO05cndBdOw_Qu4Ctmf57kuXXuQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4172 bytes --]
Hi Bob,
I meant licensed/unlicensed for private/non private.
Luca
On Mon, Aug 27, 2018 at 9:39 AM Bob McMahon <bob.mcmahon@broadcom.com>
wrote:
> 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: 5410 bytes --]
next prev parent reply other threads:[~2018-08-27 7:52 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-26 12:26 [Make-wifi-fast] " 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
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 [this message]
2018-08-30 19:11 ` [Make-wifi-fast] " bkil
2018-08-27 22:37 [Make-wifi-fast] [Bloat] " Jonathan Morton
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='CAHx=1M57qfAnWBfhgJoPa5RxdT6R=imJ9WWLmuxQGsRBywRVOw@mail.gmail.com' \
--to=luca.muscariello@gmail.com \
--cc=bloat-announce@lists.bufferbloat.net \
--cc=bloat@lists.bufferbloat.net \
--cc=bob.mcmahon@broadcom.com \
--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