Сотовые вышки связи

Hi Markus, the current opencellid API design may be appropriate for a $random clueless smartphone owner,
but it misses a lot of important and useful technical information that can be gathered
for the network cells.

  1. For GSM you do not collect Timing Advance (TA) which is a much more useful parameter
    for pure positional purposes than signal quality
  2. There is no API specification for signal quality physical units
  3. There is no way to provide UMTS and LTE information (PSC et al.)
  4. For the base stations you do not collect BSIC, antenna directions, ARFCN and other BS physical properties.

I can’t imagine why do you need UMTS and LTE information other than already collected by service. For positioning purposes it’s necessary and enough to have MCC, MNC and one of these:
for GSM: LAC, CID
for UMTS: LAC, SAC
for LTE: TAC, ECI

In the list above LAC corresponds to TAC, CID corresponds to SAC and ECI. Important is that collecting those parameters makes positioning in all generation networks fully compatible - you need 4 parameters with almost the same (in terms of service API) meaning. Thats why you don’t need TA but strongly need signal quality (one reason, another is - TA has gradations about half a kilometer, it is too much in the city). The same applies to different physical BS properties.

As for antenna directions, a phone can’t guess it, nobody can except provider engineers. How do you suggest to collect it?

And there is one more but fundamental problem. I believe that Android SDK don’t have capabilities to collect a lot of parameters you are asking for. Just look at existing Netmonitor software, most powerful can collect about half of parameters you are talking about.

Thank you for these valuable thoughts!

It is correct that Android cannot provide all the requested parameters on one side.
On the other side I can imagine that other hardware might be able to provide additional information today or in the future, so preparing the database for that situation is appropriate.

We can also expect some license compatible data donations from people having such additional information.
Currently we do not try to get such data but will for sure change our approach as soon as the database is able to handle it.

Currently we are in the phase of collecting all such wishes and later this year we´ll then consolidate all of them and try to come up with a proper enhancement of the database.
We are fully aware of the UMTS/LTE issue. In addition also CDMA is not supported which is the next step now regarding database enhancement.

And last but not least the main task for the upcoming weeks is to clean up the database: from the past there are some records with impossible data (e.g. a cell tower with MCC 250 in Africa).
This means that we have to re-check approx. 600 Million records for validity which is a serious task even for a strong server.

Pls keep contributing to OpenCellID. Russia is not yet fully covered and please keep your eyes open if you can find data which is appropriate to be uploaded to OpenCellID, e.g. CLF3 files.

Last but not least: last night a new version of OCID was published: version 3.3,5,2
This is the fasted version ever: yesterday evening we received 2.2 million measurements in 1 file and it was imported in less than 3 hours: http://opencellid.org/#&action=statistics.measurements&sortByRadio=4&dateFrom=&dateTo=&mcc=&mnc=

This data was donated by a Telematics company which uses all its thousands of devices to collect OpenCellID data.

I’m not going to use the “generic” cellphones for data logging. My carefully selected GNSS trackers provide
GPS and GLONASS raw data (not NMEA) together with the GSM and UMTS parameters.
Here is an example of GSM output on Globalsat TR-600G:
http://forum.openstreetmap.org/viewtopic.php?pid=263897#p263897
and later i will post the UMTS output (AT+CGED)
from C027-U200 https://mbed.org/platforms/u-blox-C027

TA is one of the columns in my logs, why not just store it in the database ?

By visual inspection like it is usually being done in frame of this project.
There is still a clear logical separation between the physical objects and their properties (OSM)
an GPS tracks with GSM/UMTS/LTE measured properties (OpenCellID).

I would like to hear your opinion about these slides:
http://math.tut.fi/posgroup/ICSIP2010slides.pdf

I think that Markus59 have sad what he wanted and gone away. So we can speak russian again. At least if we don’t say anything interesting for him.

Вообще, вы правы в том, что если есть такая возможность, то почему бы и не сохранять вообще все, что только можно зафиксировать - и параметры установки антенн, и все возможные параметры сигнала, в том числе и TA. Главное, не менять базовое поведение сервиса - предоставлять информацию о координатах по максимально доступным параметрам MCC-MNC-LAC-CID (и их аналогам для UMTS и LTE). Т.е., например, нужен TA - пусть будет, но опционально.

Вообще смена LAC, SAC, TAC и RAC для оператора сотовой связи раз в год дело святое. LAC же на одной БС может быть например Мегафона или Ростелекома на разных секторов иметь значения 1656, 1602, 1663. CID - номер сектора БС тоже весьма специфическое значение, когда за криворукими подрядчиками приходится производить смену азимутов и если что-то коряво работает смена CID, удаление добавление секторов. А переделкой и отслеживание базы данных БС заниматься в ОСМ будут единицы. Ну и на одной башне могут располагаться все операторы связи, тоже не пятно как их описывать. Наверное в данном случаее теги описывать как operator25002=16_4567 operator25001=16_345 operator25013=16_4713. То есть operatorXXXYY=ZZ_ABCD где XXX - MCC (англ. Mobile Country Code) — мобильный код страны. Например для России: MCC - 250. YYY- MNC (англ. Mobile Network Code) — код мобильной сети. Например для МТС: MNC - 01. ABCD - номер CID без номера сектора. например если МТС и мегафон номер сектора ставят в конце, то Смартс в начале. Соответственно CID в соседних регионах может повторяться. ZZ номер региона.

В большом городе может быть, но в лесу у меня за многие годы ничего не поменялось.

