RAvirani

15x15 L1900 + L2500.

They didn't. That's a 15 MHz L1900 carrier aggregated with L2500.

Yes, interband CA has gone live in Portland as well as several other major markets. You're seeing 15 MHz L1900 UL in that speedtest.

Yes we do. 60 MHz NR + 60 MHz LTE on M-MIMO equipment. DSS will be deployed soon as well, making it 60 MHz NR + 60 MHz LTE/NR (simultaneously). A separate 40-60 MHz will remain used for LTE on small cells/MBs. As far as LTE goes, Sprint runs between 60 MHz and 100 MHz on macro sites with 20-60 MHz used for small cells/MBs. The actual numbers vary from market to market. In Seattle, Sprint runs 100 MHz of L2500 on macros, 40 MHz on small cells, and MBs have their own dedicated channel. Only in areas lacking contiguous spectrum. 60 MHz will be the norm. Let's not start this discussion again, please.

This page is fairly accurate: https://5g-tools.com/5g-nr-throughput-calculator/ Here are the NR TDD configs: https://imgur.com/a/RswhH8p

Are you able to provide any more details? Perhaps via private message?

Yes, as soon as equipment is flex-config ready.

There is very good service along 405 in that area. A site may have been down for upgrades/maintenance. Yes, that sounds about right. Sprint needs to do something about that area.

South Center hill as in going south on I-5 from the junction of 405 and I-5? If so, that area is in dire need of a site; Sprint is the only carrier without one by exit 152. A while back, there were talks of colocating onto the monopole at (47.4332995, -122.2696476), although they never really happened and I'm not sure if that site is still in planning. A dropout in downtown Bellevue? Where along the highway (exit number)? I live right around there and I've never had an issue...

I'm not pulling data in a traditional way, as Apple has locked all that info down. Rather I'm playing with some image processing that can interpret and log data that appears on the field test screen. Thought it would be something interesting to fiddle around with.

There is only so much money to go around. Improving the data speed in those areas will cost giving up speed somewhere else, and likely somewhere they have more market share. Sprint does prioritize certain markets and let other markets struggle. That's what you've got to do when you're stretched for money/resources. It sounds like the vast majority of markets are seeing good improvements. I definitely view these results as positive overall.

Yeah until the upload issues are resolved, no matter how great the download speeds, Sprint is unlikely to win any RootScore awards.

. 15x15 @ 8615 includes the G block so it wouldn't be possible to aggregate that with the 8665 G block carrier.

Sprint will be running 100 MHz of NR when DSS is ready. Of course, all of that spectrum won't consistently be available due to LTE traffic, but it will definitely be a step up from the 40-60 MHz they are using now. Keep in mind massive MIMO radios have a 120 MHz bandwidth limit. Sprint cannot broadcast more than 120 MHz (NR, LTE or both) through a single massive MIMO antenna. BWs greater than 100 MHz are only standardized for n257/n258/n260/n261. n41 is 2496-2690 MHz. Only 194 MHz are contained by the band. The largest NR carrier that would fit is 100 MHz. The only channel sizes greater than 100 MHz are 200 MHz and 400 MHz.

NR timeslots are not strictly DL/UL. There is also something called a flex timeslot. This are dynamically allocates to DL or UL as needed. NR TDD config 2 is exclusively flex timeslots. I'm hoping we see Sprint move towards this setup in the future as it gives the network ultimate flexibility, although I'm hearing equipment isn't ready for flex configs as of today.

Yes it is. Where are you experiencing issues? I'm from Seattle and pretty well connected with the network team there so I'm curious.

That's actually just 5x5+5x5. Download BW of 25 is 5 MHz.

Ah, understood. Thanks!

Hey Mike, I'm not terribly familiar with SCP, but was a little curious how logging/notes work? Are they synced to a centralized database? I'm playing with a way to potentially log site data by GCI/EARFCN on iPhones and was considering tying it into SCP data, if possible.

"Upload is used more than downloads" is not justification for hundreds of megabits of excess downlink capacity and 1-2 megabits of excess uplink capacity. This is spot on.

That is correct, the XMM7660 is what Apple is using this year. They resolved their dispute with Qualcomm too late to switch over to their modems this year.

If my memory serves me correctly, Sprint deployed seven 9-beam fast-roll-off antennas at the stadium. This is 126 (9 beams * 2 tx/rx rows per antenna * 7 antennas) times the capacity of an average site and comes without the interference/SNR concerns we have in the real world. Don't forget that capacity was supplemented by other basic COWs and macros which covered the parking lots and other areas around the stadium. The super bowl is absolutely NOT a model for Sprint's performance across the rest of the network. This is exactly the point I'm making. Sprint needs to address upload speed problems, not download speed problems. 45x15 doesn't do that. 20x20+15 MHz TDD or even 20x35 would be a much better addition to Sprint's spectrum portfolio. Imagine Sprint's current DSS setup (40-60 MHz N2500 + 3x20 MHz L2500) aggregated with an additional 35 MHz of NR uplink. Now that would be a hell of a network. 2x is live nationwide. 3x is not deployed, but there aren't any devices that support it, so it doesn't really matter.

Sprint's UL on L2500 is slammed right now. How else could they have the fastest download speeds and the lowest speed score in many cities across the country according to RootMetrics? Speeds like these are unfortunately common on L2500: Don't forget, a 9 megabit pipe can be fully consumed by a few people facetiming or live-streaming. And those kind of things are becoming more and more popular. The Super Bowl is probably the worst example you could have picked to make this point. Sprint had a DAS and several multibeam antennas deployed across the stadium and surrounding areas. This type of high-capacity setup is most definitely the exception, not the norm. How often do you speedtest lower download than upload on Sprint? I'd guess almost never. But how often is the downlink stable while the uplink is unusable? At least in my experience traveling across the country, its's quite often. Most large studies/online reviews tend to agree as well. If you already have excess downlink capacity when in mid/high band coverage areas while the uplink is struggling, why ignore the problem when you have a chance to solve it?

That is also possible, but that will just exacerbate Sprint's poor upload problem. You would be adding 45x15 to Sprint's spectrum portfolio. That's a 3:1 ratio, but it will perform closer you a 6:1 or 7:1 ratio speed-wise (FDD UL tops out at about half FDD DL, and this problem will be exaggerated by higher order downlink MIMO). This is the problem with L2500 all over again. I'm not saying a 15 MHz UL carrier is anything to frown at, but with 2500 already favoring downloads, I'd much prefer a symmetrical setup. B70+B66 also closes the door on PCS H+G+C DSS which may be possible (someone more familiar with power limit regulations/interference potential can likely chime in with a definitive answer here).

Band 70 is a hodgepodge of three different bands: 15 MHz of AWS-3 (1695-1710) 10 MHz PCS H Block (1915-1920, 1995-2000) 40 MHz of AWS-4 (2000-2020, 2180-2200) The downlink is PCS H DL+AWS-4 UL and the uplink is AWS-3. This effectively wastes 25 MHz of spectrum (PCS H UL and AWS-4 DL). I would much prefer 20x20 B23 and TDD or UL-only AWS-3. If PCS H block NR can be deployed alongside PCS G and possibly PCS C with DSS, I'd welcome that too, although I'm not sure if that would be possible due to interference concerns (PCS H DL likely cannot sit directly next AWS-4 UL). But, even if the PCS H block was abandoned, it's better to waste 10 MHz than 25 MHz.