<div dir="ltr">Is there a specific goal in mind?  This seems an AP tx centric proposal, though I may not be fully understanding it.  I'm also curious as why not scale in spatial domain vs the frequency domain, i.e. AP and STAs can also scale using MiMO.  Why not just do that? So many phones today are 1x1, some 2x2 and few 3x3.   Yet APs are moving to 4x4 and I think the standard supports 8x8.  (I'm not sure the marginal transistor count increase per each approach.)  On the AP tx side, MuMIMO is also there which I think is similar to the DAC proposal. <div><br></div><div>I'm far from a PHY & DSP expert, but I think the simultaneous AP receive is the most difficult issue per the power variations, aka SNR.  Each of the mobile device energies is affected per inverse square law (unless some form of wave guide is used.)  Hence wi-fi use of time domain slots prior to transmit (no longer simultaneous in time.)  Particularly needed for devices that communicate with one another.  Unfortunately, "collocated" energy/information sources must honor this TDM  even when not communication with one another per tragedy of the commons.  (Agreed there is no such thing as a collision so let's redefine it to mean that the receiver is unable to receive per RF energy "confusion", still a tragedy of the commons.  I don't know what drives the limits to DSP decode that could minimize or eliminate  this tragedy.)</div><div>   <div>At the end of the day, would the ideal network would resemble a wired ethernet (including ethernet switch fabric) without the waveguides (or wires/fibers)?  From that perspective, here are some thoughts to the goals<div><br></div><div>o)  TX op/access to transmit driven to zero.  (Collision avoidance isn't nearly as good as instantaneous collision detect in this context, though "collision" should replaced with "confusion")  </div><div>o)  RX confusion detection time propagated to stop offending TX(s) driven to zero  </div><div>o)  Support of different encodings (e..g phy rates) pushes towards virtual output queueing prior (queuing at the transmitter)</div><div>o)  Power per bit xfered towards zero or driven per cost & energy density of batteries.  Note: Atomic batteries not allowed per humans being involved.</div><div>o)  Transistor count (chip cost) per bit moved driven by Moore's law and those economics</div><div>o)  Reduce "collision/confusion" domain (less STAs per AP) ideally to zero</div><div><br></div><div>Just some thoughts off the top of my head.  Please do comment and correct.  Thanks in advance for the discussion.</div><div><br></div><div>Bob</div><div> <br><div><br></div><div><br></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 24, 2016 at 2:24 PM,  <span dir="ltr"><<a href="mailto:dpreed@reed.com" target="_blank">dpreed@reed.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Without custom silicon, doing what I was talking about would involve non standard MAC power management, which would require all devices to agree.<br>
<br>
David Lang's explanation was the essence of what I meant. the transmission from access point on multiple channels is just digital addition if the DACs have enough bits per sample. to make sure that the signals to the AP are equalized, just transmit at a power that makes that approximately true... which means a power amp with at most 30 dB of dynamic gain setting. typical dynamic path attenuation range (strongest to weakest ratio) among stations served by an AP is < 20 dB from my past experiments on well operating-installtions, but 25 can be seen in reflection heavy environments.-----Original Message-----<br>
From: "David Lang" <<a href="mailto:david@lang.hm">david@lang.hm</a>><br>
Sent: Fri, Jun 24, 2016 at 1:19 am<br>
To: "Bob McMahon" <<a href="mailto:bob.mcmahon@broadcom.com">bob.mcmahon@broadcom.com</a>><br>
Cc: "Bob McMahon" <<a href="mailto:bob.mcmahon@broadcom.com">bob.mcmahon@broadcom.com</a>>, <a href="mailto:make-wifi-fast@lists.bufferbloat.net">make-wifi-fast@lists.bufferbloat.net</a>, "<a href="mailto:cerowrt-devel@lists.bufferbloat.net">cerowrt-devel@lists.bufferbloat.net</a>" <<a href="mailto:cerowrt-devel@lists.bufferbloat.net">cerowrt-devel@lists.bufferbloat.net</a>><br>
<span class="">Subject: Re: [Make-wifi-fast] more well funded attempts showing market demandfor better wifi<br>
<br>
</span><span class="">well, with the kickstarter, I think they are selling a bill of goods.<br>
<br>
Just using the DFS channels and aggregating them as supported by N and AC<br>
standards would do wonders (as long as others near you don't do the same)<br>
<br>
David Lang<br>
<br>
On Thu, 23 Jun 2016, Bob McMahon wrote:<br>
<br>
> Date: Thu, 23 Jun 2016 20:01:22 -0700<br>
> From: Bob McMahon<br>
</span>> To: David Lang<br>
> Cc: <a href="mailto:dpreed@reed.com">dpreed@reed.com</a>, <a href="mailto:make-wifi-fast@lists.bufferbloat.net">make-wifi-fast@lists.bufferbloat.net</a>,<br>
<span class="">>     "<a href="mailto:cerowrt-devel@lists.bufferbloat.net">cerowrt-devel@lists.bufferbloat.net</a>"<br>
><br>
> Subject: Re: [Make-wifi-fast] more well funded attempts showing market demand<br>
>     for better wifi<br>
><br>
> Thanks for the clarification.   Though now I'm confused about how all the<br>
> channels would be used simultaneously with an AP only solution (which is my<br>
> understanding of the kickstarter campaign.)<br>
><br>
> Bob<br>
><br>
</span><span class="">> On Thu, Jun 23, 2016 at 7:14 PM, David Lang  wrote:<br>
><br>
>> I think he is meaning when one unit is talking to one AP the signal levels<br>
>> across multiple channels will be similar. Which is probably fairly true.<br>
>><br>
>><br>
>> David Lang<br>
>><br>
>> On Thu, 23 Jun 2016, Bob McMahon wrote:<br>
>><br>
>> Curious, where does the "in a LAN setup, the variability in [receive]<br>
>>> signal strength is likely small enough" assertion come?   Any specific<br>
>>> power numbers here? We test with many combinations of "signal strength<br>
>>> variability" (e.g. deltas range from 0 dBm -  50 dBm) and per different<br>
>>> channel conditions.  This includes power variability within the spatial<br>
>>> streams' MiMO transmission.   It would be helpful to have some physics<br>
>>> combined with engineering to produce some pragmatic limits to this.<br>
>>><br>
>>> Also, mobile devices have a goal of reducing power in order to be<br>
>>> efficient<br>
>>> with their battery (vs a goal to balance power such that an AP can<br>
>>> receive simultaneously.)  Power per bit usually trumps most other design<br>
>>> goals.  There market for battery powered wi-fi devices drives a<br>
>>> semi-conductor mfg's revenue so my information come with that bias.<br>
>>><br>
>>> Bob<br>
>>><br>
</span><div><div class="h5">>>> On Thu, Jun 23, 2016 at 1:48 PM,  wrote:<br>
>>><br>
>>> The actual issues of transmitting on multiple channels at the same time<br>
>>>> are quite minor if you do the work in the digital domain (pre-DAC).  You<br>
>>>> just need a higher sampling rate in the DAC and add the two signals<br>
>>>> together (and use a wideband filter that covers all the channels).  No RF<br>
>>>> problem.<br>
>>>><br>
>>>> Receiving multiple transmissions in different channels is pretty much the<br>
>>>> same problem - just digitize (ADC) a wider bandwidth and separate in the<br>
>>>> digital domain.  the only real issue on receive is equalization - if you<br>
>>>> receive two different signals at different receive signal strengths, the<br>
>>>> lower strength signal won't get as much dynamic range in its samples.<br>
>>>><br>
>>>> But in a LAN setup, the variability in signal strength is likely small<br>
>>>> enough that you can cover that with more ADC bits (or have the MAC<br>
>>>> protocol<br>
>>>> manage the station transmit power so that signals received at the AP are<br>
>>>> nearly the same power.<br>
>>>><br>
>>>> Equalization at transmit works very well when there is a central AP (as<br>
>>>> in<br>
>>>> cellular or normal WiFi systems).<br>
>>>><br>
>>>><br>
>>>><br>
>>>> On Thursday, June 23, 2016 4:28pm, "Bob McMahon" >>> <a href="mailto:bob.mcmahon@broadcom.com">bob.mcmahon@broadcom.com</a>><br>
>>>> said:<br>
>>>><br>
>>>> _______________________________________________<br>
>>>>> Make-wifi-fast mailing list<br>
>>>>> <a href="mailto:Make-wifi-fast@lists.bufferbloat.net">Make-wifi-fast@lists.bufferbloat.net</a><br>
>>>>> <a href="https://lists.bufferbloat.net/listinfo/make-wifi-fast" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/listinfo/make-wifi-fast</a><br>
>>>>> An AP per room/area, reducing the tx power (beacon range) has been my<br>
>>>>> approach and has scaled very well.   It does require some wires to each<br>
>>>>><br>
>>>> AP<br>
>>>><br>
>>>>> but I find that paying an electrician to run some quality wiring to<br>
>>>>><br>
>>>> things<br>
>>>><br>
>>>>> that are to remain stationary has been well worth the cost.<br>
>>>>><br>
>>>>> just my $0.02,<br>
>>>>> Bob<br>
>>>>><br>
</div></div><span class="">>>>>> On Thu, Jun 23, 2016 at 1:10 PM, David Lang  wrote:<br>
>>>>><br>
>>>>> Well, just using the 5GHz DFS channels in 80MHz or 160 MHz wide chunks<br>
>>>>>> would be a huge improvement, not many people are using them (yet), and<br>
>>>>>><br>
>>>>> the<br>
>>>><br>
>>>>> wide channels let you get a lot of data out at once. If everything is<br>
>>>>>> within a good range of the AP, this would work pretty well. If you end<br>
>>>>>><br>
>>>>> up<br>
>>>><br>
>>>>> needing multiple APs, or you have many stations, I expect that you will<br>
>>>>>><br>
>>>>> be<br>
>>>><br>
>>>>> better off with more APs at lower power, each using different channels.<br>
>>>>>><br>
>>>>>> David Lang<br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> On Thu, 23 Jun 2016, Bob McMahon wrote:<br>
>>>>>><br>
>>>>>> Date: Thu, 23 Jun 2016 12:55:19 -0700<br>
>>>>>><br>
>>>>>>> From: Bob McMahon<br>
</span>>>>>>>> To: Dave Taht<br>
>>>>>>> Cc: <a href="mailto:make-wifi-fast@lists.bufferbloat.net">make-wifi-fast@lists.bufferbloat.net</a>,<br>
<span class="">>>>>>>>     "<a href="mailto:cerowrt-devel@lists.bufferbloat.net">cerowrt-devel@lists.bufferbloat.net</a>"<br>
>>>>>>><br>
>>>>>>> Subject: Re: [Make-wifi-fast] more well funded attempts showing market<br>
>>>>>>> demand<br>
>>>>>>>     for better wifi<br>
>>>>>>><br>
>>>>>>><br>
>>>>>>> hmm, I'm skeptical.   To use multiple carriers simultaneously is<br>
>>>>>>><br>
>>>>>> difficult<br>
>>>><br>
>>>>> per RF issues.   Even if that is somehow resolved, to increase<br>
>>>>>>><br>
>>>>>> throughput<br>
>>>><br>
>>>>> usually requires some form of channel bonding, i.e. needed on both<br>
>>>>>>><br>
>>>>>> sides,<br>
>>>><br>
>>>>> and brings in issues with preserving frame ordering.  If this is just<br>
>>>>>>> channel hopping, that needs coordination between both sides (and isn't<br>
>>>>>>> simultaneous, possibly costing more than any potential gain.)   An AP<br>
>>>>>>><br>
>>>>>> only<br>
>>>><br>
>>>>> solution can use channel switch announcements (CSA) but there is a<br>
>>>>>>><br>
>>>>>> cost to<br>
>>>><br>
>>>>> those as well.<br>
>>>>>>><br>
>>>>>>> I guess don't see any break though here and the marketing on the site<br>
>>>>>>> seems<br>
>>>>>>> to indicate something beyond physics, at least the physics that I<br>
>>>>>>> understand.  Always willing to learn and be corrected if I'm<br>
>>>>>>> misunderstanding things.<br>
>>>>>>><br>
>>>>>>> Bob<br>
>>>>>>><br>
>>>>>>> On Wed, Jun 22, 2016 at 10:18 AM, Dave Taht<br>
>>>>>>><br>
</span><span class="">>>>>>> wrote:<br>
>>>><br>
>>>>><br>
>>>>>>> On Wed, Jun 22, 2016 at 10:03 AM, Dave Taht<br>
>>>>>>><br>
</span><span class="">>>>>>> wrote:<br>
>>>><br>
>>>>><br>
>>>>>>>><br>
>>>>>>>>><br>
>>>>>>>>><br>
>>>>>>>><br>
>>>> <a href="https://www.kickstarter.com/projects/portalwifi/portal-turbocharged-wifi?ref=backerkit" rel="noreferrer" target="_blank">https://www.kickstarter.com/projects/portalwifi/portal-turbocharged-wifi?ref=backerkit</a><br>
>>>><br>
>>>>><br>
>>>>>>>><br>
>>>>>>>>> "Portal is the first and only router specifically engineered to cut<br>
>>>>>>>>> through and avoid congestion, delivering consistent,<br>
>>>>>>>>> high-performance<br>
>>>>>>>>> WiFi with greater coverage throughout your home.<br>
>>>>>>>>><br>
>>>>>>>>> Its proprietary spectrum turbocharger technology provides access to<br>
>>>>>>>>> 300% more of the radio airwaves than any other router, improving<br>
>>>>>>>>> performance by as much as 300x, and range and coverage by as much as<br>
>>>>>>>>> 2x in crowded settings, such as city homes and multi-unit<br>
>>>>>>>>> apartments"<br>
>>>>>>>>><br>
>>>>>>>>> It sounds like they are promising working DFS support.<br>
>>>>>>>>><br>
>>>>>>>>><br>
>>>>>>>> It's not clear what chipset they are using (they are claiming wave2)<br>
>>>>>>>> -<br>
>>>>>>>> but they are at least publicly claiming to be using openwrt. So I<br>
>>>>>>>> threw in enough to order one for september, just so I could comment<br>
>>>>>>>> on<br>
>>>>>>>> their kickstarter page. :)<br>
>>>>>>>><br>
>>>>>>>> I'd have loved to have got in earlier (early shipments are this month<br>
>>>>>>>> apparently), but those were sold out.<br>
>>>>>>>><br>
>>>>>>>><br>
>>>>>>>><br>
>>>>>>>><br>
>>>>>>>><br>
>>>> <a href="https://www.kickstarter.com/projects/portalwifi/portal-turbocharged-wifi/comments" rel="noreferrer" target="_blank">https://www.kickstarter.com/projects/portalwifi/portal-turbocharged-wifi/comments</a><br>
>>>><br>
>>>>><br>
>>>>>>>><br>
>>>>>>>><br>
>>>>>>>> --<br>
</span>>>>>>>>>> Dave Täht<br>
<span class="">>>>>>>>>> Let's go make home routers and wifi faster! With better software!<br>
>>>>>>>>> <a href="http://blog.cerowrt.org" rel="noreferrer" target="_blank">http://blog.cerowrt.org</a><br>
>>>>>>>>><br>
>>>>>>>>><br>
>>>>>>>><br>
>>>>>>>><br>
>>>>>>>> --<br>
</span>>>>>>>>> Dave Täht<br>
<div class="HOEnZb"><div class="h5">>>>>>>>> Let's go make home routers and wifi faster! With better software!<br>
>>>>>>>> <a href="http://blog.cerowrt.org" rel="noreferrer" target="_blank">http://blog.cerowrt.org</a><br>
>>>>>>>> _______________________________________________<br>
>>>>>>>> Make-wifi-fast mailing list<br>
>>>>>>>> <a href="mailto:Make-wifi-fast@lists.bufferbloat.net">Make-wifi-fast@lists.bufferbloat.net</a><br>
>>>>>>>> <a href="https://lists.bufferbloat.net/listinfo/make-wifi-fast" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/listinfo/make-wifi-fast</a><br>
>>>>>>>><br>
>>>>>>>><br>
>>>>>>>> _______________________________________________<br>
>>>>>> Make-wifi-fast mailing list<br>
>>>>>> <a href="mailto:Make-wifi-fast@lists.bufferbloat.net">Make-wifi-fast@lists.bufferbloat.net</a><br>
>>>>>> <a href="https://lists.bufferbloat.net/listinfo/make-wifi-fast" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/listinfo/make-wifi-fast</a><br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>><br>
>>>><br>
>>>><br>
>>>><br>
><br>
<br>
</div></div></blockquote></div><br></div>