Смотрите какая смешная БС попалась на opencellid:
MCC: 250 (Russian Federation)
MNC: 1 (MTS)
LAC: 20383
Cell ID: 10131
Latitude: 51.589514
Longitude: 68.912590
3 Measurements (2 в Москве и одно во Владивостоке, measured_at с разницей в секунды)
Как можно доверять таким данным?!!
Но даже если насобирать 500+ измерений (а так и получается в ареале моего пмж), то видно же, что алгоритм угадывания местоположения БС весьма ммм туп, так и скажу. Видимо разработчики (надеюсь Markus59 не в одиночку пилит сервис) тестировали алгоритм на сферической бс в вакууме… Среднее геометрическое кмк.
Короче, хочу [разработать] более подходящую модель, в которой будут фильтроваться явные выносы, статистически сравниваться LAC, отсеиваться старые измерения. Главное скажите мне, это не будет велосипедом или никому не нужным трудом?

Баг известный , на в опенцелл данные не зажимают - там что ты можешь выкачать сам замеры и вычислять сам где БСка и выкладывать результат вычислений. Я бы сам занялся но я ленивый :slight_smile:

Да, вот еще какая мысль по сбору данных. Лежит на полке нокия е50 как раз с симбианом на борту, блютусом, но без гпс. Может ее задействовать как-то можно раз уж андроид такой недружественный? А трек или параллельно записывать или через бт организовать координаты. Но нужен софт, который я даже не знаю где искать.

Я мож тоже никогда не выберусь дальше этой темы форума, но тут-то давай более конкретно говорить, а не в стиле КО :wink:
Например, предлагаю свести воедино все характеристики и тонкости в описании БС. Не в ОСМ, а как бы для своей базы данных. Как потом это в ОСМ ляжет - другой вопрос.

Вопрос к знатокам предмета: знает ли модем (сотовый телефон) и/или БС азимут на своего оппонента? Например, программа OpenSignal показывает направление на БС, как бы предлагая двигаться в том направлении для увеличения уровня сигнала :smiley:
Вот откуда эта инфа берется?

И чтоб два раза не вставать - в другой прожке с похожим функционалом (Network Signal Info by KAIBITS Software) замечено показание PSC. А кто-то тут говорил, что до него не добраться в ондроеде… Правда мой древний кусок мамонта еще и рутанутый, может поэтому.
Так какой с этого кода прок? 4095, например.

ИМХО, знает (из базы) положение станции, знает (от GPS) положение телефона → вычисляет азимут и расстояние. С антенны такое не взять, мне кажется - она ж наоборот делается максимально ненаправленной.

http://developer.android.com/reference/android/telephony/NeighboringCellInfo.html#getPsc%28%29
Другое дело что он не всегда адекватен: http://stackoverflow.com/questions/10613736/getpsc-using-gsmcelllocation-always-returns-1

Alexey Illarionov писал выше какой прок.

Вот пример информации AT+CGED и AT+UCELLINFO для UMTS:


+CGED: RAT:"UMTS",
MCC:250, MNC:  2, LAC:03ea, CI:1f85d02, DLF:10762 , ULF:9812
+UCELLINFO: 1, 2, 250,   2, 03ea, 1f85d02, 365, 10762,  30,  42

DLF и ULF надо поделить на 5, чтобы получить частоту канала UARFCN (2152.4 и 1962.4 MHz соответственно).
365 это PSC, 30 это RSCP, а 42 ECN0


<rscp_lev> Number Received Signal Code Power expressed in dBm levels. Range from 0 to 91.
                   0                               RSCP < -115                      dBm
                   1                               -115 = RSCP < -114               dBm
                   ...                                                              ...
                   90                              -26 = RSCP < -25                 dBm
                   91                              RSCP = -25                       dBm
<ecn0_lev> Number Energy per Chip/Noise ratio expressed in dB levels. Range from 0 to 49.
                                                   ECN0 < -24                       dB
                   1                               -24 = ECN0 < -23.5               dB
                                                   ...                              ...
                   48                              -0.5 = ECN0 < 0                  dB
                   49                              ECN0 = 0


Телефон вроде не знает

В API есть, но большинство устройств возвращают неопределенное значение (-1) для текущей ячейки.
Нет timing advance для GSM.

Учитывая, что диапазон 0…511, вообще никакого :slight_smile: У сотовых операторов есть правила по распределению PSC, которые можно использовать.
На одной базовой станции (cell site) 3-4 разных PSC с номерами либо подряд, либо через 8. С одним PSC на станции может быть несколько cell id (на разных частотах, скорее всего).

Он рассказал немного здесь

А кто-нибудь занимался “оцифровкой” их кривых html страниц ?
База данных по моим наблюдениям очень качественная, но устаревшая,
так как нет многих новых секторов.
Старомодные карты генерируются в сферическом меркаторе, так что их легко
использовать в piclayer, а из тэгов можно потом прямо извлечь и примерные
координаты БС.
Для автоматического сравнения LAC/CID нужен все-таки CSV формат.

Читая Вики обнаружил, что в ряде стран сотовые вышки связи обозначаются тэгом man_made=mast , в то время у нас - tower. Хотелось бы уточнить как правильно, поддерживается ли man_made=mast рендерами и конверторами - интересует OSMAnd, Гислабовская гарминовская сборка

Mast и tower это разные виды вышек, у нас mast также используется http://www.openstreetmap.org/node/2989373353
В Garmine и OSMAnd присутствуют.

Вроде бы так?
Mast:

Tower: