Meaning of Cell ID?


#1

I’m working with the SNMP query options for WAN interfaces, and the OID .1.3.6.1.4.1.27662.2.1.2.1.6.1 gives a value identified as wanCellID which matches the field in incontrol2 in the wan details labelled “Cell ID”. I see no explanation of what that Cell ID refers to. I had thought it meant the ID of the cell tower, but now that I have 2 devices side by side with the same service in the same location, one has ID 5910 and the other has ID 5911, making me think perhaps the number is unique per client on a tower. Can someone clarify this for me?

Thanks,
Jim


#2

I believed it was unique to per cell tower radio.
Could you be connected to two different towers or two different radios on the same tower?
We have seen the same and different on an HD4 in the past


#3

A Cell ID refers to a specific LTE Band coming off of a tower and more specifically a Sector on that tower.


#4

Hmm.

The difference of “Cell ID” between the two radios was surprising to me because I had assumed it was some kind of tower ID thing. Tim_S’s answer seems to match with my assumption. The part of my assumption that appears to be wrong is that they’d both have the same number at the same time.

Perhaps after a few days of data gathering I’ll be able to crunch the data and find out if they ever do have the same number.

I’m working on a project to log cellular signal information tied to GPS coordinates. Right now, I’m testing everything locally, and once the vehicle goes in the field, the BR1 will have an AT&T sim card to test how AT&T compares to Verizon in the ares of interest. But for now, the BR1 has a Verizon sim, so I can at least get some readings for my testing.

The max transit is broadcasting GPS in NMEA format on the local network segment to a raspberry pi, which turns that into latitude, longitude, and altitude, as well as grabbing the date and time from the GPS to form a timestamp for the record. Once that GPS packet is received and processed, the script then queries the max transit and max br1 for the cellid and strength individually, then fetches the undocumented items with a walk of .1.3.6.1.4.1.27662.200.1.12.1.1.1. It then stuffs everything into a complex data structure that is frankly ugly, then spits that record to a log file in json format. Originally I was using CSV for compactness, but after changing the fields and field orders too many times, I switched to json since the data format is self documenting. Every hour, that data is backed up to an on-board nas device, then nightly uploaded to a vps.

I’ve got the following data record saved from a max transit and a max br1. The record is stored in json format, and the entire record is retrieved from the two devices with back to back snmp queries within the code. The two devices have about 2 meters horizontal separation between each antenna, same model antenna, on the roof of a chevrolet suburban. Both devices are on Verizon Wireless. Both have the same plan, the alleged “unlimited” plan. This record was output using the pprint() function in python to make it easier to read. I left out the timestamp, latitude, longitude, and altitude readings as they aren’t relevant and I’m not keen on putting my GPS location in a forum. :grin:

Transit:
{‘cellid’: ‘49667’,
‘signal’: {‘band’: ‘LTE Band 13 (700 MHz)’,
‘id’: ‘28933’,
‘mode’: ‘LTE’,
‘mystery’: ‘-1’,
‘rsrp’: ‘-86’,
‘rsrq’: ‘-9’,
‘rssi’: ‘-63’,
‘sinr’: ‘10’},
‘strength’: ‘-63’}

BR1:
{‘cellid’: ‘49696’,
‘signal’: {‘band’: ‘LTE Band 13 (700 MHz)’,
‘id’: ‘28933’,
‘mode’: ‘LTE’,
‘mystery’: ‘-1’,
‘rsrp’: ‘-85’,
‘rsrq’: ‘-10’,
‘rssi’: ‘-58’,
‘sinr’: ‘19’},
‘strength’: ‘-58’}

‘cellid’ is from .1.3.6.1.4.1.27662.2.1.2.1.6.1
‘strength’ is from .1.3.6.1.4.1.27662.2.1.2.1.5.1

everything in the ‘signal’ set is taken from readings within .1.3.6.1.4.1.27662.200.1.12.1.1.1, which is totally undocumented, and lacking a MIB hint hint. Through comparison with readings via the web interface and incontrol, I’ve mapped most of them. But the “id” and “mystery” ones I don’t have any way to identify properly.

