Jump to content

On path to gigabit LTE, Sprint moving upload/download configuration closer to 12-1 traffic ratio


Recommended Posts

We max out at around 15 on the upload now, so what are we looking at here?

Configuration 1 to 2. It's been discussed in multiple places many times on the forums here.

 

Sent from my Pixel using Tapatalk

Link to comment
Share on other sites

Yeah I get that, tells me nothing about numbers. :P

 

Do not worry about it.  Think percentage.  Almost any percentage of 15 Mbps is a small number.  Trading 3 Mbps (20 percent) of a 15 Mbps max TDD uplink, for example, is not returning an additional 3 Mbps on a 90 Mbps max TDD downlink.  No, it is netting about an additional 18 Mbps (20 percent), a substantial difference.

 

Those are hypothetical examples, not actual values.  But do you get the point?  The uplink will be affected minimally.  What is lost will not be missed.

 

AJ

  • Like 5
Link to comment
Share on other sites

I've had no luck finding it.

It's 8 MBPS to answer your question. There's like 40 million forums on here not everyone knows how to find everything.

 

Sent from my 2PQ93 using Tapatalk

Link to comment
Share on other sites

Do not worry about it.  Think percentage.  Almost any percentage of 15 Mbps is a small number.  Trading 3 Mbps (20 percent) of a 15 Mbps max TDD uplink, for example, is not returning an additional 3 Mbps on a 90 Mbps max TDD downlink.  No, it is netting about an additional 18 Mbps (20 percent), a substantial difference.

 

Those are hypothetical examples, not actual values.  But do you get the point?  The uplink will be affected minimally.  What is lost will not be missed.

 

AJ

Thanks for explaining it that way.  It actually does make a lot more sense to me now as well. 

  • Like 1
Link to comment
Share on other sites

Just curious would Configuration 5 ever be a reality or makes sense for Sprint to deploy?  I know Configuration 5 only shows 1 uplink subframe but it would pretty much maximize the available downlink subframes.

Link to comment
Share on other sites

Just curious would Configuration 5 ever be a reality or makes sense for Sprint to deploy?  I know Configuration 5 only shows 1 uplink subframe but it would pretty much maximize the available downlink subframes.

 

I'll bet the bigger issue there is latency, which already isn't great when you compare to, e.g., T-Mobile's FD implementation (I've seen sub-20ms). If you're only handling uploads every once in awhile (comparatively) that'll manifest itself as higher RTTs I'd think, so you'd only want to do that if you're really capacity constrained.

 

Flip side of course is that you go from 20% of your slots being used by guards to 10%, so if raw bandwidth is what you're looking for that's an optimal configuration.

 

Doing some math here, assuming one upstream frame translates to 4.5 Mbps of real-world capacity and one downstream frame translates to 18 Mbps (hopefully I'll get corrected on these numbers if they're way off) you're going from 72/18 on config 1 to 108/9 on config 2 (hey look, 12:1!). Bumping all the way to config 5 (and incurring the latency penalty) would get you 144/4.5 on the same slice of spectrum.

 

One thing I'm not sure of here is whether you could use run different configs on the same cell site, e.g. running 3xCA with two at config 5 and one at config 2. That'd mitigate the latency penalty if devices could push their upload bits on the correct carrier and aggregate all the downstreams (plausible, since that'd basically be asymmetric CA like we're seeing now). But you'd have to run the same TD config on that same block of spectrum across the entire market (well, across an entire "island" of 2500) in order to avoid interference, which is I'm sure why Sprint couldn't do this while WiMAX was up, and why it took this long to flip the switch.

  • Like 1
Link to comment
Share on other sites

I'll bet the bigger issue there is latency, which already isn't great when you compare to, e.g., T-Mobile's FD implementation (I've seen sub-20ms). If you're only handling uploads every once in awhile (comparatively) that'll manifest itself as higher RTTs I'd think, so you'd only want to do that if you're really capacity constrained.

 

Flip side of course is that you go from 20% of your slots being used by guards to 10%, so if raw bandwidth is what you're looking for that's an optimal configuration.

 

Doing some math here, assuming one upstream frame translates to 4.5 Mbps of real-world capacity and one downstream frame translates to 18 Mbps (hopefully I'll get corrected on these numbers if they're way off) you're going from 72/18 on config 1 to 108/9 on config 2 (hey look, 12:1!). Bumping all the way to config 5 (and incurring the latency penalty) would get you 144/4.5 on the same slice of spectrum.

 

