RAvirani

I’m noticing the same thing…

I can move those sites/sectors from the AT&T map to the T-Mobile map. @mikejeep - in the attached screenshot it looks like SCP knows that the NR connection PLMN (310260) is different than the LTE connection PLMN (310410). However, all the uploaded points are showing up with the LTE PLMN (310410) on my side. Is there a reason SCP is uploading these NR points with the LTE PLMN (310410) as opposed to the NR PLMN (310260)?

Right now, I’m requiring: PLMN, tech, NCI, PCI, band, NRARFCN, RSRP, timestamp and lat/long/accuracy …to record an NR point. What is unavailable in NSA mode? Maybe I can tweak the import algorithm to match points lacking information with an existing site?

Hm…I wonder if @mikejeep can help debug this on the app side. The website is ready to accept entries without a TAC - I actually manually tested it yesterday and ran into issues which should now be resolved. That being said, I unfortunately don’t have a 5G-capable android on T-Mobile to play with. I did indeed! My T-Mobile device died on the southern part of the peninsula, so I missed a couple sites between New London and Oil City. I was able to map AT&T/VZW the entire way, though.

Update - I figured out the issue and it should be resolved now. If you go into the Beta Crew Settings, you should be able to set your upload timestamp back and reupload the data. Let me know if it works for you now.

Do you see the TAC displayed as -1 in the exported file or is it blank/0? I took a look at your upload on Monday at roughly 12:30 and I’m not seeing any non-valid TAC values - not even -1s, 0s or blanks…

Hey @mikejeep - I just shot you a diagnostic from my new Galaxy Flip last night. I’m not able to see Verizon n5 in-app when connected to a midband anchor.

Let me take a look tonight.

Support for the -1 TAC is good to go now, so I'm ready whenever you are!

I am still thinking about both of these. My idea is to try to match points without a TAC to an existing site if possible. In the case an existing site can’t be found, I can list the TAC as unknown and allow the user to enter an “unconfirmed” TAC until someone maps the site correctly (with a TAC). Then the “unconfirmed” TAC will be overwritten with that TAC. How does that sound?

Weight limitation is a super common reason for using smaller antennas, however it doesn’t look like there is a weight limitation on this setup since it is on a rooftop. Weight limitations are much more common on utility poles, tall pipe mounts, etc. Another possible reason for the shorter antenna is site density. Using a higher-gain antenna can cause sector overlap (i.e. degradation of SNR and increased noise floor) if neighboring sites are close by. You can usually use a combo of mech/etilt to control the range of these higher-gain antennas, but that sometimes causes problems with vertical coverage. These problems are especially bad on sites with higher RAD centers as you’re effectively pointing the already-narrow beam into the ground. We run into these issues a lot in urban RF planning…

Lower gain figures in exchange for increased vertical beamwidth.

Awesome!

I’d recommend against using 0 because It’s actually possible to assign a TAC of 0 (in LTE the range is 0 to 65535 and in NR the range is 0 to 16777215). My thought process with -1 was that some sort of error could in theory cause a blank or an empty value to end up in an upload file. A -1 feels a bit more intentional. I’ll see if I can get the backend up and ready to go this weekend (hopefully before the app update is released).

Could we send the TAC as -1 if it’s invalid? Then, if there’s and existing site that matches the other info, I could match the web data entry up with it (despite the TAC being absent).

@mikejeep does SCP send NR points on upload if they’re missing a TAC?

If you could hold off through the weekend, I’m going to take a look at your uploads tonight. I might be able to edit the software on my side to match TACless data to an existing site with other matching attributes. I’m not sure how I’m going to handle sites not already in the DB if TACless data is uploaded though…

While Mike resolves the TAC logging issue, if you tell me what the TAC should be and when you uploaded the data, I can manually add your trail entries to the database.

The two big reasons for this are site density disparities and the complexity associated with the spectrum transition For example, consider a hypothetical town where Sprint has 5 sites with low RAD centers and T-Mobile has 3 sites with high RAD centers. Let’s assume neither carrier has a coverage problem (due to the difference in site placement/height), and that each T-Mobile site is broadcasting 20x20 MHz and each Sprint site is broadcasting 10x10 MHz. Right now, your total on-air spectrum volume in the town is 3 sites x 3 sectors/site x 40 MHz (T-Mobile) + 5 sites x 3 sectors/site x 20 MHz (Sprint) = 660 MHz-sectors. If you flip all of the spectrum over to T-Mobile today, your total on-air spectrum volume is 3 sites x 3 sectors/site x 60 MHz = 540 MHz-sectors. As you can see, in this example, there’s a significant capacity drop (18.18%) if you don’t offload onto Sprint sites. Plus, this example assumes that all Sprint spectrum can be flipped over to T-Mobile, which isn’t necessarily true. The 5x5 800 MHz carrier won’t be used by T-Mobile, and in areas where T-Mobile hasn’t deployed 2500 equipment, 2500 MHz spectrum can’t be moved over either. Going back to the earlier example, if we assume the Sprint sites are broadcasting 5x5 L1900 and 5x5 L800, only 5x5 MHz of spectrum can be moved over to T-Mobile. So, if all the traffic were pushed over T-Mobile, the on-air spectrum volume would really be 3 sites x 3 sectors/site x 50 MHz = 450 MHz-sectors. That’s a 31.81% decrease in capacity. Even worse.

This is likely due to load balancing. In certain areas, we’ll set up mobility parameters to release users to a less loaded cell, even if it’s RSRP is lower (think NR event A4). These sorts of configs can get super complex due to degradation in SNR or BER, though (especially for cells on the same channel).

VZW CDMA-less devices have been roaming on T-Mo WCDMA/HSPA for some time now. I suppose it’s about time T-Mo users were able to use VZW LTE.

I did not unfortunately. The software can and does account for antennas that support beamforming - I just don’t have the antenna files.

PCS. I don’t have AAHF or AEHC radiation patterns so I can’t simulate 2500 coverage unfortunately.

Just the map canvas. It’s easier to see where mall/big box stores are on a satellite map than a roadmap (at least in my opinion).

I actually have those Commscope antennas in inventory now plus a bunch of SignalCheck drive test data in that area, so this should be pretty accurate: https://imgur.com/a/j4959Tl Mostly QPSK/16QAM.