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

[jf15219]

http://www.fiercewireless.com/tech/path-to-gigabit-lte-sprint-moving-upload-download-configuration-closer-to-12-1-traffic-ratio

 

Sent from my LG-LS993 using Tapatalk

[BlueAngel]

http://www.fiercewireless.com/tech/path-to-gigabit-lte-sprint-moving-upload-download-configuration-closer-to-12-1-traffic-ratio

 

Sent from my LG-LS993 using Tapatalk

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

[lilotimz]

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

[BlueAngel]

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

 

Sent from my Pixel using Tapatalk

I've had no luck finding it.

[cyclone]

 

D = Download

S = Guard

U = Upload

[BlueAngel]

 

D = Download

S = Guard

U = Upload

Yeah I get that, tells me nothing about numbers.

[WiWavelength]

Yeah I get that, tells me nothing about numbers.

 

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

[Tengen31]

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

[BlueAngel]

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

Thanks.

 

Sent from my SM-N920P using Tapatalk

[JonnygATL]

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. 

[red_dog007]

Plus once UL gets 2xCA, well be back at to where we are now .

[ericdabbs]

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.

[iansltx]

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.

[shannonbrian]

Wonder when this going s

start.

[jakeuten]

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.

[lilotimz]

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

[cyclone]

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?

[lilotimz]

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

[S4GRU]

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

[Tengen31]

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

[Dkoellerwx]

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

 

Sent from my 2PQ93 using Tapatalk

 

For TDD-LTE (B41) CA, it needs to be contiguous. 

[greenbastard]

For TDD-LTE (B41) CA, it needs to be contiguous.

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

[Dkoellerwx]

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. 

[greenbastard]

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...

 

[Tengen31]

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