One thing I'm not sure of here is whether you could use run different configs on the same cell site, e.g. running 3xCA with two at config 5 and one at config 2. That'd mitigate the latency penalty if devices could push their upload bits on the correct carrier and aggregate all the downstreams (plausible, since that'd basically be asymmetric CA like we're seeing now). But you'd have to run the same TD config on that same block of spectrum across the entire market (well, across an entire "island" of 2500) in order to avoid interference, which is I'm sure why Sprint couldn't do this while WiMAX was up, and why it took this long to flip the switch.

That's how I imagined that this 12:1 configuration would work. PCC would be the normal 72/18 config, Maybe even one more oriented towards upload... and then SCC1 and SCC2 (SCC3 even?) could be the 108/9 configuration. I don't see why this couldn't work. Maybe WiWavelength could clear this question up.

Link to comment
Share on other sites

That's how I imagined that this 12:1 configuration would work. PCC would be the normal 72/18 config, Maybe even one more oriented towards upload... and then SCC1 and SCC2 (SCC3 even?) could be the 108/9 configuration. I don't see why this couldn't work. Maybe WiWavelength could clear this question up.

Any TDD configurations must be identical or separated enough that it doesn't cause catastrophic interference.

 

You cannot run adjacent tdd carriers using different frame configurations without substantial interference.

 

 

 

Sent from my Pixel using Tapatalk

Link to comment
Share on other sites

The keyword would be adjacent, right? Couldn't they in theory break them up to not be adjacent? They do own up to 120MHz able to be broken up into 20MHz chunks. Have Chunk A be PCC with Chunks C and E be SCC1 and SCC2. This would give them all a 20MHz gap inbetween

 

Edited to ask additional question. Couldn't the secondaries actually go from Chunks C, D, E, and F since they would all be the same time configuration not needing to be guarded from interference?

Link to comment
Share on other sites

The keyword would be adjacent, right? Couldn't they in theory break them up to not be adjacent? They do own up to 120MHz able to be broken up into 20MHz chunks. Have Chunk A be PCC with Chunks C and E be SCC1 and SCC2. This would give them all a 20MHz gap inbetween

 

Edited to ask additional question. Couldn't the secondaries actually go from Chunks C, D, E, and F since they would all be the same time configuration not needing to be guarded from interference?

Not all spectrum is contiguous and you need contiguous carriers for sprint b41 CA.

 

Having different tdd ratios anywhere near each especially at the UE and eNB causes substantial issues especially when doing CA.

 

Sent from my Pixel using Tapatalk

Link to comment
Share on other sites

Just because the signal is too weak to carry LTE to the device in your hand does not mean it is not there.  Signals go on forever until blocked/absorbed.  They just get weaker and weaker.  Even a -150dBm TDD signal could cause problems if not in time.  From tower to tower, signals go much further than down on the ground.  Up above the ground clutter, above buildings and trees, the towers see each other for very long distances.  The separation would need to be very great.

 

 

To give an example, look at the 800MHz distances from the border.  There is a reason why it is so great.  They seem excessive to us on the ground level.  But above the ground clutter (where we spend most of our time) signals can travel very far.

 

Robert

Link to comment
Share on other sites

Not all spectrum is contiguous and you need contiguous carriers for sprint b41 CA.

 

Having different tdd ratios anywhere near each especially at the UE and eNB causes substantial issues especially when doing CA.

 

Sent from my Pixel using Tapatalk

I did not know that. I thought CA was always about Spectrum that isn't contiguous.

 

Sent from my 2PQ93 using Tapatalk

Link to comment
Share on other sites

Does it? I've had my phone do CA with the 40978 and 41374 carriers.

 

Just those two carriers? Most likely what you saw was stuck data as your phone was switching between 1st + 2nd, and 2nd + 3rd. The SCC seems to update less often as the PCC EARFCN in the engineering screen for the devices I've been able to look at. Currently, non-contiguous CA is not enabled on the network. And I can't think of any devices (there may be one or two) that support non-contiguous B41 CA. 

Link to comment
Share on other sites

Just those two carriers? Most likely what you saw was stuck data as your phone was switching between 1st + 2nd, and 2nd + 3rd. The SCC seems to update less often as the PCC EARFCN in the engineering screen for the devices I've been able to look at. Currently, non-contiguous CA is not enabled on the network. And I can't think of any devices (there may be one or two) that support non-contiguous B41 CA.

