Jump to content

3G IS flying for me


Recommended Posts

At least some Msm8960 devices had planned support for even 15 and 20 MHz channels (mentioned here http://www.anandtech...-usa-variants/8 though I'd seen it on Qualcomm product papers too). I realize that there's more to it than chipset support but it doesn't seem like it would have been difficult to get 10 MHz support in

 

Very true. This is not an issue with the MSM8960 baseband. Rather, it may be an issue with the ancillary equipment (e.g. RF transceiver, power amps, antennas). Or it may just be an issue with the decisions of the OEMs, carriers, and FCC authorized testing labs. If the testing lab does not test and report on a particular LTE FDD configuration, then that configuration cannot be used on said device.

 

AJ

Link to comment
Share on other sites

 

Well, 2048 LTE subcarriers would have an occupied bandwidth of 30.72 MHz. So, that would not be the 20 MHz configuration. For example, LTE FDD 5 MHz configuration (Sprint and AT&T) occupies 4.5 MHz bandwidth and uses 300 subcarriers, while LTE FDD 10 MHz configuration (VZW and AT&T) occupies 9 MHz bandwidth and uses 600 subcarriers. LTE FDD 20 MHz configuration would occupy 18 MHz bandwidth and use 1200 subcarriers. While it may be that all LTE basebands must be fully capable of receiving 2048 subcarriers, no real world network that I know of even approaches that configuration.

 

As an aside, writing this post made me think that a great T-shirt slogan for wireless nerds would be "Occupy Bandwidth."

 

AJ

 

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

Link to comment
Share on other sites

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.

 

I do not think that anyone is arguing that 10 MHz FDD has no advantages in theory. However, I would like for you to elaborate on your cell edge contention. The scenario that I think you are suggesting is that 10 MHz FDD has twice as many Resource Blocks available, hence a cell edge user that has radio conditions that can support only a very low modulation and coding scheme (e.g. QPSK and 1/2 FEC) can be assigned effectively twice as many RBs to maintain higher throughput.

 

But the above scenario assumes that all other factors are equal. In actual practice -- as deployed by VZW -- 10 MHz FDD is not necessarily equal in all other factors. Compared to Sprint, VZW has twice as many subs (a reasonable approximation) and LTE cells twice the size (a ballpark estimate). Some back of the napkin math has VZW trying to support four times as many subs per cell on only twice the bandwidth. Yeah, 10 MHz will still hit twice the peak speeds of 5 MHz FDD, but its average speeds should be no better, nor should its average cell edge speeds, as proportionally many more users are competing for those RBs.

 

I think the biggest reason for pushback, though, is simply that Sprint cannot realistically deploy 10 MHz FDD in more than a handful of markets right now and not in a majority of markets until the EV-DO shutdown in 3-5 years. So, with Sprint, 10 MHz FDD is just not in the cards for a while. Plus, VZW's parent company is becoming an awful, awful corporation -- almost on par with AT&T -- that wants to shirk its responsibility to compete in the wired broadband market. So, VZW should get no love from anyone who respects what is good for the domestic wireless industry and connected America as a whole.

 

AJ

Link to comment
Share on other sites

Ahhhh!! My head is starting to hurt. To much technical information to absorb in one sitting. Can you two speak at a normal intellegence level for us retards that are trying to understand what you are talking about?

 

Just kidding of course, this is some good info.

Link to comment
Share on other sites

 

I think the biggest reason for pushback, though, is simply that Sprint cannot realistically deploy 10 MHz FDD in more than a handful of markets right now and not in a majority of markets until the EV-DO shutdown in 3-5 years. So, with Sprint, 10 MHz FDD is just not in the cards for a while. Plus, VZW's parent company is becoming an awful, awful corporation -- almost on par with AT&T -- that wants to shirk its responsibility to compete in the wired broadband market. So, VZW should get no love from anyone who respects what is good for the domestic wireless industry and connected America as a whole.

 

AJ

 

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

Link to comment
Share on other sites

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.

 

I will be happy to be proven incorrect, but my understanding is that Release 10 non contiguous carrier aggregation (whether intra- or inter-band) requires a separate FFT for each carrier to be aggregated. And that will require handsets to have substantially greater radio resources at their disposal. Thus, I remain unconvinced that non contiguous carrier aggregation is going to be commonplace anytime in the next several years.

 

AJ

Link to comment
Share on other sites

3G has been acting funny the last couple of weeks, sometimes its fast and sometimes its not. Im currently in the NYC/ North New Jersey area and have yet to see ePHRD on my phone at all so im guessing that NV has started or not. I cant wait for LTE.

Link to comment
Share on other sites

 

I will be happy to be proven incorrect, but my understanding is that Release 10 non contiguous carrier aggregation (whether intra- or inter-band) requires a separate FFT for each carrier to be aggregated. And that will require handsets to have substantially greater radio resources at their disposal. Thus, I remain unconvinced that non contiguous carrier aggregation is going to be commonplace anytime in the next several years.

 

AJ

 

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.

Link to comment
Share on other sites

It should be no worse than HSPA carrier aggregation, which is deploying in some places worldwide.

 

But, to this point, DC-HSPA+ is all contiguous carrier aggregation. To my knowledge, no one -- certainly not T-Mobile USA -- has deployed any non contiguous DC-HSPA+.

 

AJ

Link to comment
Share on other sites

 

But, to this point, DC-HSPA+ is all contiguous carrier aggregation. To my knowledge, no one -- certainly not T-Mobile USA -- has deployed any non contiguous DC-HSPA+.

 

AJ

 

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.

Link to comment
Share on other sites

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.

 

Nope, just the opposite. T-Mobile's HSPA+ 42 is entirely Release 8 Category 24 (i.e. DC-HSPA+). T-Mobile has not deployed MIMO, which is not as effective with W-CDMA and somewhat detrimental to non MIMO mobiles.

 

As an addendum, this is why some T-Mobile markets are only HSPA+ 21. In those markets, T-Mobile has only a single AWS 10 MHz license or two non contiguous AWS 10 MHz licenses.

 

AJ

Link to comment
Share on other sites

 

But, to this point, DC-HSPA+ is all contiguous carrier aggregation. To my knowledge, no one -- certainly not T-Mobile USA -- has deployed any non contiguous DC-HSPA+.

 

AJ

 

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

Link to comment
Share on other sites

 

Nope, just the opposite. T-Mobile's HSPA+ 42 is entirely Release 8 Category 24 (i.e. DC-HSPA+). T-Mobile has not deployed MIMO, which is not as effective with W-CDMA and somewhat detrimental to non MIMO mobiles.

 

As an addendum, this is why some T-Mobile markets are only HSPA+ 21. In those markets, T-Mobile has only a single AWS 10 MHz license or two non contiguous AWS 10 MHz licenses.

 

AJ

 

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

Link to comment
Share on other sites

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.

 

The impact on non MIMO devices may be "minimal," but it is present, as those non MIMO devices cannot take advantage of the MIMO pilot. Hence, they experience it as added interference.

 

AJ

Link to comment
Share on other sites

Why is it not as effective with WCDMA (as opposed to OFDM MIMO?) I had not seen that anywhere yet.

 

I consider myself to have only rudimentary understanding of the matter, but I believe that MIMO is more effective with LTE (OFDMA) and less effective with W-CDMA because of two factors:

  • LTE symbol rate is much slower than that of W-CDMA, thus more resilient against multipath.
  • LTE FDMA allows MIMO to be applied across only selected Resource Blocks, as appropriate.

AJ

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • large.unreadcontent.png.6ef00db54e758d06

  • gallery_1_23_9202.png

  • Posts

  • Recently Browsing

    • No registered users viewing this page.
×
×
  • Create New...