Пара слов о CID и SAC
Все мы привыкли к стандартным BTS (Base Transceiver Station) и CID (Cell ID) в случае с GSM. Тут все просто — в каждый момент времени телефон обслуживается одной BTS, а вернее, одним конкретным сектором, имеющий уникальный внутри местности CID. С приходом UMTS, на первый взгляд, изменилось не много — BTS переименовали в Node B, а BSC в RNC.
Однако, это не совсем так. Гораздо более важное изменение состоит в самом способе передачи данных. Если в GSM абонентское устройство в каждый момент времени обслуживается только одним сектором, хоть и имеет информацию о других, то в UMTS телефон видит уже одновременно несколько вышек (Node B). В GSM, CID однозначно указывает на сектор базовой станции. В UMTS же, однозначно указывает на местоположение уже не CID, а SAC — Service Area Code. Этот SAC (код местности обслуживания), может охватывать как один, так и несколько секторов. Он состоит из двух октетов, т.е. может принимать значения от 0 до 0xFFFF (65535).
Что это означает для Нетмониторинга
А вот теперь самое интересное. По идее, в UMTS вообще не должно быть никаких CID, должны быть только SAC, каждый из которых может покрывать одну или несколько сот. Однако, лично я не встречал ни одного мобильного телефона, ни одного приложения для Android, которое бы умело определять и показывать SAC. Напротив, все они упорно отображают для UMTS именно CID, причем, всего один.
Отсюда может быть два противоречивых вывода:
1.Телефоны определяют именно SAC, хоть и обзывают его CID-ом.
В пользу этой версии говорит то, что т.н. CID для UMTS всего один, хотя должно бы быть несколько. Более того, смартфоны, которые умеют отображать соседей (а это, по крайней мере, некоторые из HTC), упорно не хотят этого делать на 3G. Так что вполне возможно, что все соседи уже учтены в единственном значении SAC, которое просто для удобства/красоты или от незнания названо CID.
2.Телефоны определяют CID.
Один, непонятно какой, но CID, которых в каждом SAC может быть несколько. Но это было бы странно, т.к. необходимость позиционирования мобил никто не отменял, кроме того, просто чтобы работать, телефону нужны данные о SAC, так что они должны бы быть. А если бы они были, они были бы доступны. Я так думаю.
Так вот, какая бы версия не была правильной, нам, нетмониторщикам, можно просто опустить различия в названиях, и считать SAC таким же номером сектора. И сервис местоположения секторов http://opencellid.org/ работает, как предполагается, в любом случае. Ведь наши телефоны отправляют на сервисы геопозиционирования именно те данные, которые могут получить, и которые видим мы при использовании программ-нетмониторов.
Немного о сервисах определения координат базовых станций
Выше я уже упоминал об этом, а теперь расскажу чуть более подробно. Все крупные сервисы устроены схожим образом — они накапливают свои базы данных, когда мы пользуемся их приложениями. Так, для пополнения базы Гугла, достаточно лишь использовать смартфон на базе ОС Android (привет, Сноуден), а для пополнения базы Яндекса, надо использовать Яндекс-Карты (добро пожаловать в Россию, Эд). Есть еще пара независимых проектов, которые просят пользователей самостоятельно установить на свой телефон или смартфон некое приложение — так поступает проект OpenCellID, и пока еще молодой, но подающий надежды Mozilla Location Services.
https://location.services.mozilla.com/
Тут, кстати, надо понимать, какая именно информация отправляется на сервера. Это, во-первых, номер соты (наш любимый CID), а во-вторых — GPS-координаты текущего местоположения телефона. Я думаю, понятно, что текущие координаты телефона могут быть весьма удалены от реального местоположения базовой станции? Но таких координат в базе много, т.к. и смартфонов сейчас много. И если мы делаем запрос к базе, то нам отдают усредненные координаты, но не базовой станции (их узнать не получится никак), а именно сектора — той местности, где телефоны чаще всего обслуживались сектором с искомым CID. Так что, используя сервис местоположения базовых станций, вы получаете не координаты самой базовой станции, а координаты центра того места, где на указанном CID работают телефоны.
Яндекс пошел несколько дальше, и даже пытается определить координаты самой базовой станции. Делает он это очень просто — вычисляет центр между секторами. Логично предположить, что где-то между координатами секторов и будут координаты базовой станции.
А ты, что сделал для развития нетмониторинга?
Кстати говоря, вы можете несколько ускорить процесс наполнения одной из перспективных баз, установив и почаще запуская приложение MozStumbler https://github.com/dougt/MozStumbler/releases для Android.
Это приложение сканирует эфир и отправляет данные в базу Mozilla Location Services, которая хороша уже тем, что доступ к ней абсолютно свободен, без всяких ключей и ограничений, а наполнение прозрачно и доступно.
Все мы привыкли к стандартным BTS (Base Transceiver Station) и CID (Cell ID) в случае с GSM. Тут все просто — в каждый момент времени телефон обслуживается одной BTS, а вернее, одним конкретным сектором, имеющий уникальный внутри местности CID. С приходом UMTS, на первый взгляд, изменилось не много — BTS переименовали в Node B, а BSC в RNC.
Однако, это не совсем так. Гораздо более важное изменение состоит в самом способе передачи данных. Если в GSM абонентское устройство в каждый момент времени обслуживается только одним сектором, хоть и имеет информацию о других, то в UMTS телефон видит уже одновременно несколько вышек (Node B). В GSM, CID однозначно указывает на сектор базовой станции. В UMTS же, однозначно указывает на местоположение уже не CID, а SAC — Service Area Code. Этот SAC (код местности обслуживания), может охватывать как один, так и несколько секторов. Он состоит из двух октетов, т.е. может принимать значения от 0 до 0xFFFF (65535).
Что это означает для Нетмониторинга
А вот теперь самое интересное. По идее, в UMTS вообще не должно быть никаких CID, должны быть только SAC, каждый из которых может покрывать одну или несколько сот. Однако, лично я не встречал ни одного мобильного телефона, ни одного приложения для Android, которое бы умело определять и показывать SAC. Напротив, все они упорно отображают для UMTS именно CID, причем, всего один.
Отсюда может быть два противоречивых вывода:
1.Телефоны определяют именно SAC, хоть и обзывают его CID-ом.
В пользу этой версии говорит то, что т.н. CID для UMTS всего один, хотя должно бы быть несколько. Более того, смартфоны, которые умеют отображать соседей (а это, по крайней мере, некоторые из HTC), упорно не хотят этого делать на 3G. Так что вполне возможно, что все соседи уже учтены в единственном значении SAC, которое просто для удобства/красоты или от незнания названо CID.
2.Телефоны определяют CID.
Один, непонятно какой, но CID, которых в каждом SAC может быть несколько. Но это было бы странно, т.к. необходимость позиционирования мобил никто не отменял, кроме того, просто чтобы работать, телефону нужны данные о SAC, так что они должны бы быть. А если бы они были, они были бы доступны. Я так думаю.
Так вот, какая бы версия не была правильной, нам, нетмониторщикам, можно просто опустить различия в названиях, и считать SAC таким же номером сектора. И сервис местоположения секторов http://opencellid.org/ работает, как предполагается, в любом случае. Ведь наши телефоны отправляют на сервисы геопозиционирования именно те данные, которые могут получить, и которые видим мы при использовании программ-нетмониторов.
Немного о сервисах определения координат базовых станций
Выше я уже упоминал об этом, а теперь расскажу чуть более подробно. Все крупные сервисы устроены схожим образом — они накапливают свои базы данных, когда мы пользуемся их приложениями. Так, для пополнения базы Гугла, достаточно лишь использовать смартфон на базе ОС Android (привет, Сноуден), а для пополнения базы Яндекса, надо использовать Яндекс-Карты (добро пожаловать в Россию, Эд). Есть еще пара независимых проектов, которые просят пользователей самостоятельно установить на свой телефон или смартфон некое приложение — так поступает проект OpenCellID, и пока еще молодой, но подающий надежды Mozilla Location Services.
https://location.services.mozilla.com/
Тут, кстати, надо понимать, какая именно информация отправляется на сервера. Это, во-первых, номер соты (наш любимый CID), а во-вторых — GPS-координаты текущего местоположения телефона. Я думаю, понятно, что текущие координаты телефона могут быть весьма удалены от реального местоположения базовой станции? Но таких координат в базе много, т.к. и смартфонов сейчас много. И если мы делаем запрос к базе, то нам отдают усредненные координаты, но не базовой станции (их узнать не получится никак), а именно сектора — той местности, где телефоны чаще всего обслуживались сектором с искомым CID. Так что, используя сервис местоположения базовых станций, вы получаете не координаты самой базовой станции, а координаты центра того места, где на указанном CID работают телефоны.
Яндекс пошел несколько дальше, и даже пытается определить координаты самой базовой станции. Делает он это очень просто — вычисляет центр между секторами. Логично предположить, что где-то между координатами секторов и будут координаты базовой станции.
А ты, что сделал для развития нетмониторинга?
Кстати говоря, вы можете несколько ускорить процесс наполнения одной из перспективных баз, установив и почаще запуская приложение MozStumbler https://github.com/dougt/MozStumbler/releases для Android.
Это приложение сканирует эфир и отправляет данные в базу Mozilla Location Services, которая хороша уже тем, что доступ к ней абсолютно свободен, без всяких ключей и ограничений, а наполнение прозрачно и доступно.