‘rssi’ is from .1.3.6.1.4.1.27662.200.1.12.1.1.1.3
‘sinr’ is from .1.3.6.1.4.1.27662.200.1.12.1.1.1.5
‘rsrp’ is from .1.3.6.1.4.1.27662.200.1.12.1.1.1.7
‘rsrq’ is from .1.3.6.1.4.1.27662.200.1.12.1.1.1.8
‘mode’ is from .1.3.6.1.4.1.27662.200.1.12.1.1.1.9
‘band’ is from .1.3.6.1.4.1.27662.200.1.12.1.1.1.10
‘mystery’ is from .1.3.6.1.4.1.27662.200.1.12.1.1.1.11 (and seems to always be ‘-1’)
‘id’ is from .1.3.6.1.4.1.27662.200.1.12.1.1.1.12

In the above record, the “Cell ID” aka ‘cellid’ is different for the two devices. But the ‘id’ from the undocumented items is the same.


#5

Well, it appears that sometimes they are the same:

>>> pprint(record)
{'altitude': 20.7,
 'cellular': {'br1': {'cellid': '5911',
                      'signal': {'band': 'LTE Band 4 (AWS 1700/2100 MHz)',
                                 'id': '28161',
                                 'mode': 'LTE',
                                 'mystery': '-1',
                                 'rsrp': '-98',
                                 'rsrq': '-6',
                                 'rssi': '-73',
                                 'sinr': '23'},
                      'strength': '-73'},
              'transit': {'cellid': '5911',
                          'signal': {'band': 'LTE Band 4 (AWS 1700/2100 MHz)',
                                     'id': '28161',
                                     'mode': 'LTE',
                                     'mystery': '-1',
                                     'rsrp': '-99',
                                     'rsrq': '-7',
                                     'rssi': '-71',
                                     'sinr': '23'},
                          'strength': '-71'}},
 'latitude': 38.3340492,
 'longitude': -75.5512286,
 'timestamp': 1532107098.0}

note: latitude and longitude modified
Cell ID and the undocumented ID number match between both devices

jim


#7

@baadpuppy, we are preparing the SNMP MIB files for firmware 7.1.1, that will be updated to the website once it is ready.

Please find below the description on the OIDs below.
.1.3.6.1.4.1.27662.2.1.2.1.6.1 Cell ID
.1.3.6.1.4.1.27662.200.1.12.1.1.1.11 LAC
.1.3.6.1.4.1.27662.200.1.12.1.1.1.12 TAC

About the Cell ID definition, are you referring to https://en.wikipedia.org/wiki/Cell_ID, where Cell ID (CID) is 16 bits, unique ID of the Cell?


#8

@WeiMing, thank you for the information.

By “Cell ID”, I was referring to the value returned by the OID .1.3.6.1.4.1.27662.2.1.2.1.6.1 titled I believe “wanCellID” and listed above as “Cell ID” in your post. I really was recording that information more out of curiosity than wanting to decode or decipher anything. I was surprised when the number didn’t match between two different MAX devices, although apparently the different sector id explains that. I am also recording the values you describe as LAC and TAC, also for the sake of curiosity.

However, now that I’ve read the wiki link you posted, I am even more curious. I might be able to use some of those database sources listed to get additional information, which would be very cool.

I still don’t know what a TAC is, nor why the LAC is always -1, but I’m enjoying the research path you’ve put me on. Thanks!

Jim


#9

@WeiMing, would you mind clarifying the description of the following OIDs in 7.1.1?

iso.3.6.1.4.1.27662.200.1.12.1.1.1.13.0 = INTEGER: 72790
iso.3.6.1.4.1.27662.200.1.12.2.1.1.1.0 = INTEGER: 0
iso.3.6.1.4.1.27662.200.1.12.2.1.1.2.0 = STRING: “359225051385961”

Thanks,
Jim


#10

@baadpuppy

We going to release the latest MIB soon for firmware version 7.1.1. This will explain all the OID involved.

For time being, please refer to the following screenshot:

iso.3.6.1.4.1.27662.200.1.12.1.1.1.13.0 = INTEGER: 72790

iso.3.6.1.4.1.27662.200.1.12.2.1.1.1.0 = INTEGER: 0

iso.3.6.1.4.1.27662.200.1.12.2.1.1.2.0 = STRING: “359225051385961”

Edit:
Latest MIB released:
https://www.peplink.com/support/downloads/software-supplements/


#11

Thank you,
Jim


#12

Hi Peplink Support,

May I ask what’s the format of the cell ID? decimal or hexadecimal?

Thanks.
~ Khaw