I was honored to be a delegate for Mobility Field Day 8 #MF8 last week in Silicon Valley. The experience was something I won’t forget. This week I’ve been invited to present a TENs Talk at WirelessLAN Professionals Conference #WLPC Prague. I figure I had better release one more new and fresh post before becoming a world traveler for the next few weeks.
I recently found an oddity in my LTE Packet Captures. I went for a WarDrive along the freeway in Salt Lake City and later looking at the captures noticed something very odd. Since I work in CBRS and EBS, I’m most interested in the CBRS Shared Home Network Identity (SHNI) or PLMN 315010, CBRS Band 48, or EBS Band 41. Well, when I find my device attempting to connect on Band 2, EARFCN 675, with PLMN 315010, I start scratching my head and want to figure out why. The answer opens up some deeper understanding of 5G NSA and LTE transitional frames.
5G PCAP Support
My tools, SCAT and QCSuper, haven’t been updated with 5G support yet. Everything I’m capturing is LTE or 3G. I have zero visibility into 5G traffic; although my main modem, a Simcom 8200EA-M2, running a Qualcomm X55, is 5G capable. They are working on it as included in another tool’s code here.
The issue comes down to a Wireshark feature called GSMTAP. As talked about here, the issue is that GSMTAP has limits on the size of certain containers. The PCI, ARFCN, and other data used by 5G is too large to fit in the GSMTAP fields. The people who built SCAT and QCSuper are proposing updates to GSMTAP v3 but that hasn’t been ratified yet. LTE only based modems do not have this issue. I haven’t had time to verify if Wireshark 4.0 added support new versions of GSMTAP.
I still awaiting the delivery of a SDR for building a spectrum analyzer, so for now I have to go off what is recorded in the PCAPs. I’m hoping Oscium’s WiPry Clarity opens up the CBRS band soon, since their tool technically supports it. We just need to add the accompanying software to support it.
LTE PCAPs and 5G NSA WarDriving
In my war driving tests, I’ve driven a route a couple times, with every trip showing an oddity along the i215 East Bench of the Salt Lake Valley.
To give a little background for those that are less familiar with LTE Frame types. Every LTE network will broadcast various BCCH Frames called Master Information Block (MIB) and different System Information Blocks (SIBs) at regular intervals. These are similar to a Beacon in the Wifi world, but unlike the Wifi world, a device cannot Probe for a network. Instead everything is passive and devices listen for MIBs and SIBs. The device then uses the MIB to sync its clock with the radio and to know when to listen for any SIBs that may follow. MIB schedules the following SIB1 needed to begin communication. SIB1 contains information such as the Band (2, 41, 48, etc), the PLMN of the network, Tracking Area Code (TAC), Cell Identity, as well as scheduling information for subsequent SIBs that may be needed.
PCAPs Don’t Lie
In the example capture above, the traffic seems normal as I can capture PLMNs from all the public carriers. My device captured three MIBs containing the same information. On the fourth frame, I captured a SIB1. Digging into it, the PLMN contains two PLMNs, 310 260 and 311 490. Looking those up on https://imsiadmin.com/assignments are TMobile/Sprint PLMNs. So we know now that is a TMobile tower. The EARFCN is 675 so typing that in to Cellmapper.net we get the following result:
We now know it’s a FDD LTE network on Band 2 with Uplink 1857.5 and Downlink 1937.5 frequencies. Perfect, looks normal so far.
We then receive the another SIB containing both SIB2 and SIB3. SIB2 provides information about the Uplink and Downlink frequencies, and different parameters required to connect to the radio. SIB3 shows neighboring LTE networks that are on the same channel to help the device switch to another radio. Nothing seems out of the ordinary.
My device then attempts to join this TMobile network. The SIM card in my device is programmed as a CBRS network not affiliated with TMobile, with the PLMN of 315 010. Why is my device trying to join a TMobile network with PLMNs 310 260 and 311 490? Now we are getting into some odd results.
What follows is the device attempting to join the TMobile network. It receives some additional SIBs (SIB4, SIB5, SIB6, and SIB24) and requests a TAC update. It starts the process of connecting with a RRCConnectionSetup frame, a DL_CCCH frame type in the Common Control Channel.
Then there is another oddity, the device sends a “RRCConnectionSetupComplete, Tracking area update request” frame with the CBRS PLMN 315 010 on the UL_DCCH, a dedicated control channel for a radio and UE to communicate. This frame is what caught my attention, why is there a PLMN 315 010 being sent on Band 2? Although the EARFCN is 0, as that information is not captured by the GSMTap, the other data included in the frame signify that it is in the same chain of communication frames, and not some random frame that was captured.
The TMobile radio then communicates back that it can’t identify my device, since obviously it’s not a member of the TMobile network. The radio rejects the TAC update and releases the device with a “RRCConnectionRelease [cause=other]” frame. The device still attempts to attach to the network the with “Attach request, PDN connectivity request” and RRCConnectionRequest frames. The radio sends a RRCConnectionSetup frame then the device responds with a “RRCConnectionSetupComplete, Attach request, PDN connectivity request” frame.
At this point the Radio responds that the device in not a TMobile subscriber with a “DLInformationTransfer, Attach reject (PLMN not allowed)” frame and my device acknowledges that with a “Attach reject (PLMN not allowed)” frame, followed by a “RRCConnectionRelease [cause=other]” frame. After that the device goes back to listening for MIBs and SIBs.
What in the 5G Just Happened?
To understand what is going on here, you have to look at a couple frames I initially skipped over when trying to figure out what was happening.
The first oddity is that normal frames that contain the PLMN 315 010 are in the downlink direction as part of a DL_SCH frame. The frame in question is my device sending an uplink frame UL_DCCH. Also the frames in question are FDD and not TDD as distinguished by a couple columns as all CBRS networks are TDD. The “tdd-config” column has a checkbox in a normal CBRS TDD frame, TDD Configuration is show by the “subframeAssignement” column with a “sa2” in this case, and the “specialSubframePatterns” column is blank compared to a normal CBRS frame with “ssp7” in this case. All of these columns are wrong compared to a normal frame, as you can see in the side-by-side below:
The last piece of information we skipped over is those additional SIBs. SIB4 and SIB5 are used to communicate LTE neighbor networks operating on different frequencies. SIB6 communicates any 3G neighbors operating on different frequencies. Finally, the most important piece of information for understanding this problem is SIB24. My previous studies hadn’t dug that deep into the 5G world as I’m trying to understand the LTE world before I open that can of worms.
SIB24
Like the other SIBs that are broadcast at the same time as SIB24, information about the neighbor radios is communicated to the UE device through these frames. The difference is that SIB24 is used to communicate that a 5G radio is close by on a different frequency. The process is called Cell Reselection, and the frames are broadcast on the LTE network. Since my software tools do not have full support for 5G, the neighboring 5G network is not captured. From a quick glance, I have no idea that a neighboring 5G radio exists, but digging into the frames explains why such an oddity happened.
In the 5G world, the are two different rollouts happening across the cellular frequencies, 5G NSA (Non-Stand Alone) and 5G SA (Stand Alone). 5G NSA is a transition mode for networks that have to operate with legacy 4G clients while building new 5G networks. 5G SA is a fully developed network that only operates on 5G. The clients, RAN, and Core are all 5G only in 5G SA. Most everyone is doing 5G NSA currently on both the public carrier and Private 5G side.
The carriers are all building 5G NSA networks at this time. As an aside, just like in Wifi, a lot of the full benefits of switching to 5G are found with 5G SA and are held back because of the transition in 5G NSA. The CBRS world has a better chance to build 5G SA networks because depending on when an organization enters the market, they may or may not have any legacy clients as long as they ensure all clients, radios, and the 5G Core that are purchased support 5G. From my understanding, full 5G SA Cores are still in development at the time of this writing, and CBRS 5G networks are still in trial mode. Personally, I have played with a few demo 5G cores but our network is still operating with a LTE EPC and RAN.
SIB24 is an option within 5G NSA that has to be turned on the LTE radios. Its purpose is to help LTE connected devices find a 5G network. Looking deeper in the SIB24 frame we can find the Band the 5G network is operating on.
In the captured SIB24 frame, “FreqBandIndicatorNR-r15: 71” signifies that it is Band 71 but the NR piece as I said before stands for 5G NR so it is Band n71. Band n71 is the FDD 600mhz spectrum used by TMobile for their Low Band 5G network. Band n71 operates at 663 – 698 MHz (Uplink) / 617 – 652 MHz (Downlink) with a bandwidth of 35 MHz. The UARFCN for the 5G NSA network is 126510.
Interesting enough if you look through this PCAP, you’ll find that TMobile is operating on the EBS/BRS Band 41 for their Mid Band 5G. EBS is the other band of spectrum separate from CBRS that I’m interested in because of its history with the educational space. We have some licensed Band 41 spectrum that TMobile didn’t get win in the recent auction. Band 41 operates in TDD, like CBRS. TMobile is using TDD Config SA2 and SSP6.
Final Findings..
Since my device is 5G capable, it connected to the TMobile network on LTE and received the SIB24 and was notified of the 5G network. Since my tools cannot capture the 5G traffic, I’m not entirely sure why it chose that network to join.
I originally thought that it was because maybe TMobile was broadcasting the 315010 PLMN on the 5G side. After further examination, it seems to attached only to the LTE network with the TAC Update Requests and attempts to connect. Any guess what is going on here let me know on Twitter @marko_with_a_k.
At the end of the day, I think it just decided randomly that it would attempt to join the TMobile network for no apparent reason. Maybe it’s the driver, maybe TMobile is doing something on their end, maybe it’s something with my SIM. I’ve driven past this tower a couple times and it tries to join it each time so it’s more than just a random occurrence.
The cool thing is that this specific tower led me down a rabbit hole that I was unaware was even a thing. Who would have thought a SIB24 Frame could lead to such insights?
