Difference between revisions of "FAQ"
|Line 1:||Line 1:|
[[File:OpenCellID banner .png|998px]]
Latest revision as of 19:04, 25 April 2018
- 1 Where is the site?
- 2 How can I use the OpenCellID API free of charge?
- 3 Only the few last measurements files have the field <radio>.Is there any other way to know which network a measurement originates from?
- 4 Calculated cell position vs exact cell position
- 5 Signal strength details
- 6 Long cell ID vs. short cell ID
- 7 I know where cell tower x exactly is but OpenCellID shows another position
- 8 I am an OpenStreetMap mapper. How can I also map cell towers?
- 9 How to extract all cells of one country from the cell_towers.csv file?
- 10 What is a CLF format?
- 11 LAC vs. RNC
- 12 What if I just lack the LAC?
- 13 Can I find the distribution of all cells for a given LAC?
- 14 Cell xxx is shown on the map but is not in cell_towers.csv file
- 15 GSM cell IDs with more than 16 bit
- 16 What is the difference between the LAC and TAC in the LTE Modem Status?
Where is the site?
How can I use the OpenCellID API free of charge?
Contributors of data to the OpenCellID database can use the OpenCellID API free of charge.
A contributor of data is entitled automatically for free OpenCellID API use as long as the following minium requirements are met:
A script checks once per day all users with read access and removes the access in case the user reads in 15 days, when he in fact downloaded data, more than 10x more data than he uploaded in this time.
A user reads 100 towers once per week. This means that it will take 15 weeks to execute 15 downloads and 1.500 cells will be downloaded in total during these 15 weeks.
In this case the user should upload at least 150 measurements in the same 15 weeks.
This does NOT require any white listing to be executed by the OpenCellID team.
Only the few last measurements files have the field <radio>.
Is there any other way to know which network a measurement originates from?
Most of measurements from older export files (like measurements_1.csv) have measurements only for GSM and UMTS networks.
At the moment, only the few recent export files have the <radio> field, but we are working on improving exported files and to add the <radio> information to all measurements. It should be done together with the database cleanup in Q1 2015.
At the moment you can roughly assume that if a cell has a cell ID > 65535 then the cell belongs to a UMTS network, otherwise to a GSM network.
Calculated cell position vs exact cell position
The GPS cell position provided in the export files and by the OpenCellID API is either exact or calculated (averaged).
You can find out whether any cell position is exact or not as follows: please read the data format description at http://wiki.opencellid.org/wiki/Menu_map_view#database.
The field "changeable" indicates whether the cell is averaged ("true" value) or exact ("false").
Currently it is not possible to upload measurements with "changeable" flag set to "false". The reason for this is, that this upload would make all measurements of a cell ID obsolete. The OpenCellID admins have the possibility to upload such data. So if you have such data and if this data has a proper license then please send the data by e-mail to the OpenCellID team for uploading it to the OpenCellID database including some information how this data was compiled.
Signal strength details
OpenCellID stores correct values in dBm or ASU (defined in TS 27.007 8.5), but also invalid values as for example 0 that means "no value" or a weak signal, or 99 that means unknown.
Please keep in mind, that the range of the signal depends on the network type.
You can find below rules how to calculate the signal in dBm from ASU for different network types:
GSM (in the range of -51dBM to -113dBM; ASU in the range of 0 to 31):
RSSI [dBm] = (2x ASU) - 113
UMTS (in the range of -25dBM to -121dBM; ASU in the range of -5 to 91):
RSCP [dBm] = ASU - 116
LTE (in the range of -45dBm to -137dBm; ASU in the range of 0 to 95):
RSRP [dBm] = ASU - 140
CDMA (in the range of -75dBm to -100dBm; ASU in the range of 1 to 16):
RSSI [dBm] >= -75: ASU = 16,
RSSI [dBm] >= -82: ASU = 8,
RSSI [dBm] >= -90: ASU = 4,
RSSI [dBm] >= -95: ASU = 2,
RSSI [dBm] >= -100: ASU = 1
Long cell ID vs. short cell ID
The formula for the long cell ID is as follows:
Long CID = 65536 * RNC + CID
RNC: the Radio Network Controller
CID: a short cell ID (an integer in the range of 0 to 65535)
If you have the Long CID, you can get RNC and CID in the following way:
RNC = Long CID / 65536 (integer division)
CID = Long CID mod 65536 (modulo operation)
Example for long cell ID 66808694:
RNC = 66808694 / 65536 = 1019
CID = 66808694 mod 65536 = 27510
I know where cell tower x exactly is but OpenCellID shows another position
There are two main reasons for discrepancies between the actual position of a cell tower and the position reported by OpenCellID:
1) Cell towers and cells are two different things
It is very rare that only one antenna emitting a 360-degree GSM signal is mounted on a physical cell tower. More often, several antennas are mounted on a cell tower, many of them having 3 or 4 per network access type (GPRS, UMTS, LTE...).
In this case, each antenna serves one segment of the full 360 degrees circle. A sample cell tower, with each antennae emitting signals at 120 degrees, is shown here:
This is where the big discrepancy between the number of cell towers and the number of cell IDs comes from:
Vodafone, for example, reports less than 40.000 cell towers ("Basisstationen") in Germany but OpenCellID reports more than 290,000 Vodafone cell IDs in Germany as of August 2014: Vodafone in Wikipedia, OpenCellID statistics
This means that on average one cell tower carries more than seven antennas (= cells).
After understanding that cell towers and cells are not the same, let's see what that means for the computed GPS positions of each cell ID.
Imagine that many cell ID measurements have been collected, equally distributed in one of the pie slices. In this case, the average of all recorded GPS positions would be as indicated in the graph above (e.g. "centre of area 1"). This would then be the position reported by OpenCellID.
In the case where OpenCellID knows which antennas belong to the same cell tower, this information could be used to average the positions of all cell IDs (antenna sectors) of one cell tower; this would then give a precise position of the cell tower. Unfortunately, OpenCellID has very little knowledge about the numbering schemes of the different GSM network providers and network access types today. In the case that you can provide such information for one or the other networks, this would be very helpful for improving the data quality of OpenCellID.
2) The measurements of cell towers are not always distributed equally around a cell tower
There are countless situations where it is not easy to approach a cell tower from each side by car, bicycle or as a pedestrian. Just imagine a cell tower on a hill where just one road passes by on one side:
In this case, the measurements will not be equally distributed around a cell tower, meaning that most of the measurements may be coming from just one side of the cell tower. As a result, averaging the GPS positions of all these measurements will most likely not accurately locate the centre of the respective cell tower's segmented area.
I am an OpenStreetMap mapper. How can I also map cell towers?
OpenCellID mainly collects MCC, MNC, LAC, and CID information combined with a GPS position.
In most cases, it is not possible to obtain this data by going to a cell tower for various reasons:
- the cell tower might be on a rooftop which is not accessible
- there is no sign at the base station indicating such information
- there are many antennas all together and it is not possible to find out which antenna has which cell ID
In addition, one of the basic rules of OSM is to map visible things. This is not the case here as MCC/MNC/LAC/CID are not visible in most cases.
Therefore, only a very small number of cell towers is currently mapped in OSM with MCC/MNC/LAC/CID tags.
The most effective way to contribute to OpenCellID is to use one of the smartphone applications listed here and to collect measurements while mapping something else.
The Keypad-Mapper 3, for example, has a built-in feature to record cell tower data while mapping house numbers / addresses.
How to extract all cells of one country from the cell_towers.csv file?
Due to the size of the cell tower file it is not possible to use common programs like Excel or Microsoft Word for this task.
One way to extract the required data is as follows:
- Download cell_towers.csv file here.
- Install the free Windows software CSVed.exe on your windows PC.
Last version we tested successfully was version 2.3.2 (2014). It creates a shortcut on your desktop during its installation.
- Run CSVed.exe and load the CSV file.
- Use "Filter & Dups" feature for filtering and saving the required data; filtering the data takes a few minutes but works perfectly well.
- Open the extracted data with Excel or any other CSV-compatible software for further examinations.
A big thank you to Sam Francke for this great tool!
What is a CLF format?
CLF files contain information about mobile network cells.
They were used in some Nokia mobile phones for logging cell data: cell Id, LAC, MCC, MNC, location, etc.
OpenCellID supports the import of CLF files as a source of information on cell locations. During the upload of the data it can be defined if the uploaded data is measurements or if the file contains precise information of cell tower positions which would then override the average of all GPS positions of all measurements of a given cell.
The following versions are supported: 2.0, 2.1, and 3.0.
CLF version 2.0
Files have the following format:
(plus symbol means that values are not separated; <TAB> — tabulation character)
Example: 239731EF26202<TAB>City Square
CLF version 2.1
Files have the same format as in version 2.0 but cell ID and LAC are stored as decimal values.
CLF version 3.0
This format uses more information about cells. It has the following format:
Cell ID and LAC can be decimal or hexadecimal.
LAC vs. RNC
One RNC can handle multiple LACs. RNC ID does not necessarily have a connection to LAC ID - it depends on how the network is planned. For example, you can find in the same RNC (12) LACs 33, 21 and 78 - with no connection between them. No relative connection of RNC IDs and LAC. This is based on how to plan the network. LAC depends on paging. RNC ID is same as site IDs. It only serves as identification.
What if I just lack the LAC?
Menu_map_view#search_location says "All input fields are obligatory." But what if I lack the LAC. Can I still find the given cell-id? Answer: perhaps try entering the LACs found nearby.
Can I find the distribution of all cells for a given LAC?
Perhaps try downloading the database and do analysis on it.
Cell xxx is shown on the map but is not in cell_towers.csv file
This can happen, because cells are displayed on the map in real-time but cell_towers.csv file is generated on daily basis only.
If a cell is created then you can see it immediately on the map, but it will be available in cell_towers.csv next day only.
The cell_towers.csv file is newly created every night around 3pm UTC.
GSM cell IDs with more than 16 bit
|On some phones GSM cell IDs are reported with more than 16 bit (higher than 0XFFFF).|
It has also been found that on the same phone in the same network the same cell ID has been reported with different network types.
From technical point of view this seems to be incorrect as GSM defines 16 bit cell ID.
When API 17 was introduced to Android 4.2 there was no separate class for UMTS cells, instead they used same class as for GSM and added there PSC field (now deprecated). (see http://developer.android.com/reference/android/telephony/CellIdentityGsm.html#getPsc() ).
What is the difference between the LAC and TAC in the LTE Modem Status?
Both the LAC and TAC share the same concept of providing the location code of a base station set. The only difference between LAC and TAC is that the LAC is the terminology used in GSM/UMTS while the TAC is the terminology used in LTE.