It wasn't stuck data. This was real time info straight from the modem via NSG.

 

I actually have a screenshot from a few days back. This CA set up happens very often...

 

wnOngKg.png

Link to comment
Share on other sites

Just those two carriers? Most likely what you saw was stuck data as your phone was switching between 1st + 2nd, and 2nd + 3rd. The SCC seems to update less often as the PCC EARFCN in the engineering screen for the devices I've been able to look at. Currently, non-contiguous CA is not enabled on the network. And I can't think of any devices (there may be one or two) that support non-contiguous B41 CA.

I thought I remember you saying Samsung devices can use any Carriers while the LG G5 needed contiguous.

 

Sent from my 2PQ93 using Tapatalk

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

    • I've now seen how things work in Kobe, Hiroshima, and Osaka, as well as some areas south of Osaka (e.g. Wakayama, Kinokawa), and tried three more SIMs. The two physical SIMs (different branding for each) both use IIJ, which provides a Japanese IP address/routing on NTT, aleit LTE-only, so latency is ~45ms to Tokyo. The catch with NTT is that it uses two frequency bands (B42/3500 MHz LTE, n79/4900 MHz NR) that you're not going to get on an Android sold in the US, and I'm guessing that B42 would be helpful speed-wise on that network, as it doesn't have B41. I also found one place that doesn't have cell service: a vending machine in the back of the Osaka Castle tower. Or, rather, the B8/18/19 signal is weak enough there to be unusable. Going back to 5G for a moment, I saw a fair amount of Softbank n257 in Hiroshima, as well as in some train stations between Osaka and Kobe. 4x100 MHz bandwidth, anchored by B1/3/8, with speeds sometimes exceeding 400 Mbps on the US Mobile roaming eSIM. Not quite the speeds I've seen on mmW in the States, but I've probably been on mmW for more time over the past few days than I have in the US over the past year, so I'll take it. My fastest speed test was actually on SoftBank n77 though, with 100 MHz of that plus 10x10 B8 hitting ~700 Mbps down and ~80 Mbps up with ~100ms latency...on the roaming eSIM...on the 4th floor of the hotel near Shin-Kobe station. Guessing B8 was a DAS or small cell based on signal levels, and the n77 might have been (or was just a less-used sector of the site serving the train station). I'm now 99% sure that all three providers are running DSS on band 28, and I've seen 10x10 on similar frequencies from both NTT and SoftBank IIRC, on both LTE and 5G. I also picked up one more eSIM: my1010, which is different from 1010/csl used by US Mobile's eSIM unfortunately, as it's LTE-only. On the bright side, it's cheap (10GB/7 days is like $11, and 20GB for the same period would be around $15), and can use both KDDI and SoftBank LTE. It also egresses from Taiwan (Chunghwa Telecom), though latency isn't really any better than the Singapore based eSIMs. Tomorrow will include the most rural part of our journey, so we'll see how networks hold up there, and from tomorrow night on we'll be in Tokyo, so any further reports after that will be Tokyo-centric.
    • I think the push for them is adding US Mobile as a MVNO with a priority data plan.  Ultimately, making people more aware of priority would allow them (and other carriers) to differentiate themselves from MVNOs like Consumer Cellular that advertise the same coverage. n77 has dramatically reduced the need for priority service at Verizon where the mere functioning of your phone was in jeopardy a couple of years ago if you had a low priority plan like Red Pocket. Only have heard of problems with T-Mobile in parts of Los Angeles. AT&T fell in between. All had issues at large concerts and festivals, or sporting events if your carrier has no on-site rights. Edit: Dishes native 5g network has different issues: not enough sites, limited bandwidth. Higher priority would help a few. Truth is they can push phones to AT&T or T-Mobile.
    • Tracfone AT&T sims went from QCI 8 to 9 as well a couple years ago. I'm pretty neutral towards AT&T's turbo feature here, the only bad taste left was for those who had unadvertised QCI 7 a couple months ago moved down to 8. In my eyes it would have been a lot better for AT&T to include turbo in those Premium/Elite plans for free to keep them at QCI 7, while also introducing this turbo add on option for any other plans or devices. As it stands now only a handful of plans can add it, and only if you're using a device on a random list of devices AT&T considers to be 5G smartphones.
    • My Red Pocket AT&T GSMA account was dropped to QCI 9 about a year ago.  Most recently 8 for the last few years prior.  Voice remains at 5.
  • Recently Browsing

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