Note: This content first appeared February 1, 2022 on LinkedIn and is authored by Adam Wohld, RF Deployment Engineer and Solutions Architect. Adam's post is being republished on our blog in its entirety. We thank Adam for his excellent contribution to our blog series.
I've been contacted by a number of TDD-LTE CBRS network operators about interference concerns since the launch of CBRS.
By the time these issues reach me it's usually an emergency. Once when discussing the issue with a WISP CEO, he interrupted me as a customer cancellation email hit his inbox and raged, "$%&^, we're bleeding out all our customers!" Last week, this occurred again, and I took a few vacation days to travel on-site and document the issue. In this article, I'll demonstrate what we found and how we found it.
Network "Operator X" [real name redacted] called with high noise rise on their CBRS channels. The interference couldn't be seen on a Spectrum Analyzer. To resolve, we used Epiq Solutions' PRiSM PCI Scanner to inspect the upper LTE protocol layers that a spectrum analyzer can't see.
The PRiSM PCI Scanner found three eNB's from two other network operators within Operator X's footprint. The eNB's SIB1 message decoded by the PCI scanner showed Operator X's eNB was configured to receive at the same time the foreign eNB was configured to transmit. The transmit energy from the foreign eNB is the source of Operator X's interference.
If you're having this problem or are interested in using the PRiSM PCI Scanner, feel free to reach out to me.
When I investigate interference it follows this general format:
To get an idea of the problem scope, we mapped eNB locations and antenna azimuths presenting with noise rise issues. Mapped out below, two sites indicate noise coming from the North and West. The stats indicated the strongest noise coming from the North facing antennas.
If the noise was coming from the site itself, we'd expect to see all antennas with noise rise. Here, only two of the three antenna azimuths register a noise problem. Likely the source is more to the North, than West, since the North sectors show the strongest noise rise.
When interference hunting we want to characterize the offending signal for the search phase in step #3. Unfortunately, we didn't have access to noise per PRB stats from the LTE antenna or a radio tap point for directly monitoring the antenna signal. The only option to characterize was a less-than-ideal, onsite, under-the-tower visit.
After a 7 hour drive to the land of 8-degree weather, I arrived at the site and mounted the PRiSM PCI Scanner to my dash using PRiSM's neodymium magnetic mounting system.
I put the PRiSM PCI Scanner into "Spectrum Analyzer" mode and dialed in the two EARFCNs, 56442 and 56640, reporting the strongest noise rise; 15 dB above the noise floor.
Looking at the results above, it appeared to be interference-free. We see two nice-looking LTE bart-heads on the peak hold, no spikes on the minimum hold, and normal customer traffic in the channel. I also drove in and out of town watching the spectrum, nothing looked abnormal.
This is where network operators get stuck. They're looking at the RF layer, blind to the upper layers of TDD-LTE that also cause interference. To do this they need a PCI Scanner.
However, I do have a PRiSM PCI Scanner to inspect the upper layers of the protocol and I booted it into "Blind Scan" mode. Blind scan mode will detect, analyze, and report on any LTE or 5G waveform energy found in any spectrum from 50 MHz to 6 GHz. I told it to just look at the CBRS band.
After a brief survey, the PRiSM PCI Scanner returned some alarming results. From now on, in this article, we'll limit the scope and focus only on Operator X's two EARFCNs (56442 and 56640) reporting the worst interference.
As expected, we see EARFCN 56442 ( 3.6702 GHz ) and 56640 ( 3.690 GHz ) broadcasting MCC/MNC 311/XXX. This positively identifies these signals as belonging to "Operator X".
Unexpectedly, we find two other TDD-LTE CBRS networks reporting MCC/MNC 314/030 (BaiCells) and 001/010 (Generic). Looking at both network's MIB messages broadcast on the upper layers of the protocol, we see those networks claim a 20 MHz channel bandwidth and transmit on EARFCN 56350 ( 3.661 GHz ) and 56540 ( 3.680 GHz ).
Analyzing the EARFCNs and channel bandwidths we've found, we can see both MCC/MNC 314/030 and 001/010 overlap in the frequency domain with Operator X's TDD-LTE channels.
Now that we identified foreign network TDD-LTE cells overlapping in the frequency domain, we need to make sure they are not transmitting when Operator X's tower is receiving. If this is the case, then we likely found an interference source.
To know a TDD-LTE cells uplink & downlink TDD frame pattern, we examine the "subframeAssignment" parameter broadcast in the SIB1 overhead message. This pattern tells a UE which subframes in a frame are reserved for uplink or downlink transmission.
Looking back at the PRiSM PCI Scanner results, we grab the SIB1 payload for each TDD-LTE Cell found and decode the "subframeAssginment" parameter.
The results show Operator X and network 314/030 both running "subframeAssgnment" pattern #1 while network 001/010 runs "subframeAssignment" pattern #2.
Looking up these patterns in the table below, this means Operator X and 314/030 both transmit and receive at the same time. This is likely not the source of the uplink interference. However, 314/030's UE's may degrade uplink performance for Operator X's customers.
Looking at network 001/010 is where we find the big problem, they're running "subframeAssignment" pattern #2 and Operator X is running pattern #1!!
Referring to the "subframeAssignemnt" pattern chart, when network 001/010 is transmitting on subframe #3 and #7, both Operator X and 314/030 are listening for UE transmissions on those frames. Operator X and 314/030 eNBs are receiving downlink energy from network 001/010 TDD-LTE Cells right into their uplink path.
At this point, we concluded the characterizing the problem and got into drive test mode.
To search we used the PCI Scanner in "Dedicated Scan" mode and an omni antenna. In dedicated scan mode, we continuously report RSRP of MCC/MNC 314/030 EARFCN 56350 and MCC/MNC 001/010 EARFCN 56540.
Knowing the signal was likely coming from the north, we headed off in that direction and watched the RSRP strength of MNC/MCC.
After 20 minutes of driving, we located two TDD-LTE transmitters on MCC/MNC 314/030 EARFCN 56350 and MCC/MNC 001/010 EARFCN 56540. On the way back to the hotel we located one more TDD-LTE system on MCC/MNC 001/010 EARFCN 56540. Results mapped below.
At location #1 we found a MCC MNC 001/010 tower about 17 miles from Operator X's sites. The MCC MNC 001/010 site transmits when Operator X's site is receiving. With 132 dB path loss at 3.7 GHz, 50 dBm eNB transmit EIRP over 20 MHz, and assumed 12 dB gain receive antenna for Operator X, we calculate -70 dBm RSSI interference at the receive radio port of Operator X.
At location #2 we found another MCC MNC 001/010 tower 10 miles away from Operator X's site presenting with the worst interference. This site transmits when Operator X's site is receiving. With 128 dB path loss at 3.7 GHz, 50 dBm eNB transmit EIRP over 20 MHz, and assumed 12 dB gain receive antenna for Operator X, we could see -66 dBm RSSI interference at the receive radio port of Operator X.
Finally, at location #3, we found network 314/030 8 miles from Operator X's site with the worst interference. Since both these sites transmit and receive at the same time there should be no issues. However, if their frame start time is not aligned, as I've seen happen in other BaiCell/Ericsson networks, this could be an interference issue. In a few months, the PRiSM PCI Scanner will be able to detect this.
CBRS spectrum allocation is about more than frequency, it's also about timing. Being able to survey and inspect neighboring site configurations over the air is critical to maintaining LTE and 5G performance on CBRS.
Equipping engineers and technicians with PCI scanners like PRiSM will result in quicker resolution of these issues which are not visible to a spectrum analyzer: saving revenue and customer frustration.
In short, if you're operating a CBRS network: scan your spectral neighborhood, become familiar with your spectral neighbors, and make sure everyone plays nice with timing.
If you've read this far, thanks for reading and if you can't tell, I'm a big fan of the PRiSM PCI scanner. If you want more info on it or want to get one, please feel free to contact me.
Thanks!