<div dir="ltr">I share your skepticism about beam forming. It depends of course on the kind<div>of usage you make of wifi. If it's to cover a city in a small cell optimized deployment </div><div>I don't think beam forming is going to help. When cell traffic is high only TDMA can help.</div><div><br></div><div>If you use beam forming to reach non mobile users and traffic is not to high it's going to </div><div>give best performance.</div><div><br></div><div>Both are valuable use cases with economic incentives behind.</div><div>The first one is more difficult and time fairness is gonna help a lot there</div><div>as the average cell throughput is gonna be a lot better.</div><div><br></div><div> </div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 11, 2016 at 8:13 PM, Dave Taht <span dir="ltr"><<a href="mailto:dave.taht@gmail.com" target="_blank">dave.taht@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wed, May 11, 2016 at 9:41 AM, Dave Taht <<a href="mailto:dave.taht@gmail.com">dave.taht@gmail.com</a>> wrote:<br>
> On Wed, May 11, 2016 at 9:09 AM, Luca Muscariello<br>
> <<a href="mailto:luca.muscariello@gmail.com">luca.muscariello@gmail.com</a>> wrote:<br>
>> Correct, but in between that time and now a lot has been done in different<br>
>> areas but not much on this point.<br>
>> The fact that some part of the industry is looking at LTE-U is also because<br>
>> 802.11 standard is not good enough.<br>
><br>
> What do you think of LTE-LAA?<br>
><br>
> I do think very strongly that actual usage of 802.11 can be made<br>
> vastly more efficient, that we can use up a great deal of the mac<br>
> currently being left unused, and schedule txops way more efficiently -<br>
> and that I'd love to test with michal's patch set against the LTE-U<br>
> tests cablelabs, etc which did<br>
><br>
> 100 stations before (stock):<br>
><br>
> <a href="http://blog.cerowrt.org/flent/drr/10tothe5.svg" rel="noreferrer" target="_blank">http://blog.cerowrt.org/flent/drr/10tothe5.svg</a><br>
><br>
> after<br>
><br>
> <a href="http://blog.cerowrt.org/flent/drr/newcode.svg" rel="noreferrer" target="_blank">http://blog.cerowrt.org/flent/drr/newcode.svg</a><br>
<br>
</span>Seeing "only" 250ms worth of delay for 100 stations here was what<br>
kicked off a prior thread, my understanding of a theoretical base<br>
number here would be about 70ms. (?)<br></blockquote><div><br></div><div>I miss many details about these tests. And probably I missed the thread...</div><div>Can you give me pointers?</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
...<br>
<br>
Adding in mu-mimo to the picture makes my head hurt. My understanding<br>
of how mu-mimo is supposed to work is you have to have accumulated<br>
2-3ms worth of packets for the number of stations you are going to<br>
schedule before it's worthwhile at all.<br>
<br>
The stations are going to typically be limited to 1 antenna (most<br>
laptops have 2), I think. So a 4 antenna system *could* send to 4<br>
stations if all have traffic pending... at a cost of a (proposed, I<br>
don't agree with it) 500 usec sounding phase every 10ms. My take on<br>
that is you should only sound when you actually have some potential to<br>
share that many flows to that many stations, sounding being more of an<br>
aspect of rate control, also.<br>
<br>
Having only 2 stations that you can mu-mimo to seems like a lose generally.<br>
<br>
Based on normal traffic behaviors the stations that could be sent to<br>
varies, and gang scheduling with lots of stations would require even<br>
more soundings...<br>
<br>
...<br>
<br>
I don't have a lot of hope for mu-mimo, although what I kind of expect<br>
is the work done here will end up marketed as due to that feature in<br>
the wave2 stuff...<br>
</blockquote></div><br></div></div>