DISH gNB Issue

From CellMapper Wiki
Revision as of 04:39, 4 February 2024 by RyanThaDude1 (talk | contribs) (Created page with "==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...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

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.

Math-20240203(6).png

Dish proposed-gnb cellnum.png

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: Math-20240203(4).png and its cell number Math-20240203(3).png. 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.

The result came by complete accident while just plugging numbers. Basically, what we're doing is using the 24/12 method, multiplying 256 to make it unique while finding the remainder of dividing the result by 21 and adding them together. We're now left with a number that actually looks similar to the current 32/4 method that's being used and data is consistent. All n71 cells now fall under cells 6, 7, 8, gNBs don't split between sites, and no sites have unnecessary multiple gNBs. Again, this may not be 100% correct, but it does work, and it has worked with all data throughout the United States.

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)*256)+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.