caleuche

no repeat of the behavior today, though. might have been a one time thing Sent from my iPhone using Tapatalk

I am also vaguely suspicious that the fact that I have an Apple Watch has something to do with it. things seemed normal until this morning when my watch popped up the weekly activity report - and froze. I had to reboot the watch to unfreeze that. after that my 30 minute drive to work resulted in a loss of about 40% of the phone battery which normally only loses a few percent during that drive. Sent from my iPhone using Tapatalk

without having solid data, it seems like battery life is much worse on a non-s iPhone 6 Plus. mix of LTE and wifi use, public beta 2 Sent from my iPhone using Tapatalk

Because 20 MHz in QPSK at a 1/2 code rate is still fast. Sent from my Droid DNA

You could collect 100 ms of voice, encode it, and then transmit for 10 ms for low order modulation or 6 ms for high order and so on, then at least you wouldn't be transmitting 90-95 percent of the time. The downside of that is the power consumed in buffering and encoding probably negate the advantage of that duty cycle. I imagine the codec is going to use mp3 sized frames (5000 or so samples iirc).

Ok, lets think about it. 50 million customers and 30000 towers gives, let's say, 1600 subscribers per tower (and the rule of thumb is supposed to be 350 subscribers per sector so that would be high but it should give an order of magnitude). Going per sector, 533 users each streaming 192 kbps audio would be 102.3 mbit per second. A third of the radius of the sector will be 64QAM, the next third at 16QAM, and the outlying third QPSK (again going rule of thumb), and 160 MHz would provide 160 million symbols per second, so presuming an average of 2/3 FEC and 16QAM would give you 533 mbps per layer per sector. If the deployment is 2x2 MIMO (2 spatial layers) without other overhead we could expect about 1066 mbps delivered, of which our hypothetical audio streaming alone would consume a tenth of. That's actually not bad. If you presume that they all are streaming netflix on top of that it would put it over the top though. You get about 2 mbps per second per user on average, and depending on how fairness is set up that would support the average user streaming netflix. That's without coding and control overhead as well as IP and udp or tcp overhead. Realistically you could probably expect about 1.4 mbps per user. So yes, 160 MHz is quite a bit, enough for everyone to stream audio, not quite enough for everyone to stream netflix. You can see why though if they are stuck with a single 5 mhz lte channel the problem is substantial, that's only about 16 mbps per sector and therefore only about 31 kbps per user (and maybe 22 kbps realistically) As it is, there certainly must be a significant amount of hope that everyone doesn't suddenly start treating their unlimited handsets as really unlimited.

I think it depends on how users use that unlimited data. Even 160 MHz wouldn't be enough if every sprint customer were streaming pandora 12 hours a day. Sent from my Nexus 7 using Tapatalk 2

Real signal (android app) would show independent 1x and EVDO signal strengths, perhaps it has been updated for LTE as well. Sent from my Nexus 7 using Tapatalk 2

Were you able to do anything with that connection? With LTE there would need to be a little bit of configuration to allow for that long of a propagation / light speed delay, I'd think.

Why is it not as effective with WCDMA (as opposed to OFDM MIMO?) I had not seen that anywhere yet. Sent from my Nexus 7 using Tapatalk 2

And non contiguous carrier aggregation doesn't appear in the specification until HSPA release 9 (and four carriers of any band in r10 hspa), but the impact on the handset (as mentioned by Qualcomm anyway) is minimal. Sent from my Nexus 7 using Tapatalk 2

I think tmobile's 42 mbit is from MIMO rather than DC (which would make sense, MIMO is increasing the throughput of the entire sector while DC wouldn't be increasing throughput all that much.

Meaning, of course, now I will read the r10 TS too. However, I already think the sub carriers in r8 are basically treated independently from a radio standpoint, they're just controlled from a single control channel and even with this not being the case, an fft isn't that hard these days, this isn't 1998. At worst I think if could be looked at as another spatial diversity layer that happens to be in another band. But I haven't even downloaded the r10 spec yet. It should be no worse than HSPA carrier aggregation, which is deploying in some places worldwide.

Sure, but there were other comments to the effect of sprint should avoid LTE rel.10 carrier aggregation in the future when those resources are available, and I don't really follow the reasoning for that. Sent from my Nexus 7 using Tapatalk 2

Turns out the 2048 is FFT length, and for 1200 carriers / 2048 * 30.72 MHz (as you computed) = 18 MHz, the real bandwidth of a 20 MHz LTE channel. So, that makes sense. I've been reading through the LTE specifications and would like it if it were simply outright stated as a UE requirement. It does appear to me through the specification that it is assumed that a UE must be able to receive the full 1200 carriers (though it's usually stated in terms of resource blocks) and other interesting things that I didn't know, such that asymmetrical FDD channels are not precluded, but the closest I had found so far to defining a UE requirement was something to the effect of" the ue shall implement each of the items in table such and such"where the table indicated the list of channel bandwidths. That in TS 136-101, but it wasn't worded exactly how I said and it's still not clear to me. Also there seems to be a provision for carrier spacing of 7.5 kHz as well as 15 kHz, for MBMS (a mediaFLO like standard, I suppose?) I think I can show in terms of average sector throughput it should be better to use a single 10 MHz channel instead of two 5 MHz channels no matter what the radio environment, but there's quite a bit more of the specification to read and I still maintain that when you are near the cell edge, 10 MHz at 2/3 QPSK is going to be much more usable than 5 MHz. Again, that point about single user performance is trivial to the overall point that geographic sector throughput is improved. Sent from my Nexus 7 using Tapatalk 2