DISH gNB Issue
The Problem
Currently, Cellmapper is using a method of calculating the gNB ID that cannot be correct and can provide false information. One major issue is that the current calculated gNB can be on two different physical sites. While this isn't abnormal for DAS sites, this is for macros. Another issue is that a single physical site can also have two gNBs. Again, not abnormal, but often it's accompanied with the first issue with one, or even sometimes both of the gNBs. Lastly, frequency bands on most providers usually line up with a certain cell number. As you guessed it, not the case with this calculation.
The Potential Fix
First and foremost this solution provided may not be 100% correct. The gNB may not be official but it does solve all of the major problems that is preventing normal usage.
gNB = floor(cellID / 212)_floor(cellID mod 212) / 21)
cellNum = (cellID mod 212) mod 21
Background
The definition of the gNB is beyond the scope of this document, but simply, it's a 36-bit number. Part of the binary number is the gNB and the rest is the cell number. For example, T-Mobile uses a 24-bit gNB, which gives it a 12-bit cell number, or a potential of 4096 cells! The method that Cellmapper is calculating the gNB is a 32-bit gNB and a 4-bit cell number: gNB = floor(cellID / 24)
and its cell number cellNum = cellID mod 24
. This gives 16 cells per gNB. At this point we already know this isn't correct.
After sifting through a lot of the data available on Cellmapper, a pattern was found which gave 21 cells per site. If we're slicing a 36-bit you realize you can't use 21. So we have to look for another way.
This post on Reddit was found, stating that "Just got confirmation back that DISH is using 24/12 bit structure for their gNBs." If this is true, this would produce 4096 cells, way more than the 21 needed for DISH. We need to dig deeper.
What we found out is DISH is indeed using 24/12 format, but going a step further. A group of sites in an area can have the same gNB. To break it down even further, the number 21 comes into play. Take a cell ID, divide it by 212, or 4096. This gives the base gNB. Now we append a secondary number with a separator with floor(cellID mod(212) / 21)
, such as a dash or underscore.
Here's a quick example for a cell ID of 1011724336, which is a site at 38.217800, -85.625314 Louisville, KY.
gNB = floor(cellID / 2^12)_floor(cellID mod 2^12) / 21) gNB = floor(1011724336 / 4096)_floor(1011724336 mod 4096 / 21 gNB = 247003_floor(48 / 21) gNB = 247003_2
cellNum = (cellID mod 2^12) mod 21 cellNum = (1011724336 mod 4096) mod 21 cellNum = 48 mod 21 cellNum = 48 mod 21 cellNum = 6
Therefore, a DISH Wireless cell ID of 1011724336 belongs to a gNB of 247003_2 and it's cell number is 6.
History
Previously it was thought that due to many using 32/4 that the gNBs should be similar numbers, so in order to create a similar number, a more complex formula was used. Basically, the primary gNB was multiplied by 256 and the secondary was then added. Using the example above, 247003 was the primary, so we're multiply it by 256 which the result will be 63232768. Add the 2 and we get 63232770. Cellmapper's 32/4 calculation gives us 63232771, which is very close. Although this could still be a viable option, its usage has been deprecated due to its complexity.
Bands
Using the formula posted above, you'll find that the bands all match these cell numbers:
Cell Num | Band |
---|---|
0 | unknown |
1 | |
2 | |
3 | unknown |
4 | |
5 | |
6 | n71 |
7 | |
8 | |
9 | unknown |
10 | |
11 | |
12 | n70 |
13 | |
14 | |
15 | n66 |
16 | |
17 | |
18 | n66 |
19 | |
20 |
Try It For Yourself
An easy way to see how this works is to try it for yourself. The best and easiest way is to use a spreadsheet such as Excel or Google Sheets.
gNB: =FLOOR.MATH(A1/2^12)&"_"&FLOOR.MATH(MOD(A1,2^12)/21)
, where A1 is the full Cell Identifier, in decimal.
cellNumber: =MOD(MOD(A1,2^12),21)
Summary
The current method that Cellmapper is using to calculate DISH Wireless's gNB is incorrect and a potential fix has been provided. There are no guarantees this method is correct as well, but it does allow the data to